P0: the home page takes ~7 s: the KPI/panel caches never hit (keyed on the write stamp) and readKpis costs 4.4 s on every load #7494

The owner, 2026-10-27: "the forge home page takes awhile to load. this is frustrating."

Measured just now, as the owner, 3 loads: about 7.0–7.7 s to first byte. Server-Timing on each load:

• kpis 4,301–4,603 ms
• panels 811–1,034 ms
• feed 281–354 ms
• render 246–281 ms
• asked 122–141 ms

/healthz answers in 0.3 s. And because the forge is one process, 4 s of synchronous work on a request stalls every other request too.

Cause: cachedKpis / cachedPanel / cachedVitals (src/web/studio/home_cache.ts) are keyed on writeStamp(db): valid only while nothing has written. The forge writes every second (runs, events, the crew), so the cache never hits, and every home load recomputes readKpis (4.4 s) and the pinned panels.

Done when:

1. Serve stale while it revalidates. The home reads the last KPI, panel and vitals answer when it's under 60 s old, whatever has been written since. When it's older, the request still gets the last answer, and one background refresh runs off the request path (one at a time per key). Only a cold start computes inline.
2. readKpis itself stops scanning whole tables on the request path. Find what costs 4.4 s (likely 7-day aggregates over run/event) and read bounded indexed ranges, or keep a rollup updated as rows arrive.
3. Tests:

- Two home loads 1 s apart, with 50 writes between them: the second has kpis under 50 ms (a cache hit). - Past 60 s, the response is still under 50 ms, and the refreshed value appears on the next load. - A budget test: home for an admin answers within its budget against the baselineMs floor.

1. The steward re-measures in production: home TTFB under 1 s warm.

Live triage (automatic, not written by a person): filed under P0 Trust, which it names.

Parked by the crew: the check stayed red through 2 automatic tries (pull #7501 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check failed ("on production's size > a cold home answers within a few passes over the runs, kpis read afresh") and the decider saw no point in another try try 1: docs/CACHING.md, src/core/migration-pins/20261027140000-pull-merged-oid-index.pin, src/core/migrations/20261027140000-pull-merged-oid-index.ts, src/kern… (pull #7601 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check stayed red through 2 automatic tries (pull #7501 closed)
2. the check failed ("on production's size > a cold home answers within a few passes over the runs, kpis read afresh") and the decider saw no point in another try try 1: docs/CACHING.md, src/core/migration-pins/20261027140000-pull-merged-oid-index.pin, src/core/migrations/20261027140000-pull-merged-oid-index.ts, src/kern… (pull #7601 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Planner: split. Both tries tried to do everything in one pull (caching, the query, a migration) and went red on the production-size home test. Now four small pieces, each with its own test: #7624 (60 s cache, not keyed on the write stamp), then #7625 (stale answer, refresh off the request path); #7626 (Server-Timing per readKpis part), then #7627 (landings without the correlated NOT EXISTS, no migration). The steward re-measures home TTFB in production once #7625 and #7627 land.