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

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

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

{boost_skill_cli-1.0.279 → boost_skill_cli-1.0.281/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.281
 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.281}/boost_skill_cli.egg-info/SOURCES.txt

@@ -173,6 +173,7 @@ docs/roadmap/items/ci-summary-step-fails-itself.md
 docs/roadmap/items/ci-time-is-now-runner-queueing.md
 docs/roadmap/items/clean-env-install-smoke-pip-and-pipx.md
 docs/roadmap/items/code-scanning-rule-can-be-restored.md
+docs/roadmap/items/codeql-job-rename-stranded-merge-protection.md
 docs/roadmap/items/command-carousel-page.md
 docs/roadmap/items/command-reference-docs-site.md
 docs/roadmap/items/complexity-and-dead-code-radar-xenon-vulture.md
@@ -249,6 +250,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
@@ -441,6 +443,7 @@ tests/unit/test_check_anchors.py
 tests/unit/test_check_licenses.py
 tests/unit/test_claude_settings.py
 tests/unit/test_cliparse.py
+tests/unit/test_codeql_analysis_key.py
 tests/unit/test_command_reference_fresh.py
 tests/unit/test_community_health_files.py
 tests/unit/test_config.py

boost_skill_cli-1.0.281/docs/roadmap/items/codeql-job-rename-stranded-merge-protection.md

@@ -0,0 +1,38 @@
+---
+id: codeql-job-rename-stranded-merge-protection
+board: code
+section: trust
+status: shipped
+category: CI · Bug
+complexity: S
+impact: High
+wow: 4
+note: a job rename forked the code-scanning config and blocked 100% of merges for a day
+order: 37
+owner: loop/codeql-analysis-key-guard
+pr:
+title: A CodeQL job rename silently blocked every merge
+---
+GitHub identifies a code-scanning configuration by <code>&lt;workflow path&gt;:&lt;job id&gt;</code>, which makes
+the job id load-bearing in a way nothing in the workflow file hints at: renaming it does not
+<i>move</i> the configuration, it <b>forks</b> it. #259 renamed this job <code>analyze</code> to
+<code>codeql-analyze</code> on 2026-07-27. The last <code>:analyze</code> analysis landed 20 seconds
+after that merge and never refreshed, stranding <b>247</b> of them on <code>refs/heads/main</code>
+where GitHub kept counting them as a configuration present on the base branch. Merge protection
+then reported <code>1 configuration not found</code> on every pull request — conclusion
+<code>neutral</code> — and because the branch ruleset carries a <code>code_scanning</code> rule,
+that neutral <b>blocked 100% of merges</b> while every required status check stayed green.
+The cutover is exact: the last <code>success</code> was #263, the first <code>neutral</code> #259,
+and every PR from #264 to #316 was neutral regardless of whether its diff contained Python at all.
+That symmetry is what makes it so easy to misread — it presents as a rule that rejects docs-only
+PRs, and the two hypotheses it invites (<i>"CodeQL has nothing to analyse"</i> and <i>"the rule is
+unsatisfiable"</i>) are both wrong. 29 docs-only PRs merged happily under the same rule before the
+rename. The check body says the real answer outright, and reading it beats inferring from
+<code>mergeable_state</code>. Fixed by deleting the 247 orphaned analyses, which was verified safe
+first: every alert still on the stale key was <code>fixed</code>, and all nine dismissed CodeQL
+alerts already carried their false-positive rationale on the live key. The job id was <i>already</i>
+guarded as a required status-check context by
+<code>scripts/check_required_checks.py</code>, and that guard passed during #259 because the
+context list was updated in the same commit — only the invisible half broke. So the guard added
+here pins the id from the analysis-key side, with a note that a future rename is not finished until
+the stale configuration is deleted. Related: [[release-verifies-the-wrong-commit]].

boost_skill_cli-1.0.281/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.281}/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.281}/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>173</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>
@@ -3966,6 +4014,40 @@ is built.</p>
         </div>
       </article>
 
+      <article class="cap rcard" id="codeql-job-rename-stranded-merge-protection">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CI · Bug</span></div>
+        <h3>A CodeQL job rename silently blocked every merge</h3>
+        <p>GitHub identifies a code-scanning configuration by <code>&lt;workflow path&gt;:&lt;job id&gt;</code>, which makes
+the job id load-bearing in a way nothing in the workflow file hints at: renaming it does not
+<i>move</i> the configuration, it <b>forks</b> it. #259 renamed this job <code>analyze</code> to
+<code>codeql-analyze</code> on 2026-07-27. The last <code>:analyze</code> analysis landed 20 seconds
+after that merge and never refreshed, stranding <b>247</b> of them on <code>refs/heads/main</code>
+where GitHub kept counting them as a configuration present on the base branch. Merge protection
+then reported <code>1 configuration not found</code> on every pull request — conclusion
+<code>neutral</code> — and because the branch ruleset carries a <code>code_scanning</code> rule,
+that neutral <b>blocked 100% of merges</b> while every required status check stayed green.
+The cutover is exact: the last <code>success</code> was #263, the first <code>neutral</code> #259,
+and every PR from #264 to #316 was neutral regardless of whether its diff contained Python at all.
+That symmetry is what makes it so easy to misread — it presents as a rule that rejects docs-only
+PRs, and the two hypotheses it invites (<i>"CodeQL has nothing to analyse"</i> and <i>"the rule is
+unsatisfiable"</i>) are both wrong. 29 docs-only PRs merged happily under the same rule before the
+rename. The check body says the real answer outright, and reading it beats inferring from
+<code>mergeable_state</code>. Fixed by deleting the 247 orphaned analyses, which was verified safe
+first: every alert still on the stale key was <code>fixed</code>, and all nine dismissed CodeQL
+alerts already carried their false-positive rationale on the live key. The job id was <i>already</i>
+guarded as a required status-check context by
+<code>scripts/check_required_checks.py</code>, and that guard passed during #259 because the
+context list was updated in the same commit — only the invisible half broke. So the guard added
+here pins the id from the analysis-key side, with a note that a future rename is not finished until
+the stale configuration is deleted. Related: [[release-verifies-the-wrong-commit]].</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">a job rename forked the code-scanning config and blocked 100% of merges for a day</span>
+        </div>
+      </article>
+
       <article class="cap rcard" id="installed-skill-trust-audit">
         <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Trust · Health</span></div>
         <h3><code>boost audit --skills</code> — a trust/staleness report for installed skills</h3>
@@ -4029,7 +4111,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>

boost_skill_cli-1.0.281/tests/unit/test_codeql_analysis_key.py

@@ -0,0 +1,95 @@
+"""Unit tests: the CodeQL job id is half of a code-scanning analysis key.
+
+GitHub identifies a code-scanning configuration by ``<workflow path>:<job id>``.
+That makes the job id load-bearing in a way nothing in the file hints at:
+renaming it does not *move* the configuration, it **forks** it. The old key stays
+on record as a configuration present on the default branch, no future run ever
+refreshes it, and code-scanning merge protection then reports
+
+    1 configuration not found
+    .github/workflows/codeql.yml:<old job id>
+
+on every pull request — conclusion ``neutral``, forever.
+
+This is not hypothetical. #259 ("ci(release-safety): make the required-check list
+config-as-code") renamed this job ``analyze`` -> ``codeql-analyze`` on
+2026-07-27. The last ``:analyze`` analysis landed 20 seconds after that merge and
+never refreshed, stranding 247 of them on ``refs/heads/main``. Every PR from #264
+onward reported ``neutral``, and because the branch ruleset carries a
+``code_scanning`` rule, that neutral blocked **100% of merges** — with all
+required status checks green, which is what made it so hard to read. It looked
+like a rule that rejected docs-only PRs; it was a rule that could never be
+satisfied by anything.
+
+The job id is also a required status-check context (``.github/required-checks.txt``,
+enforced by scripts/check_required_checks.py), so a rename already had one guard.
+That guard passed: the context list was updated in the same commit. Only the
+invisible half — the analysis key — broke.
+
+So this pins the id. If you genuinely need to rename the job, the rename is not
+finished until the stale configuration is deleted from the default branch
+(Security -> Code scanning -> any alert -> Affected branches -> main ->
+Configurations analyzing -> delete the old key; or DELETE
+/repos/{owner}/{repo}/code-scanning/analyses/{id}?confirm_delete=true, walking
+``next_analysis_url`` to the end of the set).
+"""
+from __future__ import annotations
+
+import importlib.util
+from pathlib import Path
+
+ROOT = Path(__file__).resolve().parent.parent.parent
+WORKFLOW = ROOT / ".github" / "workflows" / "codeql.yml"
+
+# Both halves of the analysis key GitHub records for this repo's CodeQL setup.
+# Changing either one strands the configuration these names describe.
+EXPECTED_WORKFLOW = ".github/workflows/codeql.yml"
+EXPECTED_JOB_ID = "codeql-analyze"
+
+
+def _parse_workflow():
+    """Reuse the repo's own stdlib workflow parser (no YAML dep in the lint set)."""
+    script = ROOT / "scripts" / "check_required_checks.py"
+    spec = importlib.util.spec_from_file_location("check_required_checks_for_key",
+                                                  script)
+    mod = importlib.util.module_from_spec(spec)
+    assert spec.loader is not None
+    spec.loader.exec_module(mod)
+    return mod.parse_workflow(WORKFLOW)
+
+
+class TestAnalysisKeyIsStable:
+    def test_the_workflow_lives_where_the_key_says_it_does(self):
+        assert WORKFLOW.is_file()
+        assert WORKFLOW.relative_to(ROOT).as_posix() == EXPECTED_WORKFLOW
+
+    def test_the_codeql_job_id_is_pinned(self):
+        _, _, jobs = _parse_workflow()
+        assert EXPECTED_JOB_ID in jobs, (
+            "the CodeQL job id changed to %r. That forks the code-scanning "
+            "configuration: GitHub keeps '%s:%s' on record as present on the "
+            "default branch, nothing refreshes it, and merge protection reports "
+            "'1 configuration not found' -> neutral on every PR from now on. "
+            "Delete the stale configuration before landing the rename."
+            % (sorted(jobs), EXPECTED_WORKFLOW, EXPECTED_JOB_ID))
+
+    def test_exactly_one_job_produces_the_key(self):
+        # A second job in this file would add a second configuration, and every
+        # one of them has to keep reporting or merge protection goes neutral
+        # again. Adding one is a deliberate act, not a drive-by edit.
+        _, _, jobs = _parse_workflow()
+        assert list(jobs) == [EXPECTED_JOB_ID], sorted(jobs)
+
+
+class TestTheGuardActuallyParses:
+    """A parser that silently stops matching would make the pin vacuous."""
+
+    def test_parser_finds_jobs_at_all(self):
+        _, _, jobs = _parse_workflow()
+        assert jobs, "parsed no jobs out of codeql.yml — the guard is not checking anything"
+
+    def test_workflow_still_runs_on_pull_request(self):
+        # The key is only ever exercised on PRs; a workflow that stopped
+        # triggering there would strand the configuration just as effectively.
+        on_pr, _, _ = _parse_workflow()
+        assert on_pr != "none", "codeql.yml no longer runs on pull_request"