boost-skill-cli 1.0.275__tar.gz → 1.0.277__tar.gz

{boost_skill_cli-1.0.275 → boost_skill_cli-1.0.277}/Makefile

@@ -61,7 +61,8 @@ lint:
 	$(VENV)/bin/interrogate boost_cli/core
 	$(VENV)/bin/refurb boost_cli
 	$(VENV)/bin/codespell boost_cli docs README.md
-	@command -v actionlint >/dev/null 2>&1 && actionlint || echo "actionlint not on PATH — skipping (CI enforces it)"
+	@if command -v actionlint >/dev/null 2>&1; then actionlint; \
+	else echo "actionlint not on PATH — skipping (CI enforces it)"; fi
 	$(PY) scripts/build_registries.py --check
 	$(PY) scripts/build_roadmap.py --check
 	$(PY) scripts/build_command_reference.py --check
@@ -140,7 +141,8 @@ bench:
 # part of `make check`; degrades cleanly (prints a skip message, exits 0) when
 # hyperfine isn't installed (`brew install hyperfine`).
 bench-cli:
-	@command -v hyperfine >/dev/null 2>&1 && bash scripts/bench_cli.sh || echo "hyperfine not on PATH — install via 'brew install hyperfine', skipping"
+	@if command -v hyperfine >/dev/null 2>&1; then bash scripts/bench_cli.sh; \
+	else echo "hyperfine not on PATH — install via 'brew install hyperfine', skipping"; fi
 
 # Opt-in coverage-guided fuzzing of the hand-rolled parsers (atheris/libFuzzer).
 # Not part of `make check` — a fuzzer is a search, not a pass/fail gate; the
@@ -164,7 +166,8 @@ fuzz:
 BOOST_SITE ?= https://jonnyeclectic.github.io/boost/
 post-deploy:
 	$(PY) scripts/post_deploy_smoke.py --base-url "$(BOOST_SITE)" -v
-	@command -v node >/dev/null 2>&1 && BOOST_SITE="$(BOOST_SITE)" node tests/visual/console_check.mjs || echo "node not on PATH — skipping the console check (CI runs it)"
+	@if command -v node >/dev/null 2>&1; then BOOST_SITE="$(BOOST_SITE)" node tests/visual/console_check.mjs; \
+	else echo "node not on PATH — skipping the console check (CI runs it)"; fi
 
 # regenerate generated artifacts from their source (registries + roadmap boards)
 generate:

{boost_skill_cli-1.0.275/boost_skill_cli.egg-info → boost_skill_cli-1.0.277}/PKG-INFO

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

{boost_skill_cli-1.0.275 → boost_skill_cli-1.0.277}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.0.275'
-__version_tuple__ = version_tuple = (1, 0, 275)
+__version__ = version = '1.0.277'
+__version_tuple__ = version_tuple = (1, 0, 277)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.275 → boost_skill_cli-1.0.277/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.275 → boost_skill_cli-1.0.277}/boost_skill_cli.egg-info/SOURCES.txt

@@ -181,6 +181,7 @@ docs/roadmap/items/coverage-dashboard-codecov-free-for-oss.md
 docs/roadmap/items/coverage-guided-fuzzing-atheris-oss-fuzz.md
 docs/roadmap/items/crash-listing-branch-untested.md
 docs/roadmap/items/crash-recorder-error-paths-core-logs-py.md
+docs/roadmap/items/demo-cannot-open-its-own-pr.md
 docs/roadmap/items/demo-gif-workflow-has-never-succeeded.md
 docs/roadmap/items/dense-search-fallback-and-stale-tap-pruning.md
 docs/roadmap/items/dependabot-missing-pip-ecosystem.md
@@ -225,6 +226,7 @@ docs/roadmap/items/log-timestamps-mislabeled-utc.md
 docs/roadmap/items/lowest-version-resolution-uv-resolution-lowest-d.md
 docs/roadmap/items/main-has-no-branch-protection.md
 docs/roadmap/items/main-ruleset-ref-pattern-has-literal-quotes.md
+docs/roadmap/items/make-lint-masks-actionlint-failures.md
 docs/roadmap/items/make-the-roadmaps-discoverable.md
 docs/roadmap/items/markdown-consistency-markdownlint-cli2.md
 docs/roadmap/items/markdownlint-lints-the-fuzz-corpus.md
@@ -236,6 +238,7 @@ docs/roadmap/items/mcp-search-before-reinventing.md
 docs/roadmap/items/mcp-startup-self-harden-fork-safety.md
 docs/roadmap/items/memoize-config-load-in-process.md
 docs/roadmap/items/merge-queue-would-deadlock-most-required-checks.md
+docs/roadmap/items/merged-loop-branches-are-never-pruned.md
 docs/roadmap/items/modernization-smells-refurb-pyupgrade.md
 docs/roadmap/items/mutation-gate-was-the-whole-critical-path.md
 docs/roadmap/items/mutation-hardening-core-frontmatter-py.md
@@ -270,6 +273,7 @@ docs/roadmap/items/ranx-significance-monitor.md
 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/required-checks-can-declare-a-check-that-deadlocks-prs.md
 docs/roadmap/items/required-checks-config-drift.md
 docs/roadmap/items/retrieval-quality-eval-harness.md

boost_skill_cli-1.0.277/docs/roadmap/items/demo-cannot-open-its-own-pr.md

@@ -0,0 +1,56 @@
+---
+id: demo-cannot-open-its-own-pr
+board: code
+section: pipeline
+status: planned
+category: CI reporting
+complexity: S
+impact: Med
+wow: 4
+note: a repo setting blocks it — no edit to demo.yml can fix this one
+order: 65
+owner:
+pr:
+title: <code>demo.yml</code> still fails on every push &mdash; and the fix is not in the workflow
+---
+<code>demo-gif-workflow-has-never-succeeded</code> (shipped, PR&nbsp;294) fixed the recorder:
+<code>charmbracelet/vhs-action</code>'s broken ffmpeg installer was replaced with apt plus
+ttyd/vhs pinned by release-asset id. That worked. The recording step now succeeds on both event
+paths. <b>The workflow still fails on every push to <code>main</code></b> &mdash; observed
+2026-07-28 at 20:56, 20:04 and 09:27, and it is the only failing workflow in the last 60 runs.
+
+The failure moved one step later, to <code>open a PR if the recording changed</code>. The run
+annotation gives it verbatim:
+
+<code>GitHub Actions is not permitted to create or approve pull requests.</code>
+
+<b>Nothing in <code>demo.yml</code> is wrong, so nothing in <code>demo.yml</code> will fix it.</b>
+The job already declares <code>contents: write</code> and <code>pull-requests: write</code>,
+which is exactly what <code>peter-evans/create-pull-request</code> documents as required. The
+workflow uses no secrets. <code>persist-credentials: false</code> on the checkout is correct and
+is the repo-wide convention across all 31 checkout steps &mdash; the action supplies its own git
+auth and explicitly unsets any persisted credential. Every one of those is a plausible-looking
+false lead. The actual blocker is a <b>repository setting</b>: Actions&nbsp;&rarr;&nbsp;General
+&nbsp;&rarr;&nbsp;Workflow permissions &nbsp;&rarr;&nbsp; "Allow GitHub Actions to create and
+approve pull requests", which the API reports as
+<code>can_approve_pull_request_reviews: false</code>. This is the same shape as
+<code>sbom.yml</code>: a workflow that is correct in the file and inert in reality.
+
+Deciding it is a real decision, not a formality. Turning that toggle on grants <em>every</em>
+workflow in the repo the ability to open pull requests, which is a genuine widening of what a
+compromised action can do. The alternative is to accept that this step cannot work and change
+what the push path does &mdash; upload the GIF as an artifact on both paths, as the pull-request
+path already does, and drop the PR-opening step.
+
+<b>A second, independent defect in the same file.</b> Its concurrency group is
+<code>group: demo</code>, not ref-scoped. Every other per-ref workflow scopes it &mdash;
+<code>sonarcloud-${{ github.ref }}</code>, <code>fuzz-${{ github.ref }}</code>,
+<code>eval-stats-${{ github.ref }}</code>, <code>eval-explain-${{ github.ref }}</code>; only the
+deliberately-singleton <code>release</code> and <code>post-deploy</code> are global. With
+<code>cancel-in-progress: true</code>, a pull-request run and a <code>main</code> run therefore
+cancel each other, which is where demo's <code>cancelled</code> runs come from. Fix is
+<code>group: demo-${{ github.ref }}</code> regardless of what is decided about the toggle.
+
+Worth reconciling while here: the tree disagrees with itself on the history.
+<code>demo-gif-workflow-has-never-succeeded</code> says "3 runs, 3 failures", while
+<code>demo.yml</code> and <code>ci-failure-issue.yml</code> both say six of six.

{boost_skill_cli-1.0.275 → boost_skill_cli-1.0.277}/docs/roadmap/items/dependabot-regeneration-drops-platform-pins.md

@@ -44,3 +44,11 @@ with <code>lock_toolchain.py</code> instead. Whatever is chosen, it needs a guar
 <i>loses</i> a platform-markered pin should fail its own gate rather than fail three Windows jobs
 two steps later, because the current failure names the install step and never mentions the missing
 package. Related: [[dependabot-root-pip-entry-duplicates-requirements]].
+<b>Progress:</b> <code>lock_toolchain.py</code> now takes <code>-P/--upgrade-package</code>, so a
+Dependabot bump can be <i>reproduced</i> rather than merged — take the version it proposes,
+re-resolve that one package universally, and every other pin (markers included) stays as committed.
+Both open bumps were landed that way: <code>hypothesis</code> 6.161.6 to 6.163.0 and
+<code>twine</code> 6.2.0 to 7.0.0, four changed lines across five locks, with
+<code>colorama</code> and <code>pywin32-ctypes</code> intact. What remains is the config half —
+stopping Dependabot raising these at all — which is deliberately still open because its effect is
+only observable on the next scheduled run.

boost_skill_cli-1.0.277/docs/roadmap/items/make-lint-masks-actionlint-failures.md

@@ -0,0 +1,61 @@
+---
+id: make-lint-masks-actionlint-failures
+board: code
+section: dx
+status: shipped
+category: Testing · Bug
+complexity: S
+impact: Med
+wow: 4
+note: fixed — a failing actionlint now fails make, in all three targets
+order: 60
+owner:
+pr:
+title: <code>make lint</code> reports success when <code>actionlint</code> fails &mdash; and says it wasn't installed
+---
+<code>Makefile:64</code> guards the workflow linter like this:
+
+<code>@command -v actionlint &gt;/dev/null 2&gt;&amp;1 &amp;&amp; actionlint || echo "actionlint not on PATH &mdash; skipping (CI enforces it)"</code>
+
+Because <code>||</code> binds to the whole <code>&amp;&amp;</code> chain, the fallback fires in
+<b>both</b> failure modes &mdash; actionlint absent, <em>and</em> actionlint present and reporting
+findings. Reproduced with a stub that exits 1:
+
+<code>actionlint: FAKE ERROR</code><br>
+<code>actionlint not on PATH &mdash; skipping (CI enforces it)</code><br>
+<code>make exit=0</code>
+
+So a real workflow-lint failure is swallowed, and the message asserts something false &mdash; that
+the tool is not installed, when it is installed and just failed. <b><code>make lint</code> and
+therefore <code>make check</code> can never fail on actionlint.</b> CLAUDE.md calls
+<code>make check</code> "the one gate that matters" and tells every agent to run it before calling
+a change done; for this tool it returns green unconditionally, and the developer who reads the
+output is told the opposite of what happened.
+
+The local-versus-CI gap is wider than this one line. CI's required <code>lint</code> job runs
+three workflow/security tools that <code>make lint</code> has no equivalent for at all:
+<b>actionlint</b> (present but unfailable), <b>zizmor</b> and <b>gitleaks</b> (absent from the
+Makefile entirely). No CI job invokes <code>make lint</code>, so the two lists are hand-maintained
+duplicates with nothing checking they agree &mdash; which is how they drifted.
+
+Minimal fix is to stop discarding the exit status:
+
+<code>@if command -v actionlint &gt;/dev/null 2&gt;&amp;1; then actionlint; else echo "actionlint not on PATH &mdash; skipping (CI enforces it)"; fi</code>
+
+The stricter option is to install actionlint in <code>make venv</code> and let absence itself
+fail, so <code>make check</code> cannot report success while skipping a required gate. The same
+masking idiom appears at <code>Makefile:143</code> (hyperfine) and <code>Makefile:167</code>
+(node); neither is reached by <code>check</code>, so they are cosmetic by comparison, but they are
+the same bug. Incidental drift found alongside: <code>CLAUDE.md</code> describes the lint recipe
+as "18 commands" and it is 19.
+
+<b>Shipped.</b> All three occurrences of the idiom were rewritten to an
+<code>if/then/else</code> so the tool's exit status is no longer discarded &mdash;
+<code>Makefile:64</code> (actionlint, inside <code>lint</code> and therefore inside
+<code>check</code>), plus <code>bench-cli</code> and <code>post-deploy</code>, which had the same
+bug without being reachable from the gate. Verified against the patched recipe itself, in all
+three states: a <b>failing</b> actionlint now fails <code>make</code> (exit 2) instead of printing
+"not on PATH" and returning 0; a <b>passing</b> one still exits 0; an <b>absent</b> one still exits
+0 with the skip message intact. The wider local-versus-CI gap this card also names &mdash;
+<code>zizmor</code> and <code>gitleaks</code> run only in CI and are absent from the Makefile
+&mdash; is untouched and still open.

boost_skill_cli-1.0.277/docs/roadmap/items/merged-loop-branches-are-never-pruned.md

@@ -0,0 +1,47 @@
+---
+id: merged-loop-branches-are-never-pruned
+board: code
+section: pipeline
+status: planned
+category: Hygiene · DX
+complexity: S
+impact: Low
+wow: 2
+note: 68 of 70 loop/* branches have a merged PR; one setting fixes it
+order: 66
+owner:
+pr:
+title: 68 of the repo's 77 branches are merged <code>loop/*</code> branches nobody deletes
+---
+The repository carries <b>77 branches, 70 of them <code>loop/*</code></b>. Classifying each by the
+state of its pull request: <b>68 have a merged PR</b> and are safe to delete, <b>1</b> has an open
+PR (<code>loop/dependabot-findings</code>), and 1 has no PR on record. The default branch list is
+almost entirely finished work.
+
+<b>The obvious measurement is wrong here, which is worth recording.</b> Testing "is it merged?"
+with <code>compare(main...branch).ahead_by == 0</code> reports <b>0 of 70</b> as merged &mdash;
+because this repo squash-merges, and a squash leaves the branch's original commits outside
+<code>main</code>'s history forever. Every merged branch looks permanently ahead. The state has to
+come from the pull request, not from commit reachability.
+
+The cause is a single repository setting: <code>delete_branch_on_merge</code> is <b>false</b>, so
+nothing removes a head branch when its PR merges. No workflow prunes them either &mdash; none of
+the 25 workflow files triggers on <code>create</code>/<code>delete</code> or touches
+<code>loop/*</code>, and no <code>scripts/</code> entry or Makefile target does branch cleanup.
+The one branch-deletion automation in the tree is <code>demo.yml</code>'s
+<code>delete-branch: true</code>, which is <code>create-pull-request</code> tidying its own
+<code>bot/demo-gif</code> branch and has nothing to do with <code>loop/*</code>. No documentation
+asks anyone to clean up either: <code>CONTRIBUTING.md</code>, <code>CLAUDE.md</code> and
+<code>.claude/commands/roadmap-loop.md</code> all describe branching and squash-merging, and none
+of the three mentions deleting the branch afterwards.
+
+<b>Not a claim that branches are never deleted.</b> The item files name <b>144 distinct</b>
+<code>owner: loop/&lt;topic&gt;</code> values against 70 surviving branches, so roughly 98 have
+gone at some point &mdash; by hand, or by topic reuse. The accurate statement is narrower:
+nothing in the repo <em>causes</em> cleanup, so merged branches accumulate until someone does it
+manually.
+
+Low impact and near-zero risk to fix &mdash; flip <code>delete_branch_on_merge</code> to true and
+the backlog can be pruned by listing merged PR head refs. The reason it is worth doing at all is
+that CLAUDE.md tells every agent to run <code>git worktree list</code> and inspect branch state
+before touching a tree, and 68 stale entries make that check noisier for every concurrent loop.

boost_skill_cli-1.0.277/docs/roadmap/items/release-verifies-the-wrong-commit.md

@@ -0,0 +1,57 @@
+---
+id: release-verifies-the-wrong-commit
+board: code
+section: pipeline
+status: planned
+category: Release safety
+complexity: S
+impact: High
+wow: 4
+note: 2 of 18 required contexts are re-checked against the sha actually shipped
+order: 64
+owner:
+pr:
+title: The release verifies one commit and ships another
+---
+<code>publish.yml</code> fires on <code>workflow_run</code> when <code>ci</code> completes, gates
+on that run's <code>conclusion == 'success'</code> (plus <code>event == 'push'</code> and
+<code>head_repository == this repo</code>), and then checks out <code>ref: main</code>. Those are
+not the same commit. <b>Observed 2026-07-28:</b> <code>ci</code> for <code>ecfe38bc</code>
+completed at 20:19:05Z; the release run was created at 20:19:07Z; it tagged and shipped
+<code>c1727bac</code> as <b>v1.0.271</b> &mdash; while <code>c1727bac</code>'s own
+<code>ci</code>, started 20:18:40Z, was still <code>in_progress</code>. One commit's green
+verdict authorised a different commit's release.
+
+<b>Most of this is already mitigated, and the card should not be read as "untested code ships".</b>
+A strict "require branches to be up to date" policy means the shipped commit was green as a pull
+request before it could merge, so its <em>tree</em> was gated. And
+<code>release_preflight.py</code> is already pointed at the right commit &mdash;
+<code>--sha "$(git rev-parse HEAD)"</code>, with an explicit comment that this is "not the trigger
+sha". It polls each required workflow for that exact sha and fails closed on red, cancelled,
+skipped, never-ran or still-running-at-deadline. The machinery is correct.
+
+<b>Its coverage is the gap.</b> <code>.github/required-checks.txt</code> lists <b>18</b> required
+contexts. <code>publish.yml</code> passes preflight exactly two of them &mdash;
+<code>--require pip-audit.yml</code> and <code>--require package-metadata.yml</code>. The other
+<b>16 are never re-checked against the commit being shipped</b>, including all 14 that come from
+<code>ci.yml</code> and <code>codeql-analyze</code>. The clearest evidence this is an oversight
+rather than a decision is in-tree: <code>release_preflight.py</code>'s own docstring says it waits
+for <em>every</em> required workflow for the exact commit being released, and the caller hands it
+two.
+
+<b>A required context that can never report on <code>main</code> at all.</b> While checking the
+other 16: <code>osv-scanner.yml</code> declares only <code>pull_request</code> and
+<code>merge_group</code> triggers &mdash; no <code>push</code>. So <code>scan-pr / osv-scan</code>
+is green as a PR gate and produces <em>nothing</em> for any commit on <code>main</code>, race or
+no race. Adding it to preflight without first giving that workflow a
+<code>push: branches: [main]</code> trigger would fail the release closed every time.
+
+The fix is not to change the checkout ref. Pinning to
+<code>github.event.workflow_run.head_sha</code> would build the older commit while release-drafter
+still tags the default branch's head &mdash; artifact and tag would disagree. The lower-risk
+change is to widen preflight's <code>--require</code> set to the contexts that actually run on
+<code>main</code>, and optionally fail the job when <code>git rev-parse HEAD</code> differs from
+the triggering run's <code>head_sha</code>. This is the third defect found in the same few lines
+&mdash; see <code>publish-trigger-was-reachable-from-a-fork</code> (who can fire it) and
+<code>publish-gate-ignores-pip-audit-and-metadata</code> (which gates are consulted); this one is
+<em>which commit</em> they were consulted about.

{boost_skill_cli-1.0.275 → boost_skill_cli-1.0.277}/docs/roadmap/items/zizmor-pin-is-a-yanked-release.md

@@ -2,12 +2,12 @@
 id: zizmor-pin-is-a-yanked-release
 board: code
 section: pipeline
-status: planned
+status: shipped
 category: Security · CI/CD
 complexity: S
 impact: Med
 wow: 4
-note: the only yanked release of 66 — and the required lint job pins exactly it
+note: already fixed by a4450f76 twelve hours before this card was filed
 order: 63
 owner:
 pr:
@@ -34,3 +34,19 @@ And sweep the other exact pins for yanks: nothing currently checks for this. <co
 catches CVEs in the resolved dependency closure, but a yanked <em>pinned tool</em> is neither a
 CVE in the closure nor a manifest diff, so <code>osv-scanner</code> does not see it either. This
 was found by accident, while installing zizmor locally to verify an unrelated change.
+
+<b>Already shipped when this card was written &mdash; the card was filed stale, and that is the
+more useful finding.</b> Commit <code>a4450f76</code>, "ci(security): zizmor 1.27.0 is yanked
+&mdash; take 1.28.0", landed at <b>08:07Z</b>; this card was filed at <b>20:18Z</b>, twelve hours
+later, against a base that already carried <code>1.28.0</code>. The yank was observed correctly
+against a tree extracted earlier in the day and then never re-checked against the branch point.
+<code>ci.yml</code> now runs <code>pipx run zizmor==1.28.0</code>.
+
+Two things worth keeping from it. The predicted risk did not materialise: <code>zizmor
+1.28.0</code> runs clean over all 25 workflows (exit 0, "no findings to report"), and the
+line-anchored ignores in <code>.github/zizmor.yml</code> &mdash; including
+<code>sbom.yml:29</code> &mdash; all still resolve, so the bump needed no config change. And the
+gap the card names remains real and unclosed: <b>nothing checks whether an exact pin has been
+yanked</b>. <code>pip-audit</code> scans the resolved dependency closure and
+<code>osv-scanner</code> diffs the manifest; a yanked <em>pinned tool</em> is neither, so this was
+caught by a human noticing a pip warning, twice, by luck.