boost-skill-cli 1.2.172__tar.gz → 1.2.174__tar.gz

{boost_skill_cli-1.2.172 → boost_skill_cli-1.2.174}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.172
+Version: 1.2.174
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.172 → boost_skill_cli-1.2.174}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.2.172'
-__version_tuple__ = version_tuple = (1, 2, 172)
+__version__ = version = '1.2.174'
+__version_tuple__ = version_tuple = (1, 2, 174)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.172 → boost_skill_cli-1.2.174}/boost_skill_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.172
+Version: 1.2.174
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.172 → boost_skill_cli-1.2.174}/boost_skill_cli.egg-info/SOURCES.txt

@@ -355,6 +355,7 @@ docs/roadmap/items/build-provenance-slsa-attestations.md
 docs/roadmap/items/cache-the-catalog-entry-set-across-rag-queries.md
 docs/roadmap/items/cache-writers-that-still-crash-on-a-read-only-cache.md
 docs/roadmap/items/canary-deps-check-skips-in-the-required-job.md
+docs/roadmap/items/cancelled-ci-on-main-is-silent-and-skips-the-release.md
 docs/roadmap/items/capability-manifest-and-least-privilege-policy.md
 docs/roadmap/items/capability-policy-skips-rules-and-workflows.md
 docs/roadmap/items/catalog-categories-beyond-curated.md
@@ -1033,6 +1034,7 @@ tests/unit/test_mcphost.py
 tests/unit/test_measure_registry.py
 tests/unit/test_minisign.py
 tests/unit/test_mutation_hardening.py
+tests/unit/test_mutation_shard_count.py
 tests/unit/test_mutation_shards.py
 tests/unit/test_mutation_subfile_shards.py
 tests/unit/test_mutation_weights_drift.py

boost_skill_cli-1.2.174/docs/roadmap/items/cancelled-ci-on-main-is-silent-and-skips-the-release.md

@@ -0,0 +1,114 @@
+---
+id: cancelled-ci-on-main-is-silent-and-skips-the-release
+board: code
+section: trust
+status: inflight
+category: CI · Bug
+complexity: S
+impact: High
+wow: 4
+note: the alerting that exists to make a red main impossible to miss asks only about 'failure', and the run that skipped a release was 'cancelled'
+order: 365
+owner: loop/ci-alert-conclusions
+pr: 1025
+title: "A <code>cancelled</code> <code>ci</code> on main skips the release and alerts nobody, because the alert asks only about <code>failure</code>"
+---
+<b>Two independent gates, both keyed on the wrong half of the same enum.</b>
+<code>publish.yml</code> fires on <code>workflow_run</code> and ships only when
+<code>conclusion == 'success'</code>; <code>ci-failure-alert</code> opens the tracking issue
+only when <code>conclusion == 'failure'</code>. A <code>ci</code> run that concludes
+<code>cancelled</code> satisfies neither. <b>It does not ship and it does not tell anyone</b>
+&mdash; the one conclusion that falls through both.
+
+<b>Observed, on the merge of #1015.</b> <code>mutation-shard (4)</code> hit
+<code>timeout-minutes: 75</code> and was cancelled, the aggregate <code>mutation</code> job
+failed, and the run concluded <code>cancelled</code> rather than <code>failure</code>. No
+release, no issue, no notification. It surfaced the same day, and only because somebody was
+reading per-shard job durations out of the Actions API for an unrelated reason &mdash; nothing
+in the repo would have raised it, and the next one will be found the same way or not at all.
+
+<b>This is the exact blind spot <code>ci-failure-alert</code>'s own header describes.</b> That
+file opens by explaining that <code>demo</code> "failed six runs out of six on main, alerted
+nobody, and was found by a manual audit instead", and concludes that "any workflow that runs on
+main and nobody watches belongs here". The list was then enforced by
+<code>tests/unit/test_failure_alerting_covers_unattended.py</code> so a new workflow cannot
+quietly join the blind spot. <b>The enforcement is over <em>which workflows</em> are watched,
+and the hole here is <em>which conclusions</em> are</b> &mdash; <code>ci</code> is on the list
+and still said nothing.
+
+<b>Why a timeout is not an exotic case.</b> It is the designed behaviour of every
+<code>timeout-minutes</code> in the repo, and <code>mutation-shard</code>'s is reached by an
+ordinary slow runner rather than by a bug: across 169 measured shard jobs the worst was 72.5
+minutes against a 75-minute cap. A job can also be cancelled by the concurrency group or by a
+human pressing the button &mdash; and only the last of those is one anybody already knows about.
+
+<b>A runner eviction is the neighbouring case, and it concludes differently.</b> An earlier
+draft of this card listed eviction among the routes to <code>cancelled</code>; measured on
+2026-10-02, it is not. <code>mutation-shard (0)</code> on main took
+<code>The runner has received a shutdown signal</code> and exit 143 at mutant 3095 of 28084,
+the job concluded <b>failure</b>, and the alerting fired correctly &mdash; issue #1024 opened
+and auto-closed when a rerun of the failed jobs went green. That is the point of widening on
+the <em>green</em> set rather than enumerating bad conclusions: the two most common ways a
+shard dies land on different sides of an <code>== 'failure'</code> test, and a gate that has
+to know which one it was is a gate that will be wrong again.
+
+<b>Shape of the work.</b> Widen the alert's condition from <code>== 'failure'</code> to the set
+of conclusions that mean "main is not green", which is every one except <code>success</code>,
+<code>skipped</code> and <code>neutral</code> &mdash; naming what is <em>excluded</em> rather
+than what is included, so the next conclusion GitHub adds defaults to loud. The issue body
+should say which conclusion it was, because <em>cancelled</em> and <em>failure</em> want
+different first moves. Then pin it: the sibling test already enforces the workflow list, so the
+conclusion set wants the same treatment rather than a comment. Worth checking at the same time
+whether <code>publish.yml</code> should distinguish "CI did not pass" from "CI did not finish"
+&mdash; today both are a silent no-op, and a release that was skipped because a runner was slow
+is recoverable by a rerun that nobody currently knows to start.
+
+<b>Shipped.</b> The opener now gates on the green set <em>negated</em> &mdash;
+<code>!contains(fromJSON('["success", "skipped", "neutral"]'), conclusion)</code> &mdash; so a
+conclusion GitHub adds later defaults to loud. <code>skipped</code> and <code>neutral</code>
+are in it deliberately: <code>release</code> skips on every run it does not publish from, so
+without that exclusion each non-green <code>ci</code> would open two issues. The closer keeps
+<code>== 'success'</code>, because a <code>cancelled</code> run says nothing about whether the
+tracked failure is fixed and must not stand the issue down. The body now names the conclusion
+and, for <code>ci</code>, says no release was cut and that a rerun is what publishes it.
+
+<b>publish.yml was left alone, deliberately.</b> Its
+<code>conclusion == 'success' &amp;&amp; event == 'push'</code> guard is the fork-PR boundary
+that stops an outsider cutting a real PyPI release; widening it to tell "did not pass" from
+"did not finish" would trade a silent no-op for a security hole. The recoverable case &mdash; a
+release skipped because a runner was slow &mdash; is recovered by the issue telling somebody to
+rerun, which is what the new body does.
+
+<b>Found on the way, and fixed in the same change.</b> An empty GitHub expression written
+inside a <code>run:</code> or <code>script:</code> body makes zizmor emit
+<code>couldn't parse expression</code> from six audits &mdash; template_injection,
+overprovisioned_secrets, unredacted_secrets, obfuscation, secrets_outside_env and
+unsound_ternary. A comment explaining why the script avoids interpolation was enough to cause
+it. Measured three ways: in a YAML <code>#</code> comment it is harmless (zizmor does not read
+those), in a <code>script:</code> body it costs six, and in a <code>run:</code> body it costs
+six even behind a shell <code>#</code>.
+
+<b>An earlier draft of this section said that blinded the audits for the whole file. It does
+not, and the review that asked caught it.</b> Planting a real finding &mdash; a
+<code>head_commit.message</code> interpolated into a <code>run:</code> &mdash; in two copies of
+the file, one clean and one carrying an empty expression, zizmor reported the
+template-injection in <b>both</b>. What is actually lost is the unparseable span itself, which
+no audit inspects, plus six warning lines above a run that still ends in "No findings to
+report". Worth preventing on those terms rather than the dramatic ones: a span that silently
+opts out of SAST is a bad place for a mistake to hide. A parametrised test now walks every
+workflow's parsed run/script bodies.
+
+<b>One more hole the widening opened, and the review found it.</b>
+<code>head_branch == 'main'</code> is not a provenance check. <code>ci.yml</code> runs on
+<code>pull_request</code>, so a fork PR opened from a branch named <code>main</code> produces a
+<code>ci</code> run whose <code>head_branch</code> is <code>main</code> &mdash; and
+<code>cancel-in-progress</code> concludes it <code>cancelled</code> on every superseded push.
+Under the old <code>== 'failure'</code> gate that was rare; under the new one it is routine PR
+iteration, and the issue would have claimed a release was skipped for a run that was never
+release-eligible. <code>publish.yml</code>, <code>sbom.yml</code> and
+<code>mutation-weights-refresh.yml</code> all carry the event+repository pair and this file was
+the only <code>workflow_run</code> consumer without it, so the fix is the house guard on
+<em>both</em> jobs &mdash; the closer needed it just as much, since a <em>green</em> fork PR
+could otherwise close a tracker for a failure still live on main. It is
+<code>event != 'pull_request'</code> rather than <code>== 'push'</code> because three watched
+workflows are themselves <code>workflow_run</code>-triggered.

{boost_skill_cli-1.2.172 → boost_skill_cli-1.2.174}/docs/roadmap/items/shard-weights-do-not-predict-the-job-timeout.md

@@ -2,15 +2,15 @@
 id: shard-weights-do-not-predict-the-job-timeout
 board: code
 section: trust
-status: planned
+status: inflight
 category: CI · Bug
 complexity: M
 impact: High
 wow: 4
 note: the pack is balanced to within 700ms of ideal and a shard still timed out at 75 min, cancelling a release
 order: 364
-owner:
-pr:
+owner: loop/shard-headroom
+pr: 1023
 title: "Mutation shard weights balance perfectly and predict nothing, so a shard can time out and cancel a release"
 ---
 <b>Observed, on the merge of #1015.</b> <code>mutation-shard (4)</code> ran 75 minutes against the
@@ -55,3 +55,40 @@ speedup cap is 6.0x only because <code>store.py</code> is split per function alr
 shards is cheap. Separately, a cancelled <code>ci</code> on main should be loud: it currently
 looks identical to a success from the release path's point of view, because
 <code>publish.yml</code> only asks whether the conclusion was <code>success</code>.
+
+<b>Fixed, and the calibration is measured.</b> Fitted over the Actions job API on 2026-10-01:
+<b>169 successful <code>mutation-shard</code> jobs</b>, of which 26 runs completed all six
+shards. Two numbers come out, and they answer different questions. Per <em>run</em> &mdash; the
+sum over its six shards, which is pack-invariant and so isolates runner speed from packing
+&mdash; observed minutes over committed weight-minutes is min 0.265, <b>median 0.307</b>, max
+0.355: a spread of only <b>1.34x</b>. Per <em>shard</em> against its own median the range is
+1.10x (shard 3) to <b>1.91x</b> (shard 2: median 38.0 min, worst 72.5). <b>So the mean is not
+what fails.</b> A single slow runner inside an otherwise ordinary run is, and a check scored on
+the median would have passed the pack that was cancelled &mdash; its median shard was 37.8
+minutes against a 75-minute cap, half the ceiling.
+
+<b>The 0.307 is not a fudge factor, it is parallelism.</b> Weights are summed per-mutant
+durations &mdash; the work a shard holds laid end to end &mdash; and the runner executes it
+four-way parallel (<code>max_children</code> defaults to <code>os.cpu_count()</code>;
+<code>ubuntu-latest</code> is 4 vCPU). The median inverts to 3.26 effective workers of 4, so what
+is stored is <b>81.4% parallel efficiency</b> and the worker count separately: a runner with more
+vCPUs then moves one constant and contention moves the other, where a single fitted number would
+hide which had happened.
+
+<b>It reproduces the failure it was derived to predict.</b> Six shards at these weights:
+37.8 median minutes &times; 1.91 = a <b>72.3-minute tail</b> against a real worst job of
+<b>72.5</b> &mdash; 96% of the cap. <code>plan --explain --timeout-minutes 75</code> now prints
+that and exits 1. The matrix moved to <b>eight</b>, where the same arithmetic gives 28.4 &times;
+1.91 = <b>54.2 min, 72% of the cap</b>; the largest unit (4,063,161 ms) still fits inside an even
+share (5,543,280 ms), so the speedup cap is a full 8.00x and more shards cost nothing but runner
+slots. <code>tests/unit/test_mutation_shard_count.py</code> pins the shard count across
+<code>ci.yml</code> and <code>mutation-weights-refresh.yml</code> (<code>timeout-minutes</code>
+cannot be read through <code>${{ }}</code>, so agreement is asserted rather than derived), and
+re-runs the headroom check on the committed pack every build &mdash; a pack that would be
+cancelled now fails in the <code>test</code> job in milliseconds.
+
+<b>Not fixed here, and now its own card:</b> a <code>cancelled</code> <code>ci</code> on main is
+still silent. <code>ci-failure-alert</code> gates on
+<code>conclusion == 'failure'</code>, so the run that skipped the release notified nobody either
+&mdash; see <code>cancelled-ci-on-main-is-silent-and-skips-the-release</code>.
+

{boost_skill_cli-1.2.172 → boost_skill_cli-1.2.174}/docs/roadmap.html

@@ -143,7 +143,7 @@
       <div class="stat"><b>27</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>75</b><span>Planned</span></div>
-      <div class="stat"><b>521</b><span>Loop finds</span></div>
+      <div class="stat"><b>522</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -7748,7 +7748,7 @@ the walk and the <code>redirected</code> reporting this card inherits.</p>
       </article>
 
       <article class="cap rcard" id="shard-weights-do-not-predict-the-job-timeout">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">CI · Bug</span></div>
+        <div class="head"><span class="pill inflight">In flight</span><span class="cat">CI · Bug</span></div>
         <h3>Mutation shard weights balance perfectly and predict nothing, so a shard can time out and cancel a release</h3>
         <p><b>Observed, on the merge of #1015.</b> <code>mutation-shard (4)</code> ran 75 minutes against the
 job's <code>timeout-minutes: 75</code> and was cancelled. The aggregate <code>mutation</code> job
@@ -7791,7 +7791,43 @@ give the heaviest shard headroom &mdash; at eight shards the ideal drops by a qu
 speedup cap is 6.0x only because <code>store.py</code> is split per function already, so more
 shards is cheap. Separately, a cancelled <code>ci</code> on main should be loud: it currently
 looks identical to a success from the release path's point of view, because
-<code>publish.yml</code> only asks whether the conclusion was <code>success</code>.</p>
+<code>publish.yml</code> only asks whether the conclusion was <code>success</code>.
+
+<b>Fixed, and the calibration is measured.</b> Fitted over the Actions job API on 2026-10-01:
+<b>169 successful <code>mutation-shard</code> jobs</b>, of which 26 runs completed all six
+shards. Two numbers come out, and they answer different questions. Per <em>run</em> &mdash; the
+sum over its six shards, which is pack-invariant and so isolates runner speed from packing
+&mdash; observed minutes over committed weight-minutes is min 0.265, <b>median 0.307</b>, max
+0.355: a spread of only <b>1.34x</b>. Per <em>shard</em> against its own median the range is
+1.10x (shard 3) to <b>1.91x</b> (shard 2: median 38.0 min, worst 72.5). <b>So the mean is not
+what fails.</b> A single slow runner inside an otherwise ordinary run is, and a check scored on
+the median would have passed the pack that was cancelled &mdash; its median shard was 37.8
+minutes against a 75-minute cap, half the ceiling.
+
+<b>The 0.307 is not a fudge factor, it is parallelism.</b> Weights are summed per-mutant
+durations &mdash; the work a shard holds laid end to end &mdash; and the runner executes it
+four-way parallel (<code>max_children</code> defaults to <code>os.cpu_count()</code>;
+<code>ubuntu-latest</code> is 4 vCPU). The median inverts to 3.26 effective workers of 4, so what
+is stored is <b>81.4% parallel efficiency</b> and the worker count separately: a runner with more
+vCPUs then moves one constant and contention moves the other, where a single fitted number would
+hide which had happened.
+
+<b>It reproduces the failure it was derived to predict.</b> Six shards at these weights:
+37.8 median minutes &times; 1.91 = a <b>72.3-minute tail</b> against a real worst job of
+<b>72.5</b> &mdash; 96% of the cap. <code>plan --explain --timeout-minutes 75</code> now prints
+that and exits 1. The matrix moved to <b>eight</b>, where the same arithmetic gives 28.4 &times;
+1.91 = <b>54.2 min, 72% of the cap</b>; the largest unit (4,063,161 ms) still fits inside an even
+share (5,543,280 ms), so the speedup cap is a full 8.00x and more shards cost nothing but runner
+slots. <code>tests/unit/test_mutation_shard_count.py</code> pins the shard count across
+<code>ci.yml</code> and <code>mutation-weights-refresh.yml</code> (<code>timeout-minutes</code>
+cannot be read through <code>${{ }}</code>, so agreement is asserted rather than derived), and
+re-runs the headroom check on the committed pack every build &mdash; a pack that would be
+cancelled now fails in the <code>test</code> job in milliseconds.
+
+<b>Not fixed here, and now its own card:</b> a <code>cancelled</code> <code>ci</code> on main is
+still silent. <code>ci-failure-alert</code> gates on
+<code>conclusion == 'failure'</code>, so the run that skipped the release notified nobody either
+&mdash; see <code>cancelled-ci-on-main-is-silent-and-skips-the-release</code>.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m hi">Impact <b>High</b></span>
@@ -7799,6 +7835,116 @@ looks identical to a success from the release path's point of view, because
           <span class="m">the pack is balanced to within 700ms of ideal and a shard still timed out at 75 min, cancelling a release</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="cancelled-ci-on-main-is-silent-and-skips-the-release">
+        <div class="head"><span class="pill inflight">In flight</span><span class="cat">CI · Bug</span></div>
+        <h3>A <code>cancelled</code> <code>ci</code> on main skips the release and alerts nobody, because the alert asks only about <code>failure</code></h3>
+        <p><b>Two independent gates, both keyed on the wrong half of the same enum.</b>
+<code>publish.yml</code> fires on <code>workflow_run</code> and ships only when
+<code>conclusion == 'success'</code>; <code>ci-failure-alert</code> opens the tracking issue
+only when <code>conclusion == 'failure'</code>. A <code>ci</code> run that concludes
+<code>cancelled</code> satisfies neither. <b>It does not ship and it does not tell anyone</b>
+&mdash; the one conclusion that falls through both.
+
+<b>Observed, on the merge of #1015.</b> <code>mutation-shard (4)</code> hit
+<code>timeout-minutes: 75</code> and was cancelled, the aggregate <code>mutation</code> job
+failed, and the run concluded <code>cancelled</code> rather than <code>failure</code>. No
+release, no issue, no notification. It surfaced the same day, and only because somebody was
+reading per-shard job durations out of the Actions API for an unrelated reason &mdash; nothing
+in the repo would have raised it, and the next one will be found the same way or not at all.
+
+<b>This is the exact blind spot <code>ci-failure-alert</code>'s own header describes.</b> That
+file opens by explaining that <code>demo</code> "failed six runs out of six on main, alerted
+nobody, and was found by a manual audit instead", and concludes that "any workflow that runs on
+main and nobody watches belongs here". The list was then enforced by
+<code>tests/unit/test_failure_alerting_covers_unattended.py</code> so a new workflow cannot
+quietly join the blind spot. <b>The enforcement is over <em>which workflows</em> are watched,
+and the hole here is <em>which conclusions</em> are</b> &mdash; <code>ci</code> is on the list
+and still said nothing.
+
+<b>Why a timeout is not an exotic case.</b> It is the designed behaviour of every
+<code>timeout-minutes</code> in the repo, and <code>mutation-shard</code>'s is reached by an
+ordinary slow runner rather than by a bug: across 169 measured shard jobs the worst was 72.5
+minutes against a 75-minute cap. A job can also be cancelled by the concurrency group or by a
+human pressing the button &mdash; and only the last of those is one anybody already knows about.
+
+<b>A runner eviction is the neighbouring case, and it concludes differently.</b> An earlier
+draft of this card listed eviction among the routes to <code>cancelled</code>; measured on
+2026-10-02, it is not. <code>mutation-shard (0)</code> on main took
+<code>The runner has received a shutdown signal</code> and exit 143 at mutant 3095 of 28084,
+the job concluded <b>failure</b>, and the alerting fired correctly &mdash; issue #1024 opened
+and auto-closed when a rerun of the failed jobs went green. That is the point of widening on
+the <em>green</em> set rather than enumerating bad conclusions: the two most common ways a
+shard dies land on different sides of an <code>== 'failure'</code> test, and a gate that has
+to know which one it was is a gate that will be wrong again.
+
+<b>Shape of the work.</b> Widen the alert's condition from <code>== 'failure'</code> to the set
+of conclusions that mean "main is not green", which is every one except <code>success</code>,
+<code>skipped</code> and <code>neutral</code> &mdash; naming what is <em>excluded</em> rather
+than what is included, so the next conclusion GitHub adds defaults to loud. The issue body
+should say which conclusion it was, because <em>cancelled</em> and <em>failure</em> want
+different first moves. Then pin it: the sibling test already enforces the workflow list, so the
+conclusion set wants the same treatment rather than a comment. Worth checking at the same time
+whether <code>publish.yml</code> should distinguish "CI did not pass" from "CI did not finish"
+&mdash; today both are a silent no-op, and a release that was skipped because a runner was slow
+is recoverable by a rerun that nobody currently knows to start.
+
+<b>Shipped.</b> The opener now gates on the green set <em>negated</em> &mdash;
+<code>!contains(fromJSON('["success", "skipped", "neutral"]'), conclusion)</code> &mdash; so a
+conclusion GitHub adds later defaults to loud. <code>skipped</code> and <code>neutral</code>
+are in it deliberately: <code>release</code> skips on every run it does not publish from, so
+without that exclusion each non-green <code>ci</code> would open two issues. The closer keeps
+<code>== 'success'</code>, because a <code>cancelled</code> run says nothing about whether the
+tracked failure is fixed and must not stand the issue down. The body now names the conclusion
+and, for <code>ci</code>, says no release was cut and that a rerun is what publishes it.
+
+<b>publish.yml was left alone, deliberately.</b> Its
+<code>conclusion == 'success' &amp;&amp; event == 'push'</code> guard is the fork-PR boundary
+that stops an outsider cutting a real PyPI release; widening it to tell "did not pass" from
+"did not finish" would trade a silent no-op for a security hole. The recoverable case &mdash; a
+release skipped because a runner was slow &mdash; is recovered by the issue telling somebody to
+rerun, which is what the new body does.
+
+<b>Found on the way, and fixed in the same change.</b> An empty GitHub expression written
+inside a <code>run:</code> or <code>script:</code> body makes zizmor emit
+<code>couldn't parse expression</code> from six audits &mdash; template_injection,
+overprovisioned_secrets, unredacted_secrets, obfuscation, secrets_outside_env and
+unsound_ternary. A comment explaining why the script avoids interpolation was enough to cause
+it. Measured three ways: in a YAML <code>#</code> comment it is harmless (zizmor does not read
+those), in a <code>script:</code> body it costs six, and in a <code>run:</code> body it costs
+six even behind a shell <code>#</code>.
+
+<b>An earlier draft of this section said that blinded the audits for the whole file. It does
+not, and the review that asked caught it.</b> Planting a real finding &mdash; a
+<code>head_commit.message</code> interpolated into a <code>run:</code> &mdash; in two copies of
+the file, one clean and one carrying an empty expression, zizmor reported the
+template-injection in <b>both</b>. What is actually lost is the unparseable span itself, which
+no audit inspects, plus six warning lines above a run that still ends in "No findings to
+report". Worth preventing on those terms rather than the dramatic ones: a span that silently
+opts out of SAST is a bad place for a mistake to hide. A parametrised test now walks every
+workflow's parsed run/script bodies.
+
+<b>One more hole the widening opened, and the review found it.</b>
+<code>head_branch == 'main'</code> is not a provenance check. <code>ci.yml</code> runs on
+<code>pull_request</code>, so a fork PR opened from a branch named <code>main</code> produces a
+<code>ci</code> run whose <code>head_branch</code> is <code>main</code> &mdash; and
+<code>cancel-in-progress</code> concludes it <code>cancelled</code> on every superseded push.
+Under the old <code>== 'failure'</code> gate that was rare; under the new one it is routine PR
+iteration, and the issue would have claimed a release was skipped for a run that was never
+release-eligible. <code>publish.yml</code>, <code>sbom.yml</code> and
+<code>mutation-weights-refresh.yml</code> all carry the event+repository pair and this file was
+the only <code>workflow_run</code> consumer without it, so the fix is the house guard on
+<em>both</em> jobs &mdash; the closer needed it just as much, since a <em>green</em> fork PR
+could otherwise close a tracker for a failure still live on main. It is
+<code>event != 'pull_request'</code> rather than <code>== 'push'</code> because three watched
+workflows are themselves <code>workflow_run</code>-triggered.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">the alerting that exists to make a red main impossible to miss asks only about 'failure', and the run that skipped a release was 'cancelled'</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>