Skip to content

id: gate hosted jurisdiction provisioning on verified DO and R2 support #3403

Open

Description

@dezren39

Follow-up to #2283. Implement fail-closed hosted signup/deployment configuration validation for configured jurisdiction and its restricted Durable Object namespace and R2 bucket. Consume deployed-account evidence from #2285; do not duplicate that PoC or imply a probe proves vendor residency guarantees.

Acceptance: production cannot enable signup or migration with missing/unverified jurisdiction, unsupported runtime/types, or missing mismatched bucket; explicit diagnostics and configuration tests cover unavailable US and no unrestricted fallback. Coordinate with the design doc on the #2283 branch.

Activity

  1. developing-today commented on Nov 1, 2026

    @developing-today
    Contributor
  2. added
    kind/infrastructureInfrastructure / host-portability work
    priority/highImportant and time-sensitive
    effort/mMedium: expected under 1 day of work
    source/humanFiled directly by a human
    app/idPackage/app: id (pkgs/ or apps/ in this repo)
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Nov 1, 2026
  3. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    Intake review

    Related: #2283 (parent, design doc on its branch), #2285 (deployed-account evidence — consumed, not duplicated), siblings #3399–#3402, #3404.

    Notes: Inline Acceptance present (production cannot enable signup/migration with missing/unverified jurisdiction, unsupported runtime/types, or missing/mismatched bucket; diagnostics + config tests incl. unavailable-US and no unrestricted fallback). This is the gate that makes the rest of the set safe to ship — priority/high for sequencing.

    Risks: Do not let the validation imply vendor residency guarantees beyond what #2285's PoC actually proves — the filing is explicit about that boundary.

    Suggested approach: Config validation with explicit diagnostics per failure class; tests enumerated from the acceptance list one-to-one.

    — fleet monitor intake (2026-11-01)

  4. added
    queue/queuedHas a queued task in the Supabase agent queue
    work/assignedQueue worker lifecycle state
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 1, 2026
  5. 101 remaining items

  6. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    Handed off — task 5798 claimed by lane L (queue repo-health-code-pilot) and assigned to the opencode execution lane; the opencode claimant's bound session drives issue #3403 from here.

  7. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · blocked / escalated

  8. added
    queue/blockedQueue or user escalation state
    status/blockedQueue or user escalation state
    queue/queuedHas a queued task in the Supabase agent queue
    and removed
    status/parkedDeliberately paused with a recorded resume condition
    queue/claimedQueue worker lifecycle state
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    on Nov 3, 2026
  9. developing-today commented on Nov 3, 2026

    @developing-today
    Contributor

    agent-note:v1
    state: reviewed (coverage loop-back)
    Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 5798 (small_fix, blocked, priority 20) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
    Found via: coverage loop-back 2026-11-03

  10. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    Gate update from queue task 6817: fresh triage of #2285 found it still OPEN, with no Drew authorization, PoC findings, or Cloudflare vendor response. Its gate has moved from needs-triage to an explicit user/escalated authorization blocker; task 6817 is blocked escalated-to-user. No scratch resources were deployed and no vendor message was sent. Task 5798 remains blocked until Drew decides on the no-user-data scratch Worker/R2 deployment and the required evidence is recorded on #2285.

    Resume condition: #2285 publishes verified DO/R2 PoC results and the written vendor ask/answer or an explicit disposition; then revalidate this issue and its packet before implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

app/idPackage/app: id (pkgs/ or apps/ in this repo)effort/mMedium: expected under 1 day of workkind/infrastructureInfrastructure / host-portability workmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/highImportant and time-sensitivequeue/blockedQueue or user escalation statequeue/queuedHas a queued task in the Supabase agent queuesource/humanFiled directly by a humanstatus/blockedQueue or user escalation statetask/triageQueue packet kind: verify, reproduce, and route this itemwork/assignedQueue worker lifecycle state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions