@soleur/opencode 0.0.0-stage → 3.354.2

package/skills/gdpr-gate/NOTICE

@@ -0,0 +1,136 @@
+---
+upstream: github.com/goSprinto/compliance-skills
+license: MIT
+pinned-commit: 7b58d68461cb1fc033a063e34cc9de63d0b4144b
+last-verified: 2026-10-05
+registry: knowledge-base/engineering/policies/content-vendoring.md
+lifted-files:
+  # Each entry pins TWO blob SHAs:
+  #   upstream-blob-sha — the file as it exists upstream at `pinned-commit`.
+  #     Used by the drift workflow to detect upstream content changes.
+  #   local-blob-sha    — the file as it exists in this repo (after the
+  #     attribution-header line and any documented Soleur extensions). Used
+  #     by the lefthook `vendor-pin-integrity` gate to detect silent local
+  #     edits. Computed via `git hash-object --no-filters`.
+  - path: references/fields.md
+    upstream-path: pii-detector/patterns/fields.md
+    upstream-blob-sha: c1bb748fe00a53b283efe66ec937fa39437d2efc
+    local-blob-sha: 68675dd747fcbc74bb84c99eaa14983c9c5a6b24
+    status: active-eu-extended
+  - path: references/leakage-vectors.md
+    upstream-path: pii-detector/rules/leakage-vectors.md
+    upstream-blob-sha: 15a46e529e789930149f4b9bce875bfe5c53e478
+    local-blob-sha: 8d1d7fc44183e866e128707c3e91e7b63ce835fd
+    status: active-verbatim
+  - path: references/layers/api-layer.md
+    upstream-path: pii-detector/layers/api-layer.md
+    upstream-blob-sha: 9d3202175c1d0225f60a912c489dbdacf4df491c
+    local-blob-sha: 802fc866e320bebeecae2f8e53658253853ab5f9
+    status: active-verbatim
+  - path: references/layers/data-in-transit.md
+    upstream-path: pii-detector/layers/data-in-transit.md
+    upstream-blob-sha: 6c9eeabf17d1f0ed5660f5eb54d91587c81214ef
+    local-blob-sha: 2ce203e9c041c1b1992ff9f7f636fdd63a667a44
+    status: active-eu-extended
+  - path: references/layers/data-lifecycle.md
+    upstream-path: pii-detector/layers/data-lifecycle.md
+    upstream-blob-sha: a073ef24a0527c2c3a6d738b65ea3ef9d6194abe
+    local-blob-sha: 29357a020bfa0e61f91dd529070fe3eb7cd251da
+    status: active-soleur-rewritten
+  - path: references/layers/auth-sessions.md
+    upstream-path: pii-detector/layers/auth-sessions.md
+    upstream-blob-sha: 71dd9d01fe55d3e58f8b35f1cf745d47ba5f0985
+    local-blob-sha: a2eac5e15c72b28a7f271f5ab98f376f4448f005
+    status: active-eu-extended
+  - path: references/layers/frontend.md
+    upstream-path: pii-detector/layers/frontend.md
+    upstream-blob-sha: 5f39e08fe2404759d7cbdbdea54a4f6210b91b8f
+    local-blob-sha: 7ab925695fb02151b0214ef171d92f10059b1d50
+    status: active-eu-extended
+  - path: references/layers/testing-seeding.md
+    upstream-path: pii-detector/layers/testing-seeding.md
+    upstream-blob-sha: a2f299418a5f85246fd2203475d89106936f7a72
+    local-blob-sha: 3dc230db21b657a9da31886d52abf982d7203f4b
+    status: active-eu-extended
+soleur-authored:
+  # Reference files written from scratch for this plugin. Same record shape and
+  # same `local-blob-sha` tamper check as `lifted-files` above, but NO upstream
+  # provenance — these never appear in `upstream-files`, and a `lifted-files`
+  # row for one of them would attest goSprinto MIT provenance for Soleur's own
+  # writing. Pinning them here is what makes them editable through the normal
+  # update-the-pin flow: before #7710 they were rejected outright as "silent
+  # local addition", which blocked the documented v2->v3 lifecycle of
+  # `legal-consent.md` without `--no-verify`.
+  - path: references/non-negotiables.md
+    local-blob-sha: 09723b4b71b1ab95afba4b5d4aa1f882141b9cac
+    status: soleur-authored
+  - path: references/legal-consent.md
+    local-blob-sha: 8bb3d0888ff450867b34ed8b576ec382679588bf
+    status: soleur-authored
+  - path: references/legacy/legal-consent-v1-prose.md
+    local-blob-sha: 239bc26f02098f2bb59eb1e961f92ef128094c7b
+    status: soleur-authored-archived
+---
+
+# NOTICE
+
+The frontmatter above is the canonical machine-readable form; the table below is the human-readable form. Drift between them is a bug.
+
+`gdpr-gate` lifts eight reference files from [gosprinto/compliance-skills](https://github.com/goSprinto/compliance-skills) under the MIT license. The lifted files carry a per-file attribution header and are listed below with upstream blob SHAs pinned at commit `7b58d68461cb1fc033a063e34cc9de63d0b4144b` (verified 2026-05-10 for v1; re-verified 2026-05-10 for v2 — upstream `main` SHA unchanged since v1 lift).
+
+The Soleur prose, GDPR-first framing, EU extensions (Art. 9 fields, Chapter V cross-border check, Art. 20 portability rewrite of DL-04, Art. 32(1)(b) confidentiality footer on auth-sessions, ePrivacy/TTDSG strict-opt-in footer on frontend, Art. 32 pseudonymization footer on testing-seeding), and the `non-negotiables.md` + `legal-consent.md` reference files are written from scratch for this plugin.
+
+## gosprinto/compliance-skills (MIT)
+
+Pinned commit: `7b58d68461cb1fc033a063e34cc9de63d0b4144b` (2026-05-08)
+
+Upstream: <https://github.com/goSprinto/compliance-skills>
+
+| Lifted file (Soleur) | Upstream path | Blob SHA | Status |
+|---|---|---|---|
+| `references/fields.md` | `pii-detector/patterns/fields.md` | `c1bb748fe00a53b283efe66ec937fa39437d2efc` | active (EU-extended with Art. 9) |
+| `references/leakage-vectors.md` | `pii-detector/rules/leakage-vectors.md` | `15a46e529e789930149f4b9bce875bfe5c53e478` | active (verbatim) |
+| `references/layers/api-layer.md` | `pii-detector/layers/api-layer.md` | `9d3202175c1d0225f60a912c489dbdacf4df491c` | active (verbatim) |
+| `references/layers/data-in-transit.md` | `pii-detector/layers/data-in-transit.md` | `6c9eeabf17d1f0ed5660f5eb54d91587c81214ef` | active (EU-extended with Chapter V) |
+| `references/layers/data-lifecycle.md` | `pii-detector/layers/data-lifecycle.md` | `a073ef24a0527c2c3a6d738b65ea3ef9d6194abe` | active (DL-04 rewritten for Art. 20 + CCPA) |
+| `references/layers/auth-sessions.md` | `pii-detector/layers/auth-sessions.md` | `71dd9d01fe55d3e58f8b35f1cf745d47ba5f0985` | active (EU-extended with Art. 32(1)(b) confidentiality footer) |
+| `references/layers/frontend.md` | `pii-detector/layers/frontend.md` | `5f39e08fe2404759d7cbdbdea54a4f6210b91b8f` | active (EU-extended with ePrivacy/TTDSG strict-opt-in footer) |
+| `references/layers/testing-seeding.md` | `pii-detector/layers/testing-seeding.md` | `a2f299418a5f85246fd2203475d89106936f7a72` | active (EU-extended with Art. 32 pseudonymization footer) |
+
+## Soleur-authored layers
+
+The following reference files are written from scratch for this plugin and carry no upstream attribution header. `legal-consent.md` carries an explicit `<!-- Soleur-authored — see NOTICE -->` marker on line 1 and the archived v1 prose carries its own provenance note; `non-negotiables.md` opens directly on its title. Their integrity is pinned by the `soleur-authored` frontmatter block above rather than by the header line.
+
+| File | Purpose |
+|---|---|
+| `references/non-negotiables.md` | GDPR-first regulatory framing for the plugin's scope. |
+| `references/legal-consent.md` | Layer-shaped (LC-01..LC-05) ePrivacy + GDPR Art. 7 / 13 / 14 / 35 checks. **v2 promotion:** v1 prose-shaped version is preserved at `references/legacy/legal-consent-v1-prose.md` for one release cycle and removed at v3. |
+| `references/legacy/legal-consent-v1-prose.md` | Archived v1 prose-shape of the above, retained for regulatory-citation provenance until v3. |
+
+## License
+
+Upstream MIT license terms (verbatim copy):
+
+```
+MIT License
+
+Copyright (c) 2025 goSprinto
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```

package/skills/gdpr-gate/SKILL.md

@@ -0,0 +1,341 @@
+---
+name: gdpr-gate
+description: "This skill should be used when auditing diffs or plans for GDPR/CCPA/HIPAA compliance gaps."
+---
+
+<!-- soleur-cloud-mode:start -->
+**Cloud Mode (Devin):** before pipeline work run `bash "${CLAUDE_PLUGIN_ROOT}/scripts/cloud-detect.sh"`. If `CLAUDE_PLUGIN_ROOT` is unset (cloud exec shells do not export it), resolve the root by IDENTITY, never by script basename: for `d` in `"$HOME/.local/share/devin/cli/plugins/cache"` and `/opt/.devin/plugins`, skip unless `[ -d "$d" ]`, then `MANIFEST="$(find "$d" -path '*/.claude-plugin/plugin.json' -exec grep -l '"name"[[:space:]]*:[[:space:]]*"soleur"' {} + 2>/dev/null | head -1)"`, `ROOT="${MANIFEST%/.claude-plugin/plugin.json}"` — one resolution, two consumers: `$ROOT/scripts/cloud-detect.sh` and `$ROOT/scripts/precommit-guard.sh`. (Shape check, not authentication: a planted `{"name":"soleur"}` dir passes — ADR-179 A11.) `local` or `not-local:no-devin-env` proceeds normally; any other `not-local:<reason>` applies `<plugin-root>/devin/INSTRUCTIONS.md` §Cloud Mode: emit the `--banner`, fan out sequentially with `Reviewed-Coverage: sequential-fallback` disclosure (never claim an independent review ran), `message_user` ack before any secrets read or production mutation, and run `precommit-guard.sh` before any `git commit` — hooks do not fire in cloud.
+<!-- soleur-cloud-mode:end -->
+
+<!-- grok-harness-invoke:start -->
+**Grok Build (`plugins/soleur/lib/harness.ts` `invokeSkill()`):** Read this SKILL.md in this process and run it to completion. A one-segment `soleur:<name>` in this document names a SKILL — on Grok Build, Read `plugins/soleur/skills/<name>/SKILL.md` in this process; it is not a nested tool_use. A multi-segment id such as `soleur:<domain>:<name>` names an AGENT: spawn it, never Read it, and on Grok Build spawn_subagent takes the id with its colons replaced by hyphens (`agentIdToGrokSubagentType`). **Claude Code:** Skill tool for a skill (`soleur:<name>`), Task tool with `subagent_type` for an agent. Forbidden is executing a subset, not the Read.
+<!-- grok-harness-invoke:end -->
+
+# GDPR / CCPA / HIPAA pre-generation gate
+
+`gdpr-gate` is an **advisory** code-level gate that fires inline during `soleur:plan` Phase 2.7 and at `soleur:work` Phase 2 exit. It scans plan prose, schema migrations, and diffs for regulated-data gaps under GDPR (Articles 5/6/9/17/20/25/30/32/33/35), with secondary coverage for CCPA / CPRA and HIPAA. It never blocks. Critical findings (Article 9 special-category data) prompt operator acknowledgment + GitHub issue creation; the gate never auto-writes to `compliance-posture.md`.
+
+This is **not legal review**. Output is a heuristic, machine-generated checklist meant to compress regulator-shaped surprises out of the normal feature-design loop. Consult the `soleur:legal:clo` agent and `soleur:legal:legal-compliance-auditor` before merging anything load-bearing.
+
+## When to invoke
+
+- **Plan time** — automatic at `soleur:plan` Phase 2.7 when the plan touches regulated-data surfaces (per `hr-gdpr-gate-on-regulated-data-surfaces` canonical regex).
+- **Work time** — automatic at end of `soleur:work` Phase 2, single pass after all per-task RED/GREEN/REFACTOR loops complete (token budget ≤4k per invocation).
+- **Manual** — `soleur:gdpr-gate "<scope>"` where `<scope>` is a file path, glob, or one-line description.
+- **Manual repo-scan** — `soleur:gdpr-gate --repo-scan` runs the gate against the whole working tree (operator-initiated only). Defenses, batching, and output contract documented in `## --repo-scan mode` below.
+- **Hook (advisory only)** — `lefthook.yml` `gdpr-gate-advisory` prints a stderr breadcrumb when staged paths match the canonical regex. The hook always exits 0 — it never blocks the commit. Blocking enforcement lives in `soleur:ship` Phase 5.5 (post-PR).
+
+The gate is **read-only with respect to the canonical `soleur:plan` template**. It audits the plan; it never injects its own checklist into the plan body. Architectural invariant per ADR-026.
+
+## Disclaimer (always first)
+
+Every gate output begins, as the first non-blank line, with the literal:
+
+```
+**This is not legal review. Findings are heuristic. Consult `soleur:legal:clo` + `soleur:legal:legal-compliance-auditor` before merging.**
+```
+
+The disclaimer is hardcoded. A test in `plugins/soleur/test/gdpr-gate.test.ts` asserts the literal appears as the first non-blank line of every fixture output.
+
+## --repo-scan mode
+
+`soleur:gdpr-gate --repo-scan` runs the gate against the whole working tree. Operator-initiated only — never auto-fires from `soleur:plan`, `soleur:work`, or lefthook. Token budget remains ≤4k per Haiku call (ADR-026 TR3) via 25-files-per-batch fan-out.
+
+**Sole-arg sentinel.** When invoked with `$ARGUMENTS`, trim leading/trailing whitespace (including `\t` and `\n`). If the trimmed value equals **exactly** `--repo-scan` (no spaces, no quotes, no additional tokens), enter repo-scan mode. Any other value — including `--repo-scan apps/web-platform`, `repo scan`, or `"--repo-scan section of the repo"` — falls through to the v1 scope-string mode and is forwarded verbatim to the prompt.
+
+**File source.** `git ls-files -c -o --exclude-standard` (cached + untracked, respecting `.gitignore`). Submodules excluded; symlinks not followed. Pre-filtered through the canonical regex (see `## Path globs (canonical)` below) so only regulated-data paths enter the candidate pool.
+
+**Deny-list (D1).** Single source of truth: [scripts/path-denylist.txt](./scripts/path-denylist.txt). Line-oriented file with extended-regex patterns (one per line; `#` for comments). Bash `[[ =~ ]]` semantics. Any candidate path matching at least one deny-list pattern is excluded from the scan corpus and a `# blocked: <path>` line is emitted to stderr (audit trail).
+
+**Allow-list bypass (D3).** `GDPR_GATE_REPO_SCAN_ALLOW_PATHS=path1:path2:...` — colon-separated literal paths (no globs accepted; bash strict equality after split). Default unset → all deny-list patterns enforced. Each entry must satisfy two clauses or the script exits 1: (1) the path must match at least one deny pattern (otherwise the bypass is meaningless), and (2) the path must exist in `git ls-files -c -o --exclude-standard` (otherwise the operator probably typo'd the path; see Sharp edges).
+
+**CI refusal (D3).** If both `$CI` and `$GDPR_GATE_REPO_SCAN_ALLOW_PATHS` are set, the script exits 1 with `allow-list bypass refused in CI environment`. Operator-only by construction — runbooks that set the bypass var get caught at the script boundary, not by docs alone.
+
+**Batching.** 25 files per Haiku call. The dispatching agent collects per-batch outputs, dedups by `(check_id, path, line)`, and summarises inline.
+
+**Inline-only output (D4).** Findings emitted to stdout / conversation only. The repo-scan walker NEVER writes to `compliance-posture.md`, `__goldens__/`, `test/fixtures/`, or any disk path under `~/.claude/`. The v1 critical-finding flow (operator-acknowledged write to `compliance-posture.md` Active Items + GitHub `compliance/critical` label) still applies for Art. 9 column-name matches discovered during repo-scan.
+
+**Schema-only invariant (D5).** The repo-scan prompt template inherits v1's `DO NOT INCLUDE COLUMN VALUES` directive verbatim. The directive is the load-bearing assertion in `plugins/soleur/test/gdpr-gate.test.ts`.
+
+**Canonical-regex source-of-truth.** [scripts/repo-scan.sh](./scripts/repo-scan.sh) extracts the canonical regex from this file's `## Path globs (canonical)` heading via `awk` at runtime — it does NOT redefine the regex. Editors of SKILL.md must keep that heading and the first fenced regex line stable; if extraction fails the script exits 1 with `canonical regex not found in SKILL.md`. Asserted by AC-PARITY-1 and `gdpr-gate-repo-scan.test.ts`.
+
+## Path globs (canonical)
+
+The single source of truth for "what counts as a regulated-data path" is the regex below. `lefthook.yml` mirrors it verbatim; `plugins/soleur/skills/review/scripts/fix-round-seats.sh` `GDPR_PATH_RE` mirrors it byte-identically (pinned by `plugins/soleur/test/review-tier-parity.test.ts`); the skill's prompt template references it; `AGENTS.md` `hr-gdpr-gate-on-regulated-data-surfaces` cites it.
+
+```
+^(apps/web-platform/supabase/migrations/|apps/web-platform/lib/auth/|apps/web-platform/server/.*auth.*\.(ts|tsx|js)|apps/web-platform/app/api/.*\.(ts|tsx)$|.*\.sql$)
+```
+
+Each component matches at least one file in the current repo (verified at plan time, 2026-05-10). `forms/**` and `**/*.prisma` from earlier drafts are dropped — both matched zero paths in this repo and a glob that matches nothing is a workflow violation per `hr-when-a-plan-specifies-relative-paths-e-g`.
+
+## 5 mandatory v1 checks (FR4)
+
+Each check has a stable `check_id` for cross-referencing in `compliance-posture.md` and GitHub issue labels.
+
+| `check_id` | Article | Trigger | Default severity |
+|---|---|---|---|
+| `GDPR-Art-6` | Art. 6 lawful basis | New schema column without `-- LAWFUL_BASIS: <basis>` annotation | `Important` |
+| `GDPR-Art-5e` | Art. 5(1)(e) retention | New PII table without retention metadata | `Important` |
+| `GDPR-Art-17` | Art. 17 erasure | New FK to `users` without `ON DELETE CASCADE` or anonymisation migration | `Important` |
+| `GDPR-Art-17-caller` | Art. 17 erasure (caller-site) | Diff adds an `ON DELETE RESTRICT` FK to `public.users` AND an `anonymise_*` RPC, AND `git grep -n '<rpc_name>'` returns zero matches outside `supabase/migrations/`, `knowledge-base/`, and plan files | `Important` (see [[2026-05-16-migration-mandates-must-have-wired-call-sites-in-same-pr]]) |
+| `GDPR-Chapter-V` | Art. 44–49 cross-border | New non-EEA vendor env var / SDK without `compliance-posture.md` Vendor DPA row | `Important` |
+| `GDPR-Art-9` | Art. 9 special-category | New column matching the Art. 9 list in [fields.md](./references/fields.md) | **`Critical`** |
+
+**Critical is reserved for Art. 9 column-name matches in v1.** Demoting the other four to `Important` keeps the noise floor low and preserves `compliance/critical` issue labels as a load-bearing signal. See [non-negotiables.md](./references/non-negotiables.md) for the regulatory rationale.
+
+Reference layers:
+
+**Active layers (with `check_id` markers):**
+
+- [layers/api-layer.md](./references/layers/api-layer.md) — 7 API-layer checks (AP-01..AP-07).
+- [layers/data-in-transit.md](./references/layers/data-in-transit.md) — Transit checks T-01..T-06 + DT-EU-CB Chapter V cross-border.
+- [layers/data-lifecycle.md](./references/layers/data-lifecycle.md) — Lifecycle checks DL-01..DL-06; DL-04 covers Art. 20 portability.
+- [layers/auth-sessions.md](./references/layers/auth-sessions.md) — Auth & session checks A-01..A-07 + Art. 32(1)(b) confidentiality footer.
+- [layers/frontend.md](./references/layers/frontend.md) — Frontend checks F-01..F-06 + ePrivacy/TTDSG strict-opt-in footer.
+- [layers/testing-seeding.md](./references/layers/testing-seeding.md) — Test fixture + seed-data checks TS-01..TS-05 + Art. 32 pseudonymization footer.
+- [legal-consent.md](./references/legal-consent.md) — Layer-shaped LC-01..LC-05 ePrivacy + GDPR Art. 7/13/14/35 (Soleur-authored — promoted from prose at v2; see NOTICE; v1 prose preserved at [legacy/legal-consent-v1-prose.md](./references/legacy/legal-consent-v1-prose.md) until v3).
+
+**Reference catalogues (no `check_id` markers — consulted by other layers):**
+
+- [fields.md](./references/fields.md) — PII field catalogue + Art. 9 special-category extension.
+- [leakage-vectors.md](./references/leakage-vectors.md) — PII vector catalogue (verbatim from upstream).
+- [non-negotiables.md](./references/non-negotiables.md) — GDPR-first regulatory framing.
+
+The 5 mandatory v1 checks (FR4 above) fire on every gate invocation. `--repo-scan` (see `## --repo-scan mode` above) additionally fires every layer-id check across all 7 active layers.
+
+## Output format
+
+Each finding follows this schema:
+
+```markdown
+**This is not legal review. Findings are heuristic. Consult `soleur:legal:clo` + `soleur:legal:legal-compliance-auditor` before merging.**
+
+### `<check_id>` — <one-line title>
+
+**Severity:** <Critical | Important | Suggestion>
+**Article:** <regulation citation>
+**Location:** <file path:line range, or "plan section <header>">
+**Pattern matched:** <verbatim regex/keyword that fired>
+**Why this matters:** <one short paragraph>
+**What to do:** <concrete next action — annotate, add migration, file vendor DPA row, etc.>
+```
+
+Severity levels:
+
+- `Critical` — reserved for Art. 9 (special-category) column-name matches in v1. Triggers the operator-acknowledgment escalation flow.
+- `Important` — Art. 6 / Art. 5(1)(e) / Art. 17 / Chapter V findings. Logs to console; operator may file a `compliance/improvement` issue at their discretion.
+- `Suggestion` — DPIA reminder, Art. 7 consent UX hint, ePrivacy banner alignment, etc. Read-only.
+
+## Critical-finding escalation flow (FR5)
+
+When a `Critical` finding fires, the gate emits this block at the end of the report:
+
+```
+─────────────────────────────────────────────────────────────────
+CRITICAL FINDING — operator acknowledgment required
+─────────────────────────────────────────────────────────────────
+
+A `Critical` finding (`check_id: GDPR-Art-9`) requires an Active Items row in
+`knowledge-base/legal/compliance-posture.md`. The gate does NOT auto-write the
+row.
+
+Run, in order:
+
+  1. gh issue create \
+       --title "<title summarising the finding>" \
+       --label compliance/critical,domain/legal \
+       --body "<finding text + link to PR>"
+
+  2. Edit knowledge-base/legal/compliance-posture.md and append a row to the
+     Active Compliance Items table. The canonical schema is:
+
+       | Item                 | Issue     | Status | Deadline | Notes                              |
+       | <one-line summary>   | #<issue>  | OPEN   | -        | <check_id>; <date>; <context>      |
+
+     `<check_id>` is the gdpr-gate finding identifier (e.g., GDPR-Art-9). Date
+     and remediation context belong in Notes — the table itself uses 5 fixed
+     columns.
+
+  3. git add knowledge-base/legal/compliance-posture.md
+     git commit -m "compliance: register Art. 9 finding for #<issue>"
+
+The gate exits after printing this block. It never modifies disk for you.
+```
+
+This flow is operator-driven by design — the gate is `read-only` against `compliance-posture.md`. Auto-writing would silently aggregate compliance gaps into a single repo file, defeating the human-accountability rationale (CLO assessment).
+
+## Prompt template — what the gate sends to the model
+
+The gate's reasoning step receives the following system prompt structure. The schema-only invariant is **DO NOT INCLUDE COLUMN VALUES** — the gate sends column NAMES only, never row values.
+
+```
+You are gdpr-gate, an advisory compliance auditor.
+
+Your input is:
+1. A diff or plan excerpt (no row values).
+2. The list of regulated-data paths (per the canonical regex above).
+3. The five v1 check definitions below.
+
+DO NOT INCLUDE COLUMN VALUES in the response. Send column NAMES only —
+schema-shape data, never live row payload. The user's PII is the subject of
+the audit; sending values would be a Chapter V transfer of the very data we
+are auditing.
+
+For each check:
+  - Identify pattern matches.
+  - Emit a finding using the Output format above.
+  - Reserve `Critical` for Art. 9 column-name matches.
+```
+
+The `DO NOT INCLUDE COLUMN VALUES` directive is a verbatim string assertion in `plugins/soleur/test/gdpr-gate.test.ts` — moving or paraphrasing it breaks the test by design.
+
+## First-run on existing codebase
+
+Existing migrations 001–040 in this repo do NOT use `-- LAWFUL_BASIS: <basis>` annotations. A backfill audit will fire `Important` (`GDPR-Art-6`) findings on every column that lacks one. **This is intentional** — backfill audits surface existing gaps, and the demotion of Art. 6 to `Important` keeps the noise from training operators to dismiss `Critical`. Operators may suppress backfill noise by scoping the gate to a specific diff (`soleur:gdpr-gate "git diff main...HEAD"`) rather than a full repo scan.
+
+## Future severity changes
+
+Findings carry a stable severity per the FR4 table. If a future version introduces a new severity (e.g., `Blocking`), three consumer patterns must be grepped per `cq-union-widening-grep-three-patterns`:
+
+- `const _exhaustive: never` rails (safe — the build fails until the new variant is handled).
+- `\.severity === "` if-ladders (silent drop).
+- `\?\.severity === "` optional-chained ladders (silent drop).
+
+Add new severities in this file's table FIRST, then run the three greps before writing implementation.
+
+## Boundary with sibling agents
+
+- **`soleur:engineering:review:data-integrity-guardian`** — migration safety + judgment-based PII review. The gate is deterministic pattern-matching; the guardian is judgment-based.
+- **`soleur:engineering:review:security-sentinel`** — OWASP / CWE security-of-processing flaws. Art. 32 overlaps; sentinel handles the "how", gate handles the "what".
+- **`soleur:legal:clo`** — reads `compliance-posture.md`; the gate produces the row contract the CLO consumes. The gate never writes; the operator does.
+- **`legal-audit`** / **`legal-generate`** — document-layer skills (privacy policy, DPA, terms). The gate is code-layer.
+
+Canonical disambiguation prose lives in `plugins/soleur/skills/review/SKILL.md` §boundaries.
+
+## Corpus freshness
+
+The detection rules this gate uses are partly lifted from upstream
+`gosprinto/compliance-skills` and pinned in [NOTICE](./NOTICE). `last-verified`
+records the last time the pinned corpus was compared against upstream.
+
+- **> 30 days** — the gate prints a staleness banner to stdout. Output stays
+  advisory and the gate still exits 0, but a "no findings" result may be based
+  on rules that predate a recently-patched detection pattern.
+- **> 90 days** — the gate additionally prints `POSTURE_FAIL:`. See the next
+  section.
+
+Both thresholds are stable design parameters, not settings: they are not
+relaxable without a published ADR.
+
+`last-verified` is advanced by Soleur's weekly content-vendor-drift cron, and
+only on a run that itself compared the complete upstream-derived registry and
+found it clean against a healthy upstream. The conjuncts are stated canonically
+in the content-vendoring policy (§6a) rather than restated here, because
+restating them is how the two copies came to disagree. Two consequences are
+worth having on this page:
+
+- The scope is the **upstream-derived** records. Files written for this plugin
+  carry their own pins and are checked at commit time, not by the attestation.
+- The cron skips a write while the field is recently advanced, so its value
+  moves in steps of roughly three weeks rather than weekly.
+
+A missing NOTICE, an unparseable date, or a future date all resolve to `999`
+days, which fires both banners; that is the fail-safe direction.
+
+**Do not edit `last-verified` by hand.** An earlier version of this section
+suggested exactly that, which is the one action the governing ADR (ADR-203)
+explicitly rejects: a hand-written value asserts a comparison that no artifact
+records, and on an installed plugin it is overwritten by the next update
+anyway. If the banner is firing on an installed plugin, the corpus is refreshed
+upstream and the fix is to update the plugin.
+
+## POSTURE_FAIL operator chain
+
+**If you are running an installed copy of this plugin** (you are not developing
+Soleur itself), the short version is: the gate is advisory, it exits 0, and it
+is telling you the detection corpus shipped with your copy is old. Nothing in
+your repository is wrong and there is no action to take in it. Update the
+plugin to pick up a refreshed corpus. The numbered chain below is for
+contributors working in the Soleur repository — its steps reference registers
+and internal endpoints that only exist there.
+
+**In the Soleur repository**, when the gate emits a `POSTURE_FAIL:` line:
+
+1. **Do not pause the current PR.** The gate is advisory and exits 0. The
+   staleness signal is a separate work cycle from whatever diff triggered it.
+2. Open a tracking issue labelled `compliance/critical`, titled
+   `[gdpr-gate] >90d stale rules — N days since last-verified`.
+3. Append a row to the compliance posture register's Active Compliance Items,
+   per that document's row schema. The gate never writes there itself: this is
+   an operator-acknowledged write only.
+4. Commit the row with `compliance: register vendor-pin-staleness for #<issue>`.
+5. Drive a re-vendor: ping the in-flight `ci/content-vendor-drift-*` PR if one
+   is open, or dispatch the cron manually via `soleur:trigger-cron` with
+   `cron/content-vendor-drift.manual-trigger`. `gh workflow run` cannot reach
+   it — the job is an Inngest cron, not a GitHub Actions workflow.
+   Print the dispatch as the active harness's operator-typed form per `formatSkillInvocation`
+   (`plugins/soleur/lib/harness.ts`); the operator types it, no agent reads it.
+
+The regulated-data PR that surfaced the banner can ship; the staleness
+follow-up gets its own review and merge.
+
+## Sharp edges
+
+- **Scan-completion line** (#7710): the gate prints
+  `gdpr-gate: path scan complete — N examined, M matched` to stdout on every
+  invocation, unconditionally and after the match loop. It exists because
+  "the scan ran and matched nothing" and "the scan never ran" were previously
+  byte-identical — both produced no output at all — so on a stale corpus the
+  gate printed two banners about its rule set and no evidence that any diff had
+  been examined. It carries **counts only, never path names**: this line
+  reaches a customer's terminal, and path structure is third-party-content
+  adjacent (`hr-third-party-content-grep-on-undertaking`). The stderr
+  breadcrumb still names paths for the local operator. The line deliberately
+  contains neither `days stale` nor `POSTURE_FAIL`, so the evidence that a scan
+  occurred is independent of the corpus's age.
+- **The scan line cannot witness its own most likely failure.** If the
+  `gdpr-gate-advisory` glob in `lefthook.yml` stops matching, lefthook prints
+  `(skip)`, this script never executes, and no line of any kind is emitted —
+  every in-script assertion stays green. That half is covered from outside by
+  [gdpr-gate-glob-liveness.test.sh](../../test/gdpr-gate-glob-liveness.test.sh),
+  which drives the real lefthook binary over the real `lefthook.yml` with a
+  regulated path staged. This repo has shipped the dead-glob trap twice; gobwas
+  `**` matches 1+ intermediate directories, never 0+.
+- **The `vendor-pin-integrity` glob's `*.md` entry under the references directory covers the whole
+  subtree**, because lefthook's gobwas `*` crosses `/`. Measured on lefthook
+  2.1.6: `refs/*.md` matches both depth-1 and depth-2; `refs/**/*.md` matches
+  depth-2 only (that is the `**` behaviour the repo's 2026-03-21 gobwas
+  learning describes, and it does not generalise to `*`). So the `layers/`
+  entry is redundant, and no per-subdirectory entry is needed. The
+  symmetric-difference walk in
+  [vendor-pin-integrity.test.sh](../../test/vendor-pin-integrity.test.sh) is
+  still the backstop for registry membership — it reads the disk, not the
+  glob — but it is not compensating for a coverage hole, because there is
+  none.
+- **Two registries, opposite provenance** (#7710): NOTICE frontmatter carries
+  `lifted-files` (upstream-derived, MIT, pinned against goSprinto) and
+  `soleur-authored` (written for this plugin, no upstream). Both are
+  tamper-checked by `local-blob-sha`; only the former appears in
+  `upstream-files`. A file must appear in exactly one, and the attribution
+  header on line 1 is the oracle for which. Moving a file between them is a
+  provenance falsification, not a bookkeeping change.
+- Hook layer is **advisory only** (`exit 0`). Operators expecting `lefthook` to block will be surprised — the blocking enforcement is at `soleur:ship` Phase 5.5, post-PR.
+- The lefthook breadcrumb does NOT fire when lefthook itself is bypassed: `git commit --no-verify`, GitHub web-UI edits, fork PRs whose authors don't have lefthook installed, or agent commits on machines without `lefthook install`. In those paths the only enforcement is `soleur:ship` Phase 5.5's critical-finding-acknowledgment gate (post-PR). Plan Phase 2.7 + work Phase 2 exit gates run regardless of lefthook because they live inside the skill, not the hook layer.
+- The `*auth*` regex match is intentionally broad — false-positives on `auth-error.ts` etc. are accepted because output is advisory and cheap.
+- Lifted upstream files are pinned to commit `7b58d68461cb1fc033a063e34cc9de63d0b4144b`. Upstream drift is governed by the content-vendoring policy at `knowledge-base/engineering/policies/content-vendoring.md`, the weekly content-vendor-drift cron (an Inngest function, `apps/web-platform/server/inngest/functions/cron-content-vendor-drift.ts` — a GitHub Actions scheduled workflow until the TR9 Phase-2 migration; the Sentry monitor slug keeps the old name), and the lefthook `vendor-pin-integrity` gate (silent-edit detection). NOTICE frontmatter (`upstream`, `pinned-commit`, `last-verified`, `lifted-files[]` with both `upstream-blob-sha` and `local-blob-sha`) is the canonical machine-readable form.
+- **Runtime staleness banner** (FR6 / AC6a-d): the hook subshell-execs [notice-frontmatter.sh](./scripts/notice-frontmatter.sh) `days-stale` on every invocation. Days since `last-verified` >30d → STDOUT banner. Days >90d → additional `POSTURE_FAIL:` STDOUT line; the operator follows the chain in the policy doc to append a row to `compliance-posture.md`. NOTICE deletion / parser failure / future-dated `last-verified` all resolve to `days_stale=999` → banner fires. STDOUT (not stderr) is load-bearing — agent runtimes (Claude Code skill harness, MCP servers) frequently swallow stderr. Gate exits 0 in all paths; the staleness signal is advisory.
+- **Trust-binding via cron-run timestamp** (issue #3535; repointed by #7255). NOTICE `last-verified` is operator-controlled — a PR can rewrite it to today's date and suppress the 30d/90d banners. To defend against backdating, the gate also invokes `notice-frontmatter.sh cron-run-stale`, which asks `gh pr list --search head:ci/vendor-attest --state all --limit 10` for the newest creation date of the cron's self-merging attestation PR (the job is an Inngest cron with no GHA run to list — the attest PR is the artifact every completed run writes, per ADR-203); the staleness banner uses `MIN(notice-last-verified, cron-run-stale)`. A dead or moved artifact stream falls through to 999 and the gate degrades to operator-attested mode — fail-safe, but silent; the `TS-cron-argv` case in the notice-frontmatter suites pins the query shape so the next substrate move goes red.
+- **GH_TOKEN auth contract**: in GitHub Actions the token is auto-injected via `secrets.GITHUB_TOKEN`; in local lefthook runs it is sourced from `gh auth token` if the operator has `gh` configured; in subagent contexts (`soleur:plan`, `soleur:work` shells) the token is typically absent and the gate degrades to operator-attested mode (see next bullet).
+- **MIN precedence and operator-attested-mode banner**: precedence is (cron+notice non-999 → MIN wins; if cron > notice the binding still defends future regressions) > (cron == 999, notice != 999 → operator-attested-mode banner + fallback to notice) > (both == 999 → existing 30d/90d banners fire). When no token is available the gate emits `ℹ gdpr-gate: operator-attested mode (no GH_TOKEN available — cron-run timestamp unverified, falling back to NOTICE last-verified)` to STDOUT — the documented degraded state.
+- **CODEOWNERS pin on NOTICE** (#3535 defense-in-depth): `/plugins/soleur/skills/gdpr-gate/NOTICE` requires `@deruelle` review. Load-bearing only when branch protection is enforced on `main` (an operator follow-up); the cron-run-timestamp binding is the load-bearing defense.
+- **Substrate-move silent break — this already happened once (#7255)**: the original probe keyed liveness on a GHA *workflow filename*; when the job migrated to Inngest the query matched nothing and the binding went inert for months, invisible because the failure signal was its own safe default. The current binding keys on the job's *output artifact* (the attest PR's head-branch prefix), which survives substrate moves as long as ADR-203's write-back machinery keeps producing it — and the notice-frontmatter suites pin the query argv (`pr list` + `head:ci/vendor-attest`) so the next move reds instead of silently reverting to 999. The lesson stands for any future binding of this shape: a probe whose only failure signal is its own safe default will never announce that it stopped working.
+- **Per-judgment advisory banners must gate on regulated-path match** (issue #3541 soleur:engineering:review:user-impact-reviewer P1). The operator-attested-mode banner fires only when `${#matched[@]} > 0` (a regulated-data path is being judged this commit). Otherwise it would spam every commit in subagent shells (no `GH_TOKEN`) and train operators to ignore the signal. Pre-existing 30d/90d staleness banners DO fire unconditionally — they signal gate-internal state ("rules are stale at any rate") rather than per-judgment state ("THIS regulated PR has a degraded gate"). When adding a new advisory banner, ask: does its meaning depend on what the gate is doing on THIS invocation, or on the gate's persistent state? Per-judgment banners must scope to relevance; persistent-state banners may fire unconditionally. See `knowledge-base/project/learnings/2026-05-11-runtime-advisory-banners-must-gate-on-judgment-relevance.md`.
+- The gate transmits column NAMES to the model (Anthropic). This is itself a Chapter V transfer; it falls under Anthropic's existing DPA recorded in `compliance-posture.md` Vendor DPAs. Row values are never sent — see "Prompt template" above.
+- AGENTS.md rule ID `hr-gdpr-gate-on-regulated-data-surfaces` is **immutable** per `cq-rule-ids-are-immutable`. v2 splits retire the ID via the retired-rule-ids ledger rather than reusing.
+- `--repo-scan` against full repo history will surface Art. 9 (`Critical`) findings on pre-v1 migrations 001–040 (legacy columns matching the special-category list). The default disposition is **tracked-not-amended** — `compliance-posture.md` Active Items records the row, no amendment migration is issued, because schema rewrites against historical PII tables carry their own data-integrity risk that typically exceeds the disclosure-cure benefit. The row reads `OPEN | tracked, not amended`. Default disposition only applies when the column is **dormant or read-only with disclosure cure available**. Amendment is required and the operator MUST consult `soleur:legal:clo` before selecting a disposition when ANY of the following hold:
+    1. **Active processing for an undisclosed special-category purpose** — production code currently writes or reads the column for a purpose not disclosed in the privacy notice. Fix is disclosure-side (privacy notice + DPIA + Art. 6/9 lawful-basis annotation) plus, if no Art. 9(2) lawful basis applies, halting processing.
+    2. **Backfill with new special-category data** — schema is old but the *data* is new (placeholder/test rows replaced with real PII). This is operationally a new processing activity; Art. 35 DPIA may itself trigger.
+    3. **Cross-border transfer post-Schrems II** — the column is replicated to a non-EEA processor (analytics, support, vendor) without Chapter V safeguards (DPA + SCCs + transfer impact assessment). Disclosure cure is insufficient — fix the Chapter V gap.
+    4. **CCPA / CPRA "sensitive personal information" overlay** — California's SPI definition (Cal. Civ. Code §1798.140(ae)) overlaps but is not identical to Art. 9. A column that is Art. 9 in EU may also be SPI in California; the disposition must include a CCPA-side disclosure check, not just a GDPR-side one.
+- `path-denylist.txt` patterns are bash `[[ =~ ]]` extended regex, **not shell globs**. Patterns that look like globs (e.g., `*.pem`) silently fail to match. `repo-scan.sh` sets `LC_ALL=POSIX` for locale-determinism, but contributors editing patterns should still verify on both Linux and macOS — character-class behaviour for non-ASCII bytes still differs between the two `bash` builds even with `POSIX` set.

package/skills/gdpr-gate/references/fields.md

@@ -0,0 +1,160 @@
+<!-- Adapted from gosprinto/compliance-skills (MIT) — see NOTICE -->
+# PII Field Patterns
+
+Scan all field names, types, and surrounding context against these.
+Flag on exact match OR semantic approximation.
+
+---
+
+## Critical Sensitivity — Always Flag, Always Fix
+
+```
+# Auth / Secrets
+password, passwd, pwd, pass, passphrase
+password_hash, hashed_password, encrypted_password
+secret, client_secret, app_secret
+api_key, api_secret, private_key, signing_key
+token, auth_token, access_token, refresh_token, bearer_token
+session_id, session_token
+security_question, security_answer, hint
+
+# Abbreviated / indirect — flag when on auth/user model
+p, pw, cred, creds, credential, credentials
+auth, auth_data, auth_info
+key, k  (if on user/auth model)
+
+# Payment Card — PCI-DSS
+card_number, card_num, credit_card, debit_card, pan
+cvv, cvv2, cvc, cvc2, card_code, security_code
+account_number, routing_number, bank_account, iban, swift
+
+# Government IDs
+ssn, social_security, social_security_number
+tax_id, taxpayer_id, itin, ein
+passport, passport_number, passport_no
+drivers_license, license_number, dl_number, dl_num
+national_id, national_id_number, id_number
+
+# Health / Medical — HIPAA
+diagnosis, condition, medical_condition
+medication, prescription, rx
+health_record, medical_record, medical_history, ehr, phi
+insurance, insurance_id, insurance_number, policy_number
+icd_code, cpt_code, npi
+mental_health, psychiatric, therapy_notes
+
+# Biometric — BIPA
+fingerprint, fingerprint_data, biometric
+face_id, face_data, facial_recognition, face_scan
+retina, retina_scan, iris, iris_scan
+voice_print, voice_data, voice_recognition
+dna, genetic_data
+```
+
+---
+
+## High Sensitivity — Flag, Check Storage + Handling
+
+```
+# Identity
+first_name, last_name, full_name, legal_name, maiden_name
+middle_name, display_name
+date_of_birth, dob, birth_date, birthdate, birthday
+age (exact integer), gender, sex, race, ethnicity, nationality
+photo, avatar, profile_picture, selfie
+
+# Contact
+email, email_address, email_addr
+phone, phone_number, mobile, mobile_number, cell, telephone
+address, street_address, street, addr
+city, state, zip, zipcode, zip_code, postal_code
+country, mailing_address, billing_address, shipping_address
+
+# Financial (non-card)
+salary, wage, income, compensation, pay_rate
+balance, account_balance, net_worth
+credit_score, fico, credit_rating
+transaction_history, purchase_history, spending_data
+
+# Location / Tracking
+location, coordinates, lat, lng, latitude, longitude
+gps, geo, geolocation
+ip_address, ip_addr, ip, client_ip, remote_ip
+```
+
+---
+
+## Lower Sensitivity — Flag in Context
+
+```
+# Behavioral
+device_id, device_identifier, device_fingerprint
+ad_id, idfa, gaid, advertising_id
+browser_fingerprint, user_agent
+search_history, browsing_history, click_history
+session_data, activity_log
+
+# Ambiguous — check what they actually store
+notes, metadata, extra, data, info, details, misc, other
+profile, profile_data, user_data, user_info, user_details
+preferences, settings
+```
+
+---
+
+## Indirect / Abbreviated Name Detection
+
+Flag these based on context — they don't look like PII but frequently store it:
+
+| Field | When to Flag | Risk |
+|-------|-------------|------|
+| `p`, `pw`, `k` | Any user/auth model | Almost always password or key |
+| `creds`, `credential` | Anywhere | Auth credentials |
+| `data`, `info`, `details` | User/customer models | PII blobs |
+| `notes` | Patient/customer models | Unstructured PII |
+| `metadata` | User models | Fingerprinting data |
+| `token` | Anywhere | Raw auth tokens |
+| `secret` | Anywhere | Should never be in DB |
+| `code` | Auth/payment models | OTP, CVV, verification codes |
+| `number` | User/payment models | Card, SSN, or phone |
+| `value` | Sensitive models | Generic PII container |
+| `raw`, `original` | Next to hashed fields | Plaintext alongside hash |
+
+Rule: Ambiguous field name + user-facing/financial/health model = flag it.
+
+---
+
+## GDPR Article 9 — Special Categories of Personal Data
+
+EU extension (not in upstream Sprinto). Article 9 prohibits processing of special-category data **without explicit consent or another lawful basis under Art. 9(2)**. Detection on column NAME alone is sufficient grounds for a `Critical` finding — the gate cannot verify whether Art. 9(2) basis is recorded, only that the column exists.
+
+```
+# Health data — Art. 9(1)
+medical_history, medical_record, medical_condition, ehr, phi
+diagnosis, condition, prescription, medication
+mental_health, psychiatric, therapy_notes, therapy_session
+
+# Genetic / biometric — Art. 9(1)
+genetic_data, dna, genome, genetic_marker
+biometric_id, fingerprint_data, retina_scan, iris_scan, face_data, voice_print
+
+# Sex life / sexual orientation — Art. 9(1)
+sexual_orientation, sex_life
+
+# Trade-union — Art. 9(1)
+union_member, union_membership, trade_union
+
+# Religious / philosophical beliefs — Art. 9(1)
+religion, religious_belief, religious_affiliation
+philosophical_belief
+
+# Political opinions — Art. 9(1)
+political_opinion, political_affiliation, political_party
+
+# Race / ethnic origin — Art. 9(1)
+race, ethnic_origin, ethnicity, racial_data
+```
+
+**Rule:** Any column matching the above patterns triggers a `Critical` finding with `check_id: GDPR-Art-9`. The finding routes to the operator-acknowledgment flow (see SKILL.md "Critical-finding escalation"); it never auto-writes to `compliance-posture.md`.
+
+**Why Art. 9 is the only `Critical` class:** Per the Kieran-review HIGH applied during plan review, lawful-basis / retention / DSAR / cross-border findings are demoted to `Important` — without that demotion, first-run noise on existing schemas would train operators to dismiss Critical, defeating the brand-survival rationale. Art. 9 column-name matches are the load-bearing Critical signal.