@nurix/etna 0.3.1 → 0.3.2

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

@@ -1,6 +1,6 @@
 ---
 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).
+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]
@@ -12,21 +12,21 @@ You scan the codebase for cross-module contract violations. Where the `introspec
 
 ## Before Starting
 
-1. Read `./docs/operations/guardrails.md` — this is your source of truth for which contracts exist. If it doesn't exist, stop and tell the user a guardrails doc is required.
+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 guardrail section in `guardrails.md`:
+For each boundary file in `docs/boundaries/`:
 
-1. Parse the section — extract contract name, canonical source location, consumer paths, violation description, checklist (if any)
-2. Scan the codebase for violations of that specific contract. Categories to check:
+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 guardrail entry
+   - **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
@@ -34,29 +34,29 @@ For each guardrail section in `guardrails.md`:
 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 guardrail and consumer paths
+- **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:
 
-| # | Guardrail | Violation | Location | Action taken |
-|---|-----------|-----------|----------|--------------|
+| # | Boundary | Violation | Location | Action taken |
+|---|----------|-----------|----------|--------------|
 
 Then update `docs/memory/contract-monitor.md` with:
 - Scan date
-- Violation counts per guardrail
+- Violation counts per boundary
 - Items fixed mechanically (with file paths)
 - Items backlogged (with P-level and rationale)
 - New exceptions added (if any)
 
-## Optional: extend guardrails
+## Optional: suggest a new boundary
 
-If you discover patterns in code that should be guardrails but aren't yet documented:
+If you discover patterns in code that should be a typed boundary but aren't yet documented:
 
-1. Surface the candidate guardrail to the user with a draft entry
-2. Wait for approval before writing to `guardrails.md` — never add a guardrail unilaterally
+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
 

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

@@ -11,13 +11,13 @@ plugins: [nurix-harness]
 You maintain codebase coherence by detecting drift between docs and code, and fixing it. Scope: stale feature docs, broken ownership, routing table drift, architecture drift, unowned source paths, backlog health.
 
 Out of scope (handled by sibling components):
-- **Code drifted from docs** (contract/guardrail violations in live code) → `contract-monitor` agent
-- **Pre-implementation impact analysis** (checking a plan against guardrails before coding) → `introspect` skill
+- **Code drifted from docs** (boundary violations in live code) → `contract-monitor` agent
+- **Pre-implementation impact analysis** (checking a plan against the typed boundaries before coding) → `introspect` skill
 
 ## Before Starting
 
 1. If `./docs/memory/maintenance.md` exists, read it for last review state, ownership snapshots, high-churn paths, and known failure modes.
-2. If `./docs/operations/guardrails.md` exists, read it for context on cross-module contracts the docs should reflect.
+2. If `./docs/boundaries/` exists, read its files for context on the typed cross-module contracts the docs should reflect.
 3. If `./docs/routing.md` exists, read it for the current file-pattern-to-doc mapping.
 
 ## Step 0: Regenerate Ownership Index

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 an opinionated 6-folder structure (architecture, features, operations, history, memory, tests) 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) create or update guardrails (cascading failure boundaries), (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", "guardrails", "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 + `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".
 plugins: [nurix-harness]
 ---
 
@@ -29,7 +29,7 @@ User request
     │
     ├─ "Add to protected files" ───────▶ Protected Files Template
     │
-    ├─ "Create/update guardrails" ─────▶ Guardrails Template
+    ├─ "Create/update a boundary" ─────▶ boundary-mapper agent (this skill holds only the boundary-file template)
     │
     ├─ "Record architecture decision" ─▶ ADR Template
     │
@@ -46,7 +46,7 @@ User request
 
 ## Baseline Audit
 
-When asked to "baseline", "audit", or "review" docs, enforce the canonical 6-folder documentation structure. This is an opinionated reorganization — the target structure is non-negotiable.
+When asked to "baseline", "audit", or "review" docs, enforce the canonical v9 documentation structure. This is an opinionated reorganization — the target structure is non-negotiable.
 
 ### Target Structure
 
@@ -54,24 +54,28 @@ When asked to "baseline", "audit", or "review" docs, enforce the canonical 6-fol
 docs/
 ├── README.md              # Documentation root — quick links table, section index
 ├── structure.md           # Authority map, folder rules, health log
-├── CODEBASE_MAP.md        # Auto-generated directory map (optional)
-├── faq.md                 # Common issues (optional)
-├── architecture/          # System-wide decisions, patterns, technical references
-│   ├── adr/               # Architecture Decision Records (numbered, immutable)
-│   └── core/              # Core module internals (auth, state, routing)
-├── features/              # Living feature specs with ownership frontmatter
+├── routing.md             # File-pattern → module/doc/agent map (scaled — see CLAUDE.md)
+├── OWNERSHIP_INDEX.md      # Generated: code path → owning feature doc
+├── architecture/          # Cross-module design + the steering layer
+│   │                      #   domain-model, glossary, non-goals, references, open-questions
+│   └── adr/               # Architecture Decision Records (numbered, immutable)
+├── features/              # Flat default — feature specs with ownership frontmatter
 │   └── {feature}/         # Subfolder for deep features (e.g., editor/)
+├── modules/               # Graduation (≥2 bounded contexts) — NOT scaffolded at baseline
+│   └── {module}/          #   CLAUDE.md + features/ + pillars/ (module-local doctrine, lazy)
+├── boundaries/            # Typed application boundaries — generated by boundary-mapper
 ├── operations/            # Setup, development, deployment, CI/CD
-│   └── guardrails.md      # Cascading failure boundaries (cross-module contracts)
 ├── history/               # Frozen/append-only records
 │   ├── CHANGELOG.md       # Master changelog index
 │   ├── changelog/         # Individual changelog entries
 │   ├── plans/             # Historical implementation plans (Status field required)
 │   └── backlog.md         # Tracked work items by priority (P0-P3)
-├── memory/                # Agent memory files
+├── memory/                # Agent memory files (index.md = baseline record)
 └── tests/                 # Test plans and automation docs (optional)
 ```
 
+There is **no repo-wide `docs/pillars/`** (dissolved in v9 — pillars are module-local). `docs/boundaries/` is populated by the `boundary-mapper` agent (which the bootstrap runs immediately after this baseline), and `docs/modules/` appears only when the repo graduates to ≥2 bounded contexts — neither is scaffolded here. `docs/tests/` is optional and **author-maintained**: no agent, skill, or script owns it — create it only if test-plan or test-automation docs already exist, and never scaffold it empty.
+
 ### Workflow
 
 **Step 1: Inventory existing docs**
@@ -126,7 +130,6 @@ After approval:
 8. Scaffold standard files if missing:
    - `docs/README.md` — from template (see `references/templates.md`)
    - `docs/structure.md` — from template (see `references/templates.md`)
-   - `docs/operations/guardrails.md` — cascading failure boundaries (see `references/templates.md` for what to include/exclude)
    - `docs/history/CHANGELOG.md` — master changelog index (header + table linking to entries)
    - `docs/history/backlog.md` — work items by priority (P0-P3 sections, empty if nothing to merge)
    - `docs/memory/index.md` — agent memory index (empty scaffold with section headers)
@@ -138,19 +141,19 @@ After approval:
 
 **Step 5: Verify**
 
-1. Confirm all standard files exist: `docs/README.md`, `docs/structure.md`, `docs/operations/guardrails.md`, `docs/history/CHANGELOG.md`, `docs/history/backlog.md`, `docs/memory/index.md`, `docs/memory/main.md`, `docs/OWNERSHIP_INDEX.md`, `README.md` (repo root — must exist; either pre-existing untouched or freshly scaffolded)
+1. Confirm all standard files exist: `docs/README.md`, `docs/structure.md`, `docs/history/CHANGELOG.md`, `docs/history/backlog.md`, `docs/memory/index.md`, `docs/memory/main.md`, `docs/OWNERSHIP_INDEX.md`, `README.md` (repo root — must exist; either pre-existing untouched or freshly scaffolded). `docs/boundaries/` is the `boundary-mapper` agent's responsibility (the bootstrap runs it right after this baseline), not a scaffold target here.
 2. Confirm no dead links in `docs/README.md`
 3. Confirm every plan file has a `Status:` field
 4. Confirm feature docs have ownership frontmatter
 5. Confirm `docs/OWNERSHIP_INDEX.md` rows match the frontmatter on disk (no orphans, no missing entries)
-6. Confirm no docs remain outside the 6-folder structure (except `README.md`, `structure.md`, `CODEBASE_MAP.md`, `faq.md`)
+6. Confirm no docs remain outside the v9 structure (except the docs-root files `README.md`, `structure.md`, `routing.md`, `OWNERSHIP_INDEX.md`)
 7. Confirm duplicates are eliminated — each topic has one canonical source
 
 ### Rules
 
-- The 6-folder structure is mandatory. No `docs/guides/`, `docs/core/`, `docs/editor/`, `docs/pt/`, or any other top-level folder
+- The v9 structure is mandatory. No `docs/guides/`, `docs/core/`, `docs/editor/`, `docs/pt/`, no repo-wide `docs/pillars/` (dissolved in v9 — pillars are module-local under `docs/modules/{m}/pillars/`), or any other top-level folder beyond the v9 set
 - Guides about how-to-run → `operations/`. Guides about a feature → `features/`
-- Core module docs → `docs/architecture/core/`. Editor module docs → `docs/features/editor/`
+- A genuine bounded context graduates to `docs/modules/{m}/` (owning `features/` + `pillars/`); ungraduated feature docs stay flat under `docs/features/` (deep features may nest, e.g. `docs/features/editor/`)
 - Only `CLAUDE.md`, `AGENTS.md`, and `README.md` are allowed in the repository root (not inside `docs/`)
 - Root-level `README.md` is for humans. `docs/README.md` is the agent/doc entry point
 - One canonical source per topic — link, don't copy
@@ -234,6 +237,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), guardrails, feature, changelog, plan, protected files, ADR, project root README templates |
+| `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/style-guide.md` | Writing rules, formatting conventions |
 | `references/examples.md` | Good vs bad documentation examples |

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

@@ -86,8 +86,10 @@ Each topic has one canonical location. Read from here, not from plans or changel
 
 | Topic | Authority | Key Files |
 | ----- | --------- | --------- |
-| System architecture | `docs/architecture/` | {key files} |
-| Feature behavior | `docs/features/` | {key files} |
+| System architecture + steering | `docs/architecture/` | domain-model, glossary, non-goals, references, adr/ |
+| Feature behavior | `docs/features/` (or `docs/modules/{m}/features/`) | {key files} |
+| Cross-module contracts | `docs/boundaries/` | one file per boundary (maintained by `boundary-mapper`) |
+| Bounded contexts (graduated) | `docs/modules/{m}/` | `features/` + `pillars/` |
 | Setup & development | `docs/operations/` | {key files} |
 | Historical plans | `docs/history/plans/` | YYYY-MM-DD-name.md |
 | Change records | `docs/history/changelog/` | Individual entries |
@@ -104,7 +106,9 @@ Plan (Status: Draft) → Implementation → Feature Doc or Architecture Update
 ## Folder Rules
 
 - `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 technical decisions. Update when cross-cutting concerns change.
+- `docs/architecture/`: System-wide patterns and the cross-module steering layer (domain model, glossary, non-goals, references, ADRs). Update when cross-cutting concerns change.
+- `docs/boundaries/`: Horizontal typed application boundaries — one file per cross-module contract. Generated/maintained by the `boundary-mapper` agent; read before touching a shape it defines.
+- `docs/modules/{m}/`: Vertical bounded contexts (a graduation at ≥2 contexts). Each owns `features/` + module-local `pillars/` (doctrine, lazy). There is no repo-wide `docs/pillars/`.
 - `docs/operations/`: How-to procedures for setup, development, and deployment. Update when workflows change.
 - `docs/history/plans/`: Historical. Must have `Status:` field. Never modify after completion.
 - `docs/history/changelog/`: Historical. Append-only.
@@ -115,7 +119,7 @@ Plan (Status: Draft) → Implementation → Feature Doc or Architecture Update
 <!-- Updated by maintenance agent -->
 | Date | Review Summary |
 | ---- | -------------- |
-| {today} | Initial baseline — 6-folder structure established |
+| {today} | Initial baseline — v9 structure established |
 ```
 
 ---
@@ -231,7 +235,8 @@ description: Shared knowledge accumulated across agent sessions. All agents shou
 ## Documentation Baseline
 
 - **Baselined:** {today}
-- **Structure:** 6-folder (architecture, features, operations, history, memory, tests)
+- **Structure:** v9 (architecture, features, operations, history, memory; + boundaries/, modules/, tests/ when present)
+- **Spec version:** v9
 
 ## Learnings
 
@@ -282,15 +287,15 @@ Auto-generated by the maintenance agent (Step 0). Do not edit by hand.
 
 ---
 
-## 5. docs/operations/guardrails.md (Cascading Failure Boundaries)
+## 5. Boundary File (docs/boundaries/{boundary}.md)
 
-Use for: documenting contracts, shapes, and coupling points where a change in one module silently breaks another. Created during baseline audit. Updated when new cross-module contracts are discovered.
+> **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.
 
-### What belongs in guardrails
+### What deserves a boundary
 
-A guardrail is something where **the failure is silent and crosses module boundaries**. The developer working in module A has no reason to know that module B will break. No import error, no runtime exception — just wrong behavior.
+A boundary is a **horizontal, cross-module contract** where the failure is silent and crosses module boundaries — the developer in module A has no reason to know module B will break. No import error, no runtime exception — just wrong behavior.
 
-Test: "If an agent edits this while working on a single feature, could it silently break something in a different feature?" If yes, it's a guardrail.
+Test: "If an agent edits this while working on a single feature, could it silently break something in a different feature?" If yes, it's a boundary.
 
 **Include:**
 
@@ -308,14 +313,14 @@ Test: "If an agent edits this while working on a single feature, could it silent
 
 - Module-internal architecture (well-encapsulated, no cross-module blast radius)
 - Authentication/authorization flows (behind adapters, feature code doesn't touch them)
-- Hook taxonomies and API reference (useful docs, but not guardrails — they don't cause cascading failures)
+- Hook taxonomies and API reference (useful docs, but not boundaries — they don't cause cascading failures)
 - Networking details (WebSocket, HTTP client setup) — unless the event routing has cross-module string coupling
 - Feature folder conventions and code style (conventions, not breakage vectors)
-- Anything where failure produces an import error, a clear runtime exception, or a visible UI error — those are self-diagnosing and don't need guardrails
+- Anything where failure produces an import error, a clear runtime exception, or a visible UI error — those are self-diagnosing and don't need a boundary
 
-### How to research guardrails
+### How to research a boundary
 
-When creating or updating `docs/operations/guardrails.md`, use sub-agents to investigate:
+When mapping a boundary (the `boundary-mapper` agent's job — this guidance is shared), use sub-agents to 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.
@@ -324,46 +329,29 @@ When creating or updating `docs/operations/guardrails.md`, use sub-agents to inv
 5. **Pipeline data dependencies** — For multi-step processes, check what each step reads from shared state and what previous step wrote it. Test: "If I reorder these steps, does it fail loudly or silently?"
 6. **Persistence rehydration** — Check what reconciler is used, whether transforms exist, and what happens to existing users when a persisted shape changes.
 
-### Template
-
-```markdown
-# Guardrails
-
-Things that silently break across modules if touched wrong. Each section explains what the contract is, where it's consumed, and what goes wrong if violated.
-
----
-
-## 1. [Contract Name]
-
-[One-line description of what this contract governs.]
-
-### The contract
+### Generic boundary-file template
 
-[Describe the shape, format, or protocol. Show code if it's a data shape.]
+One file per boundary in `docs/boundaries/`. `boundary-mapper` emits typed files using the Application Boundary Scale; this is the generic fallback shape.
 
-### Where it's consumed
-
-[Table or list of every file/module that depends on this contract.]
-
-### What breaks if violated
-
-[Specific failure modes. "Silent data loss", "lookup returns undefined", "pipeline hangs", etc.]
-
-### Checklist (if applicable)
-
-[Step-by-step list of files to touch when extending this contract. Mark which steps cause silent failures if skipped.]
+```markdown
+# {Boundary Name}
 
----
+[BOUNDARY: {type} · {severity}]   <!-- type from the Application Boundary Scale; severity CRITICAL | HIGH | MED | LOW -->
 
-## N. [Next Contract]
+**Bounds:** {module A} ↔ {module B}   <!-- which modules sit on each side -->
 
-...
+## Shape
+<!-- `transcribe`: a synthesized contract with no single code home (composed store tree, API envelope, the IA entity model, tenancy) — written inline, canonical here.
+     `point`: a self-locating shape (DB schema, route table) — a `file:line` pointer + invariants. Never copy a self-locating shape; it rots on the next change. -->
 
----
+## Invariants
+<!-- The rules that must hold across the boundary. -->
 
-## Reference: [Shapes / Enums / Defaults]
+## Blast radius
+<!-- What breaks, and where, if an invariant is violated. -->
 
-[Put stable reference material (store shapes, entity defaults, API envelopes) at the bottom. These support the guardrails above but aren't guardrails themselves.]
+## Safe-change checklist
+<!-- Ordered steps to change this contract without silent breakage. Mark steps that fail silently if skipped. -->
 ```
 
 ---
@@ -570,7 +558,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 guardrail impact. Keep that structure stable — section headings and bullet shape are load-bearing for the parser.
+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.
 
 ```
 # {Feature Name}
@@ -606,7 +594,7 @@ Why this work is happening *now*. Link to the spec for *what* we're building; th
 
 ### Cross-Module Contracts Affected
 
-- List which guardrails (from `docs/operations/guardrails.md`) this plan touches by name
+- List which boundaries (from `docs/boundaries/`) this plan touches by name
 - "None" is a valid answer and means introspect will pass cleanly
 
 ## Implementation Steps

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

@@ -1,12 +1,12 @@
 ---
 name: introspect
-description: Pre-implementation impact analyzer. Reads a plan in docs/history/plans/ and checks every Proposed Change against docs/operations/guardrails.md to surface cascading risks before coding starts. Produces a severity-ranked violation report with suggested plan additions. Read-only. Triggers on "introspect", "check this plan", "impact analysis", "/introspect", "what could break", "guardrail check before I start".
+description: Pre-implementation impact analyzer. Reads a plan in docs/history/plans/ and checks every Proposed Change against the typed boundaries in docs/boundaries/ to surface cascading risks before coding starts. Produces a severity-ranked violation report with suggested plan additions. Read-only. Triggers on "introspect", "check this plan", "impact analysis", "/introspect", "what could break", "boundary check before I start".
 plugins: [nurix-harness]
 ---
 
 # Introspect Skill
 
-Pre-implementation impact analysis. Reads a plan, intersects every proposed change with documented guardrails, and surfaces cascading risk _before_ implementation. The complement to `contract-monitor`, which scans the live codebase _after_ changes land.
+Pre-implementation impact analysis. Reads a plan, intersects every proposed change with the documented boundaries in `docs/boundaries/`, and surfaces cascading risk _before_ implementation. The complement to `contract-monitor`, which scans the live codebase _after_ changes land.
 
 The skill is read-only. It does not edit the plan, modify code, or write to memory. Output is a report the user reviews and acts on.
 
@@ -18,11 +18,11 @@ Trigger this skill when:
 
 - The user types `/introspect`, "introspect", "check this plan", "impact analysis", "what could break"
 - A plan exists in `docs/history/plans/` and the user is about to start implementation
-- A plan was recently revised and the user wants to re-check guardrail impact
+- A plan was recently revised and the user wants to re-check boundary impact
 
 Do not run it when:
 
-- No `docs/operations/guardrails.md` exists — tell the user to create guardrails first via the documentation skill (`add guardrail`)
+- No `docs/boundaries/` exists, or it's empty — tell the user to baseline the typed boundaries first via the `boundary-mapper` agent (`baseline boundaries`)
 - No plan exists — tell the user to write a plan first (documentation skill, `create plan`)
 - The user wants post-implementation auditing — that's the `contract-monitor` agent
 
@@ -31,7 +31,7 @@ Do not run it when:
 ## Inputs
 
 - **Plan path**: user-provided. If unspecified, use the most recent file in `docs/history/plans/` (sorted by filename date).
-- **Guardrails**: `docs/operations/guardrails.md` is mandatory. Stop if missing.
+- **Boundaries**: every file in `docs/boundaries/` is mandatory input. Stop if the folder is missing or empty (suggest `boundary-mapper`).
 - **Source files**: read on demand to verify intersections — never guess from plan text alone.
 
 ---
@@ -43,7 +43,7 @@ Do not run it when:
 1. Resolve the plan path. If the user named a feature, glob `docs/history/plans/*{feature}*.md` and pick the newest.
 2. Read the plan in full.
 3. Confirm it has a `Status:` field. If `Complete` or `Abandoned`, ask the user whether they want to introspect a frozen plan anyway — it's usually a mistake.
-4. Read `docs/operations/guardrails.md`. Parse each guardrail section into: name, canonical source location, consumer paths, violation description.
+4. Read every file in `docs/boundaries/`. For each boundary, parse the `[BOUNDARY: type · severity]` header plus: **Bounds** (the modules on each side of the contract), **Shape** (the transcribed contract, or a `file:line` pointer to self-locating code), **Invariants** (what must hold), **Blast radius** (what breaks if violated), and the **Safe-change checklist**. The severity (CRITICAL / HIGH / MED / LOW) sets the review depth for any change that touches that boundary.
 
 ### Phase 2: Parse Proposed Changes
 
@@ -51,25 +51,25 @@ The plan template's **Proposed Changes** subsections are load-bearing — intros
 
 | Subsection | What introspect uses it for |
 |------------|------------------------------|
-| **New Files** | New paths to check against ownership and guardrail consumer paths |
-| **Modified Files** | Existing paths to check against guardrails referencing them |
-| **New Entities / State** | Entity strings, state slices, schema additions — checked against entity-type and schema-mismatch guardrails |
-| **API Changes** | New or modified routes, contracts, request/response shapes — checked against documented contracts |
-| **Cross-Module Contracts Affected** | The plan author's own admission of contracts touched — start here, then verify |
+| **New Files** | New paths to check against ownership and the modules each boundary **Bounds** |
+| **Modified Files** | Existing paths to check against boundaries that **Bound** them |
+| **New Entities / State** | Entity strings, state slices, schema additions — checked against the `domain` and `db-schema` boundaries |
+| **API Changes** | New or modified routes, contracts, request/response shapes — checked against the `api` / `wire-contracts` boundaries |
+| **Cross-Module Contracts Affected** | The plan author's own admission of boundaries touched — start here, then verify |
 
 If a subsection is missing or empty, note it in the report (the plan may be incomplete) but continue with what's there.
 
 ### Phase 3: Analyze
 
-For each guardrail × proposed change pair, check intersection:
+For each boundary × proposed change pair, check intersection:
 
-1. **Path overlap** — does the change touch any file in the guardrail's consumer-paths set?
-2. **Pattern overlap** — does the change introduce code shapes the guardrail prohibits (raw string literal where a shared constant is required, new entity type not in the canonical array, persisted field without selector fallback)?
-3. **Contract overlap** — does the change modify the canonical source of a guardrail (the `ENTITY_TYPES` array, the shared constants file, the persistence schema)?
+1. **Bounds overlap** — does the change touch any module the boundary **Bounds**, or any file its **Shape** pointer (`file:line`) locates?
+2. **Invariant overlap** — does the change introduce code shapes the boundary's **Invariants** prohibit (raw string literal where a shared constant is required, new entity type not in the canonical array, persisted field without selector fallback)?
+3. **Shape overlap** — does the change modify the canonical **Shape** of a boundary (the `ENTITY_TYPES` array, the shared constants file, the persistence schema, the API envelope)?
 
 Whenever an intersection is plausible from plan text, **read the actual source files** to verify. Never guess from plan text alone.
 
-Assign severity:
+Assign severity. Anchor it to the **boundary's own severity** (it sets the floor), then adjust by the concrete risk this change carries — a change against a CRITICAL/HIGH boundary starts at that floor; downgrade only with a stated reason. The boundary's **Blast radius** is the evidence for the rating:
 
 - **Critical** — silent data loss, corrupted persistence, broken cross-entity references
 - **High** — stale state, broken lookups, schema selectors without fallbacks
@@ -84,13 +84,13 @@ Produce a markdown report:
 # Introspect — {plan filename}
 
 Plan: {path}
-Guardrails: {N} sections evaluated
+Boundaries: {N} files evaluated
 Intersections found: {N} ({critical}/{high}/{medium}/{low})
 
 ## Violations
 
-| # | Guardrail | Risk | Severity | Plan step |
-|---|-----------|------|----------|-----------|
+| # | Boundary | Risk | Severity | Plan step |
+|---|----------|------|----------|-----------|
 
 ## Suggested Plan Additions
 
@@ -106,7 +106,7 @@ For each violation, a specific recommendation:
 
 ## New Cross-Module Contracts Detected
 
-{If the plan introduces a contract not yet in guardrails.md, show a diff-style proposed addition. Ask the user to approve adding it via the documentation skill — never write directly.}
+{If the plan introduces a cross-cutting contract not yet in `docs/boundaries/`, describe the proposed boundary (type, Bounds, Shape, suggested severity) and recommend running the `boundary-mapper` agent to formalize it — never write a boundary file directly.}
 ```
 
 The severity-ranked table is the load-bearing output. Suggestions are advisory — the user decides which to fold back into the plan.
@@ -116,17 +116,17 @@ The severity-ranked table is the load-bearing output. Suggestions are advisory
 After producing the report:
 
 - If the user accepts a suggested plan addition, they edit the plan themselves (or invoke the documentation skill to do it). Introspect never edits plans.
-- If new contracts are detected, suggest invoking the documentation skill with `add guardrail` to formalize them — do not append to `guardrails.md` from this skill.
+- If new contracts are detected, suggest running the `boundary-mapper` agent to formalize them as a typed boundary — do not write to `docs/boundaries/` from this skill.
 
 ---
 
 ## Rules
 
-- **Read-only**. Never edit the plan, source code, guardrails, or memory.
+- **Read-only**. Never edit the plan, source code, boundaries, or memory.
 - **Verify against source**. Never report a violation purely from plan text — read the files the plan claims it will touch.
 - **Plan structure is load-bearing**. If a plan was not written using the documentation skill's plan template, the Proposed Changes subsections may be missing. Note this clearly rather than fabricating intersections.
 - **A clean report is valid**. Plans with no intersections produce an empty violations table — say so, don't pad.
-- **Be specific**. Cite file paths, plan-step numbers, guardrail names, and the exact code shape that breaks the contract.
+- **Be specific**. Cite file paths, plan-step numbers, boundary names, and the exact code shape that breaks the contract.
 - **Don't replicate contract-monitor**. Introspect checks intent (plan text). Contract-monitor checks reality (code). If the user wants to scan live code, route them to contract-monitor.
 
 ---

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

@@ -20,11 +20,13 @@ Everything else happens **within** an active session, as natural conversation. T
 
 ## Folder layout
 
-### Persistent pillars vs. session workspace (v8)
+### Persistent pillars vs. session workspace (v9)
 
-If the consuming repo has `docs/pillars/` (harnessed repos following the v8 three-peer-modes model — see [`nurix-harness/three-peer-modes.md`](../../docs/harness/nurix-harness/three-peer-modes.md)), the **persistent home** of pillars is `docs/pillars/`. Each brainstorming session opens a **transient working copy** at `./brainstorm/pillars/` (repo root, not inside `docs/`) that is *primed* from `docs/pillars/` on `/start`. The conversation mutates the working copy. On `/stop`, the harvest diffs the session pillars against `docs/pillars/` and writes the changes back (see Harvest destinations in `## stop` below).
+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).
 
-If `docs/pillars/` does **not** exist (legacy v7 repos, or first-time use), the skill creates `docs/pillars/` from the templates in this skill's `templates/` folder on first `/start`, so the harvest target exists by `/stop`.
+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).
+
+If none of those v9 homes exist yet (a freshly-baselined repo, or first-time use), the skill still runs the session from this skill's `templates/` folder; the harvest **creates** each destination file on `/stop`, so nothing needs to pre-exist.
 
 ### Session folder
 
@@ -309,21 +311,22 @@ 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 `docs/pillars/` and v7/v8 destinations** (if the consuming repo has them — harnessed under v8). The harvest is a structured diff between the session pillars (`./brainstorm/pillars/*`) and the persistent pillars (`docs/pillars/*`). For each kind of mutation, write to the matching destination:
-
-   | Session source | Persistent destination | Excerpt / propagation |
-   |---|---|---|
-   | `./brainstorm/pillars/doctrine.md` (additions / amendments) | `docs/pillars/doctrine.md` | Excerpt → `docs/architecture/overview.md §Doctrine`. If the principle names a cascading failure boundary, also propagate operational form to `docs/operations/guardrails.md`. |
-   | `./brainstorm/pillars/glossary.md` | `docs/pillars/glossary.md` | Excerpt → `overview.md §Glossary`. |
-   | `./brainstorm/pillars/non-goals.md` | `docs/pillars/non-goals.md` | Excerpt → `overview.md §Non-goals`. |
-   | `./brainstorm/pillars/references.md` | `docs/pillars/references.md` | Excerpt → `overview.md §References`. |
-   | `./brainstorm/pillars/inventory.md` | `docs/pillars/inventory.md` | If subsystems changed, also touch `overview.md §Subsystem index` and `OWNERSHIP_INDEX.md`. |
-   | Committed decisions (`STATUS: committed` in `./brainstorm/pillars/decisions.md`) | New `docs/architecture/adr/NNN-{slug}.md` (one ADR per cohesive theme) + entry in `docs/pillars/decisions.md` | Add a row to `overview.md §Architecture decisions`. Rejected alternatives flow to `docs/pillars/rejected.md` + ADR §Alternatives. |
-   | `./brainstorm/pillars/backlog.md` (new items) | `docs/history/backlog.md` (full operational tracking) | Update `docs/pillars/backlog.md` (steering view) headlines if a new bucket emerges. |
-   | `./brainstorm/pillars/rejected.md` | `docs/pillars/rejected.md` | Referenced from ADR §Alternatives when tied to a committed decision. |
-   | `./brainstorm/pillars/milestones.md` | `docs/pillars/milestones.md` | Mirror in `docs/structure.md §Health log` if the milestone is a structural change. |
-   | `./brainstorm/pillars/questions.md` (still-open) | `docs/pillars/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) | Use the `documentation` skill's §8 Plan template format. |
+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:
+
+   | Session source | v9 destination(s) |
+   |---|---|
+   | `./brainstorm/pillars/doctrine.md` (additions / amendments) | module-local → `docs/modules/{m}/pillars/doctrine.md`; cross-module → `docs/architecture/domain-model.md` |
+   | `./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) |
+   | 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** |
+   | `./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 `scripts/build-ownership-index.sh` and `scripts/check-doc-drift.sh` if present; surface any new findings.
 
@@ -331,7 +334,7 @@ The session is now in **Explore mode**. Resolution-style flows are opt-in from h
 
 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 persistent pillars in `docs/pillars/` are now updated; the next session primes from them.
+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.
 
 11. Print: "Run `/technical-brainstorm start` to resume."
 

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

@@ -13,7 +13,7 @@ keywords:
 plugin: kb-agi
 ---
 
-# nupilot Knowledge Hub — router
+# nuStack Knowledge Hub — router
 
 This repo is a flat Obsidian vault that you read on the user's behalf. It's the bridge from the front (positioning, claims) to the back (product and service specs); detailed execution lives downstream in the service repos.
 

package/data/harnesses/kb-agi/agents/kb-agi-init.md

@@ -151,7 +151,7 @@ Upkeep is run by the kb-agi agents (invoked by name); there is no `meta/goals/`
 ````markdown
 # genre — Sales
 
-The reader is positioning nupilot to someone else: a prospect, a partner, a teammate who needs the pitch. They want the claim and the proof behind it, not the implementation.
+The reader is positioning nuStack to someone else: a prospect, a partner, a teammate who needs the pitch. They want the claim and the proof behind it, not the implementation.
 
 **Default depth.** Start crisp. Lead with the answer in one or two sentences — what we can do, what makes it different — then offer the supporting detail rather than front-loading it. Go deeper only when the question reaches for it ("how exactly…", "what's underneath…").
 
@@ -213,7 +213,7 @@ This is a living index. It is hand-maintained today and kept fresh by the `kb-re
 ---
 
 ## "I want to understand the product"
-_What nupilot is, what it can do, the claims and their proof._
+_What nuStack is, what it can do, the claims and their proof._
 
 - _populated on migration_