@nurix/etna 0.3.6 → 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.3.5
+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

@@ -104,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`.

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/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, 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.

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.3.5
+version: 0.10.0
 keywords:
   - harness
   - knowledge-base

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@nurix/etna",
-    "version": "0.3.6",
+    "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": {