…spatch ready (#254)

Upstream M32d KV cache for qwen3_moe inference path shipped at
paiml/aprender#1832 (open; in CI). Operator flipped from Option (b)
engineer-driven (#1829) to Option (a) in-session implementation.

Empirical (on Qwen3-Coder-30B-A3B-Instruct-Q4_K_M):
- Pre-M32d: ~0.5 tok/s (bench timed out on every per-turn budget)
- Post-M32d: 9.62 tok/s sustained on 32-token gen (19× speedup)
- Numerical equivalence vs full-prefill: byte-identical greedy outputs
- V1_001 + V1_003 (#1819 cargo test) regression: stable

V1_004 prerequisite (M32d KV cache) NOW MET. Bench discharge is
operator-actionable on a tractable ~10hr wall.

## Files

### NEW: `evidence/phase-6/m32d-shipped-2026-05-20.md`

- Upstream empirical results table
- New cargo tests pinning the invariants (equivalence + perf floor)
- V1_004 dispatch checklist (7 operator steps)
- Cross-references to all upstream PRs

### MODIFIED: `evidence/phase-6/1.5b-calibration-run.md`

- aprender#1789 line: V1_004 status flipped from BLOCKED to "prerequisite MET 2026-05-20 via M32d"
- Updated PR list with all 7 follow-up PRs (#1806, #1807, #1812, #1814, #1819, #1826, #1832)
- Added cross-reference to m32d-shipped-2026-05-20.md

## What this is NOT

- NOT a CCPA-side code change (bench script + analyzer + harness unchanged)
- NOT the V1_004 bench dispatch itself (operator-coordinated, ~10hr wall)
- NOT a new CCPA contract gate (V1_004 is unchanged; only its prerequisite flipped)

Mechanical doc update. M-counter NOT bumped per the discipline doctrine.

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

…2d (#1837)

Registers a new provable contract for temperature + top_k + top_p
sampling on the qwen3_moe inference path. Sibling to
qwen3-moe-streaming-sse-v1 (#1835); independent follow-up to
M32d (#1832).

## Motivation

`run_qwen3_moe_generate` currently does unconditional greedy argmax.
QuantizedGenerateConfig.temperature/top_k/top_p are silently ignored.
HTTP chat requests with non-zero temperature get the SAME output every
time — unacceptable for production chat.

## Why now

The V1_004 bench (paiml/claude-code-parity-apr Phase 6 against
Qwen3-Coder-30B-A3B) is hitting 900s per-turn timeout because the
30B-MoE is verbose. Temperature scaling (e.g. 0.3) could concentrate
probability mass on high-confidence tokens and reduce rambling.
Greedy-only forces ONE point on the spectrum.

## Falsification gates

- V1_001: greedy-fallback (temperature=0 OR top_k=1) → deterministic
- V1_002: temperature>0 + fixed seed → deterministic
- V1_003: temperature>0 + different seeds → different outputs
- V1_004: top_k=1 with high temperature → still equivalent to greedy

## Implementation phases (engineer playbook)

- Phase 1 (~2hr): lift dense-path sampling block into reusable helper
- Phase 2 (~1hr): wire into run_qwen3_moe_generate decode loop
- Phase 3 (~2-3hr): cargo test battery + optional companion sub-bench

Total ~5-6 hours; operator-actionable any time. Independent of
qwen3-moe-streaming-sse-v1.

NOT in scope:
- Repetition penalty (separate qwen3-moe-repetition-penalty-v1 contract)
- Mirostat / logit bias / streaming (separate concerns)

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

#1835)

Registers a new provable contract for per-token SSE streaming on the
qwen3_moe chat-completions path. This is the natural follow-up to
#1832 (M32d KV cache) — pre-M32d, streaming was
meaningless because full-prefill-per-token mode took ~30 minutes per
256-token completion. Post-M32d at 9.62 tok/s sustained, per-token
SSE emits become valuable for chat UX.

## Falsification gates

- V1_001: chat-completions with stream=true emits per-token SSE events
  (not buffered into pregenerated SSE)
- V1_002: stream=false still returns a single JSON response (regression)
- V1_003: streaming throughput ≥ 2 tok/s median inter-event time

## Implementation phases (engineer playbook)

- Phase 1 (~2hr): callback variant of run_qwen3_moe_generate
- Phase 2 (~4hr): wire into try_qwen3_moe_backend in cuda_chat_backend.rs
- Phase 3 (~2hr): cargo integration test

Total ~6-8 hours, operator-actionable once #1832 merges.

NOT in scope:
- MoE inference correctness (covered by qwen3-moe-serve-dispatch-v1)
- KV cache mechanics (M32d / #1832)
- Streaming for dense models (already exists via OwnedQuantizedModelCachedSync)
- Tool-call streaming (separate contract)

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

…3-moe-streaming-sse-v1) (#1854)

## Summary

Discharges qwen3-moe-streaming-sse-v1.yaml v1.0.0 (landed in #1835).
Post-M32d (#1832), MoE per-token generation amortizes to ~100ms; this
contract codifies that `stream=true` on a qwen3_moe model emits SSE
events per-token instead of buffering the full completion.

## Changes

- `infer/qwen3_moe_generate.rs`: add `run_qwen3_moe_generate_streaming`
  — callback variant of `run_qwen3_moe_generate`. Mirrors the
  non-streaming function step-for-step, but invokes `on_token(u32) -> bool`
  after each decoded token (BEFORE the stop check, so the client sees
  every sampled token). Callback returning `false` short-circuits the
  loop for client disconnect handling.

- `api/cuda_chat_backend.rs`: in `try_qwen3_moe_backend`, branch on
  `request.stream`. If true, spin up an mpsc channel, run the streaming
  variant on a `spawn_blocking` worker, and route the channel through
  the dense path's `true_streaming_sse_response` helper. Non-streaming
  path unchanged.

- `api/openai_handlers.rs`: promote `true_streaming_sse_response` from
  `fn` to `pub(crate) fn` so the MoE backend can reuse the same SSE
  framing as the dense path. No behavior change.

- `tests/qwen3_moe_streaming_sse_v1.rs`: env-gated integration tests
  (`QWEN3_MOE_GGUF_PATH`, `#[ignore]`'d) discharging V1_001 + V1_003:
    * V1_001: streaming callback fires per-token, captured tokens
      equal the non-streaming greedy baseline.
    * V1_003: median inter-token gap < 500ms (≥2 tok/s floor, well
      below M32d's ~5 tok/s).
    * Bonus: callback returning `false` short-circuits the loop.

V1_002 (`stream=false` regression) is covered by
`qwen3_moe_serve_dispatch_v1.rs`.

## Why

#1832 made KV cache available → per-token gen amortizes to ~100ms.
Before this PR, MoE `stream=true` requests on qwen3_moe still went
through `run_qwen3_moe_generate` (synchronous) and the client got the
full response in a single late SSE event — UX regression vs dense path.
Now the client sees the first token within `prefill_wall + 100ms` and
subsequent tokens stream at ~M32d throughput.

## Test plan
- [x] `cargo check -p aprender-serve --lib` — clean
- [x] `cargo test -p aprender-serve --lib qwen3_moe_generate` — 12/12 pass
- [ ] Operator-dispatched: `QWEN3_MOE_GGUF_PATH=… cargo test --test qwen3_moe_streaming_sse_v1 -- --ignored --nocapture` (env-gated, requires GGUF)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

…3 falsifiers PASS) (#1855)

* feat: qwen3-moe streaming SSE — per-token emit when stream=true (qwen3-moe-streaming-sse-v1)

## Summary

Discharges qwen3-moe-streaming-sse-v1.yaml v1.0.0 (landed in #1835).
Post-M32d (#1832), MoE per-token generation amortizes to ~100ms; this
contract codifies that `stream=true` on a qwen3_moe model emits SSE
events per-token instead of buffering the full completion.

## Changes

- `infer/qwen3_moe_generate.rs`: add `run_qwen3_moe_generate_streaming`
  — callback variant of `run_qwen3_moe_generate`. Mirrors the
  non-streaming function step-for-step, but invokes `on_token(u32) -> bool`
  after each decoded token (BEFORE the stop check, so the client sees
  every sampled token). Callback returning `false` short-circuits the
  loop for client disconnect handling.

- `api/cuda_chat_backend.rs`: in `try_qwen3_moe_backend`, branch on
  `request.stream`. If true, spin up an mpsc channel, run the streaming
  variant on a `spawn_blocking` worker, and route the channel through
  the dense path's `true_streaming_sse_response` helper. Non-streaming
  path unchanged.

- `api/openai_handlers.rs`: promote `true_streaming_sse_response` from
  `fn` to `pub(crate) fn` so the MoE backend can reuse the same SSE
  framing as the dense path. No behavior change.

- `tests/qwen3_moe_streaming_sse_v1.rs`: env-gated integration tests
  (`QWEN3_MOE_GGUF_PATH`, `#[ignore]`'d) discharging V1_001 + V1_003:
    * V1_001: streaming callback fires per-token, captured tokens
      equal the non-streaming greedy baseline.
    * V1_003: median inter-token gap < 500ms (≥2 tok/s floor, well
      below M32d's ~5 tok/s).
    * Bonus: callback returning `false` short-circuits the loop.

V1_002 (`stream=false` regression) is covered by
`qwen3_moe_serve_dispatch_v1.rs`.

## Why

#1832 made KV cache available → per-token gen amortizes to ~100ms.
Before this PR, MoE `stream=true` requests on qwen3_moe still went
through `run_qwen3_moe_generate` (synchronous) and the client got the
full response in a single late SSE event — UX regression vs dense path.
Now the client sees the first token within `prefill_wall + 100ms` and
subsequent tokens stream at ~M32d throughput.

## Test plan
- [x] `cargo check -p aprender-serve --lib` — clean
- [x] `cargo test -p aprender-serve --lib qwen3_moe_generate` — 12/12 pass
- [ ] Operator-dispatched: `QWEN3_MOE_GGUF_PATH=… cargo test --test qwen3_moe_streaming_sse_v1 -- --ignored --nocapture` (env-gated, requires GGUF)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* evidence: qwen3-moe-streaming-sse-v1 DISCHARGED on gx10 Blackwell

## Summary

Operator-dispatched verification of `contracts/qwen3-moe-streaming-sse-v1.yaml`
v1.0.0 (shipped via #1854). All three falsifiers PASS on Qwen3-Coder-30B-A3B
(qwen3moe arch) running on gx10 Blackwell GB10.

## Results

| Falsifier   | Test                                      | Verdict |
|-------------|-------------------------------------------|---------|
| V1_001      | v1_001_callback_fires_per_token            | PASS    |
| V1_002      | (regression guard via serve-dispatch test) | GUARD   |
| V1_003      | v1_003_inter_token_latency_floor           | PASS    |

V1_003 throughput on real 30B-MoE: **median 338 ms inter-token gap** over
32 callbacks (floor 500 ms), distribution p_min=250 ms / p_max=518 ms.
≈ 3 tok/s streamed — comfortably above the 2 tok/s contract floor and
consistent with M32d's KV-cache-amortized per-token cost.

Plus the negative-path `callback_stop_short_circuits` test confirmed
that returning `false` from the per-token callback short-circuits the
decode loop (client-disconnect handling).

## Artifacts

- `findings.json` — machine-readable discharge record
- `gx10-sse-smoke.log` — full cargo test stdout/stderr (549 lines)

Both captured from `/home/noah/runs/sse-smoke-20260521-080640/` on gx10.

## Reproducer

```bash
QWEN3_MOE_GGUF_PATH=/path/to/Qwen3-Coder-30B-A3B-Instruct-Q4_K_M.gguf \
  cargo test --test qwen3_moe_streaming_sse_v1 \
    -p aprender-serve --features cuda --release \
    -- --ignored --nocapture
```

Binary commit: 6bff4ce (post-#1854 merge).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* evidence: add gx10 cargo test log (qwen3-moe-streaming-sse-v1 discharge)

Force-added (matches `.log` gitignore pattern but this one is a
load-bearing discharge artifact, not a temp file).

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>