[Bug] terminal_service.send_input: stale cached COMPLETED satisfies the next wait_until_status immediately (returns previous turn's output)

[chaogebaba]

Symptom

On a reused terminal, send_input followed by wait_until_status(COMPLETED) can return immediately with the previous turn's output — the caller receives a stale result instead of waiting for the new turn.

Root cause pointer

src/cli_agent_orchestrator/services/terminal_service.py — send_input clears only the rolling byte buffer before send_keys (deliberately, to preserve the sticky-latch arm), but the cached _last_status = COMPLETED from the previous turn survives. The next wait_until_status(COMPLETED) is satisfied by the cached value before the new turn has produced anything.

Impact

Any handoff/reuse flow that waits for completion on a warm terminal can silently get the prior answer. Intermittent (depends on whether a fresh status probe lands before the wait), which makes it look like a flaky agent rather than an orchestrator bug.

Suggested direction

Invalidate/downgrade the cached status (e.g. to PROCESSING or None) at send_input time, in the same critical section that clears the byte buffer, so completion can only be re-satisfied by a post-input detection.

[call-me-ram]

Thanks for this — confirmed against current main. send_input arms the stickiness gate via notify_input_sent (_allow_processing_revert) but never invalidates the cached _last_status, and wait_until_status polls status_monitor.get_status, which serves that cached latch for pipe-pane backends — so a warm terminal's previous COMPLETED can satisfy the wait before any post-input detection lands, returning the prior turn's output. Exactly the intermittent race you describe.

Your suggested fix is the right shape: downgrade the cached status (COMPLETED/IDLE → UNKNOWN or PROCESSING) inside notify_input_sent's existing lock, so completion can only be re-satisfied by a fresh detection. One care point for the fix: the burst/sticky-ready logic (_STICKY_READY_STATUSES) must not immediately re-latch the stale value from the old buffer.

A PR with a warm-terminal regression test (two turns, assert the second wait_until_status doesn't return turn 1's output) would be very welcome; otherwise we'll pick it up.