fix(gjc-runtime): fence continuation dispatch and repair the memory-guard split marker

[twoimo]

Thank you for the detailed review on #3595. Both P1 blockers you identified are repaired in this successor, and I want to be explicit about the causality I found for each, since in both cases the defect was slightly different from what the failure name suggested.

P1 (1) — a public authority-changing operation dispatched no continuation argv

You were right that this was a real production gap, not a flaky test. The mechanism:

continueStalledGjcTeamWorkers writes the attempt reservation under the task-store lock, releases that lock, and only then revalidates continuation eligibility before send-keys. That leaves an unguarded window. pruneTeamWorkerGcRecord — a claim-releasing operation — could land inside it, delete the claim record, and the subsequent revalidation would correctly observe "no current claim" and journal the incident skipped with zero dispatches.

The repair is the fence-hold restructure the previous PR body deferred:

• Revalidation plus send-keys now runs inside withGjcTeamMutationFence, the same fence every other public authority-changing operation already takes. Claim mutation and dispatch are now mutually exclusive.
• The fence is released before the ACK wait. This matters: the ACK is published by a separate receiver process that must acquire the same cross-process fence, so holding it across the wait would deadmine the very ACK being awaited. Your existing test allows a spawned receiver CLI ACK while continuation waits outside the mutation fence pins that contract, and it stays green — I verified an earlier, coarser version of this fix that held the fence across the whole pass, and it broke exactly that test, which is what pointed me at the correct boundary.
• pruneTeamWorkerGcRecord now also takes the fence, since it deletes claim records and rewrites claimed tasks.

The fence closure returns a typed outcome (skipped / dispatched / threw) so the post-fence code paths stay explicit rather than reading mutated outer state.

P1 (2) — replacement settled before pane-launch ACK

This one turned out to be a test-fixture regression introduced by this PR's own rewrite of createFakeTmuxBin, and I am glad you held the line on it, because the red was genuine.

The predecessor shell-based fake wrote a 3-field marker to tmux-last-split on every split-window. The rewritten TypeScript fake updated only countPath and dropped that marker write entirely. The memory-guard replacement test waits on that exact marker to know a successor pane was launched before it publishes the generation-bound worker-startup-ack. With the marker never written, the ACK never arrived, relaunchWorkerPaneForMemoryGuard hit its startup deadline, and the guard reported retrying — precisely the symptom in your CI log. Restoring the marker write fixes it.

I also fixed a separate structural bug in that same test that made it unrunnable on non-Linux hosts: it aborted the split-marker waiter and then awaited it before reaching its own process.platform !== "linux" early return, so the rejected waiter masked the advisory outcome. The platform branch now cancels and swallows the waiter first.

Verification

packages/coding-agent/test/gjc-runtime/team-runtime.test.ts on this exact head, rebased onto current dev:

116 pass / 1 fail   (was 114 pass / 3 fail before these repairs)

The three cases you flagged or that I repaired are individually green:

holds every public authority-changing operation behind the monitor dispatch fence   pass
allows a spawned receiver CLI ACK while continuation waits outside the mutation fence   pass
selects the hottest Linux worker, checkpoints it, and syncs config and manifest on replacement   pass

One honest caveat, stated plainly rather than buried: the single remaining local failure is requires exactly one current claim and rejects shutdown, draining, lease, and pane authority gaps, which exceeds its explicit 20s cap on my macOS host. It is not in your CI failure set (your run showed 115/2 with only the two P1s), it timed out identically on my very first baseline run before I made any edits, and its scenario list is byte-identical between dev and this head — so I believe it is host slowness from 13 sequential git-repo fixtures, not a logic regression. I did not touch it, and I would rather flag it than quietly claim a fully green shard.

Scope note

This branch carries no dependency on the reverted #3489. acquireManagedLockSync and ManagedStorageLockSync do not appear anywhere in it — the head commit explicitly enforces psmux authority migration exclusion without the managed sync lock, and persistGjcTmuxProviderAuthoritySync is defined within this branch's own tmux-provider-context.ts. I have also not opened any competing branch against the session-storage subsystem, which I understand is under #3596's sole ownership.

Rebased cleanly onto dev at dd26a0787. Happy to keep iterating if any of the above reasoning does not hold up under your independent check.

[Yeachan-Heo]

REQUEST_CHANGES — terminal hostile review of exact head 890bd21fdfc348aa1d9b745bb3865126af824130 against exact current-dev base dd26a0787260b4c54b6298b2f46b4908b2b1ed1a.

The two predecessor #3595 blockers are materially repaired in this successor. Exact-head CI proves team-runtime.test.ts green (job 90979894483), and source review confirms continuation revalidation + send-keys are held under withGjcTeamMutationFence, the fence is released before the receiver ACK wait, pruneTeamWorkerGcRecord takes the same fence, the receiver ACK re-enters through task mutation, and the fake tmux split marker is restored. I found no dependency on the reverted synchronous managed lock and no exact-file overlap with the sole #3596 branch.

P1 — the repaired exact head does not typecheck. Exact-head run 30574170803, required job 90979894452, fails packages/coding-agent check at src/gjc-runtime/team-runtime.ts:4534: readonly (string | undefined)[] is passed to a readonly string[] dispatch seam. The new frozen send-keys argv embeds worker.pane_id, whose type remains optional even after runtime eligibility validation. CI log SHA-256: 10b95e99ff89e21b5890ec6e6401d1bbe4e12baf60a6764c5a8c439c53e80a99.

Bounded repair: capture/narrow a non-empty pane id inside the fenced revalidation result before building argv (or return the typed skipped outcome), then use that proven string for both send operations. Keep the existing fence release before ACK and rerun a fresh exact-head package check plus team-runtime shard.

Exact-head CI is terminal with no pending checks: the team-runtime shard passed, but package check, evidence producer, and aggregate are red. Red CI is independently merge-blocking. Closing this external PR under doctrine; no external branch mutation, workflow rerun/cancellation, or duplicate internal mutation lane was created.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]