- Shipped
- 5 Septemba 2026, 02:58 UTC
- Author
- Kamo
- Commit
- 2a78ddb
The strike meter on the sign-in screen was telling people something the server then did not do. tierFor starts the five-second delay at the SIXTH failure, but attemptsBeforeNextTier and nextTier both treated the fifth as the rung — so a subject sitting on five failures was told "5 more attempts before signing in pauses for 5 minutes" and was paused for five seconds on its very next attempt. Off by one on the count, and naming the wrong tier entirely. Three functions each encoded the ladder separately, which is how they drifted. The two look-ahead ones now read a single rung table. tierFor deliberately does not: it answers what a failure EARNS, and three of its rungs fire on an exact crossing rather than at-or-above, which that shape cannot express — keeping them apart is what makes each readable. Pinned by two properties rather than another table of numbers, because a table is what was wrong: whatever the screen promises next must be what tierFor charges for the next failure, and no LOCK may arrive earlier than the countdown says. Note what the second does NOT claim — above five failures every failure costs five seconds, so the rung is the next ESCALATION, not the next consequence. The next rung now travels as a NAME as well as a label. There is no duration that completes "signing in pauses for ..." when the answer is "for ever", so anyone within five attempts of a permanent block was reading "pauses for permanent." The sentence has to change, and only the tier can tell the client when. Same reason the ladder chip in Detection Rules reads "permanent block" rather than "permanent", which parsed as a duration. loginWithoutAResolvedHost becomes loginWithoutANamedWorkspace. The name stopped being true when the unknown-host gate landed: a host that resolves is now the only way in. What is missing there is a WORKSPACE, not a host — which matters, because the list it builds comes from proven membership and never from the hostname.