Found in the adversarial review of #120.
Step 8 says check_cards.py 'must report 0 drifted', then tells you to ship with drift
Where: .claude/skills/update-xmech-page/SKILL.md:209
The gate block in step 8 annotates python3 scripts/fleet/check_cards.py # must report 0 drifted. Lines 216-221 of the same step say: when a site has moved past its pin, keep the pinned figure and list the drifted cards in the PR. This PR followed the second rule and ships with 2 drifted. The gate as written cannot pass on this run and says nothing about which rule wins.
Failure scenario. A future run treats the 'must report 0' comment as a hard gate and re-pins one Mech to clear it. That is the partial rerun the skill forbids three paragraphs later. Or the run ignores the gate, in which case the comment is dead text that trains people to ignore a red check.
Evidence. SKILL.md:209 reads python3 scripts/fleet/check_cards.py # must report 0 drifted. SKILL.md:216-221 reads 'When a site has moved past its pin, do not re-pin that one Mech … say in the PR which cards will show as drifted.' A live run on the branch gives 2 drifted, exit 1.
Verifier (confirmed, low). The finding is accurate as stated. One refinement: the most likely way a future run "clears" the gate is to edit that Mech's hand-curated card figure to the live value, as check_cards.py's own output tells it to. A re-pin is less likely. Either way the page stops being a consistent snapshot at the pins. There is also no mechanism that lets the gate pass under the exception, because check_cards.py ignores site_figure_at_check. Fixing this needs both a reworded gate comment and one of two things: have check_cards.py treat a card whose figure matches the pinned figure and has a recorded site_figure_at_check as known drift, or state plainly that a nonzero exit is expected in that case.
Suggested fix. Change the comment to something like '# 0 drifted, or only Mechs whose site moved past the pin, each recorded as site_figure_at_check and named in the PR'.
Found in the adversarial review of #120.
Step 8 says check_cards.py 'must report 0 drifted', then tells you to ship with drift
Where:
.claude/skills/update-xmech-page/SKILL.md:209The gate block in step 8 annotates
python3 scripts/fleet/check_cards.py # must report 0 drifted. Lines 216-221 of the same step say: when a site has moved past its pin, keep the pinned figure and list the drifted cards in the PR. This PR followed the second rule and ships with 2 drifted. The gate as written cannot pass on this run and says nothing about which rule wins.Failure scenario. A future run treats the 'must report 0' comment as a hard gate and re-pins one Mech to clear it. That is the partial rerun the skill forbids three paragraphs later. Or the run ignores the gate, in which case the comment is dead text that trains people to ignore a red check.
Evidence. SKILL.md:209 reads
python3 scripts/fleet/check_cards.py # must report 0 drifted. SKILL.md:216-221 reads 'When a site has moved past its pin, do not re-pin that one Mech … say in the PR which cards will show as drifted.' A live run on the branch gives2 drifted, exit 1.Verifier (confirmed, low). The finding is accurate as stated. One refinement: the most likely way a future run "clears" the gate is to edit that Mech's hand-curated card figure to the live value, as check_cards.py's own output tells it to. A re-pin is less likely. Either way the page stops being a consistent snapshot at the pins. There is also no mechanism that lets the gate pass under the exception, because check_cards.py ignores
site_figure_at_check. Fixing this needs both a reworded gate comment and one of two things: have check_cards.py treat a card whose figure matches the pinned figure and has a recordedsite_figure_at_checkas known drift, or state plainly that a nonzero exit is expected in that case.Suggested fix. Change the comment to something like '# 0 drifted, or only Mechs whose site moved past the pin, each recorded as site_figure_at_check and named in the PR'.