@nurix/etna 0.3.6 → 0.12.1

package/data/harnesses/code/skills/{technical-brainstorm → brainstorm}/README.md

@@ -1,4 +1,4 @@
-# technical-brainstorm
+# brainstorm
 
 A Claude Code skill for **structured design of unbuilt software**. It enforces a deliberate plan-before-code phase, captures decisions and open questions in a persistent registry of pillar documents, and refuses to write production code while a session is open.
 
@@ -15,7 +15,7 @@ The default failure mode of an AI assistant on a fresh problem is to **start typ
 - Architecture that drifts because no one tracked the "why".
 - Re-work when the next session forgets context the previous one had.
 
-`technical-brainstorm` inverts this. While a session is open, the skill behaves as a **design facilitator** — not a coder. It asks structured questions, records answers into named files, and uses a state file (`state.md`) to remember across conversations whether a session is active. Code authoring is **blocked** outside the brainstorm folder; small load-bearing snippets are allowed only as illustration inside it.
+`brainstorm` inverts this. While a session is open, the skill behaves as a **design facilitator** — not a coder. It asks structured questions, records answers into named files, and uses a state file (`state.md`) to remember across conversations whether a session is active. Code authoring is **blocked** outside the brainstorm folder; small load-bearing snippets are allowed only as illustration inside it.
 
 The output is not a single document. It is a **registry** — nine pillar files plus numbered plan docs — that survives across sessions and stays load-bearing because every entry has a *why*.
 
@@ -46,7 +46,7 @@ When the skill detects a bad fit during qualification, it asks the user before e
 In this repo (`etna`), the skill lives at:
 
 ```
-store/skills/technical-brainstorm/
+store/skills/brainstorm/
 ├── SKILL.md            # The skill definition Claude Code loads.
 ├── README.md           # This file.
 ├── greenfield.md       # Writing doctrine for greenfield architecture docs.
@@ -66,9 +66,9 @@ store/skills/technical-brainstorm/
 
 To use the skill in a project, place the folder at one of:
 
-- `~/.claude/skills/technical-brainstorm/` (user-wide install)
-- `<project>/.claude/skills/technical-brainstorm/` (project-scoped install)
-- A plugin under `<project>/plugins/<plugin>/skills/technical-brainstorm/`
+- `~/.claude/skills/brainstorm/` (user-wide install)
+- `<project>/.claude/skills/brainstorm/` (project-scoped install)
+- A plugin under `<project>/plugins/<plugin>/skills/brainstorm/`
 
 Claude Code loads any skill whose `SKILL.md` it can discover via its standard skill resolution.
 
@@ -79,8 +79,8 @@ Claude Code loads any skill whose `SKILL.md` it can discover via its standard sk
 The skill exposes exactly two subcommands. Everything else happens **within** an active session as natural conversation.
 
 ```
-/technical-brainstorm start    # open a session
-/technical-brainstorm close    # close a session
+/brainstorm start    # open a session
+/brainstorm close    # close a session
 ```
 
 There is no `sweep`, `check`, `resolve`, `init`, or `reinforce` subcommand. The skill reads `state.md` at the start of every turn to decide whether a session is open, and adapts behavior accordingly.
@@ -165,7 +165,7 @@ The skill refuses to write production code (in `src/`, `apps/`, `packages/`, etc
 
 If the user asks for production code, the skill says:
 
-> "We're in an active brainstorm session. I can sketch this inside `./plan/` as illustration, or you can run `/technical-brainstorm close` first if you want to start building. Which do you want?"
+> "We're in an active brainstorm session. I can sketch this inside `./plan/` as illustration, or you can run `/brainstorm close` first if you want to start building. Which do you want?"
 
 ### `close` — closing a session
 
@@ -180,7 +180,7 @@ If the user asks for production code, the skill says:
 4. Ask whether to address them now or close anyway.
 5. On confirmation, write `STATE: closed` to `state.md` with a one-line reason (milestone reached / paused / scope cut / handing off).
 6. If `./plan/sources/` exists, offer to delete it. Default to keep if unclear — they were copies; originals are untouched.
-7. Print: "Run `/technical-brainstorm start` to resume."
+7. Print: "Run `/brainstorm start` to resume."
 
 ---
 
@@ -232,7 +232,7 @@ LAST UPDATED: <ISO date>
 ```
 
 - `STATE: open` → in-session behavior applies (voices, refusal rules, topic-shift prompts).
-- `STATE: closed` → the skill does nothing on its own; only `/technical-brainstorm start` re-opens it.
+- `STATE: closed` → the skill does nothing on its own; only `/brainstorm start` re-opens it.
 - `CURRENT TOPIC` updates on every detected topic shift.
 - `LAST UPDATED` updates on every pillar write.
 
@@ -264,7 +264,7 @@ A few choices in this skill are deliberate and worth naming:
 
 **Why** is load-bearing. Every decision and every piece of feedback-style guidance carries a *why*. Without it, future-you can't judge edge cases — only blindly follow or blindly violate the rule.
 
-**The user prevents eager coding.** The skill is the assistant. The user controls when a session opens and closes. There is no "auto-open on natural language phrases like let's design" — that pattern has caused too many surprise refusals when the user just wanted to chat. The skill opens only on explicit `/technical-brainstorm start`.
+**The user prevents eager coding.** The skill is the assistant. The user controls when a session opens and closes. There is no "auto-open on natural language phrases like let's design" — that pattern has caused too many surprise refusals when the user just wanted to chat. The skill opens only on explicit `/brainstorm start`.
 
 **Reference implementations beat invented solutions.** If prior art exists for the problem, the skill prefers a one-line link in `references.md` over a re-derivation. Originality is not a virtue when shipping is the goal.
 
@@ -272,7 +272,7 @@ A few choices in this skill are deliberate and worth naming:
 
 ## Anti-features (what this skill deliberately doesn't do)
 
-- **No auto-invocation on natural language.** Phrases like "let's plan", "let's design", "let's think through X" do **not** trigger the skill. Only explicit `/technical-brainstorm start` and `/technical-brainstorm close` do.
+- **No auto-invocation on natural language.** Phrases like "let's plan", "let's design", "let's think through X" do **not** trigger the skill. Only explicit `/brainstorm start` and `/brainstorm close` do.
 - **No automatic semantic sweeps.** Sweeps run only when the user asks or when the skill recommends one after a major decision and the user agrees.
 - **No scheduled checkpoints.** Pillar reinforcement happens at natural topic boundaries — the only periodic prompt.
 - **No subcommand sprawl.** No `sweep`, `resolve`, `init`, `reinforce`, `check`. Two verbs total: `start` and `close`.
@@ -284,4 +284,4 @@ A few choices in this skill are deliberate and worth naming:
 
 - `greenfield.md` — writing doctrine for unbuilt-software docs.
 - `templates/` — pillar file templates, each with a prose introduction describing its format.
-- The `documentation` skill in this repo handles documentation of *built* systems (changelogs, ADRs, root READMEs). `technical-brainstorm` is its before-the-fact counterpart.
+- The `documentation` skill in this repo handles documentation of *built* systems (changelogs, ADRs, root READMEs). `brainstorm` is its before-the-fact counterpart.

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

@@ -1,11 +1,11 @@
 ---
-name: technical-brainstorm
-description: Structured planning/design session for software that hasn't been built yet. Invoked ONLY by explicit slash commands `/technical-brainstorm start` and `/technical-brainstorm stop`. Do NOT auto-invoke on natural-language phrases like "let's plan", "let's design", "let's think through X", or any other phrasing — those are not triggers. The skill maintains 10 pillar documents (questions, decisions, doctrine, glossary, inventory, non-goals, references, rejected, milestones, backlog) inside a `pillars/` subfolder, plus a top-level `state.md` tracking session open/closed AND the active mode (explore / decide / step-back). Refuses to write production code outside the brainstorm folder while a session is active.
+name: brainstorm
+description: Structured planning/design session for software that hasn't been built yet. Invoked ONLY by explicit slash commands `/brainstorm start` and `/brainstorm stop`. Do NOT auto-invoke on natural-language phrases like "let's plan", "let's design", "let's think through X", or any other phrasing — those are not triggers. The skill maintains 10 pillar documents (questions, decisions, doctrine, glossary, inventory, non-goals, references, rejected, milestones, backlog) inside a `pillars/` subfolder, plus a top-level `state.md` tracking session open/closed AND the active mode (explore / decide / step-back). Refuses to write production code outside the brainstorm folder while a session is active.
 argument-hint: "start | stop"
 plugins: [nurix-harness]
 ---
 
-# Technical Brainstorm
+# Brainstorm
 
 Plan and design before building. While a session is active, capture concerns, hypotheses, and decisions into a registry of pillar documents that survives across conversations.
 
@@ -15,8 +15,8 @@ The user's job is to prevent eager coding. The skill's job is to make the planni
 
 ## Two subcommands. That's it.
 
-- `/technical-brainstorm start` — open a session
-- `/technical-brainstorm stop` — stop a session
+- `/brainstorm start` — open a session
+- `/brainstorm stop` — stop a session
 
 Everything else happens **within** an active session, as natural conversation. There is no `sweep`, `check`, `resolve`, `init`, `reinforce`, `commit`, or `rescind` subcommand. The skill behaves correctly without ceremony — it reads `state.md` on every turn to know whether a session is open and what mode it is in, and adapts its voice and tool-use posture accordingly.
 
@@ -24,7 +24,7 @@ Everything else happens **within** an active session, as natural conversation. T
 
 ### Persistent pillars vs. session workspace (v9)
 
-In a v9-harnessed repo there is **no repo-wide `docs/pillars/`**. The persistent home of pillars is **dispersed by scope**: module-local doctrine / glossary / decisions live in each `docs/modules/{m}/pillars/`, and cross-module steering lives in `docs/architecture/` (`domain-model.md`, `glossary.md`, `non-goals.md`, `references.md`, `open-questions.md`). A change to the information architecture is captured as the `domain` boundary in `docs/boundaries/` (owned by the `boundary-mapper` agent, not written here).
+In a v9-harnessed repo there is **no repo-wide `docs/pillars/`**. The persistent home of pillars is **dispersed by scope**: module-local doctrine / glossary / decisions live in each `docs/modules/{m}/pillars/`, and cross-module steering lives in `docs/architecture/` (`domain-model.md`, `glossary.md`, `non-goals.md`, `references.md`, `open-questions.md`). A change to the information architecture is captured as the `domain` boundary in `docs/boundaries/` (owned by the `boundary` skill, not written here).
 
 Each brainstorming session still opens a **transient working copy** at `./brainstorm/pillars/` (repo root, not inside `docs/`) holding all ten pillar files — **that workspace and its templates are unchanged from v8**. On `/start` the working copy is *primed* from whatever dispersed v9 homes already exist (read the module pillars + the `docs/architecture/` steering files). The conversation mutates the working copy. On `/stop`, the harvest diffs the session pillars against the live docs and writes each change back **by scope** (see Harvest destinations in `## stop` below).
 
@@ -313,7 +313,7 @@ The session is now in **Explore mode**. Resolution-style flows are opt-in from h
 
 6. **Refuse close on tentative (v8).** If step 4 didn't resolve every `STATUS: tentative` decision (commit / rescind / convert-to-backlog), block close and return to the conversation. Harvest does not run with unresolved tentatives.
 
-7. **Harvest into the v9 doc tree.** The harvest is a structured diff between the session pillars (`./brainstorm/pillars/*`) and the live docs, **routed by scope** — module-local findings to `docs/modules/{m}/pillars/`, cross-module to `docs/architecture/`, IA/contract changes to `docs/boundaries/` (via `boundary-mapper`), backlog to `docs/history/`. There is no single target and no repo-wide `docs/pillars/`. For each kind of mutation, write to the matching destination:
+7. **Harvest into the v9 doc tree.** The harvest is a structured diff between the session pillars (`./brainstorm/pillars/*`) and the live docs, **routed by scope** — module-local findings to `docs/modules/{m}/pillars/`, cross-module to `docs/architecture/`, IA/contract changes to `docs/boundaries/` (via the `boundary` skill), backlog to `docs/history/`. There is no single target and no repo-wide `docs/pillars/`. For each kind of mutation, write to the matching destination:
 
    | Session source | v9 destination(s) |
    |---|---|
@@ -321,24 +321,24 @@ The session is now in **Explore mode**. Resolution-style flows are opt-in from h
    | `./brainstorm/pillars/glossary.md` | module-local → `docs/modules/{m}/pillars/glossary.md`; cross-module → `docs/architecture/glossary.md` |
    | `./brainstorm/pillars/non-goals.md` | `docs/architecture/non-goals.md` |
    | `./brainstorm/pillars/references.md` | `docs/architecture/references.md` |
-   | `./brainstorm/pillars/inventory.md` | `docs/architecture/` (and regenerate `docs/OWNERSHIP_INDEX.md` if subsystems changed) |
+   | `./brainstorm/pillars/inventory.md` | `docs/architecture/` |
    | Committed decisions (`STATUS: committed` in `./brainstorm/pillars/decisions.md`) | 2+-module → new `docs/architecture/adr/NNN-{slug}.md` (one ADR per cohesive theme); module-local → `docs/modules/{m}/pillars/decisions.md`. Rejected alternatives flow to ADR §Alternatives. |
-   | IA / entity-model change, or a new cross-cutting contract, surfaced by a committed decision | the `domain` boundary `docs/boundaries/information-architecture.md` (or a new typed boundary) — **flag for the `boundary-mapper` agent; don't hand-write the boundary file** |
+   | IA / entity-model change, or a new cross-cutting contract, surfaced by a committed decision | the `domain` boundary `docs/boundaries/information-architecture.md` (or a new typed boundary) — **flag for the `boundary` skill (`create`); don't hand-write the boundary file** |
    | `./brainstorm/pillars/backlog.md` (new items) | `docs/history/backlog.md` (P0–P3, full operational tracking) |
    | `./brainstorm/pillars/rejected.md` | ADR §Alternatives when tied to a committed decision; else `docs/modules/{m}/pillars/rejected.md` |
    | `./brainstorm/pillars/milestones.md` | `docs/architecture/` (mirror in `docs/structure.md §Health log` if the milestone is a structural change) |
    | `./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 `.claude/scripts/build-ownership-index.sh` and `.claude/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.
 
 8. **If `./plan/sources/` exists,** offer to delete it (per its README marker). Default to keep if unclear.
 
 9. **If versioned plan-doc drafts exist,** offer to prune older drafts. Default to keep.
 
-10. Delete the session folder (`./brainstorm/` or `./plan/` — whichever was used). The dispersed v9 homes (`docs/modules/*/pillars/`, `docs/architecture/`, and any `docs/boundaries/` flagged for `boundary-mapper`) are now updated; the next session primes from them.
+10. Delete the session folder (`./brainstorm/` or `./plan/` — whichever was used). The dispersed homes (`docs/modules/*/pillars/`, `docs/architecture/`, and any `docs/boundaries/` flagged for the `boundary` skill) are now updated; the next session primes from them.
 
-11. Print: "Run `/technical-brainstorm start` to resume."
+11. Print: "Run `/brainstorm start` to resume."
 
 ---
 
@@ -526,7 +526,7 @@ The skill **refuses to write production code** outside the brainstorm folder whi
 
 If the user asks for production code, say:
 
-> "We're in an active brainstorm session. I can sketch this inside `./plan/` as illustration, or you can run `/technical-brainstorm stop` first if you want to start building. Which do you want?"
+> "We're in an active brainstorm session. I can sketch this inside `./plan/` as illustration, or you can run `/brainstorm stop` first if you want to start building. Which do you want?"
 
 ---
 
@@ -568,7 +568,7 @@ CASCADE QUEUE:
 ```
 
 - `STATE: open` → in-session behavior applies.
-- `STATE: closed` → the skill does nothing on its own; `/technical-brainstorm start` re-opens it.
+- `STATE: closed` → the skill does nothing on its own; `/brainstorm start` re-opens it.
 - `MODE:` gates voice and tool-use posture (see "Modes" section).
 - Update `CURRENT TOPIC` on every detected topic shift.
 - Update `LAST UPDATED` on every pillar write.

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

@@ -1,14 +1,16 @@
 ---
 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` skill), (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) 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.
+**No redirect docs.** When moving a doc to a new location, delete the old file entirely. Update all references (routing, 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
     │
@@ -29,7 +31,7 @@ User request
     │
     ├─ "Add to protected files" ───────▶ Protected Files Template
     │
-    ├─ "Create/update a boundary" ─────▶ boundary-mapper agent (this skill holds only the boundary-file template)
+    ├─ "Create/update a boundary" ─────▶ boundary skill (this skill holds only the boundary-file template)
     │
     ├─ "Record architecture decision" ─▶ ADR 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`
@@ -237,6 +123,6 @@ For docs that don't match templates:
 
 | File | Use For |
 |------|---------|
-| `references/templates.md` | docs/README.md, structure.md, frontmatter, scaffolds (CHANGELOG, backlog, memory, OWNERSHIP_INDEX), boundary-file, feature, changelog, plan, protected files, ADR, project root README templates |
+| `references/templates.md` | docs/README.md, structure.md, frontmatter, scaffolds (CHANGELOG, backlog, memory), boundary-file, feature, changelog, plan, protected files, ADR, project root README templates |
 | `references/style-guide.md` | Writing rules, formatting conventions |
 | `references/examples.md` | Good vs bad documentation examples |

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
 
@@ -88,8 +93,8 @@ 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/` |
+| Cross-module contracts | `docs/boundaries/` | one file per boundary (maintained by the `boundary` skill) |
+| 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 |
@@ -107,8 +112,8 @@ 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/boundaries/`: Horizontal typed application boundaries — one file per cross-module contract. Generated/maintained by the `boundary` skill; read before touching a shape it defines.
+- `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.
@@ -267,29 +272,11 @@ Append entries below, oldest at bottom. Format:
 Memory file initialized during documentation baseline.
 ```
 
-### docs/OWNERSHIP_INDEX.md
-
-```
-# Ownership Index
-
-Auto-generated by the maintenance agent (Step 0). Do not edit by hand.
-
-**Generated:** {today}
-
-| Doc | Owns | Touches | Depends On |
-|-----|------|---------|------------|
-| [features/{name}.md](features/{name}.md) | `glob1`, `glob2` | `path` | `doc1`, `doc2` |
-
-## Unowned Docs
-
-{Feature docs missing frontmatter, listed here so they can be backfilled}
-```
-
 ---
 
 ## 5. Boundary File (docs/boundaries/{boundary}.md)
 
-> **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.
+> **This skill does not generate boundaries.** Typed-boundary generation is owned by the **`boundary`** skill (`generate` mode), which detects the stack + IA and applies its boundary taxonomy (`references/boundary-taxonomy.md`) to emit typed files. The baseline does **not** scaffold `docs/boundaries/` — `/boundary generate` 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
 
@@ -320,7 +307,7 @@ Test: "If an agent edits this while working on a single feature, could it silent
 
 ### How to research a boundary
 
-When mapping a boundary (the `boundary-mapper` agent's job — this guidance is shared), use sub-agents to investigate:
+When mapping a boundary (the `boundary` skill's `generate`/`create` job — this guidance is shared), investigate:
 
 1. **Shared state consumers** — For each Redux slice/context, find all files that read from it. Flag any file reading a slice it doesn't own (cross-module dependency).
 2. **String-coupled actions** — Grep for Redux action type strings referenced as raw strings rather than imported constants. These are invisible breakage points.
@@ -331,7 +318,7 @@ When mapping a boundary (the `boundary-mapper` agent's job — this guidance is
 
 ### Generic boundary-file template
 
-One file per boundary in `docs/boundaries/`. `boundary-mapper` emits typed files using the Application Boundary Scale; this is the generic fallback shape.
+One file per boundary in `docs/boundaries/`. The `boundary` skill emits typed files using its boundary taxonomy; this is the generic fallback shape.
 
 ```markdown
 # {Boundary Name}
@@ -558,7 +545,7 @@ Brief description of what changed and why.
 
 Use for: every implementation plan. Plans are created here directly with `Status: Draft`, flip to `Status: In Progress` when work starts, and freeze at `Status: Complete` or `Status: Abandoned`. Once frozen, never edit — write a new dated plan if scope changes.
 
-The `introspect` skill parses the **Proposed Changes** sections to check boundary impact. Keep that structure stable — section headings and bullet shape are load-bearing for the parser.
+The `boundary` skill (`check` mode) parses the **Proposed Changes** sections to check boundary impact. Keep that structure stable — section headings and bullet shape are load-bearing for the parser.
 
 ```
 # {Feature Name}
@@ -595,7 +582,7 @@ Why this work is happening *now*. Link to the spec for *what* we're building; th
 ### Cross-Module Contracts Affected
 
 - List which boundaries (from `docs/boundaries/`) this plan touches by name
-- "None" is a valid answer and means introspect will pass cleanly
+- "None" is a valid answer and means the `boundary` check will pass cleanly
 
 ## Implementation Steps
 

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.12.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/agents/boundary-mapper.md

@@ -1,114 +0,0 @@
----
-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 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]
----
-
-# Boundary-Mapper Agent
-
-You generate and maintain `docs/boundaries/` — the repo's **typed application boundaries**. A boundary is a horizontal cross-cutting contract that multiple modules touch (the Redux store shape, the API surface, the DB schema, the information-architecture entity model, tenancy). You are the *front* of the boundary lifecycle:
-
-```
-boundary-mapper (generate)  →  introspect (pre-impl)  →  contract-monitor (post-impl)
-```
-
-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**, 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
-
-- **Baseline** — no `docs/boundaries/` yet. Detect the stack + IA, instantiate one file per boundary that exists.
-- **Create** — add a single new boundary doc.
-- **Update** — re-scan; refresh boundary files whose shape has drifted from code (the maintenance agent flags drift; you fix the boundary file).
-
-## Before starting
-
-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.
-
-## The two boundary categories
-
-| Category | Sourced from | Example |
-|---|---|---|
-| **technology** | stack detection (`package.json` + source) | redux-store, api-surface, db-schema, wire-contracts, realtime-channels, auth |
-| **domain** | the product's information architecture (ADRs, doctrine, contracts pkg) — *not* stack detection | the entity model + topology (the IA boundary), tenancy |
-
-## `point` vs `transcribe` — decide per boundary
-
-The scale assigns each boundary type a **doc-mode**:
-
-- **`point`** — *self-locating* shapes the agent (and any reader) finds unaided: DB schema → `schema.ts`/`models.py`; routes → the router file. Write a **pointer (`file:line`) + invariants + safe-change checklist**. Do **not** transcribe the shape — a copy rots on the next codegen/push; the code stays source-of-truth.
-- **`transcribe`** — *synthesized* contracts with no single code home: the Redux composed store tree (spread across slices), the API response envelope (a convention), the IA relationship/topology, tenancy. Transcribe these canonically into the boundary file. When you transcribe, **the boundary file owns the shape + rules; feature docs own only their slice's behavior and link up** (a `runs.md` says "adds runs slice keys X, Y — see `boundaries/redux-state.md`", it does not redescribe the store).
-
-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:
-
-```markdown
-# <Boundary name>
-
-[BOUNDARY: <type> · <CRITICAL|HIGH|MED|LOW>]
-
-**Bounds.** <which modules / planes sit on each side of this contract>
-
-## Shape
-<transcribed contract, OR a pointer: `packages/.../schema.ts:NN` with a one-line orientation>
-
-## Invariants
-<what must hold>
-
-## Blast radius
-<what breaks, and where, if violated>
-
-## Safe-change checklist
-- [ ] <step>
-- [ ] <step>
-```
-
-Write `docs/boundaries/README.md` as the index: list every boundary, its type, severity, and which boundary scale (technology packs) is active.
-
-## 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.
-- **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`.
-
-## 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}`.