gc session wake/nudge: a live named session conflicts with ITSELF, making the alias unreachable (gc-h4s93)

[zook-bot]

Summary

Defect

`gc session wake`/`gc session nudge` cannot address a named session that is
alive, active and running. Resolution fails with a self-referential conflict:

gc session wake: resolving configured named session "gascity/gc-toolkit.refinery":
  configured named session conflict: "gascity/gc-toolkit.refinery" conflicts with
  configured named session "gascity/gc-toolkit.refinery" via live bead lx-fp9dj

The name on both sides of "conflicts with" is identical. The live bead it names
(lx-fp9dj) IS that session: title "gascity/gc-toolkit.refinery", status open,
created 2026-08-17T17:36:02Z. gc session list --state all shows the session
as state=active running=true.

So the resolver finds the correct, unique, live session bead for the alias and
then treats that match as a competing entry rather than as the answer. Nothing
else claims the name -- this is not two sessions racing for one alias.

Impact

Every mol-polecat-work handoff ends with step 7 of submit-and-exit:

gc session wake "$REFINERY_TARGET" || true
gc session nudge "$REFINERY_TARGET" "Run gc prime to check merge queue..."

Both fail for the gascity refinery. The formula marks them non-fatal (|| true)
and the gc bd update in step 6 still emits bead.updated, so work is not lost
-- the refinery picks it up on event-watch or its next poll. But the immediate
signal is gone for every polecat in this rig, so each handoff now waits up to
event_timeout instead of starting at once. It is a silent latency regression
in the merge queue, invisible because the failure is swallowed by design.

It also removes the only lever for waking a stopped on_demand refinery, which
is the case || true was never meant to cover.

Reproduce

gc session list --state all --json | jq ".sessions[] | select(.alias|test(\"refinery\"))"
gc session wake gascity/gc-toolkit.refinery

Observed 2026-08-19T16:5xZ from polecat gc-toolkit.furiosa while handing gc-x1a87
to the refinery. All three rigs (gascity, gc-toolkit, shutupandlisten) show an
active refinery session; the conflict was observed on the gascity one.

Where to look

Named-session resolution -- the path that maps a configured named session to a
live session bead and raises configured named session conflict. The bug is
almost certainly a missing identity check: the candidate bead is not excluded
from the conflict set when it is the very session being resolved, so a
single live match is counted as two.

Related but distinct, so do not conflate: gc-5fdrr (a CLOSED session bead
permanently reserves its alias, landed as f475b68). Here the bead is OPEN and
the session is running -- the reservation is not stale, it is self-colliding.

Acceptance

gc session wake and gc session nudge address a live named session by its
configured name. A conflict is raised only when two DISTINCT live session beads
claim one alias, with a regression test covering the single-live-session case
that fails today.

Implementation notes

Recurrence evidence (ported from gc-bwcd8, folded here 2026-08-21, visit gc-qcvca)

Confirmed NOT a stale-bead artifact — two observations naming DIFFERENT live
session beads for the same alias:

2026-08-19T16:5xZ — conflict named live bead lx-fp9dj (this bead's own filing)
2026-08-20T09:0xZ — conflict named live bead lx-fp9dj (gc-bwcd8)
2026-08-20T11:0xZ — conflict named live bead lx-npl7f (gc-bwcd8)

The refinery session was RECYCLED between the 09:0x and 11:0x observations, so a
FRESH session bead reproduces it immediately. That rules out "one leftover
duplicate bead needs cleaning up" and points squarely at the resolver treating
the target's OWN live session bead as a competing claimant.

Both times the session was healthy (state=active running=true) and the handoff
itself completed (bead reassigned, branch pushed and verified); only the
belt-and-suspenders wake+nudge was lost.

gc-bwcd8 also names the mirror-case precedent: f475b68 (gc-5fdrr) fixed a
CLOSED session bead permanently reserving its alias. This is NOT that fix — here
the bead is open and the session is running, so the closed-bead release lever
does not apply.

Classification (visit gc-qcvca, merge-base ed267ad)

cmd/gc/session_resolve.go:77 and internal/api/session_resolution.go:233 raise the
message. BOTH files are fork-UNTOUCHED and upstream-STATIC since merge-base —
neither side has changed them. Genuine upstream defect in code nobody is moving:
a fix here carries essentially zero rebase-conflict risk. upstream_pr_candidate.

Correction — converse sitting 2026-08-22T14:2xZ (visit gc-qcvca, 3rd sitting). Verified independently, three findings.

1. UPSTREAM HAS ALREADY FIXED THIS. Do not author a fork fix.
upstream commit 08461bb "fix(session): recognize unique alias owner as
canonical (gastownhall#5487)", Jim Wordelman, 2026-08-21T22:11Z. Its own summary is this
bead verbatim: "Configured named sessions can now recognize their own live
session when the session is reachable only through its configured alias. After
a named session starts, commands such as gc mail send no longer report
that sole legitimate session as conflicting with itself." It fixes both the
bead-backed CLI lookup and the Info-shaped API lookup, and preserves true
collisions as errors. Our fork does NOT have it.
Standing operator decision (this subject, visit 5) applies directly: a
cherry-pick of an existing upstream commit is near-zero cost at rebase and is
ALWAYS preferred over authoring our own fix for the same defect.

2. The patch site named in "Where to look" is not where the logic lives.
Earlier triage recorded cmd/gc/session_resolve.go and
internal/api/session_resolution.go as blob-identical across merge-base / fork /
upstream with zero commits either side. That is TRUE and it is IRRELEVANT:
neither file decides canonical-vs-conflict. Both only re-raise the error that
session.LookupConfiguredNamedSession returns
(cmd/gc/session_resolve.go:77, internal/api/session_resolution.go:233).
The decision is in internal/session/named_config.go — FindCanonicalNamedSessionBead
vs FindNamedSessionConflict / BeadConflictsWithNamedSession. That file is
fork-clean (0 commits ours) but carries the 1 upstream commit above, so its blob
differs from upstream. The "zero divergence either side" reading did not cover
the file that actually needs the change.

3. It does NOT reproduce today, and that is not a fix.
2026-08-22T14:2xZ: gc session wake succeeded, exit 0, no conflict, on all three
LIVE named refinery sessions (gc-toolkit, shutupandlisten, signal-loom
/gc-toolkit.refinery). gascity has no live refinery session, so the original
2026-08-19 target could not be retested in its original state.
The code is unchanged in our fork (0 commits ours on every file that emits
"configured named session conflict"), so the defect is LATENT, not cured: per
gastownhall#5487 it fires when a session is reachable ONLY through its configured alias
(no corroborating canonical metadata). Today's session beads are not in that
state. Do not close this as no-longer-reproducing.

Implemented 2026-08-22 (polecat gc-toolkit.nux, branch polecat/gc-h4s93)

Resolution: CHERRY-PICK of upstream 08461bb ("fix(session): recognize unique
alias owner as canonical", PR gastownhall#5487), per the correction recorded in this
bead's notes and the standing operator preference for importing an existing
upstream commit over authoring a fork fix.

Commit: 836e928 (upstream authorship preserved; -x provenance trailer kept;
subject re-titled to carry the bead ID per repo convention).

Applied cleanly, ZERO conflicts, no fork-side adaptation. Both
internal/session/named_config.go and internal/session/named_config_test.go were
verified byte-identical to the upstream commit's parent before the pick, and
the fork has 0 commits on either file since merge-base ed267ad. Third file is
the upstream release-gate doc, carried verbatim into release-gates/.

What it does: adds an alias-based canonical pass to BOTH
FindCanonicalNamedSessionBead (bead-backed CLI lookup) and
FindCanonicalNamedSessionInfo (Info-shaped API lookup), keeping the two paths
symmetric. The pass still requires the existing liveness + continuity checks
and a matching named-session template/spec, and promotes only when EXACTLY ONE
template-matching alias candidate qualifies -- so a genuine two-session
collision still falls through to conflict detection, and a reserved-name decoy
with no corroborating template metadata is not promoted.

ACCEPTANCE MET -- verified by inverted-fix test, not just by a green run:
with the fix -> all 5 new regression tests PASS
source reverted to base, new tests kept -> the 3 single-live-session cases FAIL:
TestFindCanonicalNamedSessionBead_AliasSoleLiveCandidateIsCanonical
TestFindCanonicalNamedSessionInfo_AliasSoleLiveCandidateIsCanonical
TestLookupConfiguredNamedSession_AliasOnlyLiveBeadResolvesCanonical
The 2 true-collision guards pass in both states, as intended.
This confirms the tests cover the reported defect and the fix is not inert.

Gates run (this rig configures NO test/lint/build commands, so these were run
by hand):
go build ./... PASS
go vet ./internal/session ./internal/api ./cmd/gc PASS
go test -race ./internal/session/ PASS (10.6s)
go test ./internal/api/ PASS (100.2s) [consumer]
go test ./internal/dispatch/ PASS [consumer]
go test ./cmd/gc/ -run Named PASS (targeted; never bare -- 6 shards)
gofmt clean

Push gate: .githooks/pre-push would have run make test-fast-parallel, but the
shared rig repo sets core.hooksPath=/dev/null so NO hook fires for any agent
here. Ran the gate manually instead: 9/10 jobs green. The one failure
(unit-core) was TestClientMailListAllRigsMultipleStoreSlowReturnsTyped503BeforeClientTimeout,
proven UNRELATED to this diff -- with -coverpkg=./internal/session/ that test
executes 0 of 260 coverage blocks in the changed file (6 of 4373 statements in
internal/session overall), and it passes 10/10 standalone. It is a 100ms-vs-250ms
scheduling-margin flake under parallel load.

Filed while here (both out of scope for this branch, neither fixed):
gc-38ko9 (P2) flaky: ...StoreSlowReturnsTyped503BeforeClientTimeout under
full-suite parallel load (internal/api)
gc-w89av (P1) Found: core.hooksPath=/dev/null in the shared gascity rig repo
disables the pre-push test gate for EVERY agent -- a strictly
larger hole than gc-01o2l/gc-uz8az, and it defeats their fixes
(incl. TestPrePushAnnouncesEverySkip), since the hook is never
executed at all. Needs an operator decision on intent.

Reviewer note: the alias lookup now runs BEFORE the !includeConflict early
return, so lookupConfiguredNamedSession issues one additional
listConfiguredNamedSessionBeadsByMetadata("alias", ...) store call on the
non-conflict path. That is upstream's deliberate shape (the canonical pass must
run regardless of includeConflict) and was kept unmodified.

Refinery handoff

• Issue: gc-h4s93 (bug, P1)
• Source branch: polecat/gc-h4s93
• Target: main
• Codex signed off pre-open at 5d260bdd; PR opened codex-green.

[zook-bot]

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

VERDICT: COMMENT
Reviewed branch: polecat/gc-h4s93
Reviewed base: main
Reviewed commit: 5d260bd

Scope checked: full diff for internal/session/named_config.go, internal/session/named_config_test.go, and release-gates/ga-rcroz7-named-session-alias-canonical-gate.md; anchor bead gc-h4s93 and prior review gc-adxqr; resolver call sites in cmd/gc/session_resolve.go, cmd/gc/named_sessions.go, internal/api/session_resolution.go, and internal/dispatch/control.go; session creation metadata in internal/session/manager.go; upstream equivalence against 08461bb for the first cherry-pick commit; rework delta from 836e928 to 5d260bd.

Findings:
P2 - internal/session/named_config_test.go:723: the new alias-canonical helper tests construct NamedSessionSpec without Agent/Named and create alias-only candidates without template or agent_name metadata, so NamedSessionBeadMatchesSpec succeeds through empty backing-template equality. Production callers checked in this review derive specs from config and session creation persists template metadata, so this is not a blocking runtime defect, but a stronger regression test should include a backing template on the spec and matching template/agent metadata on the candidate to pin the advertised corroboration gate.

Verification:

• git diff --check origin/main...5d260bd -> PASS (no output)
• go test ./internal/session -run 'TestFindCanonicalNamedSession(Bead|Info)_Alias|TestLookupConfiguredNamedSession_AliasOnlyLiveBeadResolvesCanonical' -count=1 -> PASS (0.049s)
• go test -race ./internal/session/ -count=1 -> PASS (9.746s)
• go test ./internal/api -run 'Session|Resolve|Named' -count=1 -> PASS (30.119s)
• go test ./cmd/gc -run 'Named|SessionResolve|SessionWake|Nudge' -count=1 -> PASS (19.866s)

Not checked: full repository matrix; this signoff focused on the changed session resolver package, direct CLI/API consumers, the release-gate diff-check regression, and the prior P1 rework.