@nurix/etna 0.18.22 → 0.18.23

package/data/harness-index.json

@@ -1,5 +1,5 @@
 {
-    "fingerprint": "5cb712a2bb9e",
+    "fingerprint": "191a460dc4ce",
     "harnesses": {
         "code": {
             "plugin": "code",

package/data/harnesses/code/CLAUDE.md

@@ -6,12 +6,7 @@ This file defines how AI coding agents — any vendor, any runtime — should wo
 
 ## Maintenance
 
-Invoke the `maintenance` agent whenever you judge the docs need it — not just at first setup. Standing triggers: a missing `docs/structure.md`, a `harness-version` marker behind the installed version, docs contradicting code, unowned source paths, or drift you notice while working. Don't reconcile any of these by hand:
-
-1. Invoke `maintenance` ("baseline this repo" / "reconcile the harness" / "docs health"). It auto-selects its mode — baseline when the version marker is missing or behind, coherence audit otherwise — then hands back.
-2. If it hands back with a follow-up (typically the module proposal), re-invoke it to finish.
-
-A repo with no `docs/structure.md` isn't reconciled yet — run the baseline before applying anything below. Runtimes without sub-agent dispatch: read `.claude/agents/maintenance.md` and execute its procedure inline. Each component's internals live in the component, not here.
+Invoke the `maintenance` agent whenever you judge the docs need it — not just at first setup: a missing `docs/structure.md` (the repo isn't reconciled — baseline before applying anything below), a `harness-version` marker behind the installed version, docs contradicting code, unowned source paths, or drift you notice while working. Never reconcile these by hand — the agent auto-selects its mode (baseline when the marker is missing or behind, coherence audit otherwise) and hands back; if it returns a follow-up (typically the module proposal), re-invoke it to finish. Each component's internals live in the component, not here.
 
 ---
 
@@ -20,7 +15,7 @@ A repo with no `docs/structure.md` isn't reconciled yet — run the baseline bef
 - Read **[`docs/structure.md`](docs/structure.md)** for the documentation map and folder authority (architecture, features, operations)
 - Read **[`docs/memory/`](docs/memory/)** for agent memory files (one per agent)
 - Prefer `docs/` over `README.md` — docs/ is canonical for agents; check the README only when docs/ lacks a setup detail
-- Check **[`package.json`](package.json)** for available scripts. Detect the package manager from the lockfile (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `package-lock.json` → npm) and use the matching command. Don't hardcode a specific manager.
+- Check **[`package.json`](package.json)** for available scripts. Detect the package manager from the lockfile — see `.claude/rules/general.md`; don't hardcode one.
 
 ---
 
@@ -30,11 +25,11 @@ Three peer modes plus a Completion step — enter wherever the user's thinking a
 
 | Mode | Enter when | Implemented by | Exits to |
 | --- | --- | --- | --- |
-| **Brainstorming** | explicit ask (`/brainstorm start`); or the user brings a large piece of work — a new system, a feature with many unknowns — most users don't know this mode exists, so recommend it: name what makes the work big and offer a session; or a user utterance contradicts a recorded design principle (a pillar) → name the principle and offer a session. Never auto-enter. | `brainstorm` agent + skill | LLD, Plan, or close + harvest |
+| **Brainstorming** | explicit ask (`/brainstorm start`); or offer a session — never auto-enter — when the user brings a large piece of work (name what makes it big) or an utterance contradicts a recorded pillar (name the principle) | `brainstorm` agent + skill | LLD, Plan, or close + harvest |
 | **LLD** (low-level design) | new feature work | `lld-mode` agent + `documentation` skill | Plan |
 | **Plan** | an LLD is approved | `documentation` skill → `docs/history/plans/YYYY-MM-DD-{slug}.md` | Completion |
 
-> Brainstorm entry needs a **basis** — a reference document or a one-shot brain dump; drip-sized asks (a bug fix, one button) are too small and get redirected. A **pillar** is a recorded strategic principle from a past brainstorm: in-progress sessions live under `docs/research/`, harvested ones under `docs/history/brainstorms/`, harvested doctrine under `docs/architecture/`. Runtimes without slash commands: read `.claude/skills/brainstorm/SKILL.md` and follow it inline. The LLD is the feature doc itself — `docs/features/{feature}.md`, design intent first, extended in place at Completion.
+> Brainstorm entry needs a **basis** — a reference document or a one-shot brain dump; drip-sized asks (a bug fix, one button) are too small and get redirected. A **pillar** is a recorded strategic principle from a past brainstorm: in-progress sessions live under `docs/research/`, harvested ones under `docs/history/brainstorms/`, harvested doctrine under `docs/architecture/`. The LLD is the feature doc itself — `docs/features/{feature}.md`, design intent first, extended in place at Completion.
 
 **On Plan Completion:**
 
@@ -42,11 +37,7 @@ Three peer modes plus a Completion step — enter wherever the user's thinking a
 2. Flip the feature LLD to `status: active`; extend it in place with the how-it-works sections; confirm its `owns:` globs against the actual code.
 3. The `boundary` skill must already have gated this plan before its first implementation step — see Ownership, Boundaries & Documentation.
 
-**On Brainstorm Close** (a separate procedure — when a brainstorm session ends, not when a plan completes):
-
-- The session record lives at `docs/research/{topic}-brainstorming/` (committed) while active; on close + harvest it moves to `docs/history/brainstorms/{topic}/` as provenance — see `docs/structure.md`.
-- Harvest conclusions by scope: doctrine, glossary, non-goals, information-architecture changes → `docs/architecture/`; decisions → `docs/architecture/decisions/` (one AD per subject — revising a recorded subject updates its AD in place); backlog items → `docs/history/backlog.md`.
-- Open questions block close.
+**On Brainstorm Close** (when a session ends, not when a plan completes): close + harvest is the skill's `stop` procedure — the record moves from `docs/research/{topic}-brainstorming/` to `docs/history/brainstorms/{topic}/` as provenance, and conclusions disperse by scope (architecture docs, ADs, backlog).
 
 ---
 
@@ -60,14 +51,14 @@ Which doc is canonical for which code paths is the **feature doc's own frontmatt
 
 Before modifying code in an unfamiliar area:
 
-1. Consult the **injected ownership index** — the generated `glob → doc · module · keywords · status` map. Match your path or topic (its `keywords:`) to the owning feature doc and read it before changes. (If no index appears in your context: either the repo isn't reconciled — see Maintenance — or your runtime doesn't inject context at session start; then derive it by scanning the `owns:` frontmatter of every doc in `docs/features/`.)
+1. Consult the **injected ownership index** (`glob → doc · module · keywords · status`). Match your path or topic to the owning feature doc and read it before changes. (No index in context ⇒ either the repo isn't reconciled — see Maintenance — or your runtime doesn't inject it — see Runtime Notes.)
 2. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes.
 
 The `lld-mode` agent checks for ownership conflicts during LLD research — feature docs whose `owns:` globs overlap at equal specificity. If conflicts are found, address them in the LLD before proceeding.
 
 ### Boundaries — check while you change
 
-A boundary is a contract between two pieces of code (or code and infra) that share an assumption with **no static link** between them — the column a raw SQL string names, the JSON envelope a client unwraps, the event string a dispatcher parses, the env var a deploy script reads. Changing one side ships green — compiles, lints, tests pass — and breaks the other at runtime. Boundaries are **diagnosed, not documented**: the `boundary` skill reads them fresh from source on every run (its `references/mechanisms.md` defines the failure mechanisms; the technology packs under `references/packs/` carry stack specifics), so nothing is persisted that could go stale.
+A boundary is a contract between two pieces of code (or code and infra) that share an assumption with **no static link** between them — the column a raw SQL string names, the env var a deploy script reads. Changing one side ships green — compiles, lints, tests pass — and breaks the other at runtime. Boundaries are **diagnosed, not documented**: the `boundary` skill reads them fresh from source on every run, so nothing is persisted that could go stale.
 
 **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, traces the consumers on the other side, and reports severity-ranked violations with suggested amendments and a pass/block verdict — in chat, read-only. Fold the amendments into the plan before coding. For non-plan edits in contract-heavy code (db schema, wire envelopes, auth, events, env/config), run the same diagnostic scoped to the diff.
 
@@ -78,7 +69,7 @@ A boundary is a contract between two pieces of code (or code and infra) that sha
 - When you move or rename source files: update the `owns:` globs of the feature doc that owns them so the generated ownership index stays accurate. A new doc that owns code declares its paths in its own `owns:` frontmatter — there is no separate map to update.
 - `docs/structure.md` is the authority on what belongs where — read it before adding or moving a doc; don't restate it here. One canonical source per topic — link, don't copy. Only `CLAUDE.md`, `AGENTS.md`, and `README.md` live at the repo root.
 
-> 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. Runtimes that can't invoke them natively: read the component file — `.claude/agents/<name>.md`; for skills, `.claude/skills/<name>/SKILL.md` plus any `references/` it points to — and follow it inline.
+> 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. Runtimes that can't invoke them natively: see Runtime Notes.
 
 ---
 
@@ -92,9 +83,7 @@ Project-specific learnings live in `docs/memory/` (git-tracked). Cross-project u
 | `docs/memory/{agent-name}.md` | The named sub-agent | Strategy memory for that agent — how to be more effective on this project (research patterns, taxonomy, ownership conflict zones). Never user-centric. |
 | Runtime user-level memory (paths in Runtime Notes) | The runtime's auto-memory system | User preferences, role, communication style, cross-project habits |
 
-If your runtime records memories automatically, override its default location for project-relevant facts. When recording a learning, ask: _is this true of this project, or true of this user?_ Project facts → `docs/memory/`. User facts → the runtime's user-level store. Runtimes without auto-memory: apply the same test when deciding where to write a learning.
-
-`docs/memory/main.md` is created on first write. Append entries dated `## YYYY-MM-DD — {topic}`; oldest at bottom is fine.
+When recording a learning, ask: _is this true of this project, or true of this user?_ Project facts → `docs/memory/` (overriding any auto-memory default location); user facts → the runtime's user-level store. `docs/memory/main.md` is created on first write; append entries dated `## YYYY-MM-DD — {topic}`.
 
 ---
 
@@ -112,19 +101,16 @@ When implementing a plan, if you discover work that is important but outside the
 
 Defaults — ❌ prohibitions hold unless the user explicitly asks otherwise; ✅ and ⚠️ items are standing policy:
 
-- ✅ **Tests — suite-first.** Tests ship with every change to product code or behavior, built as one maintained suite, never as one-off scripts:
-  - **Location**: all tests live in the repo's canonical test tree — `tests/`, or the framework convention the repo already uses (detect, don't invent). Mirror the source structure: `src/modules/auth/session.ts` → `tests/modules/auth/session.test.ts`. Never create test files at the repo root or scattered next to scratch scripts.
-  - **One framework — never chosen ad hoc**: use the runner the repo already has (detect from its config); if the repo has none, use the stack's framework named in the testing rule (`.claude/rules/testing.md`) and wire it up as the repo's canonical test command before writing the first test. Never introduce a second framework beside an existing one.
-  - **Shared plumbing**: fixtures, factories, and helpers live in `tests/helpers/` (or the suite's existing shared location) and are reused; duplicated setup across test files is a defect to refactor, not a pattern to follow.
+- ✅ **Tests — suite-first.** Tests ship with every change to product code or behavior, built as one maintained suite, never as one-off scripts. Framework choice, test-tree placement, and shared fixtures/helpers are `.claude/rules/testing.md` — the repo's existing runner and layout always win.
   - **What gets tests**: a new feature ships with tests for the behavior its LLD promises; a bug fix ships with a regression test that fails before the fix and passes after.
   - **Discipline**: run the affected part of the suite before declaring work complete and report results honestly. When an LLD or plan intentionally changes behavior, updating the affected tests to the new contract is part of the change — the ban is on weakening, skipping, or deleting a test to mask a failure you can't explain.
   - **Throwaway checks are not tests**: temporary verification scripts go to scratch space and are deleted, never committed into the test tree.
 - ❌ **Dependencies** – Never upgrade frameworks, libraries, or dependencies.
 - ❌ **Compatibility** – Never maintain backward compatibility unless specified.
-- ❌ **Branches & Worktrees [override]** – Never self-create git branches or worktrees; commit straight to the checked-out branch. This deliberately replaces any built-in "branch first when on the default branch" default — do not branch unless the user asks. Exception: when the user asks for a pull request, creating the branch the PR requires counts as being asked — create that branch **before** committing the PR's changes.
+- ❌ **Branches & Worktrees [override]** – Never self-create git branches or worktrees; commit straight to the checked-out branch. This replaces any built-in "branch first on the default branch" default. Exception: when the user asks for a pull request, create the branch the PR requires before committing its changes.
 - ❌ **Protected Files** – Before editing, if `docs/operations/protected-files.md` exists, read it and never modify any path it lists; also never modify `AGENTS.md` or the `protected-files.md` file itself.
 - ✅ **Browser Automation** – If your runtime provides browser automation, use it freely; no need to ask first. If it doesn't — or you are an agent that can't hold the browser connection (see Runtime Notes) — return a browser-verification checklist (URLs, actions, expected outcomes) for the orchestrating session or the user to run.
-- ✅ **Delegate at scale** – If your runtime supports sub-agent dispatch: offload large, independent, or parallelizable work (broad research, audits, multi-file implementation) to sub-agents; keep small, well-understood edits in the main session — a dispatch whose context hand-off costs more than the work itself is waste. Dispatch prompts must be self-contained (the sub-agent sees none of your conversation); parallelize independent dispatches. Let dispatches inherit the session's model unless your runtime supports tier selection and the task clearly wants one — a stronger tier for judgment-heavy work, a cheaper tier for mechanical fan-out (concrete tier names live in Runtime Notes, never in rules). No dispatch mechanism ⇒ do the work inline yourself.
+- ✅ **Delegate at scale** – If your runtime supports sub-agent dispatch: offload large, independent, or parallelizable work (broad research, audits, multi-file sweeps) to sub-agents with self-contained prompts (the sub-agent sees none of your conversation); parallelize independent dispatches; keep small, well-understood edits in the main session — a dispatch whose hand-off costs more than the work is waste. Dispatches inherit the session's model unless the runtime supports tier selection and the task clearly wants one — stronger for judgment-heavy work, cheaper for mechanical fan-out (concrete tier names live only in Runtime Notes). No dispatch mechanism ⇒ do the work inline.
 - ⚠️ **Plans** – Plans are created directly in `docs/history/plans/` (see Workflows). Once `Status: Complete` or `Status: Abandoned`, the file is frozen — never edited. If scope changes after completion, write a new dated plan that links back to the old one.
 - ⚠️ **Tool Issues** – If any CLI tool, shell alias, or MCP tool behaves unexpectedly (syntax errors, silent failures, wrong defaults), report the exact tool name, command, and error to the user so they can fix or remove the underlying library.
 
@@ -132,7 +118,7 @@ Defaults — ❌ prohibitions hold unless the user explicitly asks otherwise;
 
 ## File Structure
 
-- Add a file-path header comment at the top of each source file, in the file's native comment syntax — `// src/modules/example.js - Module for handling user authentication` (JS/TS), `# scripts/sync_users.py - …` (Python/shell/YAML), `-- db/seed/init.sql - …` (SQL). Place it below any shebang line; skip formats with no comment syntax (JSON, lockfiles) and generated files.
+- Add a file-path header comment at the top of each source file, in the file's native comment syntax — `// src/modules/example.js - Module for handling user authentication`. Place it below any shebang line; skip formats with no comment syntax (JSON, lockfiles) and generated files.
 - Add a 1-line description above each function whose purpose isn't fully evident from its name and signature: `// Extract JWT token from request based on endpoint type`. A comment that restates the name is noise. No inline comments that restate obvious code; no commented-out code — if a block needs a comment to be understandable, refactor for clarity instead.
 
 ---

package/data/harnesses/code/harness.json

@@ -1,11 +1,11 @@
 {
   "harness": "code",
   "name": "code",
-  "version": "3.1.6",
+  "version": "3.1.7",
   "files": [
     ".prettierrc.json",
     ".prettierignore",
     ".vscode/settings.json"
   ],
-  "digest": "e1a1b585018d"
+  "digest": "19916676801e"
 }

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

@@ -18,7 +18,7 @@ All npm packages at `latest`. Fake data comes from `@ngneat/falso` (the repo sta
 
 ## Conventions
 
-- **Suite, not scripts.** Tests live in the canonical test tree (`tests/`, mirroring `src/`), named `<subject>.test.ts`. Shared fixtures, factories, and helpers live in `tests/helpers/`. The harness `CLAUDE.md` Tests guardrail carries the full suite-first policy; this rule owns only the technology choices.
+- **Suite, not scripts.** Tests live in the canonical test tree — `tests/` mirroring `src/`, or the convention the repo already uses (detect, don't invent) — named `<subject>.test.ts`. Shared fixtures, factories, and helpers live in `tests/helpers/` (or the suite's existing shared location). The harness `CLAUDE.md` Tests guardrail carries the suite-first policy (what gets tests, discipline); this rule owns the technology and placement choices.
 - **Wire the canonical command.** `"test"` in package.json runs the whole unit suite (`vitest run`); e2e runs under `"test:e2e"`. A repo where `pnpm test`/`npm test` doesn't run the suite is misconfigured.
 - **Unit and E2E trees stay separate.** Vitest/Jest suites in `tests/`; Playwright/Maestro suites in `e2e/` with their own config — never mixed into the unit runner's glob.
 - **No test doubles for what you own.** Prefer real instances — in-memory SQLite for drizzle, the actual Express app via supertest — over mocks; mock only true externals (network via msw, time via the runner's fake timers).

package/data/harnesses/etna/harness.json

@@ -7,5 +7,5 @@
     ".prettierignore",
     ".vscode/settings.json"
   ],
-  "digest": "287a6a528ec4"
+  "digest": "26d944b51c7b"
 }

package/data/harnesses/etna/rules/testing.md

@@ -18,7 +18,7 @@ All npm packages at `latest`. Fake data comes from `@ngneat/falso` (the repo sta
 
 ## Conventions
 
-- **Suite, not scripts.** Tests live in the canonical test tree (`tests/`, mirroring `src/`), named `<subject>.test.ts`. Shared fixtures, factories, and helpers live in `tests/helpers/`. The harness `CLAUDE.md` Tests guardrail carries the full suite-first policy; this rule owns only the technology choices.
+- **Suite, not scripts.** Tests live in the canonical test tree — `tests/` mirroring `src/`, or the convention the repo already uses (detect, don't invent) — named `<subject>.test.ts`. Shared fixtures, factories, and helpers live in `tests/helpers/` (or the suite's existing shared location). The harness `CLAUDE.md` Tests guardrail carries the suite-first policy (what gets tests, discipline); this rule owns the technology and placement choices.
 - **Wire the canonical command.** `"test"` in package.json runs the whole unit suite (`vitest run`); e2e runs under `"test:e2e"`. A repo where `pnpm test`/`npm test` doesn't run the suite is misconfigured.
 - **Unit and E2E trees stay separate.** Vitest/Jest suites in `tests/`; Playwright/Maestro suites in `e2e/` with their own config — never mixed into the unit runner's glob.
 - **No test doubles for what you own.** Prefer real instances — in-memory SQLite for drizzle, the actual Express app via supertest — over mocks; mock only true externals (network via msw, time via the runner's fake timers).

package/data/harnesses/mobile/harness.json

@@ -7,5 +7,5 @@
     ".prettierignore",
     ".vscode/settings.json"
   ],
-  "digest": "e42a39e54bdb"
+  "digest": "849a333d7f63"
 }

package/data/harnesses/mobile/rules/testing.md

@@ -18,7 +18,7 @@ All npm packages at `latest`. Fake data comes from `@ngneat/falso` (the repo sta
 
 ## Conventions
 
-- **Suite, not scripts.** Tests live in the canonical test tree (`tests/`, mirroring `src/`), named `<subject>.test.ts`. Shared fixtures, factories, and helpers live in `tests/helpers/`. The harness `CLAUDE.md` Tests guardrail carries the full suite-first policy; this rule owns only the technology choices.
+- **Suite, not scripts.** Tests live in the canonical test tree — `tests/` mirroring `src/`, or the convention the repo already uses (detect, don't invent) — named `<subject>.test.ts`. Shared fixtures, factories, and helpers live in `tests/helpers/` (or the suite's existing shared location). The harness `CLAUDE.md` Tests guardrail carries the suite-first policy (what gets tests, discipline); this rule owns the technology and placement choices.
 - **Wire the canonical command.** `"test"` in package.json runs the whole unit suite (`vitest run`); e2e runs under `"test:e2e"`. A repo where `pnpm test`/`npm test` doesn't run the suite is misconfigured.
 - **Unit and E2E trees stay separate.** Vitest/Jest suites in `tests/`; Playwright/Maestro suites in `e2e/` with their own config — never mixed into the unit runner's glob.
 - **No test doubles for what you own.** Prefer real instances — in-memory SQLite for drizzle, the actual Express app via supertest — over mocks; mock only true externals (network via msw, time via the runner's fake timers).

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@nurix/etna",
-    "version": "0.18.22",
+    "version": "0.18.23",
     "description": "Bootstrap a project with a Nurix harness — copies the harness's CLAUDE.md, skills, agents, rules, and hooks directly into the project from a bundled payload (no marketplace fetch, no network).",
     "type": "module",
     "bin": {