boost-skill-cli 1.0.445__tar.gz → 1.0.446__tar.gz

{boost_skill_cli-1.0.445/boost_skill_cli.egg-info → boost_skill_cli-1.0.446}/PKG-INFO

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

{boost_skill_cli-1.0.445 → boost_skill_cli-1.0.446}/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.445'
-__version_tuple__ = version_tuple = (1, 0, 445)
+__version__ = version = '1.0.446'
+__version_tuple__ = version_tuple = (1, 0, 446)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.445 → boost_skill_cli-1.0.446}/boost_cli/core/store.py

@@ -1269,7 +1269,19 @@ def sync_plan() -> dict[str, list]:
             "missing_materializations": [], "out_of_scope_links": []}
     for name, entry in lock.items():
         sdir = skill_store_dir(name)
-        if not sdir.is_dir():
+        # A directory with no SKILL.md counts as missing, not as healthy. The
+        # check used to be `is_dir()` alone, and the gap was reachable: an
+        # interrupted copy, a partial rsync or a user deleting the file leaves
+        # the directory behind. `boost edit` and `boost evolve` both refuse such
+        # a skill with the hint "repair the store with `boost sync`" — and sync
+        # would answer "everything in sync", change nothing, and send the reader
+        # back to the same error. The remedy named the step they had just run.
+        #
+        # `missing_store` is the right bucket rather than a new one: its repair
+        # is already "reinstall this skill from its tap", which is exactly what
+        # a gutted directory needs, and reusing it means sync_apply needs no
+        # change at all.
+        if not sdir.is_dir() or not (sdir / "SKILL.md").is_file():
             plan["missing_store"].append(name)
             continue
         if entry.get("quarantined"):

{boost_skill_cli-1.0.445 → boost_skill_cli-1.0.446/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.445 → boost_skill_cli-1.0.446}/boost_skill_cli.egg-info/SOURCES.txt

@@ -394,6 +394,7 @@ docs/roadmap/items/stop-re-serializing-entry-meta-on-every-search.md
 docs/roadmap/items/structured-json-log-output-mode.md
 docs/roadmap/items/supply-chain-posture-openssf-scorecard.md
 docs/roadmap/items/surface-every-docs-page-from-the-guide.md
+docs/roadmap/items/sync-could-not-repair-a-gutted-skill.md
 docs/roadmap/items/sync-deletes-unowned-broken-symlinks.md
 docs/roadmap/items/sync-relinks-into-every-agent-ignoring-scope.md
 docs/roadmap/items/tap-signing-and-provenance-sigstore-minisign.md
@@ -668,6 +669,7 @@ tests/unit/test_spin.py
 tests/unit/test_stackprobe.py
 tests/unit/test_staleness.py
 tests/unit/test_store.py
+tests/unit/test_sync_repairs_gutted_skill.py
 tests/unit/test_token_parity.py
 tests/unit/test_toolchain_lock.py
 tests/unit/test_trustaudit.py

boost_skill_cli-1.0.446/docs/roadmap/items/sync-could-not-repair-a-gutted-skill.md

@@ -0,0 +1,53 @@
+---
+id: sync-could-not-repair-a-gutted-skill
+board: code
+section: internals
+status: shipped
+category: Bug
+complexity: S
+impact: Med
+wow: 4
+note: two commands named `boost sync` as the repair; sync answered "everything in sync" and changed nothing
+order: 111
+owner: fix/sync-repairs-gutted-skill
+pr:
+title: The repair command could not repair the thing two commands sent you to it for
+---
+<code>boost edit</code> and <code>boost evolve</code> both refuse a skill whose <code>SKILL.md</code>
+is gone, and both name the same remedy:
+
+<code>Error: SKILL.md missing from ~/.agents/skills/brainstorming</code><br>
+<code>&nbsp;&nbsp;hint: repair the store with <b>boost sync</b></code>
+
+It could not. <code>sync_plan</code> classified a skill as <code>missing_store</code> only when its
+<b>directory</b> was absent (<code>if not sdir.is_dir()</code>), so a directory that still existed
+but had been emptied read as perfectly healthy. Running the named remedy printed
+<b><code>✓ everything in sync</code></b>, changed nothing, and the next <code>boost edit</code>
+produced the identical error. <code>boost heal</code> said <code>nothing to heal</code>.
+<code>boost update</code> said <code>everything up to date</code>. The one command that did repair
+it — <code>boost reinstall</code> — was named by neither hint.
+
+<b>That is a loop, not a bad message.</b> The reader runs the suggested fix, observes no change,
+and has no next move — every diagnostic in the tool agrees the store is fine while the command in
+front of them insists it is not. It is the same defect as the shard exporter fixed earlier this
+session, which answered "no vectors — build them first with <code>reindex --dense</code>" inside a
+CI job where <code>reindex --dense</code> had just succeeded on the line above.
+
+<b>The state is ordinary, not exotic.</b> An interrupted copy, a partial rsync, a half-finished disk
+cleanup, or a user deleting the file to "start fresh" all leave the directory standing.
+
+<b>Why the suite could not see it.</b> One test pins that hint, in
+<code>tests/functional/test_cli_pkg.py</code>, and it removes the <i>whole directory</i> with
+<code>shutil.rmtree</code> — the case <code>sync</code> already handled. Nothing ever deleted just
+the file, so the <i>file-level</i> check in the two commands and the <i>directory-level</i> check in
+<code>sync</code> were never compared with each other. Both were individually correct; the defect
+lived only in the gap between them, which is where three of this session's other bugs also lived.
+
+<b>Fixed in the detection, not the repair.</b> <code>sync_apply</code> already knows how to restore a
+<code>missing_store</code> entry — it reinstalls from the recorded tap — so the change is one
+condition, and <code>missing_store</code> is the right bucket precisely because its existing repair
+is what a gutted directory needs. Seven tests pin both directions: the gutted case is now reported
+<i>and</i> actually restored, the wholly-missing directory still is, a healthy skill still is not
+(or <code>sync</code> would reinstall everything on every run), and the restored file is
+byte-identical to the original — restoring an <i>empty</i> SKILL.md would satisfy every other
+assertion and leave <code>boost edit</code> opening a blank document.

{boost_skill_cli-1.0.445 → boost_skill_cli-1.0.446}/docs/roadmap.html

@@ -133,7 +133,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>7</b><span>Planned</span></div>
-      <div class="stat"><b>242</b><span>Loop finds</span></div>
+      <div class="stat"><b>243</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -3790,6 +3790,56 @@ looking is worse than no guard, because the green tick still appears.</p></detai
           <span class="m">one codeql-action release arrived as 3 PRs, 2 red — and the green one was the misleading part</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="sync-could-not-repair-a-gutted-skill">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Bug</span></div>
+        <h3>The repair command could not repair the thing two commands sent you to it for</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><code>boost edit</code> and <code>boost evolve</code> both refuse a skill whose <code>SKILL.md</code>
+is gone, and both name the same remedy:
+
+<code>Error: SKILL.md missing from ~/.agents/skills/brainstorming</code><br>
+<code>&nbsp;&nbsp;hint: repair the store with <b>boost sync</b></code>
+
+It could not. <code>sync_plan</code> classified a skill as <code>missing_store</code> only when its
+<b>directory</b> was absent (<code>if not sdir.is_dir()</code>), so a directory that still existed
+but had been emptied read as perfectly healthy. Running the named remedy printed
+<b><code>✓ everything in sync</code></b>, changed nothing, and the next <code>boost edit</code>
+produced the identical error. <code>boost heal</code> said <code>nothing to heal</code>.
+<code>boost update</code> said <code>everything up to date</code>. The one command that did repair
+it — <code>boost reinstall</code> — was named by neither hint.
+
+<b>That is a loop, not a bad message.</b> The reader runs the suggested fix, observes no change,
+and has no next move — every diagnostic in the tool agrees the store is fine while the command in
+front of them insists it is not. It is the same defect as the shard exporter fixed earlier this
+session, which answered "no vectors — build them first with <code>reindex --dense</code>" inside a
+CI job where <code>reindex --dense</code> had just succeeded on the line above.
+
+<b>The state is ordinary, not exotic.</b> An interrupted copy, a partial rsync, a half-finished disk
+cleanup, or a user deleting the file to "start fresh" all leave the directory standing.
+
+<b>Why the suite could not see it.</b> One test pins that hint, in
+<code>tests/functional/test_cli_pkg.py</code>, and it removes the <i>whole directory</i> with
+<code>shutil.rmtree</code> — the case <code>sync</code> already handled. Nothing ever deleted just
+the file, so the <i>file-level</i> check in the two commands and the <i>directory-level</i> check in
+<code>sync</code> were never compared with each other. Both were individually correct; the defect
+lived only in the gap between them, which is where three of this session's other bugs also lived.
+
+<b>Fixed in the detection, not the repair.</b> <code>sync_apply</code> already knows how to restore a
+<code>missing_store</code> entry — it reinstalls from the recorded tap — so the change is one
+condition, and <code>missing_store</code> is the right bucket precisely because its existing repair
+is what a gutted directory needs. Seven tests pin both directions: the gutted case is now reported
+<i>and</i> actually restored, the wholly-missing directory still is, a healthy skill still is not
+(or <code>sync</code> would reinstall everything on every run), and the restored file is
+byte-identical to the original — restoring an <i>empty</i> SKILL.md would satisfy every other
+assertion and leave <code>boost edit</code> opening a blank document.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">two commands named `boost sync` as the repair; sync answered "everything in sync" and changed nothing</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

boost_skill_cli-1.0.446/tests/unit/test_sync_repairs_gutted_skill.py

@@ -0,0 +1,96 @@
+"""Unit tests: `boost sync` repairs a skill whose SKILL.md is gone, not just a missing dir.
+
+Two commands tell the user that `boost sync` is the repair for a missing
+``SKILL.md``::
+
+    $ boost edit brainstorming
+    Error: SKILL.md missing from ~/.agents/skills/brainstorming
+      hint: repair the store with `boost sync`
+
+    $ boost evolve brainstorming --feedback ...
+    Error: brainstorming has no SKILL.md in the store
+      hint: repair with `boost sync`
+
+It was not. ``sync_plan`` classified a skill as ``missing_store`` only when its
+**directory** was absent (``if not sdir.is_dir()``), so a directory that still
+existed but had been emptied read as healthy. ``boost sync`` printed
+``✓ everything in sync``, changed nothing, and the next ``boost edit`` produced
+the identical error — advice that sends the reader round a loop they have
+already completed. ``boost heal`` said ``nothing to heal`` too, and the only
+command that actually repaired it, ``boost reinstall``, was named by neither
+hint.
+
+This is not a hypothetical state. An interrupted copy, a partial rsync, a
+half-finished disk cleanup, or a user deleting the file to "start fresh" all
+leave the directory in place.
+
+The existing suite could not see it: the one test pinning that hint
+(``tests/functional/test_cli_pkg.py``) removes the whole directory with
+``shutil.rmtree``, which is the case ``sync`` already handled. Nothing deleted
+only the file, so the file-level check in the two commands and the
+directory-level check in ``sync`` were never compared.
+
+Same shape as the `export_shard` bug fixed earlier this session: a remedy that
+names the step the user has already taken.
+"""
+from __future__ import annotations
+
+from boost_cli.core import store
+
+
+def _gut(name: str) -> None:
+    """Delete a skill's SKILL.md, leaving its store directory in place."""
+    path = store.skill_store_dir(name) / "SKILL.md"
+    assert path.exists(), "fixture did not install %s" % name
+    path.unlink()
+
+
+class TestSyncPlanSeesAGuttedSkill:
+    def test_a_skill_with_no_skill_md_is_reported_as_missing(
+            self, installed):
+        _gut(installed)
+        assert installed in store.sync_plan()["missing_store"]
+
+    def test_the_directory_still_exists(self, installed):
+        # The whole point: this is NOT the rmtree case the old check caught.
+        _gut(installed)
+        assert store.skill_store_dir(installed).is_dir()
+
+    def test_a_healthy_skill_is_still_not_reported(self, installed):
+        # The rejection must not widen — a working install stays absent from
+        # the plan, or `sync` would reinstall everything on every run.
+        assert installed not in store.sync_plan()["missing_store"]
+
+    def test_a_wholly_missing_directory_is_still_reported(self, installed):
+        # The case that already worked, kept so the fix cannot regress it.
+        import shutil
+        shutil.rmtree(store.skill_store_dir(installed))
+        assert installed in store.sync_plan()["missing_store"]
+
+
+class TestSyncActuallyRepairsIt:
+    """A plan that names the problem but does not fix it is the same bug."""
+
+    def test_sync_restores_the_file(self, installed):
+        _gut(installed)
+
+        store.sync_apply(store.sync_plan())
+
+        assert (store.skill_store_dir(installed) / "SKILL.md").exists()
+
+    def test_the_repaired_skill_leaves_the_plan_clean(self, installed):
+        # The loop the user was stuck in: run the remedy, re-check, still broken.
+        _gut(installed)
+        store.sync_apply(store.sync_plan())
+        assert installed not in store.sync_plan()["missing_store"]
+
+    def test_the_restored_content_is_the_real_skill(self, installed):
+        # Restoring an empty file would satisfy every assertion above and help
+        # nobody — `boost edit` would open a blank document.
+        before = (store.skill_store_dir(installed)
+                  / "SKILL.md").read_text(encoding="utf-8")
+        _gut(installed)
+        store.sync_apply(store.sync_plan())
+        after = (store.skill_store_dir(installed)
+                 / "SKILL.md").read_text(encoding="utf-8")
+        assert after.strip() and after == before