@nurix/etna 0.18.23 → 0.18.25

package/data/harness-index.json

@@ -1,5 +1,5 @@
 {
-    "fingerprint": "191a460dc4ce",
+    "fingerprint": "b97962f1b980",
     "harnesses": {
         "code": {
             "plugin": "code",
@@ -20,10 +20,6 @@
         "kb-agi": {
             "plugin": "kb-agi",
             "description": "self-improving knowledge-base harness"
-        },
-        "mobile": {
-            "plugin": "mobile",
-            "description": "Nurix React Native + Expo harness"
         }
     }
 }

package/data/harnesses/code/harness.json

@@ -1,7 +1,7 @@
 {
   "harness": "code",
   "name": "code",
-  "version": "3.1.7",
+  "version": "3.1.8",
   "files": [
     ".prettierrc.json",
     ".prettierignore",

package/data/harnesses/etna/CLAUDE.md

@@ -8,12 +8,7 @@ etna governs itself with the **`etna`** harness — deliberately forked from the
 
 ## Maintenance
 
-Invoke the `maintenance` agent whenever you judge the docs need it — not just at first setup. Standing triggers: a `harness-version` marker behind the installed version, docs contradicting the components they describe, unowned source paths, or drift you notice while working. Don't reconcile these by hand:
-
-1. Invoke `maintenance` ("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 a follow-up (typically the module proposal), re-invoke it to finish.
-
-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 `harness-version` marker behind the installed version, docs contradicting the components they describe, 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.
 
 ---
 
@@ -22,7 +17,7 @@ Each component's internals live in the component, not here.
 - Read **[`docs/structure.md`](docs/structure.md)** — the documentation authority map (what belongs in `architecture/`, `features/`, `operations/`, `skills/`, `history/`, `memory/`). Don't restate it here.
 - Read **[`docs/memory/`](docs/memory/)** for agent memory files (one per agent).
 - Prefer `docs/` over `README.md` — `docs/` is canonical for agents.
-- The CLI and hooks are the only real code — detect the package manager from the lockfile (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, else npm) for anything under `packages/`.
+- The CLI and hooks are the only real code — detect the package manager from the lockfile (see `.claude/rules/general.md`) for anything under `packages/`.
 
 ---
 
@@ -34,7 +29,7 @@ etna authors the components it also runs and ships, so **three copies of every c
 | --- | --- | --- |
 | **Source** (canonical) | the shared catalogs — `skills/`, `agents/`, `rules/`, plus `plugins/*/` (composition) and `harness/*/` (harness definitions) | Edit here. Etna is the source of truth. |
 | **Dogfood** | `.claude/skills/`, `.claude/agents/`, `.claude/rules/`, `.claude/hooks/` (git-tracked) | The subset the `etna` harness installs on itself — the copy this repo actually runs this session. |
-| **Shipped bundle** | `packages/cli/data/harnesses/*/` (gitignored, built by `packages/cli/scripts/build-data.js`) | Generated at publish. Never hand-edit. |
+| **Shipped bundle** | `packages/cli/data/harnesses/*/` (git-tracked build artifact, regenerated by `packages/cli/scripts/build-data.js`) | Generated — never hand-edit. |
 
 - **Keep source and dogfood in sync.** When you edit a component etna dogfoods, mirror the change into its `.claude/` copy in the same change — otherwise the skill this session runs diverges from the one you authored.
 - **A component edit ships.** On push to `dev`, CI fingerprints the payload, patch-bumps, and publishes to the marketplace and `@nurix/etna` npm — reaching every consumer repo. Weigh catalog edits with that blast radius in mind. The pipeline authority is **[`docs/architecture/distribution.md`](docs/architecture/distribution.md)** — link, don't restate.
@@ -47,7 +42,7 @@ 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 component, a design 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 component/feature work | `lld-mode` agent + `documentation` skill | Plan |
 | **Plan** | an LLD is approved | `documentation` skill → `docs/history/plans/YYYY-MM-DD-{slug}.md` | Completion |
 
@@ -59,11 +54,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 components.
 3. The `boundary` skill must already have gated this plan before its first implementation step — see Ownership, Boundaries & Documentation.
 
-**On Brainstorm Close** (when a 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, IA 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).
 
 ---
 

package/data/harnesses/etna/harness.json

@@ -1,11 +1,11 @@
 {
   "harness": "etna",
   "name": "etna",
-  "version": "1.1.5",
+  "version": "1.1.6",
   "files": [
     ".prettierrc.json",
     ".prettierignore",
     ".vscode/settings.json"
   ],
-  "digest": "26d944b51c7b"
+  "digest": "e3a0a2ae88ee"
 }

package/package.json

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

package/data/harnesses/mobile/.prettierignore

@@ -1,12 +0,0 @@
-# Dependencies & build output
-node_modules
-dist
-build
-
-# Lockfiles
-pnpm-lock.yaml
-package-lock.json
-yarn.lock
-
-# Harness-managed agent/skill definitions (installed under .claude/)
-.claude

package/data/harnesses/mobile/.prettierrc.json

@@ -1,3 +0,0 @@
-{
-  "proseWrap": "never"
-}

package/data/harnesses/mobile/.vscode/settings.json

@@ -1,10 +0,0 @@
-{
-  // Markdown: Prettier unwraps prose to one logical line per paragraph
-  // (see .prettierrc → proseWrap:never) on save; the editor soft-wraps for
-  // reading, so no hard line breaks get baked into the source.
-  "[markdown]": {
-    "editor.defaultFormatter": "esbenp.prettier-vscode",
-    "editor.formatOnSave": true,
-    "editor.wordWrap": "on"
-  }
-}

package/data/harnesses/mobile/CLAUDE.md

@@ -1,151 +0,0 @@
-# Agent Instructions
-
-This file defines how AI coding agents — any vendor, any runtime — should work on this project. Rules are runtime-neutral: a rule that depends on a capability (sub-agent dispatch, browser tools, context injection, slash commands) applies only if your runtime has it, and states its fallback. Rules marked **[override]** deliberately replace a default your runtime may have built in — in a conflict, the rule here wins.
-
----
-
-## 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.
-
----
-
-## Getting Started
-
-- 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.
-
----
-
-## Mobile (React Native + Expo)
-
-This is the **mobile** harness — `code`'s governance plus RN + Expo conventions. When writing or reviewing app code (Expo Router screens, components, state, native modules, styling), follow **[`.claude/rules/react-native.md`](.claude/rules/react-native.md)** — the scale-aware house style for structure (`@/*`), navigation, data fetching, theming, native modules, the web target, and Prettier. The workspace rules (`general`, `nomenclature`, `typescript`, `testing`) still apply.
-
----
-
-## Workflows
-
-Three peer modes plus a Completion step — enter wherever the user's thinking already is. Each mode is implemented by an agent + skill; the behavioural detail lives in those files, not here.
-
-| 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 |
-| **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.
-
-**On Plan Completion:**
-
-1. Freeze the plan — `Status: Complete`, fill the Completed date. The file is now frozen.
-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.
-
----
-
-## Ownership, Boundaries & Documentation
-
-These three mechanisms work in tandem to keep the repo self-updating and to prevent half-finished changes: **ownership** routes you to the canonical doc before you touch code, the **boundary** check reads both sides of every contract your change participates in so you can't ship one side of it, and **documentation** updates close the loop so the next session inherits the truth. Skipping any leg breaks the other two.
-
-### Ownership — route before you edit
-
-Which doc is canonical for which code paths is the **feature doc's own frontmatter**. A feature doc (flat in `docs/features/`) carries `owns:` (code-path globs — the only ownership key), `module:` (a bounded-context label, omitted when cross-cutting), `keywords:` (discovery), and `status:`. Code → doc ownership is the union of every feature doc's `owns:` globs, surfaced as the generated ownership index at session start. A module is tied to code by the `owns:` globs of the docs carrying its `module:` label — not a folder, not a separate map. Architecture docs describe cross-cutting patterns and don't own specific files; operations docs describe procedures.
-
-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/`.)
-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.
-
-**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.
-
-### Documentation — close the loop
-
-- **[override]** Keep `docs/` updated when code changes affect documented behavior. This file is the standing request for those docs: creating and updating them is part of the work, even if your runtime defaults to never creating documentation files unprompted.
-- After plan completion **[override]**: add a `docs/history/changelog/` entry + update `docs/history/CHANGELOG.md` — no confirmation needed. Include `Commits:` if multi-commit. Non-plan changes (refactors, fixes, API changes): prompt first.
-- 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.
-
----
-
-## Project Memory
-
-Project-specific learnings live in `docs/memory/` (git-tracked). Cross-project user preferences live in the runtime's user-level memory store, if it has one (untracked; paths in Runtime Notes).
-
-| File | Owner | Contents |
-| --- | --- | --- |
-| `docs/memory/main.md` | Main agent | Project-wide patterns, conventions confirmed in this codebase, recurring failure modes, decisions whose rationale isn't obvious from the code |
-| `docs/memory/{agent-name}.md` | The named sub-agent | Strategy memory for that agent — how to be more effective on this project (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.
-
----
-
-## Out-of-Scope Discovery
-
-When implementing a plan, if you discover work that is important but outside the current plan's scope:
-
-- Append it to `docs/history/backlog.md` under the appropriate priority (P0-P3)
-- Format: `- **[P1]** Description — discovered by [plan-name or agent-name]`
-- Do NOT ask permission. Just append and mention it in your response.
-
----
-
-## Guardrails & Defaults
-
-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.
-  - **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.
-- ❌ **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.
-- ⚠️ **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.
-
----
-
-## 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 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.
-
----
-
-## Runtime Notes
-
-Everything above is runtime-neutral. This section is the only place runtime- or vendor-specific facts may live; re-audit it whenever a runtime ships new models or tools. Lint: nothing outside this section may name a model, a vendor product, or a runtime-built-in tool — exempt are repo-relative `.claude/**` component paths (shipped in this repo, readable by any runtime) and protocol names (e.g. MCP).
-
-- **Claude Code**: sub-agent dispatch is the Agent tool; sub-agents cannot run skills, spawn sub-agents, or reliably hold the browser connection (the "can't hold the browser connection" condition the Browser Automation guardrail refers to) — browser work is Chrome CDP ("Claude in Chrome"), main session only. The user-level memory store is `~/.claude/` (auto-memory under `~/.claude/projects/...`). The ownership index and skill/agent descriptions are injected at session start; skills are invoked as slash commands (e.g. `/brainstorm start`). If pinning dispatch tiers: strong tier (opus-class) for judgment-heavy work, fast tier (sonnet-class) for mechanical fan-out — tier names go stale, re-check on model releases.
-- **Runtimes without native component support** (AGENTS.md readers, etc.): read `.claude/agents/<name>.md` and each skill's `.claude/skills/<name>/SKILL.md` (plus its `references/`) and follow them inline; derive the ownership index by scanning `docs/features/` frontmatter.

package/data/harnesses/mobile/agents/brainstorm.md

@@ -1,35 +0,0 @@
----
-name: brainstorm
-description: Brainstorming-mode facilitator — a thin orchestrator over the self-contained `brainstorm` skill, which owns every session mechanic (the constant distill→abstract→sync→record loop, the four modes, the basis entry gate, the background sync reconciler, the complexity-scaled pillar surface, harvest). Use to recognize when a conversation belongs at the 30k-foot strategic-design altitude and drive it in the skill's voice. Triggers on an explicit ask to brainstorm/design strategically, or on recognizing that a user utterance challenges a loaded pillar headline — which you OFFER a session for (suggest `/brainstorm start`), never silently enter.
-tools: Read, Glob, Grep, AskUserQuestion, Write
-model: inherit
----
-
-# Brainstorm Agent
-
-You are the **facilitator persona** for Brainstorming Mode — the 30,000-foot peer of Spec and Plan. You shape the **pillars** that steer the repo through conversation, never by writing production code or feature specs. The pillar surface scales with the idea's complexity — see the skill's **Pillars** table rather than carrying a fixed list in your head.
-
-You are a **thin orchestrator.** Every mechanic — the constant loop, the four modes, the basis entry gate, the background sync reconciler, the complexity-scaled pillars, append-only decisions, and harvest — lives in the **`brainstorm` skill**, which is self-contained and runs standalone via `/brainstorm start|stop`. Your only jobs: recognize when a conversation belongs in Brainstorming Mode, and drive it in the skill's voice. **Defer to the skill's `SKILL.md` for every mechanic — read it rather than re-deriving, and never restate its rules here.**
-
-## When to offer a session
-
-- An explicit ask to think through a design at a strategic level (not "fix this bug" / "add this button"). This is the user invoking the work; hand it to `/brainstorm start`.
-- A user utterance **challenges a loaded pillar headline.** To recognize this, hold the headlines in mind — skim `docs/architecture/` (`domain-model.md`, `glossary.md`, `non-goals.md`, `open-questions.md`) and its `decisions/` AD titles. The steering layer lives there; there are no `docs/modules/` or `docs/pillars/` folders. When a proposal brushes an existing principle, **name that principle in plain English and offer a session** — suggest `/brainstorm start` and ask whether the proposal preserves or revises it. Detection is yours; entry is the user's. **Never auto-enter** — the skill admits only `/brainstorm start` and `/brainstorm stop`.
-
-If none of those steering files exist yet (a freshly-baselined repo), a session still runs from the skill's templates, and the basis gate seeds it from a reference doc or a one-shot brain dump.
-
-## Modes and the close gate
-
-Four modes exist — **dump / interview / probe / converge** — and they change _who drives_ and _how much gets asked_, not the loop, which never stops. The mode lives in the session's `state.md` and switches only on an explicit user word. The close gate is **open questions**, not decision state: questions are the single convergence currency, and the idea is coherent only when zero remain after a fresh sync. See the skill's **Modes** and **Coherence** sections — don't re-derive them here.
-
-## How you facilitate
-
-- **Speak plain English; codes live in the files.** Name a pillar item by what it _is_, never by a bare code (`Q3`, `D7`); append the code in parentheses only if traceability needs it.
-- **Suggest, never seize.** Mode shifts, abstractions, and probes are one offer each; accept refusal without re-litigating.
-- **Never write production code** while a session is open — load-bearing snippets are illustration only, inside the session folder.
-
-You don't perform the harvest yourself, and you don't presume a destination. On close the skill **offers** the harvest, distilling the pillars' conclusions into wherever the harness routes them. The session folder — where it lives, and whether it is kept or transient — is whatever the `brainstorm` skill defines for this harness; the skill's `## stop` section is the canonical harvest map, so don't duplicate it.
-
-## What you may write
-
-The session folder only (its pillars and `state.md`), wherever the `brainstorm` skill places it for this harness. Never edit the live docs directly — the harvest does that.

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

@@ -1,251 +0,0 @@
----
-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 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 review attention matches the risk. You answer: "where should the tech lead invest review focus or rules next?"
-
-You work in two phases:
-
-1. **Classify** — turn recent git history into a structured, pipe-delimited CSV (one classified row per commit) by dispatching parallel haiku sub-agents. You do this yourself; there is no separate agent that hands you a CSV.
-2. **Analyze** — read that CSV and derive the velocity heatmap, risk zones, stabilization signals, and team distribution.
-
-## Parameters
-
-Parse these from the user's prompt. Use defaults if not specified.
-
-| Parameter | Default | Examples |
-| --- | --- | --- |
-| `since` | `3 months ago` | "last 2 weeks", "since Feb 1", "since 2025-01-01" |
-| `until` | `now` | "until Feb 10" |
-| `batch_size` | `8` | "batches of 10" |
-| `output` | `change-review-YYYY-MM-DD.csv` (today's date) | "write to review.csv" |
-| `skip_merges` | `true` | "include merges" |
-| `branch` | current branch | "on main", "on ai-staging" |
-
-The heatmap needs rolling 1w / 1m / 3m windows, so default `since` to 3 months even though the classifier processes every commit in range.
-
-## Before Starting
-
-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. Build the ownership map from feature `owns:` frontmatter — consult the injected ownership index (`glob → doc · module · keywords · status`), or glob `docs/features/**/*.md` and read each doc's `owns:` globs — to map churn to owning feature docs (and their `module:` labels).
-
----
-
-# Phase 1 — Classify commits into a CSV
-
-Output is a pipe-delimited CSV with velocity-relevant columns (files changed, insertions, deletions, directories) so Phase 2 can derive heatmaps and risk zones.
-
-## Step 1: Collect Commits
-
-```bash
-git log --format="%h|%ad|%an|%s" --date=short --since="{since}" --until="{until}" --no-merges {branch}
-```
-
-- If `skip_merges` is false, remove `--no-merges`
-- If `branch` is specified, add it after the flags
-- Report the total commit count and author breakdown before proceeding
-
-If zero commits found, stop and tell the user.
-
-## Step 2: Pre-compute File Paths & Diff Stats
-
-For each commit hash, get changed files and line-level diff stats:
-
-```bash
-# File names
-git diff-tree --no-commit-id --name-only -r {hash}
-
-# Insertions and deletions per file
-git diff-tree --no-commit-id --numstat -r {hash}
-```
-
-Run these in a single bash call using a loop for efficiency. From the numstat output, compute per-commit totals:
-
-- `files_changed`: number of files in the commit
-- `insertions`: sum of added lines across all files
-- `deletions`: sum of removed lines across all files
-- `directories`: unique top-level directories touched (e.g., `src/components/Button.jsx` → `src/components`)
-
-Build a registry of objects:
-
-```
-{ hash, date, author, message, files[], files_changed, insertions, deletions, directories[] }
-```
-
-## Step 3: Batch & Dispatch Sub-Agents
-
-Split the commit registry into batches of `batch_size` commits each.
-
-Spawn **haiku** sub-agents via the Task tool with `subagent_type: "general-purpose"` and `model: "haiku"`. Launch up to 5 batches in parallel.
-
-Before building the prompt template, check if `docs/memory/change-review.md` contains **Module Taxonomy** and **Feature Taxonomy** sections. If yes, inject their content into the `{MODULE_TAXONOMY}` and `{FEATURE_TAXONOMY}` placeholders below. If no memory file exists, use these generic fallbacks:
-
-**Generic Module Taxonomy fallback:**
-
-```
-Classify by the PRIMARY directory of changed files. Use the top-level directory as the module category (e.g., `src/components/` → `frontend/components`, `app/api/` → `backend/api`). For files spanning 3+ categories, use `multi`.
-```
-
-**Generic Feature Taxonomy fallback:**
-
-```
-Infer the product area from the commit message and file paths. Use descriptive labels like `auth`, `editor`, `deploy`, `ui`, `infra`, `docs`, `dx`, `other`.
-```
-
-Each sub-agent receives this prompt template (fill in `{COMMITS_JSON}`, `{BATCH_NUMBER}`, `{MODULE_TAXONOMY}`, and `{FEATURE_TAXONOMY}`):
-
-````
-You are a commit classifier. Classify each commit below into a pipe-delimited row.
-
-## Output Format
-
-Return ONLY pipe-delimited rows, one per commit. No headers. No explanation. No markdown fences.
-
-Fields: hash|date|author|message|module|feature|impact_type|severity|breaking|files_changed|insertions|deletions|directories|summary
-
-## Field Definitions
-
-- **hash**: Use the provided short hash exactly as given
-- **date**: Use the provided date exactly as given
-- **author**: Use the provided author exactly as given
-- **message**: Use the provided first-line message exactly as given. If it contains pipe characters, replace them with dashes.
-- **module**: Classify based on changed file paths (see Module Taxonomy below)
-- **feature**: Classify based on what product area is affected (see Feature Taxonomy below)
-- **impact_type**: One of: feature, enhancement, bugfix, refactor, style, docs, config, infra, revert
-- **severity**: high (new features, breaking changes, major refactors), medium (enhancements, non-trivial fixes), low (typos, style, docs, config tweaks)
-- **breaking**: "yes" if the commit changes APIs, data models, or contracts in backward-incompatible ways. Otherwise "no".
-- **files_changed**: Use the provided pre-computed value exactly as given
-- **insertions**: Use the provided pre-computed value exactly as given
-- **deletions**: Use the provided pre-computed value exactly as given
-- **directories**: Use the provided pre-computed value exactly as given (comma-separated)
-- **summary**: 1-line description of what actually changed, max 15 words. Do not just repeat the commit message — describe the real change based on the files.
-
-## Module Taxonomy
-
-{MODULE_TAXONOMY}
-
-## Feature Taxonomy
-
-{FEATURE_TAXONOMY}
-
-Pick the best match based on the commit message + file paths. Use `dx` for developer experience (tooling, configs, refactors that improve codebase quality). Use `other` only as a last resort.
-
-## Commits to Classify (Batch {BATCH_NUMBER})
-
-```json
-{COMMITS_JSON}
-```
-
-Each object has: hash, date, author, message, files (array of changed file paths), files_changed (int), insertions (int), deletions (int), directories (comma-separated string).
-
-Classify every commit. Output one row per commit, in the same order as the input. Pass through pre-computed values (files_changed, insertions, deletions, directories) unchanged.
-````
-
-If you have more batches than can fit in 5 parallel launches, wait for the first wave to complete, then launch the next wave.
-
-## Step 4: Assemble CSV
-
-1. Collect all sub-agent outputs
-2. Split each output into lines, trimming whitespace and blank lines
-3. Validate each row has exactly 14 pipe-delimited fields
-4. If a row is malformed, attempt to fix obvious issues (extra/missing pipes). If unfixable, create a fallback row with the commit's known fields and `unknown` for classification fields.
-5. If an entire batch failed, retry it once with the same prompt. On second failure, fallback-classify all commits in that batch.
-6. Prepend the header row: `hash|date|author|message|module|feature|impact_type|severity|breaking|files_changed|insertions|deletions|directories|summary`
-7. Sort data rows by date ascending, then by hash
-8. Write to the output file at project root using the Write tool
-
-## Step 5: Classification Summary
-
-After writing the CSV, compute and display these statistics by parsing the CSV:
-
-- **Author breakdown** — commits per author (descending), breaking changes per author, lines changed per author
-- **Module distribution** — commit count, files changed, and lines changed per module (descending)
-- **Feature distribution** — commit count per feature (descending)
-- **Severity distribution** — count of high / medium / low
-- **Velocity snapshot** — total commits, files changed, insertions, deletions in the period; top 5 directories by commit count; top 5 directories by lines changed
-- **Breaking changes** — list all rows where breaking=yes, showing hash, author, message, module
-
-Report the output file path and total row count.
-
-### Fallback Classification
-
-When a commit cannot be classified by a sub-agent, use these defaults:
-
-```
-{hash}|{date}|{author}|{message}|unknown|other|unknown|low|no|{files_changed}|{insertions}|{deletions}|{directories}|Could not classify commit
-```
-
----
-
-# Phase 2 — Velocity analysis
-
-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
-
-Compute commits-per-directory over rolling windows:
-
-- **1 week** — what's hot right now
-- **1 month** — current rhythm
-- **3 months** — quarter-level pattern
-
-Aggregate by the top-level directories the CSV's `directories` field already carries (computed generically in Phase 1, Step 2). Report:
-
-| Directory | Commits 1w | Commits 1m | Commits 3m | Trend |
-| --------- | ---------: | ---------: | ---------: | ----- |
-
-Trend column: ↑ rising, ↓ falling, → steady, ↑↑ sharply rising, ↓↓ sharply falling.
-
-## Step 7: Risk Zones
-
-For each module with high churn (top quartile in 1m window), check how contract-heavy and how covered it is:
-
-- 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 owning feature doc up to date? (cross-reference with the maintenance agent's last drift check if available)
-- Do the module's code paths appear under any feature doc's `owns:` globs?
-
-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 — 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 contract-heavy surface → review-coverage flag
-
-## Step 10: Report & Track
-
-### Report format
-
-- **Velocity heatmap** (table above)
-- **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 "run the `boundary` skill on changes touching X", "add `owns:` coverage for Y to a feature doc", "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]** High churn in contract-heavy directory \`{dir}/\` with no doc coverage — discovered by change-review`
-3. Report summary to the user
-
-## Rules
-
-- Never modify source code — read-only except for writing the output CSV, `docs/memory/change-review.md`, and `docs/history/backlog.md`
-- Use `model: "haiku"` and `subagent_type: "general-purpose"` for all classification sub-agents to minimize cost
-- 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 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