detached-orphan lane has no merge_result guard: every parked merge anchor matches isDetachedHandoffOrphanCandidate and is re-stamped back into pool demand (gc-gf1l6)

[zook-bot]

Summary

isDetachedHandoffOrphanCandidate has no merge_result guard, so every
correctly parked merge anchor reads as a detached orphan and the lane
re-stamps gc.routed_to on it, converting a resting anchor back into pool
demand.

The collision

sweepDetachedHandoffOrphans's doc comment scopes it to a bead "fully
detached by a FAILED done sequence" — the worker cleared assignee and
gc.routed_to in one update because $REFINERY_TARGET resolved empty. The
predicate at cmd/gc/pool_detached_orphan_sweep.go:188 accepts on:

status == open
assignee empty
gc.routed_to empty
gc.run_target empty
gc.kind empty
gc.work_branch non-empty
gc.session_id or gc.session_name present

The gc-toolkit pack's merge cadence produces that signature on its SUCCESS
path. formulas/mol-refinery-patrol.toml merge-push parks the anchor with

lifecycle.sh transition "$WORK" --to pre_open_gate --assignee "" --route "" ...

precisely so the open, unassigned anchor is not pool demand; the branch is
already on origin, so gc.work_branch is set and the claim-time
gc.session_id/gc.session_name are still on the bead. Every parked anchor
is therefore a candidate, and the lane cannot tell a failed handoff from a
successful park — except by merge_result, the one field the predicate does
not read.

Cost, as seen from the pool

Reproduced on tk-iuquyk (gc-toolkit rig, PR gastownhall#503, merge_result=pull_request)
on 2026-08-27, twice, the second with no other write in between:

13:21:53 gc.routed_to cleared -> 13:22:02 restored to gc-toolkit/gc-toolkit.polecat
13:24:03 gc.routed_to cleared -> 13:24:55 restored to gc-toolkit/gc-toolkit.polecat

Both from tk.dolt_history_issues. The 9s and 52s latencies match
detachedOrphanLane's journal-keyed delta pass plus its hourly backstop.

At 13:47Z tk-iuquyk was in_progress under
gc-toolkit--gc-toolkit__polecat-2-pool: a polecat was offered, and claimed,
an anchor whose PR was already open and awaiting operator sign-off. Both
merge.sh and pr-facts.sh enumerate with --status=open, so for the
length of that claim the anchor was invisible to the merge cadence and could
not have landed. Two more anchors in the same rig (tk-bpo8cj, tk-d6ixcw) were
carrying the same re-stamped route at the same moment.

The same behaviour was reported in the gascity rig on 2026-08-20 (gc-zl5ta,
gc-zvffx: gc.routed_to verified cleared, read back as
gascity/gc-toolkit.refinery within ~1-9 minutes).

Fix

Add a merge_result guard to isDetachedHandoffOrphanCandidate: a bead
carrying ANY merge_result is out. That is the guard the gc-toolkit pack's
refinery find-work step already carries for the same reason
(formulas/mol-refinery-patrol.toml, marked block find-work-select,
"a bead with merge_result is driven by the cadence, never by find-work").

if strings.TrimSpace(b.Metadata[beadmeta.MergeResultMetadataKey]) != "" {
    return false // an anchor in the merge queue; the cadence drives it
}

Check whether beadmeta already exports that key constant; if not, the
literal is merge_result.

Note route_recovery.go:334 already carries a flap guard for this class of
fight ("another lane is clearing gc.routed_to — see gc doctor
route-recovery-quarantine"). The detached-orphan lane has no equivalent, but
a flap guard treats the symptom; the guard that belongs here is on
merge_result.

Test

Mirror the existing predicate tests: a bead with the full accept signature
plus merge_result=pre_open_gate is NOT a candidate, same with
merge_result=pull_request, and the signature with no merge_result still
IS one (the genuine failed-handoff case the lane exists to repair).

Pack-side backstop (already shipping)

zookanalytics/gc-toolkit tk-eh64m declares detached_states in
lifecycle/lifecycle.toml, has lifecycle.sh clear gc.routed_to on entry
to one, and adds an arm to doctor/check-state-space that errors on a parked
anchor carrying a pool route. That check currently reports the three beads
above; it goes permanently green once this guard lands, and it stays as the
regression gate. It does not prevent the re-stamp — only this guard does.

Refinery handoff

• Issue: gc-gf1l6
• Source branch: polecat/gc-gf1l6
• Target: main
• Codex signed off pre-open at a14ad669; PR opened codex-green.

[zook-bot]

Codex signoff (pre-open, comment-only — not an approval):

VERDICT: approve
Reviewed branch: polecat/gc-gf1l6
Reviewed base: main
Reviewed commit: a14ad66

Scope checked: Read the full three-dot diff from origin/main to the reviewed commit. Checked cmd/gc/pool_detached_orphan_sweep.go, cmd/gc/pool_detached_orphan_sweep_test.go, internal/beadmeta/keys.go, the shared detached-orphan delta call sites in cmd/gc/detached_orphan_lane.go, metadata-key conventions in internal/beadmeta, the anchor bead intent, prior notes on the anchor, and the operator profile. I did not run the full repo suite or dashboard gates because the diff is limited to cmd/gc and internal/beadmeta and does not touch API or dashboard surfaces.

Findings: None.

Verification:
go test -json ./cmd/gc -run 'DetachedHandoffOrphan|DetachedOrphan|detachedOrphan' -count=1 at the reviewed commit: 33 passed, 0 failed.
go test -json ./internal/beadmeta -count=1 at the reviewed commit: 44 passed, 0 failed.
git diff --check origin/main...a14ad66 passed.

Anchor: gc-gf1l6 — check.codex @ a14ad66