It passed where the repository was
Two bugs that no check could see, because every check ran with the whole repository on disk. Production had only what the build decided to ship.
Date: 2026-11-11. Context: the first deploy on Vercel (journal ch. 73).
What happened
The dashboard passed every check it had: types, tests, a build, and every page opened in Chrome, on a laptop and in CI. Its first build on Vercel failed, and its first working deploy showed eleven of the seventeen addresses the page check opens without their content.
The build. next build type-checks the app, whose tsconfig.json references the design
system and the generated-views package. Their declaration files exist only after tsc -b. On a
laptop they were always there, left by the last bun run check. In CI the check step runs before
the build step, so they were there too. Vercel ran the build alone, from a fresh clone: 44 type errors, 35 of them
"has not been built from source file" and 9 that followed from those.
The pages. Since chapter 66 the overview, the run list and the rules page read the tasks/
folder to know which task belongs to which domain. The build was told to ship that folder with
the task pages only, and it never shipped tasks/index.ts, the one file the app looks for to
find the folder: so in production not even the task pages found it, and that setting, written in
chapter 56 before any deploy, had never worked. A laptop and CI start the app inside the
repository, where tasks/ is always next to it.
check:app against the live address found it in half a minute: 0 of 5, "no h1" on eleven
addresses. Its first test, added in chapter 60 for a different reason ("an app that cannot read
its data still draws headings"), failed before the rest ran. The server's log gave the sentence:
"No tasks/ folder above the app."
What we learned
- A check sees the environment it runs in. Both bugs were invisible wherever the whole repository and yesterday's build output were on disk, which was everywhere a check ran.
- The order of steps can hide a dependency. CI was green because
checkhappened to make whatbuildneeded. A step that only works after another one is a bug waiting for a new host. - Run the checks against the real thing. The same test, pointed at the live address, was the only one that could fail, and it did at once.
What it means for Vektos
The benchmark runs an agent's page in a scratch folder holding only what the agent wrote, for this reason: a page that works because of what else is on the machine does not work. The app itself deserved the same treatment and did not get it until it was deployed.
Follow-ups
- Done: the web's build is
tsc -b && next build; every route shipstasks/with its marker. - A CI step that starts the built app from a copy holding only what the build traced, so a missing file fails there and not in production.
check:appagainst the live address after each deploy ofmain.
The label that pointed nowhere
The first behaviour checks failed a model that had done the right thing: the design system's date picker had no label inside a form field, and axe had never noticed.
Four green checks, none of them ours
The rule said to merge when `gh pr checks --watch` is green. It came back green in under a minute, with four checks, all Vercel's: CI had not started.