arcane-cli 0.29.2 → 0.29.4

package/dist/assets/.arcane/governance/agent-approved-paths.md

@@ -36,9 +36,9 @@ Define one block per agent. Each agent gets its own isolated workspace root, plu
 
 **Conventions:**
 
-- Each agent operates from its own `workspace-{agent}` root — never a shared tree — so concurrent agents don't collide.
-- Grant the narrowest access that lets the agent do its job (research agents: `Read-only`; builders: `Read/Write`).
-- The operator's primary working tree is never an approved agent path.
+- **Each agent operates from its own `workspace-{agent}` root. Enforcement: explicitly advisory prose (ARC-023) — this describes a convention for the operator's own agent-fleet setup; no check in this repository verifies that any agent actually runs from an isolated workspace root.** — never a shared tree — so concurrent agents don't collide.
+- **Grant the narrowest access that lets the agent do its job. Enforcement: explicitly advisory prose (ARC-023) — which access level counts as "narrowest" for a given agent is a judgment call; no check verifies the grant against actual job scope.** (research agents: `Read-only`; builders: `Read/Write`).
+- **The operator's primary working tree is never an approved agent path. Enforcement: explicitly advisory prose (ARC-023) — no check cross-references this file's approved-path rows against the operator's actual working-tree path to catch a violation.**
 
 ---
 
@@ -46,15 +46,15 @@ Define one block per agent. Each agent gets its own isolated workspace root, plu
 
 When a request targets a repo that is expected to be inside an approved root:
 
-1. Perform read-only discovery first (list/find/read).
-2. If path exists, continue task without asking for duplicate authorization.
-3. If not found, request the exact path from the operator.
-4. Do not search outside approved roots.
+1. **Perform read-only discovery first. Enforcement: explicitly advisory prose (ARC-023) — the same behavior universal-agent-rules.md rule 20 covers; no check verifies that an agent actually performs read-only discovery before proceeding.** (list/find/read).
+2. **If path exists, continue task without asking for duplicate authorization. Enforcement: explicitly advisory prose (ARC-023) — whether an agent treats prior discovery as sufficient and skips a redundant ask is a judgment call; no check verifies this occurred.**
+3. **If not found, request the exact path from the operator. Enforcement: explicitly advisory prose (ARC-023) — the same "before claiming no access" behavior universal-agent-rules.md rule 20 covers; no check verifies an agent actually asks rather than assuming access is absent.**
+4. **Do not search outside approved roots. Enforcement: explicitly advisory prose (ARC-023) — no check inspects an agent's actual filesystem access to confirm it stayed within approved roots.**
 
 ---
 
 ## Change Control
 
-- Add/remove paths only through documentation update in this file.
-- Reflect material scope changes in [[agents/agent-policies|agent-policies.md]].
-- If access boundaries meaningfully change risk posture, record an ADR.
+- **Add/remove paths only through documentation update in this file. Enforcement: explicitly advisory prose (ARC-023) — no check cross-references actual agent path grants against this document to catch an undocumented change.**
+- **Reflect material scope changes in [[agents/agent-policies|agent-policies.md]]. Enforcement: explicitly advisory prose (ARC-023) — whether a scope change is "material" enough to require an update, and whether the update happens, both depend on agent judgment; no check cross-validates this file against agent-policies.md.**
+- **If access boundaries meaningfully change risk posture, record an ADR. Enforcement: explicitly advisory prose (ARC-023) — `check:adr-references` verifies that ADR citations elsewhere resolve, not that a change to this file actually triggered a new ADR.**

package/dist/assets/.arcane/governance/agent-work-queue-model.md

@@ -18,6 +18,8 @@ Defines a single markdown-first queue for assigning work across businesses, whil
 - Queue rows include execution host and approval gate so autonomy stays explicit.
 - {BUSINESS_NAME} starts first; same structure extends to AcmeStore and other businesses.
 
+**This document specifies a queue design that has not been implemented anywhere in this codebase — no queue instance exists yet, and this document's own frontmatter is still `status: draft` (see the `## Next Action` section below). Enforcement: explicitly advisory prose (ARC-023) — every principle, field, and rollout step that follows is advisory guidance only, since no code, spell, or platform check exists yet to enforce any of it.**
+
 ---
 
 ## Queue Principles

package/dist/assets/.arcane/governance/authentication-strategy.md

@@ -24,16 +24,19 @@ This document provides rationale for authentication decisions across an agent ru
 - Bearer tokens (PATs, API keys) can be replayed if intercepted once
 - Prefer challenge/response authentication (SSH, OAuth) when available
 - When bearer tokens are required, store them as environment variables via a secret-reference pattern
+- **Enforcement: explicitly advisory prose (ARC-023) — these two practices govern a downstream operator's own authentication mechanism and secret storage; no code or spell in this repository observes which mechanism or pattern is actually used.**
 
 **2. Credential Isolation**
 - Each service/agent uses separate credentials with minimal required scope
 - Credentials stored outside version control (`.env`, system keychains, secret managers)
 - Rotation/revocation must be straightforward without config file changes
+- **Enforcement: explicitly advisory prose (ARC-023) — credential scoping, storage location, and rotation ease are properties of a downstream operator's own credential stores; no script in this repository inspects a consumer's `.env` files, keychains, or secret managers.**
 
 **3. Defense in Depth**
 - Authentication is one layer; combine with network isolation (loopback bind, VPN/tunnel)
 - Audit logging for all credential operations
 - Regular review of active credentials and permissions
+- **Enforcement: explicitly advisory prose (ARC-023) — network isolation, audit logging, and credential review are carried out entirely in the operator's own infrastructure; this repository ships no gateway, log pipeline, or scheduled check that observes them.**
 
 ## Authentication Contexts
 
@@ -47,6 +50,8 @@ This document provides rationale for authentication decisions across an agent ru
 - Private key remains local at `~/.ssh/id_*` (`600` permissions)
 - Git remote configured to use the SSH URL
 
+**Enforcement: explicitly advisory prose (ARC-023) — this decision and its mechanism and implementation-notes steps configure a downstream operator's own Git host account and local filesystem; Arcane ships no code that checks which credential type is registered with the Git host or that verifies key-file permissions.**
+
 **Why SSH Over PAT:**
 
 1. **Bearer Token Replay Risk**
@@ -95,6 +100,8 @@ This document provides rationale for authentication decisions across an agent ru
 - Store the key as an environment variable (e.g. in a `.env` file)
 - Reference it in config via a secret-reference rather than embedding the value
 
+**Enforcement: explicitly advisory prose (ARC-023) — this decision and its mechanism and implementation-notes steps configure a downstream operator's own model-provider account and local secret storage; Arcane ships no code that verifies key scope, storage location, or file permissions.**
+
 **Why Scoped Keys Over Personal Keys:**
 
 1. **Organizational Boundary**
@@ -132,6 +139,8 @@ This document provides rationale for authentication decisions across an agent ru
 - Reference it from config rather than embedding the literal value
 - Require it in the HTTP header: `Authorization: Bearer <token>`
 
+**Enforcement: explicitly advisory prose (ARC-023) — this decision and its mechanism and implementation-notes steps describe a gateway component operated outside this repository; Arcane's own codebase contains no gateway server to bind an address, validate a token, or enforce this header requirement.**
+
 **Why Token Auth:**
 
 1. **Stateless Authentication**
@@ -187,6 +196,8 @@ auth = { provider = "token", token = { source = "env", id = "SECRET_NAME" } }
 SECRET_NAME=actual-secret-value-here
 ```
 
+**Enforcement: explicitly advisory prose (ARC-023) — Arcane ships no config-schema validator or lint rule in this repository that checks a downstream repo's config for inline secrets versus this reference pattern; adoption depends on the operator's own discipline.**
+
 **Benefits:**
 - Config files are version-controlled without exposing secrets
 - Secrets are rotated by editing the secret store only (no config changes)
@@ -212,6 +223,8 @@ Regular review (quarterly):
 - [ ] Grep the codebase for hardcoded secrets (should find zero matches)
 - [ ] Review the security audit log for any anomalous credential operations
 
+**Enforcement: explicitly advisory prose (ARC-023) — this checklist runs on operator judgment and cadence; no scheduled task, spell gate, or CI check in this repository executes or verifies these items.**
+
 ---
 
 ## References

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/hardening-checklist.md

@@ -20,6 +20,8 @@ Step-by-step hardening for a Linux host that will run an autonomous agent runtim
 
 See also: [Threat Model](threat-model.md), [Authentication Strategy](authentication-strategy.md)
 
+**Enforcement: explicitly advisory prose (ARC-023) — every item below configures a downstream operator's own Linux host, a target outside anything Arcane's own CI or spells can inspect; completion is tracked only in the operator's own security audit log, not by any Arcane mechanism.**
+
 ---
 
 ## Pre-Checklist: Know Your Environment

package/dist/assets/.arcane/governance/naming-conventions.md

@@ -24,9 +24,9 @@ How machines, AI agents, and systems are named across your projects. This is a *
 
 Two rules govern every name in the system.
 
-**The Naming Test:** if an established industry term exists for the thing, use the real term — a universe name has to be *earned* by the absence of one. Two dialects result: magic grammar for the personas and vocabulary, plain functional payloads for everything technical. Corollary: the more autonomous the tool, the more boring its name should be.
+**The Naming Test:** if an established industry term exists for the thing, use the real term — a universe name has to be *earned* by the absence of one. Two dialects result: magic grammar for the personas and vocabulary, plain functional payloads for everything technical. Corollary: the more autonomous the tool, the more boring its name should be. **Enforcement: explicitly advisory prose (ARC-023) — whether a real industry term already exists is a judgment call; no check screens a candidate name against this test.**
 
-**The IP rule:** persona names must be **public domain or your own coinage**. No living people. No franchise-coined characters — a borrowed name is owned by whoever coined it, no matter how well it fits. Before any name ships, run the four checks: who coined it; does an estate still do business in it; do same-audience products already claim it (search live — don't trust memory); and what is its first association in each market you operate in, said aloud in every language your team speaks.
+**The IP rule:** persona names must be **public domain or your own coinage**. No living people. No franchise-coined characters — a borrowed name is owned by whoever coined it, no matter how well it fits. Before any name ships, run the four checks: who coined it; does an estate still do business in it; do same-audience products already claim it (search live — don't trust memory); and what is its first association in each market you operate in, said aloud in every language your team speaks. **Enforcement: explicitly advisory prose (ARC-023) — the four checks depend on human judgment and live research; `spell-scry` can perform this exact check but nothing requires it before an agent name is assigned, and the naming step in `src/modules/naming.ts` validates only that a typed name is non-empty.**
 
 Names should be memorable, distinctive, and never repeated across categories.
 
@@ -70,6 +70,7 @@ Agents get persona names paired with a role. The persona name is the primary ide
 - An agent may serve multiple projects but keeps the same name and role everywhere.
 - If an agent's role changes significantly, it gets a new name (don't reuse names for different roles).
 - If you collaborate with other operators who run their own Arcane instances, reserve names across instances so they don't collide.
+- **Enforcement: explicitly advisory prose (ARC-023) — no code checks persona-name uniqueness within a roster, across projects, or across Arcane instances; `agent-schema.ts`'s roster validation checks each entry's shape only.**
 
 ### Default Roster (Arcane personas)
 
@@ -107,9 +108,9 @@ The table above is the human-readable roster; agent definitions (`agents/*.yaml`
 
 **Role consolidation (ADR-031):** Framework-specific dev roles (.NET, Blazor, React, Flutter, MAUI) are consolidated into generic roles (Full-Stack, Frontend, Mobile). The framework/stack is a prompt parameter, not an agent identity. This scales without needing a new agent for every technology.
 
-**Naming policy:** All agent names should be positive characters — beings, not objects — with a clear thematic connection to their role.
+**Naming policy:** All agent names should be positive characters — beings, not objects — with a clear thematic connection to their role. **Enforcement: explicitly advisory prose (ARC-023) — character and tone are a judgment call; `agent-schema.ts` validates that a name is a non-empty string, not its thematic content.**
 
-**Canonical agent identity domain:** Use a single domain for all agent and tool Git identities — e.g., `merlin@{OPERATOR_DOMAIN}`. See [[DECISIONS#ADR-028|ADR-028]] for the full attribution model.
+**Canonical agent identity domain:** Use a single domain for all agent and tool Git identities — e.g., `merlin@{OPERATOR_DOMAIN}`. See [[DECISIONS#ADR-028|ADR-028]] for the full attribution model. **Enforcement: explicitly advisory prose (ARC-023) — no commit-trailer or identity check verifies that every agent/tool email shares one domain; `git-conventions.md`'s Required Commit Trailers table validates trailer presence, not the author-email domain.**
 
 ### Power Levels (ADR-032)
 

package/dist/assets/.arcane/governance/new-business-setup.md

@@ -38,6 +38,8 @@ Have the following ready:
 
 ## Phase 1 — Project & Repo Setup
 
+**Every step in this phase is performed by hand in your version-control host's UI. Enforcement: explicitly advisory prose (ARC-023) — project, repo, and template creation happen entirely on the external VCS host, which no script or CI check in this repo observes or verifies.**
+
 ### Step 1.1 — Create the Project
 
 1. Open your version-control host's project organization
@@ -82,6 +84,8 @@ In your docs/ops repo, copy `ventures/_template/` to `ventures/{venture}/` as a
 
 ## Phase 2 — Infrastructure & Security
 
+**The security checklist and docs-repo clone in this phase are unverified operator actions. Enforcement: explicitly advisory prose (ARC-023) — no script or CI check in this repo confirms these steps were completed or completed correctly.**
+
 ### Step 2.1 — Confirm Security Baseline
 
 Before running the agent runtime for any new business, verify:
@@ -101,6 +105,8 @@ git clone <docs-repo-url> ~/code/{repo}
 
 ## Phase 3 — Agent Runtime Configuration
 
+**Steps 3.1, 3.2, and 3.4 (runtime install, configuration, and the dry-run test) are manual operator actions. Enforcement: explicitly advisory prose (ARC-023) — no script or CI check in this repo verifies the agent runtime was installed, configured, or dry-run tested before live use.**
+
 ### Step 3.1 — Install the Agent Runtime (if not already installed)
 
 See [[agents/installation|Runtime Installation]].
@@ -113,6 +119,8 @@ See [[agents/installation|Runtime Installation]].
 
 ### Step 3.3 — Agent Git Identity Setup
 
+**Registering an agent's persona, Git identity, and `.mailmap` entry, and running the verify command below, are self-administered. Enforcement: explicitly advisory prose (ARC-023) — no script or CI check validates `.mailmap` entries or roster registration; the verify command is a manual smoke test, distinct from `spell-commit-work`'s Step 8 gate, which governs the commit action itself, not agent registration.**
+
 Every agent that will produce commits for this business must have a registered Git identity **before making its first commit**. See [[git-conventions#agent-attribution-model|Git Conventions — Agent Attribution]].
 
 For each agent assigned to this business:
@@ -141,6 +149,8 @@ Run the agent runtime in dry-run / observation mode first. Do not let it execute
 
 ## Phase 4 — Legal Baseline
 
+**Every step in this phase happens outside Arcane — entity structuring, tax registration, and ToS review. Enforcement: explicitly advisory prose (ARC-023) — these are legal and tax determinations on external systems that no script or CI check in this repo can observe or verify.**
+
 ### Step 4.1 — Business Entity
 
 - Confirm operations run under {LLC_NAME}
@@ -161,6 +171,8 @@ Run the agent runtime in dry-run / observation mode first. Do not let it execute
 
 ## Phase 5 — First Launch Checklist
 
+**This launch checklist is self-attested against external systems (the selling platform, the agent runtime's monitoring). Enforcement: explicitly advisory prose (ARC-023) — no script or CI check in this repo confirms any item below; the operator marks each complete by judgment.**
+
 - [ ] At least 10 product listings live (or equivalent for non-e-commerce)
 - [ ] Order/fulfillment workflow tested end-to-end
 - [ ] The agent runtime running and monitored (see `agents/monitoring.md`)

package/dist/assets/.arcane/governance/poc-management-pattern.md

@@ -34,7 +34,7 @@ ventures/        Prototypes      features/     business repo
 
 #### Concept (`ventures/<name>/`)
 
-The permanent record of every idea — good, bad, or deferred. Ideas are **never deleted**. Frontmatter `status` tracks where each idea is in its lifecycle.
+The permanent record of every idea — good, bad, or deferred. Ideas are **never deleted**. **Enforcement: explicitly advisory prose (ARC-023) — no code in this repo checks for or blocks deletion of files under `ventures/<name>/`; this depends on human/agent discipline.** Frontmatter `status` tracks where each idea is in its lifecycle.
 
 **Required files:**
 - `overview.md` — What is it? Why does it matter? Who is it for? (Minimum viable concept doc.)
@@ -45,7 +45,7 @@ The permanent record of every idea — good, bad, or deferred. Ideas are **never
 - `stories.json` — If architecture produced story breakdown
 - Screenshots in `assets/screenshots/YYYY-MM-DD/` (linked from docs)
 
-**What does NOT belong here:** Code files (`.js`, `.ts`, `.py`, `.html`, `.css`, etc.). The docs repo is a documentation-only repository.
+**What does NOT belong here:** Code files (`.js`, `.ts`, `.py`, `.html`, `.css`, etc.). The docs repo is a documentation-only repository. **Enforcement: explicitly advisory prose (ARC-023) — [[governance/agent-policies|Agent Policies]]'s repo-routing rule states the general version of this restriction; this file restates it for the docs repo specifically rather than asserting independent enforcement, and no lint/CI check here rejects code file extensions.**
 
 #### Prototype (Prototypes repo)
 
@@ -57,7 +57,7 @@ Small, self-contained, throwaway code that demonstrates a concept. Prototypes ar
 
 **Folder convention:** `<name>/` at repo root (e.g., `magic-prompt/`, `self-healing-poc/`)
 
-**No governance overhead:** No PRs required, no work items, no branch policies. This is a sandbox. Commit directly to main.
+**No governance overhead:** No PRs required, no work items, no branch policies. This is a sandbox. Commit directly to main. **Enforcement: explicitly advisory prose (ARC-023) — this is a deliberate low-ceremony policy choice, not a constraint with a pass/fail check to enforce.**
 
 #### Feature (`features/{id}-{slug}/`)
 
@@ -116,7 +116,7 @@ Ideas evolve. Track iterations without complex versioning:
 
 2. **Screenshots:** Save evidence of each meaningful state to `assets/screenshots/YYYY-MM-DD/` per [[assets/screenshots/README|screenshot conventions]]. Link from the changelog.
 
-3. **Git history is the version control.** Don't create `v1/`, `v2/` folders. The idea folder is a living document — git tracks every change.
+3. **Git history is the version control.** Don't create `v1/`, `v2/` folders. The idea folder is a living document — git tracks every change. **Enforcement: explicitly advisory prose (ARC-023) — no check inspects idea folders for `v1/`/`v2/`-style version directories; this depends on human/agent discipline.**
 
 ---
 
@@ -128,10 +128,10 @@ No formal gate. If someone (human or agent) wants to see the idea running, gener
 
 ### Concept/Prototype → Feature
 
-All of these must be true:
+All of these must be true: **Enforcement: explicitly advisory prose (ARC-023) — no spell checks these four criteria before a `status: promoted` transition; `spell-plan` satisfies only the fourth criterion (a PRD exists) and does not gate the others, and `spell-manifest`'s promotion flow uses a separate idea-book status marker, not this file's ventures frontmatter.**
 - [ ] A tracker work item exists (User Story or Feature)
 - [ ] A business track owns it (maps to a `ventures/<name>/` folder or a project)
-- [ ] A target code repo exists (or needs to be created; repo creation is human-only)
+- [ ] A target code repo exists (or needs to be created; repo creation is human-only) **Enforcement: explicitly advisory prose (ARC-023) — [[governance/agent-policies|Agent Policies]] is the canonical statement of this rule (Spectator-level, human-only); this restates it rather than asserting independent enforcement, and no code under `src/commands/` implements repo creation for a check to gate in the first place.**
 - [ ] The idea has at least a PRD (`spell-plan` output)
 
 When promoted: update the idea's frontmatter to `status: promoted` with `promoted_to` metadata. The idea folder stays in arcane forever as the historical record.
@@ -166,7 +166,7 @@ In the vibe coding era, a well-written spec can regenerate a prototype in minute
 |---|---|
 | [[governance/development-methodology\|Spell Loop]] | Ideas enter the loop at `spell-plan`. Concept stage is pre-loop exploration. |
 | Repo routing | Code → code repos. Docs → the docs repo. Prototypes → Prototypes repo. |
-| Repo governance | Repo creation is human-only. Prototypes repo is a single shared repo, not per-POC. |
+| Repo governance | Repo creation is human-only. **Enforcement: explicitly advisory prose (ARC-023) — [[governance/agent-policies\|Agent Policies]] is the canonical statement of this rule; this table restates it rather than asserting independent enforcement.** Prototypes repo is a single shared repo, not per-POC. |
 | Feature folders | Feature planning artifacts live in the target code repo under `features/`. |
 | `ventures/<name>/` | Business-level docs for shipped products. Ideas that graduate here are fully promoted. |
 

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/dist/assets/.arcane/governance/records-conventions.md

@@ -64,16 +64,16 @@ superseded_by: path/to/replacement.md
 
 Rules:
 
-- `superseded_by` is required. A tombstone that does not say what replaced it is
+- **`superseded_by` is required. Enforcement: explicitly advisory prose (ARC-023) — no script checks a superseded document's frontmatter for this field.** A tombstone that does not say what replaced it is
   worse than no tombstone: it tells the reader to stop without telling them
   where to go.
-- If a document was superseded by *several* documents, list all of them.
-- If a document was retired without replacement, say so explicitly
-  (`superseded_by: none — <reason>`), rather than leaving the field off.
-- Do not delete the original content. The tombstone is a header, not a
+- **If a document was superseded by *several* documents, list all of them. Enforcement: explicitly advisory prose (ARC-023) — no script cross-checks the list against the document's actual replacements.**
+- **If a document was retired without replacement, say so explicitly
+  (`superseded_by: none — <reason>`), rather than leaving the field off. Enforcement: explicitly advisory prose (ARC-023) — no script distinguishes this explicit form from an omitted field.**
+- **Do not delete the original content. Enforcement: explicitly advisory prose (ARC-023) — no diff check runs when a tombstone is added, so nothing confirms the body underneath is untouched.** The tombstone is a header, not a
   replacement for the body.
-- **Add the reverse link on the replacement**, so the relationship is
-  discoverable from either end. A reader who finds only the current document
+- **Add the reverse link on the replacement, so the relationship is
+  discoverable from either end. Enforcement: explicitly advisory prose (ARC-023) — no script checks that a `supersedes` field exists on the named replacement.** A reader who finds only the current document
   should still be able to see what it replaced:
 
   ```yaml
@@ -91,7 +91,7 @@ Supersession and deletion are different decisions and must not be conflated.
 Marking a document superseded is a routine editorial act. Deleting it is not.
 
 **Deletion is prohibited without an explicit, recorded decision when any of the
-following is true:**
+following is true. Enforcement: explicitly advisory prose (ARC-023) — none of the four conditions below is checked by a script; `content_sensitivity`'s value is schema-validated, but nothing gates deletion on it.**
 
 - The document records a decision, agreement, or obligation that other parties
   relied on.
@@ -101,8 +101,8 @@ following is true:**
 - The repository is marked `content_sensitivity: sensitive` and the document's
   own existence is part of the record.
 
-When deletion *is* approved, record it: what was deleted, when, on whose
-authority, and why. A deletion nobody can account for later is indistinguishable
+**When deletion *is* approved, record it: what was deleted, when, on whose
+authority, and why. Enforcement: explicitly advisory prose (ARC-023) — no script checks that a deletion record exists after the fact.** A deletion nobody can account for later is indistinguishable
 from data loss.
 
 **Arcane does not ship a retention schedule.** Retention periods are

package/dist/assets/.arcane/governance/threat-model.md

@@ -50,7 +50,7 @@ See also: [Hardening Checklist](hardening-checklist.md), [Authentication Strateg
 | Supply chain (package installs) | **Mitigated** | Global package installs use a user-owned directory, not a system directory. No `sudo` during install. |
 | Inter-machine communication | **Mitigated** | Encrypted mesh tunnel/VPN. No direct unencrypted LAN communication. |
 | Token/credential exposure (at rest) | **Mitigated** | Token stored as an env var in a `.env` file. Config uses a secret reference, not plaintext. State directory is mode `700`. |
-| Credential committed to version control | **Not mitigated** | Storage conventions are documented (secret references, `.gitignore` entries for `.env`/`*.pem`/`*.key`) but **no detection exists** — no scanner runs on the commit path, the push path, or in CI, and nothing verifies the conventions were followed. `spell-security-review`'s secrets step is an on-demand agent read, not a control. Treat every credential that reaches a commit as compromised and rotate it — history, existing clones, and remote backups all survive deleting the file (EF-35). |
+| Credential committed to version control | **Not mitigated** | Storage conventions are documented (secret references, `.gitignore` entries for `.env`/`*.pem`/`*.key`) but **no detection exists** — no scanner runs on the commit path, the push path, or in CI, and nothing verifies the conventions were followed. `spell-security-review`'s secrets step is an on-demand agent read, not a control. **Treat every credential that reaches a commit as compromised and rotate it — history, existing clones, and remote backups all survive deleting the file (EF-35). Enforcement: explicitly advisory prose (ARC-023) — rotating a leaked credential happens at the third-party provider that issued it; no Arcane mechanism can perform or verify that a specific credential was actually rotated.** |
 
 ---
 
@@ -94,11 +94,11 @@ This policy defines which collaborators can access which project data. Enforce b
 
 ### Enforcement
 
-- Project-level isolation is the primary boundary: each business is a separate project with its own access control.
-- A partner's access is limited to a single business's project, through a dedicated org only.
-- An operations co-owner receives access only to their business's project and relevant platform accounts — not to infrastructure configs.
-- System-level and multi-business reference documentation stays private to the owner unless explicitly shared.
-- New collaborator access requires an explicit entry in this table and an entry in the security audit log.
+- **Project-level isolation is the primary boundary: each business is a separate project with its own access control. Enforcement: explicitly advisory prose (ARC-023) — isolation depends on the owner actually configuring separate platform projects/repos with distinct access control; `spell doctor`'s `checkPlatformBranchPolicy` (src/modules/platform-policy.ts) verifies only branch merge-method policy and `checkDelegations` (src/commands/doctor.ts) verifies only agent power-level delegations, so no Arcane check queries collaborator or team membership to verify a given business's project is actually isolated.**
+- **A partner's access is limited to a single business's project, through a dedicated org only. Enforcement: explicitly advisory prose (ARC-023) — depends on the owner correctly scoping the partner's platform account to a single org; no Arcane check inspects collaborator or team membership to verify a partner's actual access is so limited.**
+- **An operations co-owner receives access only to their business's project and relevant platform accounts — not to infrastructure configs. Enforcement: explicitly advisory prose (ARC-023) — depends on the owner correctly scoping platform-account grants; no Arcane check inspects collaborator permissions to verify infrastructure configs are actually excluded.**
+- **System-level and multi-business reference documentation stays private to the owner unless explicitly shared. Enforcement: explicitly advisory prose (ARC-023) — depends on the owner's manual sharing decisions; no Arcane check inspects document visibility or sharing state to verify this boundary holds.**
+- **New collaborator access requires an explicit entry in this table and an entry in the security audit log. Enforcement: explicitly advisory prose (ARC-023) — a manual documentation discipline; no Arcane check verifies this table was updated or that a corresponding security audit log entry exists, and the security audit log itself is a manual record referenced across governance docs, not a system Arcane reads or writes.**
 
 ---
 

package/package.json

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