boost-skill-cli 1.2.128__tar.gz → 1.2.130__tar.gz

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/CONTRIBUTING.md

@@ -120,8 +120,8 @@ list, and neither should be added to it.
 |---|---|
 | `make test` | unit + functional suites, **≥90% coverage** (statements + branches) |
 | `make patch-coverage` | changed-line coverage vs `main`, **≥80% of the diff** (PRs) |
-| `bash tests/smoke.sh` | 170 end-to-end checks through the real `./boost` shim |
-| `make bdd` | the Gherkin suite — 11 features, 47 scenarios (needs the `[bdd]` extra) |
+| `bash tests/smoke.sh` | 183 end-to-end checks through the real `./boost` shim |
+| `make bdd` | the Gherkin suite — 11 features, 56 scenarios (needs the `[bdd]` extra) |
 | `make mutation` | mutmut over `boost_cli/core`, **≥80% mutants killed** |
 | `ruff check boost_cli tests` | lint, zero findings |
 | `mypy` | type check, zero errors |

{boost_skill_cli-1.2.128/boost_skill_cli.egg-info → boost_skill_cli-1.2.130}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.128
+Version: 1.2.130
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0
@@ -564,7 +564,7 @@ Four test layers are enforced, and `make check` runs all of them:
 | Layer | Gate |
 |---|---|
 | `make test` | ≥90% coverage of `boost_cli`, statements and branches |
-| `make smoke` | 176 checks through the actual `./boost` shim |
+| `make smoke` | 183 checks through the actual `./boost` shim |
 | `make mutation` | ≥80% of ~9,900 mutants in `boost_cli/core` killed |
 | `make evals` | metric floors on the search ranker, plus no significant regression |
 

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/README.md

@@ -522,7 +522,7 @@ Four test layers are enforced, and `make check` runs all of them:
 | Layer | Gate |
 |---|---|
 | `make test` | ≥90% coverage of `boost_cli`, statements and branches |
-| `make smoke` | 176 checks through the actual `./boost` shim |
+| `make smoke` | 183 checks through the actual `./boost` shim |
 | `make mutation` | ≥80% of ~9,900 mutants in `boost_cli/core` killed |
 | `make evals` | metric floors on the search ranker, plus no significant regression |
 

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/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.128'
-__version_tuple__ = version_tuple = (1, 2, 128)
+__version__ = version = '1.2.130'
+__version_tuple__ = version_tuple = (1, 2, 130)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/boost_cli/commands/discovery.py

@@ -1151,13 +1151,17 @@ def cmd_recommend(argv):
     if used_curated_fallback:
         out.info("no stack-specific matches — curated picks instead:")
     width = min(max(len(r["entry"]["name"]) for r in shown), 32)
-    cols = out.term_width()
-    for r in shown:
+    reasons = ["because: %s" % ", ".join(sorted(r["because"])) for r in shown]
+    # One description width for every row, from the widest reason. Sized per
+    # row from that row's own `because:` tag, the clip point swung 20 columns
+    # between rows (34-54 at COLUMNS=100) and neither column lined up.
+    desc_w = max(out.term_width() - 2 - width - 2
+                 - (max(map(len, reasons)) + 2), 8)
+    for r, because in zip(shown, reasons, strict=True):
         e = r["entry"]
-        because = "because: %s" % ", ".join(sorted(r["because"]))
-        desc_w = max(cols - 2 - width - 2 - (len(because) + 2), 8)
         name_cell = out.role(out.truncate(e["name"], width).ljust(width), "accent")
-        out.info(name_cell + "  " + out.truncate(e["description"] or "", desc_w)
+        desc = out.truncate(e["description"] or "", desc_w)
+        out.info(name_cell + "  " + desc + " " * (desc_w - out.visible_len(desc))
                  + "  " + out.role(because, "muted"))
     if ai.available():
         picks = _ai_picks(stack, [r["entry"] for r in ranked[:20]])

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130/boost_skill_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.128
+Version: 1.2.130
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0
@@ -564,7 +564,7 @@ Four test layers are enforced, and `make check` runs all of them:
 | Layer | Gate |
 |---|---|
 | `make test` | ≥90% coverage of `boost_cli`, statements and branches |
-| `make smoke` | 176 checks through the actual `./boost` shim |
+| `make smoke` | 183 checks through the actual `./boost` shim |
 | `make mutation` | ≥80% of ~9,900 mutants in `boost_cli/core` killed |
 | `make evals` | metric floors on the search ranker, plus no significant regression |
 

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/docs/design-roadmap.html

@@ -203,7 +203,7 @@
         </div>
         <div>
           <dt>Constraints</dt>
-          <dd>Every proposal stays <code>zero-dependency</code>, degrades on <code>NO_COLOR</code> / non-TTY, and targets <code>Python ≥ 3.9</code>.</dd>
+          <dd>Every proposal stays <code>zero-dependency</code>, degrades on <code>NO_COLOR</code> / non-TTY, and targets <code>Python ≥ 3.12</code>.</dd>
         </div>
       </dl>
     </div>
@@ -579,7 +579,7 @@ hidden hot-path cost hiding behind the one this card measured.</p>
 <footer>
   <div class="wrap">
     <p class="foot-brand"><b>boost</b> — a package manager for AI skills</p>
-    <p class="foot-note">Install with <code>pip install boost-skill-cli</code> · requires Python 3.9+ and <code>git</code></p>
+    <p class="foot-note">Install with <code>pip install boost-skill-cli</code> · requires Python 3.12+ and <code>git</code></p>
     <nav class="foot-links" aria-label="Documentation">
       <a href="index.html">Guide</a>
       <a href="commands.html">Commands</a>

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/docs/openssf-badge.md

@@ -120,7 +120,7 @@ Package: [`boost-skill-cli`](https://pypi.org/project/boost-skill-cli/)
 
 | Criterion | Cat. | Answer | Evidence |
 |---|---|---|---|
-| `test` | MUST | **Met** | Four tiers: `tests/unit`, `tests/functional` (drive the real CLI in-process), `tests/smoke.sh` (170 end-to-end checks through the `./boost` shim) and a Gherkin BDD suite (11 features, 47 scenarios). |
+| `test` | MUST | **Met** | Four tiers: `tests/unit`, `tests/functional` (drive the real CLI in-process), `tests/smoke.sh` (183 end-to-end checks through the `./boost` shim) and a Gherkin BDD suite (11 features, 56 scenarios). |
 | `test_invocation` | SHOULD | **Met** | `make test` — or `nox`, which reproduces the exact CI gate in isolated venvs across every supported interpreter. |
 | `test_most` | SUGGESTED | **Met** | A **90% coverage** gate over statements and branches (`fail_under = 90`), an **80% changed-line** gate on pull requests, and an **80% mutation** gate over `boost_cli/core` — the last of which means coverage cannot be satisfied by tests that merely execute the code without asserting on it. |
 | `test_continuous_integration` | SUGGESTED | **Met** | GitHub Actions runs the full gate on every push and every pull request. |
@@ -204,7 +204,7 @@ of the security-design document for the full account.
 
 | Criterion | Cat. | Answer | Evidence |
 |---|---|---|---|
-| `dynamic_analysis` | SUGGESTED | **Met** | [`fuzz.yml`](https://github.com/jonnyeclectic/boost/blob/main/.github/workflows/fuzz.yml) runs `atheris` (libFuzzer for Python) against the parsers over a target matrix, uploading any crashing input as an artifact. Beyond fuzzing, `tests/smoke.sh` drives the real binary end to end through 170 checks, and the functional suite executes the CLI against a throwaway `$HOME`. |
+| `dynamic_analysis` | SUGGESTED | **Met** | [`fuzz.yml`](https://github.com/jonnyeclectic/boost/blob/main/.github/workflows/fuzz.yml) runs `atheris` (libFuzzer for Python) against the parsers over a target matrix, uploading any crashing input as an artifact. Beyond fuzzing, `tests/smoke.sh` drives the real binary end to end through 183 checks, and the functional suite executes the CLI against a throwaway `$HOME`. |
 | `dynamic_analysis_unsafe` | SUGGESTED | **N/A** | Python is memory-safe; there is no buffer overflow or use-after-free class for a tool like ASan or Valgrind to find. The runtime has no C extension (the optional `[rag]` extra is not on the install path). |
 | `dynamic_analysis_enable_assertions` | SUGGESTED | **Met** | The test suites are assertion-driven and run with assertions enabled (no `-O`), and `pytest` promotes `DeprecationWarning` raised inside `boost_cli` to a hard error, so a latent deprecation fails a run rather than scrolling past. |
 | `dynamic_analysis_fixed` | MUST | **Met** | No medium-or-higher exploitable vulnerability has been found by dynamic analysis. A crashing input found by the fuzzer is uploaded as a workflow artifact and fixed; none is outstanding. |

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/docs/roadmap/items/audit-root-findings.md

@@ -2,15 +2,15 @@
 id: audit-root-findings
 board: code
 section: dx
-status: planned
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: Low
 wow: 1
 note: EPIPE exits 120 with stderr noise; `help version` suggests verify; launcher gates at 3.9
 order: 245
-owner:
-pr:
+owner: loop/audit-root-closed
+pr: 827
 title: "boost ROOT: CLI audit findings (2026-08)"
 ---
 <b>EPIPE leaks past main's own handler.</b> <code>boost --help | (exec 0&lt;&amp;-; sleep 0.3)</code>
@@ -45,3 +45,13 @@ fixes touches a COMMANDS row, so <code>docs/commands.html</code> is unaffected.
 
 <br><br>Found by the 2026-08 CLI audit (clusters <code>broken-pipe-exit</code>,
 <code>help-routing-aliases</code>, <code>launcher-python-floor</code>); repro in the audit log.
+
+<br><br><b>Shipped in #827</b> (commit <code>22c9193</code>, batch train-17, 2026-09-08). The card
+was never closed. Re-measured on <code>main</code> at <code>bb1229f</code> on 2026-09-18:
+<code>--help</code>, <code>count</code>, <code>taps</code> and <code>--version</code> piped into
+<code>(exec 0&lt;&amp;-; sleep 0.3)</code> exit 0 with empty stderr, 3/3 runs each (<code>_seal_broken_stdout</code>
+plus <code>_route</code>'s <code>finally</code> flush).
+<code>boost help --help</code>, <code>help version</code> and <code>help help</code> all resolve;
+<code>boost --hepl</code> says <em>&ldquo;unknown option&rdquo;</em>, and <code>print_help</code> carries the Options line.
+The launcher gates at <code>(3, 12)</code>, pinned to <code>requires-python</code> by
+<code>tests/unit/test_launcher_python_floor.py</code>.

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/docs/roadmap/items/recommend-recomputes-its-columns-per-row.md

@@ -2,15 +2,15 @@
 id: recommend-recomputes-its-columns-per-row
 board: code
 section: planned
-status: planned
+status: shipped
 category: UX · Bug
 complexity: S
 impact: Low
 wow: 2
 note: cmd_recommend hand-rolls its rows and computes desc_w = max(cols - 2 - width - 2 - (l…
 order: 226
-owner:
-pr:
+owner: loop/recommend-columns
+pr: 881
 title: <code>boost recommend</code> sizes the description cell per row from that row's <code>because:</code> text, so neither column lines up
 ---
 <b>Measured.</b> At COLUMNS=100 the eight <code>boost recommend</code> rows truncate their descriptions at eight per-row widths spanning 34 to 54 columns — a 20-column swing, the widest cell 59% wider than the narrowest — because <code>desc_w</code> is recomputed inside the row loop from that row's own <code>because:</code> tag length (<code>boost_cli/commands/discovery.py:1062</code>); every rendered cell matched the predicted <code>desc_w</code> to the character and every description ended in an ellipsis, so this is column geometry, not natural description length.

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/docs/roadmap/items/roadmap-boards-advertise-python-39.md

@@ -2,15 +2,15 @@
 id: roadmap-boards-advertise-python-39
 board: code
 section: planned
-status: planned
+status: shipped
 category: Quality · Docs
 complexity: S
 impact: Low
 wow: 2
 note: docs/roadmap.html:17141 and docs/design-roadmap.html:582 both close with Install with…
 order: 228
-owner:
-pr:
+owner: loop/boards-python-floor
+pr: 878
 title: The two roadmap boards' install footers still advertise Python 3.9+, four minor versions under the real floor
 ---
 <b>Measured.</b> On stock macOS <code>python3</code> (3.9.6), the exact command in both roadmap footers succeeds silently and installs the wrong software: <code>pip download --no-deps boost-skill-cli</code> exits 0 with no Requires-Python notice and selects boost_skill_cli-1.0.392, because 390 of 557 published releases still declare <code>requires_python: &gt;=3.9</code> — 167 releases behind the current 1.2.103.

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/docs/roadmap/items/stale-gate-sizes-in-readme-and-contributing.md

@@ -2,15 +2,15 @@
 id: stale-gate-sizes-in-readme-and-contributing
 board: code
 section: planned
-status: planned
+status: shipped
 category: Quality · Docs
 complexity: S
 impact: Low
 wow: 2
 note: README.md:515 says make smoke is "176 checks" and CONTRIBUTING.md:123 says bash tests…
 order: 235
-owner:
-pr:
+owner: loop/gate-sizes
+pr: 879
 title: The contributor-onboarding gate tables state three wrong suite sizes, and README and CONTRIBUTING disagree with each other
 ---
 <b>Measured.</b> One command (<code>make smoke</code> is literally <code>bash tests/smoke.sh</code>, Makefile:48-49) is documented as three different sizes in three files — 176 in README.md:515, 170 in CONTRIBUTING.md:123 and 170 again in docs/openssf-badge.md:123 — while it actually runs 183 checks, a figure that is deterministic and statically derivable as 102 top-level <code>run</code> lines plus 81 <code>--help</code> entries in the CMDS heredoc.

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/docs/roadmap.html

@@ -2103,41 +2103,9 @@ Nothing else needed correcting: 7 starter registries, 962 items, 11 matches, the
       </article>
 
       <article class="cap rcard" id="recommend-recomputes-its-columns-per-row">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">UX · Bug</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">UX · Bug</span></div>
         <h3><code>boost recommend</code> sizes the description cell per row from that row's <code>because:</code> text, so neither column lines up</h3>
-        <p><b>Measured.</b> At COLUMNS=100 the eight <code>boost recommend</code> rows truncate their descriptions at eight per-row widths spanning 34 to 54 columns — a 20-column swing, the widest cell 59% wider than the narrowest — because <code>desc_w</code> is recomputed inside the row loop from that row's own <code>because:</code> tag length (<code>boost_cli/commands/discovery.py:1062</code>); every rendered cell matched the predicted <code>desc_w</code> to the character and every description ended in an ellipsis, so this is column geometry, not natural description length.
-
-<b>Reproduce it.</b>
-
-<code>cd &lt;repo&gt;</code><br>
-<code>export HOME=$TMPDIR/audit-dbi-sweep; mkdir -p "$HOME"; export BOOST_HOME=$TMPDIR/eval-home BOOST_NO_AI=1</code><br>
-<code>COLUMNS=100 ./boost recommend &gt; $TMPDIR/rec.txt 2&gt;&amp;1; cat $TMPDIR/rec.txt</code><br>
-<code>python3 - &lt;&lt;'PY'</code><br>
-<code>import re,os</code><br>
-<code>for line in open(os.environ["TMPDIR"]+"/rec.txt").read().splitlines()[1:]:</code><br>
-<code>    m=re.match(r"^  (\S+)\s+(.*?)\s\sbecause: (.*)$", line)</code><br>
-<code>    if m: print("desc_cell=%3d because_len=%2d row_len=%d %s"%(len(m.group(2)),len("because: "+m.group(3)),len(line),m.group(1)))</code><br>
-<code>PY</code><br>
-<code>sed -n '1061,1065p' boost_cli/commands/discovery.py</code><br>
-<code>sed -n '638,644p' boost_cli/core/output.py</code>
-
-<b>What adversarial verification corrected.</b> This card's numbers are the re-measured ones, not the ones first reported.
-
-The geometry numbers are all CORRECT — I re-derived every one (cells 46/38/46/42/54/34/46/54, because-lengths 19/27/19/23/11/31/19/11, spread 34..54 = 20 columns, row_len 100 on all 8 rows). Four wording/detail claims are wrong and must not ship as written:
-
-1. FALSE AS STATED: "<code>recommend</code> is also the one result table in the find group that does not go through the width-aware shared <code>out.table()</code>." <code>cmd_search</code> does not call <code>out.table()</code> either — it calls <code>out.search_layout()</code> at <code>boost_cli/commands/discovery.py:219</code> and renders through <code>SearchLayout</code>. <code>out.table()</code> in the find group is called by <code>cmd_index</code> (:857), <code>cmd_discover</code> (:954), <code>_browse_plain</code> (:1091, used by <code>browse</code>) and <code>cmd_trending</code> (:1925, :1949). The correct claim: <b><code>recommend</code> is the only find-group result renderer that uses neither <code>out.table()</code> nor a frozen <code>SearchLayout</code>.</b>
-
-2. TITLE OVERSTATES: "so neither column lines up" — and the evidence line "row_len 100 on all 8 — every row is right-flush, nothing is a column" contradicts itself. The <code>because:</code> column's RIGHT edge IS flush (col 100 at COLUMNS=100, col 120 at COLUMNS=120, on all 8 rows). What wanders is (a) the <code>because:</code> column's LEFT edge, 69..89, and (b) the description truncation point, 34..54.
-
-<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
-
-PROVENANCE (I checked; it partly softens the framing and the card should say so). <code>git blame</code> puts line 1062 in ff61dfeb, "fix(search): width-clamp &amp; truncate results — the D05 overflow fix (#33)", whose message states the intent: "clip each description to the remaining terminal width, so every result stays one scannable line <b>with its trailing tag (★ curated / because:) intact</b>." So preserving the trailing tag was deliberate; the per-row recompute is what that intent produced. The defect is drift, not carelessness: <code>search</code> was later rewritten onto the frozen <code>SearchLayout</code> (7f1a9a8d, "feat(ui): one design system across search and browse", #540) whose docstring states the opposite rule, and <code>recommend</code> was left on the 2026-07 scheme. Neither commit message nor any comment claims right-alignment of the reason tag as a design goal for <code>recommend</code>, so nothing in the tree defends the current shape — but a card that calls it an oversight without naming #33's stated intent is overclaiming.
-
-SCOPE OF MY REPRO. Measured only from the boost repo (detected stack: javascript, python · frameworks: pytest · also: ci) against the shared read-only 20-tap eval corpus at $TMPDIR/eval-home, with BOOST_NO_AI=1 (which suppresses the "AI picks" block — unrelated to the geometry). Which eight rows appear, and therefore the exact cell widths, depend on that corpus and that stack; the geometry itself is deterministic from :1062 and appears whenever the shown rows carry different <code>because:</code> sets.
-
-<b>Why it is worth doing.</b> <code>recommend</code> is the surface a new user hits before they know any skill names, and its output is a ragged block rather than a scannable list — the description truncation point jumps 20 columns row to row for reasons the reader cannot see (it is the length of the reason tag on the right). Two shipped design items (BOOST-D08, BOOST-D24) made <code>out.table()</code> width-aware for ~28 call sites; this one never adopted it, and the frozen-plan rule that <code>search</code> states in its own docstring is inverted here.
-
-<em>Found by an automated audit of retrieval/eval quality, the search &amp; browse surfaces, and first-run onboarding; every finding was then re-measured from scratch by an independent adversarial verifier whose instruction was to refute it. Verdict: <b>CORRECTED</b>. No fix is prescribed here — the measurement is the contribution.</em></p>
+        <p class="cardbody"><a class="writeup" href="https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items/recommend-recomputes-its-columns-per-row.md">Write-up &middot; recommend-recomputes-its-columns-per-row.md</a></p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Low</b></span>
@@ -2197,40 +2165,9 @@ BLAST RADIUS — do not overstate it in the card. The natural set is NOT wired i
       </article>
 
       <article class="cap rcard" id="roadmap-boards-advertise-python-39">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Quality · Docs</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Quality · Docs</span></div>
         <h3>The two roadmap boards' install footers still advertise Python 3.9+, four minor versions under the real floor</h3>
-        <p><b>Measured.</b> On stock macOS <code>python3</code> (3.9.6), the exact command in both roadmap footers succeeds silently and installs the wrong software: <code>pip download --no-deps boost-skill-cli</code> exits 0 with no Requires-Python notice and selects boost_skill_cli-1.0.392, because 390 of 557 published releases still declare <code>requires_python: &gt;=3.9</code> — 167 releases behind the current 1.2.103.
-
-<b>Reproduce it.</b>
-
-<code>cd &lt;repo&gt;</code><br>
-<code>for f in docs/*.html; do printf '%-22s %s\n' "$(basename $f)" "$(grep -m1 -n 'foot-note' $f)"; done | grep -o 'Python 3\.[0-9]*+' | sort | uniq -c</code><br>
-<code>grep -n 'requires Python 3.9' docs/roadmap.html docs/design-roadmap.html</code><br>
-<code>sed -n '206p' docs/design-roadmap.html</code><br>
-<code>grep -n 'requires-python' pyproject.toml</code><br>
-<code>.venv/bin/python scripts/build_roadmap.py --check ; echo "EXIT=$?"   # green despite the drift</code>
-
-<b>What adversarial verification corrected.</b> This card's numbers are the re-measured ones, not the ones first reported.
-
-The documented defect (<code>claim</code> + <code>evidence</code>) reproduces byte-for-byte — every file, line number and count is right: 9 of 11 footers say 3.12+, roadmap.html:17141 and design-roadmap.html:582 say 3.9+, design-roadmap.html:206 says "targets Python ≥ 3.9", pyproject.toml:22 is &gt;=3.12, README.md:54 says 3.12+, and <code>build_roadmap.py --check</code> exits 0. The correction is confined entirely to <code>why_it_matters</code>, which is wrong three times:
-
-1. WRONG: "the launcher on that interpreter dies with a SyntaxError out of core/workflows.py's match statements." The <code>./boost</code> launcher no longer gates at 3.9 — <code>grep -n '3\.9' boost</code> returns nothing (exit 1), and boost:5, boost:27 and boost:37 all say 3.12. Observed on a PATH holding only Python 3.9.6, the launcher prints <code>boost: Python 3.12+ is required but was not found on PATH / hint: brew install python3</code>. It never selects the 3.9 interpreter.
-
-2. WRONG even if the gate is bypassed: importing the package on 3.9 does not raise SyntaxError from <code>core/workflows.py</code>'s match statements. It raises <code>ImportError: cannot import name 'UTC' from 'datetime'</code> at <code>boost_cli/core/util.py:15</code>, which fires before workflows.py is reached.
-
-3. WRONG about the failure being visible at all. The footer's advertised path is <code>pip install boost-skill-cli</code>, not the launcher.
-
-<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
-
-SCOPE OF MY REPRO: everything above was measured on this checkout at the session's HEAD (main, 9b70fc8e) and against live PyPI. No eval corpus or BOOST_HOME was involved — this is a static docs/metadata finding, so the 20-tap corpus caveat does not apply. I did not run a real <code>pip install</code> (only <code>pip download</code>, which exercises the same resolver and version selection without mutating anything).
-
-NOT CARDED — confirmed independently. I grepped all roadmap item titles, then every item body containing <code>3.9</code> (21 files) and every item body containing <code>footer</code>/<code>foot-note</code> (16 files). None names the docs/*.html install footers or their Python version. Three near misses, all genuinely distinct: - <code>audit-root-findings.md</code> covers the *launcher's* three 3.9 sites and explicitly closes "README already says 3.12+ — no doc change needed"; it never mentions a docs page. - <code>python-floor-moves-to-312.md</code> enumerates pyproject, the CI matrix and telemetry; no docs page. - <code>promote-nav-footer-into-the-shared-style-system.md</code> is about nav/footer *presence and styling*, not their text.
-
-TRAP FOR THE CARD AUTHOR — do not re-import the SyntaxError claim. The finder took it from <code>docs/roadmap/items/audit-root-findings.md:36-43</code>, which is still <code>status: planned</code> but whose premise is already fixed on disk: that card says the launcher "still gates at Python 3.9" at boost:5/:27/:37, and all three now say 3.12. Anyone who reads that card while writing this one will copy a consequence that no longer happens.
-
-<b>Why it is worth doing.</b> Both boards are linked from the README ("Roadmap" section, README.md:490-494) and from the Visual Guide nav, so they are landing surfaces a reader can arrive on first. Their footer is the only install instruction on the page, and it tells the reader a Python 3.9 will do. It will not: stock macOS <code>python3</code> IS 3.9, and the launcher on that interpreter dies with a SyntaxError out of core/workflows.py's match statements. The design board's "targets Python ≥ 3.9" also mis-sets the floor for anyone writing a proposal against it.
-
-<em>Found by an automated audit of retrieval/eval quality, the search &amp; browse surfaces, and first-run onboarding; every finding was then re-measured from scratch by an independent adversarial verifier whose instruction was to refute it. Verdict: <b>CORRECTED</b>. No fix is prescribed here — the measurement is the contribution.</em></p>
+        <p class="cardbody"><a class="writeup" href="https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items/roadmap-boards-advertise-python-39.md">Write-up &middot; roadmap-boards-advertise-python-39.md</a></p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Low</b></span>
@@ -2482,32 +2419,9 @@ NOT ALREADY CARDED — I re-checked independently. The PR 739 card (<code>audit-
       </article>
 
       <article class="cap rcard" id="stale-gate-sizes-in-readme-and-contributing">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Quality · Docs</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Quality · Docs</span></div>
         <h3>The contributor-onboarding gate tables state three wrong suite sizes, and README and CONTRIBUTING disagree with each other</h3>
-        <p><b>Measured.</b> One command (<code>make smoke</code> is literally <code>bash tests/smoke.sh</code>, Makefile:48-49) is documented as three different sizes in three files — 176 in README.md:515, 170 in CONTRIBUTING.md:123 and 170 again in docs/openssf-badge.md:123 — while it actually runs 183 checks, a figure that is deterministic and statically derivable as 102 top-level <code>run</code> lines plus 81 <code>--help</code> entries in the CMDS heredoc.
-
-<b>Reproduce it.</b>
-
-<code>cd &lt;repo&gt;</code><br>
-<code>sed -n '48,49p' Makefile          # make smoke == bash tests/smoke.sh</code><br>
-<code>bash tests/smoke.sh 2&gt;&amp;1 | tail -1 # == results: 183 passed, 0 failed</code><br>
-<code>sed -n '515p' README.md            # "176 checks"</code><br>
-<code>sed -n '123,124p' CONTRIBUTING.md  # "170 end-to-end checks" ; "11 features, 47 scenarios"</code><br>
-<code>HOME=$TMPDIR/audit-bdd BOOST_HOME=$TMPDIR/audit-bdd/.boost .venv/bin/behave tests/bdd/features --dry-run 2&gt;&amp;1 | tail -2</code>
-
-<b>Verification found nothing to correct.</b> Every number, <code>file:line</code> and command output above was independently re-derived and matched exactly.
-
-<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
-
-1. THE FINDING UNDERCOUNTS THE BLAST RADIUS. It names two files; there are three. <code>docs/openssf-badge.md:123</code> carries both stale numbers ("170 end-to-end checks" and "11 features, 47 scenarios") in the row that answers the OpenSSF <code>test</code> MUST criterion. That makes five stale statements across three files, not three across two. The finder's not_carded_check grepped roadmap bodies but never grepped <code>docs/</code>, which is how it missed this. A card that fixes only README and CONTRIBUTING leaves a stale count in the file that argues boost's test coverage to an external badge audit.
-
-2. TWO ARE DRIFT, ONE WAS WRONG ON DAY ONE — do not write the card as uniform "drift". Re-deriving the count at each blame commit: README's 176 was CORRECT at 3aaf4ba4 (2026-08-28, PR #579) and has since drifted to 183; CONTRIBUTING's 170 was CORRECT at c043bb3f (2026-07-24, PR #233) and was never touched again; CONTRIBUTING's "47 scenarios" was CORRECT at 17bd5003 (2026-07-28, PR #292). But docs/openssf-badge.md's 170 was WRONG WHEN IT WAS WRITTEN — at 560652b1 (2026-08-28, PR #563) the suite already ran 176. It copied CONTRIBUTING's already-stale number rather than measuring. That is the sharper story: the count is not just drifting, it is being propagated by copy from whichever file the author happened to read, which is exactly the failure mode the finding's "no way to tell which is authoritative" line predicts.
-
-3. 183 IS DETERMINISTIC — a card author must not "correct" it.
-
-<b>Why it is worth doing.</b> These two tables are the contributor's map of what <code>make check</code> will do to their PR, and a first-time contributor reads whichever file they landed on. Seeing 183 where the doc promised 176 (or 170) is a signal the gate changed under them; worse, the two files disagree, so there is no way to tell which is authoritative without running the suite. The BDD row is the same failure in a suite that is not even in <code>make check</code>, where a wrong size is the only signal a contributor has that scenarios were added.
-
-<em>Found by an automated audit of retrieval/eval quality, the search &amp; browse surfaces, and first-run onboarding; every finding was then re-measured from scratch by an independent adversarial verifier whose instruction was to refute it. Verdict: <b>CONFIRMED</b>. No fix is prescribed here — the measurement is the contribution.</em></p>
+        <p class="cardbody"><a class="writeup" href="https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items/stale-gate-sizes-in-readme-and-contributing.md">Write-up &middot; stale-gate-sizes-in-readme-and-contributing.md</a></p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Low</b></span>
@@ -6393,40 +6307,9 @@ untouched (no parser changes). Found by the 2026-08 CLI audit (cluster stale-pro
       </article>
 
       <article class="cap rcard" id="audit-root-findings">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">CLI · Bug</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CLI · Bug</span></div>
         <h3>boost ROOT: CLI audit findings (2026-08)</h3>
-        <p><b>EPIPE leaks past main's own handler.</b> <code>boost --help | (exec 0&lt;&amp;-; sleep 0.3)</code>
-exits <b>120</b> with <em>&ldquo;Exception ignored on flushing sys.stdout: BrokenPipeError&rdquo;</em>
-&mdash; 3/3 runs, and <code>count</code>, <code>taps</code> and <code>--version</code> leak the same way.
-<code>cli.py:327-331</code> deliberately catches BrokenPipeError and returns 0, but stdout is never
-flushed inside the try, so any output that fits the stdio buffer raises at interpreter exit &mdash; and
-the <code>--help</code>/<code>--version</code> early returns (<code>cli.py:292-302</code>) sit before
-the try with no handler at all. Fix: cover the early returns, flush <code>sys.stdout</code> inside the
-try, and <code>os.dup2</code> a devnull fd over stdout in the handler so the exit flush cannot raise.
-
-<br><br><b>Help routing rejects main's own aliases.</b> <code>boost help --help</code> &rarr;
-<em>&ldquo;unknown command: --help / hint: did you mean: heal?&rdquo;</em> exit 2;
-<code>boost help version</code> suggests <em>verify</em> while <code>boost version</code> works;
-even <code>boost help help</code> fails. The aliases live only in <code>cli.main</code>
-(<code>cli.py:292-302</code>) and <code>print_command_help</code> resolves against COMMANDS alone,
-then difflib-guesses any token &mdash; dash-prefixed ones included. And <code>boost --help</code>
-documents none of the working global flags (<code>-V</code>/<code>-v</code>/<code>--debug</code>/<code>-q</code>).
-Fix: short-circuit the aliases in <code>print_command_help</code> before difflib, say
-<em>unknown option</em> for dash tokens in <code>_unknown</code> (<code>cli.py:231-236</code>), and add
-one dim Options line under Usage in <code>print_help</code>.
-
-<br><br><b>The <code>./boost</code> launcher still gates at Python 3.9</b> &mdash; tuple
-(<code>boost:27</code>), hint text (<code>boost:37</code>) and header comment (<code>boost:5</code>) all
-say 3.9+ while <code>pyproject.toml:22</code> requires <code>&gt;=3.12</code>. On a stock macOS whose
-only <code>python3</code> is 3.9 the launcher selects it and the user gets a SyntaxError from
-<code>core/workflows.py</code>'s match statements instead of the friendly hint. The shipped
-<em>python-floor-moves-to-312</em> item enumerated every floor touchpoint and missed this one. Fix:
-bump all three sites to 3.12 and add a unit test pinning the launcher's floor to
-<code>requires-python</code>. README already says 3.12+ &mdash; no doc change needed; none of the three
-fixes touches a COMMANDS row, so <code>docs/commands.html</code> is unaffected.
-
-<br><br>Found by the 2026-08 CLI audit (clusters <code>broken-pipe-exit</code>,
-<code>help-routing-aliases</code>, <code>launcher-python-floor</code>); repro in the audit log.</p>
+        <p class="cardbody"><a class="writeup" href="https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items/audit-root-findings.md">Write-up &middot; audit-root-findings.md</a></p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Low</b></span>
@@ -8404,7 +8287,7 @@ regressed. Lowering the floor alone just relocates the coin flip.</p>
 <footer>
   <div class="wrap">
     <p class="foot-brand"><b>boost</b> — a package manager for AI skills</p>
-    <p class="foot-note">Install with <code>pip install boost-skill-cli</code> · requires Python 3.9+ and <code>git</code></p>
+    <p class="foot-note">Install with <code>pip install boost-skill-cli</code> · requires Python 3.12+ and <code>git</code></p>
     <nav class="foot-links" aria-label="Documentation">
       <a href="index.html">Guide</a>
       <a href="commands.html">Commands</a>

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/tests/functional/test_cli_discovery.py

@@ -1131,6 +1131,19 @@ class TestRecommend:
         assert "because: pytest, python" in r.out
         assert "because: javascript, react" in r.out
 
+    @pytest.mark.parametrize("cols", ["60", "100"])
+    def test_rows_share_one_column_plan(self, boost, stack_tap, react_project,
+                                        monkeypatch, cols):
+        # The description width used to be sized per row from that row's own
+        # `because:` tag, so the clip point swung row to row and the reason
+        # column started wherever each description happened to end.
+        monkeypatch.setenv("COLUMNS", cols)
+        r = boost("recommend", "--path", react_project)
+        rows = [ln for ln in r.out.splitlines() if "because: " in ln]
+        reasons = {ln.split("because: ")[1] for ln in rows}
+        assert len(rows) >= 2 and len({len(x) for x in reasons}) >= 2, rows
+        assert len({ln.index("because: ") for ln in rows}) == 1, rows
+
     def test_json_purity(self, boost, stack_tap, react_project):
         r = boost("recommend", "--path", react_project, "--json")
         data = json.loads(r.out)

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/tests/unit/test_launcher_python_floor.py

@@ -46,3 +46,35 @@ class TestLauncherPythonFloor:
         major, minor = _requires_python_floor()
         text = LAUNCHER.read_text(encoding="utf-8")
         assert "Python %d.%d+ is required" % (major, minor) in text
+
+
+class TestDocsPythonFloor:
+    """The docs' own install lines must name the same floor.
+
+    Nine of the eleven docs pages' footers moved to 3.12 with the floor; the
+    two roadmap boards' footers — hand-authored outside the regions
+    `build_roadmap.py` regenerates, so `--check` stayed green — kept saying
+    3.9, as did the design board's "targets Python ≥ 3.9". Stock macOS
+    `python3` is 3.9, so that is the reader the stale floor misleads.
+    """
+
+    def test_every_footer_names_requires_python(self):
+        major, minor = _requires_python_floor()
+        pages = sorted((ROOT / "docs").glob("*.html"))
+        footers = {page.name: [ln.strip() for ln in
+                               page.read_text(encoding="utf-8").splitlines()
+                               if 'class="foot-note"' in ln]
+                   for page in pages}
+        # One footer per page, found by its class alone — so a page that
+        # loses its footer, or rewords it away from "requires Python", fails
+        # here rather than dropping out of the scan.
+        assert pages and all(len(f) == 1 for f in footers.values()), footers
+        stale = {name: f[0] for name, f in footers.items()
+                 if "requires Python %d.%d+" % (major, minor) not in f[0]}
+        assert not stale, stale
+
+    def test_design_board_targets_the_same_floor(self):
+        major, minor = _requires_python_floor()
+        text = (ROOT / "docs" / "design-roadmap.html").read_text(encoding="utf-8")
+        assert re.findall(r"targets <code>Python ≥ (\d+\.\d+)</code>", text) \
+            == ["%d.%d" % (major, minor)]

{boost_skill_cli-1.2.128 → boost_skill_cli-1.2.130}/tests/unit/test_marketing_counts.py

@@ -100,6 +100,49 @@ class TestCommandCount:
 # test whose formula is a guess is worse than no test.
 
 
+class TestSuiteSizesAgree:
+    """The smoke and BDD sizes the docs state.
+
+    They had drifted three ways at once: README said 176 smoke checks,
+    CONTRIBUTING and the OpenSSF badge answer 170, the suite ran 183, and the
+    badge's 170 was already wrong on the day it was copied in. Per the note
+    above, the smoke count is not derived from smoke.sh's shape; what IS
+    checkable without a formula is that the docs agree with each other, so a
+    reader never has to guess which file is right. The BDD size is
+    declarative (one `Scenario:` per scenario), so it is checked outright.
+    """
+
+    DOCS = ("README.md", "CONTRIBUTING.md", "docs/openssf-badge.md")
+
+    def _read(self, doc):
+        return (ROOT / doc).read_text(encoding="utf-8")
+
+    def test_every_doc_states_the_same_smoke_size(self):
+        sizes = {}
+        for doc in self.DOCS:
+            for line in self._read(doc).splitlines():
+                if "smoke" in line:
+                    for n in re.findall(r"(\d+) (?:end-to-end )?checks", line):
+                        sizes.setdefault(int(n), []).append(doc)
+        # Every statement, not just every doc: the badge answer states it twice.
+        assert sorted(d for docs in sizes.values() for d in docs) == sorted(
+            ["README.md", "CONTRIBUTING.md"] + ["docs/openssf-badge.md"] * 2)
+        assert len(sizes) == 1, "docs disagree on the smoke size: %s" % sizes
+
+    def test_bdd_size_matches_the_feature_files(self):
+        features = sorted((ROOT / "tests" / "bdd" / "features").glob("*.feature"))
+        texts = [f.read_text(encoding="utf-8") for f in features]
+        # An outline expands to one scenario per Examples row, and `Example:`
+        # is Gherkin's synonym for `Scenario:`; this count models neither, so
+        # refuse rather than undercount.
+        assert not any(re.search(r"^\s*(Scenario Outline|Example):", t, re.M)
+                       for t in texts)
+        scenarios = sum(len(re.findall(r"^\s*Scenario:", t, re.M)) for t in texts)
+        stated = [(int(f), int(s)) for doc in self.DOCS for f, s in
+                  re.findall(r"(\d+) features, (\d+) scenarios", self._read(doc))]
+        assert stated and set(stated) == {(len(features), scenarios)}, stated
+
+
 class TestNoStaleCountsElsewhere:
     @pytest.mark.parametrize("doc", ["README.md", "docs/index.html"])
     def test_no_command_count_is_a_stale_literal(self, doc):