What
Two of the five marker rows in scripts/silent-revert-incidents.txt bind to a literal that occurs twice in the file it is bound to:
_FIND_SIDE_EFFECT_PRIMARIES in plugins/disk-hygiene/skills/clean/scripts/destructive_guard.pyMERGED_PR_GRAPHQL_ALIAS_PAGE in plugins/repo-fleet-hygiene/skills/audit/scripts/audit-fleet.sh
In both cases one occurrence is the definition and the other is a use site.
Why it matters
--verify-restoration tests marker presence with grep -qF. Because the literal appears twice, a partial re-land that restored only the use site — but not the definition — would still satisfy the grep and the check would report ok.
That is precisely the failure the restoration assertion exists to catch. #2855 was filed because a partial re-land passed the known-incident replay while the repository was still missing merged work; a marker that can be satisfied by half a restore reintroduces the same blind spot one level down.
Nothing is broken today — the content is fully present on main and --verify-restoration correctly reports 5 markers, 0 dispositioned. This is a latent weakness in the binding, not an active failure.
Suggested fix
Either pick a marker literal that occurs exactly once in the bound file (preferring one inside the restored block rather than at its use site), or strengthen the check so a marker declares its expected occurrence count and the check asserts that count rather than mere presence.
The second option is more work but generalizes: it would also catch the inverse case, where a botched restore duplicates a block.
How this was found
Flagged during the conflict resolution for #2843 by the lane reconciling that branch with main, and independently noted as drift while verifying the merged result. It belongs to the marker selection made in #2873, not to either of those changes.
What
Two of the five
markerrows inscripts/silent-revert-incidents.txtbind to a literal that occurs twice in the file it is bound to:_FIND_SIDE_EFFECT_PRIMARIESinplugins/disk-hygiene/skills/clean/scripts/destructive_guard.pyMERGED_PR_GRAPHQL_ALIAS_PAGEinplugins/repo-fleet-hygiene/skills/audit/scripts/audit-fleet.shIn both cases one occurrence is the definition and the other is a use site.
Why it matters
--verify-restorationtests marker presence withgrep -qF. Because the literal appears twice, a partial re-land that restored only the use site — but not the definition — would still satisfy the grep and the check would reportok.That is precisely the failure the restoration assertion exists to catch. #2855 was filed because a partial re-land passed the known-incident replay while the repository was still missing merged work; a marker that can be satisfied by half a restore reintroduces the same blind spot one level down.
Nothing is broken today — the content is fully present on
mainand--verify-restorationcorrectly reports 5 markers, 0 dispositioned. This is a latent weakness in the binding, not an active failure.Suggested fix
Either pick a marker literal that occurs exactly once in the bound file (preferring one inside the restored block rather than at its use site), or strengthen the check so a marker declares its expected occurrence count and the check asserts that count rather than mere presence.
The second option is more work but generalizes: it would also catch the inverse case, where a botched restore duplicates a block.
How this was found
Flagged during the conflict resolution for #2843 by the lane reconciling that branch with
main, and independently noted as drift while verifying the merged result. It belongs to the marker selection made in #2873, not to either of those changes.