@nurix/etna 0.20.35 → 0.20.37

package/data/harnesses/hr/skills/interview-eval/SKILL.md

@@ -5,53 +5,56 @@ description: "Use when assessing how a human steered a Claude Code session — p
 
 # interview-eval
 
-Judge **how a human drove a Claude Code session** — not how good Claude's output was. The unit of evaluation is the person's steering: how they framed the problem, decomposed it, fed context, verified results, debugged, corrected course, and revealed engineering judgment through their prompts. One or many session transcripts in → per-session reports + scorecards out, plus a candidate-level rollup when there are several.
+Judge **how a human drove a Claude Code session**: how they framed the problem, decomposed it, fed context, verified results, debugged, corrected course, and revealed engineering judgment through their prompts. Session transcripts in; per-session reports and scorecards out, plus a candidate rollup when there are several.
 
-This is the **counterpart** to the sibling `evaluator` skill: `evaluator` scores a _repo's artifacts_; `interview-eval` scores the _conversation that produced them_. They share no rubric.
+The sibling `evaluator` skill scores a repo's artifacts; this skill scores the conversation that produced them. They share no rubric.
 
 ## The one rule that governs every score
 
-**You are scoring the human, not the model.** Claude's code being clean does not earn the candidate points; Claude's code being buggy does not lose them points — _unless_ the human's prompt caused it or the human failed to catch it. Reward the prompt that set Claude up to succeed, the verification that caught Claude's mistake, the redirect that pulled Claude off a bad path. A candidate who wrote three sharp prompts and let a capable agent run is steering _well_, even if the turn count is low. A candidate who typed forty vague nudges and rubber-stamped broken output is steering _badly_, even if something shipped. Turn count, prompt length, and verbosity are **not** quality signals — precision, judgment, and verification are.
+**You are scoring the human, not the model.** Claude's clean code earns the candidate nothing and Claude's buggy code costs them nothing — **unless** the human's prompt caused it or the human failed to catch it. Reward the prompt that set Claude up to succeed, the verification that caught Claude's mistake, the redirect that pulled Claude off a bad path. Turn count, prompt length, and verbosity are **never** quality signals — precision, judgment, and verification are: three sharp prompts that let a capable agent run is good steering; forty vague nudges that rubber-stamp broken output is bad steering, even if something shipped.
 
 ## Input
 
-- **One or more session transcripts** — Claude Code `.jsonl` files (e.g. `0fe33297-….jsonl`). Accept a list of files, a glob, or a directory (evaluate every `*.jsonl` inside).
-- **An output directory** — `out_dir` (default: `./interview-eval-out/`). One subfolder per session, plus a rollup at the root when >1 session.
-- **Optional context** the user may volunteer: the candidate's seniority/role, the task brief they were given, time limits, or whether sessions are independent tasks vs. one continued task. Fold it in; never invent it.
-
-If the user just points at this folder, treat every `*.jsonl` as one candidate's sessions unless told otherwise.
+- **Session transcripts** — Claude Code `.jsonl` files, as a list, a glob, or a directory (every `*.jsonl` inside). A bare directory is one candidate's sessions unless the user says otherwise.
+- **`out_dir`** — default `./interview-eval-out/`. One subfolder per session, plus the rollup at the root when there is more than one session.
+- **Optional context** — the candidate's seniority or role, the task brief, time limits, whether sessions are independent tasks or one continued task. Fold in what the user volunteers; **never** invent it.
 
 ## Process
 
 ### 0. Preflight (cheap)
 
-Only dependency is `python3` (stdlib only). No installs, no network. If `python3` is missing, say so and stop.
+The only dependency is `python3` (stdlib only) — no installs, no network. If `python3` is missing, say so and stop.
 
 ### 1. Extract an evidence pack per session (deterministic)
 
-Run the extractor — it never scores, it only surfaces signal:
+Run the extractor — it surfaces signal and **never** scores:
 
 ```bash
 python3 <skill_dir>/extract_session.py SESSION.jsonl --out <out_dir>/<session-slug>/ --json
 ```
 
-It emits a markdown evidence pack on stdout and writes `<sessionId>.session.json`. The pack gives you:
-
-- **Turn-by-turn**: each human prompt (IDE tags stripped) followed by a summary of what the agent did (tool counts + sample targets). This is your primary evidence — quote `U<n>` turn numbers in every finding.
-- **Metrics**: prompt count, wall-clock & idle gaps, tool histogram, permission-mode transitions, plan-mode / subagent / AskUserQuestion / slash-command usage, interrupts, system/API errors.
-- **Auto red-flag signals**: secrets pasted into prompts, destructive commands the agent ran (`rm -rf ~`, force-push, `DROP TABLE`, …). These are **leads to verify**, not verdicts.
+It prints a markdown evidence pack on stdout and writes `<sessionId>.session.json` into `--out`. The pack holds:
 
-**Read the full evidence pack before scoring.** For long sessions, also open the raw `.jsonl` around any turn you intend to quote, to confirm context. Do not score from metrics alone — a session can have great metrics and terrible steering, or vice-versa.
+| Section | Contents |
+| --- | --- |
+| Turn-by-turn | Each human prompt (IDE tags stripped) as `U<n>` with its timestamp and permission mode, then a summary of what the agent did (tool counts, sample targets). Your primary evidence — cite `U<n>` in every finding |
+| Session metrics | Prompt count and length, wall-clock duration, tool histogram, permission-mode transitions, plan-mode / subagent / `AskUserQuestion` / slash-command usage, interrupts, system/API errors |
+| Auto red-flag signals | Secrets pasted into prompts; destructive commands the agent ran (`rm -rf ~`, force-push, `DROP TABLE`, …). Leads to verify, **never** verdicts |
 
-**Separate noise from signal.** `system_errors` that are `status: 529` / `ECONNRESET` are Anthropic-side overload, not the candidate's fault — never penalize them. `interrupts` may be a sharp early redirect (good) or thrash (bad) — read the surrounding turns to tell which.
+1. Read the **full** evidence pack before scoring. **Never** score from metrics alone — great metrics can hide terrible steering, and the reverse.
+2. For a long session, open the raw `.jsonl` around every turn you intend to quote, to confirm its context.
+3. Separate noise from signal:
+   - `system_errors` with `status: 529` or `ECONNRESET` are Anthropic-side overload — **never** penalize them. Neither are tool-permission prompts or model mistakes the candidate then caught.
+   - An interrupt is either a sharp early redirect (good) or thrash (bad) — read the surrounding turns to tell which.
+   - An idle gap (read from the turn timestamps) may be thinking, out-of-band testing, or absence — note it, never assume.
 
 ### 2. Classify the session type
 
-Pick the dominant type (a session can be a blend — note it): **greenfield-build · feature-add · debugging · refactor · ops/infra · research/Q&A · review/audit**. The type sets which dimensions are _primary_, _secondary_, or _N/A_ — see `rubric.md` → "Session-type matrix". A pure debugging session, for example, makes **E** the main event and may mark **B** N/A.
+Pick the dominant type, noting a blend: `greenfield-build` · `feature-add` · `debugging` · `refactor` · `ops` · `research` · `review`. The type sets which dimensions are primary, secondary, or N/A — `rubric.md` → "Session-type matrix". A pure debugging session makes **E** the main event and may mark **B** N/A.
 
 ### 3. Score the 9 dimensions
 
-Full band anchors (0–5, with concrete "looks like" descriptions and green/red flags) live in **[`rubric.md`](rubric.md)** — read it before every evaluation; do not score from memory. Summary:
+Read **[`rubric.md`](rubric.md)** before every evaluation — the band anchors, flags, and gates live there; **never** score from memory.
 
 | # | Dimension | Weight | The senior question it answers |
 | --- | --- | :-: | --- |
@@ -65,13 +68,13 @@ Full band anchors (0–5, with concrete "looks like" descriptions and green/red
 | **H** | Workflow & Tooling Leverage | 5 | Did they use the harness well (plan mode, subagents, git, slash/skills) and pick the right autonomy? |
 | **I** | Outcome & Efficiency | 5 | Did the session reach a correct, working end state with economy proportional to scope? |
 
-Each dimension gets an integer **0–5 band**, a one-paragraph **rationale**, and **≥2 quoted turn citations** (`U7: "i see the rows but they are empty"`). No citation → no score; write `INSUFFICIENT_EVIDENCE` and exclude from the total. Mark genuinely inapplicable dimensions `N/A` and renormalize over the remaining weight.
+Each dimension gets an integer **0–5 band**, a one-paragraph **rationale**, and **at least 2 quoted turn citations** (`U7: "i see the rows but they are empty"`). No citation, no score: write `INSUFFICIENT_EVIDENCE` and exclude the dimension from the total. Mark a genuinely inapplicable dimension `N/A` and renormalize over the remaining weight.
 
 ### 4. Apply gates (hard caps), then green flags
 
-**Gates** cap the overall band regardless of dimension scores — see `rubric.md` → "Gates". They fire only on _confirmed_ unsafe steering (pasted live secrets, approved a destructive/irreversible op without checking, knowingly shipped broken output). Auto-detected red flags are candidates for a gate — confirm against the transcript before firing one, and record why.
+Gates — `SECRETS-LEAKED`, `DESTRUCTIVE-UNCHECKED`, `BLIND-SHIP`, `PROMPT-INJECTION-NAIVE` — cap the overall level regardless of dimension scores (`rubric.md` → "Gates"). They fire **only** on confirmed unsafe steering: treat each auto-detected red flag as a candidate, confirm it against the transcript, and record why before firing.
 
-**Green flags** are noted as evidence of strength but never push a dimension above its band's ceiling.
+Green flags are evidence of strength and **never** push a dimension above its band's ceiling.
 
 ### 5. Compute totals and level
 
@@ -80,7 +83,7 @@ weighted = Σ(band_d / 5 × weight_d)  over scored dimensions
 normalized = weighted / Σ(weight_d of scored dimensions) × 100
 ```
 
-Map `normalized` to a **steering level** (after gate caps):
+Map `normalized` to a **steering level**, then apply the gate caps:
 
 | Level | Normalized | Reads as |
 | --- | :-: | --- |
@@ -90,30 +93,22 @@ Map `normalized` to a **steering level** (after gate caps):
 | **Developing** | 40–54 | Works, but reactive/under-specified/under-verified; junior steering |
 | **Weak** | 0–39 | Ineffective or unsafe steering |
 
-The level is a **calibration aid, not a verdict** — the human reviewer decides hire/no-hire. Present the level with the evidence that earned it, and call out the 1–2 dimensions that most moved it.
+The level is a **calibration aid, not a verdict** — the human reviewer decides hire or no-hire. Present it with the evidence that earned it, and name the 1–2 dimensions that most moved it.
 
 ### 6. Write outputs (see [`TEMPLATE.md`](TEMPLATE.md))
 
-Per session, write to `<out_dir>/<session-slug>/`:
-
-- **`report.md`** — narrative: summary line, level, per-dimension table with citations, standout moments, weaknesses, gates/flags, and a "what a stronger operator would have done differently" section. Shape = TEMPLATE.md.
-- **`scorecard.yaml`** — machine-readable: per-dimension band + rationale + citations, gates, green flags, totals, level.
-
-When >1 session, also write `<out_dir>/candidate-rollup.md`:
+Fill the shapes in `TEMPLATE.md` exactly:
 
-- Per-session level + headline.
-- Per-dimension trend across sessions (is verification consistently weak? is framing consistently strong?).
-- **Consistency** read — does the candidate steer the same way under pressure (debugging) as when greenfield?
-- A single calibrated **overall steering level** with the 3 strongest and 3 weakest pieces of evidence across all sessions, and concrete interview follow-up questions to probe the gaps.
+- Per session, in `<out_dir>/<session-slug>/`: `report.md` (the narrative) and `scorecard.yaml` (the machine-readable twin).
+- When there is more than one session: `<out_dir>/candidate-rollup.md` — per-session levels, per-dimension trends, a consistency read (does the candidate steer the same way under debugging pressure as on greenfield?), and one calibrated overall level with the strongest and weakest evidence and interview follow-ups.
 
 ## Scoring discipline (read before every run)
 
 - **Evidence or it didn't happen.** Every band cites real turns. "Seems thorough" is not a finding; `U7–U11 debugged the empty-rows bug by pasting the live API response (U9) and isolating restart behavior (U11)` is.
-- **Absolute bands, not curve.** A lone session is scored against the anchors in `rubric.md`, not against other candidates. With multiple sessions you may _report_ relative trends, but each session's band is absolute.
-- **Don't confuse activity with skill.** A 40-turn session is not 40-turns-good. Ask what each turn _accomplished_. Penalize wasted loops; reward turns that each move a verifiable step.
-- **Don't penalize the harness.** API 529s, tool-permission prompts, and model mistakes the candidate then caught are not the candidate's failures. Idle gaps may be the candidate thinking, testing out-of-band, or away — note, don't assume.
-- **Charity with a spine.** Read terse prompts in the best plausible light (typos, brevity ≠ low skill), but do not invent verification or judgment the transcript doesn't show. If you can't see it, it isn't scored there.
-- **Surface the model's contribution honestly.** If Claude proposed the good architecture and the candidate merely said "yes", that is weak **G** with strong-agent luck — say so. If the candidate's prompt _specified_ the operational concern, that is strong **G**.
+- **Absolute bands, not a curve.** Score each session against the anchors in `rubric.md`, never against other candidates. Across several sessions you may _report_ relative trends; each band stays absolute.
+- **Ask what each turn accomplished.** Penalize wasted loops; reward turns that each move a verifiable step.
+- **Charity with a spine.** Read terse prompts in the best plausible light (typos and brevity are not low skill), but **never** credit verification or judgment the transcript doesn't show.
+- **Surface the model's contribution honestly.** Claude proposing the good architecture and the candidate saying "yes" is weak **G** with strong-agent luck — say so. The candidate's prompt _specifying_ the operational concern is strong **G**.
 
 ## What good and weak steering look like (calibration vignettes)
 
@@ -125,6 +120,6 @@ When >1 session, also write `<out_dir>/candidate-rollup.md`:
 
 ## Notes
 
-- The skill is read-only over the transcripts; it only writes into `out_dir`. Never mutate the source `.jsonl`.
-- If a transcript is corrupt/empty or has zero human turns, write a stub report saying so rather than fabricating a score.
-- Keep reports honest and specific enough that the candidate, if shown the report, would recognize the session. That is the bar for evidence quality.
+- **Never mutate the source `.jsonl`** — the skill reads transcripts and writes **only** into `out_dir`.
+- A corrupt or empty transcript, or one with zero human turns, gets a stub report saying so — **never** a fabricated score.
+- The evidence bar: the candidate, shown the report, would recognize the session.

package/data/harnesses/hr/skills/interview-eval/rubric.md

@@ -1,8 +1,6 @@
 # interview-eval rubric — band anchors
 
-Score each dimension **0–5** against the anchors below. Bands are **absolute** (not curved against other candidates). Every band needs ≥2 quoted turn citations. Mark a dimension `N/A` only when the session type makes it genuinely inapplicable (see the matrix at the end), and renormalize over remaining weight.
-
-Read the whole file before scoring. The general meaning of the 0–5 scale:
+Score each dimension **0–5** against the anchors below; § Session-type matrix says which dimensions may be `N/A`. The general meaning of the scale:
 
 | Band | Meaning |
 | :-: | --- |
@@ -13,7 +11,7 @@ Read the whole file before scoring. The general meaning of the 0–5 scale:
 | **1** | Weak. Counterproductive or near-absent. |
 | **0** | None / actively harmful. |
 
-When between two bands, pick the lower unless a green flag justifies the higher. Half-points are not used.
+Between two bands, pick the lower unless a green flag justifies the higher. **Never** use half-points.
 
 ---
 
@@ -70,11 +68,11 @@ _Did the human ground the agent in the real artifacts it needed instead of makin
 
 ## D — Verification & Skepticism (weight 18 — the strongest senior signal)
 
-_Did the human treat the agent's output as a draft to be checked — running it, reading it, probing it — rather than rubber-stamping?_ This is where seniors separate from juniors. Weight it accordingly.
+_Did the human treat the agent's output as a draft to be checked — running it, reading it, probing it — rather than rubber-stamping?_
 
 **Look for:** running the app/tests and reporting results; reading diffs and pushing back on questionable choices; inspecting actual behavior/output; catching subtle or superficial work the agent slipped in; confirming a fix actually fixed it before moving on; not declaring "done" on faith.
 
-> Permission mode is **not** the signal. `acceptEdits` / bypass mode is a legitimate pragmatic choice — judge whether the human _verified behavior_, by any means (running, testing, reading output, inspecting the UI), not whether they clicked approve on each edit.
+> Permission mode is **not** the signal. `acceptEdits` / bypass mode is a legitimate pragmatic choice — judge whether the human _verified behavior_ by any means (running, testing, reading output, inspecting the UI), not whether they approved each edit.
 
 - **5** — Systematic verification throughout: runs the thing, inspects real output, catches agent errors the agent missed, confirms each fix before advancing, and pushes back on shaky choices. Skepticism is the default stance.
 - **4** — Verifies most consequential output and catches real issues; a few steps taken on faith.
@@ -85,7 +83,7 @@ _Did the human treat the agent's output as a draft to be checked — running it,
 
 **Green flags:** "restarting the server still shows old rows" (confirming a fix _didn't_ take); reading the actual response body rather than the diff; spotting that the agent stubbed/faked something. **Red flags:** "looks good" with no evidence; shipping immediately after a failed run; never once running the code in a build session.
 
-**Gate interaction:** if the human is _shown_ the output is broken and ships/commits it anyway, cap **D ≤ 2** and consider the BLIND-SHIP gate.
+**Gate interaction:** the human _shown_ broken output who ships or commits it anyway with no remediation fires `BLIND-SHIP` (§ Gates) — **D ≤ 2** and the overall level ≤ **Competent**.
 
 ---
 
@@ -93,7 +91,7 @@ _Did the human treat the agent's output as a draft to be checked — running it,
 
 _When something broke, did the human drive toward root cause with high-signal diagnostics, or just nudge vaguely?_
 
-**Look for:** precise reproduction; exact error/output pasted; expected-vs-actual framing; stated hypotheses; isolating variables one at a time; converging instead of flailing. (In a pure debugging session this is the main event; in a clean build it may be minor or `N/A`.)
+**Look for:** precise reproduction; exact error/output pasted; expected-vs-actual framing; stated hypotheses; isolating variables one at a time; converging instead of flailing. A pure debugging session makes this the main event; a clean build may make it minor or `N/A`.
 
 - **5** — Drives debugging like an engineer: repro + verbatim evidence + hypothesis, isolates one variable at a time, narrows steadily to root cause, confirms the fix. Tight convergence.
 - **4** — Good diagnostics and mostly systematic; occasional vague nudge but recovers.
@@ -110,7 +108,7 @@ _When something broke, did the human drive toward root cause with high-signal di
 
 _Did the human catch the agent drifting and redirect surgically — and know when to refine vs. undo vs. restart?_
 
-**Look for:** early detection of off-track work; minimal, targeted redirects that preserve good work; tightening constraints constructively ("run 10 at a time, spend 1s per task"); well-timed interrupts; choosing the cheapest correction (refine > undo > restart). Avoid: letting a wrong path run for many turns; chaotic yanking; re-sending an identical failing prompt; nuking good work to fix a small issue.
+**Look for:** early detection of off-track work; minimal, targeted redirects that preserve good work; tightening constraints constructively ("run 10 at a time, spend 1s per task"); well-timed interrupts; choosing the cheapest correction (refine > undo > restart). **Against:** letting a wrong path run for many turns; chaotic yanking; re-sending an identical failing prompt; nuking good work to fix a small issue.
 
 - **5** — Catches drift fast and corrects surgically; tightens scope constructively; interrupts are well-timed; always picks the cheapest effective correction.
 - **4** — Generally redirects well and early; an occasional late catch or slightly heavy-handed correction.
@@ -125,11 +123,11 @@ _Did the human catch the agent drifting and redirect surgically — and know whe
 
 ## G — Technical & Architectural Judgment (weight 15)
 
-_Do the prompts themselves reveal engineering maturity?_ This reads the **content** of the human's instructions for evidence of senior thinking — independent of whether the agent executed well.
+_Do the prompts themselves reveal engineering maturity?_ Read the **content** of the human's instructions, independent of whether the agent executed well.
 
 **Look for:** anticipating operational concerns unprompted (idempotency, reconciliation of stuck state, observability/logging, backpressure, failure/retry, race conditions, data consistency); sound trade-offs; right-sizing to context (descoping auth for a demo; not gold-plating); awareness of the system beyond the happy path; sensible tech choices for the stated constraints.
 
-> Attribute carefully: if _Claude_ proposed the mature design and the human only assented, that is weaker **G** than if the human's prompt _specified_ it. Note who originated the judgment.
+> Note who originated the judgment: _Claude_ proposing the mature design and the human assenting is weaker **G** than the human's prompt _specifying_ it.
 
 - **5** — Prompts repeatedly surface senior-level concerns the agent wouldn't have without being told — operability, failure modes, consistency — and make sound, explicit trade-offs right-sized to the context.
 - **4** — Clear engineering maturity in most prompts; raises real operational concerns; a few missed opportunities.
@@ -144,7 +142,7 @@ _Do the prompts themselves reveal engineering maturity?_ This reads the **conten
 
 ## H — Workflow & Tooling Leverage (weight 5)
 
-_Did the human use the agent and harness well, and pick the right level of autonomy?_ Credit when applicable; **do not penalize** a session that legitimately didn't need advanced features.
+_Did the human use the agent and harness well, and pick the right level of autonomy?_ Credit leverage where it applies; **never** penalize a small, well-handled task for not using advanced features — score it around 3.
 
 **Look for:** plan mode for genuinely ambiguous/large work; subagents for parallel or large-scope fan-out; slash commands / skills; sane git hygiene (branch, review, meaningful commits); MCP/CI where useful; matching autonomy to risk (high autonomy on safe mechanical work, tighter control on risky/irreversible work); economy of interaction.
 
@@ -155,13 +153,13 @@ _Did the human use the agent and harness well, and pick the right level of auton
 - **1** — Fights the tool; ignores obvious leverage; risky autonomy with no guardrails.
 - **0** — Tooling actively works against the goal.
 
-**Green flags:** plan mode before a big ambiguous build; subagents for an audit sweep; a clean commit/push flow with a written README. **Red flags:** bypass-all-permissions on destructive ops; no version control on substantial work. _(Absence of advanced features in a small, well-handled task is fine — score around 3, not down.)_
+**Green flags:** plan mode before a big ambiguous build; subagents for an audit sweep; a clean commit/push flow with a written README. **Red flags:** bypass-all-permissions on destructive ops; no version control on substantial work.
 
 ---
 
 ## I — Outcome & Efficiency (weight 5)
 
-_Did the session reach a correct, working end state, with economy proportional to scope?_ A capstone — partly downstream of the other dimensions, so weighted light to avoid double-counting.
+_Did the session reach a correct, working end state, with economy proportional to scope?_ A capstone, partly downstream of the other dimensions.
 
 **Look for:** a working, correct result the human verified; effort (turns/time/tokens) proportional to the scope; little wasted looping; a clean stopping point (committed/pushed/documented).
 
@@ -172,13 +170,13 @@ _Did the session reach a correct, working end state, with economy proportional t
 - **1** — Little working outcome; heavy waste.
 - **0** — No working outcome.
 
-**Note:** scope-adjust. Achieving a small task crisply is a 5; half-finishing a huge one with good reason may still be a 3–4. Don't reward raw volume.
+**Scope-adjust:** a small task achieved crisply is a 5; a huge one half-finished with good reason may still be a 3–4. **Never** reward raw volume.
 
 ---
 
 ## Gates (hard caps on the overall level)
 
-Gates fire only on **confirmed** behavior in the transcript (use auto red-flags as leads, then verify). When a gate fires, cap the overall level as stated, record the gate, and quote the turn. Multiple gates stack downward.
+Gates fire **only** on behavior confirmed in the transcript — auto red flags are leads. When a gate fires, apply its cap, record the gate, and quote the turn. Multiple gates stack downward.
 
 | Gate | Fires when | Cap |
 | --- | --- | --- |
@@ -187,7 +185,7 @@ Gates fire only on **confirmed** behavior in the transcript (use auto red-flags
 | **BLIND-SHIP** | The human is _shown_ output is broken (failed run, wrong result) and ships/commits/declares-done anyway, with no remediation. | **D ≤ 2** and overall ≤ **Competent** |
 | **PROMPT-INJECTION-NAIVE** | The human pipes untrusted external content into the agent as instructions and acts on it without scrutiny in a context where that's dangerous. | ≤ **Competent** |
 
-A gate is about _unsafe steering_, not mere mistakes. A bug the candidate then caught is **not** a gate — it's evidence _for_ dimension D. Distinguish "the harness/model did X" from "the human directed X": gates require human direction or human ratification.
+A gate is about _unsafe steering_, not mere mistakes: a bug the candidate then caught is **not** a gate — it is evidence _for_ D. Gates **must** have human direction or human ratification behind them; "the harness or model did X" never fires one.
 
 ---
 
@@ -204,16 +202,16 @@ A gate is about _unsafe steering_, not mere mistakes. A bug the candidate then c
 
 ## Session-type matrix — which dimensions are primary / secondary / N-A
 
-Classify the dominant type; blends are common — note them. "Primary" = weigh heavily and expect strong evidence; "Secondary" = score if present; "N/A" = exclude and renormalize unless the session actually exercises it.
+Classify the dominant type and note a blend. **Primary** = central to the read; expect strong evidence (the weights stay fixed). **Secondary** = score if present. **Often N/A** = exclude and renormalize, unless the session actually exercises it. The bold type is the `session_type` token in `scorecard.yaml`.
 
 | Type | Primary | Secondary | Often N/A |
 | --- | --- | --- | --- |
 | **greenfield-build** | A, B, G, D | C, F, I | — |
 | **feature-add** | A, D, G | B, C, F, I | — |
 | **debugging** | E, D, C | F, G | B (little to decompose) |
-| **refactor / cleanup** | D, G, B | C, F, I | E |
-| **ops / infra** | A, D, G, H | C, F, I | B, E |
-| **research / Q&A** | A, C, F | G, I | B, D (no code to verify), E, H |
-| **review / audit** | C, G, D, H | A, F | B, E, I |
+| **refactor** (cleanup) | D, G, B | C, F, I | E |
+| **ops** (infra) | A, D, G, H | C, F, I | B, E |
+| **research** (Q&A) | A, C, F | G, I | B, D (no code to verify), E, H |
+| **review** (audit) | C, G, D, H | A, F | B, E, I |
 
-If the user states a different intent (e.g. "this was a time-boxed take-home"), let that adjust expectations (efficiency matters more, polish less) but not the band anchors themselves.
+A user-stated intent ("this was a time-boxed take-home") adjusts expectations — efficiency up, polish down — and **never** the band anchors.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nurix/etna",
-  "version": "0.20.35",
+  "version": "0.20.37",
   "description": "Bootstrap a project with a Nurix harness — writes the committed contract (CLAUDE.md, AGENTS.md, .claude/harness.json, settings.json, the mount hook) and mounts the harness itself, gitignored, from a bundled payload; sessions keep it current from the CDN.",
   "type": "module",
   "bin": {
@@ -46,5 +46,5 @@
     "agent",
     "plugin"
   ],
-  "etnaFingerprint": "1099ec325647"
+  "etnaFingerprint": "899bed2c91e6"
 }