Reviewer invents a heading-map slug spec that contradicts the engine, and emits it under a 10/10 pass

[mmcky]

The review of QuantEcon/lecture-python-programming.zh-cn#79 reported a heading-map format defect that does not exist — and reported it inside a section scored 10/10 with Heading-map Correct ✅.

What it claimed

Under ### 🔍 Diff Quality, alongside Overall 10/10 and all four checks passing:

Heading map uses plain heading text keys (e.g., 'Overview', 'DataFrames::Selecting data') instead of the expected slugified English IDs (e.g., 'overview', 'dataframes::selecting-data'), which is inconsistent with the documented ID-generation scheme.

Why it is wrong

src/heading-map.ts documents the key format as literal heading text joined by :: — its own worked example is "Vector Spaces::Basic Properties::Applications in Economics", with PATH_SEPARATOR = '::'. The file under review used exactly that format.

Measured across the three programming editions (.fr, .fa, .zh-cn): 72 files carry heading maps totalling 1,052 keys, of which 0 are slug-form. There is no slugified-ID scheme anywhere in the engine or in the corpus. The reviewer invented a spec and graded against it.

Two distinct problems

1. The false positive itself. A reviewer asserting a format spec that contradicts the engine's own implementation will send editors to "fix" correct files into broken ones — the heading map is load-bearing for resync and rebase, so a well-meaning correction here is more damaging than the imagined defect.

2. The verdict block contradicts its own prose. The finding sits under Overall 10/10 with Heading-map Correct ✅. A human skimming scores sees a clean pass; a human reading prose sees a structural defect. Whichever the rubric intends, both should not be emitted together — either the finding should have moved the score, or it should not have been emitted at all.

The same review's other two notes were sound (the Series/DataFrames self-mapping observation, and the note that exercise labels pl_ex1/pl_ex2 are not heading-map entries), so this is a targeted defect rather than a poor review overall. The French and Farsi reviews of the same source change produced no equivalent claim.

Context

Same class as #102 (reviewer omitted a criterion, engine computed Overall NaN/10 and auto-FAILed), #223 (findings carry the wrong file and location) and #224 (the engine's own i18n localisation graded as unauthorised code modification): the reviewer's structured output is not constrained to what the engine actually does. A cheap mitigation for this instance specifically would be to feed the reviewer the heading-map format contract, or to compute the heading-map check rather than leaving it to model judgement — the diffCheckSources field added in v0.23.0 already distinguishes computed checks from judged ones, and Heading-map Correct being judged rather than computed is what allowed this.

Verdict block from the run: engineVersion 0.24.0, reviewerModel claude-sonnet-5, reviewedHeadSha 20daeddb2e0a32c23753bca27708801555d7cc1d, verdict PASS, recommendation editor.