Conversation
Skill 389 and the header of harness-scratch.yml both said emit-bitexact
"has NEVER run on master". It has run on master twice:
2026-08-28 workflow_dispatch success run 33150988445
2026-08-20 workflow_dispatch failure run 32319733329
The 2026-08-28 success is from two days before the change I was judging
-- the baseline I said did not exist, while I borrowed one from sibling
branches instead.
The wrong reading came from `gh run list --branch master -L 40 --json
name,conclusion` filtered by workflow name. That is a WINDOW over all
workflows, forty runs deep, which on this repository is under an hour. A
workflow absent from it has not been shown to be absent from the branch.
And the instrument already existed: `tri gates unmeasured` queries per
workflow by lifetime through the API's total_count, and does not list
emit-bitexact precisely because its dispatch is recent. I reached for a
raw gh window instead of the command written here for this question.
What the tool DID lack is orthogonal to staleness: whether a workflow can
produce a default-branch run at all without a human. One dispatched by
hand yesterday is not stale and still cannot take tomorrow's reading by
itself -- exactly the state emit-bitexact was in, and why its absence
from the stale table read as health.
`unmeasured` now prints that as its own section. Measured: 17 workflows
have no `push:` covering master, 5 of them merge-critical
(catalog-count-gate, check-now-freshness, emit-bitexact-gate, issue-gate,
phi-loop-ci). check-now-freshness is one of the four contexts the ruleset
requires and has no standing master reading; Issue Gate's last one is
2026-04-08. All 17 carry workflow_dispatch, so every missing reading can
be TAKEN rather than inferred.
has_auto_default_run is read by line, matching the two helpers beside it,
with 11 tests. Two are counterexamples a review would not produce: a
`push:` inside a COMMENT is not a trigger -- harness-scratch.yml's own
header recommends `push: branches: [master]` in prose, and a naive scan
reads its own advice as compliance -- and a `push` nested below the first
level inside `on:` is not one either. Also covered: bare `push:`, the
inline `on: [push, ...]` form, block lists, a `'**'` wildcard, and the
default branch as a parameter rather than the literal master. One test
reads every workflow in the tree and fails if it read fewer than ten,
because a test that reads nothing passes vacuously.
Section 389 is rewritten IN PLACE, not corrected beside itself, and now
names the three statements that look identical in a terminal: has not run
recently (a window), has never run on this branch (per-workflow), cannot
run on this branch (the `on:` block). Reporting the third when you
measured the first is the error.
Closes #2959
Refs #2957
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
The first version tested branch names for equality, so `branches: ['ma*']` would have read as "does not cover master" and reported a workflow structurally unmeasurable while it runs on every push. No workflow here uses such a pattern today -- an independent yaml+fnmatch reader agrees with this function on all 49 files -- so equality was correct here and wrong in principle, which is the worst kind of correct. GitHub's subset implemented: `*` matches within one path segment, `**` across them. `?` and character classes are treated as literals, which errs toward REPORTING a workflow as uncovered: a false entry in a work list is visible, a wrong silence is not. Five more tests, including the live shape that separates the two questions. notebook-sync.yml pushes on four patterns and none is master, so counting the push KEY gives 16 files without one and counting COVERAGE gives 17. 17 is the number that answers "can this produce a baseline", and it is where an independent sweep's 16 and this command's 17 turned out to agree rather than conflict -- they were answering different questions. Refs #2959 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-30 16:01:39 UTC
Summary
Seal Status
|
A correction to a message this command printed for about an hour. It said "dispatch: yes means the missing reading can be TAKEN" -- and for five of the seventeen it says that about, dispatching starts the workflow and measures nothing, because the check's subject IS a pull request. tools/check_now_entry_shape.py is explicit and deliberately so: on any event that is not pull_request it prints "NOT APPLICABLE ... Nothing was checked and nothing is claimed" and exits 0. Honest in its log, green in the checks list -- and `check` is one of the four contexts the ruleset requires. New `pr-only` column, measured by the pull-request context the workflow passes down. Of the 17: 12 takeable, 5 not -- Check Now Freshness, Issue Gate, L1 TRACEABILITY, NotebookLM Auto-Sync, PR Dashboard. Three of those five are merge-critical or required. The grep is weaker than reading the scripts each workflow calls, and it errs toward marking FEWER files: a false `-` sends someone to dispatch a gate that declines, which is recoverable; a false `YES` would tell them not to bother taking a reading that was available. A test pins that direction. Refs #2959 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-30 16:05:24 UTC
Summary
Seal Status
|
`ci.yml` does not exist on origin/master. Its registration is still active and its 23 lifetime runs are all on `dev`, the last of them 2026-04-22. With the README's own `?branch=master` the badge renders NO STATUS; drop that one parameter and it renders PASSING off April's dev history. The repository's most public claim about its own CI is one query parameter from a false green and cannot ever go red. Repointed at bootstrap-tests.yml -- the compiler's own test suite, 97 master runs. Reviewable: seal-coverage (914 master runs, 593 green), corpus-ratchet (409/182), schema-validation (428/426), secret-scan (711/707), gate-topology (351/351) and cli-tri (119/103) were the alternatives measured. cli-tri was rejected because #2903 records that it builds `-p tri` behind a `cli/**` filter, so a change to cli/tri-mcp turns a different crate green. The version badge said 0.1.0; bootstrap/Cargo.toml says 0.2.0 and the tag t27c-v0.2.0 exists. Deregistering the twelve fileless registrations appears unavailable -- GitHub keeps them after the file is deleted and exposes no delete endpoint -- so the consumer is what gets fixed. Refs #2961 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. |
Owner
Author
|
Three commits were added after this PR was opened, each with its own measurement:
Filed alongside: #2961 — two of the four required contexts produce no master reading, and for |
gHashTag
enabled auto-merge (squash)
August 30, 2026 16:08
Contributor
PR DashboardGenerated at: 2026-08-30 16:08:23 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-30 16:15:04 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.
A claim of mine was wrong, and the correction is the finding
Yesterday's skill section 389 and the header of
harness-scratch.ymlboth said:It has run on master. Twice.
The most recent is a success from two days before the change I was judging —
exactly the baseline I said did not exist, and I went and borrowed one from sibling
branches instead.
How the wrong reading was produced
I ran
gh run list --repo <r> --branch master -L 40 --json name,conclusion, filteredby workflow name, found nothing, and wrote it up as "never runs on master".
That is a window over all workflows, forty runs deep — under an hour on this
repository. A workflow absent from it has not been shown to be absent from the branch.
The per-workflow query costs the same and answers a different question.
Worse: the instrument already existed and would have said so.
tri gates unmeasuredqueries per workflow, by lifetime, through the API's
total_count— and it does not listemit-bitexactprecisely because its 2026-08-28 dispatch is recent. I reached for a rawgh run listwindow instead of the command in this repository written for this question.What the tool was actually missing
unmeasuredreports staleness. There is a second, orthogonal fact it never printed:whether a workflow can produce a default-branch run at all without a human. A
workflow dispatched by hand yesterday is not stale and is still structurally incapable of
taking tomorrow's reading by itself — which is exactly the state
emit-bitexactwas in,and why its absence from the stale table read as health.
tri gates unmeasurednow prints that as its own section:Five of the 18 merge-critical workflows are in that list —
catalog-count-gate,check-now-freshness,emit-bitexact-gate,issue-gate,phi-loop-ci.check-now-freshnessis one of the four contexts the ruleset actuallyrequires, and it has no standing master reading.
Issue Gate's last default-branch runis 2026-04-08, nearly five months ago.
All 17 carry
workflow_dispatch: yes, so every one of these readings can be takenrather than inferred. That is the actionable half, and it is what this repository's own
gate-topology.ymlheader saysworkflow_dispatchis for.The parsing, and the two counterexamples it needed
has_auto_default_runis read by line, matching the two helpers beside it, and haseleven tests. Two of them are counterexamples that a review would not have produced:
push:inside a comment is not a trigger.harness-scratch.yml's own headerrecommends
push: branches: [master]in prose. A scan that trims whitespace and looksfor
push:reads that advice as compliance.pushnested deeper than the first level insideon:— in apaths:list, or arun: git pushin a job — is not the trigger either.Also covered: a bare
push:with no branch list (fires on every branch, so it counts),the inline
on: [push, pull_request]form, block-list branches, a'**'wildcard, andthe default branch as a parameter rather than the literal
master. One test reads everyworkflow file in the tree and refuses to pass if it read fewer than ten — a test that
reads nothing passes vacuously.
What survives from the original lesson
The part that was right is the part worth acting on: no
push:means no baseline isproduced automatically, and the ordinary run of days then leaves nothing to compare
against. Borrowing a baseline from sibling branches still works and still gave the correct
verdict. It is a good second instrument and it should not have been the first.
Section 389 is rewritten in place rather than corrected beside itself, and now names the
three statements that look identical in a terminal:
gh run list --branch master -L N--workflow <file> --branch masteron:blockReporting the third when you measured the first is the error.
Refs #2957
Closes #2959 · Refs #2957
🤖 Generated with Claude Code