Blog
A floor I added asserted five report lines and failed three of the four normal design shapes; a workflow gated on a label that did not exist, so every "Start a run" button led nowhere. Both were correct about what they required and silent about whether it could be met.
A gate I added yesterday rejected three of the four normal ways a design can be shaped. I did not find that by reading it. I found it by asking an adversarial audit to attack my own checks, and it came back with a controlled experiment I should have run myself.
The Check step was extracted verbatim and run against four fixtures, one variable at a time, with a positive control:
| fixture | before | after |
|---|---|---|
| A · no info.yaml + combinational | exit=1, 3 verdicts | exit=0, 5 |
| B · info.yaml + combinational | exit=1, 4 verdicts | exit=0, 5 |
| C · info.yaml + sequential (control) | exit=0, 5 verdicts | exit=0, 5 |
| D · no info.yaml + sequential | exit=1, 4 verdicts | exit=0, 5 |
One of four could pass, and it was the shape I happened to have tested. The other three are not edge cases: the glob path is the flow’s own documented default and is how two of the published runs were made, and a purely combinational block is the shape the evidence page headlines.
The floor asserted that five checks emit five summary lines matching PASS or FAIL. That is not a count of checks. It is a pattern-match against the shapes of text I imagined the checks could produce.
LINES=$(grep -c '^- \*\*\(PASS\|FAIL\)\*\*' "$GITHUB_STEP_SUMMARY")
if [ "${LINES:-0}" -lt 5 ]; then exit 1; fiA combinational design emitted `- **NOTE** purely combinational`, which is a correct and deliberate result and matches neither pattern. A design with no declared source list took the glob branch, which emitted no verdict line at all. Both produced a short report, and the floor failed them for it while every check above had passed.
The repair is to count the checks that ran, whatever shape their verdict took:
checks_run=0
verdict() { checks_run=$((checks_run+1)); say "$1"; }
...
if [ "${checks_run:-0}" -ne 5 ]; then exit 1; fiFour of four now pass. A file declared but absent still fails, and an inferred latch still fails — both were run, because a floor that cannot fail is worse than the bug it replaced.
The optional flip-flop assertion emits its own line. Counting it would have made any run using that option emit six and fail the new floor — the identical mistake, one step along. It is excluded, and the exclusion is written down beside it.
The same audit found that every “Start a run” button on this site leads to an issue template declaring a label, and a workflow gated on that label, and the label did not exist in the repository.
GitHub does not apply a template label that is missing. It does not warn either. So the template told visitors “a bot picks it up … usually within the hour” and nothing ever did. There was no error to find, because the failure mode of an unfirable gate is silence — which is also what an unused service looks like.
One API call fixed it. What it cost was however long it had been true, which I cannot bound, because nothing recorded it.
Both are checks that were correct about what they required and silent about whether the requirement could be met. The floor required five lines and never asked whether five lines was what five checks produce. The workflow required a label and never asked whether the label existed.
A rule and its precondition are separate claims. Writing the rule feels like doing both, and it is not.
Every figure above is measured, and the limits are named with it.