Repository navigation
fix(fusion): distinguish submitted failures from unfinished repairs - #1042
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs changes before merge. What this changesSeparate submitted benchmark failures from unfinished attempts and document the repeated repair results. Example: A budget-stopped attempt has publicPassed=true, score=0, and outcome=budget.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Partial Merge readiness⛔ Needs changes before merge - 1 item remains Keep open: this maintainer-authored PR addresses a real diagnostic error, but its submission check misses supported draft submissions. Priority: P2 Before merge
Findings
Agent review detailsHow this fits togetherThe offline Fusion analyzer reads settled benchmark receipts and emits quality, cost, timing, failure diagnostics, and pilot-screen results. flowchart LR
A[Repair agents] --> B[Pair benchmark runner]
B --> C[Settled receipts]
C --> D[Pair analyzer]
D --> E[Failure diagnostics]
D --> F[Pilot screen]
Technical reviewBest possible solution: Recognize both existing submission outcomes in the analyzer’s shared classifier and cover draft failures without changing scores, accounting, or pilot gates. Do we have a high-confidence way to reproduce the issue? Source establishes the original broad false-accept count and the introduced draft-submission omission; execution was excluded by the read-only review instructions. Is this the best way to solve the issue? Shared diagnostic classification is the right small fix, provided it follows the submission contract already used by the contract and draft agents. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 1f12686c1448. Provenance checked
TestingProof path: unit tests only. SecurityNone. EvidenceAcceptance criteria:
What I checked:
Likely related people:
Preflight sourceSource unknown. Source comparison at the observed PR snapshot only. Completion is self-reported; body, policy, tests, execution, and report bytes are not verified. LabelsLabel changes:
Label justifications:
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed November 13, 2026, 1:08 PM ET / 18:08 UTC. |
Summary
Fusion repeat analysis counted every zero-score visible pass as a false accept, including budget stops that had never submitted. Distinguish submitted failures, visible-pass failures, and passing unsubmitted patches in both single-block and repeated reports. Scores, accounting and pilot criteria are unchanged; older receipts without an outcome cannot establish submission.
Document the frozen two-task, two-block confirmation: Sol-to-Luna handoff and Sol each completed 2/4 repairs, Luna 0/4. Handoff cost 57.51% less and used 9.20% more agent time than Sol. All completions were the streaming task; neither arm completed lifecycle repair. The 50% completion rate fails the predeclared 75% reliability threshold. No superiority or production-promotion claim.
Correct earlier result labels that reversed the executed model order:
edit-handoffruns Sol first, then Luna. The recorded calls establish the direction; costs and scores are unchanged.Verification
Deployment and risk
No release, deployment or routing-default change. Analysis consumers should use
visiblePassFailuresfor the previous broad diagnostic;falseAcceptsnow requires an observed submission. Benchmark results concern two historical development tasks, not public endpoint quality or statistical superiority.