META-006: Multi-Tenant Support #204

Closed
opened 2026-04-11 05:54:25 +00:00 by Mark · 3 comments
Owner
No description provided.
Author
Owner

⏸ Needs Decision

What needs to be decided?

  • Should this be split into smaller sub-issues? If yes, remove the blocked:needs-decision label and the triage will create a decomposition issue.
  • Do you want to proceed despite the risk? If yes, remove the blocked:needs-decision label and the triage will approve it.

Blocking factors:

  • Large scope — may need decomposition into phased sub-issues
  • High risk — needs human sign-off before proceeding

Scope: large Risk: high Spec: partial Type: feature
Summary: Introduce tenant isolation boundaries across the mesh substrate, including tenant-scoped ledger state, intent routing, worker execution isolation, and API-level authentication.
Suggestion: Decompose into phased sub-milestones: (1) tenant identity model + ledger scoping (new data model, schema migration), (2) tenant-aware routing + worker isolation (scoped intents, isolated exec contexts), (3) tenant API auth gateway, (4) isolation guarantee test suite. Each phase needs a security gate before proceeding to the next.
Rationale: SCOPE=large: touches 15+ files across ledger, routing, spawning, API gateway, backplane, config, and tests — a new cross-cutting identity layer. RISK=high: security-critical isolation boundaries, high blast radius if wrong, touches every core routing and execution path. SPEC=partial: the system's distributed mesh architecture naturally accommodates multi-tenancy, but it's absent from all existing docs, milestones, and current active work (M009). TYPE=feature: new major subsystem, not a fix or enhancement to existing functionality.

To unblock: Remove the blocked:needs-decision label. The triage will apply the appropriate outcome based on your choice above.

## ⏸ Needs Decision **What needs to be decided?** - **Should this be split into smaller sub-issues?** If yes, remove the `blocked:needs-decision` label and the triage will create a decomposition issue. - **Do you want to proceed despite the risk?** If yes, remove the `blocked:needs-decision` label and the triage will approve it. **Blocking factors:** - **Large scope** — may need decomposition into phased sub-issues - **High risk** — needs human sign-off before proceeding --- **Scope:** large **Risk:** high **Spec:** partial **Type:** feature **Summary:** Introduce tenant isolation boundaries across the mesh substrate, including tenant-scoped ledger state, intent routing, worker execution isolation, and API-level authentication. **Suggestion:** Decompose into phased sub-milestones: (1) tenant identity model + ledger scoping (new data model, schema migration), (2) tenant-aware routing + worker isolation (scoped intents, isolated exec contexts), (3) tenant API auth gateway, (4) isolation guarantee test suite. Each phase needs a security gate before proceeding to the next. **Rationale:** SCOPE=large: touches 15+ files across ledger, routing, spawning, API gateway, backplane, config, and tests — a new cross-cutting identity layer. RISK=high: security-critical isolation boundaries, high blast radius if wrong, touches every core routing and execution path. SPEC=partial: the system's distributed mesh architecture naturally accommodates multi-tenancy, but it's absent from all existing docs, milestones, and current active work (M009). TYPE=feature: new major subsystem, not a fix or enhancement to existing functionality. **To unblock:** Remove the `blocked:needs-decision` label. The triage will apply the appropriate outcome based on your choice above.
Author
Owner

Mark — this issue needs scope before any work can be routed. The body is empty and the ledger-side core already landed on origin/master (f15a440 feat(#204)), but the remaining scope (tests + runtime/docker/cli tenant wiring) has no requirements to plan against.

Please confirm:

  1. Tenant isolation model: schema-per-tenant, db-per-tenant, or row-level?
  2. Auth/tenant-routing: subdomain, header, or JWT claim?
  3. Which surfaces must be multi-tenant first: API, UI, or data plane?

Once the body or this thread has those answers, the fixit lane can decompose and dispatch the remaining work.

Mark — this issue needs scope before any work can be routed. The body is empty and the ledger-side core already landed on origin/master (f15a440 feat(#204)), but the remaining scope (tests + runtime/docker/cli tenant wiring) has no requirements to plan against. Please confirm: 1. **Tenant isolation model**: schema-per-tenant, db-per-tenant, or row-level? 2. **Auth/tenant-routing**: subdomain, header, or JWT claim? 3. **Which surfaces must be multi-tenant first**: API, UI, or data plane? Once the body or this thread has those answers, the fixit lane can decompose and dispatch the remaining work.
Author
Owner

Closing this as a stale empty body — core multi-tenant work landed in f15a440 feat(#204) on origin/master. The remaining scope (tests + runtime/docker/cli tenant wiring) has been split into a properly-spec'd followup: Mark/mesh-seed#285. The followup carries the three open scope questions (tenant isolation model, auth/tenant-routing, which surfaces first) as the acceptance gate before any code lands. Filing done via kilo-gsd-runner for Mark/mesh-seed#204 on 2026-09-04.

Closing this as a stale empty body — core multi-tenant work landed in `f15a440 feat(#204)` on origin/master. The remaining scope (tests + runtime/docker/cli tenant wiring) has been split into a properly-spec'd followup: **Mark/mesh-seed#285**. The followup carries the three open scope questions (tenant isolation model, auth/tenant-routing, which surfaces first) as the acceptance gate before any code lands. Filing done via kilo-gsd-runner for `Mark/mesh-seed#204` on 2026-09-04.
Mark closed this issue 2026-09-05 07:39:53 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/mesh-seed#204
No description provided.