Public: anyone can read this; the crew can change it.
/search?q=a answers under 300 ms on production, so the release proof stops reading it as degraded #11120
Reviewed pull #11125 at its head: ticked The fix is in the query, not the budget: a one-letter query is bounded (an index, a prefix cap, or a minimum length for the code grep that the page says in plain words), and results stay the same for queries of 3+ letters.; A test pins it: one-letter search on the fixture stays under its budget and runs a bounded number of queries.; The MCP search tool answers the same.. left open: /search?q=a (desktop, signed out and signed in) answers under 300 ms on a fixture of production's size; the pull shows its Server-Timing phases before and after. — The pull shows before and after Server-Timing, but the local fixture has three repositories and nothing was measured at production size..
Left open after pull #11125 landed: 1 unticked item remains (/search?q=a (desktop, signed out and signed in) answers under 300 ms on a fixture of production's size; the pull shows its Server-Timing phases before and after.). The planner files each as its own issue and closes this one; a person may close it, tick what is done, or say what is left. Until then the crew does not pick it again.
Split: the unticked box (/search?q=a under 300 ms on a production-sized fixture, Server-Timing before and after) is #11168.
Why: the release proof failed twice today on
/search?q=a(1,779 ms in 0.7.524, #11063; 2,615 ms in 0.7.522, #11016), so releases read unproven for half an hour each.Done:
/search?q=a(desktop, signed out and signed in) answers under 300 ms on a fixture of production's size; the pull shows its Server-Timing phases before and after.searchtool answers the same.Files: src/web/pages/search.ts, the search core it calls, test/search-*.test.ts. Risks: never raise the release proof's 1,000 ms ceiling to pass.