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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.5
+Version: 1.2.7
 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.7}/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.7'
+__version_tuple__ = version_tuple = (1, 2, 7)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.5 → boost_skill_cli-1.2.7}/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.7}/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.7
 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.7}/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
@@ -413,6 +414,7 @@ docs/roadmap/items/taps-check-out-freight-they-never-index.md
 docs/roadmap/items/the-catalogue-advertised-repos-that-no-longer-exist.md
 docs/roadmap/items/theme-asset-linting-stylelint-eslint.md
 docs/roadmap/items/tool-call-eval-tier.md
+docs/roadmap/items/two-ci-controls-that-could-not-act.md
 docs/roadmap/items/two-crashes-that-should-have-been-messages.md
 docs/roadmap/items/typo-detection-codespell.md
 docs/roadmap/items/typosquat-and-name-confusion-detection.md
@@ -565,6 +567,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.7/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.7/docs/roadmap/items/two-ci-controls-that-could-not-act.md

@@ -0,0 +1,50 @@
+---
+id: two-ci-controls-that-could-not-act
+board: code
+section: internals
+status: shipped
+category: CI · Correctness
+complexity: S
+impact: Medium
+wow: 4
+note: one publisher could never publish and one alert could never stand down — both reported success
+order: 119
+owner: fix/ci-controls-that-cannot-act
+pr: 529
+title: a publisher that could not publish, and an alert that could not stand down
+---
+<b>Two controls, the same failure mode: present, running, and structurally unable to do the thing
+they exist for.</b>
+
+<b>1. <code>eval-stats</code> pushed to a branch no token can push to.</b> An earlier fix got the
+credentials right &mdash; the checkout uses <code>persist-credentials: false</code>, so the push
+needed its own token URL, and it got one. That took the workflow as far as a <em>different</em>
+permanent failure: <code>GH013: Repository rule violations found for refs/heads/main</code>.
+<code>main</code> carries a ruleset with a <code>pull_request</code> rule and an <b>empty bypass
+list</b>, so no token can push to it &mdash; not <code>github.token</code>, not a PAT, not any bot.
+The workflow was not misconfigured; it was impossible.
+
+<b>The remedy is not a bypass actor.</b> Adding one would open the protection guarding every change
+to main so that a docs payload can skip review. The refreshed metrics now arrive the way
+<code>eval-corpus-refresh.yml</code> already lands its moved pins &mdash; as a pull request on one
+long-lived <code>bot/eval-metrics</code> branch that each run updates in place, rather than a new PR
+a week. Reviewable, mergeable, and no weaker than any other change to main. It carries the same
+warning that workflow's PRs do: a <code>GITHUB_TOKEN</code> push never triggers workflows, so the
+check list is empty until someone presses <b>Update branch</b>, and empty looks exactly like
+&ldquo;not started yet&rdquo;.
+
+<b>2. The failure tracker opened issues and never closed one.</b> Its own closing line said
+&ldquo;close this once CI is green again&rdquo; &mdash; a manual step nobody had a reason to take. So
+<code>visual</code> stayed open through <b>four consecutive green runs</b>, and an issue list that
+mixes live outages with fixed ones makes every entry in it read as equally suspect. An alert that
+cannot stand down is only half an alert. A success on main now closes the tracker for
+<em>that</em> workflow, keyed on the same per-workflow marker the opener writes &mdash; a
+<code>ci</code> success must never close a <code>demo</code> tracker.
+
+<b>The second job is what made the permissions wrong.</b> <code>issues: write</code> sat at the
+workflow level, where it reaches every job including any added later; zizmor's excessive-permissions
+audit says so and now fails the build on it. Each job asks for its own.
+
+<b>Both halves are pinned statically</b>, and the push guard was verified by reversion: restore the
+old <code>HEAD:main</code> and the test names the exact line. The guard outlives this fix &mdash; it
+is parametrised over every workflow that pushes, so the next one cannot rediscover the same wall.

{boost_skill_cli-1.2.5 → boost_skill_cli-1.2.7}/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>257</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -4120,6 +4120,98 @@ 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>
+
+      <article class="cap rcard" id="two-ci-controls-that-could-not-act">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CI · Correctness</span></div>
+        <h3>a publisher that could not publish, and an alert that could not stand down</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><b>Two controls, the same failure mode: present, running, and structurally unable to do the thing
+they exist for.</b>
+
+<b>1. <code>eval-stats</code> pushed to a branch no token can push to.</b> An earlier fix got the
+credentials right &mdash; the checkout uses <code>persist-credentials: false</code>, so the push
+needed its own token URL, and it got one. That took the workflow as far as a <em>different</em>
+permanent failure: <code>GH013: Repository rule violations found for refs/heads/main</code>.
+<code>main</code> carries a ruleset with a <code>pull_request</code> rule and an <b>empty bypass
+list</b>, so no token can push to it &mdash; not <code>github.token</code>, not a PAT, not any bot.
+The workflow was not misconfigured; it was impossible.
+
+<b>The remedy is not a bypass actor.</b> Adding one would open the protection guarding every change
+to main so that a docs payload can skip review. The refreshed metrics now arrive the way
+<code>eval-corpus-refresh.yml</code> already lands its moved pins &mdash; as a pull request on one
+long-lived <code>bot/eval-metrics</code> branch that each run updates in place, rather than a new PR
+a week. Reviewable, mergeable, and no weaker than any other change to main. It carries the same
+warning that workflow's PRs do: a <code>GITHUB_TOKEN</code> push never triggers workflows, so the
+check list is empty until someone presses <b>Update branch</b>, and empty looks exactly like
+&ldquo;not started yet&rdquo;.
+
+<b>2. The failure tracker opened issues and never closed one.</b> Its own closing line said
+&ldquo;close this once CI is green again&rdquo; &mdash; a manual step nobody had a reason to take. So
+<code>visual</code> stayed open through <b>four consecutive green runs</b>, and an issue list that
+mixes live outages with fixed ones makes every entry in it read as equally suspect. An alert that
+cannot stand down is only half an alert. A success on main now closes the tracker for
+<em>that</em> workflow, keyed on the same per-workflow marker the opener writes &mdash; a
+<code>ci</code> success must never close a <code>demo</code> tracker.
+
+<b>The second job is what made the permissions wrong.</b> <code>issues: write</code> sat at the
+workflow level, where it reaches every job including any added later; zizmor's excessive-permissions
+audit says so and now fails the build on it. Each job asks for its own.
+
+<b>Both halves are pinned statically</b>, and the push guard was verified by reversion: restore the
+old <code>HEAD:main</code> and the test names the exact line. The guard outlives this fix &mdash; it
+is parametrised over every workflow that pushes, so the next one cannot rediscover the same wall.</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">one publisher could never publish and one alert could never stand down — both reported success</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

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

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

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

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

{boost_skill_cli-1.2.5 → boost_skill_cli-1.2.7}/tests/unit/test_failure_alerting_covers_unattended.py

@@ -130,3 +130,47 @@ class TestEveryUnattendedWorkflowIsWatched:
         names = {workflow_name(p.read_text(encoding="utf-8"), p.stem)
                  for p in WORKFLOWS.glob("*.yml")}
         assert watched() <= names, sorted(watched() - names)
+
+
+class TestTheAlertCanStandDown:
+    """An alert that cannot close is only half an alert.
+
+    The tracker opened issues, commented on repeats, and never closed one — so
+    its own closing line, "close this once CI is green again", was a manual step
+    nobody had a reason to take. `visual` stayed open through four consecutive
+    green runs, and a list that mixes live outages with fixed ones makes every
+    entry in it read as equally suspect.
+    """
+
+    def test_a_success_on_main_closes_the_tracker(self):
+        text = ALERT.read_text(encoding="utf-8")
+        assert "conclusion == 'success'" in text, (
+            "nothing reacts to a watched workflow going green, so every "
+            "tracker this file opens stays open until someone closes it")
+        assert "state: 'closed'" in text
+
+    def test_closing_is_keyed_by_workflow_like_opening(self):
+        """A `ci` success must not close a `demo` tracker.
+
+        The opener keys its marker on the workflow name for exactly this
+        reason; a closer that matched any `ci-failure` issue would undo that.
+        """
+        text = ALERT.read_text(encoding="utf-8")
+        assert text.count("ci-failure-tracker:${run.name}") >= 2, (
+            "the closing half must use the same per-workflow marker the "
+            "opening half writes")
+
+    def test_only_main_can_close_it(self):
+        """`workflow_run` fires for the default branch, but the opener still
+        checks — and an asymmetry here would let a non-main success close a
+        tracker for a failure that is still live on main."""
+        text = ALERT.read_text(encoding="utf-8")
+        assert text.count("head_branch == 'main'") >= 2
+
+    def test_permissions_are_not_granted_workflow_wide(self):
+        """`issues: write` at the top reaches every job, including any added
+        later. zizmor's excessive-permissions audit fails the build on it."""
+        text = ALERT.read_text(encoding="utf-8")
+        assert re.search(r"^permissions:\s*\{\}\s*$", text, re.M), \
+            "workflow-level permissions must be empty; each job asks for its own"
+        assert text.count("issues: write") >= 2

boost_skill_cli-1.2.7/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))