test(smoke): boot a scaffolded board at the depth Vercel deploys it - #246
Merged
Conversation
Every board bug found so far shipped through `forum-web build --at-root` — the unregistered theme catalog, the Tailwind scan roots resolving to nothing, the installer that could not finish — and no CI job ever built or booted a board that way. The checks added for those bugs ran at `.meith/app` only, and `rebaseGlobalsCssSources` computes a different path at each depth rather than the same one twice, so depth two was never evidence about depth zero. The boot and its assertions are one helper now, run against two boards: the first at `.meith/app`, the way a self-hoster gets it, and a second scaffolded from the same packed tarballs and built with `--at-root`, the way Vercel deploys it. Both are held to the same three things — it renders `<main>`, no message key reaches the page as text, and the stylesheet carries rules for classes only the installed packages produce. The second board is scaffolded fresh rather than the first one rebuilt. Rebuilding would save the pack and one install, but it would test two materialization depths coexisting in one workspace, which no real board does — a failure there would be the smoke failing something no user can reach. Two things a green run does not prove are written down in docs/development.md rather than left to be assumed: the at-root board boots through the standalone server, because `output: 'standalone'` is skipped only when VERCEL is set and CI is not Vercel, and nothing here says the two depths can coexist.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every board bug found this week shipped through
forum-web build --at-root, and no CI job ever built or booted a board that way.default.latestThreads.heading/installcould not finishAll three were found by a person looking at a deployed page. The checks added for the first two run at
.meith/apponly, andrebaseGlobalsCssSourcescomputes a different path at each depth —../../node_modules/@meithat depth zero versus../../../../node_modules/@meithat depth two — so depth two was never evidence about depth zero.What changed
The boot and its assertions are one helper now, run against two boards:
.meith/app--at-rootBoth are held to the same three things: it renders
<main>, no message key reaches the page as text, and the stylesheet carries rules for classes only@meith/uiand@meith/theme-defaultproduce.Why a second board rather than rebuilding the first
Rebuilding would save the pack and one
npm install. It would also test two materialization depths coexisting in one workspace, which no real board does — so a failure there would be the smoke failing something no user can reach. Given how much of this week went on gates that were wrong rather than missing, the extra minute is worth it.What a green run does not prove
Both written into
docs/development.mdrather than left to be assumed later:output: 'standalone'is skipped only whenVERCELis set and CI is not Vercel. Vercel packages its own functions. This proves materialization, Tailwind and the catalog at depth zero — not Vercel's serving shape.Verification
Run locally end to end, both boards green:
This box has no Docker, so Postgres was PGlite over the wire protocol. The first attempt failed with
unnamed prepared statement does not existon the existing depth-two boot — that was the substitute database accepting 30 connections; the e2e harness serves the board withmaxConnections: 1for the same reason. Nothing in the product:packages/db/src/client.tsalready setsprepare: falseon every connection. CI uses a realpostgres:18-alpineand needs none of this.docs:links:checkpasses. The CI job comment and step name were updated to say it now boots at both depths.Fixes MEI-132.
Generated by Claude Code