@nurix/etna 0.18.11 → 0.18.13

package/data/harnesses/code/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/data/harnesses/etna/CLAUDE.md

@@ -26,12 +26,12 @@ For new features or new systems, enter **Spec Mode** before Plan Mode.
 
 1. **Spec Mode**: Create or update a feature spec in `docs/features/{feature}.md` using the **Feature Documentation template** (Status: Draft) — see `.claude/skills/documentation/references/templates.md` §6. Use the **`spec-mode`** agent (`.claude/agents/spec-mode.md`) for codebase research; its findings drop directly into the template's research-derived sections (Affected Modules, Conventions to Follow, Current Behavior, Ownership Conflicts). Interview the user for the design-intent sections (Goal, Goals & Non-Goals, Background, Approach). Present the spec for approval before proceeding.
 
-2. **Plan Mode**: Once the spec is approved, create a plan in `docs/history/plans/YYYY-MM-DD-feature-name.md` using the **Plan template** (see `.claude/skills/documentation/references/templates.md` §8). Link back to the feature spec in the **Spec** field. The template's **Proposed Changes** sections are load-bearing — the `boundary` skill (`check` mode) parses them to check boundary impact.
+2. **Plan Mode**: Once the spec is approved, create a plan in `docs/history/plans/YYYY-MM-DD-feature-name.md` using the **Plan template** (see `.claude/skills/documentation/references/templates.md` §8). Link back to the feature spec in the **Spec** field. The template's **Proposed Changes** sections are load-bearing — the `boundary` skill parses them to check boundary impact.
 
 3. **Completion**: When a plan is fully implemented:
    - Mark the plan `Status: Complete` in `docs/history/plans/` and fill the **Completed:** date. The plan is now frozen.
-   - **Flip the feature spec** to `Status: Active` and extend it in place with the implementation sections (Architecture, Key Functions, State, Redux, Files). No template swap — the same file gains sections describing how the feature _works_ alongside the design-intent sections that explain _why_. Confirm `owns`/`touches` frontmatter against actual code; resolve any unresolved Open Questions by folding them into Background.
-   - If `docs/routing.md` exists, use it to find other docs affected by the changes; otherwise glob `docs/features/**/*.md` and check `owns`/`touches` frontmatter. Update affected docs — or create new ones if a touched area has no doc yet.
+   - **Flip the feature spec** to `status: active` and extend it in place with the implementation sections (Architecture, Key Functions, State, Redux, Files). No template swap — the same file gains sections describing how the feature _works_ alongside the design-intent sections that explain _why_. Confirm the feature's `owns:` globs against actual code; resolve any unresolved Open Questions by folding them into Background.
+   - Use the injected ownership index to find other docs affected by the changes (and update the `owns:` globs of any feature doc whose source you moved or added). Update affected docs — or create new ones if a touched area has no doc yet.
 
 For **Product-level** work (new systems, unclear scope), the spec should also include: problem statement, key hypotheses, and open questions.
 
@@ -41,9 +41,10 @@ For **Product-level** work (new systems, unclear scope), the spec should also in
 
 Before modifying code in an unfamiliar area:
 
-1. If **[`docs/routing.md`](docs/routing.md)** exists, read it for file-pattern → doc/agent mapping. If it doesn't exist yet, skip — the codebase may not have owned features.
-2. Glob `docs/features/**/*.md` and check `owns` frontmatter to find the owning feature doc; read it before making changes.
-3. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes
+1. Consult the **injected ownership index** — the generated `glob → doc · module · keywords · status` map, surfaced into context at session start (the union of every feature doc's `owns:` frontmatter). Match your path or topic (its `keywords:`) to the owning doc and read it before changes. (If no ownership index appears in context, the repo isn't reconciled — run `maintenance` in baseline mode to reconcile it.)
+2. If `qmd` is installed, run `qmd query --format json -c <collection> "<topic>"` for semantic recall over the indexed docs — prefer it when entering an unfamiliar area; absent ⇒ skip.
+3. 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.
+4. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes
 
 For the protocol on _writing_ to memory (which file, what belongs there, what doesn't), see **Project Memory** below.
 
@@ -71,24 +72,19 @@ When implementing a plan, if you discover work that is important but outside the
 
 ### Doc Ownership
 
-Feature docs in `docs/features/` must include YAML frontmatter with `owns`, `touches`, and `depends_on` fields. Architecture docs describe cross-cutting patterns and don't own specific files; operations docs describe procedures. Only feature docs need frontmatter.
+Which doc is canonical for which code paths is the **feature doc's own frontmatter**. A feature doc (flat in `docs/features/`) carries `owns:` (code-path globs — the only ownership key), `module:` (a bounded-context label, omitted when cross-cutting), `keywords:` (discovery), and `status:`. Code → doc ownership is the union of every feature doc's `owns:` globs, surfaced as the generated ownership index at session start. Architecture docs describe cross-cutting patterns and don't own specific files; operations docs describe procedures. A living doc may additionally carry an optional `anchors:` block (a qmd drift tripwire, not ownership).
 
-The spec-mode agent checks for ownership conflicts during research. If conflicts are found, address them in the spec before proceeding.
+The spec-mode agent checks for ownership conflicts during research — feature docs whose `owns:` globs overlap at equal specificity. If conflicts are found, address them in the spec before proceeding.
 
 ---
 
 ## Boundaries
 
-`docs/boundaries/` documents the repo's **typed application boundaries** — cascading failure boundaries where editing one module silently breaks another (shared state shapes, entity registration, cross-module string coupling, persistence rehydration, etc.). One component owns this surface — the **`boundary` skill** — with four modes over a shared `references/boundary-taxonomy.md`:
+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.
 
-- **`generate`** — baseline `docs/boundaries/` from the detected stack + IA
-- **`create`** — add or update a single boundary file
-- **`check`** — pre-implementation: check a proposed plan against `docs/boundaries/`, surfacing cascading risk early (the boundary's severity sets review depth)
-- **`init`** — reconcile + scan the live codebase for boundary violations + drift
+**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.
 
-Without `docs/boundaries/` populated (`generate`), the `check` and `init` modes have nothing to check against.
-
-> Agents and skills available in this harness come from the bound plugin (`plugin: code` above). Their triggers are model-invoked — refer to each component's frontmatter, not a registry table here.
+> 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.
 
 ---
 
@@ -117,7 +113,7 @@ Unless explicitly requested:
 
 ### Folder Structure
 
-The six procedural folders below are fixed. Domain folders (e.g. `core/`) live as subfolders inside these — `docs/architecture/core/` for core module internals, `docs/features/{feature}/` for deep features. Discovery still flows through **[`docs/routing.md`](docs/routing.md)** when present.
+The six procedural folders below are fixed. Domain folders (e.g. `core/`) live as subfolders inside these — `docs/architecture/core/` for core module internals, `docs/features/{group}/` as browse-only groupings (never modules). Discovery flows through the generated **ownership index** (from feature `owns:`/`keywords:` frontmatter), injected at session start.
 
 | Folder | Purpose | Mutability |
 | --- | --- | --- |
@@ -139,22 +135,17 @@ The six procedural folders below are fixed. Domain folders (e.g. `core/`) live a
 
 - **Prerequisite**: Before creating changelogs, feature docs, or plans, check that `docs/memory/index.md` exists and records a baseline. If not, prompt the user to baseline docs first.
 - After plan completion: create a `docs/history/changelog/YYYY-MM-DD-feature-name.md` entry + update the index in `docs/history/CHANGELOG.md` (no confirmation needed). Root-level `CHANGELOG.md` is not used — only `CLAUDE.md`, `AGENTS.md`, and `README.md` live in the repo root.
-- Update related docs affected by the changes (use `docs/routing.md` to find the right files if present; otherwise check `owns`/`touches` frontmatter in `docs/features/`)
+- Update related docs affected by the changes (use the injected ownership index — feature `owns:` globs — to find the right files)
 - Non-plan changes (refactors, bug fixes, API changes): prompt user first
 - Multi-commit changes: include `Commits: abc1234, def5678`
 
 ### Keeping the Loop Tight
 
-When you create, move, or delete a doc:
+When you create a new doc that owns code:
 
-- If **[`docs/routing.md`](docs/routing.md)** exists, update it — file-pattern routes and keyword routes
-- If creating a new top-level domain folder and routing.md exists: add the folder to routing.md's **Top-Level Folders** table
+- Declare the code paths it owns in its own `owns:` frontmatter (plus `module:`/`keywords:`/`status:`); the generated ownership index picks it up at the next session start.
+- Verify its `owns:` globs don't overlap another feature doc's at equal specificity.
 
 When you move or rename source files:
 
-- Check `owns`/`touches` frontmatter in the owning doc. Find the owning doc via `docs/routing.md` if present; otherwise glob `docs/features/**/*.md` and match against `owns` patterns. Update paths to match the new locations.
-
-When you create a new doc that owns code:
-
-- Add `owns`, `touches`, `depends_on` YAML frontmatter
-- Verify `owns` globs don't conflict with existing docs (compare against `owns` frontmatter across `docs/features/`)
+- Update the `owns:` globs of the feature doc that owns them to the new paths.

package/data/harnesses/etna/agents/brainstorm.md

@@ -14,7 +14,7 @@ You are a **thin orchestrator.** Every mechanic — the constant loop, the four
 ## 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`.
+- 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 its `adr/` decision titles. The steering layer lives there; there are no `docs/modules/` or `docs/pillars/` folders. 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.
 
@@ -28,8 +28,8 @@ Four modes exist — **dump / interview / probe / converge** — and they change
 - **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.
+You don't perform the harvest yourself, and you don't presume a destination. On close the skill **offers** the harvest, distilling the pillars' conclusions into wherever the harness routes them. The session folder — where it lives, and whether it is kept or transient — is whatever the `brainstorm` skill defines for this harness; the skill's `## stop` section is the canonical harvest map, so 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.
+The session folder only (its pillars and `state.md`), wherever the `brainstorm` skill places it for this harness. Never edit the live docs directly — the harvest does that.

package/data/harnesses/etna/agents/change-review.md

@@ -33,7 +33,7 @@ The heatmap needs rolling 1w / 1m / 3m windows, so default `since` to 3 months e
 
 1. If `./docs/memory/change-review.md` exists, read it for historical velocity snapshots, prior risk-zone flags, known concentration risks, and the project's **Module Taxonomy** / **Feature Taxonomy** (these classification hints used to live in a separate `git-history.md` memory file — they now live here).
 2. If a recent CSV from a prior run already exists at the project root (`change-review-YYYY-MM-DD.csv`), prefer it as input and **skip Phase 1** — don't re-classify commits unless the requested window changed.
-3. Read `./docs/routing.md` File-Pattern Routes to map churn to owning feature docs (and their modules).
+3. Build the ownership map from feature `owns:` frontmatter — consult the injected ownership index (`glob → doc · module · keywords · status`), or glob `docs/features/**/*.md` and read each doc's `owns:` globs — to map churn to owning feature docs (and their `module:` labels).
 
 ---
 
@@ -207,8 +207,8 @@ Trend column: ↑ rising, ↓ falling, → steady, ↑↑ sharply rising, ↓↓
 For each module with high churn (top quartile in 1m window), check how contract-heavy and how covered it is:
 
 - Does its code own cross-cutting contract surfaces (schema/data access, wire handlers, auth/authz, event dispatch, env/config readers)? Skim the module's files to judge — contract-heavy churn is where silent breakage lives.
-- Is the module's `owns` doc up to date? (cross-reference with the maintenance agent's last drift check if available)
-- Does the module appear in `docs/routing.md`?
+- Is the module's owning feature doc up to date? (cross-reference with the maintenance agent's last drift check if available)
+- Do the module's code paths appear under any feature doc's `owns:` globs?
 
 Flag risk zones: high churn × contract-heavy × low doc coverage. These are where silent breakage is most likely.
 
@@ -231,7 +231,7 @@ Per module, list which authors made the most commits in the 3-month window. Surf
 - **Risk zones**: top 5 high-churn modules that own contract-heavy surfaces, with the specific contracts at risk named
 - **Stabilization signals**: modules where review overhead can decrease
 - **Concentration risks**: bus-factor and review-coverage flags
-- **Recommendations**: prioritized list — typically "run the `boundary` skill on changes touching X", "update routing.md to cover Y", "spread reviews of Z across more authors"
+- **Recommendations**: prioritized list — typically "run the `boundary` skill on changes touching X", "add `owns:` coverage for Y to a feature doc", "spread reviews of Z across more authors"
 
 ### Update tracking