arcane-cli 0.26.1 → 0.27.0

package/README.md

@@ -30,7 +30,7 @@ npm install -g arcane-cli   #  then:  spell init
 
 <div align="center">
 
-**🔁 opinionated lifecycle** &nbsp;·&nbsp; **📜 36 spells** &nbsp;·&nbsp; **🤖 12 agents** &nbsp;·&nbsp; **⚖️ 23 governance standards** &nbsp;·&nbsp; **📝 markdown-native** &nbsp;·&nbsp; **🔌 any AI client / tracker**
+**🔁 opinionated lifecycle** &nbsp;·&nbsp; **📜 38 spells** &nbsp;·&nbsp; **🤖 12 agents** &nbsp;·&nbsp; **⚖️ 23 governance standards** &nbsp;·&nbsp; **📝 markdown-native** &nbsp;·&nbsp; **🔌 any AI client / tracker**
 
 </div>
 
@@ -113,22 +113,27 @@ Arcane isn't a prompt snippet — it's a full framework. Everything installs int
 
 | Layer | What you get |
 | --- | --- |
-| 📜 **Spells** | **34** prompt-driven workflows spanning the entire lifecycle — planning, architecture, implementation, testing, review, shipping, session management, and ops. |
-| ⚖️ **Governance** | **19** battle-tested standards as drop-in templates: git conventions, testing standards, CI/CD, threat model, ADR format, naming, security hardening, and more. |
+| 📜 **Spells** | **38** prompt-driven workflows spanning the entire lifecycle — planning, architecture, implementation, testing, review, shipping, session management, and ops. |
+| ⚖️ **Governance** | **23** battle-tested standards as drop-in templates: git conventions, testing standards, CI/CD, threat model, ADR format, naming, security hardening, and more. |
 | 🤖 **Agents** | **12** ready-made agent personas with roles, clusters, and a gamified autonomy model — assign work and power levels per repo. |
 | 🛠️ **CLI** | `spell init / add / update / status / uninstall` — install by profile or à la carte, and keep everything in sync as new versions ship. |
 
+<!-- arcane:start -->
 <details>
-<summary><b>📜 The full spell catalogue (34)</b></summary>
-
-**Core Spell Loop** — `plan` · `enchant` · `scope` · `architect` · `implement` · `test` · `review` · `ship`
-**Session** — `open-session` · `close-session` · `status`
-**Operational & Git** — `commit-work` · `todo` · `check-drift` · `bug` · `create-pull-request` · `address-review` · `bump`
-**Specialized** — `full-cycle` · `review-batch` · `security-review` · `dotnet-expert` · `product-review` · `suggest-feature`
-**Knowledge & Docs** — `document` · `explain-concept` · `feedback` · `save-idea` · `manifest`
-**Business & Admin** — `summon-venture` · `brainstorm` · `generate-bot-icons` · `present-arcane` · `arcane-version`
+<summary><b>📜 The full spell catalogue (39)</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`
+**Docs** — `adopt-docs`
+**Venture** — `summon-venture` · `manifest`
+**Meta** — `present-arcane` · `check-drift`
 
 </details>
+<!-- arcane:end -->
 
 <details>
 <summary><b>⚖️ The governance standards (23)</b></summary>

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/.arcane/governance/portable-bootstrap.md

@@ -54,6 +54,12 @@ Paste this entire file into any AI client (Claude web, ChatGPT, etc.) to give it
 - **Project/domain documents:** use explicit descriptive paths such as `docs/`, `security/`, `infrastructure/`, or a configured business root. These add project context alongside framework standards.
 - **Overrides are not yet supported:** editing a managed `.arcane/governance/` standard can be replaced by `arcane update`. Additive project documents are safe; overriding a shipped standard requires the open customization/override model.
 
+## Research Reports
+
+Research findings (competitive analysis, technical spikes, feasibility studies — the output of the Research & Backlog Analyst role) live at `docs/research/<topic-slug>.md`, one file per report. No dedicated spell produces these: `spell-document` already proposes a target path from project structure and matches its destination directory's existing conventions — point it at `docs/research/` for investigative content, the same way it already proposes `docs/` or `.arcane/governance/` for other document types. The directory is created on first real report, not pre-seeded on `spell init`.
+
+Use this repo's standard frontmatter (below) plus one addition: `sources` — a list of what was consulted. Every claim in the body traces back to one of these or is explicitly marked speculative. Structure the body summary-first: a short **Summary** with the key findings, then **Findings** with full detail and inline citations, then an optional **Follow-ups** for anything that should become a TODO item — route those via `spell-todo`, which cross-references the report path. Throughout, distinguish **verified facts**, **reasonable inferences**, and **speculation** explicitly; don't let an inference read as a checked fact.
+
 ## Documentation Format
 
 Every doc uses YAML frontmatter: `title`, `audience` (human/ai/both), `last_updated`, `status` (draft/active/deprecated), `tags`. Use wiki-links (`[[filename]]`) for cross-references.

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-close-session.prompt.md

@@ -31,7 +31,7 @@ Workflow:
    - Decisions made (even implicit ones like naming choices, tool preferences, or workflow patterns).
    - Problems encountered and how they were resolved (troubleshooting).
    - Lessons learned (anything that cost time, surprised the user, or should prevent future mistakes).
-   - **Capture tie-in tip:** If this session produced durable analysis worth formalizing (a design, an investigation, a reusable explanation), suggest running `spell-document` before closing so it lands in the right doc. For quick ideas worth keeping but not yet actionable, suggest `spell-save-idea`.
+   - **Capture tie-in tip:** If this session produced durable analysis worth formalizing (a design, an investigation, a research finding, a reusable explanation), suggest running `spell-document` before closing so it lands in the right doc — a research finding defaults to `docs/research/<topic-slug>.md` per `portable-bootstrap.md`'s Research Reports convention. For quick ideas worth keeping but not yet actionable, suggest `spell-save-idea`.
 
 1b. **Verify in-flight async work before writing any output artifact (EF-21). Enforcement: structured spell gate (ARC-023) — this workflow requires the observable state of every dispatched item before proceeding to step 2.** "I started it" is not "it worked." Before the journal, TODO.md, or the handoff are written, enumerate every piece of asynchronous work dispatched during this session that could still be running or could have failed after being kicked off — CI/CD runs, deployments, package publishes, long-running background tasks, PR checks. For each, **actively check** its current status through whatever means is available (CI provider API/CLI, deployment dashboard, `gh run view`, `az pipelines runs show`, etc.) — attempt the check before reaching for `unverifiable`; that state exists for genuine access limits (no CLI/API access, no credentials, provider outage), not for skipping a check that was merely inconvenient to run. Then classify into exactly one state:
 

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

@@ -25,8 +25,8 @@ The user's input describes what to capture and where. If no argument was provide
 Identify:
 
 - **Topics** — what conversation insights to extract (e.g., "naming analysis", "architecture comparison").
-- **Target paths** — where to write (e.g., `docs/...`, `.arcane/governance/...`). If the user gives only topics, propose sensible paths from the project structure.
-- **Document type** — reference doc, decision record, analysis report, inventory, or guide.
+- **Target paths** — where to write (e.g., `docs/...`, `.arcane/governance/...`). If the user gives only topics, propose sensible paths from the project structure. For a research report specifically (cited investigation, competitive analysis, feasibility study), default to `docs/research/<topic-slug>.md` per `portable-bootstrap.md`'s Research Reports convention.
+- **Document type** — reference doc, decision record, analysis report, research report, inventory, or guide.
 
 ## Step 2 — Extract from Conversation
 

package/dist/assets/.github/prompts/spell-eas-store-deploy.prompt.md

@@ -0,0 +1,253 @@
+---
+name: Spell — EAS Store Deploy
+description: Deploy an Expo app to the Apple App Store and Google Play via EAS Build + EAS Submit — one-time setup, repeat deployments, and the known pitfalls hit dogfooding both flows for real.
+argument-hint: Which store(s) to deploy to (ios, android, or both) and whether this is initial setup or a repeat deployment
+agent: agent
+---
+
+## Executive Summary
+
+- This spell documents the **EAS Build + EAS Submit** pipeline end to end for both the Apple App Store
+  and Google Play — initial one-time setup, repeat deployments, and known pitfalls, in that order, for
+  each store.
+- Roughly 80% of the material (credentials, `eas.json` profile shape, build-number handling, OTA rules)
+  is shared between the two stores; only the store-console work genuinely diverges. Covered once in a
+  shared preamble, then two store-specific sections.
+- **Deliberately scoped to EAS Build + EAS Submit** — no local Xcode, Xcode Cloud, or Fastlane coverage.
+  That scope is what keeps every step concrete and copy-pasteable.
+- Every lesson here was hit for real across two dogfooding runs (a first-ever App Store submission, then
+  a from-zero Google Play listing to a live production release) — none is general knowledge restated.
+- Durable, store-specific platform facts are documented once in
+  [`mobile-release-standards.md`](../../.arcane/governance/mobile-release-standards.md) and cited here
+  by `MR-nn` ID; verification discipline is documented once in
+  [`external-verification-standards.md`](../../.arcane/governance/external-verification-standards.md)
+  and cited by `EV-nn` ID. This spell does not restate either.
+
+---
+
+## Placeholders
+
+Every placeholder below follows the same resolution rule: pull it from `.arcane.json`, the invoking
+frontmatter, or the repo's own existing `app.json`/`eas.json`; if it is not resolvable from any of those,
+**ask** — never assume. A wrong guess here produces a rejected submission or a build tied to the wrong
+account, not a local mistake.
+
+| Placeholder | What it is | Resolution rule |
+| --- | --- | --- |
+| `{IOS_BUNDLE_ID}` | The iOS bundle identifier. | Resolve from `app.json`'s `expo.ios.bundleIdentifier`; if unset, ask. |
+| `{APPLE_TEAM_ID}` | The Apple Developer Team ID. | Resolve from `eas.json` or the Apple Developer account; if unset, ask. |
+| `{ASC_APP_ID}` | The App Store Connect App ID (`ascAppId`). | Resolve from `eas.json`'s `submit.production.ios` block, or App Store Connect's own app record; if unset, ask. |
+| `{APPLE_ID_EMAIL}` | The Apple ID email used to authenticate to App Store Connect. | Resolve from `eas.json`, or ask — never assume which Apple ID owns the account. |
+| `{EAS_PROJECT_SLUG}` | The EAS project ID/slug. | Resolve from `app.json`'s `expo.extra.eas.projectId` or `eas init` output; if unset, ask. |
+| `{ANDROID_PACKAGE}` | The Android application ID / package name. | Resolve from `app.json`'s `expo.android.package`; if unset, ask. |
+| `{ORG_NAME}` | The Expo/EAS organization name, if the project belongs to one. | Resolve from `eas.json` or the EAS dashboard; if not applicable, omit. |
+
+## Context files
+
+- [governance/mobile-release-standards.md](../../.arcane/governance/mobile-release-standards.md) —
+  every `MR-nn` rule cited below. 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 `MR-nn
+  (rationale unavailable — install the standards doc)` instead of linking to it.
+- [governance/external-verification-standards.md](../../.arcane/governance/external-verification-standards.md) —
+  every `EV-nn` rule cited below, cited by ID only. **If the file is not installed**, this spell still
+  runs, and still re-reads actual state rather than trusting a console's own success signal — it just
+  cites those checks as `EV-nn (rationale unavailable — install the standards doc)`.
+
+---
+
+## Shared EAS Preamble (both stores)
+
+This section is common setup both stores' deployments depend on. Do it once.
+
+### `eas.json` profile structure
+
+```json
+{
+  "build": {
+    "production": {
+      "autoIncrement": true
+    }
+  },
+  "submit": {
+    "production": {
+      "ios": {
+        "appleId": "{APPLE_ID_EMAIL}",
+        "ascAppId": "{ASC_APP_ID}",
+        "appleTeamId": "{APPLE_TEAM_ID}"
+      },
+      "android": {
+        "serviceAccountKeyPath": "./path/to/service-account.json",
+        "track": "production"
+      }
+    }
+  }
+}
+```
+
+- `appVersionSource: "local"` (in `app.json`'s `expo` block) plus `production.autoIncrement: true` means
+  build numbers auto-increment on every build — no manual version bump needed for a routine release.
+- Credentials for both platforms can be **remote, EAS-managed** — no local Mac or Xcode required for iOS
+  signing (Distribution Certificate, Provisioning Profile, Push Notifications key are all generated and
+  held by EAS), and no local Android keystore file required either.
+
+### Cross-platform lessons (apply to every release, either store)
+
+- **Never ship a native rebuild while a submission is in review** just to carry a JS-only change — it
+  can cost the queue position. Hold the change and ship it as an OTA update after the verdict lands.
+- **A reviewer's first cold launch must already be correct.** A review build has to carry the work
+  natively; it cannot rely on an OTA update being fetched, because of the next rule.
+- **OTA updates apply on the next launch, not the current one** — the client downloads in the background
+  and swaps on relaunch. Do not diagnose a "stuck" update until after two full quit-and-reopen cycles.
+- **🔴 Bundler transform caches do not key on `EXPO_PUBLIC_*` env vars.** On a persistent (self-hosted)
+  build runner, the cache survives between runs, so an update published to one channel can ship
+  another channel's inlined config — for example, a production build silently pointing at a development
+  API. Pass `--clear-cache` on the publish lane, and verify by comparing the published `launchAsset`
+  hashes across channels: identical hashes for two channels that differ by at least one env var is proof
+  of the defect. **A green publish/build step is not evidence here (`EV-02`)** — assert against the
+  actual published asset.
+- **When a feature is removed or renamed, both stores' screenshots and descriptions are in the blast
+  radius.** Store metadata outlives the code it depicts, and it's the first thing a reviewer opens.
+
+---
+
+## Apple App Store
+
+### Initial one-time setup
+
+1. Confirm Apple Developer Program enrollment is active.
+2. Create the App Store Connect app record: name, `{IOS_BUNDLE_ID}`, SKU, and user access.
+3. Set the `eas.json` build + submit profile structure shown in the preamble above, filling in
+   `{APPLE_ID_EMAIL}`, `{ASC_APP_ID}`, and `{APPLE_TEAM_ID}`.
+4. Generate remote, EAS-managed credentials (Distribution Certificate, Provisioning Profile, Push
+   Notifications key) — no local Mac or Xcode needed.
+5. Create an App Store Connect API key for non-interactive submits (choose EAS-managed vs.
+   manually-uploaded per the operator's preference).
+6. If App Store Connect already has this bundle ID linked and EAS's automatic capability sync fails
+   against it, toggle the affected capabilities manually in the Apple Developer console's Identifiers
+   page instead of retrying the automated sync.
+
+### Repeat deployments
+
+```bash
+eas build --platform ios --profile production
+eas submit --platform ios --profile production --latest
+```
+
+Build numbers auto-increment per the preamble's `eas.json` config — no manual version bump needed.
+Realistic wait times: build ~10-20 minutes; Apple's binary processing ~5-10 minutes before the build is
+visible in TestFlight. A build not yet visible immediately after `eas submit` reports success is
+ordinarily processing lag, not a failed submission — verify by checking TestFlight directly before
+concluding otherwise (`EV-06`).
+
+### Known pitfalls
+
+- **`Failed to patch capabilities: X ON, Y OFF`** — happens when an App Store Connect app is already
+  linked to the bundle ID and Apple rejects EAS's automatic capability sync. Fix: `EXPO_NO_CAPABILITY_SYNC=1`
+  as a build-time env var, combined with the manual capability toggle from setup step 6.
+- **`Command must be re-run to pick up new updates configuration`** — EAS auto-installs `expo-updates`
+  mid-build the first time it's needed. Simply re-run the exact same `eas build` command; no
+  configuration change is required on your end.
+- **A transient Apple "Internal Server Error" during App Store Connect API key creation** clears on a
+  simple retry — no code or configuration change needed.
+
+---
+
+## Google Play
+
+Read this before anything else: **passing review on one Google Play track never promotes the binary to
+any other track** (`MR-01`) — internal testing has no review at all, while closed, open, and production
+each require one independently.
+
+### Initial one-time setup
+
+1. Create the Google Play Console app listing.
+2. **Set the country/region list on every track you plan to release to, before building that release** —
+   a fresh production track starts with zero countries and fails with a generic, un-actionable error
+   otherwise (`MR-02`).
+3. Reuse the App Store's listing copy and screenshots as a starting point — it keeps the two stores
+   consistent — but re-review each asset against the actually shipped binary before publishing; a
+   screenshot advertising a since-removed feature is a common miss from blind reuse. Image dimensions
+   differ between stores, so assets need re-export, not re-invention.
+4. Set up a Google Play service account and reference its key from `eas.json`'s
+   `submit.production.android.serviceAccountKeyPath`.
+5. Complete the IARC content-rating questionnaire one question at a time, and re-read the full form
+   after any change to the app's category (`MR-04`).
+6. Complete the data-safety declaration using "leaves the device" as the collection test, and confirm it
+   agrees with the App Store's own App Privacy answers for the same app (`MR-05`).
+7. Provide reviewer/demo-account access — one working account per app, described in prose for any
+   additional account types (`MR-07`).
+8. If Android developer verification is pending, correct the public developer address at its D-U-N-S
+   source and let it propagate **before** confirming it in the Play console — confirming first locks in
+   whatever address is currently on file (`MR-11`). Start this early: verification has a hard deadline,
+   and D&B propagation can take days to weeks.
+
+### Repeat deployments
+
+```bash
+eas build --platform android --profile production
+eas submit --platform android --profile production --latest
+```
+
+**Saving a console edit is not submitting it** — Google Play stages edits until an explicit "send
+changes for review" (or "save and publish") action, each with its own confirmation dialog (`MR-03`). A
+workflow that stops at "Save" ships nothing.
+
+Observed review latencies, for expectation-setting: internal testing is instant (no review); a first
+closed-testing review is roughly one day; production review is quoted as "typically within 7 days," and
+materially faster when the identical binary already cleared a closed-track review. Treat a release not
+yet visible immediately after submission as this ordinary review latency, not a failure, absent a
+console error stating otherwise (`EV-06`).
+
+### Known pitfalls
+
+- **🔴 Play Console silently drops synthetic browser input.** Programmatic form input and coordinate
+  clicks frequently do not register — the control appears set, the save succeeds, and nothing persists
+  (seen on both app-access contact fields and country checkboxes). Before saving, read the page's own
+  state readout (a "Targeted (N)" filter chip, "Release notes provided for N languages," a track's
+  country-count summary); if the number disagrees with intent, hand the step to a human rather than
+  retrying the same automated input (`EV-01`/`EV-03`).
+- **The "no deobfuscation file" warning** appears on every release and is benign and permanent until
+  mapping-file upload is wired up — it is not a sign of a broken build (`MR-08`).
+- **🔴 The signing certificate an installed app presents can differ from every console page you'd
+  naturally check.** Play App Signing plus "automatic protection" can make anything keyed to a
+  `(package, SHA-1)` pair — Maps, Google Sign-In, App Links/`assetlinks.json` — fail on Play-delivered
+  installs while working on sideloads. Never infer the SHA-1; read it from `adb logcat` against an
+  actual Play-delivered install (`MR-09`, `EV-01`). Zero traffic in a provider's 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.
+- **Android OAuth clients are keyed to one `(package, SHA-1)` pair each** — a Play-signed install, an
+  upload-signed sideload, and a `.dev` variant each need their own client. New clients also ship with
+  "Enable custom URI scheme" off, which fails with a visible `Error 400: invalid_request` until toggled
+  on (`MR-10`).
+- **Audit what the built artifact actually declares** (`aapt2 dump permissions`, or an equivalent
+  manifest inspection) before submission — a dependency that's installed but no longer called still
+  contributes its permissions, and removing one means removing the dependency, re-verified against a
+  fresh build (`MR-12`).
+- **Android notification icons need a dedicated monochrome, white-on-transparent small icon**, shipped
+  in a build — there's no OTA path for this. A "broken" icon symptom should be checked in the
+  notification shade, not the heads-up banner, since some OEM skins legitimately omit the small icon
+  from banners only (`MR-13`).
+- **Android's native `AlertDialog` caps at three buttons.** A menu built on `Alert.alert` past that cap
+  silently loses the overflow — typically the *Cancel* row. Use a real bottom sheet instead for any menu
+  that could exceed three options (`MR-14`).
+- **Locale lists differ between the stores.** Release notes are per-language; resolve locale coverage
+  against each store's own catalogue rather than copying the other store's list (`MR-06`).
+
+---
+
+## Rules
+
+This spell defers entirely to
+[governance/mobile-release-standards.md](../../.arcane/governance/mobile-release-standards.md) for what
+each store-specific platform fact means and why, and to
+[governance/external-verification-standards.md](../../.arcane/governance/external-verification-standards.md)
+for how any claimed success is verified. Findings and steps in this spell cite rule IDs from both; they
+do not re-explain them. Where the two disagree with what this spell says to do, the governance docs win.
+
+## Related
+
+- **Consumes from:** whatever workflow builds and versions the app before deployment (in this
+  repository's own stack, `spell-implement`/`spell-ship`) — this spell deploys an already-built app to
+  the stores, it does not build the app's features.
+- [Mobile Release Standards](../../.arcane/governance/mobile-release-standards.md)
+- [External Verification Standards](../../.arcane/governance/external-verification-standards.md)

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

@@ -118,6 +118,7 @@ Determine the target file(s) for each item:
 | Speculative idea or future-facing concept             | `TODO.md` under `## Product Ideas` or the best matching section                    |
 | ADR candidate                                         | `DECISIONS.md` — flag it as pending, do not write the full ADR yet                 |
 | Journal-worthy context                                | `journal/` — propose a filename with today's date slug, do not create the file yet |
+| Finding sourced from a research report                | `TODO.md` under the matching section — cross-reference the report path (e.g., `— see docs/research/<slug>.md`) |
 | Business-specific execution item                      | Both `TODO.md` AND the relevant `{BUSINESS_ROOT}/<name>/overview.md` reference section  |
 
 ## Step 4 — Show Proposal

package/dist/index.js

@@ -290,7 +290,8 @@ var PROFILE_CONFIGS = [
       "universal-agent-rules",
       "spell-authoring-standards",
       "external-verification-standards",
-      "web-discoverability-standards"
+      "web-discoverability-standards",
+      "mobile-release-standards"
     ]
   }
 ];
@@ -452,6 +453,11 @@ var COMPONENTS = [
     description: "Search-engine and AI-assistant discoverability rules for web properties",
     files: [".arcane/governance/web-discoverability-standards.md"]
   },
+  {
+    name: "mobile-release-standards",
+    description: "Durable App Store / Google Play console and release-track facts consumed by spell-eas-store-deploy",
+    files: [".arcane/governance/mobile-release-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
@@ -562,7 +568,9 @@ var COMPONENTS = [
       ".github/prompts/spell-make-discoverable.prompt.md",
       ".claude/commands/spell-make-discoverable.md",
       ".github/prompts/spell-scry.prompt.md",
-      ".claude/commands/spell-scry.md"
+      ".claude/commands/spell-scry.md",
+      ".github/prompts/spell-eas-store-deploy.prompt.md",
+      ".claude/commands/spell-eas-store-deploy.md"
     ]
   },
   {