Privacy Center (future): federation of privacy records + household subjects

[atomantic]

Part of epic #2138. Parked for a later cycle — promote to plan once the core Privacy Center (Phases 1–8) has shipped. Design record: docs/plans/2026-07-04-privacy-center-pii-vault-broker-optout.md ("Deferred / open questions").

Summary

Two deliberate v1 exclusions, parked with their open questions so they can be picked up cold:

1. Federation of privacy records across peers (void/null/NaN/undefined):

• v1 privacy tables are machine-local. Syncing them needs: (a) a key-distribution decision for PRIVACY_VAULT_KEY — same key on all peers (user copies it, simplest) vs per-peer re-encryption (better isolation, more machinery); (b) sync-wire version gating via server/lib/schemaVersions.js so a newer peer can't corrupt an older one; (c) tombstone semantics for deleted vault records/orgs consistent with the existing record-sharing patterns; (d) a decision on whether broker cases should sync at all (they're per-user, not per-machine — probably yes, with the ledger's single-writer assumption revisited).
• Recommended starting point: same-key sync of privacy_vault_records (ciphertext travels as-is), orgs + holdings as plain records, cases excluded initially.

2. Household subjects (unbroker manages multiple consenting people):

• Schema already leaves room (privacy_consents.subject, currently only 'self'). Adding family members means: per-subject vault records + consent records (method: how consent was captured, per unbroker's no-consent-no-action rule), subject scoping on orgs/holdings/cases, and subject filters across the Privacy UI.
• Hard rule carried over from unbroker: no scanning/opt-out for a subject without a recorded consent; the engine refuses, not just the UI.

Acceptance criteria (to be refined at promotion time)

• A second PortOS peer shows the same vault (masked) and org registry after sync, with no plaintext on the wire beyond what the transport already protects.
• A household member can be added with recorded consent and worked through the broker engine independently of self.

[atomantic]

Precondition cleared: Privacy Center Phases 1–8 (#2140–#2147) are all shipped/closed, so this is no longer blocked on the core feature. Promoting future → plan.

Not auto-implementing yet: this carries a genuine security-design fork that needs a human decision before code — key distribution for PRIVACY_VAULT_KEY (same key copied to all peers, simplest, vs. per-peer re-encryption, better isolation). Also open: tombstone semantics for deleted vault records, and whether broker cases sync at all. Recommend settling those in a short design pass, then implementing the recommended starting point (same-key sync of privacy_vault_records ciphertext + orgs/holdings as plain records, cases excluded initially).

[atomantic]

Autonomous claim skipped — needs a human security-design decision before code.

Per the /do:next --issues verify step, this issue is not autonomously actionable: your own comment on it explicitly defers implementation pending a human choice on the PRIVACY_VAULT_KEY key-distribution fork, and the scope spans federation across multiple privacy subsystems (>5 files). Tagging needs-input so autonomous swarm runs stop re-picking it and converge.

To unblock autonomous implementation, please settle these in the issue (or the design doc docs/plans/2026-07-04-privacy-center-pii-vault-broker-optout.md):

1. PRIVACY_VAULT_KEY distribution — same key copied to all peers (simplest; user copies it) vs. per-peer re-encryption (better isolation, more machinery). This is the blocking security fork.
2. Broker cases sync — do cases sync across peers at all, or stay machine-local for v1? (They're per-user, not per-machine — the single-writer ledger assumption needs revisiting if yes.)
3. Tombstone semantics — confirm deleted vault-record/org tombstones follow the existing record-sharing pattern.
4. Household subjects — confirm the no-consent-no-action rule is enforced in the engine (not just UI) for non-self subjects.

Once (1) and (2) are decided, remove needs-input and the recommended starting point (same-key sync of privacy_vault_records ciphertext + orgs/holdings as plain records, cases excluded) can be implemented autonomously.

[atomantic]

Relabeling needs-input → blocked. The open questions now have recommended defaults in the body (same-key sync of privacy_vault_records; orgs/holdings as plain records; cases excluded initially; household members gated on recorded consent), so this isn't decision-blocked — it's sequencing-blocked: it can't be built until the core Privacy Center (epic #2138, Phases 1–8) ships. Unblock action: promote to plan once the core has landed. Design record: docs/plans/2026-07-04-privacy-center-pii-vault-broker-optout.md.