arcane-cli 0.29.3 → 0.29.5

package/dist/assets/.arcane/governance/agent-policies.md

@@ -49,13 +49,15 @@ Agent autonomy is gamified into ascending power levels. Each level grants broade
 | Magus     | Self-merge within approved scope (fast-forward only).                      |
 | Archmage  | Broadest autonomous authority within an approved repo.                     |
 
-Assign a default power level per agent × per repo. Human approval and commit governance still apply in interactive sessions.
+Assign a default power level per agent × per repo. **Enforcement: explicitly advisory prose (ARC-023) — no check verifies a level was assigned for every agent × repo pair.** Human approval and commit governance still apply in interactive sessions. **Enforcement: structured spell gate (ARC-023) — `spell-commit-work`'s execution-authority table requires exact operator approval for any interactive-context commit regardless of power level, gated by an approval-fingerprint check before `git commit` runs.**
 
 **Notes:**
 
 - Repo creation remains Spectator-level (human only), regardless of an agent's assigned power level.
 - Grant the lowest level that lets an agent do its job; promote only after an autonomous fix-verify loop is validated for that agent.
 
+**Enforcement: explicitly advisory prose (ARC-023) — both notes are operating conventions with no code check for repo-creation gating or promotion timing.**
+
 ---
 
 ## Solo-Operator Delegation Records (No Roster)
@@ -84,19 +86,19 @@ For exactly this case, record the grant explicitly instead, in `.arcane/delegati
 }
 ```
 
-- **Explicit:** a structured, git-tracked file — not prose buried in an unrelated document.
+- **Explicit:** a structured, git-tracked file — not prose buried in an unrelated document. **Enforcement: explicitly advisory prose (ARC-023) — nothing prevents an ad hoc delegation from still being written as free prose elsewhere; using this file is a recommended convention, not a checked requirement.**
 - **Listable:** `spell doctor` reads this file (when present) and reports every active delegation's
   scope and exclusion list. A missing file is a silent pass — a repo with no ad hoc grants has nothing
   to report.
 - **Revocable per repo:** revocation is the git-native act of editing or removing the entry and
-  committing — set `status` to `"revoked"` or delete the entry outright.
+  committing — set `status` to `"revoked"` or delete the entry outright. **Enforcement: executable check (ARC-023) — `checkDelegations` (`src/commands/doctor.ts`) reads `.arcane/delegations.json` and reports only entries with `status === "active"`, so a revoked entry silently drops out of `spell doctor`'s report; it verifies visibility, not the legitimacy of the scope itself.**
 - **Grants no new authority.** This mechanism does not permit anything `agent-policies.md` didn't
   already allow in principle (human execution required absent an explicit grant) — it only makes an
   existing kind of ad hoc grant explicit and discoverable instead of buried.
 - **No scaffold is shipped.** A delegation record is inherently repo-specific and starts empty for a
   fresh install — there is nothing generic to seed.
 - **Does not replace the roster-based matrix.** A repo with an installed roster still uses per-agent
-  power levels for standing authority; this is the parallel, lighter-weight path for repos without one.
+  power levels for standing authority; this is the parallel, lighter-weight path for repos without one. **Enforcement: explicitly advisory prose (ARC-023) — these notes describe the mechanism's scope; `.arcane/delegations.json` is parsed with an unchecked type assertion, not a runtime-validated schema, so nothing constrains a delegation's claimed scope or actions.**
 
 ---
 
@@ -106,7 +108,7 @@ Spawn rights are configured per agent. Use a small number of orchestrators; keep
 
 - **Orchestrators** delegate work to specialists and aggregate their results.
 - **Leaf nodes** perform a single role (development, QA, research, comms) and report results upward; they cannot spawn subagents.
-- Promote a leaf to an orchestrator only once its autonomous behavior is validated.
+- Promote a leaf to an orchestrator only once its autonomous behavior is validated. **Enforcement: explicitly advisory prose (ARC-023) — `spawn.can_spawn`/`spawn.spawnable_by` are schema-validated fields (`src/modules/agent-schema.ts`) when an agent definition declares them, but that only checks the declared value's shape; no code in this repo verifies a runtime actually honors the leaf/orchestrator split.**
 
 ---
 
@@ -120,13 +122,13 @@ Agents may integrate external tools and services through MCP (Model Context Prot
 
 **Access boundaries:** An agent may be intentionally denied access to one org/service while retaining access to another (a least-privilege split). Verify the split behaves as expected — the denied target should return an unauthorized error.
 
-**MCP change control rule:** Never enable a fully automatic write mode. Adding a new MCP server (new org, new service, new auth pattern) is a **Medium**-risk change — it requires explicit approval and a recorded decision if it changes the agent's reachable network surface.
+**MCP change control rule:** Never enable a fully automatic write mode. Adding a new MCP server (new org, new service, new auth pattern) is a **Medium**-risk change — it requires explicit approval and a recorded decision if it changes the agent's reachable network surface. **Enforcement: explicitly advisory prose (ARC-023) — `spell doctor`'s `checkMcpConfig` only validates that a configured `.mcp.json` server declares a numeric timeout; it does not check write-mode, per-agent scoping, access boundaries, or new-server change-approval.**
 
 ---
 
 ## Guiding Principle
 
-An agent is operational infrastructure. It executes defined tasks. It does not make business decisions, handle financial transactions without explicit approval, or access systems outside its defined scope.
+An agent is operational infrastructure. It executes defined tasks. It does not make business decisions, handle financial transactions without explicit approval, or access systems outside its defined scope. **Enforcement: explicitly advisory prose (ARC-023) — a framing statement of intent with no independent mechanical check; the specific prohibitions it summarizes are enforced (or not) where they recur below.**
 
 ---
 
@@ -138,7 +140,7 @@ When agents can be driven through remote channels (chat, messaging, CLI, IDE), a
 
 - A front-door orchestrator captures and triages remote requests.
 - A designated privileged executor handles high-risk runtime/config changes.
-- The orchestrator may execute low-risk documentation-only updates directly in approved paths.
+- The orchestrator may execute low-risk documentation-only updates directly in approved paths. **Enforcement: explicitly advisory prose (ARC-023) — this role split is an operating convention for remote-channel work with no code that checks it was followed.**
 
 ### Required Workflow
 
@@ -150,8 +152,8 @@ Every remote environment change follows this sequence:
 4. **Pre-change backup** — snapshot relevant config/artifacts before mutation.
 5. **Apply** — execute the scoped change (delegate high-risk to the privileged executor).
 6. **Verify** — run deterministic checks and report results.
-7. **Document** — update canonical docs (policy/runbook/journal/TODO/decisions as needed).
-8. **Commit proposal** — prepare a commit message and request explicit approval.
+7. **Document** — update canonical docs (policy/runbook/journal/TODO/decisions as needed). **Enforcement: explicitly advisory prose (ARC-023) — steps 1–7 are a general change-management sequence with no dedicated spell or check verifying each step ran.**
+8. **Commit proposal** — prepare a commit message and request explicit approval. **Enforcement: structured spell gate (ARC-023) — `spell-commit-work` Step 8 computes an approval fingerprint from the staged diff and proposed message and requires an authenticated operator response tied to that fingerprint before `git commit` runs.**
 
 ### Risk Classes
 
@@ -175,14 +177,14 @@ Each completed remote change should preserve traceability by recording:
 - rollback reference
 - links to updated docs and the proposed/approved commit
 
-When evidence cannot be captured in a single step, queue a TODO immediately and mark the change as partially complete.
+When evidence cannot be captured in a single step, queue a TODO immediately and mark the change as partially complete. **Enforcement: explicitly advisory prose (ARC-023) — a recommended record-keeping checklist with no code that verifies any of these fields were actually captured.**
 
 ### Commit Hygiene for Remote Changes
 
 - **Author identity:** commits are authored under the human owner's identity ({OPERATOR_EMAIL}).
 - **Agent identity:** record the acting agent ({AGENT_NAME}) and the model/provider used.
-- Use Conventional Commits format: `type(scope): description`.
-- Show the full proposed commit and obtain approval before executing `git commit`.
+- Use Conventional Commits format: `type(scope): description`. **Enforcement: explicitly advisory prose (ARC-023) — these three conventions are generated by `spell-commit-work`'s message-drafting steps, but nothing rejects a commit that skips them; `git-conventions.md` itself notes the format regex is "optional — not enforced by hooks."**
+- Show the full proposed commit and obtain approval before executing `git commit`. **Enforcement: structured spell gate (ARC-023) — the same `spell-commit-work` Step 8 approval-fingerprint gate cited above.**
 
 ---
 
@@ -195,7 +197,7 @@ To reduce friction without weakening security, agents must follow this behavior
 3. Only request operator clarification after in-scope discovery fails.
 4. Never probe paths outside approved roots.
 
-**Intent:** fail-closed on boundaries, but avoid unnecessary "no access" responses for already-approved locations.
+**Intent:** fail-closed on boundaries, but avoid unnecessary "no access" responses for already-approved locations. **Enforcement: explicitly advisory prose (ARC-023) — this discovery-before-escalation sequence and the approved-root boundary are behavioral guidance with no check in this repo verifying an agent stayed within them.**
 
 ---
 
@@ -207,11 +209,13 @@ Before meaningful autonomous work in any newly cloned repo, agents must verify c
 - `CLAUDE.md` and/or `.github/copilot-instructions.md` (agent instruction surface)
 - Any project-local contribution/architecture guidance docs
 
+**Enforcement: explicitly advisory prose (ARC-023) — `spell doctor`'s `checkSessionContinuity` verifies a different file set (`TODO.md`, `DECISIONS.md`, `ai-context/system-prompt-context.md`, `journal/.gitkeep`, for `spell-close-session`) and does not check for `README.md`/`CLAUDE.md`/contribution docs, so this bootstrap requirement has no executable backing.**
+
 ---
 
 ## Actionable Recommendation Policy
 
-Any recommendation that could lead to a **monetary cost, account creation, subscription, purchase, license, or irreversible action** must follow these guardrails.
+Any recommendation that could lead to a **monetary cost, account creation, subscription, purchase, license, or irreversible action** must follow these guardrails. **Enforcement: explicitly advisory prose (ARC-023) — this entire policy (the classification tiers, the six guardrails below, and the worked examples) depends on model judgment at generation time; no code in this repo checks that a recommendation was flagged, verified, or confirmed.**
 
 ### Classification
 
@@ -261,7 +265,7 @@ Permitted actions are agent- and deployment-specific. As a baseline, an agent ma
 - Read and write to designated business data directories when explicitly configured.
 - Read, flag, and queue operational workflows — never execute irreversible actions (fulfillment, publishing, payment) without approval.
 
-Define the concrete permitted-actions list per agent in that agent's configuration.
+Define the concrete permitted-actions list per agent in that agent's configuration. **Enforcement: explicitly advisory prose (ARC-023) — `tools.allowed`/`tools.denied` are schema-validated when present (`src/modules/agent-schema.ts`) but declaring them is optional, and nothing in this repo verifies a runtime actually restricts an agent to its declared list.**
 
 ---
 
@@ -275,6 +279,8 @@ Define the concrete permitted-actions list per agent in that agent's configurati
 - Modifying security-relevant configuration without human approval.
 - Using personal Git credentials or SSH keys — agents must use scoped, dedicated credentials.
 
+**Enforcement: explicitly advisory prose (ARC-023) — this deny list describes deployment/runtime hardening expectations; no check in this repo's own code observes agent process privileges, filesystem access, or credential usage at execution time.**
+
 ---
 
 ## Escalation Rules
@@ -286,11 +292,13 @@ If an agent encounters a situation outside its defined parameters, it should:
 3. Queue for human review.
 4. Not attempt to resolve ambiguity autonomously.
 
+**Enforcement: explicitly advisory prose (ARC-023) — a behavioral sequence with no code that verifies an agent actually stopped, logged, or queued for review.**
+
 ---
 
 ## Branch Discipline
 
-**Agents must never commit directly to main.** All work happens on topic branches. This prevents collisions when multiple agents or human operators work in parallel.
+**Agents must never commit directly to main. Enforcement: structured spell gate (ARC-023) — `spell-commit-work` Step 1 checks the current branch and stops before staging or committing if `main`/`master` is checked out against a usable remote, requiring a compliant topic branch first.** All work happens on topic branches. This prevents collisions when multiple agents or human operators work in parallel.
 
 **Required workflow for all agents:**
 
@@ -302,7 +310,7 @@ If an agent encounters a situation outside its defined parameters, it should:
 
    Example: `lafayette/feat/api-endpoint`, `merlin/docs/architecture-update`
 
-2. **Commit** with proper attribution (author identity + required trailers per your git conventions).
+2. **Commit** with proper attribution (author identity + required trailers per your git conventions). **Enforcement: structured spell gate (ARC-023) — `spell-commit-work` Steps 1, 4.5, and 8 gate this: Step 1's branch guard, Step 4.5's loader-validated execution-authority check, and Step 8's approval-fingerprint requirement before `git commit` executes.**
 
 3. **Sync with main before opening a PR** — always fetch and rebase on the latest `origin/main` before pushing or creating a PR, even if you think no one else has merged:
 
@@ -313,21 +321,21 @@ If an agent encounters a situation outside its defined parameters, it should:
    # If rebase is unrecoverable: git rebase --abort, report to operator
    ```
 
-   **Rule:** Never open a PR against a base that is ahead of your branch. Never push a branch with unresolved conflicts. Resolve locally — the PR must be clean and CI-green before review.
+   **Rule:** Never open a PR against a base that is ahead of your branch. Never push a branch with unresolved conflicts. Resolve locally — the PR must be clean and CI-green before review. **Enforcement: structured spell gate (ARC-023) — `spell-create-pull-request` Step 0's mandatory rebase guard (its Step 0.6) and `spell-commit-work` Step 9b both require a clean `git fetch origin && git rebase origin/<target>` before any PR-creation call, stopping for human resolution on conflict.**
 
 4. **Push the branch** to origin (after rebase).
 
 5. **Merge or queue** based on your power level — and merge by the mechanism your isolation primitive allows (ARC-028 R1):
    - **Magus+ power level, in the primary checkout:** self-merge via `git merge --ff-only`, push main, delete branch.
    - **Magus+ power level, in a linked worktree or a clone:** self-merge through the platform's PR merge instead. The authority is identical; only the mechanism changes, because a local ff-merge requires checking out `main` and another working tree already holds it. Power level decides *whether* you may merge without review; the isolation primitive decides *how*.
-   - **Below Magus:** push the branch, report the branch name, and queue for human merge.
+   - **Below Magus:** push the branch, report the branch name, and queue for human merge. **Enforcement: structured spell gate (ARC-023) — `spell-commit-work`'s execution-authority table and its Step 9 merge-authorization gate (and `spell-create-pull-request`'s Authorization Gate) resolve power level and `exec_allowed` through the EF-27 loader-validated roster before permitting self-merge; below-Magus or unresolved authority always downgrades to human completion.**
 
-6. **Delete the branch** (local and remote) after merge.
+6. **Delete the branch** (local and remote) after merge. **Enforcement: structured spell gate (ARC-023) — `spell-commit-work` Step 10 and `spell-close-session`'s branch-deletion step both require running the Same-Vantage-Point Check before a worktree-adjacent deletion; the vantage-point determination itself remains a manual judgment call, which `git-conventions.md` discloses as "not a code-level gate."**
 
 **Branch naming format:** `{agent-slug}/type/short-description`
 
 - The agent-slug prefix makes ownership obvious and prevents naming collisions.
-- Use standard commit types: `feat`, `fix`, `docs`, `refactor`, `chore`, etc.
+- Use standard commit types: `feat`, `fix`, `docs`, `refactor`, `chore`, etc. **Enforcement: explicitly advisory prose (ARC-023) — no check in this repo validates an agent branch name against this format (unlike session-branch naming, which `spell-open-session` does check).**
 
 **What happens if ff-only fails:** Another actor merged to main first. This should not happen if you followed step 3. If it does, rebase and retry — **from the primary checkout**, since this block checks out `main`:
 
@@ -350,8 +358,8 @@ When more than one agent may work in the same repository simultaneously:
 4. **Append-only progress logs.** Never overwrite or truncate `features/{id}-{slug}/progress.txt`. Use `>>`, not `>`.
 5. **Story ownership.** Only the agent assigned to a feature modifies that feature's `stories.json`. If the assigned agent does not match your slug, halt and report.
 6. **No cross-repo mutations without coordination.** If a story requires changes in two repos, complete and push one before starting the second. Never hold uncommitted changes across two repos simultaneously.
-7. **Merge window.** When two agents have PRs open for the same repo, the first to merge wins; the second must rebase before merging. The operator coordinates merge order if there are conflicts.
-8. **Working-tree vantage point (EF-33 / ARC-028 R7) — applies even to a solo agent, not only when multiple agents are active.** Listed here because it's the working-tree/multi-primitive dimension ARC-028 R7 defines, not because the hazard requires a second agent: a lone agent working through a bridged/remote mount hits the identical near-miss. All linked worktrees share one physical `.git` and `.git/config` — treat config-mutating operations as fleet-wide, not scoped to the worktree that ran them. Before any `git worktree prune`, `worktree remove`, `gc`, or branch deletion, confirm the target path from the *current process's own filesystem* (not just Git's own report) — a repository or its linked worktrees reached through a bridged/remote mount can report a live, healthy worktree as safe to prune with no error distinguishing "confirmed absent" from "not resolvable from here." See [governance/git-conventions.md](git-conventions.md) Same-Vantage-Point Check section for the full procedure, including how to establish that your own vantage point is trustworthy before relying on it.
+7. **Merge window.** When two agents have PRs open for the same repo, the first to merge wins; the second must rebase before merging. The operator coordinates merge order if there are conflicts. **Enforcement: explicitly advisory prose (ARC-023) — items 1-7 are multi-agent coordination conventions (branch/folder/story ownership, staleness checks, append-only logs, cross-repo sequencing, merge order) with no code in this repo that checks another agent honored them.**
+8. **Working-tree vantage point (EF-33 / ARC-028 R7) — applies even to a solo agent, not only when multiple agents are active.** Listed here because it's the working-tree/multi-primitive dimension ARC-028 R7 defines, not because the hazard requires a second agent: a lone agent working through a bridged/remote mount hits the identical near-miss. All linked worktrees share one physical `.git` and `.git/config` — treat config-mutating operations as fleet-wide, not scoped to the worktree that ran them. Before any `git worktree prune`, `worktree remove`, `gc`, or branch deletion, confirm the target path from the *current process's own filesystem* (not just Git's own report) — a repository or its linked worktrees reached through a bridged/remote mount can report a live, healthy worktree as safe to prune with no error distinguishing "confirmed absent" from "not resolvable from here." See [governance/git-conventions.md](git-conventions.md) Same-Vantage-Point Check section for the full procedure, including how to establish that your own vantage point is trustworthy before relying on it. **Enforcement: structured spell gate (ARC-023) — `spell-commit-work` Step 10 and `spell-close-session`'s worktree-deletion step both require running this check before a worktree-adjacent branch/worktree deletion; the vantage-point determination itself stays a manual judgment call, which `git-conventions.md`'s own Same-Vantage-Point Check section calls "a standing operational caution, not a code-level gate."**
 
 ---
 
@@ -370,7 +378,7 @@ When producing planning artifacts (PRD, architecture, stories.json, UX specs), a
 - The root of a code repo (e.g. alongside `src/`).
 - Temporary or unversioned locations.
 
-Planning artifacts are the reproducible source of truth — code can be regenerated from them. They must live in a git-tracked, governed location.
+Planning artifacts are the reproducible source of truth — code can be regenerated from them. They must live in a git-tracked, governed location. **Enforcement: explicitly advisory prose (ARC-023) — no check in this repo verifies where a PRD, architecture doc, or `stories.json` was actually written.**
 
 ---
 
@@ -392,6 +400,8 @@ Agents must place artifacts in the correct repository. Misrouting (e.g. code in
 3. **Delegation must include the target repo.** When an orchestrator delegates work, the delegation message must specify which repo the work targets. If ambiguous, ask the operator before delegating.
 4. **POC code** without a permanent home should go in an operator-designated repo or a new repo — never in the docs repo by default.
 
+**Enforcement: explicitly advisory prose (ARC-023) — these routing rules depend on the acting agent's own judgment about repo fit; nothing in this repo checks that an artifact landed in the repo this section prescribes.**
+
 ---
 
 ## PR Notification & Hygiene
@@ -404,21 +414,23 @@ Agents creating pull requests must ensure the operator is aware and that PRs do
 2. **PR title** follows Conventional Commits format: `type(scope): description`.
 3. **PR description** must include: summary of changes, rationale, verification steps, and any linked work item ID.
 
+**Enforcement: explicitly advisory prose (ARC-023) — `spell-create-pull-request` generates a title and description in this shape by default, but nothing rejects a PR opened without one.**
+
 ### PR Notification
 
-When an agent creates or updates a PR, notify the operator (routed through the orchestrator) with: repo name, PR link, work item ID (if any), and a one-line summary.
+When an agent creates or updates a PR, notify the operator (routed through the orchestrator) with: repo name, PR link, work item ID (if any), and a one-line summary. **Enforcement: explicitly advisory prose (ARC-023) — no check confirms the operator was actually notified.**
 
 ### PR Hygiene Cadence
 
-- **At the start of every session:** list all open PRs across repos; flag PRs older than 3 days as stale.
-- **7-day threshold:** PRs open longer than 7 days without activity are flagged for closure. The operator decides whether to merge, update, or abandon.
-- **After merge:** the merging actor (agent or human) deletes the source branch (local and remote).
+- **At the start of every session:** list all open PRs across repos; flag PRs older than 3 days as stale. **Enforcement: structured spell gate (ARC-023) — `spell-open-session`'s "Open PRs" step lists open PRs and flags them stale/overdue at these exact thresholds, though only when tracking mode is external/ADO and ADO MCP is available — it is not universal across every provider/session.**
+- **7-day threshold:** PRs open longer than 7 days without activity are flagged for closure. The operator decides whether to merge, update, or abandon. **Enforcement: structured spell gate (ARC-023) — the same `spell-open-session` step above flags PRs older than 7 days as overdue in the same pass.**
+- **After merge:** the merging actor (agent or human) deletes the source branch (local and remote). **Enforcement: structured spell gate (ARC-023) — the same `spell-commit-work` Step 10 / `spell-close-session` branch-deletion mechanism cited under Branch Discipline.**
 
 ---
 
 ## Hardening Baseline (Policy)
 
-This section defines the minimum hardening policy baseline for production operations. It is normative for runbooks and future automation.
+This section defines the minimum hardening policy baseline for production operations. It is normative for runbooks and future automation. **Enforcement: explicitly advisory prose (ARC-023) — every deny/allow list and hardening principle below describes deployment/runtime configuration for wherever an agent actually executes; this repository's own CLI code does not run agents or observe their runtime privileges, network exposure, or filesystem access, so none of it is independently checked here.**
 
 ### Execution Restriction Baseline
 

package/dist/assets/.arcane/governance/decision-documentation-standard.md

@@ -35,8 +35,8 @@ Arcane separates framework-level decisions from org-specific ones using two pref
 
 - If the decision would apply to any organization using Arcane, it is `ARC-NNN`.
 - If the decision is specific to how your organization operates, it is `ADR-NNN`.
-- When uncertain, default to `ADR-NNN` in ops; promote to `ARC-NNN` later if the decision proves framework-generic.
-- Never renumber existing entries in either sequence.
+- When uncertain, default to `ADR-NNN` in ops; promote to `ARC-NNN` later if the decision proves framework-generic. **Enforcement: explicitly advisory prose (ARC-023) — whether a decision is framework-generic enough for `ARC-NNN` (this rule and the two prefix-scoping rules above) is a judgment call; no script evaluates a decision's content to confirm the chosen prefix.**
+- Never renumber existing entries in either sequence. **Enforcement: explicitly advisory prose (ARC-023) — `scripts/check-distributed-adr-references.ts` only verifies that a bare `ADR-NNN` citation resolves to a heading declared in `framework-decisions.md` (and separately flags certain `ARC-NNN`/`EF-NNN` link forms as cross-repo hazards); it never checks that numbers are sequential, unique, or never reused.**
 
 ## Problem Statement
 
@@ -64,7 +64,7 @@ Arcane separates framework-level decisions from org-specific ones using two pref
 - Rejected alternatives (2-3 bullets: what was considered but not chosen)
 - **Deep dive link** (if companion doc exists): `[[path/to/detail-doc|Display Text]]`
 
-**Keep ADRs under 20 lines** (excluding frontmatter). Longer means detail should move to companion doc.
+**Keep ADRs under 20 lines** (excluding frontmatter). Longer means detail should move to companion doc. **Enforcement: explicitly advisory prose (ARC-023) — no script measures ADR entry length in DECISIONS.md; the Quarterly Review checklist below asks a human to check for long ADRs manually.**
 
 **Naming Impact Check:** If the decision introduces, changes, or retires a name (repo, project, product, agent, service), the ADR **must** include a "Naming impact" section that:
 
@@ -72,7 +72,7 @@ Arcane separates framework-level decisions from org-specific ones using two pref
 2. Confirms no collision with other entities
 3. Identifies any docs, scripts, or prompts that reference the old name
 
-This check was added after [[governance/rcas/RCA-001-naming-collision|RCA-001]] discovered that ADR-061 named a product without checking whether the ops repo already used that name.
+This check was added after [[governance/rcas/RCA-001-naming-collision|RCA-001]] discovered that ADR-061 named a product without checking whether the ops repo already used that name. **Enforcement: explicitly advisory prose (ARC-023) — no script or spell gate verifies that an ADR introducing a new name actually contains a "Naming impact" section or performed its three checks; `spell-scry` can run the grep-and-collision check manually, but nothing requires it before such an ADR is written.**
 
 ### Tier 2: Companion Detail Docs
 
@@ -243,13 +243,13 @@ Create "Related ADRs" section at the top of every companion doc:
 - [[DECISIONS#ADR-NNN|Git SSH Authentication decision]]
 ```
 
-**Rationale:** Creates bidirectional graph edges in Obsidian visualization. Clicking an ADR shows its authentication strategy companion; the companion links back to each related ADR.
+**Rationale:** Creates bidirectional graph edges in Obsidian visualization. Clicking an ADR shows its authentication strategy companion; the companion links back to each related ADR. **Enforcement: explicitly advisory prose (ARC-023) — no script verifies that a companion doc's "Related ADRs" section reciprocates an ADR's "Deep dive" link, or that every companion doc has one at all; the Anti-Patterns section below lists forgetting this link as a known failure mode with no automated catch.**
 
 ---
 
 ## Index-Free Discovery
 
-**No DECISIONS-INDEX.md required.** Discovery happens via:
+**No DECISIONS-INDEX.md required. Enforcement: explicitly advisory prose (ARC-023) — nothing prevents creating one, and no script verifies that the four discovery methods below actually surface a given decision.** Discovery happens via:
 
 1. **Obsidian Graph View:** Visual clusters show related docs
 2. **Wiki-link navigation:** Click ADR "Deep dive" link → companion doc → "Related ADRs" → back to other ADRs
@@ -287,6 +287,8 @@ Create "Related ADRs" section at the top of every companion doc:
 - If new companion doc needed, create it first, then add "Deep dive" link in ADR
 - If existing companion doc covers it, add new section to that doc + update "Related ADRs" list
 
+**Enforcement: explicitly advisory prose (ARC-023) — none of the editorial steps above (bumping `last_updated`, extracting detail past 20 lines, adding or updating "Deep dive"/"Related ADRs" links) is checked by any script; each depends on the editor remembering to do it.**
+
 ### Quarterly Review
 
 Every 3 months:
@@ -296,6 +298,8 @@ Every 3 months:
 - [ ] Verify Obsidian graph shows connected clusters (no isolated decision nodes)
 - [ ] Review "Future Considerations" sections in companion docs — any re-evaluation triggers?
 
+**Enforcement: explicitly advisory prose (ARC-023) — this is a manual checklist; no script detects orphaned companion docs, measures ADR length, verifies Obsidian graph connectivity, or reminds anyone to revisit "Future Considerations" sections.**
+
 ---
 
 ## Anti-Patterns (Don't Do This)
@@ -312,6 +316,8 @@ Every 3 months:
 
 ❌ **Putting rationale in journals instead of companion docs** — Journals are chronological session logs (narrative). Companion docs are topic-indexed reference (structured). Rationale goes in companion docs, linked from journals.
 
+**Enforcement: explicitly advisory prose (ARC-023) — no lint or script detects any of the six anti-patterns above (a stray `ADR-NNN-deep-dive.md` file, duplicated content, implementation steps in a companion doc, a companion doc for a simple decision, a missing bidirectional link, or rationale left in a journal); catching them depends on the writer's or a reviewer's judgment.**
+
 ---
 
 ## Evolution of This Standard
@@ -324,6 +330,8 @@ Every 3 months:
 4. Add entry to DECISIONS.md if decision-making process itself changes
 5. Announce in relevant channels (if the team expands beyond a single operator)
 
+**Enforcement: explicitly advisory prose (ARC-023) — no script or spell gate enforces this five-step process when this standard itself changes; it depends on the editor following it by discipline.**
+
 **Versioning note:** Per-business decisions follow this pattern — business-only decisions live in `ventures/{name}/DECISIONS.md` (unnumbered or business-prefixed); system/cross-business decisions stay in the root `DECISIONS.md`.
 
 ---

package/dist/assets/.arcane/governance/development-methodology.md

@@ -141,9 +141,11 @@ Child linkage rules:
 3. If the selected fallback type combination cannot be linked as parent/child in that process template, use `Related` links and prefix titles with logical level tags (for example: `[EPIC]`, `[FEATURE]`) to preserve intent.
 4. Never silently flatten hierarchy. Document fallback/link decisions in `execution-plan.md` notes.
 
+**Enforcement: explicitly advisory prose (ARC-023) — no script verifies the fallback order was followed or that `execution-plan.md` documents a link decision; compliance depends entirely on the executing agent's judgment.**
+
 ### GitHub Issues Conventions
 
-When `tracking_mode=external` and `external_provider=github`, resolve `{owner}/{repo}` from `git remote get-url origin` (or `.arcane.json`'s `github.repo` field if set) rather than assuming it matches the working directory name.
+When `tracking_mode=external` and `external_provider=github`, **resolve `{owner}/{repo}` from `git remote get-url origin` (or `.arcane.json`'s `github.repo` field if set) rather than assuming it matches the working directory name. Enforcement: explicitly advisory prose (ARC-023) — no script gates this resolution before issue-tracking commands run; a same-principle utility (`parseGitHubRemote` in `src/modules/platform-policy.ts`) exists but serves `doctor`'s branch-policy check, not this workflow.**
 
 GitHub Issues has no configurable work-item-type hierarchy the way Azure DevOps does — there is no process-template discovery step, and no equivalent to `az boards work-item-type list`. Use these substitutes instead:
 
@@ -194,6 +196,8 @@ Without this chain, agents make conflicting decisions across stories (e.g., one
 3. Check for missing test coverage, architecture violations, security issues
 4. Defer unrelated findings to a backlog (don't derail the current change)
 
+**Enforcement: explicitly advisory prose (ARC-023) — no script counts or verifies findings, and `spell-review.prompt.md`'s current Rules section has superseded item 1's minimum with "no finding quota... zero findings is a valid outcome," so this minimum should be read as superseded framing, not current spell behavior.**
+
 ### Append-Only Progress
 
 `progress.txt` is never edited, only appended. Each iteration adds:
@@ -248,6 +252,8 @@ The Arcane story schema for autonomous implementation:
 
 If the output is missing required tracking fields, `passes`, `assignedTo`, `priority`, or `testEvidence`, it is malformed and must be regenerated.
 
+**Enforcement: structured spell gate (ARC-023) — `spell-architect` step 5a self-checks every field and must regenerate before outputting if any is missing, and `spell-full-cycle` Phase 2 independently gates on the same schema completeness before proceeding to Phase 3; no external schema-validator script exists, so the check is agent-administered, not tool-verified.**
+
 ### Story Sizing
 
 Each story must be small enough to complete in one context window:
@@ -275,7 +281,7 @@ For features that should run end-to-end with minimal human intervention, use `sp
 spell-full-cycle = spell-plan → [spell-enchant] → spell-architect → [spell-implement → spell-test → spell-review]* → spell-ship
 ```
 
-The entire pipeline runs autonomously with a single human gate at PR approval. Includes optional PRD enchantment between Plan and Architect (runs automatically if any quality dimension scores Bronze, or if `--enchant` is specified). Requires three inputs: feature description, tracking configuration (`tracking_mode` and optional `external_provider`), and target repo. In ADO mode, include the ADO work item ID; in GitHub mode, include the issue number if one already exists. Each phase has built-in quality gates that halt the pipeline on failure rather than producing garbage for downstream phases.
+The entire pipeline runs autonomously with a single human gate at PR approval. Includes optional PRD enchantment between Plan and Architect (runs automatically if any quality dimension scores Bronze, or if `--enchant` is specified). Requires three inputs: feature description, tracking configuration (`tracking_mode` and optional `external_provider`), and target repo. In ADO mode, include the ADO work item ID; in GitHub mode, include the issue number if one already exists. **Each phase has built-in quality gates that halt the pipeline on failure rather than producing garbage for downstream phases. Enforcement: structured spell gate (ARC-023) — `spell-full-cycle.prompt.md` encodes explicit per-phase `Gate:` steps (e.g., Phase 4: "If coverage is below threshold or any acceptance criterion lacks a test, loop back to Phase 3... Maximum 2 coverage-fix loops before halting"; Phase 5: "If any HIGH severity finding exists, loop back to Phase 3... Maximum 2 review-fix loops before halting") plus a human/authority gate before merge.**
 
 See [.github/prompts/spell-full-cycle.prompt.md](../.github/prompts/spell-full-cycle.prompt.md) for the complete prompt.
 
@@ -299,7 +305,7 @@ spell-plan → [spell-enchant] → spell-scope → [spell-architect → spell-im
 
 Each epic then runs through its own Spell Loop cycle (architect → implement → test → review → ship).
 
-Before starting the next epic after a major output checkpoint (execution plan, architecture + stories, full test evidence, or ship recommendation), run `spell-commit-work` to preserve progress and checkpoint branch state.
+**Before starting the next epic after a major output checkpoint (execution plan, architecture + stories, full test evidence, or ship recommendation), run `spell-commit-work` to preserve progress and checkpoint branch state. Enforcement: explicitly advisory prose (ARC-023) — `spell-full-cycle.prompt.md`'s Rules section frames this as a recommendation ("recommend running `spell-commit-work` before starting the next epic"), and nothing blocks epic-start if it is skipped.**
 
 See [.github/prompts/spell-scope.prompt.md](../.github/prompts/spell-scope.prompt.md) for the complete prompt.
 
@@ -323,7 +329,7 @@ When GitHub Copilot, Claude in VS Code, or any other interactive AI tool (not an
 
 ### Rule: Interactive tools cannot self-validate
 
-A tool that writes code **must not** also run `spell-review` on that same code. This is the same constraint that prevents Lafayette from marking his own stories as passing. Specifically:
+A tool that writes code **must not also run `spell-review` on that same code. Enforcement: explicitly advisory prose (ARC-023) — no mechanism in this repo can detect that the same agent or session both wrote and reviewed a diff (no session-identity tracking exists); GitHub's own block on self-authored `CHANGES_REQUESTED` reviews operates on GitHub account identity, not agent/session identity, and this repo routinely reuses one account for both.** This is the same constraint that prevents Lafayette from marking his own stories as passing. Specifically:
 
 - Copilot sessions count as implementation (`spell-implement` equivalent)
 - `spell-test` must be run to produce test evidence before review

package/dist/assets/.arcane/governance/portable-bootstrap.md

@@ -15,7 +15,7 @@ Paste this entire file into any AI client (Claude web, ChatGPT, etc.) to give it
 
 **Arcane** — Operational documentation for running AI-automated businesses under {LLC_NAME} (owner: {OPERATOR_NAME}). Uses an agent runtime to automate operations across one or more ventures.
 
-**This is a documentation-only repository.** No build commands, test suites, or deployable code. Do not add automation without being asked.
+**This is a documentation-only repository.** No build commands, test suites, or deployable code. **Do not add automation without being asked. Enforcement: explicitly advisory prose (ARC-023) — no check blocks adding scripts, build tooling, or automation to this repo; compliance depends on agent judgment.**
 
 ## Environment
 
@@ -26,6 +26,8 @@ Paste this entire file into any AI client (Claude web, ChatGPT, etc.) to give it
 
 ## Non-Negotiable Rules
 
+**Enforcement note (ARC-023):** these 9 rules are a condensed restatement of `.arcane/governance/universal-agent-rules.md` rules 1-6, 10, 11, and 15 — see that file for each rule's full text and its authoritative enforcement-mode classification; this summary does not duplicate those classifications here, to avoid a second, driftable copy of the same information.
+
 1. **Never access an encrypted or cross-OS volume you are not authorized to touch.** This rule stands as defense-in-depth regardless of encryption status.
 2. **No root commands** unless explicitly scoped and justified.
 3. **No secrets on the command line.** Use env vars and `read -s`.
@@ -49,20 +51,20 @@ Paste this entire file into any AI client (Claude web, ChatGPT, etc.) to give it
 
 ## Where Documents Live
 
-- **Framework-managed standards:** `.arcane/governance/`. Spells reference this single installed layer; do not create a duplicate root `governance/` tree.
+- **Framework-managed standards:** `.arcane/governance/`. Spells reference this single installed layer; **do not create a duplicate root `governance/` tree. Enforcement: explicitly advisory prose (ARC-023) — no check scans a repo for a duplicate root-level `governance/` directory.**
 - **Project-owned orientation and continuity:** `README.md`, `project.md`, `TODO.md`, `DECISIONS.md`, `ai-context/`, and `journal/`. Arcane creates missing files once and preserves existing content.
 - **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.
+- **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. Enforcement: explicitly advisory prose (ARC-023) — that model is still an open backlog item (not yet built), so nothing currently blocks a direct edit; `arcane update` will just overwrite it silently on the next run.**
 
 ## 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.
+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. Enforcement: explicitly advisory prose (ARC-023) — no mechanism reads research-report prose to verify citation coverage or speculation marking.** 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.
+**Every doc uses YAML frontmatter: `title`, `audience` (human/ai/both), `last_updated`, `status` (draft/active/deprecated), `tags`. Enforcement: explicitly advisory prose (ARC-023) — no schema validates these frontmatter fields on arbitrary docs; `.arcane.json` manifest validation (`src/modules/manifest.ts`) covers only installation-config fields, not document frontmatter.** Use wiki-links (`[[filename]]`) for cross-references.
 
 ## Naming Tiers
 

package/dist/assets/.arcane/governance/product-excellence-standards.md

@@ -25,6 +25,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
 | **Dependency identification**    | External services, APIs, and decisions the feature depends on are listed                                           |
 | **Open questions documented**    | Unresolved items are captured — not ignored or assumed                                                             |
 
+**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
+
 ### 2. User Experience (UX)
 
 | Criterion              | Description                                                                                         |
@@ -38,6 +40,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
 | **Consistency**        | UI patterns, terminology, and behavior are consistent across features                               |
 | **Micro-interactions** | Transitions, hover effects, and subtle animations provide polish without slowing users down         |
 
+**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
+
 ### 3. Accessibility (WCAG 2.1 AA Baseline)
 
 | Criterion                 | Description                                                                        |
@@ -51,6 +55,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
 | **Motion sensitivity**    | Animations respect `prefers-reduced-motion`; no content-critical motion            |
 | **Text resizing**         | UI remains usable at 200% zoom                                                     |
 
+**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
+
 ### 4. Performance
 
 | Criterion                                         | Description                                                                |
@@ -63,6 +69,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
 | **Offline / degraded**                            | Define behavior when network is slow or unavailable (if applicable)        |
 | **Concurrent users**                              | Target number documented; load testing plan defined for > 100 concurrent   |
 
+**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
+
 ### 5. Security (Beyond OWASP Baseline)
 
 | Criterion                  | Description                                                                     |
@@ -76,6 +84,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
 | **Secret handling**        | No hardcoded secrets; all credentials via environment variables or secret store |
 | **Dependency scanning**    | Third-party packages audited for known vulnerabilities                          |
 
+**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
+
 ### 6. Responsive Design
 
 | Criterion                 | Description                                                           |
@@ -85,6 +95,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
 | **Layout adaptation**     | Content reflows appropriately — no horizontal scrolling on mobile     |
 | **Navigation adaptation** | Desktop nav collapses to mobile pattern (hamburger, bottom nav, etc.) |
 
+**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
+
 ### 7. Competitive Differentiation
 
 | Criterion                 | Description                                                                |
@@ -94,6 +106,8 @@ Define what "the best version of an app" means across every dimension — UX, ac
 | **Table-stakes coverage** | Features that users expect as standard for this category are all present   |
 | **Experience premium**    | At least one UX element that makes users think "this is well-made"         |
 
+**Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant` scores this dimension and generates enhancement suggestions but never blocks (the user has final say per its Rules section); `spell-scope`'s Quality Quick-Check treats a Bronze score here as a recommendation, not a gate.**
+
 ---
 
 ## Quality Profiles
@@ -160,7 +174,7 @@ If the user does not specify a profile, **Public MVP** is the default. Rationale
 | **Could-Add**    | Current score already meets or exceeds target; enhancement is aspirational |
 | **Won't-Add**    | Explicitly excluded regardless of profile                                  |
 
-**Override:** Security and Accessibility gaps are always at least Should-Add regardless of profile. A Bronze Security score is always Must-Add.
+**Override:** Security and Accessibility gaps are always at least Should-Add regardless of profile. A Bronze Security score is always Must-Add. **Enforcement: explicitly advisory prose (ARC-023) — `spell-enchant`'s own tier-assignment step and Rules section restate this override verbatim, so it is not purely aspirational text, but enforcement is still agent judgment during suggestion generation rather than a mechanical check; the user retains final approval over every addition, security and accessibility included.**
 
 ---
 

package/dist/assets/.arcane/governance/rca-process-standard.md

@@ -27,14 +27,18 @@ An RCA is **required** when any of these occur:
 | **Implicit decision detected** | A drift check or session applied a change that had no governing ADR |
 | **Integration failure from doc mismatch** | A playbook or script failed because docs disagreed with reality |
 
+**Enforcement: explicitly advisory prose (ARC-023) — no script or drift check detects decision reversals, naming collisions, multi-file corrections, or the other trigger conditions above, or confirms an RCA was opened when one applies; recognizing a trigger and initiating an RCA depends on human or agent judgment.**
+
 An RCA is **recommended** (but optional) for:
 - Repeated confusion in sessions about the same topic
 - A TODO item that was deferred and caused downstream problems
 - Any incident where the operator says "how did we end up here?"
 
+**Enforcement: explicitly advisory prose (ARC-023) — these are softer signals than the required triggers above; no script detects them, and opening an RCA here is left to human or agent judgment.**
+
 ## RCA Template
 
-Every RCA follows this structure. Artifacts are stored in `governance/rcas/` with the filename `RCA-NNN-short-slug.md` (sequential numbering, matching the related ADR when applicable).
+**Every RCA follows this structure. Artifacts are stored in `governance/rcas/` with the filename `RCA-NNN-short-slug.md` (sequential numbering, matching the related ADR when applicable). Enforcement: explicitly advisory prose (ARC-023) — no script validates RCA filenames, sequential numbering, or template structure.**
 
 ```markdown
 ---
@@ -117,7 +121,7 @@ When a trigger condition is met:
 
 - **Corrective actions** fix the immediate problem (e.g., rename the files, revert the change)
 - **Preventive actions** change the process so the problem can't recur (e.g., add a checklist item, amend a template, update a prompt)
-- Every preventive action must reference the specific governance doc, template, or prompt it modifies
+- **Every preventive action must reference the specific governance doc, template, or prompt it modifies. Enforcement: explicitly advisory prose (ARC-023) — no script verifies that a preventive action's Target Doc cites a real, specific governance path.**
 
 ### 4. Implement and Verify
 
@@ -126,8 +130,8 @@ When a trigger condition is met:
 
 ### 5. Close
 
-- Set RCA status to `active` (RCAs remain active as reference — they are not "resolved" and deleted)
-- Link the RCA from the related ADR using a "Deep dive" wiki-link
+- **Set RCA status to `active` (RCAs remain active as reference — they are not "resolved" and deleted). Enforcement: explicitly advisory prose (ARC-023) — no script checks RCA status fields or blocks deleting an RCA file.**
+- **Link the RCA from the related ADR using a "Deep dive" wiki-link. Enforcement: explicitly advisory prose (ARC-023) — `check-distributed-adr-references.ts` validates ADR-ID references and cross-repo link hazards but does not check for a "Deep dive" backlink from the ADR.**
 - Record a note in the session journal
 
 ## Severity Levels
@@ -138,7 +142,7 @@ RCAs do not have formal severity levels. The trigger conditions above determine
 
 - In interactive sessions: the human operator and AI agent collaborate on the RCA
 - For autonomous agent work: the agent flags the trigger condition and drafts the RCA for human review
-- RCAs are never auto-committed — they require human approval (same rule as all interactive commits per [[governance/git-conventions|Git Conventions]])
+- **RCAs are never auto-committed — they require human approval (same rule as all interactive commits per [[governance/git-conventions|Git Conventions]]). Enforcement: structured spell gate (ARC-023) — this restates universal-agent-rules.md rule 10 ("Never auto-commit during interactive sessions"), enforced by `spell-commit-work`'s Step 8, which computes an approval fingerprint over the staged diff and message and halts until an authenticated operator response is tied to it before `git commit` runs.**
 
 ## Artifact Location
 
@@ -153,5 +157,5 @@ governance/
 
 ## Maintenance
 
-- Review RCA preventive actions quarterly during `spell-check-drift` runs
-- If a preventive action proves ineffective (same class of problem recurs), update the RCA with a "Recurrence" section and strengthen the preventive action
+- **Review RCA preventive actions quarterly during `spell-check-drift` runs. Enforcement: explicitly advisory prose (ARC-023) — `spell-check-drift` has no RCA-specific detector; this cross-reference depends on the operator or agent remembering to do the review by hand.**
+- **If a preventive action proves ineffective (same class of problem recurs), update the RCA with a "Recurrence" section and strengthen the preventive action. Enforcement: explicitly advisory prose (ARC-023) — no script detects recurrence of the same class of problem; recognizing it depends on human or agent judgment.**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "arcane-cli",
-  "version": "0.29.3",
+  "version": "0.29.5",
   "description": "Arcane framework CLI — scaffold and manage governance files in consuming repositories",
   "keywords": [
     "arcane",