Drop a count that only stayed true by being dated - #85
Conversation
The HUGO_BASEURL item said a wrong base URL would have run 1,245 requests at the live site. That was the live check size on 2026-08-07 and the sentence is a counterfactual about that day, so it was defensible, and leaving it meant a reader validating a deploy met 1,245 and 1,253 in one file with nothing connecting them. The number was never load-bearing there. The point is that the check would have been aimed at the old platform, which the sentence makes without it. Same reasoning as removing the duplicated release id: a value that has to be dated to stay true is better removed than dated, because the next reader has no way to know which vintage they are holding. Found by Copilot review on #83, as a suppressed comment, having been declined once on the grounds that the counterfactual was accurate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Removes an outdated, easily-stale request-count from TODO.md so the document doesn’t present conflicting “current-state” numbers and instead refers to the live check qualitatively.
Changes:
- Replaces a specific “1,245 requests” claim with “the whole live check” in the
HUGO_BASEURLproduction environment item.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Uh oh!
There was an error while loading. Please reload this page.
Two comments said the script runs 1,245 requests. It runs 1,253: the 1,245-URL contract plus the eight media probes added when the live media check landed. The file describing what it does was the last thing to know what it does. Neither states a number now. One says it runs one request per URL checked and the other says one request before the rest, which is what each comment was actually about, and neither goes stale when a list grows. The three other occurrences in the repository are correct and are left alone. 1,245 is the URL contract, 328 render plus 917 redirect, and 1,253 is what the live check requests because it adds eight media URLs. The blog post contrasting 1,245 with the sitemap 111, the audit report quoting a 2026-08-04 run, and the parity note about a build baked with the wrong host all mean the contract and all say so correctly. Found by Copilot review on #85, which caught the PR description claiming 1,245 appeared nowhere when it had only been grepped out of two files. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (1)
checks/check-live-urls.sh:117
- The comment says the script runs "one per URL checked", but a single URL can trigger multiple curl invocations (e.g., redirect checks fetch both the redirect status and destination; media checks may resolve a redirect then fetch headers/body). That makes the comment inaccurate even though the security rationale still applies.
# A command line is also world-readable in ps output, and this runs one per URL checked.
The comment claimed one invocation per URL checked. A render check is one curl, a redirect check is three, and the media check reaches six, so the count was wrong in the direction that understates the exposure the comment exists to explain. It now says every request would carry the token, which is the actual reason the credential goes in a config file rather than on a command line, and which no list or code path can make stale. Found by Copilot review on #85, as a suppressed comment, on wording I had introduced one commit earlier to remove a different stale count. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ptr727
commented
Aug 9, 2026
Fixed. Correct, and I introduced that wording one commit earlier while removing a different stale count — so the replacement for a wrong number was itself a wrong claim. Counted the invocations rather than reasoning about them: So "one per URL checked" understates it by up to six times, and understates it in the direction that weakens the security rationale the comment exists to give. It now reads:
Which is the actual reason the credential goes in a config file rather than on a command line, and which no list length or code path can make stale. That is the third count in this PR replaced by a statement that cannot go out of date — the same move as dropping |
Uh oh!
There was an error while loading. Please reload this page.
Found by Copilot review on #83, the promotion — and declined by me once already, which is the part worth recording.
The finding
The
HUGO_BASEURLitem said a wrong base URL would have "run 1,245 requests at the live site to verify it". The State table says the live check is 1,253.When this came up earlier I kept 1,245, reasoning that the sentence is a counterfactual about 2026-08-07 and the check genuinely was 1,245 that day. That reasoning is correct and it is not sufficient: a reader validating a deploy meets 1,245 and 1,253 in one file with nothing connecting them, and has no way to know one is a vintage.
The fix
The number was never load-bearing. The point of the sentence is that the check would have been aimed at the old platform — which it makes without any count:
Same reasoning as removing the duplicated release id in #82: a value that has to be dated to stay true is better removed than dated. Being accurate-as-history is not the same as being useful, and this file is read for current state.
1,253now appears only in the two places that describe the live check as it is, and1,245appears nowhere.