Ask
decide() (the spawn selector seam, e.g. bip's BipSubagentSpawnSelector) returns before the journal's spawn_subagent_{invocation,batch} lease CAS runs. The CAS outcome — committed, failed, cancelled — is not observable from the selector, so any admission-time reservation (bip's per-issue work claims, unit reservations) cannot release or transfer ownership based on the true spawn result.
Concrete need: a post-CAS callback/notification to the selector (or an awaitable spawn-outcome handle returned from decide()) carrying {child ids, outcome} per accepted slot.
Why (evidence from bipa-app/bip#576, codex-gate rounds 8-10)
bip added an atomic per-Linear-card claim at spawn admission to prevent duplicate workers on one card. Three review rounds iterated on the claim lifetime and each ended at the same wall:
- Guard disarmed at commit → claim absent during the admission→bind window (SDK calls the CAS after decide() returns) → concurrent same-card spawn double-admits.
- Guard never disarmed → an unobservable CAS failure/cancellation strands the claim until daemon restart.
- Current compromise: transfer-to-store + 5-minute lease self-heal — sound but approximate; the lease bounds the damage of the unobservable failure rather than eliminating it, and crash-ordering interactions (orphan reconciliation vs fresh admissions) remain.
The reviewer's terminal finding and the lane's own conclusion agree: ownership semantics cannot converge while the spawn outcome is invisible at the seam that takes the reservation.
Related: this is adjacent to the existing daemon-side orphan reconciliation; a spawn-outcome signal would also let reconciliation seed accepted-orphan ownership before serving new admissions.
Filed from the wave-4 codex-gate program (bip PR #576 / ENG-9023).
Ask
decide()(the spawn selector seam, e.g. bip'sBipSubagentSpawnSelector) returns before the journal'sspawn_subagent_{invocation,batch}lease CAS runs. The CAS outcome — committed, failed, cancelled — is not observable from the selector, so any admission-time reservation (bip's per-issue work claims, unit reservations) cannot release or transfer ownership based on the true spawn result.Concrete need: a post-CAS callback/notification to the selector (or an awaitable spawn-outcome handle returned from decide()) carrying {child ids, outcome} per accepted slot.
Why (evidence from bipa-app/bip#576, codex-gate rounds 8-10)
bip added an atomic per-Linear-card claim at spawn admission to prevent duplicate workers on one card. Three review rounds iterated on the claim lifetime and each ended at the same wall:
The reviewer's terminal finding and the lane's own conclusion agree: ownership semantics cannot converge while the spawn outcome is invisible at the seam that takes the reservation.
Related: this is adjacent to the existing daemon-side orphan reconciliation; a spawn-outcome signal would also let reconciliation seed accepted-orphan ownership before serving new admissions.
Filed from the wave-4 codex-gate program (bip PR #576 / ENG-9023).