boost-skill-cli 1.0.269__tar.gz → 1.0.271__tar.gz

{boost_skill_cli-1.0.269/boost_skill_cli.egg-info → boost_skill_cli-1.0.271}/PKG-INFO

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

{boost_skill_cli-1.0.269 → boost_skill_cli-1.0.271}/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.269'
-__version_tuple__ = version_tuple = (1, 0, 269)
+__version__ = version = '1.0.271'
+__version_tuple__ = version_tuple = (1, 0, 271)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.269 → boost_skill_cli-1.0.271/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.269 → boost_skill_cli-1.0.271}/boost_skill_cli.egg-info/SOURCES.txt

@@ -170,7 +170,9 @@ docs/roadmap/items/cache-the-catalog-entry-set-across-rag-queries.md
 docs/roadmap/items/capability-manifest-and-least-privilege-policy.md
 docs/roadmap/items/ci-job-timeout-minutes.md
 docs/roadmap/items/ci-summary-step-fails-itself.md
+docs/roadmap/items/ci-time-is-now-runner-queueing.md
 docs/roadmap/items/clean-env-install-smoke-pip-and-pipx.md
+docs/roadmap/items/code-scanning-rule-can-be-restored.md
 docs/roadmap/items/command-carousel-page.md
 docs/roadmap/items/command-reference-docs-site.md
 docs/roadmap/items/complexity-and-dead-code-radar-xenon-vulture.md
@@ -238,6 +240,7 @@ docs/roadmap/items/mutation-gate-was-the-whole-critical-path.md
 docs/roadmap/items/mutation-hardening-core-frontmatter-py.md
 docs/roadmap/items/mutation-hardening-core-gitutil-py.md
 docs/roadmap/items/mutation-hardening-core-store-py.md
+docs/roadmap/items/mutation-shard-floor-is-one-file.md
 docs/roadmap/items/mypy-strict-mode-for-commands.md
 docs/roadmap/items/negative-limit-inverts-log-pulse-output.md
 docs/roadmap/items/onboard-overwrites-generated-files-without-confirm.md
@@ -316,6 +319,7 @@ docs/roadmap/items/workflow-install-native-materialization.md
 docs/roadmap/items/workflow-linting-actionlint.md
 docs/roadmap/items/workflow-sast-zizmor.md
 docs/roadmap/items/workspace-scope-install.md
+docs/roadmap/items/zizmor-pin-is-a-yanked-release.md
 examples/README.md
 examples/adapt-demo.sh
 examples/boost-run-prototype.sh

boost_skill_cli-1.0.271/docs/roadmap/items/ci-time-is-now-runner-queueing.md

@@ -0,0 +1,40 @@
+---
+id: ci-time-is-now-runner-queueing
+board: code
+section: pipeline
+status: planned
+category: CI speed
+complexity: M
+impact: High
+wow: 4
+note: 104 job-min queued vs 236 executing — 31% of CI is waiting for a runner
+order: 62
+owner:
+pr:
+title: A third of CI job time is spent waiting for a runner, not running
+---
+With the mutation gate no longer dominating, the largest remaining term in CI wall clock is
+<b>queueing</b>. Measured over six consecutive successful <code>ci</code> runs: <b>104
+job-minutes queued</b> against <b>236 job-minutes executing</b> &mdash; <b>31%</b> of all job
+time spent waiting for a runner.
+
+<b>The obvious metric lies.</b> A run's <code>run_started_at</code> minus
+<code>created_at</code> is <b>0.0 for every run</b>, which reads as "no queueing anywhere".
+Queueing happens per <em>job</em>, not per run, so it is only visible as
+<code>job.started_at - job.created_at</code>. Anything measuring this at run level will
+conclude, wrongly, that there is nothing to fix.
+
+The per-run spread shows what drives it &mdash; median job queue by run:
+<code>c36c53a7</code> 0.1&nbsp;min, <code>c15ed9da</code> 0.1, <code>903b704f</code> 0.2,
+<code>638bffeb</code> 0.7, <code>ad71ba99</code> <b>2.5</b>, <code>9e190537</code> <b>2.9</b>.
+That is a 29&times; swing driven not by the change under test but by how many sibling
+<code>loop/*</code> branches and Dependabot PRs happen to be live at the same moment. It is why
+one merge took <b>41 minutes</b> wall clock with a max shard of only 11.4.
+
+Sharding the mutation gate made this worse on purpose: it traded one runner slot for six. That
+is the right trade for latency in isolation, and the wrong one to keep making blindly while a
+dozen branches are in flight, because every concurrent PR now multiplies its footprint. Options,
+roughly in increasing order of intrusiveness: a <code>concurrency</code> group that cancels
+superseded PR runs; capping the shard matrix with <code>max-parallel</code>; or making the shard
+count adaptive. Worth measuring before choosing &mdash; this item is the measurement, not the
+fix.

boost_skill_cli-1.0.271/docs/roadmap/items/code-scanning-rule-can-be-restored.md

@@ -0,0 +1,47 @@
+---
+id: code-scanning-rule-can-be-restored
+board: code
+section: trust
+status: planned
+category: Release safety
+complexity: S
+impact: Med
+wow: 4
+note: safe scoped to CodeQL (0 open) — adding Scorecard deadlocks every merge
+order: 54
+owner:
+pr:
+title: The <code>code_scanning</code> ruleset rule can go back on &mdash; but only scoped to CodeQL
+---
+Repairing the <code>main</code> ruleset dropped its <code>code_scanning</code> rule in favour of
+<code>codeql-analyze</code> as a required status check (see
+<code>main-ruleset-ref-pattern-has-literal-quotes</code>). That was the safe call at the time, and
+it left an open question: can the rule come back? <b>Yes &mdash; and the thing that would break it
+is not what it looks like.</b>
+
+<b>Nothing is blocking it.</b> Verified without touching the live ruleset: POST a throwaway
+ruleset with <code>enforcement: disabled</code> and a ref pattern matching no branch, carrying
+<code>code_scanning</code> for tool <code>CodeQL</code> &rarr; <b>HTTP 201</b>, rule stored intact.
+Delete it, then diff the live ruleset against a backup taken beforehand &rarr; no drift. That
+disabled-and-non-matching probe is the general way to test a ruleset change without risking
+anyone's in-flight pull request.
+
+<b>The stale analyses are a red herring.</b> 693 analyses still carry the old
+<code>codeql.yml:analyze</code> category against 122 on the current <code>codeql-analyze</code>,
+which looks like it should matter and does not: the rule keys on <b>tool name</b>, not category.
+Deleting them is irreversible, destroys alert history, and fixes nothing. Don't.
+
+<b>The actual hazard is the tool list.</b> Three tools file into the same code-scanning inbox.
+CodeQL has <b>0 open</b> alerts (9 dismissed, 17 fixed). Scorecard has <b>7 open, every one
+<code>severity=error</code></b> &mdash; and they are posture metrics that must not be dismissed,
+so they will stay open. Enabling the rule with Scorecard in its tool list therefore blocks
+<em>every merge in the repository, immediately</em>. The GitHub UI offers every tool that has
+reported analyses, so Scorecard sits right next to CodeQL in the picker. That is almost certainly
+why this has been assumed to be blocked.
+
+Scoped to CodeQL alone it is safe and adds real protection: <code>codeql.yml</code> carries no
+path filters and runs on <code>push</code>, <code>pull_request</code> and
+<code>merge_group</code>, so it always reports and cannot produce the never-reports deadlock this
+repo has hit twice. And it catches something the status check does not &mdash;
+<code>codeql-analyze</code> passes when the <em>job</em> succeeds, including when it succeeds
+having found error-severity alerts.

boost_skill_cli-1.0.271/docs/roadmap/items/mutation-shard-floor-is-one-file.md

@@ -0,0 +1,43 @@
+---
+id: mutation-shard-floor-is-one-file
+board: code
+section: pipeline
+status: planned
+category: CI speed
+complexity: M
+impact: Med
+wow: 3
+note: shard 0 is store.py alone — 9.3-11.7 min against a 6.1 even split
+order: 61
+owner:
+pr:
+title: The mutation gate's floor is a single file &mdash; shard 0 <em>is</em> <code>store.py</code>
+---
+Sharding took the mutation gate from ~28 minutes to ~12 (see
+<code>mutation-gate-was-the-whole-critical-path</code>), but it cannot go lower without
+splitting one file. Measured across four consecutive six-shard runs:
+
+<code>638bffeb</code> ran 1.9, 3.9, 5.7, 6.7, 7.2, <b>11.7</b>&nbsp;minutes;
+<code>02c18bd6</code> ran 2.7, 5.0, 5.2, 5.5, 5.9, <b>11.7</b>; <code>fc427839</code> ran 3.1,
+4.8, 5.3, 6.4, 7.3, <b>9.7</b>; and <code>f42e617b</code> ran 2.9, 4.9, 5.5, 6.6, 7.3,
+<b>9.3</b>.
+<b><code>mutation-shard (0)</code> was the slowest leg in all four.</b> Total work is
+36&ndash;37 job-minutes, so a perfectly even split would be <b>6.1</b>; the actual critical
+path is 9.3&ndash;11.7, or <b>1.5&ndash;1.9&times;</b> that. The gap is not bad packing &mdash;
+the planner balances mutant <em>count</em> to within 1.10&times; of ideal. It is that count is
+a poor proxy for time: measured throughput spans <b>3.39 to 14.19 mutants/second</b>, because a
+<code>store.py</code> mutant re-runs a far larger covering test set than an
+<code>ed25519.py</code> one, and survivors run their tests to completion where kills exit early.
+
+Re-weighting the planner by seconds would even out the <em>billed</em> minutes but not the wall
+clock, because <code>store.py</code> is <b>1931 mutants (18.4% of the repo)</b> in one file and
+longest-processing-time packing cannot place a single file across two bins. The floor is that
+file.
+
+The way under it: mutant names are addressable per function, so
+<code>boost_cli.core.store.install_*</code> can be its own shard. That would bring the critical
+path toward the 6.1-minute even split. Two things must survive the change &mdash;
+<code>pattern_for()</code> still has to emit patterns that match nothing else, and
+<code>cmd_merge</code>'s completeness assertion has to keep failing closed, since mutmut counts
+an unrun mutant inside <code>total</code> and a partial merge would silently depress the score
+rather than error.

boost_skill_cli-1.0.271/docs/roadmap/items/zizmor-pin-is-a-yanked-release.md

@@ -0,0 +1,36 @@
+---
+id: zizmor-pin-is-a-yanked-release
+board: code
+section: pipeline
+status: planned
+category: Security · CI/CD
+complexity: S
+impact: Med
+wow: 4
+note: the only yanked release of 66 — and the required lint job pins exactly it
+order: 63
+owner:
+pr:
+title: The required <code>lint</code> job pins <code>zizmor==1.27.0</code> &mdash; a yanked release
+---
+<code>ci.yml</code> runs the workflow SAST step as
+<code>pipx run zizmor==1.27.0 .github/workflows</code>. PyPI marks <b>1.27.0 as yanked</b>, with
+<code>yanked_reason: GHSA-f42p-wjw5-97qh</code>. It is the <b>only yanked release out of 66</b>,
+and <b>1.28.0</b> is the successor.
+
+Exact-pinning the security scanner is correct &mdash; an unpinned linter is how
+<code>ruff-defaults-broke-boost-lint</code> happened. Pinning to a version its maintainer has
+<em>withdrawn for a security advisory</em> is the failure mode on the other side, and it is
+quieter: a yank does not stop an exact pin from resolving. <code>pip</code> installs
+<code>1.27.0</code> and emits a warning nobody reads in CI logs, so the required <code>lint</code>
+gate goes on passing while running a withdrawn build of the tool that audits the workflows
+driving a Trusted-Publisher release.
+
+Two things worth doing together. Bump to <code>1.28.0</code> and confirm the four documented
+<code>dangerous-triggers</code> exemptions in <code>.github/zizmor.yml</code> still suppress
+cleanly &mdash; the line-anchored ignore entries (<code>publish.yml:19</code>,
+<code>sbom.yml:29</code>, &hellip;) are exactly the kind of thing a version bump can invalidate.
+And sweep the other exact pins for yanks: nothing currently checks for this. <code>pip-audit</code>
+catches CVEs in the resolved dependency closure, but a yanked <em>pinned tool</em> is neither a
+CVE in the closure nor a manifest diff, so <code>osv-scanner</code> does not see it either. This
+was found by accident, while installing zizmor locally to verify an unrelated change.

{boost_skill_cli-1.0.269 → boost_skill_cli-1.0.271}/docs/roadmap.html

@@ -110,7 +110,7 @@
       <div class="stat"><b>16</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>4</b><span>Planned</span></div>
-      <div class="stat"><b>162</b><span>Loop finds</span></div>
+      <div class="stat"><b>166</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -2326,6 +2326,113 @@ toward the 5.1-minute even split of the 30.8 minutes of total work.</p>
           <span class="m">28 min of CI became 12; the new floor is one file, store.py</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="mutation-shard-floor-is-one-file">
+        <div class="head"><span class="pill planned">Planned</span><span class="cat">CI speed</span></div>
+        <h3>The mutation gate's floor is a single file &mdash; shard 0 <em>is</em> <code>store.py</code></h3>
+        <p>Sharding took the mutation gate from ~28 minutes to ~12 (see
+<code>mutation-gate-was-the-whole-critical-path</code>), but it cannot go lower without
+splitting one file. Measured across four consecutive six-shard runs:
+
+<code>638bffeb</code> ran 1.9, 3.9, 5.7, 6.7, 7.2, <b>11.7</b>&nbsp;minutes;
+<code>02c18bd6</code> ran 2.7, 5.0, 5.2, 5.5, 5.9, <b>11.7</b>; <code>fc427839</code> ran 3.1,
+4.8, 5.3, 6.4, 7.3, <b>9.7</b>; and <code>f42e617b</code> ran 2.9, 4.9, 5.5, 6.6, 7.3,
+<b>9.3</b>.
+<b><code>mutation-shard (0)</code> was the slowest leg in all four.</b> Total work is
+36&ndash;37 job-minutes, so a perfectly even split would be <b>6.1</b>; the actual critical
+path is 9.3&ndash;11.7, or <b>1.5&ndash;1.9&times;</b> that. The gap is not bad packing &mdash;
+the planner balances mutant <em>count</em> to within 1.10&times; of ideal. It is that count is
+a poor proxy for time: measured throughput spans <b>3.39 to 14.19 mutants/second</b>, because a
+<code>store.py</code> mutant re-runs a far larger covering test set than an
+<code>ed25519.py</code> one, and survivors run their tests to completion where kills exit early.
+
+Re-weighting the planner by seconds would even out the <em>billed</em> minutes but not the wall
+clock, because <code>store.py</code> is <b>1931 mutants (18.4% of the repo)</b> in one file and
+longest-processing-time packing cannot place a single file across two bins. The floor is that
+file.
+
+The way under it: mutant names are addressable per function, so
+<code>boost_cli.core.store.install_*</code> can be its own shard. That would bring the critical
+path toward the 6.1-minute even split. Two things must survive the change &mdash;
+<code>pattern_for()</code> still has to emit patterns that match nothing else, and
+<code>cmd_merge</code>'s completeness assertion has to keep failing closed, since mutmut counts
+an unrun mutant inside <code>total</code> and a partial merge would silently depress the score
+rather than error.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">shard 0 is store.py alone — 9.3-11.7 min against a 6.1 even split</span>
+        </div>
+      </article>
+
+      <article class="cap rcard" id="ci-time-is-now-runner-queueing">
+        <div class="head"><span class="pill planned">Planned</span><span class="cat">CI speed</span></div>
+        <h3>A third of CI job time is spent waiting for a runner, not running</h3>
+        <p>With the mutation gate no longer dominating, the largest remaining term in CI wall clock is
+<b>queueing</b>. Measured over six consecutive successful <code>ci</code> runs: <b>104
+job-minutes queued</b> against <b>236 job-minutes executing</b> &mdash; <b>31%</b> of all job
+time spent waiting for a runner.
+
+<b>The obvious metric lies.</b> A run's <code>run_started_at</code> minus
+<code>created_at</code> is <b>0.0 for every run</b>, which reads as "no queueing anywhere".
+Queueing happens per <em>job</em>, not per run, so it is only visible as
+<code>job.started_at - job.created_at</code>. Anything measuring this at run level will
+conclude, wrongly, that there is nothing to fix.
+
+The per-run spread shows what drives it &mdash; median job queue by run:
+<code>c36c53a7</code> 0.1&nbsp;min, <code>c15ed9da</code> 0.1, <code>903b704f</code> 0.2,
+<code>638bffeb</code> 0.7, <code>ad71ba99</code> <b>2.5</b>, <code>9e190537</code> <b>2.9</b>.
+That is a 29&times; swing driven not by the change under test but by how many sibling
+<code>loop/*</code> branches and Dependabot PRs happen to be live at the same moment. It is why
+one merge took <b>41 minutes</b> wall clock with a max shard of only 11.4.
+
+Sharding the mutation gate made this worse on purpose: it traded one runner slot for six. That
+is the right trade for latency in isolation, and the wrong one to keep making blindly while a
+dozen branches are in flight, because every concurrent PR now multiplies its footprint. Options,
+roughly in increasing order of intrusiveness: a <code>concurrency</code> group that cancels
+superseded PR runs; capping the shard matrix with <code>max-parallel</code>; or making the shard
+count adaptive. Worth measuring before choosing &mdash; this item is the measurement, not the
+fix.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">104 job-min queued vs 236 executing — 31% of CI is waiting for a runner</span>
+        </div>
+      </article>
+
+      <article class="cap rcard" id="zizmor-pin-is-a-yanked-release">
+        <div class="head"><span class="pill planned">Planned</span><span class="cat">Security · CI/CD</span></div>
+        <h3>The required <code>lint</code> job pins <code>zizmor==1.27.0</code> &mdash; a yanked release</h3>
+        <p><code>ci.yml</code> runs the workflow SAST step as
+<code>pipx run zizmor==1.27.0 .github/workflows</code>. PyPI marks <b>1.27.0 as yanked</b>, with
+<code>yanked_reason: GHSA-f42p-wjw5-97qh</code>. It is the <b>only yanked release out of 66</b>,
+and <b>1.28.0</b> is the successor.
+
+Exact-pinning the security scanner is correct &mdash; an unpinned linter is how
+<code>ruff-defaults-broke-boost-lint</code> happened. Pinning to a version its maintainer has
+<em>withdrawn for a security advisory</em> is the failure mode on the other side, and it is
+quieter: a yank does not stop an exact pin from resolving. <code>pip</code> installs
+<code>1.27.0</code> and emits a warning nobody reads in CI logs, so the required <code>lint</code>
+gate goes on passing while running a withdrawn build of the tool that audits the workflows
+driving a Trusted-Publisher release.
+
+Two things worth doing together. Bump to <code>1.28.0</code> and confirm the four documented
+<code>dangerous-triggers</code> exemptions in <code>.github/zizmor.yml</code> still suppress
+cleanly &mdash; the line-anchored ignore entries (<code>publish.yml:19</code>,
+<code>sbom.yml:29</code>, &hellip;) are exactly the kind of thing a version bump can invalidate.
+And sweep the other exact pins for yanks: nothing currently checks for this. <code>pip-audit</code>
+catches CVEs in the resolved dependency closure, but a yanked <em>pinned tool</em> is neither a
+CVE in the closure nor a manifest diff, so <code>osv-scanner</code> does not see it either. This
+was found by accident, while installing zizmor locally to verify an unrelated change.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">the only yanked release of 66 — and the required lint job pins exactly it</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>
@@ -3726,6 +3833,49 @@ same-repo PRs and red CI.</p>
           <span class="m">a PR branch named main could cut a PyPI release</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="code-scanning-rule-can-be-restored">
+        <div class="head"><span class="pill planned">Planned</span><span class="cat">Release safety</span></div>
+        <h3>The <code>code_scanning</code> ruleset rule can go back on &mdash; but only scoped to CodeQL</h3>
+        <p>Repairing the <code>main</code> ruleset dropped its <code>code_scanning</code> rule in favour of
+<code>codeql-analyze</code> as a required status check (see
+<code>main-ruleset-ref-pattern-has-literal-quotes</code>). That was the safe call at the time, and
+it left an open question: can the rule come back? <b>Yes &mdash; and the thing that would break it
+is not what it looks like.</b>
+
+<b>Nothing is blocking it.</b> Verified without touching the live ruleset: POST a throwaway
+ruleset with <code>enforcement: disabled</code> and a ref pattern matching no branch, carrying
+<code>code_scanning</code> for tool <code>CodeQL</code> &rarr; <b>HTTP 201</b>, rule stored intact.
+Delete it, then diff the live ruleset against a backup taken beforehand &rarr; no drift. That
+disabled-and-non-matching probe is the general way to test a ruleset change without risking
+anyone's in-flight pull request.
+
+<b>The stale analyses are a red herring.</b> 693 analyses still carry the old
+<code>codeql.yml:analyze</code> category against 122 on the current <code>codeql-analyze</code>,
+which looks like it should matter and does not: the rule keys on <b>tool name</b>, not category.
+Deleting them is irreversible, destroys alert history, and fixes nothing. Don't.
+
+<b>The actual hazard is the tool list.</b> Three tools file into the same code-scanning inbox.
+CodeQL has <b>0 open</b> alerts (9 dismissed, 17 fixed). Scorecard has <b>7 open, every one
+<code>severity=error</code></b> &mdash; and they are posture metrics that must not be dismissed,
+so they will stay open. Enabling the rule with Scorecard in its tool list therefore blocks
+<em>every merge in the repository, immediately</em>. The GitHub UI offers every tool that has
+reported analyses, so Scorecard sits right next to CodeQL in the picker. That is almost certainly
+why this has been assumed to be blocked.
+
+Scoped to CodeQL alone it is safe and adds real protection: <code>codeql.yml</code> carries no
+path filters and runs on <code>push</code>, <code>pull_request</code> and
+<code>merge_group</code>, so it always reports and cannot produce the never-reports deadlock this
+repo has hit twice. And it catches something the status check does not &mdash;
+<code>codeql-analyze</code> passes when the <em>job</em> succeeds, including when it succeeds
+having found error-severity alerts.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">safe scoped to CodeQL (0 open) — adding Scorecard deadlocks every merge</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>