@nurix/etna 0.18.0 → 0.18.1

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

@@ -282,7 +282,7 @@ Append entries below, oldest at bottom. Format:
 Memory file initialized during documentation baseline.
 ```
 
-> The per-actor memory **inbox** (`docs/memory/inbox/`) is *not* a baseline scaffold — the `session-reflect` hook creates it mechanically on the first reflected session. See **§11 Memory inbox entry** for its format.
+> The per-actor memory **inbox** (`docs/memory/inbox/`) is _not_ a baseline scaffold — the `session-reflect` hook creates it mechanically on the first reflected session. See **§11 Memory inbox entry** for its format.
 
 ---
 
@@ -295,12 +295,12 @@ The four research-derived sections (**Affected Modules**, **Conventions to Follo
 ```yaml
 ---
 owns:
-  - src/feature-name/**     # projected at Draft, confirmed at Active
+  - src/feature-name/** # projected at Draft, confirmed at Active
 touches:
   - src/shared/state/feature.js
 depends_on:
   - docs/features/related-feature.md
-anchors:                    # optional — see §3 frontmatter reference
+anchors: # optional — see §3 frontmatter reference
   - "qmd query: wire envelope invariants"
 ---
 ```
@@ -428,7 +428,7 @@ model Resource {
 Sections fill in across the feature's lifecycle. No template swap — they accumulate in place.
 
 | When | Sections written | Source |
-|------|------------------|--------|
+| --- | --- | --- |
 | Status: Draft (design) | Goal, Goals & Non-Goals, Background, Approach, Open Questions, Risks | User interview |
 | Status: Draft (research) | Affected Modules, Conventions to Follow, Current Behavior, Ownership Conflicts | spec-mode agent |
 | Status: Draft → Active (implementation lands) | Architecture, Key Functions, State, Redux, Files; frontmatter `owns`/`touches` confirmed against real code | Main agent (from actual code) |
@@ -635,11 +635,11 @@ Three sections are required: **Decision**, **Context**, **Consequences**. Everyt
 ```markdown
 ---
 title: "ADR-NNN: Short title in sentence case"
-status: Accepted              # Proposed | Accepted | Deprecated | Superseded by ADR-NNN
+status: Accepted # Proposed | Accepted | Deprecated | Superseded by ADR-NNN
 date: YYYY-MM-DD
 decision-owner: Name
-reviewers: []                 # optional
-supersedes:                   # optional, e.g., ADR-005
+reviewers: [] # optional
+supersedes: # optional, e.g., ADR-005
 tags: [adr]
 ---
 
@@ -656,12 +656,15 @@ tags: [adr]
 ## Consequences
 
 **Positive:**
+
 - [What becomes easier]
 
 **Negative:**
+
 - [What becomes harder, what we accept reluctantly]
 
 **Risks:**
+
 - [Second-order effects you can already see, with mitigations if known]
 
 <!-- Optional sections below. Include only when warranted by the decision's weight. -->
@@ -672,10 +675,10 @@ tags: [adr]
 
 ## Options Considered
 
-| Option | Pros | Cons | Outcome |
-|---|---|---|---|
-| **Option A** | … | … | **CHOSEN** |
-| Option B | … | … | Eliminated — [reason] |
+| Option       | Pros | Cons | Outcome               |
+| ------------ | ---- | ---- | --------------------- |
+| **Option A** | …    | …    | **CHOSEN**            |
+| Option B     | …    | …    | Eliminated — [reason] |
 
 ## Deep Comparison
 
@@ -688,12 +691,12 @@ tags: [adr]
 ## Implementation Plan
 
 | Phase | Scope | Duration |
-|---|---|---|
-| 1 | … | … |
+| ----- | ----- | -------- |
+| 1     | …     | …        |
 
 ## Open Questions
 
-1. **[Question]** — *Default*: [stated default until resolved].
+1. **[Question]** — _Default_: [stated default until resolved].
 
 ## Acknowledgements
 
@@ -757,7 +760,7 @@ Skip any section that doesn't apply. Don't pad to fill the template.
 - **{Family 2}** — {what's in it.}
 - **{Family 3}** — {what's in it.}
 
-The full surface lives in [`{path/to/public-index}`]({path/to/public-index}).   ← optional pointer for libraries
+The full surface lives in [`{path/to/public-index}`]({path/to/public-index}). ← optional pointer for libraries
 
 ## Stack
 
@@ -767,32 +770,21 @@ The full surface lives in [`{path/to/public-index}`]({path/to/public-index}).
 
 ## Getting started
 
-\`\`\`bash
-{pm} install
-{pm} run dev       # what it does (port, URL)
-{pm} run build     # what it does
-{pm} run preview   # what it does (omit if not applicable)
-\`\`\`
+\`\`\`bash {pm} install {pm} run dev # what it does (port, URL) {pm} run build # what it does {pm} run preview # what it does (omit if not applicable) \`\`\`
 
 {Optional one-liner about first-run behavior — e.g., "Dev server lands on /playground."}
 
-## {Runtime entry point}   ← optional; e.g., "The playground", "CLI", "API endpoints"
+## {Runtime entry point} ← optional; e.g., "The playground", "CLI", "API endpoints"
 
 {Brief description of the dev/runtime surface.}
 
-| {Thing}              | {What it shows / does}     |
-| -------------------- | -------------------------- |
-| `{route or command}` | {description}              |
+| {Thing}              | {What it shows / does} |
+| -------------------- | ---------------------- |
+| `{route or command}` | {description}          |
 
 ## Layout
 
-\`\`\`
-src/
-├── {entry-file}         # {purpose}
-├── {folder}/            # {purpose}
-│   └── ...
-└── {folder}/            # {purpose}
-\`\`\`
+\`\`\` src/ ├── {entry-file} # {purpose} ├── {folder}/ # {purpose} │ └── ... └── {folder}/ # {purpose} \`\`\`
 
 ## Adding a {primary unit}
 
@@ -801,7 +793,7 @@ src/
 3. {Wire into the playground / example app / test harness so reviewers can see it render.}
 4. {Document any divergence from upstream in `docs/{...}`.}
 
-## Styling   ← optional; replace with whichever cross-cutting concern matters most
+## Styling ← optional; replace with whichever cross-cutting concern matters most
 
 {Configuration notes that affect every consumer — design tokens, conventions, opt-outs.}
 

package/data/harnesses/code/skills/workflow-mapper/SKILL.md

@@ -45,6 +45,7 @@ Search patterns (adapt to framework):
 For each route, record: `{ method, path, handler_function, file }`.
 
 Filter out trivial CRUD (single DB call + response). Keep routes that:
+
 - Call `startWorkflow`, `addJob`, `enqueue`, `emit`, `publish` (async dispatch)
 - Call 2+ service functions sequentially
 - Have transaction blocks (`$transaction`, `BEGIN`, `withTransaction`)
@@ -66,6 +67,7 @@ Search patterns:
 ```
 
 For Temporal specifically, also check:
+
 - `temporal/config/workflowModules.js` — workflow registry with queues and dependencies
 - `temporal/config/activityModules.js` — activity aggregation
 
@@ -82,6 +84,7 @@ Search patterns:
 ```
 
 Focus on actions that:
+
 - POST/PUT/PATCH/DELETE to backend (not just GETs)
 - Dispatch multiple Redux actions in sequence
 - Start polling loops (`setInterval`, recursive `setTimeout`, retry patterns)
@@ -138,7 +141,7 @@ For each discovered entry point, trace the full execution path. Use one sub-agen
 Map code actors to diagram participants using this hierarchy:
 
 | Code Pattern | Participant Name |
-|---|---|
+| --- | --- |
 | React component, hook, event handler | `User` + `Frontend` |
 | Express/API route handler | `API` |
 | Temporal workflow | `Temporal` |
@@ -175,7 +178,7 @@ Not every API route is a "workflow". Classify and filter.
 ### Workflow Categories
 
 | Category | Criteria | Include? |
-|---|---|---|
+| --- | --- | --- |
 | **Orchestration** | Multi-step, multi-service, async handoffs (save, publish, deploy) | Always |
 | **Auth & Session** | Login, logout, token refresh, SSO flows | Always |
 | **Real-time** | WebSocket connections, live updates, presence | Always |
@@ -206,9 +209,7 @@ Simple workflows get a compact diagram. Complex workflows get full detail with a
 ````markdown
 ### {Workflow Name}
 
-**Trigger:** {What initiates this — button click, API call, cron schedule, event}
-**Participants:** {List of systems involved}
-**Key files:** {3-5 most important files in the chain}
+**Trigger:** {What initiates this — button click, API call, cron schedule, event} **Participants:** {List of systems involved} **Key files:** {3-5 most important files in the chain}
 
 ```mermaid
 sequenceDiagram
@@ -226,6 +227,7 @@ sequenceDiagram
 ```
 
 **Notes:**
+
 - {Important implementation detail not visible in diagram}
 - {Performance consideration, timeout, retry policy}
 - {Known edge cases or failure modes}
@@ -265,11 +267,11 @@ sequenceDiagram
 
 Write to the user-specified path, or default to `docs/architecture/workflows.md`. Before writing output files, ensure the target directory exists. Create it with `mkdir -p` if needed.
 
-````markdown
+```markdown
 ---
-generated: {YYYY-MM-DD}
-scope: {full | feature-name}
-workflows_found: {count}
+generated: { YYYY-MM-DD }
+scope: { full | feature-name }
+workflows_found: { count }
 ---
 
 # Codebase Workflows
@@ -279,7 +281,7 @@ Auto-generated workflow map. Traces execution paths from user action to terminal
 ## Table of Contents
 
 | Workflow | Category | Trigger | Participants | Complexity |
-|---|---|---|---|---|
+| --- | --- | --- | --- | --- |
 | [{Name}](#{anchor}) | {Category} | {Trigger} | {Count} | {Simple/Moderate/Complex} |
 
 ---
@@ -287,6 +289,7 @@ Auto-generated workflow map. Traces execution paths from user action to terminal
 ## Orchestration Workflows
 
 ### {Workflow Name}
+
 {Diagram + metadata as defined in Phase 4}
 
 ---
@@ -294,6 +297,7 @@ Auto-generated workflow map. Traces execution paths from user action to terminal
 ## Authentication & Session Workflows
 
 ### {Workflow Name}
+
 {...}
 
 ---
@@ -301,6 +305,7 @@ Auto-generated workflow map. Traces execution paths from user action to terminal
 ## Real-time Workflows
 
 ### {Workflow Name}
+
 {...}
 
 ---
@@ -308,6 +313,7 @@ Auto-generated workflow map. Traces execution paths from user action to terminal
 ## Event-driven Workflows
 
 ### {Workflow Name}
+
 {...}
 
 ---
@@ -315,6 +321,7 @@ Auto-generated workflow map. Traces execution paths from user action to terminal
 ## Scheduled Workflows
 
 ### {Workflow Name}
+
 {...}
 
 ---
@@ -322,8 +329,9 @@ Auto-generated workflow map. Traces execution paths from user action to terminal
 ## Data Pipeline Workflows
 
 ### {Workflow Name}
+
 {...}
-````
+```
 
 ### Section Ordering
 
@@ -347,6 +355,7 @@ Launch 5 parallel sub-agents for Phase 1 (one per technique). Collect results, d
 ### Targeted Discovery
 
 User specifies a feature name. Skip broad Phase 1 scan. Instead:
+
 1. Find the feature's directory/files (grep for feature name in routes, components, workflows)
 2. Trace from those entry points only
 3. Output a single-feature workflow document
@@ -362,56 +371,68 @@ Read the existing workflow map file. For each workflow listed, check if the key
 ### Payload Storage Detection
 
 Look for patterns where large payloads are stored separately and referenced by ID:
+
 ```
 storePayload|savePayload|workflow_payload|jobData
 → then: retrievePayload|fetchPayload|getPayload (in the worker/activity)
 ```
+
 Note this in the diagram as a "Store payload → reference by ID" pattern.
 
 ### Optimistic Locking Detection
 
 Look for version comparison patterns:
+
 ```
 version.*!==|version.*conflict|StaleObjectError|OptimisticLock
 if.*serverVersion.*localVersion|if.*version.*mismatch
 ```
+
 These indicate conflict branching that should appear as `alt` blocks.
 
 ### Polling Loop Detection
 
 Look for patterns where the frontend waits for async completion:
+
 ```
 setInterval|setTimeout.*recursive|poll|retry.*status
 GET.*status\?.*workflowId|GET.*status\?.*jobId
 ```
+
 Note the polling interval and timeout in the diagram.
 
 ### Child Workflow / Sub-job Detection
 
 Look for spawned sub-processes:
+
 ```
 startChild\(|spawnChild|fork\(|.add\(.*queue
 Promise\.all.*map.*startWorkflow
 ```
+
 These should appear as nested sequences or separate linked diagrams.
 
 ### Transaction Boundary Detection
 
 Look for explicit transaction markers:
+
 ```
 \$transaction|\$executeRaw|BEGIN|COMMIT|ROLLBACK
 withTransaction|runInTransaction|atomic
 ```
+
 Group operations within a transaction using `rect` blocks in the diagram.
 
 ### Rate Limiting & Middleware Detection
 
 Look for middleware applied to route groups:
+
 ```
 rateLimit|rateLimiter|throttle
 authenticate|authorize|requireAuth|requireRole
 validate|validateBody|validateParams
 ```
+
 Note these as guards in the diagram using `opt` blocks or notes.
 
 ---

package/data/harnesses/code/skills/workflow-mapper/references/patterns.md

@@ -9,7 +9,7 @@ Concrete grep/glob patterns for each discovery technique. Agents should adapt th
 Identify the tech stack to select the right patterns:
 
 | Check | Pattern | Means |
-|---|---|---|
+| --- | --- | --- |
 | `package.json` contains `express` | `"express"` | Express backend |
 | `package.json` contains `@temporalio` | `"@temporalio"` | Temporal workflows |
 | `package.json` contains `bullmq` | `"bullmq"` | BullMQ job queues |

package/data/harnesses/code-fable/CLAUDE.md

@@ -30,11 +30,11 @@ This is the only step that runs **before** the harness exists; everything below
 
 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; or a user utterance challenges a loaded pillar headline → name the brushed principle and offer `/brainstorm start` (no auto-entry) | `brainstorm` agent + skill                                        | Spec, Plan, or close + harvest |
-| **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                     |
+| Mode | Enter when | Implemented by | Exits to |
+| --- | --- | --- | --- |
+| **Brainstorming** | explicit ask; or a user utterance challenges a loaded pillar headline → name the brushed principle and offer `/brainstorm start` (no auto-entry) | `brainstorm` agent + skill | Spec, Plan, or close + harvest |
+| **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 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.
 
@@ -59,11 +59,11 @@ For the protocol on _writing_ to memory (which file, what belongs there, what do
 
 Project-specific learnings live in `docs/memory/` (git-tracked). Cross-project user preferences live in `~/.claude/` (untracked).
 
-| 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          |
+| 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. |
-| `~/.claude/projects/...`      | Auto-memory system  | User preferences, role, communication style, cross-project habits                                                                                      |
+| `~/.claude/projects/...` | Auto-memory system | User preferences, role, communication style, cross-project habits |
 
 **Override the default auto-memory 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 → `~/.claude/`.
 
@@ -103,25 +103,14 @@ A boundary is a horizontal cross-cutting contract — entity model, db schema, w
 
 Unless explicitly requested:
 
-❌ **Tests** – Never generate, update, or modify test files.
-❌ **Dependencies** – Never upgrade frameworks, libraries, or dependencies.
-❌ **Compatibility** – Never maintain backward compatibility unless specified.
-❌ **Branches & Worktrees** – Never self-create git branches or worktrees. Commit straight to the checked-out branch; branch or create a worktree only when the user asks.
-❌ **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** – Use Chrome CDP / "Claude in Chrome" tools whenever they help (verifying UI, reproducing a flow, seeding or inspecting local data) — no need to ask first. **Main session only:** never drive the browser from a sub-agent or workflow executor — the session-bound Chrome connection destabilizes the sub-agent. A sub-agent that needs browser verification instead returns an explicit CDP checklist (exact URLs, actions, expected outcomes) for the orchestrator to execute in the main session.
-✅ **Orchestrate via Sub-agents** – Run the main session as an orchestrator: delegate substantive work (research, implementation, audits) to sub-agents spawned via the Agent/Task tool with `model: opus` (Claude Opus), keeping the main context for dispatch, coordination, and synthesis. Give each sub-agent a self-contained prompt; parallelize independent dispatches.
-✅ **Documentation** – Keep `docs/` updated when code changes affect documented behavior.
-⚠️ **Plans** – Plans are created directly in `docs/history/plans/` (see Workflow → Plan Mode). 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.
+❌ **Tests** – Never generate, update, or modify test files. ❌ **Dependencies** – Never upgrade frameworks, libraries, or dependencies. ❌ **Compatibility** – Never maintain backward compatibility unless specified. ❌ **Branches & Worktrees** – Never self-create git branches or worktrees. Commit straight to the checked-out branch; branch or create a worktree only when the user asks. ❌ **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** – Use Chrome CDP / "Claude in Chrome" tools whenever they help (verifying UI, reproducing a flow, seeding or inspecting local data) — no need to ask first. **Main session only:** never drive the browser from a sub-agent or workflow executor — the session-bound Chrome connection destabilizes the sub-agent. A sub-agent that needs browser verification instead returns an explicit CDP checklist (exact URLs, actions, expected outcomes) for the orchestrator to execute in the main session. ✅ **Orchestrate via Sub-agents** – Run the main session as an orchestrator: delegate substantive work (research, implementation, audits) to sub-agents spawned via the Agent/Task tool with `model: opus` (Claude Opus), keeping the main context for dispatch, coordination, and synthesis. Give each sub-agent a self-contained prompt; parallelize independent dispatches. ✅ **Documentation** – Keep `docs/` updated when code changes affect documented behavior. ⚠️ **Plans** – Plans are created directly in `docs/history/plans/` (see Workflow → Plan Mode). 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 file path at top of each file:
-  `// src/modules/example.js - Module for handling user authentication`
-- Add a 1-line function description as a comment above each function:
-  `// Extract JWT token from request based on endpoint type`
+- Add file path at top of each file: `// src/modules/example.js - Module for handling user authentication`
+- Add a 1-line function description as a comment above each function: `// Extract JWT token from request based on endpoint type`
 
 ---
 

package/data/harnesses/code-fable/agents/brainstorm.md

@@ -20,15 +20,15 @@ If none of those steering files exist yet (a freshly-baselined repo), a session
 
 ## 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.
+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.
+- **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 session folder *is* the product by default; if the repo is v9-harnessed the skill **offers** the adapter routing into the doc tree. The skill's `## stop` section is the canonical harvest map — don't duplicate it.
+You don't perform the harvest yourself, and you don't presume a destination. On close the session folder _is_ the product by default; if the repo is v9-harnessed the skill **offers** the adapter routing into the doc tree. The skill's `## stop` section is the canonical harvest map — don't duplicate it.
 
 ## What you may write
 

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

@@ -18,14 +18,14 @@ You work in two phases:
 
 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"                        |
+| 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.
 
@@ -66,6 +66,7 @@ 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
@@ -86,11 +87,13 @@ Spawn **haiku** sub-agents via the Task tool with `subagent_type: "general-purpo
 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`.
 ```
@@ -182,7 +185,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 review attention 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
 
@@ -195,7 +198,7 @@ Compute commits-per-directory over rolling windows:
 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.
 

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

@@ -9,14 +9,14 @@ model: inherit
 
 You bring a repo's `docs/` governance tree into conformance with the **installed** harness version, and you audit that conformance on demand. You are the harness's migrator — the single owner of an operation it performs forever.
 
-The keystone: **baseline and upgrade are the same operation.** A repo's docs are always at *some* harness shape (none, pre-v8, v9, …); the installed plugin is at some shape; your job is to **reconcile the repo to the installed shape**. Baseline is the degenerate case (reconcile from nothing). Upgrade is reconcile across a version gap. Same agent, same convergence.
+The keystone: **baseline and upgrade are the same operation.** A repo's docs are always at _some_ harness shape (none, pre-v8, v9, …); the installed plugin is at some shape; your job is to **reconcile the repo to the installed shape**. Baseline is the degenerate case (reconcile from nothing). Upgrade is reconcile across a version gap. Same agent, same convergence.
 
-Reconcile is **declarative, not a migration ladder.** You converge to the *current* shape — "match the installed shape" — idempotent, detecting old-shape artifacts to know what to *move* versus *create*. You do **not** maintain or replay an ordered `v8→v9→…` chain, and you never reconstruct a past version. (Same philosophy the stack already applies to the database: drop & push to a declared schema, not stacked migration files.)
+Reconcile is **declarative, not a migration ladder.** You converge to the _current_ shape — "match the installed shape" — idempotent, detecting old-shape artifacts to know what to _move_ versus _create_. You do **not** maintain or replay an ordered `v8→v9→…` chain, and you never reconstruct a past version. (Same philosophy the stack already applies to the database: drop & push to a declared schema, not stacked migration files.)
 
 ## The two version layers (don't confuse them)
 
-- The **CLI** (`npx @nurix/etna --name=code`) refreshes the *engine* — `CLAUDE.md` + `.claude/{agents,skills,rules,scripts}/`. That is not your job; the install does it.
-- **You** reconcile the *repo's authored data* — the `docs/` tree — to match that engine.
+- The **CLI** (`npx @nurix/etna --name=code`) refreshes the _engine_ — `CLAUDE.md` + `.claude/{agents,skills,rules,scripts}/`. That is not your job; the install does it.
+- **You** reconcile the _repo's authored data_ — the `docs/` tree — to match that engine.
 
 The upgrade story is the two run back-to-back: install refreshes the engine → you reconcile the docs to it.
 
@@ -29,10 +29,10 @@ The upgrade story is the two run back-to-back: install refreshes the engine →
 
 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). 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).
+- **`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.
+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.
 
 ## Before starting
 
@@ -82,7 +82,7 @@ While reading each markdown doc to classify it, if the doc names a code symbol i
 This is what makes reconcile more than a fresh scaffold. Detect old-shape artifacts and fold them forward:
 
 | If you find (old shape) | Fold to (current shape) |
-|---|---|
+| --- | --- |
 | `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/` |
@@ -110,7 +110,7 @@ Write `harness-version: <installed epoch>` into `docs/structure.md` frontmatter.
 
 ### Step 5b — Register the qmd retrieval lens (optional, skip-if-absent)
 
-Strictly optional and guarded on the binary — if `command -v qmd` finds nothing, **skip this entire step silently** (no error, no behavior change) and carry one advisory line into the Step 6 hand-back: *"qmd not installed — semantic retrieval unavailable; glob routing active."* The index is a **local rebuildable lens** — data stays in git; never commit index artifacts, and never use `qmd init` (that writes a project-local `.qmd`; the default global index keeps the repo clean).
+Strictly optional and guarded on the binary — if `command -v qmd` finds nothing, **skip this entire step silently** (no error, no behavior change) and carry one advisory line into the Step 6 hand-back: _"qmd not installed — semantic retrieval unavailable; glob routing active."_ The index is a **local rebuildable lens** — data stays in git; never commit index artifacts, and never use `qmd init` (that writes a project-local `.qmd`; the default global index keeps the repo clean).
 
 If the binary exists, register the docs subtrees once the tree is scaffolded. **Do not register one collection rooted at `docs/`** — qmd 2.5.3 hard-codes the `**/*.md` pattern (a custom positional glob is silently discarded) and has no `--ignore`/`--exclude` flag, so a `docs/`-root collection provably sweeps the consumable inbox queue at `docs/memory/inbox/` into the index. The inbox is **not** in scope (it is distilled into `memory/facts`, which is — and its entries are deleted on digestion, which would leave dangling index entries). Register one collection **per indexable subtree** instead — never `docs/memory` as a whole, only `docs/memory/facts` — so the inbox is excluded by construction:
 
@@ -130,12 +130,12 @@ This augments routing; it never supersedes the Step 6 ownership resolution.
 
 ### Step 6 — Module proposal
 
-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.
+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.
 
 - 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).
 
-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.
+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 is safe — the structure work is already done (idempotent), so a second pass is just the module proposal.
 
@@ -143,7 +143,7 @@ Re-running you is safe — the structure work is already done (idempotent), so a
 
 > - `docs/x.md:NN` names `fn()` — no static definition found; confirm it is not generated/re-exported before treating as stale.
 
-End the block with: *"NEXT (optional): run the maintenance agent to confirm or dismiss these — advisory, not a gate; baseline is complete regardless."* Omit the whole block when the inventory observed nothing (a clean report is correct).
+End the block with: _"NEXT (optional): run the maintenance agent to confirm or dismiss these — advisory, not a gate; baseline is complete regardless."_ Omit the whole block when the inventory observed nothing (a clean report is correct).
 
 If the user **declines** the advisory rather than running the follow-up, record each declined item in `docs/history/backlog.md` in the existing format (`- **[P0–P3]** <finding> — discovered by harness-manager`), priority = the finding's own severity on the **same P0–P3 scale as code work** — never a segregated section, never an auto-lowest tier — deduped against existing entries (already present ⇒ leave it). A backlog line is a record, never a gate.
 
@@ -157,9 +157,9 @@ Confirm all mandated files exist; `structure.md` carries the current `harness-ve
 
 Conformance, not fidelity. Report a table; fix nothing destructively without asking.
 
-- **Version currency** — `harness-version` present in `structure.md` and equal to installed? If behind/absent → recommend Reconcile. (This is the *repo-vs-installed* gap — it self-heals once the consumer reinstalls and re-runs you. The next two checks catch what reinstall *hasn't* happened yet, or was bypassed by a hand-edit.)
-- **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 --name=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.
+- **Version currency** — `harness-version` present in `structure.md` and equal to installed? If behind/absent → recommend Reconcile. (This is the _repo-vs-installed_ gap — it self-heals once the consumer reinstalls and re-runs you. The next two checks catch what reinstall _hasn't_ happened yet, or was bypassed by a hand-edit.)
+- **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 --name=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`, 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.)