fix(coding-agent): retain deferred shell output

[sj0618]

What

• Preserve in-flight shell/Python execution components across pending-message and transcript rebuilds.
• Persist deferred shell results before public agent_end publication and reconcile uncertain appends by exact entry id.
• Retain uncertain append identity across rejected recovery so committed results cannot be appended twice.
• Serialize terminal publication retries across independent waiters while preserving the exact event and resource lease.
• Associate live deferred displays with persisted entries so transcript rebuilds retire only the matching display.

Why

Fixes #3639.

Supersedes #3660. This existing contributor-owned PR contains the reviewed candidate plus the exact-head durability/publication repairs requested in maintainer review, rebased onto current dev. Contributor sj0618 remains the primary commit author and candidate author probe remains co-author.

Testing

• bun test packages/coding-agent/test/modes/controllers/bash-command.test.ts packages/coding-agent/test/agent-session-user-shortcut-hooks.test.ts — 13 passed, 71 assertions
• bun test --rerun-each 5 packages/coding-agent/test/agent-session-user-shortcut-hooks.test.ts — 55 passed, 285 assertions
• bun --cwd=packages/coding-agent run check — passed
• git diff --check upstream/dev...HEAD — passed

GJC verdict

gajae.pr-review-verdict.v1 merge-approved sha256:5be7c7b49b90249ef70acd467822730c77944eea reviewer:architect evidence:local-diff-review

---

• Target branch is dev
• Focused tests, repeated lifecycle tests, and package check pass
• CHANGELOG updated under ## [Unreleased]
• Contributor ownership preserved
• Verdict above matches the exact PR head

[Yeachan-Heo]

REQUEST_CHANGES — terminal review of PR #3697 at head 7f2380c83ac2ea1178d5d81ac8023028a4b7a775.

The fetched review base is origin/dev at c1bf3be50e2cf0dfdf51b57eb43f7a99521c94b8; this PR's merge base is b40bc271502a0802e212e5538c5d0e8436643029, so the PR is stale and must be rebased onto current dev before approval.

Hostile deferred-shell-output finding:

• Blocking race: handleBashCommand() sets recorded = true only after executeBash() resolves. If the agent emits agent_end while a deferred bash command is still running, flushPendingBashComponents() intentionally keeps the current ctx.bashComponent in pendingBashComponents. If that command then rejects, the catch path completes the component but leaves recorded === false; the final promotion condition therefore never detaches it from pendingMessagesContainer or adds it to chatContainer. The error/result is stranded in the pending area after the agent is idle, and there is no later agent-end flush to deliver it. The new test exercises a rejection, but it manually calls flushPendingBashComponents() after awaiting the command, so it does not cover this ordering race. Promote the component on rejection as well, or add a completion-time delivery path that handles both success and failure after the terminal flush.

• REQUEST_CHANGES / stale base (blocking): Rebase onto c1bf3be50e2cf0dfdf51b57eb43f7a99521c94b8, then rerun the deferred-output and agent-end lifecycle tests against that base.

I did not merge or mutate the PR. Terminal verdict for this exact head: REQUEST_CHANGES.

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

[Yeachan-Heo]

Exact-head red-team review for 7f2380c.

No implementation defect found in the deferred shell-output patch after reviewing the ownership/flush paths and running:

• bun test packages/coding-agent/test/modes/controllers/bash-command.test.ts packages/coding-agent/test/agent-session-user-shortcut-hooks.test.ts (5 pass, 58 assertions)
• bun --cwd=packages/coding-agent run check (Biome passed; local TypeScript process was interrupted by the shell runner after starting)

REQUEST CHANGES: GitHub reports this exact head as CONFLICTING/DIRTY against dev. The PR base is b40bc27, while current dev is be3940a. Rebase or otherwise update the PR onto current dev, rerun CI, and request review again. This is a mergeability blocker, not a code finding.

Review receipt: gajae.pr-review-verdict.v1 needs-changes sha256:7f2380c83ac2ea1178d5d81ac8023028a4b7a775 reviewer:Yeachan-Heo evidence:terminal-exact-head-red-team

[Yeachan-Heo]

Corrected exact-head red-team review for 7f2380c.

BLOCKING CODE FINDING in packages/coding-agent/src/modes/controllers/command-controller.ts: handleBashCommand() sets recorded = true only on successful executeBash() resolution. For a deferred command that is still running when the agent-end flush runs, flushPendingBashComponents() correctly leaves the current component pending. If executeBash() then rejects, the catch path calls setComplete() but leaves recorded false; the completion path therefore does not detach/promote it, and no later agent-end flush is guaranteed. The failed command remains stranded in pendingMessagesContainer after the agent is idle. The added rejection test manually calls flushPendingBashComponents() after awaiting the command, so it does not exercise this late-rejection ordering. Promote completed deferred components on both success and failure, or add a completion-time delivery path that handles rejection after the terminal flush.

The exact head is also stale/conflicting: base b40bc27 versus current dev be3940a. Rebase, add the late-rejection regression, rerun CI, and request review again.

Review receipt: gajae.pr-review-verdict.v1 needs-changes sha256:7f2380c83ac2ea1178d5d81ac8023028a4b7a775 reviewer:Yeachan-Heo evidence:terminal-exact-head-red-team

[Yeachan-Heo]

Corrected exact-head red-team review for 7f2380c.

BLOCKING CODE FINDING in packages/coding-agent/src/modes/controllers/command-controller.ts: handleBashCommand() sets recorded = true only on successful executeBash() resolution. For a deferred command still running when the agent-end flush runs, flushPendingBashComponents() leaves the current component pending. If executeBash() then rejects, the catch path calls setComplete() but leaves recorded false; the completion path does not detach/promote it, and no later agent-end flush is guaranteed. The failed command remains stranded in pendingMessagesContainer after the agent is idle. The added rejection test manually calls flushPendingBashComponents() after awaiting the command, so it misses this late-rejection ordering. Promote completed deferred components on both success and failure, or add a completion-time delivery path handling rejection after terminal flush.

The exact head is also stale/conflicting: base b40bc27 versus current dev be3940a. Rebase, add the late-rejection regression, rerun CI, and request review again.

Review receipt: gajae.pr-review-verdict.v1 needs-changes sha256:7f2380c83ac2ea1178d5d81ac8023028a4b7a775 reviewer:Yeachan-Heo evidence:terminal-exact-head-red-team

[Yeachan-Heo]

Exact-head red-team review for 7f2380c83ac2ea1178d5d81ac8023028a4b7a775 (single commit on merge base b40bc2715; current dev tip is 54b14cb6e).

Verdict: REQUEST_CHANGES

Blocking code finding — late-rejection race in handleBashCommand()

command-controller.ts:1158-1181: recorded is set to true only after executeBash() resolves. For a deferred command still running when the agent emits agent_end, flushPendingBashComponents() intentionally retains the active ctx.bashComponent in pendingBashComponents (the component === ctx.bashComponent guard at ui-helpers.ts:1262). If executeBash() then rejects:

1. The catch path calls bashComponent.setComplete(undefined, false) but recorded stays false.
2. The promotion condition at line 1174 (isDeferred && recorded && !this.ctx.session.isStreaming && pendingIndex !== -1) never fires, so the component is never detached from pendingMessagesContainer or added to chatContainer.
3. ctx.bashComponent is cleared at line 1179, so the next flushPendingBashComponents() will move it — but no later agent-end flush is guaranteed if the agent is already idle.

The failed command is stranded in the pending area after the agent is idle.

Verified empirically — I wrote a focused reproduction at the PR head that constructs a deferred command, drives the agent idle (isStreaming = false), runs flushPendingBashComponents() (which keeps it pending), then rejects executeBash():

RESULT: strandedInPending=true promotedToChat=false pendingBashComponentsLen=1 bashComponentUndefined=true

The component is stranded in pendingMessagesContainer, never promoted to chatContainer, and ctx.bashComponent is already cleared.

The added rejection test (failing-command scenario) manually calls flushPendingBashComponents() after awaiting the command, so it exercises the normal ordering — not this late-rejection-after-flush race.

Fix direction: promote completed deferred components on both success and failure (drop the recorded gate from the promotion condition, or add a catch-path promotion), and add a regression that rejects executeBash() after the agent-end flush has already run.

Mergeability — stale base (blocking)

GitHub reports the PR as CONFLICTING/DIRTY. I confirmed via a real git merge --no-commit against current dev (54b14cb6e) that the textual content auto-merges cleanly (zero conflict markers; only CHANGELOG.md context shifts and agent-session.ts auto-merges). The DIRTY status is a stale PR metadata base reference (b40bc2715), not a textual conflict. Rebase or update the PR branch to refresh the merge base, then rerun CI.

What is correct

• The detachPendingExecutionComponents / restorePendingExecutionComponents pair in ui-helpers.ts correctly preserves in-flight components across renderInitialMessages() and updatePendingMessagesDisplay() rebuilds.
• The flushPendingBashComponents() active-component retention guard is the right design for the still-running case.
• The agent-session.ts dual flush sites (raw agent_end in #handleAgentEvent at line 3744, and pre-publish in publish() at line 2530) correctly persist deferred results before the public terminal boundary.
• The agent-session-user-shortcut-hooks.test.ts integration test correctly verifies that results recorded during raw agent_end are flushed before the public event.

Verification run

• bun test packages/coding-agent/test/modes/controllers/bash-command.test.ts — 1 pass, 38 assertions (PR head)
• Focused late-rejection reproduction — defect confirmed (see above)
• tsc --noEmit on changed source files — no errors in command-controller.ts, event-controller.ts, ui-helpers.ts, agent-session.ts
• git merge --no-commit origin/dev pr-3697-head — clean auto-merge, zero conflict markers

I did not merge or mutate the PR.

Review receipt: gajae.pr-review-verdict.v1 needs-changes sha256:7f2380c83ac2ea1178d5d81ac8023028a4b7a775 reviewer:Yeachan-Heo evidence:terminal-exact-head-red-team

[sj0618]

Resolved. Rebased the PR onto the latest dev (54b14cb), fixed the deferred-shell rejection race so a command that settles after agent_end is promoted from pending to chat on both success and failure, and updated the regression test to cover agent_end before rejection. Validation: all 5 targeted tests pass and the packages/coding-agent check passes. The PR now reports MERGEABLE / CLEAN.

[probepark]

Exact-head follow-up against 1a99ba419 found the late-rejection repair is not yet merge-ready.

Focused verification passes (5 tests / 60 assertions, rerun 20 / 100, package check), but independent lifecycle review found a remaining raw-to-public duplication window:

1. isStreaming becomes false before deferred public agent_end publication completes. Bash/Python can become durable in that interval while the same live component remains pending; a transcript rebuild can render both.
2. Public flush can persist a result before controller post-result work promotes/removes the pending component, creating another durable/live overlap window.
3. Current timing tests collapse persistence and publication and do not reproduce those windows.

Required direction: introduce an explicit execution-publication phase/barrier (not isStreaming alone) and atomically reconcile live components with durable entries at the public boundary, with Bash/Python success/cancel/reject rebuild tests for both overlap windows.

Terminal admission also remains serialized behind unresolved #3742/#3743 agent-session.ts work. No merge performed.

[Yeachan-Heo]

Exact-head re-review at new head 1a99ba4 (base 54b14cb; MERGEABLE/CLEAN).

Verdict: MERGE_READY

My prior CHANGES_REQUESTED at 7f2380c identified a blocking late-rejection race: handleBashCommand set recorded=true only on success, so a deferred command still running when agent_end flush runs would strand on rejection.

Fix verified

New commit 1a99ba4 (deliver rejected deferred shell output) removes the recorded flag entirely. The promotion condition at command-controller.ts now reads: isDeferred && !this.ctx.session.isStreaming && pendingIndex !== -1 — no recorded gate. Both success and rejection paths reach the promotion block, so a late-rejected deferred command is promoted to chatContainer instead of stranded in pendingMessagesContainer.

I verified the fix empirically with the same reproduction that showed strandedInPending=true at the old head:

• strandedInPending=false
• promotedToChat=true

Verification

• bun test bash-command.test.ts agent-session-user-shortcut-hooks.test.ts — 5 pass, 60 assertions
• Late-rejection reproduction — defect resolved
• biome check command-controller.ts — clean
• tsc --noEmit — no errors in command-controller.ts
• CI — 16 pass, 6 skip
• mergeable: MERGEABLE/CLEAN

Review receipt: gajae.pr-review-verdict.v1 merge-ready sha256:1a99ba419897d20ca00ad27d9553cb9bace6f1ac reviewer:Yeachan-Heo evidence:terminal-exact-head-red-team

[probepark]

Current-dev integration re-review completed without mutating the contributor branch. I merged PR head 1a99ba419897d20ca00ad27d9553cb9bace6f1ac locally into dev@45bc05721b21c8f6cde933ce43ac9027abdf6d89 as synthetic review commit b9292144e4bcb6b2770d8b1d361d407d0354071f.

Verification on that integration passed:

• bun test packages/coding-agent/test/modes/controllers/bash-command.test.ts packages/coding-agent/test/agent-session-user-shortcut-hooks.test.ts — 5 pass / 60 assertions
• bun --cwd=packages/coding-agent run check — passed

Independent current-base lifecycle review remains BLOCKED on two HIGH exact-once durability/publication defects:

1. agent-session.ts: idle/deferred shell paths update agent state before durable append; current managed-persistence rollback/unknown-outcome semantics can leave a non-durable ghost or duplicate retained entries while raw terminal publication aborts. Persist/recover first, reconcile by stable entry identity, and dequeue only confirmed durable entries.
2. ui-helpers.ts: transcript rebuild can render a persisted bashExecution and then restore the still-live pending component; controller completion later promotes the same component, leaving two visible copies. Reconcile durable/live components by stable execution/session-entry identity and add a rebuild-after-persist-before-controller-return regression.

Please repair these on the existing contributor-owned PR and request exact-head/current-dev re-review. No duplicate PR was opened.

[probepark]

Current-dev corrected candidate is published without mutating the contributor branch or opening a duplicate PR:

• Base: 971ff98fc5c33e34de0962c3e59c18f51a65c395
• Candidate head: fa183b67ba3bcec2164a873c1b8863cea8412e78
• Published branch: probepark/fix/issue-3639-reviewed-candidate
• Focused tests: 10 passed, 50 assertions
• packages/coding-agent check: passed
• git diff --check: passed
• Independent exact-head audit 137-G003G004ExactAudit: CLEAR / APPROVE, no findings

The candidate persists deferred Bash results before agent state and public terminal publication, reconciles every uncertain append by exact entry id including retry-committed outcomes, retains unrelated running displays, retires only the matching persisted live display during rebuild, and restores the exact terminal event/resource lease after publication failure for bounded retry.

Adoption still requires the contributor to update this PR from the published candidate or an explicit maintainer takeover decision.

[probepark]

Exact current-dev corrected candidate refresh:

• Current upstream/dev: aebb0f6d119acf178a9c710f460f83e9735bb8e6
• Contributor head: 1a99ba419897d20ca00ad27d9553cb9bace6f1ac
• Corrected candidate: f10bb050948ca5571bbced0acfe246194527ba49
• Published branch: probepark/fix/issue-3639-reviewed-candidate
• Focused tests: 10 passed, 50 assertions
• packages/coding-agent check and exact-range diff check: passed
• Independent current-dev audit 138-RebasedCandidateAudit: CLEAR / APPROVE; one LOW duplicate changelog entry found
• Exact follow-up 139-G004ChangelogFinalReview: CLEAR / APPROVE; duplicate removed, runtime/test tree unchanged

The candidate resolves the published exact-once blockers: durable-first append, exact-entry reconciliation including retry-committed uncertainty, exact pending dequeue, stable live-display association, matching-only rebuild retirement, unrelated running-display retention, and retryable terminal publication preserving the event/resource lease.

No duplicate PR was opened and contributor ownership remains intact. Adoption requires updating this PR from the published candidate or an explicit maintainer takeover decision.

[probepark]

REQUEST CHANGES on exact contributor head 1a99ba419897d20ca00ad27d9553cb9bace6f1ac.

The current contributor head still lacks the durable-first/exact-entry reconciliation and matching-only rebuild retirement required by the published findings. Merging it can create non-durable agent-state ghosts, duplicate retained Bash entries after uncertain append, and persisted-plus-live duplicate visibility during transcript rebuild.

A corrected exact-current-dev candidate is published at probepark/fix/issue-3639-reviewed-candidate head f10bb050948ca5571bbced0acfe246194527ba49. It passed 10 focused tests / 50 assertions, packages/coding-agent check, exact-range diff check, and independent reviews 138-RebasedCandidateAudit plus 139-G004ChangelogFinalReview (CLEAR / APPROVE).

Please update this contributor-owned PR from that candidate and request exact-head re-review. No duplicate PR has been opened.

[sj0618]

Applied the published corrected candidate to this existing contributor-owned PR and rebased it onto current dev@162313f98816e3814b03519a9517dc1ea58fe4ba.

• New PR head: 9f350aa0f638935717414f4b95e7820bcf19550f
• Candidate/refreshed patch ID: 19be159cadc9fd81cc8a816a4fdd417d26afc34f (identical)
• Primary author remains sj0618; probe is retained as co-author
• Focused tests: 10 passed / 50 assertions
• packages/coding-agent check: passed
• git diff --check: passed
• Exact-head CI: green

A fresh independent exact-head audit found the applied candidate is still blocked:

1. HIGH — a committed append whose recovery attempt rejects can lose its exact uncertain entry id; the next terminal-publication attempt may append the same Bash result again.
2. MEDIUM — concurrent publication waiters can diverge when one starts a retry while another rethrows the stale failure.
3. Missing committed-append/recovery-rejection, concurrent waiter, partial dequeue, and lease-settlement regression coverage.

Required repair: retain the uncertain append entry id on the pending record until reconciliation proves the prior append absent, and serialize/join terminal publication retries through one shared promise.

gajae.pr-review-verdict.v1 merge-blocked sha256:9f350aa0f638935717414f4b95e7820bcf19550f reviewer:architect evidence:local-diff-review

[Yeachan-Heo]

SUPPORTED_SUPERSESSION — signed maintainer reconciliation, exact head 9f350aa0f638935717414f4b95e7820bcf19550f

Branch ownership. This PR's head is sj0618/gajae-code:fix/issue-3639-deferred-shell-output (cross-repo, isCrossRepository: true). sj0618 is the sole mutation owner of record — the only account with push access to this branch. probepark/fix/issue-3639-reviewed-candidate is a non-authoritative reference branch used to publish reviewed diffs without writing to the contributor's branch; it does not carry ownership and no PR was opened from it, consistent with the no-duplicate-mutation convention already followed across this thread.

Reconciliation performed. sj0618 already applied the current-dev-corrected candidate (f10bb050948ca5571bbced0acfe246194527ba49, CLEAR/APPROVE per probepark's 138-RebasedCandidateAudit + 139-G004ChangelogFinalReview) to this PR and rebased onto dev@162313f98816e3814b03519a9517dc1ea58fe4ba, producing the current exact head 9f350aa0 with an identical patch ID (19be159c…) and green CI. That satisfies the "update/rebase the contributor PR" reconciliation this backlog pass was checking for — no further rebase or candidate-adoption action is outstanding.

Standing verdict at this exact head. The same commit's own follow-up audit (tag gajae.pr-review-verdict.v1 merge-blocked sha256:9f350aa0f638935717414f4b95e7820bcf19550f reviewer:architect evidence:local-diff-review) already found two live defects and is the governing verdict for 9f350aa0:

1. HIGH — a committed append whose recovery attempt rejects can lose its exact uncertain entry id, risking a duplicate Bash-result append on the next terminal-publication attempt.
2. MEDIUM — concurrent publication waiters can diverge when one starts a retry while another rethrows the stale failure.
3. Missing regression coverage for committed-append/recovery-rejection, concurrent waiters, partial dequeue, and lease settlement.

I've independently checked this verdict is well-formed (specific mechanisms, not vague) and consistent with the durability/reconciliation constraints this PR's own commit message declares (current_append uncertainty reconciles by exact entry id before retry), so I am not re-deriving a duplicate finding — I'm signing and superseding the stale CHANGES_REQUESTED review pinned to 1a99ba419 (two commits behind current head) with this one. That prior review no longer reflects the applied state and should not gate further action.

Resuming existing owner. @sj0618 — please apply the required repair from the standing verdict directly on fix/issue-3639-deferred-shell-output (retain the uncertain append entry id on the pending record until reconciliation proves the prior append absent; serialize/join terminal-publication retries through one shared promise; add the four missing regression cases), then request re-review at the new exact head. No duplicate PR, merge, or CI control action is being taken here.

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

[sj0618]

Resolved the standing exact-head blockers directly on the existing contributor branch and rebased onto current dev@a8fa63a599e9fa3d0189e48bfce778a36353ccdd.

New exact head: 5be7c7b49b90249ef70acd467822730c77944eea

Repairs:

• retain the exact uncertain current_append entry id across rejected recovery and reconcile it before any reappend;
• dequeue only confirmed-durable FIFO heads after partial failure;
• remove the resolved publication sentinel so every waiter joins the actual replacement publication;
• make unadvanceable terminal retries fail closed rather than report false success;
• make waitForIdle() drive/join terminal publication before settlement, preventing the prior deadlock;
• preserve the same terminal event/resource lease and verify one terminal emission plus one lease close.

Verification:

• focused tests: 13 passed / 71 assertions
• lifecycle rerun ×5: 55 passed / 285 assertions
• packages/coding-agent Biome + type check: passed
• exact-range git diff --check: passed
• independent final exact-head audit: CLEAR / APPROVE, no findings

gajae.pr-review-verdict.v1 merge-approved sha256:5be7c7b49b90249ef70acd467822730c77944eea reviewer:architect evidence:local-diff-review

Requesting maintainer exact-head re-review; no duplicate PR was opened.

[Yeachan-Heo]

REQUEST_CHANGES

Exact-current hostile re-review

• PR head: 5be7c7b49b90249ef70acd467822730c77944eea
• Recorded merge base: a8fa63a599e9fa3d0189e48bfce778a36353ccdd
• Canonical base now: dev@732856b3ccb3fade6e9fbc17908a4fbca5a7682f
• Relationship: 1 commit ahead / 10 behind, diverged
• Current synthetic merge: 7fe493771631fd52ea2c33f3e3767f3684135b1a, parents 732856b3... + 5be7c7b4...
• Head checks: 22 total, 16 success / 6 skipped / 0 failed
• Synthetic current-base merge checks: 0
• GitHub review decision: CHANGES_REQUESTED

The exact-head diff has the correct architectural direction and appears to address the standing late-rejection, exact uncertain-entry reconciliation, partial FIFO dequeue, shared publication waiter, transcript rebuild identity, and settlement/lease findings. This batch found no new code blocker in that diff.

The integration gate still blocks approval. Since merge base a8fa63a..., current dev changed packages/coding-agent/src/session/agent-session.ts by +171/-8, and no check has exercised the current synthetic merge. Rebase onto exact current dev, preserve sj0618 as primary author and probepark as co-author/review contributor, rerun the affected shell durability/rebuild/append-failure/publication-settlement checks, and request fresh maintainer review at the resulting exact head.

Current dev is independently red in SDK operation-inventory CI; do not conflate that baseline seam with this PR's product behavior, but do not claim current-base green either.

gajae.pr-review-verdict.v1 merge-blocked sha256:5be7c7b49b90249ef70acd467822730c77944eea reviewer:gpt-heavy-hostile-batch evidence:live-api+current-source

—
Signed: Yeachan-Heo · GPT-heavy hostile batch triage · 2026-08-05

[yazzang-homelab]

경고 — 이 PR의 현재 head가 CHANGELOG 전체를 삭제한다

머지하면 안 된다. 확인된 사실:

$ git cat-file -s <이 PR head>:<해당 CHANGELOG 경로>
1

1바이트 — 개행 하나만 남았다. dev의 같은 파일은 312,259 bytes(coding-agent) / 244,785 bytes(ai) / 45,275 bytes(agent)다. 릴리스 이력 전체가 사라진 상태다.

원인은 내 쪽이다

#3932(11:25:32Z 머지)가 .gitattributes에서 packages/*/CHANGELOG.md merge=union을 제거했다. 제거 자체는 근거가 있었다 — union은 충돌을 내지 않고 양쪽을 이어붙여서 이미 릴리스된 섹션에 항목을 조용히 밀어넣고 있었다(#3929, 실측 35건).

그런데 그 결과 리베이스에서 CHANGELOG가 처음으로 진짜 충돌을 내기 시작했고, 그 충돌을 해소하는 과정에서 파일이 비워졌다. 시간대가 명확하다:

시각 (UTC)	사건
11:25:32	#3932 머지 (union 제거)
11:29:29 ~ 11:35:02	#3920 #3697 #3870 #3908 #3887 #3864 #3729 #3869 #3866 #3873 — 작성자 6명, 10개 PR이 전부 1바이트 CHANGELOG로 갱신됨

전환 비용을 예고하지 못한 건 내 잘못이다. 미안하다.

복구

git fetch origin
git checkout origin/dev -- packages/coding-agent/CHANGELOG.md   # 해당 패키지 경로로
# 그 다음 ## [Unreleased] 아래에 이 PR의 항목만 다시 추가
git add packages/coding-agent/CHANGELOG.md
git commit --amend --no-edit    # 또는 새 커밋

앞으로 리베이스에서 CHANGELOG 충돌이 나면 양쪽 항목을 모두 ## [Unreleased] 아래에 남기는 것이 올바른 해소다. 이미 릴리스된 ## [X.Y.Z] 섹션은 손대지 않는다. CONTRIBUTING.md의 "Rebasing onto dev" 절에 적어두었다.

푸시 전에 다음으로 자가 점검할 수 있다:

git cat-file -s HEAD:packages/coding-agent/CHANGELOG.md   # 30만 바이트 근처여야 정상

[yazzang-homelab]

Independent architect review of head 474ccae1f. The standing verdict's three items are all addressed; I verified each rather than reading the diff summary.

The standing blockers are closed

That verdict named:

1. HIGH — a committed append whose recovery attempt rejects can lose its exact uncertain entry id, risking a duplicate Bash result.
2. MEDIUM — concurrent publication waiters diverging when one retries while another rethrows the stale failure.
3. Missing regression coverage for committed-append/recovery-rejection, concurrent waiters, partial dequeue, and lease settlement.

All four coverage gaps now have named cases, and they map one-to-one onto the findings rather than being adjacent tests:

reconciles a committed deferred shell append after recovery rejects          <- (1)
shares terminal retry settlement between concurrent public waiters and emits once  <- (2)
dequeues only durable deferred shell records after a partial failure         <- partial dequeue
retries a failed terminal publication without losing the deferred shell result
reconciles a retry that commits after the first append was proven absent
reconciles an immediate shell result that committed before append failure
reconciles a deferred shell result that committed before append failure

Executed on this exact head, in a hermetic environment (see the caveat below):

bun test packages/coding-agent/test/agent-session-user-shortcut-hooks.test.ts \
         packages/coding-agent/test/modes/controllers/bash-command.test.ts
-> 13 pass, 0 fail

-t "recovery rejects"            -> 1 pass, 8 expect() calls
-t "concurrent public waiters"   -> 1 pass

The two targeted cases pass individually, so they are not passing by side effect of an earlier test in the file. emits once in the concurrent-waiter case is the right assertion — it pins the divergence (a second emission) rather than merely that both waiters resolved.

Changelog recovered

This PR was among the twelve damaged when I removed merge=union in #3932 (see #3942). It is fixed here — packages/coding-agent/CHANGELOG.md is back to 312,554 bytes, restored in the head commit. Nothing further needed. Merges cleanly into current dev.

Environment caveat worth knowing

My first run of the adjacent registry suites showed failures that were not from this PR — model-registry.test.ts reads provider API-key environment variables from the host shell, so a developer with credentials configured sees red on current dev too. I filed that as #3945. It does not touch this PR's suites, but if you see unexplained red locally in that area, that is why.

One remaining note

The description says the HIGH item risked "a duplicate Bash result". The test asserts reconciliation after recovery rejection, which covers the entry-id retention — but I could not find an assertion that the transcript ends up with exactly one Bash result in that scenario. If the observable harm was duplication, asserting the count directly (not just that reconciliation happened) would pin the user-visible property rather than the mechanism. Non-blocking, and cheap to add.

gajae.pr-review-verdict.v1 merge-approved sha256:474ccae1f9e4d86e952b3792d03dafe38a234910 reviewer:architect evidence:13 pass / 0 fail on this head with *API_KEY* unset and isolated HOME; the two named blocker cases pass individually; CHANGELOG restored to 312554 bytes; merge-tree vs origin/dev clean

[Yeachan-Heo]

Closing during the emergency maintenance freeze. This PR is not in the retained critical or maintainer-owned set. Do not open a replacement PR unless a maintainer explicitly directs it.

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