boost-skill-cli 1.0.279__tar.gz → 1.0.280__tar.gz

{boost_skill_cli-1.0.279/boost_skill_cli.egg-info → boost_skill_cli-1.0.280}/PKG-INFO

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

{boost_skill_cli-1.0.279 → boost_skill_cli-1.0.280}/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.279'
-__version_tuple__ = version_tuple = (1, 0, 279)
+__version__ = version = '1.0.280'
+__version_tuple__ = version_tuple = (1, 0, 280)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.279 → boost_skill_cli-1.0.280/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.279 → boost_skill_cli-1.0.280}/boost_skill_cli.egg-info/SOURCES.txt

@@ -249,6 +249,7 @@ docs/roadmap/items/mypy-strict-mode-for-commands.md
 docs/roadmap/items/negative-limit-inverts-log-pulse-output.md
 docs/roadmap/items/onboard-overwrites-generated-files-without-confirm.md
 docs/roadmap/items/one-command-every-env-nox.md
+docs/roadmap/items/one-commit-can-cut-two-releases.md
 docs/roadmap/items/one-shared-atomic-write-helper.md
 docs/roadmap/items/package-metadata-validation-twine-check-friends.md
 docs/roadmap/items/patch-coverage-gate-diff-cover.md

boost_skill_cli-1.0.280/docs/roadmap/items/one-commit-can-cut-two-releases.md

@@ -0,0 +1,52 @@
+---
+id: one-commit-can-cut-two-releases
+board: code
+section: pipeline
+status: planned
+category: Release safety
+complexity: M
+impact: Med
+wow: 3
+note: v1.0.277 and v1.0.278 are the same commit; so were 246/247 and 248/249
+order: 67
+owner:
+pr:
+title: One commit can cut two releases, and the naive guard against it breaks retries
+---
+<code>publish.yml</code> checks out <code>ref: main</code> rather than the commit whose
+<code>ci</code> fired it. <code>release-verifies-the-wrong-commit</code> fixed the
+<em>verification</em> half of that &mdash; preflight now waits on the shipped sha's own gates
+&mdash; but the same decoupling has a second consequence it does not address: <b>two triggers can
+both resolve to the same tip and release it twice.</b>
+
+Observed on <code>5061e756</code>: two <code>release</code> runs created 27 seconds apart
+(22:24:32Z and 22:24:59Z), both succeeding, cutting <b>v1.0.277 and v1.0.278 from one commit</b>.
+It recurs &mdash; <code>v1.0.246</code>/<code>v1.0.247</code> both point at <code>c1d67c1c</code>,
+and <code>v1.0.248</code>/<code>v1.0.249</code> both at <code>c750651</code>. Each duplicate burns
+a PyPI version on a byte-identical build and, until the companion fix in this change, left one of
+the two GitHub Releases with no SBOM.
+
+Preflight does not stop it and was never going to: both runs check out the same green tip, so both
+legitimately pass every gate. The duplication is upstream of verification.
+
+<b>The obvious fix is a trap, which is why this is filed rather than patched.</b> Guarding with
+"skip if <code>git tag --points-at HEAD</code> already has a <code>v*</code> tag" would stop the
+duplicate &mdash; and would also stop any legitimate <b>retry</b>. release-drafter creates the tag
+<em>before</em> the build, attestation, wheel smoke-test and PyPI upload run, so a release that
+failed at the upload step leaves a tag behind with nothing on PyPI. Under that guard, re-running it
+would skip instead of finishing the job, converting a recoverable failure into a version that can
+never be published. The <code>concurrency: group: release</code> block does not help either: it
+serialises the two runs rather than collapsing them, which is exactly what happened here.
+
+A correct fix has to distinguish "already released" from "tagged but not published" &mdash; check
+whether the version exists on PyPI, or whether the GitHub Release has its expected assets, rather
+than whether a tag exists. Alternatives worth weighing: collapse the trigger so only the newest
+queued run proceeds (<code>cancel-in-progress</code> on a group keyed by nothing, losing the
+serialisation the release job wants), or skip when <code>git rev-parse HEAD</code> already differs
+from <code>workflow_run.head_sha</code> &mdash; that is self-healing, since the newer commit's own
+ci will trigger its own release, but it means some merges never get their own version.
+
+<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.

{boost_skill_cli-1.0.279 → boost_skill_cli-1.0.280}/docs/roadmap/items/sbom-release-event-never-fires.md

@@ -48,7 +48,10 @@ Two details the trigger change forced. The workflow now resolves its tag from th
 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
+both point at <code>c750651</code>), so it takes <em>every</em> tag on the commit and builds each
+separately &mdash; taking only the highest left the other release with no SBOM, which showed up in
+production as <code>v1.0.277</code>; see <code>one-commit-can-cut-two-releases</code>. 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.279 → boost_skill_cli-1.0.280}/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>171</b><span>Loop finds</span></div>
+      <div class="stat"><b>172</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -2668,6 +2668,54 @@ before touching a tree, and 68 stale entries make that check noisier for every c
           <span class="m">68 of 70 loop/* branches have a merged PR; one setting fixes it</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="one-commit-can-cut-two-releases">
+        <div class="head"><span class="pill planned">Planned</span><span class="cat">Release safety</span></div>
+        <h3>One commit can cut two releases, and the naive guard against it breaks retries</h3>
+        <p><code>publish.yml</code> checks out <code>ref: main</code> rather than the commit whose
+<code>ci</code> fired it. <code>release-verifies-the-wrong-commit</code> fixed the
+<em>verification</em> half of that &mdash; preflight now waits on the shipped sha's own gates
+&mdash; but the same decoupling has a second consequence it does not address: <b>two triggers can
+both resolve to the same tip and release it twice.</b>
+
+Observed on <code>5061e756</code>: two <code>release</code> runs created 27 seconds apart
+(22:24:32Z and 22:24:59Z), both succeeding, cutting <b>v1.0.277 and v1.0.278 from one commit</b>.
+It recurs &mdash; <code>v1.0.246</code>/<code>v1.0.247</code> both point at <code>c1d67c1c</code>,
+and <code>v1.0.248</code>/<code>v1.0.249</code> both at <code>c750651</code>. Each duplicate burns
+a PyPI version on a byte-identical build and, until the companion fix in this change, left one of
+the two GitHub Releases with no SBOM.
+
+Preflight does not stop it and was never going to: both runs check out the same green tip, so both
+legitimately pass every gate. The duplication is upstream of verification.
+
+<b>The obvious fix is a trap, which is why this is filed rather than patched.</b> Guarding with
+"skip if <code>git tag --points-at HEAD</code> already has a <code>v*</code> tag" would stop the
+duplicate &mdash; and would also stop any legitimate <b>retry</b>. release-drafter creates the tag
+<em>before</em> the build, attestation, wheel smoke-test and PyPI upload run, so a release that
+failed at the upload step leaves a tag behind with nothing on PyPI. Under that guard, re-running it
+would skip instead of finishing the job, converting a recoverable failure into a version that can
+never be published. The <code>concurrency: group: release</code> block does not help either: it
+serialises the two runs rather than collapsing them, which is exactly what happened here.
+
+A correct fix has to distinguish "already released" from "tagged but not published" &mdash; check
+whether the version exists on PyPI, or whether the GitHub Release has its expected assets, rather
+than whether a tag exists. Alternatives worth weighing: collapse the trigger so only the newest
+queued run proceeds (<code>cancel-in-progress</code> on a group keyed by nothing, losing the
+serialisation the release job wants), or skip when <code>git rev-parse HEAD</code> already differs
+from <code>workflow_run.head_sha</code> &mdash; that is self-healing, since the newer commit's own
+ci will trigger its own release, but it means some merges never get their own version.
+
+<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>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">v1.0.277 and v1.0.278 are the same commit; so were 246/247 and 248/249</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>
@@ -4029,7 +4077,10 @@ Two details the trigger change forced. The workflow now resolves its tag from th
 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
+both point at <code>c750651</code>), so it takes <em>every</em> tag on the commit and builds each
+separately &mdash; taking only the highest left the other release with no SBOM, which showed up in
+production as <code>v1.0.277</code>; see <code>one-commit-can-cut-two-releases</code>. 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>