Add post-merge file-presence verification to merge-pr workflow #112

New Issue

2026-07-02T18:07:58-05:00

sysadmin commented

2026-07-02 18:07:58 -05:00

Summary

Update the merge-pr workflow/template to require post-merge verification that expected files or commits are actually present on master before reporting a PR as merged.

Problem

Gitea PR state can be ambiguous: closed does not always mean merged.

Observed issue:

Some PRs were closed without merging, but summaries treated them as landed (#82/#84 incident, caught during the v1.1.0 release audit).
The problem was only caught later by auditing whether expected files existed on master.

Proposed rule

After every merge, verify the actual landed state before reporting success.

Examples:

git fetch --all --prune
git checkout master
git pull --ff-only
git log --oneline -- <expected-file>
git merge-base --is-ancestor <pr-head-sha> master
git diff --name-only <base>...master

Use the appropriate probe for the merge method:

merge commit: ancestor check may work
squash merge: file-level or commit-message verification may be needed
docs-only change: verify expected file exists on master
deletion change: verify expected file is absent and commit/log supports it

Scope

Update:

merge-pr template
review/merge runbook
any skills docs that describe final merge reporting

Non-goals

Do not change merge tooling unless needed.
Do not implement release SOP in this issue.
Do not touch tags.
Do not alter self-review/self-merge gates.

Acceptance criteria

Merge workflow requires post-merge verification.
Docs warn that closed is not equivalent to merged.
Template requires verifying expected file/commit presence before final report.
Final report must include the verification method used.
Works for merge commits and squash merges.

Related: #51 (reconciliation rules), the release SOP re-land issue (this batch).

## Summary Update the merge-pr workflow/template to require post-merge verification that expected files or commits are actually present on master before reporting a PR as merged. ## Problem Gitea PR state can be ambiguous: `closed` does not always mean merged. Observed issue: - Some PRs were closed without merging, but summaries treated them as landed (#82/#84 incident, caught during the v1.1.0 release audit). - The problem was only caught later by auditing whether expected files existed on master. ## Proposed rule After every merge, verify the actual landed state before reporting success. Examples: ```bash git fetch --all --prune git checkout master git pull --ff-only git log --oneline -- <expected-file> git merge-base --is-ancestor <pr-head-sha> master git diff --name-only <base>...master ``` Use the appropriate probe for the merge method: * merge commit: ancestor check may work * squash merge: file-level or commit-message verification may be needed * docs-only change: verify expected file exists on master * deletion change: verify expected file is absent and commit/log supports it ## Scope Update: * merge-pr template * review/merge runbook * any skills docs that describe final merge reporting ## Non-goals * Do not change merge tooling unless needed. * Do not implement release SOP in this issue. * Do not touch tags. * Do not alter self-review/self-merge gates. ## Acceptance criteria * Merge workflow requires post-merge verification. * Docs warn that `closed` is not equivalent to `merged`. * Template requires verifying expected file/commit presence before final report. * Final report must include the verification method used. * Works for merge commits and squash merges. Related: #51 (reconciliation rules), the release SOP re-land issue (this batch).