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

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

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

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

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

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

{boost_skill_cli-1.0.301 → boost_skill_cli-1.0.303}/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.303/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.301 → boost_skill_cli-1.0.303}/docs/roadmap/items/mutation-shard-floor-is-one-file.md

@@ -88,8 +88,18 @@ time was apportioned across its functions by <em>mutant count</em>. Across
 <b>14.3&times;</b> &mdash; and <code>install</code> alone is <b>36%</b> of the file's time from
 <b>12%</b> of its mutants, so the shard that drew it ran 8.9 minutes against a 4.8-minute sibling.
 <code>weights</code> now records per-<em>function</em> durations too and apportions on those, which
-balances the plan to <b>0.06%</b>. Whether that closes the wall-clock gap is a claim the next run
-gets to settle, not this card.
+balances the plan to <b>0.06%</b>.
+
+<b>That closed most of the gap.</b> The next run came back at 4.9, 5.6, 6.3, 7.2, 7.3,
+<b>7.7</b>&nbsp;minutes &mdash; a critical path of <b>7.7</b> against a 6.5-minute even share, or
+<b>1.19&times;</b>, from 1.5&ndash;1.9&times; before. Measured end to end, the slowest leg went from
+<b>9.3&ndash;11.7 minutes to 7.7</b>, and the shard that used to be <code>store.py</code> alone now
+finishes first. Total work is unchanged at ~39 job-minutes, as it should be &mdash; this moved the
+work around, it did not remove any.
+
+The remaining 1.19&times; is not packing error. The plan is balanced to 0.06% on measured time, so
+what is left is variance between runners and the fact that a mutant's cost is not perfectly stable
+run to run. Chasing it further would mean re-measuring every run rather than better arithmetic.
 
 Two bugs found by running it rather than reasoning about it. mutmut records durations in
 <b>seconds</b>, so summing them into a field named <code>millis</code> understated

{boost_skill_cli-1.0.301 → boost_skill_cli-1.0.303}/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>
@@ -2572,8 +2572,18 @@ time was apportioned across its functions by <em>mutant count</em>. Across
 <b>14.3&times;</b> &mdash; and <code>install</code> alone is <b>36%</b> of the file's time from
 <b>12%</b> of its mutants, so the shard that drew it ran 8.9 minutes against a 4.8-minute sibling.
 <code>weights</code> now records per-<em>function</em> durations too and apportions on those, which
-balances the plan to <b>0.06%</b>. Whether that closes the wall-clock gap is a claim the next run
-gets to settle, not this card.
+balances the plan to <b>0.06%</b>.
+
+<b>That closed most of the gap.</b> The next run came back at 4.9, 5.6, 6.3, 7.2, 7.3,
+<b>7.7</b>&nbsp;minutes &mdash; a critical path of <b>7.7</b> against a 6.5-minute even share, or
+<b>1.19&times;</b>, from 1.5&ndash;1.9&times; before. Measured end to end, the slowest leg went from
+<b>9.3&ndash;11.7 minutes to 7.7</b>, and the shard that used to be <code>store.py</code> alone now
+finishes first. Total work is unchanged at ~39 job-minutes, as it should be &mdash; this moved the
+work around, it did not remove any.
+
+The remaining 1.19&times; is not packing error. The plan is balanced to 0.06% on measured time, so
+what is left is variance between runners and the fact that a mutant's cost is not perfectly stable
+run to run. Chasing it further would mean re-measuring every run rather than better arithmetic.
 
 Two bugs found by running it rather than reasoning about it. mutmut records durations in
 <b>seconds</b>, so summing them into a field named <code>millis</code> understated
@@ -3141,6 +3151,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>