Ship and explain the SSE token relay

A shippable lab artifact includes: how to run it, the metric result (time-to-first-byte, event count, cancel stops within N events), the failure you can still reproduce (buffering the whole answer before first byte, or ignoring client disconnect), the security gate for streaming secrets from upstream error bodies to the browser, and a rollback note. The user decision it supports remains: stream tokens to a client while honoring cancel and partial failure.

RUN_LIVE_EVALS=1 npm run test:live

Expected evidence: **The client renders “Hello 👋” in order, receives done once, and closes cleanly.**. Store this beside the fixture version so scores remain meaningful after content changes in `streaming-responses`.

State operating limits for the SSE token relay in plain language: fixture size, offline vs live dependencies, and what would require a new eval set. Shipping streaming-responses is honest scoping, not maximal confidence language.

Fill this table in your notes for the SSE token relay:

• Proved on fake chunk iterator yielding three tokens then done: …
• Unproved beyond the fixture: …
• Metric that blocks release: time-to-first-byte, event count, cancel stops within N events
• Failure still reproducible: buffering the whole answer before first byte, or ignoring client disconnect
• Security gate: streaming secrets from upstream error bodies to the browser
• Rollback: …

Ship the narrative only when the unproved list is honest. Reviewers trust narrow claims that support stream tokens to a client while honoring cancel and partial failure more than maximal language that collapses under the first production oddity.

Hand your ship note to a peer and ask them to recreate a proved/unproved ship note with rollback without watching you type. If they cannot, your evidence is still tribal knowledge. Tighten the run command and the metric line until a stranger can validate the SSE token relay against fake chunk iterator yielding three tokens then done.

At the mastery and shipping stage for streaming-responses, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about fake chunk iterator yielding three tokens then done that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: non-streaming JSON endpoint latency for the same prompt.

For this page specifically, success looks like a proved/unproved ship note with rollback while still centering the user decision to stream tokens to a client while honoring cancel and partial failure. If you cannot point to a file, command, or assertion that proves that for the SSE token relay, stay on this page instead of advancing.

Glossary: tool · Glossary: structured output · Cheatsheet: production ops signals

Previous