When a blocking pre-push check passes, the count is correct
A skill count arrived in two consecutive sessions as fact: 131 total, 87 free and 44 paid, with a named skill supposedly added on a specific date. None of it was true. The named skill does not exist and never has, not in any working tree, cached copy, or anywhere in the repository history by content search, path filter, or revision scan.
The numbers were real text the system can print, but only as a parenthetical showing local-only counts alongside the public ones. Someone read the parenthetical as the count, and it propagated from there.
The evidence was already there
The count check is blocking, so a genuine mismatch would have refused the push. The pushes succeeded. Therefore the checker saw the correct number: 130 skills, 86 free and 44 paid.
Acting on the relayed figure would have meant editing the single literal that the blocking check compares on-disk truth against. Doing that does not correct a count. It removes the guard, after which the check passes against whatever was typed. On a mismatch, that literal is the last thing to change, not the first.
What shipped
Three documentation commits, all deployed. No version bump; none of it was code.
Rescoped the distribution document to the Pro bundle path and cross-linked it to the delivery document published the day before. The edit had been held while that target was unpushed and a security gap was open. Both resolved, so it shipped.
Re-derived every line hint in the count-location list. All of them had drifted, most knocked out by the previous day's release. One pointed at a section heading with no count in it, one at an unrelated link, one at a bare code fence. A hint that lands on the wrong line is worse than no hint, because it reads as a checked location.
Added a warning above the sync lists. Three sentences, placed where a reader meets it before reaching the lists, because the lists are what invite editing. The warning goes above the sync lists, not beside the literal, because the lists are what invite editing.
Problems that remain
A verification command failed on this locale and its fallback printed a clean result. A check that never ran reports the same thing as a check that passed. This is the third appearance of that exact failure. A dedicated scanner with an explicit positive control exists, and was used instead.
The same false claim arrived twice. Re-verifying it a second time cost a full read-only investigation that a recorded refutation should have made unnecessary. Two identical arrivals is a provenance problem, not a fact problem.
One gap stays open by choice: the push-time count check lives in only one of the two repositories, so commits to the other reach the production branch unchecked. Recorded rather than fixed, at the owner's direction.