@nurix/etna 0.3.2 → 0.10.1

package/data/harnesses/code/CLAUDE.md

@@ -1,7 +1,7 @@
 ---
 name: code
-description: Canonical Nurix code-project harness (spec v9) — three peer authoring modes (Brainstorming / Spec / Plan), modules as bounded contexts, typed application boundaries, ownership rules. The reference CLAUDE.md every Nurix codebase starts with.
-version: 0.2.2
+description: Canonical Nurix code-project harness (spec v10) — three peer authoring modes (Brainstorming / Spec / Plan), modules as bounded contexts, typed application boundaries, a self-migrating harness-manager, ownership rules. The reference CLAUDE.md every Nurix codebase starts with.
+version: 0.10.0
 keywords:
   - harness
   - code
@@ -20,9 +20,9 @@ This file defines how AI agents (Claude, GPT, etc.) should work on this project.
 
 ## Bootstrap
 
-> If `docs/structure.md` is missing in this repo, the repo is **not yet harnessed**. Before any other work: invoke the `documentation` skill to run its baseline (`"baseline this repo"`), then run `boundary-mapper` (`"baseline boundaries"`) to populate `docs/boundaries/`. Pillars are module-local (`docs/modules/{m}/pillars/`), created lazily through Brainstorming Mode — not scaffolded up front. Re-trigger either baseline manually any time.
+> If `docs/structure.md` is missing — or its `harness-version` frontmatter is behind the installed harness — invoke the **`harness-manager`** agent (`"baseline this repo"` / `"reconcile the harness"`). It reconciles `docs/` to the installed version (baseline is just reconcile-from-nothing), calling the `documentation` skill for each template, then runs `boundary-mapper` to populate `docs/boundaries/` and proposes modules from the boundaries it finds. Pillars are module-local (`docs/modules/{m}/pillars/`), created lazily through Brainstorming Mode — not scaffolded up front. Re-trigger `harness-manager` any time.
 
-This bootstrap is the only step that runs **before** the harness exists. Everything else below assumes a baselined repo.
+This bootstrap is the only step that runs **before** the harness exists. Everything else below assumes a reconciled repo.
 
 ---
 
@@ -60,7 +60,7 @@ Before modifying code in an unfamiliar area:
 2. If **[`docs/OWNERSHIP_INDEX.md`](docs/OWNERSHIP_INDEX.md)** exists, check it for the owning feature doc (rolled up to its module) and read it before changes. Else glob `docs/{features,modules/*/features}/**/*.md` and check `owns` frontmatter.
 3. **Check [`docs/boundaries/`](docs/boundaries/)** — if your change touches a documented boundary (entity model, schema, API, auth, channels, …), read that boundary file first. A `CRITICAL`/`HIGH` boundary warrants the `introspect` skill before you start.
 4. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes
-5. In a graduated module, its `docs/modules/{m}/CLAUDE.md` auto-loads in that subtree — follow it.
+5. In a declared module, its `docs/modules/{m}/CLAUDE.md` auto-loads in that subtree — follow it.
 
 For the protocol on *writing* to memory (which file, what belongs there, what doesn't), see **Project Memory** below.
 
@@ -94,7 +94,7 @@ When implementing a plan, if you discover work that is important but outside the
 
 ## Doc Ownership
 
-Feature docs (in `docs/modules/{m}/features/`, or flat `docs/features/` if ungraduated) must include YAML frontmatter with `owns`, `touches`, and `depends_on` fields. Architecture docs describe cross-cutting patterns and don't own specific files; boundary docs own cross-cutting shapes, not file paths; operations docs describe procedures. Only feature docs need frontmatter.
+Feature docs (in `docs/modules/{m}/features/`, or flat `docs/features/` if the module isn't declared) must include YAML frontmatter with `owns`, `touches`, and `depends_on` fields. Architecture docs describe cross-cutting patterns and don't own specific files; boundary docs own cross-cutting shapes, not file paths; operations docs describe procedures. Only feature docs need frontmatter.
 
 The spec-mode agent checks for ownership conflicts during research. If conflicts are found, address them in the spec before proceeding.
 
@@ -150,4 +150,4 @@ 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` and `docs/README.md` to match. When you move or rename source files: fix the `owns`/`touches` frontmatter in the owning doc; new docs that own code need `owns`/`touches`/`depends_on`.
-- Before creating changelogs, feature docs, or plans: ensure docs are baselined (`docs/memory/index.md` exists); if not, prompt to baseline first.
+- Before creating changelogs, feature docs, or plans: ensure the repo is reconciled (`docs/structure.md` exists with a current `harness-version`); if not, invoke `harness-manager` first.

package/data/harnesses/code/agents/boundary-mapper.md

@@ -1,6 +1,6 @@
 ---
 name: boundary-mapper
-description: Application-boundary generator. Detects the project's stack and information architecture, then baselines / creates / updates the typed boundary files in docs/boundaries/ (one file per boundary — Redux store shape, API surface, DB schema, wire contracts, tenancy, auth, the IA entity model, …). Each boundary is typed by the Application Boundary Scale and gets a severity that drives introspect's review depth. Pairs with the `boundaries` skill for the per-technology scale. Triggers on "baseline boundaries", "map application boundaries", "what are the boundaries here", "/boundary-mapper".
+description: Application-boundary generator. Detects the project's stack and information architecture, then baselines / creates / updates the typed boundary files in docs/boundaries/ (one file per boundary — Redux store shape, API surface, DB schema, wire contracts, tenancy, auth, the IA entity model, …). Each boundary is typed by the built-in Application Boundary Scale (carried inline) and gets a severity that drives introspect's review depth. Triggers on "baseline boundaries", "map application boundaries", "what are the boundaries here", "/boundary-mapper".
 tools: Read, Glob, Grep, Bash, Write, Edit
 model: inherit
 plugins: [nurix-harness]
@@ -16,7 +16,7 @@ boundary-mapper (generate)  →  introspect (pre-impl)  →  contract-monitor (p
 
 Introspect and contract-monitor both *consume* the boundary set; you *produce* it. Without you, boundary docs are hand-written and incomplete — the easy-to-miss ones (API surface, Redux store shape, the IA model) never get written because they read as "just how the app is built."
 
-You are the portable **process**. The `boundaries` skill holds the per-technology **knowledge** (the Application Boundary Scale). Read the skill before a run.
+You are the portable **process**, and you carry the per-technology **knowledge** inline — the Application Boundary Scale lives in [§ The Application Boundary Scale](#the-application-boundary-scale) below. Consult it before a run.
 
 ## Modes
 
@@ -26,7 +26,7 @@ You are the portable **process**. The `boundaries` skill holds the per-technolog
 
 ## Before starting
 
-1. Read the `boundaries` skill's Application Boundary Scale.
+1. Review [§ The Application Boundary Scale](#the-application-boundary-scale) below — the boundary types, doc-modes, and default severities for the stack you're about to detect.
 2. If `docs/memory/boundary-mapper.md` exists, read it for project-specific boundary exceptions and prior decisions.
 3. Detect the stack: read `package.json` (deps), lockfile, and skim the source tree. Map detected technologies to their boundary types via the scale.
 4. Detect the information architecture: read `docs/architecture/` (domain-model, ADRs), doctrine in any `docs/modules/*/pillars/`, and the entity/contract definitions (e.g. a `@org/contracts` package, `schema.ts`, `models.py`). The IA entity model is the flagship `domain`-category boundary.
@@ -47,6 +47,33 @@ The scale assigns each boundary type a **doc-mode**:
 
 Docs never outrank code. For `point` boundaries you mirror with `file:line`, you do not fork.
 
+## The Application Boundary Scale
+
+The per-technology knowledge you apply: each technology maps to its boundary types, a doc-mode, and a default severity (which drives `introspect`'s review depth). The dangerous boundaries are the **invisible** ones — a team documents "auth" but never "the Redux store shape" or "the entity model," because those read as *just how the app is built*. The scale names them so they can't hide.
+
+### domain (stack-independent — sourced from the IA, not `package.json`)
+
+| Boundary | Lives in | doc-mode | Severity | A change triggers |
+|---|---|---|---|---|
+| **information architecture** — entity model + topology (e.g. Brief→Plan→Persona→Audience→Match→Campaign→Run; service planes) | synthesized — ADRs / doctrine / contracts pkg | `transcribe` | **CRITICAL** | re-relating or renaming an entity ripples across *every* module; check all consumers, migrations, wire types |
+| **tenancy** — the workspace/tenant scoping invariant | query layer (a rule, not a file) | `transcribe` | **CRITICAL** | a missing scope = cross-tenant leak; audit every read/write path |
+
+### technology (detected from `package.json` + source)
+
+| Tech | Boundary | Lives in | doc-mode | Severity | A change triggers |
+|---|---|---|---|---|---|
+| `react-router` | route tree | router config (self-locating) | `point` | MED | deep-linking, auth guards, redirects, lazy boundaries |
+| `redux-toolkit` | composed store shape + **persisted keys** + selectors | spread across `store/` slices (no single file) | `transcribe` | HIGH | renamed/removed key breaks selectors + rehydration; persisted keys = CRITICAL |
+| `vite` | dev proxy list, `VITE_` env prefix, path aliases | `vite.config` (self-locating) | `point` | HIGH | a new backend mount must be added to the proxy list; env prefix governs what reaches the client |
+| `shadcn/ui` | `components.json`, generated `ui/` primitives, theme tokens | self-locating | `point` | LOW | `ui/` is generated — don't hand-edit, re-run the CLI; tokens in `:root`/`.dark` are the contract |
+| `express` | middleware order, error-handler position, response envelope, route surface | order/envelope = convention; routes self-locating | `transcribe` (order+envelope) / `point` (routes) | HIGH | order is parsers→custom→routes→error-handler-**last**; envelope `{status,message,data}` is the contract |
+| `django` | `settings.py` MIDDLEWARE order + INSTALLED_APPS, models, URLconf, DRF serializers | models/urls self-locating; middleware = convention | `point` + `transcribe` | HIGH (serializers/models CRITICAL) | serializer = wire contract; migration forward-only; middleware order changes request handling globally |
+| `fastapi` | Pydantic request/response models, APIRouter surface, `Depends` graph | schemas/routers self-locating | `point` | HIGH | a response-model change = wire-contract change; the dependency-injection graph shifts auth/session resolution |
+| `temporal` | workflow/activity signatures, signal/query names, task queues | workflow defs (self-locating) | `point` | HIGH | the starter references by name; a signature mismatch = stuck runs |
+| `@org/contracts` (shared wire types) | persisted shapes + envelopes shared across SPA/BFF/worker | the contracts package (self-locating) | `point` | CRITICAL | 3-way drift; update the package first, then consumers |
+
+Extend the scale by adding a row (and, for a new technology, a short pack: where its boundaries live + the safe-change checklist). Keep the instructions **technology-specific, never vague** — "middleware order is parsers→custom→routes→error-handler-last" beats "be careful with middleware." Only instantiate the boundary types the detected stack/IA actually exhibits; `log()` what you skipped and why.
+
 ## Boundary file anatomy
 
 Every file in `docs/boundaries/` follows this shape:
@@ -77,7 +104,7 @@ Write `docs/boundaries/README.md` as the index: list every boundary, its type, s
 ## Rules
 
 - **One file per boundary.** Don't bundle unrelated boundaries.
-- **Name the bounding modules** in every file — boundaries are the *edges* between module *nodes*; the boundary graph and the module graph share vertices.
+- **Name the bounding code units** in every file (paths / package names) — boundaries are the *edges* between module *nodes*. When those units are declared as modules, the boundary graph and the module graph coincide; until a module is declared the names are descriptive, not a broken link. The distinct vertices you name across all `Bounds` lines are the **module-discovery feed** `harness-manager` reads to propose modules — so name them precisely.
 - **Severity is load-bearing.** It feeds `introspect`'s review depth. Default CRITICAL for the IA model, DB schema, wire contracts, auth, tenancy; HIGH for API surface, Redux store, workflow signatures, env parity; MED for realtime channels. Adjust from the scale + project memory.
 - **Don't invent boundaries the repo doesn't have.** Only instantiate types the detected stack/IA actually exhibits. `log()` what you skipped and why.
 - **Read-only on production code.** You write only under `docs/boundaries/` and `docs/memory/boundary-mapper.md`.
@@ -85,7 +112,3 @@ Write `docs/boundaries/README.md` as the index: list every boundary, its type, s
 ## Strategy memory
 
 After a run you may append to `docs/memory/boundary-mapper.md` (git-tracked): project-specific boundary exceptions, where the IA model actually lives in this repo, stack quirks that change a doc-mode, recurring drift zones. Never user preferences (those are `~/.claude/`); never a transcription of a boundary's content (that's the boundary file). Date each entry `## YYYY-MM-DD — {topic}`.
-
-## Pair with the `boundaries` skill
-
-The skill owns the Application Boundary Scale (`technology → boundary-types → doc-mode → default-severity`, with per-technology packs for react-router, redux-toolkit, vite, shadcn/ui, express, django, fastapi, and the `domain` category for IA) and the boundary-file template. You drive detection and writing; the skill provides the knowledge. When unsure how a technology's boundaries are typed, defer to the skill's packs.

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

@@ -1,6 +1,6 @@
 ---
 name: brainstorm
-description: Brainstorming-mode facilitator. Use to open / drive / close 30k-foot strategic design conversations that mutate the pillars (doctrine, glossary, non-goals, references, inventory, decisions, backlog, milestones, questions, rejected). Pair with the `technical-brainstorm` skill for session lifecycle + pillar templates. Returns structured findings — does not write the harvest itself (the main agent routes findings by scope into the v9 doc tree).
+description: Brainstorming-mode facilitator — a thin orchestrator over the self-contained `technical-brainstorm` skill, which owns every session mechanic (the three modes, the tentative→committed lifecycle, the realignment cascade, the scope-routed harvest, the 10 pillar templates, greenfield rules). Use to recognize when a conversation belongs at the 30k-foot strategic-design altitude, enter the right mode, and drive it in the skill's voice. Triggers on an explicit ask to brainstorm/design strategically, or when a user utterance challenges a loaded pillar headline.
 tools: Read, Glob, Grep, AskUserQuestion, Write
 model: inherit
 plugins: [nurix-harness]
@@ -8,103 +8,36 @@ plugins: [nurix-harness]
 
 # Brainstorm Agent
 
-You are a 30,000-foot design facilitator. Your job is to mutate the **pillars** that steer this repo — doctrine, glossary, non-goals, references, inventory, decisions, backlog, milestones, open questions, rejected paths — through structured conversation, not to write production code or feature specs.
+You are the **facilitator persona** for Brainstorming Mode — the 30,000-foot peer of Spec and Plan. You shape the **pillars** that steer the repo (doctrine, glossary, non-goals, references, inventory, decisions, backlog, milestones, open questions, rejected paths) through conversation, never by writing production code or feature specs.
 
-You do NOT directly edit the live docs. You work in a transient session workspace and return structured findings the main agent harvests via the `technical-brainstorm` skill, routed by scope into the v9 doc tree.
+You are a **thin orchestrator.** Every mechanic — the session lifecycle, the three modes, the tentative→committed→rescinded lifecycle, the live-realignment cascade, the scope-routed harvest, the 10 pillar templates, the greenfield writing rules, and strategy memory — lives in the **`technical-brainstorm` skill**, which is self-contained and runs standalone via `/technical-brainstorm start|stop`. Your only jobs: recognize when a conversation belongs in Brainstorming Mode, enter the right mode, and drive it in the skill's voice. **Defer to the skill's `SKILL.md` for every mechanic — read it rather than re-deriving, and never restate its rules here.**
 
-## Before Starting
+## When to enter
 
-Anchor the session in the current repo state. In v9 the steering layer is dispersed — cross-module doctrine/glossary/non-goals live in `docs/architecture/`, module-local doctrine lives in each `docs/modules/{m}/pillars/`. There is no repo-wide `docs/pillars/`.
+- An explicit ask to think through a design at a strategic level (not "fix this bug" / "add this button").
+- A user utterance **challenges a loaded pillar headline.** To recognize this, hold the headlines in mind on entry — 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 it in plain English and ask whether the proposal preserves or revises it.
 
-1. Read `docs/architecture/domain-model.md`, `docs/architecture/glossary.md`, `docs/architecture/non-goals.md`, and any `docs/modules/*/pillars/` for the **headlines** (principle names + summaries; full term list; non-goal titles). Hold the headline summary in mind throughout the session.
-2. Read the most recent 2–3 ADRs in `docs/architecture/adr/` and any module-local `decisions.md` to calibrate decision-resolution depth.
-3. Read `docs/architecture/open-questions.md` for open questions that might already cover the user's concern.
-4. Skim `docs/boundaries/` (especially the `domain` boundary, `information-architecture.md`) so you recognize when a proposal touches a typed cross-module contract.
-5. If `docs/memory/brainstorm.md` exists, read it for strategy memory — recurring doctrine drift zones, productive framing patterns, lessons from prior sessions.
-6. Read 1–2 entries in `docs/history/plans/` if the conversation might shape one.
+If none of those steering files exist yet (a freshly-baselined repo), the session still runs from the skill's templates and the harvest creates the destinations on `/stop`.
 
-If none of the v9 steering files exist yet (first-time brainstorm in a freshly-baselined repo), say so to the main agent — the session still runs from the `technical-brainstorm` skill's templates, and the harvest creates the destination files on `/stop`.
+## Be aware of all three modes
 
-Goal of pre-read: recognize when the user is *challenging a pillar* (use the headline, then fetch the full entry) vs. raising a fresh question.
+The mode is tracked in the session's `state.md` and switches **only on explicit user signal** — never on your own judgment. See the skill's **Modes** section for the full behavior of each; this is the awareness you orchestrate from:
 
-## What You Facilitate
+| Mode | Posture | In one line |
+|---|---|---|
+| **explore** (default) | Facilitator + Scribe | Capture concerns in the user's framing; no option-picking, no proactive recommendations. |
+| **decide** | Sparring partner | Entered on "let's decide / resolve / lock this in". Decisions land **tentative**; push back once on weak rationale, then accept. |
+| **step-back** | Critic | Read-only. Present the cumulative effect of decisions so far; offer commit / rescind on tentative items. |
 
-**Capture, don't push.** In Explore mode (the default), capture user concerns as questions in the user's framing. Don't restructure into A/B/C/D options until the user invites decide mode for a specific question.
+## How you facilitate
 
-**Surface relevant doctrine when conversation drifts.** If the user is proposing something that brushes against an existing pillar element, name it explicitly — *"this seems to touch P3 (Operationalize is the one verb) — does your proposal preserve that, or revise it?"*
+- **Speak plain English; codes live in the files.** Name a pillar item by what it *is*, never by a bare code (`Q3`, `D7`); append the code in parentheses only if traceability needs it.
+- **Capture, don't push** (explore): mirror the concern back, offer to capture it, write it in the user's framing.
+- **Tentative decisions block close.** At `/stop`, every `STATUS: tentative` decision must be committed / rescinded / converted-to-backlog first.
+- **Never write production code** while a session is open — load-bearing snippets are illustration only, inside the session workspace.
 
-**Track tentative-vs-committed state.** Decisions land as `STATUS: tentative` first. They become ADRs (or module-local `decisions.md` entries) only on commit. Cascades (`docs/architecture/` + boundary updates, backlog appends) wait for commit.
+You don't perform the harvest yourself. On close the skill routes findings **by scope** into the v9 doc tree (module pillars → `docs/modules/{m}/pillars/`, cross-module → `docs/architecture/`, IA / new cross-cutting contracts → `docs/boundaries/` via `boundary-mapper`, backlog → `docs/history/`). The skill's `## stop` section is the canonical harvest map — don't duplicate it.
 
-**Refuse to write production code.** While a session is open, you don't author files under `src/`, `packages/`, or any source path. Load-bearing snippets are allowed *only as illustration inside the session workspace*.
+## What you may write
 
-## What You Return
-
-Your output is structured for the main agent to harvest into the **v9 doc tree** via the `technical-brainstorm` skill's harvest mechanics. The harvest is **scope-routed, not single-target**: module-local doctrine/decisions/glossary stay in `docs/modules/{m}/pillars/`; anything cross-module escalates to `docs/architecture/`; a change to the information architecture becomes the `domain` boundary in `docs/boundaries/`; a committed 2+-module decision becomes an ADR. The main agent places each finding into the corresponding destination; you don't restructure.
-
-| Finding | Destination (v9, scope-routed) |
-|---|---|
-| **Doctrine update** — new principle, revised principle, or amendment | module-local → `docs/modules/{m}/pillars/doctrine.md`; cross-module → `docs/architecture/domain-model.md` |
-| **Glossary addition** — new term or revised meaning | module-local → `docs/modules/{m}/pillars/glossary.md`; cross-module → `docs/architecture/glossary.md` |
-| **Non-goal addition** — new scope decision (with re-evaluate trigger) | `docs/architecture/non-goals.md` |
-| **Reference addition** — external prior art | `docs/architecture/references.md` |
-| **Committed decision (2+-module)** — STATUS: committed (not tentative) | `docs/architecture/adr/NNN-{slug}.md` |
-| **Committed decision (module-local)** — STATUS: committed | `docs/modules/{m}/pillars/decisions.md` |
-| **Backlog item** — work surfaced but not in current scope | `docs/history/backlog.md` (P0–P3, with discovering-session marker) |
-| **Rejected path** — alternative considered and chosen against | ADR §Alternatives if tied to a committed decision; else `docs/modules/{m}/pillars/rejected.md` |
-| **IA / entity-model change** — a change to how entities relate or where they live | the `domain` boundary `docs/boundaries/information-architecture.md` — flag for the `boundary-mapper` agent (don't hand-write the boundary file) |
-| **New cross-cutting contract** — a contract multiple modules will touch | a typed boundary in `docs/boundaries/` — flag for the `boundary-mapper` agent |
-| **Open question** — not yet resolvable | `docs/architecture/open-questions.md` (with Resolution-lands-in pointer) |
-| **Milestone landmark** — material scope/structure change | `docs/architecture/` (mirror in `docs/structure.md §Health log` if structural) |
-| **Plan-shaped work** — implementation roadmap surfaced by the brainstorm | `docs/history/plans/YYYY-MM-DD-{slug}.md` (Status: Draft) using `documentation` skill §8 Plan template |
-
-Sections that aren't decision-derived (the prose of "let's think through this", clarifying questions, exploratory tangents) belong in the session workspace, not in the v9 doc tree.
-
-## Rules
-
-- **Read-only on production code and the live docs** (`docs/architecture/`, `docs/modules/*/pillars/`, `docs/boundaries/`). Never modify them directly. The main agent does harvest writes.
-- **Write tool is permitted ONLY for**:
-  - `./brainstorm/pillars/*` — the transient session workspace
-  - `./brainstorm/state.md` — session lifecycle + mode tracking
-  - `docs/memory/brainstorm.md` — strategy memory (see below)
-- **Be specific.** Include doctrine numbers (P3, P7), ADR numbers (ADR-006), glossary terms, file paths, function names where relevant.
-- **Be concise.** Return findings, not narratives.
-- **Refuse to close on tentative decisions.** If `STATUS: tentative` exists at `/stop`, surface them and ask the user to commit / rescind / convert-to-backlog first.
-
-## Pair with the `technical-brainstorm` skill
-
-The skill owns:
-- Pillar templates (the 10 files in `templates/`)
-- The session state machine (explore / decide / step-back modes)
-- Tentative-vs-committed decision lifecycle
-- Plan-doc versioning within a session
-- Live pillar realignment cascade (background, on commit)
-- Harvest destinations (where each pillar mutation flows on `/stop`)
-
-You drive the conversation; the skill provides the structural mechanics. When in doubt about file format or state transitions, defer to the skill's `SKILL.md`.
-
-## Strategy Memory
-
-After a brainstorm session, you may append to `docs/memory/brainstorm.md` to make future brainstorm runs more effective on this project. This file is git-tracked.
-
-**Record (project-strategy facts):**
-
-- Doctrine drift zones — areas where the user repeatedly proposes things that brush against existing principles (e.g., "doctrine drift is concentrated around the `audience` vocabulary — surface P2/P6 early when this topic comes up").
-- Productive framings — interview shapes that converged a question quickly (e.g., "for IA questions, walking through the entity from a user mental-model angle clarifies faster than starting from schema").
-- Pillar challenge patterns — phrasings that reliably indicate a challenge vs. a clarification (e.g., "`'but what if'` followed by a doctrine concept is almost always a challenge — propose mode entry").
-- Harvest pitfalls — situations where the harvest needed manual intervention (e.g., "when a doctrine update is genuinely cross-module, double-check it lands in `docs/architecture/domain-model.md` rather than a single module's pillar").
-
-**Never record:**
-
-- User preferences, communication style, feedback — those belong in `~/.claude/`.
-- Per-decision content — that belongs in the ADR or pillar file.
-- Anything tied to a single conversation or transient state.
-
-Format each entry with a date header and one-line topic, oldest at bottom:
-
-```
-## YYYY-MM-DD — {topic}
-
-{1-3 lines of strategy fact, with pillar references where relevant}
-```
-
-Before writing, read the existing file and check whether the entry duplicates or supersedes a prior one — update in place rather than appending duplicates.
+The transient session workspace only (`./brainstorm/pillars/*`, `./brainstorm/state.md`) and strategy memory (`docs/memory/brainstorm.md`, per the skill's **Strategy memory** section). Never edit the live docs directly — the harvest does that.

package/data/harnesses/code/agents/harness-manager.md

@@ -0,0 +1,144 @@
+---
+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
+plugins: [nurix-harness]
+---
+
+# 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, v10, …); 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 — "make this tree match v10" — idempotent, detecting old-shape artifacts to know what to *move* versus *create*. You do **not** maintain or replay an ordered `v8→v9→v10` 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 nurix-harness`) 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`; if absent or behind the installed version, converge `docs/` to the installed shape and stamp the new version. 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, broken `owns` globs, routing drift, a boundary file drifted from its source). 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 boundary graph implies them).
+
+You never edit a doc for content fidelity (that is `maintenance`); `maintenance` never reshapes the structure to a new version (that is you).
+
+## Before starting
+
+1. Resolve the **installed harness version** — the design epoch this plugin ships (currently `10`). It is the target.
+2. Read the repo's **current version** — the `harness-version` field in `docs/structure.md` frontmatter. Absent ⇒ the repo is unharnessed ⇒ baseline (reconcile from nothing). Equal to installed ⇒ nothing to do (report and stop, unless Health was asked). Behind ⇒ reconcile forward.
+3. 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
+├── OWNERSHIP_INDEX.md      # Generated: code path → owning feature doc
+├── 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 with ownership 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)
+├── boundaries/            # Typed application boundaries — generated by boundary-mapper
+├── 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 (routing, ownership index, memory, frontmatter `depends_on`, cross-doc links).
+
+### 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` | one file per boundary under `docs/boundaries/` (then run `boundary-mapper`) |
+| 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/` |
+| 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; add ownership frontmatter to feature docs (call the `documentation` skill's **frontmatter derivation** for `owns`/`touches`/`depends_on`); 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/README.md`, `docs/structure.md` (with `harness-version`), `docs/history/CHANGELOG.md`, `docs/history/backlog.md`, `docs/memory/index.md`, `docs/memory/main.md`, `docs/OWNERSHIP_INDEX.md`, and the repo-root `README.md` (filled from the real lockfile/scripts/layout — **never overwrite an existing root README**).
+
+### Step 5 — Stamp the version
+
+Write `harness-version: <installed epoch>` into `docs/structure.md` frontmatter. This single field is the repo's baseline-and-version sentinel — there is no second marker.
+
+### Step 6 — Seed modules from boundaries, then run boundary-mapper
+
+Invoke **`boundary-mapper`** to populate `docs/boundaries/` (it detects the stack + IA). Then **propose modules from the boundaries** — modules are *declared*, never inferred from physical layout:
+
+- Read the distinct vertices named across every `docs/boundaries/*` **Bounds** line (e.g. `apps/api`, `@acme/contracts`). These are the repo's bounded contexts, already enumerated.
+- Propose them as candidate modules. For each, partition existing flat feature docs by `owns`-glob overlap.
+- **Propose — don't force.** Declaration is opt-in: a single-context app stays flat; declare `docs/modules/{m}/` only when the author accepts a context as a module. A module is tied to code by its `owns` globs, **layout-blind** — a workspace is not a module (one workspace may hold several contexts; one context may span workspaces).
+
+### Step 7 — Verify
+
+Confirm all mandated files exist; `structure.md` carries the current `harness-version`; no dead links in `docs/README.md`; every plan has a `Status:`; feature docs have ownership frontmatter; `OWNERSHIP_INDEX.md` rows match frontmatter on disk; 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 behind/absent → recommend Reconcile.
+- **Scaffold completeness** — every mandated file present.
+- **Dissolved-version residue** — any `operations/guardrails.md`, repo-wide `docs/pillars/`, `architecture/overview.md`, or other old-shape artifact lingering.
+- **Module declaration coverage** — do the boundary `Bounds` vertices 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 boundary vertices + `owns` globs; never from `pnpm-workspace.yaml`/workspace walls. Propose, don't force.
+- **You orchestrate; 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.
+
+## 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/agents/maintenance.md

@@ -22,7 +22,7 @@ Out of scope (handled by sibling components):
 
 ## Step 0: Regenerate Ownership Index
 
-If `./scripts/build-ownership-index.sh` exists, run it to regenerate `./docs/OWNERSHIP_INDEX.md` from feature doc frontmatter. The script is the primary path — bash-3 compatible, idempotent, CI-friendly.
+If `./.claude/scripts/build-ownership-index.sh` exists, run it to regenerate `./docs/OWNERSHIP_INDEX.md` from feature doc frontmatter. The script is the primary path — bash-3 compatible, idempotent, CI-friendly. (It resolves the repo root from its own location, so it works installed under `.claude/scripts/`.)
 
 If the script doesn't exist, build the index inline:
 

package/data/harnesses/code/scripts/build-ownership-index.sh

@@ -4,7 +4,16 @@
 
 set -euo pipefail
 
-REPO_ROOT="$(cd "$(dirname "$0")/.." && pwd)"
+# Resolve the repo root from this script's own location — it lives at either
+# <root>/scripts/ (kit source) or <root>/.claude/scripts/ (installed into a
+# project). Strip whichever suffix applies; works regardless of git or cwd,
+# and stays correct when the harness sits in a monorepo subdirectory.
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+case "$SCRIPT_DIR" in
+    */.claude/scripts) REPO_ROOT="${SCRIPT_DIR%/.claude/scripts}" ;;
+    */scripts) REPO_ROOT="${SCRIPT_DIR%/scripts}" ;;
+    *) REPO_ROOT="$(dirname "$SCRIPT_DIR")" ;;
+esac
 OUTPUT="$REPO_ROOT/docs/OWNERSHIP_INDEX.md"
 FEATURES_DIR="$REPO_ROOT/docs/features"
 TMP_OWNS=$(mktemp)
@@ -81,7 +90,7 @@ cat > "$OUTPUT" << 'HEADER'
 # Ownership Index
 
 > **Generated file** — do not edit manually.
-> Regenerate with: `bash scripts/build-ownership-index.sh`
+> Regenerate with the `build-ownership-index.sh` script (the maintenance agent runs it).
 
 Machine-readable lookup table generated from feature doc frontmatter.
 

package/data/harnesses/code/scripts/check-doc-drift.sh

@@ -5,7 +5,16 @@
 set -euo pipefail
 
 DAYS="${1:-14}"
-REPO_ROOT="$(cd "$(dirname "$0")/.." && pwd)"
+# Resolve the repo root from this script's own location — it lives at either
+# <root>/scripts/ (kit source) or <root>/.claude/scripts/ (installed into a
+# project). Strip whichever suffix applies; works regardless of git or cwd,
+# and stays correct when the harness sits in a monorepo subdirectory.
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+case "$SCRIPT_DIR" in
+    */.claude/scripts) REPO_ROOT="${SCRIPT_DIR%/.claude/scripts}" ;;
+    */scripts) REPO_ROOT="${SCRIPT_DIR%/scripts}" ;;
+    *) REPO_ROOT="$(dirname "$SCRIPT_DIR")" ;;
+esac
 FEATURES_DIR="$REPO_ROOT/docs/features"
 TMP_OWNS=$(mktemp)
 TMP_STALE=$(mktemp)

package/data/harnesses/code/skills/documentation/SKILL.md

@@ -1,11 +1,13 @@
 ---
 name: documentation
-description: Create and maintain technical documentation. Use when the user asks to (1) baseline, audit, or reorganize docs — enforces the opinionated v9 structure (architecture, features, operations, history, memory; + boundaries/, modules/, tests/ as the repo grows) with ownership frontmatter and scaffold files, (2) document a feature or module, (3) create or update a changelog entry, (4) document data flows or Redux state, (5) add to protected files, (6) provide the generic boundary-file template (typed-boundary *generation* is the `boundary-mapper` agent + `boundaries` skill, not this skill), (7) record an architecture decision (ADR), (8) create or update the project root README, (9) create or update a plan, or (10) co-author any technical doc. Triggers on "document this", "create docs", "update changelog", "baseline docs", "audit docs", "add to protected files", "ADR", "architecture decision", "root README", "plan".
+description: Template & generator library for technical docs — the skill agents call to produce a doc from a template. Use to (1) document a feature or module, (2) create or update a changelog entry, (3) document data flows or Redux state, (4) add to protected files, (5) provide the generic boundary-file template (typed-boundary *generation* is the `boundary-mapper` agent), (6) record an architecture decision (ADR), (7) create or update the project root README, (8) create or update a plan, (9) derive ownership frontmatter (`owns`/`touches`/`depends_on`) from code, (10) scaffold a standard doc (README, structure.md, CHANGELOG, backlog, memory, OWNERSHIP_INDEX) from its template, or (11) co-author any technical doc. Baselining / reconciling a repo's docs to the installed harness version is the **`harness-manager` agent** (which calls this skill for each template) — this skill does not orchestrate baseline. Triggers on "document this", "create docs", "update changelog", "add to protected files", "ADR", "architecture decision", "root README", "plan", "feature doc".
 plugins: [nurix-harness]
 ---
 
 # Technical Documentation Skill
 
+**This skill is a template & generator library, not an orchestrator.** It supplies the templates, the frontmatter-derivation generator, and the co-authoring workflow that *agents* call to produce individual docs. It does **not** baseline, audit, or reconcile a repo's doc tree — that is the **`harness-manager` agent**, which calls this skill for each template it scaffolds. Reach here to generate *one* doc from a template; reach for `harness-manager` to bring a whole repo into shape.
+
 Document contracts and architecture, not implementation details. Show function signatures and API shapes — never paste full implementations (they rot fast). Use ASCII diagrams over prose for flows. Only document state at persistence boundaries (Redux persistence, DB schemas, API shapes), not component-level or transient state. Mark deprecated fields with `// UNUSED:` comments. Breaking changes belong in changelogs only, not module docs.
 
 **No redirect docs.** When moving a doc to a new location, delete the old file entirely. Update all references (routing, ownership index, memory files, frontmatter `depends_on`, cross-doc links) to point to the new path. Never leave a stub file that says "Moved to X" — redirect docs rot, clutter the repo, and create false search hits.
@@ -17,7 +19,7 @@ Document contracts and architecture, not implementation details. Show function s
 ```
 User request
     │
-    ├─ "Baseline/audit docs" ──────────▶ Baseline Audit (below)
+    ├─ "Baseline/reconcile docs" ──────▶ harness-manager agent (it calls this skill per template)
     │
     ├─ "Document feature/module" ──────▶ Module Template
     │
@@ -44,123 +46,7 @@ User request
 
 ---
 
-## Baseline Audit
-
-When asked to "baseline", "audit", or "review" docs, enforce the canonical v9 documentation structure. This is an opinionated reorganization — the target structure is non-negotiable.
-
-### Target Structure
-
-```
-docs/
-├── README.md              # Documentation root — quick links table, section index
-├── structure.md           # Authority map, folder rules, health log
-├── routing.md             # File-pattern → module/doc/agent map (scaled — see CLAUDE.md)
-├── OWNERSHIP_INDEX.md      # Generated: code path → owning feature doc
-├── architecture/          # Cross-module design + the steering layer
-│   │                      #   domain-model, glossary, non-goals, references, open-questions
-│   └── adr/               # Architecture Decision Records (numbered, immutable)
-├── features/              # Flat default — feature specs with ownership frontmatter
-│   └── {feature}/         # Subfolder for deep features (e.g., editor/)
-├── modules/               # Graduation (≥2 bounded contexts) — NOT scaffolded at baseline
-│   └── {module}/          #   CLAUDE.md + features/ + pillars/ (module-local doctrine, lazy)
-├── boundaries/            # Typed application boundaries — generated by boundary-mapper
-├── operations/            # Setup, development, deployment, CI/CD
-├── history/               # Frozen/append-only records
-│   ├── CHANGELOG.md       # Master changelog index
-│   ├── changelog/         # Individual changelog entries
-│   ├── plans/             # Historical implementation plans (Status field required)
-│   └── backlog.md         # Tracked work items by priority (P0-P3)
-├── memory/                # Agent memory files (index.md = baseline record)
-└── tests/                 # Test plans and automation docs (optional)
-```
-
-There is **no repo-wide `docs/pillars/`** (dissolved in v9 — pillars are module-local). `docs/boundaries/` is populated by the `boundary-mapper` agent (which the bootstrap runs immediately after this baseline), and `docs/modules/` appears only when the repo graduates to ≥2 bounded contexts — neither is scaffolded here. `docs/tests/` is optional and **author-maintained**: no agent, skill, or script owns it — create it only if test-plan or test-automation docs already exist, and never scaffold it empty.
-
-### Workflow
-
-**Step 1: Inventory existing docs**
-
-Glob all markdown files in the repo. Categorize each file:
-
-| Category | Matches | Target |
-|----------|---------|--------|
-| Architecture | System design, patterns, config, API specs, tech decisions | `docs/architecture/` |
-| Features | How a feature works, user-facing behavior, data models | `docs/features/` |
-| Operations | Setup, dev workflow, deployment, CI/CD, runbooks | `docs/operations/` |
-| Plans | Implementation plans, proposals, RFCs | `docs/history/plans/` |
-| Changelogs | Change records, release notes | `docs/history/changelog/` |
-| Backlogs/Tasks | Work items, TODOs, tech debt | Merge into `docs/history/backlog.md` |
-| Stale/Deprecated | Self-marked deprecated, fully superseded, empty docs | Delete |
-| Root docs | `README.md`, `CLAUDE.md`, `AGENTS.md` | Stay in root |
-
-**Step 2: Detect duplicates and overlaps**
-
-For each topic, identify all files covering it. Keep the most complete version as canonical. Extract unique content from others before deleting.
-
-**Step 3: Present reorganization plan**
-
-Present a table to the user:
-
-```
-| File | Action | From | To | Reason |
-```
-
-Actions: `Move`, `Merge into {target}`, `Delete`, `Keep`, `Create`
-
-Ask: "Approve this plan? I'll execute all moves, merges, and deletions."
-
-**Step 4: Execute reorganization**
-
-After approval:
-
-1. Create the full folder structure:
-   - `docs/architecture/`
-   - `docs/features/`
-   - `docs/operations/`
-   - `docs/history/plans/`
-   - `docs/history/changelog/`
-   - `docs/memory/`
-   - `docs/tests/` (if test docs exist)
-2. Move files per the plan
-3. Merge content where specified (extract unique content, append to target)
-4. Delete stale/superseded files
-5. Add `Status: Complete | In Progress | Draft | Abandoned` to all plan files
-6. Add YAML frontmatter to feature docs (see Frontmatter Derivation below)
-7. Merge scattered backlog/task files into `docs/history/backlog.md`
-8. Scaffold standard files if missing:
-   - `docs/README.md` — from template (see `references/templates.md`)
-   - `docs/structure.md` — from template (see `references/templates.md`)
-   - `docs/history/CHANGELOG.md` — master changelog index (header + table linking to entries)
-   - `docs/history/backlog.md` — work items by priority (P0-P3 sections, empty if nothing to merge)
-   - `docs/memory/index.md` — agent memory index (empty scaffold with section headers)
-   - `docs/memory/main.md` — main agent project memory (empty header + date marker)
-   - `docs/OWNERSHIP_INDEX.md` — generated table of feature doc ownership. Build it now from the frontmatter you derived in Step 6 (same shape the maintenance agent regenerates each run — see `references/templates.md`)
-   - `README.md` (repo root) — from §11 in `references/templates.md`, filled with concrete details from the repo (real package manager from the lockfile, real scripts, real layout). **Never overwrite an existing root README** — if one is present, leave it untouched.
-9. Fix all internal links broken by moves
-10. Record baseline in `docs/memory/index.md` with today's date (see template)
-
-**Step 5: Verify**
-
-1. Confirm all standard files exist: `docs/README.md`, `docs/structure.md`, `docs/history/CHANGELOG.md`, `docs/history/backlog.md`, `docs/memory/index.md`, `docs/memory/main.md`, `docs/OWNERSHIP_INDEX.md`, `README.md` (repo root — must exist; either pre-existing untouched or freshly scaffolded). `docs/boundaries/` is the `boundary-mapper` agent's responsibility (the bootstrap runs it right after this baseline), not a scaffold target here.
-2. Confirm no dead links in `docs/README.md`
-3. Confirm every plan file has a `Status:` field
-4. Confirm feature docs have ownership frontmatter
-5. Confirm `docs/OWNERSHIP_INDEX.md` rows match the frontmatter on disk (no orphans, no missing entries)
-6. Confirm no docs remain outside the v9 structure (except the docs-root files `README.md`, `structure.md`, `routing.md`, `OWNERSHIP_INDEX.md`)
-7. Confirm duplicates are eliminated — each topic has one canonical source
-
-### Rules
-
-- The v9 structure is mandatory. No `docs/guides/`, `docs/core/`, `docs/editor/`, `docs/pt/`, no repo-wide `docs/pillars/` (dissolved in v9 — pillars are module-local under `docs/modules/{m}/pillars/`), or any other top-level folder beyond the v9 set
-- Guides about how-to-run → `operations/`. Guides about a feature → `features/`
-- A genuine bounded context graduates to `docs/modules/{m}/` (owning `features/` + `pillars/`); ungraduated feature docs stay flat under `docs/features/` (deep features may nest, e.g. `docs/features/editor/`)
-- Only `CLAUDE.md`, `AGENTS.md`, and `README.md` are allowed in the repository root (not inside `docs/`)
-- Root-level `README.md` is for humans. `docs/README.md` is the agent/doc entry point
-- One canonical source per topic — link, don't copy
-- **No redirect docs** — when moving a file, delete the original and fix all references. Never leave a "Moved to X" stub.
-- For 10+ files, use parallel sub-agents (5-8 files each)
-
-### Naming & Lifecycle
+## Naming & Lifecycle
 
 - Features: `kebab-case.md` — living reference, status `Active`
 - Plans: `YYYY-MM-DD-kebab-case.md` — frozen after `Complete` or `Abandoned`

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

@@ -76,9 +76,14 @@ See [CLAUDE.md](../CLAUDE.md) for documentation guidelines.
 Use for: defining which folder owns which topic and how docs are maintained.
 
 ```
+---
+harness-version: 10
+---
+
 # 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 design epoch on every reconcile.
 
 ## Authority Map
 
@@ -89,7 +94,7 @@ Each topic has one canonical location. Read from here, not from plans or changel
 | System architecture + steering | `docs/architecture/` | domain-model, glossary, non-goals, references, adr/ |
 | Feature behavior | `docs/features/` (or `docs/modules/{m}/features/`) | {key files} |
 | Cross-module contracts | `docs/boundaries/` | one file per boundary (maintained by `boundary-mapper`) |
-| Bounded contexts (graduated) | `docs/modules/{m}/` | `features/` + `pillars/` |
+| Declared modules (bounded contexts) | `docs/modules/{m}/` | `features/` + `pillars/` |
 | Setup & development | `docs/operations/` | {key files} |
 | Historical plans | `docs/history/plans/` | YYYY-MM-DD-name.md |
 | Change records | `docs/history/changelog/` | Individual entries |
@@ -108,7 +113,7 @@ Plan (Status: Draft) → Implementation → Feature Doc or Architecture Update
 - `docs/features/`: Living reference for implemented features. Each spec includes YAML frontmatter with `owns`, `touches`, `depends_on` fields declaring code ownership.
 - `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/boundaries/`: Horizontal typed application boundaries — one file per cross-module contract. Generated/maintained by the `boundary-mapper` agent; read before touching a shape it defines.
-- `docs/modules/{m}/`: Vertical bounded contexts (a graduation at ≥2 contexts). Each owns `features/` + module-local `pillars/` (doctrine, lazy). There is no repo-wide `docs/pillars/`.
+- `docs/modules/{m}/`: Vertical bounded contexts, **declared** (not inferred from layout) and tied to code by their `owns` globs. 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/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.
@@ -289,7 +294,7 @@ Auto-generated by the maintenance agent (Step 0). Do not edit by hand.
 
 ## 5. Boundary File (docs/boundaries/{boundary}.md)
 
-> **This skill does not generate boundaries.** Typed-boundary generation is owned by the **`boundary-mapper`** agent (detects the stack + IA, emits typed files) and the **`boundaries`** skill (the per-technology Application Boundary Scale). The baseline does **not** scaffold `docs/boundaries/` — `boundary-mapper` runs right after the baseline ("baseline boundaries"). This section is the generic **boundary-file template** plus the guidance for *recognizing* what deserves a boundary.
+> **This skill does not generate boundaries.** Typed-boundary generation is owned by the **`boundary-mapper`** agent, which detects the stack + IA and applies its built-in Application Boundary Scale to emit typed files. The baseline does **not** scaffold `docs/boundaries/` — `boundary-mapper` runs right after the baseline ("baseline boundaries"). This section is the generic **boundary-file template** plus the guidance for *recognizing* what deserves a boundary.
 
 ### What deserves a boundary
 

package/data/harnesses/code/skills/technical-brainstorm/SKILL.md

@@ -11,6 +11,8 @@ Plan and design before building. While a session is active, capture concerns, hy
 
 The user's job is to prevent eager coding. The skill's job is to make the planning conversation feel like a conversation — not an interview, not a decision-extraction funnel.
 
+**This skill is self-contained.** It runs a complete brainstorming session on its own through the two subcommands below — the `brainstorm` agent is an optional *thin orchestrator* that recognizes when to enter Brainstorming Mode and otherwise defers entirely here. Everything a session needs lives in this file and its `templates/` + `greenfield.md` siblings: the three modes, the tentative→committed lifecycle, the realignment cascade, the scope-routed harvest, the 10 pillar templates, the greenfield rules, and strategy memory. Nothing here depends on the agent.
+
 ## Two subcommands. That's it.
 
 - `/technical-brainstorm start` — open a session
@@ -328,7 +330,7 @@ The session is now in **Explore mode**. Resolution-style flows are opt-in from h
    | `./brainstorm/pillars/questions.md` (still-open) | `docs/architecture/open-questions.md` (each carries a *Resolution lands in* pointer) |
    | Plan docs (`NN-*.md` in session root) | `docs/history/plans/YYYY-MM-DD-{slug}.md` (Status: Draft), using the `documentation` skill's §8 Plan template |
 
-   Append a harvest changelog entry at `docs/history/changelog/YYYY-MM-DD-brainstorm-harvest-{slug}.md` listing what got written where. Then run `scripts/build-ownership-index.sh` and `scripts/check-doc-drift.sh` if present; surface any new findings.
+   Append a harvest changelog entry at `docs/history/changelog/YYYY-MM-DD-brainstorm-harvest-{slug}.md` listing what got written where. Then run `.claude/scripts/build-ownership-index.sh` and `.claude/scripts/check-doc-drift.sh` if present; surface any new findings.
 
 8. **If `./plan/sources/` exists,** offer to delete it (per its README marker). Default to keep if unclear.
 
@@ -596,6 +598,27 @@ Plus **plan docs** at the top level — `01-foo.md`, `02-bar.md`, ... — domain
 
 ---
 
+## Strategy memory
+
+After a session you may append to `docs/memory/brainstorm.md` (git-tracked) to make future brainstorming on this project more effective. This is the brainstorming process's own memory — it applies whether the session was driven standalone or via the `brainstorm` agent.
+
+**Record (project-strategy facts):**
+
+- **Doctrine drift zones** — topics where the user repeatedly proposes things that brush an existing principle (e.g. "drift concentrates around the `audience` vocabulary — surface the read-only-agent principle early here").
+- **Productive framings** — interview shapes that converged a question quickly (e.g. "for IA questions, walking the entity from a user's mental model clarifies faster than starting from schema").
+- **Pillar-challenge patterns** — phrasings that reliably signal a challenge vs. a clarification.
+- **Harvest pitfalls** — where the scope-routed harvest needed manual intervention (e.g. a genuinely cross-module doctrine update must land in `docs/architecture/domain-model.md`, not a single module's pillar).
+
+**Never record:** user preferences / communication style (those are `~/.claude/`); per-decision content (that's the ADR or pillar file); anything tied to a single conversation or transient state.
+
+Format each entry oldest-at-bottom, and read the file first so you update in place rather than duplicating:
+
+```
+## YYYY-MM-DD — {topic}
+
+{1–3 lines of strategy fact, with pillar references where relevant}
+```
+
 ## Greenfield doctrine
 
 Loaded separately at `<skill-dir>/greenfield.md`. Read it before any sweep, gap detection, or stop — that's where the smell-words grep and the banned-patterns table live.

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

@@ -1,7 +1,7 @@
 ---
 name: kb-agi
 description: Self-improving knowledge-base harness — a CLAUDE.md router (interview → ask/contribute) over a flat Obsidian note-vault, with single-intent upkeep agents that keep the vault trustworthy and grow it from its own query logs.
-version: 0.1.0
+version: 0.10.0
 keywords:
   - harness
   - knowledge-base

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@nurix/etna",
-    "version": "0.3.2",
+    "version": "0.10.1",
     "description": "Bootstrap a project with a Nurix harness — installs a Claude Code plugin from the nurixlabs/skills marketplace and drops the harness's CLAUDE.md at the project root.",
     "type": "module",
     "bin": {

package/data/harnesses/code/skills/boundaries/SKILL.md

@@ -1,86 +0,0 @@
----
-name: boundaries
-description: The technology-aware Application Boundary Scale — the knowledge the boundary-mapper agent applies when generating docs/boundaries/. Maps each technology to its application boundaries (what ripples when touched), a doc-mode (point vs transcribe), and a default severity that drives introspect's review depth. Seeded for react-router, redux-toolkit, vite, shadcn/ui, express, django, fastapi, plus the stack-independent `domain` category (the information-architecture entity model). Use when baselining or extending a repo's boundary set, or when deciding whether a change touches a protected boundary.
-plugins: [nurix-harness]
----
-
-# Boundaries — the Application Boundary Scale
-
-A **boundary** is a horizontal cross-cutting contract that multiple modules touch. Touching it ripples outward, so it must be documented and protected. This skill is the *knowledge*; the `boundary-mapper` agent is the *process* that applies it to a repo, writing one file per boundary into `docs/boundaries/`.
-
-This skill exists because the dangerous boundaries are the invisible ones. A team writes a guardrail for "auth" but never for "the Redux store shape" or "the entity model" — because those read as *just how the app is built*. The scale names them so they can't hide.
-
-## Two categories
-
-| Category | Determined by | How `boundary-mapper` finds it |
-|---|---|---|
-| **technology** | the stack | detect from `package.json` + source tree |
-| **domain** | the product's information architecture, independent of stack | read ADRs, doctrine, the entity/contracts definitions — **not** stack detection |
-
-The **domain** boundary (the IA entity model) is usually the *highest-severity boundary in the whole repo* and is the cleanest bridge from Brainstorming Mode (which shapes the IA) to the boundary set (which `introspect`/`contract-monitor` enforce).
-
-## doc-mode: `point` vs `transcribe`
-
-- **`point`** — *self-locating* shapes a reader finds unaided (DB schema → `schema.ts`/`models.py`; routes → the router file). The boundary file is **pointer (`file:line`) + invariants + checklist**. Never transcribe — the code is source-of-truth and a copy rots on the next push/codegen.
-- **`transcribe`** — *synthesized* contracts with no single code home (the composed Redux store tree, the API response envelope, the IA relationship/topology, tenancy). Transcribe canonically; the boundary file then owns the shape and feature docs link up.
-
-## The scale
-
-Each entry: boundary type(s) · where it lives · doc-mode · default severity · what a change triggers.
-
-### domain (stack-independent)
-
-| Boundary | Lives in | doc-mode | Severity | A change triggers |
-|---|---|---|---|---|
-| **information architecture** — entity model + topology (e.g. Brief→Plan→Persona→Audience→Match→Campaign→Run; service planes) | synthesized — ADRs / doctrine / contracts pkg | `transcribe` | **CRITICAL** | re-relating or renaming an entity ripples across *every* module; check all consumers, migrations, wire types |
-| **tenancy** — the workspace/tenant scoping invariant | query layer (a rule, not a file) | `transcribe` | **CRITICAL** | a missing scope = cross-tenant leak; audit every read/write path |
-
-### technology
-
-| Tech | Boundary | Lives in | doc-mode | Severity | A change triggers |
-|---|---|---|---|---|---|
-| `react-router` | route tree | router config (self-locating) | `point` | MED | deep-linking, auth guards, redirects, lazy boundaries |
-| `redux-toolkit` | composed store shape + **persisted keys** + selectors | spread across `store/` slices (no single file) | `transcribe` | HIGH | renamed/removed key breaks selectors + rehydration; persisted keys = CRITICAL |
-| `vite` | dev proxy list, `VITE_` env prefix, path aliases | `vite.config` (self-locating) | HIGH | `point` | a new backend mount must be added to the proxy list; env prefix governs what reaches the client |
-| `shadcn/ui` | `components.json`, generated `ui/` primitives, theme tokens | self-locating | LOW | `point` | `ui/` is generated — don't hand-edit, re-run the CLI; tokens in `:root`/`.dark` are the contract |
-| `express` | middleware order, error-handler position, response envelope, route surface | order/envelope = convention; routes self-locating | `transcribe` (order+envelope) / `point` (routes) | HIGH | order is parsers→custom→routes→error-handler-**last**; envelope `{status,message,data}` is the contract |
-| `django` | `settings.py` MIDDLEWARE order + INSTALLED_APPS, models, URLconf, DRF serializers | models/urls self-locating; middleware = convention | `point` + `transcribe` | HIGH (serializers/models CRITICAL) | serializer = wire contract; migration forward-only; middleware order changes request handling globally |
-| `fastapi` | Pydantic request/response models, APIRouter surface, `Depends` graph | schemas/routers self-locating | `point` | HIGH | a response-model change = wire-contract change; the dependency-injection graph shifts auth/session resolution |
-| `temporal` | workflow/activity signatures, signal/query names, task queues | workflow defs (self-locating) | `point` | HIGH | the starter references by name; a signature mismatch = stuck runs |
-| `@org/contracts` (shared wire types) | persisted shapes + envelopes shared across SPA/BFF/worker | the contracts package (self-locating) | `point` | CRITICAL | 3-way drift; update the package first, then consumers |
-
-Extend the scale by adding a row (and, for a new technology, a short pack describing where its boundaries live and the safe-change checklist). The instructions must be **technology-specific, never vague** — "middleware order is parsers→custom→routes→error-handler-last" beats "be careful with middleware."
-
-## Boundary file template
-
-`boundary-mapper` writes one file per boundary using this shape:
-
-```markdown
-# <Boundary name>
-
-[BOUNDARY: <type> · <CRITICAL|HIGH|MED|LOW>]
-
-**Bounds.** <which modules / planes sit on each side>
-
-## Shape
-<transcribed contract, OR a `file:line` pointer with one-line orientation>
-
-## Invariants
-<what must hold>
-
-## Blast radius
-<what breaks, and where, if violated>
-
-## Safe-change checklist
-- [ ] <step>
-- [ ] <step>
-```
-
-`docs/boundaries/README.md` indexes every boundary (name · type · severity) and records which technology packs are active.
-
-## How the pieces connect
-
-- `boundary-mapper` (agent) detects the stack + IA and applies this scale to write `docs/boundaries/`.
-- `introspect` (skill) reads `docs/boundaries/` before implementation; the boundary **severity** sets its review depth.
-- `contract-monitor` (agent) scans the live codebase against `docs/boundaries/` after changes land, per boundary type.
-- The **maintenance** agent flags when a boundary file drifts from code; `boundary-mapper` update-mode fixes it.