arcane-cli 0.38.3 → 1.0.0

package/dist/assets/.github/prompts/spell-sync-pull-request.prompt.md

@@ -7,155 +7,4 @@ agent: agent
 last_updated: 2026-08-31
 ---
 
-## Executive Summary
-
-- This spell safely syncs an open PR's branch with its target branch once the target has moved ahead.
-- It is the recovery path `spell-create-pull-request` and `spell-ship` route to when they detect a
-  conflict they deliberately don't try to resolve themselves.
-- It draws a hard line between conflicts safe to resolve mechanically (identical changes on both sides)
-  and conflicts that need a human — it never guesses on the ambiguous side of that line.
-- Every history-rewriting step is preceded by a recoverable ref, and every push uses
-  `--force-with-lease`, never bare `--force`.
-
----
-
-Sync the specified PR's branch (or the current branch's own open PR) with its target branch.
-
-Context to consult:
-
-- `.arcane/governance/git-conventions.md` — the declared merge-strategy ladder (Merge no-fast-forward or
-  Rebase-and-fast-forward sanctioned; Squash and Semi-linear merge never sanctioned) and branch policy.
-- `.arcane/governance/testing-standards.md` — coverage thresholds for the post-replay gate re-run.
-
-Related spells:
-
-- `spell-create-pull-request` — routes here from its Step 0.6 conflict-stop; reuses its Step 2
-  provider-detection table rather than re-deriving it (D8).
-- `spell-ship` — routes here from its Step 2 conflict-stop.
-
-## Step 0 — Guard checks
-
-1. **Require a clean worktree.** Run `git status --porcelain`. Any output — staged, unstaged, or
-   untracked — **STOPS** this spell before it touches anything. Sync is not the place to also carry
-   uncommitted work through a rebase.
-2. **Resolve the active PR, source branch, base branch, and expected head SHA.** If a PR number or
-   branch name was given as an argument, resolve from that; otherwise resolve from
-   `git branch --show-current` and the open PR for it (reuse `spell-create-pull-request`'s Step 2
-   provider-detection and open-PR-lookup calls — same commands, not restated here). Record the
-   branch's current HEAD SHA now, before anything else runs — this is what "expected head SHA" means
-   for Step 5's post-push verification once rebase/replay changes it to a new value.
-3. **STOP** if no open PR is found for the resolved branch — this spell syncs an *existing* PR; if none
-   exists yet, direct the user to `spell-create-pull-request` first.
-
-## Step 1 — Create the recoverable ref
-
-Before any history-rewriting operation, tag the current HEAD so this sync is never a one-way door:
-
-```bash
-git tag "sync-backup/<branch>/$(date +%Y%m%d-%H%M%S)" HEAD
-```
-
-Report the tag name in the final output (Step 6). **Never delete this tag automatically** — leave it for
-the human to remove once they've confirmed the sync landed correctly; this spell only ever adds it.
-
-## Step 2 — Fetch and apply the declared merge policy
-
-```bash
-git fetch origin
-```
-
-Resolve the repository's actual merge-strategy ladder from `git-conventions.md` rather than assuming:
-
-- **Rebase-and-fast-forward** (the common case for a PR that's simply fallen behind): `git rebase origin/<target>`.
-- **Merge no-fast-forward** (when the repo's declared policy or the PR's own history indicates merge
-  commits are the norm here): `git merge origin/<target>`.
-- **Never** produce a squash or semi-linear result as part of this sync — those are never sanctioned,
-  regardless of which of the two above applies.
-
-## Step 3 — Classify any conflict: mechanical vs. ambiguous
-
-If Step 2 completes with no conflicts, skip straight to Step 4 — **this is the common case and it must
-not be treated as a special case of conflict handling.**
-
-If Step 2 reports conflicts, read every conflicted file's conflict markers before doing anything else,
-then classify **each conflicted hunk independently** — a single file can contain both kinds:
-
-- **Mechanically resolvable** — both sides made the identical change (e.g. the same formatting fix, the
-  same import added the same way), or one side's change is a strict superset of the other's with no
-  semantic divergence. Resolve by keeping the superset/identical content, verify no line from either
-  side's *unique* content was dropped, stage the file, and continue the rebase/merge.
-- **Ambiguous** — the same lines changed with different intent, or you cannot establish with confidence
-  that one side's content is a strict superset of the other's. **STOP.** Do not guess, do not pick a
-  side, do not attempt a "reasonable-looking" merge of the two. Abort the in-progress rebase/merge
-  (`git rebase --abort` / `git merge --abort`) so the branch is left exactly as it was, then report:
-  - The exact conflicting file(s) and hunk(s).
-  - Both sides' conflicting content, verbatim.
-  - That the recoverable ref from Step 1 still points at the pre-sync state.
-  - A direct instruction to resolve manually and re-run this spell, or to resolve and push directly.
-
-Never proceed past an ambiguous hunk on the theory that "the rest of the file is fine" — abort the whole
-operation and hand off, per the line above.
-
-## Step 4 — Re-run project gates before pushing
-
-A clean replay is not the same as a working tree. Before pushing:
-
-```bash
-npm run typecheck && npm run lint && npm run test
-```
-
-If this repository has `check:version-bump` and the sync touched any distributable path, run it too. **A
-gate failure here is the same class of stop as an ambiguous conflict** — do not push a tree that fails
-its own gates just because the git-level replay succeeded. Report which gate failed and stop; the
-recoverable ref from Step 1 is still available.
-
-## Step 5 — Push and verify
-
-```bash
-git push --force-with-lease
-```
-
-- **On success:** proceed to provider verification below.
-- **On lease rejection** (the remote moved again since this sync's own Step 2 fetch — someone else
-  pushed to the branch in the meantime): **do not retry with `--force`, and do not retry
-  `--force-with-lease` blindly.** Re-fetch and re-evaluate from Step 2 as if starting over — the branch
-  state this sync was built against no longer exists. This is a genuinely new sync, not a retry of the
-  same one.
-
-**Provider verification (never assume a successful push means the PR reflects it):**
-
-| Provider | Verify |
-| --- | --- |
-| GitHub | `gh pr view <PR#> --json headRefOid,mergeable` — `headRefOid` must equal the new HEAD SHA from Step 5; `mergeable` should not report a conflict state. |
-| Azure DevOps | `az repos pr show --id <PR_ID> --output json --query "{sha:lastMergeSourceCommit.commitId, status:mergeStatus}"` — the SHA must equal the new HEAD; `status` should not report `conflicts`. |
-
-If the reported SHA does not match, or the mergeable/status field reports a conflict despite a clean
-local push, **do not report success** — this is the exact "dispatched is not succeeded" gap EF-21
-already established for `spell-close-session`; a push completing without error is dispatched, not
-verified. Re-check once after a short wait (provider APIs can lag); if it still doesn't match, stop and
-report the discrepancy rather than declaring the sync done.
-
-## Step 6 — Report
-
-```
-✓ PR synced: <URL>
-  Branch:          <branch> → <target>
-  Method:          rebase-and-fast-forward | merge-no-fast-forward
-  Conflicts:       none | resolved (mechanical) | none — no rebase needed
-  Recoverable ref: sync-backup/<branch>/<timestamp>
-  New head SHA:    <sha> (provider-confirmed)
-```
-
-- If Step 3 resolved any mechanical conflicts, list exactly which files and what was kept from each side.
-- If Step 3 aborted on an ambiguous conflict, this report never runs — Step 3's own STOP report is final.
-- Never delete the Step 1 recoverable ref as part of this report — that is the human's call.
-
-## Rules
-
-- Never push with bare `--force` — only `--force-with-lease`, and never retry a rejected lease blindly.
-- Never guess on an ambiguous conflict — abort and hand off, every time, with no exception for
-  "obviously trivial-looking" content on either side that this spell cannot independently verify.
-- Never skip the recoverable ref (Step 1), even for a sync expected to be clean — the ref costs nothing
-  and the alternative is an unrecoverable mistake on the case that turns out not to be clean.
-- Never report a sync as complete on a push success alone — provider verification (Step 5) is mandatory.
-- Never delete the recoverable ref automatically.
+This prompt is the Arcane `spell-sync-pull-request` spell. Read [`.arcane/spells/spell-sync-pull-request.md`](../../.arcane/spells/spell-sync-pull-request.md) and follow it as the complete workflow.

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

@@ -6,83 +6,4 @@ argument-hint: Story ID or test scope (e.g., "STORY-003" or "all")
 agent: agent
 ---
 
-## Executive Summary
-
-- This prompt runs tests, validates coverage against thresholds, and generates evidence artifacts.
-- Used after `spell-implement` to verify quality before `spell-review`.
-- Enforces the testing standards from ADR-050 (80% line / 95% critical path coverage).
-- See [[.arcane/governance/testing-standards|Testing Standards]] for framework details.
-
----
-
-Run test suites and validate quality for the specified scope.
-
-Use these files for context:
-
-- [governance/testing-standards.md](../../.arcane/governance/testing-standards.md) — Frameworks, thresholds, evidence requirements
-- [governance/development-methodology.md](../../.arcane/governance/development-methodology.md) — Spell Loop context
-- The feature's `stories.json` — for acceptance criteria to validate
-
-Workflow:
-
-1. **Identify test scope**:
-   - If a story ID is given, test only the files changed by that story.
-   - If "all" is given, run the full test suite.
-   - Determine the tech stack and corresponding test framework from testing-standards.md.
-
-2. **Run tests**:
-   - The spell is framework-agnostic — execute the test command for whatever stack the project uses. Example runners by ecosystem:
-     - JS/TS: `npm test` / `vitest run` / `jest`
-     - .NET: `dotnet test`
-     - Python: `pytest`
-   - Capture output including pass/fail counts and any error messages.
-   - Run coverage analysis if the framework supports it.
-
-3. **Validate coverage**:
-   - Compare against the thresholds configured in testing-standards.md. These percentages are the project's choice — use whatever values that doc defines, not a universal law. Typical defaults:
-     - Line coverage minimum (commonly ~80%).
-     - Critical path coverage (commonly ~95% for auth, payments, data mutations).
-   - If below threshold, identify uncovered lines and recommend specific tests to add.
-
-4. **Check acceptance criteria**:
-   - Map each acceptance criterion from the story to a specific test.
-   - Flag any acceptance criteria without corresponding test coverage.
-
-5. **Generate test evidence**:
-   ```markdown
-   ## Test Evidence — [Story ID or Scope]
-
-   **Date:** [timestamp]
-   **Framework:** [e.g. Vitest / Jest / xUnit / pytest / etc.]
-
-   ### Results
-   - Tests passed: [N]
-   - Tests failed: [N]
-   - Tests skipped: [N]
-   - Line coverage: [N%]
-   - Branch coverage: [N%]
-
-   ### Acceptance Criteria Coverage
-   | Criterion   | Test        | Status            |
-   | ----------- | ----------- | ----------------- |
-   | [criterion] | [test name] | PASS/FAIL/MISSING |
-
-   ### Uncovered Areas
-   - [file:lines with no coverage]
-
-   ### Recommendations
-   - [Additional tests needed]
-   ```
-
-6. **Update stories.json** — if testing a specific story, update the `testEvidence` field.
-
-7. **Report** — present the test evidence and recommend next steps:
-   - All pass + coverage met → recommend `spell-review`.
-   - Failures found → recommend fixing via `spell-implement`.
-   - Coverage gap → recommend adding tests before review.
-
-Rules:
-- Never mark a story as passing if tests fail or coverage is below the threshold.
-- Include actual test output, not just summaries.
-- If no test framework is set up, flag this as a blocker and recommend setup.
-- Critical path code (auth, payments, data mutations) must meet the 95% threshold.
+This prompt is the Arcane `spell-test` spell. Read [`.arcane/spells/spell-test.md`](../../.arcane/spells/spell-test.md) and follow it as the complete workflow.

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

@@ -6,161 +6,4 @@ argument-hint: The raw idea to elaborate (e.g., "add spending limits doc", "auto
 agent: agent
 ---
 
-## Executive Summary
-
-- This prompt turns a vague idea into a concrete, well-scoped TODO item placed in the correct file and section.
-- It reads the current TODO landscape and repo structure to avoid duplicates and pick the right home.
-- Use this any time you have an idea mid-session and don't want to lose it or park it in the wrong place.
-- If the idea is ADR-worthy or journal-worthy, it flags that and routes accordingly.
-- **In a hub repo:** "add a todo for <venture>" targets that venture's own `TODO.md` book instead of the hub root. `--sweep` skips elaboration entirely and reports new/open counts across every book (hub root + every venture).
-
----
-
-Resolve `{BUSINESS_ROOT}` from `.arcane.json`'s `business_root` field (default `ventures/` if unset) before either mode below.
-
-## Sweep Mode (`--sweep`)
-
-If the argument is (or starts with) `--sweep`, skip every other step in this spell entirely and run this instead:
-
-- **In a hub repo:** report `status: new` counts and oldest-entry age for the hub root `TODO.md` plus every `{BUSINESS_ROOT}/<slug>/TODO.md` that exists. Group by book, point at `spell-manifest` for entries ready to promote. Report-only — no edits.
-- **In a consumer repo:** report the same, for the repo-root `TODO.md` only (no venture books exist there).
-
-Output format:
-
-```
-Todo sweep — N books, M open items
-
-hub TODO.md               12 open, oldest 2026-07-14
-ventures/ordovica/TODO.md  3 open, oldest 2026-08-10
-```
-
-## Step 0 — Venture Targeting (Hub Only)
-
-If the input names a venture ("add a todo for ordo", `--venture <slug>`), resolve it through `{BUSINESS_ROOT}/registry.json`'s aliases first (exact slug → alias → closest match offered — never guessed). Unknown slug:
-
-```
-No venture "<slug>" under {BUSINESS_ROOT}/ (closest: ordovica, tidewright).
-1) use <closest>  2) add to hub root TODO.md  3) cancel (create the venture first: spell-summon-venture)
-```
-
-If `role` in `.arcane.json` is not `"hub"`, venture-targeting phrasing is refused:
-
-> Venture targeting works only in the hub repo (`role: "hub"` in `.arcane.json`). This repo has no venture books.
-> 1) add to this repo's TODO.md (venture reference removed)
-> 2) skip — capture it in the hub: `spell-todo --venture <slug> "<idea>"`
-
-If option 1 is chosen and the named venture is a *different* venture than this repo's own, strip that name from the item text before writing it — a sibling venture's name must never land in a consumer repo's `TODO.md`. If it's this repo's own venture, keep the text as given.
-
-An idea that only *mentions* a venture, without targeting phrasing, is not redirected — proceed with the hub root as normal (speed rule: don't block on a maybe).
-
-Elaborate the idea given by the user and add it to the right document(s) — the hub root `TODO.md` by default, or the resolved venture's own `TODO.md` when targeted.
-
-The raw idea from the user is in the prompt argument. If no argument was provided, ask the user to describe the idea before proceeding.
-
-Use these files first:
-
-- [TODO.md](../../TODO.md) — section structure and existing items (avoid duplicates); or the targeted venture's own `TODO.md`
-- [DECISIONS.md](../../DECISIONS.md) — ADR registry (check if the idea is decision-worthy)
-- [README.md](../../README.md) — repo structure (find the right canonical doc to reference)
-- [project.md](../../project.md) — active priorities (calibrate urgency)
-
-## Step 1 — Understand the Idea
-
-Read the raw input. Ask one clarifying question only if the idea is fundamentally ambiguous (e.g., "which business?"). Do not ask for information you can infer.
-
-Classify the idea along two axes:
-
-**Type:**
-- `todo` — a discrete action item with a clear done state
-- `bug` — a defect to fix
-- `tech-debt` — deferred cleanup/refactor cost to track
-- `adr-candidate` — a significant architectural or policy decision that needs a formal ADR
-- `journal-seed` — context-heavy exploration that belongs in a journal entry, not a task list
-- `idea-capture` — a speculative or long-horizon idea with no immediate action (goes in TODO under the relevant section with a `[ ]`)
-
-**Domain** (pick primary):
-- `security` — threat model, hardening, access control
-- `agents` — agent config, channels, policies, installation
-- `infrastructure` — hardware, OS, cloud, networking, provisioning
-- `governance` — git conventions, agent autonomy, spending controls, work management
-- `ci-cd` — repos, pipelines, build/release automation
-- `business` — a specific business under `{BUSINESS_ROOT}/` — name which one
-- `product-ideas` — new product concepts or packaging ideas
-- `legal` — LLC, ToS, contracts
-- `playbooks` — runbooks, setup guides, automation scripts
-- `prompts` — new or updated `.github/prompts/` files
-
-**Scope** (optional, additive — does not replace Domain):
-- `repo` — repo-wide change touching the project broadly
-- `feature` — scoped to a specific feature or slug
-- `file` — scoped to a specific file or area
-
-## Step 2 — Elaborate
-
-Expand the idea into one or more concrete TODO items. Each item must:
-
-- Be phrased as an imperative action (e.g., "Define...", "Create...", "Implement...", "Document...")
-- Have a clear done state (reviewable by a human in 10 seconds)
-- Include a file reference if a canonical home doc already exists (e.g., `— see [[DECISIONS]]`)
-- Be specific enough to act on without further clarification
-
-If the idea naturally decomposes into multiple sub-items (e.g., "build dashboard" → design, implement, deploy, document), list them individually — do not bundle vague compound items.
-
-If the idea is an `adr-candidate`, also draft a one-sentence ADR title suggestion (e.g., `ADR-NNN: Use GitHub Actions for CI instead of Azure Pipelines`).
-
-## Step 3 — Route to the Right Document
-
-Determine the target file(s) for each item:
-
-| Situation                                             | Target                                                                             |
-| ----------------------------------------------------- | ---------------------------------------------------------------------------------- |
-| Discrete action item with a domain section in TODO.md | `TODO.md` under the matching section                                               |
-| New domain not yet in TODO.md                         | `TODO.md` — add a new section heading                                              |
-| Speculative idea or future-facing concept             | `TODO.md` under `## Product Ideas` or the best matching section                    |
-| ADR candidate                                         | `DECISIONS.md` — flag it as pending, do not write the full ADR yet                 |
-| Journal-worthy context                                | `journal/` — propose a filename with today's date slug, do not create the file yet |
-| Finding sourced from a research report                | `TODO.md` under the matching section — cross-reference the report path (e.g., `— see docs/research/<slug>.md`) |
-| Business-specific execution item                      | Both `TODO.md` AND the relevant `{BUSINESS_ROOT}/<name>/overview.md` reference section  |
-
-## Step 4 — Show Proposal
-
-Output the elaborated items in this format before making any edits:
-
-## Proposed TODO Addition
-
-**Idea understood as:** [one-sentence restatement]
-**Type:** [type from Step 1]
-**Domain:** [domain from Step 1]
-**Scope:** [scope from Step 1, if applicable — repo / feature / file]
-
-**Elaborated items:**
-
-- [ ] [First item — phrased as imperative, with file ref if applicable]
-- [ ] [Second item if applicable]
-- ...
-
-**Target document(s):**
-- `[file path]` → section `## [Section Name]`
-
-**If ADR-candidate:** Suggested ADR title: `ADR-NNN: [title]`
-
-**Placement note (if any):** [e.g., "No matching section exists — will add ## [New Section]"]
-
-**Approve?** (yes / edit / skip)
-
-## Step 5 — Apply (After Approval)
-
-When the user approves:
-
-1. Insert the item(s) at the bottom of the correct section in the target file(s).
-2. Update the `last_updated` frontmatter on every file touched (date: today as YYYY-MM-DD).
-3. Do NOT commit — leave that to `spell-commit-work`.
-4. Confirm what was added and where.
-
-Output after applying:
-
-## Added
-
-- `[file]` → `## [Section]`: [item text]
-
-**Next:** Run `spell-commit-work` to checkpoint, or continue the session.
+This prompt is the Arcane `spell-todo` spell. Read [`.arcane/spells/spell-todo.md`](../../.arcane/spells/spell-todo.md) and follow it as the complete workflow.

package/dist/assets/.github/prompts/spell-verification-ledger.prompt.md

@@ -6,97 +6,4 @@ argument-hint: Optional focus (e.g., "just the corrections", "since the last com
 agent: agent
 ---
 
-## Executive Summary
-
-- The highest-value output of a working session is often the corrections — claims that were checked and
-  did not survive. `spell-close-session` captures what happened and sanitized lessons learned; it does
-  not capture what was asserted, what was checked, what the check showed, or what changed as a result.
-  This spell extracts exactly that, separately.
-- **Run on demand, not every session.** Most sessions have nothing worth a ledger entry; this spell says
-  so plainly and stops rather than manufacturing content to fill one (same discipline as
-  `spell-document`).
-- **A `corrected` result is the point, not a failure to hide.** A ledger showing three confirmed claims
-  and one correction is more valuable than one showing four confirmed claims and nothing else — the
-  correction is evidence the verification step actually did something, not theater.
-- Appends to a single running file, [`docs/verification-ledger.md`](../../docs/verification-ledger.md),
-  so a calibration rate (how often a checked claim survives) is computable across sessions without
-  reading scattered journal entries.
-
----
-
-## What counts as a ledger-worthy event
-
-Only an assertion that was actually **checked against an independent source** counts — not every
-statement made during the session. The check has to have been capable of coming back either way:
-
-- A confident claim, followed by a real verification step (a tool call, a live read, re-running
-  something, checking a second source), whose result **confirmed** the claim.
-- A confident claim, followed by the same kind of check, whose result **contradicted** it —
-  a **correction**.
-- A check that was attempted but couldn't produce a definitive answer (no access, an ambiguous result)
-  — **unverifiable**. Distinct from never having been checked at all, which isn't ledger-worthy at all.
-
-Not ledger-worthy: a claim nobody checked, a preference or judgment call with no verifiable fact behind
-it, or a check whose outcome was never in doubt (confirming something already directly observed moments
-earlier is not a verification event).
-
-## Workflow
-
-1. **Scan the session for ledger-worthy events**, per the definition above. Look specifically for
-   moments where a check contradicted an initial assertion — a count that was off, a file path that
-   didn't exist, a "should be done" that direct inspection showed wasn't, a citation that pointed at the
-   wrong content. These are usually more memorable than confirmations; do not let them get lost among
-   routine, expected-to-pass checks.
-
-2. **Stop here if nothing qualifies.** If the session had no real verification events — no claim was
-   both asserted with confidence and independently checked — say so plainly and do not proceed. A quiet,
-   uneventful session with nothing to report is a valid outcome, not a gap to paper over.
-
-3. **Classify each event:**
-
-   | Field | What it captures |
-   | --- | --- |
-   | Claim | The assertion as originally stated, in the speaker's own words at the time — not softened in hindsight. |
-   | Verification method | What was actually done to check it (a specific command, a specific file read, a specific re-fetch) — not "verified," which asserts nothing checkable itself. |
-   | Result | `confirmed` / `corrected` / `unverifiable`. |
-   | Correction | For `corrected` only: what the check actually showed, and what changed as a result (a claim retracted, a decision reversed, a fix applied). |
-
-4. **Present the extracted ledger for approval** before writing — the same approval gate
-   `spell-document` uses, since this is also durable content leaving the conversation:
-
-   ```text
-   ## Verification Ledger Proposal — [session topic]
-
-   | Claim | Verification method | Result | Correction |
-   | --- | --- | --- | --- |
-   | ... | ... | confirmed | — |
-   | ... | ... | corrected | ... |
-
-   Approve? (yes / edit / skip)
-   ```
-
-5. **Append, don't rewrite.** After approval, append a new `## YYYY-MM-DD — <session topic>` section
-   with the approved table to `docs/verification-ledger.md`. Get the real date from the system rather
-   than guessing. If the file doesn't exist yet, create it with a short header explaining its purpose
-   and schema, then the first section — never insert a section anywhere but the end.
-
-## Rules
-
-- Never fabricate a ledger-worthy event to fill a report — an empty result from step 2 is a complete,
-  valid run of this spell.
-- Quote the claim as it was actually stated, not a cleaned-up paraphrase that makes the miss look
-  smaller (or larger) than it was.
-- Do not editorialize about fault or blame in the ledger itself — the value is the calibration signal
-  (how often checks confirm vs. correct), not a record of who was wrong.
-- Do not commit the changes — that is `spell-commit-work`'s job.
-
-## Related
-
-- **Complements, does not replace:** `spell-close-session`'s narrative record and sanitized lessons
-  learned. Run this spell separately when a session had real verification events worth a structured
-  record, not as a mandatory step of every close.
-- `spell-document` — the general-purpose formalization spell this one borrows its
-  extract-then-approve-then-write shape from, narrowed to one specific, structured record type.
-
-> **Tip:** Run `spell-close-session` afterward to log the session, or `spell-commit-work` to commit the
-> ledger update.
+This prompt is the Arcane `spell-verification-ledger` spell. Read [`.arcane/spells/spell-verification-ledger.md`](../../.arcane/spells/spell-verification-ledger.md) and follow it as the complete workflow.