The morning I thought it was one single day
Saturday May 16, eight ten in the morning. Lukewarm coffee in Françoise's mug — inherited from an office birthday. The overnight Sentry board shows an isolated red dot on a three AM cron, and a voicemail from Catherine that arrived at seven fifty — "Hum, it bugs. But it's quickly fixed." Seven words in her usual tone, neither urgent nor worried, the obviousness of a day that starts with a ticket to close before the others.
Catherine is almost never wrong on the first half of her sentence, and she's sometimes wrong on the second. Today's bug isn't a bug, it's four, and between the eight-AM one and the six-PM one fits a whole day that looks like one thing from afar and four very different things up close. We all tend to count incidents by tickets, by messages, by sessions, which amounts to counting by symptoms. Counting them by falsifiable hypotheses means finding four where we thought we only had one.
The autopsy that follows isn't a textbook case. It's an ordinary day I'd have preferred to end at seven PM and that I ended at eleven, because on the fourth bug I skipped the protocol that the first three had taught me to respect that very morning.
Bug number one, signatures that duplicate
Catherine reports that one of the branch's courses shows, in the attendance PDF, each student signed twice. The productive reflex arrives before reflection: "the form double-posts on double-click, we add a unique-constraint and move on". Fifteen lines of migration and done. Except it's wrong.
The /challenger skill imposes a different start. Hypothesis in one sentence: "the emargements ↔ seances join returns N×M rows when a course has multiple sessions generated for the same date." A structural cause, not a symptom. Three probes to refute, not to confirm:
-- Probe 1 — how many sessions for this course, this date?
SELECT cours_id, date_seance, COUNT(*) AS n_seances
FROM seances
WHERE date_seance = '2026-05-16'
GROUP BY cours_id, date_seance
HAVING COUNT(*) > 1;
-- 4 courses affected, 18 doubled sessions (school year filter mis-wired)
The output refutes the initial double-click hypothesis and confirms a deeper drift. Eighteen sessions appear in double because the session generator ran two passes with a getAnneeScolaire(date) filter mis-wired between 2025-2026 and 2026-2027 on the courses pivoting at the start of the new school year. The fix we would have placed on the form would not have erased a single phantom session, it would have just prevented future double signatures, leaving today's PDF spoiled.
The probe cost ninety seconds. The rollback it avoided, I estimate at a good half hour of commit-deploy-Sentry-Catherine-calls-back cycle. First ratio of the day, six to one.
Bug number two, the trainer's notes that vanish
Eleven AM. A trainer reports, calmly, that the pedagogical notes she enters at the end of an attendance form don't reappear when another trainer replaces her the following session. Surface hypothesis, seductive: "the form doesn't preload the previous attendance's notes". A line of useEffect would look like a correct fix.
/challenger hypothesis reformulated: "the notes_formateur field is bound to the signing user's identifier, not to the course or session, so a replacement by another signatory legitimately masks the notes entered by the regular trainer." Three probes: (a) read the schema, (b) read the component, (c) ask the trainer herself, because no technical probe can decide whether it's a bug or a business choice.
This is where /challenger cedes to another skill, ask-3-options-before-code, promoted to source in doctrine v0.7. Before writing a single line, formulate three options to arbitrate outside the technical realm: that notes are per-session and visible to all successive signatories, that they are private to the signatory and never shared, or that they are shared within a course's pedagogical team without being exposed to occasional replacements. The trainer chooses the second. There's no bug, there's a design choice that deserves a written decision rather than a fix patched by ear. Mini ADR, zero lines of code, two minutes of discussion.
Granted, a rushed solo dev would have done option 1 by default and deployed. But what seemed gained in speed would have cost three user complaints the following week, with the trainer's notes read by the entire branch, which she didn't want.
Bug number three, the phantom black line
Two PM. The planning editor displays a thin vertical black line on a single column, crossing the grid from top to bottom. CSS leak, says the eye. /challenger hypothesis formulated: "an orphan event surfaces an empty row that renders as a thick border, because a course deletion didn't cascade-delete its sessions." Three probes: DOM inspect, a consistency query on orphan seances, and — the probe that refutes by acquired discipline — git blame on the <PlanningGrid> component.
It's the third probe that decides. A recent commit added a conditional <hr> to visually separate branches in the grid, branching on an isLastOfAtelier variable miscalculated at the table edge. It's not a database ghost, it's an interface border. One TypeScript line, no migration, two minutes of fix. Had I started by searching the database, I'd have lost an hour inspecting courses and sessions that had nothing to reproach themselves with.
Bug number four, the one where I skipped the protocol
Six PM. Fatigue is here, and with it what must be called fragile certainty. An emergency paper attendance sheet prints "Thursday 2 PM" whereas the course is "Wednesday 2 PM". "The PDF prints the session date, not the course date", I tell myself, and I commit without a probe.
Twenty-five minutes later, rollback. Now all sheets say "Wednesday", including Thursday courses. The Sentry counter raises three alerts in five minutes. Catherine, on her end, didn't call back, she wrote "hum, it bugs" and left me alone with the fatigue.
The real cause, that a ninety-second probe would have surfaced, is that creneau_label is stored as LSC Cache without a refresher, diverging for three weeks for courses whose jour_semaine was corrected without propagating the label to the derived column. Not a PDF bug, a Live/Snapshot/Cache categorisation bug already documented in the doctrine, that the ADR-0024 audit had flagged a month earlier as a structural incident class.
An agent that doesn't contradict us isn't a counterpart, it's a faster typist; a skill we skip in the evening is no longer a skill, it's an abandoned rigour. The cost isn't in the occasional skip, it's in what the skip reveals — that the protocol holds on human discipline, not on a material mechanism still blocking enough to intercept end-of-day fatigue.
Three fixes held, one rollback, the ratio that matters
# ~/.claude/skills/challenger/SKILL.md (excerpt)
name: challenger
description: Force the formulation of a hypothesis in 1 sentence
then the execution of 3 material probes designed to REFUTE
this hypothesis before any fix code.
Over the day, the count holds in four lines. Bug one, probe held, fix correct, half hour saved. Bug two, protocol diverted toward the business question, two minutes instead of a user regression. Bug three, probe held, one-line fix, an hour saved. Bug four, protocol skipped, twenty-five minutes of rollback, Sentry alert, and the note in the journal that the fourth bug of a day doesn't have the right to be treated as an isolated fix. Three fixes held for one rollback, the ratio speaks louder than the average. The skill doesn't save us from the error, it saves us from the third hour of the same error.
A workshop metaphor might convey it: you don't fire a piece before checking the slip layer. The firing is the commit. The slip is the probe. Skipping the slip because you're in a hurry is what makes the piece crack in the kiln.
Five to ten minutes of probe avoid twenty to thirty minutes of fix-then-rollback cycle. The math is trivial on a day, it becomes crushing over sixty. If a single one of the four probes saves you, tomorrow, the rollback I had yesterday evening, the protocol has already paid for itself.
Skill /challenger, Counterpart Toolkit v0.7 R4 Falsify before fix. Public repo github.com/michelfaure/doctrine-counterpart. Article #54 of the series My ERP with Claude Code, autopsy of one day of four chained incidents.
Top comments (0)