PLAN: rule 6's enumeration omitted the canary and carried drifted zh-cn lines

[mmcky]

Rule 6 is the section a repointer consults for "the enumerated reads, the acceptance check, and why CI does not cover it" — PLAN.md's P3 checklist points there explicitly. Its tables were the last place in this document still saying 21 reads across three repos.

#64 corrected the P3 checklist line to 28 across four repos but not this section, so the corrected total and the stale enumeration have been sitting in the same file since 2026-08-10. Anyone doing PR set C by following the pointer got a missing consumer and four wrong line numbers.

What changed

The counts. 21/three → 28/four throughout, with test-actions-lecture-intro's seven reads enumerated for the first time: heavy_tails.md:822, 849, 850, 874 and _static/lecture_specific/inequality/data.ipynb:37 on the media host, mle.md:93 and inequality.md:249 on the github.com/*/raw/ redirect form. The by-repo table gains a "seen by" column, which is where the interesting fact lives — two of the four consumers are seen by nothing.

The zh-cn line numbers. heavy_tails.md 810/837/838/862 → 811/838/839/863, the +1 drift from the six sync PRs that merged on 2026-08-10. mle.md:105 and inequality.md:256 are unchanged. Re-derived against main this morning with bin/zh-fold-lines, and the whole table is now date-stamped and carries a re-derive instruction rather than being presented as fact — that drift happened in a single afternoon, from a sync PR that never touched a data-read line.

The acceptance check. It gains the canary path. The old command was shaped around repos/, and the canary is cloned under repos-infrastructure/ in the workspace, so no amount of care with the old command would have found it. A second grep is added for high_dim_data itself, because the media-host grep passes trivially on a tree that was never repointed at all — it only proves the absence of one wrong spelling, not the presence of the right one.

The coverage paragraph. Recounted from "9 of 21": the strict audit sees 12 of 28 (the .md reads in intro and wasm), the two data-url-guard workflows recover 2 more by grepping all of lectures/ including _static notebooks, and 14 reads across lecture-intro.zh-cn and test-actions-lecture-intro have no automated check of any kind.

Why the superseded figures are kept

Both are now recorded in the section as superseded, with a line saying the table is what was measured. Each has been mistaken for the total once already — "12 media reads" is the intro + wasm subset, and "21 reads / three repos" omits the canary. Deleting them silently is how the same mistake gets made a third time.

No behaviour change; docs only. Plan: QuantEcon/workspace-lectures#23

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates PLAN.md’s “repoint rule 6” documentation so the enumerated high_dim_data consumer reads, line-number snapshots, and fold acceptance checks reflect the current 28-read / 4-repo reality (including the test-actions-lecture-intro canary) and recent lecture-intro.zh-cn drift.

Changes:

• Corrects and expands the consumer-read counts/tables (21→28; 3 repos→4 repos) and adds a “seen by” coverage column.
• Updates zh-cn line-number snapshots and adds a date stamp + re-derive guidance.
• Extends the fold acceptance check to include the canary path and adds a second “legacy reference” grep.

Suppressed comments (1)

PLAN.md:196

• The acceptance check grep -rn 'high_dim_data' ... is very broad and can fail on unrelated mentions (e.g., prose, comments) even after URLs have been repointed. To make the check reliably indicate “no remaining legacy URLs,” grep for the repo-qualified substring instead (e.g., QuantEcon/high_dim_data).

A second grep is what actually proves the fold, since the one above passes trivially on a tree that was never repointed at all:

    grep -rn 'high_dim_data' <the same four lecture trees>

That must also return nothing.

---

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