chore: publish the corrected plan banners and close the upgrade epic - #47
Merged
Merged
Conversation
…(01KZD823EG6R5E1FXFX416RQ0G) Publishes across two wiki commits and closes the epic. The plan pages now read "completed plan" and "plan in flight" instead of all three claiming to be the latest status report, which was the point of the upgrade. The frozen guard fired on twelve documents before the first publish, because provenance-backfill stamped merged_in into their front matter. That is a false positive from hashing the whole file: publishing strips front matter for Gollum, so two files differing only there produce byte-identical pages. The publish script now hashes below the front matter, which is what the guard always meant -- the same fix worklog made upstream in 0.21.0. Each of the twelve was verified individually before being named in --allow-frozen: the body at the commit before provenance-backfill is byte-identical to the body now, checked with git rather than assumed. The guard also caught a twelfth document I had missed when a truncated listing showed only eleven, which is the guard doing exactly its job. No migration was needed for the hash-basis change: the ledger self-heals, since each publish rewrites source_hash on the new basis. Verified after the run -- the guard is silent with no override at all, 0 to publish, 96 current. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WMk8bhkMEUWfHi7VYzMzFX
17 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the epic
01KZD823EG6R5E1FXFX416RQ0G. Follow-up to #46.The payoff, live
Plan pages on the wiki now read:
and, for this upgrade's own plan:
instead of all of them claiming to be the latest status report. Verified by
reading the published pages in the wiki checkout, not by trusting the ledger.
Also checked all 96 published pages for leftover front matter: zero.
The frozen guard fired, and it was right to
Before the first publish, the guard refused on twelve frozen documents.
provenance-backfillhad stampedmerged_ininto their front matter, movingthe whole-file hash.
That is a false positive in my publish script, and the same defect worklog
fixed upstream in 0.21.0: publishing strips front matter for Gollum, so two
files differing only there produce byte-identical pages, yet a whole-file hash
moves on every metadata stamp. The script now hashes below the front
matter, which is what the guard always meant — the prose changed.
Each of the twelve was verified individually before being named in
--allow-frozen: the body at the commit beforeprovenance-backfillisbyte-identical to the body now, checked with
git show, not assumed.The guard caught one I missed. I built the allow-list from a truncated
listing that showed eleven; the twelfth was still refused. I verified that one
separately (body identical, sole change
+merged_in:) before adding it. Ablanket bypass would have published it unexamined — this is the argument for
an override that makes you name what you are overriding.
No migration was needed
I started building a
--rehashmigration for the basis change and backed itout: the ledger self-heals, because every publish rewrites
source_hashon thenew basis. Confirmed after the run — the guard is silent with no override at
all,
0 to publish, 96 already current.State
Both loops converged, gate exits 0. The doc-verify warning it prints is the
frozen-document fabrication situation reported upstream as
wiki_ticket_sdd#345, warn-level by design.🤖 Generated with Claude Code
https://claude.ai/code/session_01WMk8bhkMEUWfHi7VYzMzFX