pr 22356 real-dev verification, linux x64, node v24.22.1
baseline github/main: e5909e53c32a9d5b51caf6352d1f17fd73e86db7
exact pr head: 1eb4c26d8c29e223a80561dd9169784b3d574290

setup:
  git worktree add ../main github/main
  vp i (main and pr, successful)
  background vp run dev --no-seed (main ports 16733/8693)
  stop main by captured timeout pid before starting pr
  copy the stopped, app-created state into the pr's isolated .t3
  sqlite quick_check: ok; 152 items, 3,519,332 payload bytes
  background vp run dev --home-dir /home/user/t3code/.t3 --no-seed (pr ports 13773/5733)

real user/provider path:
  playwright 1.60.0 and /usr/bin/google-chrome
  add local project /home/user/cache-verification through the web app
  select codex gpt-6.1-sol; send real provider turns through the local proxy
  main: 14 completed turns; 104 persisted command items; read README/git status,
        real repository history commands, and 11 short replies to cross history boundary
  no mocked providers, inserted projection records, fixtures, or demo data

live connection inspection (node inspector, existing running DatabaseSync instances):
  main statev2 writer and four reader workers: cache_size=-2000, mmap_size=0
  pr statev2 writer and four reader workers: cache_size=-262144, mmap_size=2147418112
  after pr restart: writer and all four newly created reader workers retain tuned values
  separate server-owner database keeps defaults; checkpoint worker is outside tuning scope
  inspector scans pause the event loop; no speed conclusion uses those pauses

real server/client behavior:
  authenticated bounded snapshot with the client's compact/deferred query flags: HTTP 200
  main and pr: 30 recent items plus 122 older items; every id and payload identical
  web UI: switch threads, reopen, load earlier turns, scroll to original reply
  pr: submit follow-up through web composer using codex gpt-6.1-sol
  four concurrent clients x eight snapshot requests while the turn starts/runs:
    all 32 responses HTTP 200; observed completed/starting/running run states
  follow-up completed in 24 seconds, read README and git status, returned:
    CACHE-PR-FOLLOWUP
    sqlite cache verification repository
    git is clean.
  restart the pr dev server against the same isolated state, reload the web client:
    33 recent items identical to pre-restart snapshot; final reply still visible

existing focused checks, remote blacksmith worker:
  vp test run apps/server/src/persistence/Sqlite.test.ts packages/shared/src/nodeSqliteClient.test.ts
  2 files passed, 21 tests passed
  hosted head checks: 28 successful, 0 failed, 0 pending
  no source changes, commits, or pushes required

performance limits:
  original multi-second, 11,911-item stall was not reproduced on this 152-item history
  exploratory sequential samples were mixed:
    12 authenticated compact bounded reads: median main 183.55 ms, pr 100.60 ms
    7 sidebar reopens to the visible latest reply: median main 713.13 ms, pr 1336.33 ms
  these are small, sequential dev samples with compiler/warmup variability and differing
  main/pr revisions, not a controlled benchmark or proof of the claimed speedup
  production-scale latency, peak RSS, macos/windows, native desktop/mobile,
  remote/relay/tunnel modes, and other providers remain unverified

media:
  full-size screenshots inspected; video lead-in splash/loading frames trimmed
  uploaded 37.2-second video played and sought in t3's rendered browser player