Skip to content

ci(fpga-build): run the gate-precondition control when a gate it guards changes, and after a red ratchet (Refs #5453) - #5489

Merged
dmitrii-f-t27 merged 1 commit into
masterfrom
fix/preconditions-control-runs
Oct 2, 2026
Merged

dmitrii-f-t27 merged 1 commit into
masterfrom
fix/preconditions-control-runs

Conversation

@dmitrii-f-t27

Copy link
Copy Markdown
Collaborator

Refs #5453

tools/check_gate_preconditions.py already catches what #5183 did to the seal gate. It never ran where it could have, and this PR makes it run. The restore itself is #5454; this PR does not touch tools/check_seal_coverage.py.

What the control says

Measured locally on master d4c4f2f, with t27c rebuilt from it:

tools/check_seal_coverage.py python3 tools/check_gate_preconditions.py
master's one-line file exit 1: VACUOUS check_seal_coverage.py [bare] exits 0 with nothing to check
the 687-line file from bcb32d723^ (#5454) exit 0: OK: 10 precondition(s) across 6 gates fail loudly

Why it never said so

  1. Path filters. fpga-build.yml started only on two of the six gates in that table (check_vector_data.py, check_elab_ratchet.py). 131 seals are stale: the spec changed after sealing #5183 touched tools/check_seal_coverage.py and a docs/now entry, so the workflow never ran.
  2. One red step skips the rest. Since a90bdac (2026-09-22), every master run of fpga-conformance has failed at step 9, "Elaboration errors may fall, never rise", and GitHub skipped steps 10-16. Step 11 is this control (run 36883584257 is the latest). So it returned no verdict for the week before 131 seals are stale: the spec changed after sealing #5183 and the two days after.

Change

  • Both path lists (pull_request, push) gain the other four gates in the table, plus the helper it plants them with: check_seal_coverage.py, check_duplicate_agreement.py, check_specs_generate.py, check_specs_parse.py and tools/_prereq.py.
  • The step gets if: always(), the idiom bootstrap-tests.yml and corpus-ratchet.yml already use. It reads the built t27c and the tree, never the ratchet's verdict. If t27c did not build, it reports UNRUN, which is red and true.

Expected on this PR: step 11 goes red with VACUOUS for check_seal_coverage.py, because master still carries the one-line file. It goes green when #5454 lands. fpga-conformance is red on master anyway, from step 9. Neither is a required check; the required checks are validate, check-linked-issue and parse-ratchet.

Not changed: steps 10 and 12-16, which the same ratchet skips: its own negative control, both vector-data steps, conformance vector execution, JSON structure and power regression. Whether they should run past a red ratchet is the FPGA job's call.

Independent check of #5454

No code from #5454 is in this PR. Its file is byte-identical to bcb32d723^ (checked with cmp).

Baseline: unchanged, by measurement

tools/seal_baseline.txt has 94 lines, and they are exactly the 94 seals with no spec on disk or no spec_path, one for one. None is paid, none departed and none changed class, so there is nothing to tighten (§67).

Writing the 654 into it by hand would produce the same file --update-baseline writes. That is the decision #5158 left to the owner, and #5453 asks the gate to report red until it is made. It would also file seven seals that are simply wrong as debt, when the fix for those is a re-seal with master's t27c.

🤖 Generated with Claude Code

…ds changes, and after a red ratchet (Refs #5453)

tools/check_gate_preconditions.py runs six gates on an empty tree and
names any that exit 0 with nothing to check. Given master's one-line
tools/check_seal_coverage.py it says, in under two seconds:

    VACUOUS   check_seal_coverage.py [bare] exits 0 with nothing to check

It never got to say it, for two independent reasons:

- fpga-build.yml listed only two of the six gates in its path filters,
  so #5183 -- which emptied check_seal_coverage.py on 2026-09-29 and
  touched nothing else but a docs/now entry -- never started it.
- Since a90bdac (2026-09-22) every master run of fpga-conformance has
  failed at "Elaboration errors may fall, never rise", and GitHub skips
  every later step, this control included.

So the other four gates in its table and tools/_prereq.py (which it
plants them with) join both path lists, and the step runs with
`if: always()`, the idiom bootstrap-tests and corpus-ratchet already
use. It reads the built t27c and the tree, never the ratchet's verdict;
when t27c did not build it reports UNRUN, which is red and true.

On this PR the step is expected to report VACUOUS for
check_seal_coverage.py: master still carries the one-line file until
#5454 lands.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Oct 1, 2026

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

@github-actions

github-actions Bot commented Oct 1, 2026

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-01 23:46:27 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 47
PRs with All Checks Green 3
READY 3
FAILING 47
PENDING 0
NO CHECKS YET 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=b7d5cc5c4cf1 != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@dmitrii-f-t27
dmitrii-f-t27 merged commit 756bcff into master Oct 2, 2026
38 of 42 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant