JavaRush /Courses /Claude Code SELF /Fix with evidence

Fix with evidence

Claude Code SELF
Level 11, Lesson 4
Available

1. Fix by the card, not by vibes

Tommy takes his incident card — the one he filled out with Alex — and hands Sam not a vague “fix the portal,” but this:

Sam, fix this card. Stick to it, no broader.

# INCIDENT_NOTE
SYMPTOM:    reward-flow miscalculates — the numbers are all over the place
WHERE IT SHOWS:  submit application → reward is wrong; in the log TypeError reward-flow.js:30
EXPECTED:  for 3 matches exactly 30, stable
HOW I’LL PROVE IT: reward-flow.test.js green + build OK + manual run

“There,” he says out loud to himself. “Not ‘save me,’ but ‘do this, and we’ll verify it this way.’ One symptom, not the whole portal.”

The difference is almost tangible. Before, he would toss the agent “the portal is broken, figure it out” — and it would rush to fix everything at once, by guesswork, exactly like at night. Now the frame is narrow: one breakage, and it is stated in advance how we will measure success.

And the previous evening’s move helps right away. At the previous level, Tommy created a file CLAUDE.md in the portal — a short project documentation file for the agent: where the storefront is, where reward-flow is, where the leaderboard is, what is foundational, where not to go. The agent reads it on its own at the start of every session. Yesterday Tommy made it with boredom, “well, that’s what you’re supposed to do,” — and now Sam doesn’t start from zero. It knows the portal map from CLAUDE.md, doesn’t ask again “where is what,” goes in and works on the task right away.

“Well, that’s something,” Tommy mutters. “Yesterday’s boring little file, and today it saves half a session. At the very moment when every minute counts.”

2. “Done”? Prove it

Sam fixes it by the card and reports the usual thing: done, tests are green, the symptom is gone. And Tommy’s finger is already almost nodding “well, great, move on” — exactly like all week. The word “done” from the agent used to be a green light.

But he stops himself mid-gesture. The morning ruins are too fresh. Last night the agent also wrote “done” — and look at the result.

He writes to Sam not “good job,” but exactly what Alex taught him in the morning — a demand for facts:

Do not write "done". Run the tests and show me their actual output.
And bring the project up — it must start.

Sam runs the check through the terminal himself. A few seconds pass, while it is unclear how it will end. Tommy freezes over the keyboard. And instead of the green result he is already almost expecting, the screen shows a fact:

> node --test

✔ leaderboard is assembled from points
✖ reward calculation is correct     # the report said "fixed" — but the test is red
✔ zero matches — zero reward
ℹ tests 3
ℹ pass 2
ℹ fail 1

Tommy looks at the red. Sam confidently wrote “done, green” — but the test is red. The report did not match the fact.

“Whoa,” Tommy exhales. “If I’d nodded at the word…” And softly, almost with respect for a fellow craftsperson: “Lies like me. With the same deadpan face.”

“So that’s your ‘done.’” He snorts at the screen. “If I’d nodded, I’d have handed Tony something broken and been sure I did great. Thanks for not believing it.”

The theory from the morning conversation suddenly lands in his fingers: the agent’s report means nothing by itself. What to look at is what the tests showed, not what was said about them.

Since it is red, Tommy keeps fixing it, but no longer by guesswork. He remembers what the agent’s guesswork led to in the morning, and he remembers that he and Alex have already read these clues. So he does not write “my test is red, figure it out somehow.” He gives Sam that very clue, precisely, through the symbol @:

Here's the crash stack trace: @test-fail.log. Fix exactly this cause.

@test-fail.log is the file where the output of the failed test with the stack trace is saved. The @ symbol tells the agent: take this file and keep it in front of you. The same targeted delivery technique as in the previous level — not “the whole project,” but the needed piece tied to a location.

And the difference is obvious right away. Sam does not patch line 30 in reward-flow.js, where the smoke came up. He goes to the root cause — the input validation in portal.js, which the night autopilot “simplified.” The symptom is in one file, the mine is in another, three steps earlier; exactly as Alex said about smoke and wiring.

“Look at that,” Tommy says, pointing back, “he went not where it was burning red, but where they had messed around at night. In portal.js. Gave a precise clue — fixed it at the root.”

3. Prove it with a chain of evidence

Fixed — and now Tommy proves it for real, not with one checkmark. He assigns the run again, but asks for the whole chain at once:

Run the tests, build the project, and show me the actual output.
I’ll run the scenario myself.

Sam runs it — and on the screen three independent proofs come together. The first two:

> node --test

✔ leaderboard is assembled from points
✔ reward calculation is correct     # green: what worked did not break
✔ zero matches — zero reward
ℹ tests 3
ℹ pass 3
ℹ fail 0

● npm run build
  build OK                      # the project starts

The full test output, as Tommy sees it in the terminal — all green, fail 0 and skipped 0: not a single one skipped:

A terminal window: npm test after the fix — all three tests have green check marks; the summary says pass 3, fail 0, skipped 0.

The test is green — that means fixing one thing did not break something nearby. The build passed — that means the project starts at all, not just “the code looks nice.” The third proof remains, and Tommy does it himself, by hand: he opens the portal, clicks through the user path — application, reward-flow, storefront.

The very storefront that greeted him with a broken block that morning.

The cursor hovers over the button. The finger is suspended — exactly as it was this morning over /rewind, which did not save the day. “Well,” Tommy mutters into the empty room, “either it is fixed, or it is ruins again.” He clicks.

A second. The portal blinks.

The storefront loads — and comes up whole. Tommy clicks through the application. reward-flow counts — the numbers no longer wander, the accrual settles exactly. The path that was failing this morning is alive under his fingers.

“Now yes,” he says quietly to himself. “The test is green, it built, I ran it by hand. Three eyes, and all three said the same thing. It wasn’t Sam who said ‘done’ — I saw it myself.”

One symptom is closed. But the portal did not go down in just one place this morning — the leaderboard was empty too. Tommy does not jump to “and let’s fix that too.” He does the same thing again, now more naturally: he creates a second incident card.

# INCIDENT_NOTE
SYMPTOM:    leaderboard is empty — the leaderboard table doesn't build
WHERE IT SHOWS:  open portal → Leaders tab → empty
EXPECTED:  the table shows players in descending points order
HOW I’LL PROVE IT: leaderboard.test.js green + build OK + tab manually

The same cycle: hand the card to Sam → fix it → “show me the actual output,” not “done” → npm test green, build OK → open the tab yourself, check — the table is there. The second time goes twice as fast: the hand already knows the motion. Symptom — card — root-cause fix — proof with three eyes. Not heroics, but a routine you can repeat.

4. Trace and a new rule

Tommy does not end the day with “well, it seems to be alive.” For each fixed symptom, he leaves a short evidence trail — EVIDENCE_LOG. A small honest note: what was broken, what fixed it, what proved it.

# EVIDENCE_LOG-lite
SYMPTOM:        reward-flow miscalculated — failed with TypeError on an incomplete claim
EVIDENCE:       TypeError stack trace … at calculateReward (reward-flow.js:30) at processClaim (portal.js:23)
                + night log line "04:08 EDIT portal.js:15 — 'simplified' the input validation"
BEFORE THE FIX: tests sat in skip and stayed silent — no red while checks are disabled; TypeError only in the log
CONFIRMED:      test green + build OK + manual scenario run clean

In the “Evidence trail” task, you’ll fill in the same kind of log for this very symptom — the reward accrual failing with TypeError. Everything you need has already appeared on this level: the stack trace in the lecture “How to Read an Error” and the night log line 04:08 in the lecture “Let’s break down what happened.” In “BEFORE THE FIX,” describe the state while the tests sat in skip: no red is visible, and the failure shows up only in the log.

“And you know what is the most grown-up thing here,” Tommy says to Sam, rereading the entry. “Before, the proof was my ‘well, I can see that it works.’ And here it lies separate from me. Open any one — and check by facts, not on faith. Not ‘wow,’ like a revived map. Quiet. But I’m no longer alone with my ‘it seems to work.’”

What to record before the repair and after. Before the repair — the INCIDENT_NOTE card: SYMPTOM — one breakage, not the whole project; WHERE IT SHOWS — the steps and the message where it shows; EXPECTED — how it should be, stated so it can be checked; HOW I’LL PROVE IT — which checks will show it’s fixed. Next — the repair at the root. After the repair — the EVIDENCE_LOG trace: SYMPTOM — the same as in the card; EVIDENCE — what led to the root cause; BEFORE THE FIX — what the breakage looked like and what the checks showed; CONFIRMED — the same check is green, plus build and run. Checking the symptom itself: in the card you picked the check; before the fix, make sure it is red on the broken code — if the test sat in skip, enable it first; after the fix, the same check is green. The build and the other tests didn’t turn red after the fix — so you broke nothing nearby. Green on broken code means it doesn’t catch this breakage; you need a check that turns red. A trace is not a retelling: write down the command and save the output — before the fix and after. Proven: the symptom check was red, turned green — and the others didn’t turn red. What to record before the repair and after Before the repair — card INCIDENT_NOTE SYMPTOM one breakage, not the whole project WHERE IT SHOWS steps and the message where it shows EXPECTED how it should be — in a checkable form HOW I’LL PROVE IT which checks will show it’s fixed repair at the root After the repair — trace EVIDENCE_LOG SYMPTOM the same as in the card EVIDENCE what led to the root cause BEFORE THE FIX what the breakage looked like, what checks showed CONFIRMED same check green + build and run Checking the symptom itself HOW I’LL PROVE IT picked the check BEFORE THE FIX make sure: red on broken code CONFIRMED after the fix — green Test sat in skip — enable it first Build and other tests didn’t turn red after the fix — so you broke nothing nearby Green on broken code — so it doesn’t catch this breakage. You need a check that turns red A trace is not a retelling: write down the command and save the output — before and after the fix Proven: the symptom check was red, turned green — and the others didn’t turn red

He rolls his neck and sweeps his eyes across the assembled package: two incident cards, an evidence log. The portal stands honestly — both symptoms fixed at the root, proven by a chain, recorded. Not magically, as he expected in the morning — by fact.

“Morning ruins, now the portal is back on its feet — and I proved it, not guessed by eye. That’s it,” he says to the screen. “I don’t trust anyone’s word anymore. Especially AI.”

The rule that was not there yesterday is now with him: no proof, no result. Not “the agent said done.” Not “it seems to work.” Only what has passed through fact.

One thing stings, quietly. Today he learned to clean up afterward: the agent made the mess — he sorted it out and fixed it. And it is tempting to decide that now he is protected: if something happens — I’ll clean it up. But “afterward” is still afterward. The incident has already happened, the project has already crashed, the resource has already burned out.

“Fixing a catastrophe,” he says softly, “isn’t the same as preventing it.”

The thought is uncomfortable, and he puts it aside for now. Not for today.

Sorting out an incident is not the same as preventing it. Before — prevent it, while the agent hasn’t changed anything yet: the task — what to do and what not to touch; the plan — before the first edit; permissions — what the agent may do without asking. In detail — later in the course. If an incident did happen — after: sort it out, you can already do this: you read the error and the log, fix at the root, prove it with checks. But the project already went down, and the limits are already spent. You have something to work with only if you prepared in advance: a log, tests, CLAUDE.md. One doesn’t replace the other: protection before doesn’t catch everything — you’ll still have to sort things out after. You need both: sort it out after and prevent it before. Sorting out an incident is not the same as preventing it Before — prevent while the agent hasn’t changed anything yet Task: what to do and what not to touch Plan — before the first edit Permissions: what the agent may do unasked In detail — later in the course ! Incident if it happened After — sort it out you can already do this You read the error and the log You fix at the root You prove it with checks But the project was down, limits already spent You have something to work with only if you prepared in advance: log, tests, CLAUDE.md One doesn’t replace the other: protection before doesn’t catch everything — you’ll still sort it out after You need both: sort it out after and prevent it before

5. How the day ended

In the evening, in the chat with Tom2036, a message drops — and Tommy again notices that the older one is not the same today. In the morning he was dry, harsh, with a branching point without mercy. And now something businesslike slips into the tone, appraising — as if he is looking at today’s mess not as a drama of a guy, but as something from which benefit can be drawn.

Tom2036
online
The text is torn again, in blots — the morning clarity is gone, guard is back on duty. But the skeleton is readable:

Cleaning up after it today, you handled pretty well. Nine out of ten in your place would have run by morning — someone else’s project in ruins, easier to bail and pretend it isn’t yours. But you stayed and cleaned it up. Not like everyone else.

Just remember. Fixing a catastrophe is a skill. But not letting it happen is already ██████████, and it costs ██████████████. Take your hand off ████████ ahead of time — and one day this ██████ will count. For whom and how much — █████ you’ll understand.

You, who learned to fix after the fact. And about the fuse ██████ you’ll find out.

“Half the text got eaten again,” Tommy mutters, squinting. And he grins: it got eaten not randomly. Where the older one praises him for not running, it is readable. And the moment he veers into “how much does it cost” — dull blots, exactly like the seventh level, when he asked about money and got rubble. “That price is really killing you. Every time you get stuck on it.”

“Not like everyone else, then,” he repeats, and for the first time that day he truly smiles.

He snaps the lid shut. Somewhere at the edge of his thoughts, something is already stirring: if he can clean up afterward, sooner or later he will have to learn to hold the wheel before. But not today. Today it is enough to have what he has: in the morning there were ruins, in the evening the portal was back on its feet, raised honestly. And it was not Sam’s “done” report that pulled it out, but him himself — by refusing to take it on faith and proving it.

1
Task
Claude Code SELF, level 11, lesson 4
Locked
Evidence trail 🧾
Evidence trail 🧾
1
Task
Claude Code SELF, level 11, lesson 4
Locked
Fix it by the incident note 🔧
Fix it by the incident note 🔧
1
Task
Claude Code SELF, level 11, lesson 4
Locked
Second symptom, all over again 🔁
Second symptom, all over again 🔁
1
Task
Claude Code SELF, level 11, lesson 4
Locked
Run the three-eye check with your own hands 🖐️
Run the three-eye check with your own hands 🖐️
1
Survey/quiz
Choosing a model and debugging, 11 level, 4 lesson
Unavailable
Choosing a model and debugging
Models, limits and debugging: /rewind, /usage, /model and reading a stack trace
Comments
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION