arcane-cli 0.22.9 → 0.22.10

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

@@ -183,6 +183,23 @@ Output format:
 ## Session Closure
 
 - Summary of what was completed.
+- **Session commit graph** — per the generated state diagrams convention (rule 8, ARC-036), built only
+  from commits this session actually made (`git log <trunk>..HEAD --format="%h %s" --reverse`, or
+  `<remote>/<trunk>..HEAD` once pushed) plus step 1b's succeeded/pending/failed classification per
+  commit. Skip entirely (the applicability guard) for a read-only session or a single-commit session —
+  one point has nothing to sequence. Deliberately `gitGraph`, the same already-verified diagram type
+  R1–R9 use, not Mermaid's `timeline` diagram — that type is marked experimental in Mermaid's own docs,
+  a real compatibility risk across GitHub/VS Code/Obsidian this convention explicitly commits to
+  supporting; a session's own commit sequence is exactly what `gitGraph` already represents:
+
+  ```mermaid
+  gitGraph
+     commit id: "<short-sha 1> succeeded"
+     commit id: "<short-sha 2> pending"
+  ```
+
+  One commit per session commit, in order, `id` carrying its short SHA and step 1b's classification —
+  never claim `succeeded` for anything step 1b did not confirm as such.
 
 ## Journal Updates
 

package/dist/assets/.github/prompts/spell-full-cycle.prompt.md

@@ -196,6 +196,28 @@ After each phase completes, output a brief status line:
 [Phase 6/6 — Ship] AWAITING APPROVAL — PR #77 created, ship report below
 ```
 
+**Pipeline state diagram** — per the generated state diagrams convention (rule 8, ARC-036), built only
+from the phase status this section already tracks; skip entirely (the applicability guard) after Phase
+1 alone, before any other phase has run — a single-state pipeline has nothing to show in relation to
+the rest. From Phase 2 onward, alongside the status line above:
+
+```mermaid
+stateDiagram-v2
+   [*] --> Plan
+   Plan --> Architect
+   Architect --> Implement
+   Implement --> Test
+   Test --> Review
+   Review --> Ship
+   Ship --> [*]
+   Implement : Implement (current)
+```
+
+Append ` (current)` to whichever phase's own name is the one that just completed or is in progress —
+exactly one phase carries it at a time, matching the status line's own `[Phase N/6 — Name]` value. Omit
+`Enchant` from the diagram entirely when Phase 1.5 was skipped (Decision logic above); insert it between
+`Plan` and `Architect` when it ran.
+
 ---
 
 ## Rules
@@ -204,7 +226,7 @@ After each phase completes, output a brief status line:
 - **No scope creep.** Only build what the feature description specifies.
 - **Fail fast.** If a phase cannot succeed, halt immediately rather than producing garbage for downstream phases.
 - **Attribution required.** Every commit must carry `Agent`, `Model`, and `Provider` trailers per ADR-028/ADR-029.
-- **Branch discipline.** All work on topic branches, never on main. Per ADR-048.
+- **Branch discipline.** All work on topic branches, never on main — see `.arcane/governance/git-conventions.md`'s Trunk-based development rule. (Corrected 2026-08-31, BC-14: previously cited "ADR-048," which does exist in the shipped `framework-decisions.md` reference but is actually about the Code-Versus-Docs Branch Policy's local-only-repo fallback, unrelated to this general rule — a topical miscitation, the same class BC-06 found and fixed elsewhere. `git-conventions.md` states this rule directly with no ADR/ARC number attached, so there is nothing to cite beyond the file itself.)
 - **Fresh context per story.** Do not carry assumptions between stories during Phase 3.
 - **Epic checkpointing.** When this spell is run as one epic in a multi-epic plan, recommend running `spell-commit-work` before starting the next epic.
 - **Multi-epic runs serialize by default (ARC-028 R4).** Before running two or more epics concurrently in separate worktrees, compare their footprints: the file and directory globs each will touch, plus any **shared sequence** — database migration numbers, generated indexes and manifests, lockfiles, fixture IDs, anything where correctness depends on what another epic picked. If the footprints overlap on either axis, run the epics **sequentially in one workspace**, or re-scope them to disjoint footprints first. State the comparison and the resulting decision in the run's opening report; "they seemed unrelated" is not a footprint comparison.

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

@@ -64,7 +64,22 @@ For each selected entry, in list order, resolve the venture it belongs to (`hub`
 
 If the venture has no registered repo (`repos: []`, e.g. an idea-stage venture), only (e), (f), (g) are offered. Typing `same` for any entry after the first repeats the previous entry's destination.
 
-Once every selected entry has a destination, print one consolidated plan and ask `Proceed? (go / edit / cancel)`. This confirmation covers ordinary destinations only — it never authorizes a disclosure; see Step 5.
+Once every selected entry has a destination, print one consolidated plan — per the generated state
+diagrams convention (rule 8, ARC-036), built only from the routing already decided in this step; skip
+entirely (the applicability guard) for a single selected entry going to a single destination — routing
+a lone entry has no topology to visualize:
+
+```mermaid
+flowchart LR
+   E1["#1 dark-mode toggle"] --> A["(a) repo IDEAS.md"]
+   E2["#2 cart snapshot"] --> Eroute["(e) demote to TODO"]
+   A --> Ordovica[ordovica]
+```
+
+One node per selected entry (its list number + a short title fragment), pointing to its chosen
+destination letter; where the destination names a specific venture or repo, a further node names it,
+matching the batch's actual routing rather than a fixed shape. Then ask `Proceed? (go / edit / cancel)`.
+This confirmation covers ordinary destinations only — it never authorizes a disclosure; see Step 5.
 
 ## Step 5 — Disclosure Gate
 

package/dist/assets/.github/prompts/spell-review-batch.prompt.md

@@ -80,6 +80,23 @@ Build one report:
 
 The overall gate is **NO-GO** if any reviewed PR has an unresolved HIGH finding, **or** if any requested PR was skipped (an un-reviewed PR can't be cleared) — otherwise **GO**. `HIGH` is the top severity in the `spell-review` ladder; do not invent a "Critical" tier the engine never emits.
 
+**Gate flowchart** — per the generated state diagrams convention (rule 8, ARC-036), built only from
+the verdict already computed per PR above; skip entirely (the applicability guard) for a batch of one
+PR — there is nothing to aggregate:
+
+```mermaid
+flowchart LR
+   PR1["PR #n<br/>approve"] --> Gate{Gate}
+   PR2["PR #n<br/>request-changes"] --> Gate
+   Gate --> Verdict[GO]
+```
+
+One node per PR in the batch, labeled with its number and verdict exactly as computed in the table
+above (including `SKIPPED`); the gate node's outcome is the same GO/NO-GO already derived. Never use
+the bare lowercase word `end` as a node label — Mermaid's flowchart parser reserves it and will fail
+to render (verified against Mermaid's own flowchart syntax docs; none of this batch's real labels
+collide, but a PR title inserted verbatim as a label could).
+
 ## Step 4 — Output
 
 1. Write the consolidated markdown report to a sensible path (e.g. `reviews/batch-review-{date}.md`).

package/package.json

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