boost-skill-cli 1.2.5__tar.gz → 1.2.6__tar.gz

{boost_skill_cli-1.2.5 → boost_skill_cli-1.2.6}/PKG-INFO

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

{boost_skill_cli-1.2.5 → boost_skill_cli-1.2.6}/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.5'
-__version_tuple__ = version_tuple = (1, 2, 5)
+__version__ = version = '1.2.6'
+__version_tuple__ = version_tuple = (1, 2, 6)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.5 → boost_skill_cli-1.2.6}/boost_cli/core/registry.py

@@ -37,6 +37,29 @@ class Tap:
         return self.path.is_dir()
 
 
+# One path component, in BYTES. ext4, APFS and NTFS all stop at 255, and
+# `Tap.safe_name` maps "/" to "__" — so the whole tap name becomes exactly one
+# component under `~/.boost/repos` and this is its ceiling. A GitHub owner/repo
+# maxes out at 140 (39 + 1 + 100), so nothing real comes near it.
+MAX_NAME_BYTES = 255
+
+
+def _looks_like_a_directory(p: Path) -> bool:
+    """True if `p` is an existing directory, False if the OS will not say.
+
+    `Path.exists()` is not total. pathlib swallows ENOENT, ENOTDIR, EBADF and
+    ELOOP — ENAMETOOLONG is *not* in that set, so a long enough component makes
+    `os.stat` raise straight out of `parse_spec` as a bare OSError, which is not
+    a BoostError and so is never framed by the CLI's error handling. A path the
+    OS refuses to look at is not a directory we can tap; that is a "no", not a
+    crash.
+    """
+    try:
+        return p.is_dir()
+    except OSError:
+        return False
+
+
 def parse_spec(spec: str):
     """Resolve a tap spec -> (name, url).
 
@@ -61,18 +84,35 @@ def parse_spec(spec: str):
     # own home-dir lookup (USERPROFILE on Windows), which ignores the $HOME
     # override the whole test suite (and BOOST_HOME sandboxing) relies on.
     p = paths.expand(spec)
-    if p.exists() and p.is_dir():
-        return (p.resolve().name, str(p.resolve()))
+    if _looks_like_a_directory(p):
+        return _checked(p.resolve().name, str(p.resolve()), spec)
     if spec.startswith(("http://", "https://", "git@", "ssh://")):
         tail = spec.split(":")[-1] if spec.startswith("git@") else spec
         parts = [x for x in tail.replace(".git", "").split("/") if x][-2:]
-        return ("/".join(parts), spec)
+        return _checked("/".join(parts), spec, spec)
     if "/" in spec and " " not in spec:
-        return (spec, "https://github.com/%s" % spec)
+        return _checked(spec, "https://github.com/%s" % spec, spec)
     raise BoostError("cannot parse tap spec %r" % spec,
                     hint="use owner/repo, a git URL, or a local directory")
 
 
+def _checked(name: str, url: str, spec: str) -> tuple[str, str]:
+    """The derived pair, or a BoostError if the name cannot be a directory.
+
+    The rule is on the *name*, never on the spec: a deep local path with a short
+    basename is a perfectly good tap, and its own length says nothing about the
+    component we are about to create. Caught here rather than at clone time,
+    where it surfaces as git's own ENAMETOOLONG on a path the user never typed.
+    """
+    if len(name.encode("utf-8")) > MAX_NAME_BYTES:
+        raise BoostError(
+            "tap name is too long (%d bytes, limit %d): %r"
+            % (len(name.encode("utf-8")), MAX_NAME_BYTES, spec[:80]),
+            hint="the name becomes one directory under ~/.boost/repos, and "
+                 "no filesystem accepts a longer component")
+    return (name, url)
+
+
 def list_taps() -> list[Tap]:
     """Configured taps from config.json.
 

{boost_skill_cli-1.2.5 → boost_skill_cli-1.2.6}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.2.5 → boost_skill_cli-1.2.6}/boost_skill_cli.egg-info/SOURCES.txt

@@ -335,6 +335,7 @@ docs/roadmap/items/one-shared-atomic-write-helper.md
 docs/roadmap/items/package-metadata-validation-twine-check-friends.md
 docs/roadmap/items/patch-coverage-gate-diff-cover.md
 docs/roadmap/items/path-traversal-unsanitized-rule-workflow-name.md
+docs/roadmap/items/pathlib-exists-is-not-total.md
 docs/roadmap/items/pep585-604-modernization-sweep.md
 docs/roadmap/items/performance-regression-gate-pytest-benchmark.md
 docs/roadmap/items/pin-the-lint-toolchain.md
@@ -565,6 +566,9 @@ tests/fuzz/corpus/registry/05-empty.txt
 tests/fuzz/corpus/registry/06-space.txt
 tests/fuzz/corpus/registry/07-slash.txt
 tests/fuzz/corpus/registry/08-bare-host.txt
+tests/fuzz/corpus/registry/09-nul.txt
+tests/fuzz/corpus/registry/10-name-too-long.txt
+tests/fuzz/corpus/registry/11-long-owner-repo.txt
 tests/langchain/conftest.py
 tests/langchain/test_graph.py
 tests/langchain/test_loader.py

boost_skill_cli-1.2.6/docs/roadmap/items/pathlib-exists-is-not-total.md

@@ -0,0 +1,48 @@
+---
+id: pathlib-exists-is-not-total
+board: code
+section: internals
+status: shipped
+category: Bug
+complexity: S
+impact: Medium
+wow: 4
+note: the weekly fuzzer has now found two crashes in one function, three weeks apart, and been ignored both times
+order: 118
+owner: fix/tap-spec-name-too-long
+pr: 528
+title: <code>Path.exists()</code> looks total, and is not
+---
+<b><code>boost tap &lt;anything long enough&gt;</code> died with a raw traceback on Linux.</b>
+<code>parse_spec</code> probes whether the spec names an existing directory, and
+<code>pathlib</code> swallows only <b>ENOENT, ENOTDIR, EBADF and ELOOP</b> &mdash;
+<b>ENAMETOOLONG is not in that set</b>. So on any filesystem with a 255-byte component limit, which
+is to say ext4 and therefore every Linux runner and most users, <code>os.stat</code> raises straight
+out through <code>parse_spec</code> as a bare <code>OSError</code>. Not a <code>BoostError</code>,
+so the CLI's error handling never got to frame it.
+
+<b>macOS does not reproduce it.</b> That is the whole reason it shipped: the only thing that ever saw
+it was the scheduled Linux fuzz job.
+
+<b>Which had been reporting it for three weeks.</b> <code>fuzz.yml</code> runs libFuzzer over
+<code>parse_spec</code> weekly and has now failed <b>four scheduled runs out of four</b>. The first
+three were one bug &mdash; an embedded NUL &mdash; found on 2026-07-25, 08-01 and 08-08 and fixed
+after the third. The fourth, on 08-15, is this one, minimised to 91 bytes: <code>0x38</code>
+followed by ninety <code>0xff</code>, each un-decodable and so each becoming U+FFFD, which is
+<b>three</b> UTF-8 bytes apiece &mdash; <b>271 bytes</b> from an input only 91 characters long.
+
+<b>The limit is on bytes, and on the derived name.</b> Measuring characters would have let exactly
+this input through. Measuring the <em>spec</em> would have turned away a legitimate deep local path
+whose basename is short, so the rule applies to the name that is about to become one directory under
+<code>~/.boost/repos</code>, caught at the parse boundary rather than at clone time where it
+resurfaces as git's own ENAMETOOLONG on a path the user never typed.
+
+<b>Rejecting is only half of it.</b> A path the OS refuses to <em>look at</em> is a &ldquo;no&rdquo;,
+not a crash, so the probe is now total by construction &mdash; and pinned by a test on every
+platform, not only the one where it fails, because a test that needs a real over-long path proves
+nothing on the machine most of this is written on.
+
+<b>Both reproducers are now seeds.</b> The NUL one was fixed and never added to the corpus, so
+the fuzzer was free to spend runs rediscovering it. <code>tests/fuzz/corpus/registry/</code> carries
+both, which means the no-atheris seed smoke &mdash; the path that runs without the fuzzer installed
+&mdash; is now a regression test for both.

{boost_skill_cli-1.2.5 → boost_skill_cli-1.2.6}/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>255</b><span>Loop finds</span></div>
+      <div class="stat"><b>256</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -4120,6 +4120,51 @@ separately for the same reason.</p></details>
           <span class="m">a scheduled gate had never once passed, and the reason was one deleted upstream in its pinned corpus</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="pathlib-exists-is-not-total">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Bug</span></div>
+        <h3><code>Path.exists()</code> looks total, and is not</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><b><code>boost tap &lt;anything long enough&gt;</code> died with a raw traceback on Linux.</b>
+<code>parse_spec</code> probes whether the spec names an existing directory, and
+<code>pathlib</code> swallows only <b>ENOENT, ENOTDIR, EBADF and ELOOP</b> &mdash;
+<b>ENAMETOOLONG is not in that set</b>. So on any filesystem with a 255-byte component limit, which
+is to say ext4 and therefore every Linux runner and most users, <code>os.stat</code> raises straight
+out through <code>parse_spec</code> as a bare <code>OSError</code>. Not a <code>BoostError</code>,
+so the CLI's error handling never got to frame it.
+
+<b>macOS does not reproduce it.</b> That is the whole reason it shipped: the only thing that ever saw
+it was the scheduled Linux fuzz job.
+
+<b>Which had been reporting it for three weeks.</b> <code>fuzz.yml</code> runs libFuzzer over
+<code>parse_spec</code> weekly and has now failed <b>four scheduled runs out of four</b>. The first
+three were one bug &mdash; an embedded NUL &mdash; found on 2026-07-25, 08-01 and 08-08 and fixed
+after the third. The fourth, on 08-15, is this one, minimised to 91 bytes: <code>0x38</code>
+followed by ninety <code>0xff</code>, each un-decodable and so each becoming U+FFFD, which is
+<b>three</b> UTF-8 bytes apiece &mdash; <b>271 bytes</b> from an input only 91 characters long.
+
+<b>The limit is on bytes, and on the derived name.</b> Measuring characters would have let exactly
+this input through. Measuring the <em>spec</em> would have turned away a legitimate deep local path
+whose basename is short, so the rule applies to the name that is about to become one directory under
+<code>~/.boost/repos</code>, caught at the parse boundary rather than at clone time where it
+resurfaces as git's own ENAMETOOLONG on a path the user never typed.
+
+<b>Rejecting is only half of it.</b> A path the OS refuses to <em>look at</em> is a &ldquo;no&rdquo;,
+not a crash, so the probe is now total by construction &mdash; and pinned by a test on every
+platform, not only the one where it fails, because a test that needs a real over-long path proves
+nothing on the machine most of this is written on.
+
+<b>Both reproducers are now seeds.</b> The NUL one was fixed and never added to the corpus, so
+the fuzzer was free to spend runs rediscovering it. <code>tests/fuzz/corpus/registry/</code> carries
+both, which means the no-atheris seed smoke &mdash; the path that runs without the fuzzer installed
+&mdash; is now a regression test for both.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Medium</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">the weekly fuzzer has now found two crashes in one function, three weeks apart, and been ignored both times</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

boost_skill_cli-1.2.6/tests/fuzz/corpus/registry/10-name-too-long.txt

@@ -0,0 +1 @@
+8������������������������������������������������������������������������������������������

boost_skill_cli-1.2.6/tests/fuzz/corpus/registry/11-long-owner-repo.txt

@@ -0,0 +1 @@
+owner/rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

boost_skill_cli-1.2.6/tests/unit/test_registry_control_chars.py

@@ -0,0 +1,233 @@
+"""Unit tests: a tap spec carrying control characters is rejected at the door.
+
+`parse_spec` used to accept them. Given the ten bytes ``/\\0\\0\\0\\0\\0\\0\\0\\0A`` it
+returned a perfectly well-formed pair::
+
+    ('/\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00A',
+     'https://github.com//\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00A')
+
+Nothing raised, so the name travelled onward — into ``config.json``, into
+``Tap.safe_name``, and eventually into a filesystem call, where it died as
+``ValueError: lstat: embedded null character in path`` from deep inside
+``posixpath.realpath``. That message names neither the tap nor the command, and
+``ValueError`` is not ``BoostError``, so the CLI's error handling never got to
+frame it.
+
+This is how the repo found out: ``fuzz.yml`` runs libFuzzer over ``parse_spec``
+weekly, and it has failed **three scheduled runs out of three** — 2026-07-25,
+08-01 and 08-08 — writing the same reproducer each time. Nobody noticed, because
+``ci-failure-issue.yml`` watches only ``["ci", "demo"]``, so a red cron job is a
+red square on a page nobody opens. The fuzzer had been right for three weeks.
+
+A control character can never appear in a GitHub owner/repo, a git URL, or a
+usable directory name, so there is no input this rejects that anyone wanted.
+Rejecting at the parse boundary turns an arbitrary later ``ValueError`` into the
+documented ``BoostError`` rejection path — which the fuzz harness already
+handles, and which the CLI already renders with a hint.
+"""
+from __future__ import annotations
+
+import pytest
+
+from boost_cli.core import registry
+from boost_cli.errors import BoostError
+
+#: The exact ten bytes libFuzzer minimised to, decoded the way the harness does.
+CRASHER = "/\x00\x00\x00\x00\x00\x00\x00\x00A"
+
+
+class TestControlCharactersAreRejected:
+    def test_the_fuzzer_reproducer_raises_boost_error(self):
+        with pytest.raises(BoostError):
+            registry.parse_spec(CRASHER)
+
+    def test_a_bare_nul_is_rejected(self):
+        with pytest.raises(BoostError):
+            registry.parse_spec("owner/re\x00po")
+
+    @pytest.mark.parametrize("ch", ["\x00", "\x01", "\x07", "\x1b", "\x7f"])
+    def test_every_control_character_is_rejected(self, ch):
+        # \x1b in particular: an escape sequence in a name is echoed back by
+        # every surface that prints a tap list.
+        with pytest.raises(BoostError):
+            registry.parse_spec("owner/re%spo" % ch)
+
+    def test_the_error_names_the_problem(self):
+        with pytest.raises(BoostError) as caught:
+            registry.parse_spec(CRASHER)
+        assert "control character" in str(caught.value).lower()
+
+    def test_a_newline_or_tab_is_rejected_too(self):
+        # These survive `.strip()` when they are in the middle, and a newline in
+        # a tap name breaks every line-oriented output in the CLI.
+        for spec in ("owner/re\npo", "owner/re\tpo"):
+            with pytest.raises(BoostError):
+                registry.parse_spec(spec)
+
+
+#: The 91 bytes libFuzzer minimised to on 2026-08-15, decoded the way the
+#: harness does: `0x38` then ninety `0xff`, each of which is un-decodable and so
+#: becomes U+FFFD — three UTF-8 bytes apiece, 271 bytes for the name alone.
+TOO_LONG = "8" + "�" * 90
+
+
+class TestAnOverlongSpecIsRejected:
+    """The second thing the fuzzer found, and the same shape as the first.
+
+    ``p.exists()`` looks total and is not. ``pathlib`` swallows only ENOENT,
+    ENOTDIR, EBADF and ELOOP; **ENAMETOOLONG is not in that set**, so on a
+    filesystem with a 255-byte component limit — ext4, which is to say every
+    Linux runner and most users — a long enough spec makes ``os.stat`` raise
+    straight through ``parse_spec``. macOS does not reproduce it, which is why
+    only the scheduled Linux fuzz job ever saw it.
+
+    Rejecting is not the whole fix. A *legitimate* long path (a deep directory
+    with a short basename) must still parse, so the probe treats "too long for
+    this OS" as "not an existing directory" and the length rule applies to the
+    derived NAME, which is what becomes a single component under
+    ``~/.boost/repos``.
+    """
+
+    def test_the_fuzzer_reproducer_raises_boost_error(self):
+        with pytest.raises(BoostError):
+            registry.parse_spec(TOO_LONG)
+
+    def test_an_overlong_owner_repo_is_rejected(self):
+        """Plain ASCII reaches the same limit, it just takes 256 of them."""
+        with pytest.raises(BoostError):
+            registry.parse_spec("owner/" + "r" * 300)
+
+    def test_the_error_names_the_problem(self):
+        """Only for a spec that *parses* — the fuzzer's own reproducer carries
+        no separator, so it is rejected as unparseable and never reaches the
+        length rule. Both paths raise BoostError, which is the invariant; this
+        pins the message on the one where length is the actual reason."""
+        with pytest.raises(BoostError) as caught:
+            registry.parse_spec("owner/" + "r" * 300)
+        assert "too long" in str(caught.value).lower()
+
+    def test_the_limit_is_on_bytes_not_characters(self):
+        """A component limit is a *byte* limit, and non-ASCII costs more.
+
+        90 characters is nothing; 90 U+FFFD is 270 bytes and does not fit.
+        Measuring characters would let exactly the fuzzer's input through.
+        """
+        assert len(TOO_LONG) < 255 < len(TOO_LONG.encode("utf-8"))
+        with pytest.raises(BoostError):
+            registry.parse_spec(TOO_LONG)
+
+    def test_a_probe_that_cannot_stat_is_not_an_existing_directory(self, tmp_path):
+        """The OS refusing to look is a "no", not a crash.
+
+        This is the assertion that actually fails on Linux without the fix:
+        the spec is a path shape, so it reaches the filesystem probe before any
+        length rule could have rejected it.
+        """
+        spec = str(tmp_path / ("d" * 400))
+        with pytest.raises(BoostError):
+            registry.parse_spec(spec)
+
+    def test_a_stat_that_raises_reads_as_not_a_directory(self):
+        """Pinned on every platform, because it only *fails* on one.
+
+        macOS returns False where Linux raises ENAMETOOLONG, so a test that
+        relies on a real long path proves nothing on the machine most of this
+        is written on — and this bug reached production precisely because the
+        scheduled Linux job was the only thing that ever saw it.
+        """
+        class Raises:
+            def is_dir(self):
+                raise OSError(36, "File name too long")
+
+        assert registry._looks_like_a_directory(Raises()) is False
+
+    def test_a_stat_that_succeeds_is_still_a_directory(self, tmp_path):
+        """The guard must not swallow the answer it exists to return."""
+        assert registry._looks_like_a_directory(tmp_path) is True
+        assert registry._looks_like_a_directory(tmp_path / "nope") is False
+
+    def test_the_rejection_carries_a_hint(self):
+        """A BoostError with no hint is the CLI printing a dead end.
+
+        Every other rejection in `parse_spec` says what to do instead, and this
+        one has something specific to say: the name is about to become a
+        directory, which is why the limit is what it is.
+        """
+        with pytest.raises(BoostError) as caught:
+            registry.parse_spec("owner/" + "r" * 300)
+        assert caught.value.hint
+        assert "~/.boost/repos" in caught.value.hint
+
+    def test_a_url_whose_derived_name_is_too_long_names_the_spec(self):
+        """The URL branch derives a name too, and the error must be traceable
+        back to what the user typed rather than to the name we computed."""
+        with pytest.raises(BoostError) as caught:
+            registry.parse_spec("https://github.com/owner/" + "r" * 300)
+        assert "owner" in str(caught.value)
+
+    def test_a_long_path_with_a_short_basename_still_parses(self, tmp_path):
+        """The rule is about the derived name, never the spec's own length."""
+        deep = tmp_path
+        for _ in range(6):
+            deep = deep / ("segment-" + "x" * 30)
+        deep = deep / "my-tap"
+        deep.mkdir(parents=True)
+        assert len(str(deep)) > 255
+        name, url = registry.parse_spec(str(deep))
+        assert name == "my-tap"
+        assert url == str(deep.resolve())
+
+    def test_a_name_at_the_limit_is_still_accepted(self):
+        """Reject one byte over, not one byte under — the boundary is pinned
+        because an off-by-one here silently turns away a legal repo name."""
+        name = "o" * 100 + "/" + "r" * 154        # 255 bytes exactly
+        assert len(name.encode("utf-8")) == 255
+        assert registry.parse_spec(name)[0] == name
+
+
+class TestOrdinarySpecsStillParse:
+    """The rejection must not widen. Each of these is a documented input."""
+
+    def test_owner_repo(self):
+        assert registry.parse_spec("anthropics/skills") == (
+            "anthropics/skills", "https://github.com/anthropics/skills")
+
+    def test_an_https_url(self):
+        name, url = registry.parse_spec("https://github.com/acme/skills")
+        assert name == "acme/skills" and url.startswith("https://")
+
+    def test_an_ssh_url(self):
+        name, _url = registry.parse_spec("git@github.com:acme/skills.git")
+        assert name == "acme/skills"
+
+    def test_a_local_directory(self, tmp_path):
+        target = tmp_path / "my-skills"
+        target.mkdir()
+        name, url = registry.parse_spec(str(target))
+        assert name == "my-skills" and url == str(target.resolve())
+
+    def test_surrounding_whitespace_is_still_only_stripped(self):
+        # Leading/trailing whitespace is trimmed, not rejected — that is a
+        # paste artifact, not a hostile name, and it always worked.
+        assert registry.parse_spec("  acme/skills  ")[0] == "acme/skills"
+
+    def test_a_unicode_name_is_not_a_control_character(self):
+        # Non-ASCII is legal in a path and must not be caught by this net.
+        assert registry.parse_spec("acmé/skïlls")[0] == "acmé/skïlls"
+
+
+class TestTheDerivedPathIsNowAlwaysUsable:
+    """The property the fuzz harness asserts, and could not reach before.
+
+    Its containment check calls ``os.path.realpath`` on the derived clone
+    directory. That is what raised — so the harness could never even evaluate
+    the invariant it exists to protect.
+    """
+
+    def test_realpath_of_the_derived_path_no_longer_raises(self):
+        import os
+        with pytest.raises(BoostError):
+            name, url = registry.parse_spec(CRASHER)
+            # Unreachable once parse_spec rejects; kept so this test fails
+            # loudly rather than silently if the rejection is ever removed.
+            os.path.realpath(str(registry.Tap(name=name, url=url).path))

boost_skill_cli-1.2.5/tests/unit/test_registry_control_chars.py

@@ -1,113 +0,0 @@
-"""Unit tests: a tap spec carrying control characters is rejected at the door.
-
-`parse_spec` used to accept them. Given the ten bytes ``/\\0\\0\\0\\0\\0\\0\\0\\0A`` it
-returned a perfectly well-formed pair::
-
-    ('/\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00A',
-     'https://github.com//\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00A')
-
-Nothing raised, so the name travelled onward — into ``config.json``, into
-``Tap.safe_name``, and eventually into a filesystem call, where it died as
-``ValueError: lstat: embedded null character in path`` from deep inside
-``posixpath.realpath``. That message names neither the tap nor the command, and
-``ValueError`` is not ``BoostError``, so the CLI's error handling never got to
-frame it.
-
-This is how the repo found out: ``fuzz.yml`` runs libFuzzer over ``parse_spec``
-weekly, and it has failed **three scheduled runs out of three** — 2026-07-25,
-08-01 and 08-08 — writing the same reproducer each time. Nobody noticed, because
-``ci-failure-issue.yml`` watches only ``["ci", "demo"]``, so a red cron job is a
-red square on a page nobody opens. The fuzzer had been right for three weeks.
-
-A control character can never appear in a GitHub owner/repo, a git URL, or a
-usable directory name, so there is no input this rejects that anyone wanted.
-Rejecting at the parse boundary turns an arbitrary later ``ValueError`` into the
-documented ``BoostError`` rejection path — which the fuzz harness already
-handles, and which the CLI already renders with a hint.
-"""
-from __future__ import annotations
-
-import pytest
-
-from boost_cli.core import registry
-from boost_cli.errors import BoostError
-
-#: The exact ten bytes libFuzzer minimised to, decoded the way the harness does.
-CRASHER = "/\x00\x00\x00\x00\x00\x00\x00\x00A"
-
-
-class TestControlCharactersAreRejected:
-    def test_the_fuzzer_reproducer_raises_boost_error(self):
-        with pytest.raises(BoostError):
-            registry.parse_spec(CRASHER)
-
-    def test_a_bare_nul_is_rejected(self):
-        with pytest.raises(BoostError):
-            registry.parse_spec("owner/re\x00po")
-
-    @pytest.mark.parametrize("ch", ["\x00", "\x01", "\x07", "\x1b", "\x7f"])
-    def test_every_control_character_is_rejected(self, ch):
-        # \x1b in particular: an escape sequence in a name is echoed back by
-        # every surface that prints a tap list.
-        with pytest.raises(BoostError):
-            registry.parse_spec("owner/re%spo" % ch)
-
-    def test_the_error_names_the_problem(self):
-        with pytest.raises(BoostError) as caught:
-            registry.parse_spec(CRASHER)
-        assert "control character" in str(caught.value).lower()
-
-    def test_a_newline_or_tab_is_rejected_too(self):
-        # These survive `.strip()` when they are in the middle, and a newline in
-        # a tap name breaks every line-oriented output in the CLI.
-        for spec in ("owner/re\npo", "owner/re\tpo"):
-            with pytest.raises(BoostError):
-                registry.parse_spec(spec)
-
-
-class TestOrdinarySpecsStillParse:
-    """The rejection must not widen. Each of these is a documented input."""
-
-    def test_owner_repo(self):
-        assert registry.parse_spec("anthropics/skills") == (
-            "anthropics/skills", "https://github.com/anthropics/skills")
-
-    def test_an_https_url(self):
-        name, url = registry.parse_spec("https://github.com/acme/skills")
-        assert name == "acme/skills" and url.startswith("https://")
-
-    def test_an_ssh_url(self):
-        name, _url = registry.parse_spec("git@github.com:acme/skills.git")
-        assert name == "acme/skills"
-
-    def test_a_local_directory(self, tmp_path):
-        target = tmp_path / "my-skills"
-        target.mkdir()
-        name, url = registry.parse_spec(str(target))
-        assert name == "my-skills" and url == str(target.resolve())
-
-    def test_surrounding_whitespace_is_still_only_stripped(self):
-        # Leading/trailing whitespace is trimmed, not rejected — that is a
-        # paste artifact, not a hostile name, and it always worked.
-        assert registry.parse_spec("  acme/skills  ")[0] == "acme/skills"
-
-    def test_a_unicode_name_is_not_a_control_character(self):
-        # Non-ASCII is legal in a path and must not be caught by this net.
-        assert registry.parse_spec("acmé/skïlls")[0] == "acmé/skïlls"
-
-
-class TestTheDerivedPathIsNowAlwaysUsable:
-    """The property the fuzz harness asserts, and could not reach before.
-
-    Its containment check calls ``os.path.realpath`` on the derived clone
-    directory. That is what raised — so the harness could never even evaluate
-    the invariant it exists to protect.
-    """
-
-    def test_realpath_of_the_derived_path_no_longer_raises(self):
-        import os
-        with pytest.raises(BoostError):
-            name, url = registry.parse_spec(CRASHER)
-            # Unreachable once parse_spec rejects; kept so this test fails
-            # loudly rather than silently if the rejection is ever removed.
-            os.path.realpath(str(registry.Tap(name=name, url=url).path))