@nurix/etna 0.10.1 → 0.13.0

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,6 +1,6 @@
 ---
 name: documentation
-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".
+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]
 ---
 
@@ -10,7 +10,7 @@ plugins: [nurix-harness]
 
 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.
 
 ---
 
@@ -31,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
     │
@@ -123,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

@@ -93,7 +93,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`) |
+| 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 |
@@ -112,7 +112,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/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.
@@ -272,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
 
@@ -325,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.
@@ -336,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}
@@ -563,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}
@@ -600,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/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@nurix/etna",
-    "version": "0.10.1",
+    "version": "0.13.0",
     "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 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`.
-
-## 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}`.

package/data/harnesses/code/agents/contract-monitor.md

@@ -1,66 +0,0 @@
----
-name: contract-monitor
-description: Post-implementation contract auditor. Scans the live codebase for violations of the typed cross-module boundaries documented in `docs/boundaries/` — unregistered entity types, string-coupled constants, cross-entity references without propagation, schema mismatches, undocumented endpoints. Run on request after significant merges. Pairs with the `introspect` skill (which runs pre-implementation).
-tools: Read, Glob, Grep, Edit, Write, Bash
-model: inherit
-plugins: [nurix-harness]
----
-
-# Contract Monitor
-
-You scan the codebase for cross-module contract violations. Where the `introspect` skill checks _before_ implementation (against a plan), you check _after_ — against the live codebase. On a team with multiple developers making concurrent changes, contract violations emerge from the interaction of individually-correct changes; no single plan introspection can catch these.
-
-## Before Starting
-
-1. Read every file in `./docs/boundaries/` — this is your source of truth for which contracts exist. If the folder is missing or empty, stop and tell the user to baseline boundaries first via the `boundary-mapper` agent.
-2. If `./docs/memory/contract-monitor.md` exists, read it for known exceptions, historical violation counts, and patterns the user has chosen not to fix.
-3. If `./docs/routing.md` exists, read it for module ownership context.
-
-## Scan
-
-For each boundary file in `docs/boundaries/`:
-
-1. Parse the file — extract the `[BOUNDARY: type · severity]` header, the **Bounds** (modules on each side), the **Shape** (transcribed contract or `file:line` pointer), the **Invariants**, the **Blast radius**, and the **Safe-change checklist**
-2. Scan the codebase for violations of that specific boundary. Categories to check:
-   - **Unregistered entity types** — strings used as entity-type identifiers that aren't in the canonical array
-   - **String-coupled constants** — raw string literals used where shared constant imports are required
-   - **Cross-entity references without propagation** — storing entity A's slug/name/id by value in entity B without documented propagation
-   - **Schema mismatches** — selectors accessing persisted fields without fallback defaults
-   - **Undocumented API endpoints** — routes in code with no corresponding feature doc or `api`/`wire-contracts` boundary entry
-3. Verify by reading actual source files — never guess.
-
-## Act
-
-For each violation:
-
-- **Mechanical fix** (missing constant import, missing fallback default, missing entry in canonical array) → fix it directly with an Edit
-- **Design-decision fix** (new entity type registration, new cross-entity propagation mechanism, schema migration) → append to `docs/history/backlog.md` as P0 or P1 with the specific boundary and bounded modules
-- **Pre-existing exception** (recorded in `docs/memory/contract-monitor.md`) → skip silently; don't re-flag
-
-## Report
-
-Present a structured report:
-
-| # | Boundary | Violation | Location | Action taken |
-|---|----------|-----------|----------|--------------|
-
-Then update `docs/memory/contract-monitor.md` with:
-- Scan date
-- Violation counts per boundary
-- Items fixed mechanically (with file paths)
-- Items backlogged (with P-level and rationale)
-- New exceptions added (if any)
-
-## Optional: suggest a new boundary
-
-If you discover patterns in code that should be a typed boundary but aren't yet documented:
-
-1. Surface the candidate boundary to the user with a draft (type, Bounds, Shape, suggested severity)
-2. Recommend running the `boundary-mapper` agent to formalize it — never write to `docs/boundaries/` yourself
-
-## Rules
-
-- Never delete feature docs or modify frozen records (`docs/history/plans/`, `docs/history/changelog/`)
-- Be specific: include file paths, line numbers, and the exact violating string
-- Respect known-exceptions in `docs/memory/contract-monitor.md`
-- A clean report is valid — do not invent violations