@mmerterden/multi-agent-pipeline 8.6.0

package/pipeline/eval/golden-tasks/01-ios-bugfix-darkmode/task.json

@@ -0,0 +1,12 @@
+{
+  "title": "LoginView dark mode contrast fix",
+  "description": "Dark mode'da primary button text'i zemin rengiyle düşük kontrast veriyor. Tokens switch'i çalışmıyor çünkü LoginView hardcoded Color.white kullanıyor. Design tokens'a geri bağla.",
+  "inputType": "free-text",
+  "expectedStack": "ios",
+  "expectedLanguage": "Swift",
+  "expectedFramework": "SwiftUI",
+  "expectedBlockers": 1,
+  "expectedDeferrals": 0,
+  "baseBranch": "develop",
+  "taskBranch": "bugfix/loginview-dark-mode-contrast"
+}

package/pipeline/eval/golden-tasks/02-android-feature-compose/expected/phase-1-analysis.json

@@ -0,0 +1,29 @@
+{
+  "stack": {
+    "primary": "android",
+    "language": "Kotlin 2.1",
+    "framework": "Jetpack Compose"
+  },
+  "touchedAreas": [
+    {
+      "path": "feature/orders/src/main/java/com/example/orders/OrdersScreen.kt",
+      "why": "PullToRefreshBox UI eklenecek, ViewModel.refresh() tetiklenecek"
+    },
+    {
+      "path": "feature/orders/src/main/java/com/example/orders/OrdersViewModel.kt",
+      "why": "isRefreshing state flow eklenecek — PullToRefreshBox'ın state binding'i için"
+    },
+    {
+      "path": "feature/orders/src/test/java/com/example/orders/OrdersScreenTest.kt",
+      "why": "Pull-to-refresh compose testi eklenecek"
+    }
+  ],
+  "risks": [
+    {
+      "risk": "Material3 PullToRefreshBox henüz beta API — 1.3.x'de signature değişti",
+      "severity": "medium",
+      "mitigation": "Existing libs.versions.toml'de material3 sürümünü teyit et, gerekirse bump et"
+    }
+  ],
+  "summary": "OrdersScreen Compose ekranına Material3 pull-to-refresh eklenir. ViewModel'de zaten refresh() var; UI binding + isRefreshing state + Compose testi yeterli. Material3 API surface'i beta olduğu için version check gerekir, risk orta."
+}

package/pipeline/eval/golden-tasks/02-android-feature-compose/expected/phase-2-plan.json

@@ -0,0 +1,43 @@
+{
+  "approach": "ViewModel state genişletilir (isRefreshing StateFlow), UI PullToRefreshBox'a bağlanır, Compose test yazılır. TDD: önce Compose testi refresh davranışını doğrulamalı (RED), sonra ViewModel + UI bağlanır.",
+  "tasks": [
+    {
+      "id": "T1",
+      "title": "Add failing Compose test for pull-to-refresh trigger",
+      "type": "test",
+      "files": ["feature/orders/src/test/java/com/example/orders/OrdersScreenTest.kt"],
+      "dependsOn": [],
+      "acceptanceCriteria": [
+        "Test performTouchInput { swipeDown() } on OrdersScreen",
+        "Asserts ViewModel.refresh() is called",
+        "Test initially fails because PullToRefreshBox is not wired"
+      ]
+    },
+    {
+      "id": "T2",
+      "title": "Add isRefreshing StateFlow to OrdersViewModel",
+      "type": "code",
+      "files": ["feature/orders/src/main/java/com/example/orders/OrdersViewModel.kt"],
+      "dependsOn": ["T1"],
+      "acceptanceCriteria": [
+        "isRefreshing: StateFlow<Boolean> exposed",
+        "refresh() sets isRefreshing = true, then false on completion"
+      ]
+    },
+    {
+      "id": "T3",
+      "title": "Wire PullToRefreshBox in OrdersScreen",
+      "type": "code",
+      "files": ["feature/orders/src/main/java/com/example/orders/OrdersScreen.kt"],
+      "dependsOn": ["T2"],
+      "acceptanceCriteria": [
+        "PullToRefreshBox wraps the list",
+        "isRefreshing bound from ViewModel state",
+        "onRefresh calls viewModel::refresh",
+        "Compose test from T1 passes"
+      ]
+    }
+  ],
+  "approved": true,
+  "userFeedback": null
+}

package/pipeline/eval/golden-tasks/02-android-feature-compose/expected/phase-4-review.json

@@ -0,0 +1,35 @@
+[
+  {
+    "reviewer": "opus",
+    "findings": [
+      {
+        "severity": "blocking",
+        "file": "feature/orders/src/main/java/com/example/orders/OrdersViewModel.kt",
+        "line": 28,
+        "issue": "refresh() içinde isRefreshing = false finally bloğunda değil — exception fırlatıldığında spinner sonsuza dek takılır",
+        "fix": "Wrap the body in try/finally and set _isRefreshing.value = false in finally"
+      },
+      {
+        "severity": "important",
+        "file": "feature/orders/src/main/java/com/example/orders/OrdersScreen.kt",
+        "line": 0,
+        "issue": "Yeni modifier chain lazılarla LazyColumn semantics test matcher'larını kırabilir — Compose stability endişesi var",
+        "fix": "Measure recomposition count with Compose Compiler Reports before merging"
+      }
+    ],
+    "approved": false
+  },
+  {
+    "reviewer": "sonnet",
+    "findings": [
+      {
+        "severity": "important",
+        "file": "feature/orders/src/main/java/com/example/orders/OrdersScreen.kt",
+        "line": 54,
+        "issue": "PullToRefreshState hoisted yerine composable içinde tutuluyor — configuration change'de state kaybı",
+        "fix": "Use rememberSaveable or hoist the state up to ViewModel"
+      }
+    ],
+    "approved": false
+  }
+]

package/pipeline/eval/golden-tasks/02-android-feature-compose/expected/phase-4-triage.json

@@ -0,0 +1,35 @@
+{
+  "accepted": [
+    {
+      "severity": "blocking",
+      "file": "feature/orders/src/main/java/com/example/orders/OrdersViewModel.kt",
+      "line": 28,
+      "issue": "refresh() içinde isRefreshing = false finally bloğunda değil — exception fırlatıldığında spinner sonsuza dek takılır",
+      "fix": "Wrap the body in try/finally and set _isRefreshing.value = false in finally",
+      "reviewer": "opus"
+    },
+    {
+      "severity": "important",
+      "file": "feature/orders/src/main/java/com/example/orders/OrdersScreen.kt",
+      "line": 54,
+      "issue": "PullToRefreshState hoisted yerine composable içinde tutuluyor — configuration change'de state kaybı",
+      "fix": "Use rememberSaveable or hoist the state up to ViewModel",
+      "reviewer": "sonnet"
+    }
+  ],
+  "deferred": [
+    {
+      "finding": {
+        "severity": "important",
+        "file": "feature/orders/src/main/java/com/example/orders/OrdersScreen.kt",
+        "line": 0,
+        "issue": "Yeni modifier chain lazılarla LazyColumn semantics test matcher'larını kırabilir — Compose stability endişesi var",
+        "fix": "Measure recomposition count with Compose Compiler Reports before merging",
+        "reviewer": "opus"
+      },
+      "reason": "Out of scope for this task — recomposition audit is a performance sweep, not a correctness gate for adding pull-to-refresh"
+    }
+  ],
+  "rejected": [],
+  "approved": false
+}

package/pipeline/eval/golden-tasks/02-android-feature-compose/metadata.json

@@ -0,0 +1,14 @@
+{
+  "focus": "Android/Compose feature path with mixed-verdict triage — one finding deferred out-of-scope, two accepted (one blocker + one important cross-reviewer match).",
+  "exercises": [
+    "Phase 1 stack detection (android / Kotlin 2.1 / Jetpack Compose)",
+    "Phase 2 3-task decomposition with clear dependency chain (T1 test → T2 VM → T3 UI)",
+    "Phase 4 Reviewer-1 + Reviewer-2 surface overlapping concerns at different lines",
+    "Triage deferred bucket works (important but out-of-scope finding parked, not actioned)"
+  ],
+  "regressionsCaught": [
+    "If triage schema removes the 'deferred' bucket, this fixture fails",
+    "If reviewer enum drops a required reviewer, accepted[] loses its reviewer attribution and schema fails",
+    "If planning schema drops 'dependsOn', T1→T2→T3 ordering becomes unverifiable"
+  ]
+}

package/pipeline/eval/golden-tasks/02-android-feature-compose/task.json

@@ -0,0 +1,12 @@
+{
+  "title": "Add pull-to-refresh on OrdersScreen",
+  "description": "Compose OrdersScreen'de swipe-to-refresh yok. Material3 PullToRefreshBox eklenmeli, ViewModel refresh() zaten var — UI tarafı bağlanmadı.",
+  "inputType": "free-text",
+  "expectedStack": "android",
+  "expectedLanguage": "Kotlin",
+  "expectedFramework": "Jetpack Compose",
+  "expectedBlockers": 1,
+  "expectedDeferrals": 1,
+  "baseBranch": "develop",
+  "taskBranch": "feature/orders-pull-to-refresh"
+}

package/pipeline/eval/golden-tasks/README.md

@@ -0,0 +1,65 @@
+# Golden tasks — regression fixtures for the full pipeline (v6.2.F+)
+
+## Purpose
+
+Each subdirectory here captures one **complete pipeline run as a reference trace**. A golden task fixture answers: *"If the pipeline ran on this input, what shape of outputs should Phase 1–4 produce?"*
+
+The runner (`pipeline/scripts/eval-golden-tasks.mjs`) does **not** invoke a real model — that would require API keys, add non-determinism, and make CI flaky. Instead it validates each fixture against the pipeline's schemas and checks internal consistency (Phase 2 todos reference Phase 1 files, Phase 4 findings reference files that exist in the diff, etc.).
+
+This is a **contract regression test**, same category as `eval-triage.mjs`. A live-model evaluation harness is a separate (and expensive) artifact, deferred to a future release.
+
+## Fixture shape
+
+```
+NN-short-kebab-name/
+  task.json            — input (task description, expected stack, target repo metadata)
+  expected/
+    phase-1-analysis.json    — must conform to analysis-output.schema.json
+    phase-2-plan.json        — must conform to planning-output.schema.json
+    phase-4-review.json      — must conform to reviewer-output.schema.json (one entry per reviewer)
+    phase-4-triage.json      — must conform to triage-output.schema.json
+  metadata.json        — fixture-level notes (why this task is interesting, which phase it exercises most)
+```
+
+`expected/` files are hand-curated reference outputs. They are not literal outputs of a past run — they are what a correct pipeline **should** produce on this input. When the spec changes (e.g. a new field added to analysis-output.schema.json), fixtures are updated to match.
+
+## When to add a new fixture
+
+Add one when you discover a class of task that the pipeline should handle but no existing fixture covers. Examples:
+- A different primary stack (add Python / Node.js / Go fixtures once the runner supports them)
+- A task shape that historically caused regressions (e.g. multi-repo, figma-only, compliance-heavy)
+- An edge case in Phase 4 (e.g. a task where all reviewers approve but triage downgrades)
+
+Do **not** add fixtures just to inflate the count. The runner walks every fixture on `npm test` — each one adds seconds to CI. Quality > quantity.
+
+## Running
+
+```bash
+node pipeline/scripts/eval-golden-tasks.mjs                # all fixtures
+node pipeline/scripts/eval-golden-tasks.mjs --case 01-...  # one fixture
+node pipeline/scripts/eval-golden-tasks.mjs --json         # CI-friendly output
+```
+
+Exit codes: `0` all pass · `1` one or more fail · `2` usage / setup error.
+
+## What the runner asserts (v6.2.F scaffolding)
+
+1. **Schema conformance**: each `expected/phase-*.json` validates against its paired schema via the existing `validate-*.mjs` scripts.
+2. **Internal consistency**: Phase 2 `todos[].touchedFiles[]` is a subset of Phase 1 `touchedAreas[].path`. Phase 4 `findings[].file` is a subset of Phase 2 planned files OR the current diff's files.
+3. **Stack match**: `phase-1-analysis.json.stack.primary` equals `task.json.expectedStack`.
+4. **No invention**: Phase 4 `findings[]` either (a) match Phase 2 planned files, or (b) surface via the `triage.rejected[]` bucket with a reason.
+
+## What the runner does NOT do (yet)
+
+- Invoke a real Claude/Copilot agent. That's a separate multi-model eval, future work.
+- Score output "quality" — no rubric, no judge. Only contract checks.
+- Replay timing / token budgets. Tracker and budget smokes cover that orthogonally.
+
+---
+
+### Seed fixtures shipped with v6.2.F
+
+| # | Name | Focus |
+|---|------|-------|
+| 01 | `01-ios-bugfix-darkmode` | SwiftUI bugfix path — single repo, 2 files touched, 1 blocker finding caught, 0 deferrals |
+| 02 | `02-android-feature-compose` | Kotlin/Compose feature path — 3 files, 1 blocker, 1 deferred out-of-scope finding |

package/pipeline/eval/triage/01-empty-findings/expected.json

@@ -0,0 +1,6 @@
+{
+  "accepted": [],
+  "deferred": [],
+  "rejected": [],
+  "approved": true
+}

package/pipeline/eval/triage/01-empty-findings/input.json

@@ -0,0 +1,5 @@
+{
+  "rawFindings": [],
+  "scope": "Add a Cancel button to the OrderConfirmation screen.",
+  "diffSummary": "1 file changed, 12 insertions, 0 deletions"
+}

package/pipeline/eval/triage/01-empty-findings/notes.md

@@ -0,0 +1,7 @@
+# Case 01 — Empty findings short-circuit
+
+Both reviewers returned zero findings. Triage MUST short-circuit and emit `{approved: true}` directly, no agent call.
+
+Guards against: a future change that incorrectly invokes the triage agent on empty input (wasted Opus call + nondeterministic empty-result variation).
+
+Validator exit code: 0 (clean).

package/pipeline/eval/triage/02-real-blocker/expected.json

@@ -0,0 +1,15 @@
+{
+  "accepted": [
+    {
+      "severity": "blocking",
+      "file": "src/api/auth.ts",
+      "line": 87,
+      "issue": "Password comparison uses string equality, vulnerable to timing attacks",
+      "fix": "Use a constant-time comparison (crypto.timingSafeEqual)",
+      "reviewer": "opus"
+    }
+  ],
+  "deferred": [],
+  "rejected": [],
+  "approved": false
+}

package/pipeline/eval/triage/02-real-blocker/input.json

@@ -0,0 +1,14 @@
+{
+  "rawFindings": [
+    {
+      "severity": "blocking",
+      "file": "src/api/auth.ts",
+      "line": 87,
+      "issue": "Password comparison uses string equality, vulnerable to timing attacks",
+      "fix": "Use a constant-time comparison (crypto.timingSafeEqual)",
+      "reviewer": "opus"
+    }
+  ],
+  "scope": "Implement password-based login endpoint POST /api/auth/login.",
+  "diffSummary": "src/api/auth.ts: +43 -2"
+}

package/pipeline/eval/triage/02-real-blocker/notes.md

@@ -0,0 +1,7 @@
+# Case 02 — In-scope blocker accepted
+
+A real security issue (timing-attack-vulnerable password comparison) lands in the auth module being modified. Triage MUST accept it as blocking; `approved: false` so Phase 5/6 are gated.
+
+Guards against: triage incorrectly deferring or rejecting a clearly in-scope security blocker because the reviewer's `severity` looked over-strict.
+
+Validator exit code: 0 (clean — accepted + approved:false is consistent because there IS a blocker).

package/pipeline/eval/triage/03-out-of-scope-defer/expected.json

@@ -0,0 +1,18 @@
+{
+  "accepted": [],
+  "deferred": [
+    {
+      "finding": {
+        "severity": "important",
+        "file": "src/api/payments.ts",
+        "line": 220,
+        "issue": "Refund flow doesn't log the user-id of the actor, breaking audit trail",
+        "fix": "Add userId to the refund-log entry",
+        "reviewer": "sonnet"
+      },
+      "reason": "out of scope: task is OrderConfirmation Cancel button; payments module is explicitly out of scope per Phase 2 plan. Real issue, surfaced in Phase 7 follow-ups."
+    }
+  ],
+  "rejected": [],
+  "approved": true
+}

package/pipeline/eval/triage/03-out-of-scope-defer/input.json

@@ -0,0 +1,14 @@
+{
+  "rawFindings": [
+    {
+      "severity": "important",
+      "file": "src/api/payments.ts",
+      "line": 220,
+      "issue": "Refund flow doesn't log the user-id of the actor, breaking audit trail",
+      "fix": "Add userId to the refund-log entry",
+      "reviewer": "sonnet"
+    }
+  ],
+  "scope": "Add a Cancel button to the OrderConfirmation screen. Touches src/screens/OrderConfirmation.tsx only. Payments module is out of scope.",
+  "diffSummary": "src/screens/OrderConfirmation.tsx: +12 -0"
+}

package/pipeline/eval/triage/03-out-of-scope-defer/notes.md

@@ -0,0 +1,10 @@
+# Case 03 — Real issue, out of scope → defer
+
+A reviewer correctly flagged a real audit-logging gap, but it's in a module the current task doesn't touch. Triage MUST defer (NOT accept, NOT reject) so it surfaces in Phase 7 follow-ups without blocking this task.
+
+Guards against:
+
+- triage accepting it and dragging unrelated work into Phase 3 rework
+- triage rejecting it and silently losing a real issue
+
+`approved: true` because no accepted blocker remains.

package/pipeline/eval/triage/04-false-positive-reject/expected.json

@@ -0,0 +1,18 @@
+{
+  "accepted": [],
+  "deferred": [],
+  "rejected": [
+    {
+      "finding": {
+        "severity": "blocking",
+        "file": "src/utils/parseDate.ts",
+        "line": 14,
+        "issue": "Function may receive null input causing TypeError",
+        "fix": "Add a null check at the top of parseDate",
+        "reviewer": "sonnet"
+      },
+      "reason": "false positive: Phase 1 analysis confirmed all callers validate non-null before calling parseDate. Adding an internal null check would be defensive duplication and obscure intent."
+    }
+  ],
+  "approved": true
+}

package/pipeline/eval/triage/04-false-positive-reject/input.json

@@ -0,0 +1,14 @@
+{
+  "rawFindings": [
+    {
+      "severity": "blocking",
+      "file": "src/utils/parseDate.ts",
+      "line": 14,
+      "issue": "Function may receive null input causing TypeError",
+      "fix": "Add a null check at the top of parseDate",
+      "reviewer": "sonnet"
+    }
+  ],
+  "scope": "Refactor parseDate to support ISO 8601 with timezone. Existing callers already validate non-null at the call sites (verified in Phase 1 analysis).",
+  "diffSummary": "src/utils/parseDate.ts: +18 -6"
+}

package/pipeline/eval/triage/04-false-positive-reject/notes.md

@@ -0,0 +1,10 @@
+# Case 04 — False positive → reject
+
+A reviewer flagged a "blocking" null-safety issue, but Phase 1 analysis already proved all callers validate input. Adding an internal null check would be defensive duplication that hides intent. Triage MUST reject with a clear reason.
+
+Guards against:
+
+- triage blindly accepting any "blocking" tag without scope check (the v2.2.0 evaluation specifically called this out as a risk)
+- triage deferring a non-issue (would clutter Phase 7 follow-ups with noise)
+
+Also exercises the over-rejection guard: 1/1 = 100% rejected, but `total < 5` so the guard does NOT trip (validator exits 0, not 2).

package/pipeline/eval/triage/05-mixed-classification/expected.json

@@ -0,0 +1,43 @@
+{
+  "accepted": [
+    {
+      "severity": "blocking",
+      "file": "src/api/checkout.ts",
+      "line": 102,
+      "issue": "Race condition: order total computed twice without lock, can produce inconsistent invoice",
+      "fix": "Compute total once inside the existing transaction block",
+      "reviewer": "opus"
+    },
+    {
+      "severity": "important",
+      "file": "src/api/checkout.ts",
+      "line": 145,
+      "issue": "Hard-coded currency 'USD' won't work for non-US tenants",
+      "fix": "Read currency from tenant config",
+      "reviewer": "sonnet"
+    },
+    {
+      "severity": "suggestion",
+      "file": "src/api/checkout.ts",
+      "line": 200,
+      "issue": "Magic number 60 in retry backoff",
+      "fix": "Extract to RETRY_BACKOFF_SECONDS constant",
+      "reviewer": "sonnet"
+    }
+  ],
+  "deferred": [
+    {
+      "finding": {
+        "severity": "important",
+        "file": "src/notifications/email.ts",
+        "line": 33,
+        "issue": "Email template missing for refund-success path",
+        "fix": "Add refund_success.html and wire it up",
+        "reviewer": "sonnet"
+      },
+      "reason": "out of scope: notifications module is owned by another team per Phase 0 scope. Real issue, surfaced in Phase 7 follow-ups."
+    }
+  ],
+  "rejected": [],
+  "approved": false
+}

package/pipeline/eval/triage/05-mixed-classification/input.json

@@ -0,0 +1,38 @@
+{
+  "rawFindings": [
+    {
+      "severity": "blocking",
+      "file": "src/api/checkout.ts",
+      "line": 102,
+      "issue": "Race condition: order total computed twice without lock, can produce inconsistent invoice",
+      "fix": "Compute total once inside the existing transaction block",
+      "reviewer": "opus"
+    },
+    {
+      "severity": "important",
+      "file": "src/api/checkout.ts",
+      "line": 145,
+      "issue": "Hard-coded currency 'USD' won't work for non-US tenants",
+      "fix": "Read currency from tenant config",
+      "reviewer": "sonnet"
+    },
+    {
+      "severity": "important",
+      "file": "src/notifications/email.ts",
+      "line": 33,
+      "issue": "Email template missing for refund-success path",
+      "fix": "Add refund_success.html and wire it up",
+      "reviewer": "sonnet"
+    },
+    {
+      "severity": "suggestion",
+      "file": "src/api/checkout.ts",
+      "line": 200,
+      "issue": "Magic number 60 in retry backoff",
+      "fix": "Extract to RETRY_BACKOFF_SECONDS constant",
+      "reviewer": "sonnet"
+    }
+  ],
+  "scope": "Add tenant-aware checkout flow. Touches src/api/checkout.ts and tenant config. Notifications module is owned by another team.",
+  "diffSummary": "src/api/checkout.ts: +180 -45, src/config/tenants.ts: +12 -0"
+}

package/pipeline/eval/triage/05-mixed-classification/notes.md

@@ -0,0 +1,17 @@
+# Case 05 — Mixed classification (the realistic case)
+
+4 raw findings spanning all 3 outcomes:
+
+- 1 blocking + 1 important + 1 suggestion in the in-scope checkout module → **accepted**
+- 1 important in the out-of-scope notifications module → **deferred**
+- 0 rejected (no false positives in this fixture)
+
+`approved: false` because there's an accepted blocker.
+
+Guards against:
+
+- triage forgetting to classify some findings (every raw finding must end up in exactly one bucket)
+- triage merging suggestions into deferred (suggestions in scope still go to accepted, just at lower priority)
+- triage hallucinating new findings not in raw input (validator strips these — case has 4 in, 4 out across all buckets)
+
+This is the case most likely to catch a regression in the triage prompt structure.

package/pipeline/eval/triage/06-severity-mismatch/expected.json

@@ -0,0 +1,15 @@
+{
+  "accepted": [
+    {
+      "severity": "blocking",
+      "file": "src/api/auth.ts",
+      "line": 120,
+      "issue": "Fallback to admin role when token validation fails",
+      "fix": "Return 401 instead of falling back to admin role",
+      "reviewer": "sonnet"
+    }
+  ],
+  "deferred": [],
+  "rejected": [],
+  "approved": false
+}

package/pipeline/eval/triage/06-severity-mismatch/input.json

@@ -0,0 +1,14 @@
+{
+  "rawFindings": [
+    {
+      "severity": "suggestion",
+      "file": "src/api/auth.ts",
+      "line": 120,
+      "issue": "Fallback to admin role when token validation fails",
+      "fix": "Return 401 instead of falling back to admin role",
+      "reviewer": "sonnet"
+    }
+  ],
+  "scope": "Add JWT token validation to the auth middleware.",
+  "diffSummary": "src/api/auth.ts: +28 -3"
+}

package/pipeline/eval/triage/06-severity-mismatch/notes.md

@@ -0,0 +1,9 @@
+# Case 06 — Severity mismatch (suggestion → blocking)
+
+Reviewer tagged a real security issue as `severity: "suggestion"` — falling back to the admin role when token validation fails is a privilege-escalation vector, not a cosmetic nit.
+
+Triage MUST recognize the actual severity from the issue description and bump it to `blocking`. `approved: false` because the accepted finding is now blocking.
+
+Guards against: blind trust of reviewer severity tags. The triage agent must evaluate the described behavior, not just echo the label.
+
+Validator exit code: 0 (accepted + approved:false is consistent because there IS a blocker).

package/pipeline/eval/triage/07-duplicate-reviewers/expected.json

@@ -0,0 +1,27 @@
+{
+  "accepted": [
+    {
+      "severity": "blocking",
+      "file": "src/checkout.ts",
+      "line": 88,
+      "issue": "Missing transaction wrapper around multi-table writes in checkout",
+      "fix": "Wrap the checkout persistence logic in a database transaction",
+      "reviewer": "opus"
+    }
+  ],
+  "deferred": [],
+  "rejected": [
+    {
+      "finding": {
+        "severity": "blocking",
+        "file": "src/checkout.ts",
+        "line": 88,
+        "issue": "Checkout writes to orders and inventory tables without a transaction boundary",
+        "fix": "Use a single transaction for all database writes in the checkout flow",
+        "reviewer": "sonnet"
+      },
+      "reason": "duplicate of accepted[0]: same file, same line, same root issue (missing transaction wrapper). Opus version retained by convention."
+    }
+  ],
+  "approved": false
+}

package/pipeline/eval/triage/07-duplicate-reviewers/input.json

@@ -0,0 +1,22 @@
+{
+  "rawFindings": [
+    {
+      "severity": "blocking",
+      "file": "src/checkout.ts",
+      "line": 88,
+      "issue": "Missing transaction wrapper around multi-table writes in checkout",
+      "fix": "Wrap the checkout persistence logic in a database transaction",
+      "reviewer": "opus"
+    },
+    {
+      "severity": "blocking",
+      "file": "src/checkout.ts",
+      "line": 88,
+      "issue": "Checkout writes to orders and inventory tables without a transaction boundary",
+      "fix": "Use a single transaction for all database writes in the checkout flow",
+      "reviewer": "sonnet"
+    }
+  ],
+  "scope": "Implement checkout flow with order creation and inventory update.",
+  "diffSummary": "src/checkout.ts: +95 -10"
+}

package/pipeline/eval/triage/07-duplicate-reviewers/notes.md

@@ -0,0 +1,9 @@
+# Case 07 — Duplicate findings from two reviewers
+
+Both Opus and Sonnet flagged the same issue (same file, same line, same root cause) but with slightly different wording. Triage must deduplicate, not double-count.
+
+Convention: when two reviewers agree, keep the Opus finding in `accepted` and move the Sonnet duplicate to `rejected` with a reason linking it to the accepted entry.
+
+Guards against: double-classification when reviewers agree. Without dedup, the developer would see the same fix twice and the finding count would overstate the real issue count.
+
+Validator exit code: 0 (1/2 rejected is under the 80% over-rejection threshold).

package/pipeline/eval/triage/08-style-misclassified/expected.json

@@ -0,0 +1,18 @@
+{
+  "accepted": [],
+  "deferred": [],
+  "rejected": [
+    {
+      "finding": {
+        "severity": "blocking",
+        "file": "src/utils/format.ts",
+        "line": 14,
+        "issue": "Function name `fmt` is too short, should be `formatCurrency`",
+        "fix": "Rename fmt to formatCurrency for readability",
+        "reviewer": "sonnet"
+      },
+      "reason": "stylistic preference, not a correctness issue. Reviewer over-tagged severity. Naming was reviewed in PR #234 and approved by team."
+    }
+  ],
+  "approved": true
+}