boost-skill-cli 1.2.60__tar.gz → 1.2.62__tar.gz

{boost_skill_cli-1.2.60/boost_skill_cli.egg-info → boost_skill_cli-1.2.62}/PKG-INFO

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

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/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.60'
-__version_tuple__ = version_tuple = (1, 2, 60)
+__version__ = version = '1.2.62'
+__version_tuple__ = version_tuple = (1, 2, 62)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/boost_cli/core/dense.py

@@ -302,7 +302,17 @@ def tap_commits() -> dict[str, str]:
     Read without sqlite-vec (see :func:`_recorded_meta`) so a machine that lost
     the extra still gets a truthful answer rather than an empty one.
     """
-    commits = _recorded_meta().get("commits")
+    meta = _recorded_meta()
+    if meta.get("version") != INDEX_VERSION:
+        # A store from an older boost is about to be discarded — `build` wipes
+        # it and so does `import_shard` — so it holds no vectors anyone can
+        # reuse, and saying otherwise is worse than saying nothing. The caller
+        # asking this question is deciding which taps to SKIP: answering with a
+        # stale store's commits let `ingest` skip 417 taps as "already current"
+        # and then wipe their vectors on the first import, leaving a store that
+        # was silently missing them while the output said they were fine.
+        return {}
+    commits = meta.get("commits")
     if not isinstance(commits, dict):
         return {}
     return {str(k): str(v) for k, v in commits.items() if v}
@@ -766,6 +776,18 @@ def import_shard(shard: dict, commit: str) -> tuple[bool, str]:
         return False, "no vector backend available"
     try:
         meta = _read_meta(con)
+        if meta.get("version") not in (None, INDEX_VERSION):
+            # The same wipe `build` does, for the same reason: `_ensure_schema`
+            # is CREATE TABLE IF NOT EXISTS, so it cannot add v3's `digest`
+            # column to a table built by an older boost, and the INSERT below
+            # would fail per row with "table chunks has no column named
+            # digest". On a real machine that is 449 shards reporting a sqlite
+            # message about a column, where the honest answer is that the store
+            # predates this format. Wiping loses nothing that was in use — a
+            # stale-version store is already dead weight, refused by `ready()`
+            # and wiped by `build()` on its next run.
+            _wipe(con)
+            meta = {}
         # An empty store has no opinion yet, so it adopts the shard's backend.
         if meta.get("provider"):
             for field in ("provider", "model", "dim"):

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/boost_cli/core/shards.py

@@ -94,6 +94,67 @@ def _open(url: str, timeout: float):
                               "embeds locally instead") from exc
 
 
+def _read_capped(resp, cap: int) -> bytes:
+    """Read the whole response, stopping once it exceeds `cap` bytes.
+
+    THE LOOP IS THE POINT. ``HTTPResponse.read(amt)`` returns *up to* `amt`
+    bytes, not `amt` bytes, and over a real connection it routinely returns
+    less — one read of the live 166 KB manifest came back with 131,072 bytes
+    on one run and 146,547 on the next. A single ``resp.read(cap + 1)``
+    therefore handed a truncated document to ``json.loads``, which reported it
+    as "not valid JSON": a network artefact wearing the costume of a corrupt
+    publish, on every command that reads the manifest.
+
+    The unit suite could not see it, and still cannot without help: its
+    fixtures are ``file:`` URLs, where one read does return the whole file.
+    ``tests/unit/test_shards.py`` covers this with a response that short-reads
+    on purpose.
+
+    Reading `cap + 1` in total keeps the size check that follows honest — one
+    byte over the ceiling is enough to fail it, and nothing larger is buffered.
+    """
+    chunks: list[bytes] = []
+    total = 0
+    while total <= cap:
+        buf = resp.read(min(_CHUNK, cap + 1 - total))
+        if not buf:
+            break
+        chunks.append(buf)
+        total += len(buf)
+    return b"".join(chunks)
+
+
+def _verify_complete(resp, raw: bytes, url: str) -> None:
+    """Refuse a body that arrived shorter than the server said it would.
+
+    ``read(amt)`` performs no length check — that is done only by ``read()``
+    with no argument — so a connection cut mid-stream returns a short body and
+    then a clean EOF. The truncated document reaches ``json.loads``, which
+    calls it "not valid JSON", and the user goes looking for a corrupt publish
+    that does not exist. Observed here against the live 166,210-byte manifest:
+    a read returned 146,547 bytes and the next returned nothing.
+
+    The Content-Encoding guard is not defensive padding. ``Content-Length``
+    describes the bytes ON THE WIRE, so against a gzipping proxy it is the
+    compressed size while `raw` is the decoded body — comparing the two would
+    manufacture a truncation failure, which is the same class of bug this
+    function exists to remove. A missing or unparseable header means the
+    question cannot be answered and is left alone.
+    """
+    enc = (resp.headers.get("Content-Encoding") or "").strip().lower()
+    if enc and enc != "identity":
+        return
+    try:
+        want = int(resp.headers.get("Content-Length"))
+    except (TypeError, ValueError):
+        return
+    if len(raw) < want:
+        raise BoostError(
+            "shard manifest download from %s was truncated (%d of %d bytes)"
+            % (url, len(raw), want),
+            hint="a proxy or a dropped connection cut the stream — retry")
+
+
 def fetch_manifest(url: str | None = None, timeout: float = 30.0) -> dict:
     """Download and validate the shard manifest.
 
@@ -104,9 +165,13 @@ def fetch_manifest(url: str | None = None, timeout: float = 30.0) -> dict:
     """
     url = url or manifest_url()
     with _open(url, timeout) as resp:
-        raw = resp.read(MAX_MANIFEST_BYTES + 1)
-    if len(raw) > MAX_MANIFEST_BYTES:
-        raise BoostError("shard manifest at %s is implausibly large" % url)
+        raw = _read_capped(resp, MAX_MANIFEST_BYTES)
+        # Size ceiling first, completeness second: a manifest larger than the
+        # cap is also "shorter than declared", and reporting that one as a
+        # truncated download would name the wrong problem.
+        if len(raw) > MAX_MANIFEST_BYTES:
+            raise BoostError("shard manifest at %s is implausibly large" % url)
+        _verify_complete(resp, raw, url)
     try:
         data = json.loads(raw.decode("utf-8"))
     except (UnicodeDecodeError, json.JSONDecodeError) as exc:

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/bm25-has-no-stemming.md

@@ -2,7 +2,7 @@
 id: bm25-has-no-stemming
 board: code
 section: pipeline
-status: inflight
+status: shipped
 category: Search · Retrieval
 complexity: M
 impact: High
@@ -10,7 +10,7 @@ wow: 4
 note: a term with no postings is now replaced by the commonest term it prefixes; a term that has postings is never touched, which is what keeps the eval floors still
 order: 127
 owner: loop/bm25-stem-fallback
-pr:
+pr: 554
 title: <code>boost search brainstorm</code> finds nothing, and <code>brainstorming</code> finds it
 ---
 <b>The symptom, in two commands against the same five-skill tap.</b>

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/boost-first-carried-the-losing-trigger.md

@@ -2,7 +2,7 @@
 id: boost-first-carried-the-losing-trigger
 board: code
 section: dx
-status: inflight
+status: shipped
 category: Interop · Adoption
 complexity: M
 impact: High
@@ -11,6 +11,7 @@ note: the rule shipped the one trigger boost had already measured as losing, and
 order: 107
 owner: loop/boost-first-observable-trigger
 pr: 491
+pr: 491
 title: <code>boost-first</code> carried the trigger that had already fired and lost — and could never be updated
 ---
 <b>Two defects, and the second is why the first survived.</b> Reported from a live session:

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/branch-current-gate.md

@@ -2,7 +2,7 @@
 id: branch-current-gate
 board: code
 section: health
-status: inflight
+status: shipped
 category: CI · Release safety
 complexity: S
 impact: High
@@ -10,7 +10,7 @@ wow: 4
 note: two protection mechanisms disagreed; the binding one had the safety off
 order: 10
 owner: loop/generated-freshness
-pr:
+pr: 586
 title: main went red because "require branches up to date" was never actually on
 ---
 Two pull requests, each green against the <code>main</code> it was tested on, merged into a

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/browse-could-not-search-two-words.md

@@ -2,7 +2,7 @@
 id: browse-could-not-search-two-words
 board: code
 section: dx
-status: inflight
+status: shipped
 category: Bug · UX
 complexity: M
 impact: High
@@ -10,7 +10,7 @@ wow: 4
 note: space was bound to select, so two words could never be searched for
 order: 115
 owner: feat/browse-tui
-pr:
+pr: 525
 title: <code>browse</code> could not search for two words, and the fix reshaped the whole browser
 ---
 <b>The bug was two lines.</b> <code>space</code> toggled multi-select, and the

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/cli-output-ignored-the-terminal.md

@@ -2,7 +2,7 @@
 id: cli-output-ignored-the-terminal
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Output
 complexity: S
 impact: Med
@@ -11,6 +11,7 @@ note: an 80-command sweep found a box that drew wider than the pane, a help scre
 order: 125
 owner: loop/cli-output-defects
 pr: 552
+pr: 552
 title: The box drew 108 columns into an 80-column pane, and <code>--help</code> never asked how wide the pane was
 ---
 <b>Every one of the 80 commands was run, not just read.</b> All 80 answered

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/cold-search-reads-the-whole-catalogue.md

@@ -2,7 +2,7 @@
 id: cold-search-reads-the-whole-catalogue
 board: code
 section: pipeline
-status: inflight
+status: shipped
 category: Performance · Search
 complexity: M
 impact: High
@@ -10,7 +10,7 @@ wow: 4
 note: 0.94 s cold search at 71.6k entries — ~0.5 s spent materialising data the top hits never use
 order: 122
 owner: loop/search-perf
-pr:
+pr: 542
 title: A cold search materialises 71,600 entries to print five
 ---
 Profiled cold <code>boost search</code> at real scale (458 taps, 71,600

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/completions-install-could-eat-your-rc-file.md

@@ -2,7 +2,7 @@
 id: completions-install-could-eat-your-rc-file
 board: code
 section: dx
-status: inflight
+status: shipped
 category: Bug
 complexity: S
 impact: High
@@ -10,7 +10,7 @@ wow: 4
 note: two runs of a "no-op" command deleted the lines between two markers
 order: 113
 owner: fix/completions-malformed-block
-pr:
+pr: 523
 title: <code>completions --install</code> could delete the config between its own markers
 ---
 Found by asking a plain question — <em>is <code>boost completions</code>

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/dense-search-rescans-every-vector.md

@@ -2,7 +2,7 @@
 id: dense-search-rescans-every-vector
 board: code
 section: internals
-status: inflight
+status: shipped
 category: Search · Performance
 complexity: M
 impact: High
@@ -11,6 +11,7 @@ note: 33.9s cold search; 28.2s of it was one brute-force scan of 3.08 GB
 order: 1
 owner: loop/dense-quantization
 pr: 544
+pr: 544
 title: Every dense search re-scanned all 3.08&nbsp;GB of vectors &mdash; <code>vec0</code> has no ANN index
 ---
 <b>A user reported <code>boost search "refactor UI with taste"</code> taking 34 seconds.</b> The

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/discover-searches-github-not-a-stale-sample.md

@@ -2,7 +2,7 @@
 id: discover-searches-github-not-a-stale-sample
 board: code
 section: dx
-status: inflight
+status: shipped
 category: DX · Feature
 complexity: M
 impact: High
@@ -11,6 +11,7 @@ note: an adversarial review of the first draft confirmed 21 defects, two of whic
 order: 106
 owner: loop/discover-live-github-search
 pr: 490
+pr: 490
 title: <code>boost discover &lt;query&gt;</code> asks GitHub, instead of filtering whatever <code>boost index</code> happened to sample
 ---
 <b>What was wrong.</b> <code>boost discover react</code> read as a question about GitHub and

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/gemini-duplicate-skill-discovery.md

@@ -2,7 +2,7 @@
 id: gemini-duplicate-skill-discovery
 board: code
 section: health
-status: inflight
+status: shipped
 category: Interop · Bug
 complexity: S
 impact: Med
@@ -10,7 +10,7 @@ wow: 3
 note: Gemini warned once per skill per session and no boost surface could see it
 order: 40
 owner: loop/gemini-stale-links
-pr:
+pr: 568
 title: Gemini logged a skill conflict every session and <code>boost doctor</code> called the machine healthy
 ---
 Gemini CLI printed this on <b>every session start, once per skill</b>, on a machine whose

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/gemini-hooks-host-aware.md

@@ -2,7 +2,7 @@
 id: gemini-hooks-host-aware
 board: code
 section: compat
-status: inflight
+status: shipped
 category: Compat
 complexity: M
 impact: Med
@@ -10,7 +10,7 @@ wow: 4
 note: two upstream Gemini bugs found while establishing the schema
 order: 9
 owner: loop/gemini-hooks-support
-pr:
+pr: 570
 title: boost hooks learns a second host — and finds two bugs upstream
 ---
 <code>boost hooks</code> managed Claude Code's <code>settings.json</code> and nothing else,

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/gemini-mcp-parity.md

@@ -2,7 +2,7 @@
 id: gemini-mcp-parity
 board: code
 section: compat
-status: inflight
+status: shipped
 category: Compat
 complexity: M
 impact: Med
@@ -10,7 +10,7 @@ wow: 3
 note: audited what Gemini actually receives — two of three findings were our own wrong claims
 order: 8
 owner: loop/gemini-mcp-audit
-pr:
+pr: 569
 title: What Gemini actually receives from boost, audited
 ---
 "Do Gemini hooks invoke boost's MCP the same way Claude does?" turned out to be two questions

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/long-hints-overflow-narrow-panes.md

@@ -2,7 +2,7 @@
 id: long-hints-overflow-narrow-panes
 board: code
 section: dx
-status: inflight
+status: shipped
 category: CLI · Output
 complexity: M
 impact: Low
@@ -10,7 +10,7 @@ wow: 2
 note: a code span is one atomic token, so a hint folds to the pane without splitting the command it tells you to run
 order: 126
 owner: loop/wrap-long-hints
-pr:
+pr: 555
 title: The hints still run past the pane, and the worst one is pinned by six test files
 ---
 <b>Measured, at <code>COLUMNS=80</code>, over 46 commands.</b> After the box and the help screen

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/marketing-crm-domain-had-no-category.md

@@ -2,7 +2,7 @@
 id: marketing-crm-domain-had-no-category
 board: code
 section: internals
-status: inflight
+status: shipped
 category: Catalog · Curation
 complexity: M
 impact: High
@@ -11,6 +11,7 @@ note: the four marketing registries already carried were filed under writing and
 order: 124
 owner: loop/marketing-crm-registries
 pr: 551
+pr: 551
 title: <code>--category marketing</code> matched nothing, while four marketing registries sat in the catalog under other names
 ---
 <b>The catalog carried marketing registries and could not hand you one.</b>

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/openssf-gold-ceiling.md

@@ -2,7 +2,7 @@
 id: openssf-gold-ceiling
 board: code
 section: health
-status: inflight
+status: shipped
 category: Security · Posture
 complexity: M
 impact: Med
@@ -10,7 +10,7 @@ wow: 3
 note: 26% → 61% live; the parser that said "21 criteria" had missed two
 order: 8
 owner: loop/openssf-gold
-pr:
+pr: 575
 title: OpenSSF gold — how far it goes without a second human
 ---
 Gold sat at <b>26%</b> with eleven criteria unanswered, and the standing assumption was that

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/openssf-silver.md

@@ -2,7 +2,7 @@
 id: openssf-silver
 board: code
 section: health
-status: inflight
+status: shipped
 category: Security · Posture
 complexity: S
 impact: Med
@@ -10,7 +10,7 @@ wow: 3
 note: 55 criteria, 31% → the gap was two documents, not fifty
 order: 7
 owner: loop/openssf-silver
-pr:
+pr: 567
 title: OpenSSF silver — reachable solo, and mostly already true
 ---
 Silver reads like a wall — <b>55 criteria</b> on top of passing — and the board showed 31%

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/osps-baseline-levels.md

@@ -2,7 +2,7 @@
 id: osps-baseline-levels
 board: code
 section: health
-status: inflight
+status: shipped
 category: Security · Posture
 complexity: M
 impact: Med
@@ -10,7 +10,7 @@ wow: 3
 note: L1 + L2 earned · L3 blocked · audit found a merged regression
 order: 5
 owner: loop/osps-baseline-2
-pr:
+pr: 565
 title: OSPS Baseline — three levels, audited rather than assumed
 ---
 The <a href="roadmap.html#openssf-best-practices-badge">passing badge</a> is one of

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/readme-prune-and-search-guide.md

@@ -2,7 +2,7 @@
 id: readme-prune-and-search-guide
 board: code
 section: health
-status: inflight
+status: shipped
 category: Docs · Onboarding
 complexity: S
 impact: Med
@@ -10,7 +10,7 @@ wow: 2
 note: 609 → 399 lines; 75 em dashes → 2; a real semantic-search guide
 order: 9
 owner: loop/docs-voice
-pr:
+pr: 579
 title: The README read like a machine wrote it — measurably
 ---
 The README had grown to <b>609 lines and 3,687 words of prose</b>, and it was carrying

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/search-and-browse-visual-refresh.md

@@ -2,7 +2,7 @@
 id: search-and-browse-visual-refresh
 board: code
 section: dx
-status: inflight
+status: shipped
 category: UX · Design
 complexity: M
 impact: High
@@ -11,6 +11,7 @@ note: search rows learned kind/tap/installed with a stated drop order; browse go
 order: 122
 owner: feat/tui-visual-refresh
 pr: 540
+pr: 540
 title: One design system across <code>search</code> and <code>browse</code>
 ---
 <b>The brief was "make the CLI look good", and the answer was a design pass,

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/serve-404-reflected-the-request.md

@@ -2,7 +2,7 @@
 id: serve-404-reflected-the-request
 board: code
 section: trust
-status: inflight
+status: shipped
 category: Security · Bug
 complexity: S
 impact: Med
@@ -11,6 +11,7 @@ note: the test suite pinned the echo in place as if it were the contract
 order: 97
 owner: loop/serve-no-reflected-request
 pr: 489
+pr: 489
 title: <code>boost serve</code> echoed the request path back into its 404 body
 ---
 <b>What happened.</b> <code>route()</code> unquotes the request path before matching, so

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/serve-is-a-searchable-catalogue.md

@@ -2,7 +2,7 @@
 id: serve-is-a-searchable-catalogue
 board: code
 section: dx
-status: inflight
+status: shipped
 category: DX · Feature
 complexity: L
 impact: High
@@ -10,6 +10,7 @@ wow: 5
 order: 108
 owner: loop/serve-searchable-catalogue
 pr: 492
+pr: 492
 note: the old page listed only what was installed — 147 rows out of 71,695 — with no search, no tags and no way to see what a tap actually is
 title: <code>boost serve</code> becomes a searchable, faceted catalogue with a graph of the taps
 ---

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/smart-rerank-pays-per-novel-query.md

@@ -2,7 +2,7 @@
 id: smart-rerank-pays-per-novel-query
 board: code
 section: dx
-status: inflight
+status: shipped
 category: Performance · MCP
 complexity: S
 impact: High
@@ -10,7 +10,7 @@ wow: 3
 note: MCP boost_search measured 11.7-17 s per call — every call, even a repeat of the last one
 order: 123
 owner: loop/search-perf
-pr:
+pr: 543
 title: The smart rerank pays the LLM again for a search it already answered
 ---
 The MCP <code>boost_search</code> path passes <code>smart=True</code> on every

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/sweep-died-at-launch-not-at-a-page.md

@@ -2,7 +2,7 @@
 id: sweep-died-at-launch-not-at-a-page
 board: code
 section: pipeline
-status: inflight
+status: shipped
 category: CI · Bug
 complexity: S
 impact: High
@@ -10,7 +10,7 @@ wow: 4
 note: a comment in the sibling file predicted this exact failure
 order: 114
 owner: fix/visual-sweep-single-process
-pr:
+pr: 524
 title: The <code>sweep</code> gate died at browser launch, not at a page
 ---
 Every <code>sweep</code> run failed from 2026-08-15 onward — on <code>main</code>

{boost_skill_cli-1.2.60 → boost_skill_cli-1.2.62}/docs/roadmap/items/taps-check-out-freight-they-never-index.md

@@ -2,7 +2,7 @@
 id: taps-check-out-freight-they-never-index
 board: code
 section: internals
-status: inflight
+status: shipped
 category: Storage · Footprint
 complexity: M
 impact: High
@@ -10,7 +10,7 @@ wow: 4
 note: 458 taps held 12 GB to index 1.9 GB of Markdown
 order: 112
 owner: loop/sparse-tap-clones
-pr:
+pr: 520
 title: Taps download and check out the 84% of a repo that boost never opens
 ---
 <b>Measured on a real install, not estimated.</b> <code>~/.boost</code> had grown to