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

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

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

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

{boost_skill_cli-1.0.280 → 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
@@ -442,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.280 → 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>172</b><span>Loop finds</span></div>
+      <div class="stat"><b>173</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -4014,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>

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"