boost-skill-cli 1.0.314__tar.gz → 1.0.316__tar.gz

{boost_skill_cli-1.0.314/boost_skill_cli.egg-info → boost_skill_cli-1.0.316}/PKG-INFO

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

{boost_skill_cli-1.0.314 → boost_skill_cli-1.0.316}/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.314'
-__version_tuple__ = version_tuple = (1, 0, 314)
+__version__ = version = '1.0.316'
+__version_tuple__ = version_tuple = (1, 0, 316)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.314 → boost_skill_cli-1.0.316/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.314 → boost_skill_cli-1.0.316}/docs/roadmap/items/eval-corpus-cannot-see-real-retrieval.md

@@ -40,3 +40,23 @@ instrument that exists rather than to build one. Also needed: queries that
 <em>only</em> body text can satisfy. The golden set grades items by name, so it
 scores a surface-only index <em>above</em> the full-content one and would
 cheerfully greenlight deleting body indexing altogether.
+<b>Half of the "also needed" already exists.</b> This card asks for queries that <em>only</em> body
+text can satisfy, on the grounds that a name-graded set would greenlight deleting body indexing.
+<code>tests/eval/golden-natural.jsonl</code> (shipped in <code>#360</code>) is 50 such queries: each
+is written from its target's own <code>description</code> and has the target's distinctive
+<b>name tokens deliberately stripped</b> &mdash; a mechanical check rejected five drafts that had
+leaked one &mdash; so a surface-only index cannot answer them. It was written before any engine ran
+against it and scored once, which is the same fitting-and-reporting discipline this group needs.
+
+It corroborates this card's thesis from a second, independent direction. This card shows the gate
+blind to <b>corpus size</b>: 1.000 on 23 taps against 0.720 on 83. The natural set shows it blind to
+<b>query shape</b> on the <em>same</em> corpus &mdash; BM25 scores recall 1.000 / hit@1 0.780 on the
+keyword golden set and <b>0.690 / 0.240</b> on natural-language queries over identical data. Two
+different axes, same conclusion: the number the gate reports is not a number about retrieval.
+
+What it does <b>not</b> fix is the corpus-size half, which is this card's own finding and remains
+open &mdash; 50 queries over 6 taps cannot speak to an 83-tap install. The two are complementary
+rather than overlapping, and combining them (natural-language queries over a realistically sized
+corpus) is the instrument this group actually wants. Also unaddressed here: the kind oracle, the
+recall-only floor and <code>--regression-eps 1</code> are all still exactly as described above.
+

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

@@ -38,3 +38,26 @@ of 11,147 entries (14.0%), worst case <code>('survivorforge/cursor-rules',
 'rule')</code> ×47. Anything keyed on it — a cache, a shipped artifact, a lock
 row — silently binds data to the wrong entry. Use <code>(tap, skill_md)</code>,
 which is 11,147/11,147 distinct.
+<b>A scale bound, and one claim checked.</b> This card holds that reciprocal-rank fusion
+"actively reinforces the agreement" between duplicate copies. That is a claim about
+<code>rag.rrf_fuse</code> as shipped in <code>#360</code>, so it was worth measuring rather than
+assuming. Over the <em>pinned 6-tap eval corpus</em> &mdash; 743 entries, 693 unique names, so
+<b>12.7%</b> of entries share a name against the 56.3% measured on the 83-tap install &mdash; and
+the 50 natural-language queries in <code>tests/eval/golden-natural.jsonl</code>: repeated-name slots
+consumed in the top-10 were <b>0 for BM25, 0 for dense and 0 for hybrid</b>. Querying <em>directly</em>
+at a duplicated item (<code>code-reviewer</code> appears in 3 taps here, <code>judge</code> and
+<code>guidelines</code> in 2) returned exactly <b>one</b> copy in the top-10 under all three engines.
+
+So at this scale fusion is <b>neutral</b>, not amplifying &mdash; it consumes no more duplicate slots
+than either engine alone. That does not contradict this card: absence at 6 taps says nothing about
+83, where <code>rule</code> spans 47 registries and 18% of bodies are byte-identical. What it adds
+is a lower bound and a mechanism note. Duplicates survive fusion because
+<code>rrf_fuse</code> keys on <code>(name, tap)</code>, exactly as <code>rag.retrieve</code> already
+does, so copies in different taps remain distinct keys under every engine; fusion neither merges nor
+multiplies them. If the amplification appears at 83 taps it will be because both engines
+<em>rank</em> the copies adjacently, not because fusion treats them specially &mdash; which points
+the fix at deduplication before ranking rather than at the fusion rule.
+
+Worth re-measuring on the 83-tap install with the same script (<code>rrf_fuse</code> is public) to
+turn this bound into a curve.
+

{boost_skill_cli-1.0.314 → boost_skill_cli-1.0.316}/docs/roadmap.html

@@ -1735,7 +1735,26 @@ size (57 entries, 1 tap), not metric design, so the work is to grow an
 instrument that exists rather than to build one. Also needed: queries that
 <em>only</em> body text can satisfy. The golden set grades items by name, so it
 scores a surface-only index <em>above</em> the full-content one and would
-cheerfully greenlight deleting body indexing altogether.</p>
+cheerfully greenlight deleting body indexing altogether.
+<b>Half of the "also needed" already exists.</b> This card asks for queries that <em>only</em> body
+text can satisfy, on the grounds that a name-graded set would greenlight deleting body indexing.
+<code>tests/eval/golden-natural.jsonl</code> (shipped in <code>#360</code>) is 50 such queries: each
+is written from its target's own <code>description</code> and has the target's distinctive
+<b>name tokens deliberately stripped</b> &mdash; a mechanical check rejected five drafts that had
+leaked one &mdash; so a surface-only index cannot answer them. It was written before any engine ran
+against it and scored once, which is the same fitting-and-reporting discipline this group needs.
+
+It corroborates this card's thesis from a second, independent direction. This card shows the gate
+blind to <b>corpus size</b>: 1.000 on 23 taps against 0.720 on 83. The natural set shows it blind to
+<b>query shape</b> on the <em>same</em> corpus &mdash; BM25 scores recall 1.000 / hit@1 0.780 on the
+keyword golden set and <b>0.690 / 0.240</b> on natural-language queries over identical data. Two
+different axes, same conclusion: the number the gate reports is not a number about retrieval.
+
+What it does <b>not</b> fix is the corpus-size half, which is this card's own finding and remains
+open &mdash; 50 queries over 6 taps cannot speak to an 83-tap install. The two are complementary
+rather than overlapping, and combining them (natural-language queries over a realistically sized
+corpus) is the instrument this group actually wants. Also unaddressed here: the kind oracle, the
+recall-only floor and <code>--regression-eps 1</code> are all still exactly as described above.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m hi">Impact <b>High</b></span>
@@ -3325,7 +3344,29 @@ Second, <b><code>(tap, name)</code> is not a unique key</b>: it collides on 1,55
 of 11,147 entries (14.0%), worst case <code>('survivorforge/cursor-rules',
 'rule')</code> ×47. Anything keyed on it — a cache, a shipped artifact, a lock
 row — silently binds data to the wrong entry. Use <code>(tap, skill_md)</code>,
-which is 11,147/11,147 distinct.</p>
+which is 11,147/11,147 distinct.
+<b>A scale bound, and one claim checked.</b> This card holds that reciprocal-rank fusion
+"actively reinforces the agreement" between duplicate copies. That is a claim about
+<code>rag.rrf_fuse</code> as shipped in <code>#360</code>, so it was worth measuring rather than
+assuming. Over the <em>pinned 6-tap eval corpus</em> &mdash; 743 entries, 693 unique names, so
+<b>12.7%</b> of entries share a name against the 56.3% measured on the 83-tap install &mdash; and
+the 50 natural-language queries in <code>tests/eval/golden-natural.jsonl</code>: repeated-name slots
+consumed in the top-10 were <b>0 for BM25, 0 for dense and 0 for hybrid</b>. Querying <em>directly</em>
+at a duplicated item (<code>code-reviewer</code> appears in 3 taps here, <code>judge</code> and
+<code>guidelines</code> in 2) returned exactly <b>one</b> copy in the top-10 under all three engines.
+
+So at this scale fusion is <b>neutral</b>, not amplifying &mdash; it consumes no more duplicate slots
+than either engine alone. That does not contradict this card: absence at 6 taps says nothing about
+83, where <code>rule</code> spans 47 registries and 18% of bodies are byte-identical. What it adds
+is a lower bound and a mechanism note. Duplicates survive fusion because
+<code>rrf_fuse</code> keys on <code>(name, tap)</code>, exactly as <code>rag.retrieve</code> already
+does, so copies in different taps remain distinct keys under every engine; fusion neither merges nor
+multiplies them. If the amplification appears at 83 taps it will be because both engines
+<em>rank</em> the copies adjacently, not because fusion treats them specially &mdash; which points
+the fix at deduplication before ranking rather than at the fusion rule.
+
+Worth re-measuring on the 83-tap install with the same script (<code>rrf_fuse</code> is public) to
+turn this bound into a curve.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m hi">Impact <b>High</b></span>