codex-fuse-mode

name

codex-fuse-mode

description

Use when Codex should apply CodexFuseMode / code_fuse / codex_fuse: generate or compare C0/C1/F1 candidates with fresh Codex CLI invocations, run a second independent Codex attempt, synthesize F1 through review-and-fusion from two candidates, select by the default blind Best(C0,C1) then F1 strict-challenge judge policy, or handle real workspace implementation with candidate isolation and final-only patch application.

Codex Fuse Mode

CodexFuseMode is a conservative candidate-pool workflow:

C0 = baseline answer or patch
C1 = second independent Codex answer or patch
F1 = review&fusion(C0, C1), first auditing both candidates, then combining real strengths while avoiding weaknesses
winner = conservative blind judge selects Best(C0,C1), then allows F1 only as a strict challenger

Report the concrete candidate winner (C0, C1, or F1). Do not report only a condition name such as codex_fuse.

Default CodexFuseMode is judge-only: F1 and Judge do not see verifier rewards, hidden tests, post-hoc benchmark scores, or generated test results. Verifier-first and EvidenceBest are explicit opt-in variants only.

Default study flow:

Task
  -> C0: single-baseline Codex answer
  -> C1: second independent Codex answer

C0 + C1 + task context
  -> F1: review-and-fusion

C0 + C1 + F1
  -> blind judge final

Default blind judge policy:

1. Anonymize C0/C1/F1 as A/B/C.
2. Judge must not know which label is C0, C1, or F1.
3. Judge must not see verifier reward, hidden tests, generated tests, or candidate origins.
4. Judge first audits every candidate independently.
5. Judge first selects Best(C0, C1) from the anonymous base-pool labels.
6. F1 then challenges Best(C0, C1).
7. Select F1 only if it clearly and strictly dominates Best(C0, C1); otherwise keep Best(C0, C1).

Codex CLI Session Isolation

Hard rule: C1, F1, and model Judge must be fresh Codex CLI invocations, normally codex exec.

C0 = current session or baseline Codex CLI result
C1 = fresh codex exec, task context only, must not see C0
F1 = fresh codex exec, sees task + C0 + C1 only by default, and performs review before fusion
Judge = fresh codex exec when model judgment is used, sees only task + anonymized candidates

Do not generate C0, C1, F1, and Judge by continuing one conversation. That collapses the mode into single-session self-revision and invalidates independence.

For model judgment, anonymize candidates as A/B/C or X/Y/Z. The judge must not know which candidate is baseline, second sample, or fusion.

Mode Choice

Use Answer Mode for analysis, design, code snippets, or eval tasks where candidates are text artifacts.

Use Workspace Mode for real repository changes. In Workspace Mode, candidates are isolated patches until a winner is selected.

Skip this skill for tiny deterministic edits where one direct implementation is clearly sufficient.

Answer Mode

1. Produce C0 as the best direct answer.
2. Produce C1 with a fresh codex exec that sees only the task. Do not ask C1 to review C0.
3. Produce F1 with a fresh codex exec using the review-and-fusion prompt below. The review is an internal precondition of F1, not a separate candidate.
4. Judge C0, C1, and F1 with the conservative two-stage selector below and anonymized candidates. Do not use verifier or generated-test evidence unless explicitly requested.
5. Return the winning candidate and a short tally:

candidate_winner: C0 | C1 | F1
C0 meaning: baseline was best
C1 meaning: second sampling improved the result
F1 meaning: fusion added value beyond sampling

Workspace Mode

Hard rule: never run multiple implementation candidates against the same dirty workspace.

Use this workflow for repository edits:

1. Inspect git status --short --branch and relevant files before producing candidates.
2. Keep C0, C1, and F1 isolated:
   • Prefer patch-only artifacts, separate git worktrees, temporary copies, or dry-run diffs.
   • Generate C1 with a fresh codex exec in an isolated workspace or patch-only prompt.
   • Generate F1 with a separate fresh codex exec from C0/C1 diffs and evidence; F1 must review C0/C1 before changing files, then fuse.
   • Do not let C1 overwrite C0 changes in the main workspace.
   • Do not apply F1 directly to the main workspace before selection.
3. For each candidate, record:
   • changed files or intended patch;
   • tests/checks run;
   • failures, risks, and assumptions.
4. Build F1 from the diffs and evidence of C0/C1 through review-and-fusion, not by blindly concatenating them.
5. Select the winner with the conservative two-stage judge below. Use verifier-first or EvidenceBest only when explicitly requested.
6. Apply only the winner patch to the main workspace.
7. Before applying, re-check git status and avoid overwriting user changes.
8. After applying, run the smallest relevant verification.
9. Remove or ignore non-winning candidate artifacts unless the user asks to keep them.

Review-And-Fusion Prompt

Use this structure for F1:

You are the review-and-fusion model in CodexFuseMode.

Your job is to produce F1 through two required stages:
1. Review C0 and C1 against the task before changing the artifact.
2. Fuse the useful parts into one complete final artifact.

Privately inspect:
- the task contract and required output shape;
- C0 strengths and risks;
- C1 strengths and risks;
- conflicts between C0 and C1;
- edge cases likely to be tested.

Rules:
- Treat review as an internal precondition of F1, not a separate candidate.
- Preserve the task's expected output format.
- Prefer correctness and robustness over style.
- Do not add unsupported features.
- Do not introduce a new abstraction unless it removes a real defect.
- If C0 and C1 disagree, choose the behavior best supported by the task prompt.
- If neither candidate is clearly improvable, return the stronger candidate
  with only minimal safe fixes.
- Return only the complete final artifact F1.

Task:
{task}

Candidate C0:
{c0}

Candidate C1:
{c1}

EvidenceBest

When the task can support tests or executable checks, upgrade Best(C0, C1) from pure patch reading to evidence-assisted selection.

Preferred order:

Task/public context -> task-only TestGen -> approved tests/checks
C0/C1 run independently
C0/C1 are checked against the same approved tests
Best(C0, C1) uses this evidence before visual patch preference
F1 review-and-fusion sees C0/C1 plus approved C0/C1 evidence
F1 must run the same checks
Final keeps Best(C0,C1) unless F1 strictly dominates it

Evidence rules:

• Task-only/public/generated tests are advisory evidence, not official benchmark reward.
• Do not use hidden tests, verifier reward, candidate origins, or post-hoc benchmark scores unless the user explicitly asks for verifier-first selection.
• Generated tests must not be committed into the candidate patch. Apply them transiently, run them, then clean them from the workspace.
• Record provenance for every evidence item: public, task_only_generated, candidate_adversarial, model_validated, or manual.
• Candidate-generated tests are biased by default. Use them as adversarial suggestions only after a separate TestJudge rejects invalid, overfitted, or implementation-specific tests.
• If evidence is invalid, flaky, or inconclusive, downgrade it and fall back to the conservative judge.

EvidenceBest selector:

if C0 passes approved evidence and C1 fails:
    base = C0
elif C1 passes approved evidence and C0 fails:
    base = C1
else:
    base = blind Best(C0, C1)

if F1 passes evidence that base fails, or fixes a concrete audited defect while preserving base-passing behavior:
    Final = F1
else:
    Final = base

For DeepSWE-style runs, the local runner supports this through advisory evidence inputs:

python -B scripts/run_deepswe_codefuse_eval.py `
  --task-path <task> `
  --evidence-best `
  --evidence-test-patch <task-only-test.patch> `
  --evidence-test-command "<test command>"

The generated/public test patch is applied only for checking and is cleaned before final patch capture.

Judge Rule

Default judge-only selection:

base = blind Best(C0,C1)
if F1 clearly and strictly dominates base:
    choose F1
else:
    choose base

Verifier-first selection is an opt-in variant for evaluation or deployment settings where reliable verifier evidence is intentionally allowed:

if tests/verifier clearly separate C0/C1/F1:
    choose verifier winner
elif EvidenceBest clearly separates C0/C1:
    choose Best(C0,C1), then allow F1 only as strict challenger
else:
    use default judge-only selection

When a model judge is needed, run it as a fresh codex exec. Anonymize candidates as A/B/C; do not expose which label is baseline, second sample, or fusion. The judge may be told which two anonymous labels form the base pool and which anonymous label is the challenger, but it must not be told their real identities.

task
anonymous Candidate A/B/C
base-pool labels, e.g. A and C
challenger label, e.g. B

Do not pass verifier rewards, candidate origins, generation order, or the fusion rationale to the judge unless the user explicitly asks for verifier-first selection.

For judge-only selection, use this conservative two-stage policy:

1. Audit every candidate independently:
   - explicit requirement coverage;
   - likely compile/runtime failure;
   - public API or compatibility breakage;
   - unrelated broad rewrites;
   - missed edge cases likely to appear in hidden tests.
2. Blind pairwise select Best(C0, C1) from the two base-pool labels.
3. Let F1 challenge Best(C0, C1).
4. Select F1 only when it strictly dominates Best(C0, C1):
   - preserves the base winner's correct behavior;
   - fixes a concrete defect or missing edge case;
   - adds no material compile/API/behavior risk.
5. Otherwise keep Best(C0, C1).

In other words, F1 has the burden of proof. Never choose F1 merely because it is longer, more polished, more comprehensive-looking, or synthesized.

Ask the model judge to return structured fields:

winner_label
runner_up_label
base_pairwise_winner_label
base_pairwise_runner_up_label
f1_challenge_winner_label
f1_strictly_dominates_base
f1_challenge_confidence
candidate_audits
scores
fail_reasons
rationale

For code tasks, weak static checks are not enough to claim correctness. Label them as advisory. Prefer executable tests, type checks, linters, or benchmark checkers when available.

Report Format

Use this concise report:

CodexFuseMode result
- candidate_winner: C0 | C1 | F1
- winner_meaning: baseline | second_sample | fusion
- verifier: passed/failed/not_run
- judge_confidence: ...
- C0 risks: ...
- C1 risks: ...
- F1 risks: ...
- applied_to_workspace: yes/no
- verification: command + result

If running a batch, aggregate by concrete candidate:

C0 wins: n
C1 wins: n
F1 wins: n

Interpretation:

C0 wins -> extra calls did not help
C1 wins -> sampling helped
F1 wins -> fusion helped beyond sampling