boost-skill-cli 1.0.254__tar.gz → 1.0.255__tar.gz

{boost_skill_cli-1.0.254 → boost_skill_cli-1.0.255}/PKG-INFO

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

{boost_skill_cli-1.0.254 → boost_skill_cli-1.0.255}/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.254'
-__version_tuple__ = version_tuple = (1, 0, 254)
+__version__ = version = '1.0.255'
+__version_tuple__ = version_tuple = (1, 0, 255)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.254 → boost_skill_cli-1.0.255}/boost_skill_cli.egg-info/PKG-INFO

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

boost_skill_cli-1.0.255/docs/roadmap/items/sbom-release-event-never-fires.md

@@ -0,0 +1,54 @@
+---
+id: sbom-release-event-never-fires
+board: code
+section: trust
+status: shipped
+category: Supply chain
+complexity: S
+impact: High
+wow: 4
+note: 253 releases shipped with no SBOM; fixed with workflow_run
+order: 50
+owner:
+pr: 295
+title: <code>sbom.yml</code> has never run — it waits for an event <code>GITHUB_TOKEN</code> cannot emit
+---
+<code>sbom.yml</code> triggers on <code>release: types: [published]</code> and promises
+"a CycloneDX SBOM for every release, attached to the GitHub Release as an asset".
+It has <b>0 runs</b>. Releases here are created by <code>release-drafter</code> inside
+<code>publish.yml</code> authenticated with <code>GITHUB_TOKEN</code>, and <b>events created
+with <code>GITHUB_TOKEN</code> do not trigger workflows</b>. <code>publish.yml</code>'s own
+header states that rule verbatim — "we never rely on the release event to trigger a second
+workflow" — and <code>sbom.yml</code> is exactly that pattern.
+
+So the <code>if: github.event_name == 'release'</code> guard on its upload step is dead code,
+<code>workflow_dispatch</code> is the only reachable path and has never been used, and every
+one of the last ten releases carries <code>assets: []</code>. Zero SBOMs have been produced
+since the file landed on 2026-07-22. Same shape as the LangGraph conformance leg: wired up,
+looks covered, never executed once.
+
+By the time it was fixed the count was <b>253 releases, 0 runs, 0 SBOM assets</b>.
+
+<b>Fixed with a third option neither branch of that decision considered:</b>
+<code>workflow_run</code>. The <code>GITHUB_TOKEN</code> restriction applies to
+<em>events</em> a token creates; <code>workflow_run</code> is documented as exempt and fires
+on the upstream <em>run</em> completing regardless of what triggered it &mdash; which is
+already how <code>ci &rarr; release</code> works in this repo. Chaining
+<code>release &rarr; sbom</code> makes this the third link, inside GitHub's documented
+three-level <code>workflow_run</code> limit. So no PAT is needed, and the SBOM logic stays
+out of <code>publish.yml</code>.
+
+That separation turned out to matter more than "keeps the logic in its own file":
+<code>publish.yml</code>'s job holds PyPI Trusted-Publishing OIDC credentials, and generating
+the SBOM means installing a third-party build plugin (<code>cyclonedx-bom</code>). Inlining it
+would have put that plugin inside the one job that can publish to PyPI. Kept separate, it
+holds only <code>contents: write</code>.
+
+Two details the trigger change forced. The workflow now resolves its tag from the release
+commit (<code>git tag --points-at</code>) rather than "newest release" &mdash; releases here
+land minutes apart, so <code>gh release view</code> would race and SBOM the <em>next</em>
+version; and two tags on one commit is real (<code>v1.0.248</code> and <code>v1.0.249</code>
+both point at <code>c750651</code>), so it takes the highest. And per the original note, a
+final step re-reads the release and fails unless the asset is actually attached &mdash; a
+silent upload no-op is indistinguishable from success, which is the same class of quiet
+nothing that produced this bug.

{boost_skill_cli-1.0.254 → boost_skill_cli-1.0.255}/docs/roadmap.html

@@ -3520,7 +3520,7 @@ is built.</p>
       </article>
 
       <article class="cap rcard" id="sbom-release-event-never-fires">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Supply chain</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Supply chain</span></div>
         <h3><code>sbom.yml</code> has never run — it waits for an event <code>GITHUB_TOKEN</code> cannot emit</h3>
         <p><code>sbom.yml</code> triggers on <code>release: types: [published]</code> and promises
 "a CycloneDX SBOM for every release, attached to the GitHub Release as an asset".
@@ -3536,17 +3536,36 @@ one of the last ten releases carries <code>assets: []</code>. Zero SBOMs have be
 since the file landed on 2026-07-22. Same shape as the LangGraph conformance leg: wired up,
 looks covered, never executed once.
 
-Fix is a decision, not a patch: either build and attach the SBOM inside
-<code>publish.yml</code>'s release job (it already holds <code>contents: write</code> and is
-where the tag is cut), or have <code>publish.yml</code> dispatch this workflow with a PAT
-rather than <code>GITHUB_TOKEN</code>. The first is simpler and keeps the release atomic;
-the second keeps the SBOM logic in its own file. Worth pairing with a check that fails the
-release when the asset is missing, so "never ran" cannot recur silently.</p>
+By the time it was fixed the count was <b>253 releases, 0 runs, 0 SBOM assets</b>.
+
+<b>Fixed with a third option neither branch of that decision considered:</b>
+<code>workflow_run</code>. The <code>GITHUB_TOKEN</code> restriction applies to
+<em>events</em> a token creates; <code>workflow_run</code> is documented as exempt and fires
+on the upstream <em>run</em> completing regardless of what triggered it &mdash; which is
+already how <code>ci &rarr; release</code> works in this repo. Chaining
+<code>release &rarr; sbom</code> makes this the third link, inside GitHub's documented
+three-level <code>workflow_run</code> limit. So no PAT is needed, and the SBOM logic stays
+out of <code>publish.yml</code>.
+
+That separation turned out to matter more than "keeps the logic in its own file":
+<code>publish.yml</code>'s job holds PyPI Trusted-Publishing OIDC credentials, and generating
+the SBOM means installing a third-party build plugin (<code>cyclonedx-bom</code>). Inlining it
+would have put that plugin inside the one job that can publish to PyPI. Kept separate, it
+holds only <code>contents: write</code>.
+
+Two details the trigger change forced. The workflow now resolves its tag from the release
+commit (<code>git tag --points-at</code>) rather than "newest release" &mdash; releases here
+land minutes apart, so <code>gh release view</code> would race and SBOM the <em>next</em>
+version; and two tags on one commit is real (<code>v1.0.248</code> and <code>v1.0.249</code>
+both point at <code>c750651</code>), so it takes the highest. And per the original note, a
+final step re-reads the release and fails unless the asset is actually attached &mdash; a
+silent upload no-op is indistinguishable from success, which is the same class of quiet
+nothing that produced this bug.</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">0 runs, 0 SBOMs, 227 releases</span>
+          <span class="m">253 releases shipped with no SBOM; fixed with workflow_run</span>
         </div>
       </article>
 

boost_skill_cli-1.0.254/docs/roadmap/items/sbom-release-event-never-fires.md

@@ -1,35 +0,0 @@
----
-id: sbom-release-event-never-fires
-board: code
-section: trust
-status: planned
-category: Supply chain
-complexity: S
-impact: High
-wow: 4
-note: 0 runs, 0 SBOMs, 227 releases
-order: 50
-owner:
-pr:
-title: <code>sbom.yml</code> has never run — it waits for an event <code>GITHUB_TOKEN</code> cannot emit
----
-<code>sbom.yml</code> triggers on <code>release: types: [published]</code> and promises
-"a CycloneDX SBOM for every release, attached to the GitHub Release as an asset".
-It has <b>0 runs</b>. Releases here are created by <code>release-drafter</code> inside
-<code>publish.yml</code> authenticated with <code>GITHUB_TOKEN</code>, and <b>events created
-with <code>GITHUB_TOKEN</code> do not trigger workflows</b>. <code>publish.yml</code>'s own
-header states that rule verbatim — "we never rely on the release event to trigger a second
-workflow" — and <code>sbom.yml</code> is exactly that pattern.
-
-So the <code>if: github.event_name == 'release'</code> guard on its upload step is dead code,
-<code>workflow_dispatch</code> is the only reachable path and has never been used, and every
-one of the last ten releases carries <code>assets: []</code>. Zero SBOMs have been produced
-since the file landed on 2026-07-22. Same shape as the LangGraph conformance leg: wired up,
-looks covered, never executed once.
-
-Fix is a decision, not a patch: either build and attach the SBOM inside
-<code>publish.yml</code>'s release job (it already holds <code>contents: write</code> and is
-where the tag is cut), or have <code>publish.yml</code> dispatch this workflow with a PAT
-rather than <code>GITHUB_TOKEN</code>. The first is simpler and keeps the release atomic;
-the second keeps the SBOM logic in its own file. Worth pairing with a check that fails the
-release when the asset is missing, so "never ran" cannot recur silently.