CI is one idea — a check that runs the moment you push, on a machine that isn't yours. GitHub Actions is the instance you happen to be using
The idea is decades older than GitHub, so learn the idea and look the YAML up when you need it. Your repository already has a workflow, running since your first push.
The same verdict at two distances#
pnpm check runs the checks
on your machine in seconds, while the agent still holds the context that
produced the mistake. Speed is why it exists locally.
CI runs the same command elsewhere and more slowly, answering a different question: does this work anywhere other than the machine it was written on. Uncommitted files, a dependency you installed months ago, an environment variable living in your shell — all invisible locally, all fatal on a fresh runner. That gap is what CI closes.
Keep the two aligned. If CI runs something your local command doesn’t, you have
two results under one name, and you will stop trusting the remote one. The
starter keeps them the same on purpose: CI runs your pnpm check, plus the
handful of things only a runner can reach — your process evidence, internal
links, committed secrets, and whether the deployed page is up.
Reading a red run#
A red run is a report for you; pasting it to the agent gives it the same report.
Paste the log, not only “The build failed”. The failing step and its output give the agent a file, a line and an expected-versus-actual. Open the run, find the first red step, and copy what it printed; everything after the first failure is usually collateral.
Don’t let red become normal. Week 3’s fourth property of a good sensor was trustworthy, and a permanently failing check spends it: you learn to scroll past the red, and the result stops helping.
Where it counts for you#
From the moment /ship flips your repo public, CI runs on every push and
the crit sweep reads the result.
The full shipping mark requires a green result when the sweep runs. A red or
incomplete result, including no checks at all, receives half.
The sweep starts fifteen minutes after the cutoff, which is settling time for exactly this. Your deploy and your checks both need a moment, and a push inside that window spends it. Push early enough that the run finishes.
What it doesn’t settle#
Everything above is the machine-checkable fraction, run somewhere neutral. It is worth automating because each check handled by the runner leaves you more attention for the questions it cannot settle.
It cannot tell you whether the feature works the way a person would want, whether the code is one you’d choose to own, or whether you still understand what the agent built. Green ticks can hide that gap. That last one is cognitive debt.
The deploy is a check too#
The full-stack half deploys to Fly.io, and the deploy is
already in the starter’s workflow: once /comp4020:ship flips your repo public,
CI deploys every push to main. See
deploying for how it works before that,
while the repo is private.
Once it’s wired, a failed deploy is the same kind of signal as a failed test,
and flyctl is how you read
the running app’s logs and status.