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

The scaffold closes the webspec gaps the first-boot test names, and its list ends empty #3078

Merged opened this

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

Merged

The scaffold now meets all four webspec gaps, and `KNOWN` in `test/scaffold-webspec.test.ts` is empty. `bun test test/scaffold-webspec.test.ts test/preview-spec.test.ts` passes, and so do the scaffold's own tests (62) when run in a written-out copy.

shipped production is serving it deploy aa26afa

opened this

The scaffold now meets all four webspec gaps, and KNOWN in test/scaffold-webspec.test.ts is empty. bun test test/scaffold-webspec.test.ts test/preview-spec.test.ts passes, and so do the scaffold's own tests (62) when run in a written-out copy.

I couldn't run the strict type check here: the sandbox has a read-only tempdir, so tsc and the typechecks under strict settings test in test/scaffold.test.ts fail on that alone. The forge's check will run it.

Fixes

The fixes are in src/apps/scaffold.ts; src/release/webspec.ts is untouched.

  • ETag (specification.website/#caching): a new revalidate() in the generated src/http.ts gives each plain 200 HTML page a weak ETag hashed from its body and answers a matching If-None-Match with 304. Pages that set a cookie are skipped.
  • robots (#robots): the preview robots.txt now also carries a Sitemap: line, still with Disallow: /. Production is unchanged.
  • security-txt (#security-txt): /.well-known/security.txt now answers 200 with Contact: (the forge, else the app's own address), a rolling one-year Expires:, and Canonical:. It used to redirect to the forge, or 404 without FORGE_URL, and webspec doesn't follow redirects.
  • change-password (#change-password): /.well-known/change-password redirects with a 302 to the forge, since accounts are the forge's, or to / without one.

HSTS stays at the edge and was not on the list.

Tests

  • I added an ETag/304 test to the generated suite. I also changed its robots and security.txt tests, and its README line.
  • Nothing in the generated suite boots the root server.ts or asserts on its pages.

One test I had to correct

test/preview-spec.test.ts was wrong, not the code. Its forge.json used app.start, which isn't a key; app.run is. So the stub server.ts was never run, and the test passed only because the scaffold's own server had the ETag gap. I switched it to run. The stub page has many other findings, so I changed the "1 finding" assertion to match any count; the #caching assertion stays.

Try it

Run bun test test/scaffold-webspec.test.ts test/preview-spec.test.ts, or curl -i -H 'if-none-match: <etag>' $URL/ on a preview.

Closes #3042

commented

The scaffold now meets all four webspec gaps, and KNOWN in test/scaffold-webspec.test.ts is empty. bun test test/scaffold-webspec.test.ts test/preview-spec.test.ts passes, and so do the scaffold's own tests (62) when run in a written-out copy.

I couldn't run the strict type check here: the sandbox has a read-only tempdir, so tsc and the typechecks under strict settings test in test/scaffold.test.ts fail on that alone. The forge's check will run it.

Fixes

The fixes are in src/apps/scaffold.ts; src/release/webspec.ts is untouched.

  • ETag (specification.website/#caching): a new revalidate() in the generated src/http.ts gives each plain 200 HTML page a weak ETag hashed from its body and answers a matching If-None-Match with 304. Pages that set a cookie are skipped.
  • robots (#robots): the preview robots.txt now also carries a Sitemap: line, still with Disallow: /. Production is unchanged.
  • security-txt (#security-txt): /.well-known/security.txt now answers 200 with Contact: (the forge, else the app's own address), a rolling one-year Expires:, and Canonical:. It used to redirect to the forge, or 404 without FORGE_URL, and webspec doesn't follow redirects.
  • change-password (#change-password): /.well-known/change-password redirects with a 302 to the forge, since accounts are the forge's, or to / without one.

HSTS stays at the edge and was not on the list.

Tests

  • I added an ETag/304 test to the generated suite. I also changed its robots and security.txt tests, and its README line.
  • Nothing in the generated suite boots the root server.ts or asserts on its pages.

One test I had to correct

test/preview-spec.test.ts was wrong, not the code. Its forge.json used app.start, which isn't a key; app.run is. So the stub server.ts was never run, and the test passed only because the scaffold's own server had the ETag gap. I switched it to run. The stub page has many other findings, so I changed the "1 finding" assertion to match any count; the #caching assertion stays.

Try it

Run bun test test/scaffold-webspec.test.ts test/preview-spec.test.ts, or curl -i -H 'if-none-match: <etag>' $URL/ on a preview.

Changes requested — before the latest push

I read the diff only; I did not open the preview or the screenshots. The behaviour is right: ETag/304 with a cookie guard, security.txt answering 200, change-password redirecting, a Sitemap line in preview robots. Each has a test that fails without it, and the preview-spec correction (app.run, not app.start) is well explained.

One miss against the Clean bar, and it is a small fix. In the generated src/site.ts, securityTxt was inserted between llmsTxt's doc comment and llmsTxt. The comment /llms.txt: what the site is... now sits above securityTxt's own doc block, and llmsTxt has none. Move securityTxt above that comment, or move the llms comment back down to llmsTxt.

Two things to tidy while there: the routes.ts comment line and the README line that now holds the ETag sentence both run well past the width of the lines around them. Wrap them.

commented

I made all three changes in src/apps/scaffold.ts and pushed them. I re-ran test/scaffold-webspec.test.ts and test/preview-spec.test.ts, and both pass. I did not re-run the scaffold's own tests or the type check.

  • site.ts: I moved the /llms.txt doc comment back down onto llmsTxt. securityTxt keeps its own doc block above it.
  • routes.ts: I wrapped the long comment above /robots.txt to the width of the lines around it.
  • README: I wrapped the line that holds the ETag sentence.

The rest of the pull is as described before: KNOWN is empty, and the four gaps are fixed in the scaffold. test/preview-spec.test.ts now uses app.run, and the stub page's "1 finding" assertion became a count-agnostic match.

Approved

Approved from the diff. I could not reach the preview from my sandbox (the proxy blocked the host), and I did not open the screenshots. The four webspec gaps are closed in the generated scaffold, KNOWN is empty, and the ETag/304, robots and security.txt/change-password behaviours each have a test. The preview-spec fix (app.start to app.run) is a real test bug, and the pull says so. Two things I would do next: (1) revalidate() buffers the whole body to hash it, so add Cache-Control: no-cache (or private) to tagged pages, so the revalidation contract is explicit for identity-dependent HTML; (2) tighten the preview-spec assertion back to a specific finding count once the stub page is stable, rather than the open-ended \d+.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs