@nurix/etna 0.19.33 → 0.19.34

package/data/harnesses/delivery/skills/documentation/templates/plan.md

@@ -0,0 +1,64 @@
+# Plan (docs/history/plans/YYYY-MM-DD-feature-name.md)
+
+Record. Use for: every implementation plan. Plans are created here directly with `Status: Draft`, flip to `Status: In Progress` when work starts, and freeze at `Status: Complete` or `Status: Abandoned`. Once frozen, never edit — write a new dated plan if scope changes. The plan records the journey; the truth it implemented lives on in the feature doc and any AD it touched.
+
+The `boundary` skill parses the **Proposed Changes** sections to check boundary impact before execution. Keep that structure stable — section headings and bullet shape are load-bearing for the parser.
+
+```
+# {Feature Name}
+
+**Status:** Draft | In Progress | Complete | Abandoned
+**Spec:** [docs/features/{feature}.md](../../features/{feature}.md)
+**Started:** YYYY-MM-DD
+**Completed:** YYYY-MM-DD   <!-- fill when status flips to Complete -->
+
+## Background
+
+Why this work is happening *now*. Link to the spec for *what* we're building; this section is the motivation and the trigger. One paragraph.
+
+## Proposed Changes
+
+### New Files
+
+- `src/path/new-file.js` — purpose
+
+### Modified Files
+
+- `src/path/existing.js` — what changes and why
+
+### New Entities / State
+
+- `entities.foo` — new Redux slice / DB table / persisted shape
+- Persisted state addition: `state.bar.baz` (default `null` for existing users on rehydrate)
+
+### API Changes
+
+- `POST /api/foo` — new route, request `{...}`, response `{status, data}`
+- `PUT /api/bar` — request shape changes; see Migration
+
+### Cross-Module Contracts Affected
+
+- List which cross-cutting contracts this plan affects (db schema, wire envelope, auth, events, env/config, …)
+- "None" is a valid answer and means the `boundary` check will pass cleanly
+
+## Implementation Steps
+
+1. Concrete, ordered, testable
+2. Each step ends with something verifiable
+3. ...
+
+## Done Criteria
+
+- [ ] Implementation complete and verified
+- [ ] Affected docs updated (use the injected ownership index to find them)
+- [ ] Changelog entry created in `docs/history/changelog/`
+- [ ] Plan marked `Status: Complete`, **Completed:** date filled
+
+## Open Questions
+
+- Question — who decides, by when
+
+## Risks
+
+- Risk — likelihood / impact / mitigation
+```

package/data/harnesses/delivery/skills/documentation/templates/protected-files.md

@@ -0,0 +1,37 @@
+# Protected Files
+
+Truth document. Use for: documenting critical files that need approval before modification.
+
+This doc answers *what is protected and why breaking it hurts* — nothing more. Don't duplicate function-level detail here (signatures, inputs/outputs): it drifts from both the code and the owning feature doc. The owning feature doc is the canonical reference for how the code works; link to it.
+
+```
+# Protected Files
+
+Critical files requiring approval before modification.
+
+## File List
+
+# Category 1 - Description
+path/to/critical/file1.js
+path/to/critical/file2.js
+
+# Category 2 - Description
+path/to/another/file.js
+
+## Risk Summary
+
+| Category   | Risk if Broken  |
+|------------|-----------------|
+| Category 1 | Specific impact |
+| Category 2 | Specific impact |
+
+## Why Protected
+
+### Category 1: [Name]
+
+**Purpose:** What these files do, one or two lines
+**Owning doc:** [docs/features/{feature}.md] — canonical reference for how this code works
+**Invariants:**
+- The behavior that must not break, stated as a constraint (not a function tour)
+- Important point 2
+```

package/data/harnesses/delivery/skills/documentation/templates/root-readme.md

@@ -0,0 +1,104 @@
+# Project Root README
+
+Truth document. Use for: the human-facing entry point at the repository root (`/README.md`) — what visitors and new contributors land on. Distinct from `docs/README.md` (the agent/doc index — see **docs/README.md (Documentation Root)** above). The two coexist; don't merge them.
+
+### Strategy
+
+The root README answers, in order:
+
+1. **What is this?** — one to two sentences, no marketing claims
+2. **What do I get if I install it?** — capability families
+3. **What's it built on?** — terse stack list with versions
+4. **How do I run it?** — the three or four scripts that matter
+5. **How is it laid out?** — directory tree, one-liner per significant folder
+6. **How do I extend it?** — numbered contribution checklist
+7. **What state is it in?** — pre-publish, beta, stable, internal
+
+Skip any section that doesn't apply. Don't pad to fill the template.
+
+### Writing rules
+
+- **Sentence-case headings.** "Getting started", not "Getting Started".
+- **Concrete over abstract.** Real versions, real paths, real commands. No "leverages cutting-edge…".
+- **The tagline answers "what is this?"** — not "why is it great?". Two sentences max.
+- **Tables for enumeration** (routes, commands, endpoints). **Bullets for families and categories.**
+- **Directory tree as a code block**, not a nested markdown list.
+- **Numbered checklist** for "how to add a thing" — readers should be able to follow it top-to-bottom without re-reading.
+- **Point to `docs/` for depth.** The root README links into deep docs; it doesn't host them.
+- **Detect the package manager from the lockfile** (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, otherwise npm) and write commands accordingly. Don't hardcode `npm` if the repo uses pnpm.
+
+### Template
+
+```markdown
+# {package-name}
+
+{One- to two-sentence positioning. What it is and what scope it covers. No superlatives, no value claims.}
+
+## What's in the box
+
+- **{Family 1}** — {what's in it; a few specific items, comma-listed.}
+- **{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
+
+## Stack
+
+- {Framework} {version} · {Language} {version}
+- {Build tool} {version}
+- {Other load-bearing deps}
+
+## 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)
+\`\`\`
+
+{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"
+
+{Brief description of the dev/runtime surface.}
+
+| {Thing}              | {What it shows / does} |
+| -------------------- | ---------------------- |
+| `{route or command}` | {description}          |
+
+## Layout
+
+\`\`\`
+src/
+├── {entry-file}        # {purpose}
+├── {folder}/           # {purpose}
+│   └── ...
+└── {folder}/           # {purpose}
+\`\`\`
+
+## Adding a {primary unit}
+
+1. {Drop the source under the right family/folder.}
+2. {Re-export from the public surface.}
+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
+
+{Configuration notes that affect every consumer — design tokens, conventions, opt-outs.}
+
+## Status
+
+{Pre-publish, beta, stable, internal-only. State the stability tier per surface — which APIs are contracts and which are experimental — so readers know what can be relied on.}
+
+## License
+
+{License name — scope. e.g., "UNLICENSED — internal use only", "MIT".}
+```
+
+### Baseline scaffolding behavior
+
+The baseline audit **does** scaffold the project root README when missing. The risk this template guards against — template-shaped placeholders that look abandoned — is mitigated by the writing rules above: fill every section with concrete details from the repo (real package manager from the lockfile, real scripts, real layout, real status). Skip sections that genuinely don't apply rather than leaving stubs.
+
+**Never overwrite an existing root README** during a baseline. If one is present — even sparse or outdated — leave it untouched. Treat updates to a pre-existing root README as a separate, explicit request.

package/data/harnesses/delivery/skills/documentation/templates/security-overview.md

@@ -0,0 +1,27 @@
+# Security Overview (docs/architecture/security.md)
+
+Truth document. Use for: the single place the system's security posture is stated — assets, trust boundaries, controls, and accepted risks. Controls link to the code that implements them; this doc asserts, the code proves.
+
+Required: **Trust boundaries**, **Controls**. Optional: Assets, Accepted risks.
+
+```
+# Security Overview
+
+## Assets
+
+- {What's worth protecting — data classes, credentials, tenant isolation}
+
+## Trust boundaries
+
+- {Boundary} — {what crosses it, and what checks the crossing} 
+
+## Controls
+
+| Control | Protects against | Implemented in |
+| ------- | ---------------- | -------------- |
+| {control} | {threat} | `{file/module}` |
+
+## Accepted risks
+
+- {Risk knowingly carried} — accepted because {reason}; owner: {who}. Revisit if: {trigger}.
+```

package/data/harnesses/delivery/skills/documentation/templates/structure.md

@@ -0,0 +1,65 @@
+# docs/structure.md (Authority Map)
+
+Truth document. Use for: defining which folder owns which topic and how docs are maintained.
+
+```
+---
+harness-version: 1.0.0
+---
+
+# Documentation Structure
+
+> This file is the entry point for understanding the docs folder.
+> `harness-version` above is the repo's single baseline/version sentinel — the `maintenance` agent (baseline mode) owns it and stamps the installed harness version (semver) on every reconcile.
+
+## Authority Map
+
+Each topic has one canonical location. Read from here, not from plans or changelogs.
+
+| Topic | Authority | Key Files |
+| ----- | --------- | --------- |
+| Code-path ownership (path → doc + module) | feature `owns:` frontmatter | the generated ownership index |
+| System overview | `docs/architecture/` | system-design.md |
+| Steering (domain model, glossary, non-goals) | `docs/architecture/` | domain-model.md, glossary.md, non-goals.md |
+| Architecture decisions (ADs) | `docs/architecture/decisions/` | AD-NNN-*.md |
+| API surface | `docs/architecture/` | api.md |
+| Security | `docs/architecture/` | security.md |
+| Feature behavior | `docs/features/` | {key files} |
+| Setup & development | `docs/operations/` | {key files} |
+| Environment / config surface | `docs/operations/` | environment.md |
+| Testing strategy | `docs/tests/` | strategy.md |
+| Historical plans | `docs/history/plans/` | YYYY-MM-DD-name.md |
+| Change records | `docs/history/changelog/` | `YYYY-MM-DD-{three-words}.md` — one per unit of work, written at commit time |
+| Migration runbooks | `docs/history/migrations/` | YYYY-MM-DD-name.md |
+| Deep-research artifacts | `docs/history/research/{topic}/` | README.md + findings.md + sources.md |
+| Brainstorm design records | `docs/research/{topic}-brainstorm/` (active; legacy `-brainstorming/`) → `docs/history/brainstorms/{topic}/` (harvested; user deletes or commits) | thesis.md + forks.md + ledger.md + state.md |
+| Backlog | `docs/history/` | backlog.md |
+
+## The Two Natures
+
+Every doc is a **truth document** (states current absolutes, topic-named, updated in place) or a **record** (dated account of activity, frozen or append-only). `architecture/`, `features/`, `operations/`, `tests/` hold truth; `history/`, `research/`, `memory/` hold records.
+
+- Truth documents are rewritten in place when reality changes — the change-story goes to a changelog entry, never into the truth doc's body.
+- Records freeze: plans at `Complete`/`Abandoned`, changelog entries and migration runbooks once written/executed. A scope change is a new dated record that links back.
+- Feature docs are the living reference for implemented features; an AD is the living truth for one decision subject, with its dated journey confined to its Decision Changelog tail.
+
+## Folder Rules
+
+- `docs/features/`: Living reference for implemented features. Each feature doc **carries** the `owns:` / `module:` / `keywords:` / `status:` frontmatter — `owns:` declares the code-path globs it owns (the only ownership key), `module:` is an optional bounded-context label, `keywords:` are discovery terms, `status:` is `active`/`draft`/`deprecated`. The SessionStart hook unions every feature's `owns:` globs into the injected ownership index.
+- `docs/architecture/`: The truth layer for system-wide shape: overview, domain model, glossary, non-goals, API surface, security, and `decisions/` (ADs — one per subject, updated in place, journey in each AD's Decision Changelog). Update when cross-cutting reality changes.
+- `docs/operations/`: How-to procedures for setup, development, and deployment, plus the environment registry. Update when workflows change. One-shot migrations do NOT live here — they are records (`docs/history/migrations/`).
+- `docs/tests/`: Testing strategy and test docs. Present when the repo has a test posture worth documenting.
+- `docs/history/plans/`: Records. Must have `Status:` field. Never modify after completion.
+- `docs/history/changelog/`: Records. One entry per unit of work (`YYYY-MM-DD-{three-words}.md`), written by whoever does the work and frozen inside the commit it describes. Entries carry the refinement context a diff cannot show — the ask in the user's words, iterations and rejections, skill survived/overridden verdicts, discoveries, pins. Format is the `documentation` skill's `templates/changelog-entry.md`; trigger and lifecycle are the `changelog` rule; distillation is the `retro` agent. Immutability begins at commit — a draft in the working tree is mutable until then, never after. Every entry appends a row to `docs/history/CHANGELOG.md`.
+- `docs/history/migrations/`: Records. One-shot migration/upgrade runbooks — authored before execution, outcome-stamped and frozen after.
+- `docs/history/research/{topic}/`: Deep-research artifacts — the dumped output of a research pass, one folder per topic (conventionally `README.md` synthesis + `findings.md` verified claims & citations + `sources.md`). A point-in-time, cited record — **not** a living authority doc: it owns no code (no `owns:` frontmatter) and is never edited to "stay current." A spec/plan links to it for grounding; a new question gets a new topic folder.
+- `docs/research/{topic}-brainstorm/` → `docs/history/brainstorms/{topic}/`: Brainstorm design records — the Brainstorming-Mode session for a topic (working surface `thesis.md` + `forks.md` + `ledger.md` + `state.md` + `basis/` + `fragments/`, plus an untracked `ops/` capture layer deleted at stop), written by the `brainstorm` skill and its twin agent. An active session lives under `docs/research/` (legacy folders carry the older `-brainstorming/` suffix); on a **passed harvest** it **moves** to `docs/history/brainstorms/` — the completion marker — and the **user decides whether the moved folder is deleted or committed** as provenance. Each of the two folders carries a `Readme.md` index (the skill reads it at start instead of scanning). Author-created (never scaffolded empty), one folder per design conversation. Owns no code (no `owns:` frontmatter); the harvest routes its conclusions into `architecture/`/`features/`/`history/`. (Distinct from `docs/history/research/{topic}/` above — that is a frozen deep-research record, not a brainstorm session.)
+- `docs/history/backlog.md`: Tracked work items. Append new items under appropriate priority.
+
+## Health Log
+
+<!-- Updated by maintenance agent — the sanctioned dated tail in this truth doc (SKILL.md § The Two Natures names the two bridges) -->
+| Date | Review Summary |
+| ---- | -------------- |
+| {today} | Initial baseline — v{harness-version} structure established |
+```

package/data/harnesses/delivery/skills/documentation/templates/system-overview.md

@@ -0,0 +1,32 @@
+# System Overview (docs/architecture/system-design.md)
+
+Truth document. Use for: the bird's-eye view — what the system is, its subsystems, and how they connect. The first doc a new reader opens after the README; austere and short (two screens max). Depth lives in feature docs — this doc maps, it doesn't explain.
+
+Required: **What this is**, **Subsystem map**. Optional: Key flows, Where the truth lives.
+
+```
+# System Overview
+
+## What this is
+
+{Two or three sentences: what the system does, for whom, in what environment it runs.}
+
+## Subsystem map
+
+┌──────────┐     ┌──────────┐     ┌──────────┐
+│ Frontend │────▶│   API    │────▶│    DB    │
+└──────────┘     └──────────┘     └──────────┘
+{One box per subsystem; label the arrows with the contract that crosses them.}
+
+- **{Subsystem}** — one line: what it owns. → [owning doc](../features/{feature}.md)
+
+## Key flows
+
+{At most two or three ASCII flow diagrams for the flows everything else hangs off — request lifecycle, auth, the core domain operation.}
+
+## Where the truth lives
+
+| Area | Canonical doc |
+| ---- | ------------- |
+| {area} | [{doc}](path) |
+```

package/data/harnesses/delivery/skills/documentation/templates/testing-strategy.md

@@ -0,0 +1,29 @@
+# Testing Strategy (docs/tests/strategy.md)
+
+Truth document. Use for: the repo's test posture — what is tested at which level, how to run it, and what is deliberately untested. The framework choices come from the harness testing rule; this doc records how *this repo* applies them.
+
+Required: **Levels**, **Running**. Optional: Deliberately untested, Adding a test.
+
+```
+# Testing Strategy
+
+## Levels
+
+| Layer | Runner | Lives in | Covers |
+| ----- | ------ | -------- | ------ |
+| Unit / integration | {runner} | `tests/` | {what} |
+| E2E | {runner} | `e2e/` | {what} |
+
+## Running
+
+- `{pm} test` — the whole unit suite (CI gate)
+- `{pm} run test:e2e` — {when to run}
+
+## Deliberately untested
+
+- {Area} — {why, and what verifies it instead (typecheck, boot check, manual journey)}
+
+## Adding a test
+
+1. {Where the file goes, what it's named, where fixtures live}
+```

package/data/harnesses/delivery/skills/escalate/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: escalate
+description: Use when a task's routed tier isn't good enough — a prompt keeps failing its evals at the tier the routing table assigns. The evidence-gated promotion procedure - demands the failing eval, writes the escalation changelog entry, records the new tier. Triggers on /escalate, "this needs a stronger model", "bump this to frontier", "the cheap model can't do this".
+---
+
+# Escalate — evidence-gated tier promotion
+
+Promotion is earned by a failing eval, never by intuition. This skill is the only legitimate path to running a task above its routed tier — and it is deliberately fast: one eval run of evidence, one entry, done. No approvals theater.
+
+## Procedure
+
+1. **Demand the evidence.** A completed `prompt-eval` run at the currently routed tier, failing the family threshold. No run ⇒ run it now (that is the whole gate). An old run doesn't count — the evidence is for the current prompt version.
+2. **Write the escalation entry** — this skill owns the format; `cost-report` parses these entries, so the shape is a contract:
+   - File: `docs/history/changelog/YYYY-MM-DD-{three-words}.md`, standard changelog-entry template, plus its `docs/history/CHANGELOG.md` row.
+   - **`Class: escalation`** — the fixed rendezvous keyword. Exactly this word; `cost-report` and `retro` match on it.
+   - `Change:` names the task type, the family, the failing score vs. threshold, and the tier movement (`standard → frontier`).
+   - `Discovered:` what the failure teaches about the tier's capability ceiling — this is the routing table's tuning signal.
+3. **Record the promotion scope**: one-off (this task runs high once) or standing (the routing row itself is wrong). A standing promotion also appends an out-of-scope discovery proposing the routing-table row change — the table is policy and moves by its own edit, not silently.
+4. **Dispatch at the new tier** and finish the work.
+
+## Rules
+
+- **The entry precedes the dispatch.** An escalation with no entry is an unevidenced promotion — the routing guardrails prohibit it.
+- **Escalation is symmetric.** When `regression-runner`'s demotion experiment passes a tier down, that result is recorded the same way (`Class: escalation`, direction down) — the table tunes on both signals.
+- **Frequency is signal, not failure.** Many escalations from one row mean the row is wrong; that is `retro`'s finding to make, from these entries. Never suppress one to keep the table looking right.

package/data/harnesses/delivery/skills/prompt-eval/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: prompt-eval
+description: Use when a prompt needs its quality measured — after drafting or revising a prompt, before certifying a library entry, or when comparing prompt variants. Runs the golden-set eval loop with rubric grading and reports deltas. Triggers on /prompt-eval, "eval this prompt", "does this variant score better", "run the golden set", "certify this prompt".
+---
+
+# Prompt Eval — the golden-set loop
+
+A prompt's quality claim is its eval result, nothing else. This skill runs the loop; conventions for golden sets, rubrics, and thresholds are `.claude/rules/evals.md`.
+
+## Procedure
+
+1. **Locate the family's golden set** at `evals/{family}/` — the owning feature doc names the family. A prompt with no golden set gets one *first* (eval-first: the set ships with the prompt, and `data-generator` drafts edge-case items for human review).
+2. **Run the set** against the prompt via `eval-runner` — every item, not a sample. Batch variants in one run so scores are comparable.
+3. **Grade with the family's rubric.** Mechanical checks (format, required fields, refusal correctness) grade in code; judgment dimensions grade against the rubric's anchors. Report per-dimension scores and the delta against the incumbent prompt's certified score.
+4. **Gate:** meeting the family's threshold on iteration is a *candidate*; certification for the library additionally requires the `judge` ship gate (frontier, one dispatch — the only frontier call in the loop).
+5. **Record:** the winning variant's scores go into its `prompt-library` entry; the losing variants' deltas belong in the changelog entry's refinement context.
+
+## Rules
+
+- **Iteration stays cheap.** The draft → eval → revise loop runs on economy (`eval-runner`) and standard (`prompt-iterator`) tiers; the frontier judge appears once, at the gate — never inside the loop.
+- **Never weaken a rubric to pass a prompt.** A rubric change is a design change to the family's eval suite: it goes through the owning feature doc, re-runs the whole family, and re-certifies every entry.
+- **A failing eval is a result, not an obstacle.** Report it honestly; if the family genuinely needs a stronger tier, that is the `escalate` skill's evidence.

package/data/harnesses/delivery/skills/prompt-library/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: prompt-library
+description: Use when creating, versioning, retrieving, or auditing a production prompt — any write into prompts/{family}/, any "which prompt do we use for X", any certification question. Owns the library entry format - tier certification, eval score, date. Triggers on /prompt-library, "add this to the library", "what's our prompt for", "is this prompt certified", "bump the prompt version".
+---
+
+# Prompt Library — versioned, certified entries
+
+`prompts/{family}/` is a library of certified production artifacts, not a scratchpad. Every entry is versioned, eval-scored, and tier-certified; scratch iterations live outside until they pass.
+
+## The entry format
+
+Each prompt is one file at `prompts/{family}/{name}.md` with frontmatter:
+
+```yaml
+---
+version: 3            # integer, bumped on every content change
+tier: standard        # the tier this prompt is certified for (economy | standard | frontier)
+eval-score: 0.94      # the certified golden-set score at this version
+certified: 2026-07-26 # date of the certifying run
+status: active        # active | candidate | retired
+---
+```
+
+The body is the prompt itself, verbatim — no narration, no history (the journey lives in changelog entries). A `candidate` has passed its family threshold but not the `judge` gate; `retired` entries stay in place for provenance (consumers must never load them — status is the filter).
+
+## Procedure
+
+- **Create / update**: a content change bumps `version`, resets `status` to `candidate`, and goes through `prompt-eval` → `judge` before flipping back to `active` with fresh `eval-score` and `certified` values. The owning feature doc's `owns:` glob covers the family — read it first.
+- **Retrieve**: match by family + status `active`; the entry's `tier` names the tier it runs on — dispatch accordingly, never stronger (that is an unevidenced promotion).
+- **Audit** (on demand, and by `regression-runner` after a model-generation change): every `active` entry whose `certified` date precedes the current `model-tiers` mapping is stale — re-certify or flag.
+
+## Rules
+
+- **Certification is per tier.** A prompt certified on standard says nothing about economy; a demotion experiment that passes produces a *new* certification at the lower tier.
+- **One prompt, one entry.** Variants under comparison are `candidate` siblings; only one `active` per name.
+- **Never hand-edit `eval-score`** — it is written by the certifying run or not at all.

package/data/harnesses/delivery/skills/route/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: route
+description: Use when starting any piece of prompt work — drafting, evaluating, generating test data, probing, or judging — before dispatching any agent or choosing any tier. The entry point that classifies the task into a task type, reads the routing table, and dispatches the pinned agent. Triggers on /route, "work on this prompt", "run the evals", "which model should this use", or any prompt task whose tier hasn't been routed yet.
+---
+
+# Route — classify, look up, dispatch
+
+The model decision belongs to the routing table in `CLAUDE.md` § The Routing Policy, not to you and not to the user. This skill is the single entry point that applies it.
+
+## Procedure
+
+1. **Classify the task into exactly one task type** from the routing table's rows. Classification is mechanical work — do it inline at the cheapest capable tier, never by dispatching a frontier agent to think about it. When a task spans types (e.g. "draft a prompt and evaluate it"), decompose: each leg routes separately.
+2. **Read the row**: task type → tier → executing agent.
+3. **Dispatch the named agent.** The agent's own pin enforces the tier — never override the model at dispatch time. Work with no matching row is new: route it provisionally to the standard tier, do the work, and record the missing row as an out-of-scope discovery so the table gains it.
+4. **Never route around a failing eval.** If the routed tier's output fails its evals, the answer is the `escalate` skill (evidence-gated promotion), not a quiet re-dispatch on a stronger agent.
+
+## What this skill refuses
+
+- Naming a model. Tiers only; the mapping lives in `.claude/rules/model-tiers.md` and the agents' pins.
+- Frontier dispatch for mechanical work (eval runs, data generation, classification) — the routing guardrails in `CLAUDE.md` prohibit it regardless of who asks.
+- Skipping the table because the task "obviously" needs the strongest model — that intuition is exactly what the escalation ladder exists to test.

package/data/harnesses/etna/harness.json

@@ -1,7 +1,7 @@
 {
   "harness": "etna",
   "name": "etna",
-  "version": "1.3.2",
+  "version": "1.3.3",
   "files": [
     ".prettierignore",
     ".prettierrc.json",

package/data/harnesses/hr/harness.json

@@ -1,7 +1,7 @@
 {
   "harness": "hr",
   "name": "hr",
-  "version": "0.1.12",
+  "version": "0.1.13",
   "files": [
     ".prettierignore",
     ".prettierrc.json",

package/package.json

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