boost-skill-cli 1.2.33__tar.gz → 1.2.34__tar.gz

{boost_skill_cli-1.2.33 → boost_skill_cli-1.2.34}/PKG-INFO

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

{boost_skill_cli-1.2.33 → boost_skill_cli-1.2.34}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.2.33'
-__version_tuple__ = version_tuple = (1, 2, 33)
+__version__ = version = '1.2.34'
+__version_tuple__ = version_tuple = (1, 2, 34)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.33 → boost_skill_cli-1.2.34}/boost_cli/commands/configuration.py

@@ -570,6 +570,26 @@ def _write_onboard_file(dest: Path, content: str, force: bool) -> bool:
     return True
 
 
+def _telemetry_created(dest: Path) -> str:
+    """The existing file's ``created`` timestamp, or now for a fresh write.
+
+    ``_write_onboard_file`` treats a byte-identical re-run as a no-op — but
+    stamping a fresh ``util.now_iso()`` into telemetry.json on every
+    invocation meant the comparison could only match by wall-clock luck (two
+    invocations landing in the same second), defeating the "re-running
+    onboard regenerates the workflow byte-for-byte" guarantee documented
+    above for the one file whose content is otherwise fully deterministic.
+    """
+    try:
+        data = json.loads(dest.read_text(encoding="utf-8"))
+        created = data.get("created")
+        if isinstance(created, str) and created:
+            return created
+    except (OSError, UnicodeDecodeError, json.JSONDecodeError):
+        pass
+    return util.now_iso()
+
+
 def cmd_onboard(argv) -> int:
     """boost onboard [--repo DIR] [--pr] [--dry-run] [--force]"""
     p = cliparse.parser(
@@ -593,7 +613,7 @@ def cmd_onboard(argv) -> int:
     telemetry = json.dumps({
         "enabled": True,
         "share_pulse": True,
-        "created": util.now_iso(),
+        "created": _telemetry_created(repo / _TELEMETRY_REL),
         "by": util.user(),
     }, indent=2) + "\n"
     files = [(_TELEMETRY_REL, telemetry), (_WORKFLOW_REL, _WORKFLOW_YML)]

{boost_skill_cli-1.2.33 → boost_skill_cli-1.2.34}/boost_cli/commands/quality.py

@@ -94,7 +94,12 @@ def _resolve_as_far_as_it_exists(path: Path) -> Path:
     while cur != cur.parent and not cur.exists():
         tail.append(cur.name)
         cur = cur.parent
-    with suppress(OSError):
+    # RuntimeError is not redundant with OSError here: Python 3.12's
+    # `Path.resolve()` raises RuntimeError("Symlink loop from ...") for a
+    # cycle even in non-strict mode, and RuntimeError is NOT an OSError
+    # subclass — 3.13+ raises OSError for the same input. See
+    # store.resolves_into_store for the identical split, caught the same way.
+    with suppress(OSError, RuntimeError):
         cur = cur.resolve()
     return cur.joinpath(*reversed(tail))
 
@@ -907,10 +912,18 @@ def cmd_heal(argv):
 
     plan = store.sync_plan()
     if dry:
+        # `ours` above is exactly what a real run unlinks before computing
+        # this plan, so `sync_plan`'s stale-link sweep never sees those paths
+        # on a real run — only here, where nothing was unlinked yet. Skip
+        # them so a preview doesn't report the same path twice under two
+        # different actions.
+        already_reported = {str(link) for link in ours}
         for name, agent in plan["missing_links"]:
             out.info("would link %s → %s" % (name, agent))
             actions.append("link %s" % name)
         for p in plan["stale_links"]:
+            if p in already_reported:
+                continue
             out.info("would remove stale link %s" % _tilde(p))
             actions.append("stale %s" % p)
         for name in plan["missing_store"]:
@@ -988,7 +1001,12 @@ def cmd_conflict(argv):
     ap.add_argument("--json", action="store_true")
     args = ap.parse_args(argv)
 
-    installed = _iter_installed()
+    # Quarantine removes a skill's active links/materialization on purpose
+    # (see _drift_status_materialized's docstring) — a quarantined skill has
+    # nothing live to be contradicted by, so it is excluded from both sides
+    # of conflict detection rather than surfacing a conflict finding no
+    # `boost quarantine` can ever clear.
+    installed = [(n, e) for n, e in _iter_installed() if not e.get("quarantined")]
     rules: list[tuple[str, str, str, set]] = []   # skill, line, polarity, stems
     declared: list[tuple[str, str]] = []           # skill, conflicting skill
     installed_names = {n for n, _e in installed}

{boost_skill_cli-1.2.33 → boost_skill_cli-1.2.34}/boost_cli/commands/safety.py

@@ -268,7 +268,13 @@ def _trust_audit(as_json: bool) -> int:
     """`boost audit --skills` — one trust-health answer for the installed set."""
     installed = dict(_iter_installed())
     peers: dict = {}
-    for name, peer in trustaudit.conflict_pairs(list(installed),
+    # Quarantine removes a skill's active links on purpose — pairing it as a
+    # conflict source or target would report a finding `boost quarantine`
+    # (its own documented remedy) can never clear. Non-quarantined skills are
+    # still checked against a quarantined peer's *declared* conflicts via
+    # `_installed_conflicts`, so only the pairing set is trimmed here.
+    active_names = [n for n, lk in installed.items() if not lk.get("quarantined")]
+    for name, peer in trustaudit.conflict_pairs(active_names,
                                                 _installed_conflicts(installed)):
         peers.setdefault(name, []).append(peer)
 

{boost_skill_cli-1.2.33 → boost_skill_cli-1.2.34}/boost_cli/core/store.py

@@ -80,7 +80,16 @@ def installed() -> dict:
 def source_dir_for(entry: dict) -> Path:
     """Absolute path of a catalog entry's skill dir inside its tap clone.
 
-    Materializes the directory first. Taps check out Markdown only, so a skill
+    Clones the tap first if it is only *registered* and not yet cloned — the
+    state `boost catalog --import` deliberately leaves a tap in (a bundle
+    ships the catalogue, not the repo, precisely so the receiver can search
+    before paying for any clone). `catalog --import`'s own hint promises
+    "`boost install` clones just the one registry it needs"; without this, a
+    tap that was imported rather than tapped raised "source vanished from
+    tap" — a message that implies the source *used to* exist, when really it
+    was never fetched.
+
+    Materializes the directory next. Taps check out Markdown only, so a skill
     that ships `scripts/` or `assets/` has them in the index and not on disk;
     `_copy_skill` is a copytree, and handed a partial directory it copies what
     is there and reports success. Every consumer of a tap's real files — both
@@ -88,6 +97,8 @@ def source_dir_for(entry: dict) -> Path:
     the one place that has to get it right.
     """
     tap = registry.get(entry["tap"])
+    if not tap.is_cloned:
+        gitutil.clone_shallow(tap.url, tap.path)
     src = tap.path if entry["rel_dir"] == "." else tap.path / entry["rel_dir"]
     gitutil.materialize(tap.path, entry["rel_dir"])
     if not (src / "SKILL.md").exists():

{boost_skill_cli-1.2.33 → boost_skill_cli-1.2.34}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.2.33 → boost_skill_cli-1.2.34}/boost_skill_cli.egg-info/SOURCES.txt

@@ -227,6 +227,7 @@ docs/roadmap/items/ci-job-timeout-minutes.md
 docs/roadmap/items/ci-summary-step-fails-itself.md
 docs/roadmap/items/ci-time-is-now-runner-queueing.md
 docs/roadmap/items/clean-env-install-smoke-pip-and-pipx.md
+docs/roadmap/items/cli-command-audit.md
 docs/roadmap/items/cli-output-ignored-the-terminal.md
 docs/roadmap/items/code-scanning-rule-can-be-restored.md
 docs/roadmap/items/codeql-job-rename-stranded-merge-protection.md
@@ -391,6 +392,7 @@ docs/roadmap/items/reconcile-the-theme-drift.md
 docs/roadmap/items/refresh-the-marketing-surface.md
 docs/roadmap/items/rel-time-tests-race-the-wall-clock.md
 docs/roadmap/items/release-verifies-the-wrong-commit.md
+docs/roadmap/items/reproducible-release-artifacts.md
 docs/roadmap/items/required-checks-can-declare-a-check-that-deadlocks-prs.md
 docs/roadmap/items/required-checks-config-drift.md
 docs/roadmap/items/resolve-vendored-duplicate-copies.md
@@ -508,6 +510,7 @@ scripts/build_scale_corpus.py
 scripts/check_anchors.py
 scripts/check_dco.py
 scripts/check_licenses.py
+scripts/check_reproducible.py
 scripts/check_required_checks.py
 scripts/ensure_eval_corpus.sh
 scripts/eval_corpus.py
@@ -522,6 +525,7 @@ scripts/measure_registry.py
 scripts/mutation_gate.py
 scripts/mutation_shards.py
 scripts/mutation_weights.json
+scripts/normalize_sdist.py
 scripts/page_budget.py
 scripts/perf_gate.py
 scripts/post_deploy_smoke.py
@@ -632,6 +636,7 @@ tests/unit/test_chat.py
 tests/unit/test_check_anchors.py
 tests/unit/test_check_dco.py
 tests/unit/test_check_licenses.py
+tests/unit/test_check_reproducible.py
 tests/unit/test_claude_settings.py
 tests/unit/test_clean_internal_cache.py
 tests/unit/test_cliparse.py
@@ -710,6 +715,7 @@ tests/unit/test_mutation_shards.py
 tests/unit/test_mutation_subfile_shards.py
 tests/unit/test_mutmut_source_paths.py
 tests/unit/test_nethttp.py
+tests/unit/test_normalize_sdist.py
 tests/unit/test_output.py
 tests/unit/test_page_budget.py
 tests/unit/test_paths.py

{boost_skill_cli-1.2.33 → boost_skill_cli-1.2.34}/docs/openssf-badge.md

@@ -213,8 +213,8 @@ of the security-design document for the full account.
 
 ## Gold
 
-Gold is **23** criteria on top of silver. Sixteen are Met, two are N/A and
-five are Unmet. Three of the five are about how many people work on boost
+Gold is **23** criteria on top of silver. Seventeen are Met, two are N/A and
+four are Unmet. Three of the four are about how many people work on boost
 rather than about the code, so no pull request can close them.
 
 That count is worth a note, because an earlier version of this section said 21
@@ -225,10 +225,9 @@ like a plausible total, so nothing flagged it; the gap only appeared on the
 submission form, where 23 rows were waiting. A count that looks reasonable is
 not a checked count.
 
-Read this section as the honest ceiling. Eighteen of twenty-three is where
-boost stops on its own: of the five that remain, two are engineering (a
-reproducible sdist, a host that sets response headers) and three are a
-recruiting problem.
+Read this section as the honest ceiling. Nineteen of twenty-three is where
+boost stops on its own: of the four that remain, one is engineering (a host
+that sets response headers) and three are a recruiting problem.
 
 ### Prerequisites and project oversight
 
@@ -265,7 +264,7 @@ recruiting problem.
 
 | Criterion | Cat. | Answer | Evidence |
 |---|---|---|---|
-| `build_reproducible` | MUST | **Unmet** | Measured, not assumed: with `SOURCE_DATE_EPOCH` set, two builds of one commit produce a **bit-identical wheel** and a **differing sdist**. `setuptools` writes each tar member's real mtime plus the builder's `uid`/`gid`/user name into the sdist, so 54 members differ between builds two seconds apart. Two things are missing — the release workflow installs its build tooling unpinned, and the sdist's timestamps and ownership need normalising. The full measurement and the commands to reproduce it are in [docs/verifying-releases.md](https://github.com/jonnyeclectic/boost/blob/main/docs/verifying-releases.md#can-you-rebuild-it-yourself-partly--the-measurement). N/A would be wrong: boost ships wheels. |
+| `build_reproducible` | MUST | **Met** | Measured, not assumed: `scripts/check_reproducible.py` builds the project twice with `SOURCE_DATE_EPOCH` pinned to the same value both times and diffs the results — both the **wheel and the sdist are now bit-identical**. They were not: `setuptools` writes each sdist tar member's real mtime plus the builder's `uid`/`gid`/user name with no override, so 54 members differed between builds two seconds apart ([pypa/setuptools#2133](https://github.com/pypa/setuptools/issues/2133), open since 2020). `scripts/normalize_sdist.py` now clamps that in `publish.yml`, between the build and `twine check`, and the release toolchain that produces the artifacts is hash-pinned (`requirements/release-tools.txt`) with `pyproject.toml`'s `[build-system].requires` exact-pinned rather than left as a floor. The full measurement and the commands to reproduce it are in [docs/verifying-releases.md](https://github.com/jonnyeclectic/boost/blob/main/docs/verifying-releases.md#can-you-rebuild-it-yourself-yes--the-measurement). N/A would be wrong: boost ships wheels. |
 
 ### Test invocation and coverage
 
@@ -303,8 +302,6 @@ recruiting problem.
 - `bus_factor`, `contributors_unassociated`, `two_person_review` — **a second
   person**, sustained. Not a document, not a check, and not something to
   simulate with a second account.
-- `build_reproducible` — pin the release build toolchain, then normalise the
-  sdist tarball.
 - `hardened_site` — host the documentation somewhere that lets you set
   response headers.
 

boost_skill_cli-1.2.34/docs/roadmap/items/cli-command-audit.md

@@ -0,0 +1,72 @@
+---
+id: cli-command-audit
+board: code
+section: shipped
+status: shipped
+category: Quality · CLI
+complexity: M
+impact: Med
+wow: 3
+note: audited all 80 COMMANDS entries against a disposable HOME; 4 real defects fixed with tests
+order: 128
+owner: loop/verify
+pr:
+title: All 80 <code>boost</code> commands audited against a disposable HOME &mdash; four defects fixed
+---
+Every command in <code>boost_cli/cli.py</code>'s <code>COMMANDS</code> table (not memory of
+what the CLI does) was exercised for real: <code>--help</code> against its actual
+<code>argparse</code> definition, the happy path against its one-line summary and
+<code>docs/commands.html</code>, exit codes on success/error/empty-store/nonexistent-name,
+and &mdash; for anything that mutates state &mdash; the real lock file, symlinks and cache on
+disk, not just stdout. Four parallel audits split the ~80 commands by
+<code>COMMANDS</code>'s own groups (pkg+find, info+tap+ai, quality/safety, cfg+team) so
+every command got adversarial testing (tampered store content, corrupted lock JSON,
+deleted store dirs, real signed/tampered minisign manifests) rather than a clean-state
+smoke pass.
+
+The known failure modes this codebase has shipped before were hunted deliberately: a
+command reporting success without doing the thing, a raw read that misses a tap's sparse
+checkout, <code>Path.resolve(strict=True)</code>'s <code>RuntimeError</code>/<code>OSError</code>
+split between Python 3.12 and 3.13+, and a dry-run that silently no-ops or over-reports.
+<code>boost trust add</code> &mdash; the one command with a documented history of exactly the
+first failure mode (a merged autofix once deleted its fingerprint line) &mdash; was
+re-verified against real Ed25519 signatures and tampering and held up.
+
+Four real defects, each fixed with a failing-then-passing test. <code>boost conflict</code>
+and <code>boost audit --skills</code> kept reporting a MED conflict finding against a skill
+after it was quarantined &mdash; quarantine's own documented purpose ("isolate a problematic
+skill") gave no relief from the one command whose entire job is to report that condition;
+both now exclude quarantined skills from conflict pairing. <code>boost catalog
+--import</code> tells the receiver "<code>boost install</code> clones just the one registry
+it needs", but <code>install</code> performed no lazy clone &mdash; the one end-to-end path the
+command advertises (import &rarr; search &rarr; install) failed with a misleading "source
+vanished from tap" error; <code>store.source_dir_for</code> now clones a
+registered-but-uncloned tap on demand, the single choke point every consumer of tap content
+already goes through. <code>boost onboard</code>'s own docstring promises a byte-for-byte
+no-op on an unchanged re-run, but <code>.boost/telemetry.json</code> stamped a fresh
+timestamp on every invocation, so the comparison could only pass by wall-clock luck &mdash; a
+scripted <code>boost onboard --pr</code> on an already-onboarded repo would open a PR
+containing only a timestamp bump, forever; it now preserves the existing file's
+<code>created</code> field. <code>boost heal --dry-run</code> double-reported the same
+broken symlink under two different messages ("would remove broken link" and "would remove
+stale link") because the real run unlinks before computing <code>sync_plan()</code> while
+dry-run never unlinks anything &mdash; a preview overstating what running <code>heal</code> for
+real actually does.
+
+A fifth, latent-only finding was fixed alongside them: <code>quality.py</code>'s
+<code>_resolve_as_far_as_it_exists</code> caught only <code>OSError</code> around a
+non-strict <code>Path.resolve()</code>, the same symlink-loop gap
+<code>store.resolves_into_store</code> had already been fixed for. Verified empirically
+(not just read) on both interpreters: <code>Path.resolve(strict=False)</code> on a
+symlink-loop path returns silently on 3.14 and raises <code>RuntimeError</code> on 3.12 &mdash;
+confirmed with a live symlink cycle on both, and the full affected test suite reran green
+on a real Python 3.12 venv.
+
+Two findings were investigated and deliberately left alone after checking the existing
+test suite rather than trusting the audit's framing: <code>boost drift</code> always
+exiting 0 is pinned as intentional by <code>tests/functional/test_cli_quality.py</code>'s
+own comment ("rc stays 0: drift only reports"), and <code>boost who</code>'s aggregate view
+counting every journal subject (not just install/edit/evolve/distill/tag actions) toward
+"skill expertise" is pinned the same way by an existing test asserting a tap name in the
+skills set. Flipping either would contradict a deliberately written existing test, not fix
+an oversight.

boost_skill_cli-1.2.34/docs/roadmap/items/reproducible-release-artifacts.md

@@ -0,0 +1,62 @@
+---
+id: reproducible-release-artifacts
+board: code
+section: pipeline
+status: shipped
+category: Security · Reproducibility
+complexity: M
+impact: Med
+wow: 3
+note: wheel + sdist now bit-identical; setuptools#2133 has no native fix
+order: 128
+owner: loop/repro
+pr:
+title: Reproducible release builds — the sdist half nobody's setuptools does for you
+---
+<code>build_reproducible</code> was Unmet on measurement: with <code>SOURCE_DATE_EPOCH</code> set,
+two builds of the same commit produced a <b>bit-identical wheel</b> and a <b>differing
+sdist</b>. <code>setuptools</code> writes each tar member's real build-time mtime, and the
+builder's <code>uid</code>/<code>gid</code>/user name, into the sdist with no environment
+variable to override either &mdash; 54 members differed between builds two seconds apart on the
+same machine, and a build on another machine would have differed in the ownership fields too.
+
+<b>The upstream knob doesn't exist.</b> <a href="https://github.com/pypa/setuptools/issues/2133">
+pypa/setuptools#2133</a> has asked for <code>SOURCE_DATE_EPOCH</code> support in sdist since 2020;
+it is still open, with no fix in the version this project pins. The one PyPI package that already
+patches it, <code>setuptools-reproducible</code>, does so by replacing
+<code>build-backend</code> entirely &mdash; and its dependency closure could not be hash-pinned
+the way the rest of boost's toolchain is, because <code>[build-system].requires</code> is a bare
+PEP&nbsp;508 requirement string with no hash field. So the fix is a small, stdlib-only
+post-processing step instead: <code>scripts/normalize_sdist.py</code> clamps every member's
+mtime, zeroes uid/gid, blanks uname/gname, and resets the gzip container's own header
+timestamp, run in <code>publish.yml</code> between <code>python -m build</code> and
+<code>twine check</code> &mdash; so nothing is ever attested un-normalized.
+
+<b>The wheel had a real gap too, not just the sdist.</b> <code>publish.yml</code> never set
+<code>SOURCE_DATE_EPOCH</code> at all before this &mdash; the "bit-identical wheel" measurement
+only held in a controlled local test where the variable was exported by hand. The actual release
+pipeline was building an unreproducible wheel as well, and nothing had noticed.
+
+<b>The toolchain that determines the bytes is now pinned twice.</b>
+<code>requirements/release-tools.txt</code> hash-pins the outer <code>build</code>/
+<code>twine</code> install (<code>publish.yml</code> used to run
+<code>pip install build twine</code> unpinned, so last month's toolchain was not recoverable
+from the repository). But <code>python -m build</code> resolves <code>setuptools</code> and
+<code>setuptools-scm</code> fresh into an isolated build environment regardless of what the
+outer install has &mdash; that's the part that actually produces the artifact bytes &mdash; so
+<code>pyproject.toml</code>'s <code>[build-system].requires</code> is now exact-pinned
+(<code>setuptools==83.0.0</code>, <code>setuptools-scm==10.2.1</code>) rather than left as
+<code>&gt;=64</code>/<code>&gt;=8</code>. No hash field exists at that layer; exact-pinning is
+the strongest promise PEP 508 allows there.
+
+<b>Falsifiable, not asserted.</b> <code>scripts/check_reproducible.py</code> builds the project
+twice with the same <code>SOURCE_DATE_EPOCH</code>, runs the same sdist fix the release pipeline
+runs, and diffs the results by sha256 &mdash; <code>--skip-normalize</code> reruns without the fix
+to show the gap it closes. Degrades to exit&nbsp;2 ("could not check") rather than exit&nbsp;0
+when <code>build</code> isn't installed, matching how boost's own CI controls have failed
+silently before: a check that can't run must never read as a pass.
+
+<code>docs/openssf-badge.md</code>'s <code>build_reproducible</code> row now reads <b>Met</b>;
+<code>docs/verifying-releases.md</code> carries the re-run measurement and how to rebuild from a
+git tag (the sdist itself carries no <code>.git</code> history, so <code>SOURCE_DATE_EPOCH</code>
+has to come from a checkout, not the tarball).

{boost_skill_cli-1.2.33 → boost_skill_cli-1.2.34}/docs/roadmap.html

@@ -130,10 +130,10 @@
   <section class="block reveal">
     <div class="stats">
       <!-- ROADMAP:stats -->
-      <div class="stat"><b>16</b><span>Shipped</span></div>
+      <div class="stat"><b>17</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>7</b><span>Planned</span></div>
-      <div class="stat"><b>276</b><span>Loop finds</span></div>
+      <div class="stat"><b>278</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -448,6 +448,75 @@ message, so routing it through the helper would change user-facing errors.</p></
           <span class="m">helper dedup + double-parse removed</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="cli-command-audit">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Quality · CLI</span></div>
+        <h3>All 80 <code>boost</code> commands audited against a disposable HOME &mdash; four defects fixed</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p>Every command in <code>boost_cli/cli.py</code>'s <code>COMMANDS</code> table (not memory of
+what the CLI does) was exercised for real: <code>--help</code> against its actual
+<code>argparse</code> definition, the happy path against its one-line summary and
+<code>docs/commands.html</code>, exit codes on success/error/empty-store/nonexistent-name,
+and &mdash; for anything that mutates state &mdash; the real lock file, symlinks and cache on
+disk, not just stdout. Four parallel audits split the ~80 commands by
+<code>COMMANDS</code>'s own groups (pkg+find, info+tap+ai, quality/safety, cfg+team) so
+every command got adversarial testing (tampered store content, corrupted lock JSON,
+deleted store dirs, real signed/tampered minisign manifests) rather than a clean-state
+smoke pass.
+
+The known failure modes this codebase has shipped before were hunted deliberately: a
+command reporting success without doing the thing, a raw read that misses a tap's sparse
+checkout, <code>Path.resolve(strict=True)</code>'s <code>RuntimeError</code>/<code>OSError</code>
+split between Python 3.12 and 3.13+, and a dry-run that silently no-ops or over-reports.
+<code>boost trust add</code> &mdash; the one command with a documented history of exactly the
+first failure mode (a merged autofix once deleted its fingerprint line) &mdash; was
+re-verified against real Ed25519 signatures and tampering and held up.
+
+Four real defects, each fixed with a failing-then-passing test. <code>boost conflict</code>
+and <code>boost audit --skills</code> kept reporting a MED conflict finding against a skill
+after it was quarantined &mdash; quarantine's own documented purpose ("isolate a problematic
+skill") gave no relief from the one command whose entire job is to report that condition;
+both now exclude quarantined skills from conflict pairing. <code>boost catalog
+--import</code> tells the receiver "<code>boost install</code> clones just the one registry
+it needs", but <code>install</code> performed no lazy clone &mdash; the one end-to-end path the
+command advertises (import &rarr; search &rarr; install) failed with a misleading "source
+vanished from tap" error; <code>store.source_dir_for</code> now clones a
+registered-but-uncloned tap on demand, the single choke point every consumer of tap content
+already goes through. <code>boost onboard</code>'s own docstring promises a byte-for-byte
+no-op on an unchanged re-run, but <code>.boost/telemetry.json</code> stamped a fresh
+timestamp on every invocation, so the comparison could only pass by wall-clock luck &mdash; a
+scripted <code>boost onboard --pr</code> on an already-onboarded repo would open a PR
+containing only a timestamp bump, forever; it now preserves the existing file's
+<code>created</code> field. <code>boost heal --dry-run</code> double-reported the same
+broken symlink under two different messages ("would remove broken link" and "would remove
+stale link") because the real run unlinks before computing <code>sync_plan()</code> while
+dry-run never unlinks anything &mdash; a preview overstating what running <code>heal</code> for
+real actually does.
+
+A fifth, latent-only finding was fixed alongside them: <code>quality.py</code>'s
+<code>_resolve_as_far_as_it_exists</code> caught only <code>OSError</code> around a
+non-strict <code>Path.resolve()</code>, the same symlink-loop gap
+<code>store.resolves_into_store</code> had already been fixed for. Verified empirically
+(not just read) on both interpreters: <code>Path.resolve(strict=False)</code> on a
+symlink-loop path returns silently on 3.14 and raises <code>RuntimeError</code> on 3.12 &mdash;
+confirmed with a live symlink cycle on both, and the full affected test suite reran green
+on a real Python 3.12 venv.
+
+Two findings were investigated and deliberately left alone after checking the existing
+test suite rather than trusting the audit's framing: <code>boost drift</code> always
+exiting 0 is pinned as intentional by <code>tests/functional/test_cli_quality.py</code>'s
+own comment ("rc stays 0: drift only reports"), and <code>boost who</code>'s aggregate view
+counting every journal subject (not just install/edit/evolve/distill/tag actions) toward
+"skill expertise" is pinned the same way by an existing test asserting a tap name in the
+skills set. Flipping either would contradict a deliberately written existing test, not fix
+an oversight.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">audited all 80 COMMANDS entries against a disposable HOME; 4 real defects fixed with tests</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>
@@ -7389,6 +7458,65 @@ an index-format bump plus a regenerated <code>tests/eval/baseline.json</code>.</
           <span class="m">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</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="reproducible-release-artifacts">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Security · Reproducibility</span></div>
+        <h3>Reproducible release builds — the sdist half nobody's setuptools does for you</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><code>build_reproducible</code> was Unmet on measurement: with <code>SOURCE_DATE_EPOCH</code> set,
+two builds of the same commit produced a <b>bit-identical wheel</b> and a <b>differing
+sdist</b>. <code>setuptools</code> writes each tar member's real build-time mtime, and the
+builder's <code>uid</code>/<code>gid</code>/user name, into the sdist with no environment
+variable to override either &mdash; 54 members differed between builds two seconds apart on the
+same machine, and a build on another machine would have differed in the ownership fields too.
+
+<b>The upstream knob doesn't exist.</b> <a href="https://github.com/pypa/setuptools/issues/2133">
+pypa/setuptools#2133</a> has asked for <code>SOURCE_DATE_EPOCH</code> support in sdist since 2020;
+it is still open, with no fix in the version this project pins. The one PyPI package that already
+patches it, <code>setuptools-reproducible</code>, does so by replacing
+<code>build-backend</code> entirely &mdash; and its dependency closure could not be hash-pinned
+the way the rest of boost's toolchain is, because <code>[build-system].requires</code> is a bare
+PEP&nbsp;508 requirement string with no hash field. So the fix is a small, stdlib-only
+post-processing step instead: <code>scripts/normalize_sdist.py</code> clamps every member's
+mtime, zeroes uid/gid, blanks uname/gname, and resets the gzip container's own header
+timestamp, run in <code>publish.yml</code> between <code>python -m build</code> and
+<code>twine check</code> &mdash; so nothing is ever attested un-normalized.
+
+<b>The wheel had a real gap too, not just the sdist.</b> <code>publish.yml</code> never set
+<code>SOURCE_DATE_EPOCH</code> at all before this &mdash; the "bit-identical wheel" measurement
+only held in a controlled local test where the variable was exported by hand. The actual release
+pipeline was building an unreproducible wheel as well, and nothing had noticed.
+
+<b>The toolchain that determines the bytes is now pinned twice.</b>
+<code>requirements/release-tools.txt</code> hash-pins the outer <code>build</code>/
+<code>twine</code> install (<code>publish.yml</code> used to run
+<code>pip install build twine</code> unpinned, so last month's toolchain was not recoverable
+from the repository). But <code>python -m build</code> resolves <code>setuptools</code> and
+<code>setuptools-scm</code> fresh into an isolated build environment regardless of what the
+outer install has &mdash; that's the part that actually produces the artifact bytes &mdash; so
+<code>pyproject.toml</code>'s <code>[build-system].requires</code> is now exact-pinned
+(<code>setuptools==83.0.0</code>, <code>setuptools-scm==10.2.1</code>) rather than left as
+<code>&gt;=64</code>/<code>&gt;=8</code>. No hash field exists at that layer; exact-pinning is
+the strongest promise PEP 508 allows there.
+
+<b>Falsifiable, not asserted.</b> <code>scripts/check_reproducible.py</code> builds the project
+twice with the same <code>SOURCE_DATE_EPOCH</code>, runs the same sdist fix the release pipeline
+runs, and diffs the results by sha256 &mdash; <code>--skip-normalize</code> reruns without the fix
+to show the gap it closes. Degrades to exit&nbsp;2 ("could not check") rather than exit&nbsp;0
+when <code>build</code> isn't installed, matching how boost's own CI controls have failed
+silently before: a check that can't run must never read as a pass.
+
+<code>docs/openssf-badge.md</code>'s <code>build_reproducible</code> row now reads <b>Met</b>;
+<code>docs/verifying-releases.md</code> carries the re-run measurement and how to rebuild from a
+git tag (the sdist itself carries no <code>.git</code> history, so <code>SOURCE_DATE_EPOCH</code>
+has to come from a checkout, not the tarball).</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">wheel + sdist now bit-identical; setuptools#2133 has no native fix</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>