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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.314
+Version: 1.0.315
 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.315}/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.315'
+__version_tuple__ = version_tuple = (1, 0, 315)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.314 → boost_skill_cli-1.0.315/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.315
 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.315}/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.315}/docs/roadmap.html

@@ -3325,7 +3325,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>