@nurix/etna 0.3.1 → 0.3.6

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

@@ -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
@@ -20,11 +22,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)
+
+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 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).
+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 `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`.
+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,29 +313,30 @@ 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. |
-
-   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.
+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 `.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.
 
 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."
 
@@ -593,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
@@ -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_
 

package/data/harnesses/kb-agi/agents/kb-catch-stale.md

@@ -6,7 +6,7 @@ model: inherit
 plugins: [kb-agi]
 ---
 
-You are the **kb-catch-stale** goal-agent for the nupilot knowledge hub. One job: surface notes that have drifted out of date.
+You are the **kb-catch-stale** goal-agent for the nuStack knowledge hub. One job: surface notes that have drifted out of date.
 
 **Read first:** `meta/guidance.md` (the note model, `maturity` + `canonical` hints) — the contract that governs you. The procedure below is this agent's full, self-contained definition.
 

package/data/harnesses/kb-agi/agents/kb-find-gaps.md

@@ -1,12 +1,12 @@
 ---
 name: kb-find-gaps
-description: Audits the nupilot vault for missing notes — diffs each folder's metadata.md and the session gap-logs against the note graph to find coverage holes. Use when asked to find gaps, check coverage, or "what's missing". Proposes a ranked gap list by default; writes notes ONLY when the invocation explicitly asks it to.
+description: Audits the nuStack vault for missing notes — diffs each folder's metadata.md and the session gap-logs against the note graph to find coverage holes. Use when asked to find gaps, check coverage, or "what's missing". Proposes a ranked gap list by default; writes notes ONLY when the invocation explicitly asks it to.
 tools: Read, Grep, Glob, Bash
 model: inherit
 plugins: [kb-agi]
 ---
 
-You are the **kb-find-gaps** goal-agent for the nupilot knowledge hub. You have exactly one job: find what the vault should hold but doesn't, and surface it.
+You are the **kb-find-gaps** goal-agent for the nuStack knowledge hub. You have exactly one job: find what the vault should hold but doesn't, and surface it.
 
 ## First, read the contract
 

package/data/harnesses/kb-agi/agents/kb-fix-links.md

@@ -6,7 +6,7 @@ model: inherit
 plugins: [kb-agi]
 ---
 
-You are the **kb-fix-links** goal-agent for the nupilot knowledge hub. One job: keep the note graph sound — no dead links, no orphans.
+You are the **kb-fix-links** goal-agent for the nuStack knowledge hub. One job: keep the note graph sound — no dead links, no orphans.
 
 **Read first:** `meta/guidance.md` (the note model) — the contract that governs you. The procedure below is this agent's full, self-contained definition.
 

package/data/harnesses/kb-agi/agents/kb-refresh-frontdoor.md

@@ -6,7 +6,7 @@ model: inherit
 plugins: [kb-agi]
 ---
 
-You are the **kb-refresh-frontdoor** goal-agent for the nupilot knowledge hub. One job: keep the entry points pointing at the right notes.
+You are the **kb-refresh-frontdoor** goal-agent for the nuStack knowledge hub. One job: keep the entry points pointing at the right notes.
 
 **Read first:** `meta/guidance.md` (the note model, `canonical` hint) — the contract that governs you. The procedure below is this agent's full, self-contained definition.
 

package/data/harnesses/kb-agi/agents/kb-refresh-summaries.md

@@ -6,7 +6,7 @@ model: inherit
 plugins: [kb-agi]
 ---
 
-You are the **kb-refresh-summaries** goal-agent for the nupilot knowledge hub. One job: keep summary notes current with the raw material beneath them.
+You are the **kb-refresh-summaries** goal-agent for the nuStack knowledge hub. One job: keep summary notes current with the raw material beneath them.
 
 **Read first:** `meta/guidance.md` (the note model, the `maturity` ladder) — the contract that governs you. The procedure below is this agent's full, self-contained definition.
 

package/data/harnesses/kb-agi/agents/kb-sync-metadata.md

@@ -6,7 +6,7 @@ model: inherit
 plugins: [kb-agi]
 ---
 
-You are the **kb-sync-metadata** goal-agent for the nupilot knowledge hub. One job: keep folder `metadata.md` files honest.
+You are the **kb-sync-metadata** goal-agent for the nuStack knowledge hub. One job: keep folder `metadata.md` files honest.
 
 **Read first:** `meta/guidance.md` (the note model + the fixed `metadata.md` shape) — the contract that governs you. The procedure below is this agent's full, self-contained definition.
 

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@nurix/etna",
-    "version": "0.3.1",
+    "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.