@mutagent/evaluator 0.1.0-alpha.5 → 0.2.0-alpha.1

package/.claude/skills/mutagent-evaluator/golden/judge-trajectory.prose.md

@@ -0,0 +1,69 @@
+# golden/judge-trajectory.prose.md — the C-PIN prose surface (VERSIONED anchor)
+
+> The #mode-judge-trajectory judge constructs its prompt AT REASON-TIME from the
+> packet + this mode's prose — so THIS prose is the load-bearing C-PIN surface.
+> Any change to the workflow below is a judge-behavior change and MUST bump the
+> version here (the W-gate byte-identity proof anchors against this snapshot).
+
+## v3.1 — 2026-07-24 · REF-CONTRACT HARDENING (the first-real-run verify-surface flip)
+
+Change vs v3.0 (ONE workflow line — GATHER): the ref contract is made explicit
+after the first real run showed judge-cited packet-shaped refs reading as DEAD
+at deterministic re-verify (both verifier-UPHELD HIGH fails silently downgraded
+→ gate flipped fail→incomplete). Now: `ref.obs` = the packet's `trajectoryId`
+(NEVER an observation name — batch-order first-match can locate the wrong
+trajectory), `ref.path` = packet-shaped `trajectory.N`/`transcript.N` OR
+trace-shaped `observations.N` (both re-resolve — the verifier reconstructs the
+packet views via `verifySituationViews`), dot form canonical, brackets
+tolerated (`readPath` normalizes). VERBATIM snapshot of the mode workflow
+follows.
+
+```yaml
+  - evaluate:
+      meta:
+        what: "Score ONE trajectory against the WHOLE eval matrix (was the eval-matrix-judge agent). The DEFAULT/headline judging cell."
+        does: "Reads a MatrixPacket (the whole matrix + one trajectory + transcript + pinned envelope), BUILDS its judging prompt from the packet + the shared write-judge-prompt.md, scores every criterion for that trajectory, writes a per-trajectory MatrixVerdictFile."
+        why:  "Per-TRAJECTORY fan-out (one judge scores the whole matrix for one session) = high throughput across many sessions. EV-048. This is the headline *evaluate path."
+        how:  "Unlike the criterion axis, NO script renders the prompt — the parent's matrix-judge.ts PREPs only a DATA packet (keyed by trajectoryKey); THIS mode constructs the prompt at reason-time. Its prompt-construction prose is therefore the load-bearing C-PIN surface (golden/judge-trajectory.prose.md)."
+      display: "Score one trajectory against the WHOLE eval matrix (headline)"
+      description: |
+        PURPOSE: the DEFAULT headline judging cell — one judge per trajectory scores
+        the entire eval matrix for that session → per-criterion verdicts. Critique-
+        before-verdict, binary, inaction-can-be-success, whole-matrix-per-trajectory.
+
+        USAGE: dispatched by the parent, MASS-PARALLEL (one per trajectory). Reads
+        <trajectory_key>.packet.json (a MatrixPacket — DATA, NOT a rendered prompt);
+        BUILDS the prompt from it + write-judge-prompt.md; writes the MatrixVerdictFile.
+      dispatch: { mode: judge, axis: trajectory }
+      pre_gate.loads:
+        - "references/write-judge-prompt.md"    # SHARED 4-component contract (both judge axes; now BIND-before-judge)
+        - "references/grounded-adjudication.md"  # GA doctrine: bind · gather refs · typed assumptions · abstain · verify
+        - "references/workflows/orchestrator-protocol.md"  # Step 2 dispatch FSM
+      workflow:
+        - "Pre-read references/write-judge-prompt.md (the 4-component judging contract — your lens) + references/grounded-adjudication.md"
+        - "Read your assigned <trajectory_key>.packet.json (MatrixPacket: subject · trajectoryId · WHOLE matrix · trajectory · transcript · pinned envelope) — judge exactly this, never re-derive the data"
+        - "Frame the trajectory in its ROUTE/intended-outcome (CONTEXT) before scoring"
+        - "v3 LAYERED WALK (D1=B+, operator-frozen): the walk IS a fixed layer sequence you run INSIDE this one dispatch. Honor `packet.layerScope` when present (absent/empty = FULL walk). The phases: (L0 code checks) if the code-eval library is present at scripts/code-eval-library.ts, RUN it yourself via Bash over the packet's trajectory JSON and record each hit as codeEvalHits[{pattern,anchor,detail}] — a fired pattern is evidence, not a verdict; (L1 outcome) classify the SCENARIO from the inbound intent + tool inventory, derive its expectedExit[] terminal actions, glance ONLY at end-state evidence and emit layerVerdicts[{layer:'L1',verdict,scenario,expectedExit,refs,note}]; (STOPPING RULES) if L1 passes AND every criterion is answerable from evidence gathered so far → you may set earlyExit:'L1' and mark L2-L4 as {verdict:'skipped'} — but a criterion may NEVER go unverdicted because the agent did the right thing; if ANY criterion is unanswerable OR L1 fails/undecidable → descend; (L2 trajectory) actual-vs-expected decision path, read from the END, emit layerVerdicts L2 (+ divergence in localize); (L3 tool outputs) per-observation structural validity + completeness — external-data correctness is UNVERIFIABLE (fence), a failed tool makes everything downstream suspect; emit layerVerdicts L3 (+firstProblemOrigin); (L4 context) for each critical operational send: was required context retrieved AND present in history AT THAT TIME (chronology-sorted!) — distinguish gapKind retrieval (never fetched) vs attention (present, ignored); emit layerVerdicts L4. Record layersEngaged. CONFLICT DISCIPLINE (OT-1): when your own layers disagree (e.g. L1 pass vs L2 fail) emit BOTH verdicts honestly with a note — NEVER reconcile them yourself; the aggregate surfaces the conflict for a human."
+        - "Score EVERY criterion in the matrix for THIS trajectory: read only what the row needs (judgeInputs); compare against statement + passCondition — criteria are the SUPER-LAYER: they may bind evidence from ANY walk phase"
+        - "BIND (L1) per row: each criterion TERM must resolve in THIS trajectory; an unbound term ⇒ uncertain + blockedBy:{kind:factual-intent} (INDETERMINATE), ABSTAIN — never fail"
+        - "GATHER: cite a structured ref {obs,path,value} for the claim AND any absence (ref.obs = the packet's trajectoryId, NEVER an observation name; ref.path = packet-shaped trajectory.N/transcript.N OR trace-shaped observations.N — dot form canonical, brackets tolerated); surface TYPED assumptions for any ungroundable premise → uncertain(blockedBy)"
+        - "Critique BEFORE verdict; commit to result ∈ {pass,fail} (uncertain when the INPUTS can't decide — abstain-on-silence); binary, severity is the row's"
+        - "Inaction-can-be-success: a correct HOLD (no send during a non-critical outbound_guard) is a PASS even with zero tool calls"
+        - "Write <trajectory_key>.verdict.json (a MatrixVerdictFile {trajectoryId, judgeModel, temperature:0, verdicts[]} — each verdict may carry refs?/assumptions?/blockedBy?)"
+        - "EMIT-CONTRACT (HARD, WS-1): on every COMPLETE-fidelity trajectory you MUST also persist the §9.4 walk — `understanding` (M2), `expectedTrajectory` (M3), `agentSteps` (the target step lane), and `judgeSteps` (your anchored reasoning). These are NOT optional: the parent runs a machine `assessEmitCompleteness` gate (scripts/emit-completeness.ts) that LOUDLY flags any wholly-dropped field, and a verdict missing them STARVES the report's Trajectory (§2) + Self-Eval (§5) tabs. `agentSteps` is factual trace data (reconstruct it from the ordered tool steps you were given — order by startTime, the observations array is reverse-chronological); M2/M3/judgeSteps are YOUR reasoning. Only an INCOMPLETE (node-1) trajectory is exempt (it emits verdicts:[] and no walk)."
+        - "v3 EMIT-CONTRACT ADDITIONS (E-NEW): alongside the §9.4 walk, persist layerVerdicts[] (one per engaged layer, skipped ones marked), earlyExit?, layersEngaged, codeEvalHits[] (when the library ran), and the emissions SELF-MANIFEST {emitted[], missing[{key,reason}]} — list honestly what you gathered vs what this contract expects; a missing emission with a stated reason is a NAMED degrade, a silent drop is a defect (MR-5 catches it same-run)."
+        - "Verdicts are independently VERIFIED (#mode-verify · ≠ judge · downgrade-only); a CRIT/HIGH uncertain rolls the run up to INCOMPLETE at the gate (no false-green)"
+      compresses:
+        - "read MatrixPacket DATA; frame in ROUTE (CONTEXT)"
+        - "build judging prompt from packet + write-judge-prompt.md"
+        - "BIND terms · GATHER refs + typed assumptions · abstain on silence"
+        - "score whole matrix per trajectory, critique-before-verdict"
+        - "emit MatrixVerdictFile (then independent VERIFY, downgrade-only)"
+      preserves: "the eval-matrix-judge discipline (the headline cell; prompt-construction prose at golden/judge-trajectory.prose.md) — folded INLINE as 'Mode: judge — axis trajectory' (below); the standalone assets/agents/eval-matrix-judge.md was RETIRED in the 5→3 consolidation (Phase 3a, df6a6e8c8). This file is its canonical home."
+```
+
+## history
+
+- v3.1 (2026-07-24): GATHER ref-contract hardening — obs=trajectoryId, packet-OR-trace-shaped paths, dot canonical/brackets tolerated (fixes the verify-surface fail→incomplete flip found on the first real-trace run).
+- v3.0 (2026-07-24): layered walk + v3 emit-contract (evaluator-v3, operator-frozen).
+- v2.2 and earlier: prose lived inline in evaluator.md only; no on-disk snapshot existed (this file materializes the long-referenced golden anchor).

package/.claude/skills/mutagent-evaluator/lenses/methodology-critic-lens.md

@@ -44,7 +44,7 @@ findings:
   - mr: MR-7
     verdict: <fit | mis-fit | inefficient>
     observation: <what the run actually did at this methodology decision>
-    recommendation: <concrete rearrange/improve proposal>
+    recommendation: <concrete rearrange/optimize proposal>
     impactRank: <1=highest>          # ranked self-feedback (MR-5)
     advisory: true                    # NEVER gates the run
 ```

package/.claude/skills/mutagent-evaluator/references/data-registry.md

@@ -0,0 +1,43 @@
+# The data registry — every entity this skill can produce or consume
+
+> The agent's general knowledge of available entities (the resilience mechanism from
+> the data-availability audit §⓪). Purpose: so that when an expected entity is ABSENT,
+> the absence is **NAMED in words** — never a silent blank, never a fabricated value.
+> A renderer that cannot source a field says so ("not recorded by this run"); a judge
+> that cannot gather an emission lists it in its `emissions.missing[]` self-manifest.
+
+## Run artifacts (the `.mutagent/evaluator/runs/<runId>/` dot-root, gitignored)
+
+| entity | produced by | consumed by | absence → |
+|---|---|---|---|
+| `run-input.full.json` | run PREP (`run-evaluate`) | AGGREGATE, the report renderers | a run cannot aggregate — fail loud |
+| `packets/<trajectoryKey>.packet.json` | `prepMatrixPackets` | one dispatched judge each | the readiness gate throws (no silent partial roll-up) |
+| `verdicts/<trajectoryKey>.verdict.json` | a dispatched `#mode-judge-trajectory` agent | AGGREGATE | same — every judged trajectory MUST have one |
+| `verdicts/*.verify.json` | a dispatched `#mode-verify` reviewer | the T3 independent-verify ledger | self-verify fallback (a NAMED degrade, not a silent downgrade) |
+| `near-duplicate-decisions.json` | `aggregateDiscover` | the next run's brief (no re-proposal) | first run — key absent, never an empty claim |
+| `.mutagent/evaluator/reports/<runId>/{evaluation,discovery,review}-report.html` | the renderers | the operator | the run wrote no report — fail loud |
+
+## Judge emissions (the verdict-file fields — E-NEW)
+
+| field | shape | honesty rule |
+|---|---|---|
+| `layerVerdicts[]` | `{layer, verdict, refs?, note?, scenario?, expectedExit?, gapKind?, firstProblemOrigin?, divergence?}` | skipped ≠ undecidable; L0 may be `fired` (a candidate, never a verdict) |
+| `verdicts[]` | per-criterion `{critique, result, confidence, refs?, assumptions?, blockedBy?}` | a DECIDED verdict carries ≥1 re-resolvable ref; an `uncertain` carries `blockedBy` (na for grounding) |
+| `denseMap` | `{criterionId: pass\|fail\|uncertain\|na}` | EVERY criterion appears; `na` ≠ fail |
+| `naRationale` | `{criterionId: why}` | the reason a cell is `na` — the completeness law's third path carries its rationale |
+| `emissions` | `{emitted[], missing[{key,reason}]}` | a missing emission WITH a stated reason is a NAMED degrade; a silent drop is a defect (MR-5 catches it) |
+| `codeEvalHits[]` | `{pattern, anchor, detail}` | L0 fired patterns — evidence, not a verdict |
+| `localize` | `{root, evidence?, criteria?, independentRoots?, conflict?, routing?, …}` | the root-not-symptom; `conflict` is the judge's OT-1 statement — surfaced, never reconciled |
+
+## Subject profile + criteria
+
+| entity | produced by | note |
+|---|---|---|
+| subject profile | `buildSubjectProfile` | identity · purpose · tools · scope — GIVEN (code access) or reconstructed |
+| `criteria[]` (the eval matrix) | the suite / `*discover` | each may carry `layer` (which evidence layer it binds to) — additive, optional, defaults to `"criteria"` |
+| living suite + provenance | `growLivingSuite` | append-only, monotonic; near-duplicates MERGE (no data loss) |
+| pending near-duplicate decisions | `merge-criteria` | durable, order-independent identity; stays open until a ruling |
+
+**The rule that binds every row of this registry:** an absence is stated, never inferred
+into a number. `0` and "not recorded" are different facts, and a report that shows the
+first when it means the second is manufacturing evidence.

package/.claude/skills/mutagent-evaluator/references/edd-loop.md

@@ -1,11 +1,11 @@
-# edd-loop — the ADL ③ IMPROVE / Eval-Driven-Development loop (F18 + F19)
+# edd-loop — the ADL ③ OPTIMIZE / Eval-Driven-Development loop (F18 + F19)
 
-> **Loaded by:** the evaluator `improve` mode (`assets/agents/evaluator.md#mode-improve`). Load on demand.
+> **Loaded by:** the evaluator `optimize` mode (`assets/agents/evaluator.md#mode-optimize`). Load on demand.
 > **Backed by:** `scripts/edd/variance-gate.ts` (F19) · `scripts/edd/change-request.ts` (F18) ·
 > `scripts/edd/edd-types.ts` + `schemas/edd-change-request.schema.yaml` (the contract).
 > **Sibling refs:** `grounded-adjudication.md` (every ask is grounded) · `validate-evaluator.md` (trust the judge first).
 
-The IMPROVE stage closes the **PR-011 spec↔impl↔eval triad**. A judge that only reports is half a
+The OPTIMIZE stage closes the **PR-011 spec↔impl↔eval triad**. A judge that only reports is half a
 loop; EDD drives the subject to **full green** while the evaluator stays **judge-only (EV-051)** — it
 **REQUESTS** the `ai-engineer` to amend the Agent/AgentSpec and **re-evals**, but never
 patches the subject itself.
@@ -100,11 +100,11 @@ controller never reads a clock) → the decision is PURE + deterministic (C-PIN)
 ## Assumed eval-runner interface (the clean seam — REBUILD nothing)
 
 The EVAL engine (dataset build · the eval runner · Path A/B) is built **in parallel** (sibling
-worktree). The `improve` mode is **additive**: it orchestrates the LOOP around the runner and assumes
+worktree). The `optimize` mode is **additive**: it orchestrates the LOOP around the runner and assumes
 this interface — it does not re-implement it.
 
 ```
-// the runner the improve mode CONSUMES (owned by the eval engine, e.g. run-evaluate.ts):
+// the runner the optimize mode CONSUMES (owned by the eval engine, e.g. run-evaluate.ts):
 runOnce(caseIds: string[]) -> Array<{
   caseId: string;
   criterionId: string;
@@ -116,7 +116,7 @@ runOnce(caseIds: string[]) -> Array<{
 - **repeat-N** = `runOnce` called N times over the SAME `caseIds`; the per-rerun verdicts feed
   `CaseVarianceObservation.verdicts[]` (+ `trajectories[]`) → `evaluateVarianceGate`.
 - **accuracy** = `runOnce` over the FULL dataset → per-case verdicts → an accuracy ratio vs target.
-- the runner is **C-PIN** (pinned model + temperature 0). The improve mode adds **no** provider call.
+- the runner is **C-PIN** (pinned model + temperature 0). The optimize mode adds **no** provider call.
 
 If the sibling runner exposes a different shape, adapt at the seam (map its result into
 `CaseVarianceObservation` / the accuracy ratio) — keep the gate + loop modules untouched. The gate

package/.claude/skills/mutagent-evaluator/references/eval-layers.md

@@ -0,0 +1,52 @@
+# The evidence layers (L0–L4) — how the layered judge reads a trajectory
+
+> The know-how reference for the layered walk. Load when you need to reason about
+> **what a layer can and cannot decide**, why the judge descends, and what the
+> stopping rules permit. The judge emits one `LayerVerdict` per engaged layer; this
+> file is the map between a layer id and its meaning. Live consumers: the judge's
+> `layerVerdicts`, the aggregate's `foldLayerVerdicts` / `detectLayerConflicts`, and
+> the report's layer matrix.
+
+## The ladder
+
+The judge walks **cheapest-first, descending only when evidence requires**. Each layer
+answers a narrower question than the one above; a layer's verdict is *evidence*, never
+the run verdict on its own (the GATE is driven by criteria severity — D2).
+
+| layer | name | question it can settle | what it CANNOT decide (the fence) |
+|---|---|---|---|
+| **L0** | code checks | did a deterministic pattern fire? (fault passthrough · error output · malformed structure · unguarded send · out-of-order gate) | a fired pattern is a **candidate**, not a verdict — "code-detectable ≠ incorrect". Emits `codeEvalHits`, verdict `fired` — never pass/fail. |
+| **L1** | outcome | did the agent's terminal action belong to the scenario's expected exit set? (scenario → `expectedExit[]`) | anything about the *path*: a correct outcome can hide an unguarded send, a skipped review, an ignored flag. |
+| **L2** | trajectory | did the actual decision path match the expected one? (actual-vs-expected, read from the END) | whether a *tool's* output was trustworthy — that is L3. A divergence here is the first sign the outcome misleads. |
+| **L3** | tool outputs | were the tool outputs structurally valid + complete? (per-observation) | **external-data correctness is UNVERIFIABLE** — a well-formed output can be factually wrong. A failed tool makes everything downstream suspect. |
+| **L4** | context | was required context retrieved AND present in history at the moment of the decision? (chronology-sorted) | distinguish **`gapKind: retrieval`** (never fetched) from **`attention`** (present, ignored) — the fixes differ. |
+
+## Criteria are the super-layer
+
+Criteria do not live *in* one layer — they are the **super-layer** and may bind evidence
+from any phase (e.g. a reply-grounding criterion reads L3 tool outputs AND L1 the reply).
+Two hard rules:
+
+- **a criterion may NEVER go unverdicted because the agent did the right thing** — `na`
+  (not-applicable) is a real accounting path with a rationale, never a silent skip
+  (`assertNoUnverdictedCriterion` THROWS on a missing cell).
+- **`na` is not `uncertain`.** `na` = the criterion's scoping predicate is positively
+  falsified for this trajectory (never fail). `uncertain` = the inputs could not decide
+  (a CRIT/HIGH uncertain rolls the run INCOMPLETE-wards, never green).
+
+## The stopping rules (when the walk may exit early)
+
+- If **L1 passes AND every criterion is answerable** from evidence gathered so far → the
+  walk may set `earlyExit: 'L1'` and mark L2–L4 `skipped`. `skipped ≠ undecidable`.
+- If **any** criterion is unanswerable, OR L1 fails / is undecidable → **descend.** A
+  walk must not stop while a criterion is unanswerable (that is how a false-green forms).
+- `layersEngaged` records how deep the walk actually went (the economy stat — MR-3).
+
+## Conflict discipline (OT-1)
+
+When layers disagree — e.g. **L1 pass but L2 fail** (the outcome was right, the path
+unguarded) — the judge emits **both** verdicts honestly with a note and **never
+reconciles them itself**. The aggregate (`detectLayerConflicts`) surfaces the conflict
+to a human calibration queue; the GATE never reads it (it is driven by criteria
+severity). The judge's own statement of the tension lives in `localize.conflict`; the
+aggregate's cross-check is the layer notes. Both render; neither is auto-resolved.

package/.claude/skills/mutagent-evaluator/references/eval-stage.md

@@ -21,7 +21,7 @@ spine (`error-analysis.md` · `write-judge-prompt.md` · `validate-evaluator.md`
 | Input | Shape | Used for |
 |-------|-------|----------|
 | the built agent | a target-framework impl (e.g. a Mastra/TS agent) OR a harness agent | the eval SUBJECT |
-| `agentspec.definition.evals` | `{ success_criteria[], scenarios[], dataset_categories[] }` | dataset materialization (F8) + criteria |
+| `agentspec.spec.evaluation` | `{ criteria[], scenarios[], datasets[] }` (0.3.0, D18/D19 — datasets carry dataset-local `categories[]` + `caseDimensions` + real `items[]`) | dataset materialization (F8) + criteria |
 | `agentspec.build` | `{ target_framework, runtime, target_eval_framework }` | the target-conditional engine fork (F9) |
 
 The skill is **standalone** — it NEVER imports the agentspec schema. It consumes
@@ -38,8 +38,37 @@ After `*build`, OFFER the two derivations (AskUserQuestion, parent session only)
 1. **`*build-dataset`** — materialize + grow the golden dataset from the spec.
 2. **`*build-evals`** — build the eval suite (and pick the engine).
 
+**State what the stage will produce, up front (EVAL-1).** Before running either build,
+EMIT the "what this stage will produce" notice (`renderStageProducesNotice`, `scripts/
+render-build-cards.ts`) naming the deliverables — a **dataset** (golden cases + the sink
+file) and/or the **eval criteria** (the judges/code-checks + their sink) — so the operator
+knows what's coming. Notification only — **no approval gate** (operator constraint): once a
+build is triggered, run it; don't ask for edit-approval, just present clearly.
+
 Let the user run either/both. They are independent; `*evaluate` consumes both.
 
+**Either order — no hard sequence (EVAL-4).** There is NO build-time ordering rule between
+the dataset and the criteria: you may build the **criteria first** and derive a dataset to
+exercise them (when you can define "good" up front), or build a **dataset first** and mine
+criteria from it (when you bring examples of good/bad and fit criteria to them). Start from
+either end. The ONLY directional constraint is a RUN-TIME prerequisite, not a build order:
+`*evaluate` cannot run against no dataset, so it auto-routes to `*build-dataset` first (below).
+Do not mistake that run-time prerequisite for a build-time sequence.
+
+**The three dataset pipelines — kept SEPARATE (EVAL-2).** Do NOT fuse the source paths into
+one step (on a cold start there are no traces to ground against). They stay distinct:
+1. **cold-from-definition** — materialize the dataset from the agentspec (`materialize-dataset.ts`
+   `materializeFromAgentspec`). The only path with no traces.
+2. **from-labeled-traces** — grow the set from already-labeled traces
+   (`derive-dataset.ts` `deriveRegressionCases` / `growRegressionSet`).
+3. **seed-then-ground** — seed from the definition, THEN ground from traces (definition seeds →
+   traces ground). Reuses the shared monotonic merge floor (`build-dataset.ts` — nothing is ever
+   dropped), so the paths can be combined later without losing cases.
+
+**Precedence — scored traces outrank a stale spec (EVAL-2).** When BOTH a spec and traces
+carrying feedback/scores exist for the same case, the **scored traces WIN**: real observed
+outcomes outrank a possibly-stale definition. The spec seeds; the scored traces correct.
+
 **Dataset gate (dogfood H5).** `*evaluate` REQUIRES a materialized dataset. If `*build-evals` runs
 (or `*evaluate` is invoked) with no dataset present, do NOT dead-end — auto-route to `*build-dataset`
 (interactive) first, then resume. Never leave the user with an eval suite and nothing to run it on.
@@ -126,9 +155,13 @@ Stream PROGRESS as wireframe cards for BOTH `*build-dataset` and `*build-evals`
 
 - `renderBuildDatasetProgressCard` / `renderBuildEvalsProgressCard` — phase +
   progress bar + counters, emitted per phase (F13/F16).
-- After each, emit the VERBOSE entity card (F22): `renderDatasetEntityCard`
-  (per-category breakdown · version · sink) · `renderEvalsEntityCard` (engine ·
-  SURFACED CC/log-sink dependency · criteria).
+- **REQUIRED emission (EVAL-1).** After each build, you MUST emit the VERBOSE entity
+  card (F22) — this is not optional: `renderDatasetEntityCard` (per-category breakdown ·
+  version · sink) · `renderEvalsEntityCard` (engine · SURFACED CC/log-sink dependency ·
+  criteria). A build that reports and a build that stays silent must NOT look identical
+  (the dogfood symptom). The renderers WARN loudly (`⚠ EMPTY`) when a build produced no
+  items/criteria, so a silent no-op build can never render as a success. No approval
+  branch — notification only.
 
 ---
 

package/.claude/skills/mutagent-evaluator/references/memory-format.md

@@ -21,7 +21,7 @@ name: <short-kebab-case-slug>
 description: <one-line summary — used to decide relevance during recall>
 metadata:
   type: user | feedback | project | reference    # Claude Code's four types
-  lifecycle: spec|build|evaluate|diagnose|improve|general   # ADL extension
+  lifecycle: spec|build|evaluate|diagnose|optimize|general   # ADL extension
   created: YYYY-MM-DD                             # REQUIRED · every memory is DATED (stale-pruning)
 ---
 

package/.claude/skills/mutagent-evaluator/schemas/methodology-review.schema.yaml

@@ -5,7 +5,7 @@
 # This is the SECOND requirement family: FITNESS, not conformance. It does not
 # pass/fail a component; it interrogates the methodology's own decision-tree,
 # workflow structure, and data-flow, and emits ranked recommendations to
-# rearrange / improve the process. MR-1..9 (Tab-4 lens reads these).
+# rearrange / optimize the process. MR-1..9 (Tab-4 lens reads these).
 # ============================================================================
 $id: mutagent-evaluator/methodology-review
 title: Subject Methodology-Review Rubric