Nothing stops a pull request from making a spec stop parsing #4276

Measured

t27c spec-status over every spec on master, by date:

The swarm adds implementations and breaks files in the same hours. 14 of the broken ones were repaired in #4272 by taking back the version the bee had written, because master's copy did not parse at all — t27c generates nothing from such a file, and every test it carries stops running.

Nothing catches it. The required checks on master are validate and check-linked-issue; neither runs the compiler over a changed spec. Corpus Ratchet and Spec Guards would notice, and they are not required — a pull request merges with them red.

Done when

• 1. a workflow runs on pull requests and on pushes to master, builds t27c, and for every changed .t27 compares t27c spec-status at the base against the head
• 2. it FAILS when a file that parsed at the base does not parse at the head, naming each file and the parse error; a file that was already NOPARSE is not a new failure (this is a ratchet, not a cleanup mandate)
• 3. it exits 2 — could-not-run, not a pass — when t27c cannot be built or run
• 4. it carries a negative control: --self-test proves the checker rejects the shape it exists to reject
• 5. python3 tools/ci/check_specs_still_parse.py --self-test prints a line beginning ok

Boundary

tools/ci/check_specs_still_parse.py