Choosing among repair approaches

Use ce-bakeoff to develop competing repairs when the cause is confirmed, the intended behavior and current design remain settled, and a consequential repair choice is still open. Automatic use requires materially different mechanisms that need development before comparison, a costly reversal, and tradeoffs that available direct evidence cannot settle. Otherwise continue ordinary diagnosis and fix selection. A user-requested comparison can waive the cost threshold, but cannot reopen settled decisions or substitute for causal evidence.

Prefer a discriminating probe when it can settle the choice. Several fixes passing the reproduction check establishes neither their equivalence nor a reason to run a competition. Already-developed alternatives need judgment, not further generation. When correcting the cause requires changing the design or intended behavior, use Phase 2's existing design/defer boundary.

In interactive mode, run an eligible Bake-off without adding a permission gate. In mode:pipeline and mode:return-to-caller, it is off by default to bound nested work; run it only when the caller explicitly authorizes the comparison within its budget. A general instruction to fix the bug or an overall run budget is not that opt-in. Skipping Bake-off does not make a convergent technical choice a human decision.

Invoke ce-bakeoff with the confirmed causal chain and source evidence, reproduction check and results, intended contracts, prior failed approaches, open repair question, scope, and budget. Request repair sketches and preserve the user's model and provider restrictions. Bake-off owns candidate dispatch, assessment, and synthesis under its existing authority; this handoff grants no new recipients or implementation scope.

Resume Phase 2 by checking the returned repair against the confirmed cause, intended contracts, and scope. A selection label or candidate agreement cannot establish a required guarantee: if the repair leaves one unsupported, report that gap rather than adopt the winner. Carry a supported mechanism, its decisive tradeoffs, and implementation verification needs into the proposed fix. Preserve incomplete or unresolved results; continue only when the available evidence independently supports a safe repair, otherwise use the current mode's existing blocker or deferred-result contract. Do not invent a winner or a new return status. Phase 2 still owns whether a fix may proceed, and Phase 3 still verifies it with the regression and reproduction checks.