docs(plans): TUI streaming is not achievable — prereq spike result + honest README constraints

Backlog #2 of docs/plans/2026-07-13-tui-latency demanded a prereq spike before any
streaming design: does the transcript JSONL grow during a turn, or only at the end?
The spike was run. All three candidate sources are dead:

  (a) transcript JSONL — grows at EVENT granularity; the assistant's text event is
      written as ONE complete line, ~0.3s before the terminal turn_duration event
      (observed: turn_duration 7319ms; text event at t+7.0s, terminal at t+7.3s).
  (b) tmux capture-pane — the pane is a RENDERED view, not the text. Same turn,
      transcript T = '## Semaphore\n\nA **semaphore** is a synchronization…'
      pane        = '⏺ Semaphore' / '  A semaphore is a synchronization…'
      '## ', '**' and ```-fences are absent from the pane entirely (rendered to ANSI,
      then stripped by capture-pane -p). T.startsWith(paneText) is FALSE both raw and
      indent-stripped — not on redraw, but on essentially every markdown answer.
      capture-pane -e recovers styling, never source spelling: no unique inverse.
  (c) --debug-file — byte-exact ('last_assistant_message':'## Title\n\n**alpha…'),
      but only inside end-of-turn Stop-hook payloads; zero content_block_delta /
      text_delta events; ~2.7MB per turn.

--output-format stream-json, the only interface emitting token deltas, requires -p —
the metered-billing path TUI mode exists to avoid (cc_entrypoint=sdk-cli). The
constraint is structural. OCP's TUI SSE is, and remains, replay-only.

Also corrects this plan's own "~20s waiting for the whole turn" decomposition, which
was inferred from an external 30-32s report and never measured through OCP. Measured
through a real OCP instance (TUI, claude-sonnet-4-6, n=5): median 11.30s before #156,
9.55s after, vs a native turn_duration of ~7.3s → OCP's own overhead is ~2-4s, not
~20s. The remainder is generation time, which streaming would not shorten (it moves
the first byte, not the last) — so a consumer needing the COMPLETE answer, which is
the JSON-card case that motivated this work, would have gained nothing from streaming.

Backlog #4 measured while here: --exclude-dynamic-system-prompt-sections gives ZERO
marginal benefit (TTFT median 6.39s vs 6.17s for --effort low alone, n=5, one worse
outlier). Do not adopt. Banner stayed on Claude Max.

README: documents the ~6s TTFT floor plainly (TUI mode cannot serve interactive-latency
consumers) and states that no-token-streaming is structural rather than a missing feature.

No code change. No version bump (docs-only). Not endpoint-touching: no server.mjs diff,
so no cli.js citation applies.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VqgWJcjxrjjL9L9SkpZyXR

docs/plans/2026-07-13-tui-latency/README.md

@@ -1,7 +1,9 @@
 # TUI-mode latency: measured floor, and the four things worth fixing
 
 **Date**: 2026-07-13
-**Status**: findings + backlog (no code changed yet)
+**Status**: findings + backlog. **Superseded in part** — see the dated update boxes below.
+Item #1 shipped ([#156](https://github.com/dtzp555-max/ocp/pull/156)); item #2 is **dead**
+([`streaming-spike.md`](streaming-spike.md)); item #4 measured, **no effect**; item #3 stands.
 **Measured on**: Mac mini / macOS 26.5.2 / Claude Code **v2.1.207** / Sonnet 5 / Claude Max subscription / **real-home mode** (no `CLAUDE_CODE_OAUTH_TOKEN`, no `OCP_TUI_HOME` in the service env)
 **Evidence**: [`measurements.jsonl`](measurements.jsonl) — **n=15** (3 configs × 5) · banner captures [`billing-banner.txt`](billing-banner.txt) · harness [`floor.sh`](floor.sh)
 
@@ -47,6 +49,17 @@ All rows in [`measurements.jsonl`](measurements.jsonl); every number below is re
 before returning anything. There is no streaming path. The ~20 s delta between this harness's
 real TTFT and OCP's reported 30–32 s is exactly that.
 
+> **⚠️ 2026-07-13 correction — this decomposition attributes the ~20 s to the wrong thing.** It was
+> inferred from the external 30–32 s report, never measured *through* OCP. It has since been measured
+> through a real OCP instance (TUI mode, `claude-sonnet-4-6`, the same ~1850-token prompt, n=5):
+> **median 11.30 s** before [#156](https://github.com/dtzp555-max/ocp/pull/156), **9.55 s** after —
+> against a native `turn_duration` of ~7.3 s for a comparable turn. So **OCP's own overhead above the
+> CLI is ~2–4 s, not ~20 s.** The rest of any larger number is the model *generating a long answer*,
+> which the blocking wait does not cause and streaming would not shorten — it would only move the
+> first byte earlier. The 30–32 s figure therefore reflects a much longer output (and/or the
+> then-inherited `xhigh` effort), not 20 s of OCP dead time. See
+> [`streaming-spike.md`](streaming-spike.md) § "What streaming would have bought".
+
 ---
 
 ## ⚠️ Blocking constraint: `--bare` silently drops you off the subscription pool
@@ -105,7 +118,21 @@ the effort level silently changes if the operator ever switches to env-token mod
 - **Risk**: none — banner confirms it stays on `Claude Max` (see `billing-banner.txt`).
 - ⚠️ Do **not** reach for `--bare` to shave boot: see above.
 
-### 2. Real streaming instead of blocking on turn-terminal — **the big one (~20 s)**
+### 2. Real streaming instead of blocking on turn-terminal — ~~the big one (~20 s)~~ → **DEAD**
+
+> **2026-07-13 update — the prereq spike below was run, and it kills this item.** The transcript
+> grows at *event* granularity (the whole answer lands in one line, ~0.3 s before terminal), and the
+> pane is a **rendered** view whose `capture-pane` text no longer contains the answer's source bytes
+> (`## `, `**`, code fences are gone) — so no pane-derived stream can be reconciled with the
+> authoritative text. A third source (`--debug-file`) is byte-exact but also end-of-turn.
+> `--output-format stream-json`, the only interface that emits token deltas, requires `-p` — the
+> metered-billing path that TUI mode exists to avoid. **True token streaming is not achievable on the
+> TUI path**; OCP's TUI SSE is replay-only. Note also that streaming would never have shortened a
+> turn — only its first byte — so a consumer that needs the *complete* answer (the JSON-card case
+> that motivated this investigation) gains nothing from it.
+>
+> Full evidence, the value re-assessment, and the maintainer's options: **[`streaming-spike.md`](streaming-spike.md)**.
+> The original framing is preserved below for the record.
 
 Today `runTuiTurn` blocks on the transcript until the turn is *finished*. The pane is already
 rendering tokens incrementally the whole time — this harness proves you can observe first token
@@ -132,7 +159,14 @@ the background) amortizes it to zero for any workload below the pool refill rate
   #148 — pooled panes must not look like zombies to the sweep.
 - Lower priority than #1 and #2: it is the smallest slice.
 
-### 4. Trim the prefill — **probably not worth it; know the floor**
+### 4. Trim the prefill — ~~probably not worth it~~ **MEASURED: no effect. Do not adopt.**
+
+> **2026-07-13 update.** `--exclude-dynamic-system-prompt-sections` was measured with the same
+> harness (`floor.sh`, n=5, Sonnet 5, on top of `--effort low`): **TTFT median 6.39 s**
+> (5.87–10.54 s) vs **6.17 s** (5.87–6.44 s) for `--effort low` alone — i.e. **zero marginal
+> benefit**, within noise and with one worse outlier. The banner stayed on `· Claude Max`
+> (no billing-pool drop), but there is no win to bank. The ~6 s floor stands as stated below.
+
 
 After #1–#3, the floor is **~6 s**, and it does not go lower. `claude` always injects the full
 Claude Code system prompt + tool definitions (thousands to tens of thousands of prefill tokens)