privacy-regimelisted

<!-- privacy-regime-version: 2 --> # Privacy regime (opt-in, per project) **This file is a TEMPLATE. Fill in your regime before relying on it.** Shipped blank on purpose: forge-kit names no jurisdiction anywhere in its defaults (issue #101), because for most projects any single named regime is the wrong one, and a gate citing the wrong statute is worse than a gate citing none. It looks authoritative and is not. ## What the default already does without this skill `docs/guides/ticket-standards.md` rule 4 requires **seven regime-agnostic facts** about any ticket touching personal data, and `ticket-gate` blocks on their absence: 1. Every personal-data field the ticket touches 2. Storage location and encryption at rest 3. Erasure, including cascading deletion of dependent records 4. Portability 5. Minimisation and retention 6. The legal basis 7. Any cross-border transfer Those seven exist under GDPR, UK GDPR, CCPA and CPRA, LGPD, PIPEDA and APPI, under different names, different thresholds and different article numbers. **A project with no specific regime needs nothing beyond them.** Install this skill only when you have a regime and want its depth. ## How it reaches the gate Label a ticket `privacy` and `ticket-gate` adds the section below to the critic's brief. It is a brief modulation, not a new agent, following the same pattern as the `api` row in the gate's lens table: a privacy regime is not an independent domain perspective, it is the same rule 4 judgment with your