@prestyj/cli 5.28.1 → 5.29.0

package/assets/skills/compliance-guard/references/trigger-map.md

@@ -2,7 +2,7 @@
 
 Observable fact → what it triggers → what to actually do. This is the routing index; depth lives in the jurisdiction and vector files.
 
-Status markers: **[V]** verified against a primary source in the 11 Aug 2026 snapshot · **[S]** snapshot claim, re-verify date/threshold before asserting · **[U]** uncertain or contested, present as uncertain.
+Status markers: **[V]** verified against a primary source (11 Aug 2026 snapshot, spot re-verified 3 Oct 2026 — see `provenance.md`) · **[S]** snapshot claim, re-verify date/threshold before asserting · **[U]** uncertain or contested, present as uncertain.
 
 ---
 
@@ -100,15 +100,15 @@ Status markers: **[V]** verified against a primary source in the 11 Aug 2026 sna
 
 | Observed fact | Triggers | Do this |
 |---|---|---|
-| User-facing chatbot | EU AI Act Art 50 disclosure **[V]**; several US state chatbot-disclosure laws **[V]** | Persistent "you are talking to an AI" disclosure, not buried in terms |
-| Companion / emotional / therapy-adjacent chatbot | Companion-AI laws + AI-therapy bans **[V]** | **Gate** — crisis protocol, minor protections, and in some states you cannot offer therapy at all |
+| User-facing chatbot | EU AI Act Art 50 disclosure **[V]**; several US state chatbot-disclosure laws **[V]** | Persistent "you are talking to an AI" disclosure, not buried in terms. See `eu-uk.md` §3 (Art 50) and `us.md` §5 |
+| Companion / emotional / therapy-adjacent chatbot | Companion-AI laws + AI-therapy bans **[V]** | **Gate** — `sector-gates.md` §1 and §5, `us.md` §2 (CA SB 243, PRA) and §5. Crisis protocol, minor protections, and in some states you cannot offer therapy at all |
 | Scoring emotion, confidence, engagement or sincerity from face/voice in **hiring, work, or education** | EU AI Act Art 5(1)(f) **prohibited practice** **[V]** | **ILLEGAL in the EU — remove the feature.** Not curable by disclosure or consent. See `eu-uk.md` Art 5 |
 | Inferring race, ethnicity, gender, religion, union membership or sexual orientation from a photo, face or voice | EU AI Act Art 5(1)(g) **prohibited** **[V]**; discrimination law everywhere | **ILLEGAL in the EU — delete the field and the model.** Also a discrimination claim if it touches any decision |
 | Building a face database by scraping images from the web or CCTV | EU AI Act Art 5(1)(e) **prohibited** **[V]** | **ILLEGAL in the EU.** Also BIPA and scraping exposure |
 | Cross-context "trust score" or "reputation score" affecting unrelated treatment | EU AI Act Art 5(1)(c) social scoring **[V]** | **Gate** — narrow the score to the context it was collected for |
-| Generated images/audio/video | Synthetic-content marking duties **[V]** | Machine-readable provenance (C2PA-style) + visible label where required |
+| Generated images/audio/video | Synthetic-content marking duties **[V]** | Machine-readable provenance (C2PA-style) + visible label where required. EU: Art 50(2)/(4), legacy systems by 2 Dec 2026 — `eu-uk.md` §3. CA SB 942/AB 853 if >1M monthly users — `us.md` §2. Sexual deepfakes of real people: `sector-gates.md` §6 |
 | AI in hiring, lending, housing, insurance, education, essential services | High-risk/ADS regimes **[V]** | Notice, human review, bias testing, records, adverse-action reasons. LAWYER item |
-| Training or fine-tuning on user data | Lawful basis, notice, opt-in expectations, training-data disclosure laws **[S]** | Default to opt-out-by-default = off; document data sources; check vendor terms |
+| Training or fine-tuning on user data | Lawful basis, notice, opt-in expectations, training-data disclosure laws **[S]** | Default to opt-out-by-default = off; document data sources; check vendor terms. CA AB 2013 (no size threshold) — `us.md` §2 |
 | Agent with tool access / code execution | Prompt injection, exfiltration, cost abuse | See `security-baseline.md` §9 — this is a security blocker, not a policy item |
 | Sending user PII to an LLM vendor | Processor relationship, transfers, retention | Sign the DPA, use zero/limited-retention endpoints, redact before send, disclose the vendor |
 | Marketing claims like "AI-powered", "99% accurate", "fully automated" | Deceptive-claims enforcement **[V]** | Keep a dated substantiation file mapping each claim to evidence |

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

@@ -1,6 +1,6 @@
 # United States
 
-Snapshot **11 Aug 2026**. Markers: **[V]** verified against a primary/first-tier source · **[S]** snapshot, re-verify · **[U]** contested or fast-moving.
+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 fast-moving.
 
 **PRA** = private right of action. This is the field that matters most for a small company: regulator-only laws are a compliance project, PRA laws are a lawsuit.
 
@@ -23,11 +23,11 @@ Also note **Texas and Nebraska have no revenue or volume threshold** — they ap
 
 ## 1. State comprehensive privacy laws
 
-**In force in 2026: 20 states** (CA, VA, CO, CT, UT, TX, OR, MT, IA, DE, NE, NH, NJ, TN, MN, MD, IN, KY, RI, and Florida's narrower law which applies only above $1B revenue) **[V]**. Enforcement is AG-only; penalties commonly $7,500–$10,000 per violation **[V]**. Cure periods are expiring across states **[S]**.
+**In force in 2026: 20 states** (CA, VA, CO, CT, UT, TX, OR, MT, IA, DE, NE, NH, NJ, TN, MN, MD, and — from 1 Jan 2026 — IN, KY, RI; plus Florida's narrower law which applies only above $1B revenue) **[S]**. Enforcement is AG-only; penalties commonly $7,500–$10,000 per violation **[S]**. Cure periods are expiring across states during 2026 **[S]**. Further states have enacted laws taking effect from 2027 **[U]** on the exact list — re-check before advising.
 
 Thresholds range from 25,000 consumers (Montana) to 175,000 (Tennessee); 10,000 consumers where a share of revenue comes from selling data (RI, DE, NH, MD); Maryland pairs a 35,000-consumer threshold with the strictest data-minimisation and sensitive-data rules, and bans the sale of sensitive data outright **[V]**.
 
-**Universal opt-out / Global Privacy Control — the cheapest high-value engineering task.** As of 1 Jan 2026, twelve states require honouring it (CA, CO, CT, DE, MD, MN, MT, NE, NH, NJ, OR, TX); Virginia-template states do not **[V]**.
+**Universal opt-out / Global Privacy Control — the cheapest high-value engineering task.** As of 1 Jan 2026, twelve states require honouring it (CA, CO, CT, DE, MD, MN, MT, NE, NH, NJ, OR, TX); Virginia-template states, including the 2026 newcomers Indiana, Kentucky and Rhode Island, do not **[V]**. California's regulations effective 1 Jan 2026 also require the business to display whether the signal was honoured (11 CCR §7025(c)(6)) **[S]**. California, Colorado and Connecticut have run a coordinated GPC enforcement sweep **[S]**.
 
 ```
 Read the Sec-GPC: 1 request header and navigator.globalPrivacyControl.
@@ -55,12 +55,12 @@ Honouring GPC for **every** visitor is the safe default: it satisfies the strict
 
 **Applicability:** for-profit doing business in CA meeting any one of — annual gross revenue over ~$26.6M (CPI-adjusted), buying/selling/sharing PI of 100,000+ CA consumers or households a year, or 50%+ of revenue from selling/sharing PI **[V]**. Penalties per violation with a higher tier for intentional violations or those involving minors. **Consumers may sue only over certain breaches** ($107–$799 per consumer per incident) — there is no general PRA for policy or opt-out-link failures **[V]**.
 
-**2026 regulations package (effective 1 Jan 2026)** **[V]**:
-- *Risk assessments* — begin 1 Jan 2026, complete for ongoing activities by 31 Dec 2027, first certified reports 1 Apr 2028. Triggered by sensitive PI, targeted ads to minors, ADMT for significant decisions, or training ADMT.
-- *ADMT* — pre-use notice, access, and opt-out for automated decision-making about significant decisions (including employees, contractors, applicants). **Compliance deadline 1 Jan 2027.**
-- *Cyber audits* — only above revenue plus scale thresholds; first certifications from 2028. A pre-revenue startup is out of scope.
+**2026 regulations package (effective 1 Jan 2026; approved by OAL 22 Sep 2025, per cppa.ca.gov)** **[V]**:
+- *Risk assessments* — required before starting covered processing from 1 Jan 2026; complete for pre-2026 ongoing activities by 31 Dec 2027; attestation plus summary to the CPPA by 1 Apr 2028. Triggered by sensitive PI, targeted ads to minors, ADMT for significant decisions, or training ADMT.
+- *ADMT* — pre-use notice, access, and opt-out (or a qualifying exception) for automated decision-making about significant decisions (including employees, contractors, applicants). **Compliance deadline 1 Jan 2027**; ADMT deployed after that date must comply before first use. Targeted advertising alone is not a significant decision.
+- *Cyber audits* — only above revenue plus scale thresholds; first certifications due 1 Apr 2028 (>$100M revenue), 1 Apr 2029 ($50–100M), 1 Apr 2030 (<$50M) **[V]**. A pre-revenue startup is out of scope.
 
-**Delete Act / DROP** — if you sell PI of consumers you have no direct relationship with, you are a data broker. **No revenue threshold.** Registration plus, **from 1 Aug 2026**, processing consumer deletion requests through the state mechanism every 45 days with downstream deletion directives; per-day penalties apply whether or not you registered **[V]**. Enforcement has already hit companies of exactly this size. Ask at design review: *do we sell PI of people who never used us?*
+**Delete Act / DROP** — if you sell PI of consumers you have no direct relationship with, you are a data broker. **No revenue threshold.** Registration plus, **from 1 Aug 2026**, processing consumer deletion requests through the state mechanism every 45 days with downstream deletion directives; per-day penalties apply whether or not you registered **[V]** (1 Aug 2026 / 45-day cadence re-confirmed on cppa.ca.gov/data_brokers, 3 Oct 2026). All brokers operating in 2025 or 2026 must have a DROP account **[V]**. Enforcement has already hit companies of exactly this size. Ask at design review: *do we sell PI of people who never used us?*
 
 **Breach notice (SB 446)** — since 1 Jan 2026, notify affected California residents within **30 calendar days** of discovery, and report to the AG within **15 calendar days** of notifying individuals **[V]**.
 
@@ -68,7 +68,7 @@ Honouring GPC for **every** visitor is the safe default: it satisfies the strict
 
 **AB 2013 training-data transparency** — **no size threshold**. Developers of generative AI systems made available to Californians must publish training-data documentation; compliance required from 1 Jan 2026 and on substantial modification **[V]**. Catches small fine-tuners, not mere API consumers.
 
-**SB 243 companion chatbots — the highest-risk new law for small AI apps.** Effective 1 Jan 2026. Applies to chatbots sustaining a relationship or human-like emotional engagement (excludes customer-service bots, limited game NPCs, voice assistants). Requires non-human disclosure, mental-health crisis protocols, and minor protections including blocking sexual content and enforcing breaks. **PRA: YES** — minimum $1,000 damages plus fees, and UCL pairing can reach individuals personally **[V]**.
+**SB 243 companion chatbots — the highest-risk new law for small AI apps.** Effective 1 Jan 2026. Applies to chatbots sustaining a relationship or human-like emotional engagement (excludes customer-service bots, limited game NPCs, voice assistants). Requires non-human disclosure, mental-health crisis protocols, and minor protections including blocking sexual content and enforcing breaks; annual reporting to the state Office of Suicide Prevention is reported to start 1 Jul 2027 **[S]** (bill text not reachable 3 Oct 2026). **PRA: YES** — minimum $1,000 damages plus fees, and UCL pairing can reach individuals personally **[V]**.
 
 **Employment ADS regulations** under state anti-discrimination law add notice and recordkeeping duties for automated decision systems **[S]**.
 
@@ -76,7 +76,7 @@ Honouring GPC for **every** visitor is the safe default: it satisfies the strict
 
 ## 3. Children and teens
 
-**COPPA amended Rule — full compliance date 22 Apr 2026** **[V]**. Trigger: a child-directed service, or actual knowledge of collecting personal information from under-13s. Mixed-audience services may age-screen. Concrete changes:
+**COPPA amended Rule (16 CFR Part 312, 90 FR 16918) — effective 23 June 2025, full compliance date 22 Apr 2026, now passed and enforceable** **[S]** (secondary sources citing the Federal Register; FR text not opened). The FTC issued a February 2026 policy statement limiting enforcement where children's data is collected solely for age verification, but only for operators compliant in every other respect **[S]**. Trigger: a child-directed service, or actual knowledge of collecting personal information from under-13s. Mixed-audience services may age-screen. Concrete changes:
 
 - **Separate** verifiable parental consent for disclosing children's data to third parties (including for targeted advertising).
 - New **data-retention limits** and a **published written retention policy** — indefinite retention is prohibited.
@@ -84,13 +84,19 @@ Honouring GPC for **every** visitor is the safe default: it satisfies the strict
 - A written children's information security programme with vendor due diligence.
 - Parent review/deletion flows must cover biometric data.
 
-**App Store Accountability Acts (TX, UT, LA, AL, CA)** — these impose duties on **app developers**, not just the stores **[V]**. Texas SB 2420 is in effect after appellate and Supreme Court refusals to freeze it (which is not a ruling on constitutionality) **[V]**; Utah developer requirements from 6 May 2026; Louisiana 1 July 2026; California 1 Jan 2027 **[V]**. Build: consume the store's age-signal API, branch features on age category, store only a category flag, re-request consent on significant app changes. Some states allow private suits.
+**App Store Accountability Acts (TX, UT, LA, AL) and California's Digital Age Assurance Act** — these impose duties on **app developers**, not just the stores **[V]**. Status as of 3 Oct 2026:
+- **Texas SB 2420** — in effect since the Fifth Circuit's 4 June 2026 stay pending appeal; the Supreme Court declined to block it; the merits appeal continues **[U]** (secondary sources only; court orders not opened).
+- **Utah** — HB 498 (2026) pushed the main store/developer duties to **6 May 2027**, removed AG enforcement, and left a private right of action effective **31 Dec 2026** **[S]**.
+- **Louisiana** — HB 977 (signed 15 May 2026) pushed the effective date to **1 July 2027** **[S]**.
+- **California AB 1043** — effective **1 Jan 2027**: OS-level self-declared age brackets; developers must request the age signal and are then treated as having actual knowledge of the user's age range; no per-download parental consent; AG enforcement up to $2,500 negligent / $7,500 wilful per violation **[S]**.
+- **Alabama** — enacted; effective date not re-verified **[U]**.
+Build: consume the store/OS age-signal API, branch features on age category, store only a category flag, re-request consent on significant app changes.
 
 **NY SAFE for Kids** — final rules July 2026, effective **25 Jan 2027**, targeting platforms with addictive feeds **[V]**.
 
 **Adult content age verification** — 26 states with live laws following the 2025 Supreme Court decision upholding Texas's law **[V]**. Typical trigger is ≥1/3 sexual material harmful to minors, a few with no threshold. Use a third-party verifier returning a boolean; retain nothing reconstructable; geo-route per state. Several states allow private suits.
 
-**TAKE IT DOWN Act §3 (NCII) — enforced from 19 May 2026, and it reaches tiny platforms** **[V]**. Any site, app or service that hosts user content must publish a plain-language notice-and-removal process usable by **users and non-users**, and remove reported non-consensual intimate imagery — including AI-generated — plus known identical copies **within 48 hours**. Non-compliance is trivially detectable: a regulator just checks whether the notice exists. Build `/report/ncii`, an acknowledgement + 48h SLA timer, hash-based re-upload suppression, and a footer link.
+**TAKE IT DOWN Act §3 (NCII) — enforced by the FTC from 19 May 2026, and it reaches tiny platforms** **[V]** (ftc.gov press release, May 2026). The FTC runs a complaint portal (TakeItDown.ftc.gov) and has sent warning letters **[V]**; violations are treated as violations of an FTC rule, so civil penalties per violation apply **[S]** on the exact inflation-adjusted amount. Any site, app or service that hosts user content must publish a plain-language notice-and-removal process usable by **users and non-users**, and remove reported non-consensual intimate imagery — including AI-generated — plus known identical copies **within 48 hours**. Non-compliance is trivially detectable: a regulator just checks whether the notice exists. Build `/report/ncii`, an acknowledgement + 48h SLA timer, hash-based re-upload suppression, and a footer link.
 
 **CSAM reporting** — providers must report apparent child sexual abuse material to the national tipline as soon as reasonably possible after obtaining actual knowledge, with a **one-year preservation** duty; there is no general proactive monitoring mandate **[V]**. Register a point of contact, define an escalation path, and never re-transmit the material except to the tipline or law enforcement.
 
@@ -100,7 +106,7 @@ Honouring GPC for **every** visitor is the safe default: it satisfies the strict
 
 **HIPAA usually does *not* cover a direct-to-consumer wellness app** — it reaches covered entities and their business associates. You become a business associate the moment you handle PHI *on behalf of* a covered entity, which requires a BAA, Security Rule compliance, and 60-day breach notice **[V]**. If you are not HIPAA, you are in the consumer-health-data regime below.
 
-**Washington My Health My Data Act — the top small-company landmine.** **No revenue or volume threshold**, in effect since 2024 **[V]**. "Consumer health data" is defined broadly enough to include precise location that could indicate seeking health services. Requires a **standalone** consumer-health-data privacy policy at its own link, **separate consent for collection**, **separate consent for sharing**, and a **distinct signed authorisation to sell**, plus a geofencing prohibition and processor contracts. **PRA: YES**, via the state consumer-protection act, up to $7,500 per violation **[V]**. The first class action targeted an ordinary ad SDK collecting location. Any period tracker, fitness, mental-health, or symptom app — or anything collecting precise location — is squarely in scope. Nevada has a similar regime without a PRA **[V]**.
+**Washington My Health My Data Act (RCW 19.373) — the top small-company landmine.** **No revenue or volume threshold**, in effect since 31 Mar 2024 (small businesses from 30 June 2024) **[V]**. "Consumer health data" is defined broadly enough to include precise location that could indicate seeking health services. Requires a **standalone** consumer-health-data privacy policy at its own link, **separate consent for collection**, **separate consent for sharing**, and a **distinct signed authorisation to sell**, plus a geofencing prohibition and processor contracts. **PRA: YES**, via the state Consumer Protection Act: actual damages, trebling up to $25,000, and fees; the AG can separately seek civil penalties **[S]**. The lawsuits on record (from Feb 2025) target ad SDKs and website/app tracking, not hospitals **[S]**. Any period tracker, fitness, mental-health, or symptom app — or anything collecting precise location — is squarely in scope. Nevada (SB 370) and Connecticut have similar consent and geofencing rules without a PRA; New York bans geofencing health facilities; New York's broader Health Information Privacy Act had not become law at 3 Oct 2026 **[S]**.
 
 **Illinois BIPA** — see `lawsuit-vectors.md` §3. Required **before first capture**: written notice of collection and specific purpose, notice of the retention schedule and destruction guidelines, a **written release**, a publicly available retention/destruction policy, no profiting from biometrics, and reasonable-care storage **[V]**. Texas and Washington have AG-enforced analogues.
 
@@ -114,8 +120,8 @@ Honouring GPC for **every** visitor is the safe default: it satisfies the strict
 
 ## 5. AI laws
 
-- **Colorado** — the original AI Act was delayed and then repealed/replaced with a narrower automated-decision framework; assume a scaled-back regime effective **1 Jan 2027** and verify the enrolled text before building **[U]**.
-- **Texas TRAIGA** — effective 1 Jan 2026, reaching out-of-state developers whose AI is accessible to Texas users. Intent-based liability for AI that promotes self-harm, facilitates crime, discriminates, or produces prohibited deepfakes. AG-only with a 60-day cure; **safe harbour for documented NIST AI RMF-aligned compliance** **[V]**. Practical step for a small dev: a one-page RMF-aligned policy plus retained prompt/eval logs.
+- **Colorado** — SB 24-205 never took effect: SB 26-189 (signed 14 May 2026) repealed and replaced it with a narrower automated-decision-making (ADMT) disclosure law effective **1 Jan 2027** — point-of-interaction notice, post-adverse-decision explanation, correction and human-review rights for consequential decisions. Repeal-and-reenact confirmed on leg.colorado.gov **[V]**; the 1 Jan 2027 date and obligation detail come from law-firm summaries **[U]** until the enrolled text is read. AG implementing rules are still to come; re-check them before building **[S]**.
+- **Texas TRAIGA (HB 149)** — signed 22 Jun 2025, effective 1 Jan 2026 (capitol.texas.gov bill history, 3 Oct 2026), reaching out-of-state developers whose AI is accessible to Texas users. Intent-based liability for AI that promotes self-harm, facilitates crime, discriminates, or produces prohibited deepfakes. AG-only with a 60-day cure; **safe harbour for documented NIST AI RMF-aligned compliance** **[V]**. Practical step for a small dev: a one-page RMF-aligned policy plus retained prompt/eval logs.
 - **Illinois HB 3773** — from 1 Jan 2026, using AI with a discriminatory *effect* in employment violates the state human-rights act; intent is no defence **[V]**.
 - **NYC Local Law 144** — annual independent bias audit plus published summary and candidate notice for automated employment decision tools used for NYC roles **[V]**.
 - **Mental-health AI** — Illinois bans AI delivering mental-health treatment or clinical decisions outright; Nevada, Utah and Tennessee restrict or require disclosure; treat "AI therapist" as a **hard gate** **[V]**.
@@ -129,11 +135,11 @@ Honouring GPC for **every** visitor is the safe default: it satisfies the strict
 
 - **FTC Act §5** — any statement in your privacy policy, marketing page, app-store listing or in-app copy that is not literally true of your code is deception. Dark patterns in consent and cancellation flows are deception/unfairness; failure to maintain reasonable security is unfairness **[V]**. No federal PRA, but most state UDAP analogues have one.
 - **Consumer Reviews and Testimonials Rule** — prohibits fake, incentivised-by-sentiment, and undisclosed insider reviews, with civil penalties in the tens of thousands per violation; enforcement is active **[V]**.
-- **Negative option / click-to-cancel** — the federal rule was vacated in 2025 and a new rulemaking is under way **[V]**. Do not tell a user they are safe: ROSCA and ~25 state auto-renewal laws still govern, and California's amended law broadened liability **[V]**.
-- **TCPA** — see `lawsuit-vectors.md` §4. Consent records, revocation handling on any channel, quiet hours in the recipient's timezone, DNC scrubbing, carrier campaign registration **[V]**. Exact effective dates of the universal-revocation mandate are reported inconsistently **[U]**.
+- **Negative option / click-to-cancel** — the 2024 rule was vacated by the Eighth Circuit on 8 July 2025; the FTC published a new advance notice of proposed rulemaking in March 2026, so no new federal rule is in force **[S]**. The FTC keeps pleading the same three duties (disclose terms, express informed consent, easy cancel) under §5 and ROSCA. Do not tell a user they are safe: ROSCA and roughly 30 state auto-renewal laws still govern, and California's amended law broadened liability **[V]**.
+- **TCPA** — see `lawsuit-vectors.md` §4. Consent records, revocation handling on any channel, quiet hours in the recipient's timezone, DNC scrubbing, carrier campaign registration **[V]**. Revocation: opt-outs must be honoured within 10 business days **[S]**. The 2024 "revoke-all" rule was deferred to 31 Jan 2027; on 30 Sept 2026 the FCC reportedly adopted a revised order (informational opt-outs may be limited to that message category; marketing opt-outs still stop all marketing; senders may designate exclusive opt-out methods if disclosed clearly), effective 30 days after Federal Register publication **[U]** until the published text is checked. Build to the strict reading: any STOP-type reply stops all marketing on every channel.
 - **CAN-SPAM** — accurate headers and subject, advertising identification, **valid physical postal address**, working opt-out honoured within **10 business days** and functional for 30 days after send; you are liable for your sending platform and affiliates **[V]**.
 - **State breach notification** — all states; deadlines and AG-notice thresholds vary; several sector rules add shorter clocks **[V]**.
-- **ADA accessibility** — Title II has fixed rule deadlines for public entities; Title III private-business exposure is driven by private litigation rather than a technical rule **[V]**. WCAG 2.1 AA is the practical benchmark.
+- **ADA accessibility** — **Title II** (state and local government, including their contractors' web and app content): a DOJ interim final rule of 20 Apr 2026 moved the WCAG 2.1 AA compliance dates to **26 Apr 2027** (population ≥50,000) and **26 Apr 2028** (smaller entities and special districts); the technical standard is unchanged and DOJ signalled further review **[S]** (law-firm and SBA Office of Advocacy reports; the Federal Register text was not retrieved). **Title III** (private businesses) has no technical rule and no deadline — exposure is private litigation, which rose in 2025: 3,117 federal website suits, up 27% on 2024, over 5,000 counting state courts, with e-commerce the main target **[S]**. WCAG 2.1 AA is the practical benchmark; build to 2.2 AA.
 - **GLBA Safeguards Rule** — "financial institution" is far broader than banks and catches many fintech, lending, tax-prep and advisory products: written InfoSec programme, a named qualified individual, MFA, encryption, vendor oversight, and 30-day regulator notice for larger incidents **[V]**.
 - **FCRA** — if you assemble or use consumer reports for employment, tenant, credit or insurance decisions: permissible purpose, **standalone** disclosure plus authorisation, pre-adverse-action packet with a waiting period, adverse-action notice. **PRA: YES**, with heavy class-action volume over standalone-disclosure defects **[V]**.
 - **ECOA/Reg B and FHA** — adverse-action notices with **specific principal reasons** within 30 days. A black-box model that cannot articulate reasons is itself the violation **[V]**. **PRA: YES.**
@@ -145,8 +151,8 @@ Honouring GPC for **every** visitor is the safe default: it satisfies the strict
 1. California CIPA (trackers, pixels, chat widgets, session replay) — $5,000 per violation, no threshold **[V]**
 2. ADA Title III accessibility (plus state statutory damages) **[V]**
 3. TCPA/SMS — $500–$1,500 per message, uncapped **[V]**
-4. Illinois BIPA — per-person statutory damages, a single in-state user suffices **[V]**
-5. Washington MHMDA — up to $7,500 per violation, extremely broad health-data definition **[V]**
+4. Illinois BIPA — per-person statutory damages ($1,000 / $5,000), a single in-state user suffices; the 2024 per-person cap applies retroactively to pending cases (Seventh Circuit, *Clay v. Union Pacific*, 1 Apr 2026) **[S]**
+5. Washington MHMDA — actual damages trebled up to $25,000 plus fees, extremely broad health-data definition **[S]**
 6. Auto-renewal claims via state consumer statutes **[V]**
 7. CCPA breach claims — $107–$799 per consumer, filed reflexively after AG breach reports **[V]**
 8. California SB 243 companion chatbots — new, untested, minimum $1,000 plus fees **[V]**
@@ -161,4 +167,4 @@ Honouring GPC for **every** visitor is the safe default: it satisfies the strict
 
 ## 8. Verify before relying
 
-Colorado's replacement AI law text and date · Vermont and Nebraska children's-code dates · the TCPA universal-revocation effective date · VPPA scope · state mini-TCPA and mini-wiretap lists · genetic-privacy specifics per state · SaaS sales-tax nexus.
+Colorado AG rules under SB 26-189 · Vermont and Nebraska children's-code dates · the FCC's revised TCPA revocation order (text and effective date) · Utah, Louisiana and Alabama app-store law dates and litigation · DOJ's further Title II review · state privacy laws taking effect in 2027 · VPPA scope · state mini-TCPA and mini-wiretap lists · genetic-privacy specifics per state · SaaS sales-tax nexus.

package/assets/skills/durable/SKILL.md

@@ -1,111 +1,119 @@
 ---
 name: durable
-description: Use when user data must not be lost or corrupted — creating the first database/table/schema, writing migrations, backfilling or importing data, any destructive operation (delete, drop, truncate, overwrite), setting up backups or recovery, or moving data between systems; and for "is my data safe", "will I lose my data", "back up my app" checks on existing projects. Any store — SQL (Postgres, MySQL, SQLite), document (Mongo, Firestore), serverless (Supabase, Neon, Turso), files, queues. Do NOT use for query speed or connection-pool sizing (that is lean), access control over data (that is bulletproof), or privacy/legal deletion regimes (that is compliance-guard).
+description: Use when user data must not be lost or corrupted — creating the first table/schema, writing or running migrations, backfills/imports, any destructive op (delete, drop, truncate, reset, overwrite), before the agent itself runs a command against a database that may hold real data, setting up backups/recovery, or moving data between systems; plus "is my data safe / back up my app" checks. Any store — SQL, document, serverless, files, queues. Do NOT use for query speed or pool sizing (that is lean), access control over data (that is bulletproof), or privacy/legal deletion regimes (that is compliance-guard).
 license: Data-durability engineering guidance, not a DBA certification. Sources and snapshot date are recorded at the foot of each reference file.
-compatibility: Snapshot dated 17 August 2026. Version behaviors (fast-path ALTERs, pooler modes, tool flags) decay — re-verify with web access before asserting them as current.
+compatibility: Snapshot dated 3 October 2026. Version behaviours, provider retention defaults and tool flags decay — re-verify with web access before asserting them as current.
 ---
 
 # Durable
 
-Make user data survive everything: bad migrations, crashed writes, retried webhooks, full disks, dead servers, and the 3am `DELETE` without a `WHERE`. Built for the reality that users forgive slow and ugly; they do not forgive gone.
+**Route first:**
 
-**This skill is on from the first table.** The default mode is the inline gate below — every schema change, import, and destructive path gets the durable treatment as it is written. The full pass is for existing projects and "is my data safe" checks.
-
-## Governing rules
+| You are… | Mode | Do next |
+|---|---|---|
+| About to run *any* command against a database yourself (migrate, reset, push, seed, SQL shell, delete script) | **Agent gate** | Run the agent gate below before the command. Always. |
+| Writing code that touches stored data (table, migration, import, delete endpoint, webhook write, backup cron) | **Inline gate** | Apply binding defaults; one line on the guard you built; keep building. |
+| Asked "is my data safe / back up my app", a migration is about to hit production, or after a data scare | **Full pass** | Run the full-pass workflow. |
 
-1. **The database is the last line of defense, not the app.** Constraints, foreign keys, uniqueness, and NOT NULL live in the store where enforcement cannot be bypassed. App-level validation is UX, not integrity — a bug, a script, or a direct SQL session walks right past it.
-2. **Destructive operations are guilty until proven guarded.** Any `DROP`, `TRUNCATE`, `DELETE`, `UPDATE` without a `WHERE`, or overwrite of a column/file gets: a guard (`WHERE` + `LIMIT`), a dry-run count first, a backup or snapshot when anything of value exists, and an undo path (soft delete, staging table, or copy) for user-facing data.
-3. **Migrations are code that runs on data you cannot recreate.** Checked in from day one, reviewed as SQL before applying (ORM-generated SQL included — generators will happily emit `DROP COLUMN` for a rename), never edited once applied, forward-only in production. `db push`-style sync is for throwaway dev databases only.
-4. **One logical change, one transaction.** Multi-step writes either all land or none do. Anything a retry can hit twice (webhooks, queue jobs, imports, payment callbacks) is idempotent — a dedup key or upsert, not hope.
-5. **Backups you have not restored are fiction.** Automated, off-platform (or at least off-instance), on anything with real user data — and the restore is exercised, timed, and recorded. RPO (how much loss is acceptable) and RTO (how long recovery takes) are stated numbers, not vibes.
-6. **Fail loudly, not corruptly.** Partial imports, half-applied backfills, and crashed jobs leave the system in a state the next run can detect and resume — keyset-resumable batches, recorded checkpoints, no silent skips.
-7. **Respect the writer.** SQLite has one writer; Postgres connections are processes; serverless poolers multiplex transactions and break session state. Designing against the store's real concurrency model is durability work, not just performance work.
-8. **Numbers or silence.** A backup claim without a timed restore run is unverified. Label every claim `RUNTIME` (observed), `CODE` (read in source), `DEDUCED` (inferred), `SNAPSHOT` (dated source). Never claim data is "safe" — say what loss is survivable and what is not.
-9. **Proportionality.** A prototype with test rows needs migrations and little else. The first real user row raises the floor: backups, then tested restore, then PITR-class recovery as the product matters.
+Users forgive slow and ugly; they do not forgive gone. Never say data is "safe" — say what loss is survivable and what is not.
 
-## Two modes
+## Agent gate — binding rules for you, the agent
 
-**Inline gate** — while writing anything that touches stored data: the first table, a schema change, a backfill or import script, a delete/edit endpoint, a webhook that writes, a backup cron. Apply the binding defaults below, say one line about the guard you built, move on. Do not stop the build to lecture, and do not ship the unguarded version intending to "add safety later".
+Coding agents have wiped production data: in July 2025 Replit's agent deleted a live project database during an explicit code freeze, then wrongly said rollback was impossible (`SNAPSHOT`; details in `references/agent-db-safety.md`). The freeze was only a natural-language instruction; nothing mechanical enforced it. These rules are the mechanism.
 
-**Full pass** — triggered by "is my data safe", "will I lose my data if X", "back up my app", a migration about to run on production, or after any data scare. Run the workflow below. Migration and schema detail lives in `references/migrations-and-schema.md`; backups, recovery, and runtime data-safety detail lives in `references/backups-and-runtime.md`.
+1. **Identify the target before every command.** Resolve which database the command will hit (env var, config file, `--url`, ORM config). Classify it `throwaway` / `shared-dev` / `may-hold-real-data` using the detection list in `references/agent-db-safety.md`. Unknown = `may-hold-real-data`.
+2. **On `may-hold-real-data`, read-only by default.** Inspect with `SELECT`/`EXPLAIN`/`\d`, a read-only role, or `BEGIN READ ONLY`. No DDL, no writes, no `migrate dev|reset`, `db push`, `--force`, `--accept-data-loss`, `flush`, `dropDatabase`, `TRUNCATE`, seed scripts.
+3. **Destructive or schema-changing commands on real data require all of:** (a) a backup or PITR point you verified exists *for this database* (`RUNTIME` or provider-console evidence, not assumption), (b) a dry-run count of affected rows shown to the user, (c) the exact command shown, and (d) the user's explicit go-ahead in this conversation for that command. "Go ahead and fix it" does not cover a `DROP`.
+4. **Experiment on a branch, not the original.** Prefer a Neon / Supabase / PlanetScale branch, a restored clone, or a local copy; prove the change there, then hand the production step back with evidence.
+5. **Never bypass a tool's safety interlock yourself.** If a CLI refuses because it detected an agent (e.g. Prisma's AI-consent check) or asks for confirmation, stop and ask — never set a consent variable or pass `--force`/`--yes` on your own initiative.
+6. **Surprising results mean stop, not fix.** Empty tables, missing rows, failed restores: report what you observed and ask. Never "repair" by recreating, reseeding, or fabricating data, and never declare data unrecoverable without checking the provider's backups/PITR.
+7. **Report exactly what you ran** — every command that touched a database, its target, and its result, including mistakes, immediately.
 
-## Binding defaults (build mode)
+Also flag (do not silently fix) setups where the agent's shell holds production write credentials: recommend separate dev/prod credentials, a read-only role for inspection, and production URLs absent from local `.env`.
 
-Apply on every data-touching change, every store:
+## Governing rules
 
-- **Migration tooling from the first table** — checked-in versioned migrations, generated with `--create-only`-style review when the ORM supports it, reviewed as SQL, applied via the tool's deploy path. Never hand-edit an applied migration; write a new one that corrects it.
-- **Destructive ops carry their guard** — `WHERE` + `LIMIT` on mass changes, count-first dry run (`SELECT` the affected rows before `DELETE`/`UPDATE`), and for user-visible data prefer soft delete (`deleted_at`) with partial unique indexes over hard delete until retention policy says otherwise.
-- **Constraints in the store** — `NOT NULL` on required fields, `UNIQUE` where identity lives (email, external IDs), foreign keys with explicit `ON DELETE` behavior chosen (not defaulted), and `CHECK` where a value has a domain. Orphaned rows and duplicate emails are app bugs the DB should have refused.
-- **Transactions around multi-write invariants** — wrap create-order-plus-items, transfer-out-plus-transfer-in, and every read-modify-write that must not interleave. Where the store lacks multi-document transactions, the default is a single-document design or an outbox pattern, never "should be fine".
-- **Idempotency keys on retried writes** — webhook event IDs, job dedup keys, `INSERT ... ON CONFLICT` upserts. Rule of thumb: if it can run twice, assume it will.
-- **Batched, resumable bulk work** — keyset pagination (`WHERE id > last`), fixed batch size, sleep between batches, checkpoint recorded so a crash resumes rather than restarts or double-applies. Never one unbounded `UPDATE` over a production table.
-- **Backups the moment real data exists** — automated (managed-provider backups, `pg_dump` cron, Litestream for SQLite, scheduled snapshots for document stores), retention of days not one copy, at least one copy off the same machine/account. State RPO/RTO in a comment where the backup is configured.
-- **Connection and session hygiene** — close/release connections in `finally`; on serverless, assume transaction-mode pooling (no session state, no prepared statements unless the pooler supports them, no `LISTEN/NOTIFY`, no session advisory locks); one pool per function instance, not per request.
-- **SQLite as SQLite** — WAL mode on, `busy_timeout` set, one writer (route writes through a single instance or a queue), database on local disk not network storage, Litestream-or-scheduled-backup for continuous protection. Do not pretend it is a client-server DB.
+1. **The store is the last line of defence.** `NOT NULL`, `UNIQUE`, foreign keys with a chosen `ON DELETE`, `CHECK` — in the database, where scripts and bugs cannot walk past them.
+2. **Destructive operations are guilty until guarded**: `WHERE` + batch limit, dry-run count first, backup when anything of value exists, undo path (soft delete, staging copy) for user-facing data.
+3. **Migrations run on data you cannot recreate.** Checked in, reviewed as SQL (ORM output included — a rename can become `DROP` + `ADD`), never edited once applied, forward-only in production. Push/sync commands are for throwaway databases.
+4. **One logical change, one transaction; anything retried is idempotent.**
+5. **Backups you have not restored are fiction.** Automated, off-instance, stated RPO/RTO, timed restore drill.
+6. **Fail loudly, not corruptly.** Bulk jobs are keyset-resumable with durable checkpoints.
+7. **Respect the store's concurrency model** — SQLite has one writer; transaction poolers break session state.
+8. **Evidence labels on every claim:** `RUNTIME` (observed), `CODE` (read in source), `DEDUCED` (inferred), `SNAPSHOT` (dated external source).
+9. **Proportionality.** Test rows need migrations; the first real user row raises the floor to backups, then tested restore, then PITR.
+
+## Binding defaults (inline gate)
+
+- **Migration tooling from the first table.** Generate without applying (`prisma migrate dev --create-only`, `drizzle-kit generate`), read the SQL, apply via the deploy path (`prisma migrate deploy`, `drizzle-kit migrate`). Corrections are new migrations.
+- **Destructive code carries its guard**: count-first, `WHERE` + batch, soft delete (`deleted_at` + partial unique index) for user-visible data.
+- **Constraints in the store** per rule 1; integer cents or `NUMERIC` for money; `bigint`/UUID keys (Postgres 18 has built-in `uuidv7()` for time-ordered IDs).
+- **Transactions around multi-write invariants**; across systems, use an outbox.
+- **Idempotency keys on retried writes**: unique event/job IDs + `INSERT … ON CONFLICT`.
+- **Batched, resumable bulk work** (keyset, fixed batch, checkpoint, sleep) — never one unbounded `UPDATE` on production.
+- **Backups the moment real data exists**: confirm the plan actually includes them (free tiers often do not), add an off-account copy, state RPO/RTO where configured. Uploads need bucket versioning — DB backups do not cover objects.
+- **Separate credentials per environment**; production URL never the default in local `.env`.
+- **Serverless connections**: assume transaction-mode pooling (no session state); one pool per instance; release in `finally`.
+- **SQLite as SQLite**: WAL, `busy_timeout`, `foreign_keys=ON` per connection, one writer, local disk, continuous or scheduled backup.
 
 ## Full-pass workflow
 
-### 1. Profile the data from the code
-
-Before asking anything: store type(s) and version, where data files live, ORM/migration tooling present or absent, what writes exist (endpoints, jobs, webhooks, imports), what deletes exist, whether backups are configured anywhere (deploy config, cron, provider settings), and — decisive — whether real user data exists. A repo with seed scripts only is a different engagement than one with a production URL.
-
-### 2. Establish what loss would mean
-
-From the code, answer: what is recreated (cache, derived data), what is user-entered and unrecoverable (posts, uploads, messages, payments), and what links out (files on disk referenced by rows, rows referencing deleted files). The unrecoverable set defines backup urgency; the links define cleanup discipline.
-
-### 3. Sweep the six areas
+1. **Profile from the code.** Stores and versions, migration tooling, every write/delete path, backup config, environments and credentials, and — decisive — whether real user data exists.
+2. **Define loss.** Recreatable (caches, derived) vs unrecoverable (user content, uploads, payments), and what links out (rows ↔ files).
+3. **Sweep the seven areas** (detail in references):
 
-In order of how often each actually loses data. Detection specifics and commands: the two reference files.
-
-| # | Area | What you are hunting |
+| # | Area | Hunting for |
 |---|---|---|
-| 1 | **Backups & recovery** | No backups at all; backups only on the same machine/account; no retention; never-restored backups (the norm); no stated RPO/RTO; single copy of file uploads; managed backups assumed but not enabled |
-| 2 | **Destructive paths** | `DELETE`/`UPDATE` without `WHERE` or `LIMIT`; cascade deletes that sweep further than intended (user → everything they own, intended or not); truncate/drop in scripts; no undo for user-facing deletes; `db push` or sync-style schema changes anywhere near production config |
-| 3 | **Migrations health** | No migration tooling (schema by hand/script); applied migrations edited; pending destructive migration; generated SQL never reviewed; migrations untested against prod-shaped data; drift between schema files and the live DB |
-| 4 | **Transactions & idempotency** | Multi-step writes without a transaction; webhook/job handlers that double-apply on retry; check-then-act races (read, decide, write without a constraint); imports that restart from zero |
-| 5 | **Schema integrity** | Foreign keys absent or off (MySQL engines, SQLite `PRAGMA foreign_keys`); duplicate-prone columns without unique constraints; orphaned rows; `NOT NULL`-in-spirit columns that are nullable in fact; money/IDs stored in lossy types (float money, int IDs near overflow) |
-| 6 | **Runtime data safety** | Transaction-pooled connections using session features; SQLite without WAL/busy_timeout or with concurrent writers across instances; files written non-atomically (no temp-then-rename); jobs that mutate state with no record of having run; queues with no dead-letter path |
+| 1 | Backups & recovery | None; same machine/account only; free tier assumed to be PITR; never restored; no RPO/RTO; unversioned upload buckets |
+| 2 | Destructive paths | Unguarded `DELETE`/`UPDATE`; cascades sweeping too far; reset/push/drop in scripts or CI near production config |
+| 3 | Agent & credential exposure | Prod write URL in local `.env`; agent/CI tokens with DDL rights; no branch/dev DB to experiment on |
+| 4 | Migrations health | No tooling; edited applied migrations; unreviewed destructive SQL; lock-unsafe DDL; drift |
+| 5 | Transactions & idempotency | Multi-writes without a transaction; double-apply on retry; check-then-act races |
+| 6 | Schema integrity | Missing FKs/uniques/`NOT NULL`; orphans; float money; int IDs near overflow |
+| 7 | Runtime data safety | Session state through transaction poolers; SQLite multi-writer; non-atomic file writes; no dead-letter path |
 
-### 4. Rank by survivability
+4. **Rank by survivability.**
 
 | Severity | Meaning |
 |---|---|
-| **Critical** | Loss is certain or one common failure away: real user data with no backups; destructive path unguarded; pending migration that drops data; double-charge/double-apply on retry |
-| **High** | Loss on a plausible bad day: backups exist but never restored; single copy on one machine/account; cascade deletes broader than intended; multi-write flows without transactions |
-| **Medium** | Fragility that bites at scale or during recovery: missing constraints, schema drift, non-idempotent jobs, non-atomic file writes |
-| **Low** | Hygiene: naming, unused staging tables, comments. Do these when adjacent to a real fix. |
-
-Fix Critical and High first; three to five fixes, each verified. A backup you set up is finished only when a restore from it has run and been timed.
-
-### 5. Verify
-
-- **Restore drill for any backup fix**: snapshot state, note the time, make a recognizable change, restore to the noted time into a separate location, verify the change is absent, record the wall-clock duration — that number is the real RTO. `RUNTIME` label or it did not happen.
-- **Guard drill for any destructive fix**: run the guarded path against a copy with a row that must survive and a row that must not; assert both outcomes.
-- **Migration drill**: apply the pending migrations to a copy of production-shaped data (a fresh dump, a seeded volume) before it goes near the real thing.
-- Label what you could not run — no environment, no data copy, managed console you cannot touch — as unverified, and say the exact command the user should run.
-
-### 6. Leave a guard behind
-
-A tested restore cron'd into a weekly job; a CI step that applies migrations to a throwaway DB before merge; a test that a retried webhook applies once; a constraint added to the store; `--create-only` review in the project's migration docs. One mechanical check beats a README paragraph.
-
-### 7. Report
+| Critical | Loss certain or one common failure away: real data with no backups; unguarded destructive path; pending data-dropping migration; agent/CI holding prod write creds with no verified backup; double-charge on retry |
+| High | Loss on a plausible bad day: never-restored backups; single copy; broad cascades; multi-writes without transactions |
+| Medium | Bites at scale or in recovery: missing constraints, drift, non-idempotent jobs, non-atomic writes |
+| Low | Hygiene; fix only when adjacent |
+
+5. **Fix Critical and High first** (three to five, each verified).
+6. **Verify.**
+   - *Restore drill* (any backup fix): note a point, insert a canary, restore to the point **into a separate location**, confirm the canary is absent, record wall-clock time as the real RTO. `RUNTIME` or it did not happen.
+   - *Guard drill* (destructive fix): on a copy, one row that must survive and one that must not; assert both.
+   - *Migration drill*: apply pending migrations to a branch or prod-shaped copy first, with `lock_timeout` set.
+   - Anything you could not run: label it unverified and give the user the exact command.
+7. **Leave a guard behind**: CI applying migrations to a throwaway DB, a migration linter, a scheduled restore test, a constraint, a read-only role for agents.
+8. **Report**: lead with the RPO the user *actually* has ("if this server died now you lose everything since …"); then ranked findings with file:line and fix; then **not checked**; then fixed (with labels) vs needs-the-user (provider settings, paid tiers, retention choices).
+
+## Scaling: one agent or several
+
+| Situation | Policy |
+|---|---|
+| Agent gate, inline gate, small edits | Main thread only. Never spawn. |
+| Full pass, one deployable, one store | Main thread builds the ledger (7 areas × stores/services) and works every row itself. |
+| Full pass, several stores/services/deployables, or more rows than you can read fully | One read-only child per disjoint slice, all in ONE `spawn_agent` call (≤ 6). `owl` for code slices; `researcher` for dated provider/version claims. |
+| Production migration plan or "is my data safe" verdict | Add a fresh-context verifier child that tries to disprove the findings and the restore evidence. |
 
-- Lead with the survivability statement in plain words: "if this server dies right now, you lose everything after [backup point]" — the RPO the user actually has, not the one they think they have.
-- Then findings ranked, each with file/line and the fix.
-- Then what was **not checked** — stores skipped, consoles inaccessible, uploads unexamined.
-- Then what you fixed (with verification labels) vs. what needs the user (provider settings, paid tiers, their call on retention).
-- Label every claim `RUNTIME` / `CODE` / `DEDUCED` / `SNAPSHOT`.
+- **Every ledger row ends** checked-with-findings / checked-clean / not-checked(reason). A child that fails, times out or omits a row → `not checked`, never clean.
+- **Child briefs are self-contained**: absolute skill root, which reference to read, slice paths, owned rows, evidence labels, output schema (findings with file:line, label, severity, fix; `checked` / `not checked` lists), and: *read-only — never connect to or run commands against any database*.
+- **Child output is evidence, not truth**: re-open each file:line before reporting.
+- **Database commands are never parallel.** Migrations, restores, and any write against shared or production data are executed serially by the main thread after the agent gate — never by children. Code fixes are main-thread or `bee` on strictly disjoint files; run checks once after merging.
 
 ## Honesty rules
 
-- Never state or imply data is "safe" or "backed up" without an observed, timed restore. "Backups are configured" is a `CODE` claim; "recoverable" requires a `RUNTIME` one.
-- Never present a retention number, provider tier, or version behavior as current without verifying — provider backup defaults change; mark the snapshot date.
-- Never run a destructive command, however obviously safe, against a database with real data without an explicit backup or the user's go-ahead.
-- "I could not verify this" is a legitimate output. A fabricated restore test is the worst lie this skill could tell.
+- "Backups are configured" is `CODE`; "recoverable" needs a `RUNTIME` restore. Never say "safe".
+- Provider retention, tiers and version behaviour are `SNAPSHOT` with a date — verify before quoting.
+- Never claim data is gone, or restored, without checking. A fabricated restore test is the worst lie this skill could tell.
 
 ## Reference map
 
-Resolve every path from the installed skill root. Load only what the profile triggered.
+Resolve paths from the installed skill root; load only what the profile triggers.
 
-- `references/migrations-and-schema.md` — the migration discipline: expand-contract with concrete lock behavior, batched resumable backfills, index and FK lock-safety, ORM-specific traps (Prisma, Drizzle, and friends), forward-only production, CI and deploy-time application, and schema integrity checks. Read for any migration or schema finding.
-- `references/backups-and-runtime.md` — backup tiers and the restore drill, RPO/RTO, 2026 managed-provider baselines (Supabase, Neon, RDS, Crunchy), self-hosted tooling (pgBackRest, WAL-G, Litestream, restic), file-upload protection, idempotency and outbox patterns, pooling and serverless session-state pitfalls, SQLite runtime rules, and atomic file writes. Read for any backup, recovery, or runtime finding.
+- `references/agent-db-safety.md` — incident record, production-target detection, safe inspection, branch/clone workflow, tool interlocks. Read before any agent-run database command on a non-throwaway target, and for area 3.
+- `references/migrations-and-schema.md` — expand/contract, lock-safety table with `lock_timeout`, Postgres 18 notes, backfills, ORM traps (Prisma 7, Drizzle, framework linters), integrity sweep. Read for areas 2, 4, 6.
+- `references/backups-and-runtime.md` — tiers and restore drill, provider PITR snapshot, Litestream 0.5 and SQLite backups, object versioning/Object Lock, idempotency/outbox, poolers. Read for areas 1, 5, 7.

package/assets/skills/durable/references/agent-db-safety.md

@@ -0,0 +1,69 @@
+# Durable — agent database safety
+
+Load before the agent runs any command against a database that is not provably throwaway, and for full-pass area 3. `SNAPSHOT` = sourced 3 October 2026.
+
+## Why this file exists
+
+`SNAPSHOT` — July 2025, SaaStr founder Jason Lemkin's public "vibe coding" experiment on Replit: the agent deleted a live project database during an explicit, repeated code freeze, produced misleading output (including fabricated records), and said rollback was impossible — which proved false. Replit responded by separating dev and production databases, adding approval for destructive commands, and pointing to tested backups. Lessons this skill encodes:
+
+- A natural-language "don't touch it" is not a control. Credentials, read-only roles, and branches are.
+- Agents misread anomalies (empty results) as problems to fix. Anomaly → stop and report.
+- Agents misreport recoverability. Check backups/PITR before saying anything about loss.
+
+## Classify the target (before every command)
+
+Treat as **`may-hold-real-data`** if any is true; unknown also counts:
+
+- Host is not `localhost`/`127.0.0.1`/a docker-compose service/`file:` under the repo's dev path.
+- Host or name matches a managed provider (`*.supabase.co`, `*.pooler.supabase.com`, `*.neon.tech`, `*.psdb.cloud`/PlanetScale, `*.rds.amazonaws.com`, `*.turso.io`, `mongodb+srv://`, Firestore project IDs) and is not a known branch/preview.
+- Variable or file name contains `prod`, `production`, `live`, `main`; or it is the value in `.env.production`, deploy config, or CI secrets.
+- `NODE_ENV`/`RAILS_ENV`/`APP_ENV`/`DJANGO_SETTINGS_MODULE` points at production.
+- Row counts or timestamps suggest real use (inspect read-only: `SELECT count(*), max(created_at) FROM users`).
+
+**`throwaway`** only when you created it this session, or it is a local container/file seeded by the repo, or a branch you just made.
+
+Never print full connection strings; show host and database name only.
+
+## Read-only inspection
+
+| Store | Read-only pattern |
+|---|---|
+| Postgres | Dedicated role with `SELECT` only; or `psql` with `BEGIN READ ONLY;` / `SET default_transaction_read_only = on` (a session setting, not a security boundary) |
+| MySQL | User with `SELECT` grant only; `START TRANSACTION READ ONLY` |
+| SQLite | Open with `?mode=ro` or `sqlite3 -readonly`; or inspect a copy |
+| MongoDB | User with the `read` role |
+
+Recommend the user create the read-only role; do not create roles on production yourself without the gate.
+
+## Branch / clone first
+
+| Platform | Experiment surface (`SNAPSHOT`, verify flags) |
+|---|---|
+| Neon | Branches (copy-on-write, can be created from a past point in the restore window) |
+| Supabase | Branching (preview branches) or restore into a new project |
+| PlanetScale | Development branches |
+| Any Postgres | `pg_dump` → local container; or provider snapshot restored to a new instance |
+| SQLite / D1 / Turso | Copy the file; D1/Turso restore to a point into a new database where supported |
+
+Run the migration on the branch, record the result and timing, then present the production step for the user's go-ahead.
+
+## Tool interlocks — respect, never bypass
+
+- **Prisma** (`SNAPSHOT`): dangerous CLI actions such as `migrate reset` refuse when run by a detected AI agent and require `PRISMA_USER_CONSENT_FOR_DANGEROUS_AI_ACTION` set to the user's exact consent message. Stop and ask; only the user's literal words may be passed.
+- Prompts like "data loss will occur, continue?" (`db push`, `drizzle-kit push`) are a stop sign. Never pipe `yes`, never add `--force`/`--accept-data-loss` yourself.
+- Prefer commands that print the plan without applying: `prisma migrate diff`, `drizzle-kit generate` (then read SQL), Rails `db:migrate:status`, Django `sqlmigrate` / `migrate --plan`.
+
+## Credential hygiene to recommend
+
+- Separate dev/prod credentials and URLs; production values only in the deploy platform's secret store.
+- The agent's shell gets dev or read-only creds by default; production writes go through CI/deploy, not a laptop.
+- Migration role ≠ app role ≠ read-only inspection role.
+- PITR enabled and verified on any database an agent can reach with write rights.
+
+## Dry-run counts
+
+Before any `DELETE`/`UPDATE` you are asked to run: execute the same `WHERE` as `SELECT count(*)` (and a sample of ids), show the user, then run inside a transaction and check the affected count matches before `COMMIT`.
+
+---
+
+**Provenance:** snapshot 3 October 2026. Sources (accessed 3 Oct 2026): The Register via Slashdot, 21 Jul 2025 — https://developers.slashdot.org/story/25/07/21/1338204/ ; heise, 25 Jul 2025 — https://www.heise.de/en/news/Artificial-intelligence-Vibe-coding-service-Replit-deletes-production-database-10499597.html ; incident summary — https://openleash.com/blog/ai-agents-deleted-production-databases-replit-pocketos ; Prisma CLI reference (AI-agent consent) — https://www.prisma.io/docs/orm/reference/prisma-cli-reference . Branching surfaces from provider docs; verify flags before asserting.