Two required checks are a single echo; a third asserts a truth about arithmetic - #2192
Merged
Conversation
docs/BRANCH-PROTECTION.md names five required checks. Two of them -- seal-coverage.yml and schema-validation.yml -- have a body of exactly one echo. A third, phi-loop-ci.yml, is described there as the main test suite and asserts abs(phi**2 + phi**-2 - 3) < 1e-10, which is true of an empty repository, beside one genuine grep lint. A required check that cannot fail reads as coverage and is worse than none. That is the same shape found four times in this repository today. schema-validation now asks the weakest question worth asking -- does every tracked JSON parse -- chosen because it is cheap and carries no theory that could itself be wrong. It found one immediately: clara-bridge/audit-trail/experience-schema.json has a literal ... on line 40 clara-bridge/tests/run_tests.py:152 does json.load() on exactly that path 3 of its 11 tests were failing, measured by reverting and re-running no workflow runs clara-bridge, so nothing said so Fixed in one character; the suite is 11/11. Six empty JSON artefacts recorded as debts in tools/json_parse_baseline.txt. external/ excluded, because tsconfig is JSONC by convention and flagging it would be this gate making the very mistake it exists to catch. seal-coverage is deliberately untouched. .trinity/seals/ holds 1714 files keyed on TYPE names -- Account, AXI4_Testbench, "[]const u8" -- not spec names. My first attempt scored coverage by matching seal filenames to spec filenames and produced '1668 orphans of 1714, 1024 of 1070 uncovered', which is a finding about my assumption rather than the repository. t27c has no seal subcommand. I could not establish what a real seal-coverage check should assert, so I wrote neither a check nor a deletion. Closes #2191 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Renaming the job from 'validate' to 'schema-validation' removed the status-check context that branch protection matches on. The PR went BLOCKED with every visible check green and no required review outstanding, which is a confusing failure to read: the required context does not report as failing, it simply does not report. The workflow's display name may change freely; the job id may not. Refs #2191 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-18 13:07:11 UTC
Summary
Seal Status
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
docs/BRANCH-PROTECTION.mdnames five required checks. Read their bodies:seal-coverage.ymlecho "Running SEAL coverage analysis..."(17 lines, 1 step)schema-validation.ymlecho "Validating JSON schemas..."(15 lines, 1 step)phi-loop-ci.yml— described as "Main test suite"assert abs(phi**2 + phi**-2 - 3) < 1e-10, plus a realgreplint overffi/src/issue-gate.ymlA required check that cannot fail reads as coverage and is worse than none. This is the same shape found four times today already: a gate green because it is narrow, blind, or vacuous.
What this PR does
Replaces
schema-validation's echo with the weakest question worth asking — does every tracked JSON parse — chosen because it is cheap and carries no theory that could itself be wrong. It found something immediately:clara-bridge/audit-trail/experience-schema.jsonhas a literal...on line 40 and cannot parseclara-bridge/tests/run_tests.py:152doesjson.load()on exactly that pathclara-bridgeat all, so nothing said soFixed (one character), and the suite is now 11/11. Six empty JSON artefacts are recorded in
tools/json_parse_baseline.txtas debts, one per line;external/is excluded because tsconfig is JSONC by convention and flagging it would be this gate making the mistake it exists to catch.What this PR does NOT do, deliberately
seal-coverageis left alone..trinity/seals/holds 1714 files keyed on names likeAccount,AXI4_Testbenchand"[]const u8"— type names, not spec names. My first attempt scored coverage by matching seal filenames to spec filenames and produced "1668 orphans of 1714, 1024 specs of 1070 uncovered", which is not a finding about the repository but about my assumption.t27chas nosealsubcommand. I could not establish what a real seal-coverage check should assert, so I wrote neither a check nor a deletion.The vacuous half of
phi-loop-ciis also left in place and reported here rather than changed, since the other half is a genuine lint and removing the assert is a judgement about what "main test suite" is supposed to mean.Refs #2189
Closes #2191
🤖 Generated with Claude Code