Module 10. Every failure in this module actually happened, on a real system, and cost real time. None of them looked like failures while they were happening. That is the entire point.
It fails confidently, fluently, and in the same tone it uses when it succeeds.
There is no tell. The message that says "done, all forty exported" is written with exactly the same certainty whether or not anything was exported.
Verify the artifact, never the success code.
A success message describes what was attempted. It does not describe what exists.
If you did not look at the thing, you do not know. Every failure in the rest of this module is a variation of forgetting that.
A batch job ran overnight, reporting each item complete. Fifty confirmations. In the morning the report said fifty done.
Nothing had been created. The calls had returned a success shape without the work ever being queued.
The counter is not the artifact. A number that goes up is a number that went up.
The fix, forever: submit one. Go and look at the thing itself, in the place it is supposed to be. Only then submit the other forty nine.
Two processes were pointed at one editing application at the same time, to go faster.
Nothing errored. Nothing warned. Days later, a timeline was missing shots that had definitely been cut.
An application that holds state in memory does not collide loudly. It collides quietly, and the damage surfaces long after the session where you could have understood it.
One writer per resource. One hand on the timeline, one process per project file, always.
A weekly health check ran for weeks and passed every time.
It was checking that files existed. It was not checking that they said anything true. The system was drifting the whole time, and the green result was actively making it worse, because it retired the suspicion that would have caught it.
A check you have never seen fail is not a check. It is decoration.
Break it on purpose. Feed it something you know is wrong. If it still passes, you have learned something enormous for the cost of two minutes.
A configuration file carried a comment naming which of three settings it was using. The comment said one thing. The actual contents were a different, much stricter one.
Result: every new user's first experience was being asked for permission on every single file, dozens of times in a row, on a system advertised as effortless. They concluded the tool was broken. They were not wrong.
Nobody had diffed the file against the thing it claimed to be, because it said what it was right there at the top.
A label is a claim, not a fact. The file says what it says, not what its comment says.
A sign-in did not work. So it was tried again. And again.
Repeated attempts do not read as persistence to the system on the other end. They read as an attack, and the account was hard locked for most of a day.
Never retry a refused action hoping for a different answer. A refusal is information.
When something is denied: that lane is closed, the task is not. Say what is blocked, then go and do every other part of the work.
A session that had been running for hours started making worse decisions. Forgetting constraints from earlier. Contradicting itself.
Nothing was wrong with the model. The context was full. Everything said in the first hour had been pushed out to make room.
When it starts feeling dumber, that is a capacity signal, not a quality signal. Save where you are, start fresh, and tell the new session the three things that matter.
Long sessions are not a badge. Split the work and each half is sharper than the whole was.
The most expensive failure in this course's world is not a wrong output. It is forty correct outputs, generated perfectly, from a prompt you would have fixed in one line at item two.
Nothing failed. The bill and the afternoon are gone anyway.
One first. Look at it. Then the rest. Every time, forever, no exceptions for jobs you are confident about.
Rewrite your requests so the answer contains proof:
| Instead of | Ask |
|---|---|
| "did the exports work?" | "list every file with its size and duration" |
| "is the archive complete?" | "verify against the manifest and show mismatches" |
| "did you fix shot 9?" | "show me the diff and the new file's path" |
| "is this accurate?" | "quote the line you got that from" |
A verdict is an opinion. A file listing is a fact.
The failure underneath most of the others is filling a gap with something plausible.
"If you do not have the value, write MISSING. Do not estimate, do not infer it from context, do not use a typical value. MISSING is a correct answer and a guess is not."
Put that sentence in the instructions your studio reads every session. It is one line and it converts the most dangerous failure mode into a visible one.
Twenty minutes, on the film you already made.
deliverables/ with size and duration." Compare against what you believe.You are no longer running on trust, which means you can now let it run.
Your Short Film. The capstone. One finished piece, start to finish, using every module, and the four weeks after it.
Verified against Claude Code 2.1.220 · 2026-07-30.