fix(tri): reachability is not staleness, and withdraw a claim of mine

.claude/skills/ci-gates/SKILL.md

@@ -9739,29 +9739,77 @@ against the *actual generated output* rather than reasoning about which code
 path it came from. The third row above was confirmed by generating the file and
 running the regex, not by reading the emitter.
 
-## 389. A gate that never runs on master has no baseline — borrow one from siblings
+## 389. Query the workflow, not a window — and take the missing reading on purpose
 
-`emit-bitexact-gate.yml` is `on: pull_request` with a `paths:` filter and no
-`push:`. It has therefore **never run on master**, so "is it red on master too?"
-is unanswerable, and `gh run list --branch master` returns nothing for it — which
-reads like "no data" and is easy to mistake for "no problem".
+**This section carried a false claim for one day. The claim was mine and it is
+corrected here rather than left standing beside a correction.**
 
-The baseline is still available: the same workflow ran on every other recent
-branch.
+What I wrote: *"`emit-bitexact-gate.yml` has therefore NEVER run on master, so
+`gh run list --branch master` returns nothing for it."*
+
+What is true:
 
-```bash
-gh run list --repo <r> --workflow <file>.yml -L 20 \
-  --json headBranch,conclusion,createdAt
 ```
+$ gh run list --repo gHashTag/t27 --workflow emit-bitexact-gate.yml \
+    --branch master -L 20 --json event,conclusion,createdAt
+  2026-08-28  workflow_dispatch  success   run 33150988445
+  2026-08-20  workflow_dispatch  failure   run 32319733329
+```
+
+Two master runs, and the most recent is a **success from two days before the
+change I was trying to judge** — precisely the baseline I said did not exist.
+
+### How the wrong reading was produced
+
+I ran `gh run list --repo <r> --branch master -L 40 --json name,conclusion`,
+filtered the result by workflow name, found nothing, and printed
+"нет в выборке" — then wrote it up as "never runs on master".
+
+That query is a **window over all workflows**, forty runs deep. This repository
+pushes to master often enough that forty runs is under an hour. A workflow
+absent from that window has not been shown to be absent from the branch; it has
+been shown to be absent from the last forty runs. The per-workflow query above
+is a different question with a different answer, and it costs the same.
+
+The trap is already written down: `-L N` is a window, not a lifetime count. I put
+that sentence into the instructions for a fan-out **in the same session**, and
+then read a window as a lifetime myself.
+
+### What survives, and it is the more useful half
+
+* **No `push:` trigger means no baseline is produced automatically.** That part
+  was right and is the thing worth fixing: `on: pull_request` + `paths:` and no
+  `push:` yields zero automatic master history, so the ordinary run of days
+  leaves nothing to compare against.
+* **`workflow_dispatch` was there the whole time**, since the file's creating
+  commit `1b47f8b85`. The missing measurement did not have to be borrowed — it
+  could have been **taken**. That is exactly what this repository's own
+  `tri gates unmeasured` doctrine says to do with an unmeasured gate, and what
+  `gate-topology.yml`'s header says `workflow_dispatch` is for.
+* **Borrowing from siblings still works and still gave the right verdict** —
+  green on five other branches, red on exactly one, which convicted the change.
+  It is a good second instrument. It is not the first thing to reach for when
+  the gate can simply be fired at master.
+
+So the order is: query the workflow directly; if that is genuinely empty and the
+gate carries `workflow_dispatch`, fire it at master and take the reading; only
+then borrow a baseline sideways from sibling branches.
+
+### The general form
+
+Three statements look identical in a terminal and are not:
+
+| statement | how to establish it |
+|---|---|
+| "it has not run recently" | a window: `gh run list --branch master -L N` |
+| "it has not run on this branch, ever" | per-workflow: `--workflow <file> --branch master` |
+| "it cannot run on this branch" | read the `on:` block |
 
-Green on five sibling branches, including two from other agents and one of my
-own from the same hour — red on exactly one. That convicts the change without
-any master run existing. It is also the cheapest way to separate "my change did
-this" from "this gate is just broken today".
+Reporting the third when you measured the first is the error. Say which one you
+took.
 
-(See also 348 on gates with `paths:` and no `push:`. The complement of that
-lesson is this one: no baseline does not mean no measurement, it means look
-sideways instead of backwards.)
+(See also 348 on gates with `paths:` and no `push:`, and 395 on a guard whose
+clean line was a claim about a population it never read.)
 
 ## 390. `git checkout` does not rebuild
 

.github/workflows/harness-scratch.yml

@@ -22,13 +22,16 @@
 # NO `paths:` FILTER, deliberately, for two reasons. The first is the same one
 # the orphan gate gives: the file that introduces the collision is not
 # necessarily the file that dies of it, so a filter on the failing path would be
-# silent for exactly this defect. The second is newer and cost a measurement
-# today -- `emit-bitexact-gate.yml` is `pull_request` with a `paths:` filter and
-# no `push:`, so it has NEVER run on master. When a change made it fail there was
-# no baseline to compare against and `gh run list --branch master` returned
-# nothing, which reads like "no data" and is one careless sentence away from
-# "no problem". A gate with no master history cannot answer the only question
-# that matters when it goes red.
+# silent for exactly this defect. The second is newer and cost
+# a measurement today -- `emit-bitexact-gate.yml` is `pull_request` with a
+# `paths:` filter and no `push:`, so no master run is ever produced
+# automatically. Two exist, both fired by hand through `workflow_dispatch`
+# (2026-08-20 failure, 2026-08-28 success), and I did not find them: I read a
+# forty-run window across ALL workflows on master, saw the name absent, and
+# wrote it up as "never runs on master". A window is not a lifetime.
+# `push: branches: [master]` costs one line and means the answer to "is it red
+# on master too?" is always already there, instead of depending on somebody
+# having remembered to dispatch it.
 #
 # A refusal, not a ratchet: the class is CLOSED as of #2949 and #2955 -- the
 # command reports `none` on master today, and there is no ceiling to hold, no

README.md

@@ -1,9 +1,9 @@
 # Trinity S³AI DNA -- t27 -- TRI-27 Spec-First Language
 
-[![CI](https://img.shields.io/github/actions/workflow/status/gHashTag/t27/ci.yml?branch=master&logo=github&label=CI)](https://github.com/gHashTag/t27/actions/workflows/ci.yml)
+[![CI](https://img.shields.io/github/actions/workflow/status/gHashTag/t27/bootstrap-tests.yml?branch=master&logo=github&label=CI)](https://github.com/gHashTag/t27/actions/workflows/bootstrap-tests.yml)
 [![Zenodo](https://zenodo.org/badge/DOI/10.5281/zenodo.19456875.svg)](https://doi.org/10.5281/zenodo.19456875)
 [![License: Apache 2.0](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
-[![Version: 0.1.0](https://img.shields.io/badge/version-0.1.0-orange.svg)](https://github.com/gHashTag/t27/releases)
+[![Version: 0.2.0](https://img.shields.io/badge/version-0.2.0-orange.svg)](https://github.com/gHashTag/t27/releases)
 
 
 > **Canonical Zenodo SOT:** [zenodo.org/communities/trinity-s3ai](https://zenodo.org/communities/trinity-s3ai/). The GoldenFloat badge above (19456875) is a legitimate Vasilev deposit but lives **outside** the curated S³AI v5.0 record set; see [docs/ZENODO.md](docs/ZENODO.md) for the canonical 12-record bundle and aliases.