R-0025: A reader's review of two pieces, version 1.2

Stage one, 29 September 2026. Read before anything else: articles/two-days-for-most.md, its short form articles/short/two-days-for-most.md and articles/old-versions-new-pythons.md, all version 1.2; "Current focus" in README.md; "How the work is checked" in about.md. No record, brief, data, note, programme, investigation page, release list or history was opened, and no link followed.

What a reader would believe, written before reading the record

The finding, said back. A new version of a big Python library takes most of its share of downloads on its first full day, gains a few points over the month, and older versions keep the rest. For 26 of 37 libraries most releases passed half within two days; for eleven, boto3, numpy and pandas among them, none did that month. In a later week older versions were 37 per cent of the typical library's downloads, mostly, in 32 libraries, from Pythons a newer version supports.

Observed: shares by version and day for 424 releases, April to August 2026; one September week by version and reported Python; the first-day pattern, noticed after the counts, then holding on 355 unread releases, 28 of 32 libraries, though still rising. Explained, hedged: the first day reaches the machines that take whatever is newest, so a low share is a small pool, not a slow spread; build-flagged downloads leaning to the replaced version fit builds holding pins. Caused: an old Python rules out the new version but does not pick the old one; boto3's fifty versions fetched almost equally from Python 3.9 read as pip's resolver trying and discarding them, most never installed. Other libraries' limits could account for four libraries' older downloads, pydantic-core's most plausibly, on an unchecked assumption; the rest fits lockfiles without showing them.

Limits. A download is a fetch, not an install or a run; build servers count many times, caches never; the log keeps the day, not the hour; the reported Python is the installer's. Thirty-seven big libraries, five months, then one week; limits from the top 500 only. The installer-search reading is post hoc, untested, and whether pip's metadata reads since 2022 appear in the log is unknown. By release, only 30 per cent crossed half. Two corrections, no figure changed, leave the counts more trusted than the readings.

Stage two: the record against the reader's belief

Read after stage one: studies/LH011/ and studies/LH012/ (records 0.4, briefs, LH012's amendments, sources, data, scripts, review/); studies/LH016/ (record 0.2, brief, amendments, data/, review/ less r0023_* and r0024_*); investigations/software-updates.md; programme.md's Next; issue #19's text as relayed. Calculations, all made after the counts: studies/LH012/review/r0025_walk_dip.py and .txt, offline over the retained week counts and PyPI metadata; two anonymous web reads (PEP 714 and pip's NEWS.rst, 21:43 UTC) kept as studies/LH012/review/r0025_pip_metadata_sources.txt. No download count was read.

What the round establishes

The counts stand. Two evidence reviews recomputed them (review/recompute.txt, r0015_check.txt, review.txt, r0017_check.txt, both v04_checks.txt), and every figure I re-read in project_outcomes.csv, ci_projects.csv, python.csv, week.csv, post_hoc_reading.txt and driver_checks.txt is the figure the pieces give. Each of the three measurements the reader would say back holds as a measurement of fetches.

Where the reader infers a cause, the pieces label it a reading, and the record supports the label. The "software that takes whatever is newest" is a gloss on a share of fetches, said with "seems"; the record's two-ways table (LH008's pinned pairs moving over the month while the four releases' shares crept 3 to 15 points) fits it and tests nothing. The identified-bounds estimate rests on co-fetch, and every surface says so. The frozen-list trace is thinner than the piece's sentence "older downloads carried that flag more often" suggests: true within the 18 that show the trace, but over the 37 it is 20 projects at a median difference of 1.6 points.

The walk reading, post hoc and labelled, with LH013 named as its test, gains one thing from my check (r0025_walk_dip.txt). The record's one exception in boto3's Python 3.9 run, 1.42.87 at 55 per cent of its neighbours, has the same metadata as they do (not yanked, Requires-Python >=3.9, one wheel and one sdist) and dips only on 3.9 (0.99 and 0.91 of its neighbours on 3.10 and 3.11). Nothing on the index explains it; pip's resolver's use of an already-installed distribution as the candidate for its version, without fetching it (as I know pip's source, not re-read here), would: environments that hold 1.42.87 installed would fetch every version they try except that one. That is a further post hoc reading, so I state it as a prediction: the dip stays at exactly 1.42.87 on later weeks until those environments are rebuilt. Under the walk reading, about 885,000 walks a week, about 400 versions deep on average; only 5 per cent of the edge's 17.1 million fetches are walk starts, so about 16 million are fresh installs that stop at the edge: for boto3 the old-Python mechanism is real and small (4.6 per cent of its 3.9 fetches), as the piece says, and for aiobotocore the edge (486,492) barely exceeds the plateau (473,700), so nearly all of its old-Python fetches are walks. No class moves: with the walk-shaped fetches set aside, boto3's at-or-newer share in the week goes from 10.0 to 34.5 per cent and aiobotocore's from 2.8 to 15.2, still under half; the pooled older share goes from 45.6 to 41.7 without boto3 and 38.8 without its family.

So the measurements could be right while an explanation is wrong, and where that matters the pieces already say so. The two places a reader is led further than the evidence are below; neither changes a figure or a class.

Material claim problems

The pace piece's later-evidence box gives the old-Python result for boto3 without the reading that changes its meaning. articles/two-days-for-most.md, the box of 29 September: "downloads from old Pythons were most of the older downloads in three of the 37 libraries, boto3, aiobotocore and numpy, and fewer than half in 32, though an old Python does not say which older version is fetched"; articles/short/two-days-for-most.md, its box: "downloads from Pythons too old for a newer version were most of the older versions' downloads in three of the 37 libraries". Coming after the section that names old Pythons as one of three explanations for "what keeps older versions downloaded", a reader takes this as that explanation holding for boto3: machines on an old Python installing older versions. Evidence: LH012 record, "Read after version 0.2 was released"; review/r0018_walkshare.txt N (walk-shaped fetches 78.9 per cent of boto3's older downloads, 84.2 of aiobotocore's); data/analysis/python.csv edge shares 6.7 and 0.6; r0025_walk_dip.txt 3 (16 million fresh installs at the edge against 356 million below it). The second piece says this; the first's box, on the more-read piece, does not. Resolution: one clause in each box, after "which older version is fetched": "and for boto3 and aiobotocore most of those downloads, on a reading made after the counts and not yet tested, look like versions an installer tried and discarded rather than installed".
The date from which pip stops fetching each version it tries is given a year early, so a reader places the walks on older installers than the evidence needs. articles/old-versions-new-pythons.md, "What an old Python rules out": "since October 2022 it reads instead a small file of the version's requirements where the index offers one"; LH012 record, Findings ("since 22.3 (15 October 2022)") and Next ("resolution walks by pips older than 22.3"); programme.md, Next ("pips older than 22.3"). Evidence: r0025_pip_metadata_sources.txt. PEP 714 (June 2023): PyPI "did not support PEP 658 until just recently", and pips from 22.3 on "hard fail" on the metadata key in the JSON index they request, so PyPI emits it only under a renamed key; pip's NEWS puts the parse fix in 23.2 (15 July 2023). So the pips that fetch every candidate in full from PyPI are those older than 23.2, and PyPI itself served nothing before mid-2023: a wider and more recent set than "before October 2022", which makes the walk reading easier to hold and the "could vanish overnight" scenario rest on installers a reader might still expect to meet. Small, and it changes no figure. Resolution: "since 2023 it can read instead a small file of the version's requirements, which the index began serving that year and pips from 23.2 can read"; the same in the record's Findings and Next and in programme.md, and by dated amendment in LH013's brief if it carries the date.

Readability

Old-versions piece, opening: "on Linux machines that did not say they were build servers" is the phrasing version 1.1 withdrew elsewhere; "in downloads that reported Linux and no build-server flag" says what the log holds.
Old-versions piece, "What stays behind": the pooled 46 per cent is 42 without boto3 (r0025_walk_dip.txt 5); one clause would keep a reader from taking the pooled figure as typical.
Old-versions piece, "What an old Python rules out": name the last boto3 that admits Python 3.9 (1.42.97, of 27 April 2026) once, since the 95 per cent, the fifty versions and the walk all hang on it.

Next step

Continue to issue #19, adjusted, and do not wait. What it can and cannot do: it reads the install steps of CI workflows in the 332 repositories whose pins LH008 to LH010 timed, at fixed snapshots, from anonymous clones, with no download count, so it is available now and bounded like LH015. It cannot distinguish the explanations in play for the download log: whether a project's CI installs from its lockfile says that a road exists from a pin to a build-server fetch, and how often for these projects, not how many of the log's older fetches come down it, nor whether they are frozen lists rather than unread bounds or walks. The programme's "the question the frozen-list reading turns on" overstates that; the brief should say what the study cannot say about downloads. It would improve understanding of the slow road: LH015 left lockfile-alone pairs followed less often (21 of 37) and 41 of its 68 undecided pairs were lockfile pairs, and CI is the population the log's flag marks, so this joins the timed pin moves to the flagged installs, and it bears on LH015's untested reading that the gap lies in where the pin lives (LH016's H-22). Adjustments to the brief before any workflow is read: count per repository as well as per pair; disclose which workflows LH015 already read for build settings; fix how tox, nox, hatch and pip install . are classed, as the issue says.

Beside it, one amendment to LH013's brief before any of its counts is read, labelled as raised here: test that the dip at 1.42.87 persists (walks from environments that hold it installed), a sharper prediction than flatness alone, and fold in the corrected pip date. A pre-registered read of the count-by-version profile on a week ClickPy already holds and no study has read at that grain would test the walk reading two weeks before LH013 can, for a few queries; I would take it if a session has the room, and it does not change the recommendation: the reading is labelled, its test is fixed, and the released figures do not depend on it.

The stage 1 transcript, checked by the driving session

The reviewer's transcript (scripts/tool_calls.py in studies/LH016 lists its calls) shows that in stage 1 it read the three pieces, README.md and about.md, searched twice for headings to find the two sections, checked by name that this note did not yet exist, and wrote the note; it opened no other file. Stage 1 cost $1.29 and stage 2 $3.93 at list rates (harbour/hb tokens --agent).

Resolution, by the driving session

Made on 29 September 2026 after reading the stage 2 section, from 21:49 UTC, when the driving session first read a source for it, to 21:53; every material problem is taken, and the text written here is for the recheck to read.

Problem 1, taken. The box of 29 September in articles/two-days-for-most.md now continues, after "which older version is fetched": "and for boto3 and aiobotocore most of those downloads, on a reading made after the counts and not yet tested, look like versions an installer tried and discarded rather than installed". Its short form's box adds "though for boto3 and aiobotocore most of those look, on a reading made after the counts and not yet tested, like versions an installer tried and discarded", and so does the synthesis's short form's box of 29 September, which carried the same sentence; the synthesis's own notice already gave the reading.
Problem 2, taken after the driving session read the sources itself: PEP 714 (21:49 UTC), pip's NEWS.rst (21:49) and the pip 23.1.2 and 23.2 wheels from the Index (21:50), kept as studies/LH012/review/v04_pip_metadata_read.txt. pip 23.2's pip/_internal/models/link.py reads core-metadata first; 23.1.2's reads only dist-info-metadata, and its collector asks an index for JSON first. So the review's reading holds. The piece says that pips released before July 2023 do not read the files as the Index offers them, and so fetch every version they try in full; it does not claim what every later pip does. Changed: the piece's sentence, its Sources line, Correction notice, revised line and Corrections; LH012.md's walk paragraph, Next and Corrections 0.4; programme.md's Next; LH013's brief, by amendment 2, with a comment on issue #15.
Readability. The first suggestion is taken: boto3's Python 3.9 downloads "reported Linux and no build-server flag", noted in the piece's Corrections. The other two are not: the piece gives the typical library's share beside the pooled one, and the fifty versions are described by their counts.
Next step, followed. programme.md's Next names issue #19 as the next outward step and no longer says CI is the question "the frozen-list reading turns on"; it names the review's three adjustments for the brief, which a comment on issue #19 also carries. The dip at 1.42.87 is described, with its reading labelled as the review's and untested, in LH013's amendment 2. The pre-registered profile read on an already-held week is not taken: LH013 tests the walk from 13 October, and this round is bounded.

Recheck, by a fresh agent

Made on 29 September 2026, around 22:00 UTC, by a fresh agent on Fable 5.1 (claude-fable-5-1, as its harness reports), for step 4 of AGENTS.md: one reading of git diff c8d79eb f1c05e4, less the two notes' review sections and the reviewers' own files, with --word-diff for the prose, against studies/LH011/review/v04_checks.txt, studies/LH012/review/v04_checks.txt, v04_pip_metadata_read.txt, r0025_pip_metadata_sources.txt, r0025_walk_dip.txt and r0018_walkshare.txt, studies/LH016/review/r0024_checks.txt, the verbatim report in studies/LH016/review/relayed-review-astra-2026-09-29.md, the retained tables those name, the lines of the LH013 and LH016 briefs that the amendments quote, the replays' problem lists, PEP 714 re-read anonymously at 22:00 UTC, and issue #17 with its comment through the GitHub tools. Nothing under harbour/.session/, no key, no download count. It is one reading, not a chain: the changes below go to no other reader. Allowance about three dollars at list rates; not priced here.

What held. Every figure in the changed passages is the retained tables': litellm's six on 1 May 2026 and its older downloads at 7.49 to 7.99 million; 378 of 418 and 339 of 355, 31 of 32 and 3.2 points; litellm's rise from 9.5 to 21.0 the largest of the eleven (protobuf's 7.8 next; r0024_checks.txt §4); boto3's and aiobotocore's walk-shaped shares of 78.9 and 84.2 per cent behind "most of those downloads" in the three boxes, at the record's certainty and labelled. The pip dates: PEP 714 created 6 June and accepted 27 June 2023, pip 23.2 of 15 July 2023 reading core-metadata where 23.1.2 reads dist-info-metadata from the JSON it asks for first, so "pips released before July 2023" and "older than 23.2" say the same thing on the piece, the record, programme.md and LH013's amendment 2, whose quotation of the brief matches line 74 and whose 0.55, 0.99 and 0.91 match r0025_walk_dip.txt §2. LH016's amendment 5 quotes step K and M3 as the brief has them; Lesson 5 now matches Finding 7 (18 direct, 17 in the rounds opened); every sentence about Astra matches the verbatim report, including the quotation in Lesson 8, and the "reviewed:" line matches its second paragraph. The colophon's two agents are replay X2 (problem 3, the pace piece at a36508d) and X3 (problem 2, the reading of what stays behind at 89d4aa7, its version 1.0). Issue #17 is the fresh draw of releases from September 2026 whose thirty days are held from about 1 November, and its comment of 21:29 UTC carries the measure.

Changed, five edits and two kept calculations:

articles/two-days-for-most.md, "The first day set most of the month's share". Before: "In every library but litellm, whatever share a new version held on the day after its release was most of what it held a month later:". After: "In every library but litellm, whatever share the typical new version held on the day after its release was most of what it held a month later:". Why: written for R-0024's optional (ii), the clause is exact by the chart's median lines (36 of 37; litellm at 0.45, r0024_checks.txt §4) but not by version: of the 45 releases whose day-1 share was under half of their day-30 share, 27 are litellm's, 17 boto3's (of 101) and 1 aiobotocore's (of 6). Kept as studies/LH011/review/r0025_recheck_day1_half.py and .txt. "The typical new version" is the unit the clause after the colon already uses.
about.md, "How the work is checked". Before: "much of what was passed on in September 2026 was Astra's". After: "much of what was passed on after the releases of 28 and 29 September 2026 was Astra's". Why: the report's "much of that feedback" is what LH016 treated as the keeper's reading, step K, the readings after LH011's and LH012's pieces were released on 28 and 29 September; the first reading of 26 September is recorded as an observing agent's (LH016, Finding 13), and the report does not speak of it.
programme.md, Next, "Until LH013 can run". Before: "(the date, 22.3 until 29 September 2026, corrected after notes/R-0025.md)". After: "(22.3 until the correction of 29 September 2026, late evening, after notes/R-0025.md)". Why: 22.3 is a pip version, not a date, and the text it replaced was written the same day as the correction.
studies/LH012/sources.md, L06, "what was read". Before: "that PyPI supported PEP 658 only from mid-2023". After: "that PyPI supported PEP 658 only from shortly before June 2023 ("until just recently")". Why: the PEP, created 6 June 2023, says "PyPI did not support PEP 658 until just recently" and names no month, as both retained reads quote it and as re-read at 22:00 UTC; "mid-2023" was the reader review's gloss.
studies/LH012/LH012.md, Next, the new item on the rise. Before: "a description of data already read, not a test)". After: "a description of data already read, not a test; review/r0025_recheck_lh014_rise.py and .txt, kept by the recheck)". Why: the 4.4 and 6.1 points had no kept calculation, which the Evidence paragraph asks for. Recomputed from studies/LH014/data/analysis/release_outcomes.csv and project_outcomes.csv: medians of project medians 4.422 and 6.147 points over 50 and 35 projects, 43 and 28 of them above zero, with 239 of 290 and 173 of 195 releases higher on day 30 than on day 2. Both figures stand.

Left unchanged, for the driving session to weigh:

The same paragraph of the pace piece: after the new "as we saw only after this piece first appeared", its last sentence still begins "We noticed this only when we drew the chart" and ends "our next reading will measure it on releases we have not read". "This" is the first-day pattern and the next reading has since been made, as the box above says; a reader may take "this" for the creep. Text from before c8d79eb.
LH012.md's new Next item adds "That the slow part is pinned software moving over weeks would fit, and is untested", a reading whose test the item does not name; the comment on issue #17 says downloads alone cannot settle it, which the Evidence paragraph would have the record say too.
The synthesis's notice of 29 September gives the walk reading for boto3 alone and without "not yet tested", where the three boxes now say boto3 and aiobotocore, not yet tested. It says less, not otherwise, and both reviews read it.
LH016.md's "reviewed:" line names R-0024 for version 0.2 and neither R-0025's stage 2 read of the record nor this recheck; the release step may add them as it did for R-0023.
LH012.md's walk paragraph and LH013's amendment 2 say pip 23.1.2 "reads only dist-info-metadata": true of the JSON index it asks for first and PyPI serves; from HTML it reads data-dist-info-metadata (v04_pip_metadata_read.txt, line 301), and an index serving HTML with the old attribute is among what that read says was not checked.

After the recheck, by the driving session

The recheck's five edits stand. Of what it left for the driving session, all five points are taken, as small changes that add no claim; by AGENTS.md step 4 the recheck is one reading, so these are listed here and not sent to another reader.

articles/two-days-for-most.md: the sentence "We noticed this only when we drew the chart ... our next reading will measure it on releases we have not read" now comes straight after the 34 of 37 libraries it describes, and the paragraph then says "The share did not stand still in that month, though, as we saw only after this piece first appeared", so "this" no longer reads as the rise.
studies/LH012/LH012.md, Next: the reading that the slow part is pinned software moving over weeks now says that the download log cannot test it, since it does not say which fetches come from pins, and that no study now planned could.
articles/where-software-updates-go.md, the notice of 29 September: "for boto3 and aiobotocore most of them look, on a reading made after the counts and not yet tested", as the three boxes say.
studies/LH016/LH016.md: the "reviewed:" line and the Corrections entry name this note beside notes/R-0024.md.
studies/LH012/LH012.md's walk paragraph and LH013's amendment 2: pip 23.1.2 "reads only dist-info-metadata from a JSON index, which it asks for first"; the record adds that from an HTML index it reads data-dist-info-metadata, which was not checked.

The review cost $8.55 at list rates ($1.29, $3.93 and the recheck $3.33), over the allowance of seven dollars by the recheck, which read two resolutions rather than one.