boost-skill-cli 1.0.311__tar.gz → 1.0.313__tar.gz

{boost_skill_cli-1.0.311/boost_skill_cli.egg-info → boost_skill_cli-1.0.313}/PKG-INFO

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

{boost_skill_cli-1.0.311 → boost_skill_cli-1.0.313}/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.311'
-__version_tuple__ = version_tuple = (1, 0, 311)
+__version__ = version = '1.0.313'
+__version_tuple__ = version_tuple = (1, 0, 313)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.311 → boost_skill_cli-1.0.313/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.311 → boost_skill_cli-1.0.313}/docs/roadmap/items/demo-cannot-open-its-own-pr.md

@@ -54,3 +54,10 @@ cancel each other, which is where demo's <code>cancelled</code> runs come from.
 Worth reconciling while here: the tree disagrees with itself on the history.
 <code>demo-gif-workflow-has-never-succeeded</code> says "3 runs, 3 failures", while
 <code>demo.yml</code> and <code>ci-failure-issue.yml</code> both say six of six.
+<b>It is not only the demo any more.</b> [[scheduled-toolchain-lock-regeneration]] needs the same
+permission: since <code>#349</code> switched off Dependabot's version updates for the pinned
+toolchain, the replacement is a scheduled job that regenerates the lock and proposes it &mdash; and
+that job cannot open a pull request either. So this toggle now gates two items rather than one, and
+the second is a supply-chain freshness gap rather than a docs asset. That does not make the
+decision automatic, but it does change what is on each side of it.
+

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

@@ -155,3 +155,42 @@ The static approach still wins on cost and would win outright if the quality gap
 which is exactly what the eval should decide. Its own card is right that neither should ship a
 retrieval <i>claim</i> before that eval exists.
 
+<b>Step 6, run against those four constraints &mdash; and it does not say what this card assumed.</b>
+Corpus rebuilt from <code>tests/eval/taps.txt</code> (6 taps, 743 entries, 3740 passages embedded
+locally), k=10, 91 golden queries. Each engine measured <em>alone</em>, no fusion:
+<code>catalog.search</code> hit@1 0.714, recall 0.918, MRR 0.783; <b>BM25 full-content hit@1
+0.780</b>, recall 1.000, MRR 0.860; <b>dense (local bge-small) hit@1 0.780</b>, recall 0.956, MRR
+0.853.
+
+Leading with <code>hit@1</code> as instructed: <b>71 queries each &mdash; an exact tie.</b> Recall
+differs by 4 queries (91 against 87) and MRR by 0.6, both under the ~6-query floor this card sets
+for <em>p</em>&lt;0.05 at this <em>n</em>. So the honest reading is <b>no significant difference
+between BM25 and local dense on the golden set</b> &mdash; not a win for either. An earlier draft of
+this note claimed BM25 won; that was the recall number leading, which is exactly the error the four
+constraints above were written to prevent.
+
+<b>The more useful result is that the golden set cannot grade this feature at all.</b> It scores
+real catalog items <em>by name</em>, which is BM25's strength by construction &mdash;
+<code>CLAUDE.md</code> already records that BM25 recall over this corpus is 1.000. It contains none
+of the human-phrased queries the keyless work exists for, and on those the two engines separate
+sharply: <code>"my app is slow"</code> returns <code>phoenix-docker-setup</code>,
+<code>guidelines</code>, <code>solidjs---error-boundaries</code> from BM25 against
+<code>analyse-problem</code>, <b><code>performance-optimization</code></b>,
+<code>fastapi-best-practices</code> from dense; <code>"I need to make my website accessible"</code>
+returns <code>do-and-judge</code>, <code>write-concisely</code>, <code>do-in-steps</code> against
+<b><code>accessibility-guidelines</code></b> first. That is a demonstration, not a measurement
+&mdash; there is no scored query set of that shape yet, which is the point.
+
+Three consequences. <b>Step 6's first deliverable is a query set, not a number</b>: golden queries
+in the human-phrased style, or the eval keeps answering a question nobody asked. <b>Step 4 (RRF)
+gains support</b> &mdash; a tie on keyword queries plus a qualitative dense win on human ones is the
+"two engines fail in opposite directions" case, and fusing is the response to it. And <b>the current
+preference order deserves a look</b>: <code>rag.retrieve_any</code> takes dense whenever it is ready
+and non-empty, so shipping step 1 without step 4 silently moved keyword queries onto the engine that
+is, at best, tied for them.
+
+<b>Method note.</b> The first indexing pass reported 3 taps failed to embed (2716 of 3740 passages).
+A rerun stored all 3740, and two 30-batch replays never reproduced a failure, so it was transient
+resource pressure rather than a defect &mdash; the retry path (no commit recorded for a failed tap)
+did its job. The figures above come from a complete index.
+

{boost_skill_cli-1.0.311 → boost_skill_cli-1.0.313}/docs/roadmap/items/scheduled-toolchain-lock-regeneration.md

@@ -43,3 +43,31 @@ exists at all is that a bare <code>--upgrade</code> buries one package in unrela
 <code>lock_toolchain.py --audit</code> and <code>requirements/platform-pins.lock</code> already fail
 closed on a lost marker-gated pin, so a regeneration job that got it wrong would be caught the same
 way a Dependabot PR now is.
+
+<b>Blocked on a repository setting, and it is the same one that blocks
+[[demo-cannot-open-its-own-pr]].</b> The obvious shape for this &mdash; a scheduled job that runs
+<code>lock_toolchain.py --upgrade</code> and opens a pull request &mdash; cannot work here.
+Actions&nbsp;&rarr;&nbsp;General&nbsp;&rarr;&nbsp;Workflow permissions&nbsp;&rarr;&nbsp;"Allow
+GitHub Actions to create and approve pull requests" is off; the API reports
+<code>can_approve_pull_request_reviews: false</code>, and <code>demo.yml</code> already fails on
+every push to <code>main</code> with <code>GitHub Actions is not permitted to create or approve
+pull requests</code>. Declaring <code>pull-requests: write</code> does not help, as that card
+established at length. Building this the obvious way would produce a second workflow that is
+correct in the file and inert in reality.
+
+So the two items are coupled: flipping that one toggle unblocks both, which is worth knowing when
+weighing it &mdash; the decision is no longer about a demo GIF alone. That card is right that it is
+a real decision, since the toggle grants <em>every</em> workflow the ability to open pull requests.
+
+<b>Two designs that respect the constraint</b>, if the toggle stays off. Actions can still
+<em>push a branch</em>, so the job can regenerate the lock, commit to
+<code>chore/toolchain-lock-YYYY-MM-DD</code> and stop &mdash; leaving a one-click "Compare &amp;
+pull request", with the expensive part (resolving five groups universally with <code>uv</code>)
+already done. Or it can open an <em>issue</em> containing the diff, which
+<code>issues: write</code> does permit. The branch is better: it carries the actual bytes rather
+than a description of them, and <code>lock_toolchain.py --audit</code> then runs against it as a
+normal PR gate once a human opens it.
+
+Either way the freshness gap this item exists to close narrows from "nobody is watching" to "a
+human clicks a button", which is the honest available improvement while the setting stands.
+

{boost_skill_cli-1.0.311 → boost_skill_cli-1.0.313}/docs/roadmap.html

@@ -741,7 +741,46 @@ toward 50k items — an argument for re-measuring at scale before believing
 
 The static approach still wins on cost and would win outright if the quality gap is small —
 which is exactly what the eval should decide. Its own card is right that neither should ship a
-retrieval <i>claim</i> before that eval exists.</p>
+retrieval <i>claim</i> before that eval exists.
+
+<b>Step 6, run against those four constraints &mdash; and it does not say what this card assumed.</b>
+Corpus rebuilt from <code>tests/eval/taps.txt</code> (6 taps, 743 entries, 3740 passages embedded
+locally), k=10, 91 golden queries. Each engine measured <em>alone</em>, no fusion:
+<code>catalog.search</code> hit@1 0.714, recall 0.918, MRR 0.783; <b>BM25 full-content hit@1
+0.780</b>, recall 1.000, MRR 0.860; <b>dense (local bge-small) hit@1 0.780</b>, recall 0.956, MRR
+0.853.
+
+Leading with <code>hit@1</code> as instructed: <b>71 queries each &mdash; an exact tie.</b> Recall
+differs by 4 queries (91 against 87) and MRR by 0.6, both under the ~6-query floor this card sets
+for <em>p</em>&lt;0.05 at this <em>n</em>. So the honest reading is <b>no significant difference
+between BM25 and local dense on the golden set</b> &mdash; not a win for either. An earlier draft of
+this note claimed BM25 won; that was the recall number leading, which is exactly the error the four
+constraints above were written to prevent.
+
+<b>The more useful result is that the golden set cannot grade this feature at all.</b> It scores
+real catalog items <em>by name</em>, which is BM25's strength by construction &mdash;
+<code>CLAUDE.md</code> already records that BM25 recall over this corpus is 1.000. It contains none
+of the human-phrased queries the keyless work exists for, and on those the two engines separate
+sharply: <code>"my app is slow"</code> returns <code>phoenix-docker-setup</code>,
+<code>guidelines</code>, <code>solidjs---error-boundaries</code> from BM25 against
+<code>analyse-problem</code>, <b><code>performance-optimization</code></b>,
+<code>fastapi-best-practices</code> from dense; <code>"I need to make my website accessible"</code>
+returns <code>do-and-judge</code>, <code>write-concisely</code>, <code>do-in-steps</code> against
+<b><code>accessibility-guidelines</code></b> first. That is a demonstration, not a measurement
+&mdash; there is no scored query set of that shape yet, which is the point.
+
+Three consequences. <b>Step 6's first deliverable is a query set, not a number</b>: golden queries
+in the human-phrased style, or the eval keeps answering a question nobody asked. <b>Step 4 (RRF)
+gains support</b> &mdash; a tie on keyword queries plus a qualitative dense win on human ones is the
+"two engines fail in opposite directions" case, and fusing is the response to it. And <b>the current
+preference order deserves a look</b>: <code>rag.retrieve_any</code> takes dense whenever it is ready
+and non-empty, so shipping step 1 without step 4 silently moved keyword queries onto the engine that
+is, at best, tied for them.
+
+<b>Method note.</b> The first indexing pass reported 3 taps failed to embed (2716 of 3740 passages).
+A rerun stored all 3740, and two 30-batch replays never reproduced a failure, so it was transient
+resource pressure rather than a defect &mdash; the retry path (no commit recorded for a failed tap)
+did its job. The figures above come from a complete index.</p>
         <div class="meta">
           <span class="m">Complexity <b>L</b></span>
           <span class="m hi">Impact <b>High</b></span>
@@ -1502,7 +1541,34 @@ exists at all is that a bare <code>--upgrade</code> buries one package in unrela
 <code>check_required_checks.py</code> enforces. <b>Fourth</b>, nothing needs to guard the output:
 <code>lock_toolchain.py --audit</code> and <code>requirements/platform-pins.lock</code> already fail
 closed on a lost marker-gated pin, so a regeneration job that got it wrong would be caught the same
-way a Dependabot PR now is.</p>
+way a Dependabot PR now is.
+
+<b>Blocked on a repository setting, and it is the same one that blocks
+[[demo-cannot-open-its-own-pr]].</b> The obvious shape for this &mdash; a scheduled job that runs
+<code>lock_toolchain.py --upgrade</code> and opens a pull request &mdash; cannot work here.
+Actions&nbsp;&rarr;&nbsp;General&nbsp;&rarr;&nbsp;Workflow permissions&nbsp;&rarr;&nbsp;"Allow
+GitHub Actions to create and approve pull requests" is off; the API reports
+<code>can_approve_pull_request_reviews: false</code>, and <code>demo.yml</code> already fails on
+every push to <code>main</code> with <code>GitHub Actions is not permitted to create or approve
+pull requests</code>. Declaring <code>pull-requests: write</code> does not help, as that card
+established at length. Building this the obvious way would produce a second workflow that is
+correct in the file and inert in reality.
+
+So the two items are coupled: flipping that one toggle unblocks both, which is worth knowing when
+weighing it &mdash; the decision is no longer about a demo GIF alone. That card is right that it is
+a real decision, since the toggle grants <em>every</em> workflow the ability to open pull requests.
+
+<b>Two designs that respect the constraint</b>, if the toggle stays off. Actions can still
+<em>push a branch</em>, so the job can regenerate the lock, commit to
+<code>chore/toolchain-lock-YYYY-MM-DD</code> and stop &mdash; leaving a one-click "Compare &amp;
+pull request", with the expensive part (resolving five groups universally with <code>uv</code>)
+already done. Or it can open an <em>issue</em> containing the diff, which
+<code>issues: write</code> does permit. The branch is better: it carries the actual bytes rather
+than a description of them, and <code>lock_toolchain.py --audit</code> then runs against it as a
+normal PR gate once a human opens it.
+
+Either way the freshness gap this item exists to close narrows from "nobody is watching" to "a
+human clicks a button", which is the honest available improvement while the setting stands.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m">Impact <b>Med</b></span>
@@ -3044,7 +3110,13 @@ cancel each other, which is where demo's <code>cancelled</code> runs come from.
 
 Worth reconciling while here: the tree disagrees with itself on the history.
 <code>demo-gif-workflow-has-never-succeeded</code> says "3 runs, 3 failures", while
-<code>demo.yml</code> and <code>ci-failure-issue.yml</code> both say six of six.</p>
+<code>demo.yml</code> and <code>ci-failure-issue.yml</code> both say six of six.
+<b>It is not only the demo any more.</b> [[scheduled-toolchain-lock-regeneration]] needs the same
+permission: since <code>#349</code> switched off Dependabot's version updates for the pinned
+toolchain, the replacement is a scheduled job that regenerates the lock and proposes it &mdash; and
+that job cannot open a pull request either. So this toggle now gates two items rather than one, and
+the second is a supply-chain freshness gap rather than a docs asset. That does not make the
+decision automatic, but it does change what is on each side of it.</p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Med</b></span>