What happened
lecture-python.zh-cn's mccall_persist_trans.md is behind source — its H1 still reads 工作搜寻 V, while myst#760 (merged 2026-08-06) renumbered the lecture Job Search V → VI. That change's delivery PR was lost to the #280 auto-close race (it was part of zh-cn#242's file set).
But the target's state file says otherwise:
source-sha: 96ede29937a77fb0cb26b731e1eecce5e62f6726 # 2026-08-12, INCLUDES #760
synced-at: "2026-08-18"
mode: UPDATE
tool-version: 0.26.0
The 2026-08-18 UPDATE run correctly delivered the later myst#965 change (jax.random.key is present in the target) and wrote source-sha: 96ede29 — which is an ancestor-of-main commit after #760. The renumbering it jumped over was silently skipped, and the state now claims it synced.
Why this class matters
A sync that fires after a lost delivery launders the gap into the state file. From that moment:
This is a sibling of #276's stale-snapshot class, but on the state-recording side rather than the content-generation side: the diff window the section-diff run used did not cover old state-sha → new state-sha, yet the state was advanced across the whole interval.
Suggested direction
When a sync writes a new source-sha, the applied diff should be (or be verified against) previous source-sha → new source-sha for that file — not just the triggering PR's diff. If the run's diff window starts after the recorded state, either widen it or refuse to advance the state past the unapplied interval.
Evidence and the full seven-lecture drift table: project-translation#50 (REPORT.md, "Drift" section). Note the same audit also found the mirror case (likelihood_bayes: content current, state stale), so state repair tooling should handle both directions.
What happened
lecture-python.zh-cn'smccall_persist_trans.mdis behind source — its H1 still reads 工作搜寻 V, while myst#760 (merged 2026-08-06) renumbered the lecture Job Search V → VI. That change's delivery PR was lost to the #280 auto-close race (it was part of zh-cn#242's file set).But the target's state file says otherwise:
The 2026-08-18 UPDATE run correctly delivered the later myst#965 change (
jax.random.keyis present in the target) and wrotesource-sha: 96ede29— which is an ancestor-of-main commit after #760. The renumbering it jumped over was silently skipped, and the state now claims it synced.Why this class matters
A sync that fires after a lost delivery launders the gap into the state file. From that moment:
translate statusreads the file as aligned (it is not);This is a sibling of #276's stale-snapshot class, but on the state-recording side rather than the content-generation side: the diff window the section-diff run used did not cover
old state-sha → new state-sha, yet the state was advanced across the whole interval.Suggested direction
When a sync writes a new
source-sha, the applied diff should be (or be verified against)previous source-sha → new source-shafor that file — not just the triggering PR's diff. If the run's diff window starts after the recorded state, either widen it or refuse to advance the state past the unapplied interval.Evidence and the full seven-lecture drift table: project-translation#50 (REPORT.md, "Drift" section). Note the same audit also found the mirror case (
likelihood_bayes: content current, state stale), so state repair tooling should handle both directions.