boost-skill-cli 1.0.443__tar.gz → 1.0.445__tar.gz

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445}/CLAUDE.md

@@ -150,11 +150,13 @@ line coverage. Target `boost_cli/core` behavior with assertions, not just import
   publish workflow filename must stay `publish.yml` (PyPI Trusted Publisher
   matches on it).
 - **Target Python ≥ 3.12** (`requires-python = ">=3.12"`). Structural pattern
-  matching and runtime `X | Y` unions are now legal. The `typing.List` →
-  `list` sweep is deliberately *not* done yet: ruff's UP006/UP035/UP045 stay in
-  the ignore list until their own PR, because rewriting annotations across ~60
-  modules obliterates blame and conflicts with every branch in flight. Write new
-  code in the modern style; don't bulk-rewrite old code in an unrelated PR.
+  matching and runtime `X | Y` unions are now legal. The `typing.List` → `list`
+  sweep is **done**: UP006/UP035/UP045 are selected, not ignored, and report zero
+  violations. (This entry described the sweep as deferred long after it landed —
+  measure before trusting a "not done yet" note.) `UP031` printf-formatting *is*
+  still ignored, and deliberately: it is an unsafe fix over ~1,000 call sites in
+  `boost_cli` alone. Write new code in the modern style; don't bulk-rewrite old
+  code in an unrelated PR.
 - **Three item kinds, one scanner.** `core/catalog.scan_dir` indexes `skill`
   (SKILL.md), `rule` (.mdc/.cursorrules/.windsurfrules/.clinerules), and
   `workflow` (commands/agents/workflows Markdown). **All three install**, and
@@ -294,7 +296,7 @@ each agent's skills dir, and updating the lock file.
 
 **Search has two engines**, both in `core/`: `rag.py` is the always-on,
 zero-dependency BM25 engine (full-content index, auto-builds on first
-search — this is what the required `eval` gate floors at recall@k ≥ 0.85).
+search — this is what the required `eval` gate floors at recall@k ≥ 0.78).
 `dense.py` is optional dense/vector retrieval behind the `[rag]` extra —
 **no API key required**: `embed.py` tries Voyage, then OpenAI, then a local
 `BAAI/bge-small-en-v1.5` that ships with the extra, so a key is a quality

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445}/Makefile

@@ -73,6 +73,17 @@ lint:
 	  fi; \
 	  PATH="$(CURDIR)/$(VENV)/bin:$$PATH" actionlint; \
 	else echo "actionlint not on PATH — skipping (CI enforces it)"; fi
+	@# zizmor: workflow SAST, and it was MISSING from this recipe entirely while
+	@# CI's lint job ran it — so `make lint` could return 0 on a branch whose
+	@# lint job was already red. That happened: .github/zizmor.yml suppresses
+	@# accepted findings by file:LINE, adding a header comment to
+	@# ci-failure-issue.yml moved its `on:` block from line 12 to 28, and the
+	@# un-anchored `dangerous-triggers` finding went live. Nothing local looked.
+	@# `--offline` because the impostor/ref audits need GitHub API access the
+	@# dev sandbox proxy flakes on; CI runs it online.
+	@if [ -x $(VENV)/bin/zizmor ]; then \
+	  $(VENV)/bin/zizmor --offline .github/workflows/; \
+	else echo "zizmor not in $(VENV) — skipping (CI enforces it)"; fi
 	$(PY) scripts/build_registries.py --check
 	$(PY) scripts/build_roadmap.py --check
 	$(PY) scripts/build_command_reference.py --check

{boost_skill_cli-1.0.443/boost_skill_cli.egg-info → boost_skill_cli-1.0.445}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.443
+Version: 1.0.445
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE
@@ -1161,7 +1161,7 @@ Four layers, all enforced (`make check` runs the full set; CI runs the same thin
 | Layer | What it does | Gate |
 |---|---|---|
 | `make test` | pytest across `tests/unit/` (every core module) and `tests/functional/` (drives all 78 commands in-process against sandboxed homes) | **≥80% line coverage** of `boost_cli` (`fail_under` in pyproject.toml) |
-| `make smoke` | `tests/smoke.sh` — 170 checks run through the actual `./boost` shim (`--online` also hits real registries) | all pass |
+| `make smoke` | `tests/smoke.sh` — 174 checks run through the actual `./boost` shim (`--online` also hits real registries) | all pass |
 | `make mutation` | [mutmut] mutates `boost_cli/core` (~9,900 mutants) and reruns the unit suite against each one | **≥80% killed** (`scripts/mutation_gate.py`) |
 | `make evals` | scores the search ranker on a graded golden set — recall@5/@10, MRR, nDCG@5/@10 | **metric floors + no statistically significant regression** (`scripts/eval_gate.py`) |
 

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445}/README.md

@@ -443,7 +443,7 @@ Four layers, all enforced (`make check` runs the full set; CI runs the same thin
 | Layer | What it does | Gate |
 |---|---|---|
 | `make test` | pytest across `tests/unit/` (every core module) and `tests/functional/` (drives all 78 commands in-process against sandboxed homes) | **≥80% line coverage** of `boost_cli` (`fail_under` in pyproject.toml) |
-| `make smoke` | `tests/smoke.sh` — 170 checks run through the actual `./boost` shim (`--online` also hits real registries) | all pass |
+| `make smoke` | `tests/smoke.sh` — 174 checks run through the actual `./boost` shim (`--online` also hits real registries) | all pass |
 | `make mutation` | [mutmut] mutates `boost_cli/core` (~9,900 mutants) and reruns the unit suite against each one | **≥80% killed** (`scripts/mutation_gate.py`) |
 | `make evals` | scores the search ranker on a graded golden set — recall@5/@10, MRR, nDCG@5/@10 | **metric floors + no statistically significant regression** (`scripts/eval_gate.py`) |
 

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.0.443'
-__version_tuple__ = version_tuple = (1, 0, 443)
+__version__ = version = '1.0.445'
+__version_tuple__ = version_tuple = (1, 0, 445)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445}/boost_cli/core/registry.py

@@ -43,6 +43,20 @@ def parse_spec(spec: str):
     Accepts: owner/repo | full git URL | existing local path.
     """
     spec = spec.strip().rstrip("/")
+    # Reject control characters HERE, at the parse boundary, rather than letting
+    # them travel. A NUL cannot appear in a GitHub owner/repo, a git URL or a
+    # usable directory name, so nothing legitimate is turned away — but accepted,
+    # it reaches a filesystem call and dies as `ValueError: lstat: embedded null
+    # character in path` from inside posixpath, naming neither the tap nor the
+    # command, and as a ValueError rather than a BoostError the CLI's error
+    # handling never gets to frame it. fuzz.yml found this and failed three
+    # scheduled runs out of three before anyone looked (2026-07-25/08-01/08-08).
+    # \x1b matters for a second reason: an escape sequence in a name is echoed
+    # by every surface that prints a tap list.
+    if any(ord(c) < 0x20 or ord(c) == 0x7F for c in spec):
+        raise BoostError(
+            "tap spec contains a control character: %r" % spec,
+            hint="use owner/repo, a git URL, or a local directory")
     # paths.expand(), not Path.expanduser(): expanduser() consults the OS's
     # own home-dir lookup (USERPROFILE on Windows), which ignores the $HOME
     # override the whole test suite (and BOOST_HOME sandboxing) relies on.

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445/boost_skill_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.443
+Version: 1.0.445
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE
@@ -1161,7 +1161,7 @@ Four layers, all enforced (`make check` runs the full set; CI runs the same thin
 | Layer | What it does | Gate |
 |---|---|---|
 | `make test` | pytest across `tests/unit/` (every core module) and `tests/functional/` (drives all 78 commands in-process against sandboxed homes) | **≥80% line coverage** of `boost_cli` (`fail_under` in pyproject.toml) |
-| `make smoke` | `tests/smoke.sh` — 170 checks run through the actual `./boost` shim (`--online` also hits real registries) | all pass |
+| `make smoke` | `tests/smoke.sh` — 174 checks run through the actual `./boost` shim (`--online` also hits real registries) | all pass |
 | `make mutation` | [mutmut] mutates `boost_cli/core` (~9,900 mutants) and reruns the unit suite against each one | **≥80% killed** (`scripts/mutation_gate.py`) |
 | `make evals` | scores the search ranker on a graded golden set — recall@5/@10, MRR, nDCG@5/@10 | **metric floors + no statistically significant regression** (`scripts/eval_gate.py`) |
 

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445}/boost_skill_cli.egg-info/SOURCES.txt

@@ -404,6 +404,7 @@ docs/roadmap/items/typosquat-and-name-confusion-detection.md
 docs/roadmap/items/unify-tilde-two-copies-have-a-boundary-bug.md
 docs/roadmap/items/uninstall-has-no-confirmation-prompt.md
 docs/roadmap/items/untrack-generated-build-noise.md
+docs/roadmap/items/unwatched-crons-hid-a-real-fuzz-crash.md
 docs/roadmap/items/update-advertises-a-flag-it-rejects.md
 docs/roadmap/items/update-diff-before-apply.md
 docs/roadmap/items/update-refreshed-rules-without-a-gate.md
@@ -418,6 +419,7 @@ docs/roadmap/items/workflow-linting-actionlint.md
 docs/roadmap/items/workflow-sast-zizmor.md
 docs/roadmap/items/workspace-scope-install.md
 docs/roadmap/items/zip-strict-audit.md
+docs/roadmap/items/zizmor-ignores-drift-and-make-lint-never-ran-it.md
 docs/roadmap/items/zizmor-pin-is-a-yanked-release.md
 evals/README.md
 evals/__init__.py
@@ -597,6 +599,7 @@ tests/unit/test_eval_gate.py
 tests/unit/test_eval_grading.py
 tests/unit/test_eval_metrics.py
 tests/unit/test_eval_stats_summary.py
+tests/unit/test_failure_alerting_covers_unattended.py
 tests/unit/test_faithfulness.py
 tests/unit/test_frontmatter.py
 tests/unit/test_fuzz_targets.py
@@ -647,6 +650,7 @@ tests/unit/test_rag_fusion.py
 tests/unit/test_registries_fresh.py
 tests/unit/test_registry.py
 tests/unit/test_registry_categories.py
+tests/unit/test_registry_control_chars.py
 tests/unit/test_release_guard.py
 tests/unit/test_release_preflight.py
 tests/unit/test_required_checks.py
@@ -659,6 +663,7 @@ tests/unit/test_secretscan.py
 tests/unit/test_selfupdate.py
 tests/unit/test_serve.py
 tests/unit/test_serve_docs.py
+tests/unit/test_smoke_covers_every_command.py
 tests/unit/test_spin.py
 tests/unit/test_stackprobe.py
 tests/unit/test_staleness.py
@@ -675,6 +680,7 @@ tests/unit/test_workflow_concurrency_groups.py
 tests/unit/test_workflow_push_has_credentials.py
 tests/unit/test_workflow_timeouts.py
 tests/unit/test_workflows.py
+tests/unit/test_zizmor_ignores_still_anchor.py
 tests/visual/a11y_check.mjs
 tests/visual/console_check.mjs
 tests/visual/package-lock.json

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445}/docs/index.html

@@ -570,7 +570,7 @@
     <div class="stats">
       <div class="stat reveal"><b>70,000+</b><span>Discoverable assets</span></div>
       <div class="stat reveal"><b>78</b><span>Commands · 8 groups</span></div>
-      <div class="stat reveal"><b>5</b><span>Pre-tapped registries</span></div>
+      <div class="stat reveal"><b>7</b><span>Pre-tapped registries</span></div>
       <div class="stat reveal"><b>4</b><span>AI agents supported</span></div>
     </div>
 
@@ -648,7 +648,7 @@ facilitate structured divergent thinking:
           <div class="node src">
             <span class="tag">Source</span>
             <h3>GitHub registries</h3>
-            <p>5 pre-tapped registries + a 10,000-skill discovery index</p>
+            <p>7 pre-tapped registries + a 10,000-skill discovery index</p>
           </div>
         </div>
         <div class="flow-arrow reveal">

boost_skill_cli-1.0.445/docs/roadmap/items/unwatched-crons-hid-a-real-fuzz-crash.md

@@ -0,0 +1,73 @@
+---
+id: unwatched-crons-hid-a-real-fuzz-crash
+board: code
+section: pipeline
+status: shipped
+category: Build · Bug
+complexity: M
+impact: High
+wow: 5
+note: the fuzzer found a real crash and was right for three weeks — 24 unattended workflows, 2 watched
+order: 108
+owner: fix/parse-spec-control-chars
+pr:
+title: The fuzzer found a real crash and nobody was listening
+---
+<code>fuzz.yml</code> runs libFuzzer over <code>registry.parse_spec</code> weekly. It has failed
+<b>three scheduled runs out of three</b> — 2026-07-25, 08-01 and 08-08 — writing the same minimised
+reproducer each time. It was right every time, and nobody looked for three weeks.
+
+<b>The crash.</b> Ten bytes, <code>/\0\0\0\0\0\0\0\0A</code>. <code>parse_spec</code> accepted them
+and returned a perfectly well-formed pair:
+
+<code>('/\0…A', 'https://github.com//\0…A')</code>
+
+Nothing raised, so the name travelled — into <code>config.json</code> and through
+<code>Tap.safe_name</code> into a clone path built around a NUL byte.
+
+<b>The diagnosis was re-done twice, and both corrections matter.</b> An automated audit first
+reported this as "an uncaught-exception bug in <code>boost tap</code>". Running the payload showed
+<code>parse_spec</code> returning normally, and the real traceback — from the job log — lands on
+<code>tests/fuzz/fuzz_registry.py:85</code>, where the harness's own containment check calls
+<code>os.path.realpath</code>. An adversarial re-check then killed the rest of the product claim, and
+it is worth stating plainly because the first draft of this card got it wrong:
+
+<b>A NUL can never reach the CLI at all.</b> <code>execve</code> refuses an argument containing one
+(<code>ValueError: embedded null byte</code>), so <code>boost tap $'/\0…A'</code> is not a command
+that can be run. And in-process the product does <i>not</i> crash either:
+<code>pathlib</code> swallows the error, so <code>Tap.path.exists()</code> simply returns
+<code>False</code>. Only <code>os.path.realpath</code> raises — and the sole caller of that is the
+fuzz harness.
+
+So the honest case for the fix is not "the CLI crashes". It is three narrower things.
+<b>First</b>, other control characters are <i>not</i> execve-blocked — <code>\x1b</code> survives
+<code>argv</code> intact, so an escape sequence in a tap name reaches the CLI and is echoed by every
+surface that prints a tap list. <b>Second</b>, a NUL-bearing name yields a path whose
+<code>exists()</code> is permanently <code>False</code> — silently wrong beats loudly broken only
+until someone has to debug it. <b>Third</b>, and largest: the harness died on its <b>1,322nd</b>
+unit, so the run recorded <code>new_units_added: 0</code> and
+<code>average_exec_per_sec: 0</code> — <b>the registry parser has had no fuzz coverage at all since
+the workflow was added on 2026-07-24</b>, while still costing a runner slot every Saturday.
+
+<b>Fixed at the parse boundary.</b> A control character cannot appear in a GitHub
+<code>owner/repo</code>, in a git URL, or in a usable directory name, so rejecting them turns nothing
+legitimate away — and it converts an arbitrary later <code>ValueError</code> into the documented
+<code>BoostError</code> rejection path, which the fuzz harness already handles and the CLI already
+renders with a hint. <code>\x1b</code> matters for a second reason: an escape sequence in a name is
+echoed back by every surface that prints a tap list. Verified by running the real harness over the
+exact reproducer, which now passes.
+
+<b>The reason it stayed hidden is the more valuable half.</b>
+<code>ci-failure-issue.yml</code> opens a tracking issue when a watched workflow fails on
+<code>main</code>, and its own header states the rule: <i>"Any workflow that runs on main and nobody
+watches belongs here."</i> It watched <b>two</b>. <b>Twenty-four</b> ran unattended — fourteen on a
+cron. The rule was written down and not applied, which is the most expensive kind of convention,
+and it is the same blind spot that let <code>shards</code> fail both its scheduled runs and publish
+zero artifacts.
+
+All twenty-six are watched now, and the list is <b>enforced rather than curated</b>:
+<code>tests/unit/test_failure_alerting_covers_unattended.py</code> fails the build when a workflow
+runs unattended and is neither watched nor listed in an <code>EXPECTED_UNWATCHED</code> map with a
+reason. A new scheduled workflow therefore cannot quietly join the blind spot — the same shape as
+the action-pin lockstep guard, where the convention stays falsifiable instead of decaying the moment
+the person who wrote it stops looking.

boost_skill_cli-1.0.445/docs/roadmap/items/zizmor-ignores-drift-and-make-lint-never-ran-it.md

@@ -0,0 +1,54 @@
+---
+id: zizmor-ignores-drift-and-make-lint-never-ran-it
+board: code
+section: pipeline
+status: shipped
+category: Build · Bug
+complexity: S
+impact: Med
+wow: 4
+note: a comment four lines long un-silenced a reviewed finding, and no local gate could see it
+order: 110
+owner: fix/parse-spec-control-chars
+pr:
+title: A line-anchored suppression drifted, and make lint never ran the tool
+---
+<code>.github/zizmor.yml</code> silences accepted workflow-SAST findings by
+<b><code>file:LINE</code></b>. That anchor is fragile in a specific way: insert anything above the
+construct and the ignore stops applying — or, worse, starts applying to a <i>different</i> construct
+nobody reviewed.
+
+It drifted here. Adding a header comment to <code>ci-failure-issue.yml</code> (explaining the
+alerting-coverage fix) moved its <code>on:</code> block from <b>line 12 to line 28</b>, and CI's
+<code>lint</code> job went red on <code>dangerous-triggers</code> — for a <code>workflow_run</code>
+trigger that had been reviewed and accepted months earlier, with the reasoning written out in the
+config right above the anchor.
+
+<b>The config predicted it.</b> Its own note reads: <i>"these ignores are keyed by file:LINE, so
+editing anything above a workflow's <code>on:</code> block moves it and silently un-ignores the
+finding."</i> A warning in a comment is not a control — it depends on the next person reading the
+file they are not editing.
+
+<b>The second half is why nothing local caught it.</b> <code>make lint</code> <b>never ran
+zizmor</b>. The recipe runs ruff, mypy, pyright, import-linter, vulture, xenon, interrogate, refurb,
+codespell and actionlint — and CI's <code>lint</code> job additionally runs zizmor, which the
+Makefile did not. So <code>make lint</code> could return <b>0</b> on a branch whose <code>lint</code>
+job was already red, which is exactly what happened: the gate was run, it passed, and it had not
+looked. (<code>CLAUDE.md</code> and an operator note both listed zizmor among the tools
+<code>make lint</code> runs. Neither was true.)
+
+Both halves are closed. zizmor now runs in <code>make lint</code>, guarded the same way actionlint
+is — present, or an explicit "skipping (CI enforces it)" rather than silence — and
+<code>--offline</code>, because the impostor and ref audits need GitHub API access the dev sandbox's
+proxy flakes on.
+
+And <code>tests/unit/test_zizmor_ignores_still_anchor.py</code> checks the cheap mechanical property
+the line numbers depend on: every <code>dangerous-triggers</code> anchor still lands on an
+<code>on:</code> line, no anchor points past the end of its file, no ignore names a workflow that no
+longer exists, and no anchor is duplicated. It does not re-run zizmor — CI owns that — it asserts
+that the anchors still mean what they say.
+
+<b>Both fixes were verified by re-breaking the tree.</b> With the anchor put back to
+<code>:12</code>, the new test goes red naming the drift, and <code>make lint</code> exits
+<b>2</b> — the failure that previously only appeared in CI, now reproducible in one command before
+the push.

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445}/docs/roadmap.html

@@ -133,7 +133,7 @@
       <div class="stat"><b>16</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>7</b><span>Planned</span></div>
-      <div class="stat"><b>240</b><span>Loop finds</span></div>
+      <div class="stat"><b>242</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -6112,6 +6112,76 @@ vacuously if the trigger detection silently stops matching.</p></details>
         </div>
       </article>
 
+      <article class="cap rcard" id="unwatched-crons-hid-a-real-fuzz-crash">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Build · Bug</span></div>
+        <h3>The fuzzer found a real crash and nobody was listening</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><code>fuzz.yml</code> runs libFuzzer over <code>registry.parse_spec</code> weekly. It has failed
+<b>three scheduled runs out of three</b> — 2026-07-25, 08-01 and 08-08 — writing the same minimised
+reproducer each time. It was right every time, and nobody looked for three weeks.
+
+<b>The crash.</b> Ten bytes, <code>/\0\0\0\0\0\0\0\0A</code>. <code>parse_spec</code> accepted them
+and returned a perfectly well-formed pair:
+
+<code>('/\0…A', 'https://github.com//\0…A')</code>
+
+Nothing raised, so the name travelled — into <code>config.json</code> and through
+<code>Tap.safe_name</code> into a clone path built around a NUL byte.
+
+<b>The diagnosis was re-done twice, and both corrections matter.</b> An automated audit first
+reported this as "an uncaught-exception bug in <code>boost tap</code>". Running the payload showed
+<code>parse_spec</code> returning normally, and the real traceback — from the job log — lands on
+<code>tests/fuzz/fuzz_registry.py:85</code>, where the harness's own containment check calls
+<code>os.path.realpath</code>. An adversarial re-check then killed the rest of the product claim, and
+it is worth stating plainly because the first draft of this card got it wrong:
+
+<b>A NUL can never reach the CLI at all.</b> <code>execve</code> refuses an argument containing one
+(<code>ValueError: embedded null byte</code>), so <code>boost tap $'/\0…A'</code> is not a command
+that can be run. And in-process the product does <i>not</i> crash either:
+<code>pathlib</code> swallows the error, so <code>Tap.path.exists()</code> simply returns
+<code>False</code>. Only <code>os.path.realpath</code> raises — and the sole caller of that is the
+fuzz harness.
+
+So the honest case for the fix is not "the CLI crashes". It is three narrower things.
+<b>First</b>, other control characters are <i>not</i> execve-blocked — <code>\x1b</code> survives
+<code>argv</code> intact, so an escape sequence in a tap name reaches the CLI and is echoed by every
+surface that prints a tap list. <b>Second</b>, a NUL-bearing name yields a path whose
+<code>exists()</code> is permanently <code>False</code> — silently wrong beats loudly broken only
+until someone has to debug it. <b>Third</b>, and largest: the harness died on its <b>1,322nd</b>
+unit, so the run recorded <code>new_units_added: 0</code> and
+<code>average_exec_per_sec: 0</code> — <b>the registry parser has had no fuzz coverage at all since
+the workflow was added on 2026-07-24</b>, while still costing a runner slot every Saturday.
+
+<b>Fixed at the parse boundary.</b> A control character cannot appear in a GitHub
+<code>owner/repo</code>, in a git URL, or in a usable directory name, so rejecting them turns nothing
+legitimate away — and it converts an arbitrary later <code>ValueError</code> into the documented
+<code>BoostError</code> rejection path, which the fuzz harness already handles and the CLI already
+renders with a hint. <code>\x1b</code> matters for a second reason: an escape sequence in a name is
+echoed back by every surface that prints a tap list. Verified by running the real harness over the
+exact reproducer, which now passes.
+
+<b>The reason it stayed hidden is the more valuable half.</b>
+<code>ci-failure-issue.yml</code> opens a tracking issue when a watched workflow fails on
+<code>main</code>, and its own header states the rule: <i>"Any workflow that runs on main and nobody
+watches belongs here."</i> It watched <b>two</b>. <b>Twenty-four</b> ran unattended — fourteen on a
+cron. The rule was written down and not applied, which is the most expensive kind of convention,
+and it is the same blind spot that let <code>shards</code> fail both its scheduled runs and publish
+zero artifacts.
+
+All twenty-six are watched now, and the list is <b>enforced rather than curated</b>:
+<code>tests/unit/test_failure_alerting_covers_unattended.py</code> fails the build when a workflow
+runs unattended and is neither watched nor listed in an <code>EXPECTED_UNWATCHED</code> map with a
+reason. A new scheduled workflow therefore cannot quietly join the blind spot — the same shape as
+the action-pin lockstep guard, where the convention stays falsifiable instead of decaying the moment
+the person who wrote it stops looking.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★★★</b></span>
+          <span class="m">the fuzzer found a real crash and was right for three weeks — 24 unattended workflows, 2 watched</span>
+        </div>
+      </article>
+
       <article class="cap rcard" id="eval-stats-could-never-publish">
         <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Build · Bug</span></div>
         <h3>The published metrics could never be published</h3>
@@ -6153,6 +6223,57 @@ verified: green on the fix, and red again when the bare push is restored.</p></d
           <span class="m">the published-metrics file has ONE commit in its whole history — the one that created it</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="zizmor-ignores-drift-and-make-lint-never-ran-it">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Build · Bug</span></div>
+        <h3>A line-anchored suppression drifted, and make lint never ran the tool</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><code>.github/zizmor.yml</code> silences accepted workflow-SAST findings by
+<b><code>file:LINE</code></b>. That anchor is fragile in a specific way: insert anything above the
+construct and the ignore stops applying — or, worse, starts applying to a <i>different</i> construct
+nobody reviewed.
+
+It drifted here. Adding a header comment to <code>ci-failure-issue.yml</code> (explaining the
+alerting-coverage fix) moved its <code>on:</code> block from <b>line 12 to line 28</b>, and CI's
+<code>lint</code> job went red on <code>dangerous-triggers</code> — for a <code>workflow_run</code>
+trigger that had been reviewed and accepted months earlier, with the reasoning written out in the
+config right above the anchor.
+
+<b>The config predicted it.</b> Its own note reads: <i>"these ignores are keyed by file:LINE, so
+editing anything above a workflow's <code>on:</code> block moves it and silently un-ignores the
+finding."</i> A warning in a comment is not a control — it depends on the next person reading the
+file they are not editing.
+
+<b>The second half is why nothing local caught it.</b> <code>make lint</code> <b>never ran
+zizmor</b>. The recipe runs ruff, mypy, pyright, import-linter, vulture, xenon, interrogate, refurb,
+codespell and actionlint — and CI's <code>lint</code> job additionally runs zizmor, which the
+Makefile did not. So <code>make lint</code> could return <b>0</b> on a branch whose <code>lint</code>
+job was already red, which is exactly what happened: the gate was run, it passed, and it had not
+looked. (<code>CLAUDE.md</code> and an operator note both listed zizmor among the tools
+<code>make lint</code> runs. Neither was true.)
+
+Both halves are closed. zizmor now runs in <code>make lint</code>, guarded the same way actionlint
+is — present, or an explicit "skipping (CI enforces it)" rather than silence — and
+<code>--offline</code>, because the impostor and ref audits need GitHub API access the dev sandbox's
+proxy flakes on.
+
+And <code>tests/unit/test_zizmor_ignores_still_anchor.py</code> checks the cheap mechanical property
+the line numbers depend on: every <code>dangerous-triggers</code> anchor still lands on an
+<code>on:</code> line, no anchor points past the end of its file, no ignore names a workflow that no
+longer exists, and no anchor is duplicated. It does not re-run zizmor — CI owns that — it asserts
+that the anchors still mean what they say.
+
+<b>Both fixes were verified by re-breaking the tree.</b> With the anchor put back to
+<code>:12</code>, the new test goes red naming the drift, and <code>make lint</code> exits
+<b>2</b> — the failure that previously only appeared in CI, now reproducible in one command before
+the push.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">a comment four lines long un-silenced a reviewed finding, and no local gate could see it</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445}/pyproject.toml

@@ -176,7 +176,11 @@ ignore = [
     # batch. Hoisting the handler out of the loop would trade that resilience
     # for a negligible per-iteration saving.
     "PERF203",  # try-except-in-loop
-    # printf-formatting is this codebase's house style across ~860 call sites.
+    # printf-formatting is this codebase's house style. Measured with
+    # `ruff check --select UP031 --statistics`: 1,005 call sites in boost_cli,
+    # 1,800 across the whole lint scope. (The figure here read "~860" for a
+    # long time — a rationale whose central number has drifted is a rationale
+    # nobody re-checked, so it is stated with the command that reproduces it.)
     # The rewrite is an unsafe fix (`%` and `format` differ on tuples and on
     # types with a custom `__format__`), it would rewrite nearly every file —
     # obliterating blame and conflicting with every branch in flight — and it

{boost_skill_cli-1.0.443 → boost_skill_cli-1.0.445}/tests/smoke.sh

@@ -239,6 +239,11 @@ protocol
 pulse
 replay
 who
+bmad
+chat
+hooks
+run
+trust
 CMDS
 
 if [ "${1:-}" = "--online" ]; then

boost_skill_cli-1.0.445/tests/unit/test_failure_alerting_covers_unattended.py

@@ -0,0 +1,132 @@
+"""Unit tests: every unattended workflow is watched by the failure alerting.
+
+``ci-failure-issue.yml`` opens a tracking issue when a watched workflow fails on
+``main``. Its own header states the rule::
+
+    Any workflow that runs on main and nobody watches belongs here.
+
+It watched two: ``ci`` and ``demo``. Twenty-four run unattended — fourteen on a
+cron, ten on a push to ``main`` — so the rule was written down and not applied,
+which is the most expensive kind of convention.
+
+Two outages measured this session are exactly what that gap costs:
+
+* ``fuzz`` failed **three scheduled runs out of three** (2026-07-25, 08-01,
+  08-08), writing the same libFuzzer reproducer each time. It had found a real
+  defect in ``registry.parse_spec`` and been ignored for three weeks.
+* ``shards`` failed **both** of its scheduled runs and published zero artifacts,
+  which is how a feature reached a state where it had never once worked.
+
+Neither produced a notification, a red badge anyone looks at, or a comment on a
+pull request. A cron job's failure is a red square on a page nobody opens.
+
+The list is enforced rather than curated: a new scheduled workflow fails this
+test until it is either watched or added to ``EXPECTED_UNWATCHED`` with a
+reason. That is the same shape as ``test_action_pin_lockstep``'s parametrised
+family check — the convention stays falsifiable instead of decaying the moment
+the person who wrote it stops looking.
+"""
+from __future__ import annotations
+
+import re
+from pathlib import Path
+
+import pytest
+
+WORKFLOWS = Path(__file__).resolve().parents[2] / ".github" / "workflows"
+ALERT = WORKFLOWS / "ci-failure-issue.yml"
+
+pytestmark = pytest.mark.skipif(
+    not ALERT.exists(),
+    reason=".github/workflows not reachable (e.g. mutation sandbox)")
+
+#: Unattended workflows deliberately NOT watched, each with its reason.
+#: Empty today. An entry here is a claim that a failure is expected noise
+#: rather than news, and it should be rare enough to argue about.
+EXPECTED_UNWATCHED: dict[str, str] = {}
+
+
+def workflow_name(text: str, fallback: str) -> str:
+    """The workflow's `name:`, which is what `workflow_run` matches on."""
+    m = re.search(r"^name:\s*(.+)$", text, re.M)
+    return m.group(1).strip().strip("\"'") if m else fallback
+
+
+def runs_unattended(text: str) -> bool:
+    """True for a workflow that runs with nobody waiting on the result.
+
+    A cron run has no author watching by construction. A push to ``main`` runs
+    after the pull request's checks are already green and merged, so its failure
+    surfaces only on a commit list — which is how ``demo`` failed six runs out
+    of six before a manual audit found it.
+    """
+    return bool(re.search(r"^\s*schedule:", text, re.M)
+                or re.search(r"^\s*push:", text, re.M))
+
+
+def watched() -> set[str]:
+    """The workflow names ci-failure-issue.yml subscribes to."""
+    m = re.search(r"workflows:\s*\[([^\]]*)\]", ALERT.read_text(encoding="utf-8"))
+    assert m, "could not find the workflows: list in ci-failure-issue.yml"
+    return {w.strip().strip("\"'") for w in m.group(1).split(",") if w.strip()}
+
+
+def unattended() -> dict[str, str]:
+    """``{workflow name: file name}`` for every unattended workflow."""
+    out = {}
+    for path in sorted(WORKFLOWS.glob("*.yml")):
+        text = path.read_text(encoding="utf-8")
+        name = workflow_name(text, path.stem)
+        # The alerting workflow itself is triggered by workflow_run, never by a
+        # schedule or a push, and watching itself would be a loop.
+        if name == "ci-failure-alert":
+            continue
+        if runs_unattended(text):
+            out[name] = path.name
+    return out
+
+
+class TestTheGuardCanActuallySee:
+    """Every assertion below is vacuous if the parsing silently breaks."""
+
+    def test_the_watch_list_is_found_and_non_empty(self):
+        assert watched(), "parsed an empty watch list"
+
+    def test_unattended_workflows_are_found(self):
+        assert len(unattended()) > 5, unattended()
+
+    def test_the_two_original_watchers_are_still_there(self):
+        # `demo` is in the list because it failed six of six runs unnoticed.
+        # Losing either entry would be a silent regression of that fix.
+        assert {"ci", "demo"} <= watched()
+
+    def test_a_known_cron_workflow_is_classified_as_unattended(self):
+        assert "fuzz" in unattended(), unattended()
+
+
+class TestEveryUnattendedWorkflowIsWatched:
+    @pytest.mark.parametrize("name", sorted(unattended()))
+    def test_it_is_watched_or_documented(self, name):
+        if name in EXPECTED_UNWATCHED:
+            assert EXPECTED_UNWATCHED[name].strip(), \
+                "%s is excluded without a reason" % name
+            return
+        assert name in watched(), (
+            "%s (%s) runs unattended on main but nothing alerts when it fails "
+            "— fuzz was red for three scheduled runs and shards for two, both "
+            "unnoticed. Add it to ci-failure-issue.yml's `workflows:` list, or "
+            "to EXPECTED_UNWATCHED with a reason."
+            % (name, unattended()[name]))
+
+    def test_the_exclusion_list_has_no_stale_entries(self):
+        # An entry for a workflow that no longer runs unattended is a licence
+        # nobody re-examined.
+        stale = sorted(set(EXPECTED_UNWATCHED) - set(unattended()))
+        assert not stale, stale
+
+    def test_nothing_watched_has_disappeared(self):
+        # A watch entry naming a workflow that no longer exists silently
+        # watches nothing, and reads as coverage.
+        names = {workflow_name(p.read_text(encoding="utf-8"), p.stem)
+                 for p in WORKFLOWS.glob("*.yml")}
+        assert watched() <= names, sorted(watched() - names)