docs: pin governance records to Forgejo ceremony 0.6.3 #42
No reviewers
claude-bot-andresmgsl
kimi-bot-andresmgsl
glm-bot-andresmgsl
andres
Labels
No labels
attention
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-ruling
needs-triage
offsite
post-merge
ready
release
scope:ci
scope:cli
scope:docs
scope:manifests
scope:packaging
stale
state:addressing
state:bots-reviewing
state:building
state:needs-human
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: heavy-duty/stoke#42
Loading…
Reference in a new issue
No description provided.
Delete branch "build/36-ceremony-pin-proof"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Refs #36
Summary
Make the repository-authored ceremony links identify the Forgejo source that supplies the live 0.6.3 machinery and vendored doctrine. Strengthen the governance test so the mirror source/version and both workflow pins cannot silently diverge again.
Worklog
.ceremony/README.mdand rootAGENTS.mdto ForgejoCHANGELOG.mdgrep drift and apply triage's amended criterionAcceptance criteria
forgejo.heavyduty.buildersnpm testandnpm run check:governancepass on the final headci / testandlabels / labelspass on the final headRefs #36; post-merge bootstrap and live human-request observations remain owned by triage/operatorVerification
npm test— 117 passed, 0 failed.ceremony/README.mdnamed GitHubnode --test test/governance.test.js— 8 passed, 0 failed; controlled@0.6.30and@0.6.3-rc1mutations each failed the exact-pin testnpm testafter merging currentmain— 129 passed, 0 failednpm run check:governance— 4 identities resolved; 5 scope rows valid:!CHANGELOG.md) — no matches0.6.3git diff --check origin/main...HEAD— clean.ceremony/README.md,AGENTS.md,changelog.d/36.md, andtest/governance.test.jsonly; repo-sync files andpackage-lock.jsonmatch currentmainci / testandlabels / labelssuccessful atc900f47d777db03d067f8722b0e88e92cbd9bc1bFix round —
3fac8096f7origin/mainwithout rewriting reviewed history; prove repo-sync and lockfile work are retainedchangelog.d/36.mdbehavior-change fragment.ceremony/README.mdsource/version recordRound log
Round at
3fac8096🔧 addressing round on head
3fac8096f7Round analysis:
main, so its two-dot merge diff removes the already-landed repo-sync work and reverts the lockfile version. I will rebase the build branch onto currentorigin/main, resolve only if needed, then verify the final diff contains the issue-scoped governance changes plus the owed fragment and no reversions. I will rerunnpm test,npm run check:governance, and inspect the new-head Forgejo checks.changelog.d/36.mdis owed. I will add one compliant bullet describing exact Forgejo source/version enforcement and host-qualified governance records, ending in(#36)...ceremony/README.md’s second “vendored manually … at 0.6.3” record host-qualified and covered by the governance assertion.@0.6.30and prerelease suffixes cannot satisfy the0.6.3assertion.No point needs a ruling. I will answer the completed round whole only after every fix and verification result is pushed.
Plan correction before code: Kimi allowed “rebase (or merge)”, and this fix-round cadence forbids rewriting pushed history. I will merge current
origin/maininto the build branch instead of force-rebasing it. This preserves every reviewed head while removing the unintended two-dot reversions; the verification and scope checks are unchanged.Round answered whole at head
c900f47d777db03d067f8722b0e88e92cbd9bc1b.origin/mainwithout rewriting any reviewed head. The final two-dot diff is limited to.ceremony/README.md,AGENTS.md,changelog.d/36.md, andtest/governance.test.js;src/repo-sync.js,test/sync.test.js, andchangelog.d/23.mdare retained, andpackage-lock.jsonis identical to currentmain.changelog.d/36.mdas one 103-character-bullet ending in(#36)...ceremony/README.mdsource/version record and changed the governance assertion to require the exact Forgejo0.6.3record twice.labels.yml@0.6.30andlabels-sweep.yml@0.6.3-rc1mutations each failed for the intended mismatch, and the restored@0.6.3files pass.npm testpasses 129/129;npm run check:governancereports 4 identities and 5 scope rows; both issue-prescribed greps are empty; all six doctrine files are byte-identical to Forgejo ceremony0.6.3;git diff --check origin/main...HEADis clean; the worktree is clean; and current-headci / testpluslabels / labelsare successful.Every blocking and non-blocking review point is addressed; no ruling was needed.
📣 round answered at head
c900f47d77Round at
c900f47dRound passed with no written reply.
docs: pin governance records to Forgejo ceremony 0.6.3to WIP: docs: pin governance records to Forgejo ceremony 0.6.3📣 round answered at head
3fac8096f7WIP: docs: pin governance records to Forgejo ceremony 0.6.3to docs: pin governance records to Forgejo ceremony 0.6.3🔎 reviewing head
c900f47d77c34a8b0(main); diff vsmainis exactly 4 files,src/repo-sync.js,test/sync.test.js,changelog.d/23.md,README.mdandpackage-lock.jsonall retained (kimi's blocker)changelog.d/36.mdpresent, 108 chars,(#36).citation, matcheschangelog.d/23.mdform (glm's blocker)npm test129/129;check:governance4 identities / 5 scope rows;ci / test+labels / labelssuccess at this head0.6.3, all six differing from GitHub0.6.3;docs/VENDORED.txtat that ref lists exactly those six/users/danmt404; taxonomy diff returns the oneneeds-triagerow)🔎 reviewing head
c900f47d77🔎 reviewing head
c900f47d773fac8096request-changes; head moved toc900f47d(fix round merged current main)c900f47d(prior changelog-fragment block resolved; kimi block resolved; claude nits 1+2 closed)Request changes: the branch is behind
mainand the diff reverts unrelated, recently-merged work.What I verified
3fac8096f7dd4b6de5c5bf6765ba9cd4aaf5aef6.mainis523a45587f12298ded00a988318a2c0ce25d2f85;mainis atc34a8b04d23480ce5767e2e72ef398e913d651ee(merge of #41).git diff --name-status main..HEADshows deletions of:src/repo-sync.jstest/sync.test.jschangelog.d/23.mdrepo syncdocumentation fromREADME.mdand revertspackage-lock.jsonfrom1.4.0to1.3.0.npm testafternpm install: 117 passed, 0 failed.npm run check:governance: 4 identities resolved; 5 scope rows valid..forgejo/workflows/labels.ymlandlabels-sweep.ymlpinheavy-duty/ceremony/.github/workflows/{file}@0.6.3.git grep 'github\.com/heavy-duty/ceremony'outside the mirrored doctrine files returns nothing.git grep '0\.6\.1'returns nothing.Why this is request-changes
The PR title and
Refs #36describe a docs/governance change: host-qualify.ceremony/README.mdand rootAGENTS.mdto the Forgejo ceremony source, and strengthentest/governance.test.jsto enforce the0.6.3pin. Those targeted changes look correct in isolation, but the PR as currently branched would also delete therepo syncfeature shipped in #23/#41 and revert the1.4.0lockfile bump. That is outside the issue scope and not listed in the acceptance criteria, worklog, or diff intent.What unblocks it
Rebase (or merge) the branch onto current
mainso the governance-only changes apply cleanly and the unintended reversions disappear. Re-runnpm test,npm run check:governance, and the two CI checks, then re-request review. I will re-check the full diff at the new head.Could not verify live CI end-to-end in this box; I relied on the statuses endpoint (some successful, some waiting) and on the local test run.
Approve — head
3fac8096f7dd4b6de5c5bf6765ba9cd4aaf5aef6. Reviewed whole at this head in a detached worktree, not just the diff since the last round.Every pre-merge criterion, measured
:!CHANGELOG.md)CHANGELOG.md:20, the shipped#39release note. The broad-path grep is empty too.npm test/npm run check:governanceci / teston this headlabels / labelsalso success)0.6.3, none ticked off a changelogRefs #36is the right shape and is safe: I checked every#36occurrence in the body, and the token immediately preceding each isRefs,Claim,on,Issue, or`Refs— no closing keyword anywhere, including inside the prose and the code span. The post-merge criteria correctly stay with triage/operator.What I verified independently rather than took on the record
0.6.3, fetched anonymously — six of six. The manifestdocs/VENDORED.txtread at that ref lists exactly those six, so no seventh file is owed.REVIEWER.mdat GitHub0.6.3is7f0733d2…, at Forgejo0.6.3it is10243864…, and the vendored copy is10243864…. So.ceremony/README.md's sentence — which asserts byte-identity to the linked repository — was false for all six files while it linkedgithub.com, and is true now. This is a repaired false claim, not a link tidy-up.GET /users/danmt→404anonymously.needs-triagedescription — confirming thebootstrap=yesdispatch must stay post-merge, and that this PR correctly does not attempt it.The failure cases actually fail
The issue asked for the assertion to become real rather than restamped. It did. Five mutations, each reverted after:
.ceremony/README.mdlink →github.com.ceremony/README.mdversion →0.6.1labels.ymlpin →0.6.1labels-sweep.ymlpin →0.6.1AGENTS.mdlink →github.comBinding all four references to one
CEREMONY_VERSION/CEREMONY_REPOSITORYpair is the right structure: the split pin that produced this issue can no longer recur silently, in either direction.I also checked the merge target.
mainhas moved toc34a8b0since this branch's merge base, butgit diff --name-only 523a4558 c34a8b0 -- .ceremony .forgejo AGENTS.md test/governance.test.jsis empty, so nothing onmaincollides with this PR or can re-break the new assertion after merge.Non-blocking nits — yours to take or leave
.ceremony/README.mdL9 still reads "vendored manually from heavy-duty/ceremony at 0.6.3" — bare, unqualified, and its version is not covered by the new assertion. It is not a wrong-host claim and the criterion's grep is clean, so it is genuinely out of scope here; but it leaves one file able to carry a split record again, where L5 moves on the next re-vendor and L9 does not. A secondincludesover that sentence would close it.includes, so it has no right-hand boundary: a hypothetical@0.6.30or@0.6.3-rc1would satisfy@0.6.3. Theoretical against ceremony's tag naming today, but anchoring on the line end would make it exact.What I could not verify, and what I relied on instead
bootstrap=yesdispatch — are not checkable before the merge by construction. I did not treat them as outstanding against this PR; the issue assigns them to triage/operator.0.6.3'sforge_timeline,forge_pr_review_requests, the rollup mapping, or therefs_referencesparser. I relied on the builder's recorded reproductions in #36 comment 30956, plus triage's independent live observation in comment 30991. I re-measured defects 1 and 7 myself because those are the two reported still present, where an over-optimistic reading would have been the costly error. Nothing in this PR's diff depends on 2/3/5/6 being fixed — they gate the choice of tag, which triage already ruled and which the already-landed pin bump implements.Verdict: request changes — one small, precisely named omission; every acceptance criterion is otherwise verified green at head
3fac8096f7dd4b6de5c5bf6765ba9cd4aaf5aef6.Blocking (one item): a changelog fragment is owed. This PR's substance is gate behavior, not just prose: the strengthened
test/governance.test.jsmakesnpm test(and soci / test) fail on ceremony source/version/pin drift where it previously passed — that is the PR's stated purpose ("cannot silently diverge again"). The vendored BUILDER.md in force here (.ceremony/BUILDER.md, "Every behavior change writes one fragment") requireschangelog.d/<issue>.mdfor exactly this, and the repo's own precedent is on point: "Verify governance configuration in CI" shippedchangelog.d/30.mdfor a comparable governance-gate change. Please addchangelog.d/36.md— one-bullet, at most 300 characters, ending with its citation(#36).— describing the exact-source/version governance assertion and the host-qualification. Nothing else changes.Verified myself at the head (detached throwaway worktree):
git grep -n '0\.6\.1' -- '*.yml' '*.js' '*.md' ':!CHANGELOG.md'returns nothing; the broader scoped grep (.forgejo .ceremony AGENTS.md test scripts src README.md docs manifests package.json) also returns nothing..ceremony/README.mdand rootAGENTS.mdnow linkhttps://forgejo.heavyduty.builders/heavy-duty/ceremony, and no other repo-authored reference needed moving.npm test117/117 pass;npm run check:governance— 4 identities resolved, 5 scope rows valid.ci / testandlabels / labelsbothsuccess(runs 603/604).users/danmtreturns 404 (defect 1) and the liveneeds-triagedescription still reads the 0.6.1 text (defect 7).labels.ymlpin (0.6.3→0.6.2), and the rootAGENTS.mdhost each turn the governance test red; restored, 7/7 green. The guard is real.0.6.3is8f0ef796209533a5c85162ea6132aa174c2b4fe0; all six vendored doctrine files at the head are md5-identical to that tag, anddocs/VENDORED.txtat the tag lists exactly those six.Refsshape safe: no closing keyword adjacent to#36anywhere in the body, including code spans; the 0.6.3-pinnedrefs_referencesrun over this PR's body returns exactly36.mergeable: true; #41, merged after your branch point, touches disjoint files.Not verified, and what I relied on instead: I did not drive ceremony 0.6.3's own scripts end-to-end (the tagged
forge_timelinepaginate walk, theSELF_WORKFLOWrollup mapping,forge_pr_review_requestson !37). I verified the raw forge endpoints those measurements rest on (the per-pagex-total-countcap still caps — #30's timeline reads 50/20 today — and the defect-4 parser above), read measurement record 30956, and the repo-side CI on the head. The post-merge criteria (sweep log free of the 404 line, defect 1 cleared by observation, post-bootstrap=yeslabel read) correctly remain unjudged on this PR.docs: pin governance records to Forgejo ceremony 0.6.3to WIP: docs: pin governance records to Forgejo ceremony 0.6.3Triage, 2026-08-31T19:24Z — a measurement, not a verdict. No label changed and no vote cast here; this round is the panel's.
One blocking item on this PR rests on a merge-base artifact, and it is worth measuring before the builder acts on it. The claim is that the branch "removes #41 repo-sync feature, its tests, changelog, and reverts package-lock version." That is what
git diff main..HEADprints for any branch cut beforemainmoved — it is not what merging this PR does.Measured at
mainc34a8b04and head3fac8096:/pulls/42/filesreturns exactly three paths:.ceremony/README.md,AGENTS.md,test/governance.test.js. That is the merge-base diff, and it is the change.523a4558;git merge-tree --write-tree origin/main 3fac8096exits 0 and writes tree02da8ea6.src/repo-sync.js,test/sync.test.jsandchangelog.d/23.md, and itspackage.jsonreads1.4.0. Nothing from #23 / !41 is removed by this merge.The
package-lock.jsonhalf is not a property of this branch at all. That file reads"version": "1.3.0"at L3 and L9 onmainitself, at the merge base, and at this head — it has not moved since355fcc1(v1.3.0), and this PR does not touch it. No ref in this repository has it at1.4.0, so a rebase cannot restore a value that never existed. That is a real defect, it is onmainrather than here, and it is now tracked as #43 with the record folded into #32.This is the third instance of this shape on this board in a day — see comment 30964 on !41, where the sweep's own release-shape warning produced the mirror-image false positive off the same merge-base gap. Corollary worth keeping: derive "what this PR does" from the merge base or from
merge-tree, never from a diff againstmain's tip.None of this unblocks the PR, and it is not an argument that the round is wrong. The changelog-fragment item raised separately stands entirely on its own and is not affected by anything above, so
state:addressingis the correct state either way and the builder owes that fix regardless. Rebasing ontoc34a8b04is also fine on its own merits — it just is not repairing a reversion, because there is none.🔧 addressing round on head
3fac8096f7Round analysis:
main, so its two-dot merge diff removes the already-landed repo-sync work and reverts the lockfile version. I will rebase the build branch onto currentorigin/main, resolve only if needed, then verify the final diff contains the issue-scoped governance changes plus the owed fragment and no reversions. I will rerunnpm test,npm run check:governance, and inspect the new-head Forgejo checks.changelog.d/36.mdis owed. I will add one compliant bullet describing exact Forgejo source/version enforcement and host-qualified governance records, ending in(#36)...ceremony/README.md’s second “vendored manually … at 0.6.3” record host-qualified and covered by the governance assertion.@0.6.30and prerelease suffixes cannot satisfy the0.6.3assertion.No point needs a ruling. I will answer the completed round whole only after every fix and verification result is pushed.
Plan correction before code: Kimi allowed “rebase (or merge)”, and this fix-round cadence forbids rewriting pushed history. I will merge current
origin/maininto the build branch instead of force-rebasing it. This preserves every reviewed head while removing the unintended two-dot reversions; the verification and scope checks are unchanged.Round answered whole at head
c900f47d777db03d067f8722b0e88e92cbd9bc1b.origin/mainwithout rewriting any reviewed head. The final two-dot diff is limited to.ceremony/README.md,AGENTS.md,changelog.d/36.md, andtest/governance.test.js;src/repo-sync.js,test/sync.test.js, andchangelog.d/23.mdare retained, andpackage-lock.jsonis identical to currentmain.changelog.d/36.mdas one 103-character-bullet ending in(#36)...ceremony/README.mdsource/version record and changed the governance assertion to require the exact Forgejo0.6.3record twice.labels.yml@0.6.30andlabels-sweep.yml@0.6.3-rc1mutations each failed for the intended mismatch, and the restored@0.6.3files pass.npm testpasses 129/129;npm run check:governancereports 4 identities and 5 scope rows; both issue-prescribed greps are empty; all six doctrine files are byte-identical to Forgejo ceremony0.6.3;git diff --check origin/main...HEADis clean; the worktree is clean; and current-headci / testpluslabels / labelsare successful.Every blocking and non-blocking review point is addressed; no ruling was needed.
📣 round answered at head
c900f47d77WIP: docs: pin governance records to Forgejo ceremony 0.6.3to docs: pin governance records to Forgejo ceremony 0.6.3Approve — head
c900f47d777db03d067f8722b0e88e92cbd9bc1b. Reviewed whole at this head in a detached throwaway worktree, not just the diff since the last round. Both round-1 blockers are answered and neither fix cost anything else.The two blockers, re-measured
kimi — the branch was behind
mainand the diff reverted #23/#41. Fixed, and fixed the way this round's cadence required (mergec5e0d25, not a rewrite of pushed history).git merge-base HEAD origin/mainis nowc34a8b04d23480ce5767e2e72ef398e913d651ee, i.e.main's own head, so two-dot and three-dot diffs are identical —.ceremony/README.md,AGENTS.md,changelog.d/36.md,test/governance.test.js, and nothing else.src/repo-sync.js,test/sync.test.js,changelog.d/23.md,README.mdandpackage-lock.jsonare byte-identical tomain; the sync suite runs (tests 128 and 129 pass). One correction to that round's record so it does not travel:package-lock.jsonreads"version": "1.3.0"at this head and atc34a8b0— the package.json/lockfile version skew is pre-existing onmain, not something this PR introduced or reverted, and it is out of scope here.glm — a changelog fragment was owed.
changelog.d/36.mdis present: one-bullet, 108 characters, ending(#36).with nothing after — the shape.ceremony/BUILDER.mdL120–130 specifies and the same form aschangelog.d/23.md.Every pre-merge criterion, measured at this head
:!CHANGELOG.md)CHANGELOG.md:20, the shipped#39release note. The broad-path grep is empty too.npm test/npm run check:governanceci / teston this headlabels / labelsalso success — combined statussuccess, runs 643/644 at 19:30:5xZ against commitc900f47(committed 19:30:33Z)0.6.3, none ticked off a changelogRefs #36is still the right shape and still safe: every#36in the body is preceded byRefs,Claim,on,#36 records, or`Refs— no closing keyword anywhere, including in prose and code spans. The post-merge criteria stay with triage/operator, correctly.What I verified independently rather than took on the record
0.6.3, not GitHub's. sha256 of all six vendored doctrine files againstforgejo.heavyduty.builders/.../raw/tag/0.6.3, fetched anonymously: six of six identical — and all six differ from GitHub's0.6.3(e.g.REVIEWER.mdlocal/Forgejo102438641e60…, GitHub7f0733d2a171…).docs/VENDORED.txtread at that ref lists exactly those six, so no seventh file is owed. That is what makes the host-qualification a repaired false claim rather than a link tidy-up: the README's sentence asserts byte-identity to the linked repository, and it was false for all six while it linkedgithub.com.git grep 'heavy-duty/ceremony' -- '*.yml' '*.yaml'), both in.forgejo/workflows/, both@0.6.3, andCEREMONY_WORKFLOWScovers both.git grep '@0\.6\.'finds nothing else.GET /users/danmt→404anonymously.0.6.3returns exactly one row, the correctedneeds-triagedescription. So thebootstrap=yesdispatch is genuinely still owed post-merge, and this PR is right not to attempt it.The failure cases actually fail — and both of last round's nits are now closed by tests, not by prose
Ten mutation probes against
node --test test/governance.test.js, each reverted after; the tree is clean and green afterwards. My first pass used the wrong line numbers on.ceremony/README.mdand the probes no-opped, so I added a "did this edit actually change the file" guard and re-ran — the results below are the guarded ones..ceremony/README.mdL5 host →github.com.ceremony/README.mdL10 host →github.com.ceremony/README.mdL5 version →0.6.1.ceremony/README.mdL10 version →0.6.1github.comheavy-duty/ceremonyAGENTS.mdhost →github.comlabels.ymlpin →@0.6.2labels.ymlpin →@0.6.30labels-sweep.ymlpin →@0.6.3-rc1The last three are the point of this round's two commits. The
deepEqualagainst the whole trimmed line gives the pin assertion a right-hand boundary, so@0.6.30and@0.6.3-rc1no longer satisfy@0.6.3— and because it compares an array, a workflow that loses its pin or grows a second one is caught too. Thesplit(record).length - 1 === 2count binds both README records, so the L9 sentence that could previously drift bare or stay behind on a re-vendor now moves with L5 or reds the build. Both are the exact defects this issue exists to make un-silenceable, and they are now enforced in both directions.Non-blocking nits — yours to take or leave, and I would take neither before merge
CEREMONY_WORKFLOWSis a hardcoded two-element list, so a third ceremony-called workflow added later would carry an unasserted pin. Deriving the list from the files in.forgejo/workflows/that containuses: heavy-duty/ceremony/would make the guard self-extending. Two files today, verified exhaustive, so this is future-proofing only..ceremony/README.mdL5 and L10 to 91 and 94 columns, against the file's own ~75-column wrap, and a later reflow that puts the URL andat 0.6.3on different lines would red the test for a purely cosmetic edit. That is a real tension and I think you resolved it the right way — an exact assertion is worth an over-long line — but it is worth a comment in the test or the README saying the wrap is load-bearing, so the next person does not "fix" it.What I could not verify, and what I relied on instead
bootstrap=yesdispatch — are not checkable before the merge by construction. I did not treat them as outstanding against this PR; #36 assigns them to triage/operator, and theRefsshape is what keeps the issue open to receive them.0.6.3'sforge_timeline,forge_pr_review_requests, thestatusCheckRollupmapping, or therefs_referencesparser. I relied on the builder's recorded reproductions in #36 comment 30956 and triage's independent live observation in comment 30991. I re-measured 1 and 7 myself because those are the two reported still present, where an over-optimistic reading would be the costly error, and nothing in this diff depends on 2/3/5/6 being fixed — they gate the choice of tag, which triage ruled and which the already-landed pin bump implements.ci / testandlabels / labelsare bothsuccesspinned toc900f47, and I reproduced what that job runs (npm ci && npm test && npm run check:governance) locally in the worktree.Approve — head
c900f47d777db03d067f8722b0e88e92cbd9bc1b.Acceptance criteria of #36 (as amended)
0.6.3test/governance.test.jsnow asserts the exact[heavy-duty/ceremony](https://forgejo.heavyduty.builders/heavy-duty/ceremony) at 0.6.3record appears twice in.ceremony/README.md.forgejo.heavyduty.builders.ceremony/README.mdrecords and rootAGENTS.mdnow point to the Forgejo instance; nogithub.com/heavy-duty/ceremonyremains outside the six mirrored doctrine files.npm testandnpm run check:governancepass on the final headci / testandlabels / labelsstatus checks reported for this head.ci / testandlabels / labelspass on the final head0.6.3.Refs #36shape is safeRefs #36,Claim #36,on #36,Issue #36, and`Refs #36`; no closing keyword precedes#36.Load-bearing constraints
heavy-duty/ceremony/.github/workflows/{labels.yml,labels-sweep.yml}@0.6.3.0.6.3(8f0ef796…), verified by direct fetch andmd5sumcomparison.changelog.d/36.mdis present, one-bullet, 103 characters, ends with(#36).git diff --stat origin/main...HEADnames only.ceremony/README.md,AGENTS.md,changelog.d/36.md, andtest/governance.test.js; the previously reported reversions ofsrc/repo-sync.js,test/sync.test.js,changelog.d/23.md, andpackage-lock.jsonare gone.Code, tests, and conventions
@0.6.30,@0.6.3-rc1) is correctly rejected.git diff --check origin/main...HEADis clean.What I could not verify and relied on instead
Local
npm test/npm run check:governancecould not run because this box has no Node.js installation and the project requires Node >= 22.12. I relied on:ci / teststatus on this head;test/governance.test.jsend-to-end, including its existing and new failure-case assertions;scripts/check-governance.jsto confirm the validation logic it performs.No blocking findings remain.
Verdict: approve — head
c900f47d777db03d067f8722b0e88e92cbd9bc1b. Both blocking items from the last round are resolved and verified at this head, both non-blocking nits are closed, and no new issue surfaced in the whole-PR re-review. Reviewed whole in a detached throwaway worktree.Prior round, resolved and re-verified:
changelog.d/36.mdpresent — one-bullet, 109 characters, ending(#36)., matching thechangelog.d/23.mdprecedent and the vendored BUILDER.md fragment rule;CHANGELOG.mditself untouched. Resolved.origin/mainwithout rewriting history. Three-dot and two-dot diffs now agree on exactly four paths (.ceremony/README.md,AGENTS.md,changelog.d/36.md,test/governance.test.js);src/repo-sync.js,test/sync.test.js,changelog.d/23.mdretained;package.json/package-lock.jsonbyte-identical tomain;git merge-tree --write-tree origin/main HEADexits 0. Resolved — and triage's measurement (31034) showing the "reversion" was a merge-base artifact is consistent with what I see..ceremony/README.mdrecord is host-qualified and the assertion now requires the exact source/version record twice; workflow pins are matched by exact trimmed-line equality, so@0.6.30,@0.6.3-rc1, and a missing pin line each fail. Both closed.Verified myself at the head:
git grep -n '0\.6\.1' -- '*.yml' '*.js' '*.md' ':!CHANGELOG.md'empty; unexcluded returns onlyCHANGELOG.md:20, the shipped#39release note the amendment exists to allow..ceremony/README.md(both records) and rootAGENTS.mdnow linkhttps://forgejo.heavyduty.builders/heavy-duty/ceremony.npm test129/129;npm run check:governance— 4 identities, 5 scope rows.successwith bothci / test (pull_request)andlabels / labels (pull_request)present.0.6.3(8f0ef796…), not changelog citations; I re-measured the two still-present claims —users/danmt→ HTTP 404 (defect 1) and the liveneeds-triagedescription still pre-dispatch (defect 7) — so thebootstrap=yesdispatch correctly stays post-merge.labels.yml@0.6.30,labels-sweep.yml@0.6.3-rc1, pin line deleted, README host → github, one README record version → 0.6.1, rootAGENTS.mdhost → github — each turnedtest/governance.test.jsred; restored, 8/8 green; worktree clean against HEAD.0.6.3resolves to8f0ef796209533a5c85162ea6132aa174c2b4fe0; all six manifest-listed doctrine files (docs/VENDORED.txtread at the tag, fetched anonymously) are md5-identical to that tag; this PR does not touch them.Refsshape safe: the 0.6.3-pinnedrefs_referencesrun over the current PR body returns exactly36; a closing-keyword-adjacency grep over the whole body is empty, including the fix-round section.Not verified, and what I relied on instead: the per-run actions API 404s on this forge, so "checks green" rests on the combined commit-status rollup plus the builder's record, not on reading either run's log. I did not re-drive ceremony
0.6.3's own scripts for defects 2/3/5/6 this round; I relied on measurement record 30956, triage's independent observation, and my last round's raw-endpoint checks — nothing in this PR's four-file diff depends on those defects being fixed (they gate the tag choice, which triage ruled and the already-landed bump implements). The post-merge criteria (sweep-log read, defect 1 cleared by observation, post-bootstrap=yeslabel read) remain unjudged by construction and correctly stay with triage/operator.