@mmerterden/multi-agent-pipeline 8.6.1 → 10.0.6

package/pipeline/eval/golden-tasks/08-ios-auth-consensus-unverified/expected/phase-1-analysis.json

@@ -0,0 +1,25 @@
+{
+  "stack": {
+    "primary": "ios",
+    "language": "Swift 6",
+    "framework": "SwiftUI"
+  },
+  "touchedAreas": [
+    {
+      "path": "Sources/Auth/TokenStore.swift",
+      "why": "Wrap the Keychain read in an LAContext biometric evaluation before returning the token"
+    },
+    {
+      "path": "Sources/Auth/TokenStoreTests.swift",
+      "why": "Cover the gated read: success after auth, failure/cancel returns no token"
+    }
+  ],
+  "risks": [
+    {
+      "risk": "Biometric evaluation is async and can fail/cancel; a wrong fallback could either lock users out or defeat the gate",
+      "severity": "medium",
+      "mitigation": "Define explicit behavior for cancel / not-enrolled / lockout, and test each path"
+    }
+  ],
+  "summary": "Add a biometric (LAContext) check in front of the existing Keychain-backed TokenStore read. Security-sensitive surface: the correctness hinges on the failure-path policy (cancel / not-enrolled / lockout), which is exactly the kind of judgment call where two same-family reviewers approving is not independent proof."
+}

package/pipeline/eval/golden-tasks/08-ios-auth-consensus-unverified/expected/phase-2-plan.json

@@ -0,0 +1,31 @@
+{
+  "approach": "TDD-first. Add failing tests for the gated read: a successful biometric evaluation returns the token; a cancelled or failed evaluation returns no token and does not fall back to an ungated read (RED). Wrap the existing Keychain read in an LAContext evaluation, keeping the TokenStore API unchanged (GREEN). Define explicit behavior for cancel / not-enrolled / lockout (refactor).",
+  "tasks": [
+    {
+      "id": "T1",
+      "title": "Add failing biometric-gated read tests",
+      "type": "test",
+      "files": ["Sources/Auth/TokenStoreTests.swift"],
+      "dependsOn": [],
+      "acceptanceCriteria": [
+        "success after auth returns the stored token",
+        "cancelled / failed auth returns nil and never reads the Keychain ungated",
+        "evaluation runs against an injectable LAContext double"
+      ]
+    },
+    {
+      "id": "T2",
+      "title": "Gate the Keychain read behind LAContext",
+      "type": "code",
+      "files": ["Sources/Auth/TokenStore.swift"],
+      "dependsOn": ["T1"],
+      "acceptanceCriteria": [
+        "TokenStore public API is unchanged",
+        "Token is only returned after a successful biometric evaluation",
+        "cancel / not-enrolled / lockout each have explicit, tested behavior"
+      ]
+    }
+  ],
+  "approved": true,
+  "userFeedback": null
+}

package/pipeline/eval/golden-tasks/08-ios-auth-consensus-unverified/expected/phase-4-review.json

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

package/pipeline/eval/golden-tasks/08-ios-auth-consensus-unverified/expected/phase-4-triage.json

@@ -0,0 +1,18 @@
+{
+  "accepted": [],
+  "deferred": [],
+  "rejected": [],
+  "approved": true,
+  "consensus": {
+    "reviewerCount": 2,
+    "verdict": "unverified",
+    "disagreements": [
+      {
+        "file": "Sources/Auth/TokenStore.swift",
+        "line": 0,
+        "issue": "biometric failure-path policy (cancel / not-enrolled / lockout) on a Keychain-gated read",
+        "note": "Both reviewers approved, but this is a security/auth judgment surface - the agreement is unverified. A human should confirm the cancel / not-enrolled / lockout behavior before trusting the pass."
+      }
+    ]
+  }
+}

package/pipeline/eval/golden-tasks/08-ios-auth-consensus-unverified/metadata.json

@@ -0,0 +1,14 @@
+{
+  "focus": "Consensus surfacing (schema v3.1.0). Both reviewers APPROVE on a security/auth surface, so triage has zero accepted/deferred/rejected - but the agreement is flagged `unverified` (same-base-model approval on a judgment-heavy surface is not treated as proof) and a disagreement note is surfaced. Verifies the consensus block passes validation with approved=true + verdict=unverified.",
+  "exercises": [
+    "Phase 4 both reviewers approve (no findings) on a biometric/Keychain change",
+    "Triage short-circuits to empty buckets, approved=true",
+    "Triage attaches consensus { reviewerCount: 2, verdict: unverified, disagreements: [...] }",
+    "validate-triage accepts the consensus block and its cross-checks pass (unverified + approved=true is valid)"
+  ],
+  "regressionsCaught": [
+    "If validate-triage stops accepting a consensus block, this fixture fails",
+    "If the consensus cross-check wrongly rejects unverified+approved=true, this fixture fails",
+    "If a unanimous-pass were emitted on a security surface (instead of unverified), the intent of consensus surfacing is lost - the metadata documents the expected verdict"
+  ]
+}

package/pipeline/eval/golden-tasks/08-ios-auth-consensus-unverified/task.json

@@ -0,0 +1,12 @@
+{
+  "title": "Add a biometric gate before reading the Keychain auth token",
+  "description": "Require a Face ID / Touch ID check (LAContext) before TokenStore returns the auth token, so a stolen unlocked device can't silently reuse the session. Keep the existing TokenStore API.",
+  "inputType": "free-text",
+  "expectedStack": "ios",
+  "expectedLanguage": "Swift",
+  "expectedFramework": "SwiftUI",
+  "expectedBlockers": 0,
+  "expectedDeferrals": 0,
+  "baseBranch": "develop",
+  "taskBranch": "feature/biometric-token-gate"
+}

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

@@ -1,10 +1,10 @@
-# Golden tasks — regression fixtures for the full pipeline (v6.2.F+)
+# 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?"*
+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.).
+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.
 
@@ -12,16 +12,16 @@ This is a **contract regression test**, same category as `eval-triage.mjs`. A li
 
 ```
 NN-short-kebab-name/
-  task.json            — input (task description, expected stack, target repo metadata)
+  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)
+    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.
+`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
 
@@ -30,7 +30,7 @@ Add one when you discover a class of task that the pipeline should handle but no
 - 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.
+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
 
@@ -52,7 +52,7 @@ Exit codes: `0` all pass · `1` one or more fail · `2` usage / setup error.
 ## 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.
+- Score output "quality"  -  no rubric, no judge. Only contract checks.
 - Replay timing / token budgets. Tracker and budget smokes cover that orthogonally.
 
 ---
@@ -61,5 +61,5 @@ Exit codes: `0` all pass · `1` one or more fail · `2` usage / setup error.
 
 | # | 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 |
+| 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/intent-cases.json

@@ -0,0 +1,40 @@
+{
+  "_readme": "Labeled cases for the Phase 0 conceptual-vs-edit intent guard (pipeline/lib/classify-intent.sh). eval-intent.mjs runs each input through the classifier and reports accuracy. The DANGEROUS error is a real task read as 'question' (work silently skipped) or a clear question read as 'task' (a worktree spun up for nothing); 'ambiguous' is the safe middle and is accepted for genuinely vague input. Add real misclassifications here as they are found - this is the regression set.",
+  "cases": [
+    { "input": "fix the login crash on launch", "expected": "task" },
+    { "input": "refactor the cache layer", "expected": "task" },
+    { "input": "add a retry to the network client", "expected": "task" },
+    { "input": "LoginView dark mode fix", "expected": "task" },
+    { "input": "implement biometric unlock for the keychain", "expected": "task" },
+    { "input": "remove the deprecated analytics call", "expected": "task" },
+    { "input": "can you split this file into two", "expected": "task" },
+    { "input": "could you rename TokenStore to SessionStore", "expected": "task" },
+    { "input": "please add a loading spinner to the list", "expected": "task" },
+    { "input": "login ekranina retry ekle", "expected": "task" },
+    { "input": "cache katmanini yeniden duzenle", "expected": "task" },
+    { "input": "su crash'i duzelt", "expected": "task" },
+    { "input": "how does the login flow work", "expected": "question" },
+    { "input": "what does this function return", "expected": "question" },
+    { "input": "why is the navigation so slow", "expected": "question" },
+    { "input": "should we use Keychain or UserDefaults", "expected": "question" },
+    { "input": "does it support offline mode", "expected": "question" },
+    { "input": "should we enable caching here", "expected": "question" },
+    { "input": "which architecture is better for this screen", "expected": "question" },
+    { "input": "explain the auth module", "expected": "question" },
+    { "input": "compare MVVM and TCA for this", "expected": "question" },
+    { "input": "is this thread-safe", "expected": "question" },
+    { "input": "nasil calisiyor bu akis", "expected": "question" },
+    { "input": "neden bu kadar yavas", "expected": "question" },
+    { "input": "Keychain mi UserDefaults mi kullanmaliyim", "expected": "question" },
+    { "input": "bu thread-safe mi", "expected": "question" },
+
+    { "input": "fix the bug?", "expected": "task" },
+    { "input": "add retry logic, ok?", "expected": "task" },
+    { "input": "can you explain how to add a retry", "expected": "question" },
+    { "input": "could you tell me which file to update", "expected": "question" },
+    { "input": "would you say we should refactor this", "expected": "question" },
+    { "input": "what happens if I remove this", "expected": "question" },
+    { "input": "bu fonksiyonu nasil refactor ederim", "expected": "question" },
+    { "input": "hangi mimariyi kullanmaliyim", "expected": "question" }
+  ]
+}

package/pipeline/eval/run-metrics-fixture.json

@@ -0,0 +1,46 @@
+{
+  "taskId": "PROJ-101",
+  "status": "complete",
+  "currentPhase": 7,
+  "projects": [
+    { "project": "my-ios-app", "buildStatus": { "ok": true, "attempts": 1 } }
+  ],
+  "reviewIterations": [
+    {
+      "reviewers": [
+        { "reviewer": "opus", "findings": [
+          { "severity": "blocking", "file": "Auth/Session.swift", "line": 54, "issue": "token logged in plaintext", "fix": "redact" },
+          { "severity": "suggestion", "file": "Auth/Session.swift", "line": 12, "issue": "rename helper", "fix": "rename" }
+        ], "approved": false },
+        { "reviewer": "sonnet", "findings": [
+          { "severity": "important", "file": "Auth/Session.swift", "line": 70, "issue": "no migration for legacy token", "fix": "add migration" }
+        ], "approved": false }
+      ],
+      "triage": {
+        "accepted": [
+          { "severity": "blocking", "file": "Auth/Session.swift", "line": 54, "issue": "token logged in plaintext", "fix": "redact the token in the log", "reviewer": "opus" }
+        ],
+        "deferred": [
+          { "finding": { "severity": "important", "file": "Auth/Session.swift", "line": 70, "issue": "no migration for legacy token" }, "reason": "follow-up PR" }
+        ],
+        "rejected": [
+          { "finding": { "severity": "suggestion", "file": "Auth/Session.swift", "line": 12, "issue": "rename helper" }, "reason": "style only" }
+        ],
+        "approved": false
+      }
+    },
+    {
+      "reviewers": [
+        { "reviewer": "opus", "findings": [], "approved": true },
+        { "reviewer": "sonnet", "findings": [], "approved": true }
+      ],
+      "triage": {
+        "accepted": [],
+        "deferred": [],
+        "rejected": [],
+        "approved": true,
+        "consensus": { "reviewerCount": 2, "verdict": "unanimous-pass" }
+      }
+    }
+  ]
+}

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

@@ -1,4 +1,4 @@
-# Case 01 — Empty findings short-circuit
+# Case 01  -  Empty findings short-circuit
 
 Both reviewers returned zero findings. Triage MUST short-circuit and emit `{approved: true}` directly, no agent call.
 

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

@@ -1,7 +1,7 @@
-# Case 02 — In-scope blocker accepted
+# 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).
+Validator exit code: 0 (clean  -  accepted + approved:false is consistent because there IS a blocker).

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

@@ -1,4 +1,4 @@
-# Case 03 — Real issue, out of scope → defer
+# 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.
 

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

@@ -1,4 +1,4 @@
-# Case 04 — False positive → reject
+# 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.
 

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

@@ -1,4 +1,4 @@
-# Case 05 — Mixed classification (the realistic case)
+# Case 05  -  Mixed classification (the realistic case)
 
 4 raw findings spanning all 3 outcomes:
 
@@ -12,6 +12,6 @@ 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)
+- 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/notes.md

@@ -1,6 +1,6 @@
-# Case 06 — Severity mismatch (suggestion → blocking)
+# 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.
+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.
 

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

@@ -1,4 +1,4 @@
-# Case 07 — Duplicate findings from two reviewers
+# 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.
 

package/pipeline/eval/triage/08-style-misclassified/notes.md

@@ -1,4 +1,4 @@
-# Case 08 — Stylistic blocker misclassification
+# Case 08  -  Stylistic blocker misclassification
 
 Reviewer tagged a naming preference as `severity: "blocking"`. Renaming `fmt` to `formatCurrency` is a style opinion, not a correctness or security issue.
 

package/pipeline/eval/triage/09-cascading-finding/notes.md

@@ -1,8 +1,8 @@
-# Case 09 — Cascading finding (symptom + root cause)
+# Case 09  -  Cascading finding (symptom + root cause)
 
 Two findings describe the same underlying problem at different levels: (a) the symptom ("tests fail intermittently") and (b) the root cause ("Math.random() without a fixed seed").
 
-Triage must accept BOTH but order them upstream-first: the root cause (b) comes before the symptom (a) in the accepted array. The fix text for (a) references (b) to document the cascade — fixing the seed should resolve the intermittent failures.
+Triage must accept BOTH but order them upstream-first: the root cause (b) comes before the symptom (a) in the accepted array. The fix text for (a) references (b) to document the cascade  -  fixing the seed should resolve the intermittent failures.
 
 Guards against: treating symptom and root cause as independent issues. The cascade relationship must be explicit in the fix text so the developer addresses root cause first.
 

package/pipeline/eval/triage/10-deferred-crossref/notes.md

@@ -1,8 +1,8 @@
-# Case 10 — Deferred with cross-reference
+# Case 10  -  Deferred with cross-reference
 
 A real issue (missing audit event in refund flow) that is out of scope for the current task (checkout session creation). However, the next planned task (PROJ-5678, refund work) assumes audit events already exist.
 
-Triage must defer — not reject — because the issue is real. The reason must capture the cross-task dependency: deferring is correct, but the reason needs to surface that PROJ-5678 will be affected.
+Triage must defer  -  not reject  -  because the issue is real. The reason must capture the cross-task dependency: deferring is correct, but the reason needs to surface that PROJ-5678 will be affected.
 
 Guards against: losing inter-task dependencies when deferring. A bare "out of scope" reason is insufficient; the cross-reference to the downstream task ensures Phase 7 captures this for backlog prioritization.
 

package/pipeline/eval/triage/11-vercel-token-leak-blocker/expected.json

@@ -4,8 +4,8 @@
       "severity": "blocking",
       "file": "scripts/deploy.sh",
       "line": 14,
-      "issue": "Script invokes `vercel deploy --token=$VERCEL_TOKEN`. On retry the Vercel CLI prints failed argv verbatim — the token leaks into the conversation transcript and CI logs. Same shape as the v7.9.1 incident that forced a token rotation.",
-      "fix": "Replace with the safe wrapper: `bash $HOME/.claude/scripts/vercel-deploy.sh deploy --prod`. The wrapper refuses --token argv, reads VERCEL_TOKEN from env, and pipes stdout/stderr through a redact filter that scrubs vcp_… patterns.",
+      "issue": "Script invokes `vercel deploy --token=$VERCEL_TOKEN`. On retry the Vercel CLI prints failed argv verbatim  -  the token leaks into the conversation transcript and CI logs. Same shape as the v7.9.1 incident that forced a token rotation.",
+      "fix": "Replace with the safe wrapper: `bash $HOME/.claude/scripts/vercel-deploy.sh deploy --prod`. The wrapper refuses --token argv, reads VERCEL_TOKEN from env, and pipes stdout/stderr through a redact filter that scrubs vcp_... patterns.",
       "reviewer": "opus"
     }
   ],
@@ -20,7 +20,7 @@
         "fix": "Use env var; never argv.",
         "reviewer": "sonnet"
       },
-      "reason": "duplicate — same root cause as the accepted blocking finding; merging would dilute the actionable line"
+      "reason": "duplicate  -  same root cause as the accepted blocking finding; merging would dilute the actionable line"
     }
   ],
   "approved": false

package/pipeline/eval/triage/11-vercel-token-leak-blocker/input.json

@@ -4,8 +4,8 @@
       "severity": "blocking",
       "file": "scripts/deploy.sh",
       "line": 14,
-      "issue": "Script invokes `vercel deploy --token=$VERCEL_TOKEN`. On retry the Vercel CLI prints failed argv verbatim — the token leaks into the conversation transcript and CI logs. Same shape as the v7.9.1 incident that forced a token rotation.",
-      "fix": "Replace with the safe wrapper: `bash $HOME/.claude/scripts/vercel-deploy.sh deploy --prod`. The wrapper refuses --token argv, reads VERCEL_TOKEN from env, and pipes stdout/stderr through a redact filter that scrubs vcp_… patterns.",
+      "issue": "Script invokes `vercel deploy --token=$VERCEL_TOKEN`. On retry the Vercel CLI prints failed argv verbatim  -  the token leaks into the conversation transcript and CI logs. Same shape as the v7.9.1 incident that forced a token rotation.",
+      "fix": "Replace with the safe wrapper: `bash $HOME/.claude/scripts/vercel-deploy.sh deploy --prod`. The wrapper refuses --token argv, reads VERCEL_TOKEN from env, and pipes stdout/stderr through a redact filter that scrubs vcp_... patterns.",
       "reviewer": "opus"
     },
     {

package/pipeline/eval/triage/11-vercel-token-leak-blocker/notes.md

@@ -1,14 +1,14 @@
-# Case 11 — Vercel token-leak as a blocker (v8.0.0)
+# Case 11  -  Vercel token-leak as a blocker (v8.0.0)
 
 Two reviewers flag the same `vercel deploy --token=$VERCEL_TOKEN` call. Triage MUST:
 
-1. **Accept** the Opus finding — it's a real production-affecting blocker, identical in shape to the v7.9.1 incident that forced a token rotation.
-2. **Reject** the Sonnet finding as a duplicate — same root cause (token in argv), additional reviewer would dilute the actionable line. The fix is the same code change either way.
+1. **Accept** the Opus finding  -  it's a real production-affecting blocker, identical in shape to the v7.9.1 incident that forced a token rotation.
+2. **Reject** the Sonnet finding as a duplicate  -  same root cause (token in argv), additional reviewer would dilute the actionable line. The fix is the same code change either way.
 3. Set `approved: false` because at least one accepted blocking remains.
 
 Guards against:
-- Future regressions where token-leak findings get classified as `suggestion` or `style` (they are blocking — secret leaks reach production logs and force rotation).
+- Future regressions where token-leak findings get classified as `suggestion` or `style` (they are blocking  -  secret leaks reach production logs and force rotation).
 - Triage adding both reviewers' findings to `accepted` and producing two redundant "fix this" lines for the same line of code.
 - Approving the diff while a blocker is open.
 
-Validator exit code: 0 (clean — no contradictions).
+Validator exit code: 0 (clean  -  no contradictions).

package/pipeline/eval/triage/README.md

@@ -10,9 +10,9 @@ Each test case lives in its own subdirectory:
 pipeline/eval/triage/
 ├── README.md
 ├── 01-empty-findings/
-│   ├── input.json       — what reviewers returned (raw findings, scope, diff)
-│   ├── expected.json    — what the triage step MUST produce, normalized
-│   └── notes.md         — why this case matters
+│   ├── input.json        -  what reviewers returned (raw findings, scope, diff)
+│   ├── expected.json     -  what the triage step MUST produce, normalized
+│   └── notes.md          -  why this case matters
 ├── 02-real-blocker/
 ├── 03-out-of-scope-defer/
 ├── 04-false-positive-reject/
@@ -41,7 +41,7 @@ For each case the runner:
 2. Runs `validate-triage.mjs` against `expected.json` and asserts the documented exit code.
 3. Compares classification membership: each finding in `input.json.rawFindings` must appear in exactly one of `accepted | deferred | rejected` in `expected.json` (no leaks, no inventions).
 
-This is **not** a model-quality check (we don't run a real triage agent in CI — that requires API keys and is non-deterministic). It's a **contract regression check**: the fixtures encode "for input X, the spec says triage MUST produce Y", and any prompt/spec change that breaks the mapping fails CI.
+This is **not** a model-quality check (we don't run a real triage agent in CI  -  that requires API keys and is non-deterministic). It's a **contract regression check**: the fixtures encode "for input X, the spec says triage MUST produce Y", and any prompt/spec change that breaks the mapping fails CI.
 
 ## Adding new cases
 

package/pipeline/lib/account-resolver.sh

@@ -4,7 +4,7 @@
 # Discovers GitHub / Jira / Bitbucket / Confluence accounts from macOS Keychain
 # and emits a JSON inventory consumed by the multi-agent picker.
 #
-# Each account is identified by a *prefix* — the keychain service-name segment
+# Each account is identified by a *prefix*  -  the keychain service-name segment
 # that precedes the provider segment. Examples:
 #   ${USER}_Github_Access_Token        -> prefix=${USER}
 #   ${USER}_Tktech_Github_Access_Token -> prefix=${USER}_Tktech
@@ -128,7 +128,7 @@ emit_accounts() {
       is_work="true"
     fi
 
-    # Short id (lower, dashes) — used for per-account override lookup.
+    # Short id (lower, dashes)  -  used for per-account override lookup.
     local short_id
     short_id=$(printf '%s' "$prefix" | tr '[:upper:]_' '[:lower:]-')
 
@@ -149,7 +149,7 @@ emit_accounts() {
       fi
     fi
 
-    # GitHub username — heuristically match to gh CLI accounts
+    # GitHub username  -  heuristically match to gh CLI accounts
     local gh_user=""
     if [ -n "$gh_token" ] && command -v gh >/dev/null 2>&1; then
       local gh_accounts

package/pipeline/lib/ask-choice.sh

@@ -0,0 +1,98 @@
+#!/usr/bin/env bash
+# ask-choice.sh  -  portable single-choice picker for platforms WITHOUT a native
+# AskUserQuestion primitive (Gemini CLI, Antigravity, Copilot CLI, and Cursor
+# Agent mode). It renders a numbered menu, reads one selection, and echoes the
+# chosen option label on stdout. This is the universal fallback in the pipeline's
+# picker abstraction (see refs/picker-contract.md): Claude Code uses native
+# AskUserQuestion; everything else degrades to this.
+#
+# Usage:
+#   ask-choice.sh "<question>" "<option1>" "<option2>" [option3 ...]
+#
+# Output: the selected option's exact label on stdout (nothing else on stdout).
+# Prompts/menu render on stderr so stdout stays a clean machine-readable value.
+#
+# Non-interactive / autopilot / CI:
+#   - ASK_CHOICE_DEFAULT=<label-or-1based-index>  picks without prompting.
+#   - If stdin is not a TTY and no default is set, the FIRST option is chosen
+#     and a notice is written to stderr (never blocks an automated run).
+#
+# Exit codes: 0 selection made (label on stdout) · 64 usage error.
+
+set -uo pipefail
+
+if [ "$#" -lt 3 ]; then
+  echo "usage: ask-choice.sh \"<question>\" \"<option1>\" \"<option2>\" [option3 ...]" >&2
+  exit 64
+fi
+
+QUESTION="$1"; shift
+OPTIONS=("$@")
+COUNT="${#OPTIONS[@]}"
+
+# Resolve a default (label or 1-based index) to the option label, or empty.
+resolve_default() {
+  local d="$1"
+  [ -z "$d" ] && { echo ""; return; }
+  # numeric index?
+  case "$d" in
+    ''|*[!0-9]*) ;; # not a pure number, fall through to label match
+    *)
+      if [ "$d" -ge 1 ] && [ "$d" -le "$COUNT" ]; then
+        echo "${OPTIONS[$((d - 1))]}"; return
+      fi
+      ;;
+  esac
+  # label match (case-insensitive, trimmed)
+  local lower_d
+  lower_d=$(printf '%s' "$d" | tr '[:upper:]' '[:lower:]')
+  for opt in "${OPTIONS[@]}"; do
+    if [ "$(printf '%s' "$opt" | tr '[:upper:]' '[:lower:]')" = "$lower_d" ]; then
+      echo "$opt"; return
+    fi
+  done
+  echo ""
+}
+
+if [ -n "${ASK_CHOICE_DEFAULT:-}" ]; then
+  resolved=$(resolve_default "$ASK_CHOICE_DEFAULT")
+  if [ -n "$resolved" ]; then
+    printf '%s\n' "$resolved"
+    exit 0
+  fi
+  echo "ask-choice: ASK_CHOICE_DEFAULT='${ASK_CHOICE_DEFAULT}' matched no option; falling through" >&2
+fi
+
+# Non-interactive with no usable default: pick the first option, don't block.
+if [ ! -t 0 ]; then
+  echo "ask-choice: no TTY and no ASK_CHOICE_DEFAULT - selecting first option '${OPTIONS[0]}'" >&2
+  printf '%s\n' "${OPTIONS[0]}"
+  exit 0
+fi
+
+# Interactive: render menu on stderr, read on stdin, loop until valid.
+while true; do
+  printf '%s\n' "$QUESTION" >&2
+  local_i=1
+  for opt in "${OPTIONS[@]}"; do
+    printf '  %d) %s\n' "$local_i" "$opt" >&2
+    local_i=$((local_i + 1))
+  done
+  printf 'Select [1-%d]: ' "$COUNT" >&2
+  read -r reply || { printf '%s\n' "${OPTIONS[0]}"; exit 0; }
+  case "$reply" in
+    ''|*[!0-9]*)
+      # allow typing the label too
+      resolved=$(resolve_default "$reply")
+      if [ -n "$resolved" ]; then printf '%s\n' "$resolved"; exit 0; fi
+      echo "  invalid selection, try again" >&2
+      ;;
+    *)
+      if [ "$reply" -ge 1 ] && [ "$reply" -le "$COUNT" ]; then
+        printf '%s\n' "${OPTIONS[$((reply - 1))]}"
+        exit 0
+      fi
+      echo "  out of range, try again" >&2
+      ;;
+  esac
+done

package/pipeline/lib/channels-multi-repo.sh

@@ -10,10 +10,10 @@
 #   render-pr   <state.json> <body.md> <repo> Emit the per-PR body with cross-links substituted (stdout).
 #   render-jira <state.json> <body.md>        Emit the Jira comment with all PR URLs as a bulleted list (stdout).
 #   render-conf <state.json> <body.md>        Emit the Confluence body with `Related PRs` block prepended (stdout).
-#   summary     <state.json>                  Human-readable line: "1 primary + N extras: [pr-urls]" — for autopilot logs.
+#   summary     <state.json>                  Human-readable line: "1 primary + N extras: [pr-urls]"  -  for autopilot logs.
 #
 # Single-repo tasks: every subcommand falls through to the single PR / single
-# body — `targets` returns one entry, render-* leaves the body unchanged.
+# body  -  `targets` returns one entry, render-* leaves the body unchanged.
 
 set -eu
 
@@ -35,7 +35,7 @@ import json, sys
 state = json.load(open(sys.argv[1]))
 projects = state.get("projects") or []
 if not projects:
-    # single-repo state — synthesize one target from top-level fields
+    # single-repo state  -  synthesize one target from top-level fields
     pr = state.get("pr") or {}
     pr_url = pr.get("url") or ""
     name = state.get("project") or "primary"