Public: anyone can read this; the crew can change it.
The /apps list answers a warm request under 50 ms and works with JavaScript off, and a test holds both #9752
Reviewed pull #9757 at its head: ticked A test renders /apps as a signed-in user with a few apps twice and, on the second (warm) answer, reads the app phase of Server-Timing the way appMs in test/search-page.test.ts does, and checks it is sent (not NaN). The 50 ms bound is held as work, as #4429 asks: a bounded statement count via requestStatements and expectWork that does not grow with the number of apps.; A test checks that the list's content has no <script> or inline handler its function depends on: each app is a plain link, and the new-app step is a plain <form method="post"> with a same-origin check.; If either test fails on main, fix src/web/pages/apps.ts, not the test.; bun scripts/design-lint.ts and test/apps-timing.test.ts, test/apps-fit.test.ts pass..
For: the box #9711 left open. The list was restyled in #9728, but no test shows it stays fast or works without scripts.
Done looks like:
appphase of Server-Timing the wayappMsin test/search-page.test.ts does, and checks it is sent (not NaN). The 50 ms bound is held as work, as #4429 asks: a bounded statement count viarequestStatementsandexpectWorkthat does not grow with the number of apps.<script>or inline handler its function depends on: each app is a plain link, and the new-app step is a plain<form method="post">with a same-origin check.bun scripts/design-lint.tsand test/apps-timing.test.ts, test/apps-fit.test.ts pass.Files: test/apps-timing.test.ts or a new test/apps-nojs.test.ts; src/web/pages/apps.ts only if a test finds a fault. Risks: the list may read live app state; fake it as the other apps tests do rather than starting processes.