arcane-cli 0.22.9 → 0.22.11

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

@@ -112,5 +112,5 @@ Workflow:
 Rules:
 - Stories must be right-sized per the methodology doc (not "build the entire dashboard").
 - Architecture decisions must reference existing ADRs when relevant.
-- Use Mermaid for all diagrams.
+- Use Mermaid for all diagrams, per rule 8 (`.arcane/governance/universal-agent-rules.md`) — this spell's component/data-flow diagrams are agent-authored design output, not the generated-state-diagrams sub-convention ARC-036 covers.
 - If PRD scope is too large, recommend splitting before proceeding.

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-explain-concept.prompt.md

@@ -21,7 +21,7 @@ Follow these rules strictly:
 
 1. **Start with the one-sentence answer.** What is it, or why does it happen? No preamble.
 2. **Use analogies from the user's world** — relate to tools, systems, or workflows they already use (their editor, their chat/notification tooling, their own agents, their own infrastructure). Check the workspace for context about the user's setup.
-3. **Use diagrams when architecture matters.** Mermaid sequence diagrams for flows, flowcharts for decision trees. Don't use diagrams for simple definitions.
+3. **Use diagrams per rule 8** (`.arcane/governance/universal-agent-rules.md`) — Mermaid sequence diagrams for flows, flowcharts for decision trees. Don't use diagrams for simple definitions.
 4. **Show the "so what?"** — connect the explanation to what the user can *do* with this knowledge. What decisions does it unlock? What options does it create?
 5. **Name the moving parts** with a summary table when there are multiple components, layers, or options to compare.
 6. **Use real examples from their system** — reference actual agent names, actual config files, actual commands. Don't use generic placeholders when specific is available.

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/dist/assets/.github/prompts/spell-scope.prompt.md

@@ -175,7 +175,7 @@ Flag any epics that need **multiple roles** (e.g., a full-stack feature = backen
 
 ### 7. Dependency Graph
 
-Produce a Mermaid diagram showing epic execution order:
+Produce a Mermaid diagram (per rule 8) showing epic execution order — an agent-authored planning diagram, not the generated-state-diagrams sub-convention ARC-036 covers, since the ordering is this spell's own design output rather than already-computed state:
 
 ```mermaid
 flowchart LR

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

@@ -30,6 +30,25 @@ Workflow:
    - Full project audit
    - Particular area of concern (auth, payments, data handling)
 
+1a. **Map trust boundaries and data flow** — before running the checklists below, sketch how data crosses trust zones (external actors, the auth boundary, internal services, data stores). This is agent-authored analysis under rule 8 (`.arcane/governance/universal-agent-rules.md`), not the generated-state-diagrams sub-convention ARC-036 covers — there is no already-computed trust-boundary state to read back, only the agent's own reasoning about the code. Use a Mermaid flowchart with a subgraph per trust zone:
+
+   ```mermaid
+   flowchart LR
+       subgraph External [Untrusted]
+           User[User / Client]
+       end
+       subgraph Boundary [Trust Boundary: Auth]
+           API[API Layer]
+       end
+       subgraph Internal [Trusted]
+           DB[(Data Store)]
+       end
+       User -->|request| API
+       API -->|authenticated query| DB
+   ```
+
+   Skip this step when the review scope doesn't cross any trust boundary — a single internal utility with no new external interaction, no new data store, and no new auth flow has nothing to diagram.
+
 2. **OWASP Top 10 checklist** — check each category:
 
    | #   | Category                  | Check                                                                                       |
@@ -81,6 +100,9 @@ Workflow:
    **Date:** [timestamp]
    **Scope:** [What was reviewed]
 
+   ### Trust Boundary / Data Flow
+   [Mermaid flowchart from step 1a — omit this section entirely if step 1a was skipped]
+
    ### OWASP Top 10 Results
    | Category                  | Status    | Findings  |
    | ------------------------- | --------- | --------- |

package/package.json

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