arcane-cli 0.29.1 → 0.29.3

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

@@ -12,7 +12,7 @@ Pipeline patterns, branch policies, and deployment gates for all your projects.
 
 ## Executive Summary
 
-- Every code repository must have a CI pipeline that runs on PR creation and merge to main.
+- Every code repository must have a CI pipeline that runs on PR creation and merge to main. **Enforcement: explicitly advisory prose (ARC-023) — prescriptive guidance for repos Prospero provisions; Arcane's own tooling does not enumerate an organization's repositories to verify each one has a CI pipeline.**
 - Branch policies enforce PR requirements: build must pass, reviewer required, work item linked.
 - Terraform changes use plan-on-PR / apply-on-merge with manual approval gates.
 - Prospero owns pipeline creation and maintenance across all repos.
@@ -39,12 +39,12 @@ Applied to all code repositories (not docs-only repos per ADR-048):
 
 | Policy | Setting | Rationale |
 |--------|---------|-----------|
-| **Require PR** | All branches → main | No direct pushes to main |
-| **Minimum reviewers** | 1 (Lince for code, Merlin for architecture) | Quality gate |
-| **Build validation** | CI pipeline must pass | No merging broken code |
-| **Work item linking** | Required (when ticketing active) | Traceability |
-| **Comment resolution** | All comments must be resolved | No ignored feedback |
-| **Merge type** | Merge (no fast-forward) or Rebase and fast-forward — Squash disallowed | Preserves per-commit attribution trailers (ARC-009 §7); see [[git-conventions#Azure DevOps PR Merge Type]] |
+| **Require PR** | All branches → main | No direct pushes to main. Enforcement: explicitly advisory prose (ARC-023) — prescriptive for consumer Azure DevOps repos; no Arcane check verifies a PR-required policy is configured. |
+| **Minimum reviewers** | 1 (Lince for code, Merlin for architecture) | Quality gate. Enforcement: explicitly advisory prose (ARC-023) — prescriptive for consumer Azure DevOps repos; no Arcane check verifies configured reviewer counts. |
+| **Build validation** | CI pipeline must pass | No merging broken code. Enforcement: explicitly advisory prose (ARC-023) — prescriptive for consumer Azure DevOps repos; no Arcane check verifies a build-validation policy is configured. |
+| **Work item linking** | Required (when ticketing active) | Traceability. Enforcement: explicitly advisory prose (ARC-023) — prescriptive for consumer Azure DevOps repos; no Arcane check verifies it. |
+| **Comment resolution** | All comments must be resolved | No ignored feedback. Enforcement: explicitly advisory prose (ARC-023) — prescriptive for consumer Azure DevOps repos; no Arcane check verifies a comment-resolution policy is configured. |
+| **Merge type** | Merge (no fast-forward) or Rebase and fast-forward — Squash disallowed | Preserves per-commit attribution trailers (ARC-009 §7); see [[git-conventions#Azure DevOps PR Merge Type]]. Enforcement: verified external platform policy (ARC-023) — `spell doctor`'s `checkPlatformBranchPolicy` (src/commands/doctor.ts, backed by src/modules/platform-policy.ts's evaluateGitHubMergePolicy/evaluateAdoMergePolicy) queries live GitHub Rulesets or Azure DevOps branch policy and verifies the effective merge methods match this ladder — a local, on-demand CLI check the operator runs, not a check wired into CI itself. |
 
 For docs-only repos (Arcane):
 - PR not required (ADR-048 allows local ff-only merge for docs)
@@ -64,7 +64,7 @@ glob, and deliberately just one entry: `docs/**`/`journal/**`/`.arcane/governanc
 directory-wide excludes would ALSO exclude any non-Markdown file a consumer happens to place in
 those directories (a build script, a manifest, tooling config) — silently violating ARC-022's own
 unconditional requirement that scripts, manifests, lockfiles, migrations, containers, and
-infrastructure always remain triggering inputs, regardless of which directory they live in. Filetype-scoping to
+infrastructure always remain triggering inputs, regardless of which directory they live in. **Enforcement: explicitly advisory prose (ARC-023) — prescriptive for the Azure DevOps template this repo ships to consumers; Arcane has no shipped `azure-pipelines.yml` file of its own to check parity against, and cannot verify a downstream repo kept the filter filetype-scoped.** Filetype-scoping to
 `**/*.md` closes that gap: only actual Markdown files are excluded, anywhere in the tree; anything
 else — including a `.md`-adjacent script — still triggers CI by default.
 
@@ -111,7 +111,7 @@ steps:
 Previously had no path filter at all — fail-safe (never misses a code change) but wasteful (a
 pure docs commit still burns a full pipeline run). Fail-safe path filter (ARC-022): the same
 filetype-scoped `**/*.md` **exclude** entry as the .NET template above — never a directory-wide
-exclude, and never an include list.
+exclude, and never an include list. **Enforcement: explicitly advisory prose (ARC-023) — prescriptive for the Azure DevOps template this repo ships to consumers; Arcane has no shipped `azure-pipelines.yml` file of its own to check parity against, and cannot verify a downstream repo kept this filter filetype-scoped.**
 
 ```yaml
 trigger:
@@ -149,7 +149,7 @@ steps:
 ### Terraform Pipeline
 
 An **include** filter is correct here, not the ARC-022 anti-pattern — but only if it's a
-**filetype** glob, not a directory-prefix one. An earlier version of this template included only
+**filetype** glob, not a directory-prefix one. **Enforcement: explicitly advisory prose (ARC-023) — prescriptive for the Azure DevOps template this repo ships to consumers; Arcane has no shipped `azure-pipelines.terraform.yml` file of its own to check parity against, and cannot verify a downstream repo kept the include filter filetype-scoped rather than directory-prefixed.** An earlier version of this template included only
 `infrastructure/terraform/**`: a directory-prefix pattern that silently misses any `.tf` file
 added *outside* that one named directory (a new `modules/**` root, a renamed infra folder) —
 exactly the "new code locations fail open" failure ARC-022 rejects, and exactly what EF-22's own
@@ -244,7 +244,7 @@ steps:
 CI skip/run decisions are based **only on changed paths** — never on commit message, author
 identity, or branch name. Do not add a *new* mechanism (a custom `docs(...)`-style commit-prefix
 convention, a bot rule, a pipeline-level check) that lets a commit opt itself out of validation by
-what it *says* rather than what it *changed*.
+what it *says* rather than what it *changed*. **Enforcement: explicitly advisory prose (ARC-023) — prescriptive guidance for Azure DevOps consumer pipelines; this repo's own `.github/workflows/ci.yml` runs unconditionally on every push/PR to `main` with no path filter at all, so it neither implements nor is bound by this pattern, and no Arcane check inspects a downstream repo's CI configuration for compliance.**
 
 Commit messages, authorship, and branch names are attacker-controlled metadata — anyone who can
 push a commit controls all three. A CI-skip mechanism keyed on any of them is a bypass primitive:
@@ -253,7 +253,7 @@ actually touched. Path-based filtering (above) is the only trust signal this rep
 recognizes, because the pipeline itself independently observes the changed paths rather than
 trusting a claim embedded in the commit.
 
-**Know the platform default, don't assume this rule alone controls it.** Azure Pipelines honors
+**Know the platform default, don't assume this rule alone controls it. Enforcement: explicitly advisory prose (ARC-023) — this paragraph discloses a residual platform-level gap; it is not a mechanism Arcane enforces.** Azure Pipelines honors
 `[skip ci]`, `[ci skip]`, `skip-checks: true`, `[skip azurepipelines]`, `[skip azpipelines]`,
 `[skip azp]`, and `***NO_CI***` in a pushed commit message **by default**, on `trigger:`-driven
 runs — this is platform behavior, not something a consumer opts into, and this governance rule
@@ -283,7 +283,7 @@ adopted exclude-based YAML triggers), a change to a new top-level code directory
 triggers the pipeline (YAML is fail-safe) but does **not** require it to pass before merge (branch
 policy is not) — the build can run, fail, and be ignored, or the PR can merge before it finishes.
 Whenever a pipeline's YAML trigger scope changes, the branch policy's own path filter (if it has
-one) must be reviewed and updated to match or be a strict superset — never left narrower.
+one) must be reviewed and updated to match or be a strict superset — never left narrower. **Enforcement: explicitly advisory prose (ARC-023) — prescriptive for consumer Azure DevOps projects; Arcane has no visibility into a downstream repo's branch-policy path-filter configuration and cannot verify the two stay aligned.**
 
 ---
 
@@ -291,9 +291,9 @@ one) must be reviewed and updated to match or be a strict superset — never lef
 
 | Environment | Gate | Who Approves |
 |-------------|------|-------------|
-| **Staging** | CI passes + PR approved | Automatic on merge |
-| **Production** | Staging verified + manual approval | Human (operator) |
-| **Terraform apply** | Plan reviewed + Checkov clean | Human (operator) |
+| **Staging** | CI passes + PR approved | Automatic on merge. Enforcement: explicitly advisory prose (ARC-023) — describes a consumer Azure DevOps pipeline's intended gating; Arcane does not verify a downstream repo's environment configuration. |
+| **Production** | Staging verified + manual approval | Human (operator). Enforcement: explicitly advisory prose (ARC-023) — describes a consumer Azure DevOps environment's approval configuration; Arcane does not verify it is actually configured. |
+| **Terraform apply** | Plan reviewed + Checkov clean | Human (operator). Enforcement: explicitly advisory prose (ARC-023) — describes a consumer Azure DevOps pipeline's manual-apply step; Arcane does not verify it is actually configured. |
 
 ---
 

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

@@ -67,8 +67,7 @@ with EU visitors signing up for a free product is a plausible trigger; a company
 not, but "zero" needs to be an actual verified fact about the user base, not an assumption based on
 where the company is headquartered.
 
-**Rule (CS-01):** Determine GDPR applicability from the actual or intended user base's location and
-what the processing does, never from the business's own location alone.
+**Rule (CS-01): Determine GDPR applicability from the actual or intended user base's location and what the processing does, never from the business's own location alone. Enforcement: explicitly advisory prose (ARC-023) — GDPR applicability turns on real-world facts about a specific business's actual user base and processing, a legal/business judgment call no Arcane mechanism observes or verifies.**
 
 ### CS-02: A lawful basis and enforceable data-subject rights
 
@@ -80,8 +79,7 @@ Requests exercising these rights carry a response deadline (commonly one month,
 cases) — a rights-request process that has no defined owner or turnaround time is itself a gap, even
 before any request arrives.
 
-**Rule (CS-02):** Document a lawful basis per processing category, and maintain a working process — with
-a defined owner and turnaround time — for handling data-subject rights requests.
+**Rule (CS-02): Document a lawful basis per processing category, and maintain a working process — with a defined owner and turnaround time — for handling data-subject rights requests. Enforcement: explicitly advisory prose (ARC-023) — whether a lawful basis is properly documented and a rights-request process actually functions is a substantive judgment about the downstream product's own operations; `spell-compliance` can only ask and report on it, never verify or gate on it.**
 
 ### CS-03: 72-hour breach notification
 
@@ -90,8 +88,7 @@ relevant supervisory authority within 72 hours of the organization becoming awar
 starts at awareness, not at confirmation of scope — an incident-response process that only begins
 drafting a notification after a full investigation completes risks missing the window entirely.
 
-**Rule (CS-03):** Have a breach-notification process that can produce an initial report to the
-supervisory authority within 72 hours of awareness, even before the full scope of an incident is known.
+**Rule (CS-03): Have a breach-notification process that can produce an initial report to the supervisory authority within 72 hours of awareness, even before the full scope of an incident is known. Enforcement: explicitly advisory prose (ARC-023) — whether an incident-response process would actually meet the 72-hour window in a real breach is a judgment call about the team's own readiness that no Arcane mechanism tests.**
 
 ---
 
@@ -107,9 +104,7 @@ number here as current). Covered businesses must honor consumer rights to know w
 it, correct inaccuracies, and opt out of the sale or sharing of their personal information, plus limit
 use of sensitive personal information on request.
 
-**Rule (CS-04):** Verify CCPA's current statutory thresholds against the business's actual revenue and
-data volume, rather than assuming applicability (or non-applicability) from the business's category
-alone.
+**Rule (CS-04): Verify CCPA's current statutory thresholds against the business's actual revenue and data volume, rather than assuming applicability (or non-applicability) from the business's category alone. Enforcement: explicitly advisory prose (ARC-023) — confirming current statutory thresholds against a business's actual revenue and data volume is a legal/business determination outside anything Arcane can check itself.**
 
 ### CS-05: A real opt-out mechanism, not just a policy statement
 
@@ -119,9 +114,7 @@ or an equivalent global-privacy-control-honoring mechanism. Stating an opt-out r
 policy's prose, without a working mechanism a consumer can actually use, does not satisfy the
 requirement.
 
-**Rule (CS-05):** Verify the opt-out mechanism itself functions end-to-end — a link that exists in the
-footer but doesn't actually stop the described sharing is not compliant, regardless of what the privacy
-policy says.
+**Rule (CS-05): Verify the opt-out mechanism itself functions end-to-end — a link that exists in the footer but doesn't actually stop the described sharing is not compliant, regardless of what the privacy policy says. Enforcement: explicitly advisory prose (ARC-023) — `spell-compliance`'s Phase 2 only checks whether an opt-out mechanism's indicators are present, not whether it actually stops sharing end-to-end, so confirming real function stays a human verification step.**
 
 ---
 
@@ -135,8 +128,7 @@ feature), and distinguishable from other terms — not buried in a general terms
 Pre-ticked checkboxes, and consent bundled with acceptance of unrelated terms, do not qualify as valid
 consent under either framework.
 
-**Rule (CS-06):** Any consent mechanism must be opt-in (not pre-ticked), specific to its actual purpose,
-and separable from acceptance of unrelated terms.
+**Rule (CS-06): Any consent mechanism must be opt-in (not pre-ticked), specific to its actual purpose, and separable from acceptance of unrelated terms. Enforcement: explicitly advisory prose (ARC-023) — `spell-compliance` can render a PASS/FAIL/PARTIAL judgment on a consent mechanism in its report, but that report only surfaces a finding for a human to act on and never gates a workflow, so consent validity remains a judgment call.**
 
 ### CS-07: A data inventory is the load-bearing prerequisite
 
@@ -146,8 +138,7 @@ Records of Processing Activities under GDPR Article 30), every downstream rights
 obligation is unenforceable in practice, even if a policy document claims it's honored — there is no way
 to actually locate everything that would need to be produced, corrected, or deleted.
 
-**Rule (CS-07):** Maintain a data inventory naming what personal data is collected, where it's stored,
-and why, before treating any rights-request or retention process as operational.
+**Rule (CS-07): Maintain a data inventory naming what personal data is collected, where it's stored, and why, before treating any rights-request or retention process as operational. Enforcement: explicitly advisory prose (ARC-023) — `spell-compliance` can surface whether a data-inventory document exists, but it neither verifies the inventory's accuracy nor blocks any workflow on its presence, leaving completeness a human-verified judgment call.**
 
 ### CS-08: Retention periods must be defined and actually enforced
 
@@ -156,8 +147,7 @@ actually deleting it at the end of that period — not simply flagging a record
 while the underlying data persists indefinitely. An undefined retention period is itself a gap, distinct
 from and prior to the question of whether deletion is correctly implemented.
 
-**Rule (CS-08):** Define a retention period per data category, and verify deletion is real (data is
-actually removed, not merely deactivated) at the end of that period.
+**Rule (CS-08): Define a retention period per data category, and verify deletion is real (data is actually removed, not merely deactivated) at the end of that period. Enforcement: explicitly advisory prose (ARC-023) — whether deletion is actually real rather than merely deactivated requires inspecting the downstream product's live data stores, which is outside anything Arcane's static, read-only self-assessment observes.**
 
 ---
 
@@ -174,9 +164,7 @@ suitably designed at a single point in time; a **Type II** report attests that t
 operated effectively over an observation period (commonly 3-12 months) — a Type I report does not
 substitute for a Type II when a customer's requirement specifically calls for one.
 
-**Rule (CS-09):** Confirm which Trust Services Criteria and which report type (I vs. II) a customer's
-actual requirement calls for before scoping a SOC 2 engagement — do not assume Security-only Type I
-satisfies a requirement that wasn't explicitly checked against what was asked for.
+**Rule (CS-09): Confirm which Trust Services Criteria and which report type (I vs. II) a customer's actual requirement calls for before scoping a SOC 2 engagement — do not assume Security-only Type I satisfies a requirement that wasn't explicitly checked against what was asked for. Enforcement: explicitly advisory prose (ARC-023) — what a specific customer or auditor actually requires is an external fact no Arcane mechanism observes, so confirming it against a live requirement is inherently a human step.**
 
 ### CS-10: Access control and audit logging are the operational backbone
 
@@ -186,8 +174,7 @@ sensitive systems sufficient to reconstruct who did what and when. These are the
 controls a real security program needs regardless of whether a SOC 2 report is ever pursued — building
 them only when an audit is scheduled means starting the evidentiary trail late.
 
-**Rule (CS-10):** Implement least-privilege access control, periodic access review, and audit logging of
-access to customer-data-holding systems as an ongoing practice, not as audit-time preparation.
+**Rule (CS-10): Implement least-privilege access control, periodic access review, and audit logging of access to customer-data-holding systems as an ongoing practice, not as audit-time preparation. Enforcement: explicitly advisory prose (ARC-023) — this doc states the obligation and points to `threat-model.md`/`hardening-checklist.md` for the control detail without restating or itself verifying it, so no executable check or platform-policy verification is wired to this rule here.**
 
 ---
 
@@ -202,9 +189,7 @@ typical consumer SaaS product with no health-data handling does not trigger HIPA
 users who happen to be patients elsewhere; the trigger is the product's own handling of PHI, not its
 users' medical status in general.
 
-**Rule (CS-11):** Confirm HIPAA applicability specifically against whether the product creates,
-receives, maintains, or transmits PHI as a covered entity or business associate — do not assume
-applicability (or safety from it) based on the target market alone.
+**Rule (CS-11): Confirm HIPAA applicability specifically against whether the product creates, receives, maintains, or transmits PHI as a covered entity or business associate — do not assume applicability (or safety from it) based on the target market alone. Enforcement: explicitly advisory prose (ARC-023) — whether a product actually creates, receives, maintains, or transmits PHI is a factual/legal determination about that specific product that no Arcane mechanism observes.**
 
 ---
 
@@ -226,8 +211,7 @@ applicability (or safety from it) based on the target market alone.
   starts from real evidence rather than a scramble. HIPAA (CS-11) becomes relevant only if the business
   is entering healthcare specifically, at whatever stage that happens.
 
-**Rule (CS-12):** Use product stage as a prompt to re-check applicability, not as a substitute for
-checking it — a pre-launch product with EU beta users is already in GDPR's scope regardless of stage.
+**Rule (CS-12): Use product stage as a prompt to re-check applicability, not as a substitute for checking it — a pre-launch product with EU beta users is already in GDPR's scope regardless of stage. Enforcement: explicitly advisory prose (ARC-023) — using product stage as a prompt to re-check applicability is itself guidance about when to apply judgment, not a mechanically checkable condition.**
 
 ## Related
 

package/dist/assets/.arcane/governance/external-verification-standards.md

@@ -44,7 +44,7 @@ This is not a rare edge case specific to any one product; it is a structural pro
 
 The only valid evidence of a successful write is: perform the write, then reload or re-fetch through a path independent of the one that performed the write (a fresh page load, a separate read API call, a different client), then compare the observed value against intent field by field. A screenshot taken without reloading, or a success message read from the same response that carried the write, proves only that the interface accepted input — never that the input was stored.
 
-**Rule (EV-01):** Persisted state is proved by re-reading it, never by the interface that accepted it.
+**Rule (EV-01): Persisted state is proved by re-reading it, never by the interface that accepted it. Enforcement: explicitly advisory prose (ARC-023) — which read path counts as genuinely independent varies by system and is a judgment call applied case-by-case at the point of use, not a property a script can verify after the fact.**
 
 ### EV-02: A green pipeline does not mean the live system reflects the change
 
@@ -54,7 +54,7 @@ The only assertion that counts as evidence is against the actual served artifact
 
 This also cuts the other way: a live check performed in the same breath as a *confirmed-successful* deploy may legitimately still show the old state for a short window — propagation, cache invalidation, and instance rollout all take real time. A mismatch observed immediately after a successful deploy is not by itself proof the deploy failed; it is grounds to wait a short, bounded interval and re-check the served artifact again before escalating. What distinguishes this from ignoring a real failure is that the re-check still has to happen and still has to pass — the propagation window is a reason to retry the observation, never a reason to skip it.
 
-**Rule (EV-02):** A green exit status from a deploy or pipeline step is evidence that the pipeline ran, not that the live system reflects the change — verify against the served artifact itself, allowing a short, bounded propagation window before treating a fresh mismatch as failure.
+**Rule (EV-02): A green exit status from a deploy or pipeline step is evidence that the pipeline ran, not that the live system reflects the change — verify against the served artifact itself, allowing a short, bounded propagation window before treating a fresh mismatch as failure. Enforcement: explicitly advisory prose (ARC-023) — what counts as a short, bounded window versus a genuine failure depends on the specific target system and cannot be fixed as a general mechanical threshold.**
 
 ---
 
@@ -66,7 +66,7 @@ Some external tools expose their own summary of current state alongside the acti
 
 Retrying the identical automated input against a control that just silently dropped it is not a fix — it is a repeat of the same conditions that produced the drop, and it will typically produce the same silent drop again. If the input path is the problem (a field the automation can't reach correctly, a save handler that doesn't fire for scripted events, a control that requires a human-timed interaction the automation collapses), no number of retries changes that. What changes it is a different path: a human operator performing the same step by hand, since a human interacting normally exercises the code path the interface was actually built for.
 
-**Rule (EV-03):** When a console or tool's own state readout disagrees with what you intended to set, trust the readout over the action's apparent success, and hand the step to a human operator rather than retrying the same automated input blindly.
+**Rule (EV-03): When a console or tool's own state readout disagrees with what you intended to set, trust the readout over the action's apparent success, and hand the step to a human operator rather than retrying the same automated input blindly. Enforcement: explicitly advisory prose (ARC-023) — recognizing a genuine disagreement and deciding to stop and escalate are judgment calls made in the moment; this document states the discipline but does not itself implement or require a gate.**
 
 ---
 
@@ -80,7 +80,7 @@ The dangerous part is what "slightly different" does at the comparison site. Equ
 
 The fix is scope discipline: a value that will be compared verbatim carries only the characters the comparison expects, full stop. Explanation belongs in a comment beside the value's declaration, in a separate field, or in documentation — never folded into the value itself.
 
-**Rule (EV-04):** A value that will be compared elsewhere by exact string equality must never carry explanatory commentary appended or interleaved into the same string.
+**Rule (EV-04): A value that will be compared elsewhere by exact string equality must never carry explanatory commentary appended or interleaved into the same string. Enforcement: explicitly advisory prose (ARC-023) — identifying which values are comparison-critical and what counts as appended commentary is a semantic judgment about intent, not a syntactic pattern a generic mechanical check can detect across arbitrary code and data.**
 
 ### EV-05: Enumerate before you write to shared external state
 
@@ -90,7 +90,7 @@ Two operations look interchangeable at the call site but are not: an additive op
 
 The failure this produces is also delayed and displaced: whatever else depended on the value you overwrote breaks only when that other thing is next exercised, which may be long after and far away from the change that actually caused it — making the eventual failure much harder to trace back to its cause than if the destructive write had failed loudly at the time. Enumerating the current value first, before deciding what to write, is what makes the additive-vs-replace choice an informed one rather than a guess.
 
-**Rule (EV-05):** Before writing to a piece of externally-shared state you did not create and do not fully control, first enumerate its current full value, and prefer an additive operation over a create-or-replace operation whenever the system offers both.
+**Rule (EV-05): Before writing to a piece of externally-shared state you did not create and do not fully control, first enumerate its current full value, and prefer an additive operation over a create-or-replace operation whenever the system offers both. Enforcement: explicitly advisory prose (ARC-023) — recognizing which state is shared and not fully owned, and weighing additive against replace, is a case-by-case judgment about a specific external system, not a general invariant a script can verify.**
 
 ---
 
@@ -102,7 +102,7 @@ Many external systems separate the act of accepting a write from the act of refl
 
 The trap runs the other direction too, though: propagation lag is a real phenomenon, not a universal excuse, and it is easy to reach for as an explanation precisely because it requires no further investigation. Before attributing a "not found" to lag, verify the underlying resource independently, through a check that does not depend on the same status system that's reporting the problem — fetch the resource directly with a plain client, resolve a record against an independent resolver, query the actual target rather than a summary of it. If the independent check also fails, there is a real problem to fix, and lag was never the explanation. Only once the real, checkable causes are ruled out does "still propagating" become a legitimate conclusion rather than a guess dressed up as one.
 
-**Rule (EV-06):** A status of "not found" / "could not fetch" / "pending" observed immediately after submitting or registering something with an external system is often propagation lag in that system's own status reporting rather than a real failure — but before concluding it is lag, independently verify the underlying resource through a different, direct check, and only attribute the status to lag once the real, checkable causes have been ruled out.
+**Rule (EV-06): A status of "not found" / "could not fetch" / "pending" observed immediately after submitting or registering something with an external system is often propagation lag in that system's own status reporting rather than a real failure — but before concluding it is lag, independently verify the underlying resource through a different, direct check, and only attribute the status to lag once the real, checkable causes have been ruled out. Enforcement: explicitly advisory prose (ARC-023) — distinguishing genuine propagation lag from a real failure depends on judgment about the specific system involved, not a property a generic mechanical check can decide.**
 
 ---
 

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/mobile-release-standards.md

@@ -64,8 +64,7 @@ release, with its own binary assignment and its own country list. An operator wh
 release turn green will reasonably conclude the app is live to the public — it is not, and nothing in
 the console actively corrects that assumption.
 
-**Rule (MR-01):** Treat each Google Play track as an independent release requiring its own review and
-its own configuration; passing review on one track never promotes the binary to another.
+**Rule (MR-01): Treat each Google Play track as an independent release requiring its own review and its own configuration; passing review on one track never promotes the binary to another. Enforcement: structured spell gate (ARC-023) — spell-eas-store-deploy opens its Google Play section with this exact rule as a read-first prerequisite, so no per-track setup or deployment step proceeds under the wrong assumption that another track's review already covers it.**
 
 ### MR-02: A fresh production track starts with zero countries — and fails silently about why
 
@@ -75,8 +74,7 @@ with your release / To save, fix errors" that never names the actual cause. The
 summary reading `0 countries / regions` — set the country list on the track before attempting to build
 the release, not after the generic error appears.
 
-**Rule (MR-02):** Before building a release for any Google Play track, confirm its country/region list
-is non-empty; a generic "fix errors" message with no named cause is this failure's signature.
+**Rule (MR-02): Before building a release for any Google Play track, confirm its country/region list is non-empty; a generic "fix errors" message with no named cause is this failure's signature. Enforcement: structured spell gate (ARC-023) — spell-eas-store-deploy's Google Play setup step 2 requires confirming the track's country/region count is non-empty before building that release.**
 
 ### MR-03: Saving is not submitting
 
@@ -85,8 +83,7 @@ through an explicit "Send changes for review" action, which itself carries a sec
 A workflow that stops at "Save" ships nothing. The listing pages carry the identical trap under a
 differently-worded "Save and publish" action with its own second dialog.
 
-**Rule (MR-03):** After any Google Play console edit, look for and complete the explicit send-for-review
-(or save-and-publish) action and its confirmation dialog — "saved" is not a release state.
+**Rule (MR-03): After any Google Play console edit, look for and complete the explicit send-for-review (or save-and-publish) action and its confirmation dialog — "saved" is not a release state. Enforcement: structured spell gate (ARC-023) — spell-eas-store-deploy's repeat-deployment step for Google Play requires locating and completing that confirmation dialog before the release counts as shipped.**
 
 ---
 
@@ -99,8 +96,7 @@ re-render, shifting which question sits at which row. A batch of clicks issued a
 lands on the wrong questions and can silently set an unintended answer — including sensitive categories
 like graphic violence or location sharing.
 
-**Rule (MR-04):** Answer the IARC questionnaire one question at a time, and re-read the full form after
-any change to the app's category, rather than assuming the row order is stable.
+**Rule (MR-04): Answer the IARC questionnaire one question at a time, and re-read the full form after any change to the app's category, rather than assuming the row order is stable. Enforcement: structured spell gate (ARC-023) — spell-eas-store-deploy's Google Play setup step 5 requires re-reading the full IARC form after any category change before submitting answers.**
 
 ### MR-08: The "no deobfuscation file" warning is benign and permanent
 
@@ -109,8 +105,7 @@ wired up. This warning does not resolve itself and does not indicate a build def
 every future release until a mapping file is actually uploaded. State this explicitly wherever it
 appears in documentation or in-flight guidance, since it reads as alarming on a first submission.
 
-**Rule (MR-08):** Treat Google Play's "no deobfuscation file" warning as an expected, permanent state
-absent mapping-file upload — not a signal of a broken release.
+**Rule (MR-08): Treat Google Play's "no deobfuscation file" warning as an expected, permanent state absent mapping-file upload — not a signal of a broken release. Enforcement: explicitly advisory prose (ARC-023) — spell-eas-store-deploy's Known Pitfalls list mentions this warning for context, but no step checks for it or blocks on it; treating it as benign rather than a build defect depends on the operator's own judgment.**
 
 ---
 
@@ -124,8 +119,7 @@ collection. Because both declarations are public, a reviewer or a user can compa
 two stores' answers for the same app must describe the same underlying behavior, not merely satisfy each
 store's form independently.
 
-**Rule (MR-05):** Data-safety and privacy declarations across both stores must agree with each other on
-what is actually collected, using "leaves the device" as the collection test in both places.
+**Rule (MR-05): Data-safety and privacy declarations across both stores must agree with each other on what is actually collected, using "leaves the device" as the collection test in both places. Enforcement: structured spell gate (ARC-023) — spell-eas-store-deploy's Google Play setup step 6 requires confirming the data-safety declaration agrees with the App Store's own App Privacy answers before submission.**
 
 ### MR-06: The stores' locale catalogues differ
 
@@ -134,8 +128,7 @@ identical between Apple and Google. A locale available on one store may not exis
 default-language or locale-coverage choice has to be made against each store's own list — never copied
 across from the other store's configuration.
 
-**Rule (MR-06):** Resolve locale/language coverage against each store's own supported-locale list
-independently; do not assume the other store's locale set applies.
+**Rule (MR-06): Resolve locale/language coverage against each store's own supported-locale list independently; do not assume the other store's locale set applies. Enforcement: explicitly advisory prose (ARC-023) — spell-eas-store-deploy's Known Pitfalls list cites this rule for context, but resolving locale coverage against each store's own catalogue is left to the operator's judgment, with no checkable state or step gating it.**
 
 ---
 
@@ -148,8 +141,7 @@ cap. An app with genuinely distinct account types (consumer vs. business, for ex
 account supplied directly, with prose describing how a reviewer reaches the other flows — there is no
 mechanism for supplying multiple credential sets natively.
 
-**Rule (MR-07):** Provide one working reviewer account per app submission, with any additional
-account-type flows described in prose rather than as separate credentials.
+**Rule (MR-07): Provide one working reviewer account per app submission, with any additional account-type flows described in prose rather than as separate credentials. Enforcement: structured spell gate (ARC-023) — spell-eas-store-deploy's Google Play setup step 7 requires a working reviewer account to be provided before the submission steps that follow it.**
 
 ### MR-09: Read the actual signing certificate — never infer it
 
@@ -163,8 +155,7 @@ about certificate matching, since that flow never checks certificates. This is t
 `EV-01` states in general form — re-read the actual persisted/served state, never trust the interface —
 applied to a case where the "interface" is a console page that may not even show the value in question.
 
-**Rule (MR-09):** Never infer an Android signing SHA-1 from a console page; read the certificate the
-installed app actually presents, via `adb logcat` against a Play-delivered install (`EV-01`).
+**Rule (MR-09): Never infer an Android signing SHA-1 from a console page; read the certificate the installed app actually presents, via `adb logcat` against a Play-delivered install (`EV-01`). Enforcement: structured spell gate (ARC-023) — cited by spell-eas-store-deploy's Known Pitfalls step, which requires reading the certificate via `adb logcat` against a Play-delivered install before trusting any `(package, SHA-1)`-keyed integration, applying the general EV-01 re-read-actual-state discipline to this specific case.**
 
 ### MR-10: Android OAuth clients are scoped to one `(package, SHA-1)` pair, custom scheme off by default
 
@@ -174,8 +165,7 @@ shared one. Separately, new Android OAuth clients ship with "Enable custom URI s
 default; leaving it off produces a visible `Error 400: invalid_request`, which is a console
 configuration gap, not a code defect.
 
-**Rule (MR-10):** Provision one Android OAuth client per distinct `(package, SHA-1)` pair, and confirm
-"Enable custom URI scheme" is on for any client that needs a custom-scheme redirect.
+**Rule (MR-10): Provision one Android OAuth client per distinct `(package, SHA-1)` pair, and confirm "Enable custom URI scheme" is on for any client that needs a custom-scheme redirect. Enforcement: structured spell gate (ARC-023) — spell-eas-store-deploy's Known Pitfalls step requires confirming each OAuth client's package/SHA-1 pairing and its custom-URI-scheme toggle state before relying on a custom-scheme redirect.**
 
 ### MR-11: The public developer address comes from D-U-N-S, and confirming it locks it in
 
@@ -187,9 +177,7 @@ first, wait for propagation (days to weeks), let Google re-sync, and only then c
 verification carries its own hard deadline, so this correction needs to start early enough that the
 D&B propagation window still fits before that deadline.
 
-**Rule (MR-11):** Correct the address at the D-U-N-S source and allow it to propagate before confirming
-it in the Google Play console — confirming first permanently publishes whatever address is on file at
-that moment.
+**Rule (MR-11): Correct the address at the D-U-N-S source and allow it to propagate before confirming it in the Google Play console — confirming first permanently publishes whatever address is on file at that moment. Enforcement: structured spell gate (ARC-023) — spell-eas-store-deploy's Google Play setup step 8 requires the D-U-N-S correction to propagate before the console confirmation step runs.**
 
 ---
 
@@ -205,8 +193,7 @@ dependency's manifest entries survive independently of whether anything still ca
 permission means removing the dependency that declares it, and the removal must be re-verified against a
 newly built artifact, not assumed from the source diff.
 
-**Rule (MR-12):** Verify declared permissions against the actually built artifact, not against source
-code's apparent usage, both before submission and after removing a permission-declaring dependency.
+**Rule (MR-12): Verify declared permissions against the actually built artifact, not against source code's apparent usage, both before submission and after removing a permission-declaring dependency. Enforcement: structured spell gate (ARC-023) — spell-eas-store-deploy's Known Pitfalls step requires running `aapt2 dump permissions` (or an equivalent manifest inspection) against the built artifact before submission.**
 
 ### MR-13: Android notification icons need a dedicated asset, shipped natively
 
@@ -217,8 +204,7 @@ notification icon, check the notification shade specifically rather than the hea
 OEM skins legitimately omit the small icon from the banner view while still rendering it correctly in the
 shade. The branded, full-color icon slot is `largeIcon`, a separate asset from the required small icon.
 
-**Rule (MR-13):** Ship a dedicated monochrome small-icon asset for Android notifications in a native
-build (never an OTA), and diagnose icon issues via the notification shade, not the heads-up banner.
+**Rule (MR-13): Ship a dedicated monochrome small-icon asset for Android notifications in a native build (never an OTA), and diagnose icon issues via the notification shade, not the heads-up banner. Enforcement: explicitly advisory prose (ARC-023) — spell-eas-store-deploy's Known Pitfalls list restates this rule for awareness, but no step verifies the icon asset exists or checks the notification shade before proceeding; both remain judgment calls for the operator.**
 
 ### MR-14: Android's native `AlertDialog` caps at three buttons
 
@@ -227,9 +213,7 @@ Android's native `AlertDialog` silently drops any button past a hard cap of thre
 the *Cancel* row, leaving a dialog with no way to dismiss it. iOS has no equivalent limit
 (`ActionSheetIOS` supports an arbitrary option count).
 
-**Rule (MR-14):** For any Android menu that could exceed three options, use a real bottom sheet
-dismissible at least three ways (an explicit cancel row, a scrim tap, and the hardware back gesture)
-instead of `Alert.alert`.
+**Rule (MR-14): For any Android menu that could exceed three options, use a real bottom sheet dismissible at least three ways (an explicit cancel row, a scrim tap, and the hardware back gesture) instead of `Alert.alert`. Enforcement: explicitly advisory prose (ARC-023) — spell-eas-store-deploy's Known Pitfalls list cites this rule for awareness, but the fix is a UI code change with no console or platform state for the deploy workflow to check before proceeding; catching it depends on code review, not this spell.**
 
 ## Related
 

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)