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
Check · Review · Land · Live done — Landed and live in production.
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
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.
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 whatscripts/test-shards.tsis built around: it takes files from the command line, andforge.jsonis the one place that names them. A guard that fails when atest/*.test.tsfile 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.
This adds
test/web-apps.test.tsto thecheck.runlist inforge.json, so the gate runs the file again. The nine red tests the issue describes were already fixed onmainby earlier work, so no test needed changing. Under the gate's--timeout 60000the file runs 18 pass, 0 fail.href="/alice/hello/app/production/open".bun run checkgreen.bun x tsc --noEmitcan't find thebuntype definitions in this clone, so the type check could not run here. I ran only the web-apps file, not the whole check list.EXCLUDEDlist:scripts/suite.tsand itsEXCLUDEDlist no longer exist. The check names its files explicitly inforge.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