@mmerterden/multi-agent-pipeline 8.6.1 → 10.0.6

package/pipeline/eval/golden-tasks/03-backend-python-ratelimit/expected/phase-4-triage.json

@@ -0,0 +1,15 @@
+{
+  "accepted": [
+    {
+      "severity": "blocking",
+      "file": "app/middleware/rate_limit.py",
+      "line": 38,
+      "issue": "The per-IP window dict is read-modified-written without a lock; under concurrent requests two coroutines can both pass the check and under-count, letting bursts through",
+      "fix": "Guard the read-modify-write with an asyncio.Lock keyed per IP, or use an atomic counter structure",
+      "reviewer": "opus"
+    }
+  ],
+  "deferred": [],
+  "rejected": [],
+  "approved": false
+}

package/pipeline/eval/golden-tasks/03-backend-python-ratelimit/metadata.json

@@ -0,0 +1,14 @@
+{
+  "focus": "Backend (Python/FastAPI) feature path  -  verifies stack detection on a non-mobile repo and that Phase 4 catches a concurrency blocker (unsynchronized shared counter) in newly added middleware.",
+  "exercises": [
+    "Phase 1 stack detection (backend / Python / FastAPI)",
+    "Phase 2 TDD ordering (failing rate-limit test before middleware code)",
+    "Phase 4 Reviewer-1 (opus) catches a race condition on the shared window counter; Reviewer-2 (sonnet) approves the wiring",
+    "Triage keeps the concurrency blocker accepted, no deferrals, not approved"
+  ],
+  "regressionsCaught": [
+    "If stack detection misroutes a FastAPI repo to 'frontend' or 'unknown', the stack-match check fails",
+    "If planning emits files outside Phase 1 touchedAreas, the subset check fails",
+    "If triage stops requiring a reviewer attribution on accepted findings, this fixture fails validate-triage"
+  ]
+}

package/pipeline/eval/golden-tasks/03-backend-python-ratelimit/task.json

@@ -0,0 +1,12 @@
+{
+  "title": "Add per-IP rate limiting to the auth login endpoint",
+  "description": "Brute-force attempts on POST /auth/login are unthrottled. Add per-IP rate limiting (sliding window) as FastAPI middleware and wire it into the auth router. Return 429 with Retry-After when the limit is exceeded.",
+  "inputType": "free-text",
+  "expectedStack": "backend",
+  "expectedLanguage": "Python",
+  "expectedFramework": "FastAPI",
+  "expectedBlockers": 1,
+  "expectedDeferrals": 0,
+  "baseBranch": "main",
+  "taskBranch": "feature/auth-rate-limit"
+}

package/pipeline/eval/golden-tasks/04-frontend-next-hydration/expected/phase-1-analysis.json

@@ -0,0 +1,29 @@
+{
+  "stack": {
+    "primary": "frontend",
+    "language": "TypeScript 5",
+    "framework": "Next.js"
+  },
+  "touchedAreas": [
+    {
+      "path": "components/CartBadge.tsx",
+      "why": "Reads localStorage during render, diverging from the server-rendered 0"
+    },
+    {
+      "path": "hooks/useCart.ts",
+      "why": "Exposes the count; needs an SSR-safe initial value with hydration on mount"
+    },
+    {
+      "path": "components/CartBadge.test.tsx",
+      "why": "Adds a render test asserting no hydration warning and the count appears after mount"
+    }
+  ],
+  "risks": [
+    {
+      "risk": "Other components may also read the same localStorage key during render and reintroduce the mismatch elsewhere",
+      "severity": "low",
+      "mitigation": "Centralize the SSR-safe read in useCart so callers share one hydration-safe source"
+    }
+  ],
+  "summary": "The cart badge reads localStorage during render while the server renders 0, triggering a hydration mismatch and a count flash. Move the read behind an SSR-safe initial value that hydrates on mount, centralized in useCart. Three files; low regression risk if the read stays centralized."
+}

package/pipeline/eval/golden-tasks/04-frontend-next-hydration/expected/phase-2-plan.json

@@ -0,0 +1,40 @@
+{
+  "approach": "TDD-first. Add a render test that mounts the header and asserts there is no hydration warning and that the count is present after mount (RED). Make useCart return an SSR-safe initial value and hydrate from localStorage in an effect; consume it in CartBadge so server and first client paint agree (GREEN). Refactor any direct localStorage reads to go through the hook.",
+  "tasks": [
+    {
+      "id": "T1",
+      "title": "Add failing hydration/render test for CartBadge",
+      "type": "test",
+      "files": ["components/CartBadge.test.tsx"],
+      "dependsOn": [],
+      "acceptanceCriteria": [
+        "Test renders the badge and asserts no React hydration warning is emitted",
+        "After mount/effect flush, the badge shows the persisted count"
+      ]
+    },
+    {
+      "id": "T2",
+      "title": "Make useCart SSR-safe (stable initial value, hydrate on mount)",
+      "type": "code",
+      "files": ["hooks/useCart.ts"],
+      "dependsOn": ["T1"],
+      "acceptanceCriteria": [
+        "Initial server and first client render return the same value",
+        "localStorage is read inside an effect, not during render"
+      ]
+    },
+    {
+      "id": "T3",
+      "title": "Consume the SSR-safe count in CartBadge",
+      "type": "code",
+      "files": ["components/CartBadge.tsx"],
+      "dependsOn": ["T2"],
+      "acceptanceCriteria": [
+        "CartBadge reads the count only from useCart",
+        "No direct localStorage access remains in the component"
+      ]
+    }
+  ],
+  "approved": true,
+  "userFeedback": null
+}

package/pipeline/eval/golden-tasks/04-frontend-next-hydration/expected/phase-4-review.json

@@ -0,0 +1,20 @@
+[
+  {
+    "reviewer": "opus",
+    "findings": [
+      {
+        "severity": "blocking",
+        "file": "components/CartBadge.tsx",
+        "line": 17,
+        "issue": "The mounted-guard returns null until mount but never renders the count afterward on the first client pass, so the badge stays empty when items exist; the guard fixes the warning but breaks the feature",
+        "fix": "Render the hydrated count once mounted instead of returning null permanently; only the initial server-equal value should gate on mount"
+      }
+    ],
+    "approved": false
+  },
+  {
+    "reviewer": "sonnet",
+    "findings": [],
+    "approved": true
+  }
+]

package/pipeline/eval/golden-tasks/04-frontend-next-hydration/expected/phase-4-triage.json

@@ -0,0 +1,15 @@
+{
+  "accepted": [
+    {
+      "severity": "blocking",
+      "file": "components/CartBadge.tsx",
+      "line": 17,
+      "issue": "The mounted-guard returns null until mount but never renders the count afterward on the first client pass, so the badge stays empty when items exist; the guard fixes the warning but breaks the feature",
+      "fix": "Render the hydrated count once mounted instead of returning null permanently; only the initial server-equal value should gate on mount",
+      "reviewer": "opus"
+    }
+  ],
+  "deferred": [],
+  "rejected": [],
+  "approved": false
+}

package/pipeline/eval/golden-tasks/04-frontend-next-hydration/metadata.json

@@ -0,0 +1,14 @@
+{
+  "focus": "Frontend (Next.js/React/TypeScript) bugfix path  -  verifies frontend stack detection and that Phase 4 catches a correctness blocker (a hydration guard that hides the count past first paint).",
+  "exercises": [
+    "Phase 1 stack detection (frontend / TypeScript / Next.js)",
+    "Phase 2 TDD ordering (failing render test before the fix)",
+    "Phase 4 Reviewer-1 (opus) flags that the mounted-guard leaves the badge empty even after mount; Reviewer-2 (sonnet) approves",
+    "Triage keeps the correctness blocker accepted, no deferrals, not approved"
+  ],
+  "regressionsCaught": [
+    "If frontend detection regresses to 'unknown', the stack-match check fails",
+    "If a plan task references a file absent from touchedAreas, the subset check fails",
+    "If reviewer findings stop tracing to a planned file or triage, the traceability check fails"
+  ]
+}

package/pipeline/eval/golden-tasks/04-frontend-next-hydration/task.json

@@ -0,0 +1,12 @@
+{
+  "title": "Fix cart badge hydration mismatch in Next.js header",
+  "description": "The cart item count renders on the server as 0 but the client reads it from localStorage, causing a React hydration mismatch warning and a flash of the wrong count. Make the badge render consistently on first paint.",
+  "inputType": "free-text",
+  "expectedStack": "frontend",
+  "expectedLanguage": "TypeScript",
+  "expectedFramework": "Next.js",
+  "expectedBlockers": 1,
+  "expectedDeferrals": 0,
+  "baseBranch": "main",
+  "taskBranch": "bugfix/cart-badge-hydration"
+}

package/pipeline/eval/golden-tasks/05-ios-security-keychain/expected/phase-1-analysis.json

@@ -0,0 +1,29 @@
+{
+  "stack": {
+    "primary": "ios",
+    "language": "Swift 6",
+    "framework": "SwiftUI"
+  },
+  "touchedAreas": [
+    {
+      "path": "Sources/Auth/TokenStore.swift",
+      "why": "New Keychain-backed store replacing the UserDefaults read/write of the token"
+    },
+    {
+      "path": "Sources/Auth/SessionManager.swift",
+      "why": "Reads and writes the token through TokenStore instead of UserDefaults"
+    },
+    {
+      "path": "Sources/Auth/TokenStoreTests.swift",
+      "why": "Round-trip save/load/delete tests against a Keychain test double"
+    }
+  ],
+  "risks": [
+    {
+      "risk": "Existing users already have a token in UserDefaults; a naive switch logs everyone out on upgrade",
+      "severity": "medium",
+      "mitigation": "Plan a one-time migration that reads the legacy UserDefaults value, writes it to the Keychain, then clears it"
+    }
+  ],
+  "summary": "The auth token lives in UserDefaults (insecure). Introduce a Keychain-backed TokenStore and route SessionManager through it. The main hazard is logging out existing users on upgrade unless a one-time migration moves legacy tokens; that migration is the likely deferral if the security fix lands first."
+}

package/pipeline/eval/golden-tasks/05-ios-security-keychain/expected/phase-2-plan.json

@@ -0,0 +1,42 @@
+{
+  "approach": "TDD-first. Write round-trip tests for a Keychain-backed TokenStore (save, load, delete) against a test double (RED). Implement TokenStore over the Keychain (GREEN). Route SessionManager through TokenStore and remove the UserDefaults access (refactor). Legacy-token migration is scoped as a follow-up if the security fix is prioritized first.",
+  "tasks": [
+    {
+      "id": "T1",
+      "title": "Add failing TokenStore round-trip tests",
+      "type": "test",
+      "files": ["Sources/Auth/TokenStoreTests.swift"],
+      "dependsOn": [],
+      "acceptanceCriteria": [
+        "save then load returns the same token",
+        "delete removes the token and load returns nil",
+        "tests run against a Keychain double, no real Keychain dependency"
+      ]
+    },
+    {
+      "id": "T2",
+      "title": "Implement Keychain-backed TokenStore",
+      "type": "code",
+      "files": ["Sources/Auth/TokenStore.swift"],
+      "dependsOn": ["T1"],
+      "acceptanceCriteria": [
+        "Uses kSecClassGenericPassword with an app-specific service",
+        "No token value is ever passed to a logger",
+        "Returns typed errors, not optional-swallowing"
+      ]
+    },
+    {
+      "id": "T3",
+      "title": "Route SessionManager through TokenStore",
+      "type": "code",
+      "files": ["Sources/Auth/SessionManager.swift"],
+      "dependsOn": ["T2"],
+      "acceptanceCriteria": [
+        "All token reads/writes go through TokenStore",
+        "No UserDefaults access for the token remains"
+      ]
+    }
+  ],
+  "approved": true,
+  "userFeedback": null
+}

package/pipeline/eval/golden-tasks/05-ios-security-keychain/expected/phase-4-review.json

@@ -0,0 +1,28 @@
+[
+  {
+    "reviewer": "opus",
+    "findings": [
+      {
+        "severity": "blocking",
+        "file": "Sources/Auth/SessionManager.swift",
+        "line": 54,
+        "issue": "os_log(\"restored session token=\\(token)\") logs the raw token in plaintext; moving storage to the Keychain is undone if the value still leaks to the device log",
+        "fix": "Remove the token from the log statement, or log a redacted fingerprint only"
+      }
+    ],
+    "approved": false
+  },
+  {
+    "reviewer": "sonnet",
+    "findings": [
+      {
+        "severity": "important",
+        "file": "Sources/Auth/SessionManager.swift",
+        "line": 70,
+        "issue": "Existing users with a token in UserDefaults are not migrated, so this change logs them all out on first launch after upgrade",
+        "fix": "Add a one-time migration: read the legacy UserDefaults token, write it to TokenStore, then clear UserDefaults"
+      }
+    ],
+    "approved": false
+  }
+]

package/pipeline/eval/golden-tasks/05-ios-security-keychain/expected/phase-4-triage.json

@@ -0,0 +1,27 @@
+{
+  "accepted": [
+    {
+      "severity": "blocking",
+      "file": "Sources/Auth/SessionManager.swift",
+      "line": 54,
+      "issue": "os_log(\"restored session token=\\(token)\") logs the raw token in plaintext; moving storage to the Keychain is undone if the value still leaks to the device log",
+      "fix": "Remove the token from the log statement, or log a redacted fingerprint only",
+      "reviewer": "opus"
+    }
+  ],
+  "deferred": [
+    {
+      "finding": {
+        "severity": "important",
+        "file": "Sources/Auth/SessionManager.swift",
+        "line": 70,
+        "issue": "Existing users with a token in UserDefaults are not migrated, so this change logs them all out on first launch after upgrade",
+        "fix": "Add a one-time migration: read the legacy UserDefaults token, write it to TokenStore, then clear UserDefaults",
+        "reviewer": "sonnet"
+      },
+      "reason": "Security fix (stop the plaintext leak) ships first; the migration is a separate, lower-risk follow-up that needs its own upgrade test, so it is deferred rather than blocking this PR."
+    }
+  ],
+  "rejected": [],
+  "approved": false
+}

package/pipeline/eval/golden-tasks/05-ios-security-keychain/metadata.json

@@ -0,0 +1,14 @@
+{
+  "focus": "iOS security path with a mixed triage outcome  -  one accepted blocker plus one deferred finding. Verifies the deferred bucket count, not just blockers.",
+  "exercises": [
+    "Phase 1 stack detection (iOS / Swift / SwiftUI) on a security task",
+    "Phase 4 Reviewer-1 (opus) catches a blocking secret-logging leak; Reviewer-2 (sonnet) raises a non-blocking migration gap",
+    "Triage accepts the blocker and DEFERS the migration finding (expectedDeferrals = 1)",
+    "Reviewer findings trace to planned files / triage entries"
+  ],
+  "regressionsCaught": [
+    "If the deferred-count assertion regresses, a 1-deferred fixture catches it (01-04 all have 0 deferrals)",
+    "If validate-triage stops allowing a populated deferred bucket with approved=false, this fixture fails",
+    "If stack detection misroutes a security-flavored iOS task, the stack-match check fails"
+  ]
+}

package/pipeline/eval/golden-tasks/05-ios-security-keychain/task.json

@@ -0,0 +1,12 @@
+{
+  "title": "Move the auth token from UserDefaults into the Keychain",
+  "description": "The session auth token is stored in UserDefaults, which is not secure storage. Move it into the Keychain behind a TokenStore abstraction and update SessionManager to read/write through it.",
+  "inputType": "free-text",
+  "expectedStack": "ios",
+  "expectedLanguage": "Swift",
+  "expectedFramework": "SwiftUI",
+  "expectedBlockers": 1,
+  "expectedDeferrals": 1,
+  "baseBranch": "develop",
+  "taskBranch": "feature/keychain-token-store"
+}

package/pipeline/eval/golden-tasks/06-android-refactor-usecase/expected/phase-1-analysis.json

@@ -0,0 +1,29 @@
+{
+  "stack": {
+    "primary": "android",
+    "language": "Kotlin 2.1",
+    "framework": "Jetpack Compose"
+  },
+  "touchedAreas": [
+    {
+      "path": "feature/booking/BookingUseCase.kt",
+      "why": "New use case that holds the booking business rules extracted from the ViewModel"
+    },
+    {
+      "path": "feature/booking/BookingViewModel.kt",
+      "why": "Delegates rule evaluation to BookingUseCase, keeps only UI state mapping"
+    },
+    {
+      "path": "feature/booking/BookingViewModelTest.kt",
+      "why": "Existing behavior tests stay green to prove the refactor preserves behavior"
+    }
+  ],
+  "risks": [
+    {
+      "risk": "If the extraction accidentally changes coroutine dispatcher or state emission order, the UI could behave differently despite passing logic tests",
+      "severity": "low",
+      "mitigation": "Keep the same dispatcher and StateFlow emission points; rely on the existing ViewModel tests as the behavior contract"
+    }
+  ],
+  "summary": "BookingViewModel mixes UI state and booking rules. Extract the rules into a BookingUseCase and have the ViewModel delegate, with no behavior change. The existing ViewModel tests act as the contract; risk is low as long as dispatcher and emission order are preserved."
+}

package/pipeline/eval/golden-tasks/06-android-refactor-usecase/expected/phase-2-plan.json

@@ -0,0 +1,41 @@
+{
+  "approach": "Behavior-preserving refactor. First confirm the existing BookingViewModel tests pass and cover the rules (no new RED needed; the tests are the safety net). Extract the rules into BookingUseCase, then make the ViewModel delegate. Re-run the same tests to prove behavior is unchanged.",
+  "tasks": [
+    {
+      "id": "T1",
+      "title": "Pin behavior with the existing ViewModel tests (safety net)",
+      "type": "test",
+      "files": ["feature/booking/BookingViewModelTest.kt"],
+      "dependsOn": [],
+      "acceptanceCriteria": [
+        "Existing booking-rule tests pass before the refactor",
+        "Tests assert observable StateFlow outputs, not internal calls"
+      ]
+    },
+    {
+      "id": "T2",
+      "title": "Extract booking rules into BookingUseCase",
+      "type": "refactor",
+      "files": ["feature/booking/BookingUseCase.kt"],
+      "dependsOn": ["T1"],
+      "acceptanceCriteria": [
+        "BookingUseCase exposes the rules via a single operator invoke",
+        "No Android framework types leak into the use case"
+      ]
+    },
+    {
+      "id": "T3",
+      "title": "Delegate from BookingViewModel to BookingUseCase",
+      "type": "refactor",
+      "files": ["feature/booking/BookingViewModel.kt"],
+      "dependsOn": ["T2"],
+      "acceptanceCriteria": [
+        "ViewModel keeps only UI-state mapping and calls the use case",
+        "Same dispatcher and StateFlow emission points as before",
+        "All existing tests still pass"
+      ]
+    }
+  ],
+  "approved": true,
+  "userFeedback": null
+}

package/pipeline/eval/golden-tasks/06-android-refactor-usecase/expected/phase-4-review.json

@@ -0,0 +1,12 @@
+[
+  {
+    "reviewer": "opus",
+    "findings": [],
+    "approved": true
+  },
+  {
+    "reviewer": "sonnet",
+    "findings": [],
+    "approved": true
+  }
+]

package/pipeline/eval/golden-tasks/06-android-refactor-usecase/expected/phase-4-triage.json

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

package/pipeline/eval/golden-tasks/06-android-refactor-usecase/metadata.json

@@ -0,0 +1,14 @@
+{
+  "focus": "Android refactor with a clean approval  -  0 blockers, 0 deferrals, both reviewers approve. Verifies the happy path (empty triage, approved=true), which the bug-finding fixtures never exercise.",
+  "exercises": [
+    "Phase 1 stack detection (Android / Kotlin / Jetpack Compose)",
+    "Phase 2 plan with a behavior-preserving test gate before extraction",
+    "Phase 4 both reviewers return zero findings and approve",
+    "Triage with all-empty buckets and approved=true passes validate-triage"
+  ],
+  "regressionsCaught": [
+    "If validate-triage stops accepting an all-empty approved triage, this fixture fails",
+    "If the eval ever assumes at least one finding exists, a zero-finding fixture catches it",
+    "If Android detection regresses, the stack-match check fails"
+  ]
+}

package/pipeline/eval/golden-tasks/06-android-refactor-usecase/task.json

@@ -0,0 +1,12 @@
+{
+  "title": "Extract booking logic from BookingViewModel into a UseCase",
+  "description": "BookingViewModel mixes UI state with booking business rules. Extract the rules into a BookingUseCase (Clean Architecture) with no behavior change, and have the ViewModel delegate to it. Pure refactor, covered by existing behavior tests.",
+  "inputType": "free-text",
+  "expectedStack": "android",
+  "expectedLanguage": "Kotlin",
+  "expectedFramework": "Jetpack Compose",
+  "expectedBlockers": 0,
+  "expectedDeferrals": 0,
+  "baseBranch": "develop",
+  "taskBranch": "refactor/booking-usecase"
+}

package/pipeline/eval/golden-tasks/07-backend-node-idempotency/expected/phase-1-analysis.json

@@ -0,0 +1,29 @@
+{
+  "stack": {
+    "primary": "backend",
+    "language": "JavaScript",
+    "framework": "Express"
+  },
+  "touchedAreas": [
+    {
+      "path": "src/payments/idempotency.js",
+      "why": "New middleware that reads Idempotency-Key, stores the first response, and replays duplicates"
+    },
+    {
+      "path": "src/payments/router.js",
+      "why": "Wires the middleware ahead of the POST /payments handler"
+    },
+    {
+      "path": "test/idempotency.test.js",
+      "why": "Covers first-call passthrough, duplicate-key replay, and TTL expiry"
+    }
+  ],
+  "risks": [
+    {
+      "risk": "A store keyed only by the header lets a client collide another client's key; the key should be namespaced per authenticated account",
+      "severity": "medium",
+      "mitigation": "Namespace the stored key with the account id so keys cannot collide across users"
+    }
+  ],
+  "summary": "POST /payments can double-charge on retry. Add Idempotency-Key middleware that stores and replays the first response within a TTL, wired ahead of the handler. Main hazard is cross-account key collision, mitigated by namespacing the key per account."
+}

package/pipeline/eval/golden-tasks/07-backend-node-idempotency/expected/phase-2-plan.json

@@ -0,0 +1,42 @@
+{
+  "approach": "TDD-first. Write tests for first-call passthrough, duplicate-key replay (same response, no second charge), and TTL expiry (RED). Implement the idempotency middleware with a per-account-namespaced key and a TTL store (GREEN). Wire it ahead of the payments handler (integration).",
+  "tasks": [
+    {
+      "id": "T1",
+      "title": "Add failing idempotency tests (passthrough, replay, TTL)",
+      "type": "test",
+      "files": ["test/idempotency.test.js"],
+      "dependsOn": [],
+      "acceptanceCriteria": [
+        "First request with a key passes through and is stored",
+        "Duplicate key within TTL replays the stored response without re-charging",
+        "After TTL expiry the key is treated as new"
+      ]
+    },
+    {
+      "id": "T2",
+      "title": "Implement idempotency middleware",
+      "type": "code",
+      "files": ["src/payments/idempotency.js"],
+      "dependsOn": ["T1"],
+      "acceptanceCriteria": [
+        "Reads the Idempotency-Key header and validates its length and charset",
+        "Namespaces the stored key by authenticated account id",
+        "Stores first response with a TTL and replays on duplicate"
+      ]
+    },
+    {
+      "id": "T3",
+      "title": "Wire the middleware ahead of POST /payments",
+      "type": "code",
+      "files": ["src/payments/router.js"],
+      "dependsOn": ["T2"],
+      "acceptanceCriteria": [
+        "Middleware runs before the payment handler",
+        "Requests without the header still work (idempotency optional)"
+      ]
+    }
+  ],
+  "approved": true,
+  "userFeedback": null
+}

package/pipeline/eval/golden-tasks/07-backend-node-idempotency/expected/phase-4-review.json

@@ -0,0 +1,28 @@
+[
+  {
+    "reviewer": "opus",
+    "findings": [
+      {
+        "severity": "blocking",
+        "file": "src/payments/idempotency.js",
+        "line": 22,
+        "issue": "The Idempotency-Key header is used as a store key with no length or charset validation; a client can send a multi-megabyte key and exhaust the store, and odd bytes can corrupt the keyspace",
+        "fix": "Reject keys that are not 1-255 chars of [A-Za-z0-9-_] before using them as a store key"
+      }
+    ],
+    "approved": false
+  },
+  {
+    "reviewer": "sonnet",
+    "findings": [
+      {
+        "severity": "important",
+        "file": "src/payments/router.js",
+        "line": 14,
+        "issue": "The handler call looks like it is missing an await, so the response may be sent before the charge resolves",
+        "fix": "Await the charge before responding"
+      }
+    ],
+    "approved": false
+  }
+]

package/pipeline/eval/golden-tasks/07-backend-node-idempotency/expected/phase-4-triage.json

@@ -0,0 +1,27 @@
+{
+  "accepted": [
+    {
+      "severity": "blocking",
+      "file": "src/payments/idempotency.js",
+      "line": 22,
+      "issue": "The Idempotency-Key header is used as a store key with no length or charset validation; a client can send a multi-megabyte key and exhaust the store, and odd bytes can corrupt the keyspace",
+      "fix": "Reject keys that are not 1-255 chars of [A-Za-z0-9-_] before using them as a store key",
+      "reviewer": "opus"
+    }
+  ],
+  "deferred": [],
+  "rejected": [
+    {
+      "finding": {
+        "severity": "important",
+        "file": "src/payments/router.js",
+        "line": 14,
+        "issue": "The handler call looks like it is missing an await, so the response may be sent before the charge resolves",
+        "fix": "Await the charge before responding",
+        "reviewer": "sonnet"
+      },
+      "reason": "False positive: the handler is registered with express-async-handler, which awaits the returned promise, and the charge is already awaited inside it. No missing await."
+    }
+  ],
+  "approved": false
+}

package/pipeline/eval/golden-tasks/07-backend-node-idempotency/metadata.json

@@ -0,0 +1,14 @@
+{
+  "focus": "Backend (Node/Express) feature that exercises the REJECTED triage bucket  -  one accepted blocker plus one rejected false-positive. The only fixture that populates rejected.",
+  "exercises": [
+    "Phase 1 stack detection (backend / JavaScript / Express)",
+    "Phase 4 Reviewer-1 (opus) raises a real input-validation blocker; Reviewer-2 (sonnet) raises a false-positive 'missing await'",
+    "Triage accepts the blocker and REJECTS the false positive with a reason",
+    "validate-triage accepts a populated rejected bucket (finding + reason shape)"
+  ],
+  "regressionsCaught": [
+    "If the rejected-bucket {finding, reason} shape regresses, this fixture fails validate-triage",
+    "If triage drops the reviewer attribution on a rejected finding, it fails",
+    "If the eval's finding-traceability check breaks on rejected entries, this catches it"
+  ]
+}

package/pipeline/eval/golden-tasks/07-backend-node-idempotency/task.json

@@ -0,0 +1,12 @@
+{
+  "title": "Add idempotency keys to the payments POST endpoint",
+  "description": "POST /payments can double-charge on client retry. Accept an Idempotency-Key header, store the first response keyed by it, and replay that response for duplicate keys within a TTL.",
+  "inputType": "free-text",
+  "expectedStack": "backend",
+  "expectedLanguage": "JavaScript",
+  "expectedFramework": "Express",
+  "expectedBlockers": 1,
+  "expectedDeferrals": 0,
+  "baseBranch": "main",
+  "taskBranch": "feature/payments-idempotency"
+}