Decide how each of the eight open #127 boxes closes

[quantecon-services]

Decision point for #132. Eight boxes on #127 are open after the 2026-09-07 validation. Each needs one disposition recorded here — reword and tick, leave as refuted, run the check, or waive it — before the items below this one in #132's list proceed or are dropped.

Four boxes whose expectation is wrong as written (the facts held)

Box	The box expects	What was measured	Options
§1.5 status-projects pages	"2 completed projects" under infrastructure	Three: upstream-delta-register was set done by status-projects #53 at 00:41 UTC, before #64. Everything else in the box holds (automation done, ended 2026-09-07, 4 of 4, no findings; scaffolding carries three).	reword to "3" and tick, or leave unticked as refuted
§2.2 pure rename	git log --follow reaches the 2026-07-16 flatten (#10)	Impossible here: this repository's history has a single root, 931d626 (#57, 2026-08-10), 50 commits. The blob-hash half holds (29250cae… identical at e318f06, c4a286c, 818811b).	drop the --follow clause and tick, or leave as refuted
§3.3 CI gate	consumed-file-check stays green under mutation (a)	It goes red: check_consumed_files.py hashes every file with a recorded sha256 regardless of consumers (#130, run 34085829084). The gate itself is proven — validate-datasets red on both heads, consumed-files green for the manifest-only mutation (i).	reword the parenthetical to "for a manifest-only mutation" and tick, or leave as refuted
§5.4 latest.json	datasets-migration still active with tree-postdates-start	Still active, but compliance.findings: [] and tree.coverage: spans-start; no snapshot from 09-01 to 09-07 carries the flag (the tree fields first appear on 09-07). The automation half holds.	drop the tree-postdates-start clause and tick, or leave as refuted

Four boxes that need a network the validating session did not have (run or waive)

Box	Partial evidence in hand	Runs as
§1.2 with §6.4, the org-wide sweep	34 repositories and all 15 lecture-wasm branch tips clean; roughly 240 org repositories unswept	the first Verify item in #132
§6.2, the published-site re-probe	no publish* tag after 2026-09-01 on any of the eight hosts (by creatordate); the hosts themselves were unreachable	the second Verify item
§7.2, the FRED lag date	the 06:50 UTC canary on the 7th accepted August's blanks; the lag closes after the mid-month releases	the third Verify item

Recommendation: run the org-wide sweep — a hit there is a reader-facing regression, and it is the one check the original session skipped outright. The other two can be waived if the partial evidence is enough.

Recording the decision

Reply here with one line per box. Then: edit #127's body for any reword-and-tick; for any waived check, close its Verify item as not planned and remove it from #132's sub-issue list (QEP-6 §3: dropped work leaves the plan). Close this issue as completed once all eight have a line.

[mmcky]

Disposition of the eight open boxes, 2026-09-07

This session has the network and gh the validating session lacked, so all four "needs a network" boxes were run rather than waived, and the four "wrong as written" boxes were re-measured rather than taken on the validating session's word. That second choice mattered: one of the four was not wrong at all, and a second was wrong in a way neither the box nor the validation had right.

One line per box, as this issue asks.

Box	Disposition	Why
§1.2 + §6.4 org-wide sweep	ran — tick both	286 repos enumerated, 283 swept, 0 hits outside this repository
§2.2 pure rename	tick as written — no reword	the refutation was a shallow-clone artefact; both halves hold on a full clone
§3.3 CI gate	reword the parenthetical, tick	the gate is proven; "consumed-file-check stays green" is true only for a manifest-only mutation
§5.4 latest.json	reword, tick	datasets-migration is active with findings: []; the flag existed, but for 21 minutes
§1.5 status-projects	reword "2" to "3", tick	the live page reads "▸ 3 completed projects"
§6.2 site re-probe	ran — tick	a census of all 60 rows, 0 cleared, with the mechanism measured rather than inferred
§7.2 FRED lag	needs your call — see below	the lag has not closed; there is no date to record today

§2.2 — the box holds as written; the refutation does not

The verification comment refuted this box on the grounds that "this repository's history has a single root, 931d626 (#57, 2026-08-10), 50 commits in total", so no commit for the 2026-07-16 flatten exists. Every clause of that is false, and the cause is now reproduced exactly.

931d626 is an ordinary commit with parent c044b8c (confirmed against the API, where a true root has parents: []), and 54 commits precede it. The sole root is 77ece40 "Initial commit", 2025-02-09T22:49:14Z. main carries 104 commits at 47017ea. The Feb 2025 migration is in git as c0adb7a (2026-02-13), and the flatten is in git as 52dbb89, the merge commit of #10, mergedAt 2026-07-16T22:45:04Z. The box's own command, run verbatim, returns five commits and reaches 52dbb89 — and then one further, to b857c5c (2025-02-16). The blob half holds too: e318f06:lectures/business_cycle_data.csv and c4a286c:lectures/gdp_growth_annual.csv are the same blob 29250cae27e1422a69d0e42aabc7502ba08a14e5, and the rename diff is exactly one R100 line.

Root cause. git rev-list --count 931d626..818811b is 49, so 931d626 is precisely the 50th commit back from 818811b — the head #127 was written against. Mirroring the repo and running git clone --depth=50 at that head reproduces the finding bit for bit: 50 commits, git rev-list --max-parents=0 returning 931d626 alone, and --follow stopping there without reaching 52dbb89. On a shallow clone the boundary commit's parents are hidden, so it is indistinguishable from a root. The validating session read its own clone depth as the repository's history.

This has three consequences beyond the box. #138's first "repository fact" is false and must not be merged as written — it would put a falsehood into AGENTS.md that the next validator would trust. #139's first checklist lesson is backwards for the same reason. And the real lesson is the more useful one: verify git rev-parse --is-shallow-repository before concluding history is missing.

§5.4 — the box is wrong, and so was the refutation

Live collection generated_at 2026-09-07T06:58:20Z (the Pages copy and the repo copy are byte-identical). The automation half is exact in all five fields. datasets-migration is still active, but with compliance.findings: [] and observed.tree.coverage: spans-start — so the box's "still ... with tree-postdates-start" fails.

But the verification comment's stronger claim — that no 2026-09 snapshot carries the flag — is also wrong. Replaying the 47 collections in data/history/: tree-postdates-start was introduced by status-projects collector commit 57db2e3 at 03:40 UTC on 2026-09-07, datasets-migration carried it for exactly three collections (03:40:50Z, 03:54:57Z, 04:01:50Z), and it cleared at 04:19:44Z when the collector began seeing 9 private sub-issues on QuantEcon/workspace-lectures#14 instead of 4. The validating session read the 04:19Z collection — eighteen minutes after it cleared — and concluded it had never existed.

The flag is real and still live on three other projects (ci-migration, lecture-monorepo, workplan-skills).

§1.5 — refuted on the count, confirmed on everything else

Read from the live rendered DOM, not the served HTML (these pages render from JSON client-side). The infrastructure programme's collapsed row literally reads "▸ 3 completed projects", because upstream-delta-register was set done/ended 2026-09-07 by status-projects#53 at 00:41:34Z, 3h13m before #64 did the same for this project. Every other clause holds: data-lectures automation shows as "done September 2026"; the Pipeline done tab lists it first, above data-lectures scaffolding (fourth); its project page reads "ended 2026-09-07" with an empty conformance panel, while scaffolding carries three findings.

Two wording notes, not worth a box: the visible work-items label is "all 4 closed" ("4 of 4 work items … closed" is its tooltip), and the done-tab tie order among the three 2026-09-07 projects rests on Array.prototype.sort stability over the registry row order, not on a documented rule.

§3.3 — the gate is proven; one clause is false

All four run conclusions match the verification comment: at 5e23ade (manifest-only mutation) validate failed and consumed-files succeeded; at 93d0173 (an extra column appended to the data file) both failed. The checks-tab annotation path is confirmed through the check-runs API — gh run view --log renders ::error file=X::msg as ##[error]msg and drops the path, so the log alone cannot show it. #130 is closed, not merged, and its branch carries neither mutation.

So the box's "while consumed-file-check stays green (the bytes still hash)" is false for mutation (a) and true for a manifest-only mutation such as (i).

§1.2 and §6.4 — the sweep ran, and is clean

gh repo list QuantEcon --limit 500 enumerated 286 repositories, which reconciles with the org itself (215 public + 71 private), so private and archived repositories are in scope and were swept. 283 were swept twice — a recursive Trees-API pass over every default branch (34,179 entries, truncated: false on all 283, so no depth-1 fallback was needed) and a depth-1 clone with git grep for content, which is what covers the 26 archived repositories and 3 forks that GitHub code search does not index. The three not swept are empty — size: 0, zero branches, and Trees returns HTTP 409 Git Repository is empty (test-cli, numfocus, quantecon-book-dp).

Zero path hits for business_cycle_data anywhere in the org. Fourteen content hits, every one inside this repository and every one the deliberate dated history the box exempts: PLAN.md lines 27, 34, 301, 308, 309, 324, 343; AGENTS.md:58; builders/business_cycle.py:20; manifest-schema.yml lines 49 and 228; migration.yml:839; scripts/audit_annotations.yml:48; and the gdp_growth_annual.csv.yml header. gh search code independently returned nine lines, all from this repository.

An adversarial re-run then attacked the coverage and closed three gaps beyond what the box asked for. It re-derived the enumeration, and spot-checked five random repositories — including a private one and an archived one — by re-running the Trees call and matching both the full path set and the root tree SHA, confirming they were genuinely inspected. Then: every branch of the eight audit repositories and this one (268 branches, 43,118 entries) plus a full-history all-refs content grep of those eight (883 refs, including lecture-wasm's 16 and its gh-pages) — the only path hits are 12, every one inside this repository on stale pre-rename branches; gh-pages org-wide (39 repositories, 18,079 files), which no pass had covered and which is where the published site actually lives; and the org's only two submodules, both in lecture-mapping, which neither the Trees API nor a non-recursive clone expands. All zero.

Three residuals are named rather than closed: the non-default branches of roughly 245 low-risk repositories, fork PR heads outside the audit repositories, and any out-of-org or non-GitHub reader (a CDN, a published bundle, a student's local clone) — unmeasurable in principle, so a bound rather than a proof.

The blind spot the rename was made under is now closed on evidence rather than on consumers: [].

§6.2 — the re-probe ran, and found more than the first pass

Full detail is on QuantEcon/workspace-lectures#40, which owns the rows. In short: a census of all 60 rows, on two clients that are not curl, with controls discriminating on all eight hosts: 0 cleared, and every served body byte-identical by sha256 to the pre-deletion git blob — so nothing cleared, and nothing changed either. The 60 is now derived from the bytes rather than asserted: the eight Track X commits removed 64 files, 60 of them under _static/lecture_specific/.

The attribution is now measured rather than inferred. Cache-buster GETs on a fresh CDN cache key returned identical bytes, and for the three gh-pages hosts the deleted file is still physically in the deployed tree — so this is stale deployment output, not an edge cache. Seven of the eight hosts simply have not published since the deletions. The eighth, .ml, has deployed three times and still serves everything — and the first of those was triggered by the Track X deletion commit itself, which is positive proof of the structural keep_files: true exemption rather than an inference from the workflow file.

Two things changed since the 00:30 UTC pass. The rebuild half of the gate is now met on all seven cache-bearing hosts — the scheduled 03:00 UTC cache.yml runs completed green this morning — so only the tag is outstanding anywhere. And the deploy mechanism is now verified rather than assumed for all eight: quantecon/actions/publish-gh-pages turns out to be upload-pages-artifact + deploy-pages, a full replace, so every non-.ml host will prune on its next publish.

§7.2 — the one box that needs your decision

The August lag has not closed. Measured today: UMCSENT, CPILFESL and INDPRO all still end at 2026-07-01; UNRATE and USREC have August. That is identical to the state the box records, and today's canary (run 34092578823) independently reports the same frame end. So the box's substantive claim — and the recent: 1 rule that rests on it — is confirmed today, not merely restated.

What cannot be done is the box's instruction to "record the date the lag closed". There is no such date yet. FRED's release calendar puts the next releases at CPILFESL 2026-09-11, INDPRO 2026-09-18, UMCSENT 2026-09-25 — so the earliest the lag can fully close is 2026-09-25, eighteen days out. (One caveat found in the margin: UMCSENT's 2026-08-28 release delivered no new observation at all — the ALFRED vintages for 08-27 and 08-31 are identical — so its date is the least reliable of the three.)

Three ways to close this box, in my order of preference:

1. Reword and tick. Record what was measured today plus the expected window, and carry "the date the lag closed" as a named accepted residual in the closing comment. Record the date the FRED August publication lag closed #136 closes as completed. Nothing waits.
2. Waive. Close Record the date the FRED August publication lag closed #136 as not planned and drop it from Close out the 2026-09-07 validation (#127) #132's list, per QEP-6 §3.
3. Hold. Leave VALIDATION: independent review of the 2026-09-07 schema-decisions, rename and manifest-driven validator work #127 open until on or after 2026-09-26 and record the real date. Costs eighteen days of an open validation issue for one date that changes no decision.

I recommend (1): the box's own words are "either way the rule stands", so the date is a record, not a gate — and holding a validation issue open for it inverts the cost.

---

Generated by Claude Code

[mmcky]

All eight boxes have a disposition in the comment above, and the two that needed an owner's call are settled: §7.2 is reworded and ticked with the lag date carried as an accepted residual, and nothing is waived — so #132's sub-issue list stays intact and no QEP-6 §3 removal is needed.

#127's body is updated: 35 of 35 boxes ticked, none open.