@nurix/etna 0.3.2 → 0.3.6

package/data/harnesses/code/CLAUDE.md

@@ -1,7 +1,7 @@
 ---
 name: code
 description: Canonical Nurix code-project harness (spec v9) — three peer authoring modes (Brainstorming / Spec / Plan), modules as bounded contexts, typed application boundaries, ownership rules. The reference CLAUDE.md every Nurix codebase starts with.
-version: 0.2.2
+version: 0.3.5
 keywords:
   - harness
   - code

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

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

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

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

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 ---
 name: documentation
-description: Create and maintain technical documentation. Use when the user asks to (1) baseline, audit, or reorganize docs — enforces the opinionated v9 structure (architecture, features, operations, history, memory; + boundaries/, modules/, tests/ as the repo grows) with ownership frontmatter and scaffold files, (2) document a feature or module, (3) create or update a changelog entry, (4) document data flows or Redux state, (5) add to protected files, (6) provide the generic boundary-file template (typed-boundary *generation* is the `boundary-mapper` agent + `boundaries` skill, not this skill), (7) record an architecture decision (ADR), (8) create or update the project root README, (9) create or update a plan, or (10) co-author any technical doc. Triggers on "document this", "create docs", "update changelog", "baseline docs", "audit docs", "add to protected files", "ADR", "architecture decision", "root README", "plan".
+description: 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".
 plugins: [nurix-harness]
 ---
 

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

@@ -289,7 +289,7 @@ Auto-generated by the maintenance agent (Step 0). Do not edit by hand.
 
 ## 5. Boundary File (docs/boundaries/{boundary}.md)
 
-> **This skill does not generate boundaries.** Typed-boundary generation is owned by the **`boundary-mapper`** agent (detects the stack + IA, emits typed files) and the **`boundaries`** skill (the per-technology Application Boundary Scale). The baseline does **not** scaffold `docs/boundaries/` — `boundary-mapper` runs right after the baseline ("baseline boundaries"). This section is the generic **boundary-file template** plus the guidance for *recognizing* what deserves a boundary.
+> **This skill does not generate boundaries.** Typed-boundary generation is owned by the **`boundary-mapper`** agent, which detects the stack + IA and applies its built-in Application Boundary Scale to emit typed files. The baseline does **not** scaffold `docs/boundaries/` — `boundary-mapper` runs right after the baseline ("baseline boundaries"). This section is the generic **boundary-file template** plus the guidance for *recognizing* what deserves a boundary.
 
 ### What deserves a boundary
 

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

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

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

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

package/package.json

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

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

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