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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.283
+Version: 1.0.284
 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.284}/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.284'
+__version_tuple__ = version_tuple = (1, 0, 284)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.283 → boost_skill_cli-1.0.284}/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.284
 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.284}/boost_skill_cli.egg-info/SOURCES.txt

@@ -288,6 +288,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.283 → boost_skill_cli-1.0.284}/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.284/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.284}/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>175</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>
@@ -4279,6 +4283,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>