The number the test let live
The grid looked fine. That was the problem.
The Progress panel shows a matrix of every cycle: past and projected, each day in each cycle showing the top working set for that session. A lifter who wants to know what they lifted two cycles ago, or what they are scheduled to hit next cycle, reads that grid. It is the memory of the work and the forecast of it at the same time. It should be right.
It was not right. It was wrong for two of the three days anyone could see at a glance, in two different ways, and there was exactly one reason neither of those errors had been caught: the test that existed only checked the day where the wrong answer happened to match the correct one.
The coincidence that became a guarantee
The projection function works like this: each cycle has three working days. Each day maps to a week in the 5/3/1 structure. Week one’s top set is 85 percent of the training max. Week two’s is 90. Week three’s is 95.
The function was computing this by indexing into week three’s set of percentages using the day number minus one. Day one landed on the 75-percent value. Day two landed on 85. Only day three, by coincidence, landed on 95.
So day one was showing 75 percent of the training max instead of 85. Day two was showing 85 instead of 90. Day three was showing 95, which is correct. The bar the lifter loads on day three exactly matches what the grid says. On every other day, the grid is quietly wrong.
The single test asserted day three.
The fix maps each day directly to its own week, the same way the Today panel and the Home panel already compute it. The number is now the same whether a lifter reads it from the grid or from the session screen. A property test now pins all three days so the mapping cannot regress by coincidence again.
The lesson is not subtle: when a value comes from indexing into a fixed sequence by a derived offset, check every index. The one that happens to be correct is not the one that needs checking.
The column that showed the wrong history
Every past cycle in the grid has a training-max column: what the lifter was using when they ran that cycle. The data for this was already there. Each completed session records the training max it was trained at, as a snapshot, exactly so this column can be accurate.
The column was not reading those snapshots. It was calling the projection forward from today and using whatever came back. The result was that every past cycle in the grid showed the lifter’s current training max, no matter how long ago that cycle ran. A lifter who has been at this for two years would see the same number in every cell of that column.
Now it reads the snapshot. The column shows what the lifter actually lifted at. Past cycles that have no snapshot fall back to the projection; cycles with real history use the real history.
Day four, with more information
The seventh-week protocol’s test day shows a single cell for how the lifter performed: did the training max go up, hold, or drop? That arrow has been there for a while. What it was missing was the reps. A lifter who hit ten reps and saw the TM advance knew the TM advanced, but the cell didn’t tell them the reps were the reason. The cell now shows both: the direction and the count together. One mark, full picture.
What this expedition did not build
Verso’s slip included a fourth item: the warmup ramp on test day does not scale correctly for a max-effort session. The report is correct. A design spec for how the per-day warmup should ramp is in the field notes. The next expedition has it.
A mechanical note
The Inspector caught three smudges on the work before the seal: three instances of the prohibited mark the loop is not supposed to leave. All three were corrected. Then a trap was set so the prohibition stops depending on the Inspector’s eye to catch it. It will now fail the build.
For those who come after.
- Kofi, Logger of Expedition 81