boost-skill-cli 1.2.167__tar.gz → 1.2.169__tar.gz

{boost_skill_cli-1.2.167 → boost_skill_cli-1.2.169}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.167
+Version: 1.2.169
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.167 → boost_skill_cli-1.2.169}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.2.167'
-__version_tuple__ = version_tuple = (1, 2, 167)
+__version__ = version = '1.2.169'
+__version_tuple__ = version_tuple = (1, 2, 169)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.167 → boost_skill_cli-1.2.169}/boost_cli/commands/pkg.py

@@ -832,10 +832,73 @@ def cmd_uninstall(argv: list[str]) -> int:
                 else "removed from"
             out.ok("%s %s" % (verb, " · ".join(info["unlinked"])))
         if is_project:
-            # Report where it actually went, not where a user-scope install
-            # would have put it — a project skill never touches the
-            # canonical store.
-            out.ok("removed from %s" % _tilde(info.get("base", "this repo")))
+            refused = info.get("refused") or []
+            escaped = info.get("escaped") or []
+            redirected = info.get("redirected") or []
+            at = _tilde(info.get("base", "this repo"))
+            # Only claim a removal that happened, and read it off what came
+            # off disk rather than off `unlinked`, which is the *agent* list:
+            # a lock row need not name an agent, and gating on the agent list
+            # told a user whose row was agentless that nothing had been
+            # removed while the directory was gone. An unconditional "removed
+            # from <repo>" over an empty removal is the green panel this
+            # change exists to stop the user trusting, and this is the same
+            # sentence in the other direction. The lock *entry* does go
+            # either way, so the summary panel still counts the skill.
+            if info.get("removed_count"):
+                # Where it actually went, not where a user-scope install
+                # would have put it — a project skill never touches the
+                # canonical store.
+                out.ok("removed from %s" % at)
+            elif refused or escaped or redirected:
+                out.warn("nothing removed from %s — every path the lock named "
+                         "was left alone" % at, wrap=True)
+            # A lock row boost will not act on, named rather than swallowed:
+            # the row is in a committed file, so a user who sees nothing has
+            # no way to learn their lock was edited. Through `out.plain`
+            # because the row *is* the attacker-controlled input — a path
+            # carrying `\x1b[1A\x1b[2K` would erase the lines above it.
+            for row in refused:
+                out.warn("left alone: the lock names %s, which is not a path "
+                         "boost removes here" % out.plain(row), wrap=True)
+            # Worded apart from the above on purpose: this row may well be a
+            # path an install writes, with the lie in the filesystem rather
+            # than in the string.
+            for row in escaped:
+                out.warn("left alone: the lock names %s, which resolves "
+                         "outside this repo" % out.plain(row), wrap=True)
+            # And this one *is* a path an install writes — it is in the
+            # derived set by construction, which is why it must not borrow
+            # `refused`'s wording: that printed "not a path boost removes
+            # here" directly above a list containing the same string. The
+            # remedy is a real one, because `rm` follows the committed
+            # symlink exactly as the install did.
+            for row in redirected:
+                out.warn("left alone: the lock names %s, but a symlink inside "
+                         "the repo redirects the path to it. boost will not "
+                         "delete through a symlink it did not create; "
+                         "`rm -rf %s/%s` removes it if it is yours."
+                         % (out.plain(row), at, out.plain(row)), wrap=True)
+            if refused:
+                # The derived set, not a `<repo>/<dotdir>/skills/<name>`
+                # shape: the leaf comes from the agent's `dir`, so the shape
+                # told a user with a renamed skills dir that their path was
+                # not one an install writes — directly above a shape it
+                # matched. And worded as what boost *removes* rather than
+                # what an install *writes*, because the set keeps disabled
+                # agents on purpose and an install skips them.
+                #
+                # Gated on `refused` alone. A redirected row is in `expected`
+                # by construction, so printing this under one contradicts the
+                # line above it; its own message carries its own remedy.
+                expected = info.get("expected") or []
+                out.info(("boost only removes %s here. The lock entry is gone "
+                          "from your working copy; the directory is not, so "
+                          "remove it by hand if it is not yours."
+                          % ", ".join(expected)) if expected else
+                         ("boost cannot derive where this skill installs, so "
+                          "every row was left alone; remove the directories "
+                          "by hand if they are yours"), wrap=True)
             unregistered = info.get("mcp_unregistered") or []
             if unregistered:
                 from ..core import mcpdecl

{boost_skill_cli-1.2.167 → boost_skill_cli-1.2.169}/boost_cli/core/scopes.py

@@ -246,6 +246,44 @@ def resolve_in_base(base, rel: str) -> Path | None:
     return candidate
 
 
+def parent_matches_spelling(base, rel: str) -> bool:
+    """True when walking to ``rel``'s parent is not redirected on the way.
+
+    The third question about a committed path, and the one the other two miss.
+    :func:`contains` resolves and answers "does this end up inside the repo?".
+    :func:`resolve_in_base` returns the path *unresolved*, so an identity check
+    can compare the strings an install writes. Between them sits a row that is
+    contained, and spelled exactly like a legal path, and still points
+    somewhere else: a committed ``<repo>/.claude/skills -> ../src`` makes the
+    row ``.claude/skills/<name>`` string-equal to the legal target while
+    denoting ``src/<name>``. The leaf is honest and an ancestor is not, so a
+    guard that only inspects the leaf walks straight through it and
+    ``rmtree`` takes the victim.
+
+    So the parent is walked for real and compared against where the spelling
+    says it should be, anchored on the **real** base. ``realpath`` on both
+    sides, because a repo can sit *under* a symlink without containing one —
+    a checkout below ``/tmp`` on macOS, a home directory behind an automount,
+    a worktree reached through a convenience link. Resolve the walk and not
+    the base and every row of such a repo is compared real-against-nominal,
+    matches nothing, and is refused. The symlinked-base test builds that
+    link itself rather than relying on the runner's ``$TMPDIR``, which pytest
+    resolves before a test ever sees it.
+
+    The leaf itself is deliberately left unresolved. A materialization that
+    *is* a symlink is boost's own, and ``util.remove_path`` unlinks it without
+    following it — judging it by what it points at is the bug one layer down.
+    """
+    if not rel or not isinstance(rel, str) or Path(rel).is_absolute():
+        return False
+    try:
+        anchor = Path(os.path.realpath(base))
+        return Path(os.path.realpath((Path(base) / rel).parent)) == (
+            anchor / rel).parent
+    except (OSError, ValueError):
+        return False
+
+
 def contains(base, path) -> bool:
     """True when ``path`` sits inside ``base`` — the guard before any delete.
 

{boost_skill_cli-1.2.167 → boost_skill_cli-1.2.169}/boost_cli/core/store.py

@@ -1327,12 +1327,106 @@ def _install_project_skill(entry: dict, force: bool = False,
     return res
 
 
+def project_skill_targets(base, name: str) -> set[Path]:
+    """Every path a project install of ``name`` could legally have written.
+
+    :func:`_install_project_skill` writes exactly
+    ``<base>/<dotdir>/<skills dir>/<name>``, once per agent, so the legal set is
+    small and *derivable* — which is the point. :func:`uninstall_project` reads
+    its paths out of a committed lock file and so must decide "is this mine?"
+    from the agent table rather than from the record being checked.
+
+    Built from :func:`agents.known_agents` filtered on ``project_scope``, and
+    deliberately **not** on ``enabled``. An agent turned off after the install
+    still has its directory in the repo, and a legal-set that forgot it would
+    turn ``uninstall`` into a command that silently leaves real directories
+    behind — trading a delete bug for an orphan bug. Disabling an agent stops
+    boost writing there; it does not stop boost cleaning up what it wrote.
+
+    Derived from *this* machine's config, which has a cost worth stating: the
+    project lock is committed and read on other people's machines, so any drift
+    between the config that wrote a row and the config that reads it refuses a
+    directory a real install wrote. An agent deleted from ``config.json``, one
+    hand-added on a teammate's machine but not here, one whose ``dir`` was
+    renamed since — all three leave the copy in the repo rather than removing
+    it. That is deliberate and it is the fail-closed direction: the user is
+    told which row was skipped *and* what boost removes here, so the drift is
+    on screen and the directory can go by hand. The other way round, boost
+    deletes a path it can no longer explain — and the alternative that would
+    cover drift (checking the path's *shape* rather than deriving it) reads the
+    dotdir back out of the lock, which is the attacker-controlled input this
+    whole function exists not to trust.
+    """
+    out: set[Path] = set()
+    for agent, spec in agents.known_agents().items():
+        if not spec.get("project_scope"):
+            continue
+        skills_dir = spec["dir"]
+        try:
+            out.add(scopes.skill_target(
+                skills_dir, name, base=base,
+                dotdir=agents.project_dotdir(agent, skills_dir)))
+        except BoostError:
+            # An unusable skill name is the *caller's* problem to report, not
+            # a reason for the legal set to be wrong. Nothing matches it.
+            return set()
+    return out
+
+
 def uninstall_project(name: str, base=None) -> dict:
     """Remove a project-scoped skill: its per-agent copies and its lock entry.
 
-    Every recorded path is re-derived and checked to sit inside the project
-    before it is deleted (:func:`scopes.contains`) — the lock is a committed file
-    anyone with merge rights can edit, so a path out of it is input, not truth.
+    Every recorded path is re-derived and checked against the set of paths an
+    install could have produced (:func:`project_skill_targets`) — the lock is a
+    committed file anyone with merge rights can edit, so a path out of it is
+    input, not truth.
+
+    Containment inside the project was the whole guard and is not enough:
+    ``{"path": "src/core"}`` is inside the base, so it passed, and the repo's
+    own source tree was removed under a command the user typed with boost
+    having already said the path was safe. Being *inside the project* is the
+    weaker property; being *a path this install writes* is the real one, and
+    it is derivable.
+
+    Derivable, and then checked twice, because a path is a string and a place.
+    The string must be in the derived set, and the walk to it must not be
+    redirected by a committed symlink at an ancestor — ``.claude/skills -> src``
+    makes the legal spelling denote ``src/<name>``, so a set-membership test
+    alone passes it *by construction*. The first revision of this change
+    shipped with exactly that open. :func:`scopes.parent_matches_spelling` is
+    the second half.
+
+    Rows boost will not act on come back in three lists, because the remedy
+    differs. ``refused`` is a contained row that is not one of the paths an
+    uninstall removes here. ``escaped`` is one containment stopped outright —
+    absolute, climbing out with ``..``, or sitting on a symlink that resolves
+    out of the repo — which may well be a path an install writes, with the lie
+    in the filesystem rather than in the string. ``redirected`` is the third
+    and the quiet one: a row *in* the derived set whose walk is bent by a
+    committed symlink at an ancestor. None is deleted and all three are
+    reported; an escaped row used to be dropped in silence, and a redirected
+    one used to be reported as ``refused``, which printed "not a path boost
+    removes here" directly above a list containing that exact string.
+
+    A ``redirected`` row is also where install and uninstall disagree, and the
+    disagreement is deliberate. ``_install_project_skill`` gates on
+    :func:`scopes.ensure_in_base`, which is containment only, so
+    ``boost install --local`` writes straight through an in-repo
+    ``<repo>/.cursor -> config/cursor`` and records the row it spelled.
+    Uninstall will not delete through that redirect, because a committed
+    symlink is input: the benign layout and the attack
+    (``.claude/skills -> ../src``) are byte-identical on disk, and no test
+    distinguishes the intent behind them. Creating through a redirect is safe
+    and destroying through one is not, so the asymmetry is the right way
+    round — but it does leave boost's own copy behind, which the message says
+    by path. Making install refuse too is its own card.
+
+    The lock entry goes in all four cases (see the ``refused`` note in the
+    body), so the command still exits 0 on an all-refused run. That is also
+    why a redirected row does not hold the entry open: an attacker commits a
+    redirect as easily as a doctored path, so keeping it would be the same
+    denial of service by another route. ``uninstall`` has no ``--json``, so
+    the warning lines are the whole signal a caller gets.
     """
     resolved_base = _resolve_base(scopes.SCOPE_PROJECT, base)
     entry = projectlock.get_skill(resolved_base, name) if resolved_base else None
@@ -1340,8 +1434,64 @@ def uninstall_project(name: str, base=None) -> dict:
         raise BoostError("%s is not installed in this project" % name,
                         hint="see what is with `boost list --local`")
     removed: list[str] = []
+    refused: list[str] = []
+    redirected: list[str] = []
+    escaped: list[str] = []
+    gone = 0
+    legal = project_skill_targets(resolved_base, name)
     for m in entry.get("materializations") or []:
+        row = str(m.get("path"))
         path = scopes.resolve_in_base(resolved_base, m.get("path"))
+        if path is None:
+            # Empty, absolute, climbing out with `..` — or spelled legally and
+            # sitting on a symlink that resolves out of the repo, which
+            # `contains` catches because it resolves. Containment already
+            # stopped the delete; what was missing is saying so. This was the
+            # one doctored row that produced *no* output at all, under a
+            # change whose whole argument is that a silent survival teaches
+            # the user nothing. Kept apart from `refused` because the two need
+            # different words: this row may well be a path an install writes,
+            # with the lie in the filesystem rather than in the string.
+            escaped.append(row)
+            continue
+        # Identity, in two parts, because a path is a string *and* a place.
+        #
+        # The string must be one an install writes, compared **unresolved**,
+        # and that is load-bearing rather than incidental: resolving both
+        # sides reopens the hole this function closes. The legal path is
+        # itself a repo path, so a commit can make `.claude/skills/<name>` a
+        # *symlink* to `src/core` and file a row of `src/core`; both sides
+        # then resolve to `<base>/src/core`, the row is accepted, and the
+        # source tree is deleted again. Resolving is strictly weaker in the
+        # benign direction too — a user's own `<repo>/my-link ->
+        # .claude/skills/<name>` starts matching, and boost unlinks an alias
+        # it never created.
+        #
+        # And the walk to it must not be redirected, which comparing strings
+        # cannot tell on its own. `<repo>/.claude/skills` committed as a
+        # symlink to `src` leaves the row `.claude/skills/<name>` *equal to
+        # the legal path by construction* while denoting `src/<name>`:
+        # `is_dir()` follows the ancestor happily and `rmtree` takes the
+        # victim, which is this card's bug one component up. The leaf is
+        # honest and the ancestor is not, so the leaf-only check sees nothing.
+        # `scopes.parent_matches_spelling` walks the parent for real.
+        #
+        # Pinned by `test_a_legal_path_symlinked_at_an_in_repo_target_stays_a_
+        # string`, `test_a_users_own_symlink_to_the_skill_dir_is_refused` and
+        # `test_a_symlinked_skills_dir_does_not_redirect_the_delete`.
+        #
+        # The two halves fail differently and are reported differently. A row
+        # outside the derived set is not a path an uninstall writes here. A row
+        # *in* the set whose walk is redirected is the opposite — it is in
+        # `expected` by construction, so folding it into `refused` printed "not
+        # a path boost removes here" directly above a list containing that
+        # exact string.
+        if path not in legal:
+            refused.append(row)
+            continue
+        if not scopes.parent_matches_spelling(resolved_base, row):
+            redirected.append(row)
+            continue
         # `resolve_in_base` checks containment against the *resolved* path but
         # returns the unresolved one, so a materialization recorded as a
         # symlink arrives here as a symlink. A link out of the project was
@@ -1357,10 +1507,18 @@ def uninstall_project(name: str, base=None) -> dict:
         # link rather than through it — must not decide it by accident. A link
         # is still removed whatever it points at, because the link is boost's
         # and unlinking it leaves the target untouched.
-        if path is None or not (path.is_symlink() or path.is_dir()):
-            continue          # refused, absent, or a file we did not create
+        if not (path.is_symlink() or path.is_dir()):
+            continue          # absent, or a plain file we did not create
         if not util.remove_path(path):
             continue          # vanished between the check and the call
+        gone += 1
+        # `removed` is the *agent* list, and a lock row need not name one. The
+        # delete above is not gated on `agent` and must not be: an agentless
+        # row at a legal path is still the skill's own directory. So the count
+        # of what came off disk is tracked separately — gating the caller's
+        # "removed from <repo>" line on the agent list told a user whose lock
+        # had an agentless row that nothing had been removed, while the
+        # directory was gone.
         if m.get("agent"):
             removed.append(m["agent"])
     projectlock.remove_skill(resolved_base, name)
@@ -1371,6 +1529,30 @@ def uninstall_project(name: str, base=None) -> dict:
     unregistered = unregister_project_mcp(resolved_base, name)
     journal.log("uninstall", name, scope=scopes.SCOPE_PROJECT)
     return {"name": name, "unlinked": removed, "entry": entry,
+            # How many paths actually came off disk, which `unlinked` does not
+            # answer — see the `gone` note in the body.
+            "removed_count": gone,
+            "refused": refused,
+            # In the legal set, but an ancestor of the row is a symlink, so the
+            # walk to it is redirected. Its own list because the remedy is the
+            # opposite of `refused`'s: this *is* a path boost writes, and the
+            # spelling the user is shown still removes it by hand, since `rm`
+            # follows the ancestor the way the install did.
+            "redirected": redirected,
+            # Rows the containment check stopped. Separate from `refused`
+            # because the remedy differs: a refused row is not a path an
+            # install writes, where an escaped one may be exactly that with a
+            # symlink under it that leaves the repo.
+            "escaped": escaped,
+            # What an install writes *here*. The refusal message used to spell
+            # the shape out as `<repo>/<agent dotdir>/skills/<name>`, which
+            # hardcodes a leaf that comes from `spec["dir"]` — so for a renamed
+            # skills dir it told the user their path was "not a path a project
+            # install writes" directly above a shape that path matched. Naming
+            # the derived set instead is true under any config, and it is what
+            # puts config drift on screen.
+            "expected": sorted(scopes.relative_to_base(resolved_base, p)
+                               for p in legal),
             "mcp_unregistered": unregistered, "kind": "skill",
             "scope": scopes.SCOPE_PROJECT, "base": str(resolved_base)}
 

{boost_skill_cli-1.2.167 → boost_skill_cli-1.2.169}/boost_skill_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.167
+Version: 1.2.169
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.167 → boost_skill_cli-1.2.169}/boost_skill_cli.egg-info/SOURCES.txt

@@ -474,6 +474,7 @@ docs/roadmap/items/install-path-disambiguation.md
 docs/roadmap/items/install-paths-that-still-drop-the-result.md
 docs/roadmap/items/install-resolves-skill-dependencies.md
 docs/roadmap/items/install-scope-user-or-project.md
+docs/roadmap/items/install-writes-through-a-redirected-dotdir-uninstall-will-not.md
 docs/roadmap/items/installed-skill-trust-audit.md
 docs/roadmap/items/integrity-verification-boost-verify.md
 docs/roadmap/items/internal-architecture-diagrams.md

boost_skill_cli-1.2.169/docs/roadmap/items/install-writes-through-a-redirected-dotdir-uninstall-will-not.md

@@ -0,0 +1,46 @@
+---
+id: install-writes-through-a-redirected-dotdir-uninstall-will-not
+board: code
+section: trust
+status: planned
+category: Core · Security
+complexity: M
+impact: Low
+wow: 2
+note: install gates on containment and writes through an in-repo symlinked dotdir; uninstall refuses to delete through one, so the copy is orphaned
+order: 357
+title: "<code>install --local</code> writes through a redirected dotdir that <code>uninstall --local</code> will not remove"
+---
+A repo that commits <code>&lt;repo&gt;/.cursor &rarr; config/cursor</code> &mdash; an ordinary
+dotfile layout, not an attack &mdash; gets two different answers from the two halves of the same
+command. <code>_install_project_skill</code> gates its target with
+<code>scopes.ensure_in_base</code>, which is containment only, so <code>boost install --local</code>
+writes <code>config/cursor/skills/&lt;name&gt;</code> and records the row it spelled,
+<code>.cursor/skills/&lt;name&gt;</code>. <code>boost uninstall --local</code> then refuses that row,
+because <code>scopes.parent_matches_spelling</code> walks the parent for real and finds the
+redirect. Boost's own copy is left on disk and the lock entry goes anyway, so a second uninstall
+answers <em>not installed in this project</em>.
+
+Reproduced on the commit that introduced the guard: install wrote through the symlink, uninstall
+reported the row as <code>redirected</code>, and the directory survived.
+
+<b>The uninstall side is right and is not the thing to change.</b> The benign layout and the attack
+are byte-identical on disk: <code>.claude/skills &rarr; ../src</code> with a legally-spelled lock row
+is the same two objects in the same two places, and nothing in the filesystem carries the intent
+behind them. Creating through a redirect is safe; destroying through one hands an attacker with
+merge rights an <code>rmtree</code> aimed wherever the symlink points. So the asymmetry stays, and
+<code>uninstall</code> now names the row, says a symlink redirects it, and prints an
+<code>rm -rf</code> that works &mdash; because <code>rm</code> follows the ancestor exactly as the
+install did (shipped in #1016).
+
+What is left is the other half: <b>install should not write somewhere uninstall cannot reach.</b>
+The options are not equivalent and the choice needs measuring rather than guessing &mdash; refuse
+the install outright (safe, breaks a layout that works today); record the <em>resolved</em> path in
+the lock so uninstall's walk agrees (keeps the layout, but the lock then carries a path the repo
+never spells, and a teammate whose clone resolves differently gets a row that matches nothing); or
+record both and match on either (most forgiving, widest attack surface to re-audit). Whichever
+lands, <code>boost doctor</code> should report a project whose lock rows no longer resolve to where
+the install put them, since today nothing notices until an uninstall leaves a directory behind.
+
+Related: <code>project-uninstall-deletes-any-in-repo-directory-the-lock-names</code>, which added
+the walk and the <code>redirected</code> reporting this card inherits.

boost_skill_cli-1.2.169/docs/roadmap/items/project-uninstall-deletes-any-in-repo-directory-the-lock-names.md

@@ -0,0 +1,118 @@
+---
+id: project-uninstall-deletes-any-in-repo-directory-the-lock-names
+board: code
+section: trust
+status: shipped
+category: Core · Security
+complexity: S
+impact: Med
+wow: 3
+note: a materialization path of src/core passes the containment check and is removed
+order: 356
+owner: loop/uninstall-local-dotdir-guard
+pr: 1016
+title: "<code>uninstall --local</code> deletes any in-repo directory the committed lock names"
+---
+<code>store.uninstall_project</code> re-derives every recorded materialization through
+<code>scopes.resolve_in_base</code> and refuses anything outside the project &middot; the guard
+works, and the verification of PR #998 confirmed a planted victim outside the repo survives every
+escape attempt. What it does not check is that the path is an <em>agent skills directory</em>. A
+lock row reading <code>{"path": "src/core"}</code> is inside the base, so it passes, and
+<code>util.rmtree</code> removes the repo's source tree (store.py:1296-1300).
+
+<code>.boost/skill-lock.json</code> is a committed file: whoever can land a commit can write that
+row, and the victim runs one ordinary <code>boost uninstall &lt;skill&gt; --local</code>. That is a
+narrower threat than it sounds &mdash; someone who can commit to your repo can also commit a
+<code>Makefile</code> &mdash; but this is the one path where the damage happens under a boost
+command the user typed, with boost's own containment check having already said yes.
+
+<b>Shipped.</b> <code>store.project_skill_targets(base, name)</code> derives the whole legal set
+&mdash; <code>_install_project_skill</code> writes
+<code>&lt;base&gt;/&lt;dotdir&gt;/&lt;skills dir&gt;/&lt;name&gt;</code> and nothing else &mdash;
+and <code>uninstall_project</code> now asks "is this a path an install writes?" rather than only
+"is this inside the repo?". A row that is not in the set is returned in <code>refused</code> and
+left on disk; <code>boost uninstall --local</code> names it <em>and prints the derived set
+beside it</em>, because the row is in a committed file and a silent survival teaches the user
+nothing. Printing the set rather than a <code>&lt;repo&gt;/&lt;agent
+dotdir&gt;/skills/&lt;name&gt;</code> shape matters: the leaf comes from the agent's
+<code>dir</code>, so for a renamed skills dir the old wording told the user their path was not
+one an install writes directly above a shape that path matched.
+
+<b>Two decisions the obvious fix gets wrong.</b> The set is built from
+<code>known_agents()</code> filtered on <code>project_scope</code> and deliberately <em>not</em>
+on <code>enabled</code>: an agent switched off after the install still has its copy in the repo,
+and a legal set that forgot it would trade this delete bug for an orphan bug in the command whose
+job is to clean up. And the lock entry is removed even when a row is refused &mdash; otherwise the
+one doctored row pins the entry forever and the skill can never be uninstalled.
+
+<b>The leaf name is part of the identity, and so is comparing strings.</b> Matching "under an
+agent dotdir" would let <code>.claude/skills/&lt;other skill&gt;</code> through, so <code>boost
+uninstall --local a</code> would take <code>b</code> with it. The comparison is against the exact
+path, <em>unresolved</em>, and that half is load-bearing too: the legal path is a repo path, so a
+commit can make <code>.claude/skills/&lt;name&gt;</code> a symlink to <code>src/core</code> and
+file a row of <code>src/core</code>. Resolve both sides and they meet at the victim &mdash; the
+whole bug, re-entered through the comparison instead of the containment check.
+
+<b>A path is a string <em>and</em> a place, and the first revision only checked the string.</b>
+Set membership is equal <em>by construction</em> when the row is spelled as the legal path, so a
+committed <code>&lt;repo&gt;/.claude/skills &rarr; src</code> left the row
+<code>.claude/skills/&lt;name&gt;</code> passing every check while denoting
+<code>src/&lt;name&gt;</code>: <code>is_dir()</code> follows the ancestor, <code>rmtree</code>
+takes the victim, and the probe printed <code>refused=[]</code>. The leaf is honest and the
+ancestor is not, which is precisely what a leaf-only guard cannot see &mdash; this card's own bug,
+one component up, shipped open in the first revision and found by the verification pass.
+<code>scopes.parent_matches_spelling</code> walks the parent for real and compares it against
+where the spelling says it should be, anchored on <code>realpath(base)</code>. Both sides real: a
+repo can sit <em>under</em> a symlink without containing one &mdash; a checkout below
+<code>/tmp</code>, a home behind an automount, a worktree reached through a convenience link
+&mdash; and resolving the walk but not the base compares real against nominal, matches nothing,
+and refuses every row of that repo. Its test builds the link itself rather than leaning on the
+runner's <code>$TMPDIR</code>, which pytest resolves before a test sees it; an earlier draft of
+this paragraph claimed the opposite, and re-measuring the table is what caught it.
+
+<b>Three refusal lists, because they need different words.</b> <code>refused</code> is a
+contained row that is not a path an uninstall removes here; <code>escaped</code> is one
+containment stopped outright, which may well be a path an install writes with the lie in the
+filesystem rather than the string; <code>redirected</code> is a row <em>in</em> the derived set
+whose walk a committed symlink bends. An escaped row used to fall through every branch to a bare
+<code>continue</code> &mdash; no deletion, and no output either, so the most hostile row in the
+set was the one that left no trace. A redirected row is worse than silent: folded into
+<code>refused</code> it printed "not a path boost removes here" three lines above a list
+containing that exact string, because it is in that list <em>by construction</em>. It now says a
+symlink redirects the path and prints an <code>rm -rf</code> that works, since <code>rm</code>
+follows the ancestor the way the install did.
+
+<b>And that row is where install and uninstall disagree, deliberately.</b>
+<code>_install_project_skill</code> gates on <code>scopes.ensure_in_base</code> &mdash;
+containment only &mdash; so <code>install --local</code> writes straight through a committed
+<code>&lt;repo&gt;/.cursor &rarr; config/cursor</code>, and uninstall then will not delete through
+it, leaving boost's own copy behind. The benign layout and the attack are byte-identical on disk,
+so nothing distinguishes the intent: creating through a redirect is safe and destroying through
+one is not, and that is the right way round. Fixing the install side is
+<code>install-writes-through-a-redirected-dotdir-uninstall-will-not</code>. The two tests that
+set that layout up are skipped on Windows, where <code>install</code> cannot stage a copy
+through a relative directory symlink at all &mdash; the guard is still covered there by the two
+ancestor tests, which symlink after the install rather than before it. And the success line is now gated on a count of what actually came off disk, not on
+<code>unlinked</code>: an all-refused uninstall printed "removed from &lt;repo&gt;" over an empty
+removal, which is the green panel this whole change exists to stop the user trusting &mdash; and
+gating it on the <em>agent</em> list then told the same lie backwards, since a lock row need not
+name an agent and the delete is not gated on one. It still exits 0, because the lock entry does
+go; <code>uninstall</code> has no <code>--json</code>, so the warning lines are the whole signal a
+scripted caller gets.
+
+<b>The cost, stated.</b> The legal set comes from <em>this</em> machine's agent table while the
+lock is committed and read on others, so config drift refuses a directory a real install wrote:
+an agent hand-added on a teammate's machine, or one whose <code>dir</code> was renamed since. The
+copy stays in the repo and the lock entry goes, so the user is told by path and has to remove it
+by hand. That is deliberate. The alternative that would cover drift &mdash; checking the path's
+<em>shape</em> rather than deriving it &mdash; reads the dotdir back out of the lock, which is the
+attacker-controlled input the guard exists not to trust.
+
+Related: <code>util-rmtree-chmods-a-symlink-target-outside-the-tree</code>, and
+<code>is-dir-follows-a-symlink-at-eleven-rmtree-call-sites</code>, which brought
+<code>util.remove_path</code> in. Its
+<code>test_a_materialization_naming_a_plain_file_is_left_alone</code> deferred the wider "what may
+a lock row name?" question by name, and this change had quietly made that test vacuous &mdash; it
+pointed at <code>pyproject.toml</code>, which the new identity check refuses two guards before the
+type check it exists to pin. It now names a legal path holding a plain file, so the guard is what
+saves the file again.