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.

[nooga]

Rebased onto current main (224 commits) and reworked the ADR against your five items. Now three files instead of five — docs/ARCHITECTURE.md and docs/README.md already link adr/README.md on main, so those hunks were redundant and I dropped them.

The five items:

1. Current vs intended Live — opens with a blockquote saying plainly this isn't implemented and the supported Live path is still the workstation flow (.env, CLI, QUICKSTART). Renamed "Ideal user path" → "Intended user path (after implementation)".
2. Five-vendor baseline — Supabase, Modal, Snyk, Cisco, Tessl, all required. Dropped the old "optional scanner/API keys" line. Cisco has one clarifying sentence: two credential shapes (Skill/MCP Scanner LLM keys, or paid AI Defense), at least one required, not droppable.
3. Cluster vs SaaS — table. In-cluster: bootstrap, dashboard, HTTPS ingress. SaaS: Supabase/PostgREST, Modal, the three scanner engines. Modal explicitly not a cluster workload.
4. Kit v1 done-definition — new section; missing scanner credentials make the deploy incomplete, not a Live instance.
5. Coexistence + non-goals — Monk path is additive; explicit out-of-scope list (Kit YAML, Dockerfiles, registry publication, auth providers, other DBs, CLI instance-URL, cloud vendor, the plan itself).

No PoC detail, no cloud provider/region, no diagram changes, no slice specs. Also unreserved 0001 in docs/adr/README.md and added a DECISIONS row.

Two things I'd like you to rule on:

Ossprey. Your five-vendor list predates the Ossprey adapter landing (2026-08-25). It's credential-gated, RESEARCH-labeled, and access provisioning is still open (slice 35 🔴), so I kept the baseline at five and added one sentence putting Ossprey explicitly outside Kit v1 rather than quietly making it six. Shout if you'd rather it be in.

Five vendors vs Minimum Viable Live. env-vars.md documents MVL as Supabase + Modal only, with Snyk/Tessl/Cisco as "add for full coverage." Requiring five raises the bar. I flagged it in Costs and open questions as deliberate — a packaged instance shouldn't ship with partial scanner coverage — but if you'd rather Kit v1 match MVL and treat full coverage as a later flavor, that's a one-paragraph change.

The CI and Code Review Graph runs are sitting at action_required — they need your approval to run.

[github-actions]

code-review-graph review

Overall risk: 0.00 (LOW) — 0 changed function(s)/class(es), 0 affected flow(s), 0 test gap(s)

Token savings: this graph-backed report used ~31,572 fewer tokens (~100%) than reading every changed file in full (estimated, chars/4 approximation).

---

Powered by code-review-graph — local-first analysis; no code leaves the CI runner.

[neomatrix369]

@nooga mostly looks good, thanks for the updated PR

Cluster vs SaaS — table. In-cluster: bootstrap, dashboard, HTTPS ingress. SaaS: Supabase/PostgREST, Modal, the three scanner engines. Modal explicitly not a cluster workload.

What does "Modal explicitly not a cluster workload." mean? It will still be configured for the system to reach out and spin off sandboxes?

Ossprey. Your five-vendor list predates the Ossprey adapter landing (2026-08-25). It's credential-gated, RESEARCH-labeled, and access provisioning is still open (slice 35 🔴), so I kept the baseline at five and added one sentence putting Ossprey explicitly outside Kit v1 rather than quietly making it six. Shout if you'd rather it be in.

Lets make the API key for OSSPREY available, we can tweak this later on but thats the simple minimum and should not be too much effort.

Five vendors vs Minimum Viable Live.

Can we aim for MVL also we are missing two more vendors SIE (Superlinked) and Ali Baba Cloud -- just env variables are enough for both, we dont need provisioning/cluster stuff

[nooga]

Thanks — addressed six of the seven; the vendor-tier one I'd like you to confirm first. Pushed on top of your main merge (5dcc159), so that's preserved.

Modal. Yes, exactly that. Poor wording on my part — "not a cluster workload" only meant no Modal container runs inside the cluster. Modal is fully configured: the Kit holds the tokens and deploys the Modal app at bootstrap, and at scan time the cluster reaches out to Modal, which spins the sandboxes on its own infra. Reworded in the ADR.

Ossprey. Done — the Kit collects OSSPREY_API_KEY as an optional pass-through secret, so a keyed operator gets coverage. Kept it out of the required baseline so a deploy can't fail for a key nobody can provision yet; easy to promote once slice 35 lands.

Ephemeral environments. Promoted into the Decision as a co-equal motivation, using your phrasing — each ephemeral instance is a separate Kit deploy with isolated credentials, configured by the Monk agent from the single in-repo template.

Monk-generated CI/CD. Good catch to ask. It's an existing Monk capability, not aspirational — but Tripwire doesn't use it, so I've said both: the feature exists, our adoption of it is follow-up work.

Helm / Kustomize / Terraform. Added as Alternative C: secrets first-class (including provisioning-generated ones like the Supabase service-role key), Monk provisions the managed service rather than templating a reference to one, versioned Kit + registry, ephemeral envs from one template. Noted that Terraform can provision — the issue is you then need three tools where the Kit is one.

DECISIONS column. Fixed to the branch name.

---

Now the one I need you on — MVL + SIE + Model Studio.

Happy to add both; the PoC Kit already plumbs Snyk/Tessl/Cisco through the same three places (MANIFEST, permitted-secrets, variables), so SIE and Model Studio are mechanical.

But this reverses item #2 from your original review, which said scanner creds are required and a missing scanner key isn't an acceptable Live outcome. Proposed structure:

• Tier 1 — required for any deploy: Supabase + Modal (this is MVL; a valid but partial Live instance)
• Tier 2 — required for full scanner coverage: Snyk, Cisco, Tessl
• Tier 3 — env-var only, no provisioning: SIE (Superlinked), Alibaba Model Studio, Ossprey

Kit v1 "done" then gets defined at two levels — MVL-complete and full-coverage-complete — instead of one.

Confirm that supersedes item #2 and I'll rewrite the Decision section to match.

[neomatrix369]

@nooga — confirmed. The 3-tier model supersedes item #2 from the earlier comment:

• Tier 1 (MVL — required for any deploy): Supabase + Modal
• Tier 2 (required for full scanner coverage): Snyk, Cisco, Tessl
• Tier 3 (env-var only, no provisioning): SIE (Superlinked), Alibaba Model Studio, Ossprey

Please rewrite the Decision section of ADR-0001 to reflect this tiering. We can revisit both the tier boundaries and the Monk Kit specifics once the actual Monk config lands in the repo — this ADR is the intent record, not the implementation contract.