boost-skill-cli 1.2.108__tar.gz → 1.2.109__tar.gz

{boost_skill_cli-1.2.108/boost_skill_cli.egg-info → boost_skill_cli-1.2.109}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.108
+Version: 1.2.109
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0
@@ -217,8 +217,11 @@ refused rather than silently picking one.
 
 Because vectors are keyed to a registry's commit, `quickstart` **pins** each tap
 it fetches vectors for, and `boost update` skips a pinned tap rather than moving
-it out from under them (`--force` moves it anyway and drops the pin). When a tap
-does move, boost checks whether a newer shard exists for the new commit and
+it out from under them (`--force` moves it anyway and drops the pin). A pinned
+tap with *no* clone is not skipped — there is nothing to hold still, so it is
+cloned and checked out at its pin; if that pin cannot be reached the clone is
+removed rather than left on HEAD with a pin that no longer describes it, and
+`compact --reclone` follows the same rule. When a tap does move, boost checks whether a newer shard exists for the new commit and
 imports it; if none does, it says so instead of leaving stale vectors looking
 fresh. `boost search` never refreshes taps behind your back, and never checks
 the manifest either — acting on that answer means moving taps and downloading

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.109}/README.md

@@ -175,8 +175,11 @@ refused rather than silently picking one.
 
 Because vectors are keyed to a registry's commit, `quickstart` **pins** each tap
 it fetches vectors for, and `boost update` skips a pinned tap rather than moving
-it out from under them (`--force` moves it anyway and drops the pin). When a tap
-does move, boost checks whether a newer shard exists for the new commit and
+it out from under them (`--force` moves it anyway and drops the pin). A pinned
+tap with *no* clone is not skipped — there is nothing to hold still, so it is
+cloned and checked out at its pin; if that pin cannot be reached the clone is
+removed rather than left on HEAD with a pin that no longer describes it, and
+`compact --reclone` follows the same rule. When a tap does move, boost checks whether a newer shard exists for the new commit and
 imports it; if none does, it says so instead of leaving stale vectors looking
 fresh. `boost search` never refreshes taps behind your back, and never checks
 the manifest either — acting on that answer means moving taps and downloading

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.109}/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.108'
-__version_tuple__ = version_tuple = (1, 2, 108)
+__version__ = version = '1.2.109'
+__version_tuple__ = version_tuple = (1, 2, 109)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.109}/boost_cli/commands/configuration.py

@@ -370,9 +370,26 @@ def cmd_compact(argv) -> int:
                     # other — nothing about `--reclone` consults the pin — so
                     # without this the clone silently lands on HEAD while
                     # config.json, the catalog cache and `boost taps` keep
-                    # naming the old commit. checkout_commit's own BoostError
-                    # (unresolvable pin) surfaces through the except below.
-                    gitutil.checkout_commit(tap.path, tap.pin)
+                    # naming the old commit.
+                    try:
+                        gitutil.checkout_commit(tap.path, tap.pin)
+                    except BoostError:
+                        # `--reclone` removed the clone before making this
+                        # one, so the pinned tree is already gone and there is
+                        # nothing to fall back to. Letting the `except` below
+                        # warn and carry on would leave a clone sitting on
+                        # HEAD with the old pin still recorded beside it, and
+                        # the next `update` reads `is_cloned` true plus a pin
+                        # and answers "pinned at <sha> (skipped)" — forever,
+                        # for a tree that is not on that commit. Remove it
+                        # instead: `doctor` names a tap with no clone (`! tap
+                        # <x> not cloned`, exit 1) and `update` re-clones it
+                        # back onto its pin, so the tap ends in a state
+                        # something reports and something repairs.
+                        # `registry.update` takes the same exit on the same
+                        # failure; this is the path that gets there first.
+                        util.rmtree(tap.path)
+                        raise
                 # The re-clone can change what's on disk even when the byte
                 # count doesn't (a pinned tap's tree is identical, but the
                 # cache's recorded commit and mtime are now stale either way).

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.109}/boost_cli/commands/discovery.py

@@ -578,15 +578,30 @@ def cmd_reindex(argv):
     # and the count above reads exactly as it does for a full corpus. Say what
     # the index actually holds, in the share of TEXT rather than of documents —
     # a document share reads 100% until it reads 0%.
+    #
+    # The share quoted is of the tokens THIS INDEX holds, and the sentence says
+    # so. It used to read "this index holds N% of the searchable text", which
+    # is a share of the corpus — a number nothing here can compute, because the
+    # bodies that were never read have no token count to compare against. Since
+    # a body runs about an order of magnitude longer than the metadata standing
+    # in for it, that reading overstated badly in exactly the partly-cloned case
+    # this warning exists for: a half-cloned index announced itself as 94%
+    # complete, and one unreadable file among a thousand rendered as "100.0% of
+    # the searchable text" inside a warning about missing text.
     if stats["metadata_only"]:
         share = rag.index_completeness() or {}
-        out.warn("%d of %d items were indexed from catalog metadata alone — "
-                 "their registries are not cloned here, so this index holds "
-                 "%.1f%% of the searchable text. Tap them for real with "
-                 "`boost tap <owner/repo>` and re-run `boost reindex` to index "
-                 "their bodies."
-                 % (stats["metadata_only"], stats["docs"],
-                    100.0 * share.get("body_share", 0.0)), wrap=True)
+        tokens = share.get("tokens") or 0
+        meta_tokens = share.get("metadata_only_tokens") or 0
+        # No tokens at all means nothing but metadata got as far as the index,
+        # so 100% is the honest reading rather than a division to protect.
+        meta_pct = (100.0 * meta_tokens / tokens) if tokens else 100.0
+        out.warn("%d of %d indexed items have no body text — their registries "
+                 "are not cloned here, so only their catalog metadata was "
+                 "indexed, and that metadata is %.1f%% of everything this "
+                 "index holds. Clone them with `boost update`, then re-run "
+                 "`boost reindex --force` to index their bodies."
+                 % (stats["metadata_only"], stats["docs"], meta_pct),
+                 wrap=True)
     if args.dense:
         if dense_stats is None:
             out.warn("dense index skipped — %s" % embed.fallback_note(),

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.109}/boost_cli/core/rag.py

@@ -789,10 +789,21 @@ def index_completeness() -> dict | None:
     ``body_share`` is a share of **tokens**, not of documents, and that is the
     whole point. An entry whose body is missing still produces a document, so a
     document share sits at 1.0 until the moment it drops to 0.0 and tells a
-    partially-cloned machine nothing. The token share degrades smoothly and
-    reproduces the measurement the roadmap card made by hand: 3,041,326 tokens
-    against 182,507 over 3,015 entries indexed with and then without their
-    clones, or 6.0% of the searchable text.
+    partially-cloned machine nothing.
+
+    It describes **this index**, not the corpus behind it: the fraction of the
+    tokens actually indexed that came from a document carrying a body. The
+    share of the *corpus's* text that made it in is a different number, and it
+    is not computable here — the bodies that were never read have no token
+    count to compare against, by construction. An earlier version of this
+    docstring claimed the value "reproduces the measurement the roadmap card
+    made by hand ... or 6.0% of the searchable text". It does not: for that
+    input every token indexed came from metadata, so it returns **0.0**. The
+    two move in opposite directions, and because a body runs about an order of
+    magnitude longer than the metadata standing in for it, presenting this as
+    corpus completeness overstates a half-cloned machine badly. Callers must
+    say which share they are quoting; :func:`cmd_reindex` quotes
+    ``metadata_only_tokens / tokens`` and names it.
 
     Reads the persisted totals rather than re-deriving them, so asking is a
     stat plus a cached parse — nothing walks the corpus.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.109/boost_skill_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.108
+Version: 1.2.109
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0
@@ -217,8 +217,11 @@ refused rather than silently picking one.
 
 Because vectors are keyed to a registry's commit, `quickstart` **pins** each tap
 it fetches vectors for, and `boost update` skips a pinned tap rather than moving
-it out from under them (`--force` moves it anyway and drops the pin). When a tap
-does move, boost checks whether a newer shard exists for the new commit and
+it out from under them (`--force` moves it anyway and drops the pin). A pinned
+tap with *no* clone is not skipped — there is nothing to hold still, so it is
+cloned and checked out at its pin; if that pin cannot be reached the clone is
+removed rather than left on HEAD with a pin that no longer describes it, and
+`compact --reclone` follows the same rule. When a tap does move, boost checks whether a newer shard exists for the new commit and
 imports it; if none does, it says so instead of leaving stale vectors looking
 fresh. `boost search` never refreshes taps behind your back, and never checks
 the manifest either — acting on that answer means moving taps and downloading

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.109}/boost_skill_cli.egg-info/SOURCES.txt

@@ -207,6 +207,7 @@ docs/roadmap/items/BOOST-D24.md
 docs/roadmap/items/BOOST-D25.md
 docs/roadmap/items/BOOST-D26.md
 docs/roadmap/items/BOOST-D27.md
+docs/roadmap/items/a-new-shipped-card-always-404s-its-own-write-up-link.md
 docs/roadmap/items/a11y-sweep-flakes-on-color-contrast.md
 docs/roadmap/items/accessibility-audit-pa11y-ci-axe-core.md
 docs/roadmap/items/actionlint-skips-shellcheck-silently.md
@@ -357,6 +358,7 @@ docs/roadmap/items/codeql-job-rename-stranded-merge-protection.md
 docs/roadmap/items/cold-search-reads-the-whole-catalogue.md
 docs/roadmap/items/command-carousel-page.md
 docs/roadmap/items/command-reference-docs-site.md
+docs/roadmap/items/compact-answers-a-named-tap-with-a-global-all-clear.md
 docs/roadmap/items/completions-complete-only-command-names.md
 docs/roadmap/items/completions-install-could-eat-your-rc-file.md
 docs/roadmap/items/complexity-and-dead-code-radar-xenon-vulture.md
@@ -455,6 +457,7 @@ docs/roadmap/items/langchain-retriever-metadata-and-k-floor.md
 docs/roadmap/items/layering-guard-import-linter.md
 docs/roadmap/items/license-compliance-scanning.md
 docs/roadmap/items/lighthouse-ci-on-the-pages-site.md
+docs/roadmap/items/lighthouse-flips-on-byte-identical-input.md
 docs/roadmap/items/lighthouse-scored-a-page-nobody-is-served.md
 docs/roadmap/items/lint-tap-misscopes-rule-workflow-entries.md
 docs/roadmap/items/list-rules-and-workflows.md
@@ -548,10 +551,12 @@ docs/roadmap/items/ranx-significance-monitor.md
 docs/roadmap/items/readme-81-command-table-lists-80-omits-quickstart.md
 docs/roadmap/items/readme-hero-installs-a-name-no-starter-registry-ships.md
 docs/roadmap/items/readme-prune-and-search-guide.md
+docs/roadmap/items/reclone-leaves-a-clone-on-head-when-it-cannot-reach-the-pin.md
 docs/roadmap/items/recommend-recomputes-its-columns-per-row.md
 docs/roadmap/items/reconcile-the-theme-drift.md
 docs/roadmap/items/refresh-strands-the-natural-set-baseline.md
 docs/roadmap/items/refresh-the-marketing-surface.md
+docs/roadmap/items/reindex-reported-a-completeness-share-it-could-not-compute.md
 docs/roadmap/items/rel-time-tests-race-the-wall-clock.md
 docs/roadmap/items/release-verifies-the-wrong-commit.md
 docs/roadmap/items/relicence-apache-2.md
@@ -624,6 +629,7 @@ docs/roadmap/items/sync-reported-success-for-a-link-it-refused.md
 docs/roadmap/items/table-fit-widths-floor-destroys-columns-and-still-overflows.md
 docs/roadmap/items/tap-signing-and-provenance-sigstore-minisign.md
 docs/roadmap/items/taps-check-out-freight-they-never-index.md
+docs/roadmap/items/taps-vouches-for-a-clone-that-is-not-there.md
 docs/roadmap/items/the-catalogue-advertised-repos-that-no-longer-exist.md
 docs/roadmap/items/the-scale-corpus-refreshed-the-wrong-rows.md
 docs/roadmap/items/the-shard-job-that-could-not-finish.md

boost_skill_cli-1.2.109/docs/roadmap/items/a-new-shipped-card-always-404s-its-own-write-up-link.md

@@ -0,0 +1,42 @@
+---
+id: a-new-shipped-card-always-404s-its-own-write-up-link
+board: code
+section: pipeline
+status: planned
+category: CI · Bug
+complexity: S
+impact: Medium
+wow: 3
+note: the links check goes red on every correct PR that files a new card as shipped, and green again on merge
+order: 313
+owner:
+pr:
+title: "A new card filed as <code>shipped</code> always 404s its own write-up link"
+---
+<code>build_roadmap.py</code> renders a settled card's body as a link to the item file on
+<b><code>main</code></b> &mdash; <code>ITEMS_URL</code> (line 206) is
+<code>https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items</code>, and
+<code>_body_html</code> emits it for any status in <code>_SETTLED</code>. The
+<code>links</code> job runs on <code>pull_request</code> over
+<code>docs/*.html</code>. So a PR that files a <em>new</em> card at
+<code>status: shipped</code> renders a link to a file that does not exist on
+<code>main</code> yet, and lychee rejects it 404 &mdash; on a PR where nothing is wrong.
+It goes green by itself the moment the PR merges.
+
+Observed on PR <code>#845</code>, whose 22 required checks were all green:
+<em>&ldquo;[404] &lt;&hellip;/blob/main/docs/roadmap/items/reclone-leaves-a-clone-on-head-when-it-cannot-reach-the-pin.md&gt; (at 4125:54) | Rejected status code: 404 Not Found&rdquo;</em>.
+The mechanism is deterministic from the three sources above rather than inferred from that
+one run: any new item file whose first committed status is settled hits it. Cards that were
+already on <code>main</code> and merely change status do not, which is why this went
+unnoticed &mdash; the usual shape is claim-then-ship across two PRs.
+
+It matters because the remedy people reach for is the wrong one: either the card gets
+filed at a status that misdescribes it to keep CI quiet, or a check that is right about
+everything else gets learned as noise. <code>links</code> is advisory rather than
+required, which caps the damage and is also what lets it rot unnoticed. Options, cheapest
+first: resolve the link against the <em>head</em> ref in CI
+(<code>GITHUB_HEAD_REF</code>) and <code>main</code> elsewhere; or let lychee treat a
+<code>blob/main</code> URL whose path exists in the working tree as satisfied; or link the
+raw file relatively and accept that GitHub Pages serves <code>.md</code> as a download
+rather than rendered Markdown &mdash; which is the reason the absolute URL was chosen, so
+that one is a trade, not a fix.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.109}/docs/roadmap/items/audit-pinned-taps-silently-moved-to-head-by-update-re-clone-and-co.md

@@ -2,12 +2,12 @@
 id: audit-pinned-taps-silently-moved-to-head-by-update-re-clone-and-co
 board: code
 section: internals
-status: inflight
+status: shipped
 category: Safety · Bug
 complexity: M
 impact: High
 wow: 2
-note: compact --reclone moved a pin to HEAD and printed "every tap is already compact"
+note: three broken paths, three PRs claiming it, and one residual that took a second item to finish
 order: 216
 owner: loop/tap-pin-integrity
 pr: 725
@@ -43,3 +43,14 @@ size-only report at <code>configuration.py:288-292</code> is what hid the move.
 pinned-tap paragraph (lines 176-178) and its <code>compact --reclone</code> line (274); regenerate
 <code>docs/commands.html</code> only if the <code>--force</code> help string changes. Found by the
 2026-08 CLI audit (cluster <code>pinned-tap-integrity</code>); repro in the audit log.
+
+
+<b>Closed 2026-09-10.</b> <code>#725</code> landed the <code>registry.update</code> half
+(both the <code>--force</code> unpin and the re-clone of a pinned tap whose clone had
+vanished, with <code>tests/unit/test_tap_pins.py</code> covering each). The
+<code>compact --reclone</code> half landed in two pieces: the pin checkout, the
+<code>catalog.rebuild_tap</code> and the size-independent report came with
+<code>#725</code>; the unresolvable-pin guard was left behind when three PRs claimed this
+one item and only one could merge, and is its own card &mdash;
+<code>reclone-leaves-a-clone-on-head-when-it-cannot-reach-the-pin</code>. All three paths
+named above are now closed, and README's pinned-tap paragraph says what the code does.

boost_skill_cli-1.2.109/docs/roadmap/items/compact-answers-a-named-tap-with-a-global-all-clear.md

@@ -0,0 +1,36 @@
+---
+id: compact-answers-a-named-tap-with-a-global-all-clear
+board: code
+section: internals
+status: planned
+category: CLI · Bug
+complexity: S
+impact: Medium
+wow: 2
+note: boost compact <tap> on an uncloned tap prints a green "no cloned taps to compact" and exits 0
+order: 311
+owner:
+pr:
+title: "<code>compact &lt;tap&gt;</code> answers a question about one tap with a global all-clear"
+---
+<code>cmd_compact</code> resolves its named taps and then filters
+(<code>taps = [t for t in taps if t.is_cloned]</code>). A tap that is configured but has
+no clone falls out of that list silently, so the empty-list branch fires and prints
+<em>&ldquo;&#10003; no cloned taps to compact&rdquo;</em> with exit 0 &mdash; a green,
+plural, global-sounding all-clear in answer to a question about one specific tap, which
+it never names.
+
+Reproduced on a scratch <code>BOOST_HOME</code>: tap a repo, delete its clone directory,
+then <code>boost compact &lt;that-tap&gt;</code> &rarr; <code>rc=0</code>,
+<em>&ldquo;&#10003; no cloned taps to compact&rdquo;</em>. Meanwhile
+<code>boost doctor</code> exits 1 on the same machine and says
+<em>&ldquo;! tap &lt;x&gt; not cloned &mdash; run <code>boost update</code>&rdquo;</em>,
+so the information exists and this command is the one that withholds it.
+
+This contradicts the convention <code>registry.update</code> states in its own docstring:
+<em>&ldquo;A named tap still raises. <code>boost update sometap</code> is a request about
+that one tap, so its failure is the answer to the question asked.&rdquo;</em> The sweep
+form is right to stay quiet; the named form is not. Fix: when <code>args.tap</code> named
+taps and the filter dropped some, say which and why, and point at
+<code>boost update</code> the way <code>doctor</code> does &mdash; and do not report
+success for a tap nothing was done to.

boost_skill_cli-1.2.109/docs/roadmap/items/lighthouse-flips-on-byte-identical-input.md

@@ -0,0 +1,44 @@
+---
+id: lighthouse-flips-on-byte-identical-input
+board: code
+section: docsite
+status: planned
+category: CI · Bug
+complexity: M
+impact: High
+wow: 4
+note: the same roadmap.html scored 0.78 and passed, then 0.78 and failed — the gate now decides on runner noise
+order: 314
+owner:
+pr:
+title: The performance gate flips on byte-identical input
+---
+<code>lighthouse</code> asserts <code>categories.performance &ge; 0.80</code> on
+<code>docs/roadmap.html</code>. That page now scores <b>0.76&ndash;0.78</b>, so the
+assertion is decided by whichever way runner timing falls, not by the page. <b>Two commits
+on one branch, whose <code>docs/roadmap.html</code> is byte-identical
+(<code>sha256 42bdc4f7&hellip;</code>, 784,560&nbsp;bytes both), got opposite verdicts</b>
+&mdash; <code>c75f4a9f</code> failed, <code>037a2468</code> passed, 60 seconds apart. The
+same oscillation is visible on other branches in the run history:
+<code>loop/missing-json</code> failed at <code>2a5231cb</code> and passed at
+<code>1c949b7d</code>; <code>loop/audit-retrieval-search-onboarding</code> failed twice
+then passed.
+
+Three earlier cards closed real findings here &mdash;
+<code>lighthouse-ci-on-the-pages-site</code> installed the budgets,
+<code>lighthouse-scored-a-page-nobody-is-served</code> fixed a harness sending 3.27x the
+bytes Pages sends, and <code>roadmap-page-weight-grows-without-bound</code> found it was
+<em>never the bytes</em> but 705&nbsp;ms of <code>styleLayout</code>, and bought headroom
+by letting 55.5% of elements skip it. That headroom has since been spent: the board was
+407.6&nbsp;KB when that card was written and is <b>787&nbsp;KB</b> now. So this is not a
+re-file of any of them &mdash; it is what happens after their fix, and the symptom is
+different in kind: a gate that cannot decide rather than a page that is slow.
+
+Why it matters more than two hundredths of a score: a check that fails on input it just
+passed is a check people learn to re-run rather than read, and the next real regression
+arrives looking exactly like the last false one. <code>lighthouse</code> is advisory, not
+required, which is what has let it drift this far unnoticed. Fix &mdash; decide which
+guarantee is wanted, then make the gate express it: assert the median of the three runs
+rather than the worst, or floor at a value the page actually clears and put a separate
+bound on the growth that is eating the margin, so the number that moves is the one being
+regressed. Lowering the floor alone just relocates the coin flip.

boost_skill_cli-1.2.109/docs/roadmap/items/reclone-leaves-a-clone-on-head-when-it-cannot-reach-the-pin.md

@@ -0,0 +1,41 @@
+---
+id: reclone-leaves-a-clone-on-head-when-it-cannot-reach-the-pin
+board: code
+section: internals
+status: shipped
+category: Safety · Bug
+complexity: S
+impact: High
+wow: 3
+note: the last unfixed path of the pin-integrity item, left behind when three PRs claimed it and one won
+order: 310
+owner: loop/reclone-pin-integrity
+pr: 845
+title: "<code>compact --reclone</code> left a clone on HEAD when it could not reach the pin"
+---
+The residual of <code>audit-pinned-taps-silently-moved-to-head-by-update-re-clone-and-co</code>,
+and it survived for a reason worth recording: <b>three PRs claimed that item, all
+22/22 green, and none was a strict superset.</b> <code>#725</code> guarded the
+unresolvable pin in <code>registry.update</code> and won on the older claim;
+<code>#738</code> guarded it in <code>compact --reclone</code> and was closed. The
+closing comment named the gap and asked for it back as its own item &mdash; this is
+that item, and the fix is <code>#738</code>'s, applied to current <code>main</code>.
+
+What was left: <code>--reclone</code> deletes the clone <em>before</em> it makes a new
+one, so by the time <code>gitutil.checkout_commit</code> raises on a pin it cannot
+resolve, the pinned tree is already gone. The <code>except BoostError</code> below
+warned and carried on, leaving a clone sitting on HEAD with the old pin still recorded
+beside it in <code>config.json</code>. The next <code>update</code> then reads
+<code>is_cloned</code> true <em>plus</em> a pin and answers
+<em>&ldquo;pinned at &lt;sha&gt; (skipped)&rdquo;</em> &mdash; permanently, for a tree
+that is not on that commit. Prebuilt shard vectors are keyed to that pin, so the tap
+carries stale vectors that are still present and raise no error: the failure that looks
+like nothing at all.
+
+The fix removes the half-made clone and re-raises, which is exactly what
+<code>registry.update</code> already does on the same failure &mdash; this is simply the
+path that gets there first. Not-cloned is a state <code>doctor</code> names
+(<em>&ldquo;! tap &lt;x&gt; not cloned&rdquo;</em>, exit 1) and one <code>update</code>
+repairs, landing the tap back on its pin. Cloned-but-lying is neither. The pin itself is
+kept, because it is the target <code>update</code> needs; dropping it would be the
+silent move by another route.

boost_skill_cli-1.2.109/docs/roadmap/items/reindex-reported-a-completeness-share-it-could-not-compute.md

@@ -0,0 +1,55 @@
+---
+id: reindex-reported-a-completeness-share-it-could-not-compute
+board: code
+section: internals
+status: shipped
+category: Correctness · Bug
+complexity: S
+impact: High
+wow: 4
+note: shipped in v1.2.108 and caught by an adversarial review of the merge that carried it
+order: 315
+owner: batch/train-23
+pr: 847
+title: "<code>reindex</code> reported a completeness share it could not compute"
+---
+The completeness warning added alongside the keyword-index work said
+<em>&ldquo;this index holds N% of the searchable text&rdquo;</em> &mdash; a share of the
+<strong>corpus</strong>. The number behind it, <code>body_share</code>, is
+<code>1 - metadata_only_tokens / tokens</code>: a share of the tokens
+<strong>already in the index</strong> that came from a document carrying a body. Those
+are different quantities, and they move in opposite directions.
+
+The corpus share is not computable here, which is why this is not a sign error. The
+bodies that were never read have no token count to compare against, by construction, so
+no rearrangement of what <code>_save</code> records can recover it.
+
+Because a body runs about an order of magnitude longer than the metadata standing in for
+it, the printed figure overstated completeness in exactly the partly-cloned case the
+warning exists for. Measured against the shipped code: a half-cloned index holding 53% of
+its corpus announced <strong>94.3%</strong>; a single unreadable <code>SKILL.md</code>
+among 1,001 documents rendered as <strong>100.0% of the searchable text</strong> inside a
+warning whose first clause says text is missing; and the bundle-only shape the feature was
+built for &mdash; the one the card measured at 6.0% &mdash; printed <strong>0.0%</strong>.
+
+Two things kept it invisible. The docstring asserted the value
+<em>&ldquo;reproduces the measurement the roadmap card made by hand &hellip; or 6.0% of
+the searchable text&rdquo;</em>, which it never did. And the tests pinned the mismatch
+rather than catching it: the functional test asserted the literal string
+<code>0.0% of the searchable text</code>, while the unit test's only guard on a mixed
+corpus was <code>0.0 &lt; body_share &lt; 1.0</code> &mdash; satisfied by every overstated
+value &mdash; under a comment claiming the share would sit <em>&ldquo;well under
+0.5&rdquo;</em> when it is in fact above it.
+
+The remedy the line printed was inert in both halves. <code>boost tap &lt;owner/repo&gt;</code>
+raises <code>tap &lt;x&gt; is already configured</code> for a tap the bundle has already written
+into <code>config.json</code>, which is precisely the <code>catalog --import</code> shape;
+and a plain <code>boost reindex</code> reuses any tap whose commit has not moved &mdash;
+<code>build</code>'s predicate never consults whether a clone is present &mdash; so the
+flagged documents are carried forward verbatim and the bodies are never read. The line now
+says <code>boost update</code>, then <code>boost reindex --force</code>.
+
+The warning now quotes <code>metadata_only_tokens / tokens</code> and names it: how much of
+what this index holds is catalog metadata. That reads 100% for the bundle-only shape, which
+is the sentence the feature wanted all along, and it stays true in the two cases that
+previously inverted.

boost_skill_cli-1.2.109/docs/roadmap/items/taps-vouches-for-a-clone-that-is-not-there.md

@@ -0,0 +1,42 @@
+---
+id: taps-vouches-for-a-clone-that-is-not-there
+board: code
+section: internals
+status: planned
+category: CLI · Bug
+complexity: S
+impact: Medium
+wow: 3
+note: boost taps prints item counts and an UPDATED date for a tap whose clone was deleted
+order: 312
+owner:
+pr:
+title: "<code>boost taps</code> vouches for a clone that is not there"
+---
+<code>boost taps</code> reads the per-tap catalog cache, and
+<code>catalog.load_tap</code> deliberately serves a stale cache when the clone is gone
+(rescanning is only possible while the clone exists &mdash; making the missing clone an
+error there would trade a missing field for a missing catalogue). The consequence
+reaches the readout unlabelled: a tap whose clone has been deleted still prints its
+<code>NAME</code>, an <code>ITEMS</code> count and an <code>UPDATED</code> date, and the
+footer still counts it in <em>&ldquo;N taps &middot; N items&rdquo;</em>. Nothing on the
+line says the clone is missing.
+
+Measured on a scratch <code>BOOST_HOME</code>: after deleting the clone directory,
+<code>boost taps</code> printed <code>probe-src &nbsp;1&nbsp; 2026-09-10</code> and
+<em>&ldquo;1 taps &middot; 1 items&rdquo;</em> &mdash; while <code>boost doctor</code>
+exited 1 with <em>&ldquo;! tap &lt;x&gt; not cloned&rdquo;</em>. Two readouts of the same
+machine, one of which is wrong, and the wrong one is the command whose entire job is to
+describe the taps.
+
+It is the same shape as the pin bugs in
+<code>audit-pinned-taps-silently-moved-to-head-by-update-re-clone-and-co</code>: a
+readout that keeps vouching for state the clone no longer has. The precedent is in
+the tree: <code>boost list</code> carries a <code>FLAGS</code> column for exactly this
+reason, and <code>info.py:239-241</code> states it &mdash; <em>&ldquo;so a quarantined or
+pinned rule/workflow doesn't render byte-identical to a healthy one &hellip; a reader
+needs to see that here, not just in --json&rdquo;</em>. Its values are
+<code>pinned</code> and <code>quarantined</code>; a tap with no clone is the same class of
+fact about a different table. Fix: <code>taps</code> already has
+<code>tap.is_cloned</code> in hand, so mark the row and keep the footer counts honest,
+rather than leaving <code>doctor</code> as the only command that knows.