Release review of the software-update piece and the front page that carries it

Findings

This is the release gate for a new piece, articles/where-a-software-update-went.md, its illustration, and the front page that carries it (README.md above the horizontal rule). The reviewer read the dispatch prompt, AGENTS.md and R-0003, then the piece once straight through as a newcomer would, then sentence by sentence against studies/LH002/LH002.md at version 0.2, its brief and cohort file, and the twenty-one tables in studies/LH002/data/. Every figure in the piece was checked against a table and not only against the write-up, since the record's Corrections entry shows the write-up once disagreed with its own tables: the lags, the pin history, the release intervals, the commit and release counts, the author classes, the line totals and the archive coverage were recomputed from the CSV timestamps and counts with a short Python script, and every x position in the illustration was recomputed from the table times on the axis the SVG declares. The SVG was rendered with cairosvg at 1600 pixels wide and looked at. Nothing was fetched from the internet: the piece claims nothing that the record and its tables do not carry, and the record is the study's own reading of 26 September 2026. The verdict is that the piece can be released after one must-fix, a stale version number in its colophon, and that the front page can be released as it stands, with one should-fix that the release commit can take. Everything else is a should-fix of a clause or a note.

The piece, sentence by sentence, against the record and its tables. Line numbers are the piece's.

The illustration, mark by mark, on the axis the SVG declares (x = 252 + 18.5 px per UTC day from 26 March 00:00):

The front page, sentence by sentence, against the piece and the record:

The piece

1. Must fix. Line 49, the colophon. "our study record of the neighbourhood, version 0.1, 26 September 2026" names an edition the record has left behind. The record's header reads "version: 0.2" and "date: 2026-09-26; corrected the same day as version 0.2 (see Corrections)", and its Corrections entry says what changed: the interval between the pin commit and the project's own release, 23 minutes to 22. The correction was made in the same commit that drafted the piece (1c31791), and the piece already uses the corrected figure ("At 18:49"). A reader who follows the colophon to version 0.1 finds a record that disagrees with the piece by a minute, and the rule for a colophon is that it links the record at its version; the released survey piece already carries a stale record version, which R-0003 finding 16 left for a correction. One number: "version 0.2, 26 September 2026".

2. Should fix. Line 43. "One project's move happened before its history on GitHub begins" is firmer than the record's label. The record says "The move to 1.27.0 happened in a history that the GitHub record does not hold ... (interpretation for 'happened out of view')", and the tables allow another reading: the lockfile could have been resolved in the making of that first commit, on 4 April, in which case the move happened at the edge of the visible history rather than before it. The piece's line 15 has it exactly ("already held the new version in its first commit there"); line 43 should not say more. "One project's move is nowhere in its history on GitHub, which begins with the new version already in place; its earlier release points to a repository on another site, which we did not read."

3. Note. Line 23. "one of five written in one commit to hold steady the versions that another of its dependencies pulls in". The five exact pins are in data/manifest_dependency_changes.csv. The purpose is the record's reading of the commit's message, which no table retains and this review could not see. The record states it without a table cite; the piece follows. "written in one commit which, its message says, was to hold steady ..." would place the claim. No change required.

4. Note. Line 23. "eight commits across the ten projects". The eight are in two of the ten, the library and one dependent (data/authors_pseudonymous.csv, B01). "Across" reads as spread; "in two of the ten projects" is exact and costs nothing.

5. Note. Line 13. "The Python Package Index ... gives the minute". The study read the minute from Open Source Insights, which reports the registry's publication time (Findings, first paragraph). The colophon says so in the same breath: "Open Source Insights, for ... the publication times the Python Package Index records". No change needed.

6. Note. Line 35. "That is a second step, visible from end to end in public records". The record labels the second hop an interpretation. What is observed is the chain, pin commit to release to a registry requirement of ==1.27.0; what is interpreted is that installers received it, and the piece carries that part as "would have received". The sentence is within the label.

7. Note. The colophon at release. The form matches the two released pieces: sources with dates, the record linked, the method in a sentence, who wrote it, the review line, version and date, corrections, the Lighthouse line, and the interest disclosed (Claude in the trailers, Claude writing the piece). What the release act adds, as it did for the released pieces: "edited by" if the driver edits, the review link in place of "pending", "Version 1.0, released 26 September 2026", the released form of the corrections line, the Draft label off the byline, and a line in releases.md.

8. Note, on the record rather than the piece. The record's figures against its own tables. Every figure the piece uses was reproduced (the table above), and so were the record's totals the piece does not use: 271 observed and 143 active repository-days, 9.25 and 4.22 commits a day, 13, 1,625 and 870 by author class, the 8,065,850 and 7,632,433 lines outside lockfiles and 77,205 and 39,128 within them, 24 trailers, 83 tags, 74 releases, 50 tags for R06, nine days missing for R04, and the GH Archive scenario (672 files, 23,935,256,352 bytes, 0.49 hours). No second error of the kind the Corrections entry records was found. One rounding: "a window of thirteen days" between the archive's visits of 25 March 09:45 and 6 April 22:44 is twelve days and thirteen hours; the piece gives the dates, not the count.

The illustration

9. Note. The dates, times and marks agree with the tables, and the caption says what the figure shows. Every position recomputes to the tenth of a pixel from the table times (second table above). The rendered figure is legible: five labelled rows, the release as a vertical line with its time, the hatch for the days before R04's history begins, the ring for "already holds it", the dashed band beneath. No line joins the release to any move, which is the record's point about order and cause, and the desc says so. The caption is one line and matches the piece's argument. The alt text in the piece and the front page is the SVG's desc in substance.

The front page

10. Should fix. Line 15. "The software neighbourhood above is the first thing we have read with our own hands" is contradicted by the table two lines below it. Rows 4 and 5 are "Ours" since 25 and 26 September, the Harbour export and the host sampler, and LH000 took two host readings by hand on 25 September; all predate the LH002 collection of 26 September, 12:55 UTC. The claim is true of the wider internet, which is what the paragraph means ("Until now, almost everything we knew came through other people's instruments"), and one clause makes it so: "The software neighbourhood above is the first thing beyond our own machine that we have read with our own hands". The same phrase sits below the rule at line 37 ("Its first reading with its own hands") and in AGENTS.md line 9; the driver may align them.

11. Note. Line 29. "whether it can connect a release to the machines that took it". Download records count downloads by version and installer; they identify no machine. The record's Next says "connect a release to installation" and the programme's LH005 "connect a software release to its installation". "To the installations that took it" would ask the question the record asks. It is a question, not a claim, and the sentence goes on to say a download is not a program running.

12. Note. The standfirst, the row and the links are right. Every sentence of the standfirst is in the piece; the new row's subject, instrument and date are the record's header; the alt text and caption are the piece's by diff; every link above the rule resolves, and none carries an anchor into programme.md. "The record" links the study directory rather than the write-up, which suits a row that speaks of tables and scripts.

The piece and the front page

13. Note. The class of claim that needs a person. Nothing in the piece or on the front page says harm is happening now or names a system as compromised. The piece reads four moves as ordinary maintenance and says so with "we read"; the AI trailers are reported as the authors' own statements and not weighed; the dependents are unnamed; the library is named as its public address. Nothing is irreversible outside the repository.

14. Note. The piece keeps the rules. No person's name or handle: none in the piece, the SVG or the front page (searched for all ten namespaces and package names). No dependent named: none; the library, mcp, is named, which the rules allow. No internal reference in the prose: the only "study", "record" and "LH002" are in the colophon, where the link to the record belongs. One idea a reader could say back: public records show where a change went, not why, and not whether anyone ran it. The opening is a moment, a maintainer's commit at 18:26 UTC. The verbs are honest: "the records show", "nothing we read records a reason", "we read all four as", "as we understand", "we think". The Draft label is on the byline and the review line reads "pending"; neither was touched. British spellings throughout; no em or en dash in the piece, the SVG or the front page (by code-point count). Read silently for rhythm twice; nothing trips.

Verdict

• articles/where-a-software-update-went.md: release after finding 1, the record's version in the colophon, 0.1 to 0.2. Finding 2 should go in the release commit; findings 3 to 8 are notes. Every figure traces to a table and reproduces; every interpretation is carried with the record's hedge, except the one clause in finding 2.
• articles/where-a-software-update-went-timeline.svg: release as it stands (finding 9).
• README.md above the rule: release as it stands. Finding 10 is a one-clause should-fix the driver can take in the release commit; findings 11 and 12 are notes. The standfirst says only what the piece says, the row is accurate, the next question is the record's second Next entry and the programme's LH005, and every link resolves.
• Nothing in the piece or the front page falls into the class of claim that AGENTS.md reserves for a person (finding 13).

What the review could not check

• The commit messages: the purpose of R04's five pins (finding 3), the "dependency-update wording" classes, and the exact two commits that carry trailers. The clones are not retained; the day totals in data/repo_day.csv are consistent with the record.
• Open Source Insights' dependents list naming lean-lsp-mcp 0.26.0 under 1.27.0, and git's date for the release commit (2026-03-24T22:24:47Z); neither is a retained table. The archive file holds the release commit's hash.
• No public source was fetched. The piece claims nothing the record does not, and the record is the study's reading of 26 September; a fetch today would show the forge as it stands later, which is a different reading.
• The scripts were not re-run against fresh clones (1.1 GB and the network). Every derived figure was recomputed from the retained tables instead, and all agreed.
• The SVG was rendered with cairosvg, not in a browser. Reading aloud was a silent read, twice.
• The review's own cost is not measured here; the driver prices it from the transcript.