Remove WIP branch preservation and resume — 3 branches created in 1,999 runs, 0 resumes ever

[rssrn]

Summary

WIP preservation (preserve_wip → labro-wip/<run-id> branch → ai-handover label → resume via get_prior_wip_run) has never completed a single cycle in 1,999 runs. It spans ~68 references across 7 source modules, 7 test files and the dashboard. Proposal: remove it.

Usage data

Across 1,999 runs (98 non-skipped) in the published DB:

• 3 runs ever produced a wip_branch_url:

  run	repo	date	outcome
  daf88b12	birdbird	2026-08-11	failure
  3151100a	newschart	2026-08-04	failure
  2e985889	birdbird	2026-07-18	failure

  All three are the same opencode provider error — a dead agent, not interrupted work.

• 0 resumes, ever. prior WIP branch found appears 0 times in labro.log.

• ai-handover appears 0 times in the log — the human half of the handover loop has never been exercised.

• 3 orphan labro-wip/* branches are still live on GitHub: 2 in rssrn/birdbird, 1 in rssrn/newschart. None in rssrn/labro.

Two separate findings, worth keeping distinct

1. The feature is unexercised, not incoherent. The design is deliberate: partial → ai-handover label → comment saying "Remove the ai-handover label to re-queue this item" → the next run resumes from the branch. That is a sensible human-in-the-loop affordance. It has simply never been used. Removing it is a judgment call about whether we want the affordance, not a bug report.

2. Independently, it has a latent bug. preserve_wip fires on any non-success outcome, but store.get_prior_wip_run filters on partial only:

"SELECT wip_branch_url, summary FROM runs"
" WHERE item_url = ? AND outcome = 'partial' AND wip_branch_url IS NOT NULL"

All three real preserved branches are failure rows, so they were never eligible for resume. The failure-path half of the feature could not work even if someone did start removing labels. Fixing the bug would still leave a feature with 3 activations and 0 uses.

Why the agent already covers this

The three genuine partial runs (error_max_turns, issues 51/53/105) preserved nothing — and not because preservation failed: preserve_wip failed appears 0 times in the log, so those working copies were genuinely clean. Agents hold PUSH_DEFAULT and push their own branches; WIP preservation duplicates a capability the agent already has, and in practice the agent gets there first every time.

Scope

• Source (~68 wip references): cli.py (18), repo.py (18), post_run.py (12), store.py (8), prompt_builder.py (6), logger.py (5), agents/_subprocess.py (1), models.py.
• Dashboard: src/data/DataSource.ts:37, src/data/SqlJsDataSource.ts:121,165, src/components/RunDrawer.tsx:210-214, src/test/a11y.test.tsx:44.
• Tests: test_repo.py, test_cli_run.py, test_logger.py, test_prompt_builder.py, test_store.py, test_post_run.py, test_operator.py.

Decisions needed before implementing

1. Keep the wip_branch_url column. Stop writing it, but leave it in the schema and in the dashboard's read path so the 3 historical rows still render rather than breaking.
2. Decide the replacement behaviour for partial outcomes. post_run.py:340-410 currently routes partial to ai-handover + ai-contributed plus a handover comment. Removing WIP removes that path; something must still mark a partial run for a human.
3. Delete the 3 orphan labro-wip/* branches on rssrn/birdbird and rssrn/newschart as part of the cleanup — they are on public repos.

Keep one thing on the way out

Log a git status --porcelain diffstat on non-success outcomes. One log line, no branches, no schema — and it still answers the only question WIP preservation was ever asked: did the agent lose real work?

---

Related: #61 (clean checkout per run), #60 (crash handling and atomicity).

[rssrn]

Done in e9ac380, shipped as v0.18.0 and deployed to the host at 18:26Z on 2026-09-02.

Two corrections to the data above

The conclusion held, but two figures in this issue were wrong, and both were wrong in the same direction — they understated how active the feature was.

1. Four branches, not three. A fourth was created at 03:46Z on 2026-09-02, hours before this work started: run 843894cf on rssrn/newschart#110, outcome partial / error_max_turns — a genuine turn-limit run, not the opencode provider error the other three share.

It reinforces the case rather than undermining it. The branch held exactly one file, .pr110-comment.md, a 22-line scratch draft of the agent's dependency review — whose contents the agent had already posted in full to the PR thirteen seconds earlier. Preservation caught litter; the real work reached the PR under the agent's own steam, as it has every time.

2. ai-handover had been applied by live runs — three times in the last two days. The claim that it "appears 0 times" came from grepping labro.log, which doesn't record label writes. At the time of writing, three open PRs were parked with it: rssrn/newschart#110, rssrn/birdbird#61, #67 — all partial / error_max_turns on 2026-09-01 and 2026-09-02. Two of the three preserved no branch at all (clean trees — the agents had already pushed).

Note also that gh issue list and gh search issues exclude PRs, so a label check that only looks at issues will miss this. partial runs are running at roughly 3/month and rising.

So the accurate summary is: the harness half of the loop fired more often than recorded here, and the human half still never once completed — no run has ever resumed from a preserved branch, and no operator has ever removed ai-handover to re-queue. The three parked PRs had their labels removed by hand as part of this change.

What shipped

• Removed — repo.preserve_wip, the resume path (store.get_prior_wip_run, the wip_branch argument to prepare_repo, which now returns a plain Path), the resume section of the prompt, the ai-handover label and its two task-source exclusions, and the wip_branch_url / resuming_wip arguments of post_run and write_run.
• Decision 1 — kept the column. runs.wip_branch_url survives, nullable and never written, so the four historical rows still render in the dashboard.
• Decision 2 — partial is now an ordinary failure. The outcome value stays (it is agent-reported across all three providers, and keeps a cut-short run distinguishable in the dashboard), but on GitHub it gets ai-failed + ai-contributed and a comment naming the turn limit and the reason. This leaves Every claude-code run ends in error_max_turns, and partial stops the fallback chain before the third tier #65 cleanly separable.
• Decision 3 — branches deleted. All four orphans are gone; no labro-wip/* remains in any repo.
• Kept the one thing on the way out — repo.summarize_dirty_tree logs N uncommitted path(s) plus a diffstat on any non-success outcome, before the checkout is discarded.
• Also corrected the prompt's claim that the working copy is reused across runs — untrue since Clone the repo fresh for every run instead of reusing a persistent working copy #61.

Net −891 lines across 24 files: −268 in src/, −683 in tests/, +60 in docs/ (ADR-008 is 65 of those). wip/handover mentions across source, tests and dashboard: 285 → 40. Coverage held at 84.00%.

ADR-005 is superseded in part by ADR-008, which records the reasoning and the usage data.