@nurix/etna 0.16.0 → 0.17.0

package/data/harness-index.json

@@ -1,5 +1,5 @@
 {
-    "fingerprint": "19ff4c6bce0e",
+    "fingerprint": "b51d4ebd2a1e",
     "harnesses": {
         "code": "code-fable",
         "code-fable": "code-fable",

package/data/harnesses/code/CLAUDE.md

@@ -9,8 +9,7 @@ This file defines how AI agents (Claude, GPT, etc.) should work on this project.
 > A missing `docs/structure.md` — or a `harness-version` behind the installed harness — is the **symptom** of a repo that isn't harnessed yet, or whose harness is out of date. Don't reconcile it by hand. Drive the **reconcile chain** — you (the main session) own it, because `harness-manager` is a sub-agent that can't run skills or spawn sub-agents:
 >
 > 1. Invoke **`harness-manager`** (`"baseline this repo"` / `"reconcile the harness"`). It reconciles `docs/`, stamps the version, then hands back.
-> 2. If it hands back asking for boundaries (a fresh repo where `docs/boundaries/` is empty), run the **`boundary`** skill in `generate` mode (`/boundary generate`) to populate them.
-> 3. Re-invoke **`harness-manager`** so it proposes modules from those boundaries.
+> 2. If it hands back with a follow-up (typically the module proposal), re-invoke it to finish.
 >
 > Then continue. Each component's internals live in the component, not here.
 
@@ -37,7 +36,7 @@ Three peer modes plus a Completion step — enter wherever the user's thinking a
 | **Spec** | new feature work | `spec-mode` agent + `documentation` skill | Plan |
 | **Plan** | a spec is approved | `documentation` skill → `docs/history/plans/YYYY-MM-DD-{slug}.md` | Completion |
 
-On **Completion**: freeze the plan (`Status: Complete`) and flip the feature spec to `Status: Active`, extending it with how-it-works sections; then distil the plan's trail — if the memory inbox (`docs/memory/inbox/`) holds entries, run `distiller facts` (inbox→fact-cards), then `distiller docs` for the just-completed feature's doc drafts any pending deltas for approval (presented, never auto-written). The `boundary` skill (`check` mode) checks a plan's Proposed Changes against `docs/boundaries/` before coding; on brainstorm close, harvest by scope — module pillars → `docs/modules/{m}/pillars/`, cross-module doctrine → `docs/architecture/` / ADRs, new contracts → `docs/boundaries/`, backlog → `docs/history/`. Open questions block close.
+On **Completion**: freeze the plan (`Status: Complete`) and flip the feature spec to `Status: Active`, extending it with how-it-works sections; then distil the plan's trail — if the memory inbox (`docs/memory/inbox/`) holds entries, run `distiller facts` (inbox→fact-cards), then `distiller docs` for the just-completed feature's doc drafts any pending deltas for approval (presented, never auto-written). The `boundary` skill gates every approved plan before coding — it reads the source the plan touches and reports what would break (see **Boundaries** below); on brainstorm close, harvest by scope — module pillars → `docs/modules/{m}/pillars/`, cross-module doctrine + contract changes → `docs/architecture/` / ADRs, backlog → `docs/history/`. Open questions block close.
 
 ---
 
@@ -48,7 +47,7 @@ Before modifying code in an unfamiliar area:
 1. If **[`docs/routing.md`](docs/routing.md)** exists, read it for file-pattern → module/doc/agent mapping. If it doesn't exist yet, skip.
 2. Glob `docs/{features,modules/*/features}/**/*.md` and check `owns` frontmatter to find the owning feature doc (rolled up to its module); read it — and, if it rolled up to a declared module, that module's `CLAUDE.md` + `pillars/` — before changes.
 3. If `qmd` is installed, `qmd query --format json -c <collection> "<topic>"` (repeat `-c` to span this repo's collections; `qmd collection list` names them) searches the indexed docs with their context attached — prefer it when entering an unfamiliar area; absent ⇒ skip.
-4. **Check [`docs/boundaries/`](docs/boundaries/)** — if your change touches a documented boundary (entity model, schema, API, auth, channels, …), read that boundary file first. A `CRITICAL`/`HIGH` boundary warrants the `boundary` skill (`check` mode) before you start.
+4. If your change touches a cross-cutting contract area (entity model, db schema, wire envelope, auth/authz, event vocabulary, webhooks, env/config), run the **`boundary`** skill scoped to your change — it reads both sides of each touched contract in source and reports what would break.
 5. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes
 6. When you author a declared module's docs, its `docs/modules/{m}/CLAUDE.md` auto-loads (the pillar bootstrap) — follow it. For code work it's surfaced via step 2.
 
@@ -92,11 +91,9 @@ The spec-mode agent checks for ownership conflicts during research. If conflicts
 
 ## Boundaries
 
-`docs/boundaries/` holds the repo's **typed application boundaries** — the horizontal cross-cutting contracts (the *edges* between modules) where editing one module silently breaks another: e.g. the entity model, tenancy, auth, db-schema, wire-contracts, api, env-parity. Each is one file carrying `[BOUNDARY: type · severity]`, the modules it bounds, its shape (`transcribe`d inline for synthesized contracts, or a `file:line` `point`er for self-locating ones), invariants, blast radius, and a safe-change checklist.
+A boundary is a horizontal cross-cutting contract — entity model, db schema, wire envelope, auth/authz, event vocabulary, webhooks, env/config — where editing one side silently breaks the other. Boundaries are **diagnosed, not documented**: the `boundary` skill reads them fresh from source whenever a check runs, so they are never persisted as docs and can never go stale.
 
-One component owns this surface — the **`boundary` skill** — `generate` at baseline, `create`/`check`/`init` as you add contracts, plan changes, or reconcile. Its frontmatter is the canonical mode catalog over one shared knowledge root (`references/boundary-taxonomy.md`, the exhaustive catalog of boundary types).
-
-Without `docs/boundaries/` populated (`generate`), the `check` and `init` modes have nothing to check against.
+**Invoke the `boundary` skill after a plan is approved and before its first implementation step.** It parses the plan's Proposed Changes, reads the touched source files, identifies the contracts they participate in (its `references/boundary-taxonomy.md` is the catalog), traces the consumers on the other side, and reports severity-ranked violations with suggested plan amendments — in chat, read-only. Fold the amendments into the plan before coding. For non-plan edits in contract-heavy code, run the same diagnostic scoped to the diff.
 
 > Agents and skills live under `.claude/agents/` and `.claude/skills/`. Their triggers are model-invoked — refer to each component's frontmatter, not a registry table here.
 

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

@@ -1,13 +1,13 @@
 ---
 name: change-review
-description: Velocity + change-risk analysis. First classifies recent commits into a pipe-delimited velocity/severity CSV by dispatching parallel haiku sub-agents (module, feature, impact, severity, churn), then derives a commit heatmap, risk zones (high churn + low boundary coverage), stabilization signals, and team/bus-factor distribution. Self-contained — produces its own CSV, no separate git-history step. Use when planning where to invest in better boundaries or rules.
+description: Velocity + change-risk analysis. First classifies recent commits into a pipe-delimited velocity/severity CSV by dispatching parallel haiku sub-agents (module, feature, impact, severity, churn), then derives a commit heatmap, risk zones (high churn in contract-heavy code), stabilization signals, and team/bus-factor distribution. Self-contained — produces its own CSV, no separate git-history step. Use when planning where to invest in review focus or rules.
 tools: Bash, Read, Write, Glob, Grep, Task
 model: inherit
 ---
 
 # Change-Review Agent
 
-You analyze code-change velocity over time to find risk zones — where change is accelerating or decelerating, and whether boundary coverage matches the risk. You answer: "where should the tech lead invest in better boundaries or rules next?"
+You analyze code-change velocity over time to find risk zones — where change is accelerating or decelerating, and whether review attention matches the risk. You answer: "where should the tech lead invest review focus or rules next?"
 
 You work in two phases:
 
@@ -33,8 +33,7 @@ The heatmap needs rolling 1w / 1m / 3m windows, so default `since` to 3 months e
 
 1. If `./docs/memory/change-review.md` exists, read it for historical velocity snapshots, prior risk-zone flags, known concentration risks, and the project's **Module Taxonomy** / **Feature Taxonomy** (these classification hints used to live in a separate `git-history.md` memory file — they now live here).
 2. If a recent CSV from a prior run already exists at the project root (`change-review-YYYY-MM-DD.csv`), prefer it as input and **skip Phase 1** — don't re-classify commits unless the requested window changed.
-3. Read every file in `./docs/boundaries/` if the folder exists. Risk-zone scoring is "high churn + low boundary coverage" — without boundaries you can only produce a heatmap, not risk zones.
-4. Glob `./docs/{features,modules/*/features}/**/*.md` and read `owns` frontmatter to map churn to owning feature docs.
+3. Glob `./docs/{features,modules/*/features}/**/*.md` and read `owns` frontmatter to map churn to owning feature docs.
 
 ---
 
@@ -183,7 +182,7 @@ When a commit cannot be classified by a sub-agent, use these defaults:
 
 # Phase 2 — Velocity analysis
 
-Where Phase 1 classifies *what* changed, Phase 2 asks *where is change accelerating or decelerating* — and whether boundary coverage matches the risk. Read the CSV from Phase 1 (or the recent one found in Before Starting).
+Where Phase 1 classifies *what* changed, Phase 2 asks *where is change accelerating or decelerating* — and whether review attention matches the risk. Read the CSV from Phase 1 (or the recent one found in Before Starting).
 
 ## Step 6: Velocity Heatmap
 
@@ -202,40 +201,40 @@ Trend column: ↑ rising, ↓ falling, → steady, ↑↑ sharply rising, ↓↓
 
 ## Step 7: Risk Zones
 
-For each module with high churn (top quartile in 1m window), check boundary coverage:
+For each module with high churn (top quartile in 1m window), check how contract-heavy and how covered it is:
 
-- Does any `docs/boundaries/` file **Bound** this module (name it in its **Bounds** line)?
+- Does its code own cross-cutting contract surfaces (schema/data access, wire handlers, auth/authz, event dispatch, env/config readers)? Skim the module's files to judge — contract-heavy churn is where silent breakage lives.
 - Is the module's `owns` doc up to date? (cross-reference with the maintenance agent's last drift check if available)
 - Does the module appear in `docs/routing.md`?
 
-Flag risk zones: high churn × low coverage. These are where silent breakage is most likely.
+Flag risk zones: high churn × contract-heavy × low doc coverage. These are where silent breakage is most likely.
 
 ## Step 8: Stabilization Signals
 
-Identify modules where 1-week and 1-month velocity are both decreasing. Candidates for reducing review overhead — fewer boundaries needed where churn is dropping.
+Identify modules where 1-week and 1-month velocity are both decreasing. Candidates for reducing review overhead — lighter review needed where churn is dropping.
 
 ## Step 9: Team Distribution
 
 Per module, list which authors made the most commits in the 3-month window. Surface concentration risks:
 
 - One author > 70% of commits in a critical module → bus-factor flag
-- One author owns all changes touching a boundary → review-coverage flag
+- One author owns all changes touching a contract-heavy surface → review-coverage flag
 
 ## Step 10: Report & Track
 
 ### Report format
 
 - **Velocity heatmap** (table above)
-- **Risk zones**: top 5 high-churn / low-coverage modules with specific boundaries to consider adding (via the `boundary` skill, `create` mode)
+- **Risk zones**: top 5 high-churn modules that own contract-heavy surfaces, with the specific contracts at risk named
 - **Stabilization signals**: modules where review overhead can decrease
 - **Concentration risks**: bus-factor and review-coverage flags
-- **Recommendations**: prioritized list — typically "add a boundary for X (run the `boundary` skill, `create` mode)", "update routing.md to cover Y", "spread reviews of Z across more authors"
+- **Recommendations**: prioritized list — typically "run the `boundary` skill on changes touching X", "update routing.md to cover Y", "spread reviews of Z across more authors"
 
 ### Update tracking
 
 1. Write a snapshot to `docs/memory/change-review.md` with date and all four analysis sections above. Preserve any **Module Taxonomy** / **Feature Taxonomy** sections that improve future classification.
 2. Append items to `docs/history/backlog.md`:
-   - `- **[P1]** No boundary coverage for high-churn directory \`{dir}/\` — discovered by change-review`
+   - `- **[P1]** High churn in contract-heavy directory \`{dir}/\` with no doc coverage — discovered by change-review`
 3. Report summary to the user
 
 ## Rules
@@ -245,5 +244,5 @@ Per module, list which authors made the most commits in the 3-month window. Surf
 - Always report progress: "Dispatching batch 1-5 of 12..." etc.
 - If git commands fail (bad branch, bad date range), stop and report the error clearly
 - Pipe characters in commit messages must be replaced with dashes before writing to CSV
-- Risk-zone identification requires boundaries — if `docs/boundaries/` is missing or empty, produce the heatmap only and tell the user that risk-zone scoring needs typed boundaries (run the `boundary` skill, `generate` mode)
+- Risk-zone identification judges contract-heaviness from the code itself (Step 7) — no persisted boundary docs exist or are needed
 - A clean report (no risk zones) is valid for a low-churn, well-covered project

package/data/harnesses/code/agents/harness-manager.md

@@ -20,10 +20,6 @@ Reconcile is **declarative, not a migration ladder.** You converge to the *curre
 
 The upgrade story is the two run back-to-back: install refreshes the engine → you reconcile the docs to it.
 
-## You hand back — the boundary work is a main-session skill
-
-Generating the typed boundaries is the **`boundary` skill** (`generate` mode), and a skill runs in the *main session* — you are a sub-agent without the Skill tool, so you do **not** run it yourself. When reconcile reaches the boundary step (Step 6) you **return to the main agent with a next-step handoff** — *your final message is your return value*, and the main agent reads it, runs `/boundary generate`, then re-invokes you to propose modules. The chain lives in the caller, because only the main session can run the skill. (Same shape as before — only the target changed from a `boundary-mapper` sub-agent to the `boundary` skill.)
-
 ## Modes
 
 - **Reconcile** (incl. **baseline**) — read the repo's `harness-version`; if absent or behind the installed version, converge `docs/` to the installed shape and stamp the new version. The Bootstrap invokes this.
@@ -33,8 +29,8 @@ Generating the typed boundaries is the **`boundary` skill** (`generate` mode), a
 
 These are different axes — keep them clean:
 
-- **`maintenance` audits docs-vs-code *fidelity*** — is the documented behavior *true* of the code? (stale docs, broken `owns` globs, routing drift, a boundary file drifted from its source). It edits docs for content accuracy.
-- **You audit repo-vs-spec *conformance*** — is the governance *structure* shaped to the installed harness version? (version marker present and current, mandated scaffolds present, no lingering dissolved-version artifacts, modules declared where the boundary graph implies them).
+- **`maintenance` audits docs-vs-code *fidelity*** — is the documented behavior *true* of the code? (stale docs, broken `owns` globs, routing drift). It edits docs for content accuracy.
+- **You audit repo-vs-spec *conformance*** — is the governance *structure* shaped to the installed harness version? (version marker present and current, mandated scaffolds present, no lingering dissolved-version artifacts, modules declared where the code's bounded contexts imply them).
 
 You never edit a doc for content fidelity (that is `maintenance`); `maintenance` never reshapes the structure to a new version (that is you). Surfacing a statically-unresolved doc claim as a *question* in your hand-back (Step 1/Step 6) does **not** cross this seam — detection may cross, mutation never does. You observe and ask; you never assert falsity or fix the doc.
 
@@ -42,7 +38,7 @@ You never edit a doc for content fidelity (that is `maintenance`); `maintenance`
 
 1. Verify a **root `CLAUDE.md` exists** before any reconcile. If absent, **refuse** and instruct the user to install/copy the harness `CLAUDE.md` first (the CLI ships it; you never write it) — reconcile against a repo with no root instructions produces a half-installed system. Detect-and-instruct, not a gate.
 2. Resolve the **installed harness epoch** — read it from `.claude/harness.json`, shipped by the CLI at install. Never a number baked into this file. If `.claude/harness.json` is absent, the install predates the marker ⇒ instruct the user to re-run `npx @nurix/etna code`, then retry. The resolved epoch is the target.
-3. Read the repo's **current version** — the `harness-version` field in `docs/structure.md` frontmatter. Absent ⇒ the repo is unharnessed ⇒ baseline (reconcile from nothing). Equal to installed ⇒ report and stop, **except** when re-invoked to propose modules after `/boundary generate` populated `docs/boundaries/`: the version is already current from your first pass, so skip the stop and go straight to Step 6's populated branch. (Health asked ⇒ run Health.) Behind ⇒ reconcile forward.
+3. Read the repo's **current version** — the `harness-version` field in `docs/structure.md` frontmatter. Absent ⇒ the repo is unharnessed ⇒ baseline (reconcile from nothing). Equal to installed ⇒ report and stop, **except** when re-invoked for the Step 6 module proposal: the version is already current from your first pass, so skip the stop and go straight to Step 6. (Health asked ⇒ run Health.) Behind ⇒ reconcile forward.
 4. If `docs/memory/harness-manager.md` exists, read it for project-specific reconcile exceptions and prior decisions.
 
 ---
@@ -65,7 +61,6 @@ docs/
 │   └── {feature}/         #   subfolder for deep features
 ├── modules/               # Declared bounded contexts — NOT scaffolded empty; appear by declaration
 │   └── {module}/          #   CLAUDE.md + features/ + pillars/ (module-local doctrine, lazy)
-├── boundaries/            # Typed application boundaries — generated by the boundary skill
 ├── operations/            # Setup, development, deployment, CI/CD
 ├── history/
 │   ├── CHANGELOG.md       # Master changelog index
@@ -88,7 +83,8 @@ This is what makes reconcile more than a fresh scaffold. Detect old-shape artifa
 
 | If you find (old shape) | Fold to (current shape) |
 |---|---|
-| `docs/operations/guardrails.md` | one file per boundary under `docs/boundaries/` (then run `/boundary generate`) |
+| `docs/operations/guardrails.md` | fold durable contract notes into `docs/architecture/` |
+| `docs/boundaries/` (legacy persisted boundaries) | delete — boundary analysis is a plan-time diagnostic (the `boundary` skill reads contracts fresh from source); fold any human-authored knowledge (external consumers, intent, accepted exceptions) into `docs/architecture/` |
 | repo-wide `docs/pillars/` | module-local `docs/modules/{m}/pillars/`; cross-module doctrine → `docs/architecture/` |
 | `docs/architecture/overview.md` | split into `domain-model.md` / `glossary.md` / `non-goals.md` / `references.md` / `open-questions.md` |
 | flat feature docs that belong to a declared module | `docs/modules/{m}/features/` |
@@ -120,35 +116,28 @@ If the binary exists, register the docs subtrees once the tree is scaffolded. **
 
 1. **Per-subtree collections** — one `qmd collection add` per subtree **that exists** (skip absent ones), `{repo}` = the repo's directory name. Re-run-safe: an existing name/path prints "already exists" and no-ops — treat that as success, not a failure. **Never** `qmd collection add docs/memory` — that re-introduces the inbox; register only its in-scope child `docs/memory/facts`.
    - `qmd collection add docs/features --name {repo}-features`
-   - `qmd collection add docs/boundaries --name {repo}-boundaries`
    - `qmd collection add docs/architecture --name {repo}-architecture`
    - `qmd collection add docs/operations --name {repo}-operations`
    - `qmd collection add docs/memory/facts --name {repo}-facts`
    - `qmd collection add docs/modules --name {repo}-modules`
 2. **Context tree** — one `qmd context add` per registered collection root **that exists** (skip absent ones); re-add upserts, so it's safe to re-run:
    - `qmd context add qmd://{repo}-features/ "Feature abstractions — how each works + why it was built"`
-   - `qmd context add qmd://{repo}-boundaries/ "Typed cross-cutting contracts — severity-ranked seams"`
    - `qmd context add qmd://{repo}-facts/ "Distilled recent decisions/observations, provenance-linked"`
    - `qmd context add qmd://{repo}-modules/ "Module-local features + pillars (the module's why)"`
 3. `qmd embed -c <name>` once per collection just registered — generate the vectors so the lens is queryable. Always scope with `-c` (repeat per collection): the index is global, and a bare `qmd embed` re-embeds every repo's collections on the machine.
 
 This augments routing; it never supersedes the Step 6 ownership resolution.
 
-### Step 6 — Boundaries, then modules — hand back to the main session
-
-Generating the typed boundaries is the **`boundary` skill** (`generate` mode), which runs in the *main session* — you're a sub-agent without the Skill tool. So you **hand back**, you do not generate boundaries yourself. Your final message *is* your return value to the caller; end it with an explicit next step.
+### Step 6 — Module proposal
 
-If Step 5b skipped because `qmd` was absent, carry its one advisory line into this hand-back — *"qmd not installed — semantic retrieval unavailable; glob routing active."* — advisory, never an error, never a gate.
+Modules are *declared*, never inferred from physical layout. Derive the repo's candidate bounded contexts directly from the code and docs: distinct wire surfaces (who owns routes/handlers), schema/data-access ownership, entry points and process units, plus any contexts `docs/architecture/` or feature `owns` globs already name.
 
-Branch on whether `docs/boundaries/` is already populated:
+- Propose the derived contexts as candidate modules. For each, partition existing flat feature docs by `owns`-glob overlap.
+- **Propose — don't force.** Declaration is opt-in: a single-context app stays flat (so does a monolith whose contexts all share one kernel); declare `docs/modules/{m}/` only when the author accepts a context as a module. A module is tied to code by its `owns` globs, **layout-blind** — a workspace is not a module (one workspace may hold several contexts; one context may span workspaces).
 
-- **Empty** (typical fresh baseline) → finish here and **hand back**: report what you reconciled (structure + `harness-version` stamped) and end with — *"NEXT (main session): run `/boundary generate` to populate `docs/boundaries/`, then re-invoke me to propose modules (boundaries are now populated)."* Do **not** transcribe the boundary-generation process inline; that blurs the seam and rots. Stop.
-- **Populated** (an upgrade reconcile where boundaries already exist, or your second pass after the skill ran) → **propose modules from the boundaries** — modules are *declared*, never inferred from physical layout:
-  - Read the distinct vertices named across every `docs/boundaries/*` **Bounds** line (e.g. `apps/api`, `@acme/contracts`). These are the repo's bounded contexts, already enumerated.
-  - Propose them as candidate modules. For each, partition existing flat feature docs by `owns`-glob overlap.
-  - **Propose — don't force.** Declaration is opt-in: a single-context app stays flat; declare `docs/modules/{m}/` only when the author accepts a context as a module. A module is tied to code by its `owns` globs, **layout-blind** — a workspace is not a module (one workspace may hold several contexts; one context may span workspaces).
+If Step 5b skipped because `qmd` was absent, carry its one advisory line into the hand-back — *"qmd not installed — semantic retrieval unavailable; glob routing active."* — advisory, never an error, never a gate.
 
-Re-running you after the skill is safe — the structure work is already done (idempotent), so the second pass is just the module proposal.
+Re-running you is safe — the structure work is already done (idempotent), so a second pass is just the module proposal.
 
 **Observed doc-fidelity questions (advisory, not a gate).** If your Step 1 inventory noted any statically-unresolved doc claims, append them to the hand-back as an **optional** block — each entry phrased **as a question**, never an assertion of falsity:
 
@@ -172,17 +161,16 @@ Conformance, not fidelity. Report a table; fix nothing destructively without ask
 - **Published-version currency** *(advisory, network)* — the installed `.claude/harness.json` records the kit's `version`; the published kit may have moved past it. Attempt `npm view @nurix/etna version` (the kit is a restricted package — needs npm auth + network). **Guard:** on *any* failure — offline, no auth, npm absent, timeout — skip and report one line: *"couldn't check the published harness version — re-run `npx @nurix/etna code` to refresh to the latest."* On success, compare the published version against `.claude/harness.json`'s `version`; if published is ahead, recommend re-running the CLI to pull the newer kit. Never a gate, never blocks.
 - **Kit build fingerprint (digest)** *(informational)* — `.claude/harness.json` carries a `digest`: a deterministic fingerprint of the exact kit **build** the consumer installed (`build-data` computes it over the shipped bundle). Two installs share a digest iff they are byte-identical builds; a hotfix that changes kit bytes without bumping `version` still moves the digest — so it answers *which build am I on*, finer than `version`+`epoch` alone. **Don't recompute it over `.claude/` to self-check:** the installed layout is a superset of the build (the project `CLAUDE.md` sits at the repo root, `.claude/` adds `settings.json`/`harness.json`/local rule files), so paths and file sets differ **by design** — a recompute would never match. The actionable upgrade signals are the two checks above (epoch reconcile + published-version); the digest is provenance, and the seed for any future published-digest drift check.
 - **Scaffold completeness** — every mandated file present.
-- **Dissolved-version residue** — any `operations/guardrails.md`, repo-wide `docs/pillars/`, `architecture/overview.md`, or other old-shape artifact lingering.
-- **Module declaration coverage** — do the boundary `Bounds` vertices have declared module homes where the author intended them? (Surface gaps; never auto-declare.)
+- **Dissolved-version residue** — any `operations/guardrails.md`, repo-wide `docs/pillars/`, `architecture/overview.md`, a persisted `docs/boundaries/` tree, or other old-shape artifact lingering.
+- **Module declaration coverage** — do the repo's bounded contexts have declared module homes where the author intended them? (Surface gaps; never auto-declare.)
 - **`docs/tests/` ownership** — present-with-content, or absent. An empty/orphan `docs/tests/` is a finding (it is author-maintained; no scaffold owns it).
 
 ## Rules
 
 - **Declarative, idempotent.** Re-running on a current repo is a no-op. Converge to current shape; never replay a version ladder; never reconstruct a past shape.
 - **One sentinel.** `docs/structure.md` `harness-version` is the only baseline/version marker. Do not reintroduce a `docs/memory/index.md` "is-baselined" check.
-- **Modules are declared, layout-blind.** Seed from boundary vertices + `owns` globs; never from `pnpm-workspace.yaml`/workspace walls. Propose, don't force.
+- **Modules are declared, layout-blind.** Seed from the code's bounded contexts + `owns` globs; never from `pnpm-workspace.yaml`/workspace walls. Propose, don't force.
 - **You orchestrate docs; the `documentation` skill supplies templates.** It is a library — you never expect it to baseline.
-- **Hand back for boundaries.** Generating boundaries is the main-session `boundary` skill — you're a sub-agent without the Skill tool, so return a next-step handoff (`run /boundary generate`) and let the main session run it, then re-invoke you. Never transcribe the boundary-generation process inline.
 - **Never overwrite an existing root `README.md`.** It is human-authored.
 - **Stay in `docs/` (+ root `README.md` scaffold) and `docs/memory/harness-manager.md`.** You do not edit `CLAUDE.md` (the CLI ships it) or production code.
 - **Health reports; it does not remediate content.** Content fidelity is `maintenance`'s job.

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

@@ -1,6 +1,6 @@
 ---
 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 the `boundary` skill (`init` mode); pre-implementation impact checks by its `check` mode.
+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. Cross-cutting contract analysis is the `boundary` skill (`check` for plans, `scan` for diffs) — it derives contracts dynamically from source; there are no persisted boundary docs to audit.
 tools: Read, Glob, Grep, Edit, Write, Bash
 model: inherit
 ---
@@ -9,14 +9,14 @@ model: inherit
 
 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 the `boundary` skill):
-- **Code drifted from docs** (boundary violations in live code) → `boundary` skill, `init` mode
-- **Pre-implementation impact analysis** (checking a plan against the typed boundaries before coding) → `boundary` skill, `check` mode
+Out of scope (handled by the `boundary` skill, which derives contracts dynamically from source):
+- **Pre-implementation impact analysis** (checking a plan against cross-cutting contracts before coding) → `boundary` skill, `check` mode
+- **Diff-scoped contract analysis** (what could a change break across module edges) → `boundary` skill, `scan` mode
 
 ## 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/boundaries/` exists, read its files for context on the typed cross-module contracts the docs should reflect.
+2. If `./docs/memory/boundary.md` exists, read it for durable contract knowledge (external consumers, known gaps, accepted exceptions) relevant to the docs you audit.
 3. If `./docs/routing.md` exists, read it for the current file-pattern-to-doc mapping.
 
 ## Step 1: Build Ownership Map
@@ -25,7 +25,7 @@ Out of scope (handled by the `boundary` skill):
 2. Glob `docs/{features,modules/*/features}/**/*.md` and extract YAML frontmatter (`owns`, `touches`, `depends_on`)
 3. Build a map: glob pattern → owning doc
 
-**Boundary-first fallback.** If that glob yields **no `owns` frontmatter at all** (a real possibility — a boundary-first repo can carry thousands of LOC, a populated `docs/boundaries/`, and zero feature docs) **but `docs/boundaries/**` exists**, drive this pass's ownership/drift surface off the boundaries instead: each boundary's `Bounds`/`Shape` referents (the modules/paths it names) plus `docs/architecture/**` file-references become the **primary** ownership map for Steps 2–5. Feature-`owns` stays primary the moment any appears — this is a fallback, not a replacement. Don't re-mechanize the named-referent / path checks here; Step 2 already resolves boundary referents and Step 5 already greps architecture paths — this clause just promotes them to primary when feature-owns is empty. **Exempt the pre-code markers:** a referent a boundary marks `planned`/`point*`/`transcribe*` is intentionally not-yet-landed — never flag it absent (that is the greenfield contract, not drift); only a referent whose target *has* landed fires, via Step 2's planned-landed / transcribe-landed checks.
+**Architecture-first fallback.** If that glob yields **no `owns` frontmatter at all** (a fresh-baseline repo can carry thousands of LOC and zero feature docs), drive this pass's ownership/drift surface off `docs/architecture/**` file-references instead — they become the **primary** ownership map for Steps 2–5. Feature-`owns` stays primary the moment any appears — this is a fallback, not a replacement.
 
 ## Step 2: Validate Ownership
 
@@ -38,17 +38,9 @@ For each code symbol or path a doc explicitly **names** (function/export/route/t
 - Flag unresolved named referents as drift, phrased as a question (e.g. `docs/x.md:NN names fn() — no static definition found; confirm it is not generated/re-exported before treating as stale`)
 - On codegen/reflection/DI/barrel stacks where static resolution is unreliable, skip — yielding nothing is correct
 
-Also resolve **`point`-mode boundary pointers** in `docs/boundaries/**/*.md` — a boundary whose `Bounds`/`Shape` carries a `file:line` pointer (e.g. `self-locating in lib/db.js:14`):
-- Verify the named path still exists; a rename (e.g. `lib/db.js`→`lib/store.js`) leaves a stale pointer that **distill② can never repair — boundary docs are write-protected** — so this pass is where it surfaces, as a question
-- If the boundary carries a literal **`planned`** marker (or "pointer lands at implementation") on a named target **and that target now resolves to real code**, the pointer has gone stale the other way — the code landed but the doc still says planned. Raise it as a question (e.g. `db-schema.md is marked planned but packages/api/src/db/schema.ts now exists — confirm and convert the pointer to file:line`). A barrel/re-export at the named path counts as landed.
-- Same skip rule on unreliable-resolution stacks
-
-Also handle **`transcribe`-mode boundaries** — a boundary whose `Shape` transcribes a contract (an event/wire/config shape copied from doctrine) **until** the owning module lands, typically with a checklist line like *"replace this transcription when X lands"*:
-- If **X now exists**, the transcribed shape can have silently diverged from the real one — and a transcription names fields, so the divergence is field-level, not path-level (e.g. an event transcribed as `{ entity, event_kind, … }` against a landed module that uses `eventKind`). Raise it as a question that the transcribed shape be reconciled against the real one — or handed to a proposed `boundary init` run for that file (e.g. `outbox-events.md transcribes event_kind but the landed outbox module uses eventKind — confirm the transcription should be reconciled to the real shape`). Question-phrased, never asserted; never rewrite the boundary doc yourself (write-protected).
-
-Also check **`env-var-contract` boundaries** — a boundary whose job is to assert the env contract (typically *"every variable the code reads appears in `.env.example`"*). The named-referent check above covers code symbols and paths but not env vars, which live in a separate canonical file:
-- Extract the `UPPER_SNAKE` tokens the boundary names in its `Shape` (allow a trailing `*` glob, e.g. `MASTER_KEK*` matching `MASTER_KEK`, `MASTER_KEK_ID`). Grep each against the declared canonical `.env`/`.env.example` (the boundary names which file is canonical).
-- Raise any absence as a question (e.g. `env-vars.md names MASTER_KEK* but no MASTER_KEK* appears in .env.example — confirm the contract still holds`). Same skip rule when the canonical file isn't declared or doesn't exist.
+Also check the **env contract** when the repo declares a canonical `.env.example` (or equivalent). The named-referent check above covers code symbols and paths but not env vars, which live in a separate canonical file:
+- Extract the `UPPER_SNAKE` env keys the code reads (`process.env.X` and the deploy scripts' generated env). Grep each against the canonical `.env.example`.
+- Raise any absence as a question (e.g. `server reads MASTER_KEK but no MASTER_KEK appears in .env.example — confirm the contract still holds`). Skip when no canonical file exists.
 
 ## Step 3: Detect Doc Drift
 
@@ -108,7 +100,7 @@ If `qmd` is absent (`command -v qmd` finds nothing), **skip this whole step sile
 
 This catches **doc-area drift** — the subject the doc abstracts moving or vanishing from the indexed corpus. It does **not** catch a pure code rename that leaves the doc's prose unchanged: the anchor query semantically matches the doc's own text, so the result set doesn't shift. Code-symbol drift is Step 2's named-referent check, not this one — the two are complementary, not redundant.
 
-Glob `docs/{features,modules/*/features}/**/*.md`, `docs/boundaries/**/*.md`, `docs/architecture/**/*.md`, and `docs/operations/**/*.md` for docs carrying `anchors:` frontmatter. For each anchor query on such a doc, resolve it with `qmd query --format json -c <collection> "<query>"` — repeat `-c` per relevant `{repo}-*` collection (no comma lists; the collection set is what `qmd collection list` shows). If a query resolves to **nothing**, or to a result set that has **radically shifted** away from the area the doc describes, raise it as a drift finding **phrased as a question** — e.g. `docs/x.md anchors "<query>" — resolves to nothing; confirm the area moved before treating the doc as stale` — and ask the user. On **yes**, dispatch the remediation sub-agent (the same yes-branch as Step 6). On **decline or no action**, append it to `docs/history/backlog.md` at the finding's own P0–P3 severity per the **Declined realignment** branch in Step 6 — same scale, deduped, never a gate.
+Glob `docs/{features,modules/*/features}/**/*.md`, `docs/architecture/**/*.md`, and `docs/operations/**/*.md` for docs carrying `anchors:` frontmatter. For each anchor query on such a doc, resolve it with `qmd query --format json -c <collection> "<query>"` — repeat `-c` per relevant `{repo}-*` collection (no comma lists; the collection set is what `qmd collection list` shows). If a query resolves to **nothing**, or to a result set that has **radically shifted** away from the area the doc describes, raise it as a drift finding **phrased as a question** — e.g. `docs/x.md anchors "<query>" — resolves to nothing; confirm the area moved before treating the doc as stale` — and ask the user. On **yes**, dispatch the remediation sub-agent (the same yes-branch as Step 6). On **decline or no action**, append it to `docs/history/backlog.md` at the finding's own P0–P3 severity per the **Declined realignment** branch in Step 6 — same scale, deduped, never a gate.
 
 ---
 

package/data/harnesses/code/harness.json

@@ -1,7 +1,7 @@
 {
   "harness": "code",
   "name": "code-fable",
-  "version": "0.15.3",
-  "epoch": 13,
-  "digest": "c7bce77bd71f"
+  "version": "0.17.0",
+  "epoch": 14,
+  "digest": "adc67e13b079"
 }

package/data/harnesses/code/hooks/hooks.json

@@ -6,7 +6,7 @@
         "hooks": [
           {
             "type": "command",
-            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/session-reflect.js\"",
+            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/session-reflect.mjs\"",
             "async": true
           }
         ]
@@ -18,7 +18,7 @@
         "hooks": [
           {
             "type": "command",
-            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/prompt-recall.js\""
+            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/prompt-recall.mjs\""
           }
         ]
       }

package/data/harnesses/code/hooks/lib/{redact.js → redact.mjs}

@@ -1,6 +1,4 @@
-// harness/code/hooks/lib/redact.js — shared privacy filter: redacts secret shapes before ledger append.
-
-"use strict";
+// harness/code/hooks/lib/redact.mjs — shared privacy filter: redacts secret shapes before ledger append.
 
 // Patterns ordered most-specific first; each replaces a match with [redacted:{kind}].
 const RULES = [
@@ -34,4 +32,4 @@ function redact(text) {
   return out;
 }
 
-module.exports = { redact };
+export { redact };

package/data/harnesses/{code-fable/hooks/prompt-recall.js → code/hooks/prompt-recall.mjs}

@@ -1,11 +1,9 @@
-// plugins/code/hooks/prompt-recall.js — UserPromptSubmit hook: surface fact-cards relevant to the prompt via qmd BM25; stdout is injected as context.
+// plugins/code/hooks/prompt-recall.mjs — UserPromptSubmit hook: surface fact-cards relevant to the prompt via qmd BM25; stdout is injected as context.
 
-"use strict";
-
-const fs = require("fs");
-const os = require("os");
-const path = require("path");
-const { execFileSync } = require("child_process");
+import fs from "node:fs";
+import os from "node:os";
+import path from "node:path";
+import { execFileSync } from "node:child_process";
 
 const MIN_PROMPT_CHARS = 24;
 const MIN_SCORE = 0.45;

package/data/harnesses/{code-fable/hooks/session-reflect.js → code/hooks/session-reflect.mjs}

@@ -1,12 +1,14 @@
-// plugins/code/hooks/session-reflect.js — SessionEnd hook: reflect the session into durable lessons (headless haiku pass) appended to the actor's memory inbox.
+// plugins/code/hooks/session-reflect.mjs — SessionEnd hook: reflect the session into durable lessons (headless haiku pass) appended to the actor's memory inbox.
 
-"use strict";
+import fs from "node:fs";
+import os from "node:os";
+import path from "node:path";
+import { execFileSync, spawn } from "node:child_process";
+import { fileURLToPath } from "node:url";
+import { redact } from "./lib/redact.mjs";
 
-const fs = require("fs");
-const os = require("os");
-const path = require("path");
-const { execFileSync, spawn } = require("child_process");
-const { redact } = require("./lib/redact.js");
+// ESM has no __filename; derive it from this module's URL for the detached worker re-spawn.
+const __filename = fileURLToPath(import.meta.url);
 
 // A session below all three thresholds carries no lesson worth a model call.
 const MIN_TURNS = 8;

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

@@ -1,23 +1,14 @@
----
-applyTo: "**"
----
+# General Standards
 
-# Technology Choices & Standards
-
-Opinionated technology stack and implementation standards.
-
-## Environment & Versions
-
-### Runtime Versions
+## Runtime Versions
 
 - **Node.js:** 22 LTS (latest)
-- **Package manager:** project-determined — detect from lockfile (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `package-lock.json` → npm). Use the matching command in scripts; don't hardcode a specific manager.
-- **PostgreSQL:** 17
-- **Redis:** 7.x (latest)
+- **Package manager:** detect from lockfile (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `package-lock.json` → npm). Don't hardcode one.
+- **PostgreSQL:** 17 · **Redis:** 7.x (latest)
 
-### Recommended Packages
+## Recommended Packages
 
-No alternatives. No explanations for obvious choices. Just use these.
+No alternatives. Just use these.
 
 | Package                  | Version   | Use                    | Don't use               |
 | ------------------------ | --------- | ---------------------- | ----------------------- |
@@ -36,8 +27,8 @@ No alternatives. No explanations for obvious choices. Just use these.
 | react-window             | ^2.2.3    | List virtualization    | react-virtualized       |
 | nanoid                   | ^5.1.6    | ID generation          | uuid                    |
 | express                  | ^5.2.1    | HTTP server            | fastify, koa            |
-| prisma                   | ^7.2.0    | Database ORM           | sequelize, typeorm      |
-| @prisma/client           | ^7.2.0    | Database queries       | -                       |
+| drizzle-orm              | latest    | Database ORM           | prisma, sequelize, typeorm |
+| drizzle-kit              | latest    | Schema tooling         | -                       |
 | zod                      | ^4.2.1    | Schema validation      | yup, joi                |
 | jose                     | ^6.1.3    | JWT handling           | jsonwebtoken            |
 | microdiff                | ^1.5.0    | JSON object diffing    | deep-diff, just-diff    |
@@ -49,15 +40,24 @@ No alternatives. No explanations for obvious choices. Just use these.
 | cmdk                     | ^1.1.1    | Command palette        | kbar, ninja-keys        |
 | @monaco-editor/react     | ^4.7.0    | Code editor            | codemirror, ace         |
 | localforage              | ^1.10.0   | Client-side storage    | idb, dexie              |
-| socket.io-client         | ^4.7.0    | WebSocket client       | native WebSocket, ws    |
 | react-markdown           | ^10.1.0   | Markdown rendering     | marked, markdown-it     |
 | fast-deep-equal          | ^3.1.3    | Deep equality checks   | lodash.isEqual          |
 | @ngneat/falso            | latest    | Fake data generation   | @faker-js/faker, chance |
 | pino                     | ^10.1.0   | Logging                | winston                 |
 
----
+## Frontend
+
+Tailwind v4 + shadcn-based UI; conventions below.
+
+- **@nurix/components** — the UI component library (linked, pre-built); import by subpath, e.g. `@nurix/components/button`.
+- No components.json / shadcn CLI scaffold (.tsx, not .jsx) — consume the prebuilt library; never `npx shadcn add`.
+- Vite: `@tailwindcss/vite` + `@vitejs/plugin-react-swc`. Pin react / react-dom / react/jsx-runtime / react/jsx-dev-runtime to the app's single copy via `resolve.alias` (linked @nurix/* ship nested react — keep one hook dispatcher).
+- Tailwind v4, CSS-only (no tailwind.config.js, no PostCSS): styling runs through the `@tailwindcss/vite` plugin.
+- CSS entry `globals.css`, imports in order — `@import "./personality.css"` (token source) → `@import "tailwindcss"` → the library's `styles.css` — then `@theme inline {…}` mapping vars to tokens.
+- Tokens: CSS vars in `:root, :root[data-theme="light"]` + the archetype selector `[data-style="…"]` (personality.css), consumed as semantic Tailwind tokens (bg-card, text-foreground). Honor the archetype's radius/theme decisions (e.g. re-assert `--radius-*` to 0 for a flat archetype; add `@custom-variant dark` only if the project supports dark mode). The library bundles class-variance-authority, clsx, tailwind-merge.
+- Plus general styling rules (spacing in 2/4/6/8, object-cover, truncate, motion, color tokens — never hardcoded hex in components).
 
-## Express 5.x Setup
+## Express 5.x
 
 ```javascript
 app.use(cors({ origin: process.env.FRONTEND_URL }));
@@ -66,31 +66,14 @@ app.use(express.json({ limit: "10mb" }));
 app.use(rateLimit({ windowMs: 15 * 60 * 1000, max: 100 }));
 ```
 
-- Middleware order: body parsers, custom middleware, routes, error handlers
-- Use Express Router for modular routes
-- Centralized error handler as last middleware
-- Use middleware for auth
-
----
+- Middleware order: body parsers → custom middleware → routes → error handlers (centralized, last). Auth via middleware. Use Express Router for modular routes.
 
 ## API Response Format
 
 ```json
-{
-    "status": 1,
-    "message": "Message sent successfully",
-    "data": { "delivered": [{ "user@example.com": 2 }] }
-}
+{ "status": 1, "message": "Message sent successfully", "data": { "delivered": [{ "user@example.com": 2 }] } }
 ```
 
-**Error:**
-
-```json
-{
-    "status": 0,
-    "message": "Error description",
-    "data": null
-}
-```
+Error: `{ "status": 0, "message": "Error description", "data": null }`
 
 HTTP codes: `200`, `201` (created), `400`, `401` (not authenticated), `403` (not authorized), `404`, `500`

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

@@ -1,7 +1,3 @@
----
-applyTo: "**"
----
-
 # Nomenclature Guidelines
 
 ## Naming Guidelines

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

@@ -0,0 +1,19 @@
+# TypeScript
+
+TypeScript conventions. Compiles under `strict: true` and `noUncheckedIndexedAccess: true`.
+
+## Type Safety
+
+- Never `any` to silence the checker. Unknown value → type `unknown`, then narrow (type guard / `zod` parse).
+- Never weaken strictness. No `// @ts-nocheck`; `// @ts-expect-error` only with a same-line reason.
+- Infer locals & return types; annotate at boundaries (exports, props, contracts).
+
+## Generics
+
+Shared libraries (`@nurix/components`, etc.) are generic on purpose — that's what types `cell(row)`, checks `slug` against `keyof TData`, and ties `data`/`columns` together. Keep the safety; never widen to `any` to dodge it. State the row type **once per file**, then let inference carry it:
+
+- **Bind a repeated factory once** (preferred): `const col = defineColumn<BriefRow>;` → `col({...})`. No `<T>` per call; `row` stays typed. Canonical: `modules/briefs/BriefsListPage.tsx`.
+- **Infer JSX type args from props:** `<Table data={rows} columns={columns} />`, not `<Table<BriefRow> …>`.
+- **Anchor with a collection annotation** when nothing else can: `const columns: ColumnDefinition<BriefRow>[] = [...]`.
+
+Don't repeat `fn<Type>(…)` / `<Comp<Type>>` at every call site — cosmetic only (same safety, same emitted JS).