mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-10-26 21:47:20 +00:00
rcourtman
fe82cb29a3
Every commit touching user-visible frontend source rewrote the single frontend-modern/browser-verification.json, so any two open frontend pull requests conflicted as soon as either merged. A merge could not repair the loser: concluding it staged main's frontend files as if the author had changed them, and the guard then demanded a receipt for files the author never ran. The only honest recovery was a rebuild on the new main and a fresh browser pass, as #2415 -> #2418 -> #2433 showed on 2-3 October. Each commit now adds its own receipt under frontend-modern/browser-verification/, named by the fingerprint of the content it verified. Receipts are only ever added, so git merges them unaided. The guard keeps every binding it had: the commit's own parent, the exact changed paths and their content digests, a desktop and a narrow viewport, non-empty routes, states and interactions, and the range check that each changed file's final content matches a receipt from a non-merge commit in the range. Concluding a merge no longer counts content a merged parent already carries as the commit's own change. Merged content that neither parent holds is flagged and still needs a follow-up receipt in range mode, and a merge commit may not record one. The shared file is retired: no commit may write it again. A commit that modified it while its own parent still carried it stays valid evidence in range mode, so a pull request that still rewrites it is repaired by merging main and taking main's copy rather than by a rebuild. The file is deleted in a change of its own, because deleting it here would conflict with every pull request that still rewrites it. --write-template writes the skeleton at the path the staged content requires. --prune deletes receipts already on main. A change that records a receipt may not delete one: git pairs the two as a rename, which conflicts with any other change deleting the same receipt.
926 B
926 B
Browser verification receipts
Each commit that changes user-visible frontend source adds one receipt here. The file name is the fingerprint of the content the receipt verified, so no two changes write the same file and open frontend pull requests cannot conflict on their receipts.
Create the skeleton for the staged change, then fill it in after the browser pass:
python3 scripts/release_control/browser_verification_guard.py --write-template
Do not edit, rename or delete another change's receipt in a commit that adds
one. A receipt is read from the commit that recorded it, so receipts whose
commits are already on main are dead weight; remove them in a change that
records none:
python3 scripts/release_control/browser_verification_guard.py --prune
The rules live in the Frontend Browser Verification Gate section of
docs/release-control/v6/internal/CANONICAL_DEVELOPMENT_PROTOCOL.md.