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

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

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

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

{boost_skill_cli-1.0.302 → boost_skill_cli-1.0.304}/boost_skill_cli.egg-info/SOURCES.txt

@@ -248,6 +248,7 @@ docs/roadmap/items/mcp-install-skips-the-injection-scan.md
 docs/roadmap/items/mcp-launch-objc-fork-safety.md
 docs/roadmap/items/mcp-register-names-server-before-env.md
 docs/roadmap/items/mcp-search-before-reinventing.md
+docs/roadmap/items/mcp-servers-ignore-install-scope.md
 docs/roadmap/items/mcp-startup-self-harden-fork-safety.md
 docs/roadmap/items/memoize-config-load-in-process.md
 docs/roadmap/items/merge-queue-would-deadlock-most-required-checks.md

{boost_skill_cli-1.0.302 → 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.304/docs/roadmap/items/mcp-servers-ignore-install-scope.md

@@ -0,0 +1,70 @@
+---
+id: mcp-servers-ignore-install-scope
+board: code
+section: dx
+status: planned
+category: Bug · MCP
+complexity: M
+impact: High
+wow: 4
+note: --scope project installs the skill into the repo and its MCP server machine-wide
+order: 14
+owner:
+pr:
+title: A project-scoped install registers its MCP servers <em>machine-wide</em>
+---
+<code>boost install &lt;skill&gt; --scope project</code> (or <code>--here</code>) is a promise about
+blast radius: the skill lands inside this repo, committable, affecting nobody else's machine. The
+MCP servers that skill declares do not keep that promise. They are registered at <b>user</b> scope
+&mdash; globally, for every repo you open &mdash; whatever scope the skill itself was installed at.
+
+The path is short and the gap is a missing argument. <code>_offer_mcp()</code> in
+<code>commands/pkg.py</code> receives the whole <code>InstallResult</code>, so
+<code>res.scope</code> is right there, and never reads it. It calls
+<code>_register_mcp_server(name, spec, host)</code>, which takes no scope parameter at all, so
+<code>mcpdecl.register_argv()</code> falls to its <code>scope="user"</code> default and boost shells
+out <code>claude mcp add &lt;name&gt; --scope user …</code>. Nothing warns that the scope the user
+asked for was not the scope they got.
+
+<b>The repo-local machinery is already written, and nothing calls it.</b>
+<code>mcpdecl.merge_into(existing, rows, skill)</code> merges declared servers into an
+<code>.mcp.json</code> document &mdash; the committable, project-scoped file agents already read
+(<code>mcpdecl.SIDECAR</code>). It returns a new document rather than mutating, never overwrites a
+server the user configured by hand, and stamps each entry it adds with a <code>MARKER_KEY</code>
+naming the skill that asked for it, precisely so a later uninstall can remove what boost wrote and
+nothing else. It is covered by nine assertions in <code>tests/unit/test_mcpdecl.py</code> and has
+<b>zero callers in <code>boost_cli/</code></b>. The install path shells out to the host CLI instead.
+
+That marker matters because of the second half of the bug: <b><code>uninstall</code> never
+unregisters anything.</b> Removing a skill sweeps its files and its symlinks and leaves the MCP
+server registered, so a skill you installed once to try out keeps launching for every project you
+open afterwards. Wiring <code>merge_into</code> gives cleanup something exact to reverse, which
+shelling out to <code>mcp add</code> does not.
+
+What the fix has to get right:
+
+<b>Scope must flow, not be re-derived.</b> Thread <code>res.scope</code> from
+<code>_offer_mcp</code> through <code>_register_mcp_server</code> into
+<code>register_argv(..., scope=…)</code>. Both call sites of
+<code>store.declared_mcp_servers</code> (the user-scope and project-scope install paths in
+<code>core/store.py</code>) already know their scope; the command layer is where it gets dropped.
+
+<b>Project scope should write the file, not shell out.</b> A registration that lives in
+<code>.mcp.json</code> is reviewable in a diff, committable, and shared with the team &mdash; which
+is the whole point of <code>--scope project</code>. Shelling out to <code>mcp add --scope
+project</code> would work for a host that supports it, but produces nothing to review and re-opens
+the per-host grammar problem <code>core/mcphost.py</code> exists to contain.
+
+<b>Uninstall has to reverse exactly what was written.</b> Marker-keyed entries only &mdash; a
+server the user added by hand, or one another skill declared, must survive. Note the asymmetry
+already documented in <code>core/mcphost.py</code>: <code>claude mcp remove</code> finds a
+user-scope server unaided, while <code>gemini mcp remove</code> defaults to project scope and will
+report "not found in project settings" while leaving the user-scope entry in place. Removal needs
+the scope it was registered at, which is another reason to record it rather than guess.
+
+<b>The prompt should say where.</b> Today it asks "register N servers with Claude Code now?" and
+names no scope. It should say which file or scope is about to change, because that is the decision
+being made.
+
+Related: [[mcp-aware-skills]] (which added the declaration format),
+[[mcp-install-skips-the-injection-scan]] and [[mcp-register-names-server-before-env]].

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

@@ -111,7 +111,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>180</b><span>Loop finds</span></div>
+      <div class="stat"><b>181</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -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>
@@ -3151,6 +3172,72 @@ suite only runs if a human remembers to run it locally, so a CLI change that bre
         </div>
       </article>
 
+      <article class="cap rcard" id="mcp-servers-ignore-install-scope">
+        <div class="head"><span class="pill planned">Planned</span><span class="cat">Bug · MCP</span></div>
+        <h3>A project-scoped install registers its MCP servers <em>machine-wide</em></h3>
+        <p><code>boost install &lt;skill&gt; --scope project</code> (or <code>--here</code>) is a promise about
+blast radius: the skill lands inside this repo, committable, affecting nobody else's machine. The
+MCP servers that skill declares do not keep that promise. They are registered at <b>user</b> scope
+&mdash; globally, for every repo you open &mdash; whatever scope the skill itself was installed at.
+
+The path is short and the gap is a missing argument. <code>_offer_mcp()</code> in
+<code>commands/pkg.py</code> receives the whole <code>InstallResult</code>, so
+<code>res.scope</code> is right there, and never reads it. It calls
+<code>_register_mcp_server(name, spec, host)</code>, which takes no scope parameter at all, so
+<code>mcpdecl.register_argv()</code> falls to its <code>scope="user"</code> default and boost shells
+out <code>claude mcp add &lt;name&gt; --scope user …</code>. Nothing warns that the scope the user
+asked for was not the scope they got.
+
+<b>The repo-local machinery is already written, and nothing calls it.</b>
+<code>mcpdecl.merge_into(existing, rows, skill)</code> merges declared servers into an
+<code>.mcp.json</code> document &mdash; the committable, project-scoped file agents already read
+(<code>mcpdecl.SIDECAR</code>). It returns a new document rather than mutating, never overwrites a
+server the user configured by hand, and stamps each entry it adds with a <code>MARKER_KEY</code>
+naming the skill that asked for it, precisely so a later uninstall can remove what boost wrote and
+nothing else. It is covered by nine assertions in <code>tests/unit/test_mcpdecl.py</code> and has
+<b>zero callers in <code>boost_cli/</code></b>. The install path shells out to the host CLI instead.
+
+That marker matters because of the second half of the bug: <b><code>uninstall</code> never
+unregisters anything.</b> Removing a skill sweeps its files and its symlinks and leaves the MCP
+server registered, so a skill you installed once to try out keeps launching for every project you
+open afterwards. Wiring <code>merge_into</code> gives cleanup something exact to reverse, which
+shelling out to <code>mcp add</code> does not.
+
+What the fix has to get right:
+
+<b>Scope must flow, not be re-derived.</b> Thread <code>res.scope</code> from
+<code>_offer_mcp</code> through <code>_register_mcp_server</code> into
+<code>register_argv(..., scope=…)</code>. Both call sites of
+<code>store.declared_mcp_servers</code> (the user-scope and project-scope install paths in
+<code>core/store.py</code>) already know their scope; the command layer is where it gets dropped.
+
+<b>Project scope should write the file, not shell out.</b> A registration that lives in
+<code>.mcp.json</code> is reviewable in a diff, committable, and shared with the team &mdash; which
+is the whole point of <code>--scope project</code>. Shelling out to <code>mcp add --scope
+project</code> would work for a host that supports it, but produces nothing to review and re-opens
+the per-host grammar problem <code>core/mcphost.py</code> exists to contain.
+
+<b>Uninstall has to reverse exactly what was written.</b> Marker-keyed entries only &mdash; a
+server the user added by hand, or one another skill declared, must survive. Note the asymmetry
+already documented in <code>core/mcphost.py</code>: <code>claude mcp remove</code> finds a
+user-scope server unaided, while <code>gemini mcp remove</code> defaults to project scope and will
+report "not found in project settings" while leaving the user-scope entry in place. Removal needs
+the scope it was registered at, which is another reason to record it rather than guess.
+
+<b>The prompt should say where.</b> Today it asks "register N servers with Claude Code now?" and
+names no scope. It should say which file or scope is about to change, because that is the decision
+being made.
+
+Related: [[mcp-aware-skills]] (which added the declaration format),
+[[mcp-install-skips-the-injection-scan]] and [[mcp-register-names-server-before-env]].</p>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">--scope project installs the skill into the repo and its MCP server machine-wide</span>
+        </div>
+      </article>
+
       <article class="cap rcard" id="framework-adapters-boost-adapt">
         <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Interop</span></div>
         <h3><code>boost adapt</code> — render a skill as another framework's agent source</h3>

{boost_skill_cli-1.0.302 → 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("/")