docs(adr): propose Monk kit for Live deployment and packaging

[nooga]

Summary

• Adds docs/adr/ and ADR-0001 proposing Monk as the hosted Live packaging/deploy path (publishable Kit: Supabase entity + bootstrap + dashboard; Modal stays SaaS).
• Wires the ADR from docs/ARCHITECTURE.md, docs/README.md, and a DECISIONS.md row.
• Status is Proposed — documents the intended design constraints up front; Kit implementation is intentionally out of scope for this PR.

Test plan

• Skim ADR-0001 for clarity and consistency with Live = Supabase + Modal
• Confirm links from Architecture / docs index / DECISIONS resolve
• Docs-only change — no runtime/CI behaviour expected

Checklist

• ./scripts/quality-gates.sh passes locally
• New tests added or updated (or change is docs-only)
• Docs updated where applicable
• No secrets or credentials committed

[nooga]

There is a PoC implementation of this ADR on a separate branch (Monk Kit + in-cluster bootstrap image, DigitalOcean Live deploy with Supabase + Modal):

https://github.com/nooga/tripwire/tree/feat/monk-live-supabase-modal-kit

Happy to open a follow-up PR against main if that sounds okay — please say if you’d rather wait until this ADR is accepted/merged first, or if you want any shape changes before I send it.

[neomatrix369]

Thanks for creating this PR and the Change request @nooga

I'm going to run a quick docs related check on this but overall seems good

Except I see a few things missing, so after my review we can decide the next steps.

[neomatrix369]

There is a PoC implementation of this ADR on a separate branch (Monk Kit + in-cluster bootstrap image, DigitalOcean Live deploy with Supabase + Modal):

https://github.com/nooga/tripwire/tree/feat/monk-live-supabase-modal-kit

Happy to open a follow-up PR against main if that sounds okay — please say if you’d rather wait until this ADR is accepted/merged first, or if you want any shape changes before I send it.

We can surely consider this but I need to generate a plan on the back of the ADR unless the ADR is sufficient and then align it with the changes made, so lets keep discussing and bring this together, this is a great start!

Im eager to see how this will look like once we have bridged the gaps!

[neomatrix369]

@nooga when you get a chance can you pls rebase your branch with main from remote - I have pushed some CI/CD related fixes

[neomatrix369]

Thanks @nooga — the direction is good, and this pull request can stay Proposed and documentation-only. It is not yet the minimum record we need before writing implementation slices under docs/plan, so please add the five items below and leave everything else out of this ADR.

Please add (minimum)

1. Keep current Live and intended Live visibly separate. This ADR is a proposal, not a shipped capability. Until it is accepted and implemented, the documented Live path remains the operator workstation flow (local .env, CLI, QUICKSTART). Please do not describe Tripwire as already immediately deployable or packaged via Monk.

2. State the five-vendor Live baseline in the Decision. A packaged Live instance is Supabase, Modal, Snyk, Cisco, and Tessl — not only the dashboard and database. Scanner credentials for Snyk, Cisco, and Tessl are required for a successful Kit deploy. Do not treat them as optional, and do not treat a missing scanner key as an acceptable Live outcome. You can keep Cisco LLM versus paid AI Defense as a single clarifying sentence; do not omit Cisco as a vendor.

3. Say what runs in the cluster versus what stays SaaS. In the cluster: bootstrap, the dashboard, and HTTPS ingress. Outside the cluster: Supabase (PostgREST), Modal, and the three scanner engines. Modal remains an external SaaS; it is not a cluster workload.

4. Define when Kit v1 is done. Success is: credentials for all five vendors collected; Supabase provisioned and wired; schema applied; Modal app deployed with scanner secrets; HTTPS Live dashboard can read PostgREST. If scanner credentials are missing, the deploy is incomplete — not a successful Live instance.

5. Say how this coexists with today’s docs, and what this ADR does not decide. The Monk path is additive until it is implemented. Out of scope here: Kit YAML and Dockerfiles, registry publication, authentication/identity providers, other database backends, teaching the CLI to use an instance URL, locking a cloud vendor, and the implementation plan itself.

A one-line definition of Monk is enough (a packaging and deploy runtime that consumes a Kit: manifest, templates, and secrets). Please also rebase this branch onto current main when you push the update.

Please do not add

Proof-of-concept implementation detail, a specific cloud region or provider, architecture diagram rewrites, or slice specifications. Those belong in follow-up work after this ADR lands.

Once the five items above are in the ADR, we can merge it as Proposed and start slice creation under docs/plan.

[neomatrix369]

Thanks @nooga — the direction is good, and this pull request can stay Proposed and documentation-only. It is not yet the minimum record we need before writing implementation slices under docs/plan, so please add the five items below and leave everything else out of this ADR.

The things we are ommiting/removing from the ADR will be implemented/written into the slice plan coming up next.