[taras]

Why

Sending a follow-up while Sidekick processes automatic feedback currently shows a recovery error and refuses the message. The running owner already holds that exact feedback exchange, so the message should join the queue.

What changes

Before: the feedback record appears unresolved until its provider call completes; Send and the recovery display treat that ordinary in-flight state as interrupted work.

After: follow-ups queue behind the exact feedback exchange owned by the live Sidekick. The queued message starts once the exchange finishes. Failed or stopped feedback still requires recovery and leaves the queue held.

How it works

The owner tracks the position of its own feedback record and releases it by identity after the final refresh or during teardown. Queue admission and the recovery display read the same recovery decision. Cold owners and earlier or mismatched unresolved feedback keep the existing guard.

What must stay true

• FIFO order, capacity, withdrawal, Follow, Stop consent and one active provider prompt remain enforced.
• The exception covers only automatic feedback or the completed-round handoff position held by the current exchange; it never fabricates acceptance or replaces the conversation.
• Failed, interrupted and genuinely unresolved feedback continue to hold queued work.

How to verify it

• The mounted UI regression sends while feedback is held, observes the queued row and cleared composer, then verifies exactly one dispatch on the same conversation while preserving newer typing.
• Dispatch and recovery regressions cover failure, Stop, cold reopen, repeated identical requests, mismatched acknowledgements and UI/ACP FIFO ordering.
• Focused dispatch, recovery, journey and ACP suites passed: 57 tests / 235 steps. The final helper-only adjustment was followed by passing dispatch/recovery suites and their typecheck; the committed patch matches the tested candidate.
• Typecheck passed for production runtime entry points, headless/ACP boundaries and the affected tests.

Risks and limitations

The live exception lasts through evaluation of a successful automatic-feedback reply until its response record is saved and refreshed. CI exposed an overbroad exception for explicit recovery messages carrying interrupted work. Signed correction 5a27f27f8864b8020f60d52231152f58282fbb00 restores that guard without changing the existing R6 assertions. The original Codex Planner returned PASS on this exact correction after verifying its diff and tested candidate. The unchanged R6 test (5 tests / 14 steps), all six #1183 regressions and focused typecheck passed.

The user explicitly authorized a new Codex Implementor for this one correction because the original Opus session refused to resume before a prompt. This consumes source correction 1 of the existing maximum 3; histories and allowances remain preserved. The original Planner PASS on 518470c8 and its superseding R6 finding remain recorded.

The independent Fable review on the original commit returned progress rather than JSON and is held at 0/2 response corrections; no replacement or replay of that attempt occurred. The corrected commit has matching independent Codex Astra PASS on all four acceptance clauses. The original Fable identity refused cold resume before output; the recorded policy selected the one Astra replacement after provider release. The corrected R6 shards pass under Deno, Node and Bun. CI initially hit the separate Implementation fixture 120-second timeout tracked in #1143. Its single unchanged-head retry passed all 47 files; all branch technical checks now pass. First failure and passing retry output remain preserved; the flake stays open. The prior aggregate failed solely through Main health (#1224). The unrelated Delivery A-H failure is tracked in #1176. Main has advanced to c900ebfd through #1230; its new CI run is in progress, so current Main health remains pending. No merge is authorized.

Scope confirmation

• Every changed file supports queue admission, recovery presentation or its regressions.
• Test helper moves support reuse by the new regressions.
• The specification includes the accepted queue behavior.
• This draft is for review and CI; it must remain unmerged.

Closes #1183.

[github-actions]

PR #1225: Queue Sidekick follow-ups during live automatic feedback

9 files, +676 / -240

Scope

🔴 PR has 916 lines changed. Split into focused PRs.

🟡 916 lines changed. PRs under 400 receive more thorough review.

Structural

Oxlint structural signals:

• no-unused-vars ×3: packages/cli/src/repl/program.ts
• no-empty-function ×2: packages/cli/src/repl/sidekick/dispatch.ts
• no-unnecessary-type-arguments ×2: packages/cli/src/repl/sidekick/dispatch.ts, packages/cli/src/repl/sidekick/owner.ts

Slop

✅ Slop indicators look low.

Static Analysis

Oxlint: 71 diagnostics across 5 files (11 rules)
Density: 0.105 violations/added-line

no-shadow (31): packages/cli/src/repl/sidekick/dispatch.ts, packages/cli/src/repl/sidekick/model.ts, packages/cli/src/repl/sidekick/owner.ts (+1)
no-floating-promises (18): packages/cli/src/repl/sidekick/dispatch.ts, packages/cli/src/repl/program.ts
unbound-method (6): packages/cli/src/repl/program.ts
no-array-sort (3): packages/cli/src/repl/sidekick/model.ts
no-unused-vars (3): packages/cli/src/repl/program.ts
consistent-function-scoping (2): packages/cli/src/repl/sidekick/recovery-state.ts, packages/cli/src/repl/sidekick/owner.ts
no-empty-function (2): packages/cli/src/repl/sidekick/dispatch.ts
no-unnecessary-type-arguments (2): packages/cli/src/repl/sidekick/dispatch.ts, packages/cli/src/repl/sidekick/owner.ts
no-useless-default-assignment (2): packages/cli/src/repl/program.ts
no-useless-spread (1): packages/cli/src/repl/sidekick/dispatch.ts
consistent-return (1): packages/cli/src/repl/program.ts

Correctness

No extraneous code patterns detected.

[taras]

Spec review at 5a27f27f8864b8020f60d52231152f58282fbb00, against #1183 and the existing queue/recovery contract.

1. Cover the completed-round handoff explicitly. Lines 3299–3305 describe the exception while asking for automatic feedback. Lines 3873–3884 let an already-queued message go first when a round settles. Make clear that the exception also covers that message's exact live request when it carries the round results. Otherwise a reimplementation can accept a follow-up during a feedback-only turn but reject it during this handoff, reproducing Keep Sidekick message queueing available during automatic feedback #1183. The recovery-action rule should use the same definition.

2. Specify the outcome of a failed start-time eligibility check. The new paragraph requires a recheck but does not say what happens to a waiting head that fails it. Lines 3307–3315 also say attachment cancellation adds no hold. If such cancellation leaves feedback acceptance unknown, define the independent guard's result: keep the message queued, send nothing, expose the hold reason, and state how removal or explicit recovery resolves it. Distinguish this guard from a human-Stop hold; cancellation must not manufacture a Stop binding.

A small ownership improvement: define the exact live-request exception once and link admission and recovery presentation to it, instead of maintaining “in-flight” and “pending” variants.

The exact-request restriction, unchanged FIFO limits and composer revisions, no concurrent prompt/evaluation/writer, and preserved cold-reopen uncertainty are stated clearly. These requested additions close observable contract gaps; they do not require a broader queue redesign. This feedback concerns the specification, not merge readiness.

[taras]

Addressed the spec review in 0ce1399364ffcb8799f2bb5bb8b672cad154d90e.

1. One live-feedback exception now covers both the feedback-only provider request and the queued message whose request carries a completed round's results. Queue admission and the recovery action use that definition. The exception is bound to the exact retained record position and live request. Earlier unresolved records, mismatched acknowledgements, pending recovery decisions, and cold reopen still use the recovery guard.
2. If the waiting head fails the start-time check, it stays queued, sends nothing and has a visible hold reason. Removing the item withdraws only that item. Resume rechecks the guard, and explicit recovery uses a distinct instruction. Attachment cancellation supplies no human-Stop binding. If cancellation leaves feedback acceptance unknown, the separate guard holds the next queued message.
3. The spec retains FIFO, capacity, composer revisions and the single prompt, evaluation and writer boundary.

The change is limited to the REPL spec. The dispatch, recovery and Sidekick journey run passed 47 tests and 174 steps. Four child-reference steps were blocked by local socket permissions and all four passed on a focused rerun with local listeners permitted.

The original Fable session could not resume. The existing independent Codex Astra reviewer passed the exact update under the recorded fallback policy. CI is tracked separately on the updated head.