Repository navigation
id: partition-scoped world routing, names, and admission (from #3397 Phase 2) #3898
Description
World-specific implementation follow-on from the #3397 design (doc/2026-11-01_design_id3397.md, PR #3853), Phase 2 of its phased plan.
Scope: partition-scoped world lookup (jurisdiction, name) with no cross-partition existence oracle; fail-closed admission guards for reads/writes/invites/WebSocket/background/admin operations against the world's stored jurisdiction; participant-list and membership-metadata authorization equal to world reads; shard/coordinator jurisdiction inheritance (creation rejects a different jurisdiction); the explicit guest-grant seam, disabled until Drew settles the guest-membership policy (open question 1 on #3397).
Not this issue: #3400 covers account/user-store routing and object entry guards — this issue is the world-specific routing/admission layer that #3400 does not fully represent (per the #3397 doc, Phase 2 note).
Authority boundary: #3397 is design-only and is not an implementation authorization. Implementation ordering follows the doc: this phase depends on Phase 0 (#3403 provisioning gate evidence via #2285) and Phase 1 (#3399 authoritative jurisdiction records), and on #3400's routing foundation.
Acceptance: negative tests from the #3397 doc's matrix pass for this slice — wrong-jurisdiction read/write/invite uniformly denied with no existence signal; foreign account with no/expired/revoked guest grant denied incl. participant metadata; same-name world in another partition indistinguishable from nonexistent; shard assignment naming a different jurisdiction rejected.
Acceptance criteria
- Wrong-jurisdiction read/write/invite is uniformly denied with no existence signal (same-name world in another partition is indistinguishable from nonexistent).
- A foreign account with no, expired, or revoked guest grant is denied, including participant-list and membership metadata.
- Shard/coordinator creation naming a different jurisdiction than the world's stored jurisdiction is rejected.
- The guest-grant seam ships disabled until the guest-membership policy (open question 1 on code issue id: design: jurisdiction-partitioned hosted worlds and world blobs #3397) is settled.
- Dependencies hold: Phase 0 (id: gate hosted jurisdiction provisioning on verified DO and R2 support #3403 via id: PoC: verify DO jurisdiction mechanics and confirm vendor residency guarantees #2285) and Phase 1 (id: add immutable jurisdiction and migration metadata to hosted directory #3399) evidence has landed, and id: enforce restricted jurisdiction routing and object entry guards #3400's routing foundation is in place.
Activity
dezren39 commentedon Nov 1, 2026
Intake review
Related: design code issue #3397 (PR #3853) Phase 2; depends on #3403/#2285 (Phase 0 provisioning gate evidence), #3399 (Phase 1 jurisdiction records), and #3400 (account routing foundation — adjacent, not a substitute).
Notes: The issue body already carries this slice's acceptance in prose (the #3397 doc's negative-test matrix); the appended section restates it as the canonical checklist. The guest-grant seam ships disabled: the guest-membership policy is open question 1 on code issue #3397, which sits in Drew's lane — nothing in this slice should guess it.
Risks: The no-existence-oracle requirement is subtle: uniform denial must be indistinguishable across read/write/invite/WebSocket/background/admin paths, including participant metadata — one leaky path defeats the partition boundary.
Suggested approach: Build after Phase 0/1 land; implement admission as a single fail-closed guard consumed by every operation path, and write the wrong-jurisdiction tests against each path separately.
— fleet monitor intake enrichment, 2026-11-01 run (protocol §5). Acceptance criteria appended to the body where missing; labels normalized.
developing-today commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 3, 2026
🤖 Agent note · done — triaged: still live, implementation BLOCKED on the Phase 0/1 + routing dependency chain (ordering recorded)
status/needs-triage, queued. This is the root of the chain and has not been worked yet.status/blocked+queue/blocked, priority/high. Gates on issue id: PoC: verify DO jurisdiction mechanics and confirm vendor residency guarantees #2285's evidence.status/blocked+queue/blocked+user/escalated, priority/high. A decision on this one is currently escalated to Drew; nothing downstream can route around it.status/parked+queue/parked, priority/high.status/blockedto mirror the chain; queue/work labels from this triage removed (no live task remains).