arcane-cli 1.6.0 → 1.8.0

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

@@ -36,7 +36,43 @@ Arcane separates framework-level decisions from org-specific ones using two pref
 - If the decision would apply to any organization using Arcane, it is `ARC-NNN`.
 - If the decision is specific to how your organization operates, it is `ADR-NNN`.
 - When uncertain, default to `ADR-NNN` in ops; promote to `ARC-NNN` later if the decision proves framework-generic. **Enforcement: explicitly advisory prose (ARC-023) — whether a decision is framework-generic enough for `ARC-NNN` (this rule and the two prefix-scoping rules above) is a judgment call; no script evaluates a decision's content to confirm the chosen prefix.**
-- Never renumber existing entries in either sequence. **Enforcement: explicitly advisory prose (ARC-023) — `scripts/check-distributed-adr-references.ts` only verifies that a bare `ADR-NNN` citation resolves to a heading declared in `framework-decisions.md` (and separately flags certain `ARC-NNN`/`EF-NNN` link forms as cross-repo hazards); it never checks that numbers are sequential, unique, or never reused.**
+- Never renumber existing entries in either sequence. **Enforcement: explicitly advisory prose (ARC-023) — `scripts/check-distributed-adr-references.ts` only verifies that a bare `ADR-NNN` citation resolves to a heading declared in `framework-decisions.md` (and separately flags certain `ARC-NNN`/`EF-NNN` link forms as cross-repo hazards); it never checks that numbers are sequential, unique, or never reused. Uniqueness alone has an executable check in Arcane's own repository only: `scripts/check-stale-claims.ts` (run in CI as `npm run check:stale-claims`) fails when two decision headings in its `DECISIONS.md` share an ID (ARC-050). That check does not ship to consuming repositories, and it cannot tell a renumbered entry from a new one.**
+
+## Allocating Decision Numbers
+
+Decision numbers are a shared sequence (ARC-028 R4). Two sessions on separate branches that each take
+"the next number" both take the same one. The collision surfaces at merge, or never, and
+cross-references then point at the wrong decision. ARC-050 sets how a number is allocated:
+
+1. **Fetch, then take the maximum.** Before allocating a decision number, fetch the trunk when a
+   usable remote exists. "Usable" is the classification `spell-open-session`'s Mutation Guard uses: a
+   supported provider with authenticated provider tooling, where a remote URL alone is not enough.
+   Then allocate `max(highest number on the local branch, highest number on the remote trunk) + 1`.
+2. **A local-only repository allocates from the local maximum and says so**, so the number is
+   visibly unchecked against any other branch.
+
+   **Enforcement (rules 1 and 2): structured spell gate (ARC-023) — `spell-close-session` step 3
+   requires the observed trunk maximum, or its stated local-only line, before it writes a new entry.
+   A decision written outside that spell, by hand or by another workflow, follows these rules as
+   explicitly advisory prose: nothing else fetches or compares for it.**
+3. **No reservation markers.** Never commit a placeholder or "reserved" entry to claim a number. A
+   marker is itself an edit to the same shared sequence, so it collides the same way. **Enforcement:
+   explicitly advisory prose (ARC-023) — no script recognizes a placeholder entry as a reservation.**
+4. **Several decisions at once are allocated once.** A program that drafts several decisions
+   allocates all of them at the start of the wave that needs them, from the fetched trunk. Its
+   parallel lanes use those numbers and never allocate their own. A single session that records
+   several decisions allocates them consecutively from one fetched maximum. **Enforcement:
+   explicitly advisory prose (ARC-023) — no spell gate or script tracks which numbers a program
+   pre-allocated.**
+5. **When a collision still happens, the unmerged branch renumbers.** Fetching narrows the race but
+   does not close it: two sessions can fetch before either pushes. "Never renumber existing entries"
+   applies to merged entries. When two branches hold the same number, the branch that has not merged
+   yet renumbers its own entry and every reference to it on that branch. **Enforcement: explicitly
+   advisory prose (ARC-023) for the renumbering — no script performs it or checks which branch did
+   it. Detecting the collision is an executable check in Arcane's own repository only:
+   `scripts/check-stale-claims.ts`, run in CI as `npm run check:stale-claims`, fails when two
+   decision headings share an ID. It matches any `## <PREFIX>-<number>` heading, not only `ARC`, so
+   a consuming repository can adopt it, but it is not installed there.**
 
 ## Problem Statement
 

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

@@ -161,6 +161,26 @@ GitHub Issues has no configurable work-item-type hierarchy the way Azure DevOps
 - **Jira (`external_provider=jira`)** — TODO: define issue-type mapping, parent-child/epic linkage strategy, and command examples.
 - **Other providers (`external_provider=other`)** — TODO: define required metadata contract and fallback behavior before enabling automation.
 
+### Tracker-ID Suffix on Captured Items
+
+When `tracking_mode=external` and a `TODO.md` item or an `IDEAS.md` entry corresponds to a tracker work item that already exists, the item carries that work item's id as a suffix, in the provider's own reference format. This is the one definition of the suffix; `spell-todo`, `spell-save-idea` and `spell-manifest` point here rather than restating it.
+
+| `external_provider` | Suffix | Example |
+| --- | --- | --- |
+| `github` | `[#<number>]` | `- [ ] Add export button [#123]` |
+| `ado` | `[AB#<id>]` | `- [ ] Add export button [AB#123]` |
+| `jira` | `[<issue key>]` — the key exactly as Jira prints it | `- [ ] Add export button [PROJ-123]` |
+| `other` | no suffix until that provider's metadata contract is defined (see External Provider TODOs) | — |
+
+- **Placement:** at the end of the item's text, after any file reference, and before a trailing `<!-- status: … -->` comment on an idea entry.
+- **Only a real id:** the suffix records an id that exists — one the operator supplied, or one a spell just got back from the tracker. Never guess an id, and never file a work item just to have a suffix.
+- **One suffix per item:** an item that already carries a suffix keeps it; it is not duplicated or rewritten.
+- **`tracking_mode=internal`:** no suffix. Items are written exactly as they are without this section.
+
+The suffix uses the same reference forms as the commit-link syntax `spell-bug` writes (`Fixes AB#{id}` for Azure DevOps, `Fixes #{id}` for GitHub Issues — the GitHub form is also under GitHub Issues Conventions above), so an item and the commit that closes it point at the work item the same way.
+
+**Enforcement: explicitly advisory prose (ARC-023) — no script checks that an externally tracked item carries its suffix or that a suffix matches the provider's format; the three spells apply it at write time and compliance depends on the executing agent.**
+
 ### Fresh Context Per Iteration
 
 Each implementation iteration starts with clean context. The only memory between iterations is:

package/dist/assets/.arcane/governance/spell-authoring-standards.md

@@ -213,6 +213,38 @@ Arcane's own repository, a test (`test/up02-d-runtime-placeholders.test.ts`) fai
 `status: active` governance document uses a token that is not in this list. Whether an agent actually
 resolves a listed token from the named source is explicitly advisory prose: no check exercises it.**
 
+## Required operator actions: the `Needs you` block
+
+Some runs end with an action only the operator can take: approving or merging a pull request,
+accepting a decision record, answering a question the work is waiting on, confirming a `guarded`
+push, running an interactive command such as `spell unblock-push`, or a step on an external platform
+the agent cannot reach. Listed among optional next steps, such an action gets skimmed past. A spell
+whose output can carry one reports it in one fixed block instead:
+
+- **One fixed heading,** `## ⚠ Needs you`, at the very top of the final report, before every other
+  section and before any optional next step.
+- **One line per action:** exactly what to do, then why the agent cannot do it itself.
+- **Never only among optional steps:** an action required for correctness may be repeated under next
+  steps or suggestions, but it always appears in the block.
+- **Omitted when empty:** when nothing needs the operator, the block is left out entirely, never
+  printed as an empty heading or a "None" line.
+
+The block's wording lives in one shared prose fragment (ARC-039), `needs-you`, kept in Arcane's
+source under `.arcane/spells/_fragments/` and never shipped on its own. A spell carries it as a
+`<!-- fragment:needs-you:start -->` / `<!-- fragment:needs-you:end -->` marker pair placed where the
+spell describes its final output or report, and `npm run fix:self-host-parity` expands the fragment
+between the markers. Edit the fragment, never an expanded copy, and never restate its rules by hand
+in a spell body. Required actions also survive the end of a session: `spell-close-session` writes
+the open items into the handoff's `Needs you` field, and `spell-open-session` surfaces that field
+first, above the rest of the handoff, and does not mark the handoff consumed until it has.
+
+**Enforcement: executable check (ARC-023) for the wording — in Arcane's own repository,
+`npm run check:self-host-parity` fails CI when a spell's expanded span differs from the fragment, and
+a test (`test/up04-b-needs-you.test.ts`) fails when the fragment loses its heading, placement or
+omit-when-empty rule, or when a spell in the chosen set loses its span. Which spells carry the span
+is decided by an author's judgment, and whether an agent actually emits the block is explicitly
+advisory prose: no check reads a spell's output.**
+
 ## How to audit a spell
 
 For each dimension, score Bronze/Silver/Gold with one line of evidence. Record the overall (weakest)

package/dist/assets/.arcane/spells/_fragments/needs-you.md

@@ -0,0 +1,14 @@
+**Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+```markdown
+## ⚠ Needs you
+
+- <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+```
+
+- **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+- **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+- **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+- **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+- **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+- Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.

package/dist/assets/.arcane/spells/spell-address-review.md

@@ -114,6 +114,24 @@ Resolve threads via the provider:
 
 3. `git push` all commits.
 4. Print a summary table of actions taken (category, file, action, commit), thread status (resolved / deferred-with-TODO / needs manual resolution), commits pushed, and next steps (CI, notify reviewer, ready for re-review).
+
+   <!-- fragment:needs-you:start -->
+   **Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+   ```markdown
+   ## ⚠ Needs you
+
+   - <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+   ```
+
+   - **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+   - **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+   - **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+   - **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+   - **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+   - Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.
+   <!-- fragment:needs-you:end -->
+
 5. Optionally post the summary back to the PR as a top-level comment for a durable record.
 
 ## Rules

package/dist/assets/.arcane/spells/spell-adopt-docs.md

@@ -134,6 +134,23 @@ Hard rules for this phase:
 
 ## Phase 4 — Report
 
+<!-- fragment:needs-you:start -->
+**Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+```markdown
+## ⚠ Needs you
+
+- <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+```
+
+- **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+- **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+- **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+- **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+- **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+- Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.
+<!-- fragment:needs-you:end -->
+
 Output:
 
 ```

package/dist/assets/.arcane/spells/spell-arcane-version.md

@@ -70,6 +70,32 @@ If the npm registry is unreachable, report:
 ℹ Could not reach npm registry — update check skipped.
 ```
 
+### Setup questions from an AI harness (no interactive terminal, PRD D-02 / #282)
+
+This spell itself stays read-only. If the operator then asks you to run `spell update`, note that a
+harness shell is not an interactive terminal. The CLI then skips every unanswered manifest question
+and prints ``! Skipped N manifest question(s) (<fields>) — no interactive terminal. Run `spell update` from a terminal, or answer by flags:``,
+followed by the exact line to re-run, such as
+`spell update --tracking-mode <internal|external> --push-policy <open|guarded|blocked>`.
+`spell init --profile <profile>` prints the same kind of `spell update` line when it leaves
+questions unanswered. Do not send the operator off to find a terminal. Instead:
+
+1. Ask the operator each skipped question through the harness's own question UI (a plain chat
+   question if the harness has none): one question per flag the CLI printed, offering exactly the
+   values that flag lists. The flags are `--role`, `--tracking-mode`, `--external-provider`,
+   `--content-sensitivity`, `--push-policy` and `--subject-root`. `--tracking-mode external` also
+   needs `--external-provider <ado|github|jira|other>`, so ask that too when the answer is
+   `external`.
+2. Re-run `spell update` with the flags the CLI printed, filled with the operator's answers, for
+   example `spell update --tracking-mode internal --push-policy guarded`.
+3. Never pass a flag the operator did not answer. No guessed, default or "recommended" value stands
+   in for an answer. An unanswered question stays unset: the next interactive run asks it, and the
+   next harness run reports it skipped again.
+4. Never loosen `push_policy` by flag. `--push-policy` only answers an unset question or tightens a
+   recorded policy, and the CLI refuses a loosening. Moving a repository from `blocked` or `guarded`
+   toward `open` is only ever `spell unblock-push`, which the operator runs from an interactive
+   terminal (ARC-034 decision 6, ARC-049 decision 6). Tell them so; do not try to run it for them.
+
 ## Step 3 — Component Detail (optional)
 
 Only include this section when the user passed "components" as the prompt argument.

package/dist/assets/.arcane/spells/spell-architect.md

@@ -110,6 +110,23 @@ Workflow:
 
 8. **Present for review** — show the architecture and story breakdown to the user.
 
+   <!-- fragment:needs-you:start -->
+   **Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+   ```markdown
+   ## ⚠ Needs you
+
+   - <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+   ```
+
+   - **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+   - **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+   - **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+   - **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+   - **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+   - Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.
+   <!-- fragment:needs-you:end -->
+
 Rules:
 - Stories must be right-sized per the methodology doc (not "build the entire dashboard").
 - Architecture decisions must reference existing ADRs when relevant.

package/dist/assets/.arcane/spells/spell-close-session.md

@@ -53,13 +53,39 @@ Workflow:
    - Journal entries must include:
      - `### Prompt Context` — original prompt text or a faithful paraphrase of the multi-turn request when the session began from a substantive user ask. Include follow-up scope inputs if they materially changed the direction of the work.
      - `### What Got Done` — numbered list of concrete outcomes with file/ADR references. Only list an outcome here if step 1b classified it `succeeded` (or it never involved async work at all, e.g. a local file edit). A `pending`/`dispatched`/`unverifiable` item belongs in Open Items Carried Forward, not here — do not let this section imply completion step 1b couldn't confirm.
-     - `### Decisions Made` — table of ADR number, decision, and rationale. If no decisions were made, omit this section.
+     - `### Decisions Made` — table of ADR number, decision, and rationale. If no decisions were made, omit this section. Take every number in this table from step 3's allocation rule (ARC-050). If step 3 has not allocated yet, run that allocation now and use the same numbers in both places. Never write a number from memory or from this branch's `DECISIONS.md` alone.
      - `### Lessons Learned` — one heading per lesson with enough context to prevent the mistake again. Use narrative, not bullet fragments.
      - `### Open Items Carried Forward` — items that remain undone from this session, including every `pending`/`dispatched`/`failed`/`unverifiable` item from step 1b.
 
+2b. **Lesson routing: send each lesson where it can be acted on.** A lesson left only in the journal never reaches the people who could fix its cause. Skip this step when step 2 wrote no `### Lessons Learned`, or when the invocation includes `--no-route`. With `--no-route`, the lessons stay in the journal only; say `Lesson routing skipped (--no-route)` in the closure report.
+   - **Classify each lesson** written in step 2 into exactly one class:
+     - **Framework-shaped:** the fix belongs in Arcane itself, meaning a spell prompt, template, governance doc, playbook, or CLI behavior this repository installed rather than authored. This is `spell-feedback` Step 3's definition. Destination: `FEEDBACK.md`, queued for upstream.
+     - **Product idea:** the lesson suggests something to build in this repository's own product. Destination: `spell-save-idea`.
+     - **Repo-local:** anything about this repository's own content, configuration, or way of working. Destination: the journal only. It is already there, so nothing more is written.
+   - **Show one batch proposal and ask once.** List every lesson with its class and destination, then ask a single question: `Route these lessons? (yes / edit / skip)`. `edit` lets the operator change a class or drop a lesson, then shows the proposal again. Route nothing before an explicit `yes`. A timeout, a cancellation, a delegated or host-generated response, or assent given to something else is not approval. Neither is an autonomous run with no operator to ask. In each of those cases route nothing, keep the lessons in the journal, and list the proposal in the closure report as not routed. `skip` is a complete, valid answer.
+   - **Framework-shaped, after `yes`:** append **one** block to `FEEDBACK.md` at the repository root, in `spell-feedback`'s Step 5 block format. Create the file with a `# Feedback Log` header first if it is missing. Fill the block this way:
+     - Heading: `## Feedback — <the spell or doc the lessons concern, or "Arcane workflow" when they span several> (<YYYY-MM-DD>)`.
+     - `**Session:**` names this session and adds `(routed by spell-close-session from Lessons Learned)`.
+     - `**Rating:**` and `**Would use again:**` are `N/A`, because nobody rated anything.
+     - Friction Points: one line per lesson saying what happened.
+     - Improvement Items: one imperative item per lesson, each line ending with `<!-- upstream: queued -->`.
+     - Raw Notes: cite the journal file and each lesson's heading.
+   - **Product idea, after `yes`:** hand each one to `spell-save-idea` as a one-sentence idea, citing the journal file. That spell appends it to the idea book.
+   - **No public write from this step.** Close-session never files an issue and never runs `gh issue create`. It also never runs `spell-feedback`'s Step 6 filing flow. Queuing is the whole outcome here. The `yes` above approves local appends only. Filing upstream still needs `spell-feedback`'s own literal `disclose` confirmation on each item, given in a later `spell-feedback` or `spell-feedback --flush` run, which re-offers every queued item through its genericize-and-`disclose` flow.
+   - **Append-only.** Add new entries to `FEEDBACK.md` and the idea book. Never edit, reorder, or remove an existing entry in either.
+   - Enforcement: structured spell gate (ARC-023) — nothing is routed without the one explicit batch `yes`, and it fails closed. The no-public-write and append-only rules are explicitly advisory prose: no hook stops this step from running `gh` or rewriting a book, so they hold by the step's own instructions. Classifying a lesson is a judgment call, and the operator checks it at the batch proposal.
+
 3. **Update [DECISIONS.md](../../DECISIONS.md).**
    - Add ADRs for any decisions made during the session (naming choices, tool preferences, workflow standards, security policies, etc.).
    - Use the next sequential ADR number.
+   - **Allocate that number against the trunk, not only this branch (ARC-050; ARC-028 R4 names decision numbers a shared sequence).** Another session on another branch may already have taken "the next number". Do this immediately before writing the first new entry:
+     - **Classify the remote first.** Use the classification from step 9's remote-capability check, which is the same one `spell-open-session`'s Mutation Guard uses. A usable remote is a supported provider (`github.com`, `dev.azure.com`, or `visualstudio.com`) with authenticated provider tooling; a remote URL alone is not enough. Resolve `<remote>` and `<trunk>` from observed state as step 10 does. Never assume `origin` or `main`.
+     - **Usable remote: fetch, then take the maximum.** Run `git fetch <remote> <trunk>`. Read the highest decision ID (the number in the log's `## <PREFIX>-NNN` headings) from this branch's `DECISIONS.md`, and from the trunk's copy with `git show <remote>/<trunk>:DECISIONS.md`. A trunk with no `DECISIONS.md` has no maximum. Allocate `max(highest ID on this branch, highest ID on <remote>/<trunk>) + 1`. In the Decision Updates output, name both maxima and the number allocated.
+     - **Local-only: allocate from the local maximum and say so.** When there is no usable remote, allocate `highest ID in the local DECISIONS.md + 1`. Say so in the Decision Updates output: `Allocated <PREFIX>-NNN from the local maximum only; not checked against any other branch.` Treat a usable remote whose fetch fails the same way, and name the failed fetch in that line.
+     - **Several decisions in one session:** allocate them consecutively from the one maximum you just computed, in a single pass.
+     - **No reservation markers.** Never commit a placeholder or "reserved" entry to claim a number before the real entry exists. A marker is itself an edit to the same shared sequence, so it collides the same way.
+     - **If a collision still surfaces later** (two sessions fetched before either pushed), the branch that has not merged yet renumbers its own entry and every reference to it on that branch. Merged entries are never renumbered (`decision-documentation-standard.md`).
+     - Enforcement: structured spell gate (ARC-023) — this step requires the observed trunk maximum, or the stated local-only line, before a new entry is written. The renumbering rule above is explicitly advisory prose: nothing in this spell detects a collision after the fact.
    - Follow the existing format: Date, Status, Context, Decision, Reasoning, Rejected alternatives.
 
 4. **Update [TODO.md](../../TODO.md).**
@@ -94,6 +120,7 @@ In `ai-context/system-prompt-context.md`, replace the existing `## Next Session
 - **Branch:** Output of `git branch --show-current`.
 - **Blockers:** Known unresolved blockers or dependencies. Write "None" if clear.
 - **Pending Verification:** One line per non-`succeeded` item from step 1b: `<what> — <state> — <verification action>`. States: `dispatched`, `pending`, `failed`, `unverifiable` (never list a `succeeded` item here — it belongs in `Last completed step` / TODO.md / the journal instead, worded per the gating above). The verification action is required for `dispatched`, `pending`, and `unverifiable` — "N/A" is only valid for `failed`, where the state is already resolved and there is nothing left to check. Write "None" only if step 1b found every dispatched item resolved to `succeeded` or `failed` before this handoff was written.
+- **Needs you:** One line per action only the operator can take that this session leaves open: `<what to do> — <why the agent cannot do it>`. This block is committed before steps 9–10 run, so write it with them in view and name now the actions they will leave open: the pull request step 9c opens needs a human merge, and when `push_policy` (read it now, per step 9c's push-policy check) is `blocked`, or `guarded` in an autonomous run, the push itself waits on the operator. The closure report's `## ⚠ Needs you` block (step 11) lists the same items, plus any that arose after this handoff was committed. Write "None" when nothing needs the operator. Never leave such an action only in `Blockers`, `Notes` or `Carry Forward`; it may be repeated there, but it always appears here.
 - **Notes:** Anything time-sensitive, fragile, or contextual that would be lost if not stated explicitly. Never the sole carrier of durable content (session handoff durability) — if it names unfinished work, that work must also be registered per step 4b; name its location here.
 ```
 
@@ -149,7 +176,7 @@ Rules:
    - Timeout, cancellation, fallback, or delegated response is not approval. Print the visible authorization downgrade and halt without committing.
 
    c. **Push and open a PR through `spell-commit-work` step 9, including its separate merge gate:**
-   - Run the push-policy check before the push. `spell-commit-work` step 9a runs the same check; run it once per push, not twice. It also governs step 10's remote branch deletions. If it stops the push, end the session with the commits local and report them in the PR Readiness section as not pushed.
+   - Run the push-policy check before the push. `spell-commit-work` step 9a runs the same check; run it once per push, not twice. It also governs step 10's remote branch deletions. If it stops the push, end the session with the commits local and report them in the PR Readiness section as not pushed, and in the step 11 report's `## ⚠ Needs you` block.
 
      <!-- fragment:push-policy-check:start -->
      **Push-policy check (ARC-049) — before any push.** Read `push_policy` from the repository's `.arcane.json` at the repository root (a self-hosted source repository with no root manifest keeps it in `src/assets/.arcane.json` when that file declares `selfHosted: true`). An absent file or an absent field means `open`. The check covers every push this spell makes: a branch push, a `--force-with-lease` push, and a remote branch deletion (`git push <remote> --delete <branch>`).
@@ -199,6 +226,23 @@ Rules:
 
 Output format:
 
+<!-- fragment:needs-you:start -->
+**Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+```markdown
+## ⚠ Needs you
+
+- <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+```
+
+- **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+- **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+- **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+- **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+- **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+- Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.
+<!-- fragment:needs-you:end -->
+
 ## Session Closure
 
 - Summary of what was completed.
@@ -224,9 +268,15 @@ Output format:
 
 - Exact file updates made.
 
+## Lesson Routing
+
+- Each lesson from step 2b with its class and where it went: `FEEDBACK.md` (queued for upstream), `spell-save-idea`, or journal only.
+- Or one of: `Lesson routing skipped (--no-route)`, `No lessons recorded`, or `Not routed (no explicit yes)` followed by the proposal.
+
 ## Decision Updates
 
 - ADRs added or note that none were needed.
+- For each ADR added, how its number was allocated (step 3): `max(<this branch's highest>, <remote>/<trunk>'s highest) + 1`, or the local-only line.
 
 ## TODO Updates
 

package/dist/assets/.arcane/spells/spell-commit-work.md

@@ -256,6 +256,23 @@ Workflow:
 
 Output format after execution:
 
+<!-- fragment:needs-you:start -->
+**Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+```markdown
+## ⚠ Needs you
+
+- <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+```
+
+- **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+- **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+- **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+- **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+- **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+- Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.
+<!-- fragment:needs-you:end -->
+
 ## Commit Complete
 
 ```

package/dist/assets/.arcane/spells/spell-create-pull-request.md

@@ -200,6 +200,23 @@ so they need no edit.
 
 ## Step 6 — Report
 
+<!-- fragment:needs-you:start -->
+**Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+```markdown
+## ⚠ Needs you
+
+- <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+```
+
+- **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+- **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+- **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+- **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+- **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+- Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.
+<!-- fragment:needs-you:end -->
+
 ```
 ✓ PR created: <URL>
   Title:     <title>

package/dist/assets/.arcane/spells/spell-eas-store-deploy.md

@@ -234,6 +234,29 @@ console error stating otherwise (`EV-06`).
 - **Locale lists differ between the stores.** Release notes are per-language; resolve locale coverage
   against each store's own catalogue rather than copying the other store's list (`MR-06`).
 
+### Reporting the release
+
+End every release run with a short report. The store-console steps the agent cannot reach — sending
+staged Google Play changes for review, answering an App Store review question, confirming a manual
+release — are required operator actions:
+
+<!-- fragment:needs-you:start -->
+**Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+```markdown
+## ⚠ Needs you
+
+- <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+```
+
+- **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+- **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+- **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+- **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+- **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+- Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.
+<!-- fragment:needs-you:end -->
+
 ---
 
 ## Rules

package/dist/assets/.arcane/spells/spell-feedback.md

@@ -127,6 +127,15 @@ For each framework-shaped item:
 
 Maintainer side is unchanged: GitHub issues are arcane's normal public intake; triage into arcane's own `IDEAS.md`/`DECISIONS.md` happens in arcane sessions like any other issue. This spell never writes to a hub's venture books and never reads `ventures/registry.json` — framework feedback and venture ideas are different channels on purpose (venture ideas → hub books → `spell-manifest`; framework lessons → here → arcane's GitHub).
 
+## Entry Point — Lessons Routed by `spell-close-session`
+
+`FEEDBACK.md` has a second writer. `spell-close-session`'s lesson-routing step (step 2b) classifies each of the session's Lessons Learned. After one batch confirmation, it appends the framework-shaped ones as a single block in Step 5's format:
+- `**Session:**` carries `(routed by spell-close-session from Lessons Learned)`.
+- `**Rating:**` and `**Would use again:**` are `N/A`.
+- Each improvement item ends with `<!-- upstream: queued -->`.
+
+That step never files anything publicly. Its entries reach `{ARCANE_UPSTREAM_REPO}` only through this spell: `spell-feedback --flush` picks them up with every other queued item and runs Step 6 on each one (genericize, the literal `disclose` confirmation, then file or re-queue). A routed entry gets no shortcut, because close-session's batch confirmation approved a local append, not a public issue. An `N/A` rating is not a low rating, so it never triggers the `⚠️ LOW RATING` flag. **Enforcement: structured spell gate (ARC-023) — Step 6's literal `disclose` confirmation gates filing a routed item exactly as it gates any other; nothing in this spell distinguishes a routed item that could skip it.**
+
 ## Rules
 
 - Never overwrite existing feedback — always append.

package/dist/assets/.arcane/spells/spell-full-cycle.md

@@ -184,6 +184,24 @@ Execute the `spell-ship` workflow:
    applies (state "Nothing withheld" in that case). Fold it into the consumer repo's own QA checklist
    so a human reviewer sees exactly what still needs a human look, not just what passed (2026-07-22
    dogfooding finding: honest disclosure of sandbox limits, not just of failures).
+
+   <!-- fragment:needs-you:start -->
+   **Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+   ```markdown
+   ## ⚠ Needs you
+
+   - <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+   ```
+
+   - **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+   - **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+   - **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+   - **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+   - **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+   - Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.
+   <!-- fragment:needs-you:end -->
+
 4. Create the PR:
    - `external/ado` mode: `az repos pr create --repository {repo} --source-branch {branch} --target-branch main --title "{feature}" --work-items {adoWorkItemId}`
    - `internal` mode (or provider TODO mode): create PR without `--work-items`.

package/dist/assets/.arcane/spells/spell-make-discoverable.md

@@ -250,6 +250,23 @@ just because nothing threw an error.
 
 ## Phase 6 — Report
 
+<!-- fragment:needs-you:start -->
+**Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+```markdown
+## ⚠ Needs you
+
+- <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+```
+
+- **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+- **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+- **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+- **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+- **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+- Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.
+<!-- fragment:needs-you:end -->
+
 Summarize what changed, what's still open, and close with a plain-language,
 user-verifiable acceptance checklist:
 

package/dist/assets/.arcane/spells/spell-manifest.md

@@ -30,6 +30,18 @@ Parse `status: new` entries from the hub root `IDEAS.md` and every `{BUSINESS_RO
 
 Tolerate operator YAML frontmatter above a book's header — entries always live below the `---` divider. Malformed entries (missing timestamp, unparseable status comment) are listed under a `Skipped` heading with `file:line`, never silently dropped.
 
+**Status-comment grammar.** A status comment is `<!-- status: <state>[; <key>: <value>]... -->`. The first field is the status itself, unchanged from before: `new`, `promoted → <dest> YYYY-MM-DD`, or `dropped YYYY-MM-DD` with an optional `(reason)`. Zero or more `; <key>: <value>` fields may follow it. `spell-todo --sweep --validate` writes three of them: `value` and `fit` (each `y`, `n` or `?`) and `dup` (`none`, or a short reference). Both forms parse:
+
+```
+<!-- status: new -->
+<!-- status: new; value: y; fit: y; dup: none -->
+```
+
+- **Splitting:** split the comment body on `; ` only where the next segment starts with a lowercase `key: `. A `; ` anywhere else — inside a drop reason, say — stays part of the field it is in.
+- **Deciding `new`:** only the first field does. An entry is collected when that field is exactly `status: new`, with or without fields after it.
+- **Unknown fields:** an unknown key, or a known key with an unexpected value, is ignored and shown as-is. It never moves the entry to `Skipped`.
+- **Unparseable:** a comment is unparseable, and the entry goes to `Skipped`, when it does not open with `status:`, is not closed with `-->`, or its first field is not exactly `new`, `promoted …` or `dropped …` (a typo such as `status: nwe` or `status: New` is reported, never silently left out of both lists).
+
 ## Step 2 — List
 
 Print one numbered list, grouped by book, oldest entry first within each group. Numbering is session-scoped — it does not persist across runs.
@@ -45,6 +57,8 @@ ventures/ordovica/TODO.md
   3. [ ] Confirm cart snapshot order (open item, no status comment — todo-book entries are listed as-is)
 ```
 
+An entry whose status comment carries validation fields (Step 1's grammar) shows them after its text — for example `(value: y, fit: n, dup: none)` — so that the operator can leave out `fit: n` entries, or ones marked as duplicates, when selecting in Step 3. An entry without them is listed exactly as before.
+
 ## Step 3 — Select
 
 Ask: `Promote which? (numbers/ranges, e.g. 1,3,5-8, or "all")`. Accept a single answer covering the whole batch. `all` selects every listed entry, including ones in books outside `--venture` if no filter was given.
@@ -114,8 +128,12 @@ book:<other-slug>/IDEAS.md
 
 Any marker whose destination repository is public ends in ` (disclosed)` — whichever route landed it, because Step 5 gated it as a disclosure.
 
+**Tracker-id suffix.** When route (c) files a tracker item, append the new work item's id to the hub entry's text as a suffix — before its status comment — in the format [governance/development-methodology.md](../../.arcane/governance/development-methodology.md) defines once under "Tracker-ID Suffix on Captured Items" for that tracker's provider (`[AB#<id>]` Azure DevOps, `[#<id>]` GitHub, the issue key for Jira). Use only the id the create command returned. The promoted marker still names the repo (`github:<slug>#<id>`), which is what disambiguates a GitHub suffix inside a hub book. An entry that already carries a suffix keeps it unchanged wherever it lands. No tracker item filed means no suffix: entries routed without a tracker (and every internal-mode flow) are written exactly as before.
+
 Dropped entries get `<!-- status: dropped YYYY-MM-DD -->`, optionally with a trailing `(reason)`.
 
+Validation fields already in an entry's comment (Step 1's grammar) are kept after the new first field when it is marked, e.g. `<!-- status: dropped 2026-09-27; value: n; fit: y; dup: none -->`. An entry without them gets exactly the marker above.
+
 Before any downstream write, grep the target file for the entry's normalized first ~40 characters — if already present, treat this entry as already-landed, mark the hub entry promoted, and skip the write. This is what makes an interrupted or re-run batch safe.
 
 ## Step 7 — Leak Scan

package/dist/assets/.arcane/spells/spell-open-session.md

@@ -36,6 +36,7 @@ Use these files first:
 Check `ai-context/system-prompt-context.md` for a `## Next Session Handoff` section.
 
 - If present and **not yet marked consumed** (no `> ✓ Consumed:` line): surface it immediately as `## Picking Up From Last Session` at the very top of your output, before all other sections — include `Last completed step`, `Blockers`, and `Notes` verbatim alongside the rest (session handoff durability: these three are written by close-session but were previously never read back). Use the `Next concrete action` field as the first item in `## Next Session Plan`. Use the `Active task`, `Active files`, and `Branch` fields to pre-populate the State Snapshot.
+- **The handoff's `Needs you` field comes first.** If it lists anything other than "None", surface every item in the `## ⚠ Needs you` block (see the output structure below) **above** `## Picking Up From Last Session`, the one exception to "before all other sections" in the bullet above. Where you can check an item (a pull request's merge state, whether a branch was pushed), check it: an item the operator has already done leaves the block and is noted as done under `## Picking Up From Last Session` (that counts as surfaced); keep every item you cannot check. A handoff written before this field existed has no `Needs you` line; treat it as "None". Do not mark the handoff consumed until every listed item has been surfaced: a handoff whose `Needs you` items were not surfaced stays unconsumed, so the next open-session surfaces them again.
 - **If the handoff's `Pending Verification` field lists anything other than "None" (EF-21):** surface each listed item explicitly, then actively re-check its current status (per the item's stated verification action) rather than treating the state recorded at close-session time as still current — a `dispatched`/`pending` item may have since succeeded, failed, or still be running, and carrying it forward as inert text would repeat the exact failure mode this field exists to prevent. Report what you found (resolved succeeded / resolved failed / still pending / still unverifiable) before relying on anything downstream that depended on it.
 - After surfacing it, apply the Mutation Guard below, then run the **Durability check** (session handoff durability, ARC-040): confirm that an incomplete `Active task`, the `Next concrete action`, and any task-bearing `Notes` content each name a durable location that genuinely exists (the cited `TODO.md` item — by stable locator, not a line number that may have already drifted — or tracker work item). If a named location is missing, or close-session's own step 4b was skipped when it shouldn't have been, register the missing content now — on this session's own branch — before proceeding. Only then append `> ✓ Consumed: YYYY-MM-DD` (today's date); the marker write is a repository mutation. If the Durability check cannot complete, leave the handoff unconsumed so the next open-session retries the same check idempotently, rather than silently losing the gap.
 - If the section is absent or already marked consumed: skip this step and proceed with the normal workspace scan.
@@ -67,6 +68,23 @@ Run the `spell-check-drift` spell first, before building the state snapshot or g
 
 Then produce output in this exact structure:
 
+<!-- fragment:needs-you:start -->
+**Needs you — required operator actions.** When this run leaves an action that only the operator can take, and the work is not correct or complete until it is taken, report it in one block at the very top of the final report, before every other section and before any optional next step:
+
+```markdown
+## ⚠ Needs you
+
+- <exactly what to do: the command, the link, or the question> — <why the agent cannot do it itself>
+```
+
+- **What belongs in it:** an action the work needs that only the operator can take — approving or merging a pull request, accepting a decision record, answering a question the work is waiting on, confirming a `guarded` push, running an interactive command such as `spell unblock-push`, or a step on an external platform the agent cannot reach. An optional suggestion, a next spell to run, or anything the agent could do itself is not a required action and stays out of the block.
+- **One line per action.** Say exactly what to do, then, after the dash, why the agent cannot do it. Write the command, link or question out in full; never point elsewhere with "see above".
+- **Never only among optional steps.** An action required for correctness is never listed only under next steps, suggestions, `Carry Forward` or `What's Next?`. It may be repeated there, but it always appears in this block.
+- **Omit it when empty.** When nothing needs the operator, leave the block out entirely: no heading and no "None" line.
+- **Every final report.** The block belongs in whatever report ends the run, including a report written when the spell stops early.
+- Enforcement: explicitly advisory prose (ARC-023) — no check reads a spell's actual output for this block; it holds by these instructions alone.
+<!-- fragment:needs-you:end -->
+
 ## Workspace Health Check
 
 Before anything else, check:
@@ -99,6 +117,11 @@ Before anything else, check:
   - Run `npm view arcane-cli version` to get the latest published version.
   - **(a) Managed files behind the installed CLI** (installed CLI version is newer than the version recorded in `.arcane.json`): surface a warning: `⚠️ Managed files out of date: files at <installed> → CLI at <cli>. Run spell update to resync files.`
   - **(b) Installed CLI behind the latest published version** (latest published is newer than the installed CLI): surface a warning: `⚠️ Arcane CLI update available: CLI at <cli> → latest <latest>. Upgrade the CLI, then run spell update.`
+  - **Setup questions from an AI harness (no interactive terminal, PRD D-02 / #282):** if you run `spell update` yourself — a repository write, so apply the Mutation Guard first — note that a harness shell is not an interactive terminal. The CLI then skips every unanswered manifest question and prints ``! Skipped N manifest question(s) (<fields>) — no interactive terminal. Run `spell update` from a terminal, or answer by flags:``, followed by the exact line to re-run, such as `spell update --tracking-mode <internal|external> --push-policy <open|guarded|blocked>`. `spell init --profile <profile>` prints the same kind of `spell update` line when it leaves questions unanswered. Do not send the operator off to find a terminal. Instead:
+    1. Ask the operator each skipped question through the harness's own question UI (a plain chat question if the harness has none): one question per flag the CLI printed, offering exactly the values that flag lists. The flags are `--role`, `--tracking-mode`, `--external-provider`, `--content-sensitivity`, `--push-policy` and `--subject-root`. `--tracking-mode external` also needs `--external-provider <ado|github|jira|other>`, so ask that too when the answer is `external`.
+    2. Re-run `spell update` with the flags the CLI printed, filled with the operator's answers, for example `spell update --tracking-mode internal --push-policy guarded`.
+    3. Never pass a flag the operator did not answer. No guessed, default or "recommended" value stands in for an answer. An unanswered question stays unset: the next interactive run asks it, and the next harness run reports it skipped again.
+    4. Never loosen `push_policy` by flag. `--push-policy` only answers an unset question or tightens a recorded policy, and the CLI refuses a loosening. Moving a repository from `blocked` or `guarded` toward `open` is only ever `spell unblock-push`, which the operator runs from an interactive terminal (ARC-034 decision 6, ARC-049 decision 6). Tell them so; do not try to run it for them.
   - **If either axis shows drift, emit the canonical version-drift diagram beside the warning(s)** — per the generated state diagrams convention (rule 8, ARC-036). One commit per *distinct* version value among the three readings, in the order repo-files → installed-CLI → npm-latest; collapse consecutive identical values into a single shared commit rather than repeating it. Branch off immediately after the commit for each axis that drifts — `repo-files` after the repo-files-version commit if axis A drifts, `installed-cli` after the installed-CLI-version commit if axis B drifts. Tag the final commit `"latest"`. The dangling branch(es) *are* the drifting axis/axes — no legend needed:
     ```mermaid
     gitGraph