arcane-cli 0.26.2 → 0.28.0

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 (38)</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`
+**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/mobile-release-standards.md

@@ -0,0 +1,239 @@
+---
+title: Mobile Release Standards
+audience: both
+last_updated: YYYY-MM-DD
+status: active
+distributable: true
+tags: [mobile, app-store, google-play, release, deployment]
+---
+
+# Mobile Release Standards
+
+Durable facts about how the Apple App Store and Google Play review consoles and release pipelines
+actually behave — true regardless of which build tool produced the binary. These are platform
+properties, not Expo/EAS-specific tooling behavior; the EAS-specific workflow that consumes these rules
+lives in `spell-eas-store-deploy`. Sourced from two real dogfooding runs (a first-ever App Store
+submission, then a from-zero Google Play listing to a live production release) — every rule here was hit
+for real, not derived from documentation alone.
+
+## Executive Summary
+
+- A store's review/track model is not symmetric with the other store's, and approval on one track never
+  promotes a binary anywhere else — treat each track and each store as its own release, not a step in a
+  shared pipeline.
+- Several consoles distinguish "saved" from "submitted," and several silently drop scripted input —
+  verify the console's own state readout before trusting that an action took effect (`EV-01`/`EV-03`).
+- Identity and signing facts (the certificate an installed app actually presents, which `(package,
+  SHA-1)` pair an integration is keyed to, where a public developer address actually comes from) are
+  frequently not visible on the console page you'd naturally check — read them from the artifact or the
+  system that actually enforces them, not from a console summary.
+- Two platform-specific binary/UI constraints (notification icon requirements, a native dialog's button
+  cap) have no equivalent on the other platform and are easy to carry over incorrectly from iOS-first
+  development.
+
+---
+
+## Rule index
+
+| ID | Rule (one line) |
+|----|------|
+| MR-01 | Google Play's tracks are independent: only *internal testing* skips review, and approval on any one track never promotes the binary to another. |
+| MR-02 | A fresh Google Play production track starts with zero countries/regions, which surfaces as a generic, uninformative release error. |
+| MR-03 | Google Play console edits are staged until an explicit "send for review" action; saving is not submitting. |
+| MR-04 | Google Play's IARC content-rating questionnaire re-renders when the app category changes, shifting rows under answers already given. |
+| MR-05 | "Data collected" means data that leaves the device — and both stores' privacy/data-safety declarations must agree with each other. |
+| MR-06 | The two stores' supported locale catalogues differ; do not copy one store's locale list onto the other. |
+| MR-07 | Reviewer/demo-account access is scoped per app, not per account type, and is length-capped. |
+| MR-08 | Google Play's "no deobfuscation file" warning is benign and permanent until a mapping file is uploaded. |
+| MR-09 | The signing certificate an installed Android app actually presents can differ from what any single console page shows — read it from the device, never infer it. |
+| MR-10 | Android OAuth clients are keyed to one `(package name, SHA-1)` pair each, and ship with the custom-URI-scheme toggle off by default. |
+| MR-11 | Google Play sources the public developer address from the D-U-N-S record; confirming it in-console locks in whatever address is currently on file. |
+| MR-12 | Audit the permissions the built artifact actually declares, not what the source code appears to use. |
+| MR-13 | Android push-notification icons need a dedicated monochrome asset shipped in a native build; there is no OTA path for this. |
+| MR-14 | Android's native `AlertDialog` silently caps at three buttons; a menu built on `Alert.alert` past that cap loses the overflow, typically the dismiss action. |
+
+---
+
+## Release tracks and console state
+
+### MR-01: Google Play's tracks are independent — nothing promotes automatically
+
+*Internal testing* publishes with no review. *Closed*, *open*, and *production* each trigger a real
+review. Passing review on one track says nothing about any other track: production is a wholly separate
+release, with its own binary assignment and its own country list. An operator who watches a closed-test
+release turn green will reasonably conclude the app is live to the public — it is not, and nothing in
+the console actively corrects that assumption.
+
+**Rule (MR-01):** Treat each Google Play track as an independent release requiring its own review and
+its own configuration; passing review on one track never promotes the binary to another.
+
+### MR-02: A fresh production track starts with zero countries — and fails silently about why
+
+Countries and regions are configured per track, not once per app. A brand-new production track therefore
+starts with none selected. The release wizard responds to this with a generic "We found some problems
+with your release / To save, fix errors" that never names the actual cause. The real signal is the track
+summary reading `0 countries / regions` — set the country list on the track before attempting to build
+the release, not after the generic error appears.
+
+**Rule (MR-02):** Before building a release for any Google Play track, confirm its country/region list
+is non-empty; a generic "fix errors" message with no named cause is this failure's signature.
+
+### MR-03: Saving is not submitting
+
+Google Play console edits land in the Publishing overview as staged changes. They reach Google only
+through an explicit "Send changes for review" action, which itself carries a second confirmation dialog.
+A workflow that stops at "Save" ships nothing. The listing pages carry the identical trap under a
+differently-worded "Save and publish" action with its own second dialog.
+
+**Rule (MR-03):** After any Google Play console edit, look for and complete the explicit send-for-review
+(or save-and-publish) action and its confirmation dialog — "saved" is not a release state.
+
+---
+
+## Console review quirks
+
+### MR-04: The IARC questionnaire re-renders on category change
+
+Changing an app's category in the Google Play console causes the IARC content-rating questionnaire to
+re-render, shifting which question sits at which row. A batch of clicks issued against the prior layout
+lands on the wrong questions and can silently set an unintended answer — including sensitive categories
+like graphic violence or location sharing.
+
+**Rule (MR-04):** Answer the IARC questionnaire one question at a time, and re-read the full form after
+any change to the app's category, rather than assuming the row order is stable.
+
+### MR-08: The "no deobfuscation file" warning is benign and permanent
+
+Google Play shows a "no deobfuscation file" warning on every release once mapping-file upload isn't
+wired up. This warning does not resolve itself and does not indicate a build defect — it will appear on
+every future release until a mapping file is actually uploaded. State this explicitly wherever it
+appears in documentation or in-flight guidance, since it reads as alarming on a first submission.
+
+**Rule (MR-08):** Treat Google Play's "no deobfuscation file" warning as an expected, permanent state
+absent mapping-file upload — not a signal of a broken release.
+
+---
+
+## Cross-store consistency
+
+### MR-05: "Collected" means leaves the device — and the two stores' answers must agree
+
+Google Play's data-safety framework and Apple's App Privacy responses both hinge on the same underlying
+definition: data is "collected" only if it leaves the device. Purely on-device processing is not
+collection. Because both declarations are public, a reviewer or a user can compare them directly — the
+two stores' answers for the same app must describe the same underlying behavior, not merely satisfy each
+store's form independently.
+
+**Rule (MR-05):** Data-safety and privacy declarations across both stores must agree with each other on
+what is actually collected, using "leaves the device" as the collection test in both places.
+
+### MR-06: The stores' locale catalogues differ
+
+Release notes are supplied per-language, and the set of locales each store's catalogue supports is not
+identical between Apple and Google. A locale available on one store may not exist on the other, so a
+default-language or locale-coverage choice has to be made against each store's own list — never copied
+across from the other store's configuration.
+
+**Rule (MR-06):** Resolve locale/language coverage against each store's own supported-locale list
+independently; do not assume the other store's locale set applies.
+
+---
+
+## Access, identity, and signing
+
+### MR-07: Reviewer access is scoped per app and length-capped
+
+The demo-credentials/reviewer-access box is required per app, not per account type, and has a length
+cap. An app with genuinely distinct account types (consumer vs. business, for example) needs one working
+account supplied directly, with prose describing how a reviewer reaches the other flows — there is no
+mechanism for supplying multiple credential sets natively.
+
+**Rule (MR-07):** Provide one working reviewer account per app submission, with any additional
+account-type flows described in prose rather than as separate credentials.
+
+### MR-09: Read the actual signing certificate — never infer it
+
+Google Play App Signing, combined with "automatic protection," can result in an installed app presenting
+a signing certificate that does not appear on any console page an operator would naturally check.
+Anything keyed to a `(package, SHA-1)` pair — Maps API keys, Google Sign-In, App Links / `assetlinks.json`
+— then fails specifically on Play-delivered installs while working normally on sideloaded builds. Zero
+traffic in a provider's own usage metrics is not evidence the app isn't calling it (an auth failure can
+occur before any billable request is logged), and a working browser-based OAuth flow proves nothing
+about certificate matching, since that flow never checks certificates. This is the same discipline
+`EV-01` states in general form — re-read the actual persisted/served state, never trust the interface —
+applied to a case where the "interface" is a console page that may not even show the value in question.
+
+**Rule (MR-09):** Never infer an Android signing SHA-1 from a console page; read the certificate the
+installed app actually presents, via `adb logcat` against a Play-delivered install (`EV-01`).
+
+### MR-10: Android OAuth clients are scoped to one `(package, SHA-1)` pair, custom scheme off by default
+
+Each Android OAuth client is keyed to exactly one `(package name, SHA-1)` combination — a Play-signed
+install, an upload-signed sideload, and a separate `.dev` build variant each need their own client, not a
+shared one. Separately, new Android OAuth clients ship with "Enable custom URI scheme" switched off by
+default; leaving it off produces a visible `Error 400: invalid_request`, which is a console
+configuration gap, not a code defect.
+
+**Rule (MR-10):** Provision one Android OAuth client per distinct `(package, SHA-1)` pair, and confirm
+"Enable custom URI scheme" is on for any client that needs a custom-scheme redirect.
+
+### MR-11: The public developer address comes from D-U-N-S, and confirming it locks it in
+
+Google Play publishes the developer's address on the public listing, and that address is not directly
+editable inside Play — it is sourced from the developer's D-U-N-S record. The console offers only
+"confirm" or "contact D&B." Clicking "confirm" first locks in whatever address is currently on file,
+which for a solo operator is frequently a home address. The correct order is: fix the address at D&B
+first, wait for propagation (days to weeks), let Google re-sync, and only then confirm. Android developer
+verification carries its own hard deadline, so this correction needs to start early enough that the
+D&B propagation window still fits before that deadline.
+
+**Rule (MR-11):** Correct the address at the D-U-N-S source and allow it to propagate before confirming
+it in the Google Play console — confirming first permanently publishes whatever address is on file at
+that moment.
+
+---
+
+## Binary and platform specifics
+
+### MR-12: Audit what the binary actually declares, not what the code appears to use
+
+A dependency that is installed but no longer called from application code still contributes its declared
+permissions to the built artifact, and every declared permission is both review and data-safety surface.
+The only reliable check is against the artifact itself (`aapt2 dump permissions`, or an equivalent raw
+manifest inspection) — inspecting source code for call sites is not equivalent, since an unused
+dependency's manifest entries survive independently of whether anything still calls it. Removing a
+permission means removing the dependency that declares it, and the removal must be re-verified against a
+newly built artifact, not assumed from the source diff.
+
+**Rule (MR-12):** Verify declared permissions against the actually built artifact, not against source
+code's apparent usage, both before submission and after removing a permission-declaring dependency.
+
+### MR-13: Android notification icons need a dedicated asset, shipped natively
+
+Android requires a dedicated monochrome, white-on-transparent small icon for notifications; without one,
+the system falls back to a generic glyph in the notification shade. This is a native configuration
+change and therefore ships only in a build — there is no OTA path for it. When diagnosing a "broken"
+notification icon, check the notification shade specifically rather than the heads-up banner, since some
+OEM skins legitimately omit the small icon from the banner view while still rendering it correctly in the
+shade. The branded, full-color icon slot is `largeIcon`, a separate asset from the required small icon.
+
+**Rule (MR-13):** Ship a dedicated monochrome small-icon asset for Android notifications in a native
+build (never an OTA), and diagnose icon issues via the notification shade, not the heads-up banner.
+
+### MR-14: Android's native `AlertDialog` caps at three buttons
+
+Android's native `AlertDialog` silently drops any button past a hard cap of three. A menu built on
+`Alert.alert` with more than three options loses whatever falls past the cap — in practice, typically
+the *Cancel* row, leaving a dialog with no way to dismiss it. iOS has no equivalent limit
+(`ActionSheetIOS` supports an arbitrary option count).
+
+**Rule (MR-14):** For any Android menu that could exceed three options, use a real bottom sheet
+dismissible at least three ways (an explicit cancel row, a scrim tap, and the hardware back gesture)
+instead of `Alert.alert`.
+
+## Related
+
+- [[.arcane/governance/external-verification-standards|External Verification Standards]] — `EV-01`
+  (re-read persisted state) and `EV-03` (trust the readout, escalate rather than retry) are the general
+  principles `MR-09` applies to Android's signing-certificate opacity specifically.
+- `spell-eas-store-deploy` — the runnable EAS Build + EAS Submit workflow that cites these rules by ID.

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/.claude/commands/spell-eas-store-deploy.md

@@ -0,0 +1,13 @@
+---
+description: Use PROACTIVELY when deploying an Expo app to the App Store or Google Play via EAS.
+---
+
+# EAS Store Deploy
+
+Invoke the Arcane `spell-eas-store-deploy` spell workflow.
+
+See the full prompt at `.github/prompts/spell-eas-store-deploy.prompt.md` for the complete workflow definition.
+
+---
+
+@.github/prompts/spell-eas-store-deploy.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.