boost-skill-cli 1.0.446__tar.gz → 1.0.448__tar.gz

{boost_skill_cli-1.0.446/boost_skill_cli.egg-info → boost_skill_cli-1.0.448}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.446
+Version: 1.0.448
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.446 → boost_skill_cli-1.0.448}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.0.446'
-__version_tuple__ = version_tuple = (1, 0, 446)
+__version__ = version = '1.0.448'
+__version_tuple__ = version_tuple = (1, 0, 448)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.446 → boost_skill_cli-1.0.448}/boost_cli/core/dense.py

@@ -17,6 +17,7 @@ import json
 import sqlite3
 from pathlib import Path
 
+from ..errors import BoostError
 from . import catalog, embed, paths
 from .rag import Hit, chunk, entry_key, read_body
 
@@ -385,29 +386,57 @@ def export_shard(tap: str) -> dict:
     the embedding space that produced them, so provider/model/dim have to travel
     with the rows, and the registry commit has to travel too or a stale shard
     would be indistinguishable from a current one.
+
+    Raises :class:`BoostError` when the rows are present and unreadable, which is
+    a different problem from having none — see below.
     """
-    # Plain sqlite3, NOT _connect: exporting reads `chunks`, `meta` and the
-    # stored embedding blobs, all ordinary tables. Routing through _connect
-    # would make export impossible without the sqlite-vec extension — the same
-    # trap `_recorded_meta` documents — and a machine that built vectors and
-    # then dropped the extra is exactly the one whose shard is worth having.
     if not db_path().exists():
         return {"tap": tap, "chunks": []}
-    try:
-        con = sqlite3.connect(str(db_path()))
-    except sqlite3.Error:
-        return {"tap": tap, "chunks": []}
+    # `vec_chunks` is a vec0 VIRTUAL table, so reading an embedding needs the
+    # extension loaded: on a plain connection the join below raises `no such
+    # module: vec0`, every time, for every tap. An earlier revision opened
+    # plainly on the theory that export "reads ordinary tables" — true of
+    # `chunks` and `meta`, false of the one relation holding the vectors — and
+    # the resulting failure was swallowed into an empty shard. That is why no
+    # scheduled `shards` run has ever produced an artifact. Fall back to a plain
+    # connection anyway: it still serves a store whose vectors live in an
+    # ordinary table, and it is what makes the distinction below observable
+    # rather than an exception from the connect call.
+    con = _connect()
+    if con is None:
+        try:
+            con = sqlite3.connect(str(db_path()))
+        except sqlite3.Error:
+            return {"tap": tap, "chunks": []}
     try:
         meta = _read_meta(con)
         commits = meta.get("commits")
         commit = ""
         if isinstance(commits, dict):
             commit = str(commits.get(tap.replace("/", "__")) or "")
+        # `chunks` alone, first, because it is an ordinary table and therefore
+        # always readable. It answers the question the caller's error message
+        # depends on: are there rows for this tap at all?
+        expected = _tap_chunk_count(con, tap)
         chunks = []
-        for row in con.execute(
+        try:
+            rows = con.execute(
                 "SELECT c.name, c.tap, c.path, c.kind, c.cix, c.snip, v.embedding "
                 "FROM chunks c JOIN vec_chunks v ON v.rowid = c.id "
-                "WHERE c.tap = ? ORDER BY c.id", (tap,)):
+                "WHERE c.tap = ? ORDER BY c.id", (tap,)).fetchall()
+        except sqlite3.Error as exc:
+            # Only a tap that HAS chunks can have unreadable ones. With none,
+            # the vector relation not resolving says nothing about this tap —
+            # it is the ordinary "nothing built here" case, and the caller's
+            # "build them first" is the right answer.
+            if not expected:
+                return {"tap": tap, "chunks": []}
+            raise _unreadable_vectors(tap, expected, exc) from exc
+        if expected and not rows:
+            # The join resolved but produced nothing for a tap that has chunks:
+            # the vector rows are gone or unlinked. Still not "never built".
+            raise _unreadable_vectors(tap, expected, None)
+        for row in rows:
             name, ctap, path, kind, cix, snip, emb = row
             chunks.append({
                 "name": name, "tap": ctap, "path": path, "kind": kind,
@@ -420,12 +449,43 @@ def export_shard(tap: str) -> dict:
                 "provider": meta.get("provider"), "model": meta.get("model"),
                 "dim": meta.get("dim"), "version": INDEX_VERSION,
                 "chunks": chunks}
-    except sqlite3.Error:
-        return {"tap": tap, "chunks": []}
     finally:
         con.close()
 
 
+def _tap_chunk_count(con: sqlite3.Connection, tap: str) -> int:
+    """How many chunk rows this tap has, or 0 when `chunks` is unreadable.
+
+    Deliberately forgiving: a store with no `chunks` table has nothing built,
+    which is the ordinary empty case rather than the corrupt one.
+    """
+    try:
+        row = con.execute("SELECT COUNT(*) FROM chunks WHERE tap = ?",
+                          (tap,)).fetchone()
+    except sqlite3.Error:
+        return 0
+    return int(row[0]) if row else 0
+
+
+def _unreadable_vectors(tap: str, expected: int,
+                        exc: sqlite3.Error | None) -> BoostError:
+    """The error for "the rows are there, and this process cannot read them".
+
+    Kept apart from the empty case on purpose. Both used to surface as `no
+    vectors for <tap>` with the hint `build them first with reindex --dense` —
+    advice that is correct for an unbuilt store and a dead end for this one,
+    because `reindex --dense` is what wrote the rows the message says are
+    missing. Two scheduled `shards` runs died against that loop.
+    """
+    detail = ": %s" % exc if exc is not None else ""
+    return BoostError(
+        "%s has %d embedded chunk%s but its vectors cannot be read%s"
+        % (tap, expected, "" if expected == 1 else "s", detail),
+        hint="reading vectors needs the sqlite-vec extension — install the "
+             "`rag` extra (`pip install 'boost-skill-cli[rag]'`); the rows "
+             "themselves are intact, so no re-embedding is required")
+
+
 def import_shard(shard: dict, commit: str) -> tuple[bool, str]:
     """Merge a prebuilt shard into this machine's store. ``(ok, reason)``.
 

{boost_skill_cli-1.0.446 → boost_skill_cli-1.0.448/boost_skill_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.446
+Version: 1.0.448
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.446 → boost_skill_cli-1.0.448}/boost_skill_cli.egg-info/SOURCES.txt

@@ -385,6 +385,7 @@ docs/roadmap/items/self-update-broken-for-pip-pipx-installs.md
 docs/roadmap/items/serve-404-reflected-the-request.md
 docs/roadmap/items/serve-is-a-searchable-catalogue.md
 docs/roadmap/items/serve-py-traversal-guards-untested.md
+docs/roadmap/items/shards-pipeline-never-produced-a-shard.md
 docs/roadmap/items/shift-left-gate-pre-commit-pre-commit-ci.md
 docs/roadmap/items/single-imperative-rule-extractor.md
 docs/roadmap/items/single-tech-stack-prober.md
@@ -583,6 +584,8 @@ tests/unit/test_demo_index.py
 tests/unit/test_dense.py
 tests/unit/test_dense_fallback.py
 tests/unit/test_dense_fix_hint.py
+tests/unit/test_dense_shard_real_schema.py
+tests/unit/test_dense_shard_unreadable_vectors.py
 tests/unit/test_dense_shards.py
 tests/unit/test_dense_status.py
 tests/unit/test_dependabot_config.py
@@ -664,6 +667,7 @@ tests/unit/test_secretscan.py
 tests/unit/test_selfupdate.py
 tests/unit/test_serve.py
 tests/unit/test_serve_docs.py
+tests/unit/test_shards_matrix.py
 tests/unit/test_smoke_covers_every_command.py
 tests/unit/test_spin.py
 tests/unit/test_stackprobe.py

boost_skill_cli-1.0.448/docs/roadmap/items/shards-pipeline-never-produced-a-shard.md

@@ -0,0 +1,78 @@
+---
+id: shards-pipeline-never-produced-a-shard
+board: code
+section: internals
+status: shipped
+category: Build · Bug
+complexity: M
+impact: High
+wow: 4
+note: two scheduled runs, 0 artifacts — 40 of 60 jobs tapped a bare SHA, and the other 20 hit an export that cannot work
+order: 105
+owner: fix/shards-pipeline
+pr:
+title: The shards workflow has never once produced a shard
+---
+<code>shards.yml</code> publishes prebuilt dense-vector shards so a keyless user gets semantic search
+without paying to embed the catalogue — measured at <b>~1.2&nbsp;s/chunk</b> on CPU, 74 minutes for
+743 entries, which is what makes step 2 of the keyless epic a requirement rather than an
+optimisation. It has run twice on its weekly schedule, <b>2026-08-02</b> and <b>2026-08-09</b>, and
+uploaded <b>nothing</b> either time. Two independent bugs, one in the workflow and one in the engine,
+and a scheduled job is exactly where two of those can sit unnoticed: nobody is waiting on a cron.
+
+<b>First bug — the matrix is fields, not rows.</b> A <code>tests/eval/taps.txt</code> row is
+<code>owner/repo &lt;40-char sha&gt; &lt;entry count&gt;</code>, and the plan step built its matrix
+with <code>grep -v '^#' tests/eval/taps.txt | tr '\n' ' '</code> and then split on whitespace. That
+does not split the file into rows, it splits it into <b>fields</b>: twenty registries became a
+<b>sixty</b>-entry matrix — twenty repos, twenty bare SHAs and twenty integers, each dispatched to a
+job that ran <code>boost tap</code> on it. The run is full of <code>build (18)</code>,
+<code>build (1616)</code> and
+<code>build (b29e7cf65e5cb78a5ac33d582270551bc74a14eb)</code>. Two thirds of the fleet could never
+do anything but fail.
+
+<code>scripts/eval_corpus.parse_taps</code> already parses this format correctly and is already
+tested — the workflow had reimplemented it in one line of shell and got it wrong. It now calls
+<code>--list-repos</code>, a new flag that prints one name per line, so the row/field distinction is
+made once in tested Python instead of re-decided in <code>bash</code>. Deliberately <i>not</i>
+<code>--list</code>, which also prints the SHA and count: a caller that splits <i>that</i> on
+whitespace reproduces the bug exactly.
+
+<b>Second bug — the export cannot succeed, on any machine.</b> The twenty real registries got past
+<code>tap and embed</code> and died in <code>export the shard</code> with
+<code>no vectors for 'anthropics/skills'</code>, whose hint reads <i>build them first with
+<code>boost reindex --dense</code></i> — the step that had just run, green, in the line above.
+<code>dense.export_shard</code> opened the store with a <b>plain</b> <code>sqlite3</code> connection
+on the stated theory that it "reads <code>chunks</code>, <code>meta</code> and the stored blobs, all
+ordinary tables". True of the first two; false of the third. <code>vec_chunks</code> is a
+<b><code>vec0</code> virtual table</b>, so the join raises <code>no such module: vec0</code> — always,
+every tap — and <code>except sqlite3.Error</code> turned that into <code>chunks: []</code>.
+
+Proven rather than reasoned: build a store through the real path, reopen it plainly, and the join
+raises <code>OperationalError: no such module: vec0</code>. The comment was an accurate description
+of an intention and an inaccurate one of the code.
+
+<b>Why the test suite was no help — the fixture disagreed with production in the one way that
+mattered.</b> Every shard test hand-builds its store with <code>CREATE TABLE vec_chunks</code>, an
+<i>ordinary</i> table, and <code>with_backend</code> patches <code>_connect</code> to a plain
+connection. Both are fair shortcuts for tests about validation. Together they mean no test in that
+file ever met a virtual table, so <b>twenty passing tests coexisted with a feature that had never
+worked</b>. There is even a class named <code>TestWorksWithoutTheExtension</code> asserting the
+false claim — written, its docstring says, after an earlier version shipped broken the opposite way.
+That is the shape to remember: the first fix traded a failure that was loud for one that was silent,
+and the fixture blessed it.
+
+<b>Fixed by separating two states the old code collapsed.</b> <code>chunks</code> is an ordinary
+table and always readable, so it can answer "are there rows for this tap at all?" before the join is
+attempted. No rows means the shard is empty and <i>"build them first"</i> is right. Rows present but
+unreadable is a different problem with a different fix, and now says so, naming the
+<code>sqlite-vec</code> extension and stating that <b>no re-embedding is required</b> — the rows are
+intact. Sending someone back to a 74-minute embed to solve a missing dependency is the part that
+cost two runs.
+
+<b>Both halves are pinned, and one of them runs without the extra.</b>
+<code>test_dense_shard_real_schema.py</code> builds through <code>_ensure_schema</code> and the real
+<code>vec0</code> table — the only test here that failed before the fix — but it <i>skips</i> without
+<code>sqlite-vec</code>, which would leave a bare runner blind.
+<code>test_dense_shard_unreadable_vectors.py</code> pins the same contract with nothing installed, by
+presenting the store as a plain connection sees it: ordinary tables readable, vector relation not
+resolving. Both were run against the pre-fix code and both go red, so neither is decorative.

{boost_skill_cli-1.0.446 → boost_skill_cli-1.0.448}/docs/roadmap.html

@@ -133,7 +133,7 @@
       <div class="stat"><b>16</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>7</b><span>Planned</span></div>
-      <div class="stat"><b>243</b><span>Loop finds</span></div>
+      <div class="stat"><b>244</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -3791,6 +3791,81 @@ looking is worse than no guard, because the green tick still appears.</p></detai
         </div>
       </article>
 
+      <article class="cap rcard" id="shards-pipeline-never-produced-a-shard">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Build · Bug</span></div>
+        <h3>The shards workflow has never once produced a shard</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><code>shards.yml</code> publishes prebuilt dense-vector shards so a keyless user gets semantic search
+without paying to embed the catalogue — measured at <b>~1.2&nbsp;s/chunk</b> on CPU, 74 minutes for
+743 entries, which is what makes step 2 of the keyless epic a requirement rather than an
+optimisation. It has run twice on its weekly schedule, <b>2026-08-02</b> and <b>2026-08-09</b>, and
+uploaded <b>nothing</b> either time. Two independent bugs, one in the workflow and one in the engine,
+and a scheduled job is exactly where two of those can sit unnoticed: nobody is waiting on a cron.
+
+<b>First bug — the matrix is fields, not rows.</b> A <code>tests/eval/taps.txt</code> row is
+<code>owner/repo &lt;40-char sha&gt; &lt;entry count&gt;</code>, and the plan step built its matrix
+with <code>grep -v '^#' tests/eval/taps.txt | tr '\n' ' '</code> and then split on whitespace. That
+does not split the file into rows, it splits it into <b>fields</b>: twenty registries became a
+<b>sixty</b>-entry matrix — twenty repos, twenty bare SHAs and twenty integers, each dispatched to a
+job that ran <code>boost tap</code> on it. The run is full of <code>build (18)</code>,
+<code>build (1616)</code> and
+<code>build (b29e7cf65e5cb78a5ac33d582270551bc74a14eb)</code>. Two thirds of the fleet could never
+do anything but fail.
+
+<code>scripts/eval_corpus.parse_taps</code> already parses this format correctly and is already
+tested — the workflow had reimplemented it in one line of shell and got it wrong. It now calls
+<code>--list-repos</code>, a new flag that prints one name per line, so the row/field distinction is
+made once in tested Python instead of re-decided in <code>bash</code>. Deliberately <i>not</i>
+<code>--list</code>, which also prints the SHA and count: a caller that splits <i>that</i> on
+whitespace reproduces the bug exactly.
+
+<b>Second bug — the export cannot succeed, on any machine.</b> The twenty real registries got past
+<code>tap and embed</code> and died in <code>export the shard</code> with
+<code>no vectors for 'anthropics/skills'</code>, whose hint reads <i>build them first with
+<code>boost reindex --dense</code></i> — the step that had just run, green, in the line above.
+<code>dense.export_shard</code> opened the store with a <b>plain</b> <code>sqlite3</code> connection
+on the stated theory that it "reads <code>chunks</code>, <code>meta</code> and the stored blobs, all
+ordinary tables". True of the first two; false of the third. <code>vec_chunks</code> is a
+<b><code>vec0</code> virtual table</b>, so the join raises <code>no such module: vec0</code> — always,
+every tap — and <code>except sqlite3.Error</code> turned that into <code>chunks: []</code>.
+
+Proven rather than reasoned: build a store through the real path, reopen it plainly, and the join
+raises <code>OperationalError: no such module: vec0</code>. The comment was an accurate description
+of an intention and an inaccurate one of the code.
+
+<b>Why the test suite was no help — the fixture disagreed with production in the one way that
+mattered.</b> Every shard test hand-builds its store with <code>CREATE TABLE vec_chunks</code>, an
+<i>ordinary</i> table, and <code>with_backend</code> patches <code>_connect</code> to a plain
+connection. Both are fair shortcuts for tests about validation. Together they mean no test in that
+file ever met a virtual table, so <b>twenty passing tests coexisted with a feature that had never
+worked</b>. There is even a class named <code>TestWorksWithoutTheExtension</code> asserting the
+false claim — written, its docstring says, after an earlier version shipped broken the opposite way.
+That is the shape to remember: the first fix traded a failure that was loud for one that was silent,
+and the fixture blessed it.
+
+<b>Fixed by separating two states the old code collapsed.</b> <code>chunks</code> is an ordinary
+table and always readable, so it can answer "are there rows for this tap at all?" before the join is
+attempted. No rows means the shard is empty and <i>"build them first"</i> is right. Rows present but
+unreadable is a different problem with a different fix, and now says so, naming the
+<code>sqlite-vec</code> extension and stating that <b>no re-embedding is required</b> — the rows are
+intact. Sending someone back to a 74-minute embed to solve a missing dependency is the part that
+cost two runs.
+
+<b>Both halves are pinned, and one of them runs without the extra.</b>
+<code>test_dense_shard_real_schema.py</code> builds through <code>_ensure_schema</code> and the real
+<code>vec0</code> table — the only test here that failed before the fix — but it <i>skips</i> without
+<code>sqlite-vec</code>, which would leave a bare runner blind.
+<code>test_dense_shard_unreadable_vectors.py</code> pins the same contract with nothing installed, by
+presenting the store as a plain connection sees it: ordinary tables readable, vector relation not
+resolving. Both were run against the pre-fix code and both go red, so neither is decorative.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">two scheduled runs, 0 artifacts — 40 of 60 jobs tapped a bare SHA, and the other 20 hit an export that cannot work</span>
+        </div>
+      </article>
+
       <article class="cap rcard" id="sync-could-not-repair-a-gutted-skill">
         <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Bug</span></div>
         <h3>The repair command could not repair the thing two commands sent you to it for</h3>

{boost_skill_cli-1.0.446 → boost_skill_cli-1.0.448}/scripts/eval_corpus.py

@@ -548,6 +548,9 @@ def main(argv: list[str] | None = None) -> int:
                    help="static concentration/count checks, no network")
     p.add_argument("--list", action="store_true",
                    help="print the parsed rows and exit")
+    p.add_argument("--list-repos", action="store_true",
+                   help="print one owner/repo per line and exit (a matrix "
+                        "source that cannot be field-split by mistake)")
     p.add_argument("--taps", metavar="PATH", default=str(DEFAULT_TAPS),
                    help="corpus list to act on (default the required corpus; "
                         "%s is the scale tier)" % SCALE_TAPS.name)
@@ -555,6 +558,14 @@ def main(argv: list[str] | None = None) -> int:
     taps = Path(args.taps)
     if not taps.is_file():
         raise SystemExit("no such corpus list: %s" % taps)
+    if args.list_repos:
+        # Names only, one per line. `--list` prints the SHA and count too, and
+        # a caller that splits THAT on whitespace gets three matrix entries per
+        # row — which is exactly how shards.yml ended up dispatching 60 jobs
+        # for 20 registries, two thirds of them tapping a bare SHA or integer.
+        for repo, _sha, _count in parse_taps(taps.read_text(encoding="utf-8")):
+            print(repo)
+        return 0
     if args.list:
         for repo, sha, count in parse_taps(taps.read_text(encoding="utf-8")):
             print("%s %s %s" % (repo, sha or "", "" if count is None else count))
@@ -567,7 +578,8 @@ def main(argv: list[str] | None = None) -> int:
         return _ensure(taps, relock=True)
     if args.ensure:
         return _ensure(taps)
-    p.error("provide --ensure, --relock, --refresh, --audit or --list")
+    p.error("provide --ensure, --relock, --refresh, --audit, --list "
+            "or --list-repos")
     return 2
 
 

boost_skill_cli-1.0.448/tests/unit/test_dense_shard_real_schema.py

@@ -0,0 +1,155 @@
+"""Unit tests: export a shard from the schema production actually writes.
+
+Every other shard test builds its fixture by hand, and every one of them makes
+``vec_chunks`` an **ordinary** table. That is a fair shortcut for tests about
+validation, and it is also why the shard feature could ship broken twice: the
+real :func:`dense._ensure_schema` writes
+
+    CREATE VIRTUAL TABLE vec_chunks USING vec0(embedding float[N] ...)
+
+and a virtual table is exactly the thing a hand-rolled ``CREATE TABLE`` fixture
+cannot stand in for. Against the fixture a plain connection reads the join
+happily; against the real store it raises ``no such module: vec0``.
+
+So this file refuses to hand-build anything. It creates the store through
+``dense._connect`` and ``dense._ensure_schema`` — the production path — and then
+asks for a shard. It is the only test here that would have failed before the
+fix, and the only one that will fail if the storage layer moves again.
+
+It **skips without ``sqlite-vec``**, which is the honest cost of testing the real
+schema and the reason it is not the whole defence:
+``test_dense_shard_unreadable_vectors.py`` pins the same contract with no extra
+installed, so a runner that skips this file is still not blind. Do not "fix" the
+skip by faking the extension — a fake vec0 is the fixture that hid the bug.
+"""
+from __future__ import annotations
+
+import json
+
+import pytest
+
+from boost_cli.core import dense, paths
+
+sqlite_vec = pytest.importorskip(
+    "sqlite_vec",
+    reason="the real vec0 schema needs the [rag] extra; the contract is also "
+           "pinned extension-free in test_dense_shard_unreadable_vectors.py")
+
+
+def _extension_loadable() -> bool:
+    """True when this interpreter can actually create a vec0 table.
+
+    Importing ``sqlite_vec`` is NOT enough, and assuming it was reddened all
+    three macOS legs of PR #503 with ``sqlite-vec imported but _connect returned
+    None``. Loading an extension needs
+    ``sqlite3.Connection.enable_load_extension``, which CPython only exposes
+    when its bundled SQLite was built with extension support — macOS builds
+    routinely are not. So the package imports, ``dense._load()`` returns it, and
+    ``dense._connect()`` still returns ``None``.
+
+    Probe the capability rather than a proxy for it: build the thing these tests
+    need and see whether it works. Exactly the mistake this file exists to
+    correct, one level up — a fixture that stood in for the real schema is what
+    hid the bug, and an import that stood in for the real capability is what
+    broke the fix.
+    """
+    import sqlite3
+    con = sqlite3.connect(":memory:")
+    try:
+        con.enable_load_extension(True)
+        sqlite_vec.load(con)
+        con.execute("CREATE VIRTUAL TABLE t USING vec0(embedding float[2])")
+        return True
+    except (AttributeError, sqlite3.Error):
+        return False
+    finally:
+        con.close()
+
+
+pytestmark = pytest.mark.skipif(
+    not _extension_loadable(),
+    reason="this interpreter cannot load sqlite extensions (macOS CPython is "
+           "commonly built without support), so the real vec0 schema is "
+           "unreachable — the extension-free half of the contract still runs "
+           "in test_dense_shard_unreadable_vectors.py")
+
+DIM = 4
+
+
+def _production_store(tap: str = "acme/skills", rows: int = 2):
+    """A store built the way `dense.build` builds one — vec0 and all."""
+    paths.ensure_dirs()
+    con = dense._connect()
+    # The module-level skipif already proved the extension loads here, so a
+    # None now is a real regression in _connect rather than a missing extra.
+    assert con is not None, \
+        "_connect returned None although vec0 loads on this interpreter"
+    try:
+        dense._ensure_schema(con, DIM)
+        for i in range(rows):
+            cur = con.execute(
+                "INSERT INTO chunks (name, tap, path, kind, cix, snip) "
+                "VALUES (?, ?, ?, ?, ?, ?)",
+                ("skill-%d" % i, tap, "skill-%d/SKILL.md" % i, "skill", 0,
+                 "snippet %d" % i))
+            con.execute(
+                "INSERT INTO vec_chunks (rowid, embedding) VALUES (?, ?)",
+                (cur.lastrowid,
+                 sqlite_vec.serialize_float32([0.1 * (i + 1)] * DIM)))
+        meta = {"version": dense.INDEX_VERSION, "provider": "local",
+                "model": "bge-small-en-v1.5", "dim": DIM,
+                "commits": {tap.replace("/", "__"): "c0ffee"}}
+        con.executemany("INSERT OR REPLACE INTO meta (k, v) VALUES (?, ?)",
+                        [(k, json.dumps(v)) for k, v in meta.items()])
+        con.commit()
+    finally:
+        con.close()
+
+
+class TestExportAgainstTheRealSchema:
+    """The regression. Before the fix every assertion here failed."""
+
+    def test_a_shard_carries_the_rows(self, sandbox):
+        _production_store(rows=2)
+        assert len(dense.export_shard("acme/skills")["chunks"]) == 2
+
+    def test_a_shard_carries_its_provenance(self, sandbox):
+        # shards.yml asserts on exactly these four before it uploads, so an
+        # export that returns rows without them still fails the workflow.
+        _production_store()
+        shard = dense.export_shard("acme/skills")
+        for field in ("provider", "model", "dim", "commit"):
+            assert shard.get(field), "%s missing from %r" % (field, shard)
+
+    def test_the_embeddings_survive_the_round_trip(self, sandbox):
+        import base64
+        _production_store(rows=1)
+        blob = dense.export_shard("acme/skills")["chunks"][0]["embedding"]
+        assert len(base64.b64decode(blob)) == 4 * DIM
+
+    def test_the_shard_is_json_serialisable(self, sandbox):
+        # It is written to a file by `reindex --export-shard` and uploaded.
+        _production_store()
+        json.dumps(dense.export_shard("acme/skills"))
+
+    def test_a_tap_with_no_rows_is_empty_not_an_error(self, sandbox):
+        # Same degradation as everywhere else, now confirmed on the real
+        # schema rather than inferred from the stand-in.
+        _production_store()
+        assert dense.export_shard("nobody/nothing")["chunks"] == []
+
+
+class TestExportedShardImportsBack:
+    """End-to-end on the real schema: what CI publishes, a user can consume."""
+
+    def test_a_real_shard_is_accepted_by_import(self, sandbox):
+        _production_store(rows=2)
+        shard = dense.export_shard("acme/skills")
+        ok, reason = dense.import_shard(shard, commit="c0ffee")
+        assert ok, reason
+
+    def test_the_imported_rows_come_back_out_again(self, sandbox):
+        _production_store(rows=2)
+        shard = dense.export_shard("acme/skills")
+        dense.import_shard(shard, commit="c0ffee")
+        assert len(dense.export_shard("acme/skills")["chunks"]) == 2

boost_skill_cli-1.0.448/tests/unit/test_dense_shard_unreadable_vectors.py

@@ -0,0 +1,109 @@
+"""Unit tests: exporting a shard must not report "no vectors" when there are.
+
+``vec_chunks`` is a **vec0 virtual table**. A plain :mod:`sqlite3` connection has
+no such module, so any statement touching it raises
+``OperationalError: no such module: vec0`` — and :func:`dense.export_shard` used
+to catch ``sqlite3.Error`` and return ``{"chunks": []}``, which the command layer
+turns into::
+
+    no vectors for 'anthropics/skills'
+    hint: build them first with `boost reindex --dense`
+
+The hint names the step that had *just* run. Every scheduled ``shards`` run has
+died there — 2026-08-02 and 2026-08-09, 20 of 20 registries, "tap and embed"
+green and "export the shard" red — so the prebuilt-shard feature has never once
+produced an artifact.
+
+The existing suite could not see it. ``test_dense_shards._store`` builds
+``vec_chunks`` with ``CREATE TABLE`` — an ordinary table a plain connection reads
+happily — and its ``with_backend`` fixture patches ``_connect`` to a plain
+connection. Both are reasonable shortcuts for tests about *validation*, and
+together they mean no test in that file exercises the schema production actually
+writes. This file covers the gap from the other side, without needing the
+extension installed: from a plain connection's point of view a vec0 table is
+precisely "a relation I cannot read", which is what is simulated here.
+
+The distinction being pinned is between two states the old code collapsed:
+
+* the tap genuinely has no rows — empty shard, and "run reindex" is right;
+* the rows are there and cannot be read — a different problem with a different
+  fix, and answering it with "run reindex" sends the reader back round a loop
+  they have already completed.
+"""
+from __future__ import annotations
+
+import json
+import sqlite3
+
+import pytest
+
+from boost_cli.core import dense, paths
+from boost_cli.errors import BoostError
+
+
+def _store_with_unreadable_vectors(rows=(("a", "acme/skills"),), dim=3):
+    """``chunks`` populated, ``vec_chunks`` absent.
+
+    Stands in for the real store as a plain connection sees it: the ordinary
+    tables read fine and the vector relation does not resolve. Whether that is
+    ``no such module: vec0`` (production) or ``no such table`` (here) is the
+    same ``sqlite3.OperationalError`` reaching the same handler.
+    """
+    paths.ensure_dirs()
+    con = sqlite3.connect(str(dense.db_path()))
+    try:
+        con.execute("CREATE TABLE IF NOT EXISTS chunks ("
+                    "id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, tap TEXT,"
+                    " path TEXT, kind TEXT, cix INTEGER, snip TEXT)")
+        con.execute("CREATE TABLE IF NOT EXISTS meta (k TEXT PRIMARY KEY, v TEXT)")
+        for name, tap in rows:
+            con.execute(
+                "INSERT INTO chunks (name, tap, path, kind, cix, snip) "
+                "VALUES (?, ?, ?, ?, 0, ?)",
+                (name, tap, "%s/SKILL.md" % name, "skill", "snip"))
+        meta = {"version": dense.INDEX_VERSION, "provider": "local",
+                "model": "bge", "dim": dim, "commits": {"acme__skills": "c1"}}
+        con.executemany("INSERT OR REPLACE INTO meta (k, v) VALUES (?, ?)",
+                        [(k, json.dumps(v)) for k, v in meta.items()])
+        con.commit()
+    finally:
+        con.close()
+
+
+class TestUnreadableVectorsAreReportedNotSwallowed:
+    def test_export_raises_instead_of_returning_an_empty_shard(self, sandbox):
+        _store_with_unreadable_vectors()
+        with pytest.raises(BoostError):
+            dense.export_shard("acme/skills")
+
+    def test_the_message_does_not_tell_the_user_to_reindex(self, sandbox):
+        # THE WHOLE POINT. `reindex --dense` is what produced these rows; being
+        # sent back to it is what made the CI failure unreadable for two runs.
+        _store_with_unreadable_vectors()
+        with pytest.raises(BoostError) as caught:
+            dense.export_shard("acme/skills")
+        advice = "%s %s" % (caught.value, getattr(caught.value, "hint", "") or "")
+        assert "reindex" not in advice.lower(), advice
+
+    def test_the_message_names_the_vector_backend(self, sandbox):
+        # The actual fix is the sqlite-vec extension, so the text has to point
+        # there — a bare "cannot read" would leave the reader nowhere.
+        _store_with_unreadable_vectors()
+        with pytest.raises(BoostError) as caught:
+            dense.export_shard("acme/skills")
+        advice = ("%s %s" % (caught.value,
+                             getattr(caught.value, "hint", "") or "")).lower()
+        assert "sqlite-vec" in advice or "rag" in advice, advice
+
+
+class TestTheGenuinelyEmptyCasesStillDegrade:
+    """Only the unreadable case became an error. The rest must not regress."""
+
+    def test_no_store_at_all_is_still_an_empty_shard(self, sandbox):
+        assert dense.export_shard("acme/skills")["chunks"] == []
+
+    def test_a_tap_with_no_rows_is_still_an_empty_shard(self, sandbox):
+        # `chunks` is readable and simply has nothing for this tap. Here
+        # "build them first" IS the right advice, so this must not raise.
+        _store_with_unreadable_vectors(rows=(("a", "acme/skills"),))
+        assert dense.export_shard("nobody/nothing")["chunks"] == []