PyPI - boost-skill-cli - Versions diffs - 1.2.102__tar.gz → 1.2.104__tar.gz - Mend

boost-skill-cli 1.2.102tar.gz → 1.2.104tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1013) hide show

{boost_skill_cli-1.2.102/boost_skill_cli.egg-info → boost_skill_cli-1.2.104}/PKG-INFO RENAMED Viewed

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

{boost_skill_cli-1.2.102 → boost_skill_cli-1.2.104}/boost_cli/_version.py RENAMED Viewed

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
-__version__ = version = '1.2.102'
-__version_tuple__ = version_tuple = (1, 2, 102)
+__version__ = version = '1.2.104'
+__version_tuple__ = version_tuple = (1, 2, 104)
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.102 → boost_skill_cli-1.2.104/boost_skill_cli.egg-info}/PKG-INFO RENAMED Viewed

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

{boost_skill_cli-1.2.102 → boost_skill_cli-1.2.104}/boost_skill_cli.egg-info/SOURCES.txt RENAMED Viewed

@@ -321,6 +321,7 @@ docs/roadmap/items/audit-verify-drift-say-nothing-installed-exit-0-and-doctor-sa
 docs/roadmap/items/audit-verify-findings.md
 docs/roadmap/items/audit-who-findings.md
 docs/roadmap/items/autonomous-ship-workflow-and-isolated-worktree.md
+docs/roadmap/items/bm25-empty-tokenization-kills-catalog-fallback.md
 docs/roadmap/items/bm25-has-no-stemming.md
 docs/roadmap/items/bm25-index-is-one-json-blob.md
 docs/roadmap/items/bmad-autopilot-one-command-persona-routing.md
@@ -359,6 +360,8 @@ docs/roadmap/items/completions-install-could-eat-your-rc-file.md
 docs/roadmap/items/complexity-and-dead-code-radar-xenon-vulture.md
 docs/roadmap/items/concurrent-rag-builds-delete-each-others-temp-index.md
 docs/roadmap/items/consolidate-skill-staleness-drift-logic-into-cor.md
+docs/roadmap/items/corpus-refresh-updates-data-not-prose.md
+docs/roadmap/items/corrupt-config-reads-as-ready-to-set-up.md
 docs/roadmap/items/coverage-dashboard-codecov-free-for-oss.md
 docs/roadmap/items/coverage-guided-fuzzing-atheris-oss-fuzz.md
 docs/roadmap/items/crash-listing-branch-untested.md
@@ -368,6 +371,9 @@ docs/roadmap/items/delay-true-defeats-the-log-suppress.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-kill-switch-has-no-reason-state.md
+docs/roadmap/items/dense-no-key-guard-is-unreachable.md
+docs/roadmap/items/dense-ready-but-embedder-cannot-run.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
@@ -382,18 +388,25 @@ docs/roadmap/items/discover-searches-github-not-a-stale-sample.md
 docs/roadmap/items/docsite-chrome-and-content-audit.md
 docs/roadmap/items/docstring-coverage-interrogate.md
 docs/roadmap/items/doctor-checks-rules-and-workflows.md
+docs/roadmap/items/doctor-prescribes-sync-that-deletes-live-links.md
 docs/roadmap/items/dry-run-promised-a-link-nobody-makes.md
 docs/roadmap/items/efficiency-registries-ponytail-caveman.md
 docs/roadmap/items/end-of-options-guard-on-git-commands.md
+docs/roadmap/items/err-multiline-hint-colours-across-the-newline.md
 docs/roadmap/items/est-items-counts-agent-mirrors-as-items.md
 docs/roadmap/items/eval-corpus-cannot-see-real-retrieval.md
+docs/roadmap/items/eval-corpus-counted-by-the-method-the-repo-disavows.md
+docs/roadmap/items/eval-corpus-duplication-is-intra-tap-not-mirrors.md
 docs/roadmap/items/eval-corpus-is-96x-smaller-than-a-real-install.md
 docs/roadmap/items/eval-corpus-is-one-strangers-repo.md
 docs/roadmap/items/eval-corpus-pins-have-no-refresh-path.md
 docs/roadmap/items/eval-corpus-was-not-actually-pinned.md
 docs/roadmap/items/eval-deduped-ranked-lists-by-name.md
+docs/roadmap/items/eval-floor-calibration-stale-after-pin-refresh.md
+docs/roadmap/items/eval-gate-scores-a-body-less-corpus.md
 docs/roadmap/items/eval-stats-could-never-publish.md
 docs/roadmap/items/expanded-card-bodies-overflow.md
+docs/roadmap/items/explain-outline-has-no-cap.md
 docs/roadmap/items/extension-free-tests-core-dense-py.md
 docs/roadmap/items/extract-mcp-http-servers-out-of-configuration-py.md
 docs/roadmap/items/finish-mutation-hardening-across-core.md
@@ -403,6 +416,8 @@ docs/roadmap/items/framework-adapter-langgraph.md
 docs/roadmap/items/framework-adapter-multi-agent.md
 docs/roadmap/items/framework-adapters-boost-adapt.md
 docs/roadmap/items/frontmatter-scalar-over-coercion.md
+docs/roadmap/items/gate-parity-test-ignores-k-and-golden.md
+docs/roadmap/items/gated-golden-set-has-zero-exemplars.md
 docs/roadmap/items/gemini-agent-frontmatter-sanitizer.md
 docs/roadmap/items/gemini-cli-agent-target.md
 docs/roadmap/items/gemini-duplicate-skill-discovery.md
@@ -416,6 +431,7 @@ docs/roadmap/items/gstack-tap-first-then-coexistence.md
 docs/roadmap/items/hash-pinned-reproducible-toolchain-uv-lock.md
 docs/roadmap/items/heal-deleted-links-it-never-made.md
 docs/roadmap/items/html-validation-html-validate.md
+docs/roadmap/items/info-deps-materialize-a-dir-they-then-reject.md
 docs/roadmap/items/info-rejects-the-qualified-name-it-recommends.md
 docs/roadmap/items/install-docs-never-mentioned-upgrading.md
 docs/roadmap/items/install-from-path-bypasses-policy-and-pin-checks.md
@@ -457,14 +473,17 @@ 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-description-omits-antigravity.md
 docs/roadmap/items/mcp-install-skips-the-injection-scan.md
 docs/roadmap/items/mcp-launch-objc-fork-safety.md
 docs/roadmap/items/mcp-one-benefit-nameable-task.md
 docs/roadmap/items/mcp-register-names-server-before-env.md
 docs/roadmap/items/mcp-search-before-reinventing.md
+docs/roadmap/items/mcp-search-cost-overstated-on-keyless-machines.md
 docs/roadmap/items/mcp-search-cost-was-understated.md
 docs/roadmap/items/mcp-search-hid-which-ranking-ran.md
 docs/roadmap/items/mcp-servers-ignore-install-scope.md
+docs/roadmap/items/mcp-skip-list-absent-from-tool-descriptions.md
 docs/roadmap/items/mcp-startup-self-harden-fork-safety.md
 docs/roadmap/items/mcp-zero-setup-and-three-kinds.md
 docs/roadmap/items/memoize-config-load-in-process.md
@@ -492,6 +511,7 @@ docs/roadmap/items/openssf-playbook.md
 docs/roadmap/items/openssf-silver.md
 docs/roadmap/items/osps-baseline-levels.md
 docs/roadmap/items/package-metadata-validation-twine-check-friends.md
+docs/roadmap/items/panel-fits-data-to-an-assumed-80-in-a-pipe.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
@@ -516,10 +536,18 @@ docs/roadmap/items/published-shards-have-no-consumer.md
 docs/roadmap/items/pytest-tmpdir-cve-blocked-by-py39-floor.md
 docs/roadmap/items/python-floor-moves-to-312.md
 docs/roadmap/items/quality-dashboard-sonarcloud-free-for-oss.md
+docs/roadmap/items/quickstart-drops-incompatible-shard-status.md
+docs/roadmap/items/quickstart-manifest-error-drops-hint-and-misnames-cause.md
+docs/roadmap/items/quickstart-says-ready-exit-0-after-every-tap-failed.md
+docs/roadmap/items/quickstart-shard-download-invisible-in-preview-and-run.md
 docs/roadmap/items/ragas-unpin-when-upstream-ships.md
 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/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/rel-time-tests-race-the-wall-clock.md
 docs/roadmap/items/release-verifies-the-wrong-commit.md
@@ -530,6 +558,7 @@ docs/roadmap/items/required-checks-config-drift.md
 docs/roadmap/items/resolve-vendored-duplicate-copies.md
 docs/roadmap/items/retrieval-quality-eval-harness.md
 docs/roadmap/items/reuse-helpers-kill-minor-dead-work.md
+docs/roadmap/items/roadmap-boards-advertise-python-39.md
 docs/roadmap/items/roadmap-html-goes-stale-on-every-rebase.md
 docs/roadmap/items/roadmap-page-weight-grows-without-bound.md
 docs/roadmap/items/roadmap-perf-budget-has-no-local-guard.md
@@ -548,7 +577,13 @@ docs/roadmap/items/scheduled-toolchain-lock-regeneration.md
 docs/roadmap/items/scorecard-findings-triage.md
 docs/roadmap/items/scripts-under-the-lint-gate.md
 docs/roadmap/items/search-and-browse-visual-refresh.md
+docs/roadmap/items/search-caps-the-two-copyable-identifiers.md
+docs/roadmap/items/search-drops-symbol-language-queries-silently.md
+docs/roadmap/items/search-footer-not-fitted-to-the-pane-its-rows-were-fitted-to.md
+docs/roadmap/items/search-footer-overflows-40-col-pane-gate-passes-by-luck.md
 docs/roadmap/items/search-never-notices-a-new-tap.md
+docs/roadmap/items/search-relevance-meter-is-constant-on-default-page.md
+docs/roadmap/items/search-rows-use-term-width-so-piping-drops-the-tap-column.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
@@ -568,22 +603,26 @@ docs/roadmap/items/single-imperative-rule-extractor.md
 docs/roadmap/items/single-tech-stack-prober.md
 docs/roadmap/items/smart-rerank-pays-per-novel-query.md
 docs/roadmap/items/split-oversized-command-modules.md
+docs/roadmap/items/stale-gate-sizes-in-readme-and-contributing.md
 docs/roadmap/items/startup-and-import-time-budget-x-importtime.md
 docs/roadmap/items/stop-re-serializing-entry-meta-on-every-search.md
 docs/roadmap/items/structured-json-log-output-mode.md
 docs/roadmap/items/supply-chain-posture-openssf-scorecard.md
+docs/roadmap/items/surface-dehyphenation-rationale-is-false.md
 docs/roadmap/items/surface-every-docs-page-from-the-guide.md
 docs/roadmap/items/sweep-died-at-launch-not-at-a-page.md
 docs/roadmap/items/sync-could-not-repair-a-gutted-skill.md
 docs/roadmap/items/sync-deletes-unowned-broken-symlinks.md
 docs/roadmap/items/sync-relinks-into-every-agent-ignoring-scope.md
 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/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
 docs/roadmap/items/theme-asset-linting-stylelint-eslint.md
+docs/roadmap/items/tier3-ceiling-unreachable-at-default-n.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
@@ -591,8 +630,10 @@ docs/roadmap/items/typo-detection-codespell.md
 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/unreadable-tap-cache-healthy-doctor-crashing-heal.md
 docs/roadmap/items/untrack-generated-build-noise.md
 docs/roadmap/items/unwatched-crons-hid-a-real-fuzz-crash.md
+docs/roadmap/items/unwritable-agent-dir-has-no-remedy.md
 docs/roadmap/items/update-advertises-a-flag-it-rejects.md
 docs/roadmap/items/update-diff-before-apply.md
 docs/roadmap/items/update-refreshed-rules-without-a-gate.md

boost_skill_cli-1.2.104/docs/roadmap/items/bm25-empty-tokenization-kills-catalog-fallback.md ADDED Viewed

@@ -0,0 +1,59 @@
+---
+id: bm25-empty-tokenization-kills-catalog-fallback
+board: code
+section: planned
+status: planned
+category: Quality · Retrieval eval
+complexity: L
+impact: High
+wow: 4
+note: rag.tokenize (rag.py:88-91) keeps only [a-z0-9] runs of length &gt;= 2, so "C++", "C#" a…
+order: 200
+owner:
+pr:
+title: A query made only of characters <code>tokenize</code> drops returns zero results, and the documented <code>catalog.search</code> fallback is unreachable — <code>boost search "C++"</code> finds nothing on a machine holding …
+---
+<b>Measured.</b> On the developer's own 440-tap install — with no BOOST_HOME override, where <code>dense.status()</code> reports <code>ready: False, reason: 'provider-changed'</code> so the machine is on the always-on BM25 path — <code>rag.retrieve("C++")</code> returns <b>0</b> hits while <code>rag.retrieve("cpp")</code> returns <b>60</b>, and <code>retrieve_any</code> reports <code>(0, 'BM25 full-content')</code> rather than <code>None</code>, so the <code>catalog.search</code> fallback that finds 45 C++ items can never run.
+<b>Reproduce it.</b>
+<code>cd &lt;repo&gt;</code><br>
+<code>export BOOST_HOME=$TMPDIR/eval-home BOOST_NO_AI=1</code><br>
+<code>./boost search "C++" --json      # []</code><br>
+<code>./boost search "C#" --json       # []</code><br>
+<code>./boost search "代码审查" --json   # []</code><br>
+<code>.venv/bin/python -c "</code><br>
+<code>from boost_cli.core import rag, catalog</code><br>
+<code>from boost_cli.commands import configuration as cfg</code><br>
+<code>es = catalog.all_entries()</code><br>
+<code>for q in ['C++','C#','代码审查']:</code><br>
+<code>    print(repr(q), 'tokenize=', rag.tokenize(q),</code><br>
+<code>          'retrieve_any=', (lambda r:(len(r[0]), r[1]))(rag.retrieve_any(q)),</code><br>
+<code>          'catalog.search=', len(catalog.search(q, es)),</code><br>
+<code>          [e['name'] for e,_ in catalog.search(q, es)[:3]])</code><br>
+<code>print('rag.search(C++) -&gt;', (lambda r: 'None' if r is None else (len(r[0]), r[1]))(rag.search('C++', limit=10, smart=False)))</code><br>
+…
+<b>What adversarial verification corrected.</b> This card's numbers are the re-measured ones, not the ones first reported.
+The DEFECT reproduces exactly; five of the six cited anchors are wrong, and the drift pattern says the finder read an older tree.
+- <code>rag.py:1288</code> (<code>elif bm25_hits is not None</code>) -&gt; actual <b>rag.py:1286</b> - <code>rag.py:1010-1012</code> (<code>if not terms: return []</code>) -&gt; actual <b>rag.py:1009-1011</b> (<code>terms = tokenize(query)</code> is 1009, <code>if not terms:</code> 1010, <code>return []</code> 1011) - <code>discovery.py:144</code> (<code>use_rag = rag.ensure()</code>) -&gt; actual <b>discovery.py:145</b> - <code>configuration.py:1266</code> (<code>rag.search(...)</code>) -&gt; actual <b>configuration.py:1321</b> (off by 55) - <code>configuration.py:1281</code> (<code>catalog.search(query)[:10]</code>) -&gt; actual <b>configuration.py:1336</b> (off by 55) - <code>not_carded_check</code>: "Read all 318 <code>^title:</code> lines from docs/roadmap/items/*.md" -&gt; actual <b>432</b> items, 432 title lines.
+CORRECT as stated: <code>rag.py:88-91</code> for <code>tokenize</code>; <code>discovery.py:164</code> for <code>scored = catalog.search(query)</code>; 45 / 27 / 17 catalog.search counts; 42 entries with literal "c++" in name or description; 93 corpus files containing 代码审查; the MCP return <code>("no skills match 'C++'", False)</code>; and the absence of any <code>BOOST_NO_RAG</code> / <code>--no-rag</code> escape hatch.
+The ~55-line configuration.py drift plus a title count off by 114 is not miscounting — the finder measured an older checkout.
+<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
+SCOPE OF MY REPRO. All corpus counts (45 / 27 / 17 / 42 / 93 / 10,152) are from the shared 20-tap eval corpus at $TMPDIR/eval-home and must be labelled as such in the card — the finding says "the same machine", which reads as a real install. The datum that generalises is the one I took from the real 440-tap install (0 for <code>C++</code>, 60 for <code>cpp</code>).
+SCOPE OF THE DEFECT — dense rescues it. <code>boost_cli/core/dense.py</code> contains no call to <code>tokenize</code> (it embeds the query string), so <code>retrieve_any</code> takes the <code>elif dense_hits:</code> branch and a machine with a *ready* dense store is NOT hit. The defect is confined to the always-on BM25-only path — every user without a built dense store, plus the MCP surface on such a machine. Note this kills the "invisible from a developer install" excuse the shipped <code>bm25-has-no-stemming</code> card leaned on: this repo's own machine is on that path right now because its dense store was built with <code>BAAI/bge-small-en-v1.5</code> and the configured provider is now <code>voyage</code>.
+BLAST RADIUS IS WIDER THAN THE THREE NAMED QUERIES. Any query where *every* token is under 2 alphanumerics or non-Latin wipes out: <code>C++</code>, <code>C#</code>, <code>F#</code>, <code>R</code>, <code>C</code>, <code>how to</code>, <code>a the of</code>, <code>代码审查</code>, <code>日本語</code>. A multi-word query with one ordinary Latin word still works (<code>c++ memory safety</code> -&gt; 60 hits, with <code>c++</code> silently erased — that erasure is sibling finding 6's angle).
+DO NOT WRITE "FALL BACK TO catalog.search" AS THE FIX. I measured the naive remedy and it is unsafe: <code>catalog.search('R')</code> returns <b>10,092 of 10,152</b> entries and <code>catalog.search('how to')</code> returns <b>6,229</b> — noise, not results.
+<b>Why it is worth doing.</b> A user or agent asking for the most common name of a mainstream language is told the catalogue holds nothing and is sent to <code>boost discover</code> to search all of GitHub for <code>cpp-expert</code>, <code>cpp-reviewer</code> and <code>cpp-coding-standards</code> that are already on their disk — the exact symptom the shipped card <code>bm25-has-no-stemming</code> was written to kill, arriving through a different door. It is worse on the MCP surface, where <code>boost_search</code> answers an agent "no skills match 'C++'" and the agent has no second query to try.
+<em>Found by an automated audit of retrieval/eval quality, the search &amp; browse surfaces, and first-run onboarding; every finding was then re-measured from scratch by an independent adversarial verifier whose instruction was to refute it. Verdict: <b>CORRECTED</b>. No fix is prescribed here — the measurement is the contribution.</em>

boost_skill_cli-1.2.104/docs/roadmap/items/corpus-refresh-updates-data-not-prose.md ADDED Viewed

@@ -0,0 +1,49 @@
+---
+id: corpus-refresh-updates-data-not-prose
+board: code
+section: planned
+status: planned
+category: Quality · Retrieval eval
+complexity: S
+impact: Low
+wow: 2
+note: .github/workflows/eval-corpus-refresh.yml regenerates taps.txt's data rows and baseli…
+order: 201
+owner:
+pr:
+title: The monthly corpus refresh rewrote the pins and the baseline but left every documented number stale — taps.txt now contradicts its own header, and nothing checks it
+---
+<b>Measured.</b> tests/eval/taps.txt contradicts itself inside one file: its header at line 25 states the corpus is "<b>10,152 entries</b>", while its own twenty data rows fifty lines below sum to 10,731 (<code>awk '!/^#/ &amp;&amp; NF {s+=$3} END {print s}'</code>), and an independent materialisation at exactly those pinned SHAs measures 10,731 entries across 20 taps with sickn33 at 61.8% - verified at HEAD 5ec7ed75.
+<b>Reproduce it.</b>
+<code>cd &lt;repo&gt;</code><br>
+<code>git show --stat cbc0a58b</code><br>
+<code>grep -n '10,152\|6,309\|62.1\|1,616\|0.852' tests/eval/taps.txt scripts/eval_corpus.py CLAUDE.md Makefile .github/workflows/eval-scale.yml tests/unit/test_eval_corpus.py</code><br>
+<code>sed -n '48,70p' tests/eval/taps.txt          # data rows: sickn33 ... 6634, ECC ... 1621</code><br>
+<code>awk '!/^#/ &amp;&amp; NF {s+=$3} END {print "pinned rows sum to", s}' tests/eval/taps.txt   # -&gt; 10731</code><br>
+<code>.venv/bin/python -c "import json;d=json.load(open('tests/eval/baseline.json'));print(json.dumps(d['sets']['golden.jsonl@a0617183f8c9']['engines']['BM25 full-content'],indent=1))"</code>
+<b>What adversarial verification corrected.</b> This card's numbers are the re-measured ones, not the ones first reported.
+Only one statement in the finding is false, and it is narrow:
+1. "the same stale figures propagate to ... the Makefile" is WRONG. The Makefile contains no "10,152" (<code>grep -c '10,152' Makefile</code> -&gt; 0) and Makefile:126 quotes a DIFFERENT, older stale set: "0.863 / 0.473 / 0.607 / 0.662", which matches neither the pre-refresh baseline (0.8516/0.4725/0.6048/0.6575) nor the post-refresh one (0.8407/0.4835/0.6065/0.6552). Makefile:126 is stale prose, but it went stale before this refresh, not because of it. (Makefile:132-133 is separately stale in the other direction: it says the corpus "tracks upstream HEAD rather than pinned commits", untrue since #410 pinned it.) The card must not claim the refresh caused the Makefile drift.
+2. Under-count of call sites. The finding lists six files; there are at least four more quoting "10,152", one of which is ACTIVE rather than merely left behind: - scripts/build_scale_corpus.py:189 emits the literal string "# 10,152 entries and a real install carries ~71,655..." into tests/eval/taps-scale.txt on regeneration, so a build step re-writes the stale number. - scripts/build_scale_corpus.py:6, tests/eval/taps-scale.txt:11, tests/unit/test_scale_corpus.py:5. - Also scripts/eval_corpus.py:10 ("affaan-m/ECC alone is 1,616"), which the finding's line list omits.
+3.
+<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
+SCOPE OF MY REPRO. I materialised the corpus at the shipped pins in my own disposable HOME (network reachable, 20 blobless sparse clones) and scored it with the exact <code>make eval</code> invocation, so the 10,731 / 61.8% / 76.9% / 0.841-0.484-0.607-0.655 figures are my own measurements, not the finder's. I did not touch the shared read-only eval-home except to read its caches; that corpus is still at the PRE-refresh pins (sickn33 @ d43065e) and totals 10,152 with sickn33 at 6,309 - which is what let me confirm both sides of the move rather than only the new one. My runs wrote nothing into the repo (<code>git status --short</code> shows only a peer session's four modified boost_cli/tests files, none under tests/eval/ or scripts/).
+CORRECTED, not REFUTED, and the correction is small: sizes, shares, line numbers, the baseline match, the monthly cron and "no test covers it" all reproduced exactly. Only the Makefile attribution is wrong, plus an under-count of sites. Do not let CORRECTED read as doubt about the defect.
+DO NOT list roadmap item bodies as stale. <code>eval-corpus-was-not-actually-pinned.md</code>, <code>eval-corpus-is-one-strangers-repo.md</code>, <code>eval-corpus-is-96x-smaller-than-a-real-install.md</code>, <code>BOOST-D12.md</code> and the CLI-audit cards all quote 10,152 / 6,309 / 0.852, but they are dated records of a measurement that was true when written. The live surfaces are the ones that must be fixed.
+NOT A DUPLICATE, but cross-link it.
+<b>Why it is worth doing.</b> taps.txt's header is the primary explanation of what the corpus is and why the floors sit where they do; it now states a size, a concentration and a four-metric score that its own data rows contradict, and CLAUDE.md repeats them as the project's ground truth. The next person reasoning about the corpus (or the next agent re-deriving the floors) reads numbers that are one refresh out of date, and the drift widens every month because the job that causes it is scheduled and nothing fails when the prose and the rows disagree.
+<em>Found by an automated audit of retrieval/eval quality, the search &amp; browse surfaces, and first-run onboarding; every finding was then re-measured from scratch by an independent adversarial verifier whose instruction was to refute it. Verdict: <b>CORRECTED</b>. No fix is prescribed here — the measurement is the contribution.</em>

boost_skill_cli-1.2.104/docs/roadmap/items/corrupt-config-reads-as-ready-to-set-up.md ADDED Viewed

@@ -0,0 +1,53 @@
+---
+id: corrupt-config-reads-as-ready-to-set-up
+board: code
+section: planned
+status: planned
+category: Onboarding · Bug
+complexity: M
+impact: Med
+wow: 3
+note: Doctor has no config-integrity check. When ~/.boost/config.json fails to parse, confi…
+order: 202
+owner:
+pr:
+title: With a corrupt config.json, doctor reports "no registries tapped" and verdicts "● ready to set up" exit 0 while search is dead; heal says "nothing to heal"
+---
+<b>Measured.</b> With a corrupt <code>~/.boost/config.json</code> on a machine holding 1 tap clone (<code>repos/verify-30-fix</code>) and its catalog cache (<code>cache/verify-30-fix.json</code>), <code>boost doctor --json</code> returns <code>{"issues": 0, "ok": true, "verdict": "ready to set up — tap a registry to make boost searchable"}</code> with exit 0 and no corruption entry anywhere in its <code>checks</code> array, on the same machine where <code>boost search brainstorm</code> exits 1 with "no taps configured — nothing to search" — because the only notice of the corruption is emitted by <code>config.load()</code> before <code>report.Report</code> exists and is routed to stderr (<code>config.py:205-210</code>), so it can never be counted, never reach <code>--json</code>, and never reach <code>boost doctor &gt; health.log</code>.
+<b>Reproduce it.</b>
+<code>cd &lt;repo&gt; || exit 1</code><br>
+<code>export HOME=$TMPDIR/audit-doctor-verify3; export BOOST_HOME=$HOME/.boost; mkdir -p "$HOME"</code><br>
+<code>python3 tests/make_fixture.py $TMPDIR/audit-doctor-fix3 &gt;/dev/null</code><br>
+<code>./boost tap $TMPDIR/audit-doctor-fix3 &gt;/dev/null 2&gt;&amp;1</code><br>
+<code>BOOST_ASSUME_YES=1 ./boost install brainstorming &gt;/dev/null 2&gt;&amp;1</code><br>
+<code>printf '{"taps": [' &gt; "$BOOST_HOME/config.json"</code><br>
+<code>ls -1 "$BOOST_HOME/repos" | wc -l          # 1 clone still on disk</code><br>
+<code>./boost doctor; echo "DOCTOR_EXIT=$?"      # "no registries tapped" ... "● ready to set up", 0</code><br>
+<code>./boost heal; echo "HEAL_EXIT=$?"          # "✓ nothing to heal", 0</code><br>
+<code>./boost search brainstorm; echo "SEARCH_EXIT=$?"   # "no taps configured", 1</code>
+<b>What adversarial verification corrected.</b> This card's numbers are the re-measured ones, not the ones first reported.
+The BEHAVIOUR is exactly as claimed. Every source citation in the finding is wrong.
+1. FILE PATH. The finding says "quality.py" with no directory and implies core. The file is <code>boost_cli/commands/quality.py</code>. There is no <code>boost_cli/core/quality.py</code> (<code>sed</code> on that path errors: No such file or directory).
+2. VERDICT BRANCH. Finding says <code>quality.py:744-750</code>. Actual: the block is lines <b>727-736</b>, with <code>if issues == 0 and not taps:</code> on line <b>728</b> and <code>rep.verdict(True, "ready to set up — tap a registry to make boost searchable")</code> on 729-730.
+3. ORPHANED-STORE-DIR CHECK. Finding says <code>quality.py:646-651</code>. Actual: <b>612-618</b> (<code>orphans = [c.name for c in sorted(root.iterdir()) ...]</code> at 613, <code>bad("orphans", ...)</code> at 617-618).
+4. These line numbers were never right. I checked HEAD, HEAD~1, HEAD~2, HEAD~3, HEAD~5 and HEAD~10 (verdict line 728/728/723/723/720/720; orphan line 617/617/614/614/611/611) and the three other copies in the tree (.claude/worktrees/bmad-autopilot: 631/537; build/lib: -/510; mutants/: the block is absent). Nothing anywhere has 744 or 646, so this is not stale line numbers from a recent move — it is a miscount.
+5. WORDING OF THE FINDING'S "printed above doctor's own heading".
+<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
+SCOPE OF MY REPRO — do not let a card overstate it: - I measured <b>1 clone + 1 catalog cache</b> on disk against "0 taps synced". The finding's "a user who has been using boost for months" is extrapolation, not measured. State the disparity as "N clones on disk vs 0 taps reported" and cite N=1 as what was actually verified. - I did NOT test <code>boost tap --defaults</code> (needs network). The claim that following doctor's advice re-taps defaults over the real list is unverified; what IS verified is that any tap write quarantines the old file to <code>config.json.corrupt</code> first, so the list is recoverable. That mitigation is why Med holds rather than High. - Fixture-tap repro only; no claim about a starter/default registry set.
+THREE ROADMAP PRECEDENTS — none is a duplicate, all must be cited by the author: - <code>docs/roadmap/items/audit-doctor-findings.md</code> (shipped, PR #656) fixed THIS EXACT CLASS — an "!" line that wears the issue glyph but is never counted, under a "● healthy" exit-0 verdict — but only for the crash-report notice. The config-corrupt warning is a second instance that fix did not reach, and is harder because it originates outside doctor's own code. - <code>docs/roadmap/items/audit-verify-drift-say-nothing-installed-exit-0-and-doctor-says-lo.md</code> (shipped, PR #674) is the lock-file sibling and ships the FIX PATTERN to copy: <code>lockfile.check()</code> returning ok/missing/corrupt instead of the empty skeleton <code>read()</code> collapses to, plus <code>store.has_content()</code> to tell a genuinely empty install from one whose record vanished.
+<b>Why it is worth doing.</b> This is the worst wording doctor can choose for the state: a user who has been using boost for months is told they are a new user who has not set anything up yet, with a zero exit code, and the repair command agrees there is nothing wrong. Following the printed advice (<code>boost tap --defaults</code>) re-taps the defaults over their real registry list — recoverable only because a <code>.corrupt</code> sidecar happens to be written, which neither doctor nor heal mentions. Doctor already knows how to compare on-disk state against a record (the orphaned-store-dir check); the same comparison against <code>repos/</code> would turn this into one accurate line.
+<em>Found by an automated audit of retrieval/eval quality, the search &amp; browse surfaces, and first-run onboarding; every finding was then re-measured from scratch by an independent adversarial verifier whose instruction was to refute it. Verdict: <b>CORRECTED</b>. No fix is prescribed here — the measurement is the contribution.</em>

boost_skill_cli-1.2.104/docs/roadmap/items/dense-kill-switch-has-no-reason-state.md ADDED Viewed

@@ -0,0 +1,57 @@
+---
+id: dense-kill-switch-has-no-reason-state
+board: code
+section: planned
+status: planned
+category: Quality · Retrieval eval
+complexity: M
+impact: Med
+wow: 3
+note: embed.enabled() short-circuits provider() to None (embed.py:134), so BOOST_NO_EMBED=1…
+order: 203
+owner:
+pr:
+title: BOOST_NO_EMBED has no state in the reason ladder: doctor calls a deliberate kill switch a degraded fault (exit 1) and hands advice that is a measured no-op in both branches
+---
+<b>Measured.</b> With <code>BOOST_NO_EMBED=1</code> and a 5-chunk voyage-4 store, <code>dense.fix_hint</code> tells the user "set the key it was built with: <code>export VOYAGE_API_KEY=...</code>"; exporting that key produces a byte-identical status (reason='no-key', degraded=True, ready=False) and the byte-identical hint — the kill switch is read in <code>provider()</code> before any key, so boost's own remedy is a measured no-op, on both <code>boost doctor</code> (exit 1) and <code>boost search</code>.
+<b>Reproduce it.</b>
+<code>cd &lt;repo&gt;</code><br>
+<code>export HOME=$TMPDIR/verify-dense-f3; export BOOST_HOME=$HOME/.boost; mkdir -p "$HOME"</code><br>
+<code>unset VOYAGE_API_KEY OPENAI_API_KEY BOOST_NO_EMBED</code><br>
+<code>python3 tests/make_fixture.py $TMPDIR/verify-dense-f3-fix &gt;/dev/null</code><br>
+<code>./boost tap $TMPDIR/verify-dense-f3-fix &gt;/dev/null</code><br>
+<code># ./boost is system python3 (no sqlite_vec) -&gt; reports no-backend. Use .venv below.</code><br>
+<code>build () {   # $1 provider  $2 model  $3 dim</code><br>
+<code>.venv/bin/python - "$1" "$2" "$3" &lt;&lt;'PY'</code><br>
+<code>import hashlib, sys; sys.path.insert(0, ".")</code><br>
+<code>from boost_cli.core import catalog, dense, embed</code><br>
+<code>P, M, DIM = sys.argv[1], sys.argv[2], int(sys.argv[3])</code><br>
+<code>def fake(texts, input_type=None, timeout=60):</code><br>
+<code>    out = []</code><br>
+<code>    for t in texts:</code><br>
+<code>        h = hashlib.sha256(t.encode()).digest()</code><br>
+…
+<b>What adversarial verification corrected.</b> This card's numbers are the re-measured ones, not the ones first reported.
+Every card-worthy measurement is exact. Only citation ranges drift:
+1. "eight lines away in the same module" (why_it_matters) is FALSE as written and is the one non-trivial correction. <code>embed.fallback_note()</code> is in boost_cli/core/embed.py:170-179; the inert <code>_FIX</code> table is in boost_cli/core/dense.py:520-534. Different files, ~340 lines and one module apart. Do not put "eight lines away" on the card — it misstates where the fix lives. 2. "dense.py:513-516 states the invariant" -&gt; the quoted sentence spans dense.py:512-514 (512 is "# Why dense retrieval isn't serving...", 513 is "# Each names the ONE next action..."). 3. "<code>_FIX</code> (dense.py:522-533)" -&gt; <code>_FIX</code> is dense.py:520-534; the entries span 521-533. The 8-key count is correct. 4. "tests/unit/test_dense_status.py:100-101" -&gt; the comment and the <code>assert st["degraded"] is False</code> are at 101-102 (line 100 is <code>assert st["model"] is None</code>). 5. "embed.py:134" -&gt; the guard <code>if not enabled():</code> is 133 and <code>return None</code> is 134. Accurate enough as cited.
+Confirmed exact: reason/degraded/built_provider in both branches; both hint strings verbatim; doctor rc=1; the fallback_note string; 8 <code>_FIX</code> keys; test_dense_status.py:264 and its lack of a store; 432 roadmap items; 0 BOOST_NO_EMBED hits in roadmap items; embed.py:32 kill-switch doc line.
+<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
+1. BLAST RADIUS IS TWO SURFACES, NOT ONE. The finding only measured <code>boost doctor</code>. I also measured <code>boost search</code> under the kill switch: it prints the same inert "set the key it was built with" line (both read the one <code>dense.fix_hint</code> table, by design — CLAUDE.md's "doctor and search cannot give contradictory advice" rule). The card should say both.
+2. AN EXISTING CARD PROPOSES A FIX THAT WOULD MAKE THIS WORSE. <code>docs/roadmap/items/audit-quickstart-findings.md</code> line 18 ("The <code>[rag]</code> install hint has three different wordings") proposes: "have <code>embed.fallback_note()</code> and both quickstart paths call <code>dense.fix_hint()</code>". Executed as written that deletes the only correct kill-switch sentence in the codebase (embed.py:178). This card's fix must go the other direction — add a <code>disabled</code> reason to the ladder in <code>status()</code> and give <code>_FIX</code> that key — or the two cards collide. This is not a duplicate (that card is about zsh-unsafe unquoted <code>pip install boost-skill-cli[rag]</code>, not the kill switch), but a card author must be told.
+3. THE ONLY ESCAPE IS DELETING THE VECTORS. I renamed the store away and <code>degraded</code> flipped to False (reason stays 'no-key' but <code>degraded = store_exists and reason is not None</code>). So the exit code is not literally unfixable — but the only remedy is discarding every vector the user paid to embed, and no hint mentions it. "red forever" in why_it_matters should be phrased as "red until you delete the store".
+4. PRECONDITION IS NARROW — do not overstate reach. You must have BUILT a dense store and THEN set the kill switch.
+<b>Why it is worth doing.</b> <code>BOOST_NO_EMBED</code> is documented as a hard kill switch (embed.py:32) and is what a user or a CI job sets to opt out deliberately — including anyone who hits the previous two findings and wants to stop paying for a broken embedder. Doing so turns <code>boost doctor</code> red forever, which breaks it as a CI gate, and the only remedies boost offers are provably inert: reinstalling an installed package, or exporting a key the kill switch never reads. The correct sentence already exists eight lines away in the same module.
+<em>Found by an automated audit of retrieval/eval quality, the search &amp; browse surfaces, and first-run onboarding; every finding was then re-measured from scratch by an independent adversarial verifier whose instruction was to refute it. Verdict: <b>CONFIRMED</b>. No fix is prescribed here — the measurement is the contribution.</em>

boost_skill_cli-1.2.104/docs/roadmap/items/dense-no-key-guard-is-unreachable.md ADDED Viewed

@@ -0,0 +1,59 @@
+---
+id: dense-no-key-guard-is-unreachable
+board: code
+section: planned
+status: planned
+category: Quality · Retrieval eval
+complexity: L
+impact: High
+wow: 4
+note: dense.status() checks prov is None before it looks at the store (dense.py:618-621), b…
+order: 204
+owner:
+pr:
+title: fix_hint's no-key guard has been unreachable since the day it was written; a missing API key now prescribes the full re-embed the guard exists to prevent
+---
+<b>Measured.</b> On a complete <code>[rag]</code> extra with a voyage-4-built vector store and no API key exported, <code>dense.status()</code> returns <code>reason='provider-changed'</code> (not <code>no-key</code>), so all three status-passing surfaces print <code>rebuild it: \</code>boost reindex --dense --force\`<code> and </code>boost doctor<code> exits 1 — measured verbatim, including doctor's "live key is local; searches are using BM25" line — while the guard written to prevent exactly that (</code>21f28223<code>, #444) fires only under </code>BOOST_NO_EMBED=1` or a partial install, both confirmed by direct probe.
+<b>Reproduce it.</b>
+<code>cd &lt;repo&gt;</code><br>
+<code>export HOME=$TMPDIR/verify-dense-f1; export BOOST_HOME=$HOME/.boost; mkdir -p "$HOME"</code><br>
+<code>unset VOYAGE_API_KEY OPENAI_API_KEY BOOST_NO_EMBED</code><br>
+<code>python3 tests/make_fixture.py $TMPDIR/verify-dense-f1-fix &gt;/dev/null</code><br>
+<code>./boost tap $TMPDIR/verify-dense-f1-fix &gt;/dev/null</code><br>
+<code># NOTE: ./boost execs system python3, which has no sqlite_vec, so it always says</code><br>
+<code># "no-backend". Every dense command below MUST run under .venv.</code><br>
+<code>.venv/bin/python - &lt;&lt;'PY'</code><br>
+<code>import hashlib, sys; sys.path.insert(0, ".")</code><br>
+<code>from boost_cli.core import catalog, dense, embed</code><br>
+<code>DIM = 1024</code><br>
+<code>def fake(texts, input_type=None, timeout=60):          # no network, no API spend</code><br>
+<code>    out = []</code><br>
+<code>    for t in texts:</code><br>
+<code>        h = hashlib.sha256(t.encode()).digest()</code><br>
+…
+<b>What adversarial verification corrected.</b> This card's numbers are the re-measured ones, not the ones first reported.
+The defect is real and reproduced verbatim, but five stated details are wrong:
+1. SOURCE ATTRIBUTION OF THE COST FIGURE. <code>why_it_matters</code> says "which CLAUDE.md prices at ~1.2 s per chunk on CPU". <code>grep -n 'per chunk\|1\.2 s' CLAUDE.md</code> returns nothing. The figure is real but lives in the roadmap: <code>docs/roadmap/items/keyless-semantic-search-for-everyone.md:298</code> ("4,431 s — 74 minutes, about 1.2 s per chunk") and <code>:308</code>, plus <code>the-shard-job-that-could-not-finish.md:17</code> and <code>keyless-dense-tier-local-static-embeddings.md:75</code>. Cite the roadmap, not CLAUDE.md.
+2. <code>quality.py:769</code> is wrong -&gt; the fix_hint call is <code>boost_cli/commands/quality.py:780</code> (<code>fix = dense.fix_hint(st["reason"], st)</code>). Line 769 sits inside the unrelated <code>search-quantization</code> warning.
+3. <code>pyproject.toml:55-57</code> is wrong -&gt; the three pins are at lines <b>56, 67 and 68</b> (<code>sqlite-vec&gt;=0.1.6</code>, <code>onnxruntime&gt;=1.17</code>, <code>tokenizers&gt;=0.15</code>), split by a 10-line comment justifying the fastembed rejection. They are in one extra, which is the load-bearing part, but the range is not 55-57.
+4. THE CAUSAL-ORDER COMMIT PAIR NAMES THE WRONG COMMIT FOR THE GUARD. <code>86163e03</code> (2026-07-31, #364) created <code>test_dense_fix_hint.py</code> <b>and the <code>_FIX</code> table</b>, but not the guard.
+<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
+PRECONDITION — state it on the card so nobody reads it as unconditional. The misroute needs (a) a store built with an API provider, (b) the complete <code>[rag]</code> extra so <code>provider()</code> falls through to <code>local</code>, and (c) the key absent from the *process* environment. #444's own commit message documents that shape as recurring in the wild: "the shell exports one; the spawned server does not inherit it."
+THE REAL MACHINE IS NOT CURRENTLY IN THE BUG STATE. <code>~/.boost/cache/rag_vectors.sqlite</code> reads provider="local", model="BAAI/bge-small-en-v1.5", dim=384 — so <code>provider()</code> matches <code>built_provider</code> and its reason is None. The 645,592-chunk / 1.20 GB / 440-tap figure is <b>cost-if-the-hint-is-followed</b>, not present harm. Do not let the card imply the machine is broken today. (The 750,416-chunk voyage-4 store in the #444 message and the test docstring is a past state of the same machine.)
+THE MISDIAGNOSIS WAS REFUTABLE FROM THE SAME FILE. The <code>_FIX</code> comment — "This reason means 'no key AND no local backend', which in practice is a partial install or BOOST_NO_EMBED" — was already in <code>dense.py</code> from 86163e03 (07-31) when #444 (08-03) added a guard whose docstring asserts the opposite: "an unfinished install with no store and a complete install whose key merely went missing both land here." Two claims about <code>no-key</code>, 30 lines apart, that contradict each other.
+<b>Why it is worth doing.</b> A user who opens a new shell without exporting their key is told by doctor, search and the MCP server to re-embed their whole store. On the real machine in this repo that is 645,592 chunks / 1.20 GB, which CLAUDE.md prices at ~1.2 s per chunk on CPU — hours of compute, or a real API bill — to fix a problem whose actual remedy is one <code>export</code>. The repo already decided this was unacceptable and wrote six tests plus a paragraph of docstring to prevent it; the guard has simply never been able to fire.
+<em>Found by an automated audit of retrieval/eval quality, the search &amp; browse surfaces, and first-run onboarding; every finding was then re-measured from scratch by an independent adversarial verifier whose instruction was to refute it. Verdict: <b>CORRECTED</b>. No fix is prescribed here — the measurement is the contribution.</em>

boost_skill_cli-1.2.104/docs/roadmap/items/dense-ready-but-embedder-cannot-run.md ADDED Viewed

@@ -0,0 +1,53 @@
+---
+id: dense-ready-but-embedder-cannot-run
+board: code
+section: planned
+status: planned
+category: Quality · Retrieval eval
+complexity: M
+impact: Med
+wow: 3
+note: localembed.available() (localembed.py:85) tests whether onnxruntime and tokenizers *i…
+order: 205
+owner:
+pr:
+title: status() has no state for "ready but the embedder does not work": doctor green-ticks a tier that never ran, the search hint is suppressed, and every search re-pays the failed model fetch
+---
+<b>Measured.</b> In a store built as provider=local/BAAI/bge-small-en-v1.5/384-d with the weights absent, <code>dense.ready()</code> returns True and <code>status()</code> returns reason=None, degraded=False, while <code>dense.retrieve()</code> returns None on every query — so <code>boost search</code> prints "1 match · ranked by full-content BM25" with no hint (guard: <code>if st.get("ready"): return</code>, discovery.py:339) and <code>boost doctor</code> prints "✓ semantic search active — local BAAI/bge-small-en-v1.5 (384-d), 5 chunks across 1 tap" and exits 0 (guard: <code>if st["ready"]:</code>, quality.py:759); each such search makes exactly one un-cached 133,093,490-byte model fetch (counted in-process: 1 urlopen, 3.72 s, versus a 0.12 s BOOST_NO_EMBED baseline, of which only 0.06 s is the onnxruntime/tokenizers import).
+<b>Reproduce it.</b>
+<code>cd &lt;repo&gt;</code><br>
+<code>export HOME=$TMPDIR/verify-dense-f2; export BOOST_HOME=$HOME/.boost; mkdir -p "$HOME"</code><br>
+<code>unset VOYAGE_API_KEY OPENAI_API_KEY BOOST_NO_EMBED</code><br>
+<code>python3 tests/make_fixture.py $TMPDIR/verify-dense-f2-fix &gt;/dev/null</code><br>
+<code>./boost tap $TMPDIR/verify-dense-f2-fix &gt;/dev/null</code><br>
+<code># ./boost is system python3 (no sqlite_vec) -&gt; reports no-backend. Use .venv below.</code><br>
+<code># PRECONDITION: huggingface.co must be unreachable (blocked here by the proxy).</code><br>
+<code>.venv/bin/python - &lt;&lt;'PY'</code><br>
+<code>import hashlib, sys; sys.path.insert(0, ".")</code><br>
+<code>from boost_cli.core import catalog, dense, embed</code><br>
+<code>DIM = 384</code><br>
+<code>def fake(texts, input_type=None, timeout=60):</code><br>
+<code>    out = []</code><br>
+<code>    for t in texts:</code><br>
+<code>        h = hashlib.sha256(t.encode()).digest()</code><br>
+…
+<b>What adversarial verification corrected.</b> This card's numbers are the re-measured ones, not the ones first reported.
+1. "retries BOTH entries of FILES ... up to 1,200 s" is WRONG. <code>ensure_model</code> (localembed.py:141-150) does <code>if not _fetch(...): return None</code> on the FIRST failure, and <code>FILES</code> orders <code>onnx/model.onnx</code> before <code>tokenizer.json</code>, so tokenizer.json is never attempted on a failing network. Measured: exactly 1 <code>nethttp.urlopen</code> call per process, counted inside a real <code>boost search</code>. Correct statement: ONE fetch per search process, socket timeout 600 s. Do not write "up to 1,200 s"; also do not write "up to 600 s" as a wall-clock ceiling — <code>timeout=600</code> is a per-socket-operation timeout, so a slow-drip server is not bounded by it.
+2. Line numbers are off. <code>_hint_semantic_search</code>'s guard is discovery.py:339-340 (<code>if st.get("ready"): return</code>), not 341-343. <code>_report_search_engine</code>'s ready branch is quality.py:759, not 751-755. <code>_load</code> spans localembed.py:153-176 with the <code>ensure_model()</code> call at :164, not 152-166. (localembed.py:85 <code>available()</code> and :124 <code>timeout=600</code> are correct, as are the 133,093,490 B and tokenizer.json byte counts.)
+3. The BOOST_NO_EMBED=1 baseline is wrong: measured 0.12/0.12/0.12/0.13/0.14 s, not 1.11/0.80/1.50 s. Delta is 3.5-4.1 s.
+<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
+SCOPE OF MY REPRO — read before writing a card. (a) The failing precondition here is a proxy that truncates the huggingface.co stream, not one that blocks it; the pin in <code>FILES</code> is correct (HF's content-length matches 133,093,490 exactly), so this is not a wrong-hash finding and <code>_verified</code>'s length check is doing its job. (b) All timings are from this sandbox on a 5-entry fixture tap under a disposable HOME; only the structural facts (one fetch per process, no negative cache, both guards keyed on <code>ready</code>, no model probe on either surface) are environment-independent. (c) I could not test the positive case — with the model present dense works and none of this fires — so the finding is strictly about the store-present/model-absent state.
+PRIOR DISCLOSURE (the finder declared it, and I confirmed it): docs/roadmap/items/keyless-semantic-search-for-everyone.md, status <code>shipped</code>, body: "retrieval returned zero hits until the model was present — dense.status() reported ready the whole time, because the store genuinely was ready." That card frames it as a limit of what a shard can carry and commits to no work. Nothing in any item body claims doctor's green tick, the search hint's blindness, exit code 0, or the per-search retry cost; grepped all item bodies for localembed / ensure_model / bge-small / weights / "negative cache" / "model fetch" / "133 MB" and read the two candidate cards in full (the other being prerequisites-and-semantic-search-setup, the shipped hint whose blind spot this is).
+<b>Why it is worth doing.</b> This is the exact silent-BM25 failure <code>prerequisites-and-semantic-search-setup</code> shipped a hint to close, and the hint is blind to it: the user is told dense is active by doctor, told nothing by search, and pays several seconds per query for a download that can never succeed. A user who runs <code>boost reindex --dense</code> on a laptop with the model cached and then searches from a locked-down network or CI runner gets a slower search than if they had never enabled dense at all, with every surface reporting health.
+<em>Found by an automated audit of retrieval/eval quality, the search &amp; browse surfaces, and first-run onboarding; every finding was then re-measured from scratch by an independent adversarial verifier whose instruction was to refute it. Verdict: <b>CORRECTED</b>. No fix is prescribed here — the measurement is the contribution.</em>

boost-skill-cli 1.2.102__tar.gz → 1.2.104__tar.gz

boost-skill-cli 1.2.102tar.gz → 1.2.104tar.gz