Pre Merge

No experiment main.rs files on the branch → nothing to do (empty set, not a skip).

Phase 3: Data freshness

For experiments with committed data (.jsonl, .csv), compare code and data commit dates:

git log -1 --format='%H %ci' -- experiments/<topic>/<experiment>/main.rs
git log -1 --format='%H %ci' -- experiments/<topic>/<experiment>/*.jsonl

If code is newer than data, regenerate on this branch.

Phase 4: Review

Use the reviewer subagent plus $review. Launch separate reviewer instances for independent review surfaces, not separate agent definitions for every file type.

Default review surfaces:

If a surface has no files in scope, record "no files in scope" in the local notes. Do not launch an empty reviewer solely to prove the absence.

Cross-check subagent findings

Before including any finding in the report to Jörn, read the file at the location the subagent references and confirm the finding matches what the code or text actually says.

Verify with priority:

1. Cost-benefit recommendations the subagent made — subagents lack context for cost-benefit judgments about the larger task. Severity ratings (FIX vs FLAG) reflect the subagent's limited view: it may escalate minor issues or downplay significant ones.
2. Interpretive conclusions where the subagent inferred meaning from limited context — e.g., "this lemma is orphaned" (may be used by other modules) or "this reference dangles" (may resolve through formal/main.tex or formal/library/main.tex).
3. Specific claim types: "dangling reference" → check if it resolves through the relevant formal or thesis build. "Orphaned lemma" → check if used elsewhere or is standalone valid math. "Missing entry" → check TASKS.md, RESULTS.md, or the relevant research note for a known gap before treating it as newly discovered.

A verification subagent can cross-check the combined findings when the task has high blast radius or the first reviewer reports subtle findings.

The Phase 8 report contains only verified findings, not the review/cross-check process.

Phase 5: Sanity check

• Goal alignment: Re-read the original task prompt. Does the work produced actually serve that goal? Does it make sense for the thesis project roadmap? A misunderstood goal that produces technically correct but wrong-direction work is expensive to discover late.
• Process compliance: Work is on a worktree branch, not main. Explicit instructions from the task prompt were followed (branch naming, scope restrictions, etc.).
• Project context: Check TASKS.md — does this work correspond to a tracked task? Is the experiment still active (not superseded by another experiment)?

Phase 6: Update TASKS.md

• Mark completed tasks as done (move to Completed section with date and one-line summary)
• Update status and next-steps for tasks affected by this work
• Add newly discovered tasks
• If no updates are needed, state that explicitly in the report ("TASKS.md: no changes needed")

Phase 7: Full experiment runs (optional)

If experiment binaries were created or substantially modified, and Phase 4 review found issues that were fixed, run again with representative input to confirm fixes. Report results.

This phase is optional. Run it when experiment binaries were created or substantially modified in this branch.

Phase 8: Report to Jörn

Structure:

1. What changed — files, scope, one-paragraph summary
2. Build/test results — which commands passed, any issues fixed during Phase 1
3. Review findings — verified findings from Phase 4 subagents (after cross-check)
4. Needs Jörn — decisions, unresolved % [TODO: JÖRN items, things only Jörn can verify
5. TASKS.md changes — what was updated, or "no changes needed"
6. If work is incomplete: write a handoff to handoffs/<name>.md

Merge Conflicts

When resolving conflicts during integration, choose the content that is true for the current repository state and project conventions. Do not use timestamp, branch side, author, or apparent task ownership as a shortcut for deciding which side wins.

For each conflicted hunk, identify the claim or behavior each side represents, check the surrounding files or commands when needed, then keep or combine the parts that preserve current mathematical statements, live paths, task status, and build behavior. If neither side is clearly correct, stop and ask Jörn with the concrete hunk and the missing decision.