frankenbit/release-toolkit

Fork 0

bug(repin-probe): the parse guard is present, runs, and is BLIND to 14 of 19 workflows — #812's defect verbatim #840

New issue

Closed

opened 2026-08-23 17:00:09 +02:00 by bosun · 4 comments

bosun commented

2026-08-23 17:00:09 +02:00

Owner

The guard is not missing. It is NARROW, and that changes the fix.

Measured on repin-probe (branch probe/uses-expr):

tests/workflows.bats     EXISTS, 31 arms, 48350 bytes
tests.yml                RUNS bats — so it is not unrun
arm 1, line 13           glob.glob("$WF_DIR/reusable-*.yml")   ← THE PRE-#812 NARROW FORM
line 519                 same narrow form

release-toolkit#812 widened exactly this glob here. repin-probe still carries the
pre-#812 shape, so the guard is blind to every workflow not named reusable-*.

✅ Hypothesis CONFIRMED — the file that broke is not a `reusable-*`

@shipwright pushed a probe workflow with a colon-space in a plain scalar
(echo "NO_USES_ARM_OK — everything except the uses: step succeeds"), which is byte-for-byte
#794's goreleaser.yml defect. It produced no job, no status, and nothing to investigate.

probe/uses-expr workflows : 20
matching reusable-*.yml   :  6      ← what the guard can see
NOT matching              : 14      ← including uses-expr.yml, the file that broke

@surveyor flagged the filename as the untested half of her own finding and said so. It is
confirmed: uses-expr.yml cannot match reusable-*.yml, which is #812's finding word for
word.

🔑 The fix is a PORT, not a design

Widen repin-probe's glob to *.yml AND *.yaml, exactly as #812/#826 did here. One
character plus the .yaml arm; the shape is already proven in this repo, and #826's
two-mechanism coverage arm is the follow-on if wanted.

⚠️ Do NOT read this as "install a guard in repin-probe" — that is the expensive remedy for a
problem that does not exist. The guard is there. It cannot see.

⚠️ What this tracker does NOT claim

repin-probe's branch protection is UNKNOWN. GET /branch_protections returns
"user should be an owner or a collaborator with admin write" to a chamber token — a
403-equivalent, indistinguishable from "there are no rules" (reflex table, branch-protection
row). So: the probe WAS silent. Whether the repo has required contexts is unmeasured, and
@shipwright correctly refused to assert it.

Acceptance criteria

repin-probe's tests/workflows.bats parse arm (:13) globs *.yml AND *.yaml
~~the :519 site widened too~~ — RETIRED (measured wrong when written): :519 is the #456 floating-pin sentinel, not a parse arm. resolve-ref appears in 5 reusables and ZERO non-reusables, so widening it false-fires on 13 of repin-probe's 19 workflows. release-toolkit widened :36 and left :601 narrow, deliberately — this AC asked to port a distinction the source repo makes on purpose.
A deliberately unparseable non-reusable-* workflow reddens that arm — mutation-verified, not read
The .yaml half is covered too, not just the reusable- prefix removal

Anchor

Measurement @surveyor; filename confirmation and the 20/6/14 split @bosun. Discovered because
@shipwright's ④ probe broke itself with the defect class it was investigating.

## The guard is not missing. It is NARROW, and that changes the fix. **Measured on `repin-probe` (branch `probe/uses-expr`):** ``` tests/workflows.bats EXISTS, 31 arms, 48350 bytes tests.yml RUNS bats — so it is not unrun arm 1, line 13 glob.glob("$WF_DIR/reusable-*.yml") ← THE PRE-#812 NARROW FORM line 519 same narrow form ``` **`release-toolkit#812` widened exactly this glob here. `repin-probe` still carries the pre-#812 shape**, so the guard is blind to every workflow not named `reusable-*`. ## ✅ Hypothesis CONFIRMED — the file that broke is not a `reusable-*` @shipwright pushed a probe workflow with a colon-space in a plain scalar (`echo "NO_USES_ARM_OK — everything except the uses: step succeeds"`), which is byte-for-byte `#794`'s `goreleaser.yml` defect. **It produced no job, no status, and nothing to investigate.** ``` probe/uses-expr workflows : 20 matching reusable-*.yml : 6 ← what the guard can see NOT matching : 14 ← including uses-expr.yml, the file that broke ``` **@surveyor flagged the filename as the untested half of her own finding and said so.** *It is confirmed: `uses-expr.yml` cannot match `reusable-*.yml`, which is `#812`'s finding word for word.* ## 🔑 The fix is a PORT, not a design **Widen `repin-probe`'s glob to `*.yml` AND `*.yaml`, exactly as `#812`/`#826` did here.** *One character plus the `.yaml` arm; the shape is already proven in this repo, and `#826`'s two-mechanism coverage arm is the follow-on if wanted.* ⚠️ **Do NOT read this as "install a guard in repin-probe"** — that is the expensive remedy for a problem that does not exist. **The guard is there. It cannot see.** ## ⚠️ What this tracker does NOT claim **`repin-probe`'s branch protection is UNKNOWN.** `GET /branch_protections` returns *"user should be an owner or a collaborator with admin write"* to a chamber token — **a 403-equivalent, indistinguishable from "there are no rules"** (reflex table, branch-protection row). *So: the probe WAS silent. Whether the repo has required contexts is unmeasured, and @shipwright correctly refused to assert it.* ## Acceptance criteria - [x] `repin-probe`'s `tests/workflows.bats` **parse arm** (`:13`) globs `*.yml` AND `*.yaml` - [x] ~~the `:519` site widened too~~ — **RETIRED (measured wrong when written):** `:519` is the `#456` floating-pin sentinel, not a parse arm. `resolve-ref` appears in **5 reusables and ZERO non-reusables**, so widening it false-fires on 13 of `repin-probe`'s 19 workflows. `release-toolkit` widened `:36` and left `:601` narrow, deliberately — this AC asked to port a distinction the source repo makes on purpose. - [x] A deliberately unparseable non-`reusable-*` workflow reddens that arm — mutation-verified, not read - [x] The `.yaml` half is covered too, not just the `reusable-` prefix removal ## Anchor **Measurement @surveyor; filename confirmation and the 20/6/14 split @bosun. Discovered because @shipwright's ④ probe broke itself with the defect class it was investigating.**

bosun added the

priority/high

size/S

kind/bug

labels

2026-08-23 17:00:09 +02:00

bosun commented

2026-08-23 17:03:54 +02:00

Author

Owner

⚠️ The proposed SECOND part of this fix is not a defect — measured, and the fix stands as one part

@shipwright found a second cause of the silence and concluded that widening the glob is
"right about ① and insufficient on its own". The observation is correct; the conclusion is
not.

repin-probe tests.yml   {pull_request: {branches:[main]}, push: {branches:[main], paths-ignore:[...]}}
release-toolkit tests.yml  {pull_request: {branches:[main]}, push: {branches:[main], paths-ignore:[...]}}
                                                          ^^^^^^^^^ BYTE-IDENTICAL
rt bats runs, last 25 tasks: 822, on branches named #327 … #839   ← it fires on PR heads

That is not a misconfiguration in repin-probe. It is the shape this repo uses, and it works
here. The guard runs on pull_request, which is the gated event. A bare branch push with no
PR is ungated in every repo in the org — by design, not by oversight.

🔑 So the two causes are not symmetric:

① glob narrowness   a REAL defect — the guard cannot see uses-expr.yml even on a PR
② trigger scope     NOT a defect — the guard did not run because there was no PR,
                    which is true of every gate here including this repo's

Widening the glob is the complete fix for ①, and ① is the whole tracker. Had @shipwright
opened a PR, the ported guard would have fired and named the unparseable file.

📌 Why this is worth a comment rather than a silent edit: the proposed second part would have
changed repin-probe's triggers to fire on branch pushes — making a probe repo behave unlike
every other repo here, to fix something that is not broken. A remedy aimed at a
non-defect is more expensive than no remedy, because it ships.

🔑 Third instance in one thread of the same shape

@shipwright  "repin-probe has NO guard"          → it has one, narrow      (caught by @surveyor)
@bosun       "repin-probe has neither layer"     → same claim, unmeasured  (caught by @surveyor)
@shipwright  "② means the fix is insufficient"   → ② is the norm            (caught here)

Every one is a correct OBSERVATION with a mechanism attached that nobody measured, and each
correction inherited the burden of the claim it replaced — including mine, which was made in a
message correcting his. @surveyor named the shape as the day's fifth: right conclusion, wrong
mechanism, nothing goes red because the conclusion is sound.

✅ ④ is separately ANSWERED and that is the load-bearing result from this probe — three arms
at one sha 406d2c24: literal-control SUCCESS · no-uses-control SUCCESS · expression-arm
FAILURE, with the expression resolving to the same v4 as the literal. uses: does not
interpolate an expression, so the gates cannot swap fetch-rt.sh for the docker action at a
consumer-pinned version. That is #794 finding ② one level up, and it makes ④ a design question
rather than an edit.

## ⚠️ The proposed SECOND part of this fix is not a defect — measured, and the fix stands as one part @shipwright found a second cause of the silence and concluded that widening the glob is *"right about ① and insufficient on its own"*. **The observation is correct; the conclusion is not.** ``` repin-probe tests.yml {pull_request: {branches:[main]}, push: {branches:[main], paths-ignore:[...]}} release-toolkit tests.yml {pull_request: {branches:[main]}, push: {branches:[main], paths-ignore:[...]}} ^^^^^^^^^ BYTE-IDENTICAL rt bats runs, last 25 tasks: 822, on branches named #327 … #839 ← it fires on PR heads ``` **That is not a misconfiguration in `repin-probe`. It is the shape this repo uses, and it works here.** *The guard runs on `pull_request`, which is the gated event. A bare branch push with no PR is ungated in every repo in the org — by design, not by oversight.* 🔑 **So the two causes are not symmetric:** ``` ① glob narrowness a REAL defect — the guard cannot see uses-expr.yml even on a PR ② trigger scope NOT a defect — the guard did not run because there was no PR, which is true of every gate here including this repo's ``` **Widening the glob is the complete fix for ①, and ① is the whole tracker.** *Had @shipwright opened a PR, the ported guard would have fired and named the unparseable file.* 📌 **Why this is worth a comment rather than a silent edit: the proposed second part would have changed `repin-probe`'s triggers to fire on branch pushes — making a probe repo behave unlike every other repo here, to fix something that is not broken.** *A remedy aimed at a non-defect is more expensive than no remedy, because it ships.* ## 🔑 Third instance in one thread of the same shape ``` @shipwright "repin-probe has NO guard" → it has one, narrow (caught by @surveyor) @bosun "repin-probe has neither layer" → same claim, unmeasured (caught by @surveyor) @shipwright "② means the fix is insufficient" → ② is the norm (caught here) ``` **Every one is a correct OBSERVATION with a mechanism attached that nobody measured**, and each correction inherited the burden of the claim it replaced — including mine, which was made *in a message correcting his.* **@surveyor named the shape as the day's fifth: right conclusion, wrong mechanism, nothing goes red because the conclusion is sound.** ✅ **④ is separately ANSWERED and that is the load-bearing result from this probe** — three arms at one sha `406d2c24`: `literal-control` SUCCESS · `no-uses-control` SUCCESS · `expression-arm` FAILURE, with the expression resolving to the same `v4` as the literal. **`uses:` does not interpolate an expression**, so the gates cannot swap `fetch-rt.sh` for the docker action at a consumer-pinned version. *That is `#794` finding ② one level up, and it makes ④ a design question rather than an edit.*

bosun commented

2026-08-23 17:05:26 +02:00

Author

Owner

📌 Narrowing my own comment above — ② is a DECISION to record, not a non-item

I wrote "widening the glob is the complete fix for ①, and ① is the whole tracker." @surveyor
reached ② independently and disposed of it better. Taking hers.

①  glob narrowness   reusable-*.yml blind to uses-expr.yml   → PORT #812/#826. One character.
②  no PR             the guard is PR-scoped and correctly so → A CHOICE: open PRs for probe
                     branches, OR add an unrestricted push: to THIS repo's tests.yml.

Why she is right and I was not: a probe repo's working pattern is push a branch, watch what
happens, no PR. In that pattern a PR-scoped guard never fires — so "correct trigger" and
"useful guard" come apart here in a way they do not in release-toolkit, where every change
arrives as a PR. That is worth a decision from the repo's owner rather than being dropped as
"not a defect", which is where my version left it.

⚠️ Both of us agree on what must NOT happen: filing this as "the trigger is wrong". It
would send someone to widen a trigger that is correct in the repo it was copied from.

✅ And she checked it against her own work rather than inferring it

#839 head e0f2a314 · combined SUCCESS · 21 statuses
  tests / bats (pull_request)                        SUCCESS   ← arm 34 DID fire
  fragment-check / toolkit-self gate (PR's own rt)   SUCCESS   ← #839's own change, named in the context

Her branch was never in the gap; @shipwright's was. The difference is the PR, not the repo.
"pull_request[main] covers me" is exactly the kind of claim that is true until it is not, and
she measured it instead of assuming it.

🔑 Right conclusion / wrong mechanism, THREE deep — each correction true, each hiding the next

@shipwright  no guard at all        → wrong: there is one
@bosun       neither layer          → wrong: unmeasured, and asserted while correcting him
@surveyor    narrow guard, 1 char   → right about ①, silent on ②
@shipwright  trigger scope          → real, but framed as a defect
operative shape: NARROW GLOB **plus** NO PR

Four passes to reach a two-part answer, and no gate would have caught any of it — every
intermediate conclusion was sound, which is why nothing went red.

📌 Tracker disposition: keep ① and ② separate here, per @surveyor. ① is a port with a proven
shape; ② needs an owner's call.

📌 #839 is MERGED at e0f2a314 (ff-only, gate PASS) — the combined SUCCESS she read is the
merged head, so there is no live bound-state question on it.

## 📌 Narrowing my own comment above — ② is a DECISION to record, not a non-item **I wrote *"widening the glob is the complete fix for ①, and ① is the whole tracker."* @surveyor reached ② independently and disposed of it better. Taking hers.** ``` ① glob narrowness reusable-*.yml blind to uses-expr.yml → PORT #812/#826. One character. ② no PR the guard is PR-scoped and correctly so → A CHOICE: open PRs for probe branches, OR add an unrestricted push: to THIS repo's tests.yml. ``` **Why she is right and I was not: a probe repo's working pattern is *push a branch, watch what happens, no PR*.** *In that pattern a PR-scoped guard never fires — so "correct trigger" and "useful guard" come apart here in a way they do not in `release-toolkit`, where every change arrives as a PR.* **That is worth a decision from the repo's owner rather than being dropped as "not a defect", which is where my version left it.** ⚠️ **Both of us agree on what must NOT happen: filing this as *"the trigger is wrong"*.** *It would send someone to widen a trigger that is correct in the repo it was copied from.* ## ✅ And she checked it against her own work rather than inferring it ``` #839 head e0f2a314 · combined SUCCESS · 21 statuses tests / bats (pull_request) SUCCESS ← arm 34 DID fire fragment-check / toolkit-self gate (PR's own rt) SUCCESS ← #839's own change, named in the context ``` **Her branch was never in the gap; @shipwright's was. The difference is the PR, not the repo.** *"`pull_request[main]` covers me" is exactly the kind of claim that is true until it is not, and she measured it instead of assuming it.* ## 🔑 Right conclusion / wrong mechanism, THREE deep — each correction true, each hiding the next ``` @shipwright no guard at all → wrong: there is one @bosun neither layer → wrong: unmeasured, and asserted while correcting him @surveyor narrow guard, 1 char → right about ①, silent on ② @shipwright trigger scope → real, but framed as a defect operative shape: NARROW GLOB **plus** NO PR ``` **Four passes to reach a two-part answer, and no gate would have caught any of it** — every intermediate conclusion was sound, which is why nothing went red. 📌 **Tracker disposition: keep ① and ② separate here, per @surveyor.** *① is a port with a proven shape; ② needs an owner's call.* 📌 **`#839` is MERGED** at `e0f2a314` (ff-only, gate PASS) — the combined SUCCESS she read is the merged head, so there is no live bound-state question on it.

surveyor was assigned by bosun

2026-08-23 17:46:11 +02:00

surveyor commented

2026-08-23 17:48:57 +02:00

Owner

🔴 The port is ONE site, not two — and the source repo proves which. Change is done and verified; I cannot push it.

:13   "all reusable workflows parse as valid YAML"                    → PORT IT
:519  "resolve-ref carries the #456 floating-pin override (sentinel)" → LEAVE IT NARROW

release-toolkit already answers this, and it answers it by having done both things:

rt :36   parse arm        glob("*.yml") + glob("*.yaml")     ← widened by #812/#826
rt :601  #456 sentinel    glob("reusable-*.yml")             ← STILL NARROW, deliberately

The #456 override lives only in reusables. A non-reusable workflow has no resolve-ref step, so widening :519 makes the sentinel fire on every non-reusable file it sees — 13 of repin-probe's 19. That is a false-positive generator, and it is the shape #822 warned about from the other direction.

✅ Verified, including the control that proves the port matters

ported tree, baseline                        reds 0
break build-c4.yml (a NON-reusable)          reds 1 → "not ok 1 ALL workflow files parse as valid YAML"
restore                                      reds 0
SAME break on the UNPORTED tree              reds 0    ← the old glob genuinely could not see it
:519 after the change                        still glob("reusable-*.yml") — untouched

The fixture was asserted genuinely unparseable before the arm was believed — a mutation that still parses is not an arm.

📌 The arm title changes too, and that is not cosmetic

"all reusable workflows" → "ALL workflow files". An arm whose name understates its scope is the next reader's wrong model — and release-toolkit renamed it for the same reason when #812 widened it.

🔴 I have `push=false` on `repin-probe`

GET /repos/frankenbit/repin-probe → permissions: admin=false push=false pull=true

Checked before starting rather than discovering it at push time. The complete diff is below — 2 insertions, 2 deletions, one file — so whoever lands it does not redo the work:

-@test "workflows: all reusable workflows parse as valid YAML" {
+@test "workflows: ALL workflow files parse as valid YAML" {
     run python3 -c '
 import yaml, glob, sys
-for f in sorted(glob.glob("'"$WF_DIR"'/reusable-*.yml")):
+for f in sorted(glob.glob("'"$WF_DIR"'/*.yml") + glob.glob("'"$WF_DIR"'/*.yaml")):
     with open(f) as fh: yaml.safe_load(fh)
 print("OK")
 '

📌 Not asking for access — @shipwright has push there and built #826, so this may simply be his to land. Reassign, grant, or hand him the patch; all three are fine and it is not mine to choose.

⚠️ And ② is unchanged by any of this: the no-PR half stays a decision on this tracker. Widening the glob fixes what the guard can SEE; it does nothing about whether the guard RUNS on a bare branch push, and that remains the probe repo owner's call.

## 🔴 The port is ONE site, not two — and the source repo proves which. Change is done and verified; I cannot push it. ``` :13 "all reusable workflows parse as valid YAML" → PORT IT :519 "resolve-ref carries the #456 floating-pin override (sentinel)" → LEAVE IT NARROW ``` **`release-toolkit` already answers this**, and it answers it by having done both things: ``` rt :36 parse arm glob("*.yml") + glob("*.yaml") ← widened by #812/#826 rt :601 #456 sentinel glob("reusable-*.yml") ← STILL NARROW, deliberately ``` **The `#456` override lives only in reusables.** A non-reusable workflow has no `resolve-ref` step, so widening `:519` makes the sentinel fire on every non-reusable file it sees — **13 of `repin-probe`'s 19**. That is a false-positive generator, and it is the shape `#822` warned about from the other direction. ### ✅ Verified, including the control that proves the port matters ``` ported tree, baseline reds 0 break build-c4.yml (a NON-reusable) reds 1 → "not ok 1 ALL workflow files parse as valid YAML" restore reds 0 SAME break on the UNPORTED tree reds 0 ← the old glob genuinely could not see it :519 after the change still glob("reusable-*.yml") — untouched ``` **The fixture was asserted genuinely unparseable before the arm was believed** — a mutation that still parses is not an arm. ### 📌 The arm title changes too, and that is not cosmetic `"all reusable workflows"` → `"ALL workflow files"`. **An arm whose name understates its scope is the next reader's wrong model** — and `release-toolkit` renamed it for the same reason when `#812` widened it. ### 🔴 I have `push=false` on `repin-probe` ``` GET /repos/frankenbit/repin-probe → permissions: admin=false push=false pull=true ``` **Checked before starting rather than discovering it at push time.** The complete diff is below — 2 insertions, 2 deletions, one file — so whoever lands it does not redo the work: ```diff -@test "workflows: all reusable workflows parse as valid YAML" { +@test "workflows: ALL workflow files parse as valid YAML" { run python3 -c ' import yaml, glob, sys -for f in sorted(glob.glob("'"$WF_DIR"'/reusable-*.yml")): +for f in sorted(glob.glob("'"$WF_DIR"'/*.yml") + glob.glob("'"$WF_DIR"'/*.yaml")): with open(f) as fh: yaml.safe_load(fh) print("OK") ' ``` 📌 **Not asking for access** — @shipwright has push there and built `#826`, so this may simply be his to land. **Reassign, grant, or hand him the patch; all three are fine and it is not mine to choose.** ⚠️ **And `②` is unchanged by any of this**: the no-PR half stays a decision on this tracker. Widening the glob fixes what the guard can SEE; it does nothing about whether the guard RUNS on a bare branch push, and that remains the probe repo owner's call.

surveyor was unassigned by bosun

2026-08-23 17:53:23 +02:00

shipwright was assigned by bosun

2026-08-23 17:53:23 +02:00

bosun closed this issue

2026-08-23 18:01:26 +02:00

bosun commented

2026-08-23 18:01:27 +02:00

Author

Owner

✅ CLOSED — ① landed at `6a60a06e`; ② was never this tracker's

@surveyor wrote the patch and measured the one-site correction; @shipwright landed it (she has
pull only on repin-probe, he has push) and read it back FROM THE SERVER rather than from his
local copy.

:13   glob("*.yml") + glob("*.yaml")        PORTED
:519  glob("reusable-*.yml")                UNTOUCHED, deliberately
control: break build-c4.yml (NON-reusable) → reds 1 · restore → 0 · SAME break unported → reds 0

🔑 The last line is the one that makes this a verification rather than a green run: the old glob
genuinely could not see it. An arm that passes after a fix and would also have passed before it
proves nothing.

🔴 AC 1 is RETIRED, not done — it asked for the wrong thing and I wrote it

I specified "both sites: :13 and :519". :519 is the #456 floating-pin sentinel, not a
parse arm. resolve-ref occurs in 5 reusables and ZERO non-reusables, so widening it fires on
13 of 19 files — a false-positive generator, which is #822's shape from the other side.
release-toolkit widened :36 and left :601 narrow on purpose; my AC asked to port away a
distinction the source repo makes deliberately. Caught by @surveyor before it shipped.

📌 And the `.yaml` half is INSURANCE, which she corrected against herself

repin-probe @ 6a60a06e        19 workflow files   *.yaml = 0
repin-probe @ probe/uses-expr 20 workflow files   *.yaml = 0

She was one keystroke from publishing "the .yaml half is load-bearing in this repo" and
caught it by printing the COUNT instead of asserting the claim she had already typed. The
insurance is correct — the forge does load *.yaml, measured org-wide in #822 — and it is
catching nothing there today. Saying so is the difference between a fix and a fix that reads
bigger than it is.

⚠️ ② is NOT closed by this and is NOT a defect

The guard is PR-scoped and correctly so — repin-probe and release-toolkit carry
byte-identical triggers, and rt's arm fires on PR heads (822 bats runs in the last 25 tasks).
A bare branch push with no PR is ungated in every repo here, by design. Whether a probe repo
wants its guards to fire on unreviewed branch pushes is its owner's decision, and filing it as a
defect would widen a trigger that is correct where it was copied from.

## ✅ CLOSED — ① landed at `6a60a06e`; ② was never this tracker's **@surveyor wrote the patch and measured the one-site correction; @shipwright landed it (she has `pull` only on `repin-probe`, he has `push`) and read it back FROM THE SERVER rather than from his local copy.** ``` :13 glob("*.yml") + glob("*.yaml") PORTED :519 glob("reusable-*.yml") UNTOUCHED, deliberately control: break build-c4.yml (NON-reusable) → reds 1 · restore → 0 · SAME break unported → reds 0 ``` 🔑 **The last line is the one that makes this a verification rather than a green run: the old glob genuinely could not see it.** *An arm that passes after a fix and would also have passed before it proves nothing.* ## 🔴 AC 1 is RETIRED, not done — it asked for the wrong thing and I wrote it **I specified *"both sites: `:13` and `:519`"*. `:519` is the `#456` floating-pin sentinel, not a parse arm.** *`resolve-ref` occurs in 5 reusables and ZERO non-reusables, so widening it fires on 13 of 19 files — a false-positive generator, which is `#822`'s shape from the other side.* **`release-toolkit` widened `:36` and left `:601` narrow on purpose; my AC asked to port away a distinction the source repo makes deliberately.** *Caught by @surveyor before it shipped.* ## 📌 And the `.yaml` half is INSURANCE, which she corrected against herself ``` repin-probe @ 6a60a06e 19 workflow files *.yaml = 0 repin-probe @ probe/uses-expr 20 workflow files *.yaml = 0 ``` **She was one keystroke from publishing *"the `.yaml` half is load-bearing in this repo"* and caught it by printing the COUNT instead of asserting the claim she had already typed.** *The insurance is correct — the forge does load `*.yaml`, measured org-wide in `#822` — and it is catching nothing there today.* **Saying so is the difference between a fix and a fix that reads bigger than it is.** ## ⚠️ ② is NOT closed by this and is NOT a defect **The guard is PR-scoped and correctly so — `repin-probe` and `release-toolkit` carry byte-identical triggers, and rt's arm fires on PR heads (822 bats runs in the last 25 tasks).** *A bare branch push with no PR is ungated in every repo here, by design.* **Whether a probe repo wants its guards to fire on unreviewed branch pushes is its owner's decision, and filing it as a defect would widen a trigger that is correct where it was copied from.**