living document · updated by the quality loop

The boost roadmap

Every finding from the autonomous quality loop lands here — what shipped, what's mid-flight, and what's queued — scored by complexity, impact, and a little bit of wow.

See what's next → Back to the guide
Shipped merged & released In flight a PR is open Next triaged, starting soon Planned on the list
27Shipped
1Next up
75Planned
523Loop finds

Shipped

// merged to main & published
ShippedLicensing

The copyleft protected nothing and cost the one thing boost needs

Write-up · relicence-apache-2.md

Complexity M Impact High Wow ★★★★ GPL-3.0-only → Apache-2.0, while it was still a one-person decision
ShippedAgents · Parity

bmad on knew about a second host and wrote to one anyway

Write-up · bmad-hooks-all-hosts.md

Complexity S Impact Med Wow ★★★ the autopilot wrote hooks to Claude and nowhere else, long after boost knew a second host
ShippedAgents · Parity

A Gemini user got the heuristic fallback from every AI command

Write-up · ai-backend-fanout.md

Complexity S Impact High Wow ★★★★ the last surface that only spoke Claude — and the one a user can see
ShippedQuality · CLI

All 80 boost commands audited against a disposable HOME — four defects fixed

Write-up · cli-command-audit.md

Complexity M Impact Med Wow ★★★ audited all 80 COMMANDS entries against a disposable HOME; 4 real defects fixed with tests
ShippedQuality · Retrieval eval

fix_hint's no-key guard has been unreachable since the day it was written; a missing API key now prescribes the full re-embed the guard exists to prevent

Write-up · dense-no-key-guard-is-unreachable.md

Complexity L Impact High Wow ★★★★ A complete [rag] extra falls through a missing key to the local model, so the ladder reaches provider-changed and prescribes the full re-embed the guard exists to prevent. Two things can displace a store, and the fix answers both.
ShippedQuality · Retrieval eval

The eval corpus's size and its concentration ceiling are counted with len(scan_dir) — the measure measure_registry.py exists to say is wrong — so 44.7% of the gate's corpus is vendored …

Write-up · eval-corpus-counted-by-the-method-the-repo-disavows.md

Complexity L Impact High Wow ★★★★ taps.txt rows gained a distinct-content count and the gate gained a second ceiling. The raw count stays — BM25 indexes without de-duplicating, so the copies really are documents — but sickn33 is 61.8% of the rows and 35.7% of the content, and only one number was being floored.
ShippedQuality · Retrieval eval

The 2026-09-01 pin refresh moved the corpus and re-baselined it, but nothing re-derives the floors — CLAUDE.md's "~10% under measured" is now 7.2%–17.3%

Write-up · eval-floor-calibration-stale-after-pin-refresh.md

Complexity M Impact Med Wow ★★★ CLAUDE.md states the gate's four floors sit "~10% under" measured values of 0.852 / 0…
ShippedQuality · Retrieval eval

The exemplar mechanism was applied to the ungated set only: golden.jsonl is 0/91 pinned, and 10 of its 44 hit@1 credits are on names the metric cannot adjudicate

Write-up · gated-golden-set-has-zero-exemplars.md

Complexity M Impact Med Wow ★★★ CLAUDE.md presents exemplar pinning as a live migration — "relevance is still decided…
ShippedTech-debt

The exemplar migration never reached the query set the required gate runs: 0 of 91 rows, and 27 of them have an ambiguous target on the gate's own corpus

Write-up · required-eval-gate-still-grades-by-name.md

Complexity M Impact Med Wow ★★★ CLAUDE.md states "Relevance is still decided by name (or by content class when a gold…
ShippedInstall · Research

Research: how boost install could tell that a skill needs something else installed first

Write-up · install-cannot-tell-a-skill-needs-another-one.md

Complexity M Impact Med Wow ★★★ The premise was wrong — boost has always followed requires:. It is the narrowest spelling in the ecosystem (101 values); skills: and dependencies: carry 2,388 more and were invisible.
ShippedQuality · Retrieval eval

A locally built vector store displaced by a new API key is told to re-embed through the paid provider, where unsetting the key is free

Write-up · dense-local-built-store-displaced-by-a-key.md

Complexity S Impact High Wow ★★★★ Exporting an API key takes a locally built store off the air, and doctor answers with a paid re-embed where `unset` is free. Every user who came in through `boost quickstart` is one `export` away from this.

Next up

// triaged findings, starting soon

Planned

// on the list
DeclinedTesting · Gap

Bring commands/ under mutation testing

The ~8,100-line command layer has zero mutation coverage: mutmut is scoped to core/ only. A blocking 80% floor was attempted and the baseline has now actually been measured — it does not clear the bar, and two of the three constraints recorded here earlier were wrong. What a sample run of commands/taps.py (the best-covered module in the package, 95.8% lines) against tests/unit/ + tests/functional/ reports through this repo's own gate: 570/793 killed — 71.9%, under the 80% floor, with all 223 survivors spread across every one of the module's 7 functions rather than concentrated in one testable gap. Mutant density is 4.2 per statement in taps.py but 2.46 across core/ (9,909 mutants over 4,033 statements), so commands/'s 5,314 statements imply somewhere between 13,000 and 22,300 mutants; at the measured 1.42 mutations/sec — roughly 6.5× slower per mutant than the core/ job, which matches the functional-vs-unit suite cost — that is 2.5 to 4.5 hours on one runner, against an ~18-minute job today. The job sets no timeout-minutes, so it inherits GitHub's 360-minute cap rather than failing fast. Two blockers sit underneath that number. Selecting only tests/unit/, the way core/ does, leaves commands/ at 17.9% line coverage versus 91.5% with functional included — and "no tests" mutants count against the score, so that route floors out near 18%. Selecting tests/functional/ instead crashes the run: mutmut's record_trampoline_hit calls p.resolve(strict=True) on the relative source path, so any test that chdirs into a temp project dies with FileNotFoundError: <tmp>/boost_cli — confirmed on test_verify_sees_a_project_skill. Corrections to the earlier note: pytest_add_cli_args_test_selection is not single-valued, it is a list that configparser splits on newlines (a space-separated line is what errors), and a sibling pytest_add_cli_args takes extra pytest flags. One prerequisite is already fixed: --no-mcp leaked through os.environ and made the suite order-dependent, which mutmut exposes because it runs whichever test subset covers each mutant. Declined 2026-07-29. Not "hard" — blocked, and the block is upstream. mutmut 3.6.0 is still the latest release, and src/mutmut/__main__.py:120 still reads source_paths = [p.resolve(strict=True) for p in Config.get().source_paths] — unconditionally, before the max_stack_depth guard — on paths that configuration.py:102 builds as plain relative Paths. Every chdir-ing functional test therefore kills the run, and the functional suite is precisely what takes commands/ from 17.9% to 91.5% line coverage. So the two candidate configurations are "floors out near 18%" and "crashes"; there is no third. Even granting a fix, the measured numbers already refuse the proposal on their own terms: 71.9% against an 80% blocking floor, with survivors spread evenly rather than pooled in one testable gap, at 2.5–4.5 hours per run against an ~18-minute job. A gate that is 8 points red on the day it lands does not gate anything; it just makes main red. The lead, if anyone reopens this: the crash is a relative-path bug, and source_paths is not required to be relative — an absolute path survives resolve(strict=True) from any working directory. Whether the rest of mutmut's mutants/ copy machinery tolerates one is untested. That, plus a non-blocking scheduled job that rotates one module per week, is the shape worth trying; a blocking 80% floor is not. What is not lost by declining. The architecture already puts behaviour in core/ — which is mutation-gated at 80% — and keeps commands/ as thin CLI glue. The uncovered layer is the one deliberately designed to hold the least logic, and it still carries 91.5% line coverage from the functional suite.

Complexity XL Impact High Wow ★★★ declined 2026-07-29 — 71.9% measured, and the run cannot complete at all
In flightQuality · Eval

a Tier 3 eval for tool-call behaviour, floored in both directions

boost's required gate floors four retrieval metrics — recall@k ≥ 0.78, hit@1 ≥ 0.40, MRR ≥ 0.52, nDCG@k ≥ 0.58 — over a 91-query golden set and a 10,152-entry corpus, every row pinned to a commit SHA. All of it measures what boost returns once it is asked. Nothing measures whether an agent asks. **The call itself is unmeasured**, and it is the step everything downstream depends on. The miss that exposed it. A Gemini CLI session was asked to "create a new, simplified app demonstrating RAG implementation in Python3 using langGraph, langChain, and langSmith" — a new project, an architecture decision and a dependency choice, which is three of the triggers boost_search's description names explicitly. It activated two already-installed skills, built the app, and never called boost. Asked why, it paraphrased boost's own lock-in trigger list back verbatim, so the text was read and was not persuasive. A gate that floors recall@k at 0.78 reported nothing, because retrieval was never invoked. Every claim in the MCP surface is argued, not measured. The triggers, the 10-15s stated cost, the skip list, the three-kind framing, the "already covered is not already checked" defeater — each survived a careful review and none has a number behind it. That is a high-variance lever tuned blind: Tool Preferences in Agentic LLMs are Unreliable (EMNLP 2025, arxiv 2505.18135) measures description-only edits swinging call rate by more than 10×. boost currently ships those edits on reasoning alone. The design constraint that decides whether this is worth building: floor both directions. A tier that measures call rate alone rewards making boost maximally assertive, which is precisely the capture the surface is written to avoid — and boost has already learned this exact lesson one tier down. Flooring recall alone was a hole rather than a simplification: a ranker that finds the right answer every time and never ranks it first scores recall@10 1.000 with hit@1 0.000, and passed. So the prompt set needs two halves — a should-call set (multi-file work, a new subsystem, a config or CI job that outlives the session) and a should-not-call set drawn from the shipped skip list (a question, a one-line edit, a command the user just handed over) — with a false-call ceiling as binding as the call-rate floor. One number without the other is an incentive to ship the thing boost refuses to be. Per host, never averaged. The two registered hosts do not see the same boost text. Claude Code puts server instructions in the system prompt; Gemini CLI never delivers them in interactive mode at all — Config.initialize() does not await mcpInitializationPromise, so getMcpInstructions() returns "", startChat stamps the context entry once with a stable id, and the later refreshMcpContext() re-renders Tier 1 only. A single averaged score would hide a host where 1,786 characters of guidance are simply absent, and would credit or blame wording for a delivery failure. Shape. An opt-in make eval-tools beside eval-ai / eval-rec / eval-explain — real hosts and real LLM calls, so it is non-deterministic and key-gated and must not join the required check gate; same degrade-cleanly contract as the other Tier 2 evals. Because the outcome is stochastic, report N runs per prompt with an interval rather than a single pass/fail, the way golden-set-statistical-power established for retrieval — a one-shot replay cannot tell a wording regression from a sampling wobble. Where this stands (2026-08-31), and a correction. The Claude Code arm shipped in #616: scripts/eval_tools.py, a 16-prompt set halved into should-call and should-NOT-call, Wilson intervals over N runs, and a verdict that floors call rate and ceilings false calls. Its probe was broken, and the finding this card recorded was an artifact of it. An earlier revision of this card reported “3/3 false calls — boost's tools fired on What is the difference between a Python list and a tuple?”. They did not fire. called_boost() substring-scanned the raw event stream, and claude -p --output-format stream-json --verbose opens with a system/init event enumerating every tool available to the session — which on any machine where boost is registered contains mcp__boost__boost_search and the other three CONSULT names. So the check returned true on every run, including runs with no tool call at all. Measured directly: Say OK and nothing else. produced zero tool_use blocks and scored as a boost consult. Two consequences shipped with it. make eval-tools could never pass — eight no-call rows × three runs is 24 forced trues, so the false-call rate's lower bound sat at 1.00 against a 0.20 ceiling, red on every machine forever. And the tier built to retire unfalsifiable claims had produced one. The lesson is the tier's own: the existing tests passed because they fed hand-written one-line fragments with no init event — a fixture the author invented could not catch the author's wrong model of the input. The probe now parses the NDJSON and counts only tool_use blocks inside assistant events, and the regression test drives a captured real stream. The second host arm is still unwritten, and should stay that way until the fixed probe is re-run. Building arm two on a probe that cannot tell an offer from a call would produce two hosts scoring an identical, meaningless 1.00. When it is built, the candidate is Gemini CLI proper, not Antigravity CLI: the delivery claim below is about Gemini's Node bundle, and agy is a third mode again — it receives boost's instructions and writes them to ~/.gemini/antigravity-cli/mcp/boost/instructions.md, pointing the agent at the file rather than inlining it. Substituting it would measure a different mechanism than the one this card argues about. Cost, now measured. Two trivial runs on a real host reported $0.657 and $0.682 of total_cost_usd, so 16 prompts × 3 runs is roughly $30–50 per host per invocation on a machine with a crowded tool surface. --strict-mcp-config with a boost-only config cuts that sharply and controls the surface confound in the same move. 2026-08-31: --strict-mcp-config shipped. eval_tools.py now takes a --strict-mcp-config flag: it writes a boost-only mcpServers config (the same <launcher> mcp --stdio invocation and fork-safety env core.mcphost.register_argv uses for a real registration — confirmed against an actual claude mcp add-json write, not guessed at the schema) to a temp file and passes --strict-mcp-config --mcp-config <path> to every claude -p call, cleaning the file up afterward. This session's sandbox had no network path to PyPI, so the pinned toolchain (pytest, ruff, mypy, …) could not be installed and make check could not be run here; the change was verified by hand instead — direct python3.12 import of the module, the new unit tests executed by eye against the interpreter, py_compile, a manual line-length check against ruff's 88-column default, and an end-to-end dry run with subprocess.run mocked that confirms the flags land on the argv and the temp file is created and removed. CI runs the real gate on the PR. Still unwritten: the second host arm (Gemini CLI). No gemini CLI was reachable in this sandbox to capture a real stream from, and building that arm on an invented model of Gemini's non-interactive output format is the exact mistake this card's own probe fix (2026-08-30) already paid for once — "a fixture the author invented cannot catch the author's wrong model of the input." That arm stays a placeholder until it can be built against a captured real stream, on a machine with the gemini CLI installed. What it unlocks. The first honest answer to "did that description edit help", a baseline the next surface change can regress against, and a way to retire claims that survive only because nobody can check them.

Complexity L Impact High Wow ★★★★ probe fixed; --strict-mcp-config shipped for the surface confound; second host (Gemini CLI) still unwritten
PlannedTech-debt

unpin the [eval] langchain stack when ragas ships its fix

The [eval] extra pins langchain-core<0.4, langchain-community<0.4 and langchain-openai<1 because ragas hard-imports ChatVertexAI from a langchain_community chat-models path that 0.4.x deleted. The LangChain integration card originally made this unpin its phase 0 and was corrected in place: ragas 0.4.3 still carries the import (measured 2026-08-04 — declared bounds are open, but import ragas crashes beside langchain 1.x), while upstream main already has the removal merged. So the unpin is one release of someone else's package away. What to do when it lands. Check pip index versions ragas (or the PyPI JSON) for a release after 0.4.3; verify in a throwaway venv that import ragas succeeds beside langchain>=1; then move [eval] to that floor, delete the three langchain pins, and adapt scripts/eval_explain.py if the 0.4 scoring API moved (its evaluate/to_pandas surface is what test_eval_faithfulness.py stubs in the unit suite). The eval-explain workflow is the live proof — it must stay green with real keys. Re-checked 2026-08-30. pip index versions ragas still reports 0.4.3 as the newest release, so nothing has changed and this card is still not claimable. Recorded here rather than left implicit: a card that says "check before starting" gives a reader no way to tell a check that came back negative from a check nobody ran. Why it stays its own card. The shipped integration card documents the block but will not be re-read; an unpin nobody remembers is how a workaround pin outlives its reason by years. This card is the reminder, and it is deliberately not claimable until the upstream release exists.

Complexity S Impact Low Wow ★ still blocked — re-checked 2026-08-30, PyPI's newest ragas is still 0.4.3
DeclinedRelease

give boost-langchain a release path to PyPI

Declined, deliberately. Both missing pieces below were owner-only or upstream-blocked, and the research they prompted dissolved the premise: a second PyPI project bought a separate release cadence nobody needed (boost releases more often than langchain), while the ecosystem evidence — langchain-community sunset, non-langchain-* names in LangChain's own integrations listing, in-host precedents from ragatouille to mlflow — showed the standalone distribution was never required. The integration now ships inside the boost-skill-cli wheel behind a [langchain] extra instead; see langchain-in-the-wheel. The original card follows for the record. The boost-langchain distribution shipped under integrations/langchain/ with its whole point being a separate release cadence from boost-skill-cli — langchain majors move faster than boost does, and the conformance workflow already builds the sdist/wheel and runs twine check on every touching PR. What does not exist is any way for those artifacts to reach PyPI: the name 404s there, and nothing publishes on any trigger. Two pieces, one of which only the repo owner can do. First, create the PyPI project and configure a Trusted Publisher for it — pending-publisher registration works before the first upload, and the filename-matching rule that pinned boost's own workflow name applies here too. Second, a publish workflow with a deliberate trigger: not boost's every-merge cadence (publish.yml releases boost-skill-cli on every push to main, which is exactly the coupling the separate distribution exists to avoid) — a tag like boost-langchain-v0.1.0 or a manual dispatch that bumps the static version, builds from integrations/langchain/, and publishes with the OIDC token. Remember the repo's own lesson: a release:-triggered workflow can never fire here (GITHUB_TOKEN events do not chain), so trigger on the tag push or dispatch directly. The floor is already honest. The package requires boost-skill-cli>=1.0.320 — measured against the actual API it calls, verified by an adversarial install — so the first published version works against PyPI as it stands today.

Complexity S Impact Med Wow ★★ declined — superseded by shipping the integration inside the boost-skill-cli wheel (see langchain-in-the-wheel)
In flightSearch · Performance

publish the keyword index the way vectors are published

Dense vectors are built once in CI and downloaded. The BM25 index is not: core/rag.py has no export or import function at all, and shards.yml / scripts/publish_shards.py are dense-only end to end. Every install rebuilds the same index from the same registries, at the same pinned commits, to produce the same bytes. Measured, on a real 458-tap machine. The on-disk index is rag_index.json 43.7 MB plus rag_postings.sqlite 653.0 MB — 696.7 MB for 18,619,658 postings. Build cost, timed over a 9,306-entry / 69-tap slice: 4.54 s reading bodies and tokenizing, 3.83 s writing postings, 8.4 s total — about 0.9 ms per entry, so roughly 65 s and ~900 MB extrapolated to the full 71,700-entry catalogue. Which user actually pays it. Not the default one: boost quickstart taps the 7 starter registries and indexes them in about a second. The cost lands on boost quickstart --catalog — 463 registries, 2 min 10 s of parallel cloning and then a minute of indexing on top — and on anyone who taps their way there gradually. The bug that makes this worth doing is not speed. boost catalog --import already exists and already looks like the answer: shareable-catalogue-bundle advertises 10.9 MB replacing a 12 GB clone and "59,972 searchable items in 4 seconds". That 4 seconds is fast for a reason the card does not state. rag.read_body degrades silently to name + description when the item's clone is absent (rag.py: "Missing files degrade to just the catalog metadata"), and a bundle import restores catalogues with zero repositories cloned. So the index it builds is not the full-content index the evals gate floors — it is a frontmatter index wearing the same file name. Measured directly over 3,015 real entries, indexing them with and then without their clones: 3,041,326 tokens versus 182,507. A bundle-only index carries 6.0% of the searchable text, and nothing in the output says so. That is the same failure shape as an unpinned eval corpus — a number that still renders confidently while measuring something else. Why this is easier than the dense shards, not harder. BM25 looks like it needs global statistics, and it does — but none of them are frozen at build time. _bm25 derives n = len(docs) and df = len(plist) on every query, so IDF is computed from whatever corpus is loaded. A per-registry shard therefore merges by offsetting doc_id, unioning the postings, and recomputing avg_len from per-shard totals — arithmetic, not re-derivation. And unlike vectors there is no embedding space to match and no API key to hold, so shards.incompatible() has no analogue here: a published keyword index is importable by everyone, including the keyless user who cannot use vectors at all. Shape. rag.export_shard / rag.import_shard mirroring dense's pair, per-registry assets on the existing shards-latest release, rows carried in the same manifest.json with the same commit pin and sha256 — the carry-forward machinery in publish_shards.py manifest --carry-forward applies unchanged, because a registry whose commit did not move has an index that did not change either. Three invariants transfer verbatim from the dense side and each is load-bearing: verify before replacing, refuse a shard whose commit is not the tap's commit, and never treat a missing digest as a match. The open question is payload size, and it is large enough to be its own decision — see shrink-the-published-index. This card should not ship until that one has an answer, because publishing 697 MB per refresh to save 65 s of CPU is not obviously the right trade, and at the compressed sizes measured there it clearly is. Partly landed, and deliberately still inflight — 2026-09-10. What shipped is the half that needed no size decision: the index now records what it is. read_body_full returns the text and whether it contains the item's body, build() reports metadata_only over every document written (reused ones included, or an incremental build reports zero on the run after a bundle import), index_completeness() reads the share back off disk, and boost reindex says it out loud instead of reporting the same confident count for a 6% index. The share is of tokens, not documents: a bodyless entry still produces a document, so a document share sits at 1.0 until it drops to 0.0. INDEX_VERSION moved to 9, because the flag is written only when a body is missing and absence may only be read as "complete" once no older document can survive. What did NOT land: rag.export_shard / rag.import_shard, the per-registry assets, and the manifest.json rows — the publishing pipeline itself. That half is what the payload-size question governs, and shrink-the-published-index still has no answer: its claim is stale, not active — branch loop/shrink-postings-index was last touched 2026-09-02, carries one commit, has no pull request, and is 394 commits behind main. Someone should un-claim it. One structural finding for whoever takes it: doc ids are positional (_save does enumerate(docs)), so the card's "merge by offsetting doc_id" is sound as written — and the shard format should serialize logical postings (digest → term → tf) rather than the SQLite layout, so the interning that branch was attempting cannot invalidate a published shard.

Complexity L Impact High Wow ★★★★ every machine rebuilds 697 MB of index for a corpus that is byte-identical on all of them
In flightPerformance · Storage

shrink the keyword index before publishing it — structure first, then compression

publish-the-keyword-index is worth doing only if the artifact is small enough to ship weekly. This card is the measurement that decides it, and the first answer is that compression is the second lever, not the first. What the format actually stores. _write_postings creates postings (term TEXT, doc INTEGER, tf INTEGER) and inserts one row per posting, so the term string is repeated in every row. Measured on the real 458-tap store: 18,619,658 rows over 210,422 distinct terms averaging 6.6 characters. That is ~123 MB of term text to carry 1.4 MB of distinct term text — 88× redundancy, before the per-row and B-tree overhead that turns it into a 653 MB file (page_size 4096, 167,174 pages, freelist 0, so it is not slack space). Compression measured on that file, as it stands: rag_index.json 43.7 MB raw · gzip -6 10.6 MB (4.12×).
rag_postings.sqlite 653.0 MB raw · gzip -6 201.7 MB (3.23×) · zstd -3 169.9 MB (3.84×) · zstd -19 106.7 MB (6.11×). So even with no format change, zstd -19 puts the whole index near 117 MB — under half the ~300 MB of dense vectors already published weekly. The trade is already good; the point of this card is that it can be much better, and that the two levers compose. Structure first, and it is the bigger win. Interning terms into terms(id, term) with postings(term_id, doc, tf) removes ~123 MB of duplicated strings and shrinks the postings_term index from a text key to an integer one. Beyond that, the classic inverted-index encodings apply directly because doc ids within a term are ascending: delta-encode them, varint or bitpack the deltas, and store one blob per term rather than one row per posting. Both shrink the file on disk, not just in transit, which is the half a compressed download never gives back — the user still ends up with 653 MB resident after import. What must not regress. read_postings exists precisely so a query touches a handful of terms instead of materialising the whole map — the change that took cold search from 8-13 s and multiple GB resident to 31-70 ms of scoring. A blob-per-term layout keeps that property (one row read per query term, decoded on the spot); a scheme that requires decoding neighbouring terms to find one does not. _bm25 must stay byte-identical, as it did through the SQLite move, and TestBm25Math is what says so. Decompression cost is the thing to measure, not assume. zstd -19 is slow to compress and fast to decompress, which is the right asymmetry for a weekly build feeding many imports — but "fast" needs a number on the import path before it is a claim, next to the 0.12 s that importing dense rows costs today. A zstd dictionary trained across shards is the obvious follow-on for the many-small-registries case, where per-shard compression has little context to work with. Deliverable. A measured comparison — raw, interned, delta+varint, each × none/gzip/zstd — on the real store, with import-side decode time beside each. That table is what tells publish-the-keyword-index what to ship, and it is worth having even if publishing is declined: the on-disk win applies to every install today. Progress — PR 688, merged as f003fa03 in train 691. The structural half shipped: _write_postings now interns terms into their own terms(id, term, df) table, with postings carrying an integer term_id instead of repeating the term string on every row — exactly the "structure first" change this card calls the bigger win, and it bumps INDEX_VERSION so every store picks it up on its next rebuild. stem_expansions now reads the precomputed df column directly instead of a GROUP BY COUNT(*) over postings on every prefix lookup. Not done: the delta/varint doc-id encoding, and the full raw/interned/delta+varint × none/gzip/zstd comparison table with import-side decode times on a real multi-hundred-MB store — this sandbox has no such store to measure against, only a small synthetic one (interning alone cut a 1.8M-posting/20k-term synthetic store from 63.6 MB to 47.9 MB, directionally consistent with the real-store estimate above but not a substitute for it). Left as follow-on work before this card can be called shipped.

Complexity M Impact Med Wow ★★★ 653 MB of postings holds 1.4 MB of distinct terms — the term string is stored 88 times over
ShippedHealth · Robustness

A best-effort log handler prints a traceback over every command's output

Write-up · delay-true-defeats-the-log-suppress.md

Complexity S Impact Medium Wow ★★ handleError overridden on the file handler, scoped to emit (#637); doctor probes open() rather than mode bits (#638)
In flightSearch · Ranking

Near-identical copies survive content-hash dedup and take the whole result page

Content-hash dedup shipped and worked: rag.dedupe_by_content took duplicate result slots from 4.94 to 0.60 per query over a 77-tap corpus. That card closed naming one thing still open — near-identical rather than byte-identical clustering, where core/typosquat.py's confusion machinery would apply — and buried it under a shipped status where nobody would claim it. This card is that remainder, with a measurement that makes it look considerably worse than “refinement”. Observed on a real 466-tap install with hybrid RRF serving (658,131 chunks): for the query exa search, every one of the top ten rows is exa-search, and the descriptions are what give the shape away — one Japanese (Exa MCPによるウェブ、コード、企業調査), two Chinese (通过Exa MCP进行神经搜索), five English variants of Neural search via Exa MCP, plus Use Exa MCP for current web… and AI-powered web search…. All ten are ★ curated. The footer reads 51 matches · ranked by hybrid RRF (BM25 + dense). Every one of those passed dedup correctly. They are not byte-identical: they are the same skill in Japanese, in Chinese, and in five English phrasings across different registries. The body digest differs, so dedupe_by_content keeps them all — which is exactly the behaviour #366 proved must be preserved, since two entries sharing a name can be genuinely different rules. The shipped fix is not misbehaving. It simply does not reach this shape. What the 0.60 residual actually was. The prior card described its leftover as “entries sharing a name whose bodies genuinely differ, which must stay separate” — true as stated, and it reads as a rounding error. At 466 taps the same residual is a full result page. The gap between 0.60 and 10.0 is worth understanding before designing anything: the 77-tap measurement used 50 natural-language queries averaged, and an average hides the shape here. Duplicate pressure was already known to be a step function of which registries are tapped rather than how many; near-identical pressure looks like a step function of which query — harmless across a query set, total on any query that lands on a widely-mirrored skill. Re-measure per-query maxima, not means. The hard part is the safety proof, not the clustering. Content hashing was adoptable because one count settled it: of 14,153 distinct bodies, clusters spanning more than one name numbered zero, so collapsing could not merge two different skills. Near-identical clustering has no such free proof — any similarity threshold loose enough to merge a Japanese translation with its English original is loose enough to merge two genuinely different skills that share boilerplate. Establish the equivalent bound first (over a real corpus, at the chosen threshold, count clusters spanning more than one meaning) or the fix trades a visible problem for a silent one. Three things to get right. Translations are the motivating case and the hardest: they share almost no tokens with the original, so token-overlap similarity will not find them while an embedding will — and the vectors are already on disk, which makes this cheaper here than it would be anywhere else. Collapse before k, and at both the retrieve and retrieve_any seams, for the reason the shipped dedup already documents: fusion reintroduces copies either engine dropped, because the copies are distinct (tap, skill_md) keys and RRF has no reason to treat them as one. The existing quality prior carries over unchanged — rag.source_rank orders on the user's curated flag first and shipped confidence second, and choosing among near-identical copies is the same question as choosing among identical ones: where should the user install from. Not to be confused with #629, which deduplicated vector storage (one row per distinct embedding, 39.7% repeats reclaimed). That is a disk-size fix beneath the index and changes no ranking; this is about which rows reach the user's screen. What shipped, and what did not. rag.collapse_near_duplicate_hits is the same "keep the earliest rank slot, promote a better source" contract as dedupe_by_content, run over cosine similarity of the entries' first-chunk embeddings (dense.entry_vectors, an index probe through chunks_entry on a quantized store) instead of a body hash, at the retrieve_any seam before k is applied. It is covered by unit tests down to the arithmetic (_cosine's dimension- mismatch and zero-vector guards), the clustering contract (rank order, quality-prior promotion, limit-after-collapse), the dense.entry_vectors lookup against a real quantized sqlite-vec store, and the retrieve_any/boost search --collapse-near-duplicates wiring in both directions (on and off). It ships opt-in and off by default — retrieve_any(..., collapse_near_duplicates=True) or boost search --collapse-near-duplicates — rather than replacing dedupe_by_content's output on the default path. Two things this card asks for are still open, and both need a real embedding backend (a built dense index, over a real multi-tap corpus) that the environment this was implemented in cannot reach — no network path to an embeddings provider or to the local ONNX model download, confirmed rather than assumed: huggingface.co and pypi.org both refuse at the network policy layer. First, the safety proof this card itself demands before defaulting the mechanism on — “over a real corpus, at the chosen threshold, count clusters spanning more than one meaning” — has not been run; NEAR_DUPLICATE_THRESHOLD = 0.97 is a starting point, not a validated floor. Second, re-measuring the exa search case (and per-query maxima generally) against the fix needs that same corpus and index. Whoever runs that measurement should flip the CLI flag's default, fold the corpus count into this card's evidence, and only then consider this shipped. The bound has now been measured, and it says the acceptance test in this card is the wrong one. scripts/measure_near_duplicate_bound.py runs the count this card asks for against the pinned 20-repo eval corpus (10,152 entries, 104,271 chunks, BAAI/bge-small-en-v1.5 at 384-d). Those entries reduce to 5,714 distinct chunk-0 vectors — 44% of entries already share a chunk-0 embedding byte for byte — and at NEAR_DUPLICATE_THRESHOLD = 0.97, 162 pairs clear the threshold and 56 clusters span more than one name. Sweeping the threshold moves that number but never to zero: 0.96 → 91, 0.97 → 56, 0.98 → 28, 0.99 → 13, 0.995 → 8, 0.999 → 4. Four of those 56 are not the threshold's doing at all. They are clusters of a single vector shared by several names, so they cluster at any threshold, which is why the sweep bottoms out at 4 rather than 0. The largest is the same at every threshold and is worth naming: 28 differently-named agents from one tap (affaan-m/ECC — architect, code-reviewer, chief-of-staff, database-reviewer, e2e-runner, …) whose chunk 0 is the same Spanish preamble (No cambiar rol, persona ni identidad…) in every file. Chunk 0 is name + description + opening of body, and where a registry opens every file with identical boilerplate, the name does not move the vector enough to separate them. A floor exists that no threshold can reach under, so “count must be zero” was never achievable. Worse for the test: most of the other 52 are the feature working. Hand-classifying all 56 at 0.97, roughly two-thirds are genuinely one skill under two names — twelve are pure hyphen-versus-underscore renderings of one integration (zoho-mail / zoho_mail, google_maps / google-maps, anthropic_administrator / anthropic-administrator), and the rest are suffix variants of one document (tdd / tdd-guide, rust-review / rust-reviewer, testing-patterns / code-showcase-testing-patterns). Collapsing those is precisely what this card exists to do. A metric that counts them as violations would reject every threshold that works. The dangerous merges have a shape, and this card already named it. The ~20 clusters that are real false merges are dominated by near-miss brand names: coinmarketcal with coinmarketcap, bugbug with bugsnag, parsehub with parseur, linkhut with linkup, mx-technologies with mx-toolbox, salesforce-marketing-cloud with salesforce-service-cloud. These are distinct products whose descriptions are boilerplate around a swapped word. That is the core/typosquat.py confusion shape this card's opening paragraph pointed at, arrived at independently from the other end: the guard this needs is not a tighter cosine floor but a name-confusability veto — refuse to collapse two entries whose names are a confusable edit apart, however close their vectors sit. So the default stays off, for a better-supported reason than before. The measurement does not say 0.97 is too loose; it says similarity alone cannot separate tdd/tdd-guide (collapse) from coinmarketcal/coinmarketcap (never collapse), because both pairs sit in the same cosine band. Flipping the default needs the confusability veto first, and a re-count with it applied. And this bound is space-specific: it was measured in bge-small 384-d, while a keyed production install is voyage-4 at 1024-d. Cosine thresholds do not transfer between embedding spaces — rerun the script against each space before trusting a number in it.

Complexity M Impact High Wow ★★★★ shipped opt-in (#639); bound measured (#645) and it refutes the zero-clusters test -- default-on now waits on a name-confusability veto
ShippedQuality · Retrieval eval

The monthly corpus refresh rewrote the pins and the baseline but left every documented number stale — taps.txt now contradicts its own header, and nothing checks it

Write-up · corpus-refresh-updates-data-not-prose.md

Complexity S Impact Low Wow ★★ .github/workflows/eval-corpus-refresh.yml regenerates taps.txt's data rows and baseli…
ShippedOnboarding · Bug

With a corrupt config.json, doctor reports "no registries tapped" and verdicts "● ready to set up" exit 0 while search is dead; heal says "nothing to heal"

Write-up · corrupt-config-reads-as-ready-to-set-up.md

Complexity M Impact Med Wow ★★★ Doctor has no config-integrity check. When ~/.boost/config.json fails to parse, confi…
ShippedQuality · Retrieval eval

BOOST_NO_EMBED has no state in the reason ladder: doctor calls a deliberate kill switch a degraded fault (exit 1) and hands advice that is a measured no-op in both branches

Write-up · dense-kill-switch-has-no-reason-state.md

Complexity M Impact Med Wow ★★★ embed.enabled() short-circuits provider() to None (embed.py:134), so BOOST_NO_EMBED=1…
ShippedQuality · Retrieval eval

status() has no state for "ready but the embedder does not work": doctor green-ticks a tier that never ran, the search hint is suppressed, and every search re-pays the failed model fetch

Write-up · dense-ready-but-embedder-cannot-run.md

Complexity M Impact Med Wow ★★★ localembed.available() (localembed.py:85) tests whether onnxruntime and tokenizers *i…
ShippedUX · Bug

out.err's multi-line hint is coloured as one span, so line 1 ends with no RESET and lines 2+ carry no start code

Write-up · err-multiline-hint-colours-across-the-newline.md

Complexity S Impact Low Wow ★★ err() joins a multi-line hint's lines and then wraps the whole joined string in one c…
PlannedQuality · Retrieval eval

The corpus's 65.6% duplication is 99.93% inside a single tap, so the required gate never once exercises the cross-tap trust ordering dedup exists for — 0 swaps in 264,735 comparisons

Measured. Over the 91 required golden queries on the current pins, 264,544 of 264,735 collapse comparisons inside rag.dedupe_by_content (99.93%) were between two copies in the SAME tap and the source-preference branch executed 0 times; and forcing it to fire — marking one tap curated produces 191 swaps — leaves recall@k / hit@1 / MRR / nDCG@k at 0.8407 / 0.4835 / 0.6065 / 0.6552 both before and after, with all 91 graded ranked-key lists identical. Reproduce it. cd <repo>
export HOME=$TMPDIR/audit-corpus-verify && export BOOST_HOME=$HOME/.boost # after eval_corpus.py --ensure (see other finding)
.venv/bin/python - <<'PY'
import sys, json
sys.path.insert(0,"."); sys.path.insert(0,"scripts")
from boost_cli.core import rag
from boost_cli.core.rag import source_rank
stats={"collapses":0,"same_tap":0,"diff_tap":0,"swaps":0,"ties":0}
def patched(hits, limit):
best={}; out=[]
for hit in hits:
d=hit.get("content")
if not d: out.append(hit); continue
s=best.get(d)
if s is None: best[d]=len(out); out.append(hit); continue
stats["collapses"]+=1; kept=out[s]
… What adversarial verification corrected. This card's numbers are the re-measured ones, not the ones first reported. 1. THE REMEDY CLAIM IS WRONG, and this is the correction that matters. The finding's why_it_matters says "adding a single mirror registry to taps.txt would be enough to make it visible." It would not. eval_retrieval.grade_key (scripts/eval_retrieval.py:197-209) keys every ranked slot on the content digest (body:<digest>), the exemplar class (cls:...), or the entry name — and a swap only ever replaces hit["entry"] INSIDE a content cluster, where the digest is identical by construction and, because catalog._content_digest hashes name + description + body, so is the name. Every return branch of grade_key is therefore invariant under a swap; the nohash:tap::skill_md branch at :209 is unreachable for a swapped hit because dedupe never collapses a hit with no digest. Proven, not argued: marking composio-community/awesome-codex-skills curated on the same pinned corpus fires 191 swaps (every cross-tap collapse becomes a swap — the composio copy arrives second in all 191) and leaves recall@k / hit@1 / MRR / nDCG@k at 0.840659 / 0.483516 / 0.606517 / 0.655233 before AND after, with all 91 graded ranked-key lists byte-identical. So a trust-ordering regression is invisible to the required gate BY CONSTRUCTION, regardless of corpus shape — the gap is that the harness never grades on source, not that the corpus lacks mirrors. What is NOT established. Recorded because a card that overstates its own evidence is worse than no card. SCOPE OF MY REPRO — read this before re-verifying. The finder's numbers reproduce ONLY on the CURRENT pins (10,731 entries). The shared read-only corpus at $TMPDIR/eval-home is PRE-REFRESH: 10 of its 20 clones are not at the SHAs in tests/eval/taps.txt (anthropics/skills, NeoLabHQ, LessUp, affaan-m/ECC, first-fluke, langchain-ai, minio, OneWave-AI, sickn33, anthropics/claude-agent-sdk-python), and it holds 10,152 entries. There the same instrumentation gives 1,986 clusters / 6,348 entries (62.5%) / 240,646 collapses / 240,455 same_tap / 191 diff_tap / 0 swaps. I materialised the current pins into a private copy (eval_corpus.py --ensure, network fetch works despite a harmless failed to store: 100001 commit-graph warning) to get the finder's exact figures. Anyone re-checking against $TMPDIR/eval-home will get the smaller set and should not read that as refuting the finding — the qualitative result (5 cross-tap clusters, all high/high, 0 swaps, ~99.9% same-tap) is identical on both. DOC TRAP, not this finding's fault: tests/eval/taps.txt's own header prose says "10,152 entries" and "sickn33 … is 6,309", and CLAUDE.md repeats 10,152 — but the file's own per-repo rows sum to 10,731 with sickn33 at 6,634. The pins were moved in commit cbc0a58b ("test(eval): refresh the pinned retrieval corpus") and the header prose was not updated. A card author quoting corpus size must take the row sum, not the header. NOT ALREADY CARDED, but read the existing card first. Why it is worth doing. The required corpus contains essentially none of the duplicate shape that dominates a real install. A user's duplicates arrive as mirror registries republishing each other's skills across taps, which is what source_rank decides between and what determines where a user is told to install from; the gate's duplicates are one publisher re-vendoring itself into 60 plugin bundles, where every candidate has the same tap and the tie-break is a no-op. Found by an automated audit of retrieval/eval quality, the search & browse surfaces, and first-run onboarding; every finding was then re-measured from scratch by an independent adversarial verifier whose instruction was to refute it. Verdict: CORRECTED. No fix is prescribed here — the measurement is the contribution.

Complexity S Impact Low Wow ★★ rag.dedupe_by_content is documented against a real install where "registries mirror e…
ShippedQuality · Retrieval eval

make eval scores a corpus with every SKILL.md body missing, reports all four floors PASS, and scores HIGHER than the real corpus

Write-up · eval-gate-scores-a-body-less-corpus.md

Complexity M Impact Med Wow ★★★ The Tier 1 required gate has no check that the corpus it scores actually contains the…
ShippedUX · Bug

boost explain's heuristic fallback prints every heading in the file — 541 lines for one skill — while the sibling list in the same function caps at 12

Write-up · explain-outline-has-no-cap.md

Complexity M Impact Med Wow ★★★ cmd_explain asks the model for "4-6 sentences, no markdown" (info.py:800-803), but th…
ShippedQuality · Retrieval eval

The CI-vs-Makefile floor-parity test compares only the floor VALUES, so changing -k in ci.yml turns a PASS into a FAIL with the test still green

Write-up · gate-parity-test-ignores-k-and-golden.md

Complexity M Impact Med Wow ★★★ the parity test now parses the whole eval_retrieval.py call in the Makefile, ci.yml and the refresh workflow with the script's own parser; a -k 5 in ci.yml alone fails it
ShippedUX · Bug

boost info/deps on a not-installed rule or workflow widens the tap's sparse cone for a directory source_dir_for immediately rejects

Write-up · info-deps-materialize-a-dir-they-then-reject.md

Complexity M Impact Med Wow ★★★ cmd_info (info.py:482-486) and _skill_dir_for_deps (info.py:1058-1066) call store.sou…
ShippedInterop

boost_install's description enumerates four of the five enabled agent targets and omits Antigravity CLI, the fourth linking agent

Write-up · mcp-install-description-omits-antigravity.md

Complexity S Impact Low Wow ★★ boost_install's description says installs are "wired into every agent you have enable…
ShippedInterop

boost_search advertises "10-15 seconds" unconditionally; with no AI configured it is 0.013 s median and the rerank never runs

Write-up · mcp-search-cost-overstated-on-keyless-machines.md

Complexity M Impact Med Wow ★★★ boost_search's description and INSTRUCTIONS both state the cost as a flat "10-15 seco…
ShippedInterop

The skip list — the one bound on boost's triggers — ships in INSTRUCTIONS only, in zero of the seven tool descriptions

Write-up · mcp-skip-list-absent-from-tool-descriptions.md

Complexity M Impact Med Wow ★★★ boost's agent-facing surface duplicates six of its seven load-bearing elements from I…
ShippedUX · Bug

out.panel still fits its content to term_width(), so boost count | … clips the line to an assumed 80 columns

Write-up · panel-fits-data-to-an-assumed-80-in-a-pipe.md

Complexity S Impact Low Wow ★★ output.panel computes room = term_width() - 4 (output.py:527) and clips its content t…
ShippedOnboarding · Bug

quickstart silently discards the incompatible shard status, so a user with any API key is never told why zero vectors arrived

Write-up · quickstart-drops-incompatible-shard-status.md

Complexity M Impact Med Wow ★★★ shards.sync() returns status: "incompatible" with a fully-formed reason when the publ…
ShippedOnboarding · Bug

A local manifest read error is reported as "no published shards", and the BoostError's hint — the only actionable line — is discarded

Write-up · quickstart-manifest-error-drops-hint-and-misnames-cause.md

Complexity M Impact Med Wow ★★★ cmd_quickstart catches every BoostError from shards.fetch_manifest() and prints exc.m…
ShippedOnboarding · Bug

With every registry unreachable, quickstart prints "✓ indexed 0 items" and "✓ ready", exits 0 — and the command it recommends exits 1

Write-up · quickstart-says-ready-exit-0-after-every-tap-failed.md

Complexity L Impact High Wow ★★★★ cmd_quickstart warns per failed clone but never tracks failures: it unconditionally r…
ShippedOnboarding · Bug

The shard download is invisible both before and during: --catalog --dry-run never names the 1,604.8 MB, and the live fetch passes no progress callback and has no spinner

Write-up · quickstart-shard-download-invisible-in-preview-and-run.md

Complexity M Impact Med Wow ★★★ shards.sync() takes an on_event progress callback and both other callers pass one; qu…
ShippedQuality · Docs

README's "81 commands" table enumerates only 80 — the missing one is quickstart, the README's own first command

Write-up · readme-81-command-table-lists-80-omits-quickstart.md

Complexity S Impact Low Wow ★★ README.md:389 heads a table "## 81 commands, organized into 8 groups", but the eight …
ShippedUX · Bug

boost recommend sizes the description cell per row from that row's because: text, so neither column lines up

Write-up · recommend-recomputes-its-columns-per-row.md

Complexity S Impact Low Wow ★★ cmd_recommend hand-rolls its rows and computes desc_w = max(cols - 2 - width - 2 - (l…
ShippedQuality · Retrieval eval

The corpus refresh re-baselines only golden.jsonl, so golden-natural.jsonl's baseline silently describes a corpus that no longer exists

Write-up · refresh-strands-the-natural-set-baseline.md

Complexity M Impact Med Wow ★★★ eval-corpus-refresh.yml:119 runs eval_retrieval.py --save-baseline -k 10 with no --go…
ShippedQuality · Docs

The two roadmap boards' install footers still advertise Python 3.9+, four minor versions under the real floor

Write-up · roadmap-boards-advertise-python-39.md

Complexity S Impact Low Wow ★★ docs/roadmap.html:17141 and docs/design-roadmap.html:582 both close with Install with…
ShippedUX · Bug

search caps the name column at 32 and the tap column at 20 at every terminal width, while the description column grows without limit

Write-up · search-caps-the-two-copyable-identifiers.md

Complexity M Impact Med Wow ★★★ output.search_layout (output.py:668-690) hard-caps name_w at 32 and tap_w at 20 and h…
ShippedUX · Bug

The relevance meter and its "one gradient moment" are constant on the default result page: 138/150 rows full bars, 150/150 the same colour

Write-up · search-relevance-meter-is-constant-on-default-page.md

Complexity M Impact Med Wow ★★★ format_search_row renders aurora(meter(frac), meter_hue(frac)) with frac = score / ma…
ShippedQuality · Docs

The contributor-onboarding gate tables state three wrong suite sizes, and README and CONTRIBUTING disagree with each other

Write-up · stale-gate-sizes-in-readme-and-contributing.md

Complexity S Impact Low Wow ★★ README.md:515 says make smoke is "176 checks" and CONTRIBUTING.md:123 says bash tests…
ShippedQuality · Retrieval eval

rag.surface's de-hyphenated name copy is justified by two claims that are both false, and its real effect — an undocumented 3x name / 2x description field weight — is guarded by a test …

Write-up · surface-dehyphenation-rationale-is-false.md

Complexity M Impact Med Wow ★★★ surface() (rag.py:200-208) indexes the name, a de-hyphenated copy of the name, and th…
ShippedQuality · Retrieval eval

Tier 3's false-call ceiling is unreachable at its own default N, and tolerates zero false calls at the N make eval-tools uses

Write-up · tier3-ceiling-unreachable-at-default-n.md

Complexity M Impact Med Wow ★★★ eval_tools.py judges the should-NOT-call ceiling against the Wilson UPPER bound, but …
ShippedOnboarding · Bug

An unreadable tap cache is invisible to doctor ("✓ 1 tap cloned & cached", exit 0) while search, browse and heal all exit 70 with a crash report

Write-up · unreadable-tap-cache-healthy-doctor-crashing-heal.md

Complexity M Impact Med Wow ★★★ fixed by #889 (the cache is replaced, not rewritten in place: search/browse/info/update/heal 70 → 0 for mode 400 and 000) and the #909 train (b1b1bca, eeb2c76: doctor and heal both name an unwritable cache dir; heal no longer claims a rebuild it did not do) — re-measured on a316c6b
ShippedOnboarding · Bug

"! agent dir ~/.cursor/skills is not writable" is the one doctor issue with no next action — heal has no path for it and the next install crashes at exit 70

Write-up · unwritable-agent-dir-has-no-remedy.md

Complexity M Impact Med Wow ★★★ Every other issue doctor raises names a command (boost heal, boost sync, boost update…
ShippedOnboarding · Bug

Nothing boost prints ever names an entry point: bare ./boost is byte-identical on a virgin machine and a working one, and the one command its failure-hints route you to is the only setup …

Write-up · bare-boost-never-names-an-entry-point.md

Complexity M Impact Med Wow ★★★ A newcomer's first screen is 103 lines of 81 commands that is byte-for-byte the same …
ShippedTech-debt

golden-natural.jsonl — the only fully exemplar-graded query set — is invoked by no make target and no workflow, so its numbers can only be produced by a human typing the command

Write-up · exemplar-graded-golden-set-runs-in-no-gate.md

Complexity M Impact Med Wow ★★★ The 50-row natural-language golden set is the one place where the project's content-c…
ShippedTech-debt

The "taps last refreshed N days ago" hint can never fire on a machine that tapped and never ran boost update — the only writer of the marker is update itself

Write-up · stale-tap-hint-dead-for-tap-only-installs.md

Complexity M Impact Med Wow ★★★ CLAUDE.md's rule is that "search must never refresh taps in the background: _hint_sta…
ShippedDocs · Bug

CLAUDE.md instructs the wrong licence: every new source file is told to carry GPL-3.0-only in a repo whose 373 headers, LICENSE and pyproject all say Apache-2.0

Write-up · claude-md-instructs-the-wrong-licence-header.md

Complexity S Impact Med Wow ★★★ CLAUDE.md tells every contributor and agent to open a new source file with GPL-3.0-o…
ShippedUX · Bug

At a narrow pane boost hooks list drops name, the argument hooks remove -n takes, while host and scope survive

Write-up · hooks-list-drops-the-name-before-the-host.md

Complexity S Impact Low Wow ★★ fixed — `name` now leads the table, so a narrow pane drops it after `host`, `scope`, `event` and `matcher`, never before
ShippedOnboarding · Bug

An unwritable agent rules/ or commands/ dir still crashes a rule or workflow install at exit 70

Write-up · unwritable-rule-or-workflow-dir-crashes-install.md

Complexity M Impact Med Wow ★★ an unwritable ~/.cursor/rules or ~/.cursor/commands still crashes a rule/workflow install at exit 70, leaving files the lock never records
ShippedRobustness · Bug

Two config.json shapes still slip past the corrupt-config handling. Invalid UTF-8 crashes every command, doctor included. {"taps": "x"} is a fresh install to doctor and a configured machine to --help.

Write-up · config-json-edge-shapes-crash-or-disagree.md

Complexity S Impact Med Wow ★★ A config.json holding invalid UTF-8 crashes every command, doctor included; {"taps": "x"} reads as a fresh install to doctor and as configured to --help…
ShippedRobustness · Bug

Two cache writers still crash on what one sudo boost leaves behind. A read-only _names.txt fails heal, update and untap at exit 70 while doctor says healthy.

Write-up · cache-writers-that-still-crash-on-a-read-only-cache.md

Complexity S Impact Med Wow ★★ fixed: refresh_names replaces _names.txt through atomic_write_text and warns once when it cannot write at all (heal/update/untap/tap 70 → 0 on a 444 file); reindex in a 500 cache dir prints one error naming the dir and `chmod u+w ~/.boost/cache` (70 → 1)
ShippedUX · Bug

Just before out.table drops a column, it shrinks the widest one with an ellipsis. In hooks list that is often name, and bmad-r… is not a name hooks remove -n accepts.

Write-up · identifier-columns-shrink-to-a-name-no-command-accepts.md

Complexity M Impact Low Wow ★★ In the few columns before out.table drops a column, the widest one that can shrink is squeezed with an ellipsis, and in hooks list that is the name remove -n takes…
ShippedRobustness · Bug

Under a read-only ~/.boost with no cache dir, update, heal and doctor crash at exit 70, and heal --dry-run says 0 for a run that crashes

Write-up · read-only-boost-home-with-no-cache-dir.md

Complexity S Impact Low Wow ★★ fixed: paths.refuses_writes names the directory that stops a write, including the parent of a dir a refused mkdir left missing; doctor and heal create what they can and name ~/.boost (70 → 1), heal --dry-run agrees (0 → 1); journal.log creates only its own dir, so update, compact and install finish (70 → 0); an install checks the store before its first write (a store that refuses stops it at exit 1 with nothing written) and a refused lock-history snapshot is a warning, so none of the measured shapes lands on disk unrecorded; an install skips an agent dir with a file or dangling link in the way, whether a skills, rules or commands dir, records it and says to move it aside (70 → 0), and sync, doctor and heal name it too; untap names ~/.boost (70 → 1)
ShippedConsistency · Bug

With an API key exported and no vector store yet, doctor and search send the user to a paid build while quickstart offers the free download

Write-up · keyed-no-store-hint-disagrees-with-shard-remedy.md

Complexity S Impact Low Wow ★★ On a keyed machine with no vector store, doctor and search say "build it" (paid), while quickstart and update --shards say to unset the key and download free…
ShippedRobustness · Bug

A rule or workflow row for a disabled agent makes boost sync claim the same repair on every run, and doctor never goes healthy

Write-up · sync-repairs-a-disabled-agents-row-every-run.md

Complexity S Impact Low Wow ★ fixed — every check that reads a materialization row now asks first whether boost still writes that agent, so a disabled one is named once instead of reported as rot
PlannedRobustness · Bug

Agent-dir shapes boost still trips on: a parent with no search bit, a missing dir under a read-only parent, a dir at a rule's file path, a blocked agent dropped from the lock's scope

Found by the third review of read-only-boost-home-with-no-cache-dir. None is a regression. Each was measured behaving the same on c7dca95c. A parent with no search bit. With an agent dir's parent at mode 0o600, store.install copies the skill into the store. It then crashes at exit 70 in linked_agents, where (adir / name).is_symlink() raises PermissionError outside link_agents' guard. The store dir is left unrecorded. Treating an OSError there as "not linked" would close it. A missing skills dir under a read-only parent. The install names a chmod target that does not exist, and doctor and heal disagree about it. link_agents' PermissionError branch should record the block from paths.refuses_writes(adir) and word it through link_refusal. doctor's agent-dir check should use the same function, so that it agrees with heal. A blocked agent drops out of the scope. After an install skips an agent as blocked, the lock's agents list leaves it out. preserved_agent_scope replays that list, so a later install --force never retries the agent and never says so. Only boost sync reports and repairs it. Callers that drop the result. boost import (install_from_path), quarantine --release and the unsideline paths (focus, profile, context, team) drop res.blocked without a word, as they already drop res.unwritable. pkg._warn_unwritable(res) is the existing reporter. Also found by the reconcile review of #933 with #931, and also measured on both parents: With any agent dotdir at mode 600, on Python 3.12 and 3.13 (3.14's Path.exists answers False where they raise), doctor, heal and sync exit 70 (PermissionError on ~/.cursor/skills). A rule or workflow install in that shape is fixed on #933's branch: _refused_target names the dir through paths.refuses_writes, which asks lexists. So is uninstall of a rule or workflow there, through store.refusing_dir, which now treats a path it may not look at as not there. The skill install and these three are not fixed. And the remedy is wrong for this shape: chmod u+w leaves a 600 dir at 600, because the missing bit is search, so the wording should say chmod u+wx when X_OK is what fails.

A directory at a rule's target file path (~/.cursor/rules/house.mdc/) raises IsADirectoryError. That is not one of the refusal shapes, so install exits 70 after writing the other agents' copies, with no lock entry.

heal --dry-run previews "would re-materialize" a rule whose target dir is still locked or blocked. The real run then re-materializes nothing, correctly. The exit codes agree (1 and 1), but the wording does not.

With ~/.agents/skills read-only, every install exits 1, naming it, while doctor says healthy. doctor could ask paths.refuses_writes(paths.store_dir()).

Complexity S Impact Low Wow ★★ Agent-dir shapes install, doctor, heal and sync still mishandle after the read-only-home fix; each behaves the same on c7dca95c…
ShippedRobustness · Bug

Six install paths still printed success over an agent dir that refused the link

Write-up · install-paths-that-still-drop-the-result.md

Complexity S Impact Med Wow ★ six more install paths printed success over an agent dir that refused the link, because they threw the install result away
ShippedPolish · Bug

A refusal and its remedy print past the pane, on the one line a user reads before acting

Write-up · a-refusal-and-its-remedy-never-wrapped.md

Complexity S Impact Low Wow ★★ Every other emitter folds to the pane; the one that prints a failure printed its remedy at 173 columns…
ShippedShards · Bug

One failed shard-build job silently drops its whole chunk from the published manifest

Write-up · one-failed-shard-job-drops-registries-from-the-manifest.md

Complexity M Impact High Wow ★★★★ A single failed build job deletes ~10 unrelated registries from the published manifest, and their assets stay on the release, orphaned…
ShippedPackaging · Bug

MANIFEST.in prunes only the root copy, so dev-local files ship in the sdist

Write-up · manifest-in-prunes-only-the-root-copy.md

Complexity S Impact Low Wow ★★ A maintainer's local agent-permission file ships to PyPI under a directive written to prevent exactly that…
ShippedMCP · UX

A search that finds nothing echoes the whole query back into the agent's context

Write-up · mcp-miss-reply-echoes-the-whole-query.md

Complexity S Impact Low Wow ★★ The one reply an agent hits repeatedly while rephrasing costs context in proportion to the query…
ShippedMCP · Bug

A deeply nested JSON line kills the MCP session, because the parse guard names one exception

Write-up · mcp-session-dies-on-a-deeply-nested-json-line.md

Complexity S Impact Low Wow ★★ The parse layer catches JSONDecodeError, and a deep enough line raises RecursionError instead…
ShippedSearch · Bug

The model back-off dated its record by the filesystem clock and read it against the process clock

Write-up · the-model-back-off-mixes-two-clocks.md

Complexity S Impact Medium Wow ★★★ The record that exists to stop a 133 MB fetch was dated by one clock and read against another…
ShippedCompat · Research

Codex hooks are shaped like Claude's, and the two fields that differ are unverified

Write-up · codex-hooks-timeout-units-are-unestablished.md

Complexity M Impact Low Wow ★★ Codex has hooks shaped like Claude's, and the two fields that differ were unverified — now measured, and the file is `hooks.json`…
In flightMCP · Bug

Registering a skill's MCP server handed Antigravity the one argv its CLI rejects

Found by a reviewing subagent on #977, which was about a different file. boost install of a skill that declares an MCP server offers to register it with every agent CLI on PATH, and built that command line in core/mcpdecl.py — a second copy of the per-host grammar whose docstring said it "mirrors core/mcphost.py exactly". It mirrored two hosts of three. It had a Gemini branch and a Claude fallthrough, and agy fell through to Claude's — the single host whose CLI rejects that shape.

Measured against the old code: agy mcp add gh --scope user -e K=v -- npx -y gh-mcp. Antigravity CLI has no scopes (one global file at ~/.gemini/config/mcp_config.json, inherited from Gemini CLI), so --scope is an error rather than a no-op, and it requires every flag before the name, so the -e is rejected too. Every declared server, every install, on any machine with Antigravity installed — reported as "could not register gh" and never once as a boost bug, because the line the user sees is the CLI's.

The fix is not the missing branch. Adding one would have left the same two copies, with the fourth host (Codex, next) to remember in both. The grammar moved into one function, mcphost.add_argv(host, name, command, tail, …), and both callers became thin: register_argv registers boost itself (launcher mcp --stdio) and mcpdecl.register_argv turns a declared spec into the same call. Output is byte-identical for Claude and Gemini — all 134 existing argv assertions pass untouched — and correct for agy for the first time.

And the fallthrough is now loud. Claude's shape was the return at the bottom of the function, which is why a host with no branch inherited it silently. It is an explicit if host == CLAUDE, and the bottom of the function raises. A host can be in HOSTS and have no grammar for exactly as long as it takes a test to run.

Then a verifying subagent found a worse bug in the code that was now shared — and it was Gemini's, the host the old copy had "mirrored" correctly. boost emitted no -- for gemini at all, on the belief that its trailing variadic would pass the separator through as a literal argument. Measured against the real Gemini CLI 0.61.0: it does not. unknown-options-as-args rescues only options gemini does not know, and gemini mcp add knows ten of them, so the canonical GitHub server spec — which ships the bare docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/… — had its -e claimed by gemini's own --env (nargs: 1, taking the variable's name as its one value) and dropped from the stored entry — exit 0, "server added", and a container launched with no token. The -e KEY=value spelling is not dropped but relocated, into gemini's own env map and out of the args docker reads, which is the same outcome by a different route and the one to expect when reading a real entry. A -t http in a spec's args is worse: the entry is rewritten as {"url": "npx", "type": "http"}. The separator goes after the command for gemini — the one host where it does — and it is emitted unconditionally, because add x npx -- is accepted and stores args: [].

The same pass killed the comment justifying agy's --: measured on 1.1.22, agy never consumes an argument that follows the command, and rejects a dash-leading command with or without it. The -- stays (it is agy's documented separator) but is now described as inert rather than load-bearing. And boost install's decline path printed one command line for targets[0] after a prompt that named every host — so a user who said no got Claude's line and nothing for the two hosts a yes would also have registered with, agy among them.

Fifteen new tests and two rewritten ones that had pinned the old, wrong shape. The three literal per-host argvs on the install path (none existed: nothing tested mcpdecl.register_argv with a host= at all); agy's two rules each pinned separately, so a regression names which one broke; gemini's separator pinned three ways, including a spec whose args start with a dash — the case that was silently losing data; a cross-module parity test parametrised over mcphost.hosts(), which is the docstring's promise turned into an assertion and which covers a fourth host the moment the table gains one; and a monkeypatched codex row asserting ValueError — the regression this shape exists to prevent, failing in CI instead of on a user's machine.

Complexity S Impact Medium Wow ★★★ Two functions built the same `mcp add` command line, one had never heard of agy, and both got Gemini wrong…
In flightCLI · Bug

wrap() sizes a stderr line by stdout's pane

A line now gets its colour from the stream it lands on and its width from somewhere else. _wrap_lines (boost_cli/core/output.py:235) folds to term_width() - lead, and term_width (:402) takes no stream: it calls shutil.get_terminal_size, which consults sys.__stdout__. Right beside it, pane_width(stream) (:407) does take one, and exists because the same question has a different answer per stream.

So the emitters that write off stdout and wrap — err(wrap=True) (:318, :327) and warn(stream=sys.stderr, wrap=True) (:284, reached from catalog.py:346, journal.py:65, lockfile.py:185, registry.py:594 and complete.py:105) — size a stderr line by stdout's pane. In a 200-column terminal: boost install x >out folds the hint on the terminal at 72 columns, because stdout is a file, get_terminal_size raises and the 80-column fallback applies; boost install x 2>log writes 192-column lines into the log.

This is the twin of err-colour-judged-by-stdout, found while verifying it, and deliberately left out of that PR: it is a width bug, not a colour one, and it predates the change. Fix sketch: give term_width (or _wrap_lines) the stream the emitter is about to write to, the way c(), role() and aurora() now take one, and have each wrapping emitter pass its own. Watch the COLUMNS precedence: pane_width honours an explicit COLUMNS either way, and the wrap path must keep doing the same or a scripted COLUMNS=100 stops applying to hints. A test wraps one long hint with stdout a TTY and stderr a plain buffer, and asserts the fold point comes from stderr.

Measured before claiming, and the fix sketch above is wrong. pane_width(stream) is not the per-stream model to copy: it uses its stream only for the isatty() predicate and then takes the number from term_width() (output.py:422), so it measured 80 for a 200-column stderr terminal while stdout was a file. Routing _wrap_lines through it would have left that intact. A third instance the card missed: spin.progress_clear (spin.py:98) erases term_width() columns of a line it just proved is on s · 80 of a 200-column bar.

Two numbers here were budgets rather than widths. 192 is term_width() - len(" hint: "); the lead is printed too, so the lines run to the full pane — measured 196 for a hint and 199 for a warn on a 200-column pty. And the proposed test cannot fail: a fake tty (a StringIO whose isatty() returns True) has no file descriptor, so broken and fixed both answer 80 — measured identical fold points either way. It needs a real os.openpty() with TIOCSWINSZ.

Complexity S Impact Low Wow ★ three call sites size a stderr line by stdout — and pane_width, the card's own model, has it too

Engine & command internals

// concrete file:line findings from the code scan
ShippedRetrieval · Architecture

Semantic search is gated behind an API key it does not need

Write-up · keyless-semantic-search-for-everyone.md

Complexity L Impact High Wow ★★★★★ the vector store was never the problem — only turning text into vectors needs a key
ShippedSearch · Performance

Every dense search re-scanned all 3.08 GB of vectors — vec0 has no ANN index

Write-up · dense-search-rescans-every-vector.md

Complexity M Impact High Wow ★★★★★ 33.9s cold search; 28.2s of it was one brute-force scan of 3.08 GB
ShippedInstall engine · Scope

Workspace scope — boost install --local into the project

Write-up · workspace-scope-install.md

Complexity L Impact High Wow ★★★★ --local, committable repo lock
ShippedInstall engine · UX

boost list shows installed rules and workflows

Write-up · list-rules-and-workflows.md

Complexity S Impact Med Wow ★★ list was skill-only after rule/workflow install landed
ShippedEval · Correctness

The golden set grades by name, and 35 of 53 names are ambiguous

Write-up · golden-set-grades-by-name-not-by-skill.md

Complexity M Impact High Wow ★★★★ all 50 rows pinned; the 22 judgment calls were measured to move the published number by zero
ShippedEval · Correctness

The “pinned” eval corpus pinned names, not commits

Write-up · eval-corpus-was-not-actually-pinned.md

Complexity M Impact High Wow ★★★★ 62% of the required gate's corpus was one unpinned third-party repo, against a 1.15-query margin
ShippedEval · Correctness

The eval de-duplicated its ranked list by name, so homonyms shared a rank

Write-up · eval-deduped-ranked-lists-by-name.md

Complexity M Impact High Wow ★★★★ 13 different skills named code-reviewer shared one rank slot — where "recall is 1.000" came from
ShippedEval · Correctness

62% of the required gate's corpus is a single third-party repository

Write-up · eval-corpus-is-one-strangers-repo.md

Complexity S Impact High Wow ★★★ one third-party repo is 62% of the gate's corpus, and if it disappears every PR goes red
ShippedEval · Correctness

Nothing refreshes the eval corpus pins, so the gate measures one frozen day

Write-up · eval-corpus-pins-have-no-refresh-path.md

Complexity S Impact Medium Wow ★★★ the corpus is now frozen at one August 2026 snapshot, and nothing will ever move it
ShippedCompat · Python

the Python floor moves from 3.9 to 3.12

Write-up · python-floor-moves-to-312.md

Complexity M Impact High Wow ★★★ the floor was blocking a CVE fix and a dependency major at once
ShippedTech-debt

the typing.List → list sweep the floor now allows

Write-up · pep585-604-modernization-sweep.md

Complexity M Impact Low Wow ★ unblocked by the 3.12 floor; deferred only because the diff touches ~60 modules
ShippedCorrectness

audit the 16 zip() calls the 3.12 floor made checkable

Write-up · zip-strict-audit.md

Complexity S Impact Med Wow ★★ 16 call sites, each a judgement — a silent truncation or a new raise, never a mechanical fix
ShippedBug

boost search never noticed a tap added after the first search

Write-up · search-never-notices-a-new-tap.md

Complexity S Impact High Wow ★★★★ search said "no matches" for a skill `boost info` described from the same machine
ShippedBug

one deleted upstream stopped boost update for every other tap

Write-up · one-dead-tap-broke-every-update.md

Complexity S Impact High Wow ★★★★ found on the maintainer's own machine — 80+ taps, one deleted upstream, no updates for any of them
ShippedSecurity · Correctness

The update path skipped the scan the install path runs

Write-up · update-refreshed-rules-without-a-gate.md

Complexity M Impact High Wow ★★★★★ install scanned rule content; update did not — and the scanner could not see concealment anyway
ShippedTech-debt

bring scripts/ under the ruff gate

Write-up · scripts-under-the-lint-gate.md

Complexity M Impact Med Wow ★ 291 findings across 28 files, measured — most are the same UP sweep the package just finished
ShippedCorrectness · MCP

boost_search never said which ranking produced its answer

Write-up · mcp-search-hid-which-ranking-ran.md

Complexity S Impact Medium Wow ★★★★ the degraded order was byte-for-byte the shape of the promised one
ShippedCatalog · Correctness

est_items counted one skill fourteen times once registries went multi-agent

Write-up · est-items-counts-agent-mirrors-as-items.md

Complexity S Impact Med Wow ★★★ registries now ship one rendered copy per agent, so a raw walk credits pbakaus/impeccable with 40 items for the 9 it has
ShippedCatalog · Curation

The catalog was missing the two most-starred token-efficiency registries

Write-up · efficiency-registries-ponytail-caveman.md

Complexity S Impact Med Wow ★★★ two ~97k-star repos the catalog was missing; both advertise savings their own benchmarks contradict
ShippedBuild · Bug

The shards workflow has never once produced a shard

Write-up · shards-pipeline-never-produced-a-shard.md

Complexity M Impact High Wow ★★★★ two scheduled runs, 0 artifacts — 40 of 60 jobs tapped a bare SHA, and the other 20 hit an export that cannot work
ShippedBug

The repair command could not repair the thing two commands sent you to it for

Write-up · sync-could-not-repair-a-gutted-skill.md

Complexity S Impact Med Wow ★★★★ two commands named `boost sync` as the repair; sync answered "everything in sync" and changed nothing
ShippedBug

Path.exists() looks total, and is not

Write-up · pathlib-exists-is-not-total.md

Complexity S Impact Medium Wow ★★★★ the weekly fuzzer has now found two crashes in one function, three weeks apart, and been ignored both times
ShippedCI · Correctness

a publisher that could not publish, and an alert that could not stand down

Write-up · two-ci-controls-that-could-not-act.md

Complexity S Impact Medium Wow ★★★★ one publisher could never publish and one alert could never stand down — both reported success
ShippedCI · Performance

the shard job that had never once finished, and the timeout that could not be raised

Write-up · the-shard-job-that-could-not-finish.md

Complexity S Impact High Wow ★★★★★ 5h30m cancelled at the ceiling, then 2h07m green — the same job, with duplicate embeddings collapsed
ShippedCI · Evaluation

the scheduled re-pin that refreshed the twenty rows it must not touch, and none of the hundred and sixty-five it existed to pin

Write-up · the-scale-corpus-refreshed-the-wrong-rows.md

Complexity S Impact High Wow ★★★★★ 185 rows, 20 pinned — the monthly job moved exactly the 20 it did not own and pinned none of the 165 it existed to pin
ShippedCatalog · Curation

--category marketing matched nothing, while four marketing registries sat in the catalog under other names

Write-up · marketing-crm-domain-had-no-category.md

Complexity M Impact High Wow ★★★ the four marketing registries already carried were filed under writing and general, so the category returned nothing
ShippedSearch · Performance

Dense reuse is per tap, so one changed file re-embeds the whole registry

Write-up · dense-reindex-reuses-whole-taps.md

Complexity M Impact High Wow ★★★ one changed file re-embeds 29 min for 1.9 s of new text
ShippedCLI · Bug

boost create: CLI audit findings (2026-08)

Write-up · audit-create-findings.md

Complexity M Impact Med Wow ★★ parse(dump(meta)) != meta — evolve rewrites untouched lines, create writes broken YAML
ShippedCLI · Bug

boost reindex: CLI audit findings (2026-08)

Write-up · audit-reindex-findings.md

Complexity S Impact Med Wow ★★ reindex --json names taps two ways in one object (reused vs reindexed)
ShippedSearch · Performance

quickstart reruns re-download every shard; shards.sync never asks what is built

Write-up · shard-refresh-skips-processed-commits.md

Complexity S Impact Med Wow ★★ a quickstart rerun re-downloads every shard the store already holds at that commit
ShippedReliability · Bug

Two concurrent rag.build() runs delete each other's temp index

Write-up · concurrent-rag-builds-delete-each-others-temp-index.md

Complexity S Impact High Wow ★★★ two overlapping rag.build() runs share one .tmp name; the second unlinks the first's finished 644 MB file and the first dies on replace()
In flightTest hygiene · Bug

The sandbox fixture sandboxes every env var except the one project scope reads

`tests/conftest.py`'s `sandbox` fixture is thorough about the environment — it redirects `HOME`, clears `BOOST_HOME`, `BOOST_AGENTS_STORE` and `CODEX_HOME`, and sets five `BOOST_NO_*` guards so no test reaches AI, the network, the seed or a confirm prompt by accident. It never touches the **working directory**, and that is the one input project scope resolves against: `scopes.resolve_base` walks up from `os.getcwd()`, so a test that installs with `scope="project"` and no explicit `base`, or drives `boost install --local` without `monkeypatch.chdir`, writes into the developer's own checkout. What lands there is not a stray temp file. A project install materializes the full agent fan-out at the repo root — `.boost/skill-lock.json`, `.claude/skills/`, `.cursor/`, `.windsurf/`, `.gemini/`, `.codex/` — plus, for a rule, the context files themselves: `AGENTS.md` and `CLAUDE.local.md`, both of which every agent working the repo then loads as instructions. It is also self-propagating, because the state outlives the run that wrote it. A killed run left a project-scope `brainstorming` at the root; the next full suite read it back and failed twelve tests across four files that assert an empty install state — the `test_cli_quality.py` case for a machine that never installed anything saw `brainstorming ok project`, and `boost list`, `boost info` and the pane-width tests all inherited a row nothing in them had installed. The failures name none of the tests responsible, and they clear only when someone thinks to look at `git status` — where `.boost/` is gitignored and does not appear. No committed test writes there in its shipped form: `tests/unit`, `tests/functional` and `tests/smoke.sh` each leave the checkout clean when run directly, watched by a teardown hook that names the offending nodeid. A full `make check` does not — it ends with `.boost/skill-lock.json` and five agent dotdirs at the repo root, all stamped inside the mutation stage. That stage runs those same tests against mutated `boost_cli/core`, so the blast radius of a mutant that weakens a scope guard is the developer's own working tree, and 4,343 of them survive each run. Which is the whole argument for the guard: the suite is one edit — or one mutant — away from writing here, and when it does, the failures it causes name everything except their cause. Two halves, both cheap: - **Chdir the sandbox.** Point `cwd` at a directory under `tmp_path` in the fixture, so a forgotten `chdir` resolves to the sandbox instead of the repo. Needs an audit first — any test that reads a repo-relative path (the generated-file `--check` gates, `test_spdx_headers.py`) must take the repo root explicitly rather than inheriting it. - **Fail loudly if it happens anyway.** A session-scoped autouse check that snapshots the known project-scope artifact names at the repo root and fails the run — naming the test — when one appears. That is the half that would have turned twelve misleading failures into one accurate one.

Complexity M Impact Medium Wow ★★ `make check` leaves a project install in the repo root; a later run reads it back and fails twelve unrelated tests.
ShippedCI · Flake

One 30-minute cap for nine matrix cells, and only Windows is anywhere near it

Write-up · the-windows-test-cap-is-five-minutes-from-the-measurement.md

Complexity S Impact Medium Wow ★★ Two windows-3.14 jobs were killed at 30.4 and 30.3 min in one morning — both while pytest was still printing results, and the second one blocked a release.

Code health & security

// planned · free tooling to catch vulns, smells & bugs
ShippedSecurity · Posture

OpenSSF Best Practices — all 67 passing criteria answered

Write-up · openssf-best-practices-badge.md

Complexity M Impact Med Wow ★★★ 66 Met/N-A · 1 justified Unmet · registration is the only step left
ShippedSecurity · Posture

OSPS Baseline — three levels, audited rather than assumed

Write-up · osps-baseline-levels.md

Complexity M Impact Med Wow ★★★ L1 + L2 earned · L3 blocked · audit found a merged regression
ShippedSecurity · Posture

OpenSSF silver — reachable solo, and mostly already true

Write-up · openssf-silver.md

Complexity S Impact Med Wow ★★★ 55 criteria, 31% → the gap was two documents, not fifty
ShippedSecurity · Posture

OpenSSF gold — how far it goes without a second human

Write-up · openssf-gold-ceiling.md

Complexity M Impact Med Wow ★★★ 26% → 61% live; the parser that said "21 criteria" had missed two
ShippedDocs · Onboarding

The README read like a machine wrote it — measurably

Write-up · readme-prune-and-search-guide.md

Complexity S Impact Med Wow ★★ 609 → 399 lines; 75 em dashes → 2; a real semantic-search guide
ShippedCI · Release safety

main went red because "require branches up to date" was never actually on

Write-up · branch-current-gate.md

Complexity S Impact High Wow ★★★★ two protection mechanisms disagreed; the binding one had the safety off
ShippedInterop · Bug

Gemini logged a skill conflict every session and boost doctor called the machine healthy

Write-up · gemini-duplicate-skill-discovery.md

Complexity S Impact Med Wow ★★★ Gemini warned once per skill per session and no boost surface could see it
ShippedSecurity · Posture

A machine-readable VEX feed, sourced from findings that already existed

Write-up · vex-openvex-feed.md

Complexity S Impact Low Wow ★★ OSPS-VM-04.02 — 4 statements, zero fabricated CVEs
ShippedSafety · Bug

boost audit: CLI audit findings (2026-08)

Write-up · audit-audit-findings.md

Complexity M Impact Med Wow ★★ rm -rf ~/ passes clean, hidden.js is never scanned, and a missing dir counts as scanned
ShippedCLI · UX

boost doctor: CLI audit findings (2026-08)

Write-up · audit-doctor-findings.md

Complexity S Impact Low Wow ★ crash line wears "!" but verdicts "● healthy" exit 0; and "1 issue need attention"
ShippedCLI · Bug

boost fingerprint: CLI audit findings (2026-08)

Write-up · audit-fingerprint-findings.md

Complexity S Impact Low Wow ★ quarantine doesn't change the fingerprint; an uncloned tap hashes as empty, silently
ShippedCLI · Bug

boost health: CLI audit findings (2026-08)

Write-up · audit-health-findings.md

Complexity S Impact Med Wow ★ health calls a drifted machine "● healthy" and scores gemini 1/1 with the store dir gone
ShippedCLI · Bug

boost lint: CLI audit findings (2026-08)

Write-up · audit-lint-findings.md

Complexity M Impact Med Wow ★★ lint can't lint a path on disk, counts 6307 "skills" for 1997 names, misreads one missing ---
ShippedCLI · Bug

boost policy: CLI audit findings (2026-08)

Write-up · audit-policy-findings.md

Complexity M Impact Med Wow ★★ policy check evaluates 4 of the 7 rules install enforces — a refused env "passes"
ShippedSafety · Bug

boost quarantine --release: CLI audit findings (2026-08)

Write-up · audit-quarantine-findings.md

Complexity S Impact Med Wow ★★ a quarantine/release round trip widens 1 agent to 4 and turns doctor red
ShippedCLI · Bug

boost test: CLI audit findings (2026-08)

Write-up · audit-test-findings.md

Complexity S Impact Med Wow ★★ a skill boost lint fails (exit 1) passes boost test outright (exit 0)
ShippedSafety · Bug

boost verify: CLI audit findings (2026-08)

Write-up · audit-verify-findings.md

Complexity S Impact Low Wow ★ a row counted among the N failed still renders the green ok token
ShippedBug

Three commands that denied what was on the disk in front of them

Write-up · because-that-was-not-the-reason.md

Complexity M Impact Med Wow ★★★★★ A `.github/workflows/` directory made `boost recommend` suggest a pasta-recipe skill "because: ci"
PlannedRobustness · Bug

One unresolvable agent dir silences the whole `boost doctor` report

Found by the review of loop/codex-agent-target. paths.expand now raises a BoostError for a ${VAR} with no fallback and nothing in the environment, rather than resolving it to an empty or literal path — the change that stopped a mistyped agents.<name>.dir silently installing into ./skills. agents.known_agents calls it for every configured agent, so one bad row now aborts every command that asks who the agents are: doctor, heal, clean, install, sync. For most of those, refusing is the right answer. For doctor it is not: its whole job is to surface a misconfiguration, and it exits 1 having reported nothing else — no lock check, no store check, no duplicate-discovery check. The remedy is reachable (boost config set never calls known_agents, verified in a sandbox), so this is a bad report rather than a lockout. Fix direction. Catch BoostError around the agent lookups in cmd_doctor and render it as an issue row, then continue with an empty agent set. The catch has to cover the indirect callers too — store.duplicate_discovery, store.sync_plan and the per-agent coverage counts all reach known_agents — so the natural shape is one resolution step at the top of the command whose failure degrades the agent-dependent sections rather than the run.

Complexity S Impact Medium Wow ★★ A single agent whose `dir` names an unset variable makes `boost doctor` exit 1 with one line instead of reporting it as an issue…
PlannedCLI · Bug

An item materialized nowhere reads ok in verify, health and drift

Found by the second review of sync-repairs-a-disabled-agents-row-every-run. That item fixed a row for an agent boost no longer writes being read as a missing artifact: nothing wrote the file and nothing ever will, so boost verify failed forever and boost drift and boost health sent the user to a boost sync that skips the row by design. The fix is right, and it opens a gap at the other end. Skipping a row is correct per row and wrong per item. Skip every row an item has and the item is materialized nowhere — the rule reaches no agent, the workflow is in no command palette — and the surfaces say it is fine. Measured on a real install (fixture tap, one rule, then every agent disabled): boost verify → team-conventions  ok  rule, rc 0 · boost drift → in-sync · boost health → rules  1 installed, drift  1 in-sync, ● healthy · boost attest --verify → sha_ok. doctor both names it and denies it. It prints the note — 5 recorded materializations name an agent boost no longer writes… — and two lines later ✓ 1 rule and 0 workflows fully materialized for every agent boost writes, then ● healthy. The count is true as worded and false as read: the write set is empty, so every item is trivially materialized for all of it. Only the note carries the news, and only doctor has a note channel — a third state that is neither an issue nor silence. The other commands have two, so the per-row skip had nowhere to put this and it fell into the healthy one. Why it is not cosmetic. verify is what scripts gate on and attest --verify is the provenance check; an install that reaches nothing and passes both is wrong in the direction that costs the user something — they installed a rule believing some agent would read it. Shape of a fix. Keep the per-row skip; add a per-item question after the loop. An item whose materialization rows are all unwritten is reported distinctly — unreachable, neither ok nor missing — and the count line says how many agents it actually reaches rather than how many of the empty set it satisfies. The work is the state the three commands do not have: verify's exit code, what health's counts mean, and whether attest --verify should fail it. An item with no rows at all is a different case (a skill, or a rule installed before rows existed) and must keep reading ok.

Complexity S Impact Low Wow ★★ a rule whose every materialization row names an agent boost no longer writes reads "ok" in verify and is counted as installed by health — only doctor says otherwise

Pipeline & supply-chain integrity

// planned · free tooling to secure the CI/CD path itself
ShippedRetrieval · Onboarding

Prebuilt vectors are published where no new user can reach them

Write-up · published-shards-have-no-consumer.md

Complexity L Impact High Wow ★★★★★ the vectors were being built and then nobody could get them
ShippedSupply chain

OpenSSF Scorecard's findings, triaged into three piles

Write-up · scorecard-findings-triage.md

Complexity M Impact Med Wow ★★ 7 open · 3 now hash-pinned, 3 decided, 1 clears itself
ShippedRelease safety

main has no branch protection, so the release rules are honour-system

Write-up · main-has-no-branch-protection.md

Complexity S Impact High Wow ★★★ decided, applied, and now gated against deadlock
ShippedBug

markdownlint linted the fuzzer's corpus, so shipping a crash reproducer would redden a prose gate

Write-up · markdownlint-lints-the-fuzz-corpus.md

Complexity S Impact Med Wow ★★★ 12 of 21 linted files were malformed on purpose
ShippedCI speed

The mutation gate's floor is a single file — shard 0 is store.py

Write-up · mutation-shard-floor-is-one-file.md

Complexity M Impact Med Wow ★★★ shard 0 is store.py alone — 9.3-11.7 min against a 6.1 even split
ShippedCI speed

A third of CI job time is spent waiting for a runner, not running

Write-up · ci-time-is-now-runner-queueing.md

Complexity M Impact High Wow ★★★★ 104 job-min queued vs 236 executing — 31% of CI is waiting for a runner
ShippedSecurity · CI/CD

The required lint job pins zizmor==1.27.0 — a yanked release

Write-up · zizmor-pin-is-a-yanked-release.md

Complexity S Impact Med Wow ★★★★ already fixed by a4450f76 twelve hours before this card was filed
ShippedCI reporting

demo.yml still fails on every push — and the fix is not in the workflow

Write-up · demo-cannot-open-its-own-pr.md

Complexity S Impact Med Wow ★★★★ a repo setting blocks it — no edit to demo.yml can fix this one
ShippedRelease safety

One commit can cut two releases, and the naive guard against it breaks retries

Write-up · one-commit-can-cut-two-releases.md

Complexity M Impact Med Wow ★★★ guarded on PyPI, not on the tag — so retries still work
ShippedSearch · Index

The BM25 index is one JSON blob, and it stops working between 10k and 50k items

Write-up · bm25-index-is-one-json-blob.md

Complexity L Impact High Wow ★★★★★ 2.5 GB RSS per search at 50k items
DeclinedSearch · Retrieval

Semantic search for users who will never set an API key

Dense retrieval today needs the [rag] extra and a VOYAGE_API_KEY/OPENAI_API_KEY and a built store. Most users will do none of that, so the default experience is BM25 forever. The keyless path is a local static embedding model — potion-retrieval-32M class, MIT, model2vec family — which is not a transformer: the entire weight file is one lookup table, so inference is tokenize → gather rows → mean-pool → L2-normalize. Measured locally, pure stdlib: ~1 ms to embed a query (mmap + bisect over sorted keys), 12.8 MB of int8 vectors for 50k items at 256-d, and ~20 ms to rerank BM25's top-200. No numpy, no sqlite-vec, no ANN index, no new runtime dependency. import numpy alone costs 180–390 ms cold, which disqualifies it from a one-shot CLI query path; the BM25 prefilter is what makes the stdlib version viable, since a full 50k brute-force scan is 1.5 s in pure Python. Pool depth is justified by measurement: BM25 recall saturates at 0.890 by depth 200 and gains nothing at 400, so reranking the top-200 gives up essentially nothing versus scanning everything. Why this and not a shipped Voyage index. A precomputed Voyage index is inert without a Voyage query vector, and the only keyless way to get one is a maintainer-run anonymous embedding endpoint — an unauthenticated free embeddings API backed by the maintainer's card, which also ships every user query off-machine and breaks offline. A local model is deterministic, so the artifact becomes a cache rather than a correctness dependency: a newly tapped repo can be embedded on the user's own machine. Doc-side is the asymmetry worth shipping for — 29 ms/doc in pure Python is ~24 min for 50k single-core, versus seconds in CI with numpy. Do not ship this before the eval and dedup items. The headline claim (+11.0 recall / +15.9 hit@1) did not survive verification: its baseline used the kind oracle the real search path lacks, and both the blend weight (w_dense=0.7) and the pool depth were argmax'd on the same 82 queries they were reported on, by 2-query margins. On a binary metric at n=82 the smallest net win reaching p<0.05 is 6 queries; hit@1 (+13 net queries) holds up, recall (+9) sits at the resolution floor. And the structural risk is real: the name is only ~10.5% of a mean-pooled surface vector while 106 description clusters are shared across 270 distinct names, so the lift may shrink toward 50k rather than hold. Sequence: fix the gate, dedup, fix the index format, then re-measure with McNemar and a held-out blend weight, leading with hit@1. Test entry-level dense alone before the blend, ship 512-d not 256-d (the whole case for 256-d was one query), keep Voyage/OpenAI as the opt-in ceiling, and keep BM25 as the floor. The model table cannot go in the default wheel — the shipped runtime is 0.79 MB and every merge to main cuts a release, so +17.4 MB × ~24 releases/day exhausts PyPI's 10 GB project quota in under a month; it needs a separate, rarely-released data package behind an extra. Related, and partly overtaken: [[keyless-semantic-search-for-everyone]] shipped a keyless path using a transformer (BGE via ONNX Runtime, in the [rag] extra) while this item was open. That does not settle the question this card asks — a static lookup table is still far cheaper, and this card's discipline about not shipping a retrieval claim before the eval still stands. What it does change is the baseline: "keyless" is no longer the differentiator, so the case for a static model now rests on cost (~1 ms and no runtime dependency, against a measured 233 ms cold and 34 MB of wheels) rather than on availability. Status left alone deliberately — this is another loop's item to own. Unblocked, and the case for it got stronger. This card says “do not ship this before the eval and dedup items”. Both have now landed: the eval gate floors four metrics over a realistic-sized corpus with baselines keyed to their query set, and content-hash dedup has merged. The new evidence is a timing measurement. Building the shipped ONNX keyless store over 743 entries (3,740 chunks, bge-small-en-v1.5 on CPU) took 4,431 s — 74 minutes, about 1.2 s per chunk. This card's static-embedding proposal claims ~29 ms/doc in pure Python. If that holds it is a difference of more than an order of magnitude on the doc side, which is exactly the cost that makes prebuilt shards mandatory today. Worth measuring the model2vec path directly before committing — but the gap it claims to close is now a measured number rather than an estimate. Spike done — the prerequisites this card set have all shipped, so the measurement it asked for was finally runnable. It says “do not ship before the eval and dedup items”; dedup landed in #370, the index format in #367/#371, the published eval in #373. What follows is potion-retrieval-32M (MIT, 63,091 × 512 F32 lookup table — confirmed a single tensor, no transformer) driven by a hand-written pure-stdlib loader: WordPiece → gather rows → mean-pool → L2, mmap'd, no numpy. The two unverified performance claims were not just right, they were conservative. Query embedding measured 0.16 ms against the card's ~1 ms. Document embedding measured 1.34 ms on a synthetic 105-token doc and 3.27 ms on 300 real catalogue entries (median 61 tokens), against the card's ~29 ms. That reverses one of this card's design arguments. The doc-side cost was the reason prebuilt artifacts looked mandatory: “29 ms/doc in pure Python is ~24 min for 50k single-core”. At the measured 3.27 ms it is 2.7 min — roughly the time a first boost tap --defaults already takes. Local embedding is therefore viable on the user's own machine, and shipped shards become a genuine optimisation rather than a requirement. (Not to be confused with the ONNX bge-small path measured at ~1.2 s/chunk in keyless-semantic-search-for-everyone; that number stands, and the gap between them is the case for the static model.) But reranking bought nothing at real scale, which is the result that matters. Over the 50 natural-language golden queries against a real 71,655-entry catalogue, reranking BM25's top-200 by cosine scored hit@1 2/50 — identical to BM25's own 2/50, a net change of +0 queries where this card's own statistics note says 6 net queries is the smallest win reaching p<0.05. On two hand-checked pairs the ordering was right but the margin was thin (related 0.154 vs unrelated 0.097). Stated limits, because this does not settle the question. The document vector was built from name + description truncated to 1,500 characters, not the full body the real dense path indexes, so this measures a weaker representation than the one being proposed. No blend was tried — pure rerank, no w_dense — and this card explicitly asks for a held-out blend weight and McNemar. What it does establish is that the cheap version of the idea does not pay for itself, so the remaining work is representation and blending, not inference speed. An unrelated finding fell out of it, and it is the more important one. BM25 scored hit@1 0.040 here against the 0.340 published in #373. Both are correct: the published figure is measured over the pinned 6-tap eval corpus of 743 entries, and this run used a real 77-tap install — 96× larger. Golden targets are all present and rank 7th, 8th, 38th, 163rd rather than 1st. The eval corpus is not a scale model of a real install, and the gate's floors describe a catalogue two orders of magnitude smaller than the one users have. Tracked separately in [[eval-corpus-is-96x-smaller-than-a-real-install]]. Declined on measurement, after a second model was tried specifically to avoid declining on one data point. The card's premise is that a local static model buys keyless semantic search. Tested against the 50 natural-language golden queries over the pinned 20-tap corpus (3,843 entries as those registries stand today), with BM25 at hit@1 0.260 as the baseline in every run: potion-retrieval-32M (retrieval-tuned, 63,091×512 F32) scored dense 0.220, hybrid RRF 0.260. potion-code-16M-v2 (code-domain, 63,457×256 F16 — chosen because this catalogue is coding-agent skills, which is the strongest hypothesis for why a general retrieval model would underperform here) scored dense 0.240, hybrid 0.260. A third representation — name+description only, over the full 71,655-entry catalogue — reranked BM25's top-200 to +0 net queries. So: two models, three representations, no measurable gain, and fusion never beats BM25 alone. The code model is one query better than the retrieval model, which at n=50 is inside the noise (±0.02 per query) and should not be read as a trend. The contrast is what makes this a decline rather than a shrug. The published eval measures a real embedding model at hybrid 0.440 against BM25 0.340 — a genuine +0.100. Static embeddings reproduce the cost profile that made the keyless tier attractive (0.16 ms/query, 3.3 ms/doc, no dependency) but not the quality that made it worth having. Cheap and no better than what ships today is not a tier; it is a second code path to maintain for nothing. What survives. The performance findings stand on their own and are already recorded above: doc-side embedding is ~24× faster than the card assumed, which is why prebuilt shards are an optimisation rather than a requirement for the real models in [[keyless-semantic-search-for-everyone]]. The pure-stdlib loader (WordPiece → gather → mean-pool → L2, mmap'd, F32 and F16) is proven workable if a future model justifies it. What would reopen this. A static model that actually separates on this task — the bar is beating 0.260 as a reranker, not merely producing plausible cosines. The two hand pairs looked fine for both models (0.224 related vs -0.001 unrelated for the code model), which is exactly why plausible similarity was not accepted as evidence.

Complexity L Impact High Wow ★★★★★ two models, three representations — no measurable gain over BM25, and fusion only ties
ShippedBuild · Bug

One global concurrency group let any PR cancel any other PR's check

Write-up · demo-workflow-cancels-other-prs.md

Complexity S Impact High Wow ★★★★ two PRs deadlocked each other for hours — re-running the job just moved the cancellation to the other one
ShippedBuild · Bug

The fuzzer found a real crash and nobody was listening

Write-up · unwatched-crons-hid-a-real-fuzz-crash.md

Complexity M Impact High Wow ★★★★★ the fuzzer found a real crash and was right for three weeks — 24 unattended workflows, 2 watched
ShippedBuild · Bug

The published metrics could never be published

Write-up · eval-stats-could-never-publish.md

Complexity S Impact Med Wow ★★★★ the published-metrics file has ONE commit in its whole history — the one that created it
ShippedPerformance · Search

A cold search materialises 71,600 entries to print five

Write-up · cold-search-reads-the-whole-catalogue.md

Complexity M Impact High Wow ★★★★ 0.94 s cold search at 71.6k entries — ~0.5 s spent materialising data the top hits never use
ShippedSearch · Retrieval

boost search brainstorm finds nothing, and brainstorming finds it

Write-up · bm25-has-no-stemming.md

Complexity M Impact High Wow ★★★★ 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
ShippedSecurity · Reproducibility

Reproducible release builds — the sdist half nobody's setuptools does for you

Write-up · reproducible-release-artifacts.md

Complexity M Impact Med Wow ★★★ wheel + sdist now bit-identical; setuptools#2133 has no native fix
ShippedRetrieval · Onboarding

The weekly republish reached the machines that had never been set up

Write-up · weekly-vectors-had-no-ingestion-path.md

Complexity M Impact High Wow ★★★★ the vectors were republished weekly and no command could take delivery
ShippedQuality · Retrieval eval

A query made only of characters tokenize drops returns zero results, and the documented catalog.search fallback is unreachable — boost search "C++" finds nothing on a machine holding …

Write-up · bm25-empty-tokenization-kills-catalog-fallback.md

Complexity L Impact High Wow ★★★★ the four symbol-bearing language names now tokenize, and a query that still tokenizes to nothing says so instead of reporting a miss; the catalog.search fallback stays unreachable on purpose — substring 'R' returns 10,092 of 10,152 entries
ShippedUX · Bug

boost search 'C++' returns zero and blames the catalogue: tokenize drops every 1-char token, and nothing ever says a term was discarded

Write-up · search-drops-symbol-language-queries-silently.md

Complexity L Impact High Wow ★★★★ c++/c#/f#/objective-c now alias to indexable tokens on BOTH the index and query side (INDEX_VERSION 7 -> 8); a term that is still dropped is named on stdout, on stderr under --json, and in the MCP reply
ShippedCI · Bug

The sweep gate died at a page, not at launch — and took six unrun checks with it

Write-up · sweep-died-at-a-page-not-at-launch.md

Complexity S Impact High Wow ★★★★ the gate kept reporting failure after it had stopped checking a page and a half
ShippedCompat · Feature

Codex is a skills and rules target but not yet an MCP host

Write-up · codex-is-not-an-mcp-host.md

Complexity S Impact Medium Wow ★★★ Codex takes skills and rules but `boost mcp register` cannot reach it — the grammar is verified, the host row is not written…
ShippedCI · Bug

The free-threaded canary is red for a missing setuptools, so it warns about nothing

Write-up · free-threaded-canary-warns-about-nothing.md

Complexity S Impact Medium Wow ★★ the 3.14t early-warning leg has been red on a missing setuptools, so a real no-GIL regression would not change its colour
In flightCI · Bug

One 30-line class makes registry.py unsplittable, and floors the mutation gate at 95% of its timeout no matter how many shards you add

Found by measuring the first eight-shard run on main against its own prediction. The planner said 28.4 min a shard; run 36959485751 measured 31.2, 39.6, 41.0, 41.0, 42.3, 43.1, 47.5 and 51.5 — a median of 41.0, which is 1.44x the prediction. Job overhead is not the gap: the mutate shard step alone was 30.6–42.5 min. The committed weights simply understate the work, and #1022 is the bot's re-fit that says so (57,680,336 ms against 42,506,911, a ratio of 1.36). The part that is a bug, not a drift. #1022 cannot merge: at eight shards its pack scores a 73.5-minute tail against a 75-minute cap, which plan --timeout-minutes correctly calls TOO TIGHT. The documented remedy is to re-pack — and re-packing does nothing. At 10, 12 and 14 shards the planner returns the identical verdict, because largest unit: 7309374 is registry.py whole, and one indivisible unit is a floor on the slowest shard that no shard count divides. The only lever the repo documents is connected to nothing. Why it is indivisible. top_level_symbols returns [] for any module holding a class with methods, because mutmut mangles a method's name differently and a wrong guess leaves mutants unrun. registry.py holds exactly one such class: Tap, 30 lines of 783, which carries no recorded mutants at all — its 24 measured symbols sum to 7,309,375 against a file total of 7,309,374. So a class that contributes nothing to the cost blocks the split of everything that does. Eleven files in boost_cli/core are in the same position, 18.6% of all mutation work. The fix is proof, not a guess. cmd_weights writes millis_by_symbol[file] only when every mutant of the file was timed, and it derives each key by the exact inverse of the mangling pattern_for applies. So a complete record both covers every mutant and addresses it. measured_partition lifts the AST refusal for a module a real run has cleared, under one guard: every recorded name must be a top-level def, since a name from inside a class would round-trip to a pattern matching nothing. Over both committed weight generations and all eleven class-bearing files, no recorded name has ever come from inside a class. The split still runs over the AST rather than the record, so a function added since the measurement keeps its unit; and cmd_merge fails closed on any unrun mutant, so the worst case is a loud red build rather than a score computed over a short set. Measured result. On #1022's weights the pack goes from TOO TIGHT at every shard count to split files : registry.py, store.py and a 58.8-minute tail at ten shards, with catalog.py (5,914,538 ms) as the new floor. On the weights committed today nothing changes at all — registry.py is under the even share, so it is not split and the plan is byte-identical.

Complexity M Impact High Wow ★★★★★ a 30-line class with zero recorded mutants makes the other 7.3M weight-ms of registry.py one indivisible unit, flooring the mutation gate at 95% of its timeout at every shard count

Developer experience & maintainability

// planned · free tooling to catch issues earlier & keep the code legible
ShippedCI · Reproducibility

Pin the lint toolchain so a release can't redden the gate

Write-up · pin-the-lint-toolchain.md

Complexity S Impact High Wow ★★★ unpinned ruff 0.16 reddened every PR
ShippedFeature

make boost mcp the whole setup, and put all three kinds behind it

Write-up · mcp-zero-setup-and-three-kinds.md

Complexity M Impact High Wow ★★★★ measured — a fresh install answers every MCP search with "no skills match", which reads as "boost is empty" rather than "nothing is tapped"
ShippedBug · MCP

A project-scoped install registers its MCP servers machine-wide

Write-up · mcp-servers-ignore-install-scope.md

Complexity M Impact High Wow ★★★★ --scope project installs the skill into the repo and its MCP server machine-wide
ShippedInterop · MCP

MCP-aware skills — declare and wire an .mcp.json on install

Write-up · mcp-aware-skills.md

Complexity L Impact Med Wow ★★★★ skills that need a server
ShippedDX

roadmap.html goes stale on every rebase, so a card and a merge race redden the whole matrix

Write-up · roadmap-html-goes-stale-on-every-rebase.md

Complexity M Impact Med Wow ★★★ two of the three fixes measured dead; one survivor, and it needs a Pages change
ShippedTesting · Bug

make lint reports success when actionlint fails — and says it wasn't installed

Write-up · make-lint-masks-actionlint-failures.md

Complexity S Impact Med Wow ★★★★ fixed — a failing actionlint now fails make, in all three targets
ShippedTesting · Bug

The second silent skip — actionlint runs, and checks no run: block at all

Write-up · actionlint-skips-shellcheck-silently.md

Complexity S Impact Med Wow ★★★★ fixed — shellcheck is pinned in lint-tools and both gates now assert it is there
ShippedInterop · Adoption

MCP — answer the veto that overruled the trigger ("a skill already matched")

Write-up · mcp-already-covered-defeater.md

Complexity M Impact High Wow ★★★★ every trigger was a predicate over the request; the veto was a predicate over the agent's own context
ShippedInterop · Adoption

boost-first — the one rule boost authors, offered opt-in at boost mcp register

Write-up · boost-first-rule.md

Complexity M Impact High Wow ★★★★ the tool descriptions only help on hosts that deliver them — this is the surface that survives when none do
ShippedCatalog · DX

install dead-ends on a registry that vendors its own skills

Write-up · resolve-vendored-duplicate-copies.md

Complexity S Impact Med Wow ★★★★ found by dogfooding — the fix hint re-raised the error it was fixing
ShippedCLI · Install

install refused an ambiguous name and offered no way to answer it

Write-up · install-path-disambiguation.md

Complexity S Impact High Wow ★★★★ the ambiguity error named the paths and no flag could act on them — a dead end
ShippedDX · Feature

boost discover <query> asks GitHub, instead of filtering whatever boost index happened to sample

Write-up · discover-searches-github-not-a-stale-sample.md

Complexity M Impact High Wow ★★★★ an adversarial review of the first draft confirmed 21 defects, two of which would have reddened CI
ShippedFeature

Share the catalogue instead of making everyone re-tap it

Write-up · shareable-catalogue-bundle.md

Complexity M Impact High Wow ★★★★★ 10.9 MB replaces a 12 GB clone — a fresh machine reaches 59,972 searchable items in 4 seconds
ShippedInterop · Adoption

boost-first carried the trigger that had already fired and lost — and could never be updated

Write-up · boost-first-carried-the-losing-trigger.md

Complexity M Impact High Wow ★★★★ the rule shipped the one trigger boost had already measured as losing, and no revision of it could ever reach a machine that had installed it
ShippedDX · Feature

boost serve becomes a searchable, faceted catalogue with a graph of the taps

Write-up · serve-is-a-searchable-catalogue.md

Complexity L Impact High Wow ★★★★★ 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
ShippedBug · UX

browse could not search for two words, and the fix reshaped the whole browser

Write-up · browse-could-not-search-two-words.md

Complexity M Impact High Wow ★★★★ space was bound to select, so two words could never be searched for
ShippedUX · Design

One design system across search and browse

Write-up · search-and-browse-visual-refresh.md

Complexity M Impact High Wow ★★★★ search rows learned kind/tap/installed with a stated drop order; browse got its gradient, an empty state, a badge rail, a list scrollbar and a session chip
ShippedPerformance · MCP

The smart rerank pays the LLM again for a search it already answered

Write-up · smart-rerank-pays-per-novel-query.md

Complexity S Impact High Wow ★★★ MCP boost_search measured 11.7-17 s per call — every call, even a repeat of the last one
ShippedCLI · Output

The box drew 108 columns into an 80-column pane, and --help never asked how wide the pane was

Write-up · cli-output-ignored-the-terminal.md

Complexity S Impact Med Wow ★★★ an 80-command sweep found a box that drew wider than the pane, a help screen that never measured it, and a literal %% on screen
ShippedCLI · Output

The hints still run past the pane, and the worst one is pinned by six test files

Write-up · long-hints-overflow-narrow-panes.md

Complexity M Impact Low Wow ★★ a code span is one atomic token, so a hint folds to the pane without splitting the command it tells you to run
ShippedCLI · Bug

install --dry-run promises agents the real install never writes (antigravity-cli copy, antigravity materialize) and omits the MCP plan

Write-up · audit-install-dry-run-promises-agents-the-real-install-never-write.md

Complexity S Impact High Wow ★★ fixed — dry run now reads agents_for_scope/materializing_agents and plans the MCP action; PR awaiting CI (PyPI unreachable in the authoring sandbox, so make check needs CI's confirmation)
ShippedCLI · UX

AI degrade note blames PATH/API keys regardless of cause; several commands fall back with no note at all

Write-up · audit-ai-degrade-note-blames-path-api-keys-regardless-of-cause-sev.md

Complexity M Impact Med Wow ★★ 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
ShippedCLI · Bug

Dry-runs disagree with the real run: compact, heal and onboard previews mispredict

Write-up · audit-dry-runs-disagree-with-the-real-run-compact-counts-bytes-it.md

Complexity M Impact Med Wow ★★ fixed — compact counts only what reapply removes and previews a reclone as one; heal words the branch sync takes and names its directories; onboard marks its cut and checks --pr first
ShippedCLI · Bug

--json accepted but ignored: cohort/config/policy set, focus, profile, replay rollback, who empty state

Write-up · audit-json-accepted-but-ignored-on-many-branches-cohort-config-pol.md

Complexity M Impact Med Wow ★ shipped in PR 804 — all seven sites now emit JSON (or reject --json as a usage error, for `update` without `--shards`); CI's full check suite (lint, evals, tests, smoke, mutation) is green on the merge-ready head
PlannedCLI · Bug

Project scope in an unmarked tree does not walk up, so src/ becomes its own project

scopes.resolve_base walks up for a VCS marker and, finding none, falls back to the directory it started in · without walking up. So in a project that is not a git/hg/svn checkout, every subdirectory is its own project: install brainstorming --local run from proj/src writes proj/src/.boost/skill-lock.json and proj/src/.claude/skills/, even when proj/.boost/skill-lock.json already exists; and list --local, info, doctor, verify and bare uninstall run from proj/src cannot see what was installed at proj. mkdir .git fixes both, which is what makes it easy to miss. This is not the reader/writer split that fix(scope) closed · readers and writers now agree, and that is the point: they agree on the cwd rather than on the project. project_root's docstring says walking up is the whole point ("install --local run from src/deep/nested must write into the repo's .claude/skills, not create a stray one three levels down"), and that promise is simply not kept once the marker is absent. The fix is a choice, not a bug fix, which is why it is its own card. Option (a): make the fallback walk up for an existing .boost/skill-lock.json · but a lock-file marker cannot help the very first install, which is the one that creates it. Option (b): let the fallback walk up to the nearest ancestor that is not $HOME · too greedy, it would swallow unrelated sibling directories. Option (c): keep today's behaviour and say so · have install --local warn once when it is about to create a project in a directory with no VCS marker, naming the directory, so the second lock is a decision rather than a surprise. (c) is the cheapest and the most honest; (a) is worth pairing with it for every command after the first. Found by the adversarial verification of PR #998, which reproduced it end to end. $HOME is still never a project and deletion is still gated by resolve_in_base, so this is a wrong-directory bug, not a safety one.

Complexity M Impact Med Wow ★★ install --local from a subdirectory of an unmarked project creates a second lock there
PlannedCLI · Bug

A rule or workflow installed --local reads as a user one everywhere but list --local

Rules and workflows installed with --local materialize into the repo but are recorded in the user lock, tagged scope: project and base: <repo>, because a project lock holds skills and nothing else (store._check_scope_conflict). boost list --local now filters them with scopes.owned_by, and it is the only reader that does. lockfile.installed_rules() and installed_workflows() have a dozen other consumers — store, complete, taps, team, safety, quality, pkg — and none of them ask whose repo a row belongs to. So boost doctor and boost verify count another checkout's rule as this machine's, drift and health grade it, tab-completion offers it, and plain boost list prints it under “installed rules” with nothing saying it belongs to a directory the user may not be standing in. The failure is quiet in both directions: a row for a repo that has since been deleted never goes away, and a row for the repo you are in looks identical to one for a repo you are not. Worth settling the design before the sweep, because the honest answer differs per command. A scope column on plain list's rule and workflow tables is cheap and makes the ambiguity visible (boost info already prints scope project). Whether verify and doctor should grade a rule belonging to another repo is a separate question — they cannot read its materializations from here, so counting it is arguably the bug and skipping it with a note the honest fix. Split out of audit-project-scope-seams-uninstall-verify-list-info-reinstall-dis, where the evidence was gathered.

Complexity S Impact Low Wow ★★ a project-scoped rule reads as a user one in doctor, verify, drift, health and update
ShippedCLI · Bug

boost ROOT: CLI audit findings (2026-08)

Write-up · audit-root-findings.md

Complexity S Impact Low Wow ★ EPIPE exits 120 with stderr noise; `help version` suggests verify; launcher gates at 3.9
ShippedCLI · Consistency

boost absorb: CLI audit findings (2026-08)

Write-up · audit-absorb-findings.md

Complexity S Impact Low Wow ★ absorb is the only generated-skill command with no journal.log call at all
In flightCLI · Bug

boost adapt: CLI audit findings (2026-08)

A subagent named after a declared tool renders modules that compile but cannot run. With a subagent grep and tool Grep: crewai emits @tool("grep") def grep then grep = Agent(...), so reviewer_1 = Agent(tools=[read, grep]) hands the Agent where a tool belongs (stub run: TypeError); langgraph assigns grep = create_react_agent(...) inside build_mycrew, making it local, so the earlier tools=[read, grep] raises UnboundLocalError. _unique_idents (core/adapters.py:188-202) dedups only among agent specs and _unique_tools (:205-212) allocates stub names independently. Fix: pass the tool ident set into _unique_idents as pre-reserved names (or prefix stubs tool_<name>) in render_crew/render_graph, plus a golden test that executes a colliding render against stubs.

docs/commands.html brackets required options as optional. Line 369 shows boost adapt [--to FRAMEWORK] … while adapt --help prints an unbracketed --to FRAMEWORK and omitting it exits 2 — and the verify pass found it is broader than adapt: evolve's required --feedback and catalog's required mutually-exclusive group render all-optional too. Pure generator bug: scripts/build_command_reference.py:122-126 brackets every option unconditionally. Emit required options unbracketed (a required group as (--a | --b)), prefer the short flag like argparse, then make generate — the --check gate holds it after that.

Colon-form model ids get double-prefixed for the LiteLLM targets. --model anthropic:claude-x — the form langgraph accepts and emits — renders llm=LLM(model="anthropic/anthropic:claude-x") for crewai and the same for agents-sdk; multi-agent crews inherit it via adapters.py:376. _litellm_model's docstring says a provider-qualified value passes through, but the code checks only /. Fix: replace the first : with / before deciding to prefix (mirror of _langchain_model); document accepted syntaxes in docs/adapters.html's --model paragraph (~line 344, slash form only today), and regenerate docs/commands.html only if the argparse help changes.

adapt -o and run --print -o write generated source mode 0600 — and re-rendering over an existing 0644 file silently downgrades it, unlike a shell redirect (-rw------- vs -rw-r--r-- under umask 022). util.atomic_write_text (core/util.py:91-116) inherits mkstemp's 0600, right for the lock/config it was written for, wrong for source the user asked boost to write. Fix: add an optional mode parameter (fchmod the temp fd before os.replace), keep 0600 the default, and have cmd_adapt (pkg.py:1753-1761) and cmd_run (run.py:62) pass the umask default. Still open — an implementation of exactly this shape (path-based os.chmod, not os.fchmod, learned the hard way: the latter raises on Windows) shipped and then was reverted from PR #728 after three rounds of Windows-only windows-latest CI failures in the "unit + functional (90% coverage gate)" step that neither pytest-cov nor a temporary diagnostic artifact-upload commit could surface a cause for — the session driving that PR could not read Windows job logs (capped and consumed by harden-runner's own diagnostic noise) or download the diagnostic artifact (productionresultssa*.blob.core.windows.net blocked by that session's network egress policy) to see the actual failure. The other three findings landed clean on every platform. Whoever picks this back up needs either a session with working Windows CI log access, or to reproduce locally on a real Windows box.

Found by the 2026-08 CLI audit (clusters adapt-ident-collision, docs-required-flag-synopsis, adapt-model-id-syntax, generated-file-mode); repro in the audit log.

Complexity M Impact Med Wow ★★ PR
ShippedCLI · UX

boost bmad: CLI audit findings (2026-08)

Write-up · audit-bmad-findings.md

Complexity M Impact Med Wow ★ an edited persona reads "not installed"; each no-op bmad on burns 4 of 50 history slots
ShippedCLI · Bug

boost browse: CLI audit findings (2026-08)

Write-up · audit-browse-findings.md

Complexity S Impact Med Wow ★ both findings fixed in PR; make check unrunnable in the sandbox (no PyPI/apt egress) — CI is the real gate
ShippedCLI · UX

boost bundle: CLI audit findings (2026-08)

Write-up · audit-bundle-findings.md

Complexity M Impact Med Wow ★ mismatched tap/version lines count "already present" — the Boostfile stops being reproducible
ShippedCLI · Bug

boost catalog: CLI audit findings (2026-08)

Write-up · audit-catalog-findings.md

Complexity S Impact Med Wow ★ --show says "22 taps" then tables exactly 20; --export ships sender-machine paths as URLs
ShippedCLI · Bug

boost changelog: CLI audit findings (2026-08)

Write-up · audit-changelog-findings.md

Complexity M Impact Med Wow ★ fetch --unshallow advised on complete clones; rules/workflows logged at directory granularity
ShippedCLI · Bug

boost chat: CLI audit findings (2026-08)

Write-up · audit-chat-findings.md

Complexity M Impact Med Wow ★★ chat follow-ups like "which of these" lead with the previous turn; no "> " prompt on piped stdin; search takes -k
ShippedCLI · Bug

boost cohort: CLI audit findings (2026-08)

Write-up · audit-cohort-findings.md

Complexity S Impact Low Wow ★ fixed in PR #767 — all 41 CI checks green, including mutation, evals, and the full test matrix
ShippedCLI · UX

boost completions: CLI audit findings (2026-08)

Write-up · audit-completions-findings.md

Complexity M Impact Low Wow ★ CI ran the full pinned toolchain (lint, all mutation shards + gate, evals, full OS/version test matrix, DCO) and came back green with no merge conflict and no open review threads — the local sandbox couldn't run mutmut/vulture/etc. (PyPI blocked), so CI is what actually confirms this landed clean
ShippedCLI · Bug

boost config: CLI audit findings (2026-08)

Write-up · audit-config-findings.md

Complexity S Impact Low Wow ★★ `config unset` on a pristine HOME creates config.json and freezes all defaults into it
ShippedCLI · Bug

boost context: CLI audit findings (2026-08)

Write-up · audit-context-findings.md

Complexity S Impact Med Wow ★ git missing from PATH is reported as "not in a git repository", even inside a repo
ShippedCLI · Bug

boost deps: CLI audit findings (2026-08)

Write-up · audit-deps-findings.md

Complexity S Impact Med Wow ★★ deps shows ✗ not installed yet exits 0; the only real-world requires: shape reads as (none)
ShippedCLI · UX

boost discover: CLI audit findings (2026-08)

Write-up · audit-discover-findings.md

Complexity S Impact Low Wow ★ footer blames the network when gh is missing; --json prints [] silently with no index
ShippedCLI · Bug

boost edit: CLI audit findings (2026-08)

Write-up · audit-edit-findings.md

Complexity S Impact Med Wow ★ editor fails → green "✓ no changes", exit 0; drift calls a local edit upstream-moved
ShippedCLI · Bug

boost evolve: CLI audit findings (2026-08)

Write-up · audit-evolve-findings.md

Complexity M Impact Med Wow ★ empty --feedback writes an empty section + version bump; the revision is left unpinned
ShippedSafety · Bug

boost explain: CLI audit findings (2026-08)

Write-up · audit-explain-findings.md

Complexity M Impact Med Wow ★★ fabricated Kubernetes/Flyway summary scores faithfulness 1.0 and prints verbatim
ShippedCLI · Bug

boost export: CLI audit findings (2026-08)

Write-up · audit-export-findings.md

Complexity M Impact Med Wow ★ -o x.zip writes a gzip tarball; the repair hint drops the skill from the lock instead
ShippedCLI · Bug

boost import: CLI audit findings (2026-08)

Write-up · audit-import-findings.md

Complexity M Impact Med Wow ★ import turns a tap install into "local" silently; a URL import records a deleted temp path
ShippedCLI · Bug

boost index: CLI audit findings (2026-08)

Write-up · audit-index-findings.md

Complexity S Impact Med Wow ★ PR #802: progress bar clears before raise/warn, 0 results keeps the previous index, gh rate-limit/403 gets a native hint — CI green (lint/eval/test/smoke/mutation), awaiting human merge
In flightCLI · Bug

boost install: CLI audit findings (2026-08)

Rule/workflow lock entries are name-keyed across scopes (med). With the benchmarking rule at user scope, install benchmarking --local in a project fails “Error: benchmarking is already installed / hint: boost reinstall benchmarking to force” — the project has no copy, and the hint would reinstall the user one. The reverse direction blocks too, and skills coexist fine (separate project lock). Worse, the --force escape overwrites the user-scope lock entry with the project one, orphaning the user materializations so uninstall can no longer clean them. _install_rule (store.py:836-839) and _install_workflow (store.py:1074) gate on a name-only lookup with no scope/base comparison. Fix: key entries by scope (or compare existing scope/base before raising), word the error “already installed at user scope”, and refuse a cross-scope --force overwrite without cleanup. Docs: README's install-scope section (~301-328) and docs/roadmap/items/install-scope-user-or-project.md. (Cluster cross-scope-name-block.)

--path says “under path” but matches suffix-only (low). --path plugins/tdd/skills is refused while the error's own hint lists plugins/tdd/skills/test-driven-development — a path that is under it. Suffix matching is the shipped design (install-path-disambiguation, PR 483); the wording is the defect. Reword the raise in catalog.py:~502 to “no copy of X whose path ends with Y” and hint “pass a trailing segment of one of: …”. (Cluster install-path-prefix-match.)

The MCP offer never shows the runnable command (low). The server row prints only demo-echo  npx though the sidecar declares npx -y @example/demo-echo-mcp plus env, and on decline the hint is a literal elided claude mcp add …; the full argv only prints when the host CLI is missing. _offer_mcp renders how from spec['command'] alone (pkg.py:161-164) and mcpdecl.register_argv already exists (pkg.py:201) — render command+args, print the joined argv on decline, and indent the confirm prompt to match its neighbours. (Cluster mcp-offer-command-detail.)

The typosquat warning prints three times (low). install NeoLabHQ/context-engineering-kit:test-driven-development --dry-run prints the identical “closely resembles test-driven-development (sickn33/antigravity-awesome-skills)” warning 3×, one per mirror copy in the look-alike tap. De-duplicate find_confusions on (name.lower(), tap) (typosquat.py:79-87) so the [:3] slice in _warn_confusions covers three distinct look-alikes. Found by the 2026-08 CLI audit (cluster typosquat-warning-dupes); repro in the audit log. Status (2026-09). Three of the four clusters shipped as described above: install-path-prefix-match (catalog.py wording), mcp-offer-command-detail (mcpdecl.command_line renders the full command+args, the decline path prints the real argv), and typosquat-warning-dupes (find_confusions dedupes on (name.lower(), tap)). cross-scope-name-block got the narrower of the fix's own two options: store._check_scope_conflict now refuses a rule/workflow install whose name collides with an existing lock entry recorded under a different scope/base — naming the real location ("already installed at user scope") and refusing even under --force, which closes the silent-corruption half of the bug (a forced cross-scope install used to overwrite the other scope's lock entry, orphaning its materializations). What is still missing is the other half: rules and workflows still cannot coexist across scopes the way skills do, because they share one lock keyed by bare name with no per-location table — skills got a separate projectlock.py when project scope was added, rules/workflows never did. Giving them the same treatment (a rules/workflows section in projectlock.py, wiring _install_rule/_install_workflow and their uninstall/sync counterparts through it for project scope) is real coexistence but is its own, larger change, and belongs in its own card rather than folded into a bugfix PR.

Complexity M Impact Med Wow ★ 3 of 4 clusters landed; cross-scope-name-block gets a safe refusal, not true coexistence
ShippedCLI · Bug

boost log: CLI audit findings (2026-08)

Write-up · audit-log-findings.md

Complexity S Impact Med Wow ★ fixed — cli.main() now catches SystemExit and journals the real rc for --help/usage exits
ShippedCLI · Bug

boost mcp: CLI audit findings (2026-08)

Write-up · audit-mcp-findings.md

Complexity M Impact Med Wow ★ no --dry-run; a named missing host exits 0; unregister claims success Gemini denies
ShippedSafety · Bug

boost onboard: CLI audit findings (2026-08)

Write-up · audit-onboard-findings.md

Complexity S Impact Med Wow ★ onboard --pr pushes absolute /Users/… paths from the global lock file to GitHub
ShippedCLI · Bug

boost outdated: CLI audit findings (2026-08)

Write-up · audit-outdated-findings.md

Complexity S Impact Med Wow ★ an untapped skill vanishes from outdated; the same untapped rule shows "source missing"
ShippedCLI · UX

boost preview: CLI audit findings (2026-08)

Write-up · audit-preview-findings.md

Complexity S Impact Med Wow ★ piped preview strips ** with no substitute; at 60 cols 10 lines leak raw markers
ShippedCLI · Bug

boost profile use: CLI audit findings (2026-08)

Write-up · audit-profile-findings.md

Complexity S Impact Low Wow ★ declined --prune leaves extras fully linked yet still prints "✓ switched"
ShippedCLI · Bug

boost protocol: CLI audit findings (2026-08)

Write-up · audit-protocol-findings.md

Complexity S Impact Med Wow ★ macOS status reads "registered" though register never calls Launch Services
ShippedCLI · UX

boost pulse: CLI audit findings (2026-08)

Write-up · audit-pulse-findings.md

Complexity S Impact Med Wow ★ fix implemented + tested; make check's eval/mutation/smoke gates could not run locally (no PyPI egress) — see PR for what did run
ShippedCLI · Bug

boost quickstart: CLI audit findings (2026-08)

Write-up · audit-quickstart-findings.md

Complexity M Impact Med Wow ★★ without [rag] quickstart taps unpinned at HEAD, and a rerun can never pin them
ShippedCLI · Bug

boost recommend: CLI audit findings (2026-08)

Write-up · audit-recommend-findings.md

Complexity M Impact Med Wow ★★ curated picks repeat one name 6 of 8 rows; --json returns [] while text prints them
ShippedCLI · Bug

boost replay: CLI audit findings (2026-08)

Write-up · audit-replay-findings.md

Complexity S Impact Low Wow ★ rollback says "complete" (exit 0) with a skill unrestored, and replans it forever
ShippedCLI · Bug

boost run: CLI audit findings (2026-08)

Write-up · audit-run-findings.md

Complexity S Impact Low Wow ★ the 55-line runner's banner names a command that produces a 9-line file
ShippedCLI · Bug

boost schedule: CLI audit findings (2026-08)

Write-up · audit-schedule-findings.md

Complexity S Impact Med Wow ★★ 'interval every None' without StartInterval — and StartInterval 0 hangs status forever
ShippedCLI · Bug

boost search: CLI audit findings (2026-08)

Write-up · audit-search-findings.md

Complexity M Impact Med Wow ★★ CJK rows 72 cells in a 60 pane; --json drops --smart; '60 matches' is the cap, not the count
ShippedCLI · UX

boost simulate: CLI audit findings (2026-08)

Write-up · audit-simulate-findings.md

Complexity S Impact Low Wow ★ fixed — norm_rule lowercases the whole modal; trigger desc clips on a word boundary
ShippedCLI · Bug

boost sync: CLI audit findings (2026-08)

Write-up · audit-sync-findings.md

Complexity M Impact Med Wow ★★ First sync run hides a blocked link; --diff prints it as a raw Python tuple
In flightCLI · Bug

boost tag: CLI audit findings (2026-08)

boost tag swallows unknown flags and misreads them as operands. tag brainstorming --verbose prints the current tags and exits 0 — the flag is consumed as a removal of the tag -verbose; tag --verbose gives "Error: --verbose is not installed" (the flag becomes a skill name); verification found a third hole: tag brainstorming --list silently discards the skill-name operand and lists all tags. Cause: cmd_tag's manual split (boost_cli/commands/info.py:988-993) whitelists only --list/--json/-h/--help; every other --x token falls through as an operand. Every sibling command rejects unknown options with "unrecognized arguments" exit 2. And the mutation path has no before/after check. tag brainstorming -nosuch removes a tag that was never present — silent, exit 0; tag brainstorming +x -x prints ✓ and writes the lock plus a journal event for a net no-op (changed is set per-token at info.py:1027-1041, never compared to the before set); "+with space" is accepted as #with space; +Design and #design coexist. The shipped roadmap item robust-tag-argument-parsing (PR 94) built this manual split — these are residual holes in it, not a duplicate. Fix in cmd_tag: hand any token starting with -- (or -letter that is not a tag operand) to argparse so it errors; compute changed = sorted(tags) != sorted(before); print a one-line notice for removing an absent tag; reject whitespace in tags; document or fold case; error when a name is given with --list. Regenerate docs/commands.html if the help text gains the tag grammar. Found by the 2026-08 CLI audit (cluster tag-arg-parsing); repro in the audit log. Partly landed — PR 735. The correctness half shipped: any unrecognized -- token now reaches argparse (unrecognized arguments, exit 2), --list with a skill name is a named error, whitespace in a tag is rejected, and changed is a before/after set comparison in the new lockfile.apply_tag_mods, so +x -x no longer writes the lock and a journal event for a net no-op. Still open, and why this card stays inflight: the one-line notice when -tag removes a tag that was never present (the remove branch is still a silent no-op), and documenting or folding tag case (+Design and #design still coexist). Both are UX asks rather than correctness bugs, which is why the PR left them.

Complexity S Impact Med Wow ★★ tag brainstorming --verbose exits 0 as a remove of '-verbose'; +x -x writes lock + journal
ShippedCLI · Bug

boost tap: CLI audit findings (2026-08)

Write-up · audit-tap-findings.md

Complexity S Impact Med Wow ★ a missing local dir is cloned as https://github.com//private/tmp/… before any check
ShippedCLI · UX

boost taps: CLI audit findings (2026-08)

Write-up · audit-taps-findings.md

Complexity S Impact Low Wow ★ one UPDATED column shows "@b29e7cf", "2026-07-24" and "11h ago" with no legend
ShippedCLI · UX

boost unpin: CLI audit findings (2026-08)

Write-up · audit-unpin-findings.md

Complexity S Impact Low Wow ★ unpin prints 'released the commit pin too' before the unpinned line it qualifies
ShippedCLI · UX

boost untap: CLI audit findings (2026-08)

Write-up · audit-untap-findings.md

Complexity S Impact Low Wow ★ tap takes several SPECs in parallel; untap still errors on a second name
ShippedCLI · Performance

boost update: CLI audit findings (2026-08)

Write-up · audit-update-findings.md

Complexity M Impact Med Wow ★ a no-op update over 20 taps takes ~14 s serial; --force drops 20 pins without a word
ShippedCLI · Bug

boost who: CLI audit findings (2026-08)

Write-up · audit-who-findings.md

Complexity S Impact Med Wow ★ 29 "skills" = 20 tap names + "10152 passages" + 5 cohort names + 3 real items
ShippedCLI · Audit

August 2026 full-CLI audit: every one of the 81 boost commands exercised and verified

Write-up · cli-audit-2026-08-full-sweep.md

Complexity L Impact High Wow ★★ 81 commands, ~2,000+ invocations, 367 findings, 161 clusters, 107 cards on the board
In flightCatalog · UX

Per-item categories in search/browse/info — not just a ★ curated bool

From a user request: “proper categories for skills (can't have all of them listed as just curated)”. They are right about the item level: the only taxonomy a catalog entry carries is a boolean. A boost search row shows name, kind, tap, description and at most a ★; boost recommend's no-match fallback is literally headed “curated picks”; boost info prints no category at all. Across a real install of tens of thousands of items, “starred or not” is the entire classification a user can see or filter by. What the code confirms. catalog._make_entry stamps "curated": curated onto every entry (boost_cli/core/catalog.py:119, signature at 105–106) — and that bool is per-tap, from Tap.curated (core/registry.py:23), set by tap --defaults or by anyone passing --curated (commands/taps.py:126) — a trust star, not a classification. Category-like data does exist, but only per tap: data/registries.json rows carry one (487 registries, 21 values; general alone covers 127), and exactly two surfaces read it — browse's row badge via _tap_categories (commands/discovery.py:936–941, whose own docstring says “catalog entries themselves carry no category, only their tap does”; badge appended last in _row_badges, discovery.py:961–963, so narrow panes drop it first, and taps outside the bundled 487 get none) — and boost serve's web facets (core/serve.py:65). cmd_search renders only the star (discovery.py:179) and takes no filter flag; info shows frontmatter tags when present (commands/info.py, the meta.get("tags") kv) but no category, and its --json has no such field. An item's own frontmatter category/tags ride along invisibly in entry["meta"] and the substring search_blob (catalog.py:131, 621–627), so they can match a query yet can never be displayed or filtered. Proposed fix. Stamp a first-class category on each entry at scan time in _make_entry (catalog.py:105–132): the item's frontmatter category (or first tag) when declared, else inherited from its tap's registry category — and bump catalog.CACHE_FORMAT so hundreds of existing tap caches backfill without a re-tap, per the versioned-cache rule. Then surface it where a category would live: a badge in search rows and a --category filter on search/browse/recommend, a kv row plus JSON field in info, and browse's existing badge switched from tap-level to the entry field (which also gives un-bundled taps' items a label for the first time). ★ keeps meaning curation/trust only. Consumers must degrade cleanly when category is absent (old caches, synthesised entries), same as the content digest rule. Docs: regenerate docs/commands.html for the new flags; no other doc names categories. Found by the 2026-08 CLI audit (cluster catalog-categories-beyond-curated, filed from the user's request); repro in the audit log. Verified against source 2026-08-31. Status (2026-09-01). Landed: the category stamp at scan time (catalog._entry_category, own frontmatter category → first tags entry → tap's registry category), CACHE_FORMAT bumped to 2 so existing caches backfill on next scan, a --category filter on search/browse/recommend (catalog.matches_category/filter_by_category), info's kv row and --json field, and browse's row badge switched from the tap-level lookup to the entry's own field (falling back to the tap lookup for a cache not yet rescanned). Not done: the badge in plain boost search rows. That row's column widths (out.search_layout/format_search_row) are a tuned, heavily-pinned budget system (drop order, per-cap name shrinking, a reserved curated tail) — working it out safely needs its own pass rather than a bolt-on inside this PR. Left inflight rather than shipped for that reason; the next claim on this item is scoped to exactly that piece.

Complexity M Impact Med Wow ★★ landed everywhere except the search-row badge — see PR for what remains
ShippedBug

The last command that blamed boost for the user's typo

Write-up · typos-reported-as-boost-bugs.md

Complexity S Impact Med Wow ★★★★ `boost create --dir` answered a mistyped path with "file it at github.com/.../issues"
ShippedAgents · BMAD

The BMAD router reads each prompt alone, so a pasted log, an “ok update both and rerun” and a yes/no question all get a banner

Write-up · bmad-router-reads-each-prompt-alone.md

Complexity M Impact High Wow ★★★ pastes, follow-up replies and yes/no questions get delegation banners
ShippedAgents · BMAD

boost bmad gives every track the build contract, so a review is told to finish a change

Write-up · bmad-done-contract-ignores-the-track.md

Complexity M Impact High Wow ★★ a review or research ask is told to add tests and finish a change
ShippedAgents · BMAD

The autopilot routes docs at a skill BMAD 6.12 no longer installs, and no test would notice

Write-up · bmad-roster-drifted-from-bmad-6-12.md

Complexity M Impact Med Wow ★★ docs routes at a skill no default 6.12 install contains
ShippedCLI · Bug

out.err() judges colour by stdout while writing to stderr

Write-up · err-colour-judged-by-stdout.md

Complexity S Impact Low Wow ★ fixed — every painter takes the stream it is painting for, and all nine call sites that write off stdout pass theirs, so each line is coloured by where it lands
PlannedCLI · UX

boost quickstart: a rerun could move already-tapped registries to their vectors

A rerun of quickstart still leaves an already-tapped registry at the commit it was tapped at. registry.add_many skips a configured tap (already tapped), so a registry first tapped before quickstart pinned anything, or overtaken by a weekly republish, stays where it is, and shards.sync then refuses its shard (tap is at X, shard is for Y). The audit-quickstart-findings fix flags that refusal and names boost update --shards, which already moves such taps through shards.ingest (download and verify first, then move the tap). That was the smaller half of the card; its other half was to have quickstart do the move itself. Fix: on a rerun, hand the configured taps the manifest publishes to shards.ingest instead of shards.sync, so the vectors land in one command. Decide first whether quickstart may move a tap the user tapped on purpose at another commit: boost update treats a pin as a promise, and a tap pinned with boost tap --at should keep it. Pin that choice in tests/functional/test_cli_quickstart.py beside the commit_moved tests.

Complexity M Impact Med Wow ★★ a rerun leaves an already-tapped registry where it is, even when the manifest names another commit

Docs-site & content quality

// planned · free tooling for the Pages site, README & prose
ShippedDocs

The OpenSSF badge playbook

Write-up · openssf-playbook.md

Complexity S Impact Med Wow ★★★ the method, not the answers — so another repo can repeat it
ShippedDocs · Onboarding

The engine had no architecture diagram — and the one written rule was documented backwards

Write-up · internal-architecture-diagrams.md

Complexity M Impact Med Wow ★★★ 45 core modules and an enforced layering rule, with no diagram of either
ShippedDocs · Design system

A GIF carousel touring one flagship command per group

Write-up · command-carousel-page.md

Complexity M Impact Med Wow ★★★★ 8 GIFs · one flagship per group
ShippedDocs · Performance

The Lighthouse budget passes on noise, not on margin

Write-up · roadmap-perf-budget-has-no-local-guard.md

Complexity S Impact Medium Wow ★★★★ main passes this budget on run-to-run luck — its own three runs are 0.810, 0.840, 0.850
ShippedDocs · Interop

an explainer page for the LangChain / LangGraph / LangSmith integration

Write-up · langchain-integration-explainer-page.md

Complexity M Impact Med Wow ★★★★ the eval.html genre, pointed at the LangChain stack — and it can only document what has shipped
ShippedDocsite · Bug

Expanded card bodies overflow the roadmap board sideways

Write-up · expanded-card-bodies-overflow.md

Complexity S Impact Med Wow ★★★ the closed <details> was added for paint cost and is quietly also the only thing keeping long code tokens on the page
ShippedCI · Bug

The performance gate flips on byte-identical input

Write-up · lighthouse-flips-on-byte-identical-input.md

Complexity M Impact High Wow ★★★★ the same roadmap.html scored 0.78 and passed, then 0.78 and failed — the gate now decides on runner noise

Compatibility & install integrity

// planned · free tooling to prove boost installs & runs everywhere it claims
ShippedCompat

What Gemini actually receives from boost, audited

Write-up · gemini-mcp-parity.md

Complexity M Impact Med Wow ★★★ audited what Gemini actually receives — two of three findings were our own wrong claims
ShippedCompat

boost hooks learns a second host — and finds two bugs upstream

Write-up · gemini-hooks-host-aware.md

Complexity M Impact Med Wow ★★★★ two upstream Gemini bugs found while establishing the schema
ShippedRelease

ship the LangChain integration inside the wheel, behind a [langchain] extra

Write-up · langchain-in-the-wheel.md

Complexity M Impact High Wow ★★★ same import, same tests, zero new infrastructure — the wheel that already ships on every merge carries the integration too
ShippedBug

sanitize agent frontmatter for Gemini instead of copying it verbatim

Write-up · gemini-agent-frontmatter-sanitizer.md

Complexity S Impact Med Wow ★★ measured on Gemini CLI 0.53.1 — a boost-installed agent fails Zod validation at startup, and hand-fixes regress on the next sync
ShippedInterop · Registry

garrytan/gstack — tap it first, then learn to coexist with it

Write-up · gstack-tap-first-then-coexistence.md

Complexity M Impact Med Wow ★★★ 130k stars of SKILL.md that boost can index today, and a second installer writing into the same dotdirs
ShippedPortability · Windows

73 reads and writes left the text encoding to the locale, and the Windows jobs were the only thing that noticed

Write-up · text-io-leaves-its-encoding-to-the-locale.md

Complexity M Impact Med Wow ★★ all 73 encoded; the guard is repo-wide over 414 files; the newline half is its own card
PlannedPortability · Windows

917 text writes leave the line ending to the platform, and only some of them are bugs

Text mode decides two things, and naming the encoding fixes one of them. It also translates \n to the platform separator on write, so a file written with encoding="utf-8" on a GitHub Windows runner still holds CRLF. The sibling card text-io-leaves-its-encoding-to-the-locale closed the encoding half across 414 files; this is the other half, and it is deliberately not the same kind of sweep. #1012 hit both, one after the other, and the first fix hid the second. Naming the encoding turned the three tests (windows-latest, 3.1x) jobs green on the assertion that had failed — and the next run put them straight back to red on the line endings of the same line. Two platform defects in one call, and no way to see the second until the first was gone. The count is 917, and a blanket pass would be wrong. 858 in tests, 32 in boost_cli, 21 in scripts, 6 in evals. Most of those writes produce files whose line endings nothing ever compares, so pinning newline="\n" on all of them is 917 edits of which the overwhelming majority are churn and none is a fix — and churn in a diff is what makes the real change unreviewable. Readers need nothing at all: universal newlines already fold CRLF to LF on the way in, which is why the guard that ships with the encoding card walks writers only. So the work is the scoping, not the edit. The subset that matters is writers whose output is read back and compared — against a string, a hash, a golden file, or the same report printed to a log beside it. Three shapes are known to qualify and are a good place to start the inventory: a file written here and read back by an assertion in the same test; anything hashed or diffed (fingerprint, the generated-file --check gates, golden fixtures); and anything a second process parses line by line, which is how $GITHUB_OUTPUT got onto the list. scripts/mutation_shards.py is already pinned and already guarded by TestTheScriptPinsItsNewlines — extending that guard a scoped set at a time, with the reason each set is in it, is the shape this should take. What would make it falsifiable. A Windows job that asserts byte equality, not string equality: today a round trip on Linux passes whether the newline is pinned or not, which is exactly the class of test the encoding card's own verification pass caught twice. The AST walker (unpinned_newline in tests/unit/test_text_io_names_its_encoding.py) is the platform-independent half and already exists; what it cannot tell you is which of the 917 are bugs.

Complexity M Impact Med Wow ★★ 917 text writes take the platform line ending; only the compared ones are bugs

Skill-content trust & safety

// planned · boost's core threat model — the third-party skills it installs run inside an agent
ShippedSecurity · Content

The MCP boost_install tool skipped the injection scan the CLI runs

Write-up · mcp-install-skips-the-injection-scan.md

Complexity S Impact High Wow ★★★★ the one install path with no human watching was the one not scanning
ShippedSupply chain

sbom.yml has never run — it waits for an event GITHUB_TOKEN cannot emit

Write-up · sbom-release-event-never-fires.md

Complexity S Impact High Wow ★★★★ 253 releases shipped with no SBOM; fixed with workflow_run
ShippedRelease safety

The code_scanning ruleset rule can go back on — but only scoped to CodeQL

Write-up · code-scanning-rule-can-be-restored.md

Complexity S Impact Med Wow ★★★★ safe scoped to CodeQL (0 open) — adding Scorecard deadlocks every merge
ShippedSupply chain · Bug

The SBOM can declare a different version than the release it is attached to

Write-up · sbom-declares-the-wrong-version.md

Complexity S Impact High Wow ★★★★★ fixed — release v1.0.278's SBOM declared 1.0.277; the version is now pinned to the tag
ShippedSecurity · Correctness

rules and workflows install, then cannot be governed

Write-up · rules-install-but-cannot-be-governed.md

Complexity L Impact High Wow ★★★★★ an upstream push rewrote CLAUDE.md silently; pin and quarantine both answered "not installed"
ShippedSecurity · Bug

boost serve echoed the request path back into its 404 body

Write-up · serve-404-reflected-the-request.md

Complexity S Impact Med Wow ★★★ the test suite pinned the echo in place as if it were the contract
ShippedTrust · UX

boost attest: CLI audit findings (2026-08)

Write-up · audit-attest-findings.md

Complexity S Impact Low Wow ★ a deleted store dir is reported as a sha mismatch; drift names the same state correctly
ShippedCLI · Bug

boost trust: CLI audit findings (2026-08)

Write-up · audit-trust-findings.md

Complexity S Impact Med Wow ★ trust add of a missing .pub path blames "invalid base64 in minisign data"
In flightTests · Flake

The add_many concurrency probe measured a race, not the pool

test_it_actually_runs_concurrently counted the peak number of fake clones in flight and asserted it exceeded one. The fake clone is one mkdir and a small write, so the window in which two of them overlap is microseconds wide · on a loaded runner each worker finished before the next was scheduled, the peak stayed at 1, and the required tests (macos-latest, 3.14) check failed with assert 1 > 1 against a ThreadPoolExecutor that was doing exactly its job. Observed on PR #998, where it blocked a merge for a defect that did not exist. The failure said the wrong thing, which is the part that matters. "This is serial" and "this was too fast to catch overlapping" are different diagnoses, and the second wastes whoever reads it. A required check that can fail for a reason unrelated to the change also trains the next person to re-run rather than read · which is how a real regression gets waved through. A threading.Barrier(jobs) inverts the dependency. Every worker blocks until jobs of them have arrived, so the assertion stops being about timing: a pool of four trips the barrier and the call returns, and a pool narrower than four cannot — the first worker waits for peers that will never come and the barrier times out. Slower hardware makes the test more reliable rather than less, which is the opposite of the property it had. Paired with test_the_concurrency_probe_fails_when_the_pool_is_serial, which drives add_many at jobs=1 so the probe's own ability to fail is itself asserted, and verified by hand against a max_workers=1 executor: it fails with "the pool never had 4 clones in flight".

Complexity S Impact Med Wow ★★ assert 1 > 1 on macOS/3.14 against a thread pool that was working correctly
PlannedCore · Security

install --local writes through a redirected dotdir that uninstall --local will not remove

A repo that commits <repo>/.cursor → config/cursor — an ordinary dotfile layout, not an attack — gets two different answers from the two halves of the same command. _install_project_skill gates its target with scopes.ensure_in_base, which is containment only, so boost install --local writes config/cursor/skills/<name> and records the row it spelled, .cursor/skills/<name>. boost uninstall --local then refuses that row, because scopes.parent_matches_spelling walks the parent for real and finds the redirect. Boost's own copy is left on disk and the lock entry goes anyway, so a second uninstall answers not installed in this project. Reproduced on the commit that introduced the guard: install wrote through the symlink, uninstall reported the row as redirected, and the directory survived. The uninstall side is right and is not the thing to change. The benign layout and the attack are byte-identical on disk: .claude/skills → ../src with a legally-spelled lock row is the same two objects in the same two places, and nothing in the filesystem carries the intent behind them. Creating through a redirect is safe; destroying through one hands an attacker with merge rights an rmtree aimed wherever the symlink points. So the asymmetry stays, and uninstall now names the row, says a symlink redirects it, and prints an rm -rf that works — because rm follows the ancestor exactly as the install did (shipped in #1016). What is left is the other half: install should not write somewhere uninstall cannot reach. The options are not equivalent and the choice needs measuring rather than guessing — refuse the install outright (safe, breaks a layout that works today); record the resolved path in the lock so uninstall's walk agrees (keeps the layout, but the lock then carries a path the repo never spells, and a teammate whose clone resolves differently gets a row that matches nothing); or record both and match on either (most forgiving, widest attack surface to re-audit). Whichever lands, boost doctor should report a project whose lock rows no longer resolve to where the install put them, since today nothing notices until an uninstall leaves a directory behind. Related: project-uninstall-deletes-any-in-repo-directory-the-lock-names, which added the walk and the redirected reporting this card inherits.

Complexity M Impact Low Wow ★★ install gates on containment and writes through an in-repo symlinked dotdir; uninstall refuses to delete through one, so the copy is orphaned
ShippedCI · Bug

The floors job builds its own venv and never put setuptools in it, so main went red on the weekly cron

Write-up · floors-job-never-installed-setuptools.md

Complexity S Impact Med Wow ★★ the same missing dependency, in the second of six hand-built venvs
ShippedCI · Coverage

test_canary_deps.py needs PyYAML, which the required tests job does not install — so it only runs inside the mutation gate

Write-up · canary-deps-check-skips-in-the-required-job.md

Complexity S Impact Med Wow ★★ it skipped in all six jobs that run the suite, not the three this card first counted
In flightCI · Bug

Mutation shard weights balance perfectly and predict nothing, so a shard can time out and cancel a release

Observed, on the merge of #1015. mutation-shard (4) ran 75 minutes against the job's timeout-minutes: 75 and was cancelled. The aggregate mutation job then failed, the whole ci run concluded cancelled rather than failure, and publish.yml — which gates on workflow_run.conclusion == 'success' — skipped. A merge to main silently did not ship, which is the exact failure mode the long comment above ci.yml's concurrency: block was written to prevent by a different route. The packer is not at fault, and that is the finding. mutation_shards.py plan --shards 6 --explain reports every shard within 700 ms of the ideal 6,884,259 ms — a balance of 0.01%. The same run measured 39, 27, 38, 36, 76 and 65 minutes. Perfect balance against numbers that do not predict wall clock. The units are the tell. Total weight is 41,305,555 ms over six shards, so the plan predicts 114 minutes per shard while shards finish in 27–76. The weights are self-consistent ratios measured somewhere other than a CI runner, and ratios are all the packer needs — but it means nothing in the repo can answer "will a shard exceed the cap?". plan --explain prints the speedup cap and the largest unit; it never mentions timeout-minutes, and grep finds no comparison between the two anywhere in scripts/mutation_shards.py. Run-to-run variance eats the margin. The same tree, built twice: shard 4 took 66 min on 5aaf8bc4 (the PR) and 76 min on f196160d (its merge commit); shard 5 went 42 → 65. On 8c4a5094 shard 4 was 32. So the heaviest shard's observed range is 32–76 minutes for identical work, and the cap is 75. Related and probably the same cause: mutation-shard (4) on #1012 died at 15.1 minutes with exit 143 (SIGTERM), diagnosed then as runner eviction. Why the open weights-refresh PR does not fix it. #1014 re-measures and re-packs; under its weights the plan is again balanced to within ~400 ms, and predicts 121 min/shard. Re-measuring a quantity that was never in runner time produces a better-calibrated version of the same unanswerable question. Shape of the work. Three independent pieces, in increasing order of how much they fix: calibrate the weights against observed job duration (the API has it per shard, per run) so the plan is in minutes a human can compare to the cap; have plan fail, or at least warn, when a packed shard's predicted time is within some margin of timeout-minutes; and give the heaviest shard headroom — at eight shards the ideal drops by a quarter, and the speedup cap is 6.0x only because store.py is split per function already, so more shards is cheap. Separately, a cancelled ci on main should be loud: it currently looks identical to a success from the release path's point of view, because publish.yml only asks whether the conclusion was success. Fixed, and the calibration is measured. Fitted over the Actions job API on 2026-10-01: 169 successful mutation-shard jobs, of which 26 runs completed all six shards. Two numbers come out, and they answer different questions. Per run — the sum over its six shards, which is pack-invariant and so isolates runner speed from packing — observed minutes over committed weight-minutes is min 0.265, median 0.307, max 0.355: a spread of only 1.34x. Per shard against its own median the range is 1.10x (shard 3) to 1.91x (shard 2: median 38.0 min, worst 72.5). So the mean is not what fails. A single slow runner inside an otherwise ordinary run is, and a check scored on the median would have passed the pack that was cancelled — its median shard was 37.8 minutes against a 75-minute cap, half the ceiling. The 0.307 is not a fudge factor, it is parallelism. Weights are summed per-mutant durations — the work a shard holds laid end to end — and the runner executes it four-way parallel (max_children defaults to os.cpu_count(); ubuntu-latest is 4 vCPU). The median inverts to 3.26 effective workers of 4, so what is stored is 81.4% parallel efficiency and the worker count separately: a runner with more vCPUs then moves one constant and contention moves the other, where a single fitted number would hide which had happened. It reproduces the failure it was derived to predict. Six shards at these weights: 37.8 median minutes × 1.91 = a 72.3-minute tail against a real worst job of 72.5 — 96% of the cap. plan --explain --timeout-minutes 75 now prints that and exits 1. The matrix moved to eight, where the same arithmetic gives 28.4 × 1.91 = 54.2 min, 72% of the cap; the largest unit (4,063,161 ms) still fits inside an even share (5,543,280 ms), so the speedup cap is a full 8.00x and more shards cost nothing but runner slots. tests/unit/test_mutation_shard_count.py pins the shard count across ci.yml and mutation-weights-refresh.yml (timeout-minutes cannot be read through ${{ }}, so agreement is asserted rather than derived), and re-runs the headroom check on the committed pack every build — a pack that would be cancelled now fails in the test job in milliseconds. Not fixed here, and now its own card: a cancelled ci on main is still silent. ci-failure-alert gates on conclusion == 'failure', so the run that skipped the release notified nobody either — see cancelled-ci-on-main-is-silent-and-skips-the-release.

Complexity M Impact High Wow ★★★★ the pack is balanced to within 700ms of ideal and a shard still timed out at 75 min, cancelling a release
In flightCI · Bug

A cancelled ci on main skips the release and alerts nobody, because the alert asks only about failure

Two independent gates, both keyed on the wrong half of the same enum. publish.yml fires on workflow_run and ships only when conclusion == 'success'; ci-failure-alert opens the tracking issue only when conclusion == 'failure'. A ci run that concludes cancelled satisfies neither. It does not ship and it does not tell anyone — the one conclusion that falls through both. Observed, on the merge of #1015. mutation-shard (4) hit timeout-minutes: 75 and was cancelled, the aggregate mutation job failed, and the run concluded cancelled rather than failure. No release, no issue, no notification. It surfaced the same day, and only because somebody was reading per-shard job durations out of the Actions API for an unrelated reason — nothing in the repo would have raised it, and the next one will be found the same way or not at all. This is the exact blind spot ci-failure-alert's own header describes. That file opens by explaining that demo "failed six runs out of six on main, alerted nobody, and was found by a manual audit instead", and concludes that "any workflow that runs on main and nobody watches belongs here". The list was then enforced by tests/unit/test_failure_alerting_covers_unattended.py so a new workflow cannot quietly join the blind spot. The enforcement is over which workflows are watched, and the hole here is which conclusions are — ci is on the list and still said nothing. Why a timeout is not an exotic case. It is the designed behaviour of every timeout-minutes in the repo, and mutation-shard's is reached by an ordinary slow runner rather than by a bug: across 169 measured shard jobs the worst was 72.5 minutes against a 75-minute cap. A job can also be cancelled by the concurrency group or by a human pressing the button — and only the last of those is one anybody already knows about. A runner eviction is the neighbouring case, and it concludes differently. An earlier draft of this card listed eviction among the routes to cancelled; measured on 2026-10-02, it is not. mutation-shard (0) on main took The runner has received a shutdown signal and exit 143 at mutant 3095 of 28084, the job concluded failure, and the alerting fired correctly — issue #1024 opened and auto-closed when a rerun of the failed jobs went green. That is the point of widening on the green set rather than enumerating bad conclusions: the two most common ways a shard dies land on different sides of an == 'failure' test, and a gate that has to know which one it was is a gate that will be wrong again. Shape of the work. Widen the alert's condition from == 'failure' to the set of conclusions that mean "main is not green", which is every one except success, skipped and neutral — naming what is excluded rather than what is included, so the next conclusion GitHub adds defaults to loud. The issue body should say which conclusion it was, because cancelled and failure want different first moves. Then pin it: the sibling test already enforces the workflow list, so the conclusion set wants the same treatment rather than a comment. Worth checking at the same time whether publish.yml should distinguish "CI did not pass" from "CI did not finish" — today both are a silent no-op, and a release that was skipped because a runner was slow is recoverable by a rerun that nobody currently knows to start. Shipped. The opener now gates on the green set negated — !contains(fromJSON('["success", "skipped", "neutral"]'), conclusion) — so a conclusion GitHub adds later defaults to loud. skipped and neutral are in it deliberately: release skips on every run it does not publish from, so without that exclusion each non-green ci would open two issues. The closer keeps == 'success', because a cancelled run says nothing about whether the tracked failure is fixed and must not stand the issue down. The body now names the conclusion and, for ci, says no release was cut and that a rerun is what publishes it. publish.yml was left alone, deliberately. Its conclusion == 'success' && event == 'push' guard is the fork-PR boundary that stops an outsider cutting a real PyPI release; widening it to tell "did not pass" from "did not finish" would trade a silent no-op for a security hole. The recoverable case — a release skipped because a runner was slow — is recovered by the issue telling somebody to rerun, which is what the new body does. Found on the way, and fixed in the same change. An empty GitHub expression written inside a run: or script: body makes zizmor emit couldn't parse expression from six audits — template_injection, overprovisioned_secrets, unredacted_secrets, obfuscation, secrets_outside_env and unsound_ternary. A comment explaining why the script avoids interpolation was enough to cause it. Measured three ways: in a YAML # comment it is harmless (zizmor does not read those), in a script: body it costs six, and in a run: body it costs six even behind a shell #. An earlier draft of this section said that blinded the audits for the whole file. It does not, and the review that asked caught it. Planting a real finding — a head_commit.message interpolated into a run: — in two copies of the file, one clean and one carrying an empty expression, zizmor reported the template-injection in both. What is actually lost is the unparseable span itself, which no audit inspects, plus six warning lines above a run that still ends in "No findings to report". Worth preventing on those terms rather than the dramatic ones: a span that silently opts out of SAST is a bad place for a mistake to hide. A parametrised test now walks every workflow's parsed run/script bodies. One more hole the widening opened, and the review found it. head_branch == 'main' is not a provenance check. ci.yml runs on pull_request, so a fork PR opened from a branch named main produces a ci run whose head_branch is main — and cancel-in-progress concludes it cancelled on every superseded push. Under the old == 'failure' gate that was rare; under the new one it is routine PR iteration, and the issue would have claimed a release was skipped for a run that was never release-eligible. publish.yml, sbom.yml and mutation-weights-refresh.yml all carry the event+repository pair and this file was the only workflow_run consumer without it, so the fix is the house guard on both jobs — the closer needed it just as much, since a green fork PR could otherwise close a tracker for a failure still live on main. It is event != 'pull_request' rather than == 'push' because three watched workflows are themselves workflow_run-triggered.

Complexity S Impact High Wow ★★★★ the alerting that exists to make a red main impossible to miss asks only about 'failure', and the run that skipped a release was 'cancelled'