seal(t27f): re-seal frontend.t27, stale since 3b7c34bf1 (#10939), Seal Coverage red #10967

The coverage job of the Seal Coverage workflow fails on every PR because one seal on master no longer holds: .trinity/seals/t27f_T27fFrontend.json is [stale]. Master 3b7c34b (#10939, "widgets: catalogue all 82 widget folders and the factory law") changed specs/t27f/frontend.t27 without re-sealing it. The previous identical fix was #10814.

Boundary

• .trinity/seals/t27f_T27fFrontend.json

User Scenarios

• Given master with specs/t27f/frontend.t27 edited by widgets: catalogue all 82 widget folders and the factory law #10939, when t27c seal --verify specs/t27f/frontend.t27 runs, then it reports VERIFICATION FAILED.
• Given the seal regenerated by t27c seal specs/t27f/frontend.t27 --save with a t27c built from current master, when the same verify runs, then it prints all hashes MATCH.
• Given the regenerated seal, when tools/check_seal_coverage.py runs, then it reports no newly failing seal and the coverage job is green.

Requirements

• FR-001: .trinity/seals/t27f_T27fFrontend.json MUST be rewritten by t27c seal --save run on the Railway lab, never hand-edited.
• FR-002: The spec specs/t27f/frontend.t27 MUST NOT change.
• FR-003: The diff MUST contain only the seal file.

Success Criteria

• t27c seal --verify specs/t27f/frontend.t27 prints all hashes MATCH.
• check_seal_coverage.py reports 0 newly failing seals; the coverage job is green on the PR.

Generated with Claude Code