@nurix/etna 0.18.0 → 0.18.2

package/data/harnesses/kb-agi/CLAUDE.md

@@ -16,8 +16,8 @@ If `meta/guidance.md` is missing, this vault isn't initialized — invoke the **
 
 Before answering anything, run a short interview with the `AskUserQuestion` tool to establish two things:
 
-1. **What brings you?** → *ask* (you have a question) or *contribute* (you have something to add).
-2. **Your user-type (genre):** → *Sales*, *PM*, or *Contributor*. This sets the default depth and framing of answers, nothing else. (If none fits, let them say so — a missing genre just means use plain working depth.)
+1. **What brings you?** → _ask_ (you have a question) or _contribute_ (you have something to add).
+2. **Your user-type (genre):** → _Sales_, _PM_, or _Contributor_. This sets the default depth and framing of answers, nothing else. (If none fits, let them say so — a missing genre just means use plain working depth.)
 
 Then load the matching template from [`meta/genre/`](meta/genre/) — `sales.md`, `pm.md`, or `contributor.md` — and follow the path below.
 
@@ -29,17 +29,17 @@ Keep the interview to those two questions. Don't re-interview on every follow-up
 
 You are **read-only** on this path. You never edit a note. Your only write is appending a query log to `meta/sessions/` (see below).
 
-1. **Find the entry note(s)** for the question. Start from [`meta/intent-index.md`](meta/intent-index.md) (keyed by *what the user wants to do*) and the entry notes named in their genre template.
-2. **Traverse the note graph both ways** — *up* toward summaries and entry notes, *down* into detail and evidence. The `[[wikilinks]]` are the structure. Lead with `canonical` notes; treat `canonical: false` ones as background.
+1. **Find the entry note(s)** for the question. Start from [`meta/intent-index.md`](meta/intent-index.md) (keyed by _what the user wants to do_) and the entry notes named in their genre template.
+2. **Traverse the note graph both ways** — _up_ toward summaries and entry notes, _down_ into detail and evidence. The `[[wikilinks]]` are the structure. Lead with `canonical` notes; treat `canonical: false` ones as background.
 3. **Synthesize at the genre's default depth**, then adjust to how the question was actually asked — go deeper when they reach for it, compress when they want the headline. Depth shapes the answer; it never hides notes.
 4. **Cite the notes you used** so the user can stand behind the answer and follow the links.
-5. **Log the session** to `meta/sessions/` in the format in that folder's README — including, honestly, whether you could fully answer. A question you *couldn't* answer is a gap; logging it feeds the gap-finder and lets the user resume later.
+5. **Log the session** to `meta/sessions/` in the format in that folder's README — including, honestly, whether you could fully answer. A question you _couldn't_ answer is a gap; logging it feeds the gap-finder and lets the user resume later.
 
 If the vault can't answer, say so plainly and log it as a gap. Don't invent an answer the notes don't support.
 
 ## The contribute path — the human steers
 
-Here the user is *adding* knowledge, not reading. This path is deliberately thin and grows with use. There are **no sub-agents** — it's you and the user in a normal session.
+Here the user is _adding_ knowledge, not reading. This path is deliberately thin and grows with use. There are **no sub-agents** — it's you and the user in a normal session.
 
 1. **Orient them** with [`meta/guidance.md`](meta/guidance.md) (the note model and where things belong) and the target folder's `metadata.md` (what belongs there, what's already nearby).
 2. **What does the hub want next?** Run the `kb-find-gaps` agent (it reads `meta/sessions/` gaps + folder `metadata.md`) — that's the live content roadmap.
@@ -48,9 +48,9 @@ Here the user is *adding* knowledge, not reading. This path is deliberately thin
 
 ---
 
-## What you do *not* do
+## What you do _not_ do
 
-- **You don't run upkeep.** The kb-agi upkeep agents (`kb-find-gaps`, `kb-sync-metadata`, `kb-catch-stale`, `kb-fix-links`, `kb-refresh-frontdoor`, `kb-refresh-summaries`) are the only writers of canon, invoked by name and only when *deliberately* run — not as a side effect of a question. Don't trigger them from the ask path.
+- **You don't run upkeep.** The kb-agi upkeep agents (`kb-find-gaps`, `kb-sync-metadata`, `kb-catch-stale`, `kb-fix-links`, `kb-refresh-frontdoor`, `kb-refresh-summaries`) are the only writers of canon, invoked by name and only when _deliberately_ run — not as a side effect of a question. Don't trigger them from the ask path.
 - **You don't hand-edit `meta/_kg/`** — it's a derived graph, regenerated from the notes.
 - **You don't mutate notes on the ask path.** Read-only means read-only.
 

package/data/harnesses/kb-agi/agents/kb-agi-init.md

@@ -39,7 +39,7 @@ meta/
 
 # Templates
 
-Each block below is one file. The fences are 4-backtick (````` ```` `````) so the 3-backtick blocks inside the templates are preserved — strip the outer fence when you write the file.
+Each block below is one file. The fences are 4-backtick (` ```` `) so the 3-backtick blocks inside the templates are preserved — strip the outer fence when you write the file.
 
 ## `meta/guidance.md`
 
@@ -48,7 +48,7 @@ Each block below is one file. The fences are 4-backtick (````` ```` `````) so th
 
 This file is the single contract the router (`CLAUDE.md`) and the upkeep agents both read. It defines what a note is, what the light frontmatter hints mean, how a folder describes itself, and who is allowed to write. When any of those agents needs a rule, the rule lives here.
 
-Everything in this file is a *hint or a convention*, not a schema enforced by code. Notes that omit a hint still work; the system degrades gracefully.
+Everything in this file is a _hint or a convention_, not a schema enforced by code. Notes that omit a hint still work; the system degrades gracefully.
 
 ---
 
@@ -56,7 +56,7 @@ Everything in this file is a *hint or a convention*, not a schema enforced by co
 
 The vault is one flat Obsidian vault. Every note is the same kind of thing — a markdown note linked to other notes by `[[wikilinks]]`. There is **no per-document type label** and no altitude. Folders exist for human convenience; each folder says what it holds via a `metadata.md`.
 
-- **One idea per note.** Push deeper material into a *linked* note rather than bloating one note. The links carry the depth.
+- **One idea per note.** Push deeper material into a _linked_ note rather than bloating one note. The links carry the depth.
 - **Links are the structure.** The note-link graph is the one graph. It is derived from the notes — the renderer (`docs-template`) builds it into `meta/_kg/` — never hand-maintained.
 - **Notes are the only canon.** Everything under `meta/` is control plane, not knowledge. The graph and any index are regenerable derivatives of the notes.
 
@@ -68,10 +68,10 @@ A note carries light frontmatter. All fields are optional; treat a missing field
 
 ```yaml
 ---
-title: Human-readable title          # defaults to the H1 / filename
-maturity: synthesized                # see ladder below — default: captured
-canonical: true                      # is this THE note on its topic? default: true
-visibility: public                   # public | hidden — default: public
+title: Human-readable title # defaults to the H1 / filename
+maturity: synthesized # see ladder below — default: captured
+canonical: true # is this THE note on its topic? default: true
+visibility: public # public | hidden — default: public
 ---
 ```
 
@@ -80,7 +80,7 @@ visibility: public                   # public | hidden — default: public
 How finished the thinking is. Shapes how the ask path frames an answer, never whether a note is shown.
 
 | value | meaning |
-|---|---|
+| --- | --- |
 | `raw` | dumped in, unprocessed — a capture, a transcript, a paste |
 | `captured` | cleaned up, readable, but not yet reconciled with neighbours |
 | `synthesized` | reconciled into the vault's point of view, linked to its neighbours |
@@ -129,14 +129,14 @@ This is doctrine P3, restated as the contract:
 
 ## genre — the reader, not the document
 
-`genre` is the **user-type** of whoever is asking (Sales, PM, Contributor), established by the opening interview in `CLAUDE.md`. It is a label on the *reader*, never on a note. Its only effect is to set the **default depth and framing** of an answer — see `meta/genre/`. It never changes which notes exist or which are reachable.
+`genre` is the **user-type** of whoever is asking (Sales, PM, Contributor), established by the opening interview in `CLAUDE.md`. It is a label on the _reader_, never on a note. Its only effect is to set the **default depth and framing** of an answer — see `meta/genre/`. It never changes which notes exist or which are reachable.
 
 ---
 
 ## The rest of the control plane
 
 | path | what it is |
-|---|---|
+| --- | --- |
 | `meta/genre/` | user-type templates — default depth + entry points per reader |
 | `meta/intent-index.md` | "Read by need" — intent-keyed entry points into the vault |
 | `meta/sessions/` | query logs — every ask, and whether it could be answered |
@@ -147,7 +147,7 @@ Upkeep is run by the kb-agi agents (invoked by name); there is no `meta/goals/`
 
 ## `meta/genre/sales.md`
 
-````markdown
+```markdown
 # genre — Sales
 
 The reader is positioning NuStack to someone else: a prospect, a partner, a teammate who needs the pitch. They want the claim and the proof behind it, not the implementation.
@@ -157,15 +157,16 @@ The reader is positioning NuStack to someone else: a prospect, a partner, a team
 **Framing.** Outcomes and differentiators over mechanism. Speak in capabilities and claims. When a claim has proof in the vault, cite the note so the reader can stand behind it. Flag honestly when something is aspiration rather than shipped — a claim the vault can't back is a gap, not an answer.
 
 **Start from.**
+
 - `meta/intent-index.md` → the "understand the product / what can it do" lanes
 - positioning, claims, and capability notes (lead with `canonical`, `published` ones)
 
 **Adjust.** If the reader keeps asking "how", hand them off toward the PM depth — follow the links down into the specs. If they want it shorter, compress to the headline claim plus one citation.
-````
+```
 
 ## `meta/genre/pm.md`
 
-````markdown
+```markdown
 # genre — PM
 
 The reader is shaping or building the product: a PM, designer, or engineer who needs scope, tradeoffs, and the state of a decision. They want the mechanism and the reasoning, not just the claim.
@@ -175,34 +176,36 @@ The reader is shaping or building the product: a PM, designer, or engineer who n
 **Framing.** Scope, contracts, and decisions. Distinguish what's shipped, what's specced, and what's still open. Surface the tension behind a choice, not just the choice. When the answer rests on a decision, cite the note that records it so the reader sees the why.
 
 **Start from.**
+
 - `meta/intent-index.md` → the "build / extend / model / runtime concern" lanes
 - spec, decision, and build-plan notes; the architecture notes that set the target
 
 **Adjust.** If the reader is scoping, summarize across notes and name the open questions. If they're implementing, go deep into the one note and its neighbours. If they ask "why this and not X", traverse to the decision and rejected-alternative notes.
-````
+```
 
 ## `meta/genre/contributor.md`
 
-````markdown
+```markdown
 # genre — Contributor
 
-The reader is here to *add* knowledge, not consume it. They have something the vault doesn't yet hold — a finding, a decision, a correction — and they want to land it where it belongs.
+The reader is here to _add_ knowledge, not consume it. They have something the vault doesn't yet hold — a finding, a decision, a correction — and they want to land it where it belongs.
 
 **Default depth.** Orientation over synthesis. Show them where a note belongs, what's already nearby, and the convention to follow — then get out of the way and let them write. This genre usually means the **contribute path**, where the human steers Claude like a normal session to draft and place notes.
 
 **Framing.** Placement and convention. The questions that matter here: which folder does this belong in, what does its `metadata.md` say it should hold, what existing notes should it link to, is there already a canonical note on this topic. Links form naturally as the note is written.
 
 **Start from.**
+
 - the `kb-find-gaps` agent + `meta/sessions/` gap-logs — what the hub is missing / wants next
 - `meta/guidance.md` — the note model, frontmatter hints, and folder `metadata.md` shape
 - the target folder's `metadata.md` — what belongs there and what's missing
 
-**Adjust.** This path is deliberately thin and grows with use. No sub-agents — it's the human and Claude in a normal session. If the contributor instead wants to *read* before adding, switch to the Sales or PM framing.
-````
+**Adjust.** This path is deliberately thin and grows with use. No sub-agents — it's the human and Claude in a normal session. If the contributor instead wants to _read_ before adding, switch to the Sales or PM framing.
+```
 
 ## `meta/intent-index.md`
 
-````markdown
+```markdown
 # intent-index — Read by need
 
 The front door to the vault, keyed on **what you're trying to do**, not who you are (doctrine P4). The router and the genre templates point here; each lane lists the entry notes to start from, and the links carry you the rest of the way.
@@ -212,43 +215,49 @@ This is a living index. It is hand-maintained today and kept fresh by the `kb-re
 ---
 
 ## "I want to understand the product"
+
 _What NuStack is, what it can do, the claims and their proof._
 
 - _populated on migration_
 
 ## "I want to start building"
+
 _Where to begin, how the pieces fit, the build sequence._
 
 - _populated on migration_
 
 ## "I want to extend a capability"
+
 _How to add to the catalog — a node, a connector, an integration._
 
 - _populated on migration_
 
 ## "I want to understand a runtime concern"
+
 _Execution, streaming, observability — how it behaves when it runs._
 
 - _populated on migration_
 
 ## "I want to model data"
+
 _The schema, the entities, the contracts they speak._
 
 - _populated on migration_
 
 ## "I want to add knowledge"
+
 _You have something the vault doesn't hold yet._
 
 - run `kb-find-gaps` (or read `meta/sessions/` gap-logs) — what the hub is missing
 - `meta/guidance.md` — the note model and where things belong
-````
+```
 
 ## `meta/sessions/README.md`
 
 ````markdown
 # sessions — query logs
 
-Every ask the router handles is logged here. A log entry does double duty: it lets a reader resume a reattempt instead of starting cold, and a question the vault *couldn't* answer is a gap — the content roadmap the `kb-find-gaps` agent reads.
+Every ask the router handles is logged here. A log entry does double duty: it lets a reader resume a reattempt instead of starting cold, and a question the vault _couldn't_ answer is a gap — the content roadmap the `kb-find-gaps` agent reads.
 
 This is the one thing the read-only ask path writes (doctrine P3). It never touches a note.
 
@@ -260,7 +269,7 @@ One file per session, named `YYYY-MM-DD-short-slug.md`:
 ---
 date: 2026-05-24
 genre: pm
-answered: partial        # yes | partial | no
+answered: partial # yes | partial | no
 ---
 
 ## Q: <the question, in the asker's words>

package/data/harnesses/kb-agi/agents/kb-catch-stale.md

@@ -12,7 +12,7 @@ You are the **kb-catch-stale** goal-agent for the NuStack knowledge hub. One job
 ## Procedure
 
 1. Group notes by topic (shared `[[wikilinks]]`, near-identical titles). Flag any topic carrying more than one `canonical: true` note — one has likely superseded another without being demoted.
-2. For each `synthesized`/`published` note, use `git log` to compare its last-commit date against the `raw`/`captured` notes it links *down* to. Flag summaries older than their sources.
+2. For each `synthesized`/`published` note, use `git log` to compare its last-commit date against the `raw`/`captured` notes it links _down_ to. Flag summaries older than their sources.
 3. Emit a ranked list: each suspect note, why (duplicate-canonical or behind-source), and the rival or changed source.
 
 ## Write rules (doctrine P3)

package/data/harnesses/kb-agi/agents/kb-find-gaps.md

@@ -13,7 +13,7 @@ Before anything else, read `meta/guidance.md` — the note model, the frontmatte
 
 ## Procedure
 
-1. **Read every content folder's `metadata.md`** and list what each says it *should contain*.
+1. **Read every content folder's `metadata.md`** and list what each says it _should contain_.
 2. **Diff against the note graph** (`meta/_kg/`, or by globbing the notes and scanning `[[wikilinks]]` if the graph isn't built yet). For each "should contain" item, find whether a `canonical` note covers it. Record what's absent, what's thin (a stub with no links down), and what's orphaned (no links in).
 3. **Fold in session gaps** — read `meta/sessions/` and pull entries with `answered: no | partial`. Each `Gap.` line is a hole a real reader hit. Rank these highest.
 4. **Emit a ranked gap list.** For each gap: the folder it belongs in, what it should cover, why it's a gap (metadata expectation, session miss, or both), and the neighbouring notes it would link to.

package/data/harnesses/kb-agi/agents/kb-fix-links.md

@@ -18,5 +18,5 @@ You are the **kb-fix-links** goal-agent for the NuStack knowledge hub. One job:
 ## Write rules (doctrine P3)
 
 - **Default: write nothing.** Output the two lists.
-- **On request only:** fix a dead link when the intended target is *unambiguous* (an exact rename), and add a link from a sensible neighbour to an orphan. Leave ambiguous cases in the report for a human.
+- **On request only:** fix a dead link when the intended target is _unambiguous_ (an exact rename), and add a link from a sensible neighbour to an orphan. Leave ambiguous cases in the report for a human.
 - Every write is a git commit. Stay in your lane: you mend the plumbing, you don't rewrite note content or judge freshness.

package/data/harnesses/kb-agi/agents/kb-refresh-summaries.md

@@ -11,12 +11,12 @@ You are the **kb-refresh-summaries** goal-agent for the NuStack knowledge hub. O
 
 ## Procedure
 
-1. For each `synthesized`/`published` note, gather the `raw`/`captured` notes it links *down* to.
+1. For each `synthesized`/`published` note, gather the `raw`/`captured` notes it links _down_ to.
 2. Use `git log` to flag summaries whose sources changed more recently than the summary itself — the summary is behind.
 3. Emit the list: which summary, which new/changed sources it hasn't absorbed.
 
 ## Write rules (doctrine P3)
 
 - **Default: write nothing.** Output the behind-summaries list.
-- **On request only:** draft the refresh *into the summary note* — fold the new source material in, one idea per note, push overflow into a new linked note rather than bloating. Never invent a summary that doesn't exist (that's the `kb-find-gaps` agent).
+- **On request only:** draft the refresh _into the summary note_ — fold the new source material in, one idea per note, push overflow into a new linked note rather than bloating. Never invent a summary that doesn't exist (that's the `kb-find-gaps` agent).
 - Every write is a git commit. Stay in your lane: you keep existing summaries current, nothing else.

package/data/harnesses/kb-agi/agents/kb-sync-metadata.md

@@ -9,14 +9,14 @@ You are the **kb-sync-metadata** goal-agent for the NuStack knowledge hub. One j
 
 **Read first:** `meta/guidance.md` (the note model + the fixed `metadata.md` shape) — the contract that governs you. The procedure below is this agent's full, self-contained definition.
 
-This is the upkeep that `kb-find-gaps` depends on: it reads `metadata.md` to know what a folder *should contain*. You keep that description truthful. You never invent missing content — that's the `kb-find-gaps` agent.
+This is the upkeep that `kb-find-gaps` depends on: it reads `metadata.md` to know what a folder _should contain_. You keep that description truthful. You never invent missing content — that's the `kb-find-gaps` agent.
 
 ## Procedure
 
 1. For each content folder, read its `metadata.md` and the notes actually in the folder.
 2. Check: **Entry notes** still exist and are `canonical`; **Neighbours** match where the folder's notes really link (use the graph); the **About / Should-contain** still fit what's there.
 3. Emit per-folder drift: dead entry-note pointers, wrong/missing neighbours, an About line that no longer describes the folder.
-4. A "this folder lacks a note on X" finding is a *content gap* — route it to `kb-find-gaps`, don't act on it here.
+4. A "this folder lacks a note on X" finding is a _content gap_ — route it to `kb-find-gaps`, don't act on it here.
 
 ## Write rules (doctrine P3)
 

package/data/harnesses/kb-agi/harness.json

@@ -8,5 +8,5 @@
     ".prettierignore",
     ".vscode/settings.json"
   ],
-  "digest": "25e1cb993a7f"
+  "digest": "f0180d39f191"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@nurix/etna",
-    "version": "0.18.0",
+    "version": "0.18.2",
     "description": "Bootstrap a project with a Nurix harness — copies the harness's CLAUDE.md, skills, agents, rules, and hooks directly into the project from a bundled payload (no marketplace fetch, no network).",
     "type": "module",
     "bin": {

package/data/harnesses/code-fable/.prettierignore

@@ -1,12 +0,0 @@
-# Dependencies & build output
-node_modules
-dist
-build
-
-# Lockfiles
-pnpm-lock.yaml
-package-lock.json
-yarn.lock
-
-# Harness-managed agent/skill definitions (installed under .claude/)
-.claude

package/data/harnesses/code-fable/.prettierrc.json

@@ -1,3 +0,0 @@
-{
-  "proseWrap": "never"
-}

package/data/harnesses/code-fable/.vscode/settings.json

@@ -1,10 +0,0 @@
-{
-  // Markdown: Prettier unwraps prose to one logical line per paragraph
-  // (see .prettierrc → proseWrap:never) on save; the editor soft-wraps for
-  // reading, so no hard line breaks get baked into the source.
-  "[markdown]": {
-    "editor.defaultFormatter": "esbenp.prettier-vscode",
-    "editor.formatOnSave": true,
-    "editor.wordWrap": "on"
-  }
-}

package/data/harnesses/code-fable/CLAUDE.md

@@ -1,135 +0,0 @@
-# Agent Instructions
-
-This file defines how AI agents (Claude, GPT, etc.) should work on this project. **This file is the harness** — it orchestrates the skills and agents that do the work. There is no separate "harness skill."
-
----
-
-## Bootstrap
-
-> A missing `docs/structure.md` — or a `harness-version` behind the installed harness — is the **symptom** of a repo that isn't harnessed yet, or whose harness is out of date. Don't reconcile it by hand. Drive the **reconcile chain** — you (the main session) own it, because `harness-manager` is a sub-agent that can't run skills or spawn sub-agents:
->
-> 1. Invoke **`harness-manager`** (`"baseline this repo"` / `"reconcile the harness"`). It reconciles `docs/`, stamps the version, then hands back.
-> 2. If it hands back with a follow-up (typically the module proposal), re-invoke it to finish.
->
-> Then continue. Each component's internals live in the component, not here.
-
-This is the only step that runs **before** the harness exists; everything below assumes a reconciled repo.
-
----
-
-## Getting Started
-
-- Read **[`docs/structure.md`](docs/structure.md)** for the documentation map and folder authority (architecture, features, operations)
-- Read **[`docs/memory/`](docs/memory/)** for agent memory files (one per agent)
-- Ignore **[`README.md`](README.md)** – it's for human reference only
-- Check **[`package.json`](package.json)** for available scripts. Detect the package manager from the lockfile (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `package-lock.json` → npm) and use the matching command. Don't hardcode a specific manager.
-
----
-
-## Workflows
-
-Three peer modes plus a Completion step — enter wherever the user's thinking already is. Each mode is implemented by an agent + skill; the behavioural detail lives in those files, not here.
-
-| Mode              | Enter when                                                                                                                                       | Implemented by                                                    | Exits to                       |
-| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | ------------------------------ |
-| **Brainstorming** | explicit ask; or a user utterance challenges a loaded pillar headline → name the brushed principle and offer `/brainstorm start` (no auto-entry) | `brainstorm` agent + skill                                        | Spec, Plan, or close + harvest |
-| **Spec**          | new feature work                                                                                                                                 | `spec-mode` agent + `documentation` skill                         | Plan                           |
-| **Plan**          | a spec is approved                                                                                                                               | `documentation` skill → `docs/history/plans/YYYY-MM-DD-{slug}.md` | Completion                     |
-
-On **Completion**: freeze the plan (`Status: Complete`) and flip the feature spec to `Status: Active`, extending it with how-it-works sections; then distil the plan's trail — if the memory inbox (`docs/memory/inbox/`) holds entries, run `distiller facts` (inbox→fact-cards), then `distiller docs` for the just-completed feature's doc drafts any pending deltas for approval (presented, never auto-written). The `boundary` skill gates every approved plan before coding — it reads the source the plan touches and reports what would break (see **Boundaries** below); on brainstorm close, harvest by scope — module pillars → `docs/modules/{m}/pillars/`, cross-module doctrine + contract changes → `docs/architecture/` / ADRs, backlog → `docs/history/`. Open questions block close.
-
----
-
-## Context Routing
-
-Before modifying code in an unfamiliar area:
-
-1. If **[`docs/routing.md`](docs/routing.md)** exists, read it for file-pattern → module/doc/agent mapping. If it doesn't exist yet, skip.
-2. Glob `docs/{features,modules/*/features}/**/*.md` and check `owns` frontmatter to find the owning feature doc (rolled up to its module); read it — and, if it rolled up to a declared module, that module's `CLAUDE.md` + `pillars/` — before changes.
-3. If `qmd` is installed, `qmd query --format json -c <collection> "<topic>"` (repeat `-c` to span this repo's collections; `qmd collection list` names them) searches the indexed docs with their context attached — prefer it when entering an unfamiliar area; absent ⇒ skip.
-4. If your change touches a cross-cutting contract area (entity model, db schema, wire envelope, auth/authz, event vocabulary, webhooks, env/config), run the **`boundary`** skill scoped to your change — it reads both sides of each touched contract in source and reports what would break.
-5. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes
-6. When you author a declared module's docs, its `docs/modules/{m}/CLAUDE.md` auto-loads (the pillar bootstrap) — follow it. For code work it's surfaced via step 2.
-
-For the protocol on _writing_ to memory (which file, what belongs there, what doesn't), see **Project Memory** below.
-
----
-
-## Project Memory
-
-Project-specific learnings live in `docs/memory/` (git-tracked). Cross-project user preferences live in `~/.claude/` (untracked).
-
-| File                          | Owner               | Contents                                                                                                                                               |
-| ----------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `docs/memory/main.md`         | Main agent          | Project-wide patterns, conventions confirmed in this codebase, recurring failure modes, decisions whose rationale isn't obvious from the code          |
-| `docs/memory/{agent-name}.md` | The named sub-agent | Strategy memory for that agent — how to be more effective on this project (research patterns, taxonomy, ownership conflict zones). Never user-centric. |
-| `~/.claude/projects/...`      | Auto-memory system  | User preferences, role, communication style, cross-project habits                                                                                      |
-
-**Override the default auto-memory location for project-relevant facts.** When recording a learning, ask: _is this true of this project, or true of this user?_ Project facts → `docs/memory/`. User facts → `~/.claude/`.
-
-`docs/memory/main.md` is created on first write. Append entries dated `## YYYY-MM-DD — {topic}`; oldest at bottom is fine.
-
----
-
-## Out-of-Scope Discovery
-
-When implementing a plan, if you discover work that is important but outside the current plan's scope:
-
-- Append it to `docs/history/backlog.md` under the appropriate priority (P0-P3)
-- Format: `- **[P1]** Description — discovered by [plan-name or agent-name]`
-- Do NOT ask permission. Just append and mention it in your response.
-
----
-
-## Doc Ownership
-
-Feature docs (in `docs/modules/{m}/features/`, or flat `docs/features/` if the module isn't declared) must include YAML frontmatter with `owns`, `touches`, and `depends_on` fields. Architecture docs describe cross-cutting patterns and don't own specific files; boundary docs own cross-cutting shapes, not file paths; operations docs describe procedures. Only feature docs need frontmatter.
-
-The spec-mode agent checks for ownership conflicts during research. If conflicts are found, address them in the spec before proceeding.
-
----
-
-## Boundaries
-
-A boundary is a horizontal cross-cutting contract — entity model, db schema, wire envelope, auth/authz, event vocabulary, webhooks, env/config — where editing one side silently breaks the other. Boundaries are **diagnosed, not documented**: the `boundary` skill reads them fresh from source whenever a check runs, so they are never persisted as docs and can never go stale.
-
-**Invoke the `boundary` skill after a plan is approved and before its first implementation step.** It parses the plan's Proposed Changes, reads the touched source files, identifies the contracts they participate in (its `references/boundary-taxonomy.md` is the catalog), traces the consumers on the other side, and reports severity-ranked violations with suggested plan amendments — in chat, read-only. Fold the amendments into the plan before coding. For non-plan edits in contract-heavy code, run the same diagnostic scoped to the diff.
-
-> Agents and skills live under `.claude/agents/` and `.claude/skills/`. Their triggers are model-invoked — refer to each component's frontmatter, not a registry table here.
-
----
-
-## Boundaries & Defaults
-
-Unless explicitly requested:
-
-❌ **Tests** – Never generate, update, or modify test files.
-❌ **Dependencies** – Never upgrade frameworks, libraries, or dependencies.
-❌ **Compatibility** – Never maintain backward compatibility unless specified.
-❌ **Branches & Worktrees** – Never self-create git branches or worktrees. Commit straight to the checked-out branch; branch or create a worktree only when the user asks.
-❌ **Protected Files** – Before editing, if `docs/operations/protected-files.md` exists, read it and never modify any path it lists; also never modify `AGENTS.md` or the `protected-files.md` file itself.
-✅ **Browser Automation** – Use Chrome CDP / "Claude in Chrome" tools whenever they help (verifying UI, reproducing a flow, seeding or inspecting local data) — no need to ask first. **Main session only:** never drive the browser from a sub-agent or workflow executor — the session-bound Chrome connection destabilizes the sub-agent. A sub-agent that needs browser verification instead returns an explicit CDP checklist (exact URLs, actions, expected outcomes) for the orchestrator to execute in the main session.
-✅ **Orchestrate via Sub-agents** – Run the main session as an orchestrator: delegate substantive work (research, implementation, audits) to sub-agents spawned via the Agent/Task tool with `model: opus` (Claude Opus), keeping the main context for dispatch, coordination, and synthesis. Give each sub-agent a self-contained prompt; parallelize independent dispatches.
-✅ **Documentation** – Keep `docs/` updated when code changes affect documented behavior.
-⚠️ **Plans** – Plans are created directly in `docs/history/plans/` (see Workflow → Plan Mode). Once `Status: Complete` or `Status: Abandoned`, the file is frozen — never edited. If scope changes after completion, write a new dated plan that links back to the old one.
-⚠️ **Tool Issues** – If any CLI tool, shell alias, or MCP tool behaves unexpectedly (syntax errors, silent failures, wrong defaults), report the exact tool name, command, and error to the user so they can fix or remove the underlying library.
-
----
-
-## File Structure
-
-- Add file path at top of each file:
-  `// src/modules/example.js - Module for handling user authentication`
-- Add a 1-line function description as a comment above each function:
-  `// Extract JWT token from request based on endpoint type`
-
----
-
-## Documentation
-
-`docs/structure.md` is the authority on what belongs where — the folder map, naming, lifecycle, and the add-a-doc decision table. Read it before adding or moving a doc; don't restate it here. One canonical source per topic — link, don't copy. Only `CLAUDE.md`, `AGENTS.md`, and `README.md` live at the repo root.
-
-Maintenance triggers (act on these without re-reading `structure.md`):
-
-- After plan completion: add a `docs/history/changelog/` entry + update `docs/history/CHANGELOG.md` (no confirmation; include `Commits:` if multi-commit). Non-plan changes (refactors, fixes, API changes): prompt first.
-- When you add, move, or delete a doc: update `docs/routing.md` to match. When you move or rename source files: fix the `owns`/`touches` frontmatter in the owning doc; new docs that own code need `owns`/`touches`/`depends_on`.

package/data/harnesses/code-fable/agents/brainstorm.md

@@ -1,35 +0,0 @@
----
-name: brainstorm
-description: Brainstorming-mode facilitator — a thin orchestrator over the self-contained `brainstorm` skill, which owns every session mechanic (the constant distill→abstract→sync→record loop, the four modes, the basis entry gate, the background sync reconciler, the complexity-scaled pillar surface, harvest). Use to recognize when a conversation belongs at the 30k-foot strategic-design altitude and drive it in the skill's voice. Triggers on an explicit ask to brainstorm/design strategically, or on recognizing that a user utterance challenges a loaded pillar headline — which you OFFER a session for (suggest `/brainstorm start`), never silently enter.
-tools: Read, Glob, Grep, AskUserQuestion, Write
-model: inherit
----
-
-# Brainstorm Agent
-
-You are the **facilitator persona** for Brainstorming Mode — the 30,000-foot peer of Spec and Plan. You shape the **pillars** that steer the repo through conversation, never by writing production code or feature specs. The pillar surface scales with the idea's complexity — see the skill's **Pillars** table rather than carrying a fixed list in your head.
-
-You are a **thin orchestrator.** Every mechanic — the constant loop, the four modes, the basis entry gate, the background sync reconciler, the complexity-scaled pillars, append-only decisions, and harvest — lives in the **`brainstorm` skill**, which is self-contained and runs standalone via `/brainstorm start|stop`. Your only jobs: recognize when a conversation belongs in Brainstorming Mode, and drive it in the skill's voice. **Defer to the skill's `SKILL.md` for every mechanic — read it rather than re-deriving, and never restate its rules here.**
-
-## When to offer a session
-
-- An explicit ask to think through a design at a strategic level (not "fix this bug" / "add this button"). This is the user invoking the work; hand it to `/brainstorm start`.
-- A user utterance **challenges a loaded pillar headline.** To recognize this, hold the headlines in mind — skim `docs/architecture/` (`domain-model.md`, `glossary.md`, `non-goals.md`, `open-questions.md`) and any `docs/modules/*/pillars/`. In v9 the steering layer is dispersed there; there is no repo-wide `docs/pillars/`. When a proposal brushes an existing principle, **name that principle in plain English and offer a session** — suggest `/brainstorm start` and ask whether the proposal preserves or revises it. Detection is yours; entry is the user's. **Never auto-enter** — the skill admits only `/brainstorm start` and `/brainstorm stop`.
-
-If none of those steering files exist yet (a freshly-baselined repo), a session still runs from the skill's templates, and the basis gate seeds it from a reference doc or a one-shot brain dump.
-
-## Modes and the close gate
-
-Four modes exist — **dump / interview / probe / converge** — and they change *who drives* and *how much gets asked*, not the loop, which never stops. The mode lives in the session's `state.md` and switches only on an explicit user word. The close gate is **open questions**, not decision state: questions are the single convergence currency, and the idea is coherent only when zero remain after a fresh sync. See the skill's **Modes** and **Coherence** sections — don't re-derive them here.
-
-## How you facilitate
-
-- **Speak plain English; codes live in the files.** Name a pillar item by what it *is*, never by a bare code (`Q3`, `D7`); append the code in parentheses only if traceability needs it.
-- **Suggest, never seize.** Mode shifts, abstractions, and probes are one offer each; accept refusal without re-litigating.
-- **Never write production code** while a session is open — load-bearing snippets are illustration only, inside the session folder.
-
-You don't perform the harvest yourself, and you don't presume a destination. On close the session folder *is* the product by default; if the repo is v9-harnessed the skill **offers** the adapter routing into the doc tree. The skill's `## stop` section is the canonical harvest map — don't duplicate it.
-
-## What you may write
-
-The transient session folder only (its pillars and `state.md`). Never edit the live docs directly — the harvest does that.