record(ROAD-V1-C3): punch-list item 17 calls DSpark unspiked three days after its W1-W8 landed, and files TLI under the wrong row

[localai-bot]

Closes #536. Owning row: ROAD-V1-C3 (roadmap row 3), which stays ACTIVE.

I was dispatched as a fresh implementer on punch-list item 17 of
.agents/specs/roadmap-v1-completion.md §3 — "ROAD-V1-C3 DSpark + TLI (core
spec-decode done; overlaps D3). Size M." Re-verifying the gap against the tree
first, as AGENTS.md requires, found that no clause of it survives. This is a
reconciliation, not an implementation: no src/, include/ or tests/ file is
touched, no measurement is asserted, and the GPU lock was never taken.

What git shows

Item 17 clause	Reality
DSpark "unspiked"	Spike spec landed 2b342620e (2026-08-09); SPEC-DSPARK ACTIVE since
—	W1–W8 implemented and GPU-gated; ~20 measure(SPEC-DSPARK) commits, two of them landing on main today
TLI "unspiked"	True — and it is not a DSpark tail; it belongs to SPEC-DRAFT-MODEL
"overlaps ROAD-V1-D3"	Backwards: spec-decode-breadth-d3.md §Scope puts DSpark and TLI out of D3
"Size M"	DSpark is a perf tail plus owed gates (S–M); TLI is a separate M on another row

DSpark. The lane ships qwen3_dspark.{h,cpp} + _weights.cpp,
v1/worker/gpu/spec_decode/dspark/speculator.{h,cpp}, five test files, and a
Speculators-format config adapter. W7 (#436) moved the sequential Markov sample
on device; W8 (#442) captured the T=1+k verify by mirroring vLLM's
uniform_decode_query_len = 1 + num_speculative_tokens
(v1/cudagraph_dispatcher.py:37) — same-binary A/B +12.2%/+3.5%, text
byte-identical, four e2e spec suites green with capture ON and OFF. En route it
fixed an engine-wide defect no landed gate could see: EngineCoreProc never
threaded check_for_draft_tokens, so every speculator's drafts were dropped
on the CLI and server paths. Cross-engine under pinned clocks the 35B-A3B MoE
lane is 0.975x (code cell, non-overlapping) / 1.012x (prose cell) — not
parity, and the row does not claim it; the residual is localised to
marlin_moe_wna16::Marlin and attributed to a 12.9% effective-DRAM-bandwidth
gap on byte-equivalent machine code (94 registers / 3664 SASS both sides, with
upstream doing 4.4% more work per launch). No ceiling is declared: the next
lever is cudaMemAdvise/placement on the expert slab, since upstream ncu is
blocked in both replay modes and a standalone moe_wna16_marlin_gemm harness is
the only remaining route.

TLI is filed under the wrong row, and that is the useful half

Upstream TLI is use_heterogeneous_vocab (config/speculative.py:150) plus
VocabMapping (v1/spec_decode/vocab_mapping.py:68). Both are consumed only
by v1/spec_decode/llm_base_proposer.py (SpecDecodeBaseProposer) and
v1/spec_decode/draft_model.py:19. The V2-runner speculators our DFlash/DSpark
port mirrors (v1/worker/gpu/spec_decode/{dflash,dspark}/) have no
heterogeneous-vocab path at all — so nothing DSpark lands moves TLI, and its host
row is SPEC-DRAFT-MODEL, locally a CPU propose brick with no runner
construction. TLI is prerequisite-blocked behind that row's W3, not merely
unspiked.

In particular DSpark's d2t does not cover it. d2t offsets ids inside ONE
tokenizer's vocabulary (draft_id + d2t[draft_id]); VocabMapping builds a
string-level intersection ACROSS tokenizer families, probing the space prefix at
init so a BPE draft (Ġ) can face a SentencePiece target (▁). Filing them as
one item hid a real dependency.

The surfaces reconciled

• .agents/specs/roadmap-v1-completion.md — §2 C3 row and §3 item 17
• .agents/roadmap_v1.md — row 3, the C3 area row, the DSpark grounding note,
  and intake-table rows for SPEC-DSPARK W7: the sequential Markov sample loop is HOST-side — 28% of the draft step, 14.9 MB downloaded per step #436, SPEC-DSPARK W8: capture the T=1+k speculative VERIFY shape (the measured 0.870x-0.981x gap) #442, DFlash/DSpark draft loading hardcodes the VL weight prefix, so a text-only Qwen3.5 target cannot share its embedding #513 and ROAD-V1-C3's named tail records DSpark as unspiked three days after it landed, and files TLI under the wrong lane #536
• .agents/specs/spec-decode-inventory.md — the dspark row, the lifecycle
  summary, the TLI config axis, and the "no speculators-format adapter"
  paragraph (W3 shipped that adapter)
• .agents/specs/dspark-spec-decode.md — the Status field (stale at
  "W1-W5 … W6 PARTIAL … ~2% BEHIND spec-off", 2026-08-10) plus a new §8
  recording the drift and carrying the issue link
• docs/STATUS.md — the method-surface line listed dspark among the
  INVENTORIED methods, contradicting the same page's own DSpark paragraph

Every superseded sentence is struck through and kept in place, not deleted:
it is history, and a reader must be able to see what the record used to claim.

Why the drift happened

The punch-list is written from row summaries, and those summaries were the thing
not updated — the spike went from "planned" straight into twenty-odd
measure(SPEC-DSPARK) commits while the inventory's lifecycle list and
STATUS.md's one-line method surface stayed put. Both are facts about a row
stored away from the row, which is the shape AGENTS.md's Records section warns
about: nothing fails when they drift.

Three issues (#436, #442, #513) were tracking DSpark work while absent from
roadmap_v1.md's intake table, so the "three places must agree" rule had only
two. They are listed now. Neither #436 nor #442 is closed here: #436's
device-returning block-forward half is explicitly deferred and sized in the spec
§6k, and #442 remains the tracker for the unclosed 2.5% residual.

Gates

scripts/agent-preflight.sh --staged: green, including check-agent-record,
check-doc-checkpoint, check-public-doc-tables (the docs/STATUS.md edit is
in-place and shortens the line, so no ratchet moves), check-now-current,
audit-live-rows and the mutation suites.

Not done

No GPU work and no new measurement — there was nothing to measure, and the
existing DSpark numbers are already recorded in docs/BENCHMARKS.md and the
spec. local-ai-worker was never touched and $HOME/gpu.lock was never taken.

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