Keep the current clock and stored-History readout alongside canonical row
selection and resource-owned drawer state.
Use one Git inheritance reader for browser and canonical qualification.
Inherited modes and objects keep their parent proof, while new resolutions
and mode changes remain subject to current contract and proof requirements.
Range checks still qualify the complete proposed change.
Refs #1669
A composed stylesheet can differ from every earlier browser receipt. Show the final digest and bounded valid receipt origins so its owner can identify the exact missing pass without manually reconstructing source and parent identities. Invalid receipts never supply hints, and all existing admission rules stay enforced.
Contract-Neutral: Diagnostics only; browser receipt validation, coverage and admission rules are unchanged.
Change-source: pulse-maintainer
The per-commit receipt change left
frontend-modern/browser-verification.json in the tree, frozen, so that
it would not conflict with the pull requests still rewriting it. Nothing
reads the file at the tip: range mode reads a receipt from the commit
that recorded it. Left in place it invites the old habit and keeps those
pull requests conflicting with each other on it.
The guard now refuses a staged tree or a range tip that carries the
file, rather than only a commit that writes it. Without that, resolving
the modify/delete conflict by keeping the file changes nothing against
HEAD, passes the hook, and restores the file on main when the branch
merges.
A pull request that still rewrites the file is repaired by merging main
and removing the file with git rm. Its commits remain valid evidence in
range mode.
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.
The maintainer coordinator integrates reviewed candidates by merge onto a
main that keeps moving, then ran this guard once over before..after with
--commit after. That demands one tip receipt whose base_sha is the tip's
parent and whose paths and digests cover the whole cumulative delta. The
tip is a merge and the range carries the candidate plus upstream work that
was verified on its own, so no lane could ever produce that receipt. 13 of
13 coordinator browser-guard rollbacks since 28 September failed on
base_sha for this reason.
Add --base <range-base> for range mode. Every changed user-visible
frontend file's content at the tip must equal a digest recorded by a valid
receipt in a non-merge commit inside the range, and each receipt is
validated as the per-commit guard validates it at its own commit, bound to
that commit's parent and tree. Merge-authored receipts are never evidence,
so a conflict resolution or a later correction that changes frontend
source still needs fresh proof for the final content. Replaying the three
rolled-back 29 September batches from the host passes, and the existing
per-commit and staged modes are unchanged.
A `make format` sweep re-lays-out already-committed files without
changing a single token, so it cannot change what renders. The browser
verification guard still demanded a fresh receipt for it, which would
mean recording routes, viewports, states and interactions nobody
exercised in order to describe a diff with no visual delta. A guard that
can only be satisfied by an untrue receipt teaches people to write
untrue receipts.
Exempt a path only when its new content is byte-identical to prettier's
output for its committed content. That is provable, not a judgement
call: if the two match, the sole difference from HEAD is layout.
Fails closed everywhere else -- added or deleted files, unreadable
blobs, prettier missing, or any non-identical output all fall through
and still require the receipt. A reformat that also changes a value is
covered by a test and still blocks.
rcourtman