An eighth, from yesterday: the fix passes everything, and it never ships.
The AI fixed a bug with a new patch folder, and every test passed on my machine. But the deploy script packs a fixed list of folders, and the new one wasn't on it. No test could see that, because tests run where the file exists.
A 30-second check that could help: list the new files, then look for each one in what you ship.
git diff --name-status main | grep '^A'
Compare that with your Dockerfile COPY lines, or your package's "files" list. I only caught mine by reading the script.
Software Engineer · Next.js · React · TypeScript · Three.js · Node.js · Spring Boot · MySQL · WordPress · Shopify · Claude Code · Codex · Building tools to make your daily dev work easier
Thank you for sharing this one. The tests pass on your machine because the file is right there, and the package just never gets it. I'll think about adding a check like that to proof-of-done. Out of curiosity, is your folder list hardcoded in a shell script, or does it live in a config file? That would change how a check could read it.
Hardcoded on purpose, in a shell script: a fixed list keeps secrets like .env from shipping by accident.
We'd check the package, not the script, so it works either way. And our team always likes a human in the loop here: the check flags the file, and a human decides if it ships.
Software Engineer · Next.js · React · TypeScript · Three.js · Node.js · Spring Boot · MySQL · WordPress · Shopify · Claude Code · Codex · Building tools to make your daily dev work easier
Thank you for explaining. An allowlist is a sensible choice here: it fails safe, because anything not on the list stays out, including a stray .env. Checking the built package also keeps the check independent of how the list is maintained, whether it's a shell script or a config file. And I agree that it should flag rather than block: a new file is not always a mistake, so the final call belongs to a person.
We're a place where coders share, stay up-to-date and grow their careers.
An eighth, from yesterday: the fix passes everything, and it never ships.
The AI fixed a bug with a new patch folder, and every test passed on my machine. But the deploy script packs a fixed list of folders, and the new one wasn't on it. No test could see that, because tests run where the file exists.
A 30-second check that could help: list the new files, then look for each one in what you ship.
git diff --name-status main | grep '^A'
Compare that with your Dockerfile COPY lines, or your package's "files" list. I only caught mine by reading the script.
Thank you for sharing this one. The tests pass on your machine because the file is right there, and the package just never gets it. I'll think about adding a check like that to proof-of-done. Out of curiosity, is your folder list hardcoded in a shell script, or does it live in a config file? That would change how a check could read it.
Hardcoded on purpose, in a shell script: a fixed list keeps secrets like .env from shipping by accident.
We'd check the package, not the script, so it works either way. And our team always likes a human in the loop here: the check flags the file, and a human decides if it ships.
Thank you for explaining. An allowlist is a sensible choice here: it fails safe, because anything not on the list stays out, including a stray .env. Checking the built package also keeps the check independent of how the list is maintained, whether it's a shell script or a config file. And I agree that it should flag rather than block: a new file is not always a mistake, so the final call belongs to a person.