Record two repository facts the 2026-09-07 validation got wrong

[mmcky]

Two boxes of the #127 checklist failed on facts about this repository that nothing wrote down. Recording them where a checklist author looks stops the next validation issue asking for the impossible.

One of the two facts as #138 stated it is false, and re-measuring before writing is the reason this PR is worth reading rather than rubber-stamping.

Fact 1, corrected

#138 asked to record: "The git history begins at #57. This repository has a single root commit, 931d626, and 50 commits in total ... a check phrased as git log --follow reaches #10 cannot be satisfied."

Every clause of that is false.

Claim	Measured on main at 47017ea
single root 931d626	931d626 is an ordinary commit with parent c044b8c; 54 commits precede it. The API confirms it — a true root has parents: []
50 commits	104
Feb 2025 migration only in prose	in git as c0adb7a, 2025-02-13
the 2026-07-16 flatten only in prose	in git as 52dbb89, the merge commit of #10, mergedAt 2026-07-16T22:45:04Z
--follow cannot reach #10	it returns 5 commits, reaches 52dbb89, and continues to b857c5c (2025-02-16)

It is a shallow clone reading its own depth as the repository's history. git rev-list --count 931d626..818811b is 49, so 931d626 is precisely the 50th ancestor of 818811b — the head #127 was written against. git clone --depth=50 there reproduces the finding bit for bit: 50 commits, rev-list --max-parents=0 returning 931d626 alone, --follow stopping short of the flatten. A shallow boundary hides its parents, so it is indistinguishable from a root.

What goes into the file is therefore the true statement plus the one-line check that would have caught it. Recording #138's version would have put a falsehood into AGENTS.md that the next validator would trust — and #127 §2.2 is confirmed as written, not "not completable".

Fact 2, as written

check_consumed_files.py hashes every file whose manifest records an integrity.sha256, with or without consumers — the deliberate rekeying in #56, because manifests land ahead of their repoints and keying on consumers made the one PR that introduces new bytes the one PR that never verified them. The consequence for a checklist: consumed-files goes red for any change to a published file's bytes. Measured on #130 — a manifest-only mutation left it green with only validate red; appending a column to gdp_growth_annual.csv turned both red.

Beyond the issue's scope, flagged rather than slipped in

The repo map said "41 datasets, 41 manifests". That has been three short since #114 landed the business_cycle set on 2026-09-01; the tree holds 44 of each, and CATALOG.md already says 44. Same family, one line, fixed here.

Documentation only; no code, no manifest fields, no data bytes.

Closes #138.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

Documentation-only update, and the key operational claim about sha256 hashing is consistent with the current check_consumed_files.py behavior.

Pull request overview

This PR updates AGENTS.md to record two repository facts that were previously misstated in a validation checklist, so future validations don’t rely on incorrect assumptions (notably around shallow clones and the consumed-file hash gate).

Changes:

• Correct the repo-map dataset/manifest count to 44 (and note the business_cycle set addition).
• Document that the repository’s git history is complete (and that “50 commits / root at 931d626” is a shallow-clone artifact).
• Document that check_consumed_files.py enforces sha256 integrity whenever integrity.sha256 is recorded, regardless of consumers.

File summaries

File	Description
AGENTS.md	Updates repo-map counts and records two validation-relevant repository facts (git history completeness; sha256 hashing behavior independent of consumers).

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.