arcane-cli 0.22.10 → 0.22.12

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

@@ -66,6 +66,8 @@ Workflow:
    - Keep unresolved items open.
    - Remove completed checklist items only when completion is documented in the correct source-of-truth file.
 
+4b. **Register unfinished, task-bearing work on a durable surface (session handoff durability, ARC-040) before the handoff is written.** Enumerate: an incomplete `Active task`, the `Next concrete action`, and any content that would otherwise live only in `Notes` because it has no other durable home. For each, resolve the sink from `tracking_mode` (per ARC-032): `internal` → the appropriate `TODO.md` (root or venture book); `external` → a work item via the configured `external_provider`, falling back to `TODO.md` when tracker tooling is unavailable this session. Write or update the entry, then carry its location into step 5b so the handoff fields below can name it. Skip this step entirely when nothing is unfinished — a fully clean close has nothing to register.
+
 5. **Update [ai-context/system-prompt-context.md](../../ai-context/system-prompt-context.md).**
    - If priorities, environment state, or agent rules changed during the session, update the file to reflect current reality.
    - If no changes are needed, skip this step.
@@ -80,14 +82,14 @@ In `ai-context/system-prompt-context.md`, replace the existing `## Next Session
 > Auto-generated by spell-close-session. Consumed by spell-open-session. Do not edit manually.
 > Generated: YYYY-MM-DD
 
-- **Active task:** One-line description of the task that was in progress when this session closed.
+- **Active task:** One-line description of the task that was in progress when this session closed. If incomplete, name where step 4b registered it (e.g. `TODO.md:NNN`).
 - **Last completed step:** The final concrete action taken — include file path or command text. If that action was async work step 1b classified as anything other than `succeeded`, do not describe it as done here — name the action in `dispatched`/in-progress terms (e.g. "Pushed the fix and opened PR #NN" is fine; "Merged PR #NN" is not, unless step 1b confirmed the merge) and let `Pending Verification` carry the actual state.
-- **Next concrete action:** The exact first thing to do at next session start. Be specific: file, command, or decision. Never write "continue work."
+- **Next concrete action:** The exact first thing to do at next session start. Be specific: file, command, or decision. Never write "continue work." Name where step 4b registered it (e.g. `TODO.md:NNN`).
 - **Active files:** Files with uncommitted changes or the focus of the last edit (comma-separated).
 - **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.
-- **Notes:** Anything time-sensitive, fragile, or contextual that would be lost if not stated explicitly.
+- **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.
 ```
 
 Rules:
@@ -251,6 +253,7 @@ Route the user to the right next spell based on the end state:
 Rules:
 
 - Do not invent completions — only mark items done if verifiable from context. "Verifiable" means classified `succeeded` under step 1b's five-state vocabulary (`dispatched`/`pending`/`succeeded`/`failed`/`unverifiable`), not merely "I can see it was started" (EF-21).
+- `Notes` is a pointer, never the sole carrier of durable content (session handoff durability) — if something needs to survive to next session, it must also live wherever step 4b registers it, not only in prose here.
 - Keep frontmatter date values in `YYYY-MM-DD`.
 - Preserve existing checklist and journal style.
 - Keep edits minimal and factual.

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-open-session.prompt.md

@@ -34,9 +34,9 @@ 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. 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.
+- 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.
 - **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 before appending `> ✓ Consumed: YYYY-MM-DD` (today's date). The marker write is a repository mutation.
+- 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` line, 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.
 
 ## Mutation Guard (run lazily before the first repository write)

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/dist/assets/ai-context/system-prompt-context.md

@@ -23,11 +23,17 @@
 
 ## Next Session Handoff
 
-**Active task:** None yet.
-**Last completed step:** Initial scaffold via `spell init`.
-**Next concrete action:** Begin work.
-**Active files:** —
-**Branch:** main
-**Blockers:** None.
-**Pending Verification:** None.
-**Notes:** —
+> Auto-generated by spell-close-session. Consumed by spell-open-session. Do not edit manually.
+> Generated: YYYY-MM-DD
+
+- **Active task:** None yet.
+- **Last completed step:** Initial scaffold via `spell init`.
+- **Next concrete action:** Begin work.
+- **Active files:** —
+- **Branch:** main
+- **Blockers:** None.
+- **Pending Verification:** None.
+- **Notes:** —
+
+> ✓ Consumed: YYYY-MM-DD — scaffold placeholder, not a real session; ships pre-consumed so the first
+> real spell-open-session run does not mistake this for live handoff content.

package/package.json

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