[mforce]

What and why

The maintainer merged #1328 with the web button, so the documented gh pr merge --body "Release-As: …" never ran and the release PR stayed at 1.2.0. Adding release-please's commit-override block to #1328's description and re-running Release moved #1320 to 1.1.2. The guide said a Release-As line in the PR description does nothing. That holds only for a plain footer.

Docs:

• Forcing a version in docs/releasing.md. The override block, written in the PR description when the PR is opened, is now the main method. It works whatever merges the PR. gh pr merge --body remains the other option. The guide still warns that the block replaces the whole message release-please parses, so it starts with the full conventional subject, and that a malformed block drops the commit. release-please does not rewrite the git commit itself.
• Recovery for a PR merged without the block. Edit its description, re-run the Release run on the PR's base branch, wait for it with gh run watch --exit-status, then read the pending release PR for that base. This works for main and for release/vX.Y.x.
• Notes. The release App force-pushes its own release-please--branches--<target>--components--cluckwork branch on every Release run that changes the release PR. It never pushes main.

CONTRIBUTING.md, .github/AGENTS.md, .github/pull_request_template.md and docs/decisions/351-releases.md now say the same.

Hooks:

• pre-push runs .github/scripts/docs-impact.mjs for the first branch pushed, against its merge base with origin/main. It warns and never refuses, because the PR body that can waive a finding may not exist at the first push. It skips quietly without node, the script or origin/main. It adds about 0.23 s to a push (three runs). The check is synchronous with no timeout, so a push waits for it: an injected 1.5 s delay gave a 1,532 ms hook run, still exiting 0. feat(mcp): submit daily entries and record feed, water, purchases and expenses #1325 skipped the documented manual run and failed CI.
• pre-commit's refusal on main now names --no-verify as the skip.

Both hooks run only in a clone with git config core.hooksPath .githooks set. The main-branch refusal already existed (#1172). It did not stop fdd750ac because hooks were off in that clone at the time. The maintainer has since set core.hooksPath .githooks there and updated the checkout to origin/main (both verified: HEAD and origin/main are eeb90cfd).

How it was verified

• python3 tools/agent-guard/git_hooks_test.py: 13 tests, including four new DocsImpactWarningTest cases. The fixture moves upstream past the merge base and checks out a branch other than the one pushed. Each of these hook changes turns the tests red: using the origin/main tip instead of the merge base, using HEAD instead of the pushed commit, checking the last branch instead of the first, and refusing on a finding.
• python3 tools/agent-guard/git_guard_test.py, node --test .github/scripts/docs-impact.test.mjs .github/scripts/release-line.test.mjs (29 tests), and the ImagePin|SchemaDocs|Documentation application tests (20 tests).
• I ran the recovery commands read-only against chore: release 1.1.2 as a patch #1328 and Release run 39199470635.

Not verified: whether gh run watch sees the old completed attempt immediately after gh run rerun and returns early. Nobody triggered a live rerun to observe it.