boost-skill-cli 1.0.398__tar.gz → 1.0.400__tar.gz

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/PKG-INFO

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

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.0.398'
-__version_tuple__ = version_tuple = (1, 0, 398)
+__version__ = version = '1.0.400'
+__version_tuple__ = version_tuple = (1, 0, 400)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/boost_cli/commands/discovery.py

@@ -104,9 +104,20 @@ def cmd_search(argv):
     # every user gets BM25 ranking without having to know about `boost reindex`.
     # rag.ensure() is incremental, offline, and degrades to frontmatter search
     # if the build fails — so a search never hard-fails on an indexing problem.
-    use_rag = rag.ready()
-    if not use_rag:
-        with spin.Spinner("building the search index (first run)"):
+    #
+    # `and not rag.stale()`, not a bare `rag.ready()`: ready() only asks whether
+    # an index exists, so once one did, `boost tap X` followed by a search
+    # answered "no matches" for a skill `boost info X` could describe from the
+    # same machine — and pointed the user at `boost discover` to go searching
+    # GitHub for something already on disk.
+    fresh = rag.ready() and not rag.stale()
+    use_rag = fresh
+    if not fresh:
+        # Name which one it is: a first build and a refresh cost the user the
+        # same pause, and only one of them is explained by "first run".
+        with spin.Spinner("refreshing the search index (taps changed)"
+                          if rag.ready() else
+                          "building the search index (first run)"):
             use_rag = rag.ensure()
     engine = ""
     if use_rag:

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/boost_cli/commands/pkg.py

@@ -716,6 +716,14 @@ def cmd_update(argv: List[str]) -> int:
     ap.add_argument("tap", nargs="?", metavar="TAP", help="refresh only this tap")
     ap.add_argument("--taps-only", action="store_true",
                     help="refresh tap clones & catalogs without touching skills")
+    # Declared because this command *advertises* it: a skipped risky update
+    # prints "review the diff, then `boost update --yes` to apply", and without
+    # this line that instruction died on `unrecognized arguments: --yes` — the
+    # only escape from the confirmation was a flag the parser rejected. The
+    # behaviour needs nothing else: out.confirm() already honours --yes/-y off
+    # sys.argv, so this makes the printed advice true rather than adding a path.
+    ap.add_argument("-y", "--yes", action="store_true",
+                    help="skip the confirmation prompt")
     args = ap.parse_args(argv)
     results = registry.update(args.tap or None)
     if not results:

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/boost_cli/core/rag.py

@@ -447,15 +447,62 @@ def ready() -> bool:
     return bool(raw and raw.get("docs") and postings_path().exists())
 
 
+def stale() -> bool:
+    """True when the index no longer reflects the taps on disk.
+
+    ``ready()`` only asks whether an index *exists*, which is why ``ensure()``
+    would serve a first build forever: ``boost tap X`` rebuilds X's catalog
+    cache but nothing rebuilt the BM25 index, so ``boost search`` answered "no
+    matches" — and suggested searching GitHub — for a skill ``boost info`` could
+    already describe from the same machine.
+
+    Deliberately **stat-only**. The obvious test, comparing ``_tap_commits()``
+    against the stored commits, means parsing every tap's catalog JSON on every
+    search — reintroducing exactly the cold-start cost that moving postings into
+    SQLite existed to remove. Two cheap signals cover it instead:
+
+    * the tap set must still match the set the index recorded (catches a tap
+      added or removed, neither of which need touch an existing cache file);
+    * no tap's catalog cache may be newer than the index (catches a tap whose
+      contents moved, since ``build()`` writes the index only after every
+      catalog cache it consumed).
+
+    The residual gap is a cache rewritten inside the same filesystem mtime tick
+    as the index; the next tap operation catches it, and paying a full parse on
+    every search to close it is the worse trade.
+    """
+    raw = _load_raw()
+    if raw is None:
+        return True
+    taps = registry.list_taps()
+    if {t.safe_name for t in taps} != set(raw.get("commits") or {}):
+        return True
+    try:
+        built_at = index_path().stat().st_mtime
+    except OSError:
+        return True
+    for t in taps:
+        try:
+            if t.cache_file.stat().st_mtime > built_at:
+                return True
+        except OSError:
+            continue        # no cache yet — build() will pick it up regardless
+    return False
+
+
 def ensure() -> bool:
-    """Ensure a usable full-content index exists, building it on first use.
+    """Ensure a *current* full-content index exists, building it on first use.
 
     This makes BM25 search the default for every surface (CLI + MCP) without the
     user having to run ``boost reindex`` first. Returns True when RAG is usable.
     Never raises: with no taps, or if the build fails, it returns False so the
     caller degrades to frontmatter search instead of erroring.
+
+    A stale index rebuilds rather than being served: ``build()`` reuses every
+    tap whose commit is unchanged, so noticing one new tap costs one tap's
+    indexing, not the whole corpus.
     """
-    if ready():
+    if ready() and not stale():
         return True
     if not registry.list_taps():
         return False

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/boost_skill_cli.egg-info/SOURCES.txt

@@ -342,6 +342,7 @@ docs/roadmap/items/sbom-release-event-never-fires.md
 docs/roadmap/items/scan-and-sync-rules-and-workflows.md
 docs/roadmap/items/scheduled-toolchain-lock-regeneration.md
 docs/roadmap/items/scorecard-findings-triage.md
+docs/roadmap/items/search-never-notices-a-new-tap.md
 docs/roadmap/items/second-type-checker-pyright.md
 docs/roadmap/items/secret-and-pii-scanning-of-installed-skills.md
 docs/roadmap/items/secret-scanning-gitleaks-push-protection.md
@@ -366,6 +367,7 @@ docs/roadmap/items/typosquat-and-name-confusion-detection.md
 docs/roadmap/items/unify-tilde-two-copies-have-a-boundary-bug.md
 docs/roadmap/items/uninstall-has-no-confirmation-prompt.md
 docs/roadmap/items/untrack-generated-build-noise.md
+docs/roadmap/items/update-advertises-a-flag-it-rejects.md
 docs/roadmap/items/update-diff-before-apply.md
 docs/roadmap/items/update-refreshes-rules-and-workflows.md
 docs/roadmap/items/update-reinstall-widens-agent-scope.md

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/docs/commands.html

@@ -104,7 +104,7 @@
       <a class="cmd-link" href="#cmd-install" data-search="install install a skill from a tap registry  --force --agent a --scope {user,project} --local --global --dry-run --no-deps --no-mcp name">install</a>
       <a class="cmd-link" href="#cmd-uninstall" data-search="uninstall remove an installed skill, rule, workflow, or config  --local -y, --yes name">uninstall</a>
       <a class="cmd-link" href="#cmd-sync" data-search="sync reconcile installed skills &amp; symlinks against the lock file  --diff --prune --json">sync</a>
-      <a class="cmd-link" href="#cmd-update" data-search="update sync taps or update installed skills  --taps-only tap">update</a>
+      <a class="cmd-link" href="#cmd-update" data-search="update sync taps or update installed skills  --taps-only -y, --yes tap">update</a>
       <a class="cmd-link" href="#cmd-reinstall" data-search="reinstall reinstall a skill or all skills (force)  --all name">reinstall</a>
       <a class="cmd-link" href="#cmd-bundle" data-search="bundle export/install skill sets via a boostfile  {dump,install} file">bundle</a>
       <a class="cmd-link" href="#cmd-import" data-search="import import skills from a github url or local path  --name n --all --agent a url_or_path">import</a>
@@ -253,10 +253,10 @@
           <div class="arg"><code>--json</code><span>machine-readable output</span></div>
         </div>
       </section>
-      <section class="cmd" id="cmd-update" data-search="update sync taps or update installed skills  --taps-only tap">
+      <section class="cmd" id="cmd-update" data-search="update sync taps or update installed skills  --taps-only -y, --yes tap">
         <h3><span class="cname">update</span><span class="gtag">pkg</span></h3>
         <p class="summary">Sync taps or update installed skills</p>
-        <pre class="syn">boost update [--taps-only] [TAP]</pre>
+        <pre class="syn">boost update [--taps-only] [--yes] [TAP]</pre>
         <div class="args-h">Arguments</div>
         <div class="args">
           <div class="arg"><code>TAP</code><span>refresh only this tap</span></div>
@@ -264,6 +264,7 @@
         <div class="args-h">Options</div>
         <div class="args">
           <div class="arg"><code>--taps-only</code><span>refresh tap clones &amp; catalogs without touching skills</span></div>
+          <div class="arg"><code>-y, --yes</code><span>skip the confirmation prompt</span></div>
         </div>
       </section>
       <section class="cmd" id="cmd-reinstall" data-search="reinstall reinstall a skill or all skills (force)  --all name">

boost_skill_cli-1.0.400/docs/roadmap/items/search-never-notices-a-new-tap.md

@@ -0,0 +1,54 @@
+---
+id: search-never-notices-a-new-tap
+board: code
+section: internals
+status: shipped
+category: Bug
+complexity: S
+impact: High
+wow: 4
+note: search said "no matches" for a skill `boost info` described from the same machine
+order: 93
+owner: loop/rag-index-stale-after-tap
+title: <code>boost search</code> never noticed a tap added after the first search
+---
+<code>boost tap X</code> followed by <code>boost search</code> could not find anything in
+<code>X</code> — not until the user happened to run <code>boost reindex</code>, a command nothing
+told them to run. Worse than a miss: search answered <b>"no matches"</b> and suggested
+<code>boost discover</code> to go searching GitHub, for a skill sitting on the user's own disk that
+<code>boost info</code> would describe on request.
+
+<b>Reproduced before it was diagnosed</b>, in a throwaway <code>HOME</code> with two fixture taps:
+
+<code>boost tap fixB</code> &rarr; <i>"✓ Tapped fixB (6 skills)"</i> &middot;
+<code>boost info zeppelin-telemetry</code> &rarr; <i>"[not installed] [fixB]"</i>, describing it
+happily &middot; <code>boost search "zeppelin telemetry airship"</code> &rarr; <i>"no matches"</i>,
+plus the suggestion to try <code>boost discover</code>. The catalog cache for <code>fixB</code> had
+just been written; the BM25 index files still carried the timestamp from before the tap existed.
+
+<b>Two layers, and only fixing the first would have looked right and changed nothing.</b>
+<code>rag.ensure()</code> short-circuited on <code>ready()</code>, and <code>ready()</code> only asks
+whether an index <i>exists</i> — never whether it still describes the taps on disk. But
+<code>cmd_search</code> did not call <code>ensure()</code> at all once an index existed: it called
+<code>rag.ready()</code> itself and reached <code>ensure()</code> only on the cold path. So a fix
+confined to <code>ensure()</code> passed its unit tests and left the CLI exactly as broken. The
+comment above that line already claimed "rag.ensure() is incremental… so a search never hard-fails",
+describing a call the code no longer made.
+
+<b>The check is deliberately stat-only.</b> The obvious test — compare the stored per-tap commits
+against <code>_tap_commits()</code> — parses every tap's catalog JSON on every search, which is the
+cold-start cost that moving postings into SQLite existed to remove. Instead <code>rag.stale()</code>
+asks two cheap questions: does the tap set still match the set the index recorded (a new or removed
+tap need not touch any existing cache file), and is any tap's catalog cache newer than the index
+(<code>build()</code> writes the index only after every cache it consumed). Measured after the fix: a
+warm repeat search is <b>0.107 s</b> and leaves the index mtime untouched, so there is no rebuild
+loop. Refreshing is cheap anyway — <code>build()</code> reuses every tap whose commit is unchanged,
+so noticing one new tap costs one tap's indexing, not the corpus.
+
+<b>Verification worth naming.</b> Nine hand-applied mutants of <code>stale()</code> — including
+<code>&gt;</code>→<code>&gt;=</code> on the mtime compare and <code>!=</code>→<code>==</code> on the
+tap-set compare — were all killed by the new tests. The functional test was then confirmed to
+<i>fail</i> with the fix reverted, because a regression test that passes either way pins nothing.
+That same check demoted its sibling: the untap case passes with or without this change, since
+<code>rag.retrieve</code> already filters hits against the live catalog, so its docstring now says it
+guards that filter rather than pretending to be evidence for this fix.

boost_skill_cli-1.0.400/docs/roadmap/items/update-advertises-a-flag-it-rejects.md

@@ -0,0 +1,46 @@
+---
+id: update-advertises-a-flag-it-rejects
+board: code
+section: internals
+status: shipped
+category: Bug
+complexity: XS
+impact: Med
+wow: 3
+note: the only escape from the security gate was a flag the parser refused
+order: 94
+owner: loop/update-yes-flag
+title: <code>boost update</code> told you to run a flag it then rejected
+---
+Decline the risky-update confirmation and <code>boost update</code> printed the way out:
+<i>"update skipped — review the diff, then <code>boost update --yes</code> to apply"</i>. Doing
+exactly that produced <code>Error: unrecognized arguments: --yes</code>.
+
+<b>Why it mattered more than a typo.</b> That gate is a <i>security</i> feature: it fires when an
+incoming update adds executable-looking instructions — shell commands, pipe-to-shell, a shebang — so
+a poisoned update is seen before it lands. Declining is therefore the careful user's path, and the
+message is the only thing telling them how to proceed afterwards. The instruction was a dead end,
+so the sole documented escape from the gate did not exist, and the remaining options were to
+re-run and answer the prompt interactively or to reach for <code>BOOST_ASSUME_YES</code> — which is
+strictly worse, since it approves <i>every</i> prompt rather than this one.
+
+<b>The fix is one <code>add_argument</code>, and deliberately nothing else.</b>
+<code>out.confirm()</code> already honours <code>--yes</code>/<code>-y</code> by reading
+<code>sys.argv</code> directly, so the behaviour was wired the whole time — every other command that
+prompts (<code>install</code>, <code>uninstall</code>, <code>tap</code>, <code>bmad</code>) declares
+the flag, and <code>update</code> was the one that forgot. Declaring it makes the printed advice
+true rather than adding a new code path. <code>docs/commands.html</code> is generated from the
+parsers, so the flag documents itself.
+
+<b>Found by taking the advice literally</b> — running the exact string the CLI prints — rather than
+by reading the parser. The regression test does the same thing: it declines the gate, asserts the
+message, then runs the command that message names and asserts the upgrade lands. It was confirmed
+to fail without the fix, with the original <code>unrecognized arguments</code> error.
+
+Two traps that shaped the test. It drives the <i>real</i> <code>out.confirm()</code> instead of
+patching it, because the suite sets <code>BOOST_ASSUME_YES=1</code> — leaving that set would
+auto-approve and the test would pass whether or not <code>--yes</code> did anything. And it must
+never call <code>monkeypatch.undo()</code> to shed that env var: the <code>sandbox</code> fixture's
+<code>HOME</code> lives on the same monkeypatch, so undoing drops the test out of its sandbox and
+onto the developer's real <code>~/.boost</code>. The first draft did exactly that and spent four
+minutes pulling real tap clones over the network before failing.

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/docs/roadmap.html

@@ -125,7 +125,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>8</b><span>Planned</span></div>
-      <div class="stat"><b>211</b><span>Loop finds</span></div>
+      <div class="stat"><b>213</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -3236,6 +3236,102 @@ no judgement in it: the 18 safe <code>UP017</code> fixes (<code>timezone.utc</co
           <span class="m">the floor was blocking a CVE fix and a dependency major at once</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="search-never-notices-a-new-tap">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Bug</span></div>
+        <h3><code>boost search</code> never noticed a tap added after the first search</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><code>boost tap X</code> followed by <code>boost search</code> could not find anything in
+<code>X</code> — not until the user happened to run <code>boost reindex</code>, a command nothing
+told them to run. Worse than a miss: search answered <b>"no matches"</b> and suggested
+<code>boost discover</code> to go searching GitHub, for a skill sitting on the user's own disk that
+<code>boost info</code> would describe on request.
+
+<b>Reproduced before it was diagnosed</b>, in a throwaway <code>HOME</code> with two fixture taps:
+
+<code>boost tap fixB</code> &rarr; <i>"✓ Tapped fixB (6 skills)"</i> &middot;
+<code>boost info zeppelin-telemetry</code> &rarr; <i>"[not installed] [fixB]"</i>, describing it
+happily &middot; <code>boost search "zeppelin telemetry airship"</code> &rarr; <i>"no matches"</i>,
+plus the suggestion to try <code>boost discover</code>. The catalog cache for <code>fixB</code> had
+just been written; the BM25 index files still carried the timestamp from before the tap existed.
+
+<b>Two layers, and only fixing the first would have looked right and changed nothing.</b>
+<code>rag.ensure()</code> short-circuited on <code>ready()</code>, and <code>ready()</code> only asks
+whether an index <i>exists</i> — never whether it still describes the taps on disk. But
+<code>cmd_search</code> did not call <code>ensure()</code> at all once an index existed: it called
+<code>rag.ready()</code> itself and reached <code>ensure()</code> only on the cold path. So a fix
+confined to <code>ensure()</code> passed its unit tests and left the CLI exactly as broken. The
+comment above that line already claimed "rag.ensure() is incremental… so a search never hard-fails",
+describing a call the code no longer made.
+
+<b>The check is deliberately stat-only.</b> The obvious test — compare the stored per-tap commits
+against <code>_tap_commits()</code> — parses every tap's catalog JSON on every search, which is the
+cold-start cost that moving postings into SQLite existed to remove. Instead <code>rag.stale()</code>
+asks two cheap questions: does the tap set still match the set the index recorded (a new or removed
+tap need not touch any existing cache file), and is any tap's catalog cache newer than the index
+(<code>build()</code> writes the index only after every cache it consumed). Measured after the fix: a
+warm repeat search is <b>0.107 s</b> and leaves the index mtime untouched, so there is no rebuild
+loop. Refreshing is cheap anyway — <code>build()</code> reuses every tap whose commit is unchanged,
+so noticing one new tap costs one tap's indexing, not the corpus.
+
+<b>Verification worth naming.</b> Nine hand-applied mutants of <code>stale()</code> — including
+<code>&gt;</code>→<code>&gt;=</code> on the mtime compare and <code>!=</code>→<code>==</code> on the
+tap-set compare — were all killed by the new tests. The functional test was then confirmed to
+<i>fail</i> with the fix reverted, because a regression test that passes either way pins nothing.
+That same check demoted its sibling: the untap case passes with or without this change, since
+<code>rag.retrieve</code> already filters hits against the live catalog, so its docstring now says it
+guards that filter rather than pretending to be evidence for this fix.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">search said "no matches" for a skill `boost info` described from the same machine</span>
+        </div>
+      </article>
+
+      <article class="cap rcard" id="update-advertises-a-flag-it-rejects">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Bug</span></div>
+        <h3><code>boost update</code> told you to run a flag it then rejected</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p>Decline the risky-update confirmation and <code>boost update</code> printed the way out:
+<i>"update skipped — review the diff, then <code>boost update --yes</code> to apply"</i>. Doing
+exactly that produced <code>Error: unrecognized arguments: --yes</code>.
+
+<b>Why it mattered more than a typo.</b> That gate is a <i>security</i> feature: it fires when an
+incoming update adds executable-looking instructions — shell commands, pipe-to-shell, a shebang — so
+a poisoned update is seen before it lands. Declining is therefore the careful user's path, and the
+message is the only thing telling them how to proceed afterwards. The instruction was a dead end,
+so the sole documented escape from the gate did not exist, and the remaining options were to
+re-run and answer the prompt interactively or to reach for <code>BOOST_ASSUME_YES</code> — which is
+strictly worse, since it approves <i>every</i> prompt rather than this one.
+
+<b>The fix is one <code>add_argument</code>, and deliberately nothing else.</b>
+<code>out.confirm()</code> already honours <code>--yes</code>/<code>-y</code> by reading
+<code>sys.argv</code> directly, so the behaviour was wired the whole time — every other command that
+prompts (<code>install</code>, <code>uninstall</code>, <code>tap</code>, <code>bmad</code>) declares
+the flag, and <code>update</code> was the one that forgot. Declaring it makes the printed advice
+true rather than adding a new code path. <code>docs/commands.html</code> is generated from the
+parsers, so the flag documents itself.
+
+<b>Found by taking the advice literally</b> — running the exact string the CLI prints — rather than
+by reading the parser. The regression test does the same thing: it declines the gate, asserts the
+message, then runs the command that message names and asserts the upgrade lands. It was confirmed
+to fail without the fix, with the original <code>unrecognized arguments</code> error.
+
+Two traps that shaped the test. It drives the <i>real</i> <code>out.confirm()</code> instead of
+patching it, because the suite sets <code>BOOST_ASSUME_YES=1</code> — leaving that set would
+auto-approve and the test would pass whether or not <code>--yes</code> did anything. And it must
+never call <code>monkeypatch.undo()</code> to shed that env var: the <code>sandbox</code> fixture's
+<code>HOME</code> lives on the same monkeypatch, so undoing drops the test out of its sandbox and
+onto the developer's real <code>~/.boost</code>. The first draft did exactly that and spent four
+minutes pulling real tap clones over the network before failing.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>XS</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">the only escape from the security gate was a flag the parser refused</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/tests/functional/test_cli_discovery.py

@@ -1084,6 +1084,59 @@ class TestReindex:
         r = boost("search", "brainstorming")
         assert "ranked by full-content BM25" in r.out
 
+    def test_search_sees_a_tap_added_after_the_index_was_built(
+            self, boost, tapped, tmp_path):
+        """`boost tap X` then `boost search` must find X, with no reindex.
+
+        The regression this pins: `cmd_search` gated on `rag.ready()`, which
+        only asks whether an index *exists*. Once one did, a newly tapped repo
+        stayed invisible to search forever — while `boost info` described it
+        happily from the same machine, and search told the user to go looking
+        on GitHub for something already on their disk.
+        """
+        boost("search", "brainstorming")          # builds the index over `tapped`
+
+        root = tmp_path / "second-tap"
+        second = root / "skills" / "zeppelin-telemetry"
+        second.mkdir(parents=True)
+        (second / "SKILL.md").write_text(
+            "---\nname: zeppelin-telemetry\n"
+            "description: Stream airship gondola telemetry to a ground station.\n"
+            "---\n\n# Zeppelin telemetry\n\n"
+            "Mount the gondola sensor array and stream zeppelin telemetry "
+            "frames to the ground station dashboard.\n",
+            encoding="utf-8")
+        # `boost tap` clones its source, so the source has to be a real repo.
+        for cmd in (("init", "-q"),
+                    ("config", "user.email", "fixture@boost.test"),
+                    ("config", "user.name", "fixture"),
+                    ("add", "-A"),
+                    ("commit", "-qm", "second tap")):
+            subprocess.run(("git", *cmd), cwd=str(root),
+                           check=True, capture_output=True)
+        boost("tap", str(root))
+
+        # Deliberately no `boost reindex` — that is the whole point.
+        r = boost("search", "zeppelin telemetry gondola")
+        assert "zeppelin-telemetry" in r.out
+        assert "no matches" not in r.out
+
+    def test_search_stops_offering_an_untapped_repo(self, boost, tapped):
+        """After `boost untap`, its skills must stop ranking.
+
+        Note what actually carries this: `rag.retrieve` filters every hit
+        against the live catalog, so a removed tap's documents are dropped even
+        from a stale index. It therefore passes with or without the staleness
+        check, and is a guard on that filter rather than on `rag.stale`; the
+        removal branch of `stale()` is pinned by its own unit test. Worth
+        keeping as the end-to-end statement of the promise, not as evidence for
+        the fix beside it.
+        """
+        assert "brainstorming" in boost("search", "brainstorming").out
+        boost("untap", tapped.name)          # untap takes the tap's name
+        r = boost("search", "brainstorming", expect=None)
+        assert "brainstorming" not in r.out
+
     def test_dense_skipped_when_no_backend_at_all(self, boost, tapped, monkeypatch):
         """No key and no local model: BM25 still builds, dense says why it didn't.
 

{boost_skill_cli-1.0.398 → boost_skill_cli-1.0.400}/tests/functional/test_cli_pkg.py

@@ -429,6 +429,41 @@ class TestUpdateDiffGate:
         assert "upgraded" not in r.out
         assert _lock()["brainstorming"]["version"] == "1.4.0"
 
+    def test_the_yes_flag_the_skip_message_advertises_is_accepted(
+            self, boost, fixture_tap_src, tmp_path, monkeypatch):
+        """Declining prints "then `boost update --yes` to apply" — so that has
+        to parse.
+
+        It did not: `boost update` never declared -y/--yes, so following its own
+        instruction died on `unrecognized arguments: --yes`, and the only escape
+        from the gate was a flag the parser rejected.
+        """
+        tap_dir = _copy_tap(fixture_tap_src, tmp_path / "risk-tap3")
+        boost("tap", tap_dir)
+        boost("install", "brainstorming")
+        _poison(tap_dir, "brainstorming", "1.4.0", "1.5.0")
+
+        # Drive the real out.confirm() rather than patching it: drop conftest's
+        # BOOST_ASSUME_YES (it would auto-approve and hide whether --yes did
+        # anything) and set sys.argv explicitly, which is where confirm() looks
+        # for the flag. With neither set and stdin not a tty, confirm returns
+        # its default — False — so the gate declines on its own.
+        # NB: never monkeypatch.undo() here; the sandbox fixture's HOME is on
+        # the same monkeypatch, so undoing drops the test out of its sandbox and
+        # onto the developer's real ~/.boost.
+        monkeypatch.delenv("BOOST_ASSUME_YES", raising=False)
+        monkeypatch.setattr("sys.argv", ["boost", "update"])
+        r = boost("update")
+        assert "`boost update --yes` to apply" in r.out   # the advice is given
+        assert _lock()["brainstorming"]["version"] == "1.4.0"
+
+        # Now take that advice verbatim.
+        monkeypatch.setattr("sys.argv", ["boost", "update", "--yes"])
+        r2 = boost("update", "--yes")
+        assert "unrecognized arguments" not in r2.err
+        assert "upgraded brainstorming v1.4.0 → v1.5.0" in r2.out
+        assert _lock()["brainstorming"]["version"] == "1.5.0"
+
     def test_routine_bump_applies_without_gate(
             self, boost, fixture_tap_src, tmp_path):
         tap_dir = _copy_tap(fixture_tap_src, tmp_path / "clean-tap")