arcane-cli 0.22.8 → 0.22.10
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/assets/.github/prompts/spell-close-session.prompt.md +17 -0
- package/dist/assets/.github/prompts/spell-commit-work.prompt.md +17 -0
- package/dist/assets/.github/prompts/spell-create-pull-request.prompt.md +16 -0
- package/dist/assets/.github/prompts/spell-full-cycle.prompt.md +23 -1
- package/dist/assets/.github/prompts/spell-manifest.prompt.md +16 -1
- package/dist/assets/.github/prompts/spell-review-batch.prompt.md +17 -0
- package/package.json +1 -1
|
@@ -183,6 +183,23 @@ Output format:
|
|
|
183
183
|
## Session Closure
|
|
184
184
|
|
|
185
185
|
- Summary of what was completed.
|
|
186
|
+
- **Session commit graph** — per the generated state diagrams convention (rule 8, ARC-036), built only
|
|
187
|
+
from commits this session actually made (`git log <trunk>..HEAD --format="%h %s" --reverse`, or
|
|
188
|
+
`<remote>/<trunk>..HEAD` once pushed) plus step 1b's succeeded/pending/failed classification per
|
|
189
|
+
commit. Skip entirely (the applicability guard) for a read-only session or a single-commit session —
|
|
190
|
+
one point has nothing to sequence. Deliberately `gitGraph`, the same already-verified diagram type
|
|
191
|
+
R1–R9 use, not Mermaid's `timeline` diagram — that type is marked experimental in Mermaid's own docs,
|
|
192
|
+
a real compatibility risk across GitHub/VS Code/Obsidian this convention explicitly commits to
|
|
193
|
+
supporting; a session's own commit sequence is exactly what `gitGraph` already represents:
|
|
194
|
+
|
|
195
|
+
```mermaid
|
|
196
|
+
gitGraph
|
|
197
|
+
commit id: "<short-sha 1> succeeded"
|
|
198
|
+
commit id: "<short-sha 2> pending"
|
|
199
|
+
```
|
|
200
|
+
|
|
201
|
+
One commit per session commit, in order, `id` carrying its short SHA and step 1b's classification —
|
|
202
|
+
never claim `succeeded` for anything step 1b did not confirm as such.
|
|
186
203
|
|
|
187
204
|
## Journal Updates
|
|
188
205
|
|
|
@@ -243,4 +243,21 @@ Author: Display Name <email>
|
|
|
243
243
|
|
|
244
244
|
**Pull Request:** [full PR URL](https://github.com/{org}/{repo}/pull/{id} or https://dev.azure.com/{org}/{project}/_git/{repo}/pullrequest/{id})
|
|
245
245
|
|
|
246
|
+
**Branch topology** — per the generated state diagrams convention (rule 8, ARC-036), built only from
|
|
247
|
+
data Step 1/9 already gathered (current branch name, commits ahead of target via
|
|
248
|
+
`git log origin/<target>..HEAD --format="%h %s" --reverse`). Skip entirely — this is the applicability
|
|
249
|
+
guard — when there is no separate topic branch (the local-only-checkpoint path, committing directly on
|
|
250
|
+
trunk) or no usable remote (nothing to compare against):
|
|
251
|
+
|
|
252
|
+
```mermaid
|
|
253
|
+
gitGraph
|
|
254
|
+
commit id: "<target HEAD short-sha>"
|
|
255
|
+
branch <branch-name>
|
|
256
|
+
commit id: "<short-sha 1>"
|
|
257
|
+
commit id: "<short-sha 2>"
|
|
258
|
+
```
|
|
259
|
+
|
|
260
|
+
One commit per entry in the gathered commit list, in the same order; omit the diagram (not just the
|
|
261
|
+
commits) if that list is empty. Use `<target>`'s short SHA as the fork-point commit id.
|
|
262
|
+
|
|
246
263
|
**Next:** Continue work or run `spell-close-session` to finalize journal and session docs.
|
|
@@ -168,6 +168,22 @@ Documentation-only PR. No functional code changed.
|
|
|
168
168
|
- If no reviewers were resolved (none passed, or names the provider could not match): `⚠ No reviewers assigned — add them in the PR or re-run with --reviewers`.
|
|
169
169
|
- If `--draft`: note it was created as a draft.
|
|
170
170
|
- Delete the body temp file (`<git-dir>/arcane-pr-body.md`) once the PR is confirmed created and verified.
|
|
171
|
+
- **Branch topology** — per the generated state diagrams convention (rule 8, ARC-036), built only from
|
|
172
|
+
Step 1's already-gathered branch name and commit list (`git log origin/<target>..HEAD --format="%h %s" --reverse`).
|
|
173
|
+
Skip entirely (the applicability guard) if that commit list is empty — Step 0.4 already stops before
|
|
174
|
+
reaching here in that case, so this only re-states the same guard for anyone reading this step in
|
|
175
|
+
isolation:
|
|
176
|
+
|
|
177
|
+
```mermaid
|
|
178
|
+
gitGraph
|
|
179
|
+
commit id: "<target HEAD short-sha>"
|
|
180
|
+
branch <branch-name>
|
|
181
|
+
commit id: "<short-sha 1>"
|
|
182
|
+
commit id: "<short-sha 2>"
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
Same shape `spell-commit-work` uses for the identical concept — reference it rather than re-deriving
|
|
186
|
+
the rule (D8): one commit per gathered log entry, target's short SHA as the fork point.
|
|
171
187
|
|
|
172
188
|
## Rules
|
|
173
189
|
|
|
@@ -196,6 +196,28 @@ After each phase completes, output a brief status line:
|
|
|
196
196
|
[Phase 6/6 — Ship] AWAITING APPROVAL — PR #77 created, ship report below
|
|
197
197
|
```
|
|
198
198
|
|
|
199
|
+
**Pipeline state diagram** — per the generated state diagrams convention (rule 8, ARC-036), built only
|
|
200
|
+
from the phase status this section already tracks; skip entirely (the applicability guard) after Phase
|
|
201
|
+
1 alone, before any other phase has run — a single-state pipeline has nothing to show in relation to
|
|
202
|
+
the rest. From Phase 2 onward, alongside the status line above:
|
|
203
|
+
|
|
204
|
+
```mermaid
|
|
205
|
+
stateDiagram-v2
|
|
206
|
+
[*] --> Plan
|
|
207
|
+
Plan --> Architect
|
|
208
|
+
Architect --> Implement
|
|
209
|
+
Implement --> Test
|
|
210
|
+
Test --> Review
|
|
211
|
+
Review --> Ship
|
|
212
|
+
Ship --> [*]
|
|
213
|
+
Implement : Implement (current)
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
Append ` (current)` to whichever phase's own name is the one that just completed or is in progress —
|
|
217
|
+
exactly one phase carries it at a time, matching the status line's own `[Phase N/6 — Name]` value. Omit
|
|
218
|
+
`Enchant` from the diagram entirely when Phase 1.5 was skipped (Decision logic above); insert it between
|
|
219
|
+
`Plan` and `Architect` when it ran.
|
|
220
|
+
|
|
199
221
|
---
|
|
200
222
|
|
|
201
223
|
## Rules
|
|
@@ -204,7 +226,7 @@ After each phase completes, output a brief status line:
|
|
|
204
226
|
- **No scope creep.** Only build what the feature description specifies.
|
|
205
227
|
- **Fail fast.** If a phase cannot succeed, halt immediately rather than producing garbage for downstream phases.
|
|
206
228
|
- **Attribution required.** Every commit must carry `Agent`, `Model`, and `Provider` trailers per ADR-028/ADR-029.
|
|
207
|
-
- **Branch discipline.** All work on topic branches, never on main.
|
|
229
|
+
- **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.)
|
|
208
230
|
- **Fresh context per story.** Do not carry assumptions between stories during Phase 3.
|
|
209
231
|
- **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.
|
|
210
232
|
- **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.
|
|
@@ -64,7 +64,22 @@ For each selected entry, in list order, resolve the venture it belongs to (`hub`
|
|
|
64
64
|
|
|
65
65
|
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.
|
|
66
66
|
|
|
67
|
-
Once every selected entry has a destination, print one consolidated plan
|
|
67
|
+
Once every selected entry has a destination, print one consolidated plan — per the generated state
|
|
68
|
+
diagrams convention (rule 8, ARC-036), built only from the routing already decided in this step; skip
|
|
69
|
+
entirely (the applicability guard) for a single selected entry going to a single destination — routing
|
|
70
|
+
a lone entry has no topology to visualize:
|
|
71
|
+
|
|
72
|
+
```mermaid
|
|
73
|
+
flowchart LR
|
|
74
|
+
E1["#1 dark-mode toggle"] --> A["(a) repo IDEAS.md"]
|
|
75
|
+
E2["#2 cart snapshot"] --> Eroute["(e) demote to TODO"]
|
|
76
|
+
A --> Ordovica[ordovica]
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
One node per selected entry (its list number + a short title fragment), pointing to its chosen
|
|
80
|
+
destination letter; where the destination names a specific venture or repo, a further node names it,
|
|
81
|
+
matching the batch's actual routing rather than a fixed shape. Then ask `Proceed? (go / edit / cancel)`.
|
|
82
|
+
This confirmation covers ordinary destinations only — it never authorizes a disclosure; see Step 5.
|
|
68
83
|
|
|
69
84
|
## Step 5 — Disclosure Gate
|
|
70
85
|
|
|
@@ -80,6 +80,23 @@ Build one report:
|
|
|
80
80
|
|
|
81
81
|
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.
|
|
82
82
|
|
|
83
|
+
**Gate flowchart** — per the generated state diagrams convention (rule 8, ARC-036), built only from
|
|
84
|
+
the verdict already computed per PR above; skip entirely (the applicability guard) for a batch of one
|
|
85
|
+
PR — there is nothing to aggregate:
|
|
86
|
+
|
|
87
|
+
```mermaid
|
|
88
|
+
flowchart LR
|
|
89
|
+
PR1["PR #n<br/>approve"] --> Gate{Gate}
|
|
90
|
+
PR2["PR #n<br/>request-changes"] --> Gate
|
|
91
|
+
Gate --> Verdict[GO]
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
One node per PR in the batch, labeled with its number and verdict exactly as computed in the table
|
|
95
|
+
above (including `SKIPPED`); the gate node's outcome is the same GO/NO-GO already derived. Never use
|
|
96
|
+
the bare lowercase word `end` as a node label — Mermaid's flowchart parser reserves it and will fail
|
|
97
|
+
to render (verified against Mermaid's own flowchart syntax docs; none of this batch's real labels
|
|
98
|
+
collide, but a PR title inserted verbatim as a label could).
|
|
99
|
+
|
|
83
100
|
## Step 4 — Output
|
|
84
101
|
|
|
85
102
|
1. Write the consolidated markdown report to a sensible path (e.g. `reviews/batch-review-{date}.md`).
|