boost-skill-cli 1.0.283__tar.gz → 1.0.285__tar.gz

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.285}/CLAUDE.md

@@ -11,7 +11,7 @@ make venv                                      # .venv from the hash-pinned requ
 .venv/bin/pytest tests/unit/test_catalog.py -q                    # one test file
 .venv/bin/pytest tests/unit/test_catalog.py::test_scan_dir -q     # one test
 .venv/bin/pytest tests/functional -q -k install                   # functional tests matching "install"
-make lint                                      # the whole static tier — see the recipe, it is 18 commands
+make lint                                      # the whole static tier — read the recipe, it is long
 make test                                      # unit + functional with 80% coverage gate
 make check                                     # the full required gate — see table below
 

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.285}/Makefile

@@ -61,7 +61,17 @@ lint:
 	$(VENV)/bin/interrogate boost_cli/core
 	$(VENV)/bin/refurb boost_cli
 	$(VENV)/bin/codespell boost_cli docs README.md
-	@if command -v actionlint >/dev/null 2>&1; then actionlint; \
+	@# actionlint does not lint `run:` blocks itself — it shells out to
+	@# shellcheck, and if shellcheck is not on PATH it skips them silently and
+	@# still exits 0. So `make lint` could report a clean workflow lint having
+	@# never looked inside a single script. shellcheck is pinned in
+	@# requirements/lint-tools.in for exactly this; put $(VENV)/bin on PATH so
+	@# actionlint finds it, and fail loudly rather than run a hollow check.
+	@if command -v actionlint >/dev/null 2>&1; then \
+	  if [ ! -x $(VENV)/bin/shellcheck ]; then \
+	    echo "shellcheck missing from $(VENV) — actionlint would skip every run: block. Re-run 'make venv'."; exit 1; \
+	  fi; \
+	  PATH="$(CURDIR)/$(VENV)/bin:$$PATH" actionlint; \
 	else echo "actionlint not on PATH — skipping (CI enforces it)"; fi
 	$(PY) scripts/build_registries.py --check
 	$(PY) scripts/build_roadmap.py --check

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.285}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.283
+Version: 1.0.285
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.285}/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.283'
-__version_tuple__ = version_tuple = (1, 0, 283)
+__version__ = version = '1.0.285'
+__version_tuple__ = version_tuple = (1, 0, 285)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.285}/boost_skill_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.283
+Version: 1.0.285
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.285}/boost_skill_cli.egg-info/SOURCES.txt

@@ -155,6 +155,7 @@ docs/roadmap/items/BOOST-D24.md
 docs/roadmap/items/BOOST-D25.md
 docs/roadmap/items/BOOST-D26.md
 docs/roadmap/items/accessibility-audit-pa11y-ci-axe-core.md
+docs/roadmap/items/actionlint-skips-shellcheck-silently.md
 docs/roadmap/items/adapter-conformance-langgraph-leg-never-ran.md
 docs/roadmap/items/ai-bridge-silent-failure-logging.md
 docs/roadmap/items/ambiguous-tap-short-name-resolution.md
@@ -288,6 +289,7 @@ docs/roadmap/items/rule-install-native-materialization.md
 docs/roadmap/items/runner-egress-monitoring-stepsecurity-harden-run.md
 docs/roadmap/items/runtime-explain-faithfulness-guardrail.md
 docs/roadmap/items/sbom-aware-scanning-osv-scanner.md
+docs/roadmap/items/sbom-declares-the-wrong-version.md
 docs/roadmap/items/sbom-on-every-release-cyclonedx-syft.md
 docs/roadmap/items/sbom-release-event-never-fires.md
 docs/roadmap/items/scan-and-sync-rules-and-workflows.md

boost_skill_cli-1.0.285/docs/roadmap/items/actionlint-skips-shellcheck-silently.md

@@ -0,0 +1,58 @@
+---
+id: actionlint-skips-shellcheck-silently
+board: code
+section: dx
+status: shipped
+category: Testing · Bug
+complexity: S
+impact: Med
+wow: 4
+note: fixed — shellcheck is pinned in lint-tools and both gates now assert it is there
+order: 69
+owner: loop/lint-shellcheck
+pr:
+title: The second silent skip &mdash; <code>actionlint</code> runs, and checks no <code>run:</code> block at all
+---
+<code>make-lint-masks-actionlint-failures</code> fixed the layer everyone can see: <code>make
+lint</code> discarded actionlint's exit status. There is a second layer underneath it, and the
+first fix does not reach it. <b><code>actionlint</code> does not lint <code>run:</code> blocks
+itself.</b> It shells out to <code>shellcheck</code>, and when shellcheck is not on
+<code>PATH</code> it skips every one of them &mdash; no warning, no note, exit 0.
+
+Same workflow file, same actionlint binary, only <code>PATH</code> differs:
+
+<code>without shellcheck -&gt; (no output) exit=0</code><br>
+<code>with shellcheck    -&gt; bad.yml:8:9: shellcheck reported issue in this script: SC2001 &hellip; exit=1</code>
+
+So the honest description of the gate before this change was: <code>make lint</code> ran a workflow
+linter that silently declined to look inside any script, and reported success. That is not
+hypothetical either &mdash; it is exactly how an <code>SC2001</code> reached CI from a green local
+gate, in the very change that fixed layer one.
+
+<b>CI was not safe, only lucky.</b> Its actionlint step carried the comment "shellcheck is
+preinstalled on the runner, so run: blocks are checked too" &mdash; true today, and an unpinned,
+unversioned, silently revocable dependency on somebody else's base image. If GitHub ever drops it
+from <code>ubuntu-latest</code>, CI degrades to the same hollow check with no signal that anything
+changed. For a repository that hash-pins its entire lint toolchain precisely so an upstream release
+cannot move a gate underneath it, an implicit dependency on a runner image is the same bug in a
+different coat.
+
+<b>Shipped.</b> <code>shellcheck-py==0.11.0.1</code> is declared in
+<code>requirements/lint-tools.in</code> and hash-pinned into the generated
+<code>lint-tools.txt</code> like every other tool, which puts it on both sides: CI installs it from
+that lock, and <code>make venv</code> puts it in <code>.venv/bin</code>. <code>make lint</code> now
+prepends <code>.venv/bin</code> to <code>PATH</code> so actionlint can find it, and <b>fails</b> if
+it is missing rather than running a check it knows is hollow; CI asserts <code>command -v
+shellcheck</code> before invoking actionlint. Verified in four states against the real recipe: the
+tool absent (skip message, exit 0), shellcheck missing from the venv (exit 1 with a message naming
+the fix), both present and workflows clean (exit 0), and both present with an <code>SC2001</code> in
+a <code>run:</code> block (exit 1 &mdash; the case that used to pass). The old recipe on that same
+file exits 0.
+
+<b>What is deliberately still skipped.</b> If <code>actionlint</code> itself is absent,
+<code>make lint</code> prints a message and continues. Closing that would mean pinning
+<code>actionlint-py</code>, which is sdist-only and fetches the binary from the network at install
+time, and which tracks a different actionlint version than the URL-pinned one CI uses. Trading a
+pinned binary for a build-time download is a worse trade than the skip, so the skip stays and is
+documented rather than quietly tolerated. The wider gap named by the earlier card is also still
+open: <code>zizmor</code> and <code>gitleaks</code> run only in CI and have no Makefile equivalent.

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.285}/docs/roadmap/items/one-commit-can-cut-two-releases.md

@@ -48,5 +48,9 @@ ci will trigger its own release, but it means some merges never get their own ve
 
 <b>Already mitigated:</b> <code>sbom.yml</code> now builds and attaches an SBOM for <em>every</em>
 tag on the commit rather than only the highest, so a duplicate release no longer produces a release
-with no SBOM. Each tag is built separately, because setuptools-scm reads the version from the tag
-and one SBOM cannot honestly describe two versions.
+with no SBOM. Each tag is built separately so its SBOM carries its own version.
+
+<b>Correction:</b> the claim above originally read "because setuptools-scm reads the version from
+the tag", and that is false — it reads the version from the <em>commit</em>, so separate checkouts
+of two tags on one commit produce the same version. That was a second, quieter consequence of the
+duplicate release, fixed separately in <code>sbom-declares-the-wrong-version</code>.

boost_skill_cli-1.0.285/docs/roadmap/items/sbom-declares-the-wrong-version.md

@@ -0,0 +1,54 @@
+---
+id: sbom-declares-the-wrong-version
+board: code
+section: trust
+status: shipped
+category: Supply chain · Bug
+complexity: S
+impact: High
+wow: 5
+note: fixed — release v1.0.278's SBOM declared 1.0.277; the version is now pinned to the tag
+order: 68
+owner: loop/sbom-tag-version
+pr:
+title: The SBOM can declare a different version than the release it is attached to
+---
+<code>sbom.yml</code> builds each released tag separately so that every release gets an SBOM
+describing <em>its own</em> version. It does that by checking the tag out:
+<code>git checkout --detach "refs/tags/$TAG"</code>. The premise is wrong.
+<b>setuptools-scm derives the version from the commit, not from the ref used to reach it</b>, so
+when one commit carries two tags every checkout resolves to the same version — whichever one
+<code>git describe</code> picks, which is not the highest.
+
+Measured against the real repository, detached at each tag in turn:
+
+<code>checked out v1.0.278 -&gt; setuptools-scm says: 1.0.277</code><br>
+<code>checked out v1.0.277 -&gt; setuptools-scm says: 1.0.277</code>
+
+And confirmed in production rather than in a fixture — the published asset on
+<code>v1.0.278</code>, downloaded from the release, contains
+<code>{"name": "boost-skill-cli", "version": "1.0.277"}</code>. <b>The SBOM attached to release
+v1.0.278 describes v1.0.277.</b> A consumer resolving that release's bill of materials gets a
+document for a different version, which is precisely the trust property an SBOM exists to provide.
+
+The blast radius is bounded by how often one commit cuts two releases, which
+<code>one-commit-can-cut-two-releases</code> documents happening three times so far
+(<code>246</code>/<code>247</code>, <code>248</code>/<code>249</code>, <code>277</code>/<code>278</code>).
+Every duplicate pair mislabels one of its two SBOMs. It is <em>not</em> latent in
+<code>publish.yml</code>, which builds the PyPI dist: that job checks out before the sibling run's
+tag exists, so it happens to resolve correctly — all 281 PyPI versions are present and correctly
+numbered. The defect is specific to the job that runs <em>after</em> both tags are in place.
+
+<b>Shipped.</b> The build now pins the version to the tag it is building
+(<code>SETUPTOOLS_SCM_PRETEND_VERSION_FOR_BOOST_SKILL_CLI="${TAG#v}"</code>) and then asserts the
+wheel it produced carries that version, so a package rename — which would silently unhook the
+scoped variable and restore the bug — fails the job instead of shipping a mislabelled document.
+Verified both ways against the live repository: without the pin, <code>v1.0.278</code> resolves to
+<code>1.0.277</code>; with it, <code>1.0.278</code>.
+
+The same exercise settled the other thing this workflow had never proven: the multi-tag loop
+itself. Both <code>run:</code> blocks were extracted verbatim from the YAML and driven against a
+fixture repository with two tags on one commit, with <code>gh</code> and the build toolchain
+stubbed. Resolution returns both tags newest-first, the loop iterates both, and it issues a
+separate <code>upload</code> and a separate post-upload <code>view</code> assertion per tag. That
+path had never executed in production — every commit since it shipped has carried exactly one tag.

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.285}/docs/roadmap.html

@@ -110,7 +110,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>4</b><span>Planned</span></div>
-      <div class="stat"><b>174</b><span>Loop finds</span></div>
+      <div class="stat"><b>176</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -2707,8 +2707,12 @@ ci will trigger its own release, but it means some merges never get their own ve
 
 <b>Already mitigated:</b> <code>sbom.yml</code> now builds and attaches an SBOM for <em>every</em>
 tag on the commit rather than only the highest, so a duplicate release no longer produces a release
-with no SBOM. Each tag is built separately, because setuptools-scm reads the version from the tag
-and one SBOM cannot honestly describe two versions.</p>
+with no SBOM. Each tag is built separately so its SBOM carries its own version.
+
+<b>Correction:</b> the claim above originally read "because setuptools-scm reads the version from
+the tag", and that is false — it reads the version from the <em>commit</em>, so separate checkouts
+of two tags on one commit produce the same version. That was a second, quieter consequence of the
+duplicate release, fixed separately in <code>sbom-declares-the-wrong-version</code>.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m">Impact <b>Med</b></span>
@@ -3177,6 +3181,60 @@ regresses.</p>
           <span class="m">agent reflex</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="actionlint-skips-shellcheck-silently">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Testing · Bug</span></div>
+        <h3>The second silent skip &mdash; <code>actionlint</code> runs, and checks no <code>run:</code> block at all</h3>
+        <p><code>make-lint-masks-actionlint-failures</code> fixed the layer everyone can see: <code>make
+lint</code> discarded actionlint's exit status. There is a second layer underneath it, and the
+first fix does not reach it. <b><code>actionlint</code> does not lint <code>run:</code> blocks
+itself.</b> It shells out to <code>shellcheck</code>, and when shellcheck is not on
+<code>PATH</code> it skips every one of them &mdash; no warning, no note, exit 0.
+
+Same workflow file, same actionlint binary, only <code>PATH</code> differs:
+
+<code>without shellcheck -&gt; (no output) exit=0</code><br>
+<code>with shellcheck    -&gt; bad.yml:8:9: shellcheck reported issue in this script: SC2001 &hellip; exit=1</code>
+
+So the honest description of the gate before this change was: <code>make lint</code> ran a workflow
+linter that silently declined to look inside any script, and reported success. That is not
+hypothetical either &mdash; it is exactly how an <code>SC2001</code> reached CI from a green local
+gate, in the very change that fixed layer one.
+
+<b>CI was not safe, only lucky.</b> Its actionlint step carried the comment "shellcheck is
+preinstalled on the runner, so run: blocks are checked too" &mdash; true today, and an unpinned,
+unversioned, silently revocable dependency on somebody else's base image. If GitHub ever drops it
+from <code>ubuntu-latest</code>, CI degrades to the same hollow check with no signal that anything
+changed. For a repository that hash-pins its entire lint toolchain precisely so an upstream release
+cannot move a gate underneath it, an implicit dependency on a runner image is the same bug in a
+different coat.
+
+<b>Shipped.</b> <code>shellcheck-py==0.11.0.1</code> is declared in
+<code>requirements/lint-tools.in</code> and hash-pinned into the generated
+<code>lint-tools.txt</code> like every other tool, which puts it on both sides: CI installs it from
+that lock, and <code>make venv</code> puts it in <code>.venv/bin</code>. <code>make lint</code> now
+prepends <code>.venv/bin</code> to <code>PATH</code> so actionlint can find it, and <b>fails</b> if
+it is missing rather than running a check it knows is hollow; CI asserts <code>command -v
+shellcheck</code> before invoking actionlint. Verified in four states against the real recipe: the
+tool absent (skip message, exit 0), shellcheck missing from the venv (exit 1 with a message naming
+the fix), both present and workflows clean (exit 0), and both present with an <code>SC2001</code> in
+a <code>run:</code> block (exit 1 &mdash; the case that used to pass). The old recipe on that same
+file exits 0.
+
+<b>What is deliberately still skipped.</b> If <code>actionlint</code> itself is absent,
+<code>make lint</code> prints a message and continues. Closing that would mean pinning
+<code>actionlint-py</code>, which is sdist-only and fetches the binary from the network at install
+time, and which tracks a different actionlint version than the URL-pinned one CI uses. Trading a
+pinned binary for a build-time download is a worse trade than the skip, so the skip stays and is
+documented rather than quietly tolerated. The wider gap named by the earlier card is also still
+open: <code>zizmor</code> and <code>gitleaks</code> run only in CI and have no Makefile equivalent.</p>
+        <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">fixed — shellcheck is pinned in lint-tools and both gates now assert it is there</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>
@@ -4279,6 +4337,56 @@ having found error-severity alerts.</p>
           <span class="m">safe scoped to CodeQL (0 open) — adding Scorecard deadlocks every merge</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="sbom-declares-the-wrong-version">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Supply chain · Bug</span></div>
+        <h3>The SBOM can declare a different version than the release it is attached to</h3>
+        <p><code>sbom.yml</code> builds each released tag separately so that every release gets an SBOM
+describing <em>its own</em> version. It does that by checking the tag out:
+<code>git checkout --detach "refs/tags/$TAG"</code>. The premise is wrong.
+<b>setuptools-scm derives the version from the commit, not from the ref used to reach it</b>, so
+when one commit carries two tags every checkout resolves to the same version — whichever one
+<code>git describe</code> picks, which is not the highest.
+
+Measured against the real repository, detached at each tag in turn:
+
+<code>checked out v1.0.278 -&gt; setuptools-scm says: 1.0.277</code><br>
+<code>checked out v1.0.277 -&gt; setuptools-scm says: 1.0.277</code>
+
+And confirmed in production rather than in a fixture — the published asset on
+<code>v1.0.278</code>, downloaded from the release, contains
+<code>{"name": "boost-skill-cli", "version": "1.0.277"}</code>. <b>The SBOM attached to release
+v1.0.278 describes v1.0.277.</b> A consumer resolving that release's bill of materials gets a
+document for a different version, which is precisely the trust property an SBOM exists to provide.
+
+The blast radius is bounded by how often one commit cuts two releases, which
+<code>one-commit-can-cut-two-releases</code> documents happening three times so far
+(<code>246</code>/<code>247</code>, <code>248</code>/<code>249</code>, <code>277</code>/<code>278</code>).
+Every duplicate pair mislabels one of its two SBOMs. It is <em>not</em> latent in
+<code>publish.yml</code>, which builds the PyPI dist: that job checks out before the sibling run's
+tag exists, so it happens to resolve correctly — all 281 PyPI versions are present and correctly
+numbered. The defect is specific to the job that runs <em>after</em> both tags are in place.
+
+<b>Shipped.</b> The build now pins the version to the tag it is building
+(<code>SETUPTOOLS_SCM_PRETEND_VERSION_FOR_BOOST_SKILL_CLI="${TAG#v}"</code>) and then asserts the
+wheel it produced carries that version, so a package rename — which would silently unhook the
+scoped variable and restore the bug — fails the job instead of shipping a mislabelled document.
+Verified both ways against the live repository: without the pin, <code>v1.0.278</code> resolves to
+<code>1.0.277</code>; with it, <code>1.0.278</code>.
+
+The same exercise settled the other thing this workflow had never proven: the multi-tag loop
+itself. Both <code>run:</code> blocks were extracted verbatim from the YAML and driven against a
+fixture repository with two tags on one commit, with <code>gh</code> and the build toolchain
+stubbed. Resolution returns both tags newest-first, the loop iterates both, and it issues a
+separate <code>upload</code> and a separate post-upload <code>view</code> assertion per tag. That
+path had never executed in production — every commit since it shipped has carried exactly one tag.</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">fixed — release v1.0.278's SBOM declared 1.0.277; the version is now pinned to the tag</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.285}/requirements/lint-tools.in

@@ -30,3 +30,13 @@ interrogate==1.7.0
 # itself, which is why this set is lint-only and never a runtime dependency.
 # Reuses the mypy pinned above.
 refurb==2.3.1
+# shellcheck, as a pinned dependency rather than an assumption. actionlint does
+# not lint `run:` blocks itself — it shells out to shellcheck, and when
+# shellcheck is not on PATH it skips that entirely and still exits 0. Same
+# workflow file, same actionlint: without shellcheck, no output and exit 0; with
+# it, `SC2001` and exit 1. CI got away with it because the GitHub runner image
+# happens to preinstall shellcheck, which is an unpinned, unversioned, silently
+# revocable dependency on somebody else's base image — and locally, where it is
+# usually absent, `make lint` was passing a check it never ran. Pinning it here
+# puts it on both sides and makes the version reviewable like every other tool.
+shellcheck-py==0.11.0.1

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.285}/requirements/lint-tools.txt

@@ -564,6 +564,13 @@ ruff==0.16.0 \
     --hash=sha256:e5115729eb08c585e5121978ba5d5b60caeae394ce21b9fb5e6cd33a1c6c9b1e \
     --hash=sha256:e95c448fca1fb2a18372a9440926c5a6ee789639bb975c72e7ae6d0b04218ab4
     # via -r requirements/lint-tools.in
+shellcheck-py==0.11.0.1 \
+    --hash=sha256:1b274df81de5b000ff78db433e7328b87e52e3c38481c60f8e488c3095beef05 \
+    --hash=sha256:5c620c88901e8f1d3be5934b31ea99e3310065e1245253741eafd0a275c8c9cc \
+    --hash=sha256:6b88d0a244c82ed07e06a53e444da841f69330ca59ae15d4a66c391655dae7a0 \
+    --hash=sha256:784156289ecb17e91c692cd783ab5152333309588cabb10032a047331c63e759 \
+    --hash=sha256:b6a3fee28efda2e16e38d6e6d59faf7224300256456639727370d404730849e8
+    # via -r requirements/lint-tools.in
 six==1.17.0 \
     --hash=sha256:4721f391ed90541fddacab5acf947aa0d3dc7d27b2e1e8eda2be8970586c3274 \
     --hash=sha256:ff70335d468e7eb6ec65b95b99d3a2836546063f63acc5171de367e834932a81