boost-skill-cli 1.2.52__tar.gz → 1.2.53__tar.gz

{boost_skill_cli-1.2.52/boost_skill_cli.egg-info → boost_skill_cli-1.2.53}/PKG-INFO

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

{boost_skill_cli-1.2.52 → boost_skill_cli-1.2.53}/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.52'
-__version_tuple__ = version_tuple = (1, 2, 52)
+__version__ = version = '1.2.53'
+__version_tuple__ = version_tuple = (1, 2, 53)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.52 → boost_skill_cli-1.2.53}/boost_cli/commands/taps.py

@@ -51,7 +51,8 @@ def _tap_catalog(args) -> int:
 
 def _tap_all(urls: list[str], jobs: int | None,
              focus: dict[str, str] | None = None,
-             pins: dict[str, str] | None = None) -> int:
+             pins: dict[str, str] | None = None,
+             curated: bool = True) -> int:
     """Clone many registries at once, then scan each one that arrived.
 
     The split is the whole optimisation. Cloning is network latency — 1.6 s per
@@ -60,7 +61,7 @@ def _tap_all(urls: list[str], jobs: int | None,
     its output can be printed in order and its errors belong to one tap.
     """
     focus = focus or {}
-    results = registry.add_many(urls, curated=True, pins=pins, jobs=jobs)
+    results = registry.add_many(urls, curated=curated, pins=pins, jobs=jobs)
     rc = 0
     for res in results:
         name = res["name"]
@@ -106,8 +107,9 @@ def cmd_tap(argv) -> int:
     p = cliparse.parser(
         prog="boost tap",
         description="Add a GitHub repo as a skill registry")
-    p.add_argument("spec", nargs="?",
-                   help="owner/repo, a git URL, or a local directory")
+    p.add_argument("spec", nargs="*",
+                   help="owner/repo, a git URL, or a local directory — several "
+                        "at once clone in parallel")
     p.add_argument("--defaults", action="store_true",
                    help="tap the recommended public registries")
     p.add_argument("--catalog", action="store_true",
@@ -131,8 +133,8 @@ def cmd_tap(argv) -> int:
                         "%d)" % (registry.DEFAULT_TAP_JOBS,
                                  registry.MAX_TAP_JOBS))
     args = p.parse_args(argv)
-    if args.at and not args.spec:
-        p.error("--at pins one registry, so it needs a SPEC")
+    if args.at and len(args.spec) != 1:
+        p.error("--at pins one registry, so it needs exactly one SPEC")
     if not args.spec and not args.defaults and not args.catalog:
         p.error("provide a SPEC, --defaults, or --catalog")
 
@@ -147,13 +149,21 @@ def cmd_tap(argv) -> int:
                        jobs=args.jobs,
                        focus={str(d["name"]): str(d.get("focus", ""))
                               for d in config.DEFAULT_TAPS})
-    if args.spec:
-        with spin.Spinner("cloning %s" % args.spec):
-            tap = registry.add(args.spec, curated=args.curated, at=args.at)
+    if len(args.spec) == 1:
+        with spin.Spinner("cloning %s" % args.spec[0]):
+            tap = registry.add(args.spec[0], curated=args.curated, at=args.at)
             entries = catalog.rebuild_tap(tap)
         journal.log("tap", tap.name)
         pin = " @ %s" % args.at[:7] if args.at else ""
         out.ok("Tapped %s (%d items)%s" % (tap.name, len(entries), pin))
+    elif args.spec:
+        # Several specs clone through the same pool as --defaults/--catalog.
+        # This is not only a convenience: `xargs boost_cli tap < list` hands
+        # every line to ONE invocation, and rejecting the extras is how the
+        # shards workflow tapped nothing — argparse errored, `|| true`
+        # swallowed it, and the job died three steps later on "no taps
+        # configured". A multi-spec surface makes the natural script correct.
+        rc |= _tap_all(list(args.spec), jobs=args.jobs, curated=args.curated)
     # Refresh the TAB-completion name cache so `boost install <TAB>` sees
     # whatever this call just tapped instead of the pre-tap snapshot.
     complete.refresh_names()

{boost_skill_cli-1.2.52 → boost_skill_cli-1.2.53/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.2.52 → boost_skill_cli-1.2.53}/boost_skill_cli.egg-info/SOURCES.txt

@@ -253,6 +253,8 @@ docs/roadmap/items/crash-reports-leak-api-keys.md
 docs/roadmap/items/demo-cannot-open-its-own-pr.md
 docs/roadmap/items/demo-gif-workflow-has-never-succeeded.md
 docs/roadmap/items/demo-workflow-cancels-other-prs.md
+docs/roadmap/items/dense-reindex-has-no-progress-or-durability.md
+docs/roadmap/items/dense-reindex-reuses-whole-taps.md
 docs/roadmap/items/dense-search-fallback-and-stale-tap-pruning.md
 docs/roadmap/items/dense-search-rescans-every-vector.md
 docs/roadmap/items/dependabot-missing-pip-ecosystem.md
@@ -336,6 +338,7 @@ docs/roadmap/items/markdownlint-lints-the-fuzz-corpus.md
 docs/roadmap/items/marketing-crm-domain-had-no-category.md
 docs/roadmap/items/mcp-already-covered-defeater.md
 docs/roadmap/items/mcp-aware-skills.md
+docs/roadmap/items/mcp-cannot-read-a-skill-before-installing.md
 docs/roadmap/items/mcp-check-skills-before-starting-a-task.md
 docs/roadmap/items/mcp-hub-diagram-node-text-overflow.md
 docs/roadmap/items/mcp-install-skips-the-injection-scan.md

{boost_skill_cli-1.2.52 → boost_skill_cli-1.2.53}/docs/commands.html

@@ -628,10 +628,10 @@
       <section class="cmd" id="cmd-tap" data-search="tap add a github repo as a skill registry  --defaults --catalog --type {skill,rule,workflow} --category category --limit n --include-lists --dry-run --curated --at sha --jobs n spec">
         <h3><span class="cname">tap</span><span class="gtag">tap</span></h3>
         <p class="summary">Add a GitHub repo as a skill registry</p>
-        <pre class="syn">boost tap [--defaults] [--catalog] [--type {skill,rule,workflow}] [--category CATEGORY] [--limit N] [--include-lists] [--dry-run] [--curated] [--at SHA] [--jobs N] [spec]</pre>
+        <pre class="syn">boost tap [--defaults] [--catalog] [--type {skill,rule,workflow}] [--category CATEGORY] [--limit N] [--include-lists] [--dry-run] [--curated] [--at SHA] [--jobs N] [spec ...]</pre>
         <div class="args-h">Arguments</div>
         <div class="args">
-          <div class="arg"><code>spec</code><span>owner/repo, a git URL, or a local directory</span></div>
+          <div class="arg"><code>spec</code><span>owner/repo, a git URL, or a local directory — several at once clone in parallel</span></div>
         </div>
         <div class="args-h">Options</div>
         <div class="args">

boost_skill_cli-1.2.53/docs/roadmap/items/dense-reindex-has-no-progress-or-durability.md

@@ -0,0 +1,93 @@
+---
+id: dense-reindex-has-no-progress-or-durability
+board: code
+section: internals
+status: shipped
+category: Observability · UX
+complexity: M
+impact: High
+wow: 3
+note: 5 h 33 m of silence, 18.26 GB RSS, nothing on disk
+order: 125
+owner:
+pr: 603
+title: "<code>reindex --dense</code> runs for hours behind a bare spinner, and a cancel discards all of it"
+---
+A keyless <code>boost reindex --dense</code> on a 465-tap / <b>63,003-entry</b> install ran
+<b>5&nbsp;h&nbsp;33&nbsp;m</b> and emitted exactly one thing the whole time:
+<code>⠏ embedding chunks into the dense store</code>. Nothing on the machine could answer
+&ldquo;how far along is it, and should I cancel?&rdquo; &mdash; three independent reasons, each
+separately fixable.
+
+<b>(1) The loop is holding the numbers and never prints them.</b> <code>_embed_and_store</code>'s
+batch loop (<code>dense.py:781</code>) has <code>start</code> and <code>len(order)</code> in scope
+&mdash; precisely the pair <code>spin.progress(current, total, label)</code> takes.
+That helper already exists in <code>boost_cli/spin.py</code>, is already TTY-gated so piped, CI and
+test output stay clean, and already has a caller <em>one module over</em> at
+<code>discovery.py:478</code>. So this is a one-line call into shipped, exercised code, not new
+machinery.
+
+<b>(2) <code>--debug</code> is a dead end on this path.</b> <code>dense.py</code> never constructs a
+logger, so <code>--debug</code>, <code>BOOST_DEBUG=1</code> and <code>BOOST_LOG_LEVEL=DEBUG</code>
+all produce the same bare spinner. <code>~/.boost/logs/boost.log</code> records <code>invoke:</code>
+and <code>done:</code> and nothing in between &mdash; which for a six-hour command is the one
+interval that matters.
+
+<b>(3) The store cannot serve as a proxy either, and that is the deeper defect.</b>
+<code>_embed_and_store</code> accumulates every vector into the <code>vec_of</code> dict and inserts
+nothing until the final batch returns (<code>dense.py:802</code>); <code>build()</code> then commits
+<b>once</b>, at <code>dense.py:535</code>. Measured across the entire run:
+<code>rag_vectors.sqlite</code> sat at <b>24,924,160 bytes</b> with its mtime unchanged and no
+<code>-journal</code> beside it. A user watching the file sees a dead process.
+
+The only thing that actually worked was reading the live frame:
+<code>sudo py-spy dump --pid &lt;pid&gt; --locals</code> &rarr; <code>start: 361216</code>. The
+<code>--locals</code> is load-bearing; a plain <code>dump</code> gives the function but not the
+position. From that one number: <b>361,216 distinct texts in 20,006 s = 18.1/s</b>, on
+<b>1 of 18 cores</b>, at <b>18.26 GB RSS</b> of 48 GB &mdash; <code>vec_of</code> grows
+monotonically and is never drained.
+
+<b>And <code>start</code> alone is still not an answer, which is the sharpest form of the bug.</b>
+A numerator without its denominator is not progress. <code>len(order)</code> is <em>not</em>
+printable from a py-spy dump, so establishing it meant re-deriving boost's own chunking over all 465
+cached catalogs out-of-process: <b>647,597 chunks spanning 390,978 distinct texts</b> (39.63%
+duplicates) from <b>62,041 entries across 457 fresh taps</b>. Only then does
+<code>start: 361216</code> resolve to <b>92.4% complete, ~27 min remaining</b>. Requiring a user to
+reimplement the chunker to read a percentage is the whole defect in one sentence &mdash; and the
+process already had both numbers in the same stack frame the entire time.
+
+<b>What the opacity actually costs.</b> Because the only commit is at the end, Ctrl-C rolls the whole
+transaction back; and <code>build()</code> records per-tap commits only <em>after</em>
+<code>_embed_and_store</code> returns, so a cancelled run records nothing and a re-run re-embeds from
+zero. The user is therefore asked to bet five and a half hours of CPU on a guess about whether a
+spinner is stuck. That is the real bug &mdash; the missing progress line is how it reaches them.
+
+<b>Fix, smallest first.</b>
+<b>(a)</b> <code>spin.progress(start, len(order), "embedding chunks")</code> in the batch loop.
+<b>(b)</b> A <code>logger.debug</code> per batch, so <code>--debug</code> leaves a trail a bug report
+can carry.
+<b>(c)</b> Stream rather than accumulate &mdash; embed a batch, insert it, commit every N &mdash;
+which bounds peak RSS instead of letting it reach tens of GB, and makes a cancel cost one batch
+rather than the whole run.
+<b>(c) is what makes (a) worth trusting</b>: a progress bar over work that evaporates on Ctrl-C is
+still a bad deal. Note (c) has to keep the current failure semantics &mdash; a tap whose batch the
+provider rejected must still not get a recorded commit, or one transient failure leaves that tap
+permanently marked built and empty.
+
+<b>(a) and (c) shipped in <code>#603</code>.</b> <code>dense.build</code> now takes
+<code>on_progress(done, total)</code>, called once before the first request so the size of the job is
+known up front and again after every batch &mdash; including a rejected one, or a run with a few
+provider errors would appear to stall. <code>discovery.py</code> feeds it into the existing spinner via
+<code>_embed_progress</code>. And <code>_embed_and_store</code> now commits every
+<code>_COMMIT_EVERY = 5000</code> rows instead of once at the end, so an interrupt costs one batch
+rather than the whole run. That is safe precisely because <code>build</code> deletes each changed
+tap's rows <em>before</em> re-inserting, so a partial store is replaced rather than doubled.
+
+<b>One detail worth keeping.</b> The progress total counts <b>distinct</b> texts, not rows. On this
+corpus 657,587 chunks reduce to 396,812 distinct (39.66% repeats, embedded once), so a total taken
+from the row count would over-report the work by two thirds and make the bar crawl.
+
+<b>Still open: (b).</b> <code>dense.py</code> constructs no logger, so <code>--debug</code>,
+<code>BOOST_DEBUG=1</code> and <code>BOOST_LOG_LEVEL=DEBUG</code> still produce no per-batch trail &mdash;
+fine interactively now that the spinner counts, but a piped or CI run still has nothing to attach to a
+bug report, and <code>spin.progress</code> is deliberately silent off a TTY.

boost_skill_cli-1.2.53/docs/roadmap/items/dense-reindex-reuses-whole-taps.md

@@ -0,0 +1,93 @@
+---
+id: dense-reindex-reuses-whole-taps
+board: code
+section: internals
+status: next
+category: Search · Performance
+complexity: M
+impact: High
+wow: 3
+note: one changed file re-embeds 29 min for 1.9 s of new text
+order: 126
+owner:
+pr:
+title: "Dense reuse is per <em>tap</em>, so one changed file re-embeds the whole registry"
+---
+<code>dense.build</code> decides reuse by comparing each tap's recorded commit against its current
+one, and everything below that granularity is re-done from scratch:
+<code>_delete_taps</code> is <code>DELETE FROM chunks WHERE tap = ?</code>, and <code>fresh</code>
+collects <b>every entry of any tap whose commit moved</b>. So a one-character fix upstream costs that
+registry's entire distinct chunk set.
+
+<b>The incremental path is excellent when nothing moves and terrible when something does.</b> Measured
+on a real 464-tap / 63,003-entry / 657,587-chunk install (keyless local
+<code>BAAI/bge-small-en-v1.5</code>, 384-d, ~21 texts/s single-core):
+
+full cold build <b>5 h 28 m</b>;<br>
+<code>reindex --dense</code> with nothing changed <b>26.6 s</b>;<br>
+worst single tap re-embed <b>29 m 13 s</b> &mdash; for <b>&le;1.9 s</b> of genuinely new text.
+
+That last figure is the defect in one line. The corpus is brutally skewed:
+<code>lingxling/awesome-skills-cn</code> alone is <b>123,471 chunks (18.8%)</b>, the top ten taps carry
+<b>47.2%</b>, and the median tap is <b>349 chunks (~17 s)</b>. So the cost of an update is decided
+almost entirely by <em>which</em> registries happened to push.
+
+<b>And they push often.</b> Measured 6.56 h after tapping all 464 at HEAD: <b>19 taps had already
+moved</b> &mdash; 4.1% of taps but <b>17.0% of chunks</b>, because drift is weighted toward the big,
+active registries. Re-running at that point costs <b>61&ndash;68 min, 20.9% of the full
+build</b>, to absorb a few hours of upstream commits &mdash; and ~99% of that is embedding: deleting
+and re-inserting all 112,081 rows on a copy of the real 1.65 GB store measured <b>2.7 s</b>, a full
+464-clone rescan <b>12.7 s</b>.
+
+<b>The amplification, counted exactly.</b> Those 19 taps are 64 commits and 967 changed files ahead.
+Exactly <b>39</b> of those files map to an indexed catalog entry, and those entries own <b>659
+chunks</b>. Boost re-embeds <b>112,081</b>. That is <b>170&times;</b> more work than the change.
+
+<b>Worse: 40% of it is bots.</b> <b>10 of the 19 moved taps changed nothing boost indexes at all</b>
+&mdash; no SKILL.md, no rule file, no Markdown under commands/agents/workflows. They moved on badge
+JSON, star-history SVGs, CI YAML and e2e TypeScript, and they cost <b>44,866 chunks = 40.0% of the
+incremental bill</b>, about <b>37 of the 68 minutes</b>. <code>davila7/claude-code-templates</code>
+alone re-embeds all <b>18,566</b> of its chunks because four dashboard JSON files changed.
+Entry-level digests take that 40% to <b>zero</b> without a special case, which is most of the argument
+for doing it.
+
+<b>And the advantage decays with cadence</b> (distinct-text counts per scenario at the measured
+19.92 texts/s): 6.9 h &rarr; 21%, 1 day &rarr; 33%, <b>7 days &rarr; 52&ndash;58%</b>, 30 days
+&rarr; 72% of a full rebuild. A weekly refresh buys under 2&times;. Part of that is a dedup collapse:
+the whole corpus is 39.66% duplicate text, but <em>within</em> the 19 moved taps only 27.21%, so
+effective throughput falls 33.5 &rarr; 27.4 chunks/s.
+
+<b>The fix does not need new identity machinery.</b> A catalog entry already carries
+<code>content</code>, a truncated sha256 of name + description + body stamped by
+<code>catalog._content_digest</code> at scan time and pinned byte-identical to what
+<code>rag.read_body</code> assembles by <code>tests/unit/test_content_identity.py</code>. On a commit
+change, diff the tap's entries by that digest and delete + re-embed only the ones that actually moved.
+A registry that reorganised files, bumped a README or touched one skill then costs one entry rather
+than 123,471 chunks. Deletion stays tap-scoped underneath, so the constraint that
+<code>chunks.tap</code> is what scopes removal is unaffected.
+
+<b>Content-keyed vectors were measured and declined.</b> The obvious neighbouring idea &mdash; hash each
+chunk's text, look it up before embedding, skip on a hit &mdash; sounds like it should erase the
+corpus's 39.6% duplicate rate. It does not, because <code>_embed_and_store</code> already dedupes
+<code>order</code> <em>within the fresh set</em>: on a cold build every duplicate is already collapsed,
+so content keying saves <b>0</b>. Only text shared with the <em>unchanged</em> taps is recoverable:
+measured on the real moved set, <b>11,501 of 81,580 distinct texts = 14.1%</b>, worth <b>9.6 min of
+the 68</b> &mdash; against ~60&ndash;120 lines in <code>dense.py</code>
+plus a schema change, an <code>INDEX_VERSION</code> bump and a wrong-vector failure mode that is silent.
+Recorded so the measurement is not re-litigated; per-entry granularity is where the win is.
+
+<b>Related gap: a tap pin cannot be set after tapping.</b> <code>registry.pin</code> /
+<code>unpin</code> exist (<code>registry.py:398</code>/<code>410</code>) and <code>registry.update</code>
+already honours them &mdash; <em>&ldquo;A pinned tap is skipped unless <code>force</code>, which also
+clears the pin&rdquo;</em> &mdash; but the only way to set one is <code>boost tap --at &lt;SHA&gt;</code> at
+creation, and <code>add()</code> raises <code>"tap %s is already configured"</code>.
+<code>boost pin</code>/<code>unpin</code> are in the <code>pkg</code> group and pin <em>skills</em>, not
+taps. So freezing the registries responsible for most of the re-embed cost is impossible on an
+existing install without untapping. Exposing the pin that already works is the cheapest lever here and
+worth landing first &mdash; measured, pinning just <code>jeremylongshore/claude-code-plugins-plus-skills</code>
+and <code>davila7/claude-code-templates</code> removes <b>75,227 of 112,081 moved chunks = 67.1%</b> of
+today's incremental cost, and <code>davila7</code> changed nothing boost indexes.
+
+<b>Shards do not cover this case.</b> Of the 19 moved taps exactly one appears in the published
+manifest, and its shard is pinned at the commit the tap just left, so <code>import_shard</code>
+refuses it. Net importable for this reindex: <b>0 of 112,081 chunks</b>.

boost_skill_cli-1.2.53/docs/roadmap/items/mcp-cannot-read-a-skill-before-installing.md

@@ -0,0 +1,67 @@
+---
+id: mcp-cannot-read-a-skill-before-installing
+board: code
+section: dx
+status: next
+category: MCP · UX
+complexity: S
+impact: High
+wow: 3
+note: boost_info returns the same one line boost_search already gave
+order: 127
+owner:
+pr:
+title: MCP has no way to read a skill before installing it
+---
+<code>boost_info</code>'s MCP description promises &ldquo;<em>the whole picture of one skill, rule or
+workflow by name &mdash; what it does, its kind, the tap it came from, its version, and whether it is
+already installed</em>&rdquo;. Called on a real hit it returns five fields:
+
+<code>name</code> &middot; <code>version</code> &middot; <code>tap</code> &middot;
+<code>description</code> &middot; <code>installed</code>
+
+&mdash; where <code>description</code> is <b>byte-identical to the one-liner
+<code>boost_search</code> already returned</b>. There is no body, no excerpt, no first paragraph. So
+&ldquo;what it does&rdquo; is the same sentence the agent already had, and the tool adds only
+<code>installed: no</code>, which the search reply already marks.
+
+<b>The consequence is that installing is the only way to read.</b> An agent deciding whether a skill
+is worth adopting has exactly one sentence to go on, written by whoever published it, and its only
+route to the actual procedure is to install it into the user's real
+<code>~/.agents/skills</code> and read it off disk. That inverts the tool's own pitch: the point of
+<code>boost_search</code> costing 10&ndash;15 s of LLM rerank is that the top result is
+&ldquo;worth acting on rather than skimming&rdquo;, and then nothing lets the agent look before it acts.
+
+<b>Why the one-liner is not enough, measured today.</b> A single search for embedding work returned ten
+hits, two of which &mdash; <code>ai-cost-optimization</code> and <code>rag-patterns</code>, both from
+<code>j4flmao/agent-skills</code> &mdash; carry the description &ldquo;<em>To optimize **Skill**, we
+enforce the following foundational rules:</em>&rdquo;. That is an unfilled template. Separately,
+<code>superpowers-lab</code> installs to an 868-byte <code>SKILL.md</code> whose entire Instructions
+section reads &ldquo;<em>This skill provides guidance and patterns for lab environment for claude
+superpowers.</em>&rdquo; &mdash; the name echoed back in every section. Both indexed, both ranked, both
+returned looking exactly like real results. <b>The body is the only thing that separates a written
+skill from a generated stub, and MCP cannot reach the body.</b> Note the eval gate cannot catch this
+either: <code>golden.jsonl</code> grades by <em>name</em>, and a stub matches its own name perfectly.
+
+<b>The fix is already written &mdash; it is just not exposed.</b> Two CLI commands already do this, both
+in the <code>info</code> module: <code>boost cat</code> (&ldquo;Print a skill or rule's contents&rdquo;,
+<code>cli.py:79</code>) and <code>boost explain</code> (&ldquo;Explain what a skill does in plain
+English&rdquo;, <code>cli.py:82</code>). The MCP server exposes six tools and neither is among them. And
+<code>core/mcp.py</code> is built for exactly this: tools self-register on a <code>Registry</code>, so
+adding one is &ldquo;<em>one <code>register()</code> call &mdash; no dispatcher edits, no server
+changes</em>&rdquo; (<code>mcp.py:7-10</code>).
+
+<b>Three things to get right, none of them large.</b>
+<b>(1) Prefer <code>cat</code> as the default.</b> It is offline, deterministic and free;
+<code>explain</code> goes through <code>core/ai.py</code>, costs seconds plus a key, and degrades to
+heuristics without one. The cheap answer must not sit behind the expensive one's latency &mdash; that is
+the same mistake <code>boost_list</code> avoids by never reading the catalog.
+<b>(2) Cap the bytes and say so when truncating.</b> A <code>SKILL.md</code> can be large and an MCP
+reply lands directly in an agent's context; returning a whole file unbounded is how one lookup costs a
+session. The <code>snip = text[:200]</code> convention exists for the same reason.
+<b>(3) Keep it read-only.</b> This is the tool that exists so an agent does <em>not</em> have to install
+to look; it must not become a second install path.
+
+<b>And fix the description either way.</b> If <code>boost_info</code> keeps returning five fields, it
+should stop claiming the whole picture &mdash; an overstated tool description costs an agent a wasted
+call and teaches it to distrust the rest of the surface.