PR #27975 runtime verification, 2026-11-01, Linux Boat VM
main: ce9e01640636c0884c4a7574a722bf1d773cfa07
PR:   54b50f11062ab24fa9342a0a49736886d9df5136

Installed each checkout with vp i. Ran one background dev server at a time.
main: server 16733 / web 8693. Stopped captured process group before PR startup.
PR: server 13773 / web 5733. Explicit isolated home, copied from main after stopping it.
No mocks, fixtures, replay provider, or direct database writes.
Chrome: /usr/bin/google-chrome, Playwright 1.60.0 from repository dependencies.
Added /home/user/main as a project through the app; created turns via the web composer.
All four real provider turns selected Codex gpt-6.1-sol.

MAIN BASELINE
Two completed turns executed read-only git commands in the real project.
Raw turn items by run: 7, 8. Browser HTTP shell itemCount=15, visibleItemCount=15.
Reload restored both conversations and tool results.
No turn_item_counts table existed.
EXPLAIN QUERY PLAN of main's count query:
SEARCH orchestration_v2_projection_turn_items USING COVERING INDEX
orchestration_v2_projection_turn_items_thread_run_idx (thread_id=?)
This confirms the old per-item counting path; no large-history latency claim.

PR MIGRATION
Startup: Migrations ran successfully: [ '77_TurnItemCounts' ].
Stored counts backfilled to 7, 8; equal to GROUP BY over raw items.
Browser HTTP shell preserved itemCount=15, visibleItemCount=15.
Same thread history and provider results rendered after pairing and reconnect.
New query plan searches turn_item_counts USING PRIMARY KEY (thread_id=?).

NEW TURN, SAME CODEX SESSION
Sent read-only git commands through the upgraded web composer.
Observed real shell WebSocket thread.updated counts:
15 completed -> 16 starting -> 16 running -> 17 -> 18 -> 19 -> 20
-> 20 waiting -> 21 completed.
COUNT_AFTER_OK rendered in the client.
Stored run counts: 7, 8, 6. Raw GROUP BY matched exactly.
Repeated streaming upserts did not inflate counts.

FORK NEIGHBOR
Clicked Fork from this response on the first completed response.
Fork rendered only the first source run and the fork marker.
HTTP shell: own itemCount=0, visibleItemCount=8.
Sent a real Codex turn in the fork; COUNT_FORK_OK rendered.
WebSocket own counts 1 -> 2 -> 3 -> 4 -> 5; visible counts 9 -> 10 -> 11 -> 12 -> 13.
Reload preserved HTTP shell own=5, visible=13; raw items and stored counts matched.

ROLLBACK NEIGHBOR
On source third user message clicked Edit from here, then Revert and keep changes.
Provider rollback completed. Third run status became rolled_back.
The run's 6 raw items and stored count remained intact.
HTTP and WebSocket shell counts excluded that run: source 21 -> 15.
Reload showed original two runs; prompt returned to composer.
Fork remained own=5, visible=13.

CHECKS
Blacksmith: 69 focused tests passed across migration, preview migration,
ProjectionStore and ShellStream.
Blacksmith: vp run check:changed 7195b699547b538e49f758e314dde5c8c5d907cf passed
format, lint, knip, GraphQL, 3 package typechecks and 61 tests in 5 files.
Latest GitHub CI: all applicable checks passed (others skipped).
No source changes needed.

NOT VERIFIED
Native mobile and desktop shells, other providers, remote/relay/tunnel modes.
Large-history speedup and cold-cache latency: this intentionally small real dataset
proves integration and count correctness, not production-scale performance.
Delete/move triggers were covered by focused existing tests; projection repair was
not induced through a destructive runtime scenario.