Test 584 — Dashboard → Codex TUI reliable delivery
Date: 2026-08-04 (Asia/Shanghai)
Base: origin/main 7876336513903c42bc9212aeaf5f038bf51844cc
Source candidate: 904d8959f66a1f09cd694be71358bf57bbbed794
Image: anet-test584:dev
Image ID: sha256:25e2b1e37775938374add2ccf26a9be492e324f34a67f5a1f557310749ccfcde
Image ENV: TEST584_SOURCE_COMMIT=904d8959f66a1f09cd694be71358bf57bbbed794
Command: sg docker -c 'docker run --rm anet-test584:dev'
Result: PASS (exit 0)

Production witnessed-red that motivated this follow-up
- Dashboard task idem_74cbad5ff7fc4b14eb0c180d1a534f2f9c23c430 reached the
  current Codex TUI and was answered UAT584-ACK, proving authenticated inbound
  delivery, but its bridge handler remained queued behind an already-active turn.
- A second Dashboard task idem_f0c9855b6057f8e63ad3a2cef72f6c539decf620
  emitted new_task while that handler was active. The bridge logged the SSE event
  but did not fetch/process the row.
- Root cause: workInboxDrain serialized the whole processInbox promise. Although
  rows from one get_inbox snapshot were concurrent, a later SSE wake only set the
  lane dirty and could not run get_inbox again until the first model turn ended
  (or reached its 600-second default timeout).

Candidate behavior
- Codex inbox rows take their synchronous per-row inflight claim and enter bridge
  arbitration without keeping the serialized fetch lane occupied for the model
  turn's lifetime.
- A later new_task/new_message/broadcast SSE wake can therefore fetch and submit a
  new Dashboard row while the first Codex turn is still active.
- Admission is synchronously deduplicated and capped at 20 active handlers. N+1
  waits in a local FIFO, starts when a slot settles, and completion wakes another
  Hub read so backlogs beyond the first get_inbox page continue advancing.
- This handler concurrency never bypasses the bridge's synchronous turn claim:
  ordinary network tasks still produce one turn/start at a time and remain FIFO;
  only authenticated Dashboard chat may steer a proven human turn.
- Detached completion failures are observable and schedule a fresh inbox drain.
- Durable pending-reply draining is fenced while any detached Codex row is active,
  preventing a concurrent drain from racing direct send/clear and duplicating a
  reply. Other runtimes preserve their awaited serialized behavior.

L1 — source/build
- Exact source SHA was embedded in the image ENV and printed by the harness.
- agent-node CLI bundled successfully (239 modules, 1.65 MB output).

L2 — app-server bridge, dispatch, and production wiring
- 56 tests passed, 0 failed, 163 assertions.
- Real createInboxDrainLane behavior proves snapshot #2 enters before snapshot #1's
  blocked model turn is released.
- Source wiring pins the Codex-only detached path and the active-row pending-reply
  fence; non-Codex runtimes remain awaited and serial.
- Same-tick duplicate kicks invoke one handler exactly once; cap N+1 waits and is
  admitted after a slot settles; settling emits the next Hub-window wake.
- If the settle notification callback throws, its error remains observable and
  the queued N+1 row is still pumped; the queue cannot silently stall.
- A real PendingReplyQueue harness proves the active direct-send path and the
  durable drain produce one outbound reply, not two.
- Wire assertions distinguish both runtime paths: Dashboard on a proven human
  turn emits turn/steer and zero turn/start; a bridge-task B emits no second
  turn/start until A's terminal event, then starts in FIFO order.
- Existing exact turn/steer, provenance, race, FIFO, approval, and reconciliation
  tests remain green.

L3 — Hub auth boundary and rolling idempotency
- 12 tests passed, 0 failed, 27 assertions.
- Hub-authenticated user origin, node spoof rejection, replay idempotency, and
  changed-payload conflicts remain green.

L4 — private real HTTP Hub
- 2 tests passed, 0 failed, 6 assertions.
- User tokens persist auth_origin=user; node tokens cannot spoof it.

L5 — witnessed-red mutations (all rc 1)
- node-origin-cannot-steer
- later-sse-kick-cannot-wait-for-active-turn
- same-tick-row-claim-is-unique
- detached-admission-cap-is-real
- settled-row-must-wake-next-hub-window
- throwing-settle-callback-cannot-stall-queue
- pending-reply-drain-cannot-race-active-row
- exact-expected-turn-id
- accepted-steer-must-reply
- human-turn-dashboard-must-steer-not-start
- network-task-b-cannot-start-before-a-terminal
- reconnect-network-turn-stays-fifo
- leading-whitespace-network-prefix-stays-fifo
- mcp-node-cannot-forge-user-origin
- rest-node-cannot-forge-user-origin

Production deployment remains excluded from this container result. Completion
requires independent review, a bridge-only rollout that preserves the current TUI
and app-server, and one new real Dashboard nonce proven through: authenticated DB
row → live SSE/steer while a TUI turn is active → automatic task reply → inbox ack
→ Dashboard readback.
