arcane-cli 0.29.1 → 0.29.3

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/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/spell-authoring-standards.md

@@ -21,22 +21,26 @@ wiki-link** (corrected 2026-08-31, BC-06) — this file ships to consumer repos,
 `DECISIONS.md` does not: `src/assets/DECISIONS.md` (what consumers actually receive via
 `spell init`) is an empty starter template for the *consumer's own* decisions, so a
 same-repo wiki-link to a specific ARC id would resolve to the wrong document once
-installed, not simply fail to resolve.
+installed, not simply fail to resolve. **Enforcement: explicitly advisory prose (ARC-023)
+— depends on editorial judgment; no mechanical check verifies citation style in this file.**
 
 ## The Spell Quality Rubric
 
 Eight dimensions. Each is scored **Bronze (1) / Silver (2) / Gold (3)**. A spell's **overall score is
 its weakest dimension** (same weakest-link rule as the PRD scorecard) — a Gold workflow with a Bronze
-safety rail is a Bronze spell.
+safety rail is a Bronze spell. **Enforcement: explicitly advisory prose (ARC-023) — self-graded during
+spell audit; no coded scorer computes or verifies this aggregation.**
 
 Two dimensions are **hard gates**: **D2 Distributability** and **D7 Safety** must be **≥ Silver** for a
-spell to ship, regardless of overall target.
+spell to ship, regardless of overall target. **Enforcement: explicitly advisory prose (ARC-023) — self-graded
+during spell audit; only D2's Bronze floor (literal org-name detection) is mechanically checked today, so
+this broader ≥ Silver gate is not fully verified by any coded scorer or workflow gate.**
 
 ### D1 — Front-matter & invocation contract
 
 | Tier | Bar |
 | --- | --- |
-| Bronze | Front-matter complete: `name`, `description`, `argument-hint`, `agent`. |
+| Bronze | Front-matter complete: `name`, `description`, `argument-hint`, `agent`. Enforcement: explicitly advisory prose (ARC-023) — self-graded during spell audit; a CI check (`npm run check:spell-catalog`, running `scripts/spell-catalog.ts`) incidentally validates only the `name`/`description` fields as a side effect of catalog generation, not the full front-matter set this bar requires. |
 | Silver | + an accurate **Executive Summary** stating purpose, when to use it, and what it produces. |
 | Gold | + explicitly disambiguates itself from sibling spells a user might confuse it with. |
 
@@ -44,17 +48,17 @@ spell to ship, regardless of overall target.
 
 | Tier | Bar |
 | --- | --- |
-| Bronze | No real organization, person, venture, or machine names. Org-specific values use `{UPPER_SNAKE}` placeholders. |
-| Silver | + every placeholder has an inline resolution note: *"resolve from `.arcane.json` / frontmatter; ask if unset."* |
+| Bronze | No real organization, person, venture, or machine names. Org-specific values use `{UPPER_SNAKE}` placeholders. Enforcement: executable check (ARC-023) — `scripts/org-token-lint.ts` scans `.github/prompts/*.prompt.md` against the `ARCANE_ORG_TOKENS` denylist and runs automatically as part of `npm run build`, failing the build on a match; `spell ward --gate` (`src/commands/ward.ts`) runs the same denylist-scanning engine standalone but is not currently wired into CI as its own gate. |
+| Silver | + every placeholder has an inline resolution note: *"resolve from `.arcane.json` / frontmatter; ask if unset."* Enforcement: explicitly advisory prose (ARC-023) — part of the D2 hard gate by name, but this specific bar is self-graded; no check verifies a placeholder carries an inline resolution note. |
 | Gold | + no hard assumption of a specific tracker, agent roster, or directory layout — the spell works in a vanilla consuming repo with no Arcane context files present. |
 
-> A **Bronze on D2 is OSS-blocking** and must be fixed before release. See **Distributability conventions** below.
+> A **Bronze on D2 is OSS-blocking** and must be fixed before release. **Enforcement: executable check (ARC-023) — same mechanism as the D2 Bronze bar above: the `org-token-lint` build gate fails `npm run build` automatically; `spell ward --gate` provides the same scan standalone but is not yet wired into CI.** See **Distributability conventions** below.
 
 ### D3 — Context-file robustness
 
 | Tier | Bar |
 | --- | --- |
-| Bronze | Context files the spell reads are listed. |
+| Bronze | Context files the spell reads are listed. Enforcement: explicitly advisory prose (ARC-023) — self-graded during spell audit; no coded scorer verifies this dimension. |
 | Silver | + each optional file has a fallback: *"if missing, proceed with X."* |
 | Gold | + the spell degrades gracefully end-to-end when **no** context files exist. |
 
@@ -62,7 +66,7 @@ spell to ship, regardless of overall target.
 
 | Tier | Bar |
 | --- | --- |
-| Bronze | The happy path is fully specified with clear, ordered steps. |
+| Bronze | The happy path is fully specified with clear, ordered steps. Enforcement: explicitly advisory prose (ARC-023) — self-graded during spell audit; no coded scorer verifies this dimension. |
 | Silver | + edge and failure cases handled: missing/invalid input, a required tool unavailable, an empty result. |
 | Gold | + re-run safety (idempotency) and recovery from partial failure. |
 
@@ -70,7 +74,7 @@ spell to ship, regardless of overall target.
 
 | Tier | Bar |
 | --- | --- |
-| Bronze | The output is named. |
+| Bronze | The output is named. Enforcement: explicitly advisory prose (ARC-023) — self-graded during spell audit; no coded scorer verifies this dimension. |
 | Silver | + the output's structure or a template is given. |
 | Gold | + a user-verifiable **acceptance checklist** — how to know the spell did its job. |
 
@@ -78,7 +82,7 @@ spell to ship, regardless of overall target.
 
 | Tier | Bar |
 | --- | --- |
-| Bronze | Related spells are mentioned. |
+| Bronze | Related spells are mentioned. Enforcement: explicitly advisory prose (ARC-023) — self-graded during spell audit; no coded scorer verifies this dimension. |
 | Silver | + correct hand-off direction (consumes-from X, feeds-into Y). |
 | Gold | + bidirectional and consistent with the flow in [[development-methodology]]. |
 
@@ -86,25 +90,29 @@ spell to ship, regardless of overall target.
 
 | Tier | Bar |
 | --- | --- |
-| Bronze | A `Rules` section exists. |
-| Silver | + required arguments are validated or requested; the spell refuses to proceed on clearly invalid input. |
+| Bronze | A `Rules` section exists. Enforcement: explicitly advisory prose (ARC-023) — part of the D7 hard gate by name, but this specific bar is self-graded; no check verifies a spell prompt contains a `Rules` section. |
+| Silver | + required arguments are validated or requested; the spell refuses to proceed on clearly invalid input. Enforcement: explicitly advisory prose (ARC-023) — part of the D7 hard gate by name, but this specific bar is self-graded; no check verifies input-validation behavior across spell prompts. |
 | Gold | + every destructive or outward-facing action (delete, force-push, publish, external post) is explicitly gated behind confirmation. |
 
 ### D8 — Conciseness & non-duplication
 
 | Tier | Bar |
 | --- | --- |
-| Bronze | No dead or contradictory text. |
+| Bronze | No dead or contradictory text. Enforcement: explicitly advisory prose (ARC-023) — self-graded during spell audit; no coded scorer verifies this dimension. |
 | Silver | + shared logic is **referenced**, not copy-pasted (e.g. point to a governance doc rather than inlining it). |
 | Gold | + tight and single-responsibility — the spell does one job well. |
 
 ## Scoring & target
 
-- **Overall = lowest dimension score.**
-- **Hard gates:** D2 and D7 must each be **≥ Silver**.
+- **Overall = lowest dimension score.** Enforcement: explicitly advisory prose (ARC-023) — self-graded
+  during spell audit; no coded scorer computes or verifies this aggregation.
+- **Hard gates:** D2 and D7 must each be **≥ Silver**. Enforcement: explicitly advisory prose (ARC-023) —
+  self-graded during spell audit; only D2's Bronze floor is mechanically checked today, so this broader
+  gate is not fully verified by any coded scorer or workflow gate.
 - **Authoring target:** every shipped spell reaches **Silver overall, Gold on D2.** Gold-everywhere is
   aspirational, not required — chasing it on a mature spell usually adds bloat, not value. A short spell
-  that meets every gate at Silver is **done**; do not pad it.
+  that meets every gate at Silver is **done**; do not pad it. Enforcement: explicitly advisory prose
+  (ARC-023) — self-graded during spell audit; no coded scorer verifies overall attainment.
 
 ## Distributability conventions (D2)
 
@@ -112,20 +120,33 @@ Arcane spells ship to other repositories and, eventually, open source. Keep them
 
 - **Never hard-code** an org name, person, venture, product, or machine name. Use a documented
   `{UPPER_SNAKE}` placeholder: `{ADO_ORG}`, `{ADO_PROJECT}`, `{BUSINESS_NAME}`, `{OPERATOR_NAME}`.
+  Enforcement: executable check (ARC-023) — same mechanism as D2 Bronze above: the `org-token-lint`
+  build gate (`scripts/org-token-lint.ts`) fails `npm run build` automatically; `spell ward --gate`
+  (`src/commands/ward.ts`) runs the same scan standalone but is not yet wired into CI.
 - **Resolution rule:** a placeholder resolves from `.arcane.json` or the feature/PRD frontmatter; if it
-  is unset, the spell **asks** rather than assuming a default.
+  is unset, the spell **asks** rather than assuming a default. Enforcement: explicitly advisory prose
+  (ARC-023) — depends on each spell's own runtime judgment; no check exercises a spell's unset-placeholder
+  behavior.
 - **Roster by reference, not by name:** when a spell needs the concept of an agent role, reference
   [[agent-policies]] / [[naming-conventions]] as context (with a fallback) instead of naming personas
-  inline.
+  inline. Enforcement: explicitly advisory prose (ARC-023) — self-graded during spell audit; no coded
+  scorer verifies this convention.
 - **Trackers are optional:** never assume Azure DevOps (or any single provider). Respect
   `tracking_mode` (internal/external) and detect the provider; the shared rules live in
-  [[development-methodology]] — point to them rather than re-inlining ADO logic.
+  [[development-methodology]] — point to them rather than re-inlining ADO logic. Enforcement: explicitly
+  advisory prose (ARC-023) — self-graded during spell audit; no lint scans spell prompts for a
+  hard-coded tracker assumption.
 
 > **Maintainer-internal exemption.** A few spells operate *on the Arcane framework itself*
 > (e.g. `spell-bump`, `spell-arcane-version`) and legitimately reference repo internals like
 > `registry.ts`, `src/assets/`, or the `arcane-cli` package name. Such
 > **framework-self-referential** references do **not** count as a D2 violation. The exemption covers
 > only the framework's own internals — never a consuming org's venture, person, machine, or tracker names.
+> **Enforcement: explicitly advisory prose (ARC-023) — depends on an auditor's judgment about what
+> counts as framework-self-reference; `org-token-lint`'s denylist is derived only from package
+> author/repository identity plus the operator-supplied `ARCANE_ORG_TOKENS` list, so these terms were
+> never candidates for that scan regardless of this clause, and no check specifically verifies the
+> carve-out itself.**
 
 ## How to audit a spell
 
@@ -133,3 +154,6 @@ For each dimension, score Bronze/Silver/Gold with one line of evidence. Record t
 score and flag any D2/D7 below Silver as **must-fix**. When elevating, prefer **additive** changes
 (add a fallback, an edge case, an acceptance line, a cross-reference); preserve the spell's intent and
 working prose, and treat any change to *behavior* (not just coverage) as requiring explicit sign-off.
+**Enforcement: explicitly advisory prose (ARC-023) — this audit process, including the must-fix flag
+and the sign-off convention, is self-graded during spell-enchant's review; no coded scorer or
+workflow gate verifies it.**

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

@@ -12,10 +12,10 @@ Framework selection, coverage thresholds, and test evidence requirements across
 
 ## Executive Summary
 
-- Every tech stack has a designated test framework — no ambiguity.
+- Every tech stack has a designated test framework — no ambiguity. **Enforcement: explicitly advisory prose (ARC-023) — no script or CI step verifies that code for a given stack was tested with its designated framework; the mapping is a team convention enforced only by code review.**
 - New code requires 80% unit test coverage; critical paths require 95%.
-- Lince (QA Lead) must sign off on test evidence before any ticket moves to "Resolved."
-- Test evidence is required in every PR: results, coverage report, known limitations.
+- Lince (QA Lead) must sign off on test evidence before any ticket moves to "Resolved." **Enforcement: explicitly advisory prose (ARC-023) — a tracker-workflow convention Arcane's own tooling has no visibility into and cannot mechanically verify.**
+- Test evidence is required in every PR: results, coverage report, known limitations. **Enforcement: explicitly advisory prose (ARC-023) — no CI step or PR template parses PR descriptions for these sections; `check:review-round` verifies review-approval state only, not test-evidence content.**
 
 ---
 
@@ -46,8 +46,8 @@ Framework selection, coverage thresholds, and test evidence requirements across
 
 | Category | Minimum Coverage | Examples |
 |----------|-----------------|----------|
-| **Standard code** | 80% | Business logic, data access, UI components, API handlers |
-| **Critical paths** | 95% | Authentication, payment processing, IoT firmware commands, calibration protocols, encryption/signing |
+| **Standard code** | 80% | Business logic, data access, UI components, API handlers. Enforcement: executable check (ARC-023) — vitest.config.ts configures a global 80% lines/branches/functions/statements threshold under `coverage.thresholds`, but ci.yml's build-test Test step runs `npm test` (bare `vitest run`), not `npm run test:coverage`, so it is never evaluated in CI. |
+| **Critical paths** | 95% | Authentication, payment processing, IoT firmware commands, calibration protocols, encryption/signing. Enforcement: executable check (ARC-023) — vitest.config.ts overrides this to 95% for src/modules/copier.ts, manifest.ts, merger.ts, registry.ts, and src/config/profiles.ts (manifest.ts's branches override is 90%, not 95%), but the same CI gap applies: `npm test` runs bare `vitest run`, not `npm run test:coverage`, so these overrides are never evaluated in CI. |
 
 ### What Counts as "Critical"
 
@@ -101,6 +101,8 @@ Every PR must include:
 
 ### Unit Tests (Required)
 
+**Enforcement: executable check (ARC-023) — ci.yml's build-test job's Test step runs `npm test` (`vitest run`), which fails the job on any failing unit test; `.husky/pre-commit` runs only `lint` and `typecheck`, not tests, so the "every commit" portion of this rule is not locally enforced.**
+
 - Test individual functions/methods in isolation
 - Mock external dependencies (DB, API, hardware)
 - Fast execution (< 1 second per test)
@@ -108,18 +110,24 @@ Every PR must include:
 
 ### Integration Tests (Recommended)
 
+**Enforcement: explicitly advisory prose (ARC-023) — self-labeled Recommended rather than Required, and ci.yml runs a single `npm test` step with no distinct integration-test job or gate.**
+
 - Test component interactions (API → DB, mobile → backend)
 - Use real dependencies where practical (in-memory DB, test containers)
 - Run in CI on PR creation and merge
 
 ### End-to-End Tests (For UI Stories)
 
+**Enforcement: explicitly advisory prose (ARC-023) — no Playwright or other end-to-end job exists in ci.yml, and Arcane's own repository is a CLI tool with no UI for this rule to apply to.**
+
 - Test complete user workflows
 - Use browser automation (Playwright for web, Flutter integration_test for mobile)
 - Run in CI on merge to main (not on every commit — too slow)
 
 ### Firmware Tests ({BUSINESS_NAME}-Specific)
 
+**Enforcement: explicitly advisory prose (ARC-023) — Arcane's own repository has no firmware or hardware target; this is template guidance for consuming projects that Arcane's own tooling does not verify.**
+
 - Host-based unit tests via PlatformIO Unity (no hardware required)
 - Hardware-in-the-loop tests for calibration validation (requires physical device)
 - BLE protocol tests via mock transport
@@ -130,14 +138,14 @@ Every PR must include:
 
 Adapt the ticket lifecycle policy to your tracker:
 
-The **Code Review → QA** transition now requires:
+The **Code Review → QA** transition now requires: **Enforcement: explicitly advisory prose (ARC-023) — a tracker-workflow gate Arcane's own tooling cannot observe or enforce; items 1 and 2 below (tests passing, coverage thresholds) are independently verified by CI, but the transition itself is not.**
 
 1. All unit tests pass (CI green)
 2. Coverage meets thresholds (80% standard / 95% critical)
 3. No HIGH-severity review findings unresolved
 4. Lince signs off with test evidence linked to the work item
 
-The **QA → Resolved** transition requires:
+The **QA → Resolved** transition requires: **Enforcement: explicitly advisory prose (ARC-023) — a tracker-workflow gate Arcane's own tooling cannot observe or enforce, the same gap ARC-023 identifies for the Lince sign-off rule above.**
 
 1. Integration tests pass (if applicable)
 2. Manual verification for UI stories (screenshot or recording)

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/dist/assets/.arcane/governance/universal-agent-rules.md

@@ -15,59 +15,59 @@ See also: [[README]], [[DECISIONS]], [[governance/git-conventions|Git Convention
 
 ## Non-Negotiable Safety Rules
 
-1. **Never access an encrypted or cross-OS volume you are not authorized to touch.** Do not suggest, execute, or recommend any action that would mount, read, or probe a drive outside the agent's authorized environment. This rule stands as defense-in-depth regardless of encryption status.
+1. **Never access an encrypted or cross-OS volume you are not authorized to touch. Enforcement: explicitly advisory prose (ARC-023) — depends on agent judgment about authorization boundaries; no script scans proposed commands for drive or volume access before execution.** Do not suggest, execute, or recommend any action that would mount, read, or probe a drive outside the agent's authorized environment. This rule stands as defense-in-depth regardless of encryption status.
 
-2. **No root commands without justification.** Do not generate or suggest commands that run as root unless explicitly scoped and justified. The agent runtime should run as a dedicated non-root user by design. See [[security/hardening-checklist|Hardening Checklist]].
+2. **No root commands without justification. Enforcement: explicitly advisory prose (ARC-023) — depends on judgment about what justifies root scope; no script inspects generated commands for root usage before they run.** Do not generate or suggest commands that run as root unless explicitly scoped and justified. The agent runtime should run as a dedicated non-root user by design. See [[security/hardening-checklist|Hardening Checklist]].
 
-3. **No secrets on the command line.** Never pass API keys, tokens, or secrets on the command line, in chat, or in config files. Use SecretRef (env vars) and `read -s` for interactive input.
+3. **No secrets on the command line. Enforcement: explicitly advisory prose (ARC-023) — no secret-scanner exists in this repo yet (tracked as future work, BC-30), so no mechanical check catches a violation.** Never pass API keys, tokens, or secrets on the command line, in chat, or in config files. Use SecretRef (env vars) and `read -s` for interactive input.
 
-4. **This is a production system.** No "fix it later" shortcuts. No experimental changes without rollback plans.
+4. **This is a production system. Enforcement: explicitly advisory prose (ARC-023) — the no-shortcuts and rollback-plan requirements depend on engineering judgment; no check evaluates whether a rollback plan exists.** No "fix it later" shortcuts. No experimental changes without rollback plans.
 
 ---
 
 ## Documentation Rules
 
-5. **Update `last_updated` frontmatter** whenever you edit a document. Every document must have YAML frontmatter with `audience`, `status`, `last_updated`, and `tags`.
+5. **Update `last_updated` frontmatter. Enforcement: explicitly advisory prose (ARC-023) — no lint validates frontmatter fields or verifies `last_updated` was bumped when a document changes.** whenever you edit a document. Every document must have YAML frontmatter with `audience`, `status`, `last_updated`, and `tags`.
 
-6. **Log significant decisions in [[DECISIONS]].** Use the next sequential ADR number. Format: Date, Status, Context, Decision, Reasoning, Rejected alternatives.
+6. **Log significant decisions in [[DECISIONS]]. Enforcement: explicitly advisory prose (ARC-023) — whether a decision is "significant" enough to log is a judgment call; `check:adr-references` verifies that ADR citations resolve, not that decisions get logged in the first place.** Use the next sequential ADR number. Format: Date, Status, Context, Decision, Reasoning, Rejected alternatives.
 
-7. **Use wiki-links for cross-references** (e.g., `[[DECISIONS#ADR-NNN|Short Title]]`, `[[journal/YYYY-MM-DD-topic-slug|Session Label]]`). This enables knowledge graph visualization.
+7. **Use wiki-links for cross-references. Enforcement: explicitly advisory prose (ARC-023) — no link-checker validates wiki-link usage or resolution across this repo's docs.** (e.g., `[[DECISIONS#ADR-NNN|Short Title]]`, `[[journal/YYYY-MM-DD-topic-slug|Session Label]]`). This enables knowledge graph visualization.
 
-8. **Use Mermaid for diagrams** (` ```mermaid ` blocks) for all flow charts, architecture diagrams, and sequence diagrams. Directory trees stay as plain code blocks. Spell output describing state the spell already computed — not authored, freehand explanatory content — additionally follows the **generated state diagrams** convention ([ARC-036](https://github.com/codemagicianhq/arcane/blob/main/DECISIONS.md#arc-036--generated-state-diagrams-deterministic-mermaid-for-computed-spell-state)): a deterministic, data-derived Mermaid diagram built only from values already in scope, never modeled or invented. Skip it for one-line outputs, speed-rule spells, or any state with only a single reading — the diagram exists to make relationships between multiple already-computed values legible, not to decorate simple output.
+8. **Use Mermaid for diagrams. Enforcement: explicitly advisory prose (ARC-023) — no lint validates diagram block type or the generated-state-diagrams determinism convention.** (` ```mermaid ` blocks) for all flow charts, architecture diagrams, and sequence diagrams. Directory trees stay as plain code blocks. Spell output describing state the spell already computed — not authored, freehand explanatory content — additionally follows the **generated state diagrams** convention ([ARC-036](https://github.com/codemagicianhq/arcane/blob/main/DECISIONS.md#arc-036--generated-state-diagrams-deterministic-mermaid-for-computed-spell-state)): a deterministic, data-derived Mermaid diagram built only from values already in scope, never modeled or invented. Skip it for one-line outputs, speed-rule spells, or any state with only a single reading — the diagram exists to make relationships between multiple already-computed values legible, not to decorate simple output.
 
-9. **Journal files use date-prefix naming:** `journal/YYYY-MM-DD-topic-slug.md` for chronological sorting.
+9. **Journal files use date-prefix naming. Enforcement: explicitly advisory prose (ARC-023) — `checkSessionContinuity` only verifies `journal/.gitkeep` exists, not that individual journal filenames follow the date-prefix pattern.** `journal/YYYY-MM-DD-topic-slug.md` for chronological sorting.
 
 ---
 
 ## Git Rules
 
-10. **Never auto-commit during interactive sessions.** Stage changes and present the proposed commit message for human approval before executing `git commit`. This applies to Copilot, Claude Code, Codex, and any other interactive AI tool. The human decides when to commit. Exception: autonomous agents at Magus+ power level may self-commit within approved scope.
+10. **Never auto-commit during interactive sessions. Enforcement: structured spell gate (ARC-023) — `spell-commit-work`'s Step 8 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.** Stage changes and present the proposed commit message for human approval before executing `git commit`. This applies to Copilot, Claude Code, Codex, and any other interactive AI tool. The human decides when to commit. Exception: autonomous agents at Magus+ power level may self-commit within approved scope.
 
-11. **Use Conventional Commits format** for all commit messages: `type(scope): description`. See [[governance/git-conventions|Git Conventions]] for types, scopes, and examples.
+11. **Use Conventional Commits format. Enforcement: explicitly advisory prose (ARC-023) — no commitlint or equivalent hook validates commit message format.** for all commit messages: `type(scope): description`. See [[governance/git-conventions|Git Conventions]] for types, scopes, and examples.
 
-12. **Agent attribution trailers** are required on agent-authored commits (`Agent`, `Model`, `Model-Source`, `Provider`). `Persona`/`Role` are conditional — present only when a roster exists and one was assigned, never guessed. See [[governance/git-conventions#agent-attribution-model|Attribution Model]].
+12. **Agent attribution trailers. Enforcement: explicitly advisory prose (ARC-023) — `spell-commit-work`'s Step 7 documents the required trailers, but no hook or CI check verifies they are actually present on a given commit.** are required on agent-authored commits (`Agent`, `Model`, `Model-Source`, `Provider`). `Persona`/`Role` are conditional — present only when a roster exists and one was assigned, never guessed. See [[governance/git-conventions#agent-attribution-model|Attribution Model]].
 
-13. **For runtime config changes** (anything touching the agent runtime's config files or service restarts): do NOT commit supporting docs until the user has confirmed the change is working. Stage and present — but wait for explicit approval after testing.
+13. **For runtime config changes. Enforcement: structured spell gate (ARC-023), hedged — `spell-commit-work`'s Step 8 operator-approval gate covers this commit like any other before it can be made, though it verifies diff/message approval rather than a dedicated confirmation that testing occurred.** (anything touching the agent runtime's config files or service restarts): do NOT commit supporting docs until the user has confirmed the change is working. Stage and present — but wait for explicit approval after testing.
 
-14. **Never commit directly to main.** All work — human or agent — happens on topic branches. Humans use `type/short-description`; agents use `{agent-slug}/type/short-description`. Main receives changes only through PR completion, not local direct merges. See [[governance/git-conventions#branch-discipline|Branch Discipline]].
+14. **Never commit directly to main. Enforcement: explicitly advisory prose (ARC-023) — `spell doctor`'s `checkPlatformBranchPolicy` verifies only the platform's merge-method policy (squash disallowed), not that direct pushes/commits to main are blocked.** All work — human or agent — happens on topic branches. Humans use `type/short-description`; agents use `{agent-slug}/type/short-description`. Main receives changes only through PR completion, not local direct merges. See [[governance/git-conventions#branch-discipline|Branch Discipline]].
 
 ---
 
 ## Spell Lifecycle
 
-22. **Lifecycle operations run through their spell when one is installed.** Committing, opening a PR, opening or closing a session, reviewing code, and shipping each have a dedicated spell (`spell-commit-work`, `spell-create-pull-request`, `spell-open-session`/`spell-close-session`, `spell-review`, `spell-ship`). When the installed component set includes the matching spell, invoke it for that operation rather than improvising the workflow from general knowledge — even when the user does not name the spell explicitly. The intent→spell routing table injected into each client's L1 instruction file (`CLAUDE.md`, `.github/copilot-instructions.md`, `AGENTS.md`) is normative for this mapping, not illustrative.
+22. **Lifecycle operations run through their spell when one is installed. Enforcement: explicitly advisory prose (ARC-023) — invoking the correct spell instead of improvising depends on agent judgment; no check verifies that a matching spell was actually invoked for a given operation.** Committing, opening a PR, opening or closing a session, reviewing code, and shipping each have a dedicated spell (`spell-commit-work`, `spell-create-pull-request`, `spell-open-session`/`spell-close-session`, `spell-review`, `spell-ship`). When the installed component set includes the matching spell, invoke it for that operation rather than improvising the workflow from general knowledge — even when the user does not name the spell explicitly. The intent→spell routing table injected into each client's L1 instruction file (`CLAUDE.md`, `.github/copilot-instructions.md`, `AGENTS.md`) is normative for this mapping, not illustrative.
 
 ---
 
 ## Recommendation Guardrails (ADR-034)
 
-15. **Flag actionable recommendations.** Any recommendation that could lead to a purchase, subscription, account creation, or irreversible action must: (a) be flagged explicitly, (b) use verified current information — never assume or fabricate, (c) present free/no-cost alternatives when they exist, (d) state confidence level if based on general knowledge. For >$50 or contracts, require explicit confirmation. See [[agents/agent-policies#actionable-recommendation-policy-adr-034|Full Policy]].
+15. **Flag actionable recommendations. Enforcement: explicitly advisory prose (ARC-023) — whether a recommendation is flagged, sourced, and confidence-rated depends on judgment; no automated check evaluates response content against this policy.** Any recommendation that could lead to a purchase, subscription, account creation, or irreversible action must: (a) be flagged explicitly, (b) use verified current information — never assume or fabricate, (c) present free/no-cost alternatives when they exist, (d) state confidence level if based on general knowledge. For >$50 or contracts, require explicit confirmation. See [[agents/agent-policies#actionable-recommendation-policy-adr-034|Full Policy]].
 
 ---
 
 ## Screenshot Curation
 
-15. **Curate screenshots — not every screenshot needs saving.** Use these heuristics:
+24. **Curate screenshots — not every screenshot needs saving. Enforcement: explicitly advisory prose (ARC-023) — which screenshots to keep is a judgment call; no check evaluates screenshot-retention decisions.** Use these heuristics:
     - **Save** when it shows a completed setup, config state, UI result, or evidence of a problem/fix.
     - **Save** when the user explicitly says "save this" or "add this to docs."
     - **Save key decision points and final states** in multi-step flows; skip intermediate steps.
@@ -80,7 +80,7 @@ See also: [[README]], [[DECISIONS]], [[governance/git-conventions|Git Convention
 
 ## Sensitive Repositories
 
-21. **Reference, don't transcribe, when the repository is marked sensitive.** If
+21. **Reference, don't transcribe, when the repository is marked sensitive. Enforcement: explicitly advisory prose (ARC-023) — whether written output cites versus transcribes sensitive content depends on judgment; no check scans agent output for this distinction.** If
     `.arcane.json` has `content_sensitivity: "sensitive"`, the repository's own
     documents are the sensitive material — not just credentials inside them. In
     that mode:
@@ -106,7 +106,7 @@ See also: [[README]], [[DECISIONS]], [[governance/git-conventions|Git Convention
 
 ## Naming Conventions
 
-16. **Three naming tiers — never mix them:**
+16. **Three naming tiers — never mix them. Enforcement: explicitly advisory prose (ARC-023) — `spell ward` and `org-token-lint` scan for denylisted org/venture/customer names, not for adherence to this tier taxonomy; no check verifies tier consistency.**
 
 | Tier | What | Style | Examples |
 |------|------|-------|---------|
@@ -114,19 +114,19 @@ See also: [[README]], [[DECISIONS]], [[governance/git-conventions|Git Convention
 | AI Agents | Autonomous agents | Persona name + role title | Merlin — CTO, Kellar — Product Ops |
 | Systems/Services | DBs, APIs, tools | Functional `[slug]-[function]` | `inventory-api`, `orders-worker` |
 
-17. **Projects and repos follow a consistent naming convention.** Pick one (TitleCase or kebab-case) and apply it uniformly across your org.
+17. **Projects and repos follow a consistent naming convention. Enforcement: explicitly advisory prose (ARC-023) — no check verifies TitleCase/kebab-case consistency across projects and repos.** Pick one (TitleCase or kebab-case) and apply it uniformly across your org.
 
 ---
 
 ## Operational Rules
 
-18. **TODO.md is a scratchpad.** Resolved items move to the relevant doc, then get deleted from TODO.md.
+18. **TODO.md is a scratchpad. Enforcement: explicitly advisory prose (ARC-023) — `checkSessionContinuity` verifies TODO.md exists, not that resolved items are removed from it.** Resolved items move to the relevant doc, then get deleted from TODO.md.
 
-19. **After any onboarding or config wizard**, re-validate authentication and network-exposure settings — wizards can silently downgrade security settings.
+19. **After any onboarding or config wizard. Enforcement: explicitly advisory prose (ARC-023) — no wizard or check re-validates authentication and network-exposure settings after configuration changes.**, re-validate authentication and network-exposure settings — wizards can silently downgrade security settings.
 
-20. **For repo path requests**, perform read-only discovery before claiming "no access." Use [[agents/agent-approved-paths|Agent Approved Paths Registry]].
+20. **For repo path requests. Enforcement: explicitly advisory prose (ARC-023) — performing read-only discovery before claiming no access depends on agent judgment; no check verifies this behavior occurred.**, perform read-only discovery before claiming "no access." Use [[agents/agent-approved-paths|Agent Approved Paths Registry]].
 
-23. **Diff before deleting a "duplicate."** When housekeeping surfaces two blocks of content that look
+23. **Diff before deleting a "duplicate." Enforcement: explicitly advisory prose (ARC-023) — the branch-specific case this generalizes from has a structured procedure (git-conventions.md's Content-Verified Branch Deletion), but no equivalent structured check exists for arbitrary documents, configs, or data files.** When housekeeping surfaces two blocks of content that look
     like duplicates — in a document, a config, a data file — compare them in full before removing
     either. A near-identical pair is usually a **drifted copy carrying unique content in one and not the
     other**, not byte-identical redundancy; deleting on sight can destroy the unique content silently.