boost-skill-cli 1.2.145__tar.gz → 1.2.147__tar.gz

{boost_skill_cli-1.2.145 → boost_skill_cli-1.2.147}/.vale/styles/config/vocabularies/boost/accept.txt

@@ -12,6 +12,7 @@ ASan
 Attio
 Autofix
 autofix
+autouse
 Backfilling
 backfilling
 backport
@@ -25,6 +26,8 @@ bestpractices
 bmad
 bookended
 Camunda
+chdir
+chdirs
 CI's
 CLIs
 Codecov
@@ -36,6 +39,7 @@ CPython
 CRM
 cron
 crontab
+cwd
 cyclomatic
 dedupe
 deduped
@@ -103,6 +107,7 @@ mtime
 mtimes
 mutmut
 mypy
+nodeid
 nonces
 npm
 onboards

{boost_skill_cli-1.2.145 → boost_skill_cli-1.2.147}/CLAUDE.md

@@ -34,6 +34,50 @@ The functional/unit `sandbox` fixture (`tests/conftest.py`) also sets
 block on a confirm prompt or a real AI call — override explicitly in a test
 that means to exercise the AI or confirmation path.
 
+**`sandbox` also chdirs into `tmp_path/"cwd"`**, because the working directory
+is the one input *project* scope resolves against: `scopes.resolve_base` walks
+up from `os.getcwd()` looking for a `.git`, so a test installing with
+`scope="project"` and no explicit `base=` used to write `.boost/skill-lock.json`
+plus a full five-agent fan-out into the developer's own checkout — all of it
+gitignored, so `git status` never said a word, and the next full run read the
+leftover lock back and failed a dozen tests that assert an empty install state.
+The sandbox cwd is a *sibling* of the fake `$HOME`, never `$HOME` itself
+(`scopes.project_root` refuses to call `$HOME` a project, which would make
+`resolve_base` return `None` and change what every project-scope test means),
+and it carries no `.git`: **a test that needs a real project root plants its own
+marker and chdirs into it.** The backstop is the autouse `_repo_root_guard`
+fixture, which snapshot-diffs the project-scope paths under the checkout *and*
+under the directory pytest started in, and fails the offending test by nodeid.
+Two details there are load-bearing. **The checkout is found by walking up for a
+VCS marker, never from `__file__`**: mutmut copies `tests/` into `mutants/` and
+runs the suite from there, so under the mutation gate — the one run the guard
+exists for — `Path(__file__).parent.parent` *is* `mutants/`, it coincides with
+the start directory, and a derivation from either watches only `mutants/` while
+`scopes.resolve_base` puts the escaped install at the real repo root. That walk
+**stops at `$HOME`**, where `scopes.project_root` stops: a dotfiles `~/.git` is
+common, no scope-resolved writer can put a project install at `$HOME`, and
+without the stop the guard fingerprints the live `~/.claude`, `~/.codex` and
+`~/.boost` trees — so a `boost install` in another terminal fails whichever
+test happened to be running. And a
+watched **directory** is fingerprinted by its immediate entries with each
+file's size and `mtime_ns`, not by name alone, or replacing a slash command the
+developer wrote by hand leaves the listing identical; a watched **file** by
+content, except an agent **context file** (`CLAUDE.local.md`, `GEMINI.md`,
+`AGENTS.md`), which is prose a human also edits and is fingerprinted by its
+`<!-- boost:rule:… -->` marker lines alone — a whole-file hash turns a teammate
+appending a line during a tens-of-minutes `make check` into a flake in a
+required gate. The probe list is derived
+from the live agent table over `config.DEFAULTS["agents"]`, plus
+`rules.CONTEXT_FILES` and `hookhost.hosts()`, so a new write target is covered
+by adding it to those tables, not to the guard — and it reads that config
+defensively, because an autouse fixture that can raise is a setup error on
+every test in the suite rather than one failure. The standing exception is
+`store.project_mcp_sidecar` (`<repo>/.mcp.json`), which no table names because
+`register_project_mcp` joins it straight onto the base; it is probed by name,
+and it is the one project-scope artifact that is committable, so a report that
+omitted it would have the developer clean up everything the guard named and
+commit one file anyway.
+
 ## The one gate that matters
 
 Before calling any change done, run the full gate:

{boost_skill_cli-1.2.145 → boost_skill_cli-1.2.147}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.145
+Version: 1.2.147
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.145 → boost_skill_cli-1.2.147}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.2.145'
-__version_tuple__ = version_tuple = (1, 2, 145)
+__version__ = version = '1.2.147'
+__version_tuple__ = version_tuple = (1, 2, 147)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.145 → boost_skill_cli-1.2.147}/boost_skill_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.145
+Version: 1.2.147
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.145 → boost_skill_cli-1.2.147}/boost_skill_cli.egg-info/SOURCES.txt

@@ -673,9 +673,11 @@ docs/roadmap/items/taps-check-out-freight-they-never-index.md
 docs/roadmap/items/taps-vouches-for-a-clone-that-is-not-there.md
 docs/roadmap/items/the-catalogue-advertised-repos-that-no-longer-exist.md
 docs/roadmap/items/the-install-path-hands-agy-claudes-mcp-argv.md
+docs/roadmap/items/the-links-concurrency-cap-did-not-hold.md
 docs/roadmap/items/the-model-back-off-mixes-two-clocks.md
 docs/roadmap/items/the-scale-corpus-refreshed-the-wrong-rows.md
 docs/roadmap/items/the-shard-job-that-could-not-finish.md
+docs/roadmap/items/the-windows-test-cap-is-five-minutes-from-the-measurement.md
 docs/roadmap/items/theme-asset-linting-stylelint-eslint.md
 docs/roadmap/items/tier3-ceiling-unreachable-at-default-n.md
 docs/roadmap/items/tool-call-eval-tier.md
@@ -844,6 +846,7 @@ tests/functional/test_keyed_no_store_hint.py
 tests/functional/test_kind_conformance.py
 tests/functional/test_property_parsers.py
 tests/functional/test_recommend_because_is_true.py
+tests/functional/test_repo_root_guard_covers_real_installs.py
 tests/functional/test_reports_match_reality.py
 tests/functional/test_run.py
 tests/functional/test_tap_signing.py
@@ -1046,6 +1049,7 @@ tests/unit/test_registry_control_chars.py
 tests/unit/test_registry_parallel.py
 tests/unit/test_release_guard.py
 tests/unit/test_release_preflight.py
+tests/unit/test_repo_root_guard.py
 tests/unit/test_report.py
 tests/unit/test_required_checks.py
 tests/unit/test_rerank_cache.py
@@ -1053,6 +1057,7 @@ tests/unit/test_resolve.py
 tests/unit/test_retrieve_any_near_duplicates.py
 tests/unit/test_roadmap_fresh.py
 tests/unit/test_rules.py
+tests/unit/test_sandbox_fixture_cwd.py
 tests/unit/test_scale_corpus.py
 tests/unit/test_schedule_plist.py
 tests/unit/test_scopes.py

{boost_skill_cli-1.2.145 → boost_skill_cli-1.2.147}/docs/roadmap/items/sandbox-fixture-does-not-sandbox-the-working-directory.md

@@ -2,14 +2,14 @@
 id: sandbox-fixture-does-not-sandbox-the-working-directory
 board: code
 section: internals
-status: planned
+status: inflight
 category: Test hygiene · Bug
 complexity: M
 impact: Medium
 wow: 2
 order: 347
-owner: ""
-pr: ""
+owner: loop/sandbox-cwd
+pr: "982"
 title: The sandbox fixture sandboxes every env var except the one project scope reads
 note: `make check` leaves a project install in the repo root; a later run reads it back and fails twelve unrelated tests.
 ---

boost_skill_cli-1.2.147/docs/roadmap/items/the-links-concurrency-cap-did-not-hold.md

@@ -0,0 +1,41 @@
+---
+id: the-links-concurrency-cap-did-not-hold
+board: code
+section: internals
+status: shipped
+owner: loop/links-remap
+pr: "984"
+category: CI · Flake
+complexity: S
+impact: Medium
+wow: 3
+order: 351
+title: Capping the burst did not stop the 503s — the whole fetch was signal-free
+note: 474 requests to one host, and --accept already takes 403, so the only verdict the live fetch could give that a file check cannot is 404.
+---
+<b>The previous fix did not hold.</b>
+<code>links-job-503s-its-own-write-up-links</code> (#966) capped lychee at
+<code>--max-concurrency 8</code> on the theory that the burst was the whole problem. Run
+<code>36393345706</code>, the push that landed #981 on <code>main</code>, still lost <b>8</b>
+write-up URLs to <code>[503] Service Unavailable</code> under that cap. Every roadmap item
+regenerates <code>docs/roadmap.html</code>, so every merge out of the roadmap loop rolled the
+dice again: the loop's own output was reddening <code>main</code>.
+<br><br>
+<b>The right question was what the fetch proves, not how fast it runs.</b> The boards emit a
+<code>blob/main/docs/roadmap/items/&lt;id&gt;.md</code> link per settled card — <b>474</b> of
+the 483 <code>github.com</code> links in the docs. That URL is derived mechanically from a path
+in the very commit being checked, and <code>--accept</code> already takes <code>403</code>, so
+a live fetch cannot even tell an inaccessible repo from a reachable one. <b>404 is the only
+verdict it discriminates</b>, and the <code>file://</code> check the pull-request path already
+used gives that one identically. The guard was paying 474 requests at one host for no signal.
+<br><br>
+<b>Fixed by making the remap unconditional.</b> Dropping
+<code>github.event_name == 'pull_request' &amp;&amp;</code> takes the docs from 483 same-host
+fetches to 9 on every event. A write-up URL that does <i>not</i> match the prefix — a card
+pointing into the wrong directory — is still fetched for real, so a typo outside the remap is
+caught as before, and one inside it fails as <code>File not found</code>.
+<code>503</code> stays out of <code>--accept</code>: accepting it was always the cheap non-fix,
+and <code>test_a_503_is_still_a_failure</code> still says so. The test that pinned the old rule
+is inverted, and a new one asserts what actually replaced the burst — that <b>every</b>
+write-up link both boards emit matches the remap pattern, since a cap only makes a burst
+slower whereas a remap removes it.

boost_skill_cli-1.2.147/docs/roadmap/items/the-windows-test-cap-is-five-minutes-from-the-measurement.md

@@ -0,0 +1,87 @@
+---
+id: the-windows-test-cap-is-five-minutes-from-the-measurement
+board: code
+section: internals
+status: shipped
+owner: loop/windows-test-timeout
+pr: "986"
+category: CI · Flake
+complexity: S
+impact: Medium
+wow: 2
+order: 352
+title: One 30-minute cap for nine matrix cells, and only Windows is anywhere near it
+note: Two windows-3.14 jobs were killed at 30.4 and 30.3 min in one morning — both while pytest was still printing results, and the second one blocked a release.
+---
+<b>Found by watching the train release land, then again on main 82 minutes
+later.</b> Every check on <code>release/train-2026-09-28</code> was green except
+<code>tests (windows-latest, 3.14)</code>, which came back <code>cancelled</code>
+after 30.4 minutes (run <code>36399947619</code>, job <code>108855169521</code>).
+The log distinguishes a slow job from a wedged one, and this was slow: pytest's
+last complete progress row lands at <code>09:22:22.18</code> at <code>99%</code>,
+a partial row of eleven more results at <code>09:22:29.19</code>, and
+<code>##[error]The operation was canceled</code> at <code>09:22:29.24</code>.
+Eleven tests finished in the final seven seconds — the suite was still moving when
+the cap fired.
+<br><br>
+<b>Then the merge commit did it again.</b> Run <code>36408455593</code> on
+<code>008c5d41</code>, job <code>108882688603</code>: same cell, cancelled at 30.3
+minutes, last full row <code>99%</code> at <code>10:43:27.71</code>, thirty-three
+more results at <code>10:44:06.94</code>, cancelled 46 ms later. Two independent
+samples, same shape, both still at work — and because <code>publish.yml</code>
+triggers on <code>workflow_run</code> of a <i>completed, successful</i>
+<code>ci</code>, the second one held the release back until the job was re-run by
+hand. That is the cost of the flake stated precisely: not a red square, a blocked
+publish.
+<br><br>
+<b>One cap, three very different machines.</b> The <code>tests</code> job sets
+<code>timeout-minutes: 30</code> for all nine matrix cells. Over the last 40
+<code>ci</code> runs (every attempt, not just the latest), the successful jobs
+measure:
+<br><br>
+<code>ubuntu&nbsp;3.14&nbsp;4.0&nbsp;min · ubuntu&nbsp;3.13&nbsp;5.4 ·
+ubuntu&nbsp;3.12&nbsp;5.8 · macos&nbsp;3.14&nbsp;7.4 · macos&nbsp;3.13&nbsp;7.5 ·
+macos&nbsp;3.12&nbsp;8.8 · windows&nbsp;3.12&nbsp;19.3 ·
+windows&nbsp;3.14&nbsp;19.4 · windows&nbsp;3.13&nbsp;20.7</code> (medians)
+<br><br>
+A median is the wrong number to size a timeout against, though, so the cap has to
+be read against the <i>slowest run of each OS that still passed</i>: ubuntu 7.9,
+macOS 10.3, Windows 24.6. That is 22.1 minutes of headroom for Linux, 19.7 for
+macOS — and 5.4 for Windows. A Windows runner 1.25x slower than the worst one yet
+measured is a red required check on a tree that is fine, which is exactly what
+happened twice: 2 timeouts in 36 completed windows-3.14 attempts, both today.
+(The other cancellations in that sample are concurrency-group cancels — none ran
+longer than 13 minutes.)
+<br><br>
+<b>Fixed by giving Windows its own cap</b>, not by widening all nine:
+<code>timeout-minutes: ${{ startsWith(matrix.os, 'windows') &amp;&amp; 45 || 30 }}</code>.
+45 is 1.8x the slowest Windows run that ever <i>passed</i> (24.6 min) and about
+1.5x the two that were killed, and the six Linux/macOS cells keep the
+tight cap that is the point of having one — a genuinely hung Linux job still dies
+in 30 minutes rather than 45. It is <code>startsWith</code> rather than
+<code>== 'windows-latest'</code> because the condition and the <code>os:</code>
+list are otherwise related only by spelling: pin that list to a dated label such
+as <code>windows-2025</code> and the equality matches nothing, handing all nine
+cells 30 again without failing anything.
+<br><br>
+<b>The gate that should have caught the value did not read it.</b>
+<code>test_workflow_timeouts</code> caps every job's <code>timeout-minutes</code>
+at 90 via <code>^&nbsp;&nbsp;&nbsp;&nbsp;timeout-minutes: (\d+)\s*$</code> — four
+spaces of indent and a line that ends at the digits, so it skips any line it
+cannot match, and the repo's single cap over the bound
+(<code>shards.yml</code>/<code>build</code>, 330, with a trailing comment) was the
+one the bound never saw. It now parses the branch operands of the expression form
+structurally, refuses aloud any shape it was not taught, and evaluates the
+condition against the job's real <code>os:</code> list, so a cap that has stopped
+applying to any cell fails the test instead of passing it.
+<br><br>
+Two sibling holes closed with it. The companion
+<code>test_every_job_declares_a_timeout</code> asked only whether the string
+<code>timeout-minutes:</code> appeared anywhere in the job — which a
+<i>step</i>-level cap satisfies at eight spaces of indent, so a job with no
+job-level cap at all passed both guards. Both now ask the same question. And the
+carve-out for an expression with no digits in it (<code>${{ inputs.cap }}</code>,
+whose number genuinely lives elsewhere) was wide enough to swallow
+<code>${{ cond &amp;&amp; vars.WIN_CAP || vars.CAP }}</code> — digit-free, but a
+two-branch decision this file can see the shape of. It is now narrowed to a bare
+context reference, and anything else raises.

{boost_skill_cli-1.2.145 → boost_skill_cli-1.2.147}/docs/roadmap.html

@@ -143,7 +143,7 @@
       <div class="stat"><b>20</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>80</b><span>Planned</span></div>
-      <div class="stat"><b>502</b><span>Loop finds</span></div>
+      <div class="stat"><b>504</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -3352,7 +3352,7 @@ instead of on a user's machine.</p>
       </article>
 
       <article class="cap rcard" id="sandbox-fixture-does-not-sandbox-the-working-directory">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Test hygiene · Bug</span></div>
+        <div class="head"><span class="pill inflight">In flight</span><span class="cat">Test hygiene · Bug</span></div>
         <h3>The sandbox fixture sandboxes every env var except the one project scope reads</h3>
         <p>`tests/conftest.py`'s `sandbox` fixture is thorough about the environment — it
 redirects `HOME`, clears `BOOST_HOME`, `BOOST_AGENTS_STORE` and `CODEX_HOME`,
@@ -3420,6 +3420,30 @@ Two halves, both cheap:
           <span class="m">Three attempts of one run failed on three disjoint sets of URLs, every one of which returns 200 on its own.</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="the-links-concurrency-cap-did-not-hold">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CI · Flake</span></div>
+        <h3>Capping the burst did not stop the 503s — the whole fetch was signal-free</h3>
+        <p class="cardbody"><a class="writeup" href="https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items/the-links-concurrency-cap-did-not-hold.md">Write-up &middot; the-links-concurrency-cap-did-not-hold.md</a></p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Medium</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">474 requests to one host, and --accept already takes 403, so the only verdict the live fetch could give that a file check cannot is 404.</span>
+        </div>
+      </article>
+
+      <article class="cap rcard" id="the-windows-test-cap-is-five-minutes-from-the-measurement">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CI · Flake</span></div>
+        <h3>One 30-minute cap for nine matrix cells, and only Windows is anywhere near it</h3>
+        <p class="cardbody"><a class="writeup" href="https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items/the-windows-test-cap-is-five-minutes-from-the-measurement.md">Write-up &middot; the-windows-test-cap-is-five-minutes-from-the-measurement.md</a></p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Medium</b></span>
+          <span class="m">Wow <b class="wow">★★</b></span>
+          <span class="m">Two windows-3.14 jobs were killed at 30.4 and 30.3 min in one morning — both while pytest was still printing results, and the second one blocked a release.</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>