@nurix/etna 0.18.11 → 0.18.13

package/data/harnesses/etna/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/hr/harness.json

@@ -1,11 +1,11 @@
 {
   "harness": "hr",
   "name": "hr",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "files": [
     ".prettierrc.json",
     ".prettierignore",
     ".vscode/settings.json"
   ],
-  "digest": "da038267aa11"
+  "digest": "6d11004d6849"
 }

package/data/harnesses/hr/skills/evaluator/criteria/testing.md

@@ -132,13 +132,13 @@ jq '[.results[] | select(
 )]' /tmp/semgrep.json
 ```
 
-**What was dropped from the earlier regex and why:**
+**What the pattern deliberately excludes, and why:**
 
 - `error|exception` — matched every rule name containing those words (most security rules do), inflating findings ~10×.
 - `injection|deserial|unsafe` — security territory; belongs in 1.4 Maintainability / SECURITY gate to avoid double-counting.
-- `await|promise` (bare) — tightened to `unchecked-await` / `unhandled-promise` so async-correctness rules aren't indiscriminately matched.
+- `await|promise` (bare) — scoped to `unchecked-await` / `unhandled-promise` so async-correctness rules aren't indiscriminately matched.
 
-Also dropped `p/security-audit` config — was producing security-skewed noise. Language packs alone carry the resilience rules we want.
+`p/security-audit` config is excluded — it produces security-skewed noise. Language packs alone carry the resilience rules we want.
 
 Capture:
 
@@ -390,7 +390,7 @@ signals_used: [filesystem, gha, semgrep, llm, coderabbit_empty]
 
 ## Caveats
 
-- Semgrep pre-built packs skew toward security. Tightened regex keeps resilience focus; worth 3–5 custom rules if scoring reveals gaps.
+- Semgrep pre-built packs skew toward security. A tight regex keeps resilience focus; worth 3–5 custom rules if scoring reveals gaps.
 - CodeRabbit reuse is a calibrating modifier, not a primary axis; `null` on Free-plan walkthrough-only repos means no-op. Full rationale + plan-upgrade escape hatch in [`SKILL.md → CodeRabbit — calibrating modifier with null-data semantics`](../SKILL.md#coderabbit--calibrating-modifier-with-null-data-semantics).
 - `AI_AUTHORED_SUSPECTED` flag (from 1.1) remains informational — LLM reviewer should note AI-generated resilience patterns (e.g. copy-pasted try/except blocks with identical logging).
 - LLM sample size is 3. Diverse codebases may score unevenly. Evidence must name the files.

package/data/harnesses/mobile/CLAUDE.md

@@ -6,9 +6,9 @@ This file defines how AI agents (Claude, GPT, etc.) should work on this project.
 
 ## 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:
+> 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 `maintenance` 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.
+> 1. Invoke **`maintenance`** (`"baseline this repo"` / `"reconcile the harness"`). It auto-selects **baseline mode** from the missing/behind `harness-version`, 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.
@@ -42,7 +42,7 @@ Three peer modes plus a Completion step — enter wherever the user's thinking a
 | **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 (the deployed-design SOT) → `docs/architecture/` with its decision record → `docs/history/adr/`, backlog → `docs/history/`. Open questions block close.
+On **Completion**: freeze the plan (`Status: Complete`) and flip the feature spec to `status: active`, extending it with how-it-works sections and confirming its `owns:` globs against the actual code; 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); a brainstorm session is written to a **kept** record at `docs/brainstorm/{topic}/` (committed, one subfolder per topic), and on close harvest distils its conclusions by scope — doctrine, glossary, non-goals, and information-architecture changes → `docs/architecture/`, decisions → `docs/architecture/adr/`, backlog → `docs/history/backlog.md` — leaving the `docs/brainstorm/{topic}/` record in place as the provenance. Open questions block close.
 
 ---
 
@@ -50,11 +50,10 @@ On **Completion**: freeze the plan (`Status: Complete`) and flip the feature spe
 
 Before modifying code in an unfamiliar area:
 
-1. Read **[`docs/routing.md`](docs/routing.md)** — the single map of file-pattern/keyword → canonical doc + module. Match your path or topic to find the owning feature doc and its module; read that doc — and, if its row names a declared module, that module's `CLAUDE.md` + `pillars/` — before changes. (If `routing.md` doesn't exist yet, the repo isn't reconciled — see Bootstrap.)
-2. 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.
+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 feature doc and read it before changes. (If no ownership index appears in context, the repo isn't reconciled — see Bootstrap.)
+2. If `qmd` is installed, run `qmd query --format json -c <collection> "<topic>"` (repeat `-c` to span this repo's collections; `qmd collection list` names them) 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
-5. 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 1.
+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.
 
@@ -88,9 +87,9 @@ When implementing a plan, if you discover work that is important but outside the
 
 ## Doc Ownership
 
-Which doc is canonical for which code paths — and which module each path belongs to — is recorded in **[`docs/routing.md`](docs/routing.md)** (File-Pattern Routes), the single hand-maintained map. Feature docs (in `docs/modules/{m}/features/`, or flat `docs/features/` if the module isn't declared) carry **no** ownership frontmatter; their code paths are their routing row(s). A module is tied to code by its routing patterns (the Module column), not by aggregated globs. Architecture docs describe cross-cutting patterns and don't own specific files; operations docs describe procedures. The only frontmatter a living doc may carry is an optional `anchors:` block (a qmd drift tripwire, not ownership).
+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. A module is tied to code by the `owns:` globs of the docs carrying its `module:` label — not a folder, not a separate map. 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 `routing.md` for ownership conflicts during research (overlapping patterns). 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.
 
 ---
 
@@ -126,4 +125,4 @@ Unless explicitly requested:
 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: update the matching File-Pattern Route(s) in `docs/routing.md`; a new doc that owns code gets its row(s) there (no frontmatter).
+- When you move or rename source files: update the `owns:` globs of the feature doc that owns them so the generated ownership index stays accurate. A new doc that owns code declares its paths in its own `owns:` frontmatter — there is no separate map to update.

package/data/harnesses/mobile/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/mobile/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