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

{boost_skill_cli-1.0.278/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.278
+Version: 1.0.280
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

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

{boost_skill_cli-1.0.278 → 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.278
+Version: 1.0.280
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.278 → 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.278 → boost_skill_cli-1.0.280}/docs/roadmap/items/release-verifies-the-wrong-commit.md

@@ -2,12 +2,12 @@
 id: release-verifies-the-wrong-commit
 board: code
 section: pipeline
-status: planned
+status: shipped
 category: Release safety
 complexity: S
 impact: High
 wow: 4
-note: 2 of 18 required contexts are re-checked against the sha actually shipped
+note: preflight now waits on 17 of 18 for the shipped sha, up from 2
 order: 64
 owner:
 pr:
@@ -39,12 +39,16 @@ rather than a decision is in-tree: <code>release_preflight.py</code>'s own docst
 for <em>every</em> required workflow for the exact commit being released, and the caller hands it
 two.
 
-<b>A required context that can never report on <code>main</code> at all.</b> While checking the
-other 16: <code>osv-scanner.yml</code> declares only <code>pull_request</code> and
-<code>merge_group</code> triggers &mdash; no <code>push</code>. So <code>scan-pr / osv-scan</code>
-is green as a PR gate and produces <em>nothing</em> for any commit on <code>main</code>, race or
-no race. Adding it to preflight without first giving that workflow a
-<code>push: branches: [main]</code> trigger would fail the release closed every time.
+<b>A required context that can never report on <code>main</code> at all &mdash; and must not
+be made to.</b> <code>osv-scanner.yml</code> declares only <code>pull_request</code> and
+<code>merge_group</code>, so <code>scan-pr / osv-scan</code> produces nothing for any commit on
+<code>main</code>. This card originally proposed giving it a <code>push</code> trigger. <b>That was
+wrong.</b> It is PR-scoped deliberately: it calls the
+<code>osv-scanner-reusable-<b>pr</b>.yml</code> diff workflow so it reports only what a pull
+request <em>adds</em>, and its own header records why a full-repo scan is unwanted &mdash; it
+would trip the accepted, documented old-langchain pin in the <code>[eval]</code> extra that ragas
+requires. The correct conclusion is the opposite one: <code>scan-pr / osv-scan</code> is
+inherently a pull-request gate and belongs nowhere near release preflight.
 
 The fix is not to change the checkout ref. Pinning to
 <code>github.event.workflow_run.head_sha</code> would build the older commit while release-drafter
@@ -55,3 +59,20 @@ the triggering run's <code>head_sha</code>. This is the third defect found in th
 &mdash; see <code>publish-trigger-was-reachable-from-a-fork</code> (who can fire it) and
 <code>publish-gate-ignores-pip-audit-and-metadata</code> (which gates are consulted); this one is
 <em>which commit</em> they were consulted about.
+
+<b>Shipped.</b> <code>publish.yml</code> now passes preflight every required context's workflow
+that actually runs on a push to <code>main</code> &mdash; <code>ci.yml</code>,
+<code>codeql.yml</code>, <code>pip-audit.yml</code>, <code>package-metadata.yml</code> &mdash;
+taking coverage of the shipped sha from <b>2 of 18 required contexts to 17 of 18</b>. The
+remaining one is <code>scan-pr / osv-scan</code>, excluded on purpose for the reason above. The
+checkout ref is untouched: pinning it to the trigger's <code>head_sha</code> would build the older
+commit while release-drafter still tags the branch head, leaving artifact and tag disagreeing.
+<code>--timeout-seconds</code> is raised to 3600 because ci must now finish for the shipped sha and
+ci's wall clock is dominated by runner queueing; failing closed on a slow-but-green ci would be
+worse than waiting, and a timeout is still fail-closed either way.
+
+Verified by running the real script against <code>main</code> before merging: the four shipped
+gates return <b>exit 0</b> ("all 4 release gates green"), and adding
+<code>--require osv-scanner.yml</code> returns <b>exit 1</b> &mdash; "no run recorded for this
+commit ... a release gate that never reported cannot be assumed green" &mdash; which is the
+concrete proof that the original recommendation would have blocked every release.

{boost_skill_cli-1.0.278 → 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.278 → 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>
@@ -2501,7 +2501,7 @@ caught by a human noticing a pip warning, twice, by luck.</p>
       </article>
 
       <article class="cap rcard" id="release-verifies-the-wrong-commit">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Release safety</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Release safety</span></div>
         <h3>The release verifies one commit and ships another</h3>
         <p><code>publish.yml</code> fires on <code>workflow_run</code> when <code>ci</code> completes, gates
 on that run's <code>conclusion == 'success'</code> (plus <code>event == 'push'</code> and
@@ -2529,12 +2529,16 @@ rather than a decision is in-tree: <code>release_preflight.py</code>'s own docst
 for <em>every</em> required workflow for the exact commit being released, and the caller hands it
 two.
 
-<b>A required context that can never report on <code>main</code> at all.</b> While checking the
-other 16: <code>osv-scanner.yml</code> declares only <code>pull_request</code> and
-<code>merge_group</code> triggers &mdash; no <code>push</code>. So <code>scan-pr / osv-scan</code>
-is green as a PR gate and produces <em>nothing</em> for any commit on <code>main</code>, race or
-no race. Adding it to preflight without first giving that workflow a
-<code>push: branches: [main]</code> trigger would fail the release closed every time.
+<b>A required context that can never report on <code>main</code> at all &mdash; and must not
+be made to.</b> <code>osv-scanner.yml</code> declares only <code>pull_request</code> and
+<code>merge_group</code>, so <code>scan-pr / osv-scan</code> produces nothing for any commit on
+<code>main</code>. This card originally proposed giving it a <code>push</code> trigger. <b>That was
+wrong.</b> It is PR-scoped deliberately: it calls the
+<code>osv-scanner-reusable-<b>pr</b>.yml</code> diff workflow so it reports only what a pull
+request <em>adds</em>, and its own header records why a full-repo scan is unwanted &mdash; it
+would trip the accepted, documented old-langchain pin in the <code>[eval]</code> extra that ragas
+requires. The correct conclusion is the opposite one: <code>scan-pr / osv-scan</code> is
+inherently a pull-request gate and belongs nowhere near release preflight.
 
 The fix is not to change the checkout ref. Pinning to
 <code>github.event.workflow_run.head_sha</code> would build the older commit while release-drafter
@@ -2544,12 +2548,29 @@ change is to widen preflight's <code>--require</code> set to the contexts that a
 the triggering run's <code>head_sha</code>. This is the third defect found in the same few lines
 &mdash; see <code>publish-trigger-was-reachable-from-a-fork</code> (who can fire it) and
 <code>publish-gate-ignores-pip-audit-and-metadata</code> (which gates are consulted); this one is
-<em>which commit</em> they were consulted about.</p>
+<em>which commit</em> they were consulted about.
+
+<b>Shipped.</b> <code>publish.yml</code> now passes preflight every required context's workflow
+that actually runs on a push to <code>main</code> &mdash; <code>ci.yml</code>,
+<code>codeql.yml</code>, <code>pip-audit.yml</code>, <code>package-metadata.yml</code> &mdash;
+taking coverage of the shipped sha from <b>2 of 18 required contexts to 17 of 18</b>. The
+remaining one is <code>scan-pr / osv-scan</code>, excluded on purpose for the reason above. The
+checkout ref is untouched: pinning it to the trigger's <code>head_sha</code> would build the older
+commit while release-drafter still tags the branch head, leaving artifact and tag disagreeing.
+<code>--timeout-seconds</code> is raised to 3600 because ci must now finish for the shipped sha and
+ci's wall clock is dominated by runner queueing; failing closed on a slow-but-green ci would be
+worse than waiting, and a timeout is still fail-closed either way.
+
+Verified by running the real script against <code>main</code> before merging: the four shipped
+gates return <b>exit 0</b> ("all 4 release gates green"), and adding
+<code>--require osv-scanner.yml</code> returns <b>exit 1</b> &mdash; "no run recorded for this
+commit ... a release gate that never reported cannot be assumed green" &mdash; which is the
+concrete proof that the original recommendation would have blocked every release.</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">2 of 18 required contexts are re-checked against the sha actually shipped</span>
+          <span class="m">preflight now waits on 17 of 18 for the shipped sha, up from 2</span>
         </div>
       </article>
 
@@ -2647,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>
@@ -4008,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>