boost-skill-cli 1.0.210__tar.gz → 1.0.212__tar.gz

{boost_skill_cli-1.0.210/boost_skill_cli.egg-info → boost_skill_cli-1.0.212}/PKG-INFO

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

{boost_skill_cli-1.0.210 → boost_skill_cli-1.0.212}/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.210'
-__version_tuple__ = version_tuple = (1, 0, 210)
+__version__ = version = '1.0.212'
+__version_tuple__ = version_tuple = (1, 0, 212)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.210 → boost_skill_cli-1.0.212/boost_skill_cli.egg-info}/PKG-INFO

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

boost_skill_cli-1.0.212/docs/roadmap/items/bring-commands-under-mutation-testing.md

@@ -0,0 +1,34 @@
+---
+id: bring-commands-under-mutation-testing
+board: code
+section: planned
+status: planned
+category: Testing · Gap
+complexity: XL
+impact: High
+wow: 3
+note: 
+order: 2
+owner:
+pr:
+title: Bring <code>commands/</code> under mutation testing
+---
+The ~8,100-line command layer has <strong>zero</strong> mutation coverage: mutmut is
+           scoped to <code>core/</code> only. Measurements taken before attempting it, so the
+           next attempt starts from data rather than re-deriving it:
+           <code>commands/</code> is 8,122 lines against <code>core/</code>'s 8,289, and
+           <code>core/</code> generates <strong>9,909</strong> mutants — so expect ~10,000
+           more, roughly <em>doubling</em> the ~18-minute mutation job that is already the
+           long pole before every release. Three constraints found the hard way:
+           mutmut's <code>pytest_add_cli_args_test_selection</code> is <em>single-valued</em>
+           (<code>tests/unit/ tests/functional/</code> is passed as one path and errors — it
+           has to be <code>tests/</code>); <code>commands/</code> is covered by
+           <code>tests/functional</code> (61s) not <code>tests/unit</code> (12s), so
+           per-mutant cost rises about 5&#215;; and mutmut must run that suite <em>inside</em>
+           <code>mutants/</code>, which needs <code>docs/</code>, <code>style/</code>,
+           <code>README.md</code> and the root redirect added to <code>also_copy</code> —
+           a missing tree fails baseline <em>collection</em> and surfaces as "mutmut run
+           failed to execute", pointing nowhere near the cause. Deliberately not shipped as a
+           blocking gate until the baseline kill rate has actually been measured: this gate
+           runs on every release, and setting a floor without ever seeing the number is how
+           you red-line main.

{boost_skill_cli-1.0.210 → boost_skill_cli-1.0.212}/docs/roadmap.html

@@ -478,9 +478,25 @@ message, so routing it through the helper would change user-facing errors.</p>
       <article class="cap rcard" id="bring-commands-under-mutation-testing">
         <div class="head"><span class="pill planned">Planned</span><span class="cat">Testing · Gap</span></div>
         <h3>Bring <code>commands/</code> under mutation testing</h3>
-        <p>The ~5,000-line CLI command layer has <strong>zero</strong> mutation
-           coverage today — mutmut is scoped to <code>core/</code> only. Extend
-           the gate (or a second gate) to the command groups.</p>
+        <p>The ~8,100-line command layer has <strong>zero</strong> mutation coverage: mutmut is
+           scoped to <code>core/</code> only. Measurements taken before attempting it, so the
+           next attempt starts from data rather than re-deriving it:
+           <code>commands/</code> is 8,122 lines against <code>core/</code>'s 8,289, and
+           <code>core/</code> generates <strong>9,909</strong> mutants — so expect ~10,000
+           more, roughly <em>doubling</em> the ~18-minute mutation job that is already the
+           long pole before every release. Three constraints found the hard way:
+           mutmut's <code>pytest_add_cli_args_test_selection</code> is <em>single-valued</em>
+           (<code>tests/unit/ tests/functional/</code> is passed as one path and errors — it
+           has to be <code>tests/</code>); <code>commands/</code> is covered by
+           <code>tests/functional</code> (61s) not <code>tests/unit</code> (12s), so
+           per-mutant cost rises about 5&#215;; and mutmut must run that suite <em>inside</em>
+           <code>mutants/</code>, which needs <code>docs/</code>, <code>style/</code>,
+           <code>README.md</code> and the root redirect added to <code>also_copy</code> —
+           a missing tree fails baseline <em>collection</em> and surfaces as "mutmut run
+           failed to execute", pointing nowhere near the cause. Deliberately not shipped as a
+           blocking gate until the baseline kill rate has actually been measured: this gate
+           runs on every release, and setting a floor without ever seeing the number is how
+           you red-line main.</p>
         <div class="meta">
           <span class="m">Complexity <b>XL</b></span>
           <span class="m hi">Impact <b>High</b></span>

{boost_skill_cli-1.0.210 → boost_skill_cli-1.0.212}/scripts/lock_toolchain.py

@@ -41,6 +41,7 @@ import re
 import shutil
 import subprocess
 import sys
+import tempfile
 from pathlib import Path
 
 ROOT = Path(__file__).resolve().parent.parent
@@ -101,19 +102,39 @@ def _uv() -> str:
 
 
 def compile_group(stem: str, python_version: str, upgrade: bool) -> str:
-    """Resolve one group and return the file contents we want on disk."""
-    # No `-o`: uv writes the resolution to stdout by default. Passing `-o -`
-    # streams to stdout *and* creates a file literally named "-" in the cwd.
-    cmd = [_uv(), "pip", "compile", str(REQS / ("%s.in" % stem)),
-           "--generate-hashes", "--universal",
-           "--python-version", python_version, "--no-header"]
-    if upgrade:
-        cmd.append("--upgrade")
-    proc = subprocess.run(cmd, capture_output=True, text=True, cwd=ROOT)
-    if proc.returncode != 0:
-        sys.stderr.write(proc.stderr)
-        raise SystemExit("lock_toolchain: `uv pip compile` failed for %s" % stem)
-    body = _UV_HEADER.sub("", proc.stdout).lstrip("\n")
+    """Resolve one group and return the file contents we want on disk.
+
+    Resolution is deliberately NOT "newest that satisfies the .in". uv treats an
+    existing ``--output-file`` as the preferred solution and keeps those pins
+    unless a declaration forces a change, so the compile is *stable*: it
+    reproduces the committed lock byte-for-byte until someone edits the .in or
+    passes ``--upgrade``.
+
+    That distinction is the whole gate. Compiling to stdout instead re-resolves
+    against the live index every time, so any upstream release makes the
+    committed lock "stale" and reddens `lint` on unrelated PRs with no code
+    change — which is precisely the failure mode requirements/lint-tools.in's
+    header was written about. (It happened: three groups went STALE overnight.)
+    """
+    target = REQS / ("%s.txt" % stem)
+    # Compile into a scratch copy of the committed lock so uv can read the
+    # current pins and prefer them, without touching the real file until the
+    # caller decides to write it.
+    with tempfile.TemporaryDirectory() as tmp:
+        scratch = Path(tmp) / target.name
+        if target.exists():
+            shutil.copyfile(target, scratch)
+        cmd = [_uv(), "pip", "compile", str(REQS / ("%s.in" % stem)),
+               "--generate-hashes", "--universal",
+               "--python-version", python_version, "--no-header",
+               "--output-file", str(scratch)]
+        if upgrade:
+            cmd.append("--upgrade")
+        proc = subprocess.run(cmd, capture_output=True, text=True, cwd=ROOT)
+        if proc.returncode != 0:
+            sys.stderr.write(proc.stderr)
+            raise SystemExit("lock_toolchain: `uv pip compile` failed for %s" % stem)
+        body = _UV_HEADER.sub("", scratch.read_text(encoding="utf-8")).lstrip("\n")
     return _header(stem, python_version) + body
 
 

{boost_skill_cli-1.0.210 → boost_skill_cli-1.0.212}/tests/unit/test_toolchain_lock.py

@@ -135,3 +135,35 @@ class TestEvalExtraStaysOut:
             for forbidden in ("langchain", "ragas", "ranx"):
                 assert forbidden not in text, \
                     "%s locks the opt-in [eval] stack (%s)" % (stem, forbidden)
+
+
+class TestCompileIsStable:
+    """The compile must reproduce the committed lock, not chase the newest release.
+
+    uv treats an existing `--output-file` as the preferred solution and keeps
+    those pins unless a declaration forces a change. Compiling to stdout instead
+    re-resolves against the live index, so any upstream release makes the
+    committed lock "stale" and reddens `lint` on unrelated PRs with no code
+    change — the exact failure mode requirements/lint-tools.in's header warns
+    about, and one this gate hit within a day of landing.
+
+    This asserts the mechanism rather than running uv (which needs the network):
+    a resolver invoked without an output file to read cannot be stable.
+    """
+
+    def test_compile_passes_output_file_so_uv_reads_current_pins(self):
+        src = (ROOT / "scripts" / "lock_toolchain.py").read_text(encoding="utf-8")
+        assert "--output-file" in src, \
+            "compile_group must give uv the committed lock to prefer"
+
+    def test_compile_seeds_the_scratch_file_from_the_committed_lock(self):
+        # Copying the committed .txt into the scratch path is what makes uv
+        # prefer the existing pins; without the copy the flag achieves nothing.
+        src = (ROOT / "scripts" / "lock_toolchain.py").read_text(encoding="utf-8")
+        assert "shutil.copyfile(target, scratch)" in src
+
+    def test_upgrade_is_the_only_way_to_re_resolve(self):
+        src = (ROOT / "scripts" / "lock_toolchain.py").read_text(encoding="utf-8")
+        assert '"--upgrade"' in src
+        # --check must never imply --upgrade, or the gate becomes non-deterministic
+        assert "--check and --upgrade are exclusive" in src

boost_skill_cli-1.0.210/docs/roadmap/items/bring-commands-under-mutation-testing.md

@@ -1,18 +0,0 @@
----
-id: bring-commands-under-mutation-testing
-board: code
-section: planned
-status: planned
-category: Testing · Gap
-complexity: XL
-impact: High
-wow: 3
-note: 
-order: 2
-owner:
-pr:
-title: Bring <code>commands/</code> under mutation testing
----
-The ~5,000-line CLI command layer has <strong>zero</strong> mutation
-           coverage today — mutmut is scoped to <code>core/</code> only. Extend
-           the gate (or a second gate) to the command groups.