boost-skill-cli 1.0.320__tar.gz → 1.0.322__tar.gz

{boost_skill_cli-1.0.320/boost_skill_cli.egg-info → boost_skill_cli-1.0.322}/PKG-INFO

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

{boost_skill_cli-1.0.320 → boost_skill_cli-1.0.322}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.0.320'
-__version_tuple__ = version_tuple = (1, 0, 320)
+__version__ = version = '1.0.322'
+__version_tuple__ = version_tuple = (1, 0, 322)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.320 → boost_skill_cli-1.0.322/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.320 → boost_skill_cli-1.0.322}/docs/roadmap/items/bm25-index-is-one-json-blob.md

@@ -73,3 +73,29 @@ would otherwise never match <code>code-reviewer</code>) and the description alon
 binary format are both untouched, as is moving <code>snip</code> text off the hot path. So is
 <code>build()</code>'s O(entire-corpus) incremental path, which still inverts every posting to
 reindex one changed file.
+
+<b>Where the bytes are now, measured after win (1).</b> This card sends win (2) after two targets:
+postings, and <code>snip</code> text (&ldquo;46.7 MB of the 132 MB&rdquo;, ~35%). That split was a
+property of the <em>chunked</em> index, where every 1000-char window carried its own snippet. With
+one document per entry the balance moves sharply, measured on the pinned 6-tap corpus at 2.05 MB
+total: <b>postings 1.31 MB (64%)</b>, doc metadata 0.46 MB (22%), <b>snips 0.29 MB (14%)</b>, over
+743 documents and 15,639 distinct terms.
+
+So unchunking already collected most of the snippet win, and <b>postings are now the dominant lever
+by a wide margin</b>. Anyone picking up win (2) should size it against 64%, not chase snip at an
+assumed 35%.
+
+<b>FTS5 probe result.</b> Confirmed present on both interpreters available here &mdash; CPython 3.14
+(bundled SQLite 3.53.4) and the macOS system Python 3.9 (SQLite 3.54.0). That supports the card's
+design instruction rather than replacing it: it is still a per-build property, so the runtime probe
+stays required. A distro CPython compiled without <code>ENABLE_FTS5</code> is the case the probe
+exists for.
+
+<b>On the incremental path.</b> The O(entire-corpus) reindex noted above is not separable from win
+(2). <code>_kept_docs</code> calls <code>_postings_to_doc_tf</code> because per-document term
+frequencies exist <em>only</em> inside the postings on disk, so recovering them for the unchanged
+taps means scanning every posting whatever the filter. Narrowing the inversion to kept doc ids saves
+memory but not the scan, and in the common case (one tap of many changed) nearly every document is
+kept, so it saves little of that either. Denormalising <code>tf</code> back into the documents would
+fix it directly but roughly duplicates the 64% that postings already occupy. The real fix is the
+storage format, which is win (2) &mdash; worth treating them as one item rather than two.

{boost_skill_cli-1.0.320 → boost_skill_cli-1.0.322}/docs/roadmap/items/keyless-semantic-search-for-everyone.md

@@ -260,3 +260,16 @@ The set is deliberately <b>not</b> wired into <code>make eval</code> or the requ
 the <code>[rag]</code> extra and a built store, and its purpose is comparing engines rather than
 flooring one. Run it with <code>--golden tests/eval/golden-natural.jsonl</code>.
 
+
+<b>Step 4 is shipped too.</b> <code>rag.rrf_fuse</code> landed in <code>#360</code> with
+<code>RRF_K = 60</code>, fusing on ranks exactly as described above, and
+<code>retrieve_any</code> reports <code>hybrid RRF</code> when both engines are built. Recording it
+here because this card still read as though only step 1 were done, and the next loop scanning for
+work would have rebuilt it. The step's own instruction &mdash; &ldquo;ship the k=60 default, benchmark
+it, and tune only if the eval says so&rdquo; &mdash; was followed: the benchmark is
+<code>tests/eval/golden-natural.jsonl</code>, and k=60 is untouched.
+
+<b>Steps 2, 3, 5 and 6 remain open.</b> Note that step 6 (publish the eval) is now partly answered by
+the gate work in <code>#365</code>, which floors four metrics instead of recall alone and keys
+baselines to their query set, so BM25-vs-dense-vs-hybrid comparisons are at least falsifiable. What
+step 6 still wants is the published write-up rather than the instrument.

{boost_skill_cli-1.0.320 → boost_skill_cli-1.0.322}/docs/roadmap/items/near-duplicate-items-eat-the-result-slots.md

@@ -91,3 +91,35 @@ at one path — and were corrected.
 prior, and the 83-tap re-measurement of the fusion bound are all untouched. Note the two are
 independent: dedup <em>merges</em> copies that are genuinely the same, whereas this fix stops copies
 that were never the same from being merged by accident.
+
+<b>The curve this card asked for.</b> The note above measured 0 duplicate slots over the pinned
+6-tap corpus and said, correctly, that absence at 6 taps says nothing about 83. Re-measured over 77
+tapped registries sampled across the shipped list, with the same 50 natural-language queries,
+counting how many of the ten slots a user sees are second-or-later copies of a name already in that
+same result list:
+
+<code>6 taps</code>: 1,122 entries, 0.0% sharing a name, <b>0.00</b> duplicate slots/query &middot;
+<code>12</code>: 14,194 entries, 77.8%, <b>4.28</b> &middot;
+<code>25</code>: 16,633, 77.9%, 4.12 &middot;
+<code>40</code>: 17,470, 74.7%, 3.88 &middot;
+<code>60</code>: 29,137, 83.9%, 5.08 &middot;
+<code>77</code>: 29,938 entries, 82.7% sharing a name, <b>4.94</b> duplicate slots/query.
+
+So at realistic corpus size <b>roughly half the ten slots a user sees are repeat copies of a name
+already in the list</b>, worst observed 9 of 10 (&ldquo;our full-text queries have got slow as the
+index grew&rdquo;). The card's thesis holds, and more sharply than its own 56.3% figure suggested.
+
+<b>But the driver is not tap count.</b> Entries jump 1,122 &rarr; 14,194 between 6 and 12 taps, so
+the sample is not uniform: a single awesome-list-style rule registry contributes more entries than
+the entire 6-tap eval corpus. Duplicate pressure is a step function of <em>which</em> registries are
+tapped, not a smooth function of how many &mdash; it appears the moment one duplicate-heavy registry
+is added and then stays flat at ~4-5 slots per query from 12 taps to 77. Any dedup benefit should be
+reported against a stated tap set for that reason, and a user who taps only curated skill registries
+may never see the problem at all.
+
+<b>What this does not settle.</b> The measurement counts repeated <em>names</em>, which is the
+symptom the card names, not content-identical bodies &mdash; two rules that share a name and
+genuinely differ (the <code>admin-interface-rule</code> pair fixed in <code>#366</code>) are counted
+here as duplicate slots but must <em>not</em> be merged. That is precisely why the card asks for
+clustering on content hash rather than on name, and this curve is an upper bound on what dedup could
+reclaim, not a target.

{boost_skill_cli-1.0.320 → boost_skill_cli-1.0.322}/docs/roadmap.html

@@ -846,7 +846,21 @@ before concluding the local model is enough.
 
 The set is deliberately <b>not</b> wired into <code>make eval</code> or the required gate: it needs
 the <code>[rag]</code> extra and a built store, and its purpose is comparing engines rather than
-flooring one. Run it with <code>--golden tests/eval/golden-natural.jsonl</code>.</p>
+flooring one. Run it with <code>--golden tests/eval/golden-natural.jsonl</code>.
+
+
+<b>Step 4 is shipped too.</b> <code>rag.rrf_fuse</code> landed in <code>#360</code> with
+<code>RRF_K = 60</code>, fusing on ranks exactly as described above, and
+<code>retrieve_any</code> reports <code>hybrid RRF</code> when both engines are built. Recording it
+here because this card still read as though only step 1 were done, and the next loop scanning for
+work would have rebuilt it. The step's own instruction &mdash; &ldquo;ship the k=60 default, benchmark
+it, and tune only if the eval says so&rdquo; &mdash; was followed: the benchmark is
+<code>tests/eval/golden-natural.jsonl</code>, and k=60 is untouched.
+
+<b>Steps 2, 3, 5 and 6 remain open.</b> Note that step 6 (publish the eval) is now partly answered by
+the gate work in <code>#365</code>, which floors four metrics instead of recall alone and keys
+baselines to their query set, so BM25-vs-dense-vs-hybrid comparisons are at least falsifiable. What
+step 6 still wants is the published write-up rather than the instrument.</p>
         <div class="meta">
           <span class="m">Complexity <b>L</b></span>
           <span class="m hi">Impact <b>High</b></span>
@@ -3426,7 +3440,39 @@ at one path &mdash; and were corrected.
 <b>Still open:</b> the ranking half. Clustering on content hash, picking a winner with a quality
 prior, and the 83-tap re-measurement of the fusion bound are all untouched. Note the two are
 independent: dedup <em>merges</em> copies that are genuinely the same, whereas this fix stops copies
-that were never the same from being merged by accident.</p>
+that were never the same from being merged by accident.
+
+<b>The curve this card asked for.</b> The note above measured 0 duplicate slots over the pinned
+6-tap corpus and said, correctly, that absence at 6 taps says nothing about 83. Re-measured over 77
+tapped registries sampled across the shipped list, with the same 50 natural-language queries,
+counting how many of the ten slots a user sees are second-or-later copies of a name already in that
+same result list:
+
+<code>6 taps</code>: 1,122 entries, 0.0% sharing a name, <b>0.00</b> duplicate slots/query &middot;
+<code>12</code>: 14,194 entries, 77.8%, <b>4.28</b> &middot;
+<code>25</code>: 16,633, 77.9%, 4.12 &middot;
+<code>40</code>: 17,470, 74.7%, 3.88 &middot;
+<code>60</code>: 29,137, 83.9%, 5.08 &middot;
+<code>77</code>: 29,938 entries, 82.7% sharing a name, <b>4.94</b> duplicate slots/query.
+
+So at realistic corpus size <b>roughly half the ten slots a user sees are repeat copies of a name
+already in the list</b>, worst observed 9 of 10 (&ldquo;our full-text queries have got slow as the
+index grew&rdquo;). The card's thesis holds, and more sharply than its own 56.3% figure suggested.
+
+<b>But the driver is not tap count.</b> Entries jump 1,122 &rarr; 14,194 between 6 and 12 taps, so
+the sample is not uniform: a single awesome-list-style rule registry contributes more entries than
+the entire 6-tap eval corpus. Duplicate pressure is a step function of <em>which</em> registries are
+tapped, not a smooth function of how many &mdash; it appears the moment one duplicate-heavy registry
+is added and then stays flat at ~4-5 slots per query from 12 taps to 77. Any dedup benefit should be
+reported against a stated tap set for that reason, and a user who taps only curated skill registries
+may never see the problem at all.
+
+<b>What this does not settle.</b> The measurement counts repeated <em>names</em>, which is the
+symptom the card names, not content-identical bodies &mdash; two rules that share a name and
+genuinely differ (the <code>admin-interface-rule</code> pair fixed in <code>#366</code>) are counted
+here as duplicate slots but must <em>not</em> be merged. That is precisely why the card asks for
+clustering on content hash rather than on name, and this curve is an upper bound on what dedup could
+reclaim, not a target.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m hi">Impact <b>High</b></span>
@@ -3497,7 +3543,33 @@ would otherwise never match <code>code-reviewer</code>) and the description alon
 <b>Still open:</b> win (2), getting postings out of JSON &mdash; the FTS5 probe and the mmap-able
 binary format are both untouched, as is moving <code>snip</code> text off the hot path. So is
 <code>build()</code>'s O(entire-corpus) incremental path, which still inverts every posting to
-reindex one changed file.</p>
+reindex one changed file.
+
+<b>Where the bytes are now, measured after win (1).</b> This card sends win (2) after two targets:
+postings, and <code>snip</code> text (&ldquo;46.7 MB of the 132 MB&rdquo;, ~35%). That split was a
+property of the <em>chunked</em> index, where every 1000-char window carried its own snippet. With
+one document per entry the balance moves sharply, measured on the pinned 6-tap corpus at 2.05 MB
+total: <b>postings 1.31 MB (64%)</b>, doc metadata 0.46 MB (22%), <b>snips 0.29 MB (14%)</b>, over
+743 documents and 15,639 distinct terms.
+
+So unchunking already collected most of the snippet win, and <b>postings are now the dominant lever
+by a wide margin</b>. Anyone picking up win (2) should size it against 64%, not chase snip at an
+assumed 35%.
+
+<b>FTS5 probe result.</b> Confirmed present on both interpreters available here &mdash; CPython 3.14
+(bundled SQLite 3.53.4) and the macOS system Python 3.9 (SQLite 3.54.0). That supports the card's
+design instruction rather than replacing it: it is still a per-build property, so the runtime probe
+stays required. A distro CPython compiled without <code>ENABLE_FTS5</code> is the case the probe
+exists for.
+
+<b>On the incremental path.</b> The O(entire-corpus) reindex noted above is not separable from win
+(2). <code>_kept_docs</code> calls <code>_postings_to_doc_tf</code> because per-document term
+frequencies exist <em>only</em> inside the postings on disk, so recovering them for the unchanged
+taps means scanning every posting whatever the filter. Narrowing the inversion to kept doc ids saves
+memory but not the scan, and in the common case (one tap of many changed) nearly every document is
+kept, so it saves little of that either. Denormalising <code>tf</code> back into the documents would
+fix it directly but roughly duplicates the 64% that postings already occupy. The real fix is the
+storage format, which is win (2) &mdash; worth treating them as one item rather than two.</p>
         <div class="meta">
           <span class="m">Complexity <b>L</b></span>
           <span class="m hi">Impact <b>High</b></span>