arcane-cli 0.16.4 → 0.17.0

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

@@ -306,6 +306,7 @@ When more than one agent may work in the same repository simultaneously:
 5. **Story ownership.** Only the agent assigned to a feature modifies that feature's `stories.json`. If the assigned agent does not match your slug, halt and report.
 6. **No cross-repo mutations without coordination.** If a story requires changes in two repos, complete and push one before starting the second. Never hold uncommitted changes across two repos simultaneously.
 7. **Merge window.** When two agents have PRs open for the same repo, the first to merge wins; the second must rebase before merging. The operator coordinates merge order if there are conflicts.
+8. **Working-tree vantage point (EF-33 / ARC-028 R7) — applies even to a solo agent, not only when multiple agents are active.** Listed here because it's the working-tree/multi-primitive dimension ARC-028 R7 defines, not because the hazard requires a second agent: a lone agent working through a bridged/remote mount hits the identical near-miss. All linked worktrees share one physical `.git` and `.git/config` — treat config-mutating operations as fleet-wide, not scoped to the worktree that ran them. Before any `git worktree prune`, `worktree remove`, `gc`, or branch deletion, confirm the target path from the *current process's own filesystem* (not just Git's own report) — a repository or its linked worktrees reached through a bridged/remote mount can report a live, healthy worktree as safe to prune with no error distinguishing "confirmed absent" from "not resolvable from here." See [governance/git-conventions.md](git-conventions.md) Same-Vantage-Point Check section for the full procedure, including how to establish that your own vantage point is trustworthy before relying on it.
 
 ---
 

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

@@ -57,6 +57,17 @@ For docs-only repos (Arcane):
 
 ### .NET Backend Pipeline
 
+Fail-safe path filter (ARC-022): **exclude** known-inert doc paths rather than **include** a
+named code directory — a new code directory added outside `src/**` would silently never trigger
+this pipeline under an include filter. The exclude entry is a **filetype** glob, not a directory
+glob, and deliberately just one entry: `docs/**`/`journal/**`/`.arcane/governance/**`-style
+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
+`**/*.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.
+
 ```yaml
 # azure-pipelines.yml
 trigger:
@@ -64,8 +75,8 @@ trigger:
     include:
       - main
   paths:
-    include:
-      - src/**
+    exclude:
+      - '**/*.md'
 
 pr:
   branches:
@@ -97,11 +108,19 @@ steps:
 
 ### Node.js Pipeline
 
+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.
+
 ```yaml
 trigger:
   branches:
     include:
       - main
+  paths:
+    exclude:
+      - '**/*.md'
 
 pr:
   branches:
@@ -129,7 +148,27 @@ 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
+`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
+report flagged for this template specifically, grouped with .NET's `src/**` problem, not treated
+as a different category. `**/*.tf`/`**/*.tfvars` has the same closure property `**/*.md` has for
+the Markdown-lint template below: Terraform files trigger this pipeline from *anywhere* in the
+tree, while a Node.js/`.NET` source change still correctly does not. Widened to also cover this
+pipeline's own definition file, so an edit to the pipeline itself is validated rather than
+silently unreviewed.
+
+Widened further to cover Terraform's JSON-syntax file variants (`.tf.json`/`.tfvars.json`,
+HashiCorp's own first-class alternative syntax to `.tf`/`.tfvars`) and its dependency lock file
+(`.terraform.lock.hcl`, one per root module directory). ARC-022 names lockfiles as a non-negotiable
+always-trigger category in their own right, independent of the general "Terraform files trigger
+this pipeline" argument above — a lock file's own name doesn't end in `.tf`/`.tfvars`, so it would
+have silently fallen through the filetype glob above without a named entry of its own.
+
 ```yaml
+# azure-pipelines.terraform.yml
 trigger: none  # Manual only for apply
 
 pr:
@@ -138,7 +177,12 @@ pr:
       - main
   paths:
     include:
-      - infrastructure/terraform/**
+      - '**/*.tf'
+      - '**/*.tfvars'
+      - '**/*.tf.json'
+      - '**/*.tfvars.json'
+      - '**/.terraform.lock.hcl'
+      - azure-pipelines.terraform.yml
 
 pool:
   vmImage: 'ubuntu-latest'
@@ -160,7 +204,14 @@ steps:
 
 ### Markdown Lint Pipeline
 
+Also correctly include-scoped, for the same reason as the Terraform pipeline: this pipeline
+exists specifically to lint markdown, not to validate code generally, and `**.md` already has the
+same anywhere-in-the-tree closure property `**/*.tf` gives the Terraform template above (unlike a
+directory-prefix pattern, it was never the gap this fix needed to close). Widened to cover its
+own definition file too.
+
 ```yaml
+# azure-pipelines.markdown.yml
 trigger:
   branches:
     include:
@@ -168,6 +219,7 @@ trigger:
   paths:
     include:
       - '**.md'
+      - azure-pipelines.markdown.yml
 
 pool:
   vmImage: 'ubuntu-latest'
@@ -187,6 +239,54 @@ steps:
 
 ---
 
+## Never Trust Commit Metadata for CI Skipping (ARC-022)
+
+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*.
+
+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:
+it lets a malicious or careless commit self-certify as "safe to skip" regardless of what it
+actually touched. Path-based filtering (above) is the only trust signal this repository
+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
+`[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
+cannot disable it from the YAML alone. The required-before-merge gate this repo's own Branch
+Policies table relies on (**build validation on the PR's merge commit**) is documented to run
+*regardless* of `[skip ci]` and its variants, so the merge gate itself stays sound. What is **not**
+protected: any other trigger-based run this repo depends on for signal outside that one gate —
+direct pushes to a non-PR branch, a secondary environment build, a dashboard keyed off pipeline
+status. Treat those as a residual, platform-level exposure this document can flag but not close;
+if a trigger-based run must be tamper-resistant, that requires an organization-level policy
+outside this repo's own YAML, not a governance sentence.
+
+## Branch-Policy Path-Filter Alignment (ARC-022)
+
+A YAML pipeline's own `trigger`/`pr` path filter and an Azure DevOps branch policy's **build
+validation path filter** are two independent mechanisms, and only one of them controls whether a
+passing build is actually *required* before a PR can merge. If the branch policy's path filter is
+narrower than the pipeline's own trigger scope, a change that falls outside the policy's filter
+can merge with **no build check required at all** — even though the pipeline itself is correctly
+scoped and would have run and caught a problem, because nothing forced it to be a merge
+requirement for that specific change.
+
+**Concrete failure mode:** the .NET pipeline above triggers on everything except docs (exclude
+filter, fail-safe). If the repo's branch policy still requires the build check only for changes
+under `paths: src/**` (an older include-style policy filter, or one configured before this repo
+adopted exclude-based YAML triggers), a change to a new top-level code directory outside `src/`
+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.
+
+---
+
 ## Deployment Gates
 
 | Environment | Gate | Who Approves |

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

@@ -359,6 +359,21 @@ git push origin --delete type/old-topic  # delete remote branch (safety net; ign
 
 This applies to all actors — humans, interactive tools (Copilot, Claude), and autonomous agents. The `spell-commit-work` and `spell-close-session` prompts enforce this check.
 
+### Same-Vantage-Point Check (EF-33 / ARC-028 R7)
+
+`git worktree list` can **truthfully** report a live, healthy linked worktree as `prunable` when read through a cross-filesystem bridge — a Linux-side mount of a Windows host, a remote-mounted volume, a container bind-mount, any path-translation layer between the reading process and the repository's actual owning environment. The registered absolute path simply doesn't resolve from that vantage point, even though the directory exists and is valid from the machine that owns it. Nothing in Git's own output distinguishes "confirmed absent" from "not resolvable from this process's filesystem view" — both render identically as `prunable`. (A separate, unconditional hazard applies to `git branch --merged` regardless of vantage point — see the note at the end of this section; do not assume that one only matters when a bridge is in play.)
+
+**Before running any Git command with irreversible effects on worktree, branch, or ref state** — `git worktree prune`, `git worktree remove`, `git gc --prune=now`, `git branch -d`/`-D`, or manual deletion of `.git/worktrees/<name>` metadata — **when the repository or its linked worktrees might be reached through more than one filesystem view**, perform the same-vantage-point check first:
+
+1. Resolve the registered path exactly as Git sees it (`git worktree list --porcelain`'s `worktree` field).
+2. **First confirm your OWN vantage point, before trusting anything else.** Checking `Test-Path`/`[ -e "$path" ]`/`os.path.exists()` against the registered path is only meaningful if the process running that check is itself in the same environment that registered the worktree — running the "independent" check from the *same* bridged/mounted process that produced the `git worktree list` read reproduces the exact failure this section exists to prevent, since both signals are corrupted by the identical wrong vantage point. A concrete, checkable signal for this: does the registered path's own syntax match the current process's native OS conventions (drive letter + backslashes for Windows; POSIX root + forward-slashes for Linux/macOS)? A registered path in a **foreign** syntax (e.g. a `C:\...` path seen from a POSIX shell, or vice versa) is itself proof you are not viewing this repository from the environment that registered it — treat every entry as unconfirmed on sight, skip step 3 entirely, and go straight to step 4. Matching syntax alone is not proof of a shared vantage point (two different containers can both use POSIX paths) — it only rules out the specific cross-OS case; it does not establish confidence on its own.
+3. Only if step 2 gives you a genuine reason to trust your own vantage point (matching path syntax, plus independent knowledge that this is the same machine/container/session that registered the worktree — not merely "the check ran without error"): confirm the path from the current process's own filesystem (`Test-Path` / `[ -e "$path" ]` / `os.path.exists()` / equivalent). Never treat Git's own `prunable` annotation as sufficient evidence on its own, and never treat "the existence check returned a clean answer" as sufficient either — a clean answer from the wrong vantage point is not a safe answer.
+4. If step 2 raised any doubt, if the path syntax doesn't match, or if there is any uncertainty about which environment actually owns the repository, **stop and ask** rather than trusting the more convenient answer. This is the default outcome whenever step 2's confidence isn't genuinely established — not a rare escape hatch reserved for exceptional cases.
+
+This is documented as a standing operational caution, not a code-level gate: EF-33's own intake report frames the underlying defect as cross-machine/cross-mount filesystem visibility, which no single CI runner can reproduce — the confirmation step above must be followed manually by whichever human or agent is about to run the destructive command. Confirmed as a live near-miss on 2026-08-03: a Linux-side read reported eight healthy linked worktrees `prunable`; the same repository read from Windows (their actual owning environment) showed zero prunable entries, and `git worktree prune -v` there removed nothing.
+
+**Unconditional, vantage-point-independent note on branch deletion:** `git branch --merged` can also report a fully-landed branch as unmerged — or the reverse confusion, a branch never actually reviewed but ancestry-visible — because Git's rebase-and-fast-forward and squash merge strategies (both sanctioned by this repo's own merge-strategy table above) rewrite commit SHAs, defeating ancestry-based detection. This has nothing to do with filesystem bridges — it fires identically on a single machine with no mount involved. See the ancestry-vs-content-verification finding in `TODO.md`'s PR Workflow section for the full mechanism; verify branch content before deleting regardless of what vantage-point confidence steps 1-4 above establish.
+
 ### ADO PR Lifecycle — Complete Command Reference
 
 When working in an Azure DevOps repo with branch protection (direct push to `main` rejected), use this exact sequence. Several shortcut tools have known reliability issues on Windows — use the commands below instead.

package/dist/assets/.github/prompts/spell-check-drift.prompt.md

@@ -27,8 +27,8 @@ Use these files first:
 - [ai-context/system-prompt-context.md](../../ai-context/system-prompt-context.md)
 - [agents/agent-policies.md](../../.arcane/governance/agent-policies.md)
 - Most recent journal file(s) in [journal/](../../journal/)
-- Relevant business overviews under [ventures/](../../ventures/)
-- `ventures/registry.json`, if present (hub-role and registry-consistency detectors)
+- Relevant business overviews under `{BUSINESS_ROOT}/` (resolve from `.arcane.json`'s `business_root` field, default `ventures/` if unset)
+- `{BUSINESS_ROOT}/registry.json`, if present (hub-role and registry-consistency detectors)
 
 Scope selection (`--scope <value>`, default `all`):
 
@@ -49,12 +49,12 @@ Concrete detectors to run (in addition to general contradiction/stale-date check
   - If normalized content differs, report **real content drift** with normal severity grading.
   - If normalized content matches, report **line-ending-only drift** separately. Do not count these paths as real content findings and do not include them in severity totals or the Go / No-Go decision.
   - Report exact path counts for both classes. Never summarize all byte-different files as content drift.
-- **Hub-artifact leak (non-hub repos)** — if `.arcane.json` does not have `role: "hub"`, the existence of any `ventures/*/IDEAS.md`, `ventures/*/TODO.md`, or `ventures/registry.json` is **Critical**: hub-only artifacts (potentially including sibling-venture and portfolio data) do not belong in a repo that isn't a declared hub. This check is deliberately structural (file existence only) — a non-hub repo cannot safely hold the sibling-name list a content-level check would need, so that asymmetry is by design, not a gap.
+- **Hub-artifact leak (non-hub repos)** — if `.arcane.json` does not have `role: "hub"`, the existence of any `{BUSINESS_ROOT}/*/IDEAS.md`, `{BUSINESS_ROOT}/*/TODO.md`, or `{BUSINESS_ROOT}/registry.json` (resolve `{BUSINESS_ROOT}` the same way as above -- a consumer repo can still have a configured `business_root` left over from a prior role change, so this must not skip resolution just because the repo isn't currently a hub) is **Critical**: hub-only artifacts (potentially including sibling-venture and portfolio data) do not belong in a repo that isn't a declared hub. This check is deliberately structural (file existence only) — a non-hub repo cannot safely hold the sibling-name list a content-level check would need, so that asymmetry is by design, not a gap.
 - **Hub role/registry consistency (hub repos only)** — when `.arcane.json` has `role: "hub"`:
-  - `role: "hub"` with no `{business_root}` directory (default `ventures/`) present — **High**: the manifest claims a role the repo can't actually fulfill.
-  - `ventures/registry.json` slugs that don't match an existing `ventures/<slug>/` folder, or venture folders with no registry entry — **Medium**, both directions.
+  - `role: "hub"` with no `{BUSINESS_ROOT}` directory (default `ventures/`) present — **High**: the manifest claims a role the repo can't actually fulfill.
+  - `{BUSINESS_ROOT}/registry.json` slugs that don't match an existing `{BUSINESS_ROOT}/<slug>/` folder, or venture folders with no registry entry — **Medium**, both directions.
   - Malformed `status: promoted → …` / `status: dropped …` markers in any book (unparseable destination, missing date) — **Low**.
-  - A `ventures/<slug>/` folder with a `role`-shaped `.arcane.json`-like marker of its own (i.e., it looks like it's trying to be a hub itself) — **Medium**: flag for operator review; nested hubs are unsupported.
+  - A `{BUSINESS_ROOT}/<slug>/` folder with a `role`-shaped `.arcane.json`-like marker of its own (i.e., it looks like it's trying to be a hub itself) — **Medium**: flag for operator review; nested hubs are unsupported.
 
 For each drift finding include:
 

package/dist/assets/.github/prompts/spell-close-session.prompt.md

@@ -148,7 +148,7 @@ Rules:
    - Resolve `<remote>` and `<trunk>` from observed Git/provider state: use the usable authenticated remote selected in step 9 and the merged PR's target branch (falling back to that remote's default branch). Never assume `origin` or `main`.
    - Verify through the detected provider that the PR is merged before changing branches.
    - Run `git switch <trunk>` followed by `git pull --ff-only <remote> <trunk>`. Do not end a remote-backed session on a topic branch.
-    - Delete the local topic branch: `git branch -d <branch>`.
+    - Delete the local topic branch: `git branch -d <branch>` — if the repository or its linked worktrees might be reached through more than one filesystem view, run the same-vantage-point check first (EF-33 / ARC-028 R7, [governance/git-conventions.md](../../.arcane/governance/git-conventions.md) Same-Vantage-Point Check section).
    - Verify `git log --oneline -3` shows the merged change at HEAD.
     - If stale local branches exist (merged or older than 7 days), list them and suggest cleanup.
     - See [governance/git-conventions.md](../../.arcane/governance/git-conventions.md) Post-Merge Cleanup section.

package/dist/assets/.github/prompts/spell-commit-work.prompt.md

@@ -101,7 +101,7 @@ Workflow:
    - `infrastructure` — infrastructure/ directory, hardware, OS setup
    - `decisions` — DECISIONS.md updates
    - `journal` — journal/ entries
-   - `business` — ventures/ directory
+   - `business` — `{BUSINESS_ROOT}` directory (resolve from `.arcane.json`'s `business_root` field, default `ventures/` if unset)
    - `playbooks` — playbooks/ directory
    - `governance` — governance/ directory
    - Multiple scopes? Pick the primary one or use a broader scope like `docs` or `repo`.
@@ -206,7 +206,7 @@ Workflow:
   - `git push origin --delete <branch>` (if already deleted, treat as non-fatal)
   - `git fetch --prune origin`
 - If `<branch>` is attached to an active worktree, skip local branch deletion.
-- If branch is not attached to any active worktree, run `git branch -d <branch>`.
+- If branch is not attached to any active worktree, run `git branch -d <branch>` — but if the repository or its linked worktrees might be reached through more than one filesystem view, run the same-vantage-point check first (EF-33 / ARC-028 R7, [governance/git-conventions.md](../../.arcane/governance/git-conventions.md) Same-Vantage-Point Check section) before trusting a "safe to delete" read.
 - Return to `main` only when appropriate for the active session/worktree context.
 - If other stale local branches exist (merged or older than 7 days), list them and suggest cleanup.
 - See [governance/git-conventions.md](../../.arcane/governance/git-conventions.md) Post-Merge Cleanup section.

package/dist/assets/.github/prompts/spell-open-session.prompt.md

@@ -28,7 +28,7 @@ Use these files first:
 - [ai-context/system-prompt-context.md](../../ai-context/system-prompt-context.md)
 - [agents/agent-policies.md](../../.arcane/governance/agent-policies.md)
 - Most recent journal file(s) in [journal/](../../journal/)
-- Relevant business overview(s) under [ventures/](../../ventures/)
+- Relevant business overview(s) under `{BUSINESS_ROOT}/` (resolve from `.arcane.json`'s `business_root` field, default `ventures/` if unset)
 
 **Handoff Detection (run before anything else):**
 
@@ -70,17 +70,17 @@ Then produce output in this exact structure:
 
 Before anything else, check:
 
-- **Current branch:** Run `git branch --show-current` and `git worktree list`. Report the current state; do not switch during this read-only check. Branch creation/switching is owned by the lazy Mutation Guard.
+- **Current branch:** Run `git branch --show-current` and `git worktree list`. Report the current state; do not switch during this read-only check. Branch creation/switching is owned by the lazy Mutation Guard. **Caveat (EF-33):** if this repository or its linked worktrees might be reached through more than one filesystem view (a bridged/remote mount, a container bind-mount), `git worktree list` can truthfully report a live, healthy worktree as `prunable` when read from a vantage point that can't resolve its registered path — this is a read-only report, not a reason to act; never run a destructive worktree/branch command on its output alone (see git-conventions.md's Same-Vantage-Point Check section before any such command elsewhere in this or later sessions).
 - **Session branch naming compliance:** Branch names must be human-readable and policy-compliant:
   - Interactive session default: `sessions/YYYY-MM-DD-<topic-slug>` (kebab-case topic from current task/session objective).
   - Disallow random adjective-noun generator names (example: `ideal-disco`) as session defaults.
   - If current branch is non-compliant and no active PR depends on it, record the required rename for the Mutation Guard. Do not rename during a read-only session.
   - If an active PR uses the old branch name, do not force-delete the old remote branch; flag it and continue with a follow-up rename plan.
-- **Stale local branches:** Run `git branch --merged main` to list branches already merged that should be deleted.
-- **Tracker configuration check (early):** resolve active tracking settings before planning. Read root `.arcane.json` first (if present), then the current feature PRD frontmatter if available. A self-host marker under `src/assets/` is doctor metadata, not active repository configuration; never use it as tracking provenance. If neither active source sets tracking, ask the operator and treat the answer as session-scoped until EF-14 defines persistent configuration:
+- **Stale local branches:** Run `git branch --merged main` to list branches already merged that should be deleted. This lists candidates only — before deleting any, apply the same-vantage-point check (EF-33) and, separately, verify by content rather than trusting ancestry alone (rebase-and-fast-forward merges are invisible to `--merged`; see the merged-branch cleanup item in TODO.md).
+- **Tracker configuration check (early):** resolve active tracking settings before planning, in this order: root `.arcane.json` (if present) -> the committed self-hosted source manifest (`src/assets/.arcane.json`, read only when it declares `selfHosted: true` -- this is EF-14's recorded self-hosting resolution tier, distinct from treating the mere presence of a self-host marker as license to infer other, unrelated config) -> the current feature PRD frontmatter -> ask. Persisted once at `spell init`/`spell update` (EF-14); do not re-ask when any of the first three sources already sets it.
   - `tracking_mode: internal | external`
   - `external_provider: ado | jira | other`
-  - If missing, ask the operator to choose now. Default to `external` + `ado` only when existing ADO context already exists (backward compatibility).
+  - If all three sources are absent, ask: "Track work in this repo (TODO.md / PRDs)" [internal] vs "Track work in an external tracker (Azure DevOps / Jira / other)" [external]. Default to `external` + `ado` only when existing ADO context already exists (backward compatibility).
 - **Open PRs (external/ado mode only):** if tracking mode is `external` with provider `ado` and ADO MCP is available, list all open PRs across all repos in the configured repo list (resolve from `.arcane.json`; if unset, ask the operator which repos to scan). Flag PRs older than 3 days as stale, older than 7 days as overdue. Format each as a clickable markdown link: `[PR #{id} — {title}](https://dev.azure.com/{ADO_ORG}/{ADO_PROJECT}/_git/{repo}/pullrequest/{id})` — resolve `{ADO_ORG}` and `{ADO_PROJECT}` from `.arcane.json` / PRD frontmatter; ask if unset. Never list a bare `PR #NNN`.
 - **Uncommitted changes:** Run `git status` and report any uncommitted files.
 - **Arcane version check (two-axis):** If `.arcane.json` exists in the repo root, check both whether the repo's managed files are behind the installed CLI _and_ whether the installed CLI is behind the latest published version of `arcane-cli`:

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

@@ -31,8 +31,14 @@ Workflow:
    external_provider: ado | jira | other
    ```
 
+   Resolve in this order, matching spell-open-session's own resolution chain (EF-14): root
+   `.arcane.json` (if present) → the committed self-hosted source manifest (`src/assets/.arcane.json`,
+   read only when it declares `selfHosted: true`) → the current feature PRD frontmatter → ask.
+   Do not re-ask when any of the first three sources already sets it.
+
    Rules:
    - If not explicitly set and ADO context is already present (work item ID + org/project), default to `tracking_mode: external`, `external_provider: ado` for backward compatibility.
+   - If none of the three sources above set it and no ADO context exists, ask: "Track work in this repo (TODO.md / PRDs)" [internal] vs "Track work in an external tracker (Azure DevOps / Jira / other)" [external].
    - If `tracking_mode=internal`, do not require an external tracker ID.
    - If `tracking_mode=external` and `external_provider=ado`, collect org/project and resolve process template + available work item types before planning:
      ```bash
@@ -64,7 +70,7 @@ Workflow:
    - Are there existing ADRs or constraints?
    - **If `tracking_mode=external` and `external_provider=ado`: What is the ADO work item ID?** — required before proceeding in ADO mode. Store it as `adoWorkItemId` in PRD frontmatter so it flows to `spell-architect` and `stories.json`.
 
-3. **Research context** — check the relevant business docs in `ventures/` and any existing code repos.
+3. **Research context** — check the relevant business docs under `{BUSINESS_ROOT}/` (resolve from `.arcane.json`'s `business_root` field, default `ventures/` if unset) and any existing code repos.
 
 4. **Generate PRD.md** with these sections:
    ```markdown

package/dist/assets/.github/prompts/spell-save-idea.prompt.md

@@ -21,10 +21,12 @@ The user's input IS the idea. If no idea text was provided, ask one short questi
 
 ## Step 0 — Venture Targeting (Hub Only)
 
-If the input names a venture ("save this idea for ordo", `--venture <slug>`), resolve it through `ventures/registry.json`'s aliases first (exact slug → alias → closest match offered — never guessed). Unknown slug:
+Resolve `{BUSINESS_ROOT}` from `.arcane.json`'s `business_root` field (default `ventures/` if unset) before anything below.
+
+If the input names a venture ("save this idea for ordo", `--venture <slug>`), resolve it through `{BUSINESS_ROOT}/registry.json`'s aliases first (exact slug → alias → closest match offered — never guessed). Unknown slug:
 
 ```
-No venture "<slug>" under ventures/ (closest: ordovica, tidewright).
+No venture "<slug>" under {BUSINESS_ROOT}/ (closest: ordovica, tidewright).
 1) use <closest>  2) save to hub root IDEAS.md  3) cancel (create the venture first: spell-summon-venture)
 ```
 

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

@@ -93,7 +93,7 @@ Workflow:
 9. **Post-merge branch cleanup** (after the PR merges) — the merge was the human gate, so cleanup is automatic:
    - Switch to the main branch (e.g. `git checkout main`).
    - Pull the latest (e.g. `git pull`).
-   - Delete the merged topic branch locally (e.g. `git branch -d <branch>`).
+   - Delete the merged topic branch locally (e.g. `git branch -d <branch>`) — if the repository or its linked worktrees might be reached through more than one filesystem view, run the same-vantage-point check first (EF-33 / ARC-028 R7, [governance/git-conventions.md](../../.arcane/governance/git-conventions.md) Same-Vantage-Point Check section).
    - Delete the merged topic branch on the remote (e.g. `git push origin --delete <branch>`); tolerate an already-deleted remote branch.
    - Prune stale remote-tracking refs (e.g. `git fetch --prune` or `git remote prune origin`).
 

package/dist/assets/.github/prompts/spell-summon-venture.prompt.md

@@ -7,7 +7,7 @@ agent: agent
 
 ## Executive Summary
 
-- This prompt creates a new venture in a **hub** repo: the venture folder, its starter docs, its two idea/todo books, and its `ventures/registry.json` entry — one operation instead of several manual steps.
+- This prompt creates a new venture in a **hub** repo: the venture folder, its starter docs, its two idea/todo books, and its registry entry — one operation instead of several manual steps.
 - **Hub-gated:** requires `role: "hub"` in `.arcane.json`. Refuses cleanly in a consumer repo, pointing at the right place to capture the idea instead.
 - Use this when starting a new venture (business, product, or personal project) that the hub should track.
 - Input format is: `Venture Name | Venture Type | Description` — prompt will ask for missing fields.
@@ -36,7 +36,7 @@ Use these files first (each is optional — if missing, proceed as noted):
 
 - [playbooks/new-business-setup.md](../../playbooks/new-business-setup.md) — setup playbook. If `playbooks/` doesn't exist, skip and derive steps from the venture-type checklist below.
 - [naming-conventions.md](../../.arcane/governance/naming-conventions.md) — slug/file naming rules. If missing, default to lowercase-with-dashes slugs.
-- [ventures/\_template/overview.md](../../ventures/_template/overview.md) — overview template. If missing, generate a minimal overview from the fields below.
+- `{BUSINESS_ROOT}/_template/overview.md` — overview template. If missing, generate a minimal overview from the fields below.
 - [.arcane/templates/venture-template/IDEAS.md](../../.arcane/templates/venture-template/IDEAS.md) and [.arcane/templates/venture-template/TODO.md](../../.arcane/templates/venture-template/TODO.md) — book stubs. If missing, use the header format from [[spell-save-idea|spell-save-idea]] / [[spell-todo|spell-todo]].
 - [README.md](../../README.md) — repo navigation. If missing, skip cross-linking.
 - [project.md](../../project.md) — project context. If missing, skip.
@@ -54,7 +54,7 @@ Use these files first (each is optional — if missing, proceed as noted):
 
 ## Step 3 — Register the Venture
 
-Open (or create, with the standard header — see `ventures/registry.json`'s own `_comment` field for the expected shape) `ventures/registry.json` and append an entry keyed by the slug:
+Open (or create, with the standard header — see `{BUSINESS_ROOT}/registry.json`'s own `_comment` field for the expected shape) `{BUSINESS_ROOT}/registry.json` and append an entry keyed by the slug:
 
 ```json
 "<slug>": {
@@ -83,7 +83,7 @@ Output format:
 
 ## Created
 
-- File and folder paths created, including the `ventures/registry.json` entry.
+- File and folder paths created, including the `{BUSINESS_ROOT}/registry.json` entry.
 
 ## Defaults Applied
 

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

@@ -15,11 +15,13 @@ agent: agent
 
 ---
 
+Resolve `{BUSINESS_ROOT}` from `.arcane.json`'s `business_root` field (default `ventures/` if unset) before either mode below.
+
 ## Sweep Mode (`--sweep`)
 
 If the argument is (or starts with) `--sweep`, skip every other step in this spell entirely and run this instead:
 
-- **In a hub repo:** report `status: new` counts and oldest-entry age for the hub root `TODO.md` plus every `ventures/<slug>/TODO.md` that exists. Group by book, point at `spell-manifest` for entries ready to promote. Report-only — no edits.
+- **In a hub repo:** report `status: new` counts and oldest-entry age for the hub root `TODO.md` plus every `{BUSINESS_ROOT}/<slug>/TODO.md` that exists. Group by book, point at `spell-manifest` for entries ready to promote. Report-only — no edits.
 - **In a consumer repo:** report the same, for the repo-root `TODO.md` only (no venture books exist there).
 
 Output format:
@@ -33,10 +35,10 @@ ventures/ordovica/TODO.md  3 open, oldest 2026-08-10
 
 ## Step 0 — Venture Targeting (Hub Only)
 
-If the input names a venture ("add a todo for ordo", `--venture <slug>`), resolve it through `ventures/registry.json`'s aliases first (exact slug → alias → closest match offered — never guessed). Unknown slug:
+If the input names a venture ("add a todo for ordo", `--venture <slug>`), resolve it through `{BUSINESS_ROOT}/registry.json`'s aliases first (exact slug → alias → closest match offered — never guessed). Unknown slug:
 
 ```
-No venture "<slug>" under ventures/ (closest: ordovica, tidewright).
+No venture "<slug>" under {BUSINESS_ROOT}/ (closest: ordovica, tidewright).
 1) use <closest>  2) add to hub root TODO.md  3) cancel (create the venture first: spell-summon-venture)
 ```
 
@@ -81,7 +83,7 @@ Classify the idea along two axes:
 - `infrastructure` — hardware, OS, cloud, networking, provisioning
 - `governance` — git conventions, agent autonomy, spending controls, work management
 - `ci-cd` — repos, pipelines, build/release automation
-- `business` — a specific business under `ventures/` — name which one
+- `business` — a specific business under `{BUSINESS_ROOT}/` — name which one
 - `product-ideas` — new product concepts or packaging ideas
 - `legal` — LLC, ToS, contracts
 - `playbooks` — runbooks, setup guides, automation scripts
@@ -116,7 +118,7 @@ Determine the target file(s) for each item:
 | Speculative idea or future-facing concept             | `TODO.md` under `## Product Ideas` or the best matching section                    |
 | ADR candidate                                         | `DECISIONS.md` — flag it as pending, do not write the full ADR yet                 |
 | Journal-worthy context                                | `journal/` — propose a filename with today's date slug, do not create the file yet |
-| Business-specific execution item                      | Both `TODO.md` AND the relevant `ventures/<name>/overview.md` reference section  |
+| Business-specific execution item                      | Both `TODO.md` AND the relevant `{BUSINESS_ROOT}/<name>/overview.md` reference section  |
 
 ## Step 4 — Show Proposal
 

package/dist/index.js

@@ -87,10 +87,28 @@ var ManifestCorruptError = class extends Error {
     this.name = "ManifestCorruptError";
   }
 };
+var ManifestInvalidFieldError = class extends Error {
+  constructor(manifestPath2, field, value) {
+    super(
+      `Manifest at "${manifestPath2}" has an unsupported value for "${field}": ${JSON.stringify(value)}.`
+    );
+    this.name = "ManifestInvalidFieldError";
+  }
+};
 var MANIFEST_FILE = ".arcane.json";
+var VALID_TRACKING_MODES = ["internal", "external"];
+var VALID_EXTERNAL_PROVIDERS = ["ado", "jira", "other"];
 function manifestPath(targetDir) {
   return path2.join(targetDir, MANIFEST_FILE);
 }
+function validateTrackingFields(manifest, filePath) {
+  if (manifest.tracking_mode !== void 0 && !VALID_TRACKING_MODES.includes(manifest.tracking_mode)) {
+    throw new ManifestInvalidFieldError(filePath, "tracking_mode", manifest.tracking_mode);
+  }
+  if (manifest.external_provider !== void 0 && manifest.external_provider !== null && !VALID_EXTERNAL_PROVIDERS.includes(manifest.external_provider)) {
+    throw new ManifestInvalidFieldError(filePath, "external_provider", manifest.external_provider);
+  }
+}
 async function readManifest(targetDir) {
   const filePath = manifestPath(targetDir);
   let content;
@@ -102,11 +120,14 @@ async function readManifest(targetDir) {
     }
     throw err;
   }
+  let manifest;
   try {
-    return JSON.parse(content);
+    manifest = JSON.parse(content);
   } catch {
     throw new ManifestCorruptError(filePath);
   }
+  validateTrackingFields(manifest, filePath);
+  return manifest;
 }
 async function writeManifest(targetDir, manifest) {
   const filePath = manifestPath(targetDir);
@@ -2018,12 +2039,40 @@ async function runInit(options, targetDir, assetsDir, packageVersion) {
     });
     role = isHub ? "hub" : "consumer";
   }
+  let tracking_mode;
+  let external_provider;
+  if (profile === "governance-only" || profile === "methodology") {
+    tracking_mode = "internal";
+    external_provider = null;
+  } else if (!options.profile) {
+    console.log();
+    tracking_mode = await select2({
+      message: "How will work be tracked in this repo?",
+      choices: [
+        { value: "internal", name: "Track work in this repo (TODO.md / PRDs)" },
+        { value: "external", name: "Track work in an external tracker (Azure DevOps / Jira / other)" }
+      ]
+    });
+    if (tracking_mode === "external") {
+      external_provider = await select2({
+        message: "Which external tracker?",
+        choices: [
+          { value: "ado", name: "Azure DevOps" },
+          { value: "jira", name: "Jira" },
+          { value: "other", name: "Other" }
+        ]
+      });
+    } else {
+      external_provider = null;
+    }
+  }
   const manifest = {
     version: packageVersion,
     profile,
     installedAt: (/* @__PURE__ */ new Date()).toISOString(),
     components: installedComponents,
-    ...role ? { role } : {}
+    ...role ? { role } : {},
+    ...tracking_mode ? { tracking_mode, external_provider } : {}
   };
   await writeManifest(targetDir, manifest);
   printSuccess(`Initialized with profile "${profile}" \u2014 ${fileCount} files installed`);
@@ -2150,7 +2199,7 @@ async function runAdd(name, options, targetDir, assetsDir, packageVersion) {
 import { join as join7 } from "path";
 
 // src/modules/hub.ts
-import { confirm as confirm2 } from "@inquirer/prompts";
+import { confirm as confirm2, select as select3 } from "@inquirer/prompts";
 import { readdir as readdir3, writeFile as writeFile5 } from "fs/promises";
 import { join as join6 } from "path";
 var MANIFEST_RETROFITS = [
@@ -2164,6 +2213,36 @@ var MANIFEST_RETROFITS = [
       });
       return { role: isHub ? "hub" : "consumer" };
     }
+  },
+  {
+    field: "tracking_mode",
+    needsRetrofit: (m) => m.tracking_mode === void 0,
+    // Mirrors init.ts's Step 5b branching exactly (EF-14 D5): docs-only
+    // profiles get a silent default, full/lite get asked.
+    ask: async (manifest) => {
+      if (manifest.profile === "governance-only" || manifest.profile === "methodology") {
+        return { tracking_mode: "internal", external_provider: null };
+      }
+      const tracking_mode = await select3({
+        message: "How will work be tracked in this repo?",
+        choices: [
+          { value: "internal", name: "Track work in this repo (TODO.md / PRDs)" },
+          { value: "external", name: "Track work in an external tracker (Azure DevOps / Jira / other)" }
+        ]
+      });
+      if (tracking_mode === "external") {
+        const external_provider = await select3({
+          message: "Which external tracker?",
+          choices: [
+            { value: "ado", name: "Azure DevOps" },
+            { value: "jira", name: "Jira" },
+            { value: "other", name: "Other" }
+          ]
+        });
+        return { tracking_mode, external_provider };
+      }
+      return { tracking_mode, external_provider: null };
+    }
   }
 ];
 async function runManifestRetrofits(manifest) {
@@ -2175,7 +2254,7 @@ async function runManifestRetrofits(manifest) {
   );
   let patch = {};
   for (const retrofit of applicable) {
-    const answer = await retrofit.ask();
+    const answer = await retrofit.ask({ ...manifest, ...patch });
     patch = { ...patch, ...answer };
   }
   return patch;