arcane-cli 0.27.0 → 0.28.1

package/README.md

@@ -120,14 +120,14 @@ Arcane isn't a prompt snippet — it's a full framework. Everything installs int
 
 <!-- arcane:start -->
 <details>
-<summary><b>📜 The full spell catalogue (39)</b></summary>
+<summary><b>📜 The full spell catalogue (40)</b></summary>
 
 **Session** — `open-session` · `close-session` · `commit-work` · `status` · `arcane-version`
 **Capture** — `save-idea` · `todo` · `feedback` · `suggest-feature` · `document` · `brainstorm` · `explain-concept`
 **Delivery** — `create-pull-request` · `sync-pull-request` · `address-review`
 **Review** — `review` · `review-batch`
 **Planning** — `plan` · `architect` · `scope` · `product-review`
-**Build** — `implement` · `test` · `full-cycle` · `bug` · `bump` · `dotnet-expert` · `security-review` · `ship` · `enchant` · `generate-bot-icons` · `make-discoverable` · `scry` · `eas-store-deploy`
+**Build** — `implement` · `test` · `full-cycle` · `bug` · `bump` · `dotnet-expert` · `security-review` · `ship` · `enchant` · `generate-bot-icons` · `make-discoverable` · `scry` · `eas-store-deploy` · `compliance`
 **Docs** — `adopt-docs`
 **Venture** — `summon-venture` · `manifest`
 **Meta** — `present-arcane` · `check-drift`

package/dist/assets/.arcane/governance/compliance-standards.md

@@ -0,0 +1,238 @@
+---
+title: Compliance Standards
+audience: both
+last_updated: YYYY-MM-DD
+status: active
+distributable: true
+tags: [compliance, privacy, gdpr, ccpa, soc2, hipaa]
+---
+
+# Compliance Standards
+
+A starting reference for the regulatory and privacy obligations a typical SaaS product runs into —
+GDPR, CCPA, SOC 2, and HIPAA — mapped to the concrete artifacts a product actually needs (data
+inventory, consent, retention/deletion, breach notification, access controls, audit logs), plus a
+tiered guide for which frameworks plausibly apply at which stage.
+
+**This is not legal advice.** It is a governance reference and a self-assessment starting point,
+written at the level of established, uncontroversial obligations — not a substitute for a qualified
+lawyer's analysis of a specific business's specific facts. Applicability determinations, especially
+close calls, should be confirmed with counsel before being treated as settled.
+
+## Executive Summary
+
+- GDPR and CCPA both apply based on **whose data you handle and how**, not where your business is
+  incorporated — a US-only company with EU visitors or California residents can still be in scope.
+- Both frameworks converge on the same underlying artifacts regardless of which one applies: know what
+  personal data you hold and why (a data inventory), get real consent before non-essential processing,
+  define and enforce retention/deletion periods, and be able to act on a user's rights request within a
+  bounded time.
+- SOC 2 is an operational-controls attestation, not a privacy law — it becomes relevant when a customer
+  (typically enterprise) requires it contractually, not from a regulatory trigger.
+- HIPAA has a narrow trigger: it applies to covered entities and their business associates handling
+  protected health information specifically. Most consumer SaaS products never trigger it.
+- Treat this doc as a checklist of what to go verify, not as verification itself — every rule below
+  names the artifact or evidence that would actually demonstrate compliance, not just the obligation in
+  the abstract.
+
+---
+
+## Rule index
+
+| ID | Rule (one line) |
+|----|------|
+| CS-01 | GDPR applies based on whose data is processed (EU residents) and what the processing does (offering goods/services, or monitoring behavior), regardless of where the business is based. |
+| CS-02 | GDPR requires a documented lawful basis for every category of processing, and grants data subjects enforceable rights (access, rectification, erasure, portability, objection) with a response-time bound. |
+| CS-03 | GDPR requires notifying the relevant supervisory authority of a qualifying personal-data breach within 72 hours of becoming aware of it. |
+| CS-04 | CCPA/CPRA applies based on revenue/data-volume thresholds and California residency, and grants consumers rights to know, delete, correct, and opt out of sale/sharing of their personal information. |
+| CS-05 | A CCPA-covered business must provide a clear opt-out mechanism for the sale/sharing of personal information, not just a general privacy policy. |
+| CS-06 | Consent, where required by either framework, must be specific, informed, freely given, and distinguishable from other terms — pre-ticked boxes and bundled consent do not qualify. |
+| CS-07 | A data inventory (what personal data exists, where, and why) is the prerequisite artifact every other obligation in this doc depends on — rights requests and retention policy are both unenforceable without it. |
+| CS-08 | Data minimization requires a defined retention period per data category and actual deletion at the end of it — not merely marking a record inactive. |
+| CS-09 | SOC 2 is a controls attestation against the Trust Services Criteria, not a privacy law — Security is mandatory, the other four criteria are opted into based on what a customer's contract or questionnaire actually requires; Type I attests to a point in time, Type II to operating effectiveness over a period. |
+| CS-10 | SOC 2's Security criterion expects least-privilege access control, periodic access reviews, and audit logging of access to systems holding customer data. |
+| CS-11 | HIPAA applies narrowly, to covered entities and their business associates handling protected health information — most consumer SaaS products never trigger it. |
+| CS-12 | Which frameworks plausibly apply changes by product stage: a privacy policy and lawful-basis/consent groundwork are day-one MVP concerns if any EU or California user could sign up; a working data-subject-request process is a public-launch concern; SOC 2 readiness typically becomes an enterprise-sales-stage concern, not an earlier one. |
+
+---
+
+## GDPR
+
+### CS-01: Applicability is about whose data and what processing, not where the business sits
+
+The GDPR applies to any organization processing the personal data of individuals in the EU, when that
+processing relates to offering goods or services to those individuals (paid or free) or to monitoring
+their behavior — regardless of whether the organization itself has any EU presence. A US-only company
+with EU visitors signing up for a free product is a plausible trigger; a company with zero EU users is
+not, but "zero" needs to be an actual verified fact about the user base, not an assumption based on
+where the company is headquartered.
+
+**Rule (CS-01):** Determine GDPR applicability from the actual or intended user base's location and
+what the processing does, never from the business's own location alone.
+
+### CS-02: A lawful basis and enforceable data-subject rights
+
+Every category of personal-data processing needs a documented lawful basis (consent, contract necessity,
+legal obligation, legitimate interest, among others) — "we're processing it" is not itself a basis. Data
+subjects additionally hold enforceable rights: access to their data, rectification of inaccuracies,
+erasure ("right to be forgotten"), portability to another provider, and objection to certain processing.
+Requests exercising these rights carry a response deadline (commonly one month, extendable in limited
+cases) — a rights-request process that has no defined owner or turnaround time is itself a gap, even
+before any request arrives.
+
+**Rule (CS-02):** Document a lawful basis per processing category, and maintain a working process — with
+a defined owner and turnaround time — for handling data-subject rights requests.
+
+### CS-03: 72-hour breach notification
+
+A personal-data breach that risks the rights and freedoms of data subjects must be reported to the
+relevant supervisory authority within 72 hours of the organization becoming aware of it. This clock
+starts at awareness, not at confirmation of scope — an incident-response process that only begins
+drafting a notification after a full investigation completes risks missing the window entirely.
+
+**Rule (CS-03):** Have a breach-notification process that can produce an initial report to the
+supervisory authority within 72 hours of awareness, even before the full scope of an incident is known.
+
+---
+
+## CCPA / CPRA
+
+### CS-04: Threshold-based applicability and consumer rights
+
+CCPA (as amended by CPRA) applies to for-profit businesses collecting California residents' personal
+information that meet at least one threshold — commonly framed around annual revenue, the volume of
+consumers'/households' data processed, or revenue from selling/sharing personal information (exact
+thresholds are set in statute and updated periodically; verify current figures rather than treating any
+number here as current). Covered businesses must honor consumer rights to know what's collected, delete
+it, correct inaccuracies, and opt out of the sale or sharing of their personal information, plus limit
+use of sensitive personal information on request.
+
+**Rule (CS-04):** Verify CCPA's current statutory thresholds against the business's actual revenue and
+data volume, rather than assuming applicability (or non-applicability) from the business's category
+alone.
+
+### CS-05: A real opt-out mechanism, not just a policy statement
+
+A covered business must provide a clear, functioning mechanism for a consumer to opt out of the sale or
+sharing of their personal information — commonly a "Do Not Sell or Share My Personal Information" link
+or an equivalent global-privacy-control-honoring mechanism. Stating an opt-out right exists in a privacy
+policy's prose, without a working mechanism a consumer can actually use, does not satisfy the
+requirement.
+
+**Rule (CS-05):** Verify the opt-out mechanism itself functions end-to-end — a link that exists in the
+footer but doesn't actually stop the described sharing is not compliant, regardless of what the privacy
+policy says.
+
+---
+
+## Shared obligations (both frameworks)
+
+### CS-06: Consent must be real, not assumed
+
+Where either framework requires consent, it must be specific to the processing purpose, informed (the
+person understands what they're agreeing to), freely given (not a condition of using an unrelated
+feature), and distinguishable from other terms — not buried in a general terms-of-service acceptance.
+Pre-ticked checkboxes, and consent bundled with acceptance of unrelated terms, do not qualify as valid
+consent under either framework.
+
+**Rule (CS-06):** Any consent mechanism must be opt-in (not pre-ticked), specific to its actual purpose,
+and separable from acceptance of unrelated terms.
+
+### CS-07: A data inventory is the load-bearing prerequisite
+
+Honoring an access, deletion, or portability request requires first knowing what personal data exists,
+where it lives, and why it was collected. Without a maintained data inventory (sometimes called a
+Records of Processing Activities under GDPR Article 30), every downstream rights-request and retention
+obligation is unenforceable in practice, even if a policy document claims it's honored — there is no way
+to actually locate everything that would need to be produced, corrected, or deleted.
+
+**Rule (CS-07):** Maintain a data inventory naming what personal data is collected, where it's stored,
+and why, before treating any rights-request or retention process as operational.
+
+### CS-08: Retention periods must be defined and actually enforced
+
+Data minimization requires defining how long each category of personal data is kept and why, then
+actually deleting it at the end of that period — not simply flagging a record as inactive or archived
+while the underlying data persists indefinitely. An undefined retention period is itself a gap, distinct
+from and prior to the question of whether deletion is correctly implemented.
+
+**Rule (CS-08):** Define a retention period per data category, and verify deletion is real (data is
+actually removed, not merely deactivated) at the end of that period.
+
+---
+
+## SOC 2
+
+### CS-09: A controls attestation, not a privacy law — and Type I vs. Type II matters
+
+SOC 2 is an attestation against the AICPA's Trust Services Criteria, produced by an independent auditor
+— it has no regulatory trigger of its own and becomes relevant when a customer's contract or security
+questionnaire requires it, typically at the enterprise sales stage. The Security criterion is mandatory
+for any SOC 2 report; Availability, Processing Integrity, Confidentiality, and Privacy are each opted
+into based on what's actually being attested to. A **Type I** report attests that controls were
+suitably designed at a single point in time; a **Type II** report attests that those controls actually
+operated effectively over an observation period (commonly 3-12 months) — a Type I report does not
+substitute for a Type II when a customer's requirement specifically calls for one.
+
+**Rule (CS-09):** Confirm which Trust Services Criteria and which report type (I vs. II) a customer's
+actual requirement calls for before scoping a SOC 2 engagement — do not assume Security-only Type I
+satisfies a requirement that wasn't explicitly checked against what was asked for.
+
+### CS-10: Access control and audit logging are the operational backbone
+
+SOC 2's Security criterion expects least-privilege access to systems holding customer data, periodic
+review of who has access to what (not just at onboarding), and audit logging of access to
+sensitive systems sufficient to reconstruct who did what and when. These are the same operational
+controls a real security program needs regardless of whether a SOC 2 report is ever pursued — building
+them only when an audit is scheduled means starting the evidentiary trail late.
+
+**Rule (CS-10):** Implement least-privilege access control, periodic access review, and audit logging of
+access to customer-data-holding systems as an ongoing practice, not as audit-time preparation.
+
+---
+
+## HIPAA
+
+### CS-11: A narrow trigger — covered entities and business associates handling PHI
+
+HIPAA applies to covered entities (health plans, healthcare clearinghouses, healthcare providers that
+transmit health information electronically) and their business associates — vendors that create,
+receive, maintain, or transmit protected health information (PHI) on a covered entity's behalf. A
+typical consumer SaaS product with no health-data handling does not trigger HIPAA merely by having
+users who happen to be patients elsewhere; the trigger is the product's own handling of PHI, not its
+users' medical status in general.
+
+**Rule (CS-11):** Confirm HIPAA applicability specifically against whether the product creates,
+receives, maintains, or transmits PHI as a covered entity or business associate — do not assume
+applicability (or safety from it) based on the target market alone.
+
+---
+
+## Tiered applicability guide
+
+### CS-12: What plausibly applies at which stage
+
+- **Early MVP:** if the product could realistically have any EU visitor or California resident sign up —
+  which is the default for anything reachable on the open internet — a privacy policy and a documented
+  lawful basis/consent approach are day-one concerns, not deferred ones. Waiting until "we have real
+  users" to start is waiting until the obligation is already live.
+- **Public launch:** a working data-subject-request process (someone owns it, there's a defined
+  turnaround) and a real, functioning consent/opt-out mechanism move from "nice to have documented" to
+  "will actually be exercised by a real person" — this is the stage where CS-02, CS-05, CS-06, and CS-07
+  need to be operational, not just written down.
+- **Enterprise sales stage:** SOC 2 readiness (CS-09, CS-10) typically becomes relevant when a customer's
+  procurement or security-questionnaire process asks for it — building the access-control and logging
+  practices in CS-10 well before an audit is scheduled makes the eventual Type II observation period
+  starts from real evidence rather than a scramble. HIPAA (CS-11) becomes relevant only if the business
+  is entering healthcare specifically, at whatever stage that happens.
+
+**Rule (CS-12):** Use product stage as a prompt to re-check applicability, not as a substitute for
+checking it — a pre-launch product with EU beta users is already in GDPR's scope regardless of stage.
+
+## Related
+
+- [[.arcane/governance/threat-model|Threat Model]] and
+  [[.arcane/governance/hardening-checklist|Hardening Checklist]] — the security-control side of SOC 2 and
+  breach-notification readiness overlaps with these existing docs; this doc doesn't restate their
+  content.
+- `spell-compliance` — the runnable self-assessment that cites these rules by ID.

package/dist/assets/.arcane/governance/universal-agent-rules.md

@@ -126,6 +126,16 @@ See also: [[README]], [[DECISIONS]], [[governance/git-conventions|Git Convention
 
 20. **For repo path requests**, perform read-only discovery before claiming "no access." Use [[agents/agent-approved-paths|Agent Approved Paths Registry]].
 
+23. **Diff before deleting a "duplicate."** When housekeeping surfaces two blocks of content that look
+    like duplicates — in a document, a config, a data file — compare them in full before removing
+    either. A near-identical pair is usually a **drifted copy carrying unique content in one and not the
+    other**, not byte-identical redundancy; deleting on sight can destroy the unique content silently.
+    Merge anything unique to either copy into the one that survives, and only delete a copy confirmed
+    byte-identical to (or a confirmed strict subset of) the one kept. This generalizes the same
+    content-verification discipline
+    [[governance/git-conventions#content-verified-branch-deletion-todomd-merged-branch-cleanup-finding|Content-Verified
+    Branch Deletion]] already applies to branches specifically.
+
 ---
 
 ## Client-Specific Instruction Locations

package/dist/assets/.claude/commands/spell-compliance.md

@@ -0,0 +1,13 @@
+---
+description: Use PROACTIVELY before a launch, an enterprise sales cycle, or a security questionnaire that raises GDPR/CCPA/SOC 2/HIPAA questions.
+---
+
+# Compliance
+
+Invoke the Arcane `spell-compliance` spell workflow.
+
+See the full prompt at `.github/prompts/spell-compliance.prompt.md` for the complete workflow definition.
+
+---
+
+@.github/prompts/spell-compliance.prompt.md

package/dist/assets/.github/prompts/spell-compliance.prompt.md

@@ -0,0 +1,129 @@
+---
+name: Spell — Compliance
+description: Run a regulatory compliance self-assessment against this repo (GDPR, CCPA, SOC 2, HIPAA) and produce a prioritized remediation checklist. Read-only — never drafts policies or fixes gaps automatically.
+argument-hint: Optional focus (e.g., "GDPR only", "pre-launch check", "SOC 2 readiness")
+agent: agent
+---
+
+## Executive Summary
+
+- This spell self-assesses a repo's compliance posture against GDPR, CCPA, SOC 2, and HIPAA, and
+  produces a prioritized remediation checklist.
+- **It is read-only.** It never drafts a privacy policy, invents a retention period, or fixes a gap on
+  its own — every finding is a checklist item for a human (often with legal input) to act on.
+- **This is not legal advice**, and the report says so explicitly. It is a starting self-assessment
+  against established, uncontroversial obligations — not a substitute for a qualified lawyer's analysis
+  of this specific business's specific facts.
+- Findings cite `CS-nn` rule IDs from
+  [`compliance-standards.md`](../../.arcane/governance/compliance-standards.md) — the rationale for each
+  obligation lives there, not restated here.
+
+---
+
+## Context files
+
+- [governance/compliance-standards.md](../../.arcane/governance/compliance-standards.md) — every
+  `CS-nn` rule this spell checks against. Rules are **cited by ID only** in this spell, never restated.
+  **If the file is not installed**, this spell still runs in full — findings just cite each check as
+  `CS-nn (rationale unavailable — install the standards doc)` instead of linking to it.
+- `threat-model.md` and `hardening-checklist.md`, if present — the security-control evidence for `CS-10`
+  (access control, audit logging) frequently already exists in these docs rather than needing to be
+  assessed fresh.
+- `project.md` / `.arcane.json` — for the business context (target users, whether the product could
+  plausibly reach EU or California residents, whether it handles health data) that Phase 1 needs.
+
+## Phase 1 — Determine applicability (ask, don't assume)
+
+Applicability determinations have real consequences, so resolve each of the following by checking the
+repo's own context first (`project.md`, `.arcane.json`, existing docs); **ask the operator directly**
+for anything not resolvable from those sources — never assume:
+
+- Could the product realistically reach EU residents (any public-internet-reachable consumer product
+  defaults to yes) — GDPR relevance (`CS-01`).
+- Does the business meet, or plausibly approach, CCPA/CPRA's revenue or data-volume thresholds, and
+  could it reach California residents — CCPA relevance (`CS-04`). State plainly that exact thresholds
+  should be verified against current statute, not assumed from this spell's own knowledge.
+- Is a customer, prospect, or procurement process currently asking for a SOC 2 report, or is one
+  expected within a near-term sales cycle — SOC 2 relevance (`CS-09`).
+- Does the product create, receive, maintain, or transmit protected health information as a covered
+  entity or business associate — HIPAA relevance (`CS-11`). State plainly that this is a narrow trigger,
+  not a default.
+
+Record which frameworks are in scope for this run and why, before proceeding — a framework judged
+out of scope is reported as such in Phase 4, not silently skipped without explanation.
+
+## Phase 2 — Inventory (read-only)
+
+Enumerate what compliance-relevant artifacts already exist, without judging sufficiency yet:
+
+- A privacy policy — does one exist, and where.
+- A data inventory / Records of Processing Activities doc — does one exist and does it name what
+  personal data is collected, where it's stored, and why.
+- A retention/deletion policy — does one exist, and does it define a period per data category.
+- Consent mechanism indicators — a cookie/consent banner, a consent-management SDK, an opt-in flow in
+  the signup path; and separately, a "Do Not Sell or Share" link or equivalent opt-out mechanism.
+- Existing security documentation this repo may already ship (`threat-model.md`,
+  `hardening-checklist.md`, `authentication-strategy.md`) — relevant evidence for `CS-10` without
+  needing to reassess it from scratch.
+- Breach-notification process — is there a documented incident-response process with a named owner and
+  a notification path.
+
+Report anything not found as absent, not as failed — Phase 3 is where absence becomes a finding against
+a specific applicable rule.
+
+## Phase 3 — Audit
+
+For each framework marked in-scope in Phase 1, check its rules from `compliance-standards.md` against
+what Phase 2 found. Mark each `PASS` / `FAIL` / `PARTIAL`, citing the rule ID only:
+
+```text
+CS-07 FAIL — no data inventory found; a data inventory is the prerequisite artifact CS-02/CS-04's
+  rights-request obligations depend on.
+CS-06 PARTIAL — a consent banner exists, but the "accept all" and "reject non-essential" options are
+  not visually equivalent, which is a common consent-validity gap.
+```
+
+Do not restate why a rule matters — that reasoning lives in `compliance-standards.md`; cite the ID and
+state the evidence.
+
+## Phase 4 — Report
+
+Produce a prioritized remediation checklist: mandatory-baseline gaps (GDPR/CCPA, if in scope) before
+optional-tier gaps (SOC 2, HIPAA), and structural prerequisites (a missing data inventory) before the
+rights-request/consent mechanisms that depend on them.
+
+```markdown
+## Compliance Self-Assessment — [repo name]
+
+**Frameworks assessed:** [list, with in-scope/out-of-scope reasoning from Phase 1]
+**Date:** [timestamp]
+
+> This is a self-assessment against established compliance obligations, not legal advice. Confirm any
+> finding below with qualified counsel before treating it as a compliance determination.
+
+### Findings, by priority
+
+#### Mandatory baseline (GDPR / CCPA)
+- [ ] CS-07 — [gap + what artifact would close it]
+
+#### Optional tier (SOC 2 / HIPAA), if in scope
+- [ ] CS-10 — [gap + what artifact would close it]
+
+### Out of scope this run
+- [Framework] — [why, per Phase 1's determination]
+```
+
+## Rules
+
+This spell defers entirely to
+[governance/compliance-standards.md](../../.arcane/governance/compliance-standards.md) for what each
+obligation means and why. Findings in this spell cite rule IDs; they do not re-explain them. This spell
+never drafts a policy document, never invents a retention period or lawful basis on the operator's
+behalf, and never claims to produce a legal compliance determination — every output is a checklist item
+for a human to act on, with legal input where the finding calls for it.
+
+## Related
+
+- [Compliance Standards](../../.arcane/governance/compliance-standards.md)
+- **Feeds into:** the operator's own remediation work — this spell does not fix gaps, it enumerates
+  them.

package/dist/index.js

@@ -291,7 +291,8 @@ var PROFILE_CONFIGS = [
       "spell-authoring-standards",
       "external-verification-standards",
       "web-discoverability-standards",
-      "mobile-release-standards"
+      "mobile-release-standards",
+      "compliance-standards"
     ]
   }
 ];
@@ -458,6 +459,11 @@ var COMPONENTS = [
     description: "Durable App Store / Google Play console and release-track facts consumed by spell-eas-store-deploy",
     files: [".arcane/governance/mobile-release-standards.md"]
   },
+  {
+    name: "compliance-standards",
+    description: "GDPR/CCPA/SOC 2/HIPAA obligations and a tiered applicability guide, consumed by spell-compliance",
+    files: [".arcane/governance/compliance-standards.md"]
+  },
   // ─── Spells ────────────────────────────────────────────────────────────────
   // Split from the former monolithic `spell-prompts` + `claude-commands` pair
   // so a profile can select spells by capability (see ARC-0NN). Grouping lives
@@ -570,7 +576,9 @@ var COMPONENTS = [
       ".github/prompts/spell-scry.prompt.md",
       ".claude/commands/spell-scry.md",
       ".github/prompts/spell-eas-store-deploy.prompt.md",
-      ".claude/commands/spell-eas-store-deploy.md"
+      ".claude/commands/spell-eas-store-deploy.md",
+      ".github/prompts/spell-compliance.prompt.md",
+      ".claude/commands/spell-compliance.md"
     ]
   },
   {