@prestyj/cli 5.28.1 → 5.29.0

package/assets/skills/clarify/SKILL.md

@@ -1,30 +1,39 @@
 ---
 name: clarify
-description: Use when requirements or a design are genuinely unsettled — the user asks to interrogate, sharpen, or stress-test a plan before building, or mid-build discovery surfaces a decision that materially changes the result. Do NOT use for routine changes, clear bug reports, or work whose requirements are already settled — bias to action there.
+description: Use when requirements or a design are genuinely unsettled — the user asks to interrogate, sharpen, or stress-test a plan or spec before building, a new app or feature request leaves costly-to-reverse product decisions open, or mid-build discovery hits a decision that materially changes the result (scope, data model, UX, tradeoff). Settled terms and hard-to-reverse calls hand off to shared-language. Do NOT use for routine changes, clear bug reports (root-cause), reviewing finished work (code-review), or work whose requirements are already settled — bias to action there.
 ---
 
 # Clarify
 
-Misalignment is the most expensive failure in software: the build succeeds and the thing is still wrong. This skill is a structured interview that settles every open decision **before** implementation. It is not permission-asking — it is decision-forcing.
+Decision-forcing, not permission-asking. Pick the mode:
 
-## Two modes
+- **Quick gate** (mid-build, a blocking decision appears) → one `ask_user` call with every blocking question; keep building everything that does not depend on the answer. Never halt the whole task at one branch point.
+- **Full interview** (user asks to refine a plan/spec/design) → run the rounds below.
 
-**Quick gate** — mid-build, when you hit an unanswered decision that materially changes the result: batch every blocking question into ONE numbered list, each with your recommended answer, and keep building the parts that don't depend on it. Never stop a whole task at one branch point.
+## Rules for every question
 
-**Full interview** — the user asks to refine a plan, spec, or design. Run the rounds below.
+1. **Never ask for facts.** If reading code, running a command, or checking docs can answer it, do that instead. Only decisions reach the user: product calls, taste, tradeoffs with real stakes.
+2. **Ask only the frontier.** A question is on the frontier when every decision it depends on is settled ("needs persistence?" before "which database?"). Never re-ask a settled decision.
+3. **One `ask_user` call per round, never prose questions.** Each question: clickable options, your recommended option first and marked, a one-line reason, and the **default** you will apply if skipped ("Default if skipped: SQLite").
+4. **Show behaviour choices as examples.** When options differ in behaviour, give one concrete case per option ("Given an empty cart, When checkout is pressed, Then …"). Examples expose disagreement that abstract wording hides.
 
-## Rounds (full interview)
+## Full-interview rounds
 
-Work the decision tree from the top:
+1. Investigate first; list open decisions; keep only the frontier.
+2. Ask the round (rule 3).
+3. Record answers as one-line facts — `Settled: dark theme only`. Skipped questions settle to their stated default.
+4. Repeat until a round yields no new frontier questions.
+5. Close: print the decision list plus Given/When/Then acceptance examples for each load-bearing behaviour, then build (or hand back if the user only wanted the plan).
 
-1. **Ask only the frontier.** A question belongs on the frontier when every decision it depends on is already settled. Asking "which database?" before "does this need persistence?" wastes a round; so does re-asking anything an earlier round settled.
-2. **Batch the round.** Every frontier question in one message, numbered, each with `→ recommended: X` and a one-line reason. A recommendation is cheap for the user to confirm and expensive for them to derive.
-3. **Never ask for facts.** Facts are yours: read the code, run the command, check the docs, delegate the wide search. If investigation can answer it, it is not a question — it is homework. Only decisions — taste, product calls, tradeoffs with real stakes — reach the user.
-4. **Record what settled.** After each round, restate the settled decisions as one-line facts ("Settled: dark theme only") before asking the next round, so the record is unambiguous.
-5. **Stop at empty frontier.** When a round produces no new questions, the session is done: restate the full decision list, then start building. The goal is settled decisions, not exhaustive documentation.
+Hand-offs (shared-language skill): newly settled domain terms → glossary; a decision that is hard to reverse, surprising, and a real tradeoff → offer an ADR.
 
-## Anti-patterns
+## Do not
 
-- **Interrogation drip** — one question per reply across ten replies. Every reply costs the user a context switch; batching is the fix.
-- **Homework outsourcing** — asking what you could have read. Burns trust and returns worse answers than the source.
-- **Speculative depth** — questions about futures nobody has committed to. Ask when the decision is load-bearing for work you are about to do.
+- Drip one question per reply — batch the round.
+- Ask about futures nobody has committed to; ask only what is load-bearing for work about to start.
+
+## Scaling: one agent or several
+
+Main thread only. Fact-finding spanning several packages may go to `owl` (repo) or `researcher` (web) children in one `spawn_agent` call; the interview itself is never delegated.
+
+Sources (accessed 3 October 2026): Given-When-Then — https://martinfowler.com/bliki/GivenWhenThen.html

package/assets/skills/code-review/SKILL.md

@@ -1,30 +1,88 @@
 ---
 name: code-review
-description: Use when the user asks to review written work — a diff, PR, branch, or "review this before commit/merge" — checking both what was asked for and how well it is built. Do NOT use while still mid-build, when the user only wants a diff summary, or for security review — that is the bulletproof skill's lane.
+description: Use when the user asks to review written work — a diff, PR, branch, commit range, or agent-generated change — or says "review before merge", "is this really done?", "check what the agent did". Checks spec compliance and build quality separately, verifies PR/"done" claims against the diff, and reports file:line findings by severity. Do NOT use while still mid-build (finish and run checks instead), for a plain diff summary, or for security review (bulletproof), performance (lean), migrations/data loss (durable), or UI review (evidence-led-ui).
 ---
 
 # Code Review
 
-Two independent questions, kept separate because each contaminates the other:
+**Route first:**
 
-1. **Spec axis** — does this change do what was asked, completely, with nothing asked that is missing?
-2. **Standards axis** — does it meet how this repo builds: correctness, error handling, tests at real seams, naming, dead code, scope discipline?
+| Situation | Mode | Next |
+|---|---|---|
+| Small diff: one concern, ≲ ~400 changed lines, few files | **Single pass** | Method below; both axes yourself, spec first, then standards |
+| Large diff, multi-package PR, or many unrelated concerns | **Fan-out** | Build the ledger, then `## Scaling` |
+| Diff written by an agent (including you, this session) | Either mode **+ agent checks** | Also run `references/agent-diffs.md` |
+| User asks "is it secure?" | Defer | Load the `bulletproof` skill — do not audit security here |
+
+Two questions, kept separate because each contaminates the other:
+
+1. **Spec axis** — does the change do what was asked, completely, and nothing unasked?
+2. **Standards axis** — does it meet how this repo builds: design, correctness, error handling, tests, naming, dead code, scope?
 
 ## Method
 
-1. **Pre-flight.** Resolve the exact ref and range and confirm the diff is non-empty BEFORE any review work — a bad ref must fail here, not two passes deep. Read the request or task that motivated the change first: spec-conformance cannot be judged without the spec.
-2. **Split the passes.** On anything larger than a small diff, run the two axes as separate subagents — the spec brief pastes in the original request, the standards brief pastes in the repo's conventions. Separate contexts keep one axis from anchoring the other. Small diffs: run both passes yourself, in that order, never interleaved.
-3. **Findings format.** Per finding: `file:line`, one-line problem, why it matters, the concrete fix. Label each **[spec]** or **[standards]**, and never merge the lists into one ranking — the axes are not comparable, and merging re-ranks by noise.
-4. **Report, then fix what is selected.** Report first; fix what the user picks. Never auto-apply fixes mid-review.
+1. **Pre-flight.** Resolve the exact ref/range (`git diff --stat <base>...<head>`) and confirm it is non-empty BEFORE review work — a bad ref must fail here. Read the motivating request/issue/task first; spec compliance cannot be judged without the spec. No spec available → say so and review standards only.
+2. **Claims ledger.** List every claim from the PR description, commit messages, or the agent's "done" report ("adds X", "fixes Y", "tests pass", "no behaviour change"). Each row ends `verified (file:line or command output)` / `contradicted` / `unverifiable`. A claim with no matching hunk is a **[spec]** finding.
+3. **Run what is cheap.** Typecheck, lint, affected tests — the commands CI uses. Record the actual result. Never write "tests pass" from reading.
+4. **Read the whole diff, then the context.** Every changed line, plus callers of changed signatures (`code_nav references`). Start with design: does the change belong here, at this layer, now? (Google eng-practices ranks design first.)
+5. **Spec pass, then standards pass.** Never interleave. Standards baseline below; agent failure modes in `references/agent-diffs.md`; test quality in `references/tests.md`.
+6. **Report, then fix what the user selects.** Never auto-apply fixes mid-review.
 
-Security findings belong to the `bulletproof` skill — note them and defer; do not audit them here.
+## Findings format
 
-## Standards baseline (when the repo defines none)
+One line each, anchored and actionable:
+
+`[severity] [spec|standards] path/file.ts:42 — problem. Why it matters. Fix: concrete change.`
 
-Missing error handling on I/O and external calls; load-bearing logic without tests, or tests asserting implementation details; dead code and commented-out blocks; names that hide intent; an abstraction used once; a new dependency where the standard library or an installed package would do; secrets in the diff; suppression of failing checks (skipped tests, `as any`, relaxed assertions).
+| Severity | Means | Example |
+|---|---|---|
+| **blocking** | Must change before merge | Wrong behaviour, missing requirement, deleted/weakened test, swallowed error, hallucinated API or package |
+| **non-blocking** | Should change; may follow up | Duplicate helper, weak assertion on a non-critical path |
+| **nit** | Optional polish | Naming, local readability |
+| **question** | You cannot tell; author must answer | Unclear intent, unverifiable claim |
+
+Rules:
+- Keep **[spec]** and **[standards]** as two separate lists — never merge the lists into one ranking; the axes are not comparable and merging re-ranks by noise. Order by severity within each list.
+- Every finding cites a `file:line` you re-opened yourself. No line → it is a **question**, not a finding.
+- Comment on the code, not the author; say why.
+- Skip what tooling already enforces — if lint/CI catches it, it is noise.
+- Security: one line, `[defer → bulletproof] file:line — what looked risky`. Do not rate or fix it here.
+
+## Standards baseline (when the repo defines none)
 
-Skip anything tooling already enforces — findings the linter or CI catches are noise.
+- **Design:** abstraction with one caller; logic in the wrong layer; new dependency where stdlib or an installed package does it.
+- **Correctness:** boundary/off-by-one, null/empty handling, ordering/concurrency changes, error paths.
+- **Errors:** I/O and external calls without handling; broad `catch` that swallows or logs-and-continues.
+- **Tests:** behaviour change without a test; tests that assert internals or nothing (`references/tests.md`).
+- **Hygiene:** dead code, commented-out blocks, debug prints, names that hide intent, secrets in the diff.
+- **Suppression:** skipped tests, `as any`/`@ts-ignore`/`noqa`/`eslint-disable`, relaxed thresholds, `continue-on-error` in CI.
+- **Scope:** files or refactors outside the request; config, lockfile, or CI changes nobody asked for.
 
 ## Verdict
 
-End with the honest state: **works as asked** / **works with gaps** (name them) / **not ready** (blocking reasons). Never "looks good" without stating what was and was not verified.
+- **works as asked** / **works with gaps** (name them) / **not ready** (blocking reasons).
+- Claims ledger: N verified, N contradicted, N unverifiable.
+- What you ran (commands + result) and **what was not checked**.
+
+Never "looks good"/"LGTM" without stating what was and was not verified. Never certify a change safe or bug-free.
+
+## Scaling: one agent or several
+
+| Situation | Do |
+|---|---|
+| Single-pass size (one concern, ≲ ~400 changed lines, few files) | Main thread only. Never spawn. |
+| Larger, multi-package, or > ~15 files | Main thread builds a **coverage ledger**: rows = lens (spec, standards/correctness, tests, agent checks) × file group (package/directory). Each row ends `checked-with-findings` / `checked-clean` / `not-checked(reason)`. |
+| Fan-out | ONE `spawn_agent` call, ≤ 6 read-only children per lens and/or file group: `owl` for reading; general-purpose child if it must run tests. |
+| Security-sensitive hunks (auth, input, secrets, deps, CI) | Route to bulletproof's protocol: `auditor` child briefed with the bulletproof skill root, then `skeptic` on its findings. |
+| High-stakes merge (release, > ~1,000 lines) | One fresh-context verifier child tries to disprove each blocking finding. |
+
+**Child brief** (children see nothing else): absolute skill root `…/assets/skills/code-review`; reference file(s) to read; the exact `git diff <base>...<head> -- <paths>` to run; its ledger rows; the spec text verbatim (spec lens) or the repo conventions (standards lens); the output schema — findings in the format above plus explicit `checked` and `not checked` lists. Read-only, no edits.
+
+**Merge:** a child that fails, times out, or omits a row → that row is `not checked`, never clean. Re-open every reported `file:line` before reporting it; drop what you cannot confirm. Dedupe across children. Keep spec and standards lists separate. Fixes afterwards are serialized in the main thread.
+
+## Sources (SNAPSHOT, accessed 3 October 2026)
+
+- Google eng-practices — https://google.github.io/eng-practices/review/reviewer/looking-for.html, …/reviewer/comments.html, …/reviewer/standard.html, …/developer/small-cls.html
+- Conventional Comments (labels, blocking/non-blocking) — https://conventionalcomments.org/
+- Mutation-testing concept — https://stryker-mutator.io/docs/
+- Package hallucination — Spracklen et al., USENIX Security 2025 (arXiv:2406.10279); 2026 re-evaluation, not peer-reviewed (arXiv:2605.17062), via https://socket.dev/blog/slopsquatting-targets-across-frontier-llms

package/assets/skills/code-review/references/agent-diffs.md

@@ -0,0 +1,27 @@
+# Agent-Generated Diffs: Failure Modes and Checks
+
+Run on any diff an agent wrote (including your own). Each row: what to look for → how to check → default severity.
+
+| Failure mode | Check | Severity |
+|---|---|---|
+| **Hallucinated package** | Every new dependency in a manifest: confirm it exists in the registry (`npm view <pkg>`, `pip index versions <pkg>`), is the intended project (not a look-alike name), and is actually imported. Install scripts → defer to bulletproof. | blocking |
+| **Hallucinated API / symbol** | Every newly called function, method, option, or flag: `code_nav definition`, or read the installed source in `node_modules`/site-packages for the pinned version. Typecheck passing is evidence only for typed code. | blocking |
+| **Weakened or deleted tests** | `git diff --stat -- '*test*' '*spec*'`. For each test hunk: removed assertions, loosened matchers (`toEqual`→`toBeDefined`, exact→`toContain`), widened tolerances, added `.skip`/`.only`/`xit`/`@pytest.mark.skip`, snapshots re-recorded without reason. | blocking unless justified in the PR |
+| **Mocked-away assertions** | Test mocks the very unit under test, or asserts only that a mock was called with whatever it was given. | blocking on critical paths |
+| **Swallowed errors** | New `try/catch` / `except Exception` that returns a default, logs and continues, or wraps a whole function. Compare with the code's previous error contract. | blocking |
+| **Dead code / duplicate helpers** | New function that duplicates an existing helper (`grep` the name's verbs, `code_search` the behaviour); unused exports, params, or branches left behind. | non-blocking |
+| **Scope creep / unrequested refactor** | Map every changed file to a requirement. Files with no requirement → list them. Renames/reformatting mixed with behaviour change → ask for a split. | non-blocking; blocking if it changes behaviour |
+| **Fake "done"** | Claims ledger (SKILL.md step 2): "tests pass" with no run; "handles X" with no hunk; TODO/placeholder/`throw new Error("not implemented")` left in. | blocking |
+| **Config / lockfile drift** | Lockfile changes without a manifest change (or vice versa); tsconfig/eslint/biome rules relaxed; CI steps removed or `continue-on-error` added; version bumps nobody asked for. | blocking for relaxed checks; question otherwise |
+| **Suppressions** | New `any`, `!`, `@ts-ignore`, `eslint-disable`, `# type: ignore`, `noqa`. Each needs a reason at the line. | non-blocking (blocking if hiding a failing check) |
+| **Generated / vendored edits** | Hand edits in `dist/`, generated, or vendored files. | blocking |
+
+## Quick commands
+
+```bash
+git diff --stat <base>...<head>                         # scope
+git diff <base>...<head> -- '*.lock' '*lock.json' '*.toml' 'package.json'   # dependency drift
+git diff <base>...<head> | grep -nE '^\+.*(\.skip|\.only|xit\(|@ts-ignore|eslint-disable|as any|catch *\()'
+```
+
+Grep hits are leads, not findings — open each at file:line before reporting.

package/assets/skills/code-review/references/tests.md

@@ -0,0 +1,19 @@
+# Reviewing Tests
+
+Coverage says a line ran, not that a test would notice it breaking. Review tests with a mutation-testing mindset: "if I broke this line, which test fails?"
+
+## Checks
+
+1. **Each behaviour change has a test that fails without it.** Mentally revert the production hunk and trace which assertion would fail. None → the test does not cover the change. (Do not stash or reset the author's work to check; if a run is needed, ask first.)
+2. **Mutation spot-check on critical lines** (money, auth, data writes, parsing boundaries): flip a comparison, drop a condition, return early. If a test framework exists (e.g. StrykerJS, mutmut, PIT), suggest running it on the changed files only; do not install it unasked.
+3. **Assertion quality.** Flag:
+   - no assertion, or only `toBeDefined`/`toBeTruthy`/`not.toThrow` where a value is knowable;
+   - asserting a mock was called, with no check of the outcome;
+   - snapshot of a huge object where one field matters;
+   - assertions on private internals that block refactoring.
+4. **Real seams.** Mocks only at external boundaries (network, clock, filesystem, randomness). Mocking the unit under test, or the module next to it, proves nothing.
+5. **Edge cases present:** empty, null/undefined, boundary values, error path, concurrency/ordering when relevant.
+6. **Determinism.** No real time, randomness, network, or test-order dependence. Flaky = blocking.
+7. **Test diffs in a "no behaviour change" PR** need a stated reason; otherwise treat as weakened tests (see `agent-diffs.md` table).
+
+Report test findings under **[standards]** unless a required test the spec asked for is missing — that is **[spec]**.

package/assets/skills/compliance-guard/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: compliance-guard
-description: Use when shipping something real users reach and the work carries legal exposure — pre-launch or "is this safe to ship" reviews; personal data, tracking pixels, cookies and consent; payments, subscriptions, auto-renewal; user uploads or UGC; email/SMS; AI or chatbot features; minors' data; biometrics; scraping; accessibility of public pages; or drafting privacy policies, terms, and disclosures. Also use when a feature may be licensed or illegal: health, finance, legal advice, money movement, crypto, gambling, adult content, background checks, automated hiring/lending/housing decisions. Do NOT use for local-only scripts, throwaway prototypes with no real users or data, or changes with no data, money, users, or public surface.
+description: Use when shipping something real users reach and the work carries legal exposure — pre-launch or "is this safe to ship" reviews; mid-build features adding personal data, pixels/cookies, payments or auto-renewal, uploads/UGC, email/SMS/push, AI chatbots, minors, biometrics, scraping; drafting privacy policies, terms, disclosures. Also when a feature may need a licence or be illegal: health, finance, money movement, crypto, gambling, adult content, background checks, automated hiring/lending/housing decisions. Do NOT use for local-only scripts, prototypes with no real users or data, or changes touching no data, money, users or public surface; security hardening is bulletproof's lane.
 license: Apache-2.0. Content is engineering guidance, not legal advice. See references/provenance.md.
 compatibility: Static review works offline from the bundled references. Legal status changes constantly; date-sensitive claims must be re-verified with web access before being stated as current. Never certifies compliance.
 ---
@@ -13,9 +13,9 @@ Catch the legal, privacy, and regulatory exposure in a shipped product before a
 
 1. **Exposure drives obligations, not stack.** What the product *does*, *who can reach it*, and *whose data it touches* decide what applies. A CLI that never leaves the laptop owes almost nothing. A one-page site with a contact form and an ad pixel owes a surprising amount.
 2. **Never certify.** Do not write or say "compliant", "GDPR compliant", "ADA compliant", "fully legal", or "you're covered". Produce a risk register, implemented controls, residual risk, and an explicit *get a lawyer for this* list. This is engineering guidance, not legal advice, and must be labelled as such in every report.
-3. **Date-check before asserting.** The references are a snapshot dated **11 August 2026**. Effective dates, thresholds, injunctions, and penalty amounts move. Before stating a date, a threshold, or "this is in force", re-verify with web access if available; if unavailable, say the claim is from a dated snapshot and needs confirmation. Never invent a citation, statute section, or deadline.
+3. **Date-check before asserting.** The references are a snapshot dated **11 August 2026**, spot re-verified **3 October 2026** (`references/provenance.md` lists what was and was not re-checked). Effective dates, thresholds, injunctions, and penalty amounts move. Before stating a date, a threshold, or "this is in force", re-verify with web access if available; if unavailable, say the claim is from a dated snapshot and needs confirmation. Never invent a citation, statute section, or deadline.
 4. **Say it plainly when it is illegal.** If the requested build is unlawful, licensed, or criminal as described, state that clearly and early — before writing code, not after. Name the specific regime, the concrete red line, the safe subset that *can* be built, and what authorization would change the answer. Do not soften it into a vague caution, and do not silently build it.
-5. **Fix, do not just flag.** Anything code can fix, fix: consent gating, security P0s, opt-out plumbing, deletion propagation, disclosure strings, accessibility defects. Draft documents as clearly-marked templates with `[PLACEHOLDER]` fields. Never invent the user's legal facts — entity name, registered address, DPO, retention periods, or vendor list must come from the user or the repo.
+5. **Fix, do not just flag.** Anything code can fix, fix: consent gating, security P0s (via bulletproof's inline gate), opt-out plumbing, deletion propagation, disclosure strings, accessibility defects. Draft documents as clearly-marked templates with `[PLACEHOLDER]` fields. Never invent the user's legal facts — entity name, registered address, DPO, retention periods, or vendor list must come from the user or the repo.
 6. **Proportionality.** A weekend prototype with no users does not need 60 findings. Gate on *launch-blocking* first, rank by probability × severity, and keep the tail as a backlog. Overwhelming a solo dev produces zero fixes.
 7. **Jurisdictions are a matrix, not a country.** "Where the company is" rarely limits exposure; "who can reach the app" usually sets it. A US-only startup with EU visitors and an unblocked signup form is in scope for EU law.
 
@@ -25,7 +25,7 @@ Catch the legal, privacy, and regulatory exposure in a shipped product before a
 
 This mode matters most, because the users who need this skill will never ask for it. They ask for a signup page, a Stripe checkout, a contact form, an image upload. **Build the control into the feature as you write it** rather than waiting to be asked — consent-gate the pixel you were told to add, put the unsubscribe link in the email template, enforce authorization at the data layer. Mention it in one line and move on. Do not stop the build to deliver a lecture, and do not silently ship the unsafe version and flag it later.
 
-**Full review** — triggered by pre-launch, "is this safe", audit, or first use of this skill on a project. Run the whole workflow below and write the register.
+**Full review** — triggered by pre-launch, "is this safe", or an audit. A first use on a project mid-build stays an inline gate. Run the whole workflow below and write the register.
 
 ## Workflow
 
@@ -214,6 +214,21 @@ The register is the artifact; the message to the user is what actually gets acte
 
 **Do not moralise and do not catastrophise.** State the base rate. "Small apps get sued over this regularly" and "this almost never gets enforced against someone your size, but it is cheap to fix" are both useful; "you could be fined €20 million" is not, because they will stop reading.
 
+## Scaling: one agent or several
+
+| Situation | Do |
+|---|---|
+| Inline gate, small edit, single feature | Main thread only. Never spawn for an inline gate. |
+| Full review, one deployable, one primary jurisdiction, every ledger row readable by you | Stay single-threaded. |
+| Several deployables/surfaces (web + mobile + admin + marketing site) **and** several jurisdictions or data flows | Build the coverage ledger first (rows = ledger items × surfaces × jurisdictions), then fan out. |
+
+Fan-out rules:
+- One `spawn_agent` call, ≤ 6 read-only children, each owning a disjoint slice — **by product surface** (paths) or **by jurisdiction** (US / EU / UK). Brief each with: absolute skill root, the exact reference files to read, its paths, the ledger rows it owns, the RUNTIME/CODE/DEDUCED labels, `[V]/[S]/[U]` markers, and the output schema (finding, file:line, label, severity, fix, plus explicit `checked` and `not checked` lists). Children never see this conversation.
+- Dated legal claims the report will rely on → one `researcher` child per jurisdiction to re-verify against primary sources (statute site, official journal, regulator, court), returning date, status, and URL.
+- **Merge:** a child that fails, times out, or omits a row → that row is `not checked`, never clean. Re-open each reported file:line yourself before reporting it.
+- **Independent verification, always, for a full review:** a fresh-context child gets the draft findings and tries to disprove each one (wrong jurisdiction, ban vs duty, stale date, wrong label). Downgrade or drop what it refutes.
+- Fixes stay serialized in the main thread (or `bee` children on strictly disjoint files); run checks once after merging.
+
 ## Hard stops
 
 Do not build these, regardless of framing. State the reason and offer the lawful subset from `references/sector-gates.md`:
@@ -232,7 +247,7 @@ Do not build these, regardless of framing. State the reason and offer the lawful
 - Never present something you read as something you ran. Every finding and every fix is **RUNTIME**, **CODE**, or **DEDUCED**, and the report says which. "I could not verify this" is a legitimate and useful output; a fabricated confirmation is not.
 - Report what you did **not** check. A review that silently skips the mobile app, the admin panel, or the marketing site reads as full coverage and is more dangerous than no review.
 - Never fabricate a statute, section number, case, effective date, or penalty. If unsure, say "verify this" and mark confidence.
-- Distinguish **verified**, **snapshot (11 Aug 2026, re-verify)**, and **uncertain** in the report. The references carry these markers — preserve them; do not launder a flagged-uncertain item into a confident statement.
+- Distinguish **verified**, **snapshot (11 Aug 2026 / 3 Oct 2026, re-verify)**, and **uncertain** in the report. The references carry these markers — preserve them; do not launder a flagged-uncertain item into a confident statement.
 - Do not use fear as a lever. Give the base rate and the fix, not doom.
 - When the user says a jurisdiction does not apply to them, record it as their stated assumption rather than silently accepting or arguing.
 

package/assets/skills/compliance-guard/references/artifacts.md

@@ -1,6 +1,6 @@
 # Artifacts
 
-What each required document or flow must actually contain, as a skeleton to generate against. Snapshot **11 Aug 2026**.
+What each required document or flow must actually contain, as a skeleton to generate against. Snapshot **11 Aug 2026**, spot re-verified 3 Oct 2026 (see `provenance.md`).
 
 **Rule for every document here:** generate it with `[PLACEHOLDER]` fields for facts only the user has, never invent entity names, addresses, retention periods, or vendor lists, and mark the output as a template that needs review. State plainly which artifacts a competent developer can safely template and which genuinely need a lawyer.
 

package/assets/skills/compliance-guard/references/eu-uk.md

@@ -1,6 +1,6 @@
 # EU / EEA / UK
 
-Snapshot **11 Aug 2026**. Markers: **[V]** verified against a primary/first-tier source · **[S]** snapshot, re-verify · **[U]** contested or in flux.
+Snapshot **11 Aug 2026**, spot re-verified 3 Oct 2026 (see `provenance.md`). Markers: **[V]** verified against a primary/first-tier source · **[S]** snapshot, re-verify · **[U]** contested or in flux.
 
 **Territorial reality:** GDPR applies to anyone offering goods or services to, or *monitoring the behaviour of*, people in the EU/EEA — regardless of where the developer sits **[V]**. Monitoring includes analytics cookies, session replay, ad pixels, and behavioural profiling. A US solo dev with an open signup form and Google Analytics is in scope. Blocking EU traffic is a legitimate engineering answer and should be offered as an option.
 
@@ -38,7 +38,7 @@ Snapshot **11 Aug 2026**. Markers: **[V]** verified against a primary/first-tier
 
 ## 2. ePrivacy — cookies and device storage
 
-Consent is required **before** any non-essential storage or access on the user's device, under the ePrivacy Directive as transposed by each Member State — 27 variants, and harmonisation is not coming **[V]**. Scope is technology-neutral and expressly reaches pixels, local storage, and similar techniques **[V]**. This applies **whether or not** the data is personal, which is why "we only use anonymous analytics" is not an answer.
+Consent is required **before** any non-essential storage or access on the user's device, under the ePrivacy Directive as transposed by each Member State — 27 variants **[V]**. The Digital Omnibus proposal to move cookie rules into the GDPR (Art 88a/88b: one-click refuse, no re-asking for six months, browser signals) is **not law** — as of September 2026 it was still in first reading with no Council negotiating mandate and no trilogue **[S]**. Do not build to it; one-click reject is already the defensible design anyway. Scope is technology-neutral and expressly reaches pixels, local storage, and similar techniques **[V]**. This applies **whether or not** the data is personal, which is why "we only use anonymous analytics" is not an answer.
 
 **Banner technical spec** (this is the implementable contract):
 - No third-party script, pixel, or network request before an affirmative choice.
@@ -60,19 +60,19 @@ Consent is required **before** any non-essential storage or access on the user's
 
 ---
 
-## 3. EU AI Act — verified timeline
+## 3. EU AI Act — timeline
 
-The Digital Omnibus on AI (Reg (EU) 2026/1744) was published on 24 July 2026 and entered into force on 27 July 2026 **[V]**. **Any guidance dated before mid-2026 saying high-risk obligations apply from 2 August 2026 is now wrong.**
+The Digital Omnibus on AI (Reg (EU) 2026/1744 of 8 July 2026) was published in the OJ on 24 July 2026 and entered into force on the third day after publication **[V]** (EUR-Lex OJ text opened 3 Oct 2026). Dates below marked **[V]** were read in that text; 2 Feb 2027 was not located there **[U]**. **Any guidance dated before mid-2026 saying high-risk obligations apply from 2 August 2026 is now wrong.**
 
 | Date | Status |
 |---|---|
-| 2 Feb 2025 | Prohibited practices and AI literacy — **in force** |
-| 2 Aug 2025 | GPAI models, governance, penalties — **in force** |
-| **2 Aug 2026** | **Article 50 transparency obligations — in force now** (Art 50(2) not applying to systems already on the market at that date) |
-| 2 Dec 2026 | Art 50(2) marking for legacy systems; new prohibited practices added (AI-generated NCII and CSAM) |
-| 2 Feb 2027 | Watermark-detection interoperability deadline for providers |
-| **2 Dec 2027** | High-risk obligations for standalone Annex III systems — **deferred** |
-| 2 Aug 2028 | High-risk obligations for embedded Annex I systems |
+| 2 Feb 2025 | Prohibited practices and AI literacy — **in force** **[V]** |
+| 2 Aug 2025 | GPAI models, governance, penalties — **in force** **[S]** |
+| **2 Aug 2026** | **Article 50 transparency obligations — in force now** (general application date) **[V]** |
+| 2 Dec 2026 | Art 50(2) marking for generative systems placed on the market before 2 Aug 2026; new Art 5(1)(ba)/(bb) prohibitions incl. non-consensual sexual deepfakes of identifiable people **[V]** |
+| 2 Feb 2027 | Watermark-detection interoperability deadline for providers **[U]** |
+| **2 Dec 2027** | High-risk obligations for standalone Annex III systems — **deferred** **[V]** |
+| 2 Aug 2028 | High-risk obligations for embedded Annex I systems **[V]** |
 
 **Provider vs deployer is the consequential classification.** Providers develop an AI system, or have it developed, and place it on the market or into service **under their own name or trademark**, regardless of establishment **[V]**. Wrapping a foundation model in your own product and shipping it under your brand generally makes you a provider of that AI system — not merely a deployer.
 
@@ -114,10 +114,10 @@ Penalties for Art 50 breaches reach €15M or 3% of global turnover; prohibited
 ## 4. Other EU acts
 
 - **Digital Services Act** — triggered by *hosting information provided by a recipient*: user uploads, comments, profiles, public pastes, shared docs. Single-tenant B2B SaaS with no third-party-visible content is generally out **[V]**. All hosting providers regardless of size owe a point of contact for authorities and users, a notice-and-action mechanism, statements of reasons for removals, and terms describing moderation. Micro and small enterprises are exempt from several heavier duties but **not** from the basics.
-- **European Accessibility Act** — applies to **service categories**, not all software: e-commerce (any consumer-facing online sale), consumer banking, e-books, electronic communications, transport ticketing, and access to audiovisual media **[V]**. In force since 28 June 2025 for new products and services. A B2B-only SaaS is out of scope; a B2C app with a checkout is in. Technical standard is EN 301 549 (WCAG 2.1 AA today; a WCAG 2.2-aligned version is expected **[U]** — build to 2.2 AA now, it is backwards-compatible). Microenterprise exemptions apply to services but the detail varies by transposition **[U]**.
+- **European Accessibility Act (Directive (EU) 2019/882)** — applies to **service categories**, not all software: e-commerce (any consumer-facing online sale), consumer banking, e-books, electronic communications, transport ticketing, and access to audiovisual media **[V]**. Applies since 28 June 2025 to products placed on the market and services provided to consumers after that date (Art 31(2)) **[V]**. Art 32 transitional rules: service contracts agreed before 28 June 2025 may run unaltered until expiry but no later than **28 June 2030**; products already used to deliver services may continue until 28 June 2030; self-service terminals up to 20 years **[S]** (Article text as quoted by secondary sources; EUR-Lex not opened). None of this exempts a new or changed web checkout. A B2B-only SaaS is out of scope; a B2C app with a checkout is in. Technical standard is EN 301 549 (WCAG 2.1 AA today; a WCAG 2.2-aligned revision is in progress **[U]** — build to 2.2 AA now, it is backwards-compatible). Microenterprises (<10 staff and ≤€2M turnover) are exempt for services, but the detail varies by transposition **[S]**.
 - **Cyber Resilience Act** — applies to *manufacturers* of products with digital elements placed on the EU market: downloadable or installable software, desktop and mobile apps, browser extensions, firmware, monetised libraries **[V]**. Main obligations from 11 December 2027, but **reporting obligations from 11 September 2026** — actively exploited vulnerabilities and severe incidents must be reported on a short clock. Pure SaaS is generally outside, but the SaaS boundary is exactly where small products get caught unexpectedly; re-read the Commission's practical guidance **[U]**.
 - **NIS2** — sector plus size; cloud, data-centre, managed-service and managed-security providers are in scope, but the size cap generally means ≥50 staff or >€10M turnover **[S]**. A small SaaS is normally out unless designated.
-- **Data Act** — applies to providers of data processing services (expressly including SaaS, PaaS, IaaS) with EU customers, with no carve-out for small providers **[V]**. Practical duties: contractual switching and egress terms, no unreasonable exit barriers, and data-porting support.
+- **Data Act (Regulation (EU) 2023/2854)** — applicable since **12 September 2025** (Art 50) **[S]**. Two developer-relevant parts: (1) providers of data processing services (expressly including SaaS, PaaS, IaaS) with EU customers, with no carve-out for small providers, owe contractual switching and egress terms, no unreasonable exit barriers, and data-porting support; switching charges must be abolished from **12 January 2027** **[S]**. (2) Makers of **connected products** (IoT devices, wearables, connected cars) and their companion apps owe user access to product and related-service data; from **12 September 2026** products placed on the market must be designed so users can access that data directly where relevant and technically feasible (Art 3(1)) **[S]**. Chapter IV unfair-terms rules apply to B2B data contracts concluded after 12 Sept 2025 **[S]**.
 - **DORA** — only if you are a financial entity or a contracted ICT provider to one; for a small dev it arrives as customer contract terms **[S]**.
 - **PSD2 SCA** — use a PSP with 3-D Secure rather than building card flows; exemptions belong to the PSP **[S]**.
 - **MiCA** — issuing a token or providing crypto-asset services to EU users requires authorisation; merely accepting crypto payment through a licensed processor generally does not **[S]**.
@@ -128,8 +128,8 @@ Penalties for Art 50 breaches reach €15M or 3% of global turnover; prohibited
 
 ## 5. UK specifics
 
-- **Data (Use and Access) Act 2025** — principal data-protection provisions in force from 5 February 2026 **[V]**. Code-relevant changes: the new DSAR clock (Art 12A), recognised legitimate interests, a permission-plus-safeguards model for automated decision-making replacing the old prohibition, and the PECR analytics/functionality cookie exemption.
-- **Online Safety Act** — triggered by **user-to-user** services (anywhere users can encounter content uploaded by others — comments, DMs, forums, shared galleries, multiplayer chat), search services, and pornography publishers, with UK links. **There is no small-service exemption from the core duties**, and the regulator runs a dedicated "small but risky" supervision function **[V]**. Duties include illegal-content and children's-access risk assessments, proportionate safety measures, reporting and complaints mechanisms, and highly effective age assurance where required. Treat any UK-reachable UGC product as in scope and produce the risk assessments — their absence is itself the enforceable failure.
+- **Data (Use and Access) Act 2025** — Royal Assent 19 June 2025; commenced in stages. The principal data-protection provisions came into force on **5 February 2026** under SI 2026/82 (legislation.gov.uk): ss. 70, 76, 80, 112 and Schedules 4, 6, 11, 12 **[V]**. Code-relevant changes: the new DSAR clock (Art 12A UK GDPR), recognised legitimate interests (no balancing test), Arts 22A–22D replacing the automated-decision prohibition with permission plus safeguards (information, representations, human intervention, contest) for non-special-category data, and the PECR analytics/functionality cookie exemption. The complaints-handling duty (new s. 164A DPA 2018) followed on **19 June 2026** **[V]**. Remaining stages (ICO restructuring into the Information Commission) are institutional and do not change code **[S]**.
+- **Online Safety Act** — triggered by **user-to-user** services (anywhere users can encounter content uploaded by others — comments, DMs, forums, shared galleries, multiplayer chat), search services, and pornography publishers, with UK links. **There is no small-service exemption from the core duties**, and the regulator runs a dedicated "small but risky" supervision function **[V]**. Duties include illegal-content and children's-access risk assessments, proportionate safety measures, reporting and complaints mechanisms, and highly effective age assurance where required. Ofcom has been fining since late 2025 — mostly for missing highly effective age assurance on pornographic services, and in one case for a missing illegal-content risk assessment and deficient terms — with penalties up to £18M or 10% of qualifying worldwide revenue **[S]**. The register of categorised services (Category 1, 2A, 2B; extra duties) was published in July 2026 **[S]**; small services are not categorised, but the core duties still apply. Treat any UK-reachable UGC product as in scope and produce the risk assessments — their absence is itself the enforceable failure.
 - **Children's Code** — applies to services *likely to be accessed* by under-18s, a much lower bar than "aimed at children": high-privacy defaults, geolocation off by default, no nudges toward weaker privacy, a DPIA covering children, minimised profiling **[V]**.
 - **Accessibility** — no private-sector EAA equivalent; exposure runs through the Equality Act duty to make reasonable adjustments, with WCAG 2.1 AA as the de facto benchmark **[S]**.
 
@@ -148,4 +148,4 @@ Penalties for Art 50 breaches reach €15M or 3% of global turnover; prohibited
 
 ## 7. Verify before relying
 
-AI Act fine tiers post-Omnibus · the EAA transitional date for pre-2025 service contracts (sources conflict between 2027 and 2030) · EN 301 549 version status · the GDPR/ePrivacy half of the Digital Omnibus (**still in negotiation — not law**) · consent-or-pay scope broadening · CRA SaaS boundary · NIS2 small-provider designation practice · UK adequacy status.
+AI Act fine tiers post-Omnibus · EN 301 549 version status · the GDPR/ePrivacy half of the Digital Omnibus (**not law**: as of Sept 2026 still in first reading, no Council mandate, no trilogue) · Ofcom's categorised-services duties consultation outcome · consent-or-pay scope broadening · CRA SaaS boundary · NIS2 small-provider designation practice · UK adequacy status.

package/assets/skills/compliance-guard/references/lawsuit-vectors.md

@@ -1,6 +1,6 @@
 # Lawsuit & Demand-Letter Vectors
 
-How a small app actually gets sued or extorted, ranked by real base rate rather than statutory maximum. Snapshot **11 Aug 2026** — verify any date, amount, or case posture before stating it as current.
+How a small app actually gets sued or extorted, ranked by real base rate rather than statutory maximum. Snapshot **11 Aug 2026**, spot re-verified 3 Oct 2026 (see `provenance.md`) — verify any date, amount, or case posture before stating it as current.
 
 **The core asymmetry:** most regulators do not chase solo developers. Private plaintiffs and demand-letter mills do, because the process is automated: a bot scans public sites for a technical fingerprint, a letter goes out, and settling is cheaper than defending. Optimise against *fingerprints*, not against theoretical liability.
 
@@ -8,7 +8,7 @@ How a small app actually gets sued or extorted, ranked by real base rate rather
 
 ## 1. Web accessibility demand letters — highest base rate
 
-**Who:** serial plaintiff firms filing thousands of federal suits a year, plus a much larger volume of pre-suit letters. Filings have grown year over year **[V]**; small e-commerce is the primary target.
+**Who:** serial plaintiff firms filing thousands of federal suits a year, plus a much larger volume of pre-suit letters. Federal website-accessibility filings were 3,117 in 2025, up 27% on 2024, and over 5,000 counting state courts **[S]**; e-commerce is the primary target, and pro se filings drafted with AI tools are rising **[S]**.
 
 **Fingerprint they scan for:** automated scanners on the homepage and checkout. Missing `alt`, unlabeled form inputs, missing form `<label>`/`aria-label`, low contrast, no visible focus indicator, keyboard traps in modals and menus, inaccessible custom dropdowns, images of text, missing page language, empty links/buttons with icon-only content, and — the defect generated code produces most reliably — **a clickable `<div>` or `<span>` carrying an `onClick` with no `<button>`, no `role`, no `tabIndex`, and no key handler**, which is simply invisible to keyboard and screen-reader users.
 
@@ -35,7 +35,7 @@ How a small app actually gets sued or extorted, ranked by real base rate rather
 
 **Scale:** pen-register-style claims have become a dominant share of active privacy litigation, driven by ordinary analytics and ad tools **[V]**. Statutory damages of **$5,000 per violation** are the leverage **[V]**.
 
-**Relief status:** California SB 690 would strip private rights of action for the pen-register sections only, and as amended in July 2026 it does **not** touch §631 wiretap claims **[V]**. Do not plan around it; re-verify its status before advising.
+**Relief status:** California SB 690 was signed on 30 September 2026 and is operative 1 January 2027: private suits under the pen-register/trap-and-trace section (§638.51) over a website or app are removed (Attorney General only), with retroactive reach to pending claims filed within the prior two years **[U]** (consistent across law-firm reports; the leginfo text was not retrieved). It does **not** touch §631/§632 wiretap claims, which remain the main pixel/session-replay/chat-widget theory **[S]**. The fix is unchanged: consent-gate every third-party request.
 
 **Fingerprint:** any third-party request firing on page load before consent — Meta/TikTok/LinkedIn pixels, GA, session replay, chat widgets, A/B tools. Server-side tagging does **not** cure it if the third party still receives the data.
 
@@ -53,7 +53,7 @@ How a small app actually gets sued or extorted, ranked by real base rate rather
 
 **Trigger:** collecting a face geometry, fingerprint, voiceprint, iris, or similar identifier from a person in Illinois — with **no volume threshold**, so a single user creates exposure. Consent must be a **written release obtained before collection**, and you must publish a retention and destruction schedule **[V]**.
 
-**Damages:** $1,000 negligent / $5,000 intentional **per person**, plus fees. A 2024 amendment limits recovery to a single accrual per person rather than per scan, which materially reduced exposure but not filing volume **[V]**.
+**Damages:** $1,000 negligent / $5,000 intentional **per person**, plus fees. The August 2024 amendment (SB 2979) limits recovery to one per person per collection method rather than per scan, and the Seventh Circuit held on 1 Apr 2026 (*Clay v. Union Pacific*) that it applies to cases already pending **[S]**. Exposure dropped, filing volume did not: a class of thousands is still serious money.
 
 **Fingerprint in code:** face detection or recognition SDKs, `face_embedding`/`descriptor`/`template` columns, voice embeddings, liveness checks, photo auto-tagging, avatar generation from a selfie. Face *detection* without identification is contested **[U]** — do not rely on it as a defence.
 
@@ -73,7 +73,7 @@ How a small app actually gets sued or extorted, ranked by real base rate rather
 
 ## 5. Subscription / auto-renewal class actions
 
-**Trigger:** auto-renewal or free-trial conversion with disclosures that are not clear and conspicuous *adjacent to the enrolment control*, no separate affirmative consent, or a cancellation path harder than the signup path **[V]**. California's amended auto-renewal law broadened what is actionable **[V]**; a federal click-to-cancel rule was vacated in 2025, so **state law and general deception rules are the live risk** — do not tell a user the federal rule saves them **[V]**.
+**Trigger:** auto-renewal or free-trial conversion with disclosures that are not clear and conspicuous *adjacent to the enrolment control*, no separate affirmative consent, or a cancellation path harder than the signup path **[V]**. California's amended auto-renewal law broadened what is actionable **[V]**; the federal click-to-cancel rule was vacated in July 2025 and the FTC only restarted rulemaking with an advance notice in March 2026, so **state law and general deception rules are the live risk** — do not tell a user the federal rule saves them **[S]**.
 
 **Fingerprint:** trial logic with no reminder job; a cancel flow that emails support; terms shown behind a link rather than adjacent to the button; no stored record of what the user was shown.
 

package/assets/skills/compliance-guard/references/provenance.md

@@ -2,7 +2,7 @@
 
 ## Snapshot
 
-These references were compiled on **11 August 2026** from primary and first-tier sources: EUR-Lex and the Official Journal, EDPB, national data protection authorities, ICO, Ofcom, the European Commission, the FTC, CPPA, state legislature and AG sites, US federal court opinions, the Copyright Office, NIST, OWASP, PCI SSC, and platform developer documentation.
+These references were compiled on **11 August 2026** and spot re-verified on **3 October 2026** (see *Re-verification log* below) from primary and first-tier sources: EUR-Lex and the Official Journal, EDPB, national data protection authorities, ICO, Ofcom, the European Commission, the FTC, CPPA, state legislature and AG sites, US federal court opinions, the Copyright Office, NIST, OWASP, PCI SSC, and platform developer documentation.
 
 ## Confidence markers
 
@@ -21,7 +21,7 @@ Re-verify these before relying on them, in rough order of volatility:
 1. **US state AI laws** — effective dates have moved repeatedly, some are enjoined, some were repealed and replaced mid-cycle, and federal preemption efforts are active.
 2. **State privacy law scope** — new states take effect on 1 January and 1 July cycles; thresholds and cure periods change.
 3. **EU AI Act dates** — amended in July 2026; any guidance written before mid-2026 is unreliable on the high-risk timeline.
-4. **EU data/ePrivacy reform** — the data-protection half of the Digital Omnibus was still in negotiation at snapshot time and is **not law**. Do not build to proposed cookie or browser-signal provisions.
+4. **EU data/ePrivacy reform** — the data-protection half of the Digital Omnibus is **not law**; at 3 Oct 2026 it was in first reading with no Council mandate. Do not build to proposed cookie or browser-signal provisions.
 5. **EU–US transfer framework** — valid at snapshot, with an appeal pending.
 6. **Wiretap/pixel litigation** — statutory reform and appellate decisions are actively reshaping which theories survive.
 7. **Age-verification and minors' laws** — rapid state adoption plus constitutional litigation.
@@ -40,3 +40,42 @@ Re-verify these before relying on them, in rough order of volatility:
 When web access is available, verify in this order before making a claim the user will act on: (1) the effective date, (2) whether the law survived litigation, (3) the threshold and whether the user is over it, (4) the penalty and whether a private right of action exists. Prefer the statute, the regulator's own guidance, or the court's opinion over secondary commentary — law-firm blog posts were a recurring source of the errors corrected during this research, including at least one widely-repeated claim about an EU obligation that does not exist.
 
 When web access is unavailable, say so, cite the snapshot date, and mark the affected findings as needing verification.
+
+## Re-verification log — 3 October 2026
+
+**Pass 1** (secondary sources): CA SB 690 signed 30 Sep 2026; Colorado SB 26-189; FCC TCPA revocation order reportedly adopted 30 Sep 2026; FTC negative-option ANPRM March 2026; Data Omnibus first-reading status; AI Omnibus dates; Texas SB 2420.
+
+**Pass 2** (primary sources preferred):
+
+| Item | Result | Source tier | File |
+|---|---|---|---|
+| UK DUAA commencement | Main provisions 5 Feb 2026 (SI 2026/82); s.164A complaints 19 Jun 2026 | **Primary**: legislation.gov.uk SI 2026/82, SI 2026/31 | `eu-uk.md` |
+| CPPA ADMT / risk assessment / audits | Effective 1 Jan 2026; ADMT 1 Jan 2027; RA attestation 1 Apr 2028; audits 2028/29/30 by revenue | **Primary**: cppa.ca.gov rulemaking page + 23 Sep 2025 announcement | `us.md` |
+| TAKE IT DOWN §3 | Enforced from 19 May 2026; 48h removal; FTC complaint portal | **Primary**: ftc.gov press releases (May 2026) | `us.md` |
+| Colorado SB 26-189 | Repeal-and-reenact confirmed; 1 Jan 2027 date from secondary only → **[U]** | Primary (partial): leg.colorado.gov bill page | `us.md` |
+| EU Data Act | Applies 12 Sep 2025; Art 3(1) design duty 12 Sep 2026 (Art 50) | Statute text via secondary mirror + law firms (EUR-Lex not fetched) | `eu-uk.md` |
+| EAA transitional | 28 Jun 2030 cap for pre-2025 service contracts (Art 32); "2027 vs 2030" conflict resolved | Statute text quoted in secondary sources | `eu-uk.md` |
+| COPPA | Effective 23 Jun 2025; compliance 22 Apr 2026 (90 FR 16918) | Secondary (consistent citations to FR) | `us.md` |
+| ADA Title II | DOJ IFR 20 Apr 2026: 26 Apr 2027 / 26 Apr 2028 (FR Doc 2026-07663) | Secondary + SBA Office of Advocacy (federalregister.gov blocked the fetch) | `us.md` |
+| ADA Title III trend | 3,117 federal web suits in 2025 (+27%) | Secondary (Seyfarth tracker) → [S] | `us.md`, `lawsuit-vectors.md` |
+| GPC states / new laws | 12 GPC states unchanged; IN, KY, RI live 1 Jan 2026 without GPC duty | Secondary → GPC list kept [V] from August, 2027 laws [U] | `us.md` |
+| UK OSA | Fines ongoing; categorised register July 2026 | Secondary (Ofcom roadmap page partly) → [S] | `eu-uk.md` |
+| PCI DSS 4.0.1 | Future-dated reqs mandatory 31 Mar 2025; v4.0 retired 31 Dec 2024 | Secondary (pcisecuritystandards.org not fetched) → [S] | `security-baseline.md` |
+| WA MHMDA + health-data laws | Damages: actual, treble to $25,000 (corrected from "$7,500/violation"); NY HIPA not law | Secondary → [S] | `us.md` |
+| BIPA | SB 2979 per-person cap retroactive (7th Cir. *Clay v. Union Pacific*, 1 Apr 2026) | Secondary (multiple firms quoting opinion) | `us.md`, `lawsuit-vectors.md` |
+| App-store laws | Utah → 6 May 2027 (HB 498), PRA 31 Dec 2026; Louisiana → 1 Jul 2027 (HB 977); CA AB 1043 1 Jan 2027 | Secondary → [S]; Alabama [U] | `us.md` |
+| Reg (EU) 2026/1744 | Pass 3: OJ text opened (eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202601744): OJ 24.7.2026, in force 3rd day; Art 5(1)(ba)/(bb) + Art 50(2) legacy 2 Dec 2026; Annex III 2 Dec 2027; Annex I 2 Aug 2028 → **[V]**. 2 Feb 2027 watermark date not found → [U] | Primary | `eu-uk.md`, `sector-gates.md` |
+| Delete Act / DROP | Pass 3: 1 Aug 2026, 45-day cadence, DROP account duty → **[V]** (cppa.ca.gov/data_brokers/) | Primary | `us.md` |
+| Texas TRAIGA HB 149 | Pass 3: signed 22 Jun 2025, effective 1 Jan 2026 → **[V]** (capitol.texas.gov History HB149, 89R) | Primary | `us.md` |
+| CA SB 243 reporting | Pass 3: leginfo unreachable; 1 Jul 2027 reporting start from secondary → [S] | — | `us.md` |
+| CA SB 690 | leginfo fetch failed → retroactivity detail **[U]** | — | `lawsuit-vectors.md` |
+| FCC TCPA order | fcc.gov page not found; stays **[U]** | — | `us.md` |
+| Texas SB 2420 | No court order opened → **[U]** | — | `us.md` |
+
+Marker rule applied in pass 2: **[V]** only where a primary source was actually opened (legislation.gov.uk, cppa.ca.gov, ftc.gov, leg.colorado.gov); secondary-only facts are **[S]**; earlier-pass items without primary confirmation are **[U]**. Items whose [V] dates from the 11 Aug snapshot keep it.
+
+**Pass 3 (3 Oct 2026) still unverified:** leginfo (SB 243/942/AB 853/AB 2013) timed out; nysenate.gov and legiscan 403; CRA (Reg 2024/2847) EUR-Lex and digital-strategy pages returned empty; DPF appeal (C-703/25 P) not fetched. Those claims keep their prior markers.
+
+**Still unverified after pass 2:** primary text for Reg 2026/1744, SB 690, the FCC order, Colorado's effective date, the Title II IFR, COPPA FR text, PCI SSC documents, and Ofcom's register. Not re-checked at all: genetic-privacy state list, VPPA, NY SAFE for Kids, Delete Act/DROP, CA SB 942/AB 2013/SB 243, Texas TRAIGA, CRA, DSA, NIS2, DPF appeal, consent-or-pay, adult-content AV state count, everything in `sector-gates.md`, `artifacts.md`, `trigger-map.md`, `exposure-triage.md`.
+
+Pass 1 sources: whitecase.com, acompli.ie, fenwick.com, procopio.com, seyfarth.com, troutmanprivacy.com, burr.com, commlawgroup.com, mslawgroup.com, kelleydrye.com, crowell.com, mofo.com, recordinglaw.com. Pass 2 adds: legislation.gov.uk/uksi/2026/82, cppa.ca.gov/regulations/ccpa_updates.html, cppa.ca.gov/announcements/2025/20250923.html, ftc.gov/news-events/news/press-releases/2026/05/ftc-begins-enforcing-take-it-down-act, leg.colorado.gov/bills/sb26-189, reedsmith.com (Title II IFR), advocacy.sba.gov, adatitleiii.com, wsgr.com (Data Act), lw.com and davispolk.com (COPPA), insideprivacy.com (BIPA), loeb.com and recordinglaw.com (Utah/Louisiana), enzuzo.com (MHMDA), 360advanced.com (PCI), reedsmith.com (OSA).

package/assets/skills/compliance-guard/references/sector-gates.md

@@ -2,7 +2,7 @@
 
 Domains where **building the thing is the problem**, not the privacy policy. Evaluate these *before* any other checklist: if the product cannot lawfully exist as described, nothing downstream matters.
 
-Snapshot **11 Aug 2026**. Markers: **[V]** verified · **[S]** re-verify · **[U]** genuinely unresolved.
+Snapshot **11 Aug 2026**, spot re-verified 3 Oct 2026 (see `provenance.md`). Markers: **[V]** verified · **[S]** re-verify · **[U]** genuinely unresolved.
 
 Each entry gives the trigger, the **safe subset** a small dev can ship, and the **red line** that means stop.
 
@@ -107,7 +107,7 @@ The test is **prize + chance + consideration**. Remove one leg or you need a lic
 - **Screening or scoring people** — assembling or evaluating consumer information for eligibility decisions makes you a **consumer reporting agency**: permissible purpose, maximum possible accuracy, dispute handling, and adverse-action notices **[V]**. "It's just an AI background check" does not escape this; it is the classic small-company FCRA class action.
 - **Credit** — adverse-action notices must state **specific principal reasons**. A black-box model that cannot articulate reasons is itself the violation **[V]**.
 - **Housing and insurance** — disparate-impact exposure and rating regulation apply regardless of intent.
-- **EU** — these are Annex III high-risk categories under the AI Act, with obligations from Dec 2027 **[V]**.
+- **EU** — these are Annex III high-risk categories under the AI Act, with obligations from 2 Dec 2027 (Reg 2026/1744) **[V]**.
 
 ---
 
@@ -149,7 +149,7 @@ Product descriptions or code signals → regime → the one-line warning to show
 | "loot box", "gacha" | Consumer-protection and gambling rules | Disclose real-money value and drop rates; cash-out crosses into gambling. |
 | "users upload photos/videos" | DMCA, CSAM reporting, NCII takedown | Register a DMCA agent, build a CSAM reporting path, and ship a 48-hour NCII takedown flow. |
 | "voice clone of [celebrity]", "sounds like [artist]" | Right of publicity, digital-replica laws | Cloning an identifiable voice without consent is actionable in a growing number of states. |
-| "nudify", "undress", sexualised image of a real person | Federal criminal statutes, NCII law, EU AI Act Art 5 | Criminal territory, not a grey area. Refuse. |
+| "nudify", "undress", sexualised image of a real person | Federal criminal statutes, NCII law, EU AI Act Art 5(1)(ba) (from 2 Dec 2026, per Reg 2026/1744) **[V]** | Criminal territory, not a grey area. Refuse. |
 | "we scrape LinkedIn" or any logged-in source | Anti-hacking statutes, contract, GDPR | Authenticated scraping revives criminal-statute exposure, and EU personal data needs a documented lawful basis. |
 | "train on scraped user photos/posts" | GDPR, TDM opt-outs, AI Act | Public availability is not consent; machine-readable opt-outs must be honoured and a training-data summary published for the EU. |
 | "under 13", kids' game, school rollout | COPPA, FERPA, state student-privacy laws | Verifiable parental consent or a signed school agreement is required before any collection, and no ad SDKs. |

package/assets/skills/compliance-guard/references/security-baseline.md

@@ -2,7 +2,7 @@
 
 Security is the fastest route from "small app" to "regulatory incident": a breach triggers notification duties, class actions in states with a breach private right of action, and the deception theory that your privacy policy promised protection you did not provide. This file is the pre-deploy floor, weighted toward the failure modes that AI-generated and rapidly built apps produce most often.
 
-Snapshot **11 Aug 2026**. Verify version numbers and vendor terms before asserting them.
+Snapshot **11 Aug 2026**, spot re-verified 3 Oct 2026 (see `provenance.md`). Verify version numbers and vendor terms before asserting them.
 
 ---
 
@@ -79,7 +79,7 @@ Academic and vendor studies through 2024–2026 consistently find a substantial
 ## Payments
 
 - Use hosted fields/checkout from your processor so PAN never touches your origin. This is what keeps your PCI scope minimal.
-- Payment-page script integrity and script inventory requirements now apply to pages that take card data **[S]** — verify the current PCI DSS requirement numbers and SAQ eligibility with your processor before advising, since eligibility differs between fully hosted redirect and embedded-fields integrations.
+- PCI DSS v4.0.1 is the only active version (v4.0 retired 31 Dec 2024), and all 51 formerly future-dated requirements have been mandatory since **31 March 2025**, with no remaining grace period **[S]**. For web checkouts the ones that bite are 6.4.3 (inventory, authorise and integrity-check every script on the payment page) and 11.6.1 (detect unauthorised changes to payment-page scripts and security headers) **[S]**. Confirm SAQ eligibility with your processor before advising: it differs between a fully hosted redirect and embedded fields/iframes.
 - Verify webhook signatures; make handlers idempotent; never grant entitlements from a client-side success callback.
 - Reconcile: entitlement state must derive from the processor's record, not from your optimistic write.
 - Store only the processor's customer/payment-method reference, never card data.