@nurix/etna 0.2.0 → 0.3.1

package/README.md

@@ -2,6 +2,8 @@
 
 CLI to bootstrap a project with a Nurix harness. Copies the harness's `CLAUDE.md`, skills, agents, rules, and scripts into the project so they live with the code — version-controllable, editable per project, and visible without leaving the repo.
 
+A second install path also exists and is fully supported: `/plugin install <plugin>@nurixlabs` from inside Claude Code, which installs the harness as a plugin from the `nurixlabs/skills` marketplace. The two paths are first-class equals — pick the one that matches how you want to manage the harness. See [`docs/architecture/harness-install-model.md`](../../docs/architecture/harness-install-model.md) for the comparison.
+
 ## Usage
 
 From the root of the project you want to bootstrap:

package/data/harnesses/code/CLAUDE.md

@@ -1,6 +1,28 @@
+---
+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.0
+keywords:
+  - harness
+  - code
+  - workflow
+  - documentation
+  - boundaries
+  - nurix
+plugin: nurix-harness
+---
+
 # Agent Instructions
 
-This file defines how AI agents (Claude, GPT, etc.) should work on this project.
+This file defines how AI agents (Claude, GPT, etc.) should work on this project. **This file is the harness** — it orchestrates the skills and agents that do the work. There is no separate "harness" skill.
+
+---
+
+## Bootstrap
+
+> If `docs/structure.md` is missing in this repo, the repo is **not yet harnessed**. Before any other work: invoke the `documentation` skill to run its baseline (`"baseline this repo"`). Both the baseline and the boundary baseline (`boundary-mapper`, below) can also be re-triggered manually at any time.
+
+This bootstrap is the only step that runs **before** the harness exists. Everything else below assumes a baselined repo.
 
 ---
 
@@ -11,39 +33,66 @@ This file defines how AI agents (Claude, GPT, etc.) should work on this project.
 - Ignore **[`README.md`](README.md)** — it's for human reference only
 - Check **[`package.json`](package.json)** for available scripts. **Detect the package manager from the lockfile** (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `package-lock.json` → npm) and use the matching command. Don't hardcode a specific manager.
 - Look at similar modules/files and follow existing patterns
-
-> **If you are a Claude agent** (for example, `claude-4.5-sonnet`) — other agents ignore:
-> Check **[`.claude/rules/`](.claude/rules/)** for specialized instructions (automatically loaded into memory)
+- Check **[`.claude/rules/`](.claude/rules/)** for specialized instructions (automatically loaded into memory)
 
 ---
 
 ## Workflows
 
-For new features or new systems, enter **Spec Mode** before Plan Mode.
+Three peer modes. Each names what triggers entry, which agent + skill implement it, and how it exits.
+
+```
+   ┌──────────────────────────┐      ┌──────────────────────────┐
+   │   Brainstorming Mode     │◀────▶│       Spec Mode          │
+   │   (30k-foot strategy,    │      │     (feature SSoT)       │
+   │    shapes module pillars │      │                          │
+   │    + the IA boundary)    │      │   spec-mode agent        │
+   │   brainstorm agent       │      │  + documentation skill   │
+   │  + technical-brainstorm  │      │                          │
+   └──────────────┬───────────┘      └──────────────┬───────────┘
+                  │                                 │
+                  └─────────────────┬───────────────┘
+                                    ▼
+                         ┌──────────────────────┐
+                         │     Plan Mode        │
+                         │ docs/history/plans/  │
+                         └──────────┬───────────┘
+                                    ▼
+                              Completion
+```
+
+Four transitions: `brainstorm → spec`, `brainstorm → plan`, `spec → plan`, `plan → complete`.
+
+### Brainstorming Mode
 
-### Spec Mode → Plan Mode → Completion
+30,000-foot directional work — doctrine, glossary, non-goals, open questions, and the **information architecture** (entity model + topology). Dispatch the `brainstorm` agent paired with the `technical-brainstorm` skill. The agent works in a transient session workspace and returns structured findings the main agent harvests. **Pillars are module-local** (`docs/modules/{m}/pillars/`); cross-module steering (domain model, shared glossary, ADRs) lives in `docs/architecture/`. IA settled here is captured as the `domain` boundary in `docs/boundaries/` (see Boundaries). Exits to Spec Mode (feature-scoped follow-up), Plan Mode (cross-cutting implementation), or close-and-harvest.
 
-1. **Spec Mode**: Create or update a feature spec in `docs/features/{feature}.md` using the **Feature Documentation template** (Status: Draft) — see the documentation skill (`.claude/skills/documentation/references/templates.md`). Use the **`spec-mode`** agent (`.claude/agents/spec-mode.md`) for codebase research; its findings drop directly into the template's research-derived sections (Affected Modules, Conventions to Follow, Current Behavior, Ownership Conflicts). Interview the user for the design-intent sections (Goal, Goals & Non-Goals, Background, Approach). Present the spec for approval before proceeding.
+### Spec Mode
 
-2. **Plan Mode**: Once the spec is approved, create a plan in `docs/history/plans/YYYY-MM-DD-feature-name.md` using the **Plan template**. Link back to the feature spec in the **Spec** field. The template's **Proposed Changes** subsections are load-bearing — the `introspect` skill parses them to check guardrail impact.
+New feature work. Create/update `docs/features/{feature}.md` (or `docs/modules/{m}/features/{feature}.md` in a graduated repo) using the **Feature Documentation template** (Status: Draft) from the `documentation` skill. Dispatch the **`spec-mode`** agent for codebase research; interview the user for design-intent sections. Present for approval, then → Plan Mode.
 
-3. **Completion**: When a plan is fully implemented:
-    - Mark the plan `Status: Complete` and fill the **Completed:** date. The plan is now frozen.
-    - **Flip the feature spec** to `Status: Active` and extend it in place with the implementation sections (Architecture, Key Functions, State, Redux, Files). Same file. Confirm `owns`/`touches` frontmatter against actual code; resolve any unresolved Open Questions by folding them into Background.
-    - If `docs/routing.md` exists, use it to find other docs affected by the changes; otherwise glob `docs/features/**/*.md` and check `owns`/`touches` frontmatter. Update affected docs — or create new ones if a touched area has no doc yet.
-    - Create a changelog entry in `docs/history/changelog/YYYY-MM-DD-feature-name.md`.
+### Plan Mode
 
-`docs/features/` is _what_ we're building (lives on as documentation). `docs/history/plans/` is _how_ we built it (historical record).
+A spec is approved. Create `docs/history/plans/YYYY-MM-DD-{feature}.md` using the **Plan template**. Link the spec in the **Spec** field. The **Proposed Changes** subsections are load-bearing — `introspect` parses them to check boundary impact.
+
+### Completion
+
+- Mark the plan `Status: Complete`, fill **Completed:**. Frozen.
+- Flip the feature spec to `Status: Active`; extend it in place with implementation sections (Architecture, Key Functions, State, Files). Confirm `owns`/`touches` frontmatter against code.
+- Use `docs/routing.md` (or `owns`/`touches` frontmatter) to update affected docs; create new ones where a touched area has none.
+- Create a changelog entry in `docs/history/changelog/YYYY-MM-DD-{feature}.md`.
+
+`docs/features/` (and `docs/modules/{m}/features/`) is _what_ we're building. `docs/history/plans/` is _how_ we built it.
 
 ### Context Routing
 
 Before modifying code in an unfamiliar area:
 
-1. If **[`docs/routing.md`](docs/routing.md)** exists, read it for file-pattern → doc/agent mapping. If it doesn't exist yet, skip — the codebase may not have owned features.
-2. If **[`docs/OWNERSHIP_INDEX.md`](docs/OWNERSHIP_INDEX.md)** exists, check it for the owning feature doc and read that doc before making changes. If it doesn't exist, glob `docs/features/**/*.md` and check `owns` frontmatter directly.
-3. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes
-
-For the protocol on *writing* to memory, see **Project Memory** below.
+1. If **[`docs/routing.md`](docs/routing.md)** exists, read it for file-pattern → module/doc/agent mapping. If absent, skip.
+2. If **[`docs/OWNERSHIP_INDEX.md`](docs/OWNERSHIP_INDEX.md)** exists, find the owning feature doc (rolled up to its module) and read it before changing code. Else glob `docs/{features,modules/*/features}/**/*.md` and check `owns` frontmatter.
+3. **Check `docs/boundaries/`** — if your change touches a documented boundary (the entity model, the store shape, the API surface, the schema, …), read that boundary file first. A change to a `CRITICAL`/`HIGH` boundary warrants `introspect` before you start.
+4. If a `docs/memory/{domain}.md` file exists, read it for failure modes.
+5. In a graduated repo, the module's own `docs/modules/{m}/CLAUDE.md` auto-loads in that subtree — follow it.
 
 ### Project Memory
 
@@ -51,89 +100,69 @@ Project-specific learnings live in `docs/memory/` (git-tracked). Cross-project u
 
 | File | Owner | Contents |
 |------|-------|----------|
-| `docs/memory/main.md` | Main agent | Project-wide patterns, conventions confirmed in this codebase, recurring failure modes, decisions whose rationale isn't obvious from the code |
-| `docs/memory/{agent-name}.md` | The named sub-agent | Strategy memory for that agent — how to be more effective on this project. Never user-centric. |
+| `docs/memory/main.md` | Main agent | Project-wide patterns, conventions, recurring failure modes |
+| `docs/memory/{agent-name}.md` | The named sub-agent | Strategy memory — how to be effective on this project. Never user-centric. |
 | `~/.claude/projects/...` | Auto-memory system | User preferences, role, communication style, cross-project habits |
 
-**Override the default auto-memory location for project-relevant facts.** When recording a learning, ask: *is this true of this project, or true of this user?* Project facts → `docs/memory/`. User facts → `~/.claude/`.
-
-`docs/memory/main.md` is scaffolded during baseline. Append entries dated `## YYYY-MM-DD — {topic}`; oldest at bottom is fine.
+**Override the default auto-memory location for project-relevant facts.** Ask: *is this true of this project, or this user?* Project facts → `docs/memory/`. User facts → `~/.claude/`.
 
 ### Out-of-Scope Discovery
 
-When implementing a plan, if you discover work that is important but outside the current plan's scope:
-
-- Append it to `docs/history/backlog.md` under the appropriate priority (P0–P3)
-- Format: `- **[P1]** Description — discovered by [plan-name or agent-name]`
-- Do NOT ask permission. Just append and mention it in your response.
+When implementing a plan, if you discover important work outside the current scope: append it to `docs/history/backlog.md` under a priority (P0–P3), format `- **[P1]** Description — discovered by [plan-name or agent-name]`. Don't ask permission; just append and mention it.
 
 ### Doc Ownership
 
-Feature docs in `docs/features/` must include YAML frontmatter with `owns`, `touches`, and `depends_on` fields. Architecture docs describe cross-cutting patterns and don't own specific files; operations docs describe procedures. Only feature docs need frontmatter.
+Feature docs require YAML frontmatter with `owns`, `touches`, `depends_on`. Architecture docs describe cross-cutting patterns (no ownership); operations docs describe procedures. Boundary docs name the modules they bound. The `spec-mode` agent checks ownership conflicts during research.
 
-The spec-mode agent checks for ownership conflicts during research. If conflicts are found, address them in the spec before proceeding.
+### Modules — vertical bounded contexts (graduation)
 
-### Architecture Decisions (ADRs)
+Flat `docs/features/` is the **default**. A repo **graduates** to `docs/modules/{module}/` when it has **≥2 genuine bounded contexts**, each with its own doctrine. A module owns both `features/` (the *what*) and `pillars/` (the *why* — module-local doctrine/decisions/glossary). Ungraduated features and graduated modules may coexist. Each module carries an auto-loaded `CLAUDE.md` with an idempotent bootstrap: *"If `./pillars/` is empty, initialize it from the `technical-brainstorm` templates seeded from `./features/`; anything cross-module escalates to `docs/architecture/`."* Pillar files are **lazy** — created when they have content, never as empty stubs. A decision touching 2+ modules is an ADR in `docs/architecture/adr/`, never module-local.
 
-Record an ADR when a decision (a) changes how state, dependencies, or boundaries are organized, (b) has a rejected alternative worth remembering, and (c) could plausibly be re-litigated. Default: don't write one. Style preferences, local refactors, and obvious-from-code choices don't qualify.
+### Architecture Decisions (ADRs)
 
-- File: `docs/architecture/adr/NNNN-kebab-case.md` (4-digit sequential number). Frozen once written — supersede via a new ADR, never edit.
-- Invoke the `documentation` skill with "record an ADR" or "architecture decision".
+Record an ADR when a decision (a) changes how state, dependencies, or boundaries are organized, (b) has a rejected alternative worth remembering, and (c) could be re-litigated. Default: don't write one. File: `docs/architecture/adr/NNNN-kebab-case.md`, frozen once written. Invoke the `documentation` skill with "record an ADR".
 
 ---
 
-## Agents
+## Boundaries (`docs/boundaries/`)
 
-Seven sub-agents and three skills are defined under `.claude/`. Reach for them by name or by trigger phrase:
+`docs/boundaries/` holds the repo's **typed application boundaries** — horizontal cross-cutting contracts that ripple when touched. Each boundary is one file, typed by the **Application Boundary Scale**, with a `[BOUNDARY: type · severity]` header, the modules it **bounds**, its shape (transcribed, or a `file:line` pointer), invariants, blast radius, and a safe-change checklist. Boundaries are the **edges** between module **nodes**.
 
-| Component | Type | Use for | Trigger phrases |
-|-----------|------|---------|-----------------|
-| `spec-mode` | Agent | Codebase research before writing a feature spec | Invoked during Spec Mode |
-| `maintenance` | Agent | Periodic audit — fix docs drifting from code | "run maintenance", "audit docs", "check drift" |
-| `contract-monitor` | Agent | Post-implementation contract audit — scan code against guardrails | "check contracts", "audit guardrails", "code drift" |
-| `review` | Agent | Code health — bundle, performance, anti-patterns | "weekly review", "review code health", "check bundle" |
-| `dep-health` | Agent | Dependency supply-chain audit | "audit dependencies", "check CVEs", "dep health" |
-| `git-history` | Agent | Classify recent commits into a velocity/severity CSV | "classify commits", "commit history report" |
-| `change-review` | Agent | Velocity heatmap, risk zones (high churn + low coverage) | "where is risk accumulating", "velocity report" |
-| `documentation` | Skill | Baseline audit, scaffolding, templates, ADRs, guardrails | "baseline docs", "create docs", "audit docs", "record an ADR", "architecture decision", "create guardrails" |
-| `workflow-mapper` | Skill | Discover and diagram codebase workflows | "map workflows", "trace flows" |
-| `introspect` | Skill | Pre-implementation impact analysis against guardrails | "introspect this plan", "impact analysis" |
+Two categories: **technology** boundaries (Redux store shape, API surface, DB schema, wire contracts, routes, …) and **domain** boundaries (the **information-architecture entity model** — usually the highest-severity boundary in the repo — and tenancy).
 
-### Guardrails
+Three components share this surface:
 
-`docs/operations/guardrails.md` documents **cascading failure boundaries** — places where editing one module silently breaks another (shared state shapes, entity registration checklists, cross-module string coupling, persistence rehydration, etc.). Two components depend on it:
+- **`boundary-mapper`** (agent) — detects the stack + IA and **generates / baselines / updates** `docs/boundaries/`. Pairs with the `boundaries` skill (the scale). Trigger: "baseline boundaries".
+- **`introspect`** (skill, pre-implementation) — checks a proposed plan against `docs/boundaries/`; the boundary **severity** sets review depth.
+- **`contract-monitor`** (agent, post-implementation) — scans the live codebase against `docs/boundaries/`, per boundary type.
 
-- **`contract-monitor`** (post-implementation) — scans code for violations of documented guardrails
-- **`introspect`** (pre-implementation) — checks a proposed plan against guardrails to surface cascading risk before coding
+`point` vs `transcribe`: self-locating shapes (DB schema, routes) get a pointer + invariants (code stays source-of-truth); synthesized contracts (composed store tree, API envelope, the IA model, tenancy) are transcribed — then the boundary file owns the shape and feature docs link up.
 
-To create or extend guardrails, invoke the `documentation` skill with "create guardrails" / "add guardrail". Without guardrails populated, `contract-monitor` and `introspect` are not useful.
+> Agents and skills come from the bound plugin (`plugin: nurix-harness`). Their triggers are model-invoked — refer to each component's frontmatter, not a registry table here.
 
 ---
 
-## Boundaries & Defaults
+## Defaults & Constraints
 
 Unless explicitly requested:
 
 ❌ **Tests** — Never generate, update, or modify test files.
 ❌ **Dependencies** — Never upgrade frameworks, libraries, or dependencies.
 ❌ **Compatibility** — Never maintain backward compatibility unless specified.
-❌ **Browser Automation** — Never use "Claude in Chrome" (CDP/MCP browser tools) unless the user explicitly requests it.
-❌ **Protected Files** — Never modify these read-only files:
-`AGENTS.md`, `docs/operations/protected-files.md`
+❌ **Browser Automation** — Never use "Claude in Chrome" (CDP/MCP browser tools) unless explicitly requested.
+❌ **Protected Files** — Never modify these read-only files: `AGENTS.md`, `docs/operations/protected-files.md`
 ✅ **Documentation** — Keep `docs/` updated when code changes affect documented behavior.
-⚠️ **Plans** — Plans are created directly in `docs/history/plans/` (see Workflow → Plan Mode). Once `Status: Complete` or `Status: Abandoned`, the file is frozen — never edited. If scope changes after completion, write a new dated plan that links back to the old one.
-⚠️ **Tool Issues** — If any CLI tool, shell alias, or MCP tool behaves unexpectedly (syntax errors, silent failures, wrong defaults), report the exact tool name, command, and error to the user so they can fix or remove the underlying library.
+⚠️ **Plans** — Created directly in `docs/history/plans/`. Once `Complete`/`Abandoned`, frozen — never edited. New scope → new dated plan linking back.
+⚠️ **Tool Issues** — If any CLI tool, alias, or MCP tool behaves unexpectedly, report the exact tool, command, and error to the user.
 
 ---
 
 ## File Structure
 
-- Add file path at top of each file:
-  `// src/modules/example.js - Module for handling user authentication`
-- Add a 1-line function description as a comment above each function:
-  `// Extract JWT token from request based on endpoint type`
+- Add file path at top of each file: `// src/modules/example.js - Module for handling user authentication`
+- Add a 1-line function description as a comment above each function.
 - Keep related code together in a logical hierarchy.
-- No inline comments that restate obvious code. No commented-out code. If a block of code needs a comment to be understandable, refactor for clarity instead.
+- No inline comments that restate obvious code. No commented-out code. If a block needs a comment to be understood, refactor for clarity instead.
 
 ---
 
@@ -145,46 +174,35 @@ Unless explicitly requested:
 
 ### Folder Structure
 
-The six procedural folders below are fixed. Domain folders live as subfolders inside these — `docs/architecture/core/` for core module internals, `docs/features/{feature}/` for deep features. Discovery flows through **[`docs/routing.md`](docs/routing.md)** when present.
+| Folder | Purpose | Mutability |
+| --- | --- | --- |
+| `docs/architecture/` | Cross-module patterns, domain model, cross-module glossary, ADRs | Living |
+| `docs/architecture/adr/` | Architecture Decision Records — numbered, one per file | Frozen (supersede) |
+| `docs/features/` | How implemented features work today (flat default, ungraduated) | Living |
+| `docs/modules/` | Vertical bounded contexts; each owns `features/` + `pillars/` (graduation) | Living |
+| `docs/boundaries/` | Horizontal typed application boundaries (one file each) | Generated/updated by `boundary-mapper` |
+| `docs/operations/` | Setup, development, deployment | Living |
+| `docs/history/` | Plans, changelogs, backlog | Frozen or append-only |
+| `docs/memory/` | Project knowledge + agent state | Living |
+| `docs/tests/` | Test plans and automation | Living |
 
-| Folder                   | Purpose                                                  | Mutability            |
-| ------------------------ | -------------------------------------------------------- | --------------------- |
-| `docs/architecture/`     | System-wide patterns, technical decisions, API specs     | Living                |
-| `docs/architecture/adr/` | Architecture Decision Records — numbered, one per file   | Frozen (supersede)    |
-| `docs/features/`         | How implemented features work today                      | Living                |
-| `docs/operations/`       | Setup, development, deployment                           | Living                |
-| `docs/history/`          | Plans, changelogs, backlog                               | Frozen or append-only |
-| `docs/memory/`           | Project knowledge + agent state                          | Living                |
-| `docs/tests/`            | Test plans and automation                                | Living                |
+There is **no repo-wide `docs/pillars/` folder** — pillars are module-local. Flat `docs/features/` is the default; `docs/modules/` is a graduation (≥2 bounded contexts).
 
 ### Naming & Lifecycle
 
-- Features: `kebab-case.md` — living reference, status `Active`
-- Plans: `YYYY-MM-DD-kebab-case.md` — frozen after `Complete` or `Abandoned`
-- Changelogs: `YYYY-MM-DD-kebab-case.md` — append-only
-- ADRs: `NNNN-kebab-case.md` (4-digit zero-padded number, sequential) — frozen; supersede via a new ADR
+- Features: `kebab-case.md` — living, status `Active`
+- Plans / Changelogs: `YYYY-MM-DD-kebab-case.md` — plans freeze after Complete/Abandoned; changelogs append-only
+- ADRs: `NNNN-kebab-case.md` — frozen; supersede via a new ADR
+- Boundaries: `kebab-case.md` (e.g. `information-architecture.md`, `redux-state.md`) — maintained by `boundary-mapper`
 - Memory: `{agent-name}.md` — agent-maintained
 
 ### Documentation Maintenance
 
-- **Prerequisite**: Before creating changelogs, feature docs, or plans, check that `docs/memory/index.md` exists and records a baseline. If not, prompt the user to baseline docs first.
-- After plan completion: create a `docs/history/changelog/YYYY-MM-DD-feature-name.md` entry + update the index in `docs/history/CHANGELOG.md` (no confirmation needed).
-- Update related docs affected by the changes (use `docs/routing.md` to find the right files)
-- Non-plan changes (refactors, bug fixes, API changes): prompt user first
-- Multi-commit changes: include `Commits: abc1234, def5678`
-- Missing `docs/README.md`: create a documentation index
+- **Prerequisite**: Before creating changelogs, feature docs, or plans, check `docs/memory/index.md` records a baseline. If not, prompt to baseline first.
+- After plan completion: create a changelog entry + update `docs/history/CHANGELOG.md` (no confirmation needed).
+- Update related docs affected by the changes (use `docs/routing.md` to find them).
+- Non-plan changes (refactors, bug fixes, API changes): prompt user first.
 
 ### Keeping the Loop Tight
 
-When you create, move, or delete a doc:
-- If **[`docs/routing.md`](docs/routing.md)** exists, update it — file-pattern routes and keyword routes
-- Update **[`docs/README.md`](docs/README.md)** — add/remove the doc's entry
-- If creating a new top-level domain folder and routing.md exists: add the folder to routing.md's **Top-Level Folders** table
-
-When you move or rename source files:
-- Check `owns`/`touches` frontmatter in the owning doc. Find the owning doc via `docs/routing.md` or `docs/OWNERSHIP_INDEX.md` if either is present; otherwise glob `docs/features/**/*.md` and match against `owns` patterns. Update paths to match the new locations.
-
-When you create a new doc that owns code:
-- Add `owns`, `touches`, `depends_on` YAML frontmatter
-- Verify `owns` globs don't conflict with existing docs (check `docs/OWNERSHIP_INDEX.md` if present, otherwise compare against `owns` frontmatter across `docs/features/`)
-
+When you create, move, or delete a doc: update `docs/routing.md` (routes) and `docs/README.md` (index). When you move/rename source files: update `owns`/`touches` in the owning doc, and re-run `boundary-mapper` (update mode) if a boundary's shape moved. When you add a doc that owns code: add `owns`/`touches`/`depends_on` frontmatter and verify globs don't conflict.

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

@@ -0,0 +1,91 @@
+---
+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", "generate guardrails", "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**. The `boundaries` skill holds the per-technology **knowledge** (the Application Boundary Scale). Read the skill 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. Read the `boundaries` skill's Application Boundary Scale.
+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/` or `docs/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.
+
+## 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}`.
+
+## 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

@@ -0,0 +1,107 @@
+---
+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 to docs/pillars/ directly (the main agent harvests).
+tools: Read, Glob, Grep, AskUserQuestion, Write
+model: inherit
+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 do NOT directly edit `docs/pillars/`. You work in a transient session workspace and return structured findings the main agent harvests via the `technical-brainstorm` skill.
+
+## Before Starting
+
+Anchor the session in the current repo state:
+
+1. Read `docs/pillars/doctrine.md`, `docs/pillars/glossary.md`, `docs/pillars/non-goals.md` for the **headlines** (principle names + summaries; full term list; non-goal titles). Hold the headline summary in mind throughout the session.
+2. Read `docs/pillars/decisions.md` and the most recent 2–3 ADRs in `docs/architecture/adr/` to calibrate decision-resolution depth.
+3. Read `docs/pillars/questions.md` for open questions that might already cover the user's concern.
+4. If `docs/memory/brainstorm.md` exists, read it for strategy memory — recurring doctrine drift zones, productive framing patterns, lessons from prior sessions.
+5. Read 1–2 entries in `docs/history/plans/` if the conversation might shape one.
+
+If `docs/pillars/` does not exist in the repo (first-time brainstorm in a harnessed repo), say so to the main agent and ask whether to initialize from the `technical-brainstorm` skill's templates before continuing.
+
+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.
+
+## What You Facilitate
+
+**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.
+
+**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?"*
+
+**Track tentative-vs-committed state.** Decisions land as `STATUS: tentative` first. They become ADRs only on commit. Cascades (overview.md updates, backlog appends) wait for commit.
+
+**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 Return
+
+Your output is structured for the main agent to harvest into v7/v8 destinations via the `technical-brainstorm` skill's harvest mechanics. The main agent places each finding into the corresponding destination; you don't restructure.
+
+| Finding | Destination |
+|---|---|
+| **Doctrine update** — new principle, revised principle, or amendment | `docs/pillars/doctrine.md` + excerpt to `docs/architecture/overview.md §Doctrine` |
+| **Glossary addition** — new term or revised meaning | `docs/pillars/glossary.md` + excerpt to `overview.md §Glossary` |
+| **Non-goal addition** — new scope decision (with re-evaluate trigger) | `docs/pillars/non-goals.md` + excerpt to `overview.md §Non-goals` |
+| **Reference addition** — external prior art | `docs/pillars/references.md` + excerpt to `overview.md §References` |
+| **Committed decision** — STATUS: committed (not tentative) | `docs/architecture/adr/NNN-{slug}.md` + index entry in `docs/pillars/decisions.md` + table row in `overview.md §Architecture decisions` |
+| **Backlog item** — work surfaced but not in current scope | `docs/history/backlog.md` (with priority + discovering session marker) |
+| **Rejected path** — alternative considered and chosen against | `docs/pillars/rejected.md` + ADR §Alternatives if tied to a committed decision |
+| **Cross-module doctrine** — doctrine that names a cascading failure boundary | `docs/operations/guardrails.md` (operational form, with G-number) |
+| **Open question** — not yet resolvable | `docs/pillars/questions.md` (with Resolution-lands-in pointer) |
+| **Milestone landmark** — material scope/structure change | `docs/pillars/milestones.md` |
+| **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 v7/v8 destinations.
+
+## Rules
+
+- **Read-only on production code and the live `docs/pillars/` files.** 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 session touches both P-IA and P-op numbering, double-check the doctrine excerpt in overview.md preserves both").
+
+**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.

package/data/harnesses/code/agents/change-review.md

@@ -3,6 +3,7 @@ name: change-review
 description: Velocity analysis — produces commit heatmap, risk-zone identification (high churn + low guardrail coverage), stabilization signals, team distribution. Consumes `git-history`'s CSV output rather than reanalyzing commits. Use when planning where to invest in better guardrails or rules.
 tools: Read, Glob, Grep, Bash
 model: inherit
+plugins: [nurix-harness]
 ---
 
 # Change-Review Agent

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

@@ -3,6 +3,7 @@ name: contract-monitor
 description: Post-implementation contract auditor. Scans the live codebase for violations of cross-module contracts documented in `docs/operations/guardrails.md` — 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

package/data/harnesses/code/agents/dep-health.md

@@ -3,6 +3,7 @@ name: dep-health
 description: Dependency supply-chain audit — security CVEs, outdated packages, license compliance, abandoned packages, unwanted transitive dependencies, install size. Run before releases or monthly. Pairs with `review` (which audits code, not deps).
 tools: Read, Glob, Grep, Bash
 model: inherit
+plugins: [nurix-harness]
 ---
 
 # Dependency Health Agent

package/data/harnesses/code/agents/git-history.md

@@ -3,6 +3,7 @@ name: git-history
 description: Analyze git history by dispatching parallel sub-agents to classify commits into a pipe-delimited CSV with module, feature, impact, severity, and velocity dimensions.
 tools: Bash, Read, Write, Glob, Grep, Task
 model: sonnet
+plugins: [nurix-harness]
 ---
 
 # Git History Agent

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

@@ -3,6 +3,7 @@ name: maintenance
 description: Docs-vs-code coherence audit. Detects and fixes docs drifting from code — stale docs, broken ownership, routing table drift, unowned source paths. Run weekly or after major changes. Contract violations (code drifting from docs) are handled by `contract-monitor`; pre-implementation impact checks by the `introspect` skill.
 tools: Read, Glob, Grep, Edit, Write, Bash
 model: inherit
+plugins: [nurix-harness]
 ---
 
 # Maintenance Agent

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

@@ -3,6 +3,7 @@ name: review
 description: Code-level health audit — bundle size, tree-shaking issues, performance anti-patterns, code-quality flags. Run weekly or after major code changes. Pairs with `dep-health` (which audits dependencies, not code that uses them).
 tools: Read, Glob, Grep, Bash
 model: inherit
+plugins: [nurix-harness]
 ---
 
 # Review Agent

package/data/harnesses/code/agents/spec-mode.md

@@ -5,6 +5,7 @@ tools: Read, Glob, Grep, WebSearch, WebFetch
 model: inherit
 skills:
   - documentation
+plugins: [nurix-harness]
 ---
 
 # Spec Mode Agent

package/data/harnesses/code/rules/general.md

@@ -1,5 +1,6 @@
 ---
 applyTo: "**"
+plugins: [nurix-harness]
 ---
 
 # Technology Choices & Standards

package/data/harnesses/code/rules/nomenclature.md

@@ -1,5 +1,6 @@
 ---
 applyTo: "**"
+plugins: [nurix-harness]
 ---
 
 # Nomenclature Guidelines

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

@@ -1,5 +1,6 @@
 #!/usr/bin/env bash
 # scripts/build-ownership-index.sh - Generate docs/OWNERSHIP_INDEX.md from feature doc frontmatter
+# plugins: [nurix-harness]
 
 set -euo pipefail