A good build week is boring from the outside: the same small loop, run morning after morning, each pass leaving one more rung landed and nothing behind it broken. The loop's rules are not etiquette; each one is a defence against a specific, well-documented way build weeks die. This page gives the loop and the reasons, so that under Thursday's pressure you keep the rules because you believe them.
The daily loop
Six stations, one lap per rung, several laps per day on a good day. Stations 1 and 2 take minutes, 3 takes the hours, and 4 is the one the pressure will tempt you to skip, which is exactly why it is drawn heavy. Nothing new starts while station 4 is red.
One rung in flight
The cap in the centre has two justifications, one cognitive and one structural. Cognitive: task switching is not free; attention research (Monsell's classic review of switch costs, 2003) finds measurable time and error penalties every time you resume a task mid-state, and a half-built rung is nothing but mid-state. Structural, and heavier: the ninety-ninety rule from the previous page locates most of a rung's hidden cost at the join, so a rung that is "built but not joined" has banked its cheap 90 % and still owes its expensive one. Three such rungs are not 90 % of three greens; they are an inventory of unpaid joins, each a candidate for Week 12's two-sided contract failures. The figure below is the whole argument:
Un-joined work is risk inventory, not progress. Pair A will experience Sunday as four simultaneous integration surprises; pair B spent the same hours and banked the surprises one at a time, with week left to absorb each. Demos, markers and the table all agree on which week went better.
The definition of done
The loop needs a hard boundary for "done", or the ninety-ninety rule will quietly redefine it downward all week. A rung is done when all four hold, and not before:
Joined: running in the real system, not beside it; the stub it replaced is retired.
Regression-clean: the old rungs re-run green after the join, this station's whole point.
Recorded: the verification table cell updated with today's date and the evidence, per the scoreboard page.
Pushed: committed on a main that walks, so the other partner, and a dead laptop, cannot lose it.
Anything less is "in flight", and the list on the wall should say so. The phrase "basically done" is banned by house rule; it is the ninety-ninety rule introducing itself politely.
Re-run everything, every join
Why re-run rungs that already worked? Because "worked" is a statement about the system as it was, and every join changes the system. Regression testing is the standard name: changes, even correct ones, break distant things, and they do it through exactly the surface Week 12 counted, the shared contracts, up to n(n−1)/2 of them, where a new component can shift timing, topic traffic, resource use or message shapes that an old component silently relied on. The economics are lopsided in your favour: your full re-run is minutes (the firehose, a curl, one disturbance, one setpoint change), while an uncaught regression surfaces at the worst possible moment by construction, since the next full run of everything is otherwise the demo itself. Minutes now, or Monday. The pairs' docs/verification re-run commands from Week 12 make the ritual mechanical; mechanical is what survives pressure.
Debt: journal it, don't chase it
Build weeks generate ugliness: a hard-coded threshold, a copied block, a function named handle2. Ward Cunningham's debt metaphor (1992, the origin of the term technical debt) prices it honestly: shipping not-quite-right code is borrowing, and every minute it stands you pay interest in confusion and caution. But the metaphor cuts both ways, and this week it cuts for you: debt is a legitimate instrument when the deadline is real, provided it is recorded, because unrecorded debt is the kind that compounds. The house rule: make it work, journal what is ugly in docs/ with one line each, and repay nothing this week unless it blocks the next rung. Refactoring a working system during the proof week converts a green to a maybe at the exact moment greens are the product; January is cheap, December 7 is not.
The journal line format
DEBT: node/main.py hard-codes SP fallback at 50; fine for D4, parametrize later. One line, file named, why it is acceptable now, what later looks like. Five of these in the journal read as engineering; five surprises in January read as archaeology.
Checklist for this stage
Check yourself
It is Thursday evening, the week is behind, and skipping the re-run would save twenty minutes tonight. Make the case for skipping, then dismantle it with the economics.
The case for skipping: the join was small, nothing old touches it, and twenty minutes times several joins is real time in a behind week. The dismantling: "nothing old touches it" is a claim about up to n(n−1)/2 contracts you have not checked, made at the moment you are most tired and least careful, and it is exactly the claim regression testing exists because people get wrong. The expected cost comparison is minutes with certainty against a small probability of a break that, unchecked, surfaces at the next full run of the system, which is now Monday's demonstration. Twenty minutes against any meaningful chance of debugging live at D4 is not a close call; and if the re-run really is the bottleneck, the fix is making it faster (scripted, ten minutes), not rarer.
Your partner wants to start the alert rung while the sensor rung "finishes overnight" as a service burning in. Does WIP = 1 forbid it? Where exactly is the line?
The line is drawn by the definition of done, not by the clock. If the sensor rung is joined, regression-clean, recorded and pushed, and the overnight run is extra evidence (a soak test), it is done: pulling the alert rung is the loop working, not a violation. If the overnight run is the thing that will tell you whether the join actually holds, the rung is still at station 4 and the alert rung must wait, because starting it means two rungs mid-state and the morning's failure, if it comes, lands on a pair already context-switched away (Monsell's cost) with new changes tangled into the diagnosis (half-splitting now has two suspects' worth of segments). Practical compromise that respects both: spend the waiting hour on a zero-integration task, the journal, the README, rehearsing the demo sentence for the landed rungs.
Classify, as acceptable-and-journal or fix-now: (a) the bridge's topic string appears in two files; (b) the monitor crashes if the first message arrives malformed; (c) the dashboard JS has a copied fetch block with one changed URL.
(a) Journal it: duplication is classic principal-only debt, zero behaviour risk today, one DEBT line, parametrize in January. (c) Journal it: same category, ugly and stable. (b) Fix now, because it is not debt at all by Cunningham's meaning: debt is working code that is structured expediently, while a crash on malformed input is a correctness hole in a system whose demo includes disturbances and whose services (Week 12) will restart-loop through it; it threatens greens you already banked. The test in general: does it change what the system does under the demo's conditions? Yes means fix, no means journal. Rung-worthiness is not aesthetics; it is behaviour.