boost-skill-cli 1.0.286__tar.gz → 1.0.287__tar.gz

{boost_skill_cli-1.0.286 → boost_skill_cli-1.0.287}/PKG-INFO

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

{boost_skill_cli-1.0.286 → boost_skill_cli-1.0.287}/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.286'
-__version_tuple__ = version_tuple = (1, 0, 286)
+__version__ = version = '1.0.287'
+__version_tuple__ = version_tuple = (1, 0, 287)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.286 → boost_skill_cli-1.0.287}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.0.286 → boost_skill_cli-1.0.287}/docs/roadmap/items/bring-commands-under-mutation-testing.md

@@ -2,14 +2,14 @@
 id: bring-commands-under-mutation-testing
 board: code
 section: planned
-status: planned
+status: declined
 category: Testing · Gap
 complexity: XL
 impact: High
 wow: 3
-note: 
+note: declined 2026-07-29 — 71.9% measured, and the run cannot complete at all
 order: 2
-owner:
+owner: loop/roadmap-decisions
 pr:
 title: Bring <code>commands/</code> under mutation testing
 ---
@@ -47,3 +47,28 @@ The ~8,100-line command layer has <strong>zero</strong> mutation coverage: mutmu
            One prerequisite is already fixed: <code>--no-mcp</code> leaked through
            <code>os.environ</code> and made the suite order-dependent, which mutmut exposes
            because it runs whichever test subset covers each mutant.
+           <b>Declined 2026-07-29.</b> Not "hard" — <em>blocked</em>, and the block is
+           upstream. mutmut <b>3.6.0 is still the latest release</b>, and
+           <code>src/mutmut/__main__.py:120</code> still reads
+           <code>source_paths = [p.resolve(strict=True) for p in Config.get().source_paths]</code>
+           — unconditionally, before the <code>max_stack_depth</code> guard — on paths that
+           <code>configuration.py:102</code> builds as plain relative <code>Path</code>s. Every
+           <code>chdir</code>-ing functional test therefore kills the run, and the functional
+           suite is precisely what takes <code>commands/</code> from 17.9% to 91.5% line
+           coverage. So the two candidate configurations are "floors out near 18%" and "crashes";
+           there is no third. Even granting a fix, the measured numbers already refuse the
+           proposal on their own terms: <b>71.9%</b> against an <b>80%</b> blocking floor, with
+           survivors spread evenly rather than pooled in one testable gap, at
+           <b>2.5–4.5 hours</b> per run against an ~18-minute job. A gate that is 8 points red
+           on the day it lands does not gate anything; it just makes <code>main</code> red.
+           <b>The lead, if anyone reopens this:</b> the crash is a relative-path bug, and
+           <code>source_paths</code> is not required to be relative — an absolute path survives
+           <code>resolve(strict=True)</code> from any working directory. Whether the rest of
+           mutmut's <code>mutants/</code> copy machinery tolerates one is untested. That, plus a
+           non-blocking scheduled job that rotates one module per week, is the shape worth
+           trying; a blocking 80% floor is not.
+           <b>What is not lost by declining.</b> The architecture already puts behaviour in
+           <code>core/</code> — which <em>is</em> mutation-gated at 80% — and keeps
+           <code>commands/</code> as thin CLI glue. The uncovered layer is the one deliberately
+           designed to hold the least logic, and it still carries 91.5% line coverage from the
+           functional suite.

boost_skill_cli-1.0.287/docs/roadmap/items/roadmap-html-goes-stale-on-every-rebase.md

@@ -0,0 +1,69 @@
+---
+id: roadmap-html-goes-stale-on-every-rebase
+board: code
+section: dx
+status: shipped
+category: DX
+complexity: M
+impact: Med
+wow: 3
+note: two of the three fixes measured dead; one survivor, and it needs a Pages change
+order: 59
+owner: loop/roadmap-stale-diagnosis
+pr: 307
+title: <code>roadmap.html</code> goes stale on every rebase, so a card and a merge race redden the whole matrix
+---
+The data-driven roadmap solved the conflict problem for <em>item files</em>: two loops adding
+two cards touch two different files and merge cleanly. But <code>docs/roadmap.html</code> is
+still a single committed artifact generated from <b>all</b> of them, and
+<code>update-branch</code> merges it textually.
+
+So whenever another roadmap-carrying PR merges first, the rebase brings in the new item
+<code>.md</code> cleanly and leaves the generated HTML behind. The board no longer matches
+<code>docs/roadmap/items/</code>, and both <code>build_roadmap.py --check</code> (in lint) and
+<code>tests/unit/test_roadmap_fresh.py</code> fail — on <b>every</b> test leg, for a PR that
+changed no Python at all. It reads as a catastrophic failure and is really a stale generated
+file.
+
+This is not hypothetical: one PR hit it twice in a single afternoon, each time needing a
+manual regenerate-and-push, and the cost scales with the number of concurrent loops — the
+exact workload the item-file split was introduced to support. With <code>strict: true</code>
+every merge rebases every open PR, so any PR carrying a card is guaranteed to hit it if it
+sits behind one other roadmap PR.
+
+Options, roughly in order of appeal: have CI regenerate and push the board on the PR branch
+(fixes it silently, needs a bot token and care with the required checks); a custom merge
+driver for the generated boards that reruns the generator instead of merging text; or stop
+committing the HTML and build the site at deploy time (biggest change, and it removes the
+artifact from review). At minimum, make the <code>--check</code> failure message say
+"regenerate after rebasing" so the cause is obvious from the log.
+<b>Update 2026-07-29 — the three options were measured, and two of them do not work.</b>
+First, the repro, because both halves matter and they fail differently. Two branches each
+adding one item to the same section: the <em>cards</em> hard-conflict (same insertion point),
+while the <em>counters</em> merge silently to a wrong value — base <code>N</code>, both sides
+<code>N+1</code>, git keeps <code>N+1</code>, the truth is <code>N+2</code>. So a clean merge
+still fails <code>--check</code>. That is why one root cause reddens ~6 checks.
+<b>"Custom merge driver" is dead.</b> GitHub's server-side merge ignores
+<code>.gitattributes</code> merge strategies — not just custom drivers, the built-in ones too.
+Measured on this repo with four throwaway branches and
+<code>POST /repos/&hellip;/merges</code>: <b>409 without</b> the attribute and <b>409 with</b>
+<code>docs/roadmap.html merge=union</code>, while the identical merge <em>locally</em> succeeds
+cleanly and one <code>build_roadmap.py</code> run makes it correct. The attribute would help
+only whoever resolves the conflict by hand, which is the case that already works.
+<b>"CI regenerates and pushes on the PR branch" is dead too</b>, at least with
+<code>GITHUB_TOKEN</code>: a push made with it deliberately does not trigger workflows, so the
+fix-up commit would land a new head with <b>no check runs at all</b> and the required contexts
+would never report — the PR blocks forever instead of for one cycle. It needs a PAT or a GitHub
+App, i.e. a new long-lived secret with write access to every branch.
+<b>The survivor is the third one</b> — stop committing the generated HTML and build the site at
+deploy time — and it has a prerequisite that is a repository <em>setting</em>, not a commit:
+Pages is currently <code>build_type: legacy</code> serving <code>main:/</code>, so it publishes
+whatever bytes are committed. The artifact cannot leave git until Pages builds it, which means
+either an Actions-built site or a generated <code>gh-pages</code> branch (the pattern
+<code>ci.yml</code> already uses for the coverage badge, and one that does <b>not</b> re-trigger
+<code>ci</code> → <code>publish</code>, so it cuts no extra release). Everything that reads
+<code>docs/*.html</code> off disk — <code>html-validate</code>, <code>visual</code>,
+<code>lighthouse</code>, <code>check_anchors</code>, <code>a11y_check</code>,
+<code>test_docsite_chrome</code> — would need a generate step first, and
+<code>test_roadmap_fresh</code> loses its purpose. That is the whole cost, and it is bounded;
+what it is not is a change one loop should make to a live public site on its own initiative.

{boost_skill_cli-1.0.286 → boost_skill_cli-1.0.287}/docs/roadmap.html

@@ -47,6 +47,7 @@
   .pill.inflight  { color: var(--cyan); }
   .pill.next      { color: var(--yellow); }
   .pill.planned   { color: var(--violet); }
+  .pill.declined  { color: var(--text-3); }  /* investigated and rejected — not a stage */
 
   .cat { margin-left: auto; font-family: var(--mono); font-size: 11px; color: var(--text-3); letter-spacing: .06em; text-transform: uppercase; }
 
@@ -478,7 +479,7 @@ message, so routing it through the helper would change user-facing errors.</p>
       </article>
 
       <article class="cap rcard" id="bring-commands-under-mutation-testing">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Testing · Gap</span></div>
+        <div class="head"><span class="pill declined">Declined</span><span class="cat">Testing · Gap</span></div>
         <h3>Bring <code>commands/</code> under mutation testing</h3>
         <p>The ~8,100-line command layer has <strong>zero</strong> mutation coverage: mutmut is
            scoped to <code>core/</code> only. A blocking 80% floor was attempted and the
@@ -513,11 +514,37 @@ message, so routing it through the helper would change user-facing errors.</p>
            errors), and a sibling <code>pytest_add_cli_args</code> takes extra pytest flags.
            One prerequisite is already fixed: <code>--no-mcp</code> leaked through
            <code>os.environ</code> and made the suite order-dependent, which mutmut exposes
-           because it runs whichever test subset covers each mutant.</p>
+           because it runs whichever test subset covers each mutant.
+           <b>Declined 2026-07-29.</b> Not "hard" — <em>blocked</em>, and the block is
+           upstream. mutmut <b>3.6.0 is still the latest release</b>, and
+           <code>src/mutmut/__main__.py:120</code> still reads
+           <code>source_paths = [p.resolve(strict=True) for p in Config.get().source_paths]</code>
+           — unconditionally, before the <code>max_stack_depth</code> guard — on paths that
+           <code>configuration.py:102</code> builds as plain relative <code>Path</code>s. Every
+           <code>chdir</code>-ing functional test therefore kills the run, and the functional
+           suite is precisely what takes <code>commands/</code> from 17.9% to 91.5% line
+           coverage. So the two candidate configurations are "floors out near 18%" and "crashes";
+           there is no third. Even granting a fix, the measured numbers already refuse the
+           proposal on their own terms: <b>71.9%</b> against an <b>80%</b> blocking floor, with
+           survivors spread evenly rather than pooled in one testable gap, at
+           <b>2.5–4.5 hours</b> per run against an ~18-minute job. A gate that is 8 points red
+           on the day it lands does not gate anything; it just makes <code>main</code> red.
+           <b>The lead, if anyone reopens this:</b> the crash is a relative-path bug, and
+           <code>source_paths</code> is not required to be relative — an absolute path survives
+           <code>resolve(strict=True)</code> from any working directory. Whether the rest of
+           mutmut's <code>mutants/</code> copy machinery tolerates one is untested. That, plus a
+           non-blocking scheduled job that rotates one module per week, is the shape worth
+           trying; a blocking 80% floor is not.
+           <b>What is not lost by declining.</b> The architecture already puts behaviour in
+           <code>core/</code> — which <em>is</em> mutation-gated at 80% — and keeps
+           <code>commands/</code> as thin CLI glue. The uncovered layer is the one deliberately
+           designed to hold the least logic, and it still carries 91.5% line coverage from the
+           functional suite.</p>
         <div class="meta">
           <span class="m">Complexity <b>XL</b></span>
           <span class="m hi">Impact <b>High</b></span>
           <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">declined 2026-07-29 — 71.9% measured, and the run cannot complete at all</span>
         </div>
       </article>
 
@@ -3126,12 +3153,42 @@ Options, roughly in order of appeal: have CI regenerate and push the board on th
 driver for the generated boards that reruns the generator instead of merging text; or stop
 committing the HTML and build the site at deploy time (biggest change, and it removes the
 artifact from review). At minimum, make the <code>--check</code> failure message say
-"regenerate after rebasing" so the cause is obvious from the log.</p>
+"regenerate after rebasing" so the cause is obvious from the log.
+<b>Update 2026-07-29 — the three options were measured, and two of them do not work.</b>
+First, the repro, because both halves matter and they fail differently. Two branches each
+adding one item to the same section: the <em>cards</em> hard-conflict (same insertion point),
+while the <em>counters</em> merge silently to a wrong value — base <code>N</code>, both sides
+<code>N+1</code>, git keeps <code>N+1</code>, the truth is <code>N+2</code>. So a clean merge
+still fails <code>--check</code>. That is why one root cause reddens ~6 checks.
+<b>"Custom merge driver" is dead.</b> GitHub's server-side merge ignores
+<code>.gitattributes</code> merge strategies — not just custom drivers, the built-in ones too.
+Measured on this repo with four throwaway branches and
+<code>POST /repos/&hellip;/merges</code>: <b>409 without</b> the attribute and <b>409 with</b>
+<code>docs/roadmap.html merge=union</code>, while the identical merge <em>locally</em> succeeds
+cleanly and one <code>build_roadmap.py</code> run makes it correct. The attribute would help
+only whoever resolves the conflict by hand, which is the case that already works.
+<b>"CI regenerates and pushes on the PR branch" is dead too</b>, at least with
+<code>GITHUB_TOKEN</code>: a push made with it deliberately does not trigger workflows, so the
+fix-up commit would land a new head with <b>no check runs at all</b> and the required contexts
+would never report — the PR blocks forever instead of for one cycle. It needs a PAT or a GitHub
+App, i.e. a new long-lived secret with write access to every branch.
+<b>The survivor is the third one</b> — stop committing the generated HTML and build the site at
+deploy time — and it has a prerequisite that is a repository <em>setting</em>, not a commit:
+Pages is currently <code>build_type: legacy</code> serving <code>main:/</code>, so it publishes
+whatever bytes are committed. The artifact cannot leave git until Pages builds it, which means
+either an Actions-built site or a generated <code>gh-pages</code> branch (the pattern
+<code>ci.yml</code> already uses for the coverage badge, and one that does <b>not</b> re-trigger
+<code>ci</code> → <code>publish</code>, so it cuts no extra release). Everything that reads
+<code>docs/*.html</code> off disk — <code>html-validate</code>, <code>visual</code>,
+<code>lighthouse</code>, <code>check_anchors</code>, <code>a11y_check</code>,
+<code>test_docsite_chrome</code> — would need a generate step first, and
+<code>test_roadmap_fresh</code> loses its purpose. That is the whole cost, and it is bounded;
+what it is not is a change one loop should make to a live public site on its own initiative.</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">hit twice on one PR in a single afternoon</span>
+          <span class="m">two of the three fixes measured dead; one survivor, and it needs a Pages change</span>
         </div>
       </article>
 

{boost_skill_cli-1.0.286 → boost_skill_cli-1.0.287}/scripts/build_roadmap.py

@@ -60,6 +60,11 @@ STATUS_LABEL = {
     "inflight": "In flight",
     "next": "Next",
     "planned": "Planned",
+    # A measured "no". Without it, an item that was investigated and rejected
+    # sits on the board as `planned` forever and reads as backlog, so the next
+    # loop scanning for work re-opens the same question. The pill is muted
+    # rather than coloured because a decline is not a lifecycle stage.
+    "declined": "Declined",
 }
 
 # rstatus class -> visible label (design board).

boost_skill_cli-1.0.286/docs/roadmap/items/roadmap-html-goes-stale-on-every-rebase.md

@@ -1,39 +0,0 @@
----
-id: roadmap-html-goes-stale-on-every-rebase
-board: code
-section: dx
-status: shipped
-category: DX
-complexity: M
-impact: Med
-wow: 3
-note: hit twice on one PR in a single afternoon
-order: 59
-owner: loop/roadmap-stale-diagnosis
-pr: 307
-title: <code>roadmap.html</code> goes stale on every rebase, so a card and a merge race redden the whole matrix
----
-The data-driven roadmap solved the conflict problem for <em>item files</em>: two loops adding
-two cards touch two different files and merge cleanly. But <code>docs/roadmap.html</code> is
-still a single committed artifact generated from <b>all</b> of them, and
-<code>update-branch</code> merges it textually.
-
-So whenever another roadmap-carrying PR merges first, the rebase brings in the new item
-<code>.md</code> cleanly and leaves the generated HTML behind. The board no longer matches
-<code>docs/roadmap/items/</code>, and both <code>build_roadmap.py --check</code> (in lint) and
-<code>tests/unit/test_roadmap_fresh.py</code> fail — on <b>every</b> test leg, for a PR that
-changed no Python at all. It reads as a catastrophic failure and is really a stale generated
-file.
-
-This is not hypothetical: one PR hit it twice in a single afternoon, each time needing a
-manual regenerate-and-push, and the cost scales with the number of concurrent loops — the
-exact workload the item-file split was introduced to support. With <code>strict: true</code>
-every merge rebases every open PR, so any PR carrying a card is guaranteed to hit it if it
-sits behind one other roadmap PR.
-
-Options, roughly in order of appeal: have CI regenerate and push the board on the PR branch
-(fixes it silently, needs a bot token and care with the required checks); a custom merge
-driver for the generated boards that reruns the generator instead of merging text; or stop
-committing the HTML and build the site at deploy time (biggest change, and it removes the
-artifact from review). At minimum, make the <code>--check</code> failure message say
-"regenerate after rebasing" so the cause is obvious from the log.