Keep Sidekick message queueing available during automatic feedback #1183

Story

While Sidekick is processing automatic feedback in xmd repl, I can send a follow-up message and see it waiting in the queue. The current work continues, and the follow-up starts at the existing eligible boundary.

For example, Sidekick finishes an entry and asks Claude to interpret its results. I send “When that finishes, explain the changes.” The message queues instead of failing with a recovery error.

Reproduction and observed failure

1. Enable Follow and let Sidekick submit an entry.
2. The entry finishes and the host begins the automatic feedback prompt.
3. While that prompt is still generating, send a follow-up through the Sidekick composer.

The UI reports:

This conversation holds feedback whose acceptance cannot be established.

The screenshot shows Sidekick working with a live response preview, QUEUE 0/16, and the attempted message still in the composer. The message was rejected before entering the queue. No Stop, crash or quota failure is required for this sequence.

Cause and evidence

Before sending feedback, the owner saves a feedback record with turn: null. Until a completed canonical Prompt establishes delivery, the history projection classifies it as unresolved. That is an expected temporary state while the current exchange owns the request.

The dispatch send() path checks the recovery guard before queue admission. The guard does not distinguish the active exchange's in-flight feedback from unresolved feedback left after an exchange ends.

In execution de5e5a54299363701d445bb846f931de, a read-only reconstruction of the saved prefix immediately before turn 100's result showed:

records: 1225
saved turns: 99
unestablished: [{ turn: null }]
uncertainRequests: [1224]
recoveryPending: true
blocked: true

Once turn 100's completed result was present, the same projection showed unestablished: [], uncertainRequests: [], recoveryPending: false and blocked: false. This establishes the temporary false recovery state; it does not require changing the incident history or sending another provider prompt.

Source inspection at e93866dd793732edcaf9cc2d026f32c4881e0433:

• Pending feedback persistence and refresh
• Dispatch recovery guard
• Guard before queue admission

Required behavior

• Accept an otherwise eligible follow-up while the active exchange owns the in-flight feedback. Show the queued message and preserve newer composer text.
• Queue admission starts no concurrent prompt, evaluation or writer. Processing still follows the existing queue ordering, Follow, Stop and cleanup rules.
• Distinguish the exact live request from genuinely unresolved prior feedback. A generic busy flag is insufficient evidence that every unresolved request belongs to the active exchange.
• Recheck eligibility before a queued message starts. If the active exchange fails or leaves genuine delivery uncertainty, retain the appropriate queue hold and recovery behavior.
• Do not fabricate a delivery acknowledgement, mark pending feedback completed, resend it, repeat an entry, replace the conversation or bypass cold-reopen recovery protections.
• Present the recovery action for actual recovery conditions; ordinary in-flight feedback alone must not make the conversation appear broken.

Acceptance and verification

Use a deterministic provider with the real Sidekick owner and dispatcher:

1. Complete an entry, observe its feedback request and hold the feedback reply open. Enqueue a follow-up through the actual UI; verify a visible queued row, cleared submitted composer text and no extra provider call.
2. Release the reply. Verify the follow-up starts once at the permitted boundary, with the original conversation and completed entry effects preserved.
3. Fail or interrupt the held feedback request. Verify the queued message does not drain through unresolved acceptance and the existing hold/recovery controls remain correct.
4. Supply genuinely unresolved earlier feedback as a negative control. Active work elsewhere must not suppress its guard.
5. Exercise the shared dispatch boundary used by UI and ACP callers; preserve capacity, withdrawal and Stop behavior.

Focused entrypoints: packages/cli/tests/repl-sidekick-dispatch.test.ts, repl-sidekick-recovery.test.ts, and the relevant real-UI journey in repl-sidekick-journey.test.ts. Run explicit affected files with deno task test <files>; no paid provider call or live-session mutation is required.

Relationships

Follow-up to completed #964 (visible follow-up queueing). Distinct from #1151 (joined Stop during feedback cancellation) and #987 (recovery after genuinely uncertain delivery). This ticket corrects admission during a healthy active exchange; it does not redesign the queue or weaken recovery.

Reserved higher-value pilot assignment

The maintainer asked for more valuable work than the earlier #1207/#1210 pair. This issue is reserved for one fresh Opus Implementor pilot, coordinated by #1199's existing owner (chat 01a1bcee-8df7-77b3-86db-21dcde6a4b3c), after all accepted workflow changes and independent review-summary repair pass review/checks. Use the same exact frozen workflow revision as paired issue #1178. The earlier pair was withdrawn before any pilot dispatch.

Bounded scope: Fix admission of follow-ups during the exact live automatic-feedback exchange, retaining queue order and rechecking before dispatch. Preserve genuine uncertain-delivery recovery and cancellation behavior. No generic recovery bypass, automatic replay, new concurrency or conversation replacement.

The user authorized unattended planning, implementation, applicable/independent reviews, focused PR publication and CI without additional routine approval. Preserve finite budgets, original failures and native identity; no silent model substitution or reset. Recheck current ownership and whether the bug persists before dispatch. Genuine new contract decisions remain explicit blockers; continue the other task if one blocks. Keep PRs reviewable for the user's decision; no merge authorization is granted here or for #1203.

Record actual workflow/source pins, first-result validity, guide-read timing, correction/additional-call counts, summary-overflow handling and manual interventions. Collect one short debrief from the original Implementor once useful work is complete. Use deterministic regression evidence rather than fabricating an overflow or adding another paid review run.