local-first-tenancy-boundary

name	local-first-tenancy-boundary
description	Audits a product's local-first account/tenancy model: whether every identity-gated feature keeps a real local-only path, whether every scope-tier crossing (private -> repo -> team -> public) shows an explicit data-boundary consent screen, whether the "local-only mode uploads nothing" claim is runtime-testable rather than asserted, whether export/delete controls exist per tier, and whether the scope ladder is declared as one ordered source of truth. Use when designing or reviewing account creation, passkey sign-in, device pairing, team harbor roles, or the data-boundary screen for a local-first product. NOT for the crypto/PKI/relay mechanism underneath the zero-trust boundary itself (use pd-relay-zero-trust), agent (not human-operator) identity continuity and reputation across respawns (use agent-identity-continuity- reputation), or general cryptographic security patterns for agent networking — signed envelopes, ocaps, mTLS, sandboxing (use agentic-zero-trust-security).
license	Apache-2.0
allowed-tools	Read,Write,Edit,Bash,Grep,Glob
metadata	{"category":"Agent & Orchestration","tags":["tenancy","local-first","data-boundary","consent","account-model"],"provenance":{"kind":"first-party","owners":["port-daddy"]},"pairs-with":[{"skill":"pd-relay-zero-trust","reason":"Once a tier crossing needs to leave the device for real, this is the crypto/relay mechanism that carries it — this skill only decides that a crossing needs consent, not how the wire protocol works."},{"skill":"agent-identity-continuity-reputation","reason":"Covers durable identity/reputation for the agents themselves; this skill covers the human operator's account/tenancy model those agents act inside of."},{"skill":"agentic-zero-trust-security","reason":"Supplies the general cryptographic security patterns (signed envelopes, capability tokens, sandboxing) a data-boundary consent screen's backing mechanism may draw on."}],"io-contract":{"kind":"deliverable","consumes":["[Truncated]","[Truncated]"],"produces":["[Truncated]","[Truncated]"]}}

Local-First Tenancy Boundary

Decide whether a local-first product's account/tenancy model actually keeps its local-first promise, or just says it does.

Use This For

• Verifying every identity-gated feature (passkey sign-in, device pairing, team invites) ships a real local-only equivalent, not a policy statement.
• Verifying every place data crosses a scope tier — private to repo, repo to team, team to public — shows an explicit data-boundary consent screen before the crossing, not a buried default.
• Proving the "local-only mode uploads nothing" claim is runtime-testable, not a doc comment.
• Checking export/delete controls exist and are verified for every scope tier a user's data can land in.
• Confirming the private/repo/team/public scope ladder is declared once, in order, before role or consent logic is built on top of it.

Do Not Use This For

• Designing the crypto/PKI/relay mechanism underneath the zero-trust boundary itself (pd-relay-zero-trust).
• Modeling agent (not human-operator) identity continuity and reputation across respawns (agent-identity-continuity-reputation).
• General cryptographic security patterns for agent networking — signed envelopes, ocaps, mTLS, sandboxing (agentic-zero-trust-security).

Tenancy Boundary Decision Model

flowchart TD
  A[Enumerate every feature] --> B{requiresIdentity?}
  B -->|No| C[No identity-gate risk]
  B -->|Yes| D{hasLocalOnlyPath?}
  D -->|No| E[CRITICAL: identity-gated-no-local-path]
  D -->|Yes| F[OK: local escape hatch exists]
  A --> G{scopeTier beyond private?}
  G -->|No| H[Stays on-device, no crossing]
  G -->|Yes| I{crossesTierWithConsentScreen?}
  I -->|No| J[CRITICAL: tier-crossing-no-consent]
  I -->|Yes| K[OK: consent screen shown before crossing]
  L[localOnlyMode.uploadsNothingTestable?] -->|No| M[CRITICAL: local-mode-uploads-not-testable]
  L -->|Yes| N[OK: claim is runtime-verifiable]
  O[exportDelete.perTierSupported?] -->|No| P[CRITICAL: no-export-delete-per-tier]
  O -->|Yes| Q[OK]
  R[scopeLadderOrdered?] -->|No| S[CRITICAL: scope-ladder-unordered]
  R -->|Yes| T[OK]

1. Enumerate every user-facing feature with its requiresIdentity, hasLocalOnlyPath, scopeTier, and crossesTierWithConsentScreen fields — an incomplete inventory is not evidence of safety.
2. For every identity-gated feature, verify a working local-only equivalent — the "local-only no-account path" has to survive contact with the actual feature list, not just live on the onboarding screen.
3. For every feature whose scope tier leaves , verify an explicit data-boundary consent screen fires at the moment of the crossing, not a settings default the user set once and forgot.