* fix(lifecycle): publish AgentReady on wakeup-driven turns
Wakeup turns flow Adapter.Prompt → bridge → events, bypassing
SessionManager.SendPrompt. The execution status stayed Ready across
the wakeup turn, so MarkReady's duplicate-suppression guard dropped
the second AgentReady — the orchestrator never closed the turn,
never evaluated on_turn_complete, and never dispatched queued
messages. Detect this in recordActivity and flip Ready → Running on
the first non-terminal event, re-emitting AgentRunning so the rest
of the pipeline behaves like any other turn.
* fix(lifecycle): gate wakeup flip on turn-content events and handle empty turns
Three follow-ups on the wakeup AgentReady fix:
1. Restrict the Ready → Running flip in `recordActivity` to events that
unambiguously indicate turn-in-progress activity (message_chunk,
reasoning, tool_call/update, plan, agent_plan, permission_request).
The original whole-event-type flip caused a regression: claude-agent-acp
emits available_commands_update asynchronously ~50ms after session/new,
well after dispatchInitialPrompt fires MarkBootReady for a no-prompt
task. The Ready → Running flip on that delayed metadata event was
putting newly-created tasks back into Running and breaking the chat-
input UI (changes-panel-focus E2E tests).
2. Handle the empty-wakeup edge case: a wakeup turn that emits only a
`complete` event (empty model response) is still excluded from the
flip whitelist, so the Ready guard in MarkReady would suppress
AgentReady. `handleCompleteEventMarkState` now publishes AgentReady
directly when Status is already Ready on a successful complete —
the orchestrator still closes the turn for empty wakeup responses.
3. Fold the `executionStore != nil` check into the early-return so the
AgentRunning publish only fires when the status flip actually succeeded.
Test-file cleanup from review feedback: dead loop, redundant
`var _ = io.MultiReader`, and `teeReader.src any` → `io.Reader`.
New regression tests:
- TestWakeup_PostBootMetadataEventsDoNotFlipToRunning — locks in the
whitelist behavior so future events can't accidentally re-arm a
boot-ready session.
- TestWakeup_EmptyTurnStillPublishesAgentReady — covers the
empty-wakeup-complete fallback.
* fix(lifecycle): publish AgentRunning before AgentReady on empty wakeup turns
Follow-up on the previous wakeup fixes — addresses three issues raised in
review:
1. **Empty-wakeup AgentReady was ignored by the orchestrator.** The fallback
in `handleCompleteEventMarkState` published AgentReady when Status was
already Ready, but `handleAgentReady` at the orchestrator early-returns
when `session.State != Running/Starting`. After the previous turn ended
the session is in WaitingForInput, so the AgentReady got silently
dropped — same suppression the wakeup fix was meant to prevent. Now the
fallback flips Ready → Running + publishes AgentRunning first (mirroring
`recordActivity` for the non-empty case), then falls through to MarkReady.
2. **firstActivityOnce could still publish AgentRunning on a late
metadata event.** Gate it on `Status != Ready` so a delayed
`available_commands_update` arriving after MarkBootReady (the original
regression scenario) can't slip through via the once-per-execution path.
In practice the adapter always emits `agent_capabilities` during
Initialize before MarkBootReady, so firstActivityOnce still fires there
with Status==Running — this is defensive hardening.
3. **Tighter test assertions.** The post-boot-metadata test now primes
firstActivityOnce in setup and asserts strict `runningCount == 0`.
The second-turn test verifies AgentRunning precedes each AgentReady in
bus order so the orchestrator's session-state guard isn't violated.
Same ordering check added to the empty-wakeup test.
* test(lifecycle): rename exec to agentExec to avoid os/exec shadow
The test variable `exec` in wakeup_e2e_test.go shadowed the imported
`os/exec` package — harmless today because all `exec.Command`/`LookPath`
calls happen before the local binding, but a future call added below
would silently fail. Rename to `agentExec` to remove the shadow.
* ci: retrigger CodeQL after transient Ruby analyze flake
The default-setup CodeQL run on PR #875 produced a flaky 'CodeQL could
not process any code written in Ruby' failure on the Ruby analyze job
(github.com/kdlbs/kandev/actions/runs/26124163769). The repo has no
Ruby code and main's CodeQL only analyzes javascript-typescript +
actions; the Ruby job was added dynamically and failed on the empty
diff. Sibling run 26124163815 on the same SHA passed. Cannot rerun
default-setup workflows via the API (403 'cannot be retried'), so
push an empty commit to retrigger the analysis.
* test(lifecycle): tighten wakeup test assertions
- wakeup_simulated_test.go: assert exact readyCount==2 instead of <2 so
any over-emission (e.g. duplicate AgentReady on the wakeup turn) is
also caught.
- wakeup_e2e_test.go: fail with t.Fatalf when the adapter surfaces no
WAKEUP text instead of logging a warning. Otherwise the bus-level
assertions below pass vacuously if the wakeup never fires.
Both fixes address review comments from cubic-dev-ai / claude[bot] on
PR #875.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* test(lifecycle): remove unsynchronised SessionID write in forwarder goroutine
The forwarding goroutine wrote to agentExec.SessionID without holding
the executionStore mutex, racing with the main goroutine's authoritative
assignment after NewSession returns. The forwarder's write is redundant
— line 264 sets the canonical value — and benign in practice, but
`go test -race` would flag it. Drop the write to keep the race detector
clean.
Addresses review comment from claude[bot] on PR #875.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
---------
Co-authored-by: Kandev Agent <agent@kandev.dev>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
João Salavisa
0b2c59a2dd