[F21] First-class cross-campaign code reuse: `derived_from`, cumulative patches, preserved branches

[sriumcp]

Problem

Each new campaign on the same target codebase rebuilds previously-validated implementations from scratch. There is no first-class mechanism for cross-campaign code reuse.

In paper-memorytime-mirage, iter-1 → iter-3 produced ~1900 lines of validated code (KV-time meter, GreedyKV scheduler, 6 baseline schedulers, runner binary). The implementations passed apparatus checks (zero conservation violations, correct VTC counter balance) — they're known correct. The prior campaign's worktree branches (nous-exp-iter-1-<id>, etc.) were torn down at completion. Only the patches/h-main.patch files survive in the work_dir.

Patches are incremental: iter-3's 20-line patch is a delta on iter-2's branch state, NOT a full diff vs main. So the surviving artifact is not directly applicable to a fresh main checkout without further archeology.

For the follow-up paper-memorytime-realistic-K campaign (which reuses 100% of the prior schedulers + meter, only changing workload + locked parameters), the campaign author had to:

1. Identify which iteration's patch was "the substantial one" (turned out to be iter-2's, 1852 lines).
2. Verify it applies cleanly to current main (it did, but had to be tested manually).
3. Skip iter-3's patch because it's incremental on iter-2 and fails to apply on top.
4. Bake git apply <iter-2-patch-path> into the new campaign's preflight_commands.
5. Manually re-add any iter-3 CLI flag extensions that didn't survive.

This is operator archeology that nous should automate.

Desired behavior

Concrete proposals (any subset would help; (1)+(2) is the minimal viable pair):

(1) derived_from block in campaign.yaml. Declares "this campaign inherits the worktree code state of :". nous resolves to the appropriate cumulative patch and applies as preflight automatically.

derived_from:
  campaign: paper-memorytime-mirage
  iteration: 2          # or "final"; nous figures out cumulative patch

(2) Cumulative patches. At iteration completion, nous emits both an incremental patch (delta from prior iteration) AND a cumulative patch (delta from main). Future campaigns reuse the cumulative trivially. Stored as patches/incremental.patch + patches/cumulative.patch per iteration.

(3) Preserved branches. Keep nous-exp-<campaign>-iter-<N> branches alive after campaign completion. Future campaigns can git worktree add -b new-branch <prior-campaign-iter-N-branch> for direct lineage. The branch becomes a canonical archival artifact.

(4) nous lineage <campaign> command. Surfaces lineage / rebase relationships. "Campaign A's iter-2 code applied to current main" should be a one-command operation, not manual patch archeology.

Suggested implementation sketch

1. After EXECUTE_ANALYZE produces an incremental patch, also produce a cumulative-from-main patch (just git diff main..nous-exp-iter-N-<id> and write it). Store as patches/cumulative.patch.
2. Add derived_from to campaign schema.
3. At INIT, if derived_from is set, apply the resolved cumulative patch as a preflight step (or insert it into the bundle's preflight_commands automatically).
4. Add a lineage subcommand to surface relationships.
5. Optionally: a CLI flag controlling branch retention policy after campaign completion.

Acceptance criteria

• Each iteration emits both incremental.patch and cumulative.patch.
• derived_from is documented in campaign schema and applied automatically at INIT.
• nous lineage <campaign> surfaces inheritance relationships.
• Optional: a flag preserves experiment branches across campaign completion.
• Friction report F21 row in the tracking issue checks off.

Severity

HIGH — every multi-campaign nous research project pays this cost; addressing once at framework level saves substantial campaign-author time and reduces re-implementation drift.

Source

friction-report.md F21, paper-memorytime-mirage campaign (2026-05).

---

Part of friction-report tracking issue #245.