Repository navigation
id: add immutable jurisdiction and migration metadata to hosted directory #3399
Description
Follow-up to #2283. Implement jurisdiction-aware account directory/signup: atomic default policy creation before object derivation, unique subject mapping, validated jurisdiction, routing epoch and migration state, restricted mutation via guarded state transitions, and legacy inventory without silently relabelling existing stores.
Acceptance: duplicate signup preserves record; absent/invalid jurisdiction fails closed; profile updates cannot change jurisdiction; atomic transitions and concurrent signup have tests. Deployment depends on provisioning evidence #2285 and the #2283 design.
Metadata
Metadata
Assignees
Labels
Package/app: id (pkgs/ or apps/ in this repo)Medium: expected under 1 day of workInfrastructure / host-portability workIntake review done: acceptance criteria, links, and normalized labels addedImportant and time-sensitiveQueue or user escalation stateHas a queued task in the Supabase agent queueFiled directly by a humanQueue or user escalation stateQueue or user escalation stateQueue worker lifecycle state
Activity
developing-today commentedon Nov 1, 2026
CODE-1301
dezren39 commentedon Nov 1, 2026
Intake review
Related: #2283 (parent design), #2285 (provisioning evidence — deployment dependency), siblings #3400–#3404 (the jurisdiction set).
Notes: Body already carries an inline Acceptance section (duplicate signup, fail-closed jurisdiction, immutable jurisdiction on profile update, atomic-transition tests). This is the foundation item of the set — #3400's routing guards depend on the directory semantics defined here. Priority/high for sequencing, not urgency.
Risks: Legacy inventory must not silently relabel existing stores — call that out in the implementation PR description.
Suggested approach: Land directory/signup + guarded transitions first; keep migration-state fields minimal until #3404's control plane consumes them.
— fleet monitor intake (2026-11-01)
186 remaining items
dezren39 commentedon Nov 3, 2026
agent-note:v1
event: picked-up
task: 5800 (repo-health-code-pilot; worker repo-worker-code; OpenChamber scheduled lane bf419306-c4ef-470f-a553-beabf93239de)
state: claimed; revalidating dependencies fresh before any worktree or implementation.
verified: #3399 OPEN with no hard-stop labels; design PRs #3406/#3843 MERGED; no open implementation PR. Dependency #2285 remains OPEN and has no deployed-account DO/R2 evidence beyond the intake comments. Dependency #3403 remains OPEN with queue/parked + status/parked + work/assigned; its phase-0 gate is incomplete. No task-5800 branch/worktree exists locally.
next: Park; resume only after #2285 evidence is available and #3403 phase-0 gate is complete; revalidate all state fresh.
dezren39 commentedon Nov 3, 2026
agent-note:v1
event: parked
task: 5800 (repo-health-code-pilot; worker repo-worker-code; OpenChamber scheduled lane bf419306-c4ef-470f-a553-beabf93239de)
state: parked for 30 minutes; dependency gates remain unmet.
blocker: Fresh checks at 2026-11-03T10:12Z: issue #2285 is OPEN and has no deployed-account DO/R2 evidence beyond intake comments; issue #3403 is OPEN with queue/parked and its phase-0 gate incomplete. Design PRs #3406/#3843 are MERGED, but there is no implementation PR for #3399. No task-5800 branch/worktree or source changes.
resume: Revalidate #3399, #2285, and #3403 after 30 minutes. Implement only when #2285 evidence is available and #3403 phase-0 coordination is complete.
labels: queue/parked + status/parked; work/assigned retained. Sandbox bookkeeping deferred to fleet reconciliation.
dezren39 commentedon Nov 3, 2026
Queue task 5800 blocked
escalated-to-user— no code changed, no worktree, no branch.Why not parked again. Fresh checks 2026-11-03T10:47Z: #3399 OPEN; dependency #2285 still OPEN and byte-for-byte unchanged since 2026-10-29T12:28Z (tracker link + intake review only); phase-0 gate #3403 still OPEN and
queue/parked. This task has now cycled through time-parks without the gate moving, and the packet bars implementing Phase 1 without #2285 evidence ("do not enable production signup from this packet alone").What actually changes the picture. #2285 assumes the PoC is "not doable from a repo-only worker session" because it needs a Cloudflare account. On this execution host
wrangleris on PATH andCLOUDFLARE_API_TOKEN/CLOUDFLARE_ACCOUNT_IDare present (names checked, values never read). So Half 1 is authorization-gated, not access-gated — the one thing a worker may not do unilaterally is deploy scratch resources on Drew's account.Decision required (Drew): authorize one non-interactive scratch-Worker PoC (#2285 Half 1, no user data) under the
us/eujurisdiction pair, producing the DO/R2 evidence. Half 2 — the written vendor/residency ask — stays Drew's regardless, since it is correspondence and it is what gates any EU-residency DPA language.Resume condition: #2285 posts deployed-account DO/R2 jurisdiction evidence and #3403 phase 0 completes → revalidate all three issues and main, then implement #3399.
Full read posted on the gate issue: #2285 (comment)