boost-skill-cli 1.0.230__tar.gz → 1.0.232__tar.gz

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/PKG-INFO

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

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/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.230'
-__version_tuple__ = version_tuple = (1, 0, 230)
+__version__ = version = '1.0.232'
+__version_tuple__ = version_tuple = (1, 0, 232)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/boost_cli/commands/configuration.py

@@ -26,6 +26,7 @@ from ..core import (
     policy,
     rag,
     registry,
+    selfupdate,
     serve,
     store,
     util,
@@ -119,10 +120,14 @@ def cmd_clean(argv) -> int:
         adir = spec["dir"]
         if not adir.is_dir():
             continue
+        # Same ownership rule as `boost sync`: a broken symlink is only ours to
+        # remove if it pointed into the canonical store. A user's own dangling
+        # link in ~/.claude/skills is not boost's to clean up.
         items.extend(
             (link, "broken symlink", 0)
             for link in sorted(adir.iterdir())
             if link.is_symlink() and not link.exists()
+            and store.points_into_store(link)
         )
 
     configured = {t.safe_name for t in registry.list_taps()}
@@ -1000,12 +1005,47 @@ def cmd_self_update(argv) -> int:
     p = cliparse.parser(
         prog="boost self-update",
         description="Update boost itself to the latest version")
-    p.parse_args(argv)
+    p.add_argument("--dry-run", action="store_true",
+                   help="show how boost would update itself, change nothing")
+    args = p.parse_args(argv)
+
+    method = selfupdate.detect()
+    if method != selfupdate.GIT:
+        return _self_update_package(method, dry_run=args.dry_run)
+    return _self_update_git(dry_run=args.dry_run)
+
+
+def _self_update_package(method: str, dry_run: bool) -> int:
+    """Upgrade a pip / pipx / uv-tool install by driving its own manager."""
+    old = __version__
+    cmd = selfupdate.upgrade_command(method)   # errors if the manager is gone
+    if dry_run:
+        out.info("installed with: %s" % method)
+        out.info("would run: %s" % " ".join(cmd))
+        return 0
+    out.info("updating via %s: %s" % (method, " ".join(cmd)))
+    selfupdate.run_upgrade(cmd)
+    # This process imported its version before the upgrade, so ask a fresh one.
+    new = selfupdate.observed_version()
+    journal.log("self-update", new or old, previous=old, method=method)
+    if new and new != old:
+        out.ok("boost v%s → v%s" % (old, new))
+    elif new:
+        out.ok("already up to date (v%s)" % new)
+    else:
+        # The upgrade succeeded but we never saw a version — say exactly that
+        # rather than claim one.
+        out.ok("upgraded via %s; run `boost --version` to confirm" % method)
+    return 0
+
 
+def _self_update_git(dry_run: bool) -> int:
+    """Fast-forward the source checkout boost is running from."""
     root = paths.repo_root()
-    if not gitutil.is_repo(root):
-        raise BoostError("boost is not running from a git checkout",
-                        hint="git clone the boost repo and symlink bin")
+    if dry_run:
+        out.info("installed with: git checkout (%s)" % _tilde(root))
+        out.info("would run: git -C %s pull --ff-only" % root)
+        return 0
     old = __version__
     before = gitutil.head_commit(root)
     gitutil.run(["-C", str(root), "pull", "--ff-only"], timeout=120)

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/boost_cli/commands/pkg.py

@@ -864,6 +864,14 @@ def _bundle_install(file: Optional[str]) -> int:
                          % (sname, (" in tap %s" % tapq) if tapq else ""))
                 failed += 1
                 continue
+            if len({e["tap"] for e in matches}) > 1:
+                # A Boostfile is meant to be reproducible, so guessing which tap
+                # `skills:brainstorming` meant is the one thing this must not do.
+                out.warn("%s is ambiguous — in %s; qualify it as owner/repo:%s"
+                         % (sname, ", ".join(sorted({e["tap"] for e in matches})),
+                            sname))
+                failed += 1
+                continue
             entry = matches[0]
             if sver and str(entry.get("version")) != sver:
                 out.warn("%s: Boostfile wants @%s, tap has %s — installing that"

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/boost_cli/core/catalog.py

@@ -248,8 +248,15 @@ def find(name: str, tap: Optional[str] = None) -> List[dict]:
         tap, name = name.rsplit(":", 1)
     matches = [e for e in all_entries() if e["name"] == name]
     if tap:
-        matches = [e for e in matches
-                   if tap in (e["tap"], e["tap"].split("/")[-1])]
+        # Same tiering as registry.get: a qualified owner/repo beats a bare
+        # repo tail, so `angular/skills:x` never picks up `microsoft/skills:x`.
+        # Without this the two resolvers disagreed — `boost untap skills`
+        # errored on the ambiguity while `boost bundle apply` with
+        # `skills:brainstorming` silently took matches[0] from whichever tap
+        # sorted first.
+        exact = [e for e in matches if e["tap"] == tap]
+        matches = exact or [e for e in matches
+                            if e["tap"].split("/")[-1] == tap]
     return matches
 
 

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/boost_cli/core/registry.py

@@ -80,12 +80,26 @@ def list_taps() -> List[Tap]:
 def get(name: str) -> Tap:
     """Look up a tap by name, safe_name, or bare repo name.
 
+    Tiered so a qualified name always beats a short one: exact ``owner/repo``
+    first, then ``safe_name``, then the bare repo tail. Within a tier a name
+    that matches more than one tap is an error rather than a guess — with
+    ``angular/skills`` and ``microsoft/skills`` both tapped, ``boost untap
+    skills`` used to act on whichever came first in config.json, which for a
+    destructive command is the wrong answer half the time.
+
     Raises BoostError (with a did-you-mean hint) if none match.
     """
     taps = list_taps()
-    for t in taps:
-        if name in (t.name, t.safe_name, t.name.split("/")[-1]):
-            return t
+    for key in (lambda t: t.name, lambda t: t.safe_name,
+                lambda t: t.name.split("/")[-1]):
+        hits = [t for t in taps if key(t) == name]
+        if len(hits) == 1:
+            return hits[0]
+        if len(hits) > 1:
+            raise BoostError(
+                "%r is ambiguous — it matches %d taps: %s"
+                % (name, len(hits), ", ".join(sorted(t.name for t in hits))),
+                hint="use the full owner/repo name")
     close = difflib.get_close_matches(name, [t.name for t in taps], n=1)
     raise BoostError("no such tap: %s" % name,
                     hint=("did you mean %s?" % close[0]) if close

boost_skill_cli-1.0.232/boost_cli/core/selfupdate.py

@@ -0,0 +1,138 @@
+"""How this boost was installed, and the command that upgrades it in place.
+
+`boost self-update` assumed a git checkout and told everyone else to abandon
+their install method — but the documented way in is `pipx install
+boost-skill-cli` or `pip install boost-skill-cli`, where the package lives in
+site-packages and there is nothing to `git pull`. This resolves the install
+method from evidence on disk and hands the command layer the exact argv that
+upgrades *this* copy.
+"""
+from __future__ import annotations
+
+import re
+import shutil
+import subprocess
+import sys
+from pathlib import Path
+from typing import List, Optional
+
+from ..errors import BoostError
+from . import gitutil, paths
+
+DIST = "boost-skill-cli"
+
+GIT = "git"
+PIPX = "pipx"
+UV_TOOL = "uv-tool"
+PIP = "pip"
+UNKNOWN = "unknown"
+
+# `boost --version` prints "boost <version>"; anything else means we did not
+# actually observe a version and must not report one.
+_VERSION_LINE = re.compile(r"^boost\s+(\S+)$", re.MULTILINE)
+
+
+def installed_version() -> Optional[str]:
+    """Version recorded in installed package metadata, or None.
+
+    None is the useful answer, not a failure: it means no Python package
+    manager has a record of this boost, so none of them can upgrade it.
+    """
+    try:
+        from importlib.metadata import version
+        return version(DIST)
+    except Exception:
+        return None
+
+
+def detect(root: Optional[Path] = None, prefix: Optional[Path] = None,
+           metadata_version=None) -> str:
+    """Resolve how this boost was installed.
+
+    Order matters. A source checkout wins first — that includes `pip install
+    -e .`, where the package metadata exists too but `git pull` is what the
+    user means. Then the two managers that own a private venv and leave a
+    receipt inside it. Then plain pip, but only if pip actually has a record
+    of the distribution: telling someone to `pip install --upgrade` a boost
+    that pip never installed sends them chasing a package that isn't there.
+    """
+    root = paths.repo_root() if root is None else Path(root)
+    if gitutil.is_repo(root):
+        return GIT
+    prefix = Path(sys.prefix) if prefix is None else Path(prefix)
+    if (prefix / "pipx_metadata.json").is_file():
+        return PIPX
+    if (prefix / "uv-receipt.toml").is_file():
+        return UV_TOOL
+    # Resolved here, not as a default argument: a default binds the function
+    # object once at import, which silently defeats every attempt to swap it —
+    # including a test's, which is how a test of the "nothing installed this"
+    # branch ended up running a real `pip install` against PyPI.
+    lookup = installed_version if metadata_version is None else metadata_version
+    return PIP if lookup() else UNKNOWN
+
+
+def _require(tool: str) -> str:
+    """Absolute path to `tool`, or a BoostError naming what is missing.
+
+    Falling back to another manager here would upgrade a different copy of
+    boost — or none at all — while reporting success.
+    """
+    found = shutil.which(tool)
+    if not found:
+        raise BoostError(
+            "boost was installed with %s, but %s is not on PATH" % (tool, tool),
+            hint="install %s, or upgrade manually with `%s upgrade %s`"
+                 % (tool, tool, DIST))
+    return found
+
+
+def upgrade_command(method: str) -> List[str]:
+    """The argv that upgrades boost for `method`."""
+    if method == PIPX:
+        return [_require("pipx"), "upgrade", DIST]
+    if method == UV_TOOL:
+        return [_require("uv"), "tool", "upgrade", DIST]
+    if method == PIP:
+        # sys.executable, never a bare `pip`: the pip first on PATH can belong
+        # to a different interpreter than the one running boost, and upgrading
+        # that one leaves this install exactly where it was while printing
+        # every sign of success.
+        return [sys.executable, "-m", "pip", "install", "--upgrade", DIST]
+    raise BoostError(
+        "cannot work out how boost was installed, so it cannot update itself",
+        hint="upgrade with your package manager, e.g. `pipx upgrade %s`" % DIST)
+
+
+def run_upgrade(cmd: List[str], timeout: float = 300.0):
+    """Run the upgrade, raising BoostError with the manager's own last words."""
+    try:
+        proc = subprocess.run(cmd, capture_output=True, text=True,
+                              timeout=timeout)
+    except (OSError, subprocess.SubprocessError) as err:
+        raise BoostError("could not run %s" % " ".join(cmd),
+                         hint=str(err)) from err
+    if proc.returncode != 0:
+        detail = ((proc.stderr or "") + (proc.stdout or "")).strip().splitlines()
+        raise BoostError(
+            "upgrade failed (%s exited %d)" % (Path(cmd[0]).name, proc.returncode),
+            hint=detail[-1] if detail else "re-run the command by hand to see why")
+    return proc
+
+
+def observed_version(timeout: float = 30.0) -> Optional[str]:
+    """Ask a freshly-spawned boost what version it is now, or None.
+
+    This process imported its own version before the upgrade ran, so it cannot
+    answer the question. None means "we did not see one" — better to say
+    nothing than to report a version we never observed.
+    """
+    try:
+        proc = subprocess.run([str(paths.launcher()), "--version"],
+                              capture_output=True, text=True, timeout=timeout)
+    except (OSError, subprocess.SubprocessError):
+        return None
+    if proc.returncode != 0:
+        return None
+    match = _VERSION_LINE.search(proc.stdout or "")
+    return match.group(1) if match else None

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/boost_cli/core/store.py

@@ -810,6 +810,65 @@ def uninstall(name: str) -> dict:
     return {"name": name, "unlinked": removed_links, "entry": entry}
 
 
+def strip_extended_prefix(text: str) -> str:
+    """Drop Windows' ``\\\\?\\`` extended-length prefix from a raw path string.
+
+    Since 3.8, `os.readlink()` on Windows returns the reparse point's
+    substitution path, which typically carries that prefix — so boost's own
+    link into the store reads back as
+    ``\\\\?\\C:\\Users\\...\\.agents\\skills\\x``. Compared by path components
+    that is a *different drive* from ``C:\\Users\\...``, and every Windows leg
+    of the matrix went red on exactly this. The check it replaced was a
+    substring test, which the prefix sailed straight through; comparing
+    properly is what exposed it.
+    """
+    if text.startswith("\\\\?\\UNC\\"):
+        return "\\\\" + text[len("\\\\?\\UNC\\"):]
+    if text.startswith("\\\\?\\"):
+        return text[len("\\\\?\\"):]
+    return text
+
+
+def normalize_link_target(path: Path) -> str:
+    """A comparable string form of a `readlink()` result.
+
+    Normalizes separators and case as well as the prefix: Windows paths
+    compare case-insensitively, and POSIX `normcase` is a no-op.
+    """
+    return os.path.normcase(os.path.normpath(strip_extended_prefix(str(path))))
+
+
+def points_into_store(link: Path) -> bool:
+    """True if `link`'s target lands inside boost's canonical store.
+
+    Reads the raw `readlink()` target rather than `resolve()`, because the
+    links this has to judge are usually broken — `resolve()` cannot tell us
+    where a dangling link was aiming. A relative target is resolved against
+    the link's own directory, and containment is decided by `commonpath`
+    (the same guard `scopes.contains` uses): a substring test on the store
+    path also matches siblings like `~/.agents/skills-backup`, which boost
+    does not own either.
+
+    Everything boost deletes under an agent's skills dir is gated on this.
+    A user's own broken symlink sitting in `~/.claude/skills` is not ours.
+    Fails closed — an unreadable link is not boost's to delete.
+    """
+    try:
+        target = link.readlink()
+    except OSError:
+        return False
+    if not target.is_absolute():
+        target = link.parent / target
+    target_s = normalize_link_target(target)
+    root_s = normalize_link_target(paths.store_dir())
+    try:
+        # ValueError for paths with no common root — on Windows, two different
+        # drives — which means "outside", not "crash out of the delete guard".
+        return os.path.commonpath([target_s, root_s]) == root_s
+    except ValueError:
+        return False
+
+
 def sync_plan() -> Dict[str, list]:
     """Compare lock file <-> store <-> agent symlinks.
 
@@ -843,11 +902,12 @@ def sync_plan() -> Dict[str, list]:
         if not adir.is_dir():
             continue
         for link in adir.iterdir():
-            if link.is_symlink():
-                points_into_store = str(paths.store_dir()) in str(
-                    link.resolve() if link.exists() else link.readlink())
-                if not link.exists() or (points_into_store and link.name not in lock):
-                    plan["stale_links"].append(str(link))
+            # Ownership first, for broken links too: the old test short-circuited
+            # on `not link.exists()`, so any dangling symlink a user happened to
+            # keep in ~/.claude/skills was swept up by `boost sync`.
+            if (link.is_symlink() and points_into_store(link)
+                    and (not link.exists() or link.name not in lock)):
+                plan["stale_links"].append(str(link))
     # Rules/workflows don't live in the store — they materialize into agent dirs.
     # A materialization whose file (or CLAUDE.md block) is gone can be repaired
     # by re-materializing from the tap, same as a missing skill store dir.

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/boost_skill_cli.egg-info/SOURCES.txt

@@ -81,6 +81,7 @@ boost_cli/core/resolve.py
 boost_cli/core/rules.py
 boost_cli/core/scopes.py
 boost_cli/core/secretscan.py
+boost_cli/core/selfupdate.py
 boost_cli/core/serve.py
 boost_cli/core/stackprobe.py
 boost_cli/core/staleness.py
@@ -460,6 +461,7 @@ tests/unit/test_roadmap_fresh.py
 tests/unit/test_rules.py
 tests/unit/test_scopes.py
 tests/unit/test_secretscan.py
+tests/unit/test_selfupdate.py
 tests/unit/test_serve.py
 tests/unit/test_spin.py
 tests/unit/test_stackprobe.py

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/docs/commands.html

@@ -188,7 +188,7 @@
       <a class="cmd-link" href="#cmd-mcp" data-search="mcp register boost as an mcp server for claude code  --stdio {register,unregister}">mcp</a>
       <a class="cmd-link" href="#cmd-hooks" data-search="hooks manage claude code hooks (scope-aware) in settings.json  -c, --command command -n, --name name -s, --scope {global,project} -m, --matcher matcher --timeout timeout {add,remove,list} event">hooks</a>
       <a class="cmd-link" href="#cmd-bmad" data-search="bmad install &amp; manage the bmad method (scope-aware, toggleable)  -s, --scope {project,global} --modules modules -y, --yes --startup {install,init,startup,orient,uninstall,disable,enable,doctor,status} value">bmad</a>
-      <a class="cmd-link" href="#cmd-self-update" data-search="self-update update boost itself to the latest version ">self-update</a>
+      <a class="cmd-link" href="#cmd-self-update" data-search="self-update update boost itself to the latest version  --dry-run">self-update</a>
     </div>
     <div class="group" data-group="team">
       <div class="group-h">Team &amp; sharing</div>
@@ -1083,10 +1083,14 @@
           <div class="arg"><code>--startup</code><span>enable the startup toggle right after install</span></div>
         </div>
       </section>
-      <section class="cmd" id="cmd-self-update" data-search="self-update update boost itself to the latest version ">
+      <section class="cmd" id="cmd-self-update" data-search="self-update update boost itself to the latest version  --dry-run">
         <h3><span class="cname">self-update</span><span class="gtag">cfg</span></h3>
         <p class="summary">Update boost itself to the latest version</p>
-        <pre class="syn">boost self-update</pre>
+        <pre class="syn">boost self-update [--dry-run]</pre>
+        <div class="args-h">Options</div>
+        <div class="args">
+          <div class="arg"><code>--dry-run</code><span>show how boost would update itself, change nothing</span></div>
+        </div>
       </section>
       <h2 class="group-h" id="grp-team">Team &amp; sharing</h2>
       <section class="cmd" id="cmd-cohort" data-search="cohort controlled skill rollouts &amp; team a/b testing  --skills skills --percent percent --json {list,create,delete,status,apply} name">

boost_skill_cli-1.0.232/docs/roadmap/items/ambiguous-tap-short-name-resolution.md

@@ -0,0 +1,23 @@
+---
+id: ambiguous-tap-short-name-resolution
+board: code
+section: internals
+status: shipped
+category: Bug
+complexity: S
+impact: High
+wow: 3
+note:
+order: 28
+owner: loop/tap-name-ambiguity
+pr:
+title: Ambiguous tap short-name resolution silently picks the wrong tap
+---
+<code>registry.get(name)</code> matches on full name, safe-name, or trailing path segment and returns
+the <em>first</em> hit with no ambiguity check — unlike <code>catalog.resolve_one</code>, which
+explicitly errors on a multi-tap ambiguous match. Three of the five default taps end in
+<code>/skills</code>, so after <code>boost tap --defaults</code>, <code>boost untap skills</code> or
+<code>boost update skills</code> silently resolves to whichever tap sorts first and the others
+become unreachable by short name. Raise on an ambiguous short-name match, mirroring
+<code>resolve_one</code>.
+<b>Shipped.</b> <code>registry.get()</code> is now tiered — exact <code>owner/repo</code>, then <code>safe_name</code>, then the bare repo tail — and refuses a short name that matches more than one tap instead of taking the first. Two corrections while fixing it: there is no <i>sort</i>, the winner was whichever came first in <code>config.json</code>; and the fix was <b>half a fix</b> as originally scoped. <code>catalog.find()</code> carried an independent, untiered <code>tap in (e["tap"], tail)</code> membership test, so with both taps configured <code>angular/skills:brainstorming</code> also matched <code>microsoft/skills</code>, and <code>boost bundle apply</code> took <code>matches[0]</code> — silently installing from the wrong tap, verbatim the defect this item exists to fix. Fixing only <code>registry.get</code> would have left the CLI self-contradictory: <code>boost untap skills</code> erroring while a Boostfile silently guessed. Both resolvers are tiered now and <code>bundle apply</code> refuses an ambiguous entry rather than picking one.

boost_skill_cli-1.0.232/docs/roadmap/items/self-update-broken-for-pip-pipx-installs.md

@@ -0,0 +1,31 @@
+---
+id: self-update-broken-for-pip-pipx-installs
+board: code
+section: compat
+status: shipped
+category: Bug
+complexity: M
+impact: High
+wow: 3
+note:
+order: 10
+owner: loop/self-update
+pr: 272
+title: <code>self-update</code> is non-functional for pip/pipx installs
+---
+<code>boost self-update</code> only works when boost runs from a git checkout: <code>paths.repo_root()</code>
+resolves inside <code>site-packages</code> for a pip/pipx install, <code>gitutil.is_repo()</code> is
+False, and <code>cmd_self_update</code> raises "boost is not running from a git checkout" with a hint
+to clone the repo — telling a normal PyPI user to abandon their install method. Detect the install
+method and shell out to <code>pip install --upgrade boost-skill-cli</code> /
+<code>pipx upgrade boost-skill-cli</code>, falling back to the git-pull path only for source
+checkouts. Shipped as <code>core/selfupdate.py</code>: detection reads evidence on disk —
+<code>.git</code>, then <code>pipx_metadata.json</code> or <code>uv-receipt.toml</code> in
+<code>sys.prefix</code>, then installed package metadata — and a <code>--dry-run</code> flag
+prints the exact command without running it. Two details carry the weight: the pip branch
+invokes <code>sys.executable -m pip</code>, never a bare <code>pip</code>, because the pip
+first on PATH can belong to another interpreter and would upgrade a different copy while
+reporting success; and an install nothing has a record of reports that plainly instead of
+guessing pip. The new version is read from a freshly spawned <code>boost --version</code>,
+since the running process imported its own version before the upgrade — if that probe says
+nothing, neither does boost.

boost_skill_cli-1.0.232/docs/roadmap/items/sync-deletes-unowned-broken-symlinks.md

@@ -0,0 +1,35 @@
+---
+id: sync-deletes-unowned-broken-symlinks
+board: code
+section: internals
+status: shipped
+category: Bug
+complexity: S
+impact: Med
+wow: 2
+note:
+order: 29
+owner: loop/sync-symlink-ownership
+pr: 273
+title: <code>sync --apply</code> deletes any broken symlink, not just boost's own
+---
+<code>sync_plan</code> flags every broken symlink under an enabled agent dir as stale regardless of
+whether it points into boost's store — the <code>points_into_store</code> check only runs on the
+live-link branch — and <code>sync_apply</code> unconditionally unlinks everything in
+<code>stale_links</code>. A user's own unrelated broken symlink sitting in
+<code>~/.claude/skills</code> gets deleted by <code>boost sync --apply</code> with no ownership
+check. Only treat a broken symlink as boost-managed if its raw <code>readlink()</code> target
+resolves under the store dir. Shipped as <code>store.points_into_store()</code>, applied to
+broken and live links alike. Two things turned up while fixing it. <code>boost clean</code>
+carried the identical overreach — it unlinked every broken symlink under an agent dir with no
+ownership test at all — so it now shares the same helper; fixing only <code>sync</code> would
+have left boost contradicting itself. And the original check was a substring test
+(<code>str(store_dir) in str(target)</code>), which also matches siblings like
+<code>~/.agents/skills-backup</code>; the comparison is component-wise now, and a relative
+<code>readlink()</code> target is resolved against the link's own directory before it is judged.
+Comparing properly is what exposed a Windows bug the sloppy check had been hiding: since 3.8
+<code>os.readlink()</code> there returns the reparse point's substitution path, which carries the
+<code>\\?\</code> extended-length prefix, so boost's own link reads back as a
+<em>different drive</em> and stopped matching the store at all. Every Windows leg of the matrix
+went red on it. The prefix is stripped before comparison, and the behaviour is pinned on every
+platform via <code>ntpath</code>, which imports fine on POSIX.

{boost_skill_cli-1.0.230 → boost_skill_cli-1.0.232}/docs/roadmap.html

@@ -948,7 +948,7 @@ chunks instead cost ~70%.</p>
       </article>
 
       <article class="cap rcard" id="ambiguous-tap-short-name-resolution">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Bug</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Bug</span></div>
         <h3>Ambiguous tap short-name resolution silently picks the wrong tap</h3>
         <p><code>registry.get(name)</code> matches on full name, safe-name, or trailing path segment and returns
 the <em>first</em> hit with no ambiguity check — unlike <code>catalog.resolve_one</code>, which
@@ -956,7 +956,8 @@ explicitly errors on a multi-tap ambiguous match. Three of the five default taps
 <code>/skills</code>, so after <code>boost tap --defaults</code>, <code>boost untap skills</code> or
 <code>boost update skills</code> silently resolves to whichever tap sorts first and the others
 become unreachable by short name. Raise on an ambiguous short-name match, mirroring
-<code>resolve_one</code>.</p>
+<code>resolve_one</code>.
+<b>Shipped.</b> <code>registry.get()</code> is now tiered — exact <code>owner/repo</code>, then <code>safe_name</code>, then the bare repo tail — and refuses a short name that matches more than one tap instead of taking the first. Two corrections while fixing it: there is no <i>sort</i>, the winner was whichever came first in <code>config.json</code>; and the fix was <b>half a fix</b> as originally scoped. <code>catalog.find()</code> carried an independent, untiered <code>tap in (e["tap"], tail)</code> membership test, so with both taps configured <code>angular/skills:brainstorming</code> also matched <code>microsoft/skills</code>, and <code>boost bundle apply</code> took <code>matches[0]</code> — silently installing from the wrong tap, verbatim the defect this item exists to fix. Fixing only <code>registry.get</code> would have left the CLI self-contradictory: <code>boost untap skills</code> erroring while a Boostfile silently guessed. Both resolvers are tiered now and <code>bundle apply</code> refuses an ambiguous entry rather than picking one.</p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m hi">Impact <b>High</b></span>
@@ -965,7 +966,7 @@ become unreachable by short name. Raise on an ambiguous short-name match, mirror
       </article>
 
       <article class="cap rcard" id="sync-deletes-unowned-broken-symlinks">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Bug</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Bug</span></div>
         <h3><code>sync --apply</code> deletes any broken symlink, not just boost's own</h3>
         <p><code>sync_plan</code> flags every broken symlink under an enabled agent dir as stale regardless of
 whether it points into boost's store — the <code>points_into_store</code> check only runs on the
@@ -973,7 +974,20 @@ live-link branch — and <code>sync_apply</code> unconditionally unlinks everyth
 <code>stale_links</code>. A user's own unrelated broken symlink sitting in
 <code>~/.claude/skills</code> gets deleted by <code>boost sync --apply</code> with no ownership
 check. Only treat a broken symlink as boost-managed if its raw <code>readlink()</code> target
-resolves under the store dir.</p>
+resolves under the store dir. Shipped as <code>store.points_into_store()</code>, applied to
+broken and live links alike. Two things turned up while fixing it. <code>boost clean</code>
+carried the identical overreach — it unlinked every broken symlink under an agent dir with no
+ownership test at all — so it now shares the same helper; fixing only <code>sync</code> would
+have left boost contradicting itself. And the original check was a substring test
+(<code>str(store_dir) in str(target)</code>), which also matches siblings like
+<code>~/.agents/skills-backup</code>; the comparison is component-wise now, and a relative
+<code>readlink()</code> target is resolved against the link's own directory before it is judged.
+Comparing properly is what exposed a Windows bug the sloppy check had been hiding: since 3.8
+<code>os.readlink()</code> there returns the reparse point's substitution path, which carries the
+<code>\\?\</code> extended-length prefix, so boost's own link reads back as a
+<em>different drive</em> and stopped matching the store at all. Every Windows leg of the matrix
+went red on it. The prefix is stripped before comparison, and the behaviour is pinned on every
+platform via <code>ntpath</code>, which imports fine on POSIX.</p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Med</b></span>
@@ -2814,7 +2828,7 @@ same nav and footer as every other page.</p>
       </article>
 
       <article class="cap rcard" id="self-update-broken-for-pip-pipx-installs">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Bug</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Bug</span></div>
         <h3><code>self-update</code> is non-functional for pip/pipx installs</h3>
         <p><code>boost self-update</code> only works when boost runs from a git checkout: <code>paths.repo_root()</code>
 resolves inside <code>site-packages</code> for a pip/pipx install, <code>gitutil.is_repo()</code> is
@@ -2822,7 +2836,16 @@ False, and <code>cmd_self_update</code> raises "boost is not running from a git
 to clone the repo — telling a normal PyPI user to abandon their install method. Detect the install
 method and shell out to <code>pip install --upgrade boost-skill-cli</code> /
 <code>pipx upgrade boost-skill-cli</code>, falling back to the git-pull path only for source
-checkouts.</p>
+checkouts. Shipped as <code>core/selfupdate.py</code>: detection reads evidence on disk —
+<code>.git</code>, then <code>pipx_metadata.json</code> or <code>uv-receipt.toml</code> in
+<code>sys.prefix</code>, then installed package metadata — and a <code>--dry-run</code> flag
+prints the exact command without running it. Two details carry the weight: the pip branch
+invokes <code>sys.executable -m pip</code>, never a bare <code>pip</code>, because the pip
+first on PATH can belong to another interpreter and would upgrade a different copy while
+reporting success; and an install nothing has a record of reports that plainly instead of
+guessing pip. The new version is read from a freshly spawned <code>boost --version</code>,
+since the running process imported its own version before the upgrade — if that probe says
+nothing, neither does boost.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m hi">Impact <b>High</b></span>