A repository's home answers under 50 ms on the server: `now` and `following` under 5 ms each for trevato/forge #6188

An app's home now builds now in about 3 ms on a fixture with 400 open issues, 40 open pulls and 5 active runs, down from about 8 ms. following was already fast, and I changed nothing for it. The new test asserts both under 5 ms. The tsc check, design-lint and 748 tests across the app, studio, tell, words, dependencies, now, issues and home suites pass. I did not run the whole suite.

What changed

• now card (src/web/studio/now.ts): it now reads the checks and reviewers for its open pulls, and the pulls behind its finished runs, in one pass with knowPulls and knowRunPulls. Before, it did those reads once per row.
• Held tells (same file): these are now worded in one call, tellWords, instead of one tellWord each. That call cost about 4 ms, almost all of it building the whole-repository dependency graph just to ask whether five tells are deferred.
• Skipping the graph (src/web/studio/tell.ts, src/core/dependencies.ts): a new linkedIssueIds makes one query for which of the page's issues sit on a dependency edge. An issue on no edge is never deferred, unless its title starts with "Later". That is the umbrella pillars.ts finds by title, so it still goes through the graph.
• What the sections show: unchanged. Tells with edges, and any "Later" issue, still read deferral from the graph.

following

• Already fast: the git comparison is cached by the two branch tips from #6127, so following was already 0.4 ms on a diverged, unmergeable fork. The 18.6 ms in the issue looks like that uncached read. I did not touch it.
• Per viewer: nothing is cached across viewers.

Test: test/app-home-batched.test.ts builds the fixture on an app and on a fork whose README conflicts with its parent's. It reads Server-Timing from a real request, takes the best of six, and asserts now and following each under 5 ms. It checks that the fork's card says "one file needs a decision", so the converge path is the one measured.

Left out: the shipped (11.5 ms) and panels (10.7 ms) phases from the issue's measurement, and the 50 ms total. I did not re-measure on production data; the 400/40/5 figures are a synthetic fixture.

Try it: bun test test/app-home-batched.test.ts, or open an app's home and read now;dur= in Server-Timing.

Closes #6184

An app's home now builds now in about 3 ms on a fixture with 400 open issues, 40 open pulls and 5 active runs, down from about 8 ms. following was already fast, and I changed nothing for it. The new test asserts both under 5 ms. The tsc check, design-lint and 748 tests across the app, studio, tell, words, dependencies, now, issues and home suites pass. I did not run the whole suite.

What changed

• now card (src/web/studio/now.ts): it now reads the checks and reviewers for its open pulls, and the pulls behind its finished runs, in one pass with knowPulls and knowRunPulls. Before, it did those reads once per row.
• Held tells (same file): these are now worded in one call, tellWords, instead of one tellWord each. That call cost about 4 ms, almost all of it building the whole-repository dependency graph just to ask whether five tells are deferred.
• Skipping the graph (src/web/studio/tell.ts, src/core/dependencies.ts): a new linkedIssueIds makes one query for which of the page's issues sit on a dependency edge. An issue on no edge is never deferred, unless its title starts with "Later". That is the umbrella pillars.ts finds by title, so it still goes through the graph.
• What the sections show: unchanged. Tells with edges, and any "Later" issue, still read deferral from the graph.

following

• Already fast: the git comparison is cached by the two branch tips from #6127, so following was already 0.4 ms on a diverged, unmergeable fork. The 18.6 ms in the issue looks like that uncached read. I did not touch it.
• Per viewer: nothing is cached across viewers.

Test: test/app-home-batched.test.ts builds the fixture on an app and on a fork whose README conflicts with its parent's. It reads Server-Timing from a real request, takes the best of six, and asserts now and following each under 5 ms. It checks that the fork's card says "one file needs a decision", so the converge path is the one measured.

Left out: the shipped (11.5 ms) and panels (10.7 ms) phases from the issue's measurement, and the 50 ms total. I did not re-measure on production data; the 400/40/5 figures are a synthetic fixture.

Try it: bun test test/app-home-batched.test.ts, or open an app's home and read now;dur= in Server-Timing.

I've fixed all three points from sentinel's review and pushed. test/flake.test.ts, test/app-home-batched.test.ts, the studio, tell and words suites, and tsc all pass.

• Raw ms bounds (High): both speed checks now use expectBudget(…, { ms: 5, against }) with against = await baselineMs(servers.url). No test title says "under N ms".
• Deferral shortcut (Medium): tellWords now records which issues the batch covered (read.covered). tellWord skips the dependency graph only for those issues, so any other issue on the same wordCtx goes through the graph as before.
• Fixture size (Minor):

- Fixture: it is cut from 400 to 200 open issues per repository, still with 40 pulls and 5 runs. It still makes four git commits. - Sleep: I kept the 500 ms sleep. The parent's push is followed asynchronously, and that sleep is what lets the fork settle into the diverged state the test needs. - Following test: it is renamed "regression guard; this pull does not change it", and I kept it so the converge path stays measured.

I've addressed both of juniper's points and pushed. The new tests, the existing studio, tell and words suites, and tsc all pass.

Correctness test for the deferral shortcut. test/tell-deferral.test.ts is new, and each case checks the batched answer against the graph path:

• linkedIssueIds returns exactly the issues on either end of an edge. It is empty for an empty list and for issues on no edge.
• tellWords words an issue on an edge as deferred: …, identical to what tellWord gives without the shortcut.
• An issue on no edge gets the same words with the shortcut as without it.
• A Later: umbrella on no edge still goes through the graph and comes out deferred.
• An issue outside the batch, worded on the same WordCtx while the batch is in flight, still gets the graph path.

I checked the tests catch regressions: removing the Later-title guard fails the umbrella test. Removing the covered guard fails four of the five.

Naming the Later-title rule. The /^later/i regex now lives in src/core/pillars.ts as LATER_TITLED, next to the TITLED SQL it mirrors. tell.ts imports it instead of keeping a second copy. I did not add the onNoEdge(read, issue) helper juniper suggested; the condition is still inline in tellWord.

Tidying test/app-home-batched.test.ts. The transaction body is re-indented. The fixed 500 ms sleep is replaced by polling forkRelation until the fork reads diverged, checked every 30 ms for at most 3 s.