boost-skill-cli 1.0.303__tar.gz → 1.0.304__tar.gz

{boost_skill_cli-1.0.303/boost_skill_cli.egg-info → boost_skill_cli-1.0.304}/PKG-INFO

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

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.304}/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.303'
-__version_tuple__ = version_tuple = (1, 0, 303)
+__version__ = version = '1.0.304'
+__version_tuple__ = version_tuple = (1, 0, 304)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.304/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.304}/docs/roadmap/items/dependabot-root-pip-entry-duplicates-requirements.md

@@ -2,15 +2,15 @@
 id: dependabot-root-pip-entry-duplicates-requirements
 board: code
 section: internals
-status: planned
+status: shipped
 category: Build · Gap
 complexity: S
 impact: Low
 wow: 1
 note: fallout from #289 — every toolchain bump now arrives twice
 order: 35
-owner:
-pr:
+owner: loop/dependabot-root-narrow
+pr: 349
 title: Dependabot raises every toolchain bump <em>twice</em>
 ---
 PR #289 added a third Dependabot entry, <code>package-ecosystem: pip</code> with
@@ -43,3 +43,24 @@ Dependabot's file discovery is what got this wrong in the first place. <b>First<
 extras bumps are genuinely wanted, that needs <code>versioning-strategy: increase</code> so open
 lower bounds are raised at all; otherwise accept that this entry is security-only and say so in the
 comment, which is the honest smaller change.
+
+<b>Shipped &mdash; the second one, and <code>#342</code> changed why.</b> That change gave
+<code>/requirements</code> <code>open-pull-requests-limit: 0</code>, which silences the duplicate on
+one side but leaves the <code>/</code> entry as the <em>only</em> remaining path to a
+lock-regenerating pull request &mdash; precisely the thing that cannot be done correctly on a single
+platform. The duplicate stopped being the problem and the survivor became one.
+
+So the version-update side of the <code>/</code> entry is off too, and the reasoning is now written
+where the next person will look. It produces nothing wanted: every constraint under
+<code>[project.optional-dependencies]</code> is an open lower bound or sits in the entry's own
+ignore list, so its set of possible <code>pyproject.toml</code> version updates is <b>empty</b>
+&mdash; none of the eight PRs in that first run touched it. And it produces one thing actively
+harmful: four of those eight were byte-identical lock regenerations. <b>Security</b> updates ignore
+the limit and keep firing, which is the coverage the extras genuinely gained, and
+<code>lock_toolchain.py --audit</code> now catches a security PR that arrives having dropped a
+marker-gated pin.
+
+Both pip entries are pinned at <code>limit: 0</code> by
+<code>tests/unit/test_dependabot_config.py</code>, alongside an assertion that neither entry is
+<em>deleted</em> &mdash; removing them would give up the security coverage that is the whole
+remaining point. Related: [[dependabot-regeneration-drops-platform-pins]].

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.304}/docs/roadmap.html

@@ -1162,7 +1162,7 @@ every enabled agent. So narrowing is honoured and the newly-enabled-agent path i
       </article>
 
       <article class="cap rcard" id="dependabot-root-pip-entry-duplicates-requirements">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Build · Gap</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Build · Gap</span></div>
         <h3>Dependabot raises every toolchain bump <em>twice</em></h3>
         <p>PR #289 added a third Dependabot entry, <code>package-ecosystem: pip</code> with
 <code>directory: /</code>, to give <code>pyproject.toml</code>'s optional extras the proactive bump
@@ -1193,7 +1193,28 @@ Dependabot's file discovery is what got this wrong in the first place. <b>First<
 <code>/requirements</code> as the single owner of the hash-pinned lock. <b>Second</b>, if proactive
 extras bumps are genuinely wanted, that needs <code>versioning-strategy: increase</code> so open
 lower bounds are raised at all; otherwise accept that this entry is security-only and say so in the
-comment, which is the honest smaller change.</p>
+comment, which is the honest smaller change.
+
+<b>Shipped &mdash; the second one, and <code>#342</code> changed why.</b> That change gave
+<code>/requirements</code> <code>open-pull-requests-limit: 0</code>, which silences the duplicate on
+one side but leaves the <code>/</code> entry as the <em>only</em> remaining path to a
+lock-regenerating pull request &mdash; precisely the thing that cannot be done correctly on a single
+platform. The duplicate stopped being the problem and the survivor became one.
+
+So the version-update side of the <code>/</code> entry is off too, and the reasoning is now written
+where the next person will look. It produces nothing wanted: every constraint under
+<code>[project.optional-dependencies]</code> is an open lower bound or sits in the entry's own
+ignore list, so its set of possible <code>pyproject.toml</code> version updates is <b>empty</b>
+&mdash; none of the eight PRs in that first run touched it. And it produces one thing actively
+harmful: four of those eight were byte-identical lock regenerations. <b>Security</b> updates ignore
+the limit and keep firing, which is the coverage the extras genuinely gained, and
+<code>lock_toolchain.py --audit</code> now catches a security PR that arrives having dropped a
+marker-gated pin.
+
+Both pip entries are pinned at <code>limit: 0</code> by
+<code>tests/unit/test_dependabot_config.py</code>, alongside an assertion that neither entry is
+<em>deleted</em> &mdash; removing them would give up the security coverage that is the whole
+remaining point. Related: [[dependabot-regeneration-drops-platform-pins]].</p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Low</b></span>

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.304}/tests/unit/test_dependabot_config.py

@@ -104,3 +104,61 @@ def test_the_root_ignore_list_matches_the_ceilings_pyproject_sets():
                  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
+
+
+def limit_for(directory: str):
+    """The `open-pull-requests-limit` of the pip entry for `directory`, or None.
+
+    Parsed separately rather than by widening `entries()`, which several tests
+    unpack positionally.
+    """
+    seen = None
+    for line in CONFIG.read_text(encoding="utf-8").splitlines():
+        m = _ENTRY.match(line)
+        if m:
+            seen = {"eco": m.group(1)}
+            continue
+        if seen is None:
+            continue
+        m = _FIELD.match(line)
+        if not m:
+            continue
+        seen[m.group(1)] = m.group(2)
+        if seen.get("directory") == directory and seen["eco"] == "pip" \
+                and "open-pull-requests-limit" in seen:
+            return int(seen["open-pull-requests-limit"])
+    return None
+
+
+class TestNeitherPipEntryRegeneratesTheLock:
+    """Dependabot must not raise *version* updates for either pip entry.
+
+    Not a preference — it cannot regenerate the hash-pinned locks correctly. It
+    re-resolves on Linux and commits that resolution, dropping every pin whose
+    environment marker excludes it there, and the locks install with
+    --require-hashes on Windows and macOS too. `scripts/lock_toolchain.py`
+    resolves --universal for every supported platform, which is why it is the
+    source of truth (see its `-P` flag, and requirements/platform-pins.lock).
+
+    `open-pull-requests-limit: 0` disables version updates while leaving
+    **security** updates firing, which is what these entries are actually worth.
+    """
+
+    def test_the_requirements_entry_raises_no_version_prs(self):
+        assert limit_for("/requirements") == 0
+
+    def test_the_root_entry_raises_no_version_prs(self):
+        # The root entry cannot deliver what it was added for: every constraint
+        # under [project.optional-dependencies] is either an open lower bound or
+        # in its own ignore list, so the set of pyproject version updates it can
+        # ever produce is EMPTY — none of the eight PRs in the first scheduled
+        # run touched pyproject.toml. What it did produce was byte-identical
+        # duplicates of the /requirements entry's lock regenerations, which is
+        # the one thing that must never be merged.
+        assert limit_for("/") == 0
+
+    def test_both_pip_entries_still_exist(self):
+        # Deleting them would give up security updates too, which ignore the
+        # limit and are the coverage these entries genuinely provide.
+        assert pip_entry("/requirements")
+        assert pip_entry("/")