boost-skill-cli 1.0.254__tar.gz → 1.0.256__tar.gz

{boost_skill_cli-1.0.254 → boost_skill_cli-1.0.256}/PKG-INFO

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

{boost_skill_cli-1.0.254 → boost_skill_cli-1.0.256}/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.254'
-__version_tuple__ = version_tuple = (1, 0, 254)
+__version__ = version = '1.0.256'
+__version_tuple__ = version_tuple = (1, 0, 256)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.254 → boost_skill_cli-1.0.256}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.0.254 → boost_skill_cli-1.0.256}/boost_skill_cli.egg-info/SOURCES.txt

@@ -431,6 +431,7 @@ tests/unit/test_command_reference_fresh.py
 tests/unit/test_config.py
 tests/unit/test_dense.py
 tests/unit/test_dense_fallback.py
+tests/unit/test_dependabot_config.py
 tests/unit/test_docs_pages_linked.py
 tests/unit/test_docsite_chrome.py
 tests/unit/test_ed25519.py

boost_skill_cli-1.0.256/docs/roadmap/items/sbom-release-event-never-fires.md

@@ -0,0 +1,54 @@
+---
+id: sbom-release-event-never-fires
+board: code
+section: trust
+status: shipped
+category: Supply chain
+complexity: S
+impact: High
+wow: 4
+note: 253 releases shipped with no SBOM; fixed with workflow_run
+order: 50
+owner:
+pr: 295
+title: <code>sbom.yml</code> has never run — it waits for an event <code>GITHUB_TOKEN</code> cannot emit
+---
+<code>sbom.yml</code> triggers on <code>release: types: [published]</code> and promises
+"a CycloneDX SBOM for every release, attached to the GitHub Release as an asset".
+It has <b>0 runs</b>. Releases here are created by <code>release-drafter</code> inside
+<code>publish.yml</code> authenticated with <code>GITHUB_TOKEN</code>, and <b>events created
+with <code>GITHUB_TOKEN</code> do not trigger workflows</b>. <code>publish.yml</code>'s own
+header states that rule verbatim — "we never rely on the release event to trigger a second
+workflow" — and <code>sbom.yml</code> is exactly that pattern.
+
+So the <code>if: github.event_name == 'release'</code> guard on its upload step is dead code,
+<code>workflow_dispatch</code> is the only reachable path and has never been used, and every
+one of the last ten releases carries <code>assets: []</code>. Zero SBOMs have been produced
+since the file landed on 2026-07-22. Same shape as the LangGraph conformance leg: wired up,
+looks covered, never executed once.
+
+By the time it was fixed the count was <b>253 releases, 0 runs, 0 SBOM assets</b>.
+
+<b>Fixed with a third option neither branch of that decision considered:</b>
+<code>workflow_run</code>. The <code>GITHUB_TOKEN</code> restriction applies to
+<em>events</em> a token creates; <code>workflow_run</code> is documented as exempt and fires
+on the upstream <em>run</em> completing regardless of what triggered it &mdash; which is
+already how <code>ci &rarr; release</code> works in this repo. Chaining
+<code>release &rarr; sbom</code> makes this the third link, inside GitHub's documented
+three-level <code>workflow_run</code> limit. So no PAT is needed, and the SBOM logic stays
+out of <code>publish.yml</code>.
+
+That separation turned out to matter more than "keeps the logic in its own file":
+<code>publish.yml</code>'s job holds PyPI Trusted-Publishing OIDC credentials, and generating
+the SBOM means installing a third-party build plugin (<code>cyclonedx-bom</code>). Inlining it
+would have put that plugin inside the one job that can publish to PyPI. Kept separate, it
+holds only <code>contents: write</code>.
+
+Two details the trigger change forced. The workflow now resolves its tag from the release
+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
+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.254 → boost_skill_cli-1.0.256}/docs/roadmap.html

@@ -3520,7 +3520,7 @@ is built.</p>
       </article>
 
       <article class="cap rcard" id="sbom-release-event-never-fires">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Supply chain</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Supply chain</span></div>
         <h3><code>sbom.yml</code> has never run — it waits for an event <code>GITHUB_TOKEN</code> cannot emit</h3>
         <p><code>sbom.yml</code> triggers on <code>release: types: [published]</code> and promises
 "a CycloneDX SBOM for every release, attached to the GitHub Release as an asset".
@@ -3536,17 +3536,36 @@ one of the last ten releases carries <code>assets: []</code>. Zero SBOMs have be
 since the file landed on 2026-07-22. Same shape as the LangGraph conformance leg: wired up,
 looks covered, never executed once.
 
-Fix is a decision, not a patch: either build and attach the SBOM inside
-<code>publish.yml</code>'s release job (it already holds <code>contents: write</code> and is
-where the tag is cut), or have <code>publish.yml</code> dispatch this workflow with a PAT
-rather than <code>GITHUB_TOKEN</code>. The first is simpler and keeps the release atomic;
-the second keeps the SBOM logic in its own file. Worth pairing with a check that fails the
-release when the asset is missing, so "never ran" cannot recur silently.</p>
+By the time it was fixed the count was <b>253 releases, 0 runs, 0 SBOM assets</b>.
+
+<b>Fixed with a third option neither branch of that decision considered:</b>
+<code>workflow_run</code>. The <code>GITHUB_TOKEN</code> restriction applies to
+<em>events</em> a token creates; <code>workflow_run</code> is documented as exempt and fires
+on the upstream <em>run</em> completing regardless of what triggered it &mdash; which is
+already how <code>ci &rarr; release</code> works in this repo. Chaining
+<code>release &rarr; sbom</code> makes this the third link, inside GitHub's documented
+three-level <code>workflow_run</code> limit. So no PAT is needed, and the SBOM logic stays
+out of <code>publish.yml</code>.
+
+That separation turned out to matter more than "keeps the logic in its own file":
+<code>publish.yml</code>'s job holds PyPI Trusted-Publishing OIDC credentials, and generating
+the SBOM means installing a third-party build plugin (<code>cyclonedx-bom</code>). Inlining it
+would have put that plugin inside the one job that can publish to PyPI. Kept separate, it
+holds only <code>contents: write</code>.
+
+Two details the trigger change forced. The workflow now resolves its tag from the release
+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
+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>
         <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">0 runs, 0 SBOMs, 227 releases</span>
+          <span class="m">253 releases shipped with no SBOM; fixed with workflow_run</span>
         </div>
       </article>
 

boost_skill_cli-1.0.256/tests/unit/test_dependabot_config.py

@@ -0,0 +1,106 @@
+"""Unit test: .github/dependabot.yml — what actually gets bump PRs.
+
+Dependabot only scans manifests under an entry's declared ``directory``, so
+"we have a pip entry" says nothing about which manifests are covered. This
+pins the two that matter (``/requirements`` for the hash-pinned toolchain, ``/``
+for ``pyproject.toml``'s extras) and ties the root entry's ignore list to the
+version ceilings pyproject actually sets — so lifting a ceiling and leaving a
+stale ignore behind fails here rather than silently costing us the bump PRs.
+
+Read by hand rather than with a YAML parser: PyYAML is not a dependency of this
+repo, and ``scripts/check_required_checks.py`` sets the same precedent for
+workflow YAML.
+"""
+from __future__ import annotations
+
+import re
+import sys
+from pathlib import Path
+
+import pytest
+
+ROOT = Path(__file__).resolve().parents[2]
+CONFIG = ROOT / ".github" / "dependabot.yml"
+PYPROJECT = ROOT / "pyproject.toml"
+
+pytestmark = pytest.mark.skipif(
+    not CONFIG.exists(),
+    reason="repo-root .github/dependabot.yml not reachable (e.g. mutation sandbox)")
+
+_ENTRY = re.compile(r"^  - package-ecosystem:\s*(\S+)\s*$")
+_FIELD = re.compile(r"^    (\w[\w-]*):\s*(\S*)\s*$")
+_IGNORE = re.compile(r"^      - dependency-name:\s*(\S+)\s*$")
+
+
+def entries():
+    """[(ecosystem, directory, [ignored dependency names])] in file order."""
+    out = []
+    for line in CONFIG.read_text(encoding="utf-8").splitlines():
+        m = _ENTRY.match(line)
+        if m:
+            out.append((m.group(1), None, []))
+            continue
+        if not out:
+            continue
+        eco, _directory, ignored = out[-1]
+        m = _FIELD.match(line)
+        if m and m.group(1) == "directory":
+            out[-1] = (eco, m.group(2), ignored)
+            continue
+        m = _IGNORE.match(line)
+        if m:
+            ignored.append(m.group(1))
+    return out
+
+
+def pip_entry(directory: str):
+    matches = [e for e in entries() if e[0] == "pip" and e[1] == directory]
+    assert len(matches) == 1, "expected exactly one pip entry for %r" % directory
+    return matches[0]
+
+
+def test_every_entry_declares_a_directory():
+    # An entry with no directory silently defaults to /, which would make one
+    # of these a duplicate of another rather than the coverage it looks like.
+    assert entries(), "no update entries parsed — has the file's shape changed?"
+    for eco, directory, _ignored in entries():
+        assert directory, "%s entry has no directory" % eco
+
+
+def test_the_pinned_toolchain_is_covered():
+    # requirements/*.txt are hash-pinned; a pin with no update path is only
+    # half the job, so this entry is what stops the lock silently rotting.
+    assert pip_entry("/requirements")[1] == "/requirements"
+
+
+def test_pyprojects_extras_are_covered():
+    # The bug this file was added for: only /requirements was declared, so
+    # pyproject.toml at the repo root was never scanned and [rag]/[bdd]/[perf]
+    # got no proactive bumps at all — only reactive pip-audit CVE flags.
+    assert pip_entry("/")[1] == "/"
+
+
+def test_the_actions_workflows_are_covered():
+    assert [e for e in entries() if e[0] == "github-actions"], \
+        "workflow action versions are a supply-chain surface too"
+
+
+@pytest.mark.skipif(sys.version_info < (3, 11),
+                    reason="tomllib is stdlib only on Python 3.11+")
+def test_the_root_ignore_list_matches_the_ceilings_pyproject_sets():
+    """Ignore exactly the packages pyproject deliberately holds back.
+
+    ragas 0.2.x hard-imports a ChatVertexAI path that langchain>=1.0 removed,
+    so the [eval] stack carries upper bounds and a bump PR there cannot be
+    merged. Ignoring them is why declaring ``directory: /`` is safe at all.
+    Anything held back but *not* ignored raises unmergeable PRs; anything
+    ignored but no longer held back silently costs us a bump we could take.
+    """
+    import tomllib
+
+    with open(PYPROJECT, "rb") as f:
+        extras = tomllib.load(f)["project"]["optional-dependencies"]
+    held_back = {re.split(r"[<>=!~\[]", req, maxsplit=1)[0].strip()
+                 for reqs in extras.values() for req in reqs if "<" in req}
+    assert held_back, "no upper bounds left in pyproject — drop the ignores"
+    assert set(pip_entry("/")[2]) == held_back

boost_skill_cli-1.0.254/docs/roadmap/items/sbom-release-event-never-fires.md

@@ -1,35 +0,0 @@
----
-id: sbom-release-event-never-fires
-board: code
-section: trust
-status: planned
-category: Supply chain
-complexity: S
-impact: High
-wow: 4
-note: 0 runs, 0 SBOMs, 227 releases
-order: 50
-owner:
-pr:
-title: <code>sbom.yml</code> has never run — it waits for an event <code>GITHUB_TOKEN</code> cannot emit
----
-<code>sbom.yml</code> triggers on <code>release: types: [published]</code> and promises
-"a CycloneDX SBOM for every release, attached to the GitHub Release as an asset".
-It has <b>0 runs</b>. Releases here are created by <code>release-drafter</code> inside
-<code>publish.yml</code> authenticated with <code>GITHUB_TOKEN</code>, and <b>events created
-with <code>GITHUB_TOKEN</code> do not trigger workflows</b>. <code>publish.yml</code>'s own
-header states that rule verbatim — "we never rely on the release event to trigger a second
-workflow" — and <code>sbom.yml</code> is exactly that pattern.
-
-So the <code>if: github.event_name == 'release'</code> guard on its upload step is dead code,
-<code>workflow_dispatch</code> is the only reachable path and has never been used, and every
-one of the last ten releases carries <code>assets: []</code>. Zero SBOMs have been produced
-since the file landed on 2026-07-22. Same shape as the LangGraph conformance leg: wired up,
-looks covered, never executed once.
-
-Fix is a decision, not a patch: either build and attach the SBOM inside
-<code>publish.yml</code>'s release job (it already holds <code>contents: write</code> and is
-where the tag is cut), or have <code>publish.yml</code> dispatch this workflow with a PAT
-rather than <code>GITHUB_TOKEN</code>. The first is simpler and keeps the release atomic;
-the second keeps the SBOM logic in its own file. Worth pairing with a check that fails the
-release when the asset is missing, so "never ran" cannot recur silently.