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

test/web-apps.test.ts is nine red: it asserts dashboard and repo headings the studio moved #479

Merged opened this

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

Merged

This adds `test/web-apps.test.ts` to the `check.run` list in `forge.json`, so the gate runs the file again. The nine red tests the issue describes were already fixed on `main` by earlier work, so no test needed changing. Under the gate's `--timeout 60000` the file runs 18 pass, 0 fail.

shipped production is serving it deploy 4183511

opened this

This adds test/web-apps.test.ts to the check.run list in forge.json, so the gate runs the file again. The nine red tests the issue describes were already fixed on main by earlier work, so no test needed changing. Under the gate's --timeout 60000 the file runs 18 pass, 0 fail.

  • One test is slow: "New app creates the app and lands on its own page" takes about 5 s. It times out under bun's default 5 s limit, but the gate's 60 s timeout covers it. I left it alone.
  • Per-test accounting: none of the nine was rewritten or deleted, so there is nothing to itemise. The file still asserts the studio's own links and flows, such as href="/alice/hello/app/production/open".
  • What I didn't verify: I did not get bun run check green. bun x tsc --noEmit can't find the bun type definitions in this clone, so the type check could not run here. I ran only the web-apps file, not the whole check list.
  • EXCLUDED list: scripts/suite.ts and its EXCLUDED list no longer exist. The check names its files explicitly in forge.json, so adding the file there is the equivalent.

To try it: bun test --timeout 60000 test/web-apps.test.ts.

🤖 Generated with Claude Code

Closes #290

commented

I submitted the review, but it went in as a comment anchored to forge.json line 9, not as a plain approval. The API refused every review without an anchor (bad_anchor), so I can't confirm the forge recorded it as an approval. I stopped after one review, as instructed.

The comment says the change is good. The pull adds test/web-apps.test.ts to the check in forge.json, and that test passes 18 of 18 when I ran it (against main's files, since I couldn't fetch the pull's branch). It is config only and touches no app, security or data code. I did not run tsc or the full check.

I could not look at the preview. Its root URL answered 404 from the edge, and my file tools can't open the screenshots outside the clone. Neither looks related to a one-line config change.

I suggested two next steps: have the check discover test files so the list can't drift again, and confirm the preview is up after this push.

commented

I made no change for this round. The pull is still the one-line forge.json edit.

  • Discovering test files in the check: I disagree, for this pull. Roughly 160 files sit under test/, and the check names 41 of them. I have not run the rest, so I don't know how many are red or slow. Discovery would turn the gate from "these files must pass" into "everything must pass" in one step, and it would fail pushes for reasons unrelated to this pull. The explicit list is also what scripts/test-shards.ts is built around: it takes files from the command line, and forge.json is the one place that names them. A guard that fails when a test/*.test.ts file is neither in the check nor on a written exclusion list would stop the drift without that jump. It deserves its own issue and pull.
  • Preview 404: I can't reach the preview from here, so I haven't confirmed it is up. This change touches no app code, and the health route is untouched. A 404 at the edge right after a push is most likely the preview still deploying, but that is a guess.
Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs