# Proof audit pass 1

Issue: [#20427](https://git.cafe/pingdotgg/t3code/issues/20427)

Scope: branch `fix/issue-20427`, [ef0c03176a](https://git.cafe/pingdotgg/t3code/commit/ef0c03176a85979d4dae9d826043181ea7599fee), compared with [6e79211743](https://git.cafe/pingdotgg/t3code/commit/6e792117436662208bf2b6eb71ee8d0d88817e43). Complete diff inspected: two server files, 306 insertions and 29 deletions. Checkout clean at inspection. No PR. This audit changed no repository files, ran no server/browser/tests, and made no forge writes.

## Visual fixture matrix

**Empty: 0 affected visual rows.** The server-only exception applies. The production change caches an existing timeline index, validates its event sequence within read transactions, and invalidates indexes on projection apply. It changes no component, styling, navigation, client contract, or intended rendered output. Per the requested proof rule, the proof is a red regression test plus runtime transcript, with backend correctness checks below. Faster loading alone does not require invented screenshot rows.

## Callers, surfaces, and conditional shapes traced

- `ProjectionStore.getThreadHistoryPage` -> Orchestrator -> ThreadManagementService -> orchestration HTTP `threadHistoryPage`. Shared client-runtime `loadEarlier` reaches it from web ChatView/MessagesTimeline and find navigation, desktop through web, and mobile ThreadRouteScreen. Ordinary older-history requests use activity; targeted `throughEntryId` requests load conversation first and activity second. Local, remote/relay, and tunnel use the same server path. No transport or authorization changes.
- `ProjectionStore.getTimelinePage` -> Orchestrator -> ThreadManagementService -> MCP `OrchestratorMcpService.readThread`. Agent reads (including scheduled agent execution) use `messages` or `activity`, forward positions/limits, or item-ID selection. No provider adapter changed; index behavior is provider-independent.
- History branches: user-turn-aware vs tool-only item/byte-bounded history; conversation filtering; targeted entry extension; cursor identity/position fallback and revision change; deleted/missing threads; current payload hydration vs cached identity/visibility metadata.
- Timeline branches: messages/activity filters; `afterPosition`; `itemId` (bypasses ordinary filtering); synthetic rows vs database hydration; totalItems/hasMore.
- Index branches: non-fork; run fork; recursive/nested fork; cycle guard; missing source run; inherited items through fork boundary; imported runless history; synthetic fork marker; rollback/cancellation/interrupt visibility; source/local updates.
- New cache branches: miss; unchanged-sequence hit; sequence mismatch; apply invalidation for local or any recorded ancestor; unrelated thread event; eight-entry insertion-order eviction; reader transaction interleavings and failed/rolled-back writes.
- Search/search stream still call uncached `readTimelineIndex`; initial bounded snapshots use their existing path. Settings, command palette, keybindings, reverse actions, and provider-specific controls gain no new behavior or entry point.

## Evidence inspected (baseline only)

1. `/tmp/issue-20427/red-test.txt` is a **reported red-step summary**, not raw runner output. It identifies the base and test-only commit and reports history 4 whole-thread reads over 4 pages, and timeline 6 over 6 pages (second assertion checked with the first temporarily disabled), against a maximum of 1. It reports all 600 unique items and 37 other passing tests. This supports the intended regression, with provenance limited to the report; retain raw red command/output if stronger reproducibility is required.
2. `/tmp/issue-20427/run13000/result.json`: base sourceRef matches; Node v26.12.1; all three repetitions return 13,000 items over 73 pages; full-scrollback median 5,399.7 ms; per-page median 72.93 ms. This is in-process, warm synthetic workload, not network or UI time.
3. `/tmp/issue-20427/runtime-before.json`: 13,000 items, 73 pages, total 7,539.9 ms with per-page timings. User identifies it as the real HTTP browser transcript. The JSON itself contains timings/counts, but no endpoint, source revision, HTTP statuses, request IDs, or item identities; retain the surrounding run metadata for independent provenance.
4. Harness README/manifest inspected: single completed run, mixed synthetic user/assistant/command payloads, warmup plus three measured walks. Original issue timings use an older source/runtime and are not this baseline.

**After run is in progress. No after result, green test, speedup, or completed runtime verification is claimed by this audit.**

## Backend proof requirements (not visual rows)

- **Regression red/green:** retain the red report (prefer raw runner transcript with exact command/revision); execute the focused new test and relevant existing paging/fork/ThreadFind tests on the final head. Both APIs must avoid repeated full-index SQL scans while preserving exact ordered identities, no omissions/duplicates, cursor termination and page metadata. The new test proves unique count but does not directly assert duplicate-free total or exact order; its second API walk may reuse the first API's cache. Include an independently cold timeline walk or trace demonstrating each API's cache behavior.
- **Comparable runtime:** same 13,000-item fixture, Node, host and process conditions, warmup and repetitions on final head; retain revision, commands, counts, pages and raw timings. Repeat real HTTP walk with equivalent request/view/cursor parameters and 13,000 items/73 pages, recording endpoint/status and source metadata without tokens. Separate in-process vs HTTP results. Explain any page/count difference; do not combine their timing denominators or claim client rendering/motion improvement from fetch timings.
- **Freshness:** warm each API, then apply local add/update/delete, run/attempt visibility changes, rollback/cancellation/interrupt changes and thread deletion; subsequent reads must match uncached behavior. Exercise committed event-sequence mismatch separately from direct apply/replay invalidation, since the new test's direct apply only proves the latter. Payload-only changes must hydrate current values; metadata changes must rebuild visibility/order as needed. Unrelated writes should preserve reusable cache entries.
- **Forks:** warm a fork and nested fork, update each ancestor and local thread, verify next page and totals; preserve inherited cutoff, rollback behavior, synthetic markers, missing source-run behavior, imported runless items and cycle termination. The added test covers one source append and fork timeline total; it does not by itself prove all fork/history combinations.
- **Paging semantics:** exercise ordinary vs targeted/conversation-then-activity history, no-user-turn budget fallback, absent/stale cursor anchor and throughEntryId, empty history; timeline messages/activity/itemId/forward limit boundaries. Existing focused tests may supply unchanged semantics, but ensure cache is warm when checking transitions.
- **Boundedness/interactions:** walk more than eight independent threads and revisit evicted ones; verify rebuild correctness and cache size bound. Use deterministic barriers/transactions (no sleeps) for reader/writer interleaving and rollback so a cached index is never accepted for a different database snapshot. This matters because the cache lives outside SQL transactions and apply invalidates before its SQL work.
- **Limits:** cache removes repeated SQL/index construction, but history and timeline still map/filter the visible array per page. Do not describe the implementation as fully page-size-only or universally linear scrollback. Eight entries bound entry count, not total bytes; record long/forked-thread memory if making a memory claim.

## Friction

- EVIDENCE_PROVENANCE | Red evidence is a summarized report; HTTP JSON lacks request/revision metadata. | Retain exact commands, head/base, raw runner output and sanitized HTTP context with each run.
- COVERAGE | Added test covers scan reuse and one fork-source append, but not warm-cache visibility transitions, sequence-only invalidation, eviction or deterministic transaction interleavings. | Use the focused backend requirements above; reuse existing fixtures and assert observable output.
- CLAIM_SCOPE | Baseline in-process and HTTP timings differ, and the after run is unfinished. | Label measurement layers separately and defer improvement claims until final-head results exist.

VERDICT: SUFFICIENT (matrix plan)