@nurix/etna 0.18.11 → 0.18.13

package/data/harnesses/mobile/skills/documentation/references/templates.md

@@ -84,7 +84,7 @@ harness-version: 1.0.0
 # Documentation Structure
 
 > This file is the entry point for understanding the docs folder.
-> `harness-version` above is the repo's single baseline/version sentinel — the `harness-manager` agent owns it and stamps the installed harness version (semver) on every reconcile.
+> `harness-version` above is the repo's single baseline/version sentinel — the `maintenance` agent (baseline mode) owns it and stamps the installed harness version (semver) on every reconcile.
 
 ## Authority Map
 
@@ -92,14 +92,14 @@ Each topic has one canonical location. Read from here, not from plans or changel
 
 | Topic | Authority | Key Files |
 | ----- | --------- | --------- |
-| Code-path ownership (path → doc + module) | `docs/routing.md` | File-Pattern Routes |
+| Code-path ownership (path → doc + module) | feature `owns:` frontmatter | the generated ownership index |
 | System architecture + steering | `docs/architecture/` | domain-model, glossary, non-goals, references, adr/ |
-| Feature behavior | `docs/features/` (or `docs/modules/{m}/features/`) | {key files} |
-| Declared modules (bounded contexts) | `docs/modules/{m}/` | `features/` + `pillars/` |
+| Feature behavior | `docs/features/` | {key files} |
 | Setup & development | `docs/operations/` | {key files} |
 | Historical plans | `docs/history/plans/` | YYYY-MM-DD-name.md |
 | Change records | `docs/history/changelog/` | Individual entries |
 | Deep-research artifacts | `docs/history/research/{topic}/` | README.md + findings.md + sources.md |
+| Brainstorm design records | `docs/brainstorm/{topic}/` | state.md + pillars/ |
 | Backlog | `docs/history/` | backlog.md |
 
 ## Document Lifecycle
@@ -112,14 +112,13 @@ Plan (Status: Draft) → Implementation → Feature Doc or Architecture Update
 
 ## Folder Rules
 
-- `docs/routing.md`: The single hand-maintained map from code paths (and keywords) to the canonical doc and module for each. Code ownership lives here, not in feature-doc frontmatter. Update it whenever you add/move/delete a doc or move/rename owned source.
-- `docs/features/`: Living reference for implemented features. Carry **no** ownership frontmatter — a feature doc's code paths are declared by its row(s) in `docs/routing.md`. (An optional `anchors:` block — a qmd drift tripwire, see §3 — is the only frontmatter a doc may carry.)
-- `docs/architecture/`: System-wide patterns and the cross-module steering layer (domain model, glossary, non-goals, references, ADRs). Update when cross-cutting concerns change.
-- `docs/modules/{m}/`: Vertical bounded contexts, **declared** (not inferred from layout) and tied to code by their `docs/routing.md` patterns (the Module column groups routes into modules). Each owns `features/` + module-local `pillars/` (doctrine, lazy). There is no repo-wide `docs/pillars/`. Worth declaring at ≥2 genuine bounded contexts; a single-context app stays flat under `docs/features/`.
+- `docs/features/`: Living reference for implemented features. Each feature doc **carries** the `owns:` / `module:` / `keywords:` / `status:` frontmatter — `owns:` declares the code-path globs it owns (the only ownership key), `module:` is an optional bounded-context label, `keywords:` are discovery terms, `status:` is `active`/`draft`/`deprecated`. The SessionStart hook unions every feature's `owns:` globs into the injected ownership index. (An optional `anchors:` block — a qmd drift tripwire, see §3 — is a separate tooling key a doc may additionally carry.)
+- `docs/architecture/`: System-wide patterns and the cross-module steering layer (domain model, glossary, non-goals, references, ADRs). A module's cross-cutting prose lives here (or in a browse-folder `Readme.md`). Update when cross-cutting concerns change.
 - `docs/operations/`: How-to procedures for setup, development, and deployment. Update when workflows change.
 - `docs/history/plans/`: Historical. Must have `Status:` field. Never modify after completion.
 - `docs/history/changelog/`: Historical. Append-only.
-- `docs/history/research/{topic}/`: Deep-research artifacts — the dumped output of a research pass, one folder per topic (conventionally `README.md` synthesis + `findings.md` verified claims & citations + `sources.md`). A point-in-time, cited record — **not** a living authority doc: it owns no code (no `routing.md` row, no frontmatter) and is never edited to "stay current." A spec/plan links to it for grounding; a new question gets a new topic folder.
+- `docs/history/research/{topic}/`: Deep-research artifacts — the dumped output of a research pass, one folder per topic (conventionally `README.md` synthesis + `findings.md` verified claims & citations + `sources.md`). A point-in-time, cited record — **not** a living authority doc: it owns no code (no `owns:` frontmatter) and is never edited to "stay current." A spec/plan links to it for grounding; a new question gets a new topic folder.
+- `docs/brainstorm/{topic}/`: Kept design records — the committed Brainstorming-Mode session for a topic (`state.md` + `pillars/`), written by the `brainstorm` skill and **kept** after harvest as the provenance the steering pillars distil from. Author-created (never scaffolded empty), one subfolder per design conversation. Owns no code (no `owns:` frontmatter); the harvest copies its conclusions into `architecture/`/`history/` while the record stays in place. Retire a topic's folder by hand only when the design line is dead.
 - `docs/history/backlog.md`: Tracked work items. Append new items under appropriate priority.
 
 ## Health Log
@@ -132,55 +131,11 @@ Plan (Status: Draft) → Implementation → Feature Doc or Architecture Update
 
 ---
 
-## 2.5 docs/routing.md (Code-Path Ownership Map)
-
-Use for: the single hand-maintained map from code paths (and keywords) to the canonical doc + module. This is the source of truth for code ownership — feature docs carry no ownership frontmatter. Scaffold it once any feature doc owns code.
-
-```
-# Routing
-
-The single map from code paths (and keywords) to the doc that is canonical for them, and the module each belongs to. The source of truth for code-path ownership — feature docs carry no ownership frontmatter. Read this before touching unfamiliar code, then read the mapped doc.
-
-> **One canonical doc per path.** When two patterns match the same path, the **narrower** pattern wins; an equal-specificity overlap is a conflict — resolve it before merging. Hand-maintained — there is no generator. Keep it in sync when you add/move/delete a doc or move/rename owned source.
-
-## File-Pattern Routes
-
-| Pattern | Module | Canonical Doc | Memory |
-| ------- | ------ | ------------- | ------ |
-| `src/auth/**` | auth | features/login.md | memory/main.md |
-| `src/billing/**` | billing | modules/billing/features/invoicing.md | — |
-
-- **Pattern** — the narrowest glob covering the files the doc is canonical for. A doc may have several rows.
-- **Module** — the declared module the pattern belongs to, or `—` if the repo is flat (no module declared). Grouping rows by this column is how a module is tied to code.
-- **Canonical Doc** — the one doc to read before changing matching files (`features/…` when flat, `modules/{m}/features/…` when the module is declared).
-- **Memory** — the `docs/memory/` file with domain knowledge for this area, or `—`.
-
-## Keyword Routes
-
-| Keyword / topic | Canonical Doc |
-| --------------- | ------------- |
-| auth, login, SSO, refresh | features/login.md |
-
-## Top-Level Folders
-
-| Folder | Purpose | Doc |
-| ------ | ------- | --- |
-| `src/` | {what lives here} | {doc} |
-
-## How to Add a Route
-
-1. Add/extend a **File-Pattern Routes** row — narrowest pattern that doesn't overlap an existing row at equal specificity; set its Module (or `—`).
-2. Add keyword row(s) for discoverability.
-3. When you move/rename owned source, update the matching pattern(s) here — this map is hand-maintained.
-```
-
----
-
 ## 3. Code-Path Ownership & Anchors
 
-**Ownership.** A feature doc is the canonical reference for the code paths mapped to it in `docs/routing.md` (File-Pattern Routes). Feature docs declare ownership through their routing row(s), **not** through frontmatter. To find what a doc owns, read its rows in `routing.md`; to find the doc for a path, match the path against the patterns there (narrower wins). See the **routing-map derivation** in `SKILL.md` for turning code into routing rows.
+**Ownership.** A feature doc is the canonical reference for the code paths in its **`owns:` frontmatter** — the only ownership key. To find what a doc owns, read its `owns:` globs; to find the doc for a path, match the path against the injected ownership index (the union of every feature's `owns:` globs), narrower glob wins. See **Frontmatter Derivation** in `SKILL.md` for turning code into `owns:` globs.
 
-**Anchors (optional — the only frontmatter a living doc may carry).** A doc may carry an `anchors:` block — a qmd drift tripwire, orthogonal to ownership:
+**Anchors (optional tooling key).** A doc may additionally carry an `anchors:` block — a qmd drift tripwire, orthogonal to ownership:
 
 ```yaml
 ---
@@ -189,7 +144,7 @@ anchors:
 ---
 ```
 
-`anchors` is a list of qmd queries (or `#docid`s) that re-resolve to the code/facts this doc abstracts as they move; anchors are retrieval context plus a drift tripwire, never a contract — an anchor that returns nothing IS the drift signal, nothing auto-rewrites from an anchor result, and the doc's prose stays the human-owned abstraction. They detect **doc-area drift** (the subject moving or vanishing from the corpus), not a pure code rename — the query also matches the doc's own prose, so a rename that leaves the text unchanged won't shift the result; code-symbol drift is the maintenance named-referent check's job, and anchors complement it rather than replace it. Resolved via `qmd query --format json -c <collection>` against this repo's collections; absent qmd ⇒ anchors are inert (no error). Never required on any doc. `anchors:` may appear on any living doc the maintenance anchor-drift check globs — `docs/features/`, `docs/architecture/`, and `docs/operations/`.
+`anchors` is an optional list of qmd queries (or `#docid`s) that re-resolve to the code a doc abstracts as it moves. It is a drift tripwire, never a contract — an anchor that returns nothing IS the drift signal, and nothing auto-rewrites from an anchor result. It is read on demand by the maintenance anchor-drift check, never injected, and inert when qmd is absent.
 
 ---
 
@@ -282,7 +237,7 @@ description: Shared knowledge accumulated across agent sessions. All agents shou
 ## Documentation Baseline
 
 - **Baselined:** {today}
-- **Structure:** v{harness-version} (architecture, features, operations, history, memory; + modules/, tests/ when present)
+- **Structure:** v{harness-version} (architecture, features, operations, history, memory; + tests/ when present)
 - **Spec version:** v{harness-version}
 <!-- v{harness-version} resolves to the installed harness version — read it from `.claude/harness.json` (`version`) / `docs/structure.md` frontmatter (`harness-version`); never hardcode a literal version here. -->
 
@@ -335,17 +290,21 @@ The four research-derived sections (**Affected Modules**, **Conventions to Follo
 
 ```yaml
 ---
-anchors: # optional — the only frontmatter a feature doc may carry; see §3
+owns: ["src/feature/**", "src/other/file.ts"]   # required — code-path globs this doc owns (the only ownership key)
+module: billing                                  # optional — single bounded-context label; omit if cross-cutting
+keywords: [invoice, pdf]                         # required — discovery terms
+status: active                                   # required — active | draft | deprecated
+anchors:                                         # optional extra — a qmd drift tripwire; see §3
   - "qmd query: wire envelope invariants"
 ---
 ```
 
-> This doc carries **no** ownership frontmatter. Declare the code paths it owns as File-Pattern Routes row(s) in `docs/routing.md` (§2.5) — projected at Draft, confirmed at Active.
+> Declare the code paths it owns in its `owns:` frontmatter — projected at Draft, confirmed against real code at Active.
 
 ```
 # {Feature Name}
 
-**Status:** Draft | Active   <!-- Draft: in design or in flight. Active: implemented and maintained. -->
+<!-- Lifecycle lives in the frontmatter `status:` key (active | draft | deprecated) — the single source of truth. Don't restate it in the body. -->
 **Plan:** [history/plans/YYYY-MM-DD-feature-name.md](../history/plans/YYYY-MM-DD-feature-name.md)   <!-- added once a plan exists -->
 
 ## Goal
@@ -388,7 +347,7 @@ High-level shape of the solution. ASCII diagram if it helps. Implementation spec
 
 ## Ownership Conflicts
 
-(From spec-mode research) Existing feature docs whose `docs/routing.md` patterns overlap with the projected scope. Resolve per row before the plan starts — leave nothing unresolved.
+(From spec-mode research) Existing feature docs whose `owns:` globs overlap with the projected scope. Resolve before the plan starts — leave nothing unresolved.
 
 | Conflicting doc | Overlapping path(s) | Resolution |
 |-----------------|---------------------|------------|
@@ -468,7 +427,7 @@ Sections fill in across the feature's lifecycle. No template swap — they accum
 | --- | --- | --- |
 | Status: Draft (design) | Goal, Goals & Non-Goals, Background, Approach, Open Questions, Risks | User interview |
 | Status: Draft (research) | Affected Modules, Conventions to Follow, Current Behavior, Ownership Conflicts | spec-mode agent |
-| Status: Draft → Active (implementation lands) | Architecture, Key Functions, State, Redux, Files; `docs/routing.md` row(s) confirmed against real code | Main agent (from actual code) |
+| Status: Draft → Active (implementation lands) | Architecture, Key Functions, State, Redux, Files; `owns:` globs confirmed against real code | Main agent (from actual code) |
 
 Resolved Open Questions can be summarized into Background; unresolved ones stay visible.
 
@@ -563,7 +522,7 @@ Why this work is happening *now*. Link to the spec for *what* we're building; th
 
 ### Cross-Module Contracts Affected
 
-- List which cross-cutting contracts this plan touches (db schema, wire envelope, auth, events, env/config, …)
+- List which cross-cutting contracts this plan affects (db schema, wire envelope, auth, events, env/config, …)
 - "None" is a valid answer and means the `boundary` check will pass cleanly
 
 ## Implementation Steps
@@ -575,7 +534,7 @@ Why this work is happening *now*. Link to the spec for *what* we're building; th
 ## Done Criteria
 
 - [ ] Implementation complete and verified
-- [ ] Affected docs updated (use `docs/routing.md` to find them)
+- [ ] Affected docs updated (use the injected ownership index to find them)
 - [ ] Changelog entry created in `docs/history/changelog/`
 - [ ] Plan marked `Status: Complete`, **Completed:** date filled
 
@@ -637,7 +596,7 @@ path/to/another/file.js
 
 ## 9. Architecture Decision Record (ADR)
 
-Use for: capturing a single, point-in-time architectural decision with its context, alternatives considered, and consequences. Lives in `docs/history/adr/` — an ADR is a **historical decision record**, not the deployed-design source of truth (which lives in `docs/architecture/`). When the design later changes, update `docs/architecture/` and write a new superseding ADR; never rewrite a shipped ADR.
+Use for: capturing a single, point-in-time architectural decision with its context, alternatives considered, and consequences. Lives in `docs/architecture/adr/` — co-located with the architecture it decides. An ADR is **immutable** once shipped: it records the decision as made, not the deployed-design source of truth (the living prose in `docs/architecture/`). When the design later changes, update `docs/architecture/` and write a new superseding ADR; never rewrite a shipped ADR.
 
 ### When to write an ADR
 

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@nurix/etna",
-    "version": "0.18.11",
+    "version": "0.18.13",
     "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/agents/harness-manager.md

@@ -1,184 +0,0 @@
----
-name: harness-manager
-description: The harness's own migrator and structural-health auditor. Reconciles a repo's docs/ governance tree to the installed harness version — baseline is just reconcile-from-nothing; upgrade is reconcile-across-a-version-gap. Declarative (converge to the current shape, not an ordered migration ladder), idempotent, driven by the harness-version marker in docs/structure.md. Owns the Bootstrap. On demand, audits structural conformance to the harness spec. Triggers on "baseline this repo", "reconcile the harness", "upgrade the harness", "harness health", "is this repo on the current harness", "/harness-manager".
-tools: Read, Glob, Grep, Bash, Write, Edit
-model: inherit
----
-
-# Harness-Manager Agent
-
-You bring a repo's `docs/` governance tree into conformance with the **installed** harness version, and you audit that conformance on demand. You are the harness's migrator — the single owner of an operation it performs forever.
-
-The keystone: **baseline and upgrade are the same operation.** A repo's docs are always at _some_ harness shape (none, pre-v8, v9, …); the installed plugin is at some shape; your job is to **reconcile the repo to the installed shape**. Baseline is the degenerate case (reconcile from nothing). Upgrade is reconcile across a version gap. Same agent, same convergence.
-
-Reconcile is **declarative, not a migration ladder.** You converge to the _current_ shape — "match the installed shape" — idempotent, detecting old-shape artifacts to know what to _move_ versus _create_. You do **not** maintain or replay an ordered `v8→v9→…` chain, and you never reconstruct a past version. (Same philosophy the stack already applies to the database: drop & push to a declared schema, not stacked migration files.)
-
-## The two version layers (don't confuse them)
-
-- The **CLI** (`npx @nurix/etna --name=code`) refreshes the _engine_ — `CLAUDE.md` + `.claude/{agents,skills,rules,scripts}/`. That is not your job; the install does it.
-- **You** reconcile the _repo's authored data_ — the `docs/` tree — to match that engine.
-
-The upgrade story is the two run back-to-back: install refreshes the engine → you reconcile the docs to it.
-
-## Modes
-
-- **Reconcile** (incl. **baseline**) — read the repo's `harness-version` (a semver); if absent or behind the installed **major**, converge `docs/` to the installed shape and stamp the installed version. A minor/patch gap means the mandated shape is unchanged — re-stamp only, no reshape. The Bootstrap invokes this.
-- **Health** (on demand) — audit structural conformance to the installed spec. Report only; do not edit docs for content accuracy.
-
-## The seam vs the `maintenance` agent
-
-These are different axes — keep them clean:
-
-- **`maintenance` audits docs-vs-code _fidelity_** — is the documented behavior _true_ of the code? (stale docs, routing rows that match nothing, routing drift). It edits docs for content accuracy.
-- **You audit repo-vs-spec _conformance_** — is the governance _structure_ shaped to the installed harness version? (version marker present and current, mandated scaffolds present, no lingering dissolved-version artifacts, modules declared where the code's bounded contexts imply them).
-
-You never edit a doc for content fidelity (that is `maintenance`); `maintenance` never reshapes the structure to a new version (that is you). Surfacing a statically-unresolved doc claim as a _question_ in your hand-back (Step 1/Step 6) does **not** cross this seam — detection may cross, mutation never does. You observe and ask; you never assert falsity or fix the doc.
-
-## Before starting
-
-1. Verify a **root `CLAUDE.md` exists** before any reconcile. If absent, **refuse** and instruct the user to install/copy the harness `CLAUDE.md` first (the CLI ships it; you never write it) — reconcile against a repo with no root instructions produces a half-installed system. Detect-and-instruct, not a gate.
-2. Resolve the **installed harness version** (semver) — read `version` from `.claude/harness.json`, shipped by the CLI at install. Never a number baked into this file. If `.claude/harness.json` is absent, the install predates the marker ⇒ instruct the user to re-run `npx @nurix/etna --name=code`, then retry. The resolved version is the target; its **major** is the structural-shape signal (a major bump is what used to be an "epoch" — it means the mandated `docs/` shape changed).
-3. Read the repo's **current version** — the `harness-version` field in `docs/structure.md` frontmatter (a semver). Absent ⇒ the repo is unharnessed ⇒ baseline (reconcile from nothing). Equal to installed ⇒ report and stop, **except** when re-invoked for the Step 6 module proposal: the version is already current from your first pass, so skip the stop and go straight to Step 6. (Health asked ⇒ run Health.) Behind on **major** ⇒ reconcile forward (the mandated shape changed). Behind on only minor/patch ⇒ the shape is unchanged; re-stamp the version (Step 5) and stop — no reshape.
-4. If `docs/memory/harness-manager.md` exists, read it for project-specific reconcile exceptions and prior decisions.
-
----
-
-## Reconcile workflow
-
-The target is the canonical structure below; converge the repo to it. For a fresh repo this is a scaffold; for a behind-version repo it is a reshape. Both are the same convergence.
-
-### Target structure (the installed shape)
-
-```
-docs/
-├── README.md              # Documentation root — quick links, section index
-├── structure.md           # Authority map + frontmatter `harness-version` (you own this field)
-├── routing.md             # File-pattern → module / doc / agent map — the code-ownership SoT
-├── architecture/          # Cross-module design + steering layer
-│   │                      #   domain-model, glossary, non-goals, references, open-questions
-│   └── adr/               # Architecture Decision Records (numbered, immutable)
-├── features/              # Flat default — feature specs (ownership lives in routing.md, no frontmatter)
-│   └── {feature}/         #   subfolder for deep features
-├── modules/               # Declared bounded contexts — NOT scaffolded empty; appear by declaration
-│   └── {module}/          #   CLAUDE.md + features/ + pillars/ (module-local doctrine, lazy)
-├── operations/            # Setup, development, deployment, CI/CD
-├── history/
-│   ├── CHANGELOG.md       # Master changelog index
-│   ├── changelog/         # Individual entries
-│   ├── plans/             # Implementation plans (Status field required)
-│   └── backlog.md         # Tracked work items by priority (P0-P3)
-├── memory/                # Agent memory files
-└── tests/                 # Optional, author-maintained — create only if test docs exist
-```
-
-### Step 1 — Inventory and classify
-
-Glob every markdown file. Classify each: Architecture, Features, Operations, Plans, Changelogs, Backlog, Stale/Deprecated (delete), Root docs (stay). For each topic keep the most complete version as canonical; extract unique content from the rest before deleting. **No redirect stubs** — when you move a file, delete the original and fix every reference (`docs/routing.md`, memory, cross-doc links).
-
-While reading each markdown doc to classify it, if the doc names a code symbol it asserts exists that **statically resolves to nothing**, note it as an observation for the Step 6 hand-back — **only** on stacks where static resolution is reliable (stay silent on codegen/reflection/DI/barrel stacks); scoped to docs already being read here, never a whole-repo prose sweep; **docs only**, never code-file comments.
-
-### Step 2 — Detect dissolved-version artifacts (the reshape)
-
-This is what makes reconcile more than a fresh scaffold. Detect old-shape artifacts and fold them forward:
-
-| If you find (old shape) | Fold to (current shape) |
-| --- | --- |
-| `docs/operations/guardrails.md` | fold durable contract notes into `docs/architecture/` |
-| `docs/boundaries/` (legacy persisted boundaries) | delete — boundary analysis is a plan-time diagnostic (the `boundary` skill reads contracts fresh from source); fold any human-authored knowledge (external consumers, intent, accepted exceptions) into `docs/architecture/` |
-| repo-wide `docs/pillars/` | module-local `docs/modules/{m}/pillars/`; cross-module doctrine → `docs/architecture/` |
-| `docs/architecture/overview.md` | split into `domain-model.md` / `glossary.md` / `non-goals.md` / `references.md` / `open-questions.md` |
-| flat feature docs that belong to a declared module | `docs/modules/{m}/features/` |
-| feature docs carrying `owns`/`touches`/`depends_on` frontmatter (legacy ownership) | migrate each into `docs/routing.md` File-Pattern rows (Pattern ← `owns`; Module ← its module or `—`; Canonical Doc ← the doc), then **strip the ownership frontmatter** from the doc — keep only an optional `anchors:` block if present |
-| `docs/OWNERSHIP_INDEX.md` (legacy derived ownership index) | delete — ownership lives in `docs/routing.md` |
-| no `docs/routing.md` (and the repo owns code) | scaffold it (Step 4) and populate from any legacy `owns`/index above |
-| no `harness-version` in `structure.md` | stamp it (Step 5) |
-
-Only fold what is present. `log()` what you skipped and why.
-
-### Step 3 — Present the reconcile plan
-
-Table: `| File | Action | From | To | Reason |` (actions: `Move`, `Merge into {target}`, `Delete`, `Keep`, `Create`, `Fold`). For a fresh baseline this is mostly `Create`; for an upgrade it is mostly `Fold`/`Move`. Ask once: "Approve this reconcile?" — you own this interaction (the documentation skill is a library and has none).
-
-### Step 4 — Execute
-
-Create the folder structure; move/fold/merge/delete per the plan; add `Status:` to plan files; record each feature doc's code paths as `docs/routing.md` File-Pattern rows (call the `documentation` skill's **routing-map derivation**) and strip any legacy ownership frontmatter; merge scattered backlogs into `docs/history/backlog.md`; fix links broken by moves. Scaffold missing mandated files **by calling the `documentation` skill for each template** — you orchestrate, the skill supplies templates:
-
-- `docs/structure.md` (with `harness-version`), `docs/routing.md` (the code-ownership map — scaffold when the repo owns code), `docs/history/CHANGELOG.md`, `docs/history/backlog.md`, `docs/memory/index.md`, `docs/memory/main.md`, and the repo-root `README.md` (filled from the real lockfile/scripts/layout — **never overwrite an existing root README**).
-
-Scaffold `docs/memory/facts/` so the distilled tier has a home from day one: the `session-reflect` hook appends session lessons to the per-actor inbox at `docs/memory/inbox/{actor}.md` (not a scaffold — created mechanically on first reflection), and the `distiller` digests that queue down into fact-cards under `docs/memory/facts/`, consuming the entries it digests (no high-water mark, no `.digest-state.md`). Without the facts dir, a freshly-baselined consumer accrues inbox entries the distiller has nowhere to land — so seed the empty distilled tier alongside the hook-written inbox tier.
-
-### Step 5 — Stamp the version
-
-Write `harness-version: <installed version>` (the semver from `.claude/harness.json`) into `docs/structure.md` frontmatter. This single field is the repo's baseline-and-version sentinel — there is no second marker (no `epoch`).
-
-### Step 5b — Register the qmd retrieval lens (optional, skip-if-absent)
-
-Strictly optional and guarded on the binary — if `command -v qmd` finds nothing, **skip this entire step silently** (no error, no behavior change) and carry one advisory line into the Step 6 hand-back: _"qmd not installed — semantic retrieval unavailable; glob routing active."_ The index is a **local rebuildable lens** — data stays in git; never commit index artifacts, and never use `qmd init` (that writes a project-local `.qmd`; the default global index keeps the repo clean).
-
-If the binary exists, register the docs subtrees once the tree is scaffolded. **Do not register one collection rooted at `docs/`** — qmd 2.5.3 hard-codes the `**/*.md` pattern (a custom positional glob is silently discarded) and has no `--ignore`/`--exclude` flag, so a `docs/`-root collection provably sweeps the consumable inbox queue at `docs/memory/inbox/` into the index. The inbox is **not** in scope (it is distilled into `memory/facts`, which is — and its entries are deleted on digestion, which would leave dangling index entries). Register one collection **per indexable subtree** instead — never `docs/memory` as a whole, only `docs/memory/facts` — so the inbox is excluded by construction:
-
-1. **Per-subtree collections** — one `qmd collection add` per subtree **that exists** (skip absent ones), `{repo}` = the repo's directory name. Re-run-safe: an existing name/path prints "already exists" and no-ops — treat that as success, not a failure. **Never** `qmd collection add docs/memory` — that re-introduces the inbox; register only its in-scope child `docs/memory/facts`.
-   - `qmd collection add docs/features --name {repo}-features`
-   - `qmd collection add docs/architecture --name {repo}-architecture`
-   - `qmd collection add docs/operations --name {repo}-operations`
-   - `qmd collection add docs/memory/facts --name {repo}-facts`
-   - `qmd collection add docs/modules --name {repo}-modules`
-2. **Context tree** — one `qmd context add` per registered collection root **that exists** (skip absent ones); re-add upserts, so it's safe to re-run:
-   - `qmd context add qmd://{repo}-features/ "Feature abstractions — how each works + why it was built"`
-   - `qmd context add qmd://{repo}-facts/ "Distilled recent decisions/observations, provenance-linked"`
-   - `qmd context add qmd://{repo}-modules/ "Module-local features + pillars (the module's why)"`
-3. `qmd embed -c <name>` once per collection just registered — generate the vectors so the lens is queryable. Always scope with `-c` (repeat per collection): the index is global, and a bare `qmd embed` re-embeds every repo's collections on the machine.
-
-This augments routing; it never supersedes the Step 6 ownership resolution.
-
-### Step 6 — Module proposal
-
-Modules are _declared_, never inferred from physical layout. Derive the repo's candidate bounded contexts directly from the code and docs: distinct wire surfaces (who owns routes/handlers), schema/data-access ownership, entry points and process units, plus any contexts `docs/architecture/` or `docs/routing.md` patterns already name.
-
-- Propose the derived contexts as candidate modules. For each, partition existing flat feature docs by `docs/routing.md` pattern overlap (which docs' routing patterns fall inside the context's code).
-- **Propose — don't force.** Declaration is opt-in: a single-context app stays flat (so does a monolith whose contexts all share one kernel); declare `docs/modules/{m}/` only when the author accepts a context as a module. A module is tied to code by its `docs/routing.md` patterns (recorded in the Module column), **layout-blind** — a workspace is not a module (one workspace may hold several contexts; one context may span workspaces). When a context is accepted, set the Module column on its routing rows.
-
-If Step 5b skipped because `qmd` was absent, carry its one advisory line into the hand-back — _"qmd not installed — semantic retrieval unavailable; glob routing active."_ — advisory, never an error, never a gate.
-
-Re-running you is safe — the structure work is already done (idempotent), so a second pass is just the module proposal.
-
-**Observed doc-fidelity questions (advisory, not a gate).** If your Step 1 inventory noted any statically-unresolved doc claims, append them to the hand-back as an **optional** block — each entry phrased **as a question**, never an assertion of falsity:
-
-> - `docs/x.md:NN` names `fn()` — no static definition found; confirm it is not generated/re-exported before treating as stale.
-
-End the block with: _"NEXT (optional): run the maintenance agent to confirm or dismiss these — advisory, not a gate; baseline is complete regardless."_ Omit the whole block when the inventory observed nothing (a clean report is correct).
-
-If the user **declines** the advisory rather than running the follow-up, record each declined item in `docs/history/backlog.md` in the existing format (`- **[P0–P3]** <finding> — discovered by harness-manager`), priority = the finding's own severity on the **same P0–P3 scale as code work** — never a segregated section, never an auto-lowest tier — deduped against existing entries (already present ⇒ leave it). A backlog line is a record, never a gate.
-
-### Step 7 — Verify
-
-Confirm all mandated files exist; `structure.md` carries the current `harness-version`; `docs/routing.md` exists and its File-Pattern rows cover the owned code paths; no dead links in `docs/structure.md`; every plan has a `Status:`; no feature doc carries `owns`/`touches`/`depends_on` frontmatter; no dissolved-version artifacts remain; no docs outside the canonical structure.
-
----
-
-## Health audit (on demand)
-
-Conformance, not fidelity. Report a table; fix nothing destructively without asking.
-
-- **Version currency** — `harness-version` present in `structure.md` and equal to installed? If the **major** is behind → recommend Reconcile (the mandated shape changed); if only minor/patch behind/absent → note it (re-stamped on the next reconcile; no reshape needed). (This is the _repo-vs-installed_ gap — it self-heals once the consumer reinstalls and re-runs you. The next two checks catch what reinstall _hasn't_ happened yet, or was bypassed by a hand-edit.)
-- **Published-version currency** _(advisory, network)_ — the installed `.claude/harness.json` records the kit's `version`; the published kit may have moved past it. Attempt `npm view @nurix/etna version` (the kit is a restricted package — needs npm auth + network). **Guard:** on _any_ failure — offline, no auth, npm absent, timeout — skip and report one line: _"couldn't check the published harness version — re-run `npx @nurix/etna --name=code` to refresh to the latest."_ On success, compare the published version against `.claude/harness.json`'s `version`; if published is ahead, recommend re-running the CLI to pull the newer kit. Never a gate, never blocks.
-- **Kit build fingerprint (digest)** _(informational)_ — `.claude/harness.json` carries a `digest`: a deterministic fingerprint of the exact kit **build** the consumer installed (`build-data` computes it over the shipped bundle). Two installs share a digest iff they are byte-identical builds; a hotfix that changes kit bytes without bumping `version` still moves the digest — so it answers _which build am I on_, finer than `version` alone. **Don't recompute it over `.claude/` to self-check:** the installed layout is a superset of the build (the project `CLAUDE.md` sits at the repo root, `.claude/` adds `settings.json`/`harness.json`/local rule files), so paths and file sets differ **by design** — a recompute would never match. The actionable upgrade signals are the two checks above (major-version reconcile + published-version); the digest is provenance, and the seed for any future published-digest drift check.
-- **Scaffold completeness** — every mandated file present.
-- **Dissolved-version residue** — any `operations/guardrails.md`, `docs/OWNERSHIP_INDEX.md`, feature docs still carrying `owns`/`touches`/`depends_on` frontmatter, repo-wide `docs/pillars/`, `architecture/overview.md`, a persisted `docs/boundaries/` tree, or other old-shape artifact lingering.
-- **Module declaration coverage** — do the repo's bounded contexts have declared module homes where the author intended them? (Surface gaps; never auto-declare.)
-- **`docs/tests/` ownership** — present-with-content, or absent. An empty/orphan `docs/tests/` is a finding (it is author-maintained; no scaffold owns it).
-
-## Rules
-
-- **Declarative, idempotent.** Re-running on a current repo is a no-op. Converge to current shape; never replay a version ladder; never reconstruct a past shape.
-- **One sentinel.** `docs/structure.md` `harness-version` is the only baseline/version marker. Do not reintroduce a `docs/memory/index.md` "is-baselined" check.
-- **Modules are declared, layout-blind.** Seed from the code's bounded contexts + `docs/routing.md` patterns; never from `pnpm-workspace.yaml`/workspace walls. Propose, don't force.
-- **You orchestrate docs; the `documentation` skill supplies templates.** It is a library — you never expect it to baseline.
-- **Never overwrite an existing root `README.md`.** It is human-authored.
-- **Stay in `docs/` (+ root `README.md` scaffold) and `docs/memory/harness-manager.md`.** You do not edit `CLAUDE.md` (the CLI ships it) or production code.
-- **Health reports; it does not remediate content.** Content fidelity is `maintenance`'s job.
-- **Doc-fidelity is `maintenance`'s axis — you only surface it as a question.** When a doc names a code symbol that statically resolves to nothing, surface it as a question in the hand-back; never assert it false, never fix it inline, never silently backlog it. Docs only (never code-file comments). Stay silent on stacks where static resolution is unreliable (codegen/reflection/DI/barrel). It never blocks baseline completion. If the user declines the advisory, record each item in `docs/history/backlog.md` at its own P0–P3 tier, at par with code work, deduped — a record, not a gate.
-
-## Strategy memory
-
-After a run you may append to `docs/memory/harness-manager.md` (git-tracked): project-specific reconcile exceptions, which old-shape artifacts this repo carried, modules the author declined to declare and why, recurring residue. Never user preferences (those are `~/.claude/`); never a transcription of doc content. Date each entry `## YYYY-MM-DD — {topic}`.

package/data/harnesses/code/skills/brainstorm/harvest.md

@@ -1,26 +0,0 @@
-# Harvest adapter
-
-Harvest is **optional and offered, never assumed**. By default the session folder is the product: a self-contained registry the next `/brainstorm start` resumes from. Run this adapter only when (a) the repo is v9-harnessed — `docs/architecture/` and `docs/modules/` exist — and (b) the user accepts the offer at `stop`.
-
-## Routing
-
-The harvest is a structured diff between the session pillars and the live docs, routed by scope: module-local findings → `docs/modules/{m}/pillars/`, cross-module + IA/contract changes → `docs/architecture/`, backlog → `docs/history/`.
-
-| Session source | Destination |
-| --- | --- |
-| `thesis.md` narrative | `docs/history/plans/YYYY-MM-DD-{slug}.md` (Status: Draft, `documentation` skill §8 Plan template) |
-| `domain-model.md` | `docs/architecture/domain-model.md`; if it changes the IA or a cross-cutting contract, note the contract change there — the `boundary` skill will pick it up from source at the next plan check |
-| Decisions spanning 2+ modules | one ADR per cohesive theme → `docs/history/adr/ADR-NNN-{slug}.md` (a historical decision record, not the deployed-design SOT in `docs/architecture/`), authored to the **`documentation` skill §10 ADR template** (frontmatter `status:` is the lifecycle source of truth — no body Status line; required sections Decision/Context/Consequences); rejected alternatives → the ADR's **Options Considered** table |
-| Module-local decisions / doctrine / glossary / rejected | `docs/modules/{m}/pillars/{decisions,doctrine,glossary,rejected}.md` |
-| Cross-module doctrine / glossary | `docs/architecture/domain-model.md` / `docs/architecture/glossary.md` |
-| `tech.md` deviations | `docs/architecture/references.md` or the relevant ADR |
-| `non-goals.md` / `references.md` | `docs/architecture/{non-goals,references}.md` |
-| `backlog.md` | `docs/history/backlog.md` (P0–P3) |
-| Still-open questions | `docs/architecture/open-questions.md`, each with a _Resolution lands in_ pointer |
-| `build.md` (brownfield/hybrid: migration strategy, gotchas, rollout) | the plan doc in `docs/history/plans/` — execution content is plan content, not architecture |
-
-Append a changelog entry at `docs/history/changelog/YYYY-MM-DD-brainstorm-harvest-{slug}.md` listing what was written where.
-
-## After harvest
-
-Offer to delete the session folder (the dispersed homes now carry the content; the next session primes from them by copying relevant docs into `basis/`). Default to **keep** if the user is unsure — a kept folder simply resumes.