boost-skill-cli 1.2.62__tar.gz → 1.2.64__tar.gz

{boost_skill_cli-1.2.62 → boost_skill_cli-1.2.64}/.gitignore

@@ -281,3 +281,10 @@ node_modules/
 # config). Written into the repo root by the language-server tooling, not by
 # boost, and specific to one developer's machine.
 .serena/
+
+# A SQLite artifact from a tool that passed ":memory:" as a path rather than as
+# the in-memory sentinel. Junk either way, and on Windows it is worse than junk:
+# a colon cannot appear in a filename there, so committing it makes `git
+# checkout` fail with exit 128 and every Windows CI job dies before it runs a
+# single test.
+:memory:*

{boost_skill_cli-1.2.62/boost_skill_cli.egg-info → boost_skill_cli-1.2.64}/PKG-INFO

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

{boost_skill_cli-1.2.62 → boost_skill_cli-1.2.64}/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.62'
-__version_tuple__ = version_tuple = (1, 2, 62)
+__version__ = version = '1.2.64'
+__version_tuple__ = version_tuple = (1, 2, 64)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.62 → boost_skill_cli-1.2.64}/boost_cli/core/dense.py

@@ -15,6 +15,7 @@ are the expensive step, so an unchanged tap is never re-embedded.
 from __future__ import annotations
 
 import base64
+import hashlib
 import json
 import sqlite3
 from pathlib import Path
@@ -84,6 +85,27 @@ def _connect() -> sqlite3.Connection | None:
 # and returns the same 60 rows, so the extra candidates are pure overhead.
 RESCORE_POOL = 2048
 
+#: How many result entries may share one byte-identical embedding.
+#:
+#: Registries paste boilerplate. On a real 657,587-chunk store the largest
+#: cluster of byte-identical vectors is **1,464 copies spanning 1,464 distinct
+#: skills across 2 taps** — one Composio/Rube tool-calling paragraph, vendored
+#: into every skill in two registries. Identical vectors score an identical
+#: distance, so `retrieve`'s tie-break (the displayed name) decided the page:
+#: a query landing near that paragraph returned the alphabetically-first 60 of
+#: the 1,464, measured **60 of 60 slots**, and every one of them matched on
+#: text its skill did not write.
+#:
+#: `rag.dedupe_by_content` cannot reach this. It keys on the *entry* body
+#: digest, and these are 1,464 genuinely different entries — correctly kept
+#: apart. The repetition is one chunk *inside* each of them, which is a
+#: different axis and the one `near-duplicate-items-eat-the-result-slots`
+#: leaves open.
+#:
+#: Not 1, because two skills can legitimately share a paragraph that really is
+#: the best answer; a handful shows that without letting it own the page.
+MAX_PER_VECTOR = 3
+
 
 def _quantizable(dim: int) -> bool:
     """Whether ``dim`` can be binary-quantized at all.
@@ -1101,8 +1123,11 @@ def quantize() -> dict | None:
 
 
 def _knn(con: sqlite3.Connection, qblob: bytes,
-         pool: int) -> list[tuple[int, float]]:
-    """``(chunk_id, cosine_distance)`` for the ``pool`` nearest chunks.
+         pool: int) -> list[tuple[int, float, bytes]]:
+    """``(chunk_id, cosine_distance, vector_key)`` for the nearest chunks.
+
+    ``vector_key`` identifies the *embedding*, not the row: byte-identical
+    vectors share one key, which is what :data:`MAX_PER_VECTOR` caps on.
 
     Two-stage on a quantized store, one stage on a legacy one, and the answer
     is the same either way — which is the whole point. `vec0` has no ANN index,
@@ -1132,14 +1157,43 @@ def _knn(con: sqlite3.Connection, qblob: bytes,
         # Exact cosine over the candidates only. `vec_raw` is an ordinary
         # rowid-keyed table precisely so this `IN` is an index lookup; the same
         # clause against a vec0 table plans as a full scan (see _ensure_schema).
-        return con.execute(
-            "SELECT id, vec_distance_cosine(embedding, ?) AS d FROM vec_raw "  # noqa: S608  interpolates only `?` placeholders
-            "WHERE id IN (%s) ORDER BY d LIMIT ?"
-            % ",".join("?" * len(cand)), (qblob, *cand, pool)).fetchall()
-    return con.execute(
+        #
+        # The embedding comes back too, and it is not waste: hashing it is what
+        # lets `retrieve` tell "60 entries that each matched something" from
+        # "60 copies of one paragraph". The bytes were already read to compute
+        # the distance, so the only new cost is one sha256 per candidate.
+        # No LIMIT, and that is the point: sqlite computes a distance for all
+        # `cand` rows either way — a LIMIT only truncates what it hands back.
+        # Truncating here is what let one cluster own the pool. The largest on
+        # a real store is 1,464 copies of one pasted paragraph, so a 480-row
+        # cut was 480 copies of it and the page had nothing else to rank.
+        rows = con.execute(
+            "SELECT id, vec_distance_cosine(embedding, ?) AS d, embedding "  # noqa: S608  interpolates only `?` placeholders
+            "FROM vec_raw WHERE id IN (%s) ORDER BY d"
+            % ",".join("?" * len(cand)), (qblob, *cand)).fetchall()
+        # Thin to `pool` while letting no single embedding take more than
+        # MAX_PER_VECTOR of it. Rows arrive sorted, so the copies that survive
+        # are the nearest ones and the slots freed go to the next *distinct*
+        # vector rather than to the next copy of this one.
+        out: list[tuple[int, float, bytes]] = []
+        per: dict[bytes, int] = {}
+        for rid, dist, blob in rows:
+            if len(out) >= pool:
+                break
+            vkey = hashlib.sha256(blob).digest()[:16]
+            if per.get(vkey, 0) >= MAX_PER_VECTOR:
+                continue
+            per[vkey] = per.get(vkey, 0) + 1
+            out.append((rid, dist, vkey))
+        return out
+    # Legacy float32 layout: one row per chunk with no separate blob table, so
+    # there is nothing cheap to hash. Each row becomes its own group, which
+    # makes the cap a no-op — correct rather than clever, because this path
+    # exists for widths `bit[N]` cannot take and no real store is on it.
+    return [(rid, dist, b"%d" % rid) for rid, dist in con.execute(
         "SELECT rowid, distance FROM vec_chunks "
         "WHERE embedding MATCH ? ORDER BY distance LIMIT ?",
-        (qblob, pool)).fetchall()
+        (qblob, pool)).fetchall()]
 
 
 def retrieve(query: str, k: int = 60, kind: str | None = None,
@@ -1169,14 +1223,18 @@ def retrieve(query: str, k: int = 60, kind: str | None = None,
             return []
         by_id = {r[0]: (r[1], r[2], r[3], r[4]) for r in con.execute(
             "SELECT id, tap, path, kind, snip FROM chunks WHERE id IN (%s)"  # noqa: S608  interpolates only `?` placeholders; ids are bound params
-            % ",".join("?" * len(knn)), [rid for rid, _d in knn])}
+            % ",".join("?" * len(knn)), [rid for rid, _d, _v in knn])}
     finally:
         con.close()
 
     entries = catalog.all_entries() if entries is None else entries
     live = {entry_key(e): e for e in entries}
     best: dict[tuple[str, str], tuple[float, str]] = {}
-    for rid, dist in knn:
+    # Which embedding won each entry its score. An entry that also matched on
+    # a chunk of its own keeps *that* pairing, because `best` only records the
+    # winner — so capping below never costs an entry a hit it earned itself.
+    won_by: dict[tuple[str, str], bytes] = {}
+    for rid, dist, vkey in knn:
         meta = by_id.get(rid)
         if meta is None:
             continue
@@ -1190,11 +1248,26 @@ def retrieve(query: str, k: int = 60, kind: str | None = None,
         prev = best.get(key)
         if prev is None or score > prev[0]:
             best[key] = (score, snip)
+            won_by[key] = vkey
     # Tie-break on the displayed name (see rag.retrieve for why).
     ranked = sorted(best.items(),
                     key=lambda kv: (-kv[1][0], live[kv[0]]["name"], kv[0]))
-    hits: list[Hit] = [
-        {"entry": live[key], "score": score,
-         "snippet": snip}  # type: ignore[typeddict-item]
-        for key, (score, snip) in ranked[:k]]
+    hits: list[Hit] = []
+    seen_vec: dict[bytes, int] = {}
+    for key, (score, snip) in ranked:
+        if len(hits) >= k:
+            break
+        # The cap, and the reason the sort above is not enough on its own:
+        # byte-identical vectors produce a byte-identical distance, so every
+        # entry sharing one arrives with the *same* score and the tie-break
+        # decides the page alphabetically. Measured on a real store, one
+        # 1,464-copy cluster took 60 of 60 slots that way. Skipping past the
+        # cap rather than truncating keeps the page full: the freed slots go
+        # to the next entries that matched on something else.
+        vkey = won_by[key]
+        if seen_vec.get(vkey, 0) >= MAX_PER_VECTOR:
+            continue
+        seen_vec[vkey] = seen_vec.get(vkey, 0) + 1
+        hits.append({"entry": live[key], "score": score,
+                     "snippet": snip})  # type: ignore[typeddict-item]
     return hits

{boost_skill_cli-1.2.62 → boost_skill_cli-1.2.64/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.2.62 → boost_skill_cli-1.2.64}/boost_skill_cli.egg-info/SOURCES.txt

@@ -257,6 +257,7 @@ 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/dense-store-holds-every-vector-once-per-copy.md
 docs/roadmap/items/dependabot-missing-pip-ecosystem.md
 docs/roadmap/items/dependabot-regeneration-drops-platform-pins.md
 docs/roadmap/items/dependabot-root-pip-entry-duplicates-requirements.md
@@ -591,6 +592,7 @@ tests/eval/recommend.jsonl
 tests/eval/taps-scale.txt
 tests/eval/taps.txt
 tests/eval/tool_calls.jsonl
+tests/eval/fixtures/claude_init_event.jsonl
 tests/functional/test_bmad_all_hosts.py
 tests/functional/test_capabilities_policy.py
 tests/functional/test_cli_adapt.py
@@ -688,6 +690,7 @@ tests/unit/test_crash_redaction.py
 tests/unit/test_dedup_trust.py
 tests/unit/test_demo_index.py
 tests/unit/test_dense.py
+tests/unit/test_dense_boilerplate_cluster.py
 tests/unit/test_dense_embed_dedupe.py
 tests/unit/test_dense_entry_reuse.py
 tests/unit/test_dense_fallback.py
@@ -717,6 +720,7 @@ tests/unit/test_eval_grading.py
 tests/unit/test_eval_metrics.py
 tests/unit/test_eval_stats_summary.py
 tests/unit/test_eval_tools.py
+tests/unit/test_eval_tools_probe.py
 tests/unit/test_failure_alerting_covers_unattended.py
 tests/unit/test_faithfulness.py
 tests/unit/test_frontmatter.py

boost_skill_cli-1.2.64/docs/roadmap/items/dense-store-holds-every-vector-once-per-copy.md

@@ -0,0 +1,79 @@
+---
+id: dense-store-holds-every-vector-once-per-copy
+board: code
+section: internals
+status: planned
+category: Search · Storage
+complexity: L
+impact: Med
+wow: 3
+note: 39.7% of vector rows are byte-identical repeats; 1.43x whole-store, no re-embedding
+order: 128
+owner:
+pr:
+title: The dense store keeps one vector per <em>copy</em>, not one per distinct text
+---
+<code>_embed_and_store</code> already buys each distinct text <b>once</b> &mdash; <code>seen</code>
+de-duplicates before the provider call, which is why <code>build</code>'s progress total counts
+distinct texts rather than rows. The <em>storage</em> never got the same treatment: every chunk row
+still gets its own <code>vec_raw</code> blob and its own <code>vec_chunks_bin</code> row, so a text
+vendored into 1,464 skills is stored 1,464 times.
+
+<b>Measured on a real store</b> (657,587 chunks, 384-d <code>BAAI/bge-small-en-v1.5</code>):
+657,587 vector rows collapse to <b>396,638 distinct</b> &mdash; 39.7% repeats, <b>1.658&times;</b>.
+The earlier 750,416-chunk / 1024-d Voyage store measured 42.9%, so the ratio is a property of the
+corpus rather than of one embedder.
+
+<b>State the payoff in the right scope.</b> The <code>#544</code> note said &ldquo;~1.75&times;&rdquo;
+without saying of what, and that reads as a whole-store number. It is not. From <code>dbstat</code>
+on the live file: <code>vec_raw</code> 1,287.6&nbsp;MB and <code>vec_chunks_bin</code> 45.1&nbsp;MB
+of a 1,634&nbsp;MB total, so vectors are <b>81.6%</b> of the file. Deduplicating them saves
+<b>529&nbsp;MB</b>; add back a <code>vid</code> column, a hash index and a <code>chunks(vid)</code>
+index and the honest figure is <b>1,634 &rarr; ~1,140&nbsp;MB, 1.43&times; whole-store</b>. On a
+1024-d store, where vectors are ~90% of the file, it lands nearer 1.6&times;.
+
+<b>The key must be the embedding blob, not the text &mdash; and this is the constraint that decides
+the design.</b> <code>export_shard</code> emits <code>name/tap/path/kind/cix/snip/digest/embedding</code>
+and <code>snip</code> is <code>text[:200]</code>: <b>the full chunk text is not in the store and not
+in the shard</b>, so <code>import_shard</code> has nothing to hash. A <code>text_hash</code> column
+is unpopulatable on the import path. <code>sha256(embedding)</code> is equivalent by construction
+&mdash; identical texts are embedded once and serialize to identical bytes &mdash; and it works for
+imports and for the migration.
+
+<b>No join table.</b> <code>#544</code> proposed a chunk&rarr;tap join table; <code>chunks</code>
+already <em>is</em> that table and already carries <code>tap</code>. The change is one
+<code>vid</code> column on <code>chunks</code>, a <code>vectors</code> relation, and
+<code>vec_chunks_bin</code> keyed by <code>vid</code>.
+
+<b>Three things break, and one of them is an ordering.</b> <code>_delete_matching</code> drops
+vectors <em>then</em> rows; refcounted GC must run <em>after</em> the row delete or it counts
+references about to vanish. <code>_store_vector</code>'s orphan guard stops being sufficient, because
+under dedup a <code>_COMMIT_EVERY</code> interrupt makes orphans structural rather than exceptional.
+And <code>export_shard</code>'s <code>v.id = c.id</code> join becomes <code>v.vid = c.vid</code>
+&mdash; the same shape whose breakage the docstring already records as having killed two scheduled
+<code>shards</code> runs.
+
+<b>In place, not an <code>INDEX_VERSION</code> bump.</b> Every input is already on disk, so the
+migration re-encodes rather than re-embeds &mdash; the posture <code>quantize()</code> established,
+and roughly its cost (~1360&nbsp;s, ~2&times; peak while both copies coexist), except that this one
+ends <em>smaller</em>. <code>dense.py</code> promises in writing that v3's re-embed is
+&ldquo;the last one this mechanism needs&rdquo;; a v4 wipe would charge every user a full re-embed
+to reclaim disk, which is the wrong trade even where the embedder is free.
+
+<b>The quality half is already fixed, and this card is not blocked on it.</b>
+<code>MAX_PER_VECTOR</code> thins the candidate pool and caps the page, which is what stopped one
+1,464-copy cluster taking 60 of 60 result slots. Dedup would make the pool distinct
+<em>structurally</em> rather than by thinning, and would let <code>_knn</code> stop hashing 2,048
+blobs per query &mdash; a simplification, not a rescue.
+
+<b>The free bonus nobody has claimed:</b> <code>seen</code> in <code>_embed_and_store</code> is a
+local rebuilt per call, so reuse is <em>per build</em>. A persisted blob-keyed table makes it
+cross-build and cross-tap: a newly tapped mirror registry would cost zero embeddings.
+
+<b>Biggest risk, named:</b> a third schema state. The store already branches float32 vs quantized
+through every vector-touching function; &ldquo;deduplicated or not&rdquo; makes four combinations,
+each needing mutant-killing tests. And the one invariant that catches silent corruption &mdash;
+<code>test_dense_entry_reuse.py</code>'s two-way <code>chunks.id</code> &harr; <code>vec_raw.id</code>
+bijection &mdash; must be <b>rewritten</b> rather than extended, because dedup breaks one direction
+by design. Its replacement: every <code>chunks.vid</code> resolves, and every <code>vectors</code>
+row has at least one referent.

{boost_skill_cli-1.2.62 → boost_skill_cli-1.2.64}/docs/roadmap/items/tool-call-eval-tier.md

@@ -7,7 +7,7 @@ category: Quality · Eval
 complexity: L
 impact: High
 wow: 4
-note: Claude Code arm shipped in #616; the second host arm is unwritten and the card stays open for it
+note: the Claude Code probe was broken and its finding was an artifact; fixed, second host still unwritten
 owner:
 order: 96
 title: a Tier 3 eval for tool-call behaviour, floored in <b>both</b> directions
@@ -61,22 +61,44 @@ N runs per prompt with an interval rather than a single pass/fail, the way
 <code>golden-set-statistical-power</code> established for retrieval — a one-shot replay cannot tell
 a wording regression from a sampling wobble.
 
-<b>Where this stands (2026-08-30).</b> The Claude Code arm shipped in #616:
+<b>Where this stands (2026-08-31), and a correction.</b> The Claude Code arm shipped in #616:
 <code>scripts/eval_tools.py</code>, a 16-prompt set halved into should-call and should-NOT-call,
-Wilson intervals over N runs, and a verdict that floors call rate <em>and</em> ceilings false
-calls. Its first real run measured <b>3/3 false calls</b> &mdash; boost's tools fired on "What is
-the difference between a Python list and a tuple?", which the shipped skip list excuses by name.
-Call rate alone would have scored that a perfect 1.00, which is the whole argument for flooring
-both directions, now with a number behind it.
+Wilson intervals over N runs, and a verdict that floors call rate <em>and</em> ceilings false calls.
 
-<b>The card stays open because "per host, never averaged" is the binding requirement and only one
-host has been driven.</b> Gemini CLI is not installed on the machine this was built on, and its
-successor Antigravity CLI (<code>agy</code>, which boost already supports as its fifth agent
-target and which has boost registered) cannot be driven from a sandbox: it starts a local
-language server and dies on <code>listen tcp 127.0.0.1:0: bind: operation not permitted</code>.
-Shipping an arm for a host nobody drove would put a number next to a measurement that never
-happened &mdash; the exact unfalsifiable claim this tier exists to retire. The <code>owner</code>
-is cleared rather than left on a merged branch, so the second arm is claimable.
+<b>Its probe was broken, and the finding this card recorded was an artifact of it.</b> An earlier
+revision of this card reported &ldquo;3/3 false calls &mdash; boost's tools fired on <em>What is the
+difference between a Python list and a tuple?</em>&rdquo;. They did not fire. <code>called_boost()</code>
+substring-scanned the raw event stream, and <code>claude -p --output-format stream-json --verbose</code>
+opens with a <code>system</code>/<code>init</code> event enumerating <em>every tool available to the
+session</em> &mdash; which on any machine where boost is registered contains
+<code>mcp__boost__boost_search</code> and the other three CONSULT names. So the check returned
+<code>true</code> on every run, including runs with no tool call at all. Measured directly:
+<code>Say OK and nothing else.</code> produced zero <code>tool_use</code> blocks and scored as a
+boost consult.
+
+Two consequences shipped with it. <code>make eval-tools</code> could never pass &mdash; eight
+no-call rows &times; three runs is 24 forced trues, so the false-call rate's lower bound sat at
+1.00 against a 0.20 ceiling, red on every machine forever. And the tier built to retire
+unfalsifiable claims had produced one. <b>The lesson is the tier's own:</b> the existing tests
+passed because they fed hand-written one-line fragments with no <code>init</code> event &mdash; a
+fixture the author invented could not catch the author's wrong model of the input. The probe now
+parses the NDJSON and counts only <code>tool_use</code> blocks inside <code>assistant</code>
+events, and the regression test drives a <b>captured real stream</b>.
+
+<b>The second host arm is still unwritten, and should stay that way until the fixed probe is
+re-run.</b> Building arm two on a probe that cannot tell an offer from a call would produce two
+hosts scoring an identical, meaningless 1.00. When it is built, the candidate is <b>Gemini CLI
+proper</b>, not Antigravity CLI: the delivery claim below is about Gemini's Node bundle, and
+<code>agy</code> is a third mode again &mdash; it receives boost's <code>instructions</code> and
+writes them to <code>~/.gemini/antigravity-cli/mcp/boost/instructions.md</code>, pointing the agent
+at the file rather than inlining it. Substituting it would measure a different mechanism than the
+one this card argues about.
+
+<b>Cost, now measured.</b> Two trivial runs on a real host reported <code>$0.657</code> and
+<code>$0.682</code> of <code>total_cost_usd</code>, so 16 prompts &times; 3 runs is roughly
+<b>$30&ndash;50 per host per invocation</b> on a machine with a crowded tool surface.
+<code>--strict-mcp-config</code> with a boost-only config cuts that sharply and controls the
+surface confound in the same move.
 
 <b>What it unlocks.</b> The first honest answer to "did that description edit help", a baseline the
 next surface change can regress against, and a way to retire claims that survive only because

{boost_skill_cli-1.2.62 → boost_skill_cli-1.2.64}/docs/roadmap.html

@@ -133,7 +133,7 @@
       <div class="stat"><b>20</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>7</b><span>Planned</span></div>
-      <div class="stat"><b>290</b><span>Loop finds</span></div>
+      <div class="stat"><b>291</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -865,22 +865,44 @@ N runs per prompt with an interval rather than a single pass/fail, the way
 <code>golden-set-statistical-power</code> established for retrieval — a one-shot replay cannot tell
 a wording regression from a sampling wobble.
 
-<b>Where this stands (2026-08-30).</b> The Claude Code arm shipped in #616:
+<b>Where this stands (2026-08-31), and a correction.</b> The Claude Code arm shipped in #616:
 <code>scripts/eval_tools.py</code>, a 16-prompt set halved into should-call and should-NOT-call,
-Wilson intervals over N runs, and a verdict that floors call rate <em>and</em> ceilings false
-calls. Its first real run measured <b>3/3 false calls</b> &mdash; boost's tools fired on "What is
-the difference between a Python list and a tuple?", which the shipped skip list excuses by name.
-Call rate alone would have scored that a perfect 1.00, which is the whole argument for flooring
-both directions, now with a number behind it.
-
-<b>The card stays open because "per host, never averaged" is the binding requirement and only one
-host has been driven.</b> Gemini CLI is not installed on the machine this was built on, and its
-successor Antigravity CLI (<code>agy</code>, which boost already supports as its fifth agent
-target and which has boost registered) cannot be driven from a sandbox: it starts a local
-language server and dies on <code>listen tcp 127.0.0.1:0: bind: operation not permitted</code>.
-Shipping an arm for a host nobody drove would put a number next to a measurement that never
-happened &mdash; the exact unfalsifiable claim this tier exists to retire. The <code>owner</code>
-is cleared rather than left on a merged branch, so the second arm is claimable.
+Wilson intervals over N runs, and a verdict that floors call rate <em>and</em> ceilings false calls.
+
+<b>Its probe was broken, and the finding this card recorded was an artifact of it.</b> An earlier
+revision of this card reported &ldquo;3/3 false calls &mdash; boost's tools fired on <em>What is the
+difference between a Python list and a tuple?</em>&rdquo;. They did not fire. <code>called_boost()</code>
+substring-scanned the raw event stream, and <code>claude -p --output-format stream-json --verbose</code>
+opens with a <code>system</code>/<code>init</code> event enumerating <em>every tool available to the
+session</em> &mdash; which on any machine where boost is registered contains
+<code>mcp__boost__boost_search</code> and the other three CONSULT names. So the check returned
+<code>true</code> on every run, including runs with no tool call at all. Measured directly:
+<code>Say OK and nothing else.</code> produced zero <code>tool_use</code> blocks and scored as a
+boost consult.
+
+Two consequences shipped with it. <code>make eval-tools</code> could never pass &mdash; eight
+no-call rows &times; three runs is 24 forced trues, so the false-call rate's lower bound sat at
+1.00 against a 0.20 ceiling, red on every machine forever. And the tier built to retire
+unfalsifiable claims had produced one. <b>The lesson is the tier's own:</b> the existing tests
+passed because they fed hand-written one-line fragments with no <code>init</code> event &mdash; a
+fixture the author invented could not catch the author's wrong model of the input. The probe now
+parses the NDJSON and counts only <code>tool_use</code> blocks inside <code>assistant</code>
+events, and the regression test drives a <b>captured real stream</b>.
+
+<b>The second host arm is still unwritten, and should stay that way until the fixed probe is
+re-run.</b> Building arm two on a probe that cannot tell an offer from a call would produce two
+hosts scoring an identical, meaningless 1.00. When it is built, the candidate is <b>Gemini CLI
+proper</b>, not Antigravity CLI: the delivery claim below is about Gemini's Node bundle, and
+<code>agy</code> is a third mode again &mdash; it receives boost's <code>instructions</code> and
+writes them to <code>~/.gemini/antigravity-cli/mcp/boost/instructions.md</code>, pointing the agent
+at the file rather than inlining it. Substituting it would measure a different mechanism than the
+one this card argues about.
+
+<b>Cost, now measured.</b> Two trivial runs on a real host reported <code>$0.657</code> and
+<code>$0.682</code> of <code>total_cost_usd</code>, so 16 prompts &times; 3 runs is roughly
+<b>$30&ndash;50 per host per invocation</b> on a machine with a crowded tool surface.
+<code>--strict-mcp-config</code> with a boost-only config cuts that sharply and controls the
+surface confound in the same move.
 
 <b>What it unlocks.</b> The first honest answer to "did that description edit help", a baseline the
 next surface change can regress against, and a way to retire claims that survive only because
@@ -889,7 +911,7 @@ nobody can check them.</p>
           <span class="m">Complexity <b>L</b></span>
           <span class="m hi">Impact <b>High</b></span>
           <span class="m">Wow <b class="wow">★★★★</b></span>
-          <span class="m">Claude Code arm shipped in</span>
+          <span class="m">the Claude Code probe was broken and its finding was an artifact; fixed, second host still unwritten</span>
         </div>
       </article>
 
@@ -4886,6 +4908,81 @@ existing table, and <code>build</code> already wipes on a version change. One fu
           <span class="m">one changed file re-embeds 29 min for 1.9 s of new text</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="dense-store-holds-every-vector-once-per-copy">
+        <div class="head"><span class="pill planned">Planned</span><span class="cat">Search · Storage</span></div>
+        <h3>The dense store keeps one vector per <em>copy</em>, not one per distinct text</h3>
+        <p><code>_embed_and_store</code> already buys each distinct text <b>once</b> &mdash; <code>seen</code>
+de-duplicates before the provider call, which is why <code>build</code>'s progress total counts
+distinct texts rather than rows. The <em>storage</em> never got the same treatment: every chunk row
+still gets its own <code>vec_raw</code> blob and its own <code>vec_chunks_bin</code> row, so a text
+vendored into 1,464 skills is stored 1,464 times.
+
+<b>Measured on a real store</b> (657,587 chunks, 384-d <code>BAAI/bge-small-en-v1.5</code>):
+657,587 vector rows collapse to <b>396,638 distinct</b> &mdash; 39.7% repeats, <b>1.658&times;</b>.
+The earlier 750,416-chunk / 1024-d Voyage store measured 42.9%, so the ratio is a property of the
+corpus rather than of one embedder.
+
+<b>State the payoff in the right scope.</b> The <code>#544</code> note said &ldquo;~1.75&times;&rdquo;
+without saying of what, and that reads as a whole-store number. It is not. From <code>dbstat</code>
+on the live file: <code>vec_raw</code> 1,287.6&nbsp;MB and <code>vec_chunks_bin</code> 45.1&nbsp;MB
+of a 1,634&nbsp;MB total, so vectors are <b>81.6%</b> of the file. Deduplicating them saves
+<b>529&nbsp;MB</b>; add back a <code>vid</code> column, a hash index and a <code>chunks(vid)</code>
+index and the honest figure is <b>1,634 &rarr; ~1,140&nbsp;MB, 1.43&times; whole-store</b>. On a
+1024-d store, where vectors are ~90% of the file, it lands nearer 1.6&times;.
+
+<b>The key must be the embedding blob, not the text &mdash; and this is the constraint that decides
+the design.</b> <code>export_shard</code> emits <code>name/tap/path/kind/cix/snip/digest/embedding</code>
+and <code>snip</code> is <code>text[:200]</code>: <b>the full chunk text is not in the store and not
+in the shard</b>, so <code>import_shard</code> has nothing to hash. A <code>text_hash</code> column
+is unpopulatable on the import path. <code>sha256(embedding)</code> is equivalent by construction
+&mdash; identical texts are embedded once and serialize to identical bytes &mdash; and it works for
+imports and for the migration.
+
+<b>No join table.</b> <code>#544</code> proposed a chunk&rarr;tap join table; <code>chunks</code>
+already <em>is</em> that table and already carries <code>tap</code>. The change is one
+<code>vid</code> column on <code>chunks</code>, a <code>vectors</code> relation, and
+<code>vec_chunks_bin</code> keyed by <code>vid</code>.
+
+<b>Three things break, and one of them is an ordering.</b> <code>_delete_matching</code> drops
+vectors <em>then</em> rows; refcounted GC must run <em>after</em> the row delete or it counts
+references about to vanish. <code>_store_vector</code>'s orphan guard stops being sufficient, because
+under dedup a <code>_COMMIT_EVERY</code> interrupt makes orphans structural rather than exceptional.
+And <code>export_shard</code>'s <code>v.id = c.id</code> join becomes <code>v.vid = c.vid</code>
+&mdash; the same shape whose breakage the docstring already records as having killed two scheduled
+<code>shards</code> runs.
+
+<b>In place, not an <code>INDEX_VERSION</code> bump.</b> Every input is already on disk, so the
+migration re-encodes rather than re-embeds &mdash; the posture <code>quantize()</code> established,
+and roughly its cost (~1360&nbsp;s, ~2&times; peak while both copies coexist), except that this one
+ends <em>smaller</em>. <code>dense.py</code> promises in writing that v3's re-embed is
+&ldquo;the last one this mechanism needs&rdquo;; a v4 wipe would charge every user a full re-embed
+to reclaim disk, which is the wrong trade even where the embedder is free.
+
+<b>The quality half is already fixed, and this card is not blocked on it.</b>
+<code>MAX_PER_VECTOR</code> thins the candidate pool and caps the page, which is what stopped one
+1,464-copy cluster taking 60 of 60 result slots. Dedup would make the pool distinct
+<em>structurally</em> rather than by thinning, and would let <code>_knn</code> stop hashing 2,048
+blobs per query &mdash; a simplification, not a rescue.
+
+<b>The free bonus nobody has claimed:</b> <code>seen</code> in <code>_embed_and_store</code> is a
+local rebuilt per call, so reuse is <em>per build</em>. A persisted blob-keyed table makes it
+cross-build and cross-tap: a newly tapped mirror registry would cost zero embeddings.
+
+<b>Biggest risk, named:</b> a third schema state. The store already branches float32 vs quantized
+through every vector-touching function; &ldquo;deduplicated or not&rdquo; makes four combinations,
+each needing mutant-killing tests. And the one invariant that catches silent corruption &mdash;
+<code>test_dense_entry_reuse.py</code>'s two-way <code>chunks.id</code> &harr; <code>vec_raw.id</code>
+bijection &mdash; must be <b>rewritten</b> rather than extended, because dedup breaks one direction
+by design. Its replacement: every <code>chunks.vid</code> resolves, and every <code>vectors</code>
+row has at least one referent.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>L</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">39.7% of vector rows are byte-identical repeats; 1.43x whole-store, no re-embedding</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>