arcane-cli 0.39.0 → 1.1.0

package/dist/assets/.github/prompts/spell-make-discoverable.prompt.md

@@ -6,288 +6,4 @@ argument-hint: Optional path or origin of the property to audit (defaults to the
 agent: agent
 ---
 
-## Executive Summary
-
-- This spell audits a web property's discoverability to search engines and, by
-  extension, to the AI assistants that retrieve from those engines' indexes —
-  per-route share metadata, robots/sitemap policy, non-production noindexing,
-  and search-engine registration — then proposes fixes.
-- **The default run changes nothing.** It produces an audit and a proposed
-  change set, and stops at an explicit approval gate. Nothing is written
-  without `--apply` *and* that approval.
-- **It never performs an outward-facing action on its own** — a DNS write, a
-  console submission, a crawl-notification ping. Every such action is
-  confirmed individually, with the current live state printed first, never
-  batched and never assumed from a prior run.
-- **It verifies by content, never by confirmation.** Every claimed fix is
-  checked by re-fetching the actual served response or re-reading the actual
-  external state, per `EV-01`/`EV-02`.
-- **This spell audits a property that is already live.** It does not deploy
-  one — run it after your team's own deploy/ship workflow has put something
-  live at `{SITE_ORIGIN}`, not instead of it.
-
----
-
-## Placeholders
-
-Every placeholder below follows the same resolution rule: pull it from
-`.arcane.json`, the invoking frontmatter, or the repository's own existing
-config; if it is not resolvable from any of those, **ask** — never assume.
-A wrong guess in this spell is not a local mistake, it is published to the
-public internet.
-
-| Placeholder | What it is | Resolution rule |
-| --- | --- | --- |
-| `{SITE_ORIGIN}` | The production origin (scheme + host) of the property being audited. | Resolve from `.arcane.json` / frontmatter / the repo's own deploy config; if unset, ask — never assume, a wrong guess here is published to the public internet. |
-| `{SERVING_LAYER}` | The component that already serves the built app's HTML responses (a static host, an edge/SSR function, a CDN in front of the origin). | Resolve from `.arcane.json` / frontmatter / the repo's own build-and-deploy config; if unset, ask rather than assuming a serving layer that isn't actually there. |
-| `{ENV_SIGNAL}` | The repo's own existing signal for which environment a given request is running in (an env var, a build-time flag, a hostname pattern) — used to gate non-production noindexing. | Resolve from `.arcane.json` / frontmatter / the repo's own config; if unset, ask — guessing wrong here either noindexes production or leaves staging indexable. |
-| `{PUBLIC_ASSET_PREFIX}` | The path prefix or origin that serves publicly-fetchable static/share assets (e.g. share-card images) without authentication. | Resolve from `.arcane.json` / frontmatter / the repo's own asset/storage config; if unset, ask. |
-| `{RESTRICTED_PREFIX}` | The path prefix for admin, internal, or otherwise non-public routes that must never be indexable or listed in a sitemap. | Resolve from `.arcane.json` / frontmatter / the repo's own routing config; if unset, ask. |
-| `{NONPROD_ORIGINS}` | The staging, preview, and development origins for this property that must never be indexed. | Resolve from `.arcane.json` / frontmatter / the repo's own deploy config; if unset, ask — never assume a short list you found is exhaustive. |
-| `{DNS_ZONE}` | The DNS zone that holds, or will hold, this property's domain-ownership verification record for search-engine registration. | Resolve from `.arcane.json` / frontmatter / the repo's own infrastructure config; if unset, ask — never assume (see `EV-05`). |
-| `{PUBLIC_VISIBILITY_PREDICATE}` | The app's own existing rule for what counts as publicly listed/indexable content, as distinct from private, draft, or restricted content. | Resolve from `.arcane.json` / frontmatter / the app's own existing authorization or visibility logic; if unset, ask — never invent a visibility rule the app doesn't already enforce. |
-
-## Context files
-
-- [governance/web-discoverability-standards.md](../../.arcane/governance/web-discoverability-standards.md) —
-  every `WD-nn` rule this spell checks against. Rules are **cited by ID
-  only** in this spell, never restated. **If the file is not installed**,
-  this spell still runs in full — findings just cite each check as
-  `WD-nn (rationale unavailable — install the standards doc)` instead of
-  linking to it.
-- [governance/external-verification-standards.md](../../.arcane/governance/external-verification-standards.md) —
-  every `EV-nn` rule the Verify phase (and the outward-facing-action gating
-  in Phase 4b) checks against, cited by ID only. **If the file is not
-  installed**, this spell still runs, and Phase 5 still re-fetches and
-  re-reads rather than trusting a write's own success signal — it just
-  cites those checks as `EV-nn (rationale unavailable — install the
-  standards doc)` instead of linking to it.
-- An existing decisions or architecture doc, if one is present (e.g.
-  `DECISIONS.md` or an equivalent) — check it for any prior decision that
-  already governs this property's discoverability approach before proposing
-  something that would conflict with it. **If none is present**, proceed
-  without it and note in Phase 6 that no prior decision was found.
-
-## Preconditions
-
-Stop and report, without changing anything, if any of these fail:
-
-1. **`{SITE_ORIGIN}` resolves**, per the Placeholders rule above, or the
-   operator supplies it when asked. If it cannot be resolved and the
-   operator does not answer, stop before Phase 1.
-2. **At least one HTTP(S) response is actually reachable at
-   `{SITE_ORIGIN}`.** This spell audits a property that is already live; if
-   nothing responds, stop and report that a deploy needs to happen first
-   (see Related) rather than auditing an empty origin.
-3. **`--apply` never substitutes for approval.** If `--apply` is passed up
-   front, the explicit approval gate in Phase 3 still applies in full before
-   Phase 4 runs anything.
-
-## Phase 1 — Inventory (always read-only)
-
-Enumerate the current state before proposing anything to change. Do not
-judge it yet — just record what is actually there, for `{SITE_ORIGIN}` and
-for each of `{NONPROD_ORIGINS}`:
-
-- **Per-route metadata**, sampled across a small set of distinct route
-  types (not just the homepage): `<title>`, meta description, canonical
-  link, Open Graph / social-card tags, and any structured-data block —
-  fetched with a plain HTTP client that does not execute JavaScript.
-- **`robots.txt`** — full raw contents, and whether it exists at all.
-- **AI user-agent policy in `robots.txt`** — every `User-agent:` group
-  present, and which vendor-published *retrieval* agents (the ones an AI
-  assistant or answer engine fetches with at answer time or indexes with)
-  versus *training* crawlers each group's rules match — checked against each
-  vendor's current crawler documentation, not memory, because the names
-  change.
-- **AI-readable convention files** — whether `/llms.txt` exists, its raw
-  contents, and whether documentation routes also serve a Markdown
-  representation.
-- **Non-canonical production hostnames** — every hostname the platform
-  serves the production artifact on besides `{SITE_ORIGIN}` (a
-  platform-assigned default hostname, a `www` alias), with the canonical tag
-  and robots meta of one sampled route on each. These are not
-  `{NONPROD_ORIGINS}` — they serve the real artifact — so record them
-  separately.
-- **`sitemap.xml`** (or wherever `robots.txt` points) — full raw contents,
-  whether it parses as well-formed, and the set of distinct `lastmod` values
-  it carries.
-- **Non-production noindex signals** — for each `{NONPROD_ORIGINS}` host,
-  the response headers and parsed `<head>` of one sampled route.
-- **DNS state at `{DNS_ZONE}`** relevant to search-engine registration —
-  the full current record set for the relevant name, queried directly
-  rather than read from a console (per `EV-01`).
-- **Anything unreachable** — a route, origin, or DNS name that doesn't
-  resolve at all. Report it; never silently skip it.
-
-## Phase 2 — Audit
-
-For each check below, capture the stated evidence and mark it
-`PASS`/`FAIL`. **Do not restate any rule's justification here — cite the ID
-only**; the reasoning lives in `web-discoverability-standards.md`. A row
-marked *(supplementary)* is a useful check that doesn't correspond to any
-single `WD-nn` rule — capture its evidence the same way, but don't cite a
-rule ID for it.
-
-**Per-route share metadata**
-
-| Rule ID | Check | Evidence to capture |
-| --- | --- | --- |
-| `WD-01` | Fetch `{SITE_ORIGIN}`/&lt;a specific deep route, not the homepage&gt; with a plain HTTP client that does not execute JavaScript. Does the raw response body carry a `<title>` and meta description distinct from the homepage's? | The two raw response bodies, with the extracted `<title>`/description values highlighted. |
-| *(supplementary)* | In that same response, do the Open Graph / social-card tags (`og:title`, `og:description`, `og:image`) reflect the route's own content, not the homepage's or a hard-coded default? | Extracted `og:*` tag values per sampled route. |
-| `WD-03` | Fetch a route representing content that no longer exists, or that was never public. Does the response return a genuine `404` or `410` status — not a `200` that merely renders a not-found-looking page? | The response status code, and the rendered body (to confirm it's the application's own not-found UI, not a generic host error page). |
-| *(supplementary)* | Does each fetched route carry exactly one `<link rel="canonical">`, self-referential or pointing at the one intended canonical URL, with no second conflicting canonical tag? | Canonical URL(s) found per route; flag any route with more than one. |
-| *(supplementary)* | Where the route type is expected to carry structured data, is an `application/ld+json` block present and does it parse as valid JSON? | The raw JSON-LD block per route, and the parse result. |
-| `WD-13` | Where a share-metadata or structured-data value is built from user- or content-supplied text (e.g. a title containing a quote or ampersand), is it correctly escaped for both contexts it appears in — JSON-escaped inside the JSON-LD payload, and separately HTML-escaped in surrounding markup — with no raw pass-through? | One sampled route whose content contains a quote, ampersand, or angle bracket, with the rendered JSON-LD and HTML attribute shown side by side. |
-| *(supplementary)* | Fetch a sampled `{PUBLIC_ASSET_PREFIX}` share-image URL with a plain, unauthenticated HTTP client. Does it return `200` with an image content-type and no auth redirect? | Response status, `Content-Type` header, and byte size for the sampled asset. |
-
-**Robots and sitemap policy**
-
-| Rule ID | Check | Evidence to capture |
-| --- | --- | --- |
-| *(supplementary)* | Fetch `{SITE_ORIGIN}/robots.txt` directly. Does it exist, return `200`, parse as valid, and avoid disallowing any route intended to be indexed? | Raw `robots.txt` body, and any `Disallow` line matching an intended-public route. |
-| *(supplementary)* | Does `robots.txt` contain a `Sitemap:` directive, and does fetching that URL return a well-formed sitemap? | The `Sitemap:` line and the fetched sitemap's parse result. |
-| `WD-07` | Does every URL listed in the sitemap satisfy `{PUBLIC_VISIBILITY_PREDICATE}`? | Any sitemap entries that fail the predicate. |
-| `WD-08` | Where `{PUBLIC_ASSET_PREFIX}` (or another specific public path referenced by page metadata) falls under a broader disallowed prefix in `robots.txt`, is an explicit `Allow:` rule declared for that specific path? | The relevant `Allow:`/`Disallow:` lines from `robots.txt`, and confirmation the specific path is fetchable by a crawler despite the broader disallow. |
-| `WD-16` | Parse `{SITE_ORIGIN}/robots.txt` group by group. Is any *retrieval*-class AI user-agent (per each vendor's current crawler documentation) matched by a `Disallow:` that covers an intended-public route? A training-crawler `Disallow:` is not a failure — record it as the operator's declared policy. | Every `User-agent:` group with its rules, each agent name classified as retrieval or training with the vendor page that says so, and the resolved allow/disallow verdict per retrieval agent for one sampled public route. |
-| `WD-18` | Parse the sitemap's `lastmod` values. Do they differ across URLs and track each URL's actual content change date — or does every entry carry one shared constant? | The distinct `lastmod` values with their counts, and for one sampled URL, the content's own change date (file date, changelog entry, or commit) next to its `lastmod`. |
-| *(supplementary)* | For a sampled route under `{RESTRICTED_PREFIX}`: is it absent from the sitemap, does it carry a noindex signal, and is it unreachable via any link from a route that satisfies `{PUBLIC_VISIBILITY_PREDICATE}`? | Sitemap membership (should be none), noindex signal, and an inbound-link check from the public route set. |
-
-**Non-production noindexing**
-
-| Rule ID | Check | Evidence to capture |
-| --- | --- | --- |
-| *(supplementary)* | For each `{NONPROD_ORIGINS}` host: is a site-wide `Disallow: /` in `robots.txt` the *only* suppression signal present — no accompanying noindex header or meta tag? Closely related to `WD-09` below. | The host's `robots.txt` plus presence/absence of a noindex header and meta tag on a sampled route. |
-| `WD-09` | For each `{NONPROD_ORIGINS}` host: does a sampled route serve **both** an `X-Robots-Tag: noindex` response header **and** an HTML `<meta name="robots" content="noindex">` tag, gated by `{ENV_SIGNAL}`? | Response headers and parsed `<head>` for one sampled route per non-prod host. |
-
-**Search-engine registration**
-
-| Rule ID | Check | Evidence to capture |
-| --- | --- | --- |
-| `WD-10` | Query `{DNS_ZONE}` directly (independent of any console) for the domain-ownership verification record this property's registration depends on. Is it present, and does it match the value the registration actually expects? | Raw DNS query result — record type, name, and full current value — captured before any write, per `EV-05`. |
-| `WD-11` | Is a crawl/recrawl notification path (e.g. IndexNow) wired for URLs that change, and has `{SITE_ORIGIN}` been submitted through the webmaster console for each target search engine? | Notification endpoint configuration (if any), and the submission status shown in each webmaster console. |
-| `WD-12` | In the webmaster console of the search engine with the largest share of query volume in the target market, **and** in the console of each engine whose index an AI answer engine draws on (these are frequently different engines), does `{SITE_ORIGIN}` show confirmed index coverage with no outstanding manual-action or coverage blocker? | Each console's own coverage/status readout, copied verbatim, plus its AI-visibility report (citations, grounding queries, or generative-AI impressions) where the console offers one — this is what downstream AI-assistant retrieval actually depends on, not the site's own claim of being indexable. |
-
-## Phase 3 — Propose
-
-Render every `FAIL` from Phase 2 as one line:
-
-```text
-WD-08 FAIL — <what was actually observed, in one sentence>
-  → see web-discoverability-standards.md § non-production noindexing
-```
-
-Group the findings under the same four headings used in Phase 2. For each,
-give the exact remediation: what changes in-repo (Phase 4a) versus what
-requires an outward-facing action (Phase 4b).
-
-End with the full proposed change set and one explicit question:
-
-**"Approve this change set? (yes / edit / cancel)"**
-
-Stop here. Nothing before this point writes anything, with or without
-`--apply`.
-
-## Phase 4a — Apply: in-repo changes
-
-Only with `--apply` **and** after Phase 3 approval. Typical fixes:
-
-- Inject the missing per-route title/description/`og:*`/canonical tags at
-  `{SERVING_LAYER}` (server-rendered or edge-injected — never
-  client-side-only, per `WD-01`).
-- Add or correct `robots.txt` and `sitemap.xml`, and exclude
-  `{RESTRICTED_PREFIX}` from the sitemap.
-- Add the missing noindex header and meta tag for `{NONPROD_ORIGINS}`,
-  gated by `{ENV_SIGNAL}` so production never picks it up by accident.
-- Declare named per-agent `robots.txt` groups so retrieval and training
-  agents are visibly separate and a later edit cannot silently block both
-  (`WD-16`); derive sitemap `lastmod` from content dates (`WD-18`); publish
-  `/llms.txt` and, for documentation routes, a Markdown representation
-  (`WD-12`).
-- Fix the escaping gap found under `WD-13`.
-
-Each fix lands as its own commit, so any one of them can be reverted on its
-own (`git revert`, by commit) without touching the others.
-
-## Phase 4b — Apply: outward-facing actions
-
-Only with `--apply` **and** after Phase 3 approval. Every item here is
-confirmed **individually**, one at a time, with current state printed
-first — never batched:
-
-- **DNS TXT write at `{DNS_ZONE}`.** Print the CURRENT full record
-  verbatim (re-queried live, not from Phase 1's cached inventory). State
-  explicitly that the operation is an ADD/APPEND, never a create-or-replace
-  (`EV-05`). Require the operator to confirm the resulting full record
-  before writing. If the underlying tool only offers a replace operation,
-  refuse and require the operator to make the change manually instead.
-- **Search-engine registration and verification-value entry.** This spell
-  *prepares* the exact value(s) the webmaster console needs and hands them
-  to the operator to enter — it does not attempt to drive the console's UI
-  itself.
-- **Crawl/recrawl instant-notification pings (`WD-11`).** Confirmed once
-  per batch of changed URLs. Never auto-re-fired on a later re-run without
-  a fresh, explicit confirmation for that run.
-
-## Phase 5 — Verify
-
-Cite `EV-01` and `EV-02` explicitly for every check below.
-
-- For every in-repo fix from Phase 4a: re-fetch the actual served response
-  at `{SITE_ORIGIN}` (a fresh request, independent of the deploy that
-  shipped the fix) and compare it against the Phase 3 proposal, allowing a
-  short, bounded propagation window before treating a fresh mismatch as
-  failure (`EV-02`).
-- For the DNS write from Phase 4b: re-query `{DNS_ZONE}` independently
-  (a different resolver path than whatever console performed the write) and
-  compare the full record against what was confirmed.
-- For any console value entered by the operator: re-read it back from the
-  console rather than trusting the entry UI's own confirmation (`EV-01`).
-
-Report each item as `PASS` / `FAIL` / `UNVERIFIED`. An item that could not
-actually be re-checked is `UNVERIFIED` — never silently reported as `PASS`
-just because nothing threw an error.
-
-## Phase 6 — Report
-
-Summarize what changed, what's still open, and close with a plain-language,
-user-verifiable acceptance checklist:
-
-- [ ] A plain fetch (no JavaScript) of three distinct deep routes returns
-      three distinct `<title>` values.
-- [ ] `{SITE_ORIGIN}/robots.txt` and its sitemap both return `200`, and the
-      sitemap contains no `{RESTRICTED_PREFIX}` or `{NONPROD_ORIGINS}` URLs.
-- [ ] Each `{NONPROD_ORIGINS}` host serves both a noindex header and a
-      noindex meta tag on a sampled route.
-- [ ] `{SITE_ORIGIN}/robots.txt` disallows no retrieval-class AI user-agent
-      (`WD-16`), and the sitemap's `lastmod` values are not one shared
-      constant (`WD-18`).
-- [ ] The property's analytics has a dedicated AI-referrer channel and its
-      access log is watched for retrieval-class user-agents (`WD-17`) — so
-      the effect of everything above is measurable rather than assumed.
-- [ ] The DNS verification record at `{DNS_ZONE}`, re-queried
-      independently, matches what the registration expects.
-- [ ] The webmaster console for each target search engine shows the
-      property verified with no outstanding coverage blocker.
-
-## Rules
-
-This spell defers entirely to
-[governance/web-discoverability-standards.md](../../.arcane/governance/web-discoverability-standards.md)
-for what "discoverable" means and why, and to
-[governance/external-verification-standards.md](../../.arcane/governance/external-verification-standards.md)
-for how any claimed fix is verified. Findings and gates in this spell cite
-rule IDs from both; they do not re-explain them. Where the two disagree with
-what this spell says to do, the governance docs win.
-
-## Related
-
-- **Consumes from:** the spell your team uses to ship/deploy a build (in
-  this repository, `spell-ship`). Run `spell-make-discoverable` only after a
-  deploy has put something live at `{SITE_ORIGIN}` — it audits an
-  already-deployed property, it does not deploy one.
-- **Feeds into:** `spell-product-review` — once discoverability fixes are
-  applied and verified, carry the before/after state into the next
-  product-review cycle as one more measured signal.
-- [Web Discoverability Standards](../../.arcane/governance/web-discoverability-standards.md)
-- [External Verification Standards](../../.arcane/governance/external-verification-standards.md)
+This prompt is the Arcane `spell-make-discoverable` spell. Read [`.arcane/spells/spell-make-discoverable.md`](../../.arcane/spells/spell-make-discoverable.md) and follow it as the complete workflow.

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

@@ -6,143 +6,4 @@ argument-hint: Optional --venture <slug> to restrict triage to one venture's boo
 agent: agent
 ---
 
-## Executive Summary
-
-- This prompt is the promotion step of the idea lifecycle: it takes `status: new` entries out of hub-side `IDEAS.md`/`TODO.md` books and lands them where they actually get built — a consumer repo, a tracker, a PRD, or (deliberately, never by accident) a public disclosure.
-- **Hub-gated:** requires `role: "hub"` in `.arcane.json`. Refuses cleanly in a consumer repo.
-- Batch-capable: list entries once, select by number/range, route each (or all identically), execute with one final confirmation — except disclosure, which is never covered by a batch confirmation and always requires its own literal answer.
-- Every downstream write is leak-scanned first: no sibling venture names, no hub paths, no machine names ever land in a consumer artifact.
-- Idempotent: promoted entries are marked in place, so re-running never double-lands the same idea.
-
----
-
-## Step 0 — Hub Gate
-
-Read `.arcane.json`. If `role` is not `"hub"`, stop and report:
-
-> `spell-manifest` runs only in a hub repo (`role: "hub"` in `.arcane.json`). This repo is a consumer — triage its own `IDEAS.md`/`TODO.md` with `spell-todo` (task), `spell-suggest-feature` (tracked story), or `spell-plan` (PRD) instead.
-
-Do not read or list anything further. If `role` is `"hub"`, resolve `{BUSINESS_ROOT}` from `.arcane.json` (default `ventures/`) and load `{BUSINESS_ROOT}/registry.json`. If the registry is missing or fails to parse, stop and report the exact error — never triage blind without knowing the venture list (sibling names come from here, and the leak scan in Step 5 depends on it).
-
-## Step 1 — Collect
-
-Parse `status: new` entries from the hub root `IDEAS.md` and every `{BUSINESS_ROOT}/<slug>/IDEAS.md` / `TODO.md` that exists. If `--venture <slug>` was given, resolve it through the registry's aliases first (exact slug → alias → closest match offered — never guessed; unknown slug lists the closest matches and stops) and restrict collection to that venture's two books plus the hub root.
-
-Tolerate operator YAML frontmatter above a book's header — entries always live below the `---` divider. Malformed entries (missing timestamp, unparseable status comment) are listed under a `Skipped` heading with `file:line`, never silently dropped.
-
-## Step 2 — List
-
-Print one numbered list, grouped by book, oldest entry first within each group. Numbering is session-scoped — it does not persist across runs.
-
-```
-Idea triage — hub books (N books, M new entries)
-
-hub IDEAS.md
-  1. [2026-08-02] [#dx] Portfolio-wide spell usage stats dashboard
-ventures/ordovica/IDEAS.md
-  2. [2026-07-30] [#ui] Dark-mode toggle for event pages
-ventures/ordovica/TODO.md
-  3. [ ] Confirm cart snapshot order (open item, no status comment — todo-book entries are listed as-is)
-```
-
-## Step 3 — Select
-
-Ask: `Promote which? (numbers/ranges, e.g. 1,3,5-8, or "all")`. Accept a single answer covering the whole batch. `all` selects every listed entry, including ones in books outside `--venture` if no filter was given.
-
-## Step 4 — Route (per entry)
-
-For each selected entry, in list order, resolve the venture it belongs to (`hub` for root-book entries) and offer destinations. The menu depends on that venture's registry entry:
-
-| # | Destination | Requires | What lands |
-| --- | --- | --- | --- |
-| a | Consumer repo-root `IDEAS.md` | a registered clone on this machine | New entry, `status: new`, fresh timestamp |
-| b | PRD scaffold in consumer `features/<slug>/PRD.md` | a registered clone | spell-plan-style stub: Problem Statement = idea text; tracking frontmatter from that repo's own `.arcane.json`; open question noting no work-item ID exists yet |
-| c | Tracker item | venture `tracking != "none"` | ADO: resolve process template + work item type, `az boards work-item create`. GitHub: `gh issue create --repo <owner>/<repo>`. Works without a local clone. |
-| d | Public disclosure to that repo's `IDEAS.md` | a registered clone, destination `visibility: "public"` | Same as (a) — but gated by Step 5's disclosure confirm, always |
-| e | Demote to a TODO book | — | Venture's own `TODO.md` (or hub root `TODO.md` for hub-book entries), as a `- [ ]` line |
-| f | Drop | — | Nothing lands |
-| g | Cross-copy to another venture's book | target venture exists in registry | Fresh `status: new` entry appended to that venture's book |
-
-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 — 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
-
-Any destination whose repo has `visibility: "public"` — (a) or (d) landing in a public repo, or (c) filing a tracker item in a public tracker (a GitHub issue on a public repo is exactly as much a disclosure as its `IDEAS.md`) — is a disclosure, never covered by `all`, `go`, or any other batch confirmation. Per entry, print the **exact text** that will become public and ask for the literal word `disclose`. Anything else skips that one entry (it stays `status: new`) without aborting the rest of the batch.
-
-On a repo's first-ever disclosure (its `IDEAS.md` has no existing entries with a `promoted → public:` marker), offer to add this boundary statement to that file's header in the same staged change:
-
-> Build-in-public covers source, decisions, and the accepted roadmap; idea incubation is curated and lands here when committed.
-
-## Step 6 — Execute
-
-Per entry, in list order: **land downstream first, mark the hub entry after.** Before writing anything to a consumer repo, run the leak scan (Step 7) on the outbound text; a hit blocks that entry and asks for an operator rewrite rather than writing leaked content. After a successful downstream write, mark the hub entry:
-
-```
-<!-- status: promoted → <dest> YYYY-MM-DD -->
-```
-
-where `<dest>` is one of:
-
-```
-repo:<slug>/IDEAS.md
-prd:<slug>/features/<feature-slug>
-ado:<slug>#<id>
-github:<slug>#<id>                    (append " (disclosed)" if the repo is public)
-public:<slug>/IDEAS.md (disclosed)
-hub:TODO.md
-book:<other-slug>/IDEAS.md
-```
-
-Dropped entries get `<!-- status: dropped YYYY-MM-DD -->`, optionally with a trailing `(reason)`.
-
-Before any downstream write, grep the target file for the entry's normalized first ~40 characters — if already present, treat this entry as already-landed, mark the hub entry promoted, and skip the write. This is what makes an interrupted or re-run batch safe.
-
-## Step 7 — Leak Scan
-
-Before writing outbound text to any consumer or public destination, scan it for:
-
-- Every other venture's slug and aliases from the registry (never the destination's own)
-- Hub path fragments (`{BUSINESS_ROOT}` paths, this repo's own root-relative paths)
-- Machine names (the `clones` keys across the registry)
-- This repo's org-token denylist, if `.arcane.json`/config defines one
-
-A hit blocks the write and reports exactly what matched; offer the operator a rewrite or `keep in book` (leave the entry `status: new`, untouched). This scan is only possible hub-side, because only the hub holds the full sibling list — that asymmetry is deliberate, not a gap: a consumer repo could never run this check on itself without first being handed the very list it must never see.
-
-## Step 8 — Report
-
-Stage (never commit) the touched files in each repo that received a write, including this hub repo. Print one proposed commit message per repo:
-
-```
-Staged (not committed):
-  hub:            ventures/ordovica/IDEAS.md
-                  proposed: docs(ideas): promote 1 entry to ordovica
-  ordovica:       IDEAS.md
-                  proposed: docs(ideas): capture dark-mode toggle candidate
-Run spell-commit-work in each repo. N entries remain new.
-```
-
-## Rules
-
-- Never run outside a hub repo. Never infer hub status.
-- Never let `all` or the plan-confirm authorize a disclosure — that confirmation is always separate, always per-entry, always the literal word `disclose`.
-- Never write a sibling venture's slug, a hub path, or a machine name into a consumer or public artifact — the leak scan is mandatory, not advisory.
-- Never commit. Stage and report; hand off to `spell-commit-work`.
-- Never guess a venture from partial input — resolve through the registry's aliases or ask.
-- Land downstream before marking the hub entry promoted, so an interrupted batch never loses track of what actually shipped.
+This prompt is the Arcane `spell-manifest` spell. Read [`.arcane/spells/spell-manifest.md`](../../.arcane/spells/spell-manifest.md) and follow it as the complete workflow.

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

@@ -6,149 +6,4 @@ argument-hint: Optional focus area (e.g., security hardening, a specific feature
 agent: agent
 ---
 
-## Executive Summary
-
-- This prompt opens a new session after chat reset by reading core docs and identifying unfinished work.
-- It produces a state snapshot, top priorities, and concrete next actions to minimize startup friction.
-- Use this when opening work in a new chat session to avoid re-reading full context manually.
-- Optional focus argument narrows scope to a specific domain (security, business, infrastructure).
-
----
-
-Open work in this repository after context reset. Treat repository documents as source of truth. See [[README]] and [[CLAUDE]] for repo orientation.
-
-If the user provided a focus area in the prompt argument, prioritize that area. Otherwise perform a general session-opening pass.
-
-Use these files first:
-
-- [README.md](../../README.md)
-- [project.md](../../project.md)
-- [TODO.md](../../TODO.md)
-- [DECISIONS.md](../../DECISIONS.md)
-- [naming-conventions.md](../../.arcane/governance/naming-conventions.md)
-- [ai-context/system-prompt-context.md](../../ai-context/system-prompt-context.md)
-- [agents/agent-policies.md](../../.arcane/governance/agent-policies.md)
-- Most recent journal file(s) in [journal/](../../journal/)
-- Relevant business overview(s) under `{BUSINESS_ROOT}/` (resolve from `.arcane.json`'s `business_root` field, default `ventures/` if unset)
-
-**Handoff Detection (run before anything else):**
-
-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 — 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, 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` item — by stable locator, not a line number that may have already drifted — 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)
-
-Do not create a branch during a read-only session. Immediately before the first file edit, generated file, staging action, or other repository mutation, classify the current Git/remote state and apply exactly one path:
-
-| Observed state                                                        | Required action before mutation                                                                                                                                           |
-| --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Supported, authenticated GitHub/ADO remote + trunk checked out        | Create and switch the **current worktree only** to `sessions/YYYY-MM-DD-<topic-slug>`, derived deterministically from the focus, handoff active task, or top next action. |
-| Already on a compliant `sessions/YYYY-MM-DD-<topic-slug>` branch      | Stay on it; do not create or switch branches.                                                                                                                             |
-| Noncompliant unpushed branch with no active PR                        | Rename it to the deterministic session name before mutation.                                                                                                              |
-| Branch has an active PR                                               | Stay on the PR branch and report it; never rename a branch backing an active PR.                                                                                          |
-| Current path is a linked worktree                                     | Mutate/switch only the current worktree. Never switch or delete a branch attached to another worktree.                                                                    |
-| No remote, unsupported remote, or provider authentication unavailable | Stay on the repository trunk. Print `Local-only session: no usable remote merge path; mutations remain on <trunk> and close-session must use its local-only path.`        |
-
-A usable merge path requires a configured remote on a supported provider (`github.com`, `dev.azure.com`, or `visualstudio.com`) and authenticated provider tooling. A remote URL alone is insufficient. Re-evaluate immediately before the first mutation so a remote added or removed during the read-only portion is handled from observed state.
-
-If branch creation/rename is required, complete it before writing the handoff consumed marker or any other file. If the guard cannot determine the current worktree, active-PR state, or merge capability, fail closed without mutation and ask for operator direction.
-
-**Drift Check (run before deep context gathering):**
-
-Run the `spell-check-drift` spell first, before building the state snapshot or gathering deep context. Drift compounds the longer a session runs, so catch it early.
-
-- If **HIGH** drift is found: list it under the `## Risks And Gaps` output section and ask the user whether to fix it before proceeding. Do not continue deep context gathering until they decide.
-- If **MEDIUM** or **LOW** drift is found: note it and suggest deferring it until after the session-opening pass.
-- If no drift is found: note `drift check passed` and continue.
-
-Then produce output in this exact structure:
-
-## Workspace Health Check
-
-Before anything else, check:
-
-- **Current branch:** Run `git branch --show-current` and `git worktree list`. Report the current state; do not switch during this read-only check. Branch creation/switching is owned by the lazy Mutation Guard. **Caveat (EF-33):** if this repository or its linked worktrees might be reached through more than one filesystem view (a bridged/remote mount, a container bind-mount), `git worktree list` can truthfully report a live, healthy worktree as `prunable` when read from a vantage point that can't resolve its registered path — this is a read-only report, not a reason to act; never run a destructive worktree/branch command on its output alone (see git-conventions.md's Same-Vantage-Point Check section before any such command elsewhere in this or later sessions).
-- **Isolation primitive (ARC-028 R1–R5):** name where this session will run *before* the Mutation Guard creates anything, and state it in the session output. Every unit of work lives in exactly one of three primitives — the **primary checkout**, a **linked worktree**, or a **full clone**. Select from what the previous bullet's `git worktree list` and `git status` already showed, in this order:
-  - **Managing repository state** — reconciling uncommitted files, pruning branches, fast-forwarding `main`, cutting a release, or any `git worktree` lifecycle operation → **primary checkout** (R1). These are the only operations that require holding `main`, and only one working tree can.
-  - **The primary checkout is occupied** — another session's branch is checked out there, or it holds uncommitted work that is not yours → **linked worktree** (R3). At most one actor occupies the primary checkout at a time. Create it with `git worktree add <path> -b <session-branch>`; never switch or delete a branch attached to a worktree you are not in.
-  - **Unattended/automated git operations** (cron, daemon fleets, anything pulling or pushing without a human present) → **full clone** (R5). Linked worktrees share one physical `.git`, so concurrent unattended operations contend on the same locks.
-  - **Otherwise** → **primary checkout on a session branch** (R2). This is the default and it is deliberately the do-nothing path: one actor, one checkout, no new tooling.
-  - **Footprint overlap overrides the choice (R4).** If this session's work touches the same files or the same shared sequence (migration numbers, generated indexes, lockfiles) as work already running in another primitive, do **not** isolate it — serialize instead: wait, or re-scope to a disjoint footprint first. Isolation does not prevent those collisions, it hides them until merge review.
-  - Working in a linked worktree changes two things later in the session and nothing else: `spell-close-session` must not check out `main` (see git-conventions.md's Post-Merge Cleanup section), and the worktree contains no untracked tooling state — budget for `npm install` or equivalent in a code repo. Branch naming, attribution, and the PR gate are identical from every primitive (R8).
-- **Session branch naming compliance:** Branch names must be human-readable and policy-compliant:
-  - Interactive session default: `sessions/YYYY-MM-DD-<topic-slug>` (kebab-case topic from current task/session objective).
-  - Disallow random adjective-noun generator names (example: `ideal-disco`) as session defaults.
-  - If current branch is non-compliant and no active PR depends on it, record the required rename for the Mutation Guard. Do not rename during a read-only session.
-  - If an active PR uses the old branch name, do not force-delete the old remote branch; flag it and continue with a follow-up rename plan.
-- **Stale local branches:** Run `git branch --merged main` to list branches already merged that should be deleted — this session's own read-only candidate list (`--merged` also misses every branch landed via this repo's sanctioned rebase-and-fast-forward, so treat a *clean* result as "no ancestry-visible candidates," not "nothing to check"). Open-session only lists; it does not delete. Apply the [Content-Verified Branch Deletion](../../.arcane/governance/git-conventions.md#content-verified-branch-deletion-todomd-merged-branch-cleanup-finding) procedure (git-conventions.md) to any candidate before flagging it as safe, and leave the actual idempotent prune to `spell-close-session`'s sweep.
-- **Tracker configuration check (early):** resolve active tracking settings before planning, in this order: root `.arcane.json` (if present) -> the committed self-hosted source manifest (`src/assets/.arcane.json`, read only when it declares `selfHosted: true` -- this is EF-14's recorded self-hosting resolution tier, distinct from treating the mere presence of a self-host marker as license to infer other, unrelated config) -> the current feature PRD frontmatter -> ask. Persisted once at `spell init`/`spell update` (EF-14); do not re-ask when any of the first three sources already sets it.
-  <!-- fragment:tracking-mode-declaration:start -->
-  - `tracking_mode: internal | external`
-  - `external_provider: ado | github | jira | other`
-  <!-- fragment:tracking-mode-declaration:end -->
-  - If all three sources are absent, ask: "Track work in this repo (TODO.md / PRDs)" [internal] vs "Track work in an external tracker (Azure DevOps / GitHub / Jira / other)" [external]. Default to `external` + `ado` only when existing ADO context already exists (backward compatibility).
-- **Open PRs (external/ado mode only):** if tracking mode is `external` with provider `ado` and ADO MCP is available, list all open PRs across all repos in the configured repo list (resolve from `.arcane.json`; if unset, ask the operator which repos to scan). Flag PRs older than 3 days as stale, older than 7 days as overdue. Format each as a clickable markdown link: `[PR #{id} — {title}](https://dev.azure.com/{ADO_ORG}/{ADO_PROJECT}/_git/{repo}/pullrequest/{id})` — resolve `{ADO_ORG}` and `{ADO_PROJECT}` from `.arcane.json` / PRD frontmatter; ask if unset. Never list a bare `PR #NNN`.
-- **Uncommitted changes:** Run `git status` and report any uncommitted files.
-- **Arcane version check (two-axis):** If `.arcane.json` exists in the repo root, check both whether the repo's managed files are behind the installed CLI _and_ whether the installed CLI is behind the latest published version of `arcane-cli`:
-  - Read the installed version from `.arcane.json` (field: `arcaneVersion` or `version`).
-  - Determine the version of the installed `arcane-cli` CLI (for example, `npx arcane-cli --version`, or the locally installed package version).
-  - Run `npm view arcane-cli version` to get the latest published version.
-  - **(a) Managed files behind the installed CLI** (installed CLI version is newer than the version recorded in `.arcane.json`): surface a warning: `⚠️ Managed files out of date: files at <installed> → CLI at <cli>. Run spell update to resync files.`
-  - **(b) Installed CLI behind the latest published version** (latest published is newer than the installed CLI): surface a warning: `⚠️ Arcane CLI update available: CLI at <cli> → latest <latest>. Upgrade the CLI, then run spell update.`
-  - **If either axis shows drift, emit the canonical version-drift diagram beside the warning(s)** — per the generated state diagrams convention (rule 8, ARC-036). One commit per *distinct* version value among the three readings, in the order repo-files → installed-CLI → npm-latest; collapse consecutive identical values into a single shared commit rather than repeating it. Branch off immediately after the commit for each axis that drifts — `repo-files` after the repo-files-version commit if axis A drifts, `installed-cli` after the installed-CLI-version commit if axis B drifts. Tag the final commit `"latest"`. The dangling branch(es) *are* the drifting axis/axes — no legend needed:
-    ```mermaid
-    gitGraph
-       commit id: "<repo-files version>"
-       branch repo-files
-       checkout main
-       commit id: "<installed-CLI version>"
-       branch installed-cli
-       checkout main
-       commit id: "<npm-latest version>" tag: "latest"
-    ```
-    (Shown here with both axes drifting — omit whichever `branch`/`checkout` pair belongs to a non-drifting axis, and collapse its commit into its neighbor's if the values are equal.) Use `:::mermaid` fencing instead of ` ```mermaid ` when the output surface is an Azure DevOps wiki — resolve `external_provider` from `.arcane.json` rather than assuming, the same as every other tracker-conditional step in this file; note for bare terminals that the fenced source is still readable without a renderer.
-  - If both axes are current, report current and continue — no diagram (the applicability guard: a single, matching reading has nothing to visualize).
-  - If no `.arcane.json` exists, skip silently.
-
-## State Snapshot
-
-- Short bullets by area: security, infrastructure, `{PRIMARY_VENTURE}` readiness, business readiness, and documentation maturity. Resolve `{PRIMARY_VENTURE}` from `.arcane.json` / venture frontmatter; if unset, substitute the active focus area (or omit that bullet).
-
-## Top Unfinished Work
-
-- Prioritized list with severity labels: Critical, High, Medium.
-- Every item must include a file reference.
-
-## Next Session Plan
-
-- 3 to 5 concrete actions to execute now.
-- Keep actions specific and immediately executable.
-- If moving from one completed epic to the next, include an explicit checkpoint action to run `spell-commit-work` first.
-
-## Suggested Session Name
-
-- **Required output field.**
-- Provide a 1–4 word, sentence-case, human-meaningful session name.
-- If a focus/task argument is provided, generate the name deterministically from that focus (never use the generic name `Open session`).
-- If no focus argument is provided, generate the name from the top recommended action in `## Next Session Plan`.
-- Optional helper line: `Branch helper: sessions/YYYY-MM-DD-<kebab-case-slug>`.
-
-## Risks And Gaps
-
-- Contradictions, stale assumptions, missing files, or draft documents that block progress.
-
-## Clarifications Needed
-
-- Up to 3 short questions only if they materially change priorities.
-
-Rules:
-
-- Prefer facts from docs over assumptions.
-- Keep output concise but actionable.
-- Include clickable file paths for claims.
-- If you find outdated statements (for example, docs that contradict the current state of the system), call them out explicitly as drift.
-- Never return a generic session name like `Open session` when a meaningful alternative can be derived from focus or the top next action.
+This prompt is the Arcane `spell-open-session` spell. Read [`.arcane/spells/spell-open-session.md`](../../.arcane/spells/spell-open-session.md) and follow it as the complete workflow.