boost-skill-cli 1.2.129__tar.gz → 1.2.131__tar.gz

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/CLAUDE.md

@@ -293,10 +293,10 @@ line coverage. Target `boost_cli/core` behavior with assertions, not just import
   adding to the vale list.** Every `.py`/`.sh` under `boost_cli`,
   `boost_langchain`, `evals`, `scripts`, `tests` plus `./boost` and
   `noxfile.py` opens with `# Copyright the boost contributors.` and
-  `# SPDX-License-Identifier: GPL-3.0-only`. Run
+  `# SPDX-License-Identifier: Apache-2.0`. Run
   `python3 scripts/add_spdx_headers.py` (idempotent) — the file list and the
-  expression live there, so changing `-only` to `-or-later` is one edit rather
-  than 314. Separately, `prose-lint.yml` names the Markdown files vale checks
+  expression live there, so changing the licence expression is one edit rather
+  than hundreds. Separately, `prose-lint.yml` names the Markdown files vale checks
   **explicitly**: a new doc that is not added to that list is never linted, and
   `make lint` will not tell you.
 
@@ -517,7 +517,7 @@ each agent's skills dir, and updating the lock file.
 
 - **The shard matrix is packed, not sliced, and 256 is a hard ceiling.**
   GitHub runs at most 256 matrix jobs per workflow, so `shards.yml` cannot take
-  one job per registry once the scope is the 463-registry catalogue — the run
+  one job per registry once the scope is the ~460-registry catalogue — the run
   fails before a job starts. `scripts/shard_plan.py` bin-packs by the measured
   `est_items` (longest-processing-time-first), which matters because cost is
   uneven: the largest catalogued registry is 880 items against a median of 30,

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/CONTRIBUTING.md

@@ -191,7 +191,7 @@ form linked there, never a public issue.
   tests that actually kill your mutants.
 - **Every source file opens with a two-line header** —
   `# Copyright the boost contributors.` then
-  `# SPDX-License-Identifier: GPL-3.0-only`, below any shebang.
+  `# SPDX-License-Identifier: Apache-2.0`, below any shebang.
   `python3 scripts/add_spdx_headers.py` stamps whatever is missing and is safe
   to re-run; `tests/unit/test_spdx_headers.py` fails the build for a new file
   without one.

{boost_skill_cli-1.2.129/boost_skill_cli.egg-info → boost_skill_cli-1.2.131}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.129
+Version: 1.2.131
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0
@@ -190,8 +190,9 @@ those vectors. Embedding is ~1.2 s/chunk on CPU — hours for a real corpus —
 and importing the same rows takes 0.12 s, so the difference between the two is
 the difference between semantic search being available and being reachable.
 
-Want everything? `boost quickstart --catalog` taps all 463 catalogued
-registries — 2 min 10 s now that clones run in parallel — and fetches vectors
+Want everything? `boost quickstart --catalog` taps every catalogued
+registry — measured at 2 min 10 s for 463 of them, now that clones run in
+parallel — and fetches vectors
 for every one that has a published shard.
 
 Already tapped? `boost reindex --fetch-shards` does the download half alone,

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/README.md

@@ -148,8 +148,9 @@ those vectors. Embedding is ~1.2 s/chunk on CPU — hours for a real corpus —
 and importing the same rows takes 0.12 s, so the difference between the two is
 the difference between semantic search being available and being reachable.
 
-Want everything? `boost quickstart --catalog` taps all 463 catalogued
-registries — 2 min 10 s now that clones run in parallel — and fetches vectors
+Want everything? `boost quickstart --catalog` taps every catalogued
+registry — measured at 2 min 10 s for 463 of them, now that clones run in
+parallel — and fetches vectors
 for every one that has a published shard.
 
 Already tapped? `boost reindex --fetch-shards` does the download half alone,

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/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.129'
-__version_tuple__ = version_tuple = (1, 2, 129)
+__version__ = version = '1.2.131'
+__version_tuple__ = version_tuple = (1, 2, 131)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/boost_cli/commands/discovery.py

@@ -256,7 +256,12 @@ def cmd_search(argv):
     else:
         footer = ("%d match%s · ranked by %s"
                   % (len(scored), "" if len(scored) == 1 else "es", ranker))
-    out.info(out.role(footer, "muted"))
+    # Chrome, so fitted like the rows `search_layout` just fitted above it —
+    # the same wrap-then-colour as `_hint_semantic_search`. Emitted whole it
+    # measured 55 columns in a 40-column pane (the cap branch), and the
+    # pane-width gate only passed because its fixture returned one match.
+    for line in out.wrap(footer, max(out.term_width() - 2, 20)):
+        out.info(out.role(line, "muted"))
     if use_rag:
         _note_stem_expansions(query)
         _note_dropped_terms(dropped)
@@ -1151,13 +1156,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.129 → boost_skill_cli-1.2.131}/boost_cli/commands/quickstart.py

@@ -36,9 +36,9 @@ def _selection(catalog_scope: bool) -> list[dict]:
     """The registries quickstart will tap: the seven defaults, or all of them.
 
     `--catalog` exists because "search everything" is a real ask and the two
-    costs that used to make it unreasonable are gone: tapping 463 registries is
-    2 min 10 s now that clones run in parallel, and their vectors are a
-    download rather than an hour of CPU.
+    costs that used to make it unreasonable are gone: tapping the whole
+    catalogue measured 2 min 10 s (463 registries) once clones ran in
+    parallel, and their vectors are a download rather than an hour of CPU.
     """
     if not catalog_scope:
         return [d.copy() for d in config.DEFAULT_TAPS]
@@ -62,7 +62,7 @@ def _tap_defaults(selection: list[dict], pins: dict[str, dict],
     if dry_run:
         existing = {t.name for t in registry.list_taps()}
         pending = [n for n in names if n not in existing]
-        # Over 463 registries a line each is a wall of text, so past a handful
+        # Over the whole catalogue a line each is a wall of text, so past a handful
         # the dry run reports the shape instead of the list.
         if len(pending) > 12:
             out.info("would tap %d registries (%d pinned to a published "

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131/boost_skill_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.129
+Version: 1.2.131
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0
@@ -190,8 +190,9 @@ those vectors. Embedding is ~1.2 s/chunk on CPU — hours for a real corpus —
 and importing the same rows takes 0.12 s, so the difference between the two is
 the difference between semantic search being available and being reachable.
 
-Want everything? `boost quickstart --catalog` taps all 463 catalogued
-registries — 2 min 10 s now that clones run in parallel — and fetches vectors
+Want everything? `boost quickstart --catalog` taps every catalogued
+registry — measured at 2 min 10 s for 463 of them, now that clones run in
+parallel — and fetches vectors
 for every one that has a published shard.
 
 Already tapped? `boost reindex --fetch-shards` does the download half alone,

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/docs/index.html

@@ -658,7 +658,7 @@ facilitate structured divergent thinking:
           <div class="node src">
             <span class="tag">Source</span>
             <h3>GitHub registries</h3>
-            <p>7 pre-tapped registries + a 10,000-skill discovery index</p>
+            <p>7 pre-tapped registries + live GitHub discovery</p>
           </div>
         </div>
         <div class="flow-arrow reveal">
@@ -874,8 +874,8 @@ facilitate structured divergent thinking:
       <p class="sec-sub">Boost ships pre-tapped to seven curated registries covering all three
         item kinds — skills, rules and workflows — and <code>boost mcp</code> taps them for you
         on a machine that has none. Beyond that,
-        the curated catalog spans 100+ registries and <code>boost discover</code> indexes
-        10,000+ skills across GitHub. Tap your own team’s repo anytime.</p>
+        the curated catalog spans 100+ registries and <code>boost discover</code> searches
+        GitHub live for skill repositories you have not tapped. Tap your own team’s repo anytime.</p>
 
       <div class="reg-wrap reveal">
         <div class="reg-scroll">
@@ -937,7 +937,7 @@ facilitate structured divergent thinking:
         </div>
       </div>
       <p class="reg-note">Item counts (skills + rules + workflows) measured from the live repositories ·
-        build the GitHub-wide index with <code>boost index</code>, browse it with <code>boost discover</code></p>
+        <code>boost discover &lt;query&gt;</code> searches GitHub live; <code>boost index</code> builds the offline index that bare <code>discover</code> and <code>--local</code> browse</p>
     </div>
   </section>
 
@@ -1009,7 +1009,7 @@ pipx inject boost-skill-cli <span class="yv">"boost-skill-cli[rag]"</span>
         <a href="#commands"><span class="name"><span class="v">boost</span> install brainstorming</span><p>Install into every agent</p></a>
         <a href="#commands"><span class="name"><span class="v">boost</span> recommend</span><p>Suggestions for your stack</p></a>
         <a href="#commands"><span class="name"><span class="v">boost</span> browse</span><p>Interactive TUI explorer</p></a>
-        <a href="#commands"><span class="name"><span class="v">boost</span> discover</span><p>Browse 10,000+ skills</p></a>
+        <a href="#commands"><span class="name"><span class="v">boost</span> discover</span><p>Find untapped skills on GitHub</p></a>
         <a href="#commands"><span class="name"><span class="v">boost</span> doctor</span><p>Health check &amp; repair hints</p></a>
       </div>
     </div>

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/docs/openssf-badge.md

@@ -241,8 +241,8 @@ that sets response headers) and three are a recruiting problem.
 
 | Criterion | Cat. | Answer | Evidence |
 |---|---|---|---|
-| `copyright_per_file` | MUST | **Met** | Every source file opens with `# Copyright the boost contributors.` — 314 files across `boost_cli/`, `boost_langchain/`, `evals/`, `scripts/`, `tests/` and the two root files. [`scripts/add_spdx_headers.py`](https://github.com/jonnyeclectic/boost/blob/main/scripts/add_spdx_headers.py) stamps them idempotently and `tests/unit/test_spdx_headers.py` fails the build if a new file arrives without one. |
-| `license_per_file` | MUST | **Met** | The next line of every one of those files is `# SPDX-License-Identifier: GPL-3.0-only`. `-only` rather than `-or-later` because nothing in the repository grants "or any later version"; a test asserts that LICENSE still contains no such grant, so the expression cannot quietly become wrong. |
+| `copyright_per_file` | MUST | **Met** | Every source file opens with `# Copyright the boost contributors.` — every `.py`/`.sh` file across `boost_cli/`, `boost_langchain/`, `evals/`, `scripts/`, `tests/` and the two root files. [`scripts/add_spdx_headers.py`](https://github.com/jonnyeclectic/boost/blob/main/scripts/add_spdx_headers.py) stamps them idempotently and `tests/unit/test_spdx_headers.py` fails the build if a new file arrives without one. |
+| `license_per_file` | MUST | **Met** | The next line of every one of those files is `# SPDX-License-Identifier: Apache-2.0`, the licence LICENSE carries. `tests/unit/test_spdx_headers.py` fails the build on a file missing either line, and a second test pins CLAUDE.md's contributor rule to the same expression. |
 | `repo_distributed` | MUST | **Met** | git. |
 | `small_tasks` | SHOULD | **Met** | [CONTRIBUTING.md § Good first tasks](https://github.com/jonnyeclectic/boost/blob/main/CONTRIBUTING.md#good-first-tasks) names five standing starter tasks, each with the exact file to edit — adding a registry row, adding a retrieval golden-set query, teaching the prose linter a word, sharpening a command summary, covering an untested branch. They are standing tasks on purpose: a newcomer can start without waiting for an issue to be triaged. Specific one-off tasks carry the `good first issue` label. |
 

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/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.129 → boost_skill_cli-1.2.131}/docs/roadmap/items/audit-stale-prose-after-shipped-changes-catalog-export-live-discov.md

@@ -2,15 +2,15 @@
 id: audit-stale-prose-after-shipped-changes-catalog-export-live-discov
 board: code
 section: dx
-status: planned
+status: shipped
 category: Docs · Drift
 complexity: S
 impact: Low
 wow: 1
 note: a documented command that exits 2, 463 vs 464 in eight places, a GPL rule over Apache files
 order: 244
-owner:
-pr:
+owner: loop/stale-prose
+pr: 883
 title: "Stale prose after shipped changes: <code>catalog --export</code>, live discover, 464 count, Apache-2.0"
 ---
 Four patches of prose describe the repo as it was before a shipped change, each verified against the current

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/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.129 → boost_skill_cli-1.2.131}/docs/roadmap/items/search-footer-not-fitted-to-the-pane-its-rows-were-fitted-to.md

@@ -2,15 +2,15 @@
 id: search-footer-not-fitted-to-the-pane-its-rows-were-fitted-to
 board: code
 section: planned
-status: planned
+status: shipped
 category: UX · Bug
 complexity: S
 impact: Low
 wow: 2
 note: search_layout's docstring guarantees every row measures within cols, and at COLUMNS=4…
 order: 231
-owner:
-pr:
+owner: loop/search-footer-fit
+pr: 884
 title: The search footer is the one unfitted line on a screen <code>search_layout</code> just fitted: 55 columns in a 40-column pane
 ---
 <b>Measured.</b> The same command measures 55 columns in a 40-column pane in the field and 39 in the test that asserts it fits: <code>tests/functional/test_cli_pane_width.py::TestChromeOnlyCommandsFitAnyPane::test_search[40]</code> passes only because its fixture tap yields exactly one match, whose footer is <code>1 match · ranked by full-content BM25</code> = 39 — one column under the pane.

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/docs/roadmap/items/search-footer-overflows-40-col-pane-gate-passes-by-luck.md

@@ -2,15 +2,15 @@
 id: search-footer-overflows-40-col-pane-gate-passes-by-luck
 board: code
 section: planned
-status: planned
+status: shipped
 category: UX · Bug
 complexity: M
 impact: Med
 wow: 3
 note: tests/functional/test_cli_pane_width.py asserts _widest(r.out) <= cols for boost sear…
 order: 232
-owner:
-pr:
+owner: loop/search-footer-fit
+pr: 884
 title: <code>boost search</code>'s footer overflows a 40-column pane by 2-15 cells, and the gate that swears it doesn't passes only because its fixture returns exactly one match
 ---
 <b>Measured.</b> On the gate's <b>own</b> 5-item fixture at COLUMNS=40, changing the query from <code>brainstorming</code> to <code>workflow</code> — nothing else — takes <code>_widest(r.out)</code> from 40 (passes) to 41 (fails), because the footer goes from <code>1 match · ranked by full-content BM25</code> (39 cells) to <code>2 matches · ranked by full-content BM25</code> (41 cells): the gate's green is a property of the singular noun, not of the code. On the 20-tap corpus the same footer measures 55 cells at COLUMNS=40 (over by 15) via the <code>hit_cap</code> branch.

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/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>
@@ -2253,46 +2221,9 @@ MITIGATIONS (why Med and not High): every failure path recovers in one command.
       </article>
 
       <article class="cap rcard" id="search-footer-not-fitted-to-the-pane-its-rows-were-fitted-to">
-        <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>The search footer is the one unfitted line on a screen <code>search_layout</code> just fitted: 55 columns in a 40-column pane</h3>
-        <p><b>Measured.</b> The same command measures 55 columns in a 40-column pane in the field and 39 in the test that asserts it fits: <code>tests/functional/test_cli_pane_width.py::TestChromeOnlyCommandsFitAnyPane::test_search[40]</code> passes only because its fixture tap yields exactly one match, whose footer is <code>1 match · ranked by full-content BM25</code> = 39 — one column under the pane.
-
-<b>Reproduce it.</b>
-
-<code>cd &lt;repo&gt;</code><br>
-<code>export BOOST_HOME=$TMPDIR/eval-home</code><br>
-<code>COLUMNS=40 ./boost search "code review" 2&gt;&amp;1 | python3 -c "</code><br>
-<code>import sys,re,unicodedata</code><br>
-<code>A=re.compile(r'\033\[[0-9;]*m')</code><br>
-<code>def vl(s):</code><br>
-<code>    s=A.sub('',s); return sum(0 if unicodedata.combining(c) else (2 if unicodedata.east_asian_width(c) in ('W','F') else 1) for c in s)</code><br>
-<code>for i,l in enumerate(sys.stdin.read().splitlines()):</code><br>
-<code>    if vl(l)&gt;40: print('OVERFLOW line%d %d&gt;40: %r' % (i, vl(l), l))</code><br>
-<code>"</code>
-
-<b>What adversarial verification corrected.</b> This card's numbers are the re-measured ones, not the ones first reported.
-
-Three citation errors; all measured numbers are right.
-
-1. The footer emit is <code>boost_cli/commands/discovery.py:238</code>, not 239. 2. The <code>search_layout</code> docstring sentence is <code>boost_cli/core/output.py:665-667</code> (the whole docstring runs 653-668), not 680-682. Lines 680-682 are <code>desc_room()</code>'s body and the <code>tap_w</code> drop test. 3. "thirty lines later in the same module" is wrong: 238 -&gt; 258 is 20 lines. The finding's own <code>why_it_matters</code> already says "20 lines away", so the evidence contradicts itself.
-
-Not a correction but a scope fact the finding did not state: the *other* footer branch also overflows. At COLUMNS=40 with BM25 the widths are 39 (1 match, fits) / 41 (3) / 42 (35 matches, measured) / 55 (cap branch, measured) — i.e. the overflow is 1-15 cells, zero at exactly one match. The smart path pushes it further ("ranked by Claude Haiku relevance" = 59).
-
-<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
-
-Scope of my repro: the 20-tap eval corpus at $TMPDIR/eval-home for the field measurement, plus the real <code>tests/make_fixture.py</code> tap in a disposable HOME for the gate fixture. No network, no writes to the shared corpus. The defect is in the emit site, not the corpus — any query returning &gt;1 match reproduces it.
-
-Four things a card author must not get wrong:
-
-1. <b><code>search_layout</code> does not violate its own docstring.</b> Its guarantee is over "every row assembled from the plan"; the footer is not a row assembled from the plan. The title's contrast is rhetorical and true as *juxtaposition* (the fitted rows sit directly above an unfitted line), but a card must not say "search_layout breaks its own guarantee." The law the footer *does* break is the repo's own, stated in <code>tests/functional/test_cli_pane_width.py</code>'s module docstring: "Commands whose whole output boost composed — <code>search</code>, <code>who</code>, <code>protocol</code> — are swept at panes down to 40 columns. Every line is chrome, so every line is boost's to fit."
-
-2. <b>"The one unfitted line" holds only for a screen with results.</b> On the zero-result screen a different line overflows and <code>search_layout</code> never runs: <code>COLUMNS=40 ./boost search zzzqqxnothing</code> emits <code> → try \</code>boost discover zzzqqxnothing\<code> to search all of GitHub</code> at 62 columns. Fixing the footer does not make <code>boost search</code> pane-clean, and a card claiming it does will be wrong the first time someone types a miss.
-
-3.
-
-<b>Why it is worth doing.</b> The footer is chrome (a count and a ranker name), so the wrap law permits fitting it — nothing on that line is data the user must copy. Leaving it unfitted means the one screen boost spent a whole frozen <code>SearchLayout</code> dataclass fitting still wraps on a narrow pane, and it wraps on the summary line, breaking the visual bottom edge of the result block. The fix is one call already used 20 lines away in the same file.
-
-<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/search-footer-not-fitted-to-the-pane-its-rows-were-fitted-to.md">Write-up &middot; search-footer-not-fitted-to-the-pane-its-rows-were-fitted-to.md</a></p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Low</b></span>
@@ -2302,47 +2233,9 @@ Four things a card author must not get wrong:
       </article>
 
       <article class="cap rcard" id="search-footer-overflows-40-col-pane-gate-passes-by-luck">
-        <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 search</code>'s footer overflows a 40-column pane by 2-15 cells, and the gate that swears it doesn't passes only because its fixture returns exactly one match</h3>
-        <p><b>Measured.</b> On the gate's <b>own</b> 5-item fixture at COLUMNS=40, changing the query from <code>brainstorming</code> to <code>workflow</code> — nothing else — takes <code>_widest(r.out)</code> from 40 (passes) to 41 (fails), because the footer goes from <code>1 match · ranked by full-content BM25</code> (39 cells) to <code>2 matches · ranked by full-content BM25</code> (41 cells): the gate's green is a property of the singular noun, not of the code. On the 20-tap corpus the same footer measures 55 cells at COLUMNS=40 (over by 15) via the <code>hit_cap</code> branch.
-
-<b>Reproduce it.</b>
-
-<code>cd &lt;repo&gt;</code><br>
-<code>export BOOST_HOME=$TMPDIR/eval-home</code><br>
-<code>.venv/bin/python - &lt;&lt;'PY'</code><br>
-<code>import os,subprocess,sys</code><br>
-<code>sys.path.insert(0,".")</code><br>
-<code>from boost_cli.core import output</code><br>
-<code>for C in (40,48,60,80,120):</code><br>
-<code>    env=dict(os.environ); env["COLUMNS"]=str(C)</code><br>
-<code>    r=subprocess.run(["./boost","search","code","review"],capture_output=True,text=True,env=env)</code><br>
-<code>    lines=r.stdout.splitlines()</code><br>
-<code>    w=max((output.visible_len(l) for l in lines),default=0)</code><br>
-<code>    print("COLUMNS=%-4d widest=%-4d %s" % (C,w,"OVER by %d"%(w-C) if w&gt;C else "ok"))</code><br>
-<code>    for l in lines:</code><br>
-<code>        if output.visible_len(l)&gt;C: print("      %3d | %s" % (output.visible_len(l), l))</code><br>
-<code>for q in (["quarkus"],["minio"]):</code><br>
-<code>    env=dict(os.environ); env["COLUMNS"]="40"</code><br>
-…
-
-<b>What adversarial verification corrected.</b> This card's numbers are the re-measured ones, not the ones first reported.
-
-Three of the finding's file:line refs are stale against current HEAD (9b70fc8e). A card author copying them lands in the wrong place:
-
-1. <code>hit_cap = len(hits) &gt;= k</code> is at <b>discovery.py:161</b>, not 157. 2. <code>k = max(60, args.limit * 4)</code> is at <b>discovery.py:153</b>, not 150. 3. <code>out.info(out.role(footer, "muted"))</code> is at <b>discovery.py:238</b>, not 239. (<code>discovery.py:234-237</code> for the footer assembly IS correct — 234 is the cap branch, 236-237 the plain branch.) 4. The test-file docstring quote is at <b>test_cli_pane_width.py:15-17</b>, not 14-17 (line 14 is blank).
-
-5. "Every other count on any corpus overflows" is over-scoped. The 8-cell count budget (40 - 2 indent - 3 separator - 27 for "ranked by full-content BM25") is specific to the <b>key-free BM25 label</b>. <code>rag.py:1282-1287</code> ships two other labels and the envelope moves in BOTH directions: - <code>dense vectors</code> → "ranked by dense vectors" is 23, budget 12, so counts up to <code>9999 matches</code> fit at 40. A dense-backed install's plain branch mostly does not overflow. - <code>hybrid RRF (BM25 + dense)</code> → "ranked by hybrid RRF (BM25 + dense)" is 35, budget 0, so <b>nothing</b> fits at COLUMNS=40 — including <code>1 match</code>.
-
-<b>What is NOT established.</b> Recorded because a card that overstates its own evidence is worse than no card.
-
-SCOPE OF MY REPRO - The 55 / 54 / 42 / 41 numbers come from the shared 20-tap eval corpus at $TMPDIR/eval-home. They are "how bad on a real catalogue", corpus-dependent. - The load-bearing half is corpus-INDEPENDENT: the arithmetic (2 + len("N match(es)") + 3 + len("ranked by &lt;label&gt;")) and the fixture proof above, both reproducible with only <code>tests/make_fixture.py</code>. A card can be written without any external corpus. - The gate currently passes (4 passed, exit 0). I did not edit any source.
-
-DEDUPE — clean, not carded. I read <code>long-hints-overflow-narrow-panes.md</code> (#555) in full: it enumerates its 11+1 offenders by name (doctor 127, AI-fallback 101, protocol 100, changelog 93, who 87, search's *extra hint* 82, simulate 97) and its "Still open" section names only doctor's ·-joined summaries at 71 and protocol's <code>try it:</code> at 59 — the search footer is absent, and could not be present since 74c4aac9 wrote the long branch after #555. <code>audit-search-findings.md</code> (#770) specifies the footer's new wording and never measures a pane. <code>search-and-browse-visual-refresh.md</code> scopes its 40-column claim to <code>format_search_row</code>, which my measurement confirms still holds (every result row fits at 40 and 48). Also checked BOOST-D23, BOOST-D24, BOOST-D27, cli-output-ignored-the-terminal, cli-audit-2026-08-full-sweep, audit-output-wrap-tokens…, audit-out-table-clips… — none mention search's footer.
-
-<b>Why it is worth doing.</b> A required functional gate is asserting an invariant that is false for every real user, and it stays green because the fixture happens to hit the one count that fits. Anyone reading <code>test_cli_pane_width.py</code> or <code>long-hints-overflow-narrow-panes</code> ("eight overflowing lines became two, and the two are the data lines") believes <code>boost search</code> is width-clean at 40 columns; on a real catalogue the footer wraps in a split pane or narrow tmux window, which is exactly the class of regression PR 555 built the sweep to catch. The footer is chrome by the card's own definition — a match count and an engine label, not data like <code>pulse</code>'s paths or <code>fingerprint</code>'s hash — so nothing exempts 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/search-footer-overflows-40-col-pane-gate-passes-by-luck.md">Write-up &middot; search-footer-overflows-40-col-pane-gate-passes-by-luck.md</a></p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m">Impact <b>Med</b></span>
@@ -6300,36 +6193,9 @@ Found by the 2026-08 CLI audit (cluster help-examples-sweep); repro in the audit
       </article>
 
       <article class="cap rcard" id="audit-stale-prose-after-shipped-changes-catalog-export-live-discov">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Docs · Drift</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Docs · Drift</span></div>
         <h3>Stale prose after shipped changes: <code>catalog --export</code>, live discover, 464 count, Apache-2.0</h3>
-        <p>Four patches of prose describe the repo as it was before a shipped change, each verified against the current
-tree. <b>A documented command that does not run:</b> <code>docs/security-design.md:35</code> says
-<em>a <code>boost catalog export</code> tarball</em>; running it prints <code>Error: one of the arguments
---export --import --show is required</code> and exits 2 &mdash; the flag is <code>--export</code>.
-<b>Pre-live-search discover:</b> <code>docs/index.html:877</code> (<em><code>boost discover</code> indexes
-10,000+ skills across GitHub</em>) and <code>:940</code> (<em>build the GitHub-wide index &hellip; browse it with
-<code>boost discover</code></em>) predate the shipped change that made a query hit GitHub Code Search live; the
-index now only backs bare <code>discover</code> and <code>--local</code>, exactly as the command's own help says.
-
-<b>A hard-coded count, off by one and spreading:</b> README:151, <code>semantic-search.md:64</code> and
-<code>quickstart.py:39</code> say <code>--catalog</code> taps <b>463</b> registries;
-<code>registries.json</code> holds <b>464</b> non-list_only rows of 487, and <code>quickstart --dry-run
---catalog</code> on the 20-tap fixture prints <code>would tap 445 registries</code> (445&nbsp;+&nbsp;19 already
-tapped&nbsp;=&nbsp;464). Verification found more copies than the auditor: README:211,
-<code>quickstart.py:65</code> and CLAUDE.md:183&ndash;184 and :500. <b>A licence rule contradicting every
-file:</b> CLAUDE.md:276 still says headers open with <code>SPDX-License-Identifier: GPL-3.0-only</code>, but
-every source file greps to <code>Apache-2.0</code>, LICENSE is the Apache License 2.0, and
-<code>scripts/add_spdx_headers.py</code> already writes Apache-2.0 &mdash; the CLAUDE.md paragraph (and its
-<code>-only</code>&rarr;<code>-or-later</code> example) is the sole stale statement.
-
-Fix as one doc-only PR: <code>security-design.md:35</code> &rarr; <code>boost catalog --export</code>; rewrite
-the two <code>index.html</code> sentences to live-GitHub-search plus <code>boost index</code>/<code>--local</code>;
-replace the literal 463 with <em>every catalogued registry</em> (or 464) in README.md:151/211,
-<code>semantic-search.md:64</code>, <code>quickstart.py:39/65</code> and CLAUDE.md:183/500 &mdash; a number
-<code>scripts/build_registries.py</code> changes should not be hard-coded in prose; and correct the CLAUDE.md
-licence paragraph to Apache-2.0. <code>security-design.md</code> and <code>semantic-search.md</code> are already
-in <code>prose-lint.yml</code>'s vale list, so no lint wiring is needed; <code>docs/commands.html</code> is
-untouched (no parser changes). Found by the 2026-08 CLI audit (cluster stale-prose-docs); repro in the audit log.</p>
+        <p class="cardbody"><a class="writeup" href="https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items/audit-stale-prose-after-shipped-changes-catalog-export-live-discov.md">Write-up &middot; audit-stale-prose-after-shipped-changes-catalog-export-live-discov.md</a></p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Low</b></span>
@@ -6339,40 +6205,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>

{boost_skill_cli-1.2.129 → boost_skill_cli-1.2.131}/docs/security-design.md

@@ -32,7 +32,7 @@ thing boost does, and the code path treats it that way.
 | Boundary | Trusted side | Untrusted side |
 |---|---|---|
 | **Tap content** | boost's own code | every byte of a cloned registry: file names, paths, YAML frontmatter, body text |
-| **Catalogue bundle** | the importing machine | a `boost catalog export` tarball received from elsewhere |
+| **Catalogue bundle** | the importing machine | a `boost catalog --export` tarball received from elsewhere |
 | **The agent** | — | boost cannot police what an agent does with a file it has loaded |
 | **The toolchain** | the pinned hashes in `requirements/` | PyPI, and anything it resolves to |
 | **CI** | the workflow files in this repo | every third-party action, and anything a fork's PR can influence |