JavaRush /Courses /Claude Code SELF /Proving the fix honestly

Proving the fix honestly

Claude Code SELF
Level 14, Lesson 4
Available

1. First — honest red

The conversation, the screenshots, and one caught trap — that was just now. Tommy already has everything he needs: the spec with four separated columns, the log up to line 9, the understood green trap, and the rule of honest testing. The bug itself was already fixed during the day too — the code is correct, and the scoreboard shows three. One thing is missing, the most important one: an honest proof. Because his check is still the same one from Sam — a dummy with its insides commented out. The code is fixed, but there is no way to prove it.

This is where Tommy starts — with the test. And the first thing he writes to Sam is something he would never have thought of before:

— Sam, bring back that test you commented out. Uncomment the if, let it compare the score with three again and yell if it does not match. Just do not turn it green too early — first prove to me that it can even turn red.

Not “as long as it is green,” the way he would have asked a couple of weeks ago. On the contrary: let the test honestly show red on the broken version first. The test had existed since the morning, the same one, “three in a row should give three” — there is no need to write it again, just bring it back to life: Sam did not throw it away, he put it to sleep with two slashes //.

Sam restores the if to its place — the test is alive again and has teeth. And right away a subtle point comes up that is easy to miss. The test must be kept separate from the fix: save it in git (commit it), so it does not get tucked into the pocket together with the score change. Otherwise stash will take both the fix and the test — and then there will be nothing left to test. Tommy asks Sam to help:

— Save the test in git as a separate commit. And then stash only the score fix, src/bonus-game/score.js — we will bring the bug back and see whether it turns red.

Sam commits the test and hides only the fix:

● git commit -m "restore score test"    # honest test saved separately
● git stash push -- src/bonus-game/score.js         # ONLY the score fix goes into the pocket; the test stays

Tommy asks to run the test:

  FAIL  score.test.js     # 3 in a row → expected 3, got 30

Red. FAIL.

— Oh, Tommy says out loud and catches himself smiling at the red test. We have come far: a couple of weeks ago this would have been a “something is broken” light, a failure, a reason to frown. And now he looks at this FAIL almost tenderly. Because red here is good news: it means the test is finally looking exactly where it should. It saw the bug. It can turn red.

He holds that red on the screen for a second. The morning dummy was green and blind. This one is red and sighted. And between the two, only the sighted one can be trusted.

2. Honest green

Red has been proven. Now — bring back the fix. There is no need to fix anything again: Sam had already put the correct code aside during the day, and it is just waiting for its moment in the pocket. Tommy asks to get it back and run that very test that just honestly turned red — not “the score lies there,” but the test that is directly tied to the bug.

● git stash pop      # take the ready fix out of the pocket — put it back in place

A second. The tests are running. Tommy catches himself not breathing — in the morning this same green had already fooled him once, and now he does not trust it in advance, he waits. Either it will come out red, or...

  PASS  score.test.js     # 3 in a row → 3 points

Green.

And this time Tommy looks at PASS without the morning trust — now he knows the price of green. But this green is different, and he says the difference out loud:

— This time I believe you. Half an hour ago you honestly turned red on the same bug; I saw it myself. And now you turned green on the fix. Red on the broken version — green on the fixed one. You cannot fake that: a fake cannot turn red.

But he no longer takes the test at its word — he has learned. He opens bonus-game, runs it live, and makes three in a row.

The scoreboard shows honest three. Not thirty.

Tommy leans back and exhales. Not the excitement he used to get from games — something calmer and heavier. The green on the screen now means exactly what it should. The light is green, and there is no smoke behind it.

— I did not believe you, he says to PASS on the screen, almost cheerfully. — I proved you.

3. Second channel — a screenshot through the sighted model

The test proved its point — it honestly turned red on the bug and green on the fix. But Tommy remembers that Alex promised another channel, through the eyes. And now he runs it himself — the thing that, by day, had been just a theory about “putting on glasses.”

He takes a screenshot of the scoreboard after the fix — score-after.png, where the scoreboard shows an honest three. And he switches to the vision model:

/model    # choose the vision model — "put on glasses"

Then he sends the image into the session and asks it to confirm:

Here is the score screenshot @screenshots/score-after.png — confirm that the score is correct now.

The sighted model looks at the frame and answers directly: three in a row means three points, not thirty. Not Tommy’s paraphrase, not “I checked it” — the agent itself described what is on the picture. That means it saw it.

— Ah, so that is why the screenshot worked so well on the landing page back then, Tommy realizes. — The environment itself handed me a sighted model, and I did not even notice. And now I switched it by hand — and I can see the whole mechanism.

He switches back to the working model — /model, the “glasses” are no longer needed — and sums it up for Sam:

— Look what we ended up with. I now have two pieces of evidence for the fix: a test that can turn red, and an image that the model itself saw. You can fake one — the other will not line up. You cannot fake both at once.

4. EVIDENCE_LOG — the clue you assembled yourself

When the bug is fixed and proven, Alex writes one line, sparing and workmanlike after hard days:

— What you just assembled is called EVIDENCE_LOG. An evidence package. Not “done,” but a chain of facts by which the fix proves itself.

He does not explain anything else — he goes silent. And Tommy’s habit of pulling answers out with questions kicks in. He recognizes the shape from somewhere, not out of nowhere: earlier he had already assembled a lightweight clue card for one burning symptom — EVIDENCE_LOG-lite. That was the embryo.

— And how is this full thing different from that lite card? Tommy asks.

— Lite only recorded the clue: “here is what broke.” The full one must also prove that the clue disappeared because of the fix, and not on its own. The whole arc — from red on the broken version to green on the fix.

Tommy asks Sam again what must be inside so the package can be trusted, and, one question at a time, he pulls the structure out. He builds it himself, field by field, from what he lived through during the day:

# EVIDENCE_LOG — score bug in bonus-game
1. SYMPTOM:            3 in a row = 30 points instead of 3
2. LOG CLUE:           calcScore (src/bonus-game/score.js:9) — POINTS_PER_MATCH=10 instead of 1
3. FAILURE ON THE BROKEN VERSION: test turns red on the bug (otherwise it is worthless)
4. FIX:                POINTS_PER_MATCH from 10 to 1 in calcScore
5. HONEST GREEN:       the same test turns green on the fix
6. SCREENSHOT:         score-after.png — the sighted model confirmed honest 3 on the scoreboard

Tommy looks at these six lines and understands why such a package cannot be faked with one bogus green report. Every item is checked again by hand. Green here does not stand on its own — it is squeezed between red-before and screenshot-after. This is not “I checked everything, it works.” It is a clue you can open and walk through step by step.

5. Testing is a craft too

Oliver comes back and stops at the screen. Usually he does not linger around Tommy’s hobbies — he has seen enough boys who wrote a pretty toy and decided they had become engineers. Tommy had still been in that same column for him.

— What is this, then, he nods at the screen. He expects to see a wow demo.

But it is not a demo. It is EVIDENCE_LOG: red on the broken version, the cause in the log, honest green after the fix, a screenshot. Oliver skims the six lines with his eyes. Once, twice. He snorts — and it is not the usual snort.

— Wait. So you did not just poke the tool. — He looks at Tommy without his usual sour face. — You caught a false test with a test. Our kind of person. Nice one.

He winks and walks away without waiting for an answer. But Tommy still feels a brief warmth — the old-timer who does not believe in “AI magic” one bit has just recognized craft in him. And Oliver respects craft.

And suddenly the main thing about the whole day falls into place on its own.

— Listen, he writes to Alex. — It was not the fancy model that saved me today. Sam is strong — and he still laid a trap for us. What saved us was process. The process that did not let the green light slip through without a check.

— Write that down and pin it to the wall, — Alex replies. — A good model does not save you from a bad process. And a good process catches even a beautiful lie.

Tommy rereads his EVIDENCE_LOG. The dull burden he had been carrying around for weeks as dead weight worked for the first time today — and not because of a fancy model, but because of these six pedantic lines.

1
Task
Claude Code SELF, level 14, lesson 4
Locked
EVIDENCE_LOG — proof packet 📋
EVIDENCE_LOG — proof packet 📋
1
Task
Claude Code SELF, level 14, lesson 4
Locked
First red, then green 🚦
First red, then green 🚦
1
Survey/quiz
Tests and proof of a fix, 14 level, 4 lesson
Unavailable
Tests and proof of a fix
Tests, logs, stack traces and honest proof that a bug is fixed
Comments
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION