record(ROAD-V1-C6): punch-list item 9 asks for a lever the project refuted and a flip that landed 10 days before the item was written

[localai-bot]

Closes #534. Owning row: SERVE-ASYNC-LLM (roadmap row 6, ROAD-V1-C6), which stays
GATING. Roadmap issue table, spec and this body all carry #534.

I was dispatched as a fresh implementer on punch-list item 9 of
.agents/specs/roadmap-v1-completion.md §3, whose recorded W-plan was "land the depth-2
throughput lever, flip runner_supports_async prod-ON, close priority/busy-loop GPU
gates". Re-verifying the gap against the tree first, as AGENTS.md requires, found two
clauses already stale on the day the spec was committed and the third half covered.
This is a reconciliation, not an implementation: no src/, include/ or tests/
file is touched and no lifecycle state moves.

Clause by clause

Item 9 clause	Reality	Evidence
land the depth-2 throughput lever	Landed 11 days before the item was written, and REFUTED in the same commit	6ea7856 (2026-07-16)
flip runner_supports_async prod-ON	Flipped 10 days before, default-ON since	a0013a2 (2026-07-17)
close priority/busy-loop GPU gates	busy-loop covered since 2026-08-05; priority genuinely open	1718bf155, 52d76f3a9 / nothing

The spec is 489f7771, 2026-07-27.

1. The lever is not merely landed, its objective was retired

6ea7856 implemented AsyncOutputPool (persistent sampled-id/pinned buffers plus a
Sampler greedy scratch, removing every per-step cudaMalloc/cudaFree/cudaHostAlloc/
event-create from the sampled-id path, including the overlap-killing cudaFree inside
get_output). Its own commit title carries the verdict: lever REFUTED as tput unlock,
c16 throughput -0.32% against a >=+1.5% gate, because the removed syncs are
O(10-100 us) of a ~165 ms step.

The next day CLAIM-W3-ASYNC-DISC measured vLLM's OWN async self-A/B and found upstream
pays -0.66 to -0.91% throughput for async scheduling and ships it as the default
anyway. async-serving.md records the conclusion verbatim: "There is NO depth-2
throughput unlock to find, D6's search target does not exist in the reference either",
and "The speed-credit floor for W3 as a lever is retired with it". Acting on this
clause reopens a closed negative result, which is worse than acting on a stale one.

2. runner_supports_async and SERVE-ASYNC-LLM are different things, and both are already on

VT_ASYNC_RUNNER has been default-ON since a0013a2 via the CPU-unit-tested
AsyncRunnerFlagIsOn predicate (include/vllm/v1/worker/gpu/async_runner_flag.h:38), so
with no environment set runner_supports_async() is TRUE and LoadedEngine resolves an
AsyncScheduler + max_concurrent_batches=2. DGX-proven token-neutral: 27B 235/235 and
35B 315/315, default arm bit-identical to both rollback arms.

The item's title and the §1 C6 cell instead read "SERVE-ASYNC-LLM (GATING -> prod-ON)",
which conflates that runner-side default with a different row. SERVE-ASYNC-LLM is the
AsyncLLM streaming serving API, and it is likewise already the production path:
src/vllm/entrypoints/openai/server_main.cpp:731-734, "the production server uses
AsyncLLM over EngineCoreProc's dedicated engine thread", with the capacity-derived fixed
HTTP worker pool as the default and VLLM_CPP_HTTP_FIXED_POOL=0 retained only as a
same-binary diagnostic. Reading GATING as "not in production" is the error; the row is
GATING on its declared broader every-axis parity (27B ratified at 115/124 two-grid
effective, 35B open under ROAD-V1-A) plus open bug #294.

That also unblocks a consumer on paper. BACKEND-GATE-CUDA-SGLANG records
BLOCKED on SERVE-ASYNC-LLM with the rationale "HTTP TTFT/ITL cannot be measured
honestly yet", which describes the pre-W2 buffered-SSE server. The exit criterion
that spike actually attached to the row, "Real incremental SSE, in-flight batching, and
streaming timing test pass", was met on 2026-07-10; the arrival-time assertion is
tests/vllm/entrypoints/openai/test_api_server.cpp:622-634
(dispatched < first_arrival < completed), and SERVE-GATE-ONLINE has since measured
HTTP TTFT/ITL on that exact path against vLLM across five recorded bindings. Its residual
dependency is its own exact-equivalence preflight.

3. The third clause is half stale and half the only real work in the item

ENG-CORE-BUSY-LOOP G1 (token-exact twins) has been covered in substance since
1718bf155 (2026-08-05): tests/parity/test_qwen36_async_serving.cpp drives
LoadedEngine::async_engine() -> AsyncLLM -> EngineCoreProc::step_with_batch_queue
(depth-2) token-exact against the same pinned oracle continuation the SACRED sync gate
uses, proven RED->GREEN on GB10 under compute-sanitizer, with the classic-dense arm
test_qwen3_dense_async_serving.cpp (52d76f3a9) alongside. G4 is covered by the
SERVE-GATE-ONLINE binding 9ecd9d0 114/124, which runs that path with async default ON.
I did not promote the row: rerunning a gate is the operator's job.

ENG-PRIORITY-SCHED is the one genuinely open leaf. --scheduling-policy priority
is plumbed all the way to the production server (server_main.cpp:408-411,672-673 ->
SchedulerPolicyFromString -> SchedulerConfig::policy), but no priority-vs-FCFS gate
exists at the engine or model level anywhere under tests/. What exists is scheduler-unit
(test_scheduler.cpp:674,916 ordering and preemption, test_request_queue.cpp heap
ordering) and C-ABI wire-name validation (tests/capi/test_capi.cpp:1159); nothing drives
a real engine with policy=kPriority and compares token streams. So its G1 cannot be
"rerun" as both the item and the row imply, it has to be written first, RED-first.

Both rows still record "deferred to the next GPU-idle window, GPU held by the
SERVE-GATE-ONLINE campaign", a 2026-07-10 scheduling note that five successive
bindings have since expired. That phrasing is what makes the item read as GPU-blocked
when it is not.

The surfaces reconciled

• .agents/specs/roadmap-v1-completion.md, §3 item 9 (the punch-list entry), the §1 C6
  cell, and item 5's ROAD-V1-A SGLang clause
• .agents/engine-matrix.md, the SERVE-ASYNC-LLM, ENG-CORE-BUSY-LOOP and
  ENG-PRIORITY-SCHED rows; also repoints one stale local anchor that ARCH-ONE-SURFACE
  (arch(ARCH-ONE-SURFACE): the OpenAI server becomes a THIN ABI CLIENT — vllm_server_main, ABI v17 #189) moved out of examples/server/main.cpp
• .agents/backend-matrix.md, the BACKEND-GATE-CUDA-SGLANG blocker rationale
• .agents/coordination.md, queue rows 2 and 6, whose "next handoff" still directs
  CLAIM-ASYNC-SCHED-W3 to land a flip that landed
• .agents/specs/async-serving.md, a ## Now reconciliation section carrying Punch-list item 9 (ROAD-V1-C6) directs a lever the project refuted and a flip that landed 10 days before the item was written #534
• .agents/specs/roadmap-v1-audit-2026-07-31.md, whose finding 4 is where the
  "GATING, not prod-ON" reading originates
• .agents/roadmap_v1.md, the issue-table row for Punch-list item 9 (ROAD-V1-C6) directs a lever the project refuted and a flip that landed 10 days before the item was written #534

Every superseded sentence is struck and kept in place, never deleted. The old text is
what the plan said, and a reader has to be able to see both the claim and its correction.

docs/FEATURES.md

check-doc-checkpoint classifies .agents/backend-matrix.md as a feature surface and
requires docs/FEATURES.md to move with it, and a checker's message is the authority on
what it enforces. Its Priority scheduling cell read ◐ gating, which overstates
readiness in exactly the way this PR corrects, so it now names the reachable flag and the
missing gate. One existing cell amended, no new row or paragraph: the page is a keyed
table with a 220-char cell cap and no paragraph headroom. No other public doc moves,
because no row changed lifecycle state and no measurement was recorded.

Gates

scripts/agent-preflight.sh --staged: All gates green, including doc-checkpoint,
check-public-doc-tables, check-gate-commands, audit-live-rows, now-current,
check-role-discipline, the trailer suites and every mutation suite.

An earlier run of the same command was red on test_cpu_x86_llamacpp_floor, which reads
the real host loadavg and is #529, not this branch; it passed on the quiet re-run.

Not done

No GPU work and no new measurement: there was nothing to measure. The dgx GPU lock was
never taken and local-ai-worker was never touched. The branch is
row/SERVE-ASYNC-LLM-534 rather than row/SERVE-ASYNC-LLM because a stale remote branch
of the latter name already exists at 8a8bed99 (the pre-squash form of #31, whose content
is on main as 1718bf155); pushing over it would have been a non-fast-forward.

Needs a fresh reviewer who is not me. Merge authority is not mine.