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.

--------------------------------------------------------------------------------
#1268 addendum — 2026-10-15 (Asia/Shanghai)
Base: origin/main 2404bc53d148d78a30954fc448c9926b00b0af00
Why: on this base the suite was FAILING (L0-L4 green, L5 red) with
     `MUTATION_FALSE_GREEN: detached-admission-cap-is-real`.

Root cause of the false green (oracle gap, not a product regression)
- run.sh applies `activeKeys.size < opts.maxConcurrent` -> `true` in
  agent-node/src/inbox-dispatch.ts and expects agent-node/src/inbox-dispatch.test.ts
  to notice. No test noticed.
- Why it was invisible: for an ORDINARY queue head, the reserved-slot gate
  (`if (!queue[0].priority && activeOrdinaryKeys.size >= opts.maxConcurrent - reserved) break;`,
  inbox-dispatch.ts:107) breaks the pump before the global cap can matter. Removing
  the cap therefore changes nothing any ordinary-only case can observe.
- A PRIORITY head skips that break, which makes the global cap the only thing
  bounding admission — and so the only case that pins it. Before this change the
  test file never used `prioritize` or `reservedPrioritySlots` at all.

Change (observation point added; the mutation is NOT changed or relaxed)
- New case "a priority row cannot exceed the detached admission cap":
  maxConcurrent 1, two priority rows; admission must stay {active:1, queued:1}
  synchronously, and the second row must start only after the first slot settles.
- No assertion removed, no negative control deleted, no mutation anchor rewritten.

Witnessed-red evidence (same checkout, same anchor replacement mutate.ts performs)
- Unmutated: `bun test agent-node/src/inbox-dispatch.test.ts` -> 14 pass, 0 fail, 36 expect() calls.
- Mutated:   `bun test agent-node/src/inbox-dispatch.test.ts` -> 13 pass, 1 fail —
  the new case reads `{active: 2, queued: 0}` where `{active: 1, queued: 1}` is
  required, i.e. the mutation is detectable again.

Full-suite evidence (Docker, exact suite, real hub + real HTTP):
  command: QA_L1_ONLY=test584-dashboard-codex-delivery bash scripts/qa.sh --l1
  ✓ L1 test584-dashboard-codex-delivery (RESULT: PASS)  [L1+99s..173s, 74s] rc=0
  ✓ ALL PASS in 174s
  L2: 104 tests passed, 0 failed
  L5: all 15 mutations rc=1, including
      MUTATION_RED: detached-admission-cap-is-real rc=1   <- was MUTATION_FALSE_GREEN on 2404bc53
