Loading today’s stories
Build1 distinct publisher3 min readUpdated
WhyRep bounded its plateau read to 14 misses plus two rows. Any lifter who deloaded once during a stall stopped being told they had plateaued, and nothing logged it.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Both wrong answers were the same wrong answer. The first bound was denominated in days while the rule is denominated in consecutive missed sessions, which vary by lifter tier and by whether the movement is a big or small joint action [4]; that is why a 14-day cutoff could not have fired a plateau for anyone above beginner tier and would not have thrown while failing [7]. The author's own summary is that the unit was wrong, not the number [23]. The replacement bound is denominated in database rows while the rule is still denominated in misses [11], and the exchange rate between those two units is set by the data, not by the constant.
The arithmetic is small enough to do in the margin. The widest window in the signed methodology is 14 consecutive sessions without progress [5], so the shipped budget was 16 rows [19]. One row goes to the baseline session that gets consumed and cannot count as a miss [9], fourteen go to the streak, and that leaves exactly one spare [20]. A flagged deload is one of four ordinary paths that emit NO_VERDICT [12], and every one of them eats a row while adding nothing to the count [11]. One deload inside a stall spends the whole margin, and the two rows that would have closed the streak fall off the far end of the window [15].
Neither component is broken. Skipping no-verdict sessions without resetting the streak is deliberate and right, because such a session is evidence of neither progress nor a miss [10]. The defect lives in the seam, where a quantity measured in misses was converted into a quantity measured in rows at a rate of one to one. Since nothing caps how many no-verdict rows a real history can contain [13][21], no constant can be exact, and the KDoc claimed exactness [9].
That is also why the five tests were never going to help [8]. A fixture can only expose this bound if it places a no-verdict session inside the miss streak [22]. Step four of the derivation assumed step three described the only case, and that assumption was never written down [14], so it was not available to anybody building test data from the same reasoning. The comment made it harder, not easier: it cites the correct constant and derives correctly from its premise [9], so a reviewer checking the doc against the code finds them in agreement.
The output was legal, which is the part worth keeping. The read succeeded, the analyzer returned no plateau, and no crash, error, or log line marked the difference between "no plateau" and "I could not see far enough to tell" [16]. The lifters who hit it were the ones deloading mid-stall, which is the correct thing for a lifter to do [17]. The author stopped reasoning and reproduced it instead: elite tier, barbell curl, 40 weekly sessions [18].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
WhyRep's stated promise is that it tells a lifter when they have stalled and what to change, with every verdict traceable to a methodology document rather than to a language model.
The architecture precomputes nothing: verdicts are derived from raw set logs on read, every time, so there is no cached judgement to go stale when the rules change.
As a result, every read walked the lifter's entire history for every exercise in the session, which the author describes as fine at ten sessions and not fine at three hundred.
The plateau rules are not measured in calendar time; they are consecutive-miss counts that vary by lifter tier and by whether the movement is a big or small joint action.
The widest plateau window in the signed methodology is an elite lifter on a small joint action: 14 consecutive sessions without progress.
For a lateral raise trained once a week, 14 sessions covers over three months of data.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific and self-consistent, but single-source and self-reported
The account is unusually concrete for a blog post: it quotes the constant and its KDoc, enumerates the four NO_VERDICT paths, and gives a named reproduction fixture (elite tier, barbell curl, 40 weekly sessions, one deload). The internal arithmetic checks out. But every element comes from one first-person author writing about a private codebase, with no repository link, diff, test output, or third-party confirmation in the supplied material, which caps evidentiary strength.
No adoption signal in the supplied source
The article discloses no user counts, install numbers, session volumes, release identifiers, downstream dependents, or third-party usage of WhyRep. The only quantities given are fixture and rules-table values (14 misses, 16 rows, 40 simulated sessions), which describe the bug rather than uptake. There is no basis to score adoption without inventing facts.
Claims scoped tightly to the evidence, mildly under-sold
The post's assertions stay inside what it demonstrates: it names its own bug, calls its own prior reasoning wrong, and confines severity language ('P0 coaching-logic regression') to its own product. If anything it under-states the generalizable finding, that a bound on rows cannot encode a limit on misses, treating it as a personal lesson rather than a pattern others repeat. The small negative reflects that mild understatement, offset by the unverifiable severity label.
Disclosed contest submission that also markets the author's own app
The first line discloses that the piece is a submission for DEV's Summer Bug Smash: Smash Stories, so there is a competitive publishing incentive to make the bug narrative compelling. The post also promotes WhyRep and its methodology-traceable positioning. Both incentives are disclosed and cut against self-flattery, since the story is an admission of error, which keeps the score moderate rather than high.
Confident on mechanism, unsupported on impact
Confidence is high that the described mechanism is real and internally coherent: the interaction between streak-skipping and row consumption follows from the stated code behaviour and the arithmetic is checkable. Confidence is low on anything beyond the author's own machine, including whether the fix holds, how many real lifters were affected, and whether the methodology document says what is claimed, because there is exactly one publisher and no adoption evidence.
build
"No key, no SDK" is not a guarantee on Android: the manifest merger gets there first1 distinct publisher
build
Sentry's defaults shipped a lifter's shoulder injury while the scrubbing policy passed its tests1 distinct publisher
build
One game, two codebases: where parity belongs when you ship native on iOS and Android1 distinct publisher
build
The 39 rows that vanished at per_page=100, and the 277 refusals that never raised1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026