Release review of the published-images piece, its short form, the front page that carries it, the programme paragraph and the record behind them

Findings

This is the release gate for articles/what-an-image-holds.md, its illustration, its short form, the front page above the rule, the LH006 paragraph and LH007 section in programme.md, S24 and S25 in sources.md, and the record studies/LH006/. The reviewer read the dispatch, AGENTS.md and R-0005, then the piece straight through, then sentence by sentence against LH006.md at version 0.1, its brief, its source assessment and the tables in studies/LH006/data/, recomputing each derived count from the tables with short Python. Unlike a review of a summary, this one went to the registries: the two agentcrew images the piece turns on and two of serena's were read again from Docker Hub and ghcr.io with the reviewer's own script, written after reading scripts/registry.py rather than by running it, streaming each image's layers from the top and stopping at the mcp dist-info; agentcrew's Dockerfile, its Docker-specific project file, its lockfile and its publishing workflow were read from a blobless clone at the commits the record names; and jesse's repository was cloned to settle the pin question the writer flagged. The piece's SVG was regenerated from its script and compared byte for byte; the driver had already rendered it in light and dark, and the reviewer did not render it again.

The verdict is that the piece, the short form, the front page and the programme paragraph can be released as they now stand, after the changes below, which the reviewer made. Every figure in the piece was found in the record's tables or derived from them, every registry reading reproduced gave the same version and the same configured build time, and every link resolves. What had to change was one count that the piece, the short form, the front page and the record all gave as 37 images read where the table has 38 read and 37 holding mcp; one header phrase in the record ("two older" bracketing images where there is one); one unlabelled inference in the piece and the short form (the 8 April tag move) and one in the record (keboola moving "with its pin"); and a data label ("lockfile only") that named a lockfile pin the reads never saw. None changes a conclusion.

The piece, sentence by sentence, against the record and its tables

Line numbers are the piece's at ebabb93. "Live" means the reviewer's own registry read on 26 September at 19:24 to 19:26 UTC; "recomputed" means from the tables in data/.

The record against the primary sources

Every registry reading below was made on 26 September 2026 between 19:24:44 and 19:25:54 UTC, about an hour after the study's, through the same shared proxy, with anonymous tokens whose values were not kept. The reviewer's script chose layers by their history lines (skipping steps that only make directories or set the working directory, which the study read), so its byte totals differ from the study's where the layer choice did; the layer that held mcp and the bytes into it are the same.

The writer's open questions

1. Must fix, fixed. The count of images read. The Answer said "37 images had their installed mcp read and one was found to hold none", which a reader takes as 37 in all; the piece, short form and front page said "37 images of six projects" and then named jesse's mcp-less image among them. The table has 38 images read to an answer: 37 with an mcp version, across five projects, and jesse's one with none. All five places now say 38 read, 37 holding mcp. The programme paragraph's "the installed mcp in 37 images" was already right and is unchanged.

2. Must fix, fixed. Header: "two older and one later bracketing image". The images outside 20 March to 27 May are serena dev (11 December 2025) and octobot 3.0.0-beta1 (30 July 2026): one older, one later, as the piece's colophon already said.

3. Should fix, fixed. The 8 April tag move is an inference. The record labels it ("the tag's history is inference from the workflow"); the piece said "was published by moving a tag" and the short form "as agentcrew's was on 8 April". The evidence is strong (the workflow gives every CI build the vX.Y.Z tag, the CI build of 0.12.3 no longer carries it, the 8 April image does, has no labels and a +07:00 clock) but no registry shows the tag's history. One clause in each.

4. Should fix, fixed. keboola "moved only when the pin did". keboola has no public repository, so its pin commit is not seen. What is seen is that the image built at 12:50 on 17 April holds package version 1.56.2 with mcp 1.27.0, and that PyPI 1.56.2, published 2.7 days later, is the first release to require 1.27.0. The Answer now says the move with the pin is inferred from that, and the piece's own sentence already said it that way.

5. Settled. jesse's 14 February pin against its mcp-less 28 March image. From the clone: the commit requirements.txt gained mcp==1.26.0 in (7300efb5, 14 February) is on master's first-parent chain, which is what scripts/collect_pins.py walks, and is an ancestor of the 2.1.3 commit (08b81849, 20 May). It is not an ancestor of the 28 March commits (cad0cfae, "Fix package build inputs", 15:04 UTC, eleven minutes before the 1.13.8 image was built and PyPI 1.13.8 published) nor of "Bump version to 1.13.8" (b64c867d, 16 March); at those commits requirements.txt has no mcp line, setup.py reads its requirements from that file, and the Dockerfile runs pip3 install -r requirements.txt then pip3 install -e .. So the 1.13.x images and releases came from another line of the repository than the one the pin table follows, and the record's three statements (a pin from 14 February, no mcp in the 28 March image, no PyPI requirement until 2.1.3) are all true of different lines. A Findings entry and a Limits entry now say so. Not checked: when that line was merged, and from which line 2.0.0 to 2.1.2 (which require no mcp) were built.

6. Fixed. image_mcp.csv method "lockfile only". The value meant "no dist-info seen; a requirements or lock file was seen", and in both rows the file had no mcp pin. Renamed in scripts/collect_images.py and in the two rows of the table; analyse.py does not test for the old string; the Method sentence names the old value.

7. Consequential. Record version. Findings 1, 2, 4 and 6 change figures or labels in the record, so it is now version 0.2 with a Corrections entry, and the piece's colophon cites version 0.2 (R-0004 finding 1 and R-0005 finding 1 were this slip in the other direction).

The interpretation boundary and labelling

8. Note. Kept. The record labels each paragraph (observation, derived, interpretation, inference) and names the cause of agentcrew's early move as interpretation; the piece carries it in verbs ("What the image records is what the installer gave", "that fits a build made on someone's own machine", "We think the nearer question"). The piece's one qualification, the section "A thin record, and not a run", is present and matches the record's Limits: six projects are not a population, one held no mcp, an image is not a run, a pull is a request. Line 25's "The images show exactly that" rests on the Dockerfile read from the repository and the 22 April CI build whose lockfile said 1.26.0 while the image held 1.27.0, which is observation, so it stands. The front page's lead says "we counted it among the projects that had not moved", which LH002 did. Nothing in any file claims harm now, names a system as compromised, or did anything irreversible: the study and this review created no account, read no credential and made anonymous reads only.

9. Note. The programme. The LH006 paragraph's figures (37 packages, 7 and 6, 37 images with mcp, 5.5 days, 2.9 days, 11 minutes, 17 April and three days, end of July, nine tags, 100 an hour, 30 pulls) are the record's. The LH007 section is a design, not a claim, and its access note (prefer ghcr.io, HEAD where a digest suffices) matches what the reads showed. S24's "100 pulls an hour, against six hours in Docker's documentation" is what the reviewer's HEADs returned.

House style and the rules

10. Note. Kept. No em or en dash in the piece, short form, front page, programme, sources, record, brief, source assessment or figure (checked by code point). British spellings. No internal reference in the piece's or short form's prose: "record" appears as a plain word and the study number only in colophon links. Every relative link in the three reader files resolves (6 in the piece, 1 in the short form, 26 on the front page). The Draft labels are on both bylines for the driver to remove. One idea a reader can say back: a published image records what was installed, and it was not always what the project had pinned. The piece's SVG regenerates byte for byte from scripts/draw_piece_figure.py against the three tables it names.

What the review could not check

• The other 34 image readings, and the four undetermined ones: they are the study's tables, taken as published; the four that were reread agreed to the byte on ghcr.io and to the nanosecond in created on Docker Hub.
• The tag lists, tag records, pull counts and the Docker Hub search count (data/tags_hub.csv, tags_registry.csv, context_reads.csv) were not re-fetched; the derived counts from them were recomputed.
• The 26 repository clones behind candidates.csv and Open Source Insights' 34 dependents: not repeated; only agentcrew and jesse were cloned.
• The eight documentation pages D1 to D8 were not re-fetched; the one quantity that matters, the limit as served, was reproduced from the headers.
• The figure was not rendered by the reviewer; the driver rendered it in light and dark and reported it legible.
• Whether Docker Hub still serves a replaced, untagged manifest, and ghcr.io's version history: unreadable anonymously, as the record says.
• The review's own cost is not measured here; the driver prices it from the transcript. Its network use: three counted Docker Hub pulls, two ghcr.io manifests and two indexes, 403,429,983 layer bytes streamed, two blobless clones.

Changes made by the reviewer

1. studies/LH006/LH006.md: version 0.2; header "one older and one later bracketing image"; Answer "38 images were read to a result: 37 held an installed mcp and one, jesse's, held none"; Answer's keboola sentence rewritten as inferred; a Findings entry on jesse's two lines; the Method sentence on method; a Limits entry on first-parent pin tables; the Corrections entry.
2. studies/LH006/scripts/collect_images.py and data/image_mcp.csv: "lockfile only" renamed "no dist-info; requirements or lock file seen" (two rows).
3. articles/what-an-image-holds.md: line 19's count; line 51 "as far as we can tell"; colophon cites record version 0.2 and names this review.
4. articles/short/what-an-image-holds.md: "38 images"; "appears to have been"; the review line.
5. README.md: "38 images" in the lead and in the table row.

Verdict

Nothing remains that must be fixed. The piece, the short form, the front page above the rule, the programme paragraph and S24 and S25 can be released as they now stand; the driver removes the Draft labels, fills the piece's version and date on release, adds the releases.md line, and commits the record at version 0.2 with the piece.