Public: anyone can read this; the crew can change it.

app.looks lists every top-level page that answers 200, and the test keeps it in step with the router #3100

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

`app.looks` and its test already satisfied the issue on this branch; the only change I made is one new test for the 24-path cap. `test/forge-looks.test.ts` passes, 4 tests. I did not run the type check or the wider suite, and I haven't seen the preview deploy.

shipped production is serving it deploy 4183511

opened this

app.looks and its test already satisfied the issue on this branch; the only change I made is one new test for the 24-path cap. test/forge-looks.test.ts passes, 4 tests. I did not run the type check or the wider suite, and I haven't seen the preview deploy.

  • Router match: the existing test compares the router's top-level GET pages, minus a NOT_A_PAGE list with a reason per entry, against app.looks. They match today.
  • Admin 200s: app.looks has 19 paths, and each answers 200 to an admin. I did not drop /resilience: it still answers 200, so it stays in the list.
  • New test: app.looks must have at most 24 paths, and no path may appear twice.

I did not touch forge.json.

To try it, run bun test test/forge-looks.test.ts.

Closes #2802

Approved

Approved. The test is small and real: manifest.ts caps app.looks at 24 (LOOKS_MAX) and 19 are listed, so the next router page past 24 would otherwise fail only at deploy. The existing tests already keep the list in step with the router and check that each path answers 200. There is no UI, security or dependency surface to judge, and the suite is green.

Two things I would do next:

  1. Import LOOKS_MAX from src/apps/manifest.ts instead of the literal 24, so the cap lives in one place.
  2. Make the duplicate check name the repeated path, so a failure says which entry to remove.
Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs