boost-skill-cli 1.2.108__tar.gz → 1.2.110__tar.gz

{boost_skill_cli-1.2.108/boost_skill_cli.egg-info → boost_skill_cli-1.2.110}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.108
+Version: 1.2.110
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0
@@ -217,8 +217,11 @@ refused rather than silently picking one.
 
 Because vectors are keyed to a registry's commit, `quickstart` **pins** each tap
 it fetches vectors for, and `boost update` skips a pinned tap rather than moving
-it out from under them (`--force` moves it anyway and drops the pin). When a tap
-does move, boost checks whether a newer shard exists for the new commit and
+it out from under them (`--force` moves it anyway and drops the pin). A pinned
+tap with *no* clone is not skipped — there is nothing to hold still, so it is
+cloned and checked out at its pin; if that pin cannot be reached the clone is
+removed rather than left on HEAD with a pin that no longer describes it, and
+`compact --reclone` follows the same rule. When a tap does move, boost checks whether a newer shard exists for the new commit and
 imports it; if none does, it says so instead of leaving stale vectors looking
 fresh. `boost search` never refreshes taps behind your back, and never checks
 the manifest either — acting on that answer means moving taps and downloading

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/README.md

@@ -175,8 +175,11 @@ refused rather than silently picking one.
 
 Because vectors are keyed to a registry's commit, `quickstart` **pins** each tap
 it fetches vectors for, and `boost update` skips a pinned tap rather than moving
-it out from under them (`--force` moves it anyway and drops the pin). When a tap
-does move, boost checks whether a newer shard exists for the new commit and
+it out from under them (`--force` moves it anyway and drops the pin). A pinned
+tap with *no* clone is not skipped — there is nothing to hold still, so it is
+cloned and checked out at its pin; if that pin cannot be reached the clone is
+removed rather than left on HEAD with a pin that no longer describes it, and
+`compact --reclone` follows the same rule. When a tap does move, boost checks whether a newer shard exists for the new commit and
 imports it; if none does, it says so instead of leaving stale vectors looking
 fresh. `boost search` never refreshes taps behind your back, and never checks
 the manifest either — acting on that answer means moving taps and downloading

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/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.108'
-__version_tuple__ = version_tuple = (1, 2, 108)
+__version__ = version = '1.2.110'
+__version_tuple__ = version_tuple = (1, 2, 110)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/boost_cli/commands/configuration.py

@@ -370,9 +370,26 @@ def cmd_compact(argv) -> int:
                     # other — nothing about `--reclone` consults the pin — so
                     # without this the clone silently lands on HEAD while
                     # config.json, the catalog cache and `boost taps` keep
-                    # naming the old commit. checkout_commit's own BoostError
-                    # (unresolvable pin) surfaces through the except below.
-                    gitutil.checkout_commit(tap.path, tap.pin)
+                    # naming the old commit.
+                    try:
+                        gitutil.checkout_commit(tap.path, tap.pin)
+                    except BoostError:
+                        # `--reclone` removed the clone before making this
+                        # one, so the pinned tree is already gone and there is
+                        # nothing to fall back to. Letting the `except` below
+                        # warn and carry on would leave a clone sitting on
+                        # HEAD with the old pin still recorded beside it, and
+                        # the next `update` reads `is_cloned` true plus a pin
+                        # and answers "pinned at <sha> (skipped)" — forever,
+                        # for a tree that is not on that commit. Remove it
+                        # instead: `doctor` names a tap with no clone (`! tap
+                        # <x> not cloned`, exit 1) and `update` re-clones it
+                        # back onto its pin, so the tap ends in a state
+                        # something reports and something repairs.
+                        # `registry.update` takes the same exit on the same
+                        # failure; this is the path that gets there first.
+                        util.rmtree(tap.path)
+                        raise
                 # The re-clone can change what's on disk even when the byte
                 # count doesn't (a pinned tap's tree is identical, but the
                 # cache's recorded commit and mtime are now stale either way).

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/boost_cli/commands/discovery.py

@@ -578,15 +578,30 @@ def cmd_reindex(argv):
     # and the count above reads exactly as it does for a full corpus. Say what
     # the index actually holds, in the share of TEXT rather than of documents —
     # a document share reads 100% until it reads 0%.
+    #
+    # The share quoted is of the tokens THIS INDEX holds, and the sentence says
+    # so. It used to read "this index holds N% of the searchable text", which
+    # is a share of the corpus — a number nothing here can compute, because the
+    # bodies that were never read have no token count to compare against. Since
+    # a body runs about an order of magnitude longer than the metadata standing
+    # in for it, that reading overstated badly in exactly the partly-cloned case
+    # this warning exists for: a half-cloned index announced itself as 94%
+    # complete, and one unreadable file among a thousand rendered as "100.0% of
+    # the searchable text" inside a warning about missing text.
     if stats["metadata_only"]:
         share = rag.index_completeness() or {}
-        out.warn("%d of %d items were indexed from catalog metadata alone — "
-                 "their registries are not cloned here, so this index holds "
-                 "%.1f%% of the searchable text. Tap them for real with "
-                 "`boost tap <owner/repo>` and re-run `boost reindex` to index "
-                 "their bodies."
-                 % (stats["metadata_only"], stats["docs"],
-                    100.0 * share.get("body_share", 0.0)), wrap=True)
+        tokens = share.get("tokens") or 0
+        meta_tokens = share.get("metadata_only_tokens") or 0
+        # No tokens at all means nothing but metadata got as far as the index,
+        # so 100% is the honest reading rather than a division to protect.
+        meta_pct = (100.0 * meta_tokens / tokens) if tokens else 100.0
+        out.warn("%d of %d indexed items have no body text — their registries "
+                 "are not cloned here, so only their catalog metadata was "
+                 "indexed, and that metadata is %.1f%% of everything this "
+                 "index holds. Clone them with `boost update`, then re-run "
+                 "`boost reindex --force` to index their bodies."
+                 % (stats["metadata_only"], stats["docs"], meta_pct),
+                 wrap=True)
     if args.dense:
         if dense_stats is None:
             out.warn("dense index skipped — %s" % embed.fallback_note(),

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/boost_cli/core/rag.py

@@ -789,10 +789,21 @@ def index_completeness() -> dict | None:
     ``body_share`` is a share of **tokens**, not of documents, and that is the
     whole point. An entry whose body is missing still produces a document, so a
     document share sits at 1.0 until the moment it drops to 0.0 and tells a
-    partially-cloned machine nothing. The token share degrades smoothly and
-    reproduces the measurement the roadmap card made by hand: 3,041,326 tokens
-    against 182,507 over 3,015 entries indexed with and then without their
-    clones, or 6.0% of the searchable text.
+    partially-cloned machine nothing.
+
+    It describes **this index**, not the corpus behind it: the fraction of the
+    tokens actually indexed that came from a document carrying a body. The
+    share of the *corpus's* text that made it in is a different number, and it
+    is not computable here — the bodies that were never read have no token
+    count to compare against, by construction. An earlier version of this
+    docstring claimed the value "reproduces the measurement the roadmap card
+    made by hand ... or 6.0% of the searchable text". It does not: for that
+    input every token indexed came from metadata, so it returns **0.0**. The
+    two move in opposite directions, and because a body runs about an order of
+    magnitude longer than the metadata standing in for it, presenting this as
+    corpus completeness overstates a half-cloned machine badly. Callers must
+    say which share they are quoting; :func:`cmd_reindex` quotes
+    ``metadata_only_tokens / tokens`` and names it.
 
     Reads the persisted totals rather than re-deriving them, so asking is a
     stat plus a cached parse — nothing walks the corpus.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110/boost_skill_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.108
+Version: 1.2.110
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0
@@ -217,8 +217,11 @@ refused rather than silently picking one.
 
 Because vectors are keyed to a registry's commit, `quickstart` **pins** each tap
 it fetches vectors for, and `boost update` skips a pinned tap rather than moving
-it out from under them (`--force` moves it anyway and drops the pin). When a tap
-does move, boost checks whether a newer shard exists for the new commit and
+it out from under them (`--force` moves it anyway and drops the pin). A pinned
+tap with *no* clone is not skipped — there is nothing to hold still, so it is
+cloned and checked out at its pin; if that pin cannot be reached the clone is
+removed rather than left on HEAD with a pin that no longer describes it, and
+`compact --reclone` follows the same rule. When a tap does move, boost checks whether a newer shard exists for the new commit and
 imports it; if none does, it says so instead of leaving stale vectors looking
 fresh. `boost search` never refreshes taps behind your back, and never checks
 the manifest either — acting on that answer means moving taps and downloading

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/boost_skill_cli.egg-info/SOURCES.txt

@@ -207,6 +207,7 @@ docs/roadmap/items/BOOST-D24.md
 docs/roadmap/items/BOOST-D25.md
 docs/roadmap/items/BOOST-D26.md
 docs/roadmap/items/BOOST-D27.md
+docs/roadmap/items/a-new-shipped-card-always-404s-its-own-write-up-link.md
 docs/roadmap/items/a11y-sweep-flakes-on-color-contrast.md
 docs/roadmap/items/accessibility-audit-pa11y-ci-axe-core.md
 docs/roadmap/items/actionlint-skips-shellcheck-silently.md
@@ -357,6 +358,7 @@ docs/roadmap/items/codeql-job-rename-stranded-merge-protection.md
 docs/roadmap/items/cold-search-reads-the-whole-catalogue.md
 docs/roadmap/items/command-carousel-page.md
 docs/roadmap/items/command-reference-docs-site.md
+docs/roadmap/items/compact-answers-a-named-tap-with-a-global-all-clear.md
 docs/roadmap/items/completions-complete-only-command-names.md
 docs/roadmap/items/completions-install-could-eat-your-rc-file.md
 docs/roadmap/items/complexity-and-dead-code-radar-xenon-vulture.md
@@ -455,6 +457,7 @@ docs/roadmap/items/langchain-retriever-metadata-and-k-floor.md
 docs/roadmap/items/layering-guard-import-linter.md
 docs/roadmap/items/license-compliance-scanning.md
 docs/roadmap/items/lighthouse-ci-on-the-pages-site.md
+docs/roadmap/items/lighthouse-flips-on-byte-identical-input.md
 docs/roadmap/items/lighthouse-scored-a-page-nobody-is-served.md
 docs/roadmap/items/lint-tap-misscopes-rule-workflow-entries.md
 docs/roadmap/items/list-rules-and-workflows.md
@@ -548,10 +551,12 @@ docs/roadmap/items/ranx-significance-monitor.md
 docs/roadmap/items/readme-81-command-table-lists-80-omits-quickstart.md
 docs/roadmap/items/readme-hero-installs-a-name-no-starter-registry-ships.md
 docs/roadmap/items/readme-prune-and-search-guide.md
+docs/roadmap/items/reclone-leaves-a-clone-on-head-when-it-cannot-reach-the-pin.md
 docs/roadmap/items/recommend-recomputes-its-columns-per-row.md
 docs/roadmap/items/reconcile-the-theme-drift.md
 docs/roadmap/items/refresh-strands-the-natural-set-baseline.md
 docs/roadmap/items/refresh-the-marketing-surface.md
+docs/roadmap/items/reindex-reported-a-completeness-share-it-could-not-compute.md
 docs/roadmap/items/rel-time-tests-race-the-wall-clock.md
 docs/roadmap/items/release-verifies-the-wrong-commit.md
 docs/roadmap/items/relicence-apache-2.md
@@ -624,6 +629,7 @@ docs/roadmap/items/sync-reported-success-for-a-link-it-refused.md
 docs/roadmap/items/table-fit-widths-floor-destroys-columns-and-still-overflows.md
 docs/roadmap/items/tap-signing-and-provenance-sigstore-minisign.md
 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-scale-corpus-refreshed-the-wrong-rows.md
 docs/roadmap/items/the-shard-job-that-could-not-finish.md

boost_skill_cli-1.2.110/docs/roadmap/items/a-new-shipped-card-always-404s-its-own-write-up-link.md

@@ -0,0 +1,42 @@
+---
+id: a-new-shipped-card-always-404s-its-own-write-up-link
+board: code
+section: pipeline
+status: planned
+category: CI · Bug
+complexity: S
+impact: Medium
+wow: 3
+note: the links check goes red on every correct PR that files a new card as shipped, and green again on merge
+order: 313
+owner:
+pr:
+title: "A new card filed as <code>shipped</code> always 404s its own write-up link"
+---
+<code>build_roadmap.py</code> renders a settled card's body as a link to the item file on
+<b><code>main</code></b> &mdash; <code>ITEMS_URL</code> (line 206) is
+<code>https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items</code>, and
+<code>_body_html</code> emits it for any status in <code>_SETTLED</code>. The
+<code>links</code> job runs on <code>pull_request</code> over
+<code>docs/*.html</code>. So a PR that files a <em>new</em> card at
+<code>status: shipped</code> renders a link to a file that does not exist on
+<code>main</code> yet, and lychee rejects it 404 &mdash; on a PR where nothing is wrong.
+It goes green by itself the moment the PR merges.
+
+Observed on PR <code>#845</code>, whose 22 required checks were all green:
+<em>&ldquo;[404] &lt;&hellip;/blob/main/docs/roadmap/items/reclone-leaves-a-clone-on-head-when-it-cannot-reach-the-pin.md&gt; (at 4125:54) | Rejected status code: 404 Not Found&rdquo;</em>.
+The mechanism is deterministic from the three sources above rather than inferred from that
+one run: any new item file whose first committed status is settled hits it. Cards that were
+already on <code>main</code> and merely change status do not, which is why this went
+unnoticed &mdash; the usual shape is claim-then-ship across two PRs.
+
+It matters because the remedy people reach for is the wrong one: either the card gets
+filed at a status that misdescribes it to keep CI quiet, or a check that is right about
+everything else gets learned as noise. <code>links</code> is advisory rather than
+required, which caps the damage and is also what lets it rot unnoticed. Options, cheapest
+first: resolve the link against the <em>head</em> ref in CI
+(<code>GITHUB_HEAD_REF</code>) and <code>main</code> elsewhere; or let lychee treat a
+<code>blob/main</code> URL whose path exists in the working tree as satisfied; or link the
+raw file relatively and accept that GitHub Pages serves <code>.md</code> as a download
+rather than rendered Markdown &mdash; which is the reason the absolute URL was chosen, so
+that one is a trade, not a fix.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-ai-degrade-note-blames-path-api-keys-regardless-of-cause-sev.md

@@ -2,7 +2,7 @@
 id: audit-ai-degrade-note-blames-path-api-keys-regardless-of-cause-sev
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · UX
 complexity: M
 impact: Med
@@ -10,7 +10,7 @@ wow: 2
 note: fix implemented and unit/functional/smoke-tested locally; mutation/eval/full-lint gates unverified — this session had no PyPI/network egress to run them, PR relies on CI
 order: 223
 owner: loop/ai-fallback-attribution
-pr:
+pr: 760
 title: "AI degrade note blames PATH/API keys regardless of cause; several commands fall back with no note at all"
 ---
 <code>boost simulate</code> prints <code>! AI features need one of `claude` or `gemini` on PATH, or ANTHROPIC_API_KEY set &mdash; using the heuristic fallback</code> in two situations where that diagnosis is false: under <code>BOOST_NO_AI=1</code> with <code>claude</code> on PATH (AI was disabled by env, not missing), and with AI enabled while <code>~/.boost/logs/boost.log</code> records <code>ai: claude CLI call failed: exit 1: &hellip;workspace has not been trusted&hellip;</code> &mdash; the backend ran and failed. A controlled fake <code>claude</code> exiting 3 reproduces the same misblame for <code>evolve</code>. Meanwhile a second group degrades with <b>no note at all</b> when the call was attempted and failed: <code>explain</code> shows the extractive summary with stderr empty, <code>conflict</code> lists pairs as <code>(heuristic)</code> silently, <code>impact</code> and one-shot <code>chat</code> say nothing, and <code>search --smart</code> spent 4.62&nbsp;s then reported <code>60 matches &middot; ranked by full-content BM25</code> with no rerank-failed warning.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-browse-findings.md

@@ -2,7 +2,7 @@
 id: audit-browse-findings
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: Med
@@ -10,7 +10,7 @@ wow: 1
 note: both findings fixed in PR; make check unrunnable in the sandbox (no PyPI/apt egress) — CI is the real gate
 order: 251
 owner: loop/browse-plain-fallback
-pr:
+pr: 790
 title: "boost browse: CLI audit findings (2026-08)"
 ---
 <b>A curses init failure crashes with a report instead of falling back</b> (cluster

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-catalog-resolve-one-s-duplicate-name-hint-advertises-path-to.md

@@ -2,7 +2,7 @@
 id: audit-catalog-resolve-one-s-duplicate-name-hint-advertises-path-to
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: High
@@ -10,7 +10,7 @@ wow: 1
 note: Following the CLI's own hint earns `unrecognized arguments: --path`, exit 2
 order: 215
 owner: loop/resolve-one-path-hint
-pr:
+pr: 655
 title: "<code>catalog.resolve_one</code>'s duplicate-name hint advertises <code>--path</code> to commands that reject it"
 ---
 When a name matches two skills inside one tap, every <code>catalog.resolve_one</code> caller prints

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-context-findings.md

@@ -2,7 +2,7 @@
 id: audit-context-findings
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: Med

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-create-distill-infer-absorb-install-silently-replace-an-inst.md

@@ -2,7 +2,7 @@
 id: audit-create-distill-infer-absorb-install-silently-replace-an-inst
 board: code
 section: dx
-status: inflight
+status: shipped
 category: Safety · Bug
 complexity: S
 impact: High

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-declined-confirms-never-name-y-boost-assume-yes-snapshot-cle.md

@@ -2,7 +2,7 @@
 id: audit-declined-confirms-never-name-y-boost-assume-yes-snapshot-cle
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · UX
 complexity: M
 impact: Med
@@ -10,7 +10,7 @@ wow: 1
 note: implementation lands the full fix; make check's eval/mutation/smoke gates could not run in the claiming sandbox (no PyPI egress) — see PR for what did run
 order: 224
 owner: loop/confirm-bypass-hints
-pr:
+pr: 731
 title: "Declined confirms never name <code>-y</code>/<code>BOOST_ASSUME_YES</code>; snapshot, clean, infer/distill/absorb and sync reject <code>--yes</code>"
 ---
 One pattern across seven commands. <code>snapshot restore</code>, piped without <code>BOOST_ASSUME_YES</code>: output is exactly <code>&nbsp;&nbsp;cancelled</code>, exit 0 &mdash; no prompt shown, no reason, no bypass named &mdash; and <code>snapshot restore ID --yes</code> answers <code>Error: unrecognized arguments: --yes</code> (exit 2). <code>clean --deep --yes</code> hits the same error, and its declined path claims <code>&#10003; nothing to clean</code> when a snapshot was in fact kept. <code>sync --prune</code> declined tells the user to run <code>boost sync --prune</code> &mdash; the command just run. <code>untap</code> and <code>bmad uninstall</code> print bare <code>cancelled</code>/<code>aborted</code> lines (bmad exits 0 with nothing removed); <code>infer -o</code>/<code>distill</code> abort with no hint and reject <code>--yes</code>. <code>BOOST_ASSUME_YES</code> appears in zero command help texts.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-discover-findings.md

@@ -2,7 +2,7 @@
 id: audit-discover-findings
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · UX
 complexity: S
 impact: Low

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-export-o-cohort-create-and-profile-save-silently-overwrite-e.md

@@ -2,7 +2,7 @@
 id: audit-export-o-cohort-create-and-profile-save-silently-overwrite-e
 board: code
 section: dx
-status: inflight
+status: shipped
 category: Safety · Bug
 complexity: S
 impact: Med

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-git-operations-never-set-git-terminal-prompt-0-so-a-404-priv.md

@@ -2,7 +2,7 @@
 id: audit-git-operations-never-set-git-terminal-prompt-0-so-a-404-priv
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: Med

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-health-findings.md

@@ -2,7 +2,7 @@
 id: audit-health-findings
 board: code
 section: health
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: Med

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-install-findings.md

@@ -10,7 +10,7 @@ wow: 1
 note: "3 of 4 clusters landed; cross-scope-name-block gets a safe refusal, not true coexistence"
 order: 273
 owner: loop/audit-install-findings
-pr:
+pr: 823
 title: "<code>boost install</code>: CLI audit findings (2026-08)"
 ---
 <b>Rule/workflow lock entries are name-keyed across scopes</b> <em>(med)</em>. With the

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-log-simulate-changelog-headings-echo-the-raw-qualified-argum.md

@@ -2,7 +2,7 @@
 id: audit-log-simulate-changelog-headings-echo-the-raw-qualified-argum
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Polish
 complexity: S
 impact: Low
@@ -10,7 +10,7 @@ wow: 1
 note: "changelog for anthropics/skills:pdf (anthropics/skills) — the tap printed twice"
 order: 243
 owner: loop/qualified-name-headings
-pr:
+pr: 754
 title: "<code>log</code>/<code>simulate</code>/<code>changelog</code> headings echo the raw qualified argument, printing the tap twice"
 ---
 Give any of the three a tap-qualified name and the heading repeats the tap. Reproduced verbatim:

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-mcp-findings.md

@@ -2,7 +2,7 @@
 id: audit-mcp-findings
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: M
 impact: Med

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-mcp-register-s-boost-first-consent-names-only-the-registered.md

@@ -2,7 +2,7 @@
 id: audit-mcp-register-s-boost-first-consent-names-only-the-registered
 board: code
 section: dx
-status: inflight
+status: shipped
 category: Safety · Bug
 complexity: S
 impact: High

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-out-warn-defaults-to-stdout-infer-absorb-corrupt-skill-md-se.md

@@ -2,7 +2,7 @@
 id: audit-out-warn-defaults-to-stdout-infer-absorb-corrupt-skill-md-se
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: High

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-output-wrap-tokens-splits-punctuation-off-backtick-spans-ins.md

@@ -2,7 +2,7 @@
 id: audit-output-wrap-tokens-splits-punctuation-off-backtick-spans-ins
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: Low
@@ -10,7 +10,7 @@ wow: 1
 note: the wrapper rejoins span + ")" with a space; one fix covers doctor, reindex and all help
 order: 240
 owner: loop/wrap-tokens-punctuation
-pr:
+pr: 665
 title: "<code>output._wrap_tokens</code> splits punctuation off backtick spans, inserting a stray space"
 ---
 CLAUDE.md's wrap law makes a backtick span one atomic token so pasteable commands survive folding

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-pinned-taps-silently-moved-to-head-by-update-re-clone-and-co.md

@@ -2,12 +2,12 @@
 id: audit-pinned-taps-silently-moved-to-head-by-update-re-clone-and-co
 board: code
 section: internals
-status: inflight
+status: shipped
 category: Safety · Bug
 complexity: M
 impact: High
 wow: 2
-note: compact --reclone moved a pin to HEAD and printed "every tap is already compact"
+note: three broken paths, three PRs claiming it, and one residual that took a second item to finish
 order: 216
 owner: loop/tap-pin-integrity
 pr: 725
@@ -43,3 +43,14 @@ size-only report at <code>configuration.py:288-292</code> is what hid the move.
 pinned-tap paragraph (lines 176-178) and its <code>compact --reclone</code> line (274); regenerate
 <code>docs/commands.html</code> only if the <code>--force</code> help string changes. Found by the
 2026-08 CLI audit (cluster <code>pinned-tap-integrity</code>); repro in the audit log.
+
+
+<b>Closed 2026-09-10.</b> <code>#725</code> landed the <code>registry.update</code> half
+(both the <code>--force</code> unpin and the re-clone of a pinned tap whose clone had
+vanished, with <code>tests/unit/test_tap_pins.py</code> covering each). The
+<code>compact --reclone</code> half landed in two pieces: the pin checkout, the
+<code>catalog.rebuild_tap</code> and the size-independent report came with
+<code>#725</code>; the unresolvable-pin guard was left behind when three PRs claimed this
+one item and only one could merge, and is its own card &mdash;
+<code>reclone-leaves-a-clone-on-head-when-it-cannot-reach-the-pin</code>. All three paths
+named above are now closed, and README's pinned-tap paragraph says what the code does.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-preview-findings.md

@@ -2,7 +2,7 @@
 id: audit-preview-findings
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · UX
 complexity: S
 impact: Med
@@ -10,7 +10,7 @@ wow: 1
 note: piped preview strips ** with no substitute; at 60 cols 10 lines leak raw markers
 order: 280
 owner: loop/preview-render
-pr:
+pr: 807
 title: "<code>boost preview</code>: CLI audit findings (2026-08)"
 ---
 <b>Preview strips markdown markers with no substitute when piped, and leaks raw <code>**</code> when a bold span straddles a wrap boundary.</b> Piped <code>preview brainstorming</code> shows 0 lines containing <code>**</code> where piped <code>cat</code> shows the raw 22 — the markers are removed and no colour replaces them, <code>---</code> prints literally, and a wrapped <code>&gt; quote</code> continuation loses its <code>&gt;</code>; neither raw Markdown nor a faithful render. On a TTY at <code>COLUMNS=60</code> the reverse bug: <b>10 lines leak literal <code>**</code></b> (0 at 120 columns) because <code>_render_markdown</code> wraps first and runs <code>_inline</code> per chunk, and <code>out.wrap</code>'s atomic-span protection (<code>output.py:369-390</code>, <code>_CODE_SPAN_RE</code>) covers only backtick spans. Fix per the verified recommendation: in <code>cmd_preview</code> (<code>boost_cli/commands/info.py:614-677</code>) emit the raw body when <code>not sys.stdout.isatty()</code>, mirroring <code>boost cat</code>; and extend the atomic-token handling in <code>out.wrap</code> to treat <code>**…**</code> like a backtick span (or apply <code>_inline</code> before wrapping with bold state carried across chunks). Regenerate <code>docs/commands.html</code>.<br><br><b>The title bar shows <code>v?</code> where <code>info</code>/<code>list</code>/<code>search</code> show 0.0.0 for the same skill.</b> Observed: <code>● ● ●  brainstorming · v? · sickn33/antigravity-awesome-skills</code> while <code>info</code> prints <code>version 0.0.0</code> — and verification found it broader than filed: <em>every</em> skill whose SKILL.md omits <code>version:</code> disagrees, installed or not, because <code>cmd_preview</code> reads raw frontmatter while <code>catalog.scan_dir</code> normalises a missing version to "0.0.0" (<code>core/catalog.py:117</code>). The same titlebar line already falls back to the lock/catalog for the <em>tap</em>; version simply missed the pattern. One-line fix at <code>info.py:673</code>: <code>meta.get("version") or (lock or cat or {}).get("version") or "?"</code>, plus a unit test asserting preview and info agree.<br><br>Found by the 2026-08 CLI audit (clusters <code>preview-markdown-render</code>, <code>preview-version-placeholder</code>); repro in the audit log.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-profile-findings.md

@@ -2,7 +2,7 @@
 id: audit-profile-findings
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: Low
@@ -10,7 +10,7 @@ wow: 1
 note: declined --prune leaves extras fully linked yet still prints "✓ switched"
 order: 281
 owner: loop/profile-use-drift-prune
-pr:
+pr: 820
 title: "<code>boost profile use</code>: CLI audit findings (2026-08)"
 ---
 <b><code>profile use</code> omits the version-drift warning <code>diff</code> reports, and a declined <code>--prune</code> still reports a clean switch with extras fully linked.</b> Reproduced: <code>profile diff daily</code> prints <code>~ brainstorming  (version differs)</code> but <code>profile use daily</code> says only <code>✓ switched to profile daily</code> — <code>team.py:335</code> discards the <code>_changed</code> tuple element that <code>diff</code> prints at <code>team.py:315-316</code>. Worse, with an extra skill installed and the <code>--prune</code> confirm declined via EOF, the output is <code>kept extras installed</code> then the same unconditional <code>✓ switched to profile daily</code>, and the extra's symlink was confirmed still present in <code>.claude/skills/</code> — the non-prune path would have sidelined it, so the checkmark claims a state the machine is not in.<br><br>Verified fix (<code>boost_cli/commands/team.py:333-367</code>): print a warn line per entry in <code>_changed</code>, mirroring diff's "~ NAME (version differs)" wording; and after a declined <code>--prune</code> confirm either fall through to the sideline/unlink branch or drop the trailing checkmark and say the switch was partial. No flag changes, so no docs regeneration needed.<br><br>Found by the 2026-08 CLI audit (cluster <code>profile-use-drift-prune</code>); repro in the audit log.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-pulse-findings.md

@@ -2,7 +2,7 @@
 id: audit-pulse-findings
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · UX
 complexity: S
 impact: Med
@@ -10,7 +10,7 @@ wow: 1
 note: "fix implemented + tested; make check's eval/mutation/smoke gates could not run locally (no PyPI egress) — see PR for what did run"
 order: 283
 owner: loop/pulse-who-filtered-empty
-pr:
+pr: 780
 title: "<code>boost pulse</code>: CLI audit findings (2026-08)"
 ---
 <b><code>pulse --action</code> and <code>who &lt;name&gt;</code> claim "no activity yet" when only the filter is empty.</b> Reproduced with a populated journal: <code>pulse --action nosuch</code> prints <code>○ no activity yet — events appear as you install and manage skills</code> and <code>who nosuchskill-zzz</code> prints <code>○ no journal activity yet — expertise builds as people install, edit, and evolve skills</code> — while <code>pulse.jsonl</code> held 35 events at audit time (23 on re-verification; both matched verbatim). Both commands compute a filtered <code>events</code> list and print the same global empty state when it is empty, with no branch distinguishing filter-empty from journal-empty — so the output asserts a state ("nothing has happened on this machine") that is simply false, and hides that the user's filter value matched nothing.<br><br>Verified fix (<code>boost_cli/commands/team.py:518-522</code> for <code>cmd_pulse</code>, <code>team.py:692-702</code> for <code>cmd_who</code>): when <code>args.action</code> / the skill argument is set and the unfiltered journal is non-empty, print a filter-specific empty state naming the filter value — e.g. <code>○ no events with action "nosuch" (35 events in the journal)</code> — ideally listing the distinct actions present; for <code>who</code>, name the subject and say "not installed" or offer a did-you-mean when the name is close to a known one. Keep the current message only for a truly empty journal. No flag changes, so no docs regeneration needed.<br><br>Found by the 2026-08 CLI audit (cluster <code>filtered-empty-state</code>); repro in the audit log.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-quarantine-findings.md

@@ -2,7 +2,7 @@
 id: audit-quarantine-findings
 board: code
 section: health
-status: inflight
+status: shipped
 category: Safety · Bug
 complexity: S
 impact: Med

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-replay-findings.md

@@ -2,7 +2,7 @@
 id: audit-replay-findings
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: Low
@@ -10,7 +10,7 @@ wow: 1
 note: rollback says "complete" (exit 0) with a skill unrestored, and replans it forever
 order: 288
 owner: loop/replay-audit-findings
-pr:
+pr: 798
 title: "boost replay: CLI audit findings (2026-08)"
 ---
 <b><code>replay list</code>'s ID and WHEN describe two different instants on one row.</b> <code>replay list --json</code> after two installs 4 s apart: <code>{"id": "20260831T140213Z", "updated": "2026-08-31T14:02:09Z"}</code>. <code>lockfile.write()</code> (<code>boost_cli/core/lockfile.py:78-99</code>) stamps the history filename with <em>now</em> &mdash; the moment the outgoing lock becomes historical &mdash; but that snapshot's own <code>updated</code> field was stamped by the <em>previous</em> write, and <code>cmd_replay list</code> (<code>boost_cli/commands/team.py:592</code>) prints the two side by side as if they were one instant; <code>replay show</code> reuses the earlier one. Fix: stamp the history filename with the lock's own <code>updated</code> so the id equals the state time, or relabel the column (e.g. STATE FROM) and note the distinction in <code>replay show</code>'s heading.

{boost_skill_cli-1.2.108 → boost_skill_cli-1.2.110}/docs/roadmap/items/audit-run-findings.md

@@ -2,7 +2,7 @@
 id: audit-run-findings
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Bug
 complexity: S
 impact: Low
@@ -10,7 +10,7 @@ wow: 1
 note: the 55-line runner's banner names a command that produces a 9-line file
 order: 289
 owner: loop/run-print-banner
-pr:
+pr: 791
 title: "boost run: CLI audit findings (2026-08)"
 ---
 <b><code>run --print</code>'s provenance banner names the wrong command.</b> The first line of the emitted runner reads <code># Generated by `boost adapt brainstorming --to agents-sdk`. Do not edit by hand.</code> &mdash; but that command produces a 9-line Agent module, while this is a 55-line runner with <code>_boost_brain</code>, <code>read_file</code>/<code>list_dir</code>/<code>grep</code> tools and <code>Runner.run_sync</code>. The banner's stated purpose is provenance (&ldquo;Do not edit by hand&rdquo; &mdash; regenerate instead), and the command it names cannot regenerate the file: <code>adapters.render_runner</code> (<code>boost_cli/core/adapters.py:539-562</code>) returns <code>render_agents_sdk(&hellip;)</code> plus tools and a main, inheriting the agents-sdk banner from line 267 verbatim. Fix: in <code>render_runner</code>, replace the first line with <code># Generated by `boost run NAME [TARGET] --print`. Do not edit by hand.</code> (including TARGET when given), and add a unit test asserting the runner's banner names <code>boost run</code>. No flag or summary changes, so docs/commands.html needs no regeneration. Found by the 2026-08 CLI audit (cluster <code>run-print-banner</code>); repro in the audit log.