boost-skill-cli 1.0.285__tar.gz → 1.0.287__tar.gz

{boost_skill_cli-1.0.285 → boost_skill_cli-1.0.287}/.gitignore

@@ -235,6 +235,12 @@ mutants/
 # dir (see evals/run_evals.py), so only the per-run scores land here; the
 # committed evals/baseline.json is what regressions are measured against.
 evals/results.json
-tests/visual/node_modules/
 tests/visual/out/
-tests/visual/package-lock.json
+
+# Installed npm trees, never the lockfiles that describe them. Both
+# package-lock.json files ARE committed on purpose: package.json pins only the
+# direct dependencies, so without the lock every transitive package resolves
+# fresh at install time. The lock carries an integrity hash for all 181 (root)
+# and 81 (tests/visual) packages, which is what makes `npm ci` reproducible and
+# what OpenSSF Scorecard's Pinned-Dependencies check asks for.
+node_modules/

{boost_skill_cli-1.0.285 → boost_skill_cli-1.0.287}/MANIFEST.in

@@ -9,4 +9,7 @@ prune .idea
 prune .claude
 prune .github
 exclude .coverage
+# The npm lint/test toolchain (stylelint, eslint, puppeteer-core, axe-core). CI
+# only; nothing in the shipped runtime touches node.
+exclude package.json package-lock.json
 global-exclude __pycache__ *.pyc *.pyo .DS_Store

{boost_skill_cli-1.0.285 → boost_skill_cli-1.0.287}/PKG-INFO

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

{boost_skill_cli-1.0.285 → boost_skill_cli-1.0.287}/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.285'
-__version_tuple__ = version_tuple = (1, 0, 285)
+__version__ = version = '1.0.287'
+__version_tuple__ = version_tuple = (1, 0, 287)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.285 → boost_skill_cli-1.0.287}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.0.285 → boost_skill_cli-1.0.287}/boost_skill_cli.egg-info/SOURCES.txt

@@ -529,5 +529,6 @@ tests/unit/test_workflow_timeouts.py
 tests/unit/test_workflows.py
 tests/visual/a11y_check.mjs
 tests/visual/console_check.mjs
+tests/visual/package-lock.json
 tests/visual/package.json
 tests/visual/visual_check.mjs

{boost_skill_cli-1.0.285 → boost_skill_cli-1.0.287}/docs/roadmap/items/bring-commands-under-mutation-testing.md

@@ -2,14 +2,14 @@
 id: bring-commands-under-mutation-testing
 board: code
 section: planned
-status: planned
+status: declined
 category: Testing · Gap
 complexity: XL
 impact: High
 wow: 3
-note: 
+note: declined 2026-07-29 — 71.9% measured, and the run cannot complete at all
 order: 2
-owner:
+owner: loop/roadmap-decisions
 pr:
 title: Bring <code>commands/</code> under mutation testing
 ---
@@ -47,3 +47,28 @@ The ~8,100-line command layer has <strong>zero</strong> mutation coverage: mutmu
            One prerequisite is already fixed: <code>--no-mcp</code> leaked through
            <code>os.environ</code> and made the suite order-dependent, which mutmut exposes
            because it runs whichever test subset covers each mutant.
+           <b>Declined 2026-07-29.</b> Not "hard" — <em>blocked</em>, and the block is
+           upstream. mutmut <b>3.6.0 is still the latest release</b>, and
+           <code>src/mutmut/__main__.py:120</code> still reads
+           <code>source_paths = [p.resolve(strict=True) for p in Config.get().source_paths]</code>
+           — unconditionally, before the <code>max_stack_depth</code> guard — on paths that
+           <code>configuration.py:102</code> builds as plain relative <code>Path</code>s. Every
+           <code>chdir</code>-ing functional test therefore kills the run, and the functional
+           suite is precisely what takes <code>commands/</code> 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: <b>71.9%</b> against an <b>80%</b> blocking floor, with
+           survivors spread evenly rather than pooled in one testable gap, at
+           <b>2.5–4.5 hours</b> 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 <code>main</code> red.
+           <b>The lead, if anyone reopens this:</b> the crash is a relative-path bug, and
+           <code>source_paths</code> is not required to be relative — an absolute path survives
+           <code>resolve(strict=True)</code> from any working directory. Whether the rest of
+           mutmut's <code>mutants/</code> 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.
+           <b>What is not lost by declining.</b> The architecture already puts behaviour in
+           <code>core/</code> — which <em>is</em> mutation-gated at 80% — and keeps
+           <code>commands/</code> 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.

boost_skill_cli-1.0.287/docs/roadmap/items/roadmap-html-goes-stale-on-every-rebase.md

@@ -0,0 +1,69 @@
+---
+id: roadmap-html-goes-stale-on-every-rebase
+board: code
+section: dx
+status: shipped
+category: DX
+complexity: M
+impact: Med
+wow: 3
+note: two of the three fixes measured dead; one survivor, and it needs a Pages change
+order: 59
+owner: loop/roadmap-stale-diagnosis
+pr: 307
+title: <code>roadmap.html</code> goes stale on every rebase, so a card and a merge race redden the whole matrix
+---
+The data-driven roadmap solved the conflict problem for <em>item files</em>: two loops adding
+two cards touch two different files and merge cleanly. But <code>docs/roadmap.html</code> is
+still a single committed artifact generated from <b>all</b> of them, and
+<code>update-branch</code> merges it textually.
+
+So whenever another roadmap-carrying PR merges first, the rebase brings in the new item
+<code>.md</code> cleanly and leaves the generated HTML behind. The board no longer matches
+<code>docs/roadmap/items/</code>, and both <code>build_roadmap.py --check</code> (in lint) and
+<code>tests/unit/test_roadmap_fresh.py</code> fail — on <b>every</b> test leg, for a PR that
+changed no Python at all. It reads as a catastrophic failure and is really a stale generated
+file.
+
+This is not hypothetical: one PR hit it twice in a single afternoon, each time needing a
+manual regenerate-and-push, and the cost scales with the number of concurrent loops — the
+exact workload the item-file split was introduced to support. With <code>strict: true</code>
+every merge rebases every open PR, so any PR carrying a card is guaranteed to hit it if it
+sits behind one other roadmap PR.
+
+Options, roughly in order of appeal: have CI regenerate and push the board on the PR branch
+(fixes it silently, needs a bot token and care with the required checks); a custom merge
+driver for the generated boards that reruns the generator instead of merging text; or stop
+committing the HTML and build the site at deploy time (biggest change, and it removes the
+artifact from review). At minimum, make the <code>--check</code> failure message say
+"regenerate after rebasing" so the cause is obvious from the log.
+<b>Update 2026-07-29 — the three options were measured, and two of them do not work.</b>
+First, the repro, because both halves matter and they fail differently. Two branches each
+adding one item to the same section: the <em>cards</em> hard-conflict (same insertion point),
+while the <em>counters</em> merge silently to a wrong value — base <code>N</code>, both sides
+<code>N+1</code>, git keeps <code>N+1</code>, the truth is <code>N+2</code>. So a clean merge
+still fails <code>--check</code>. That is why one root cause reddens ~6 checks.
+<b>"Custom merge driver" is dead.</b> GitHub's server-side merge ignores
+<code>.gitattributes</code> merge strategies — not just custom drivers, the built-in ones too.
+Measured on this repo with four throwaway branches and
+<code>POST /repos/&hellip;/merges</code>: <b>409 without</b> the attribute and <b>409 with</b>
+<code>docs/roadmap.html merge=union</code>, while the identical merge <em>locally</em> succeeds
+cleanly and one <code>build_roadmap.py</code> run makes it correct. The attribute would help
+only whoever resolves the conflict by hand, which is the case that already works.
+<b>"CI regenerates and pushes on the PR branch" is dead too</b>, at least with
+<code>GITHUB_TOKEN</code>: a push made with it deliberately does not trigger workflows, so the
+fix-up commit would land a new head with <b>no check runs at all</b> and the required contexts
+would never report — the PR blocks forever instead of for one cycle. It needs a PAT or a GitHub
+App, i.e. a new long-lived secret with write access to every branch.
+<b>The survivor is the third one</b> — stop committing the generated HTML and build the site at
+deploy time — and it has a prerequisite that is a repository <em>setting</em>, not a commit:
+Pages is currently <code>build_type: legacy</code> serving <code>main:/</code>, so it publishes
+whatever bytes are committed. The artifact cannot leave git until Pages builds it, which means
+either an Actions-built site or a generated <code>gh-pages</code> branch (the pattern
+<code>ci.yml</code> already uses for the coverage badge, and one that does <b>not</b> re-trigger
+<code>ci</code> → <code>publish</code>, so it cuts no extra release). Everything that reads
+<code>docs/*.html</code> off disk — <code>html-validate</code>, <code>visual</code>,
+<code>lighthouse</code>, <code>check_anchors</code>, <code>a11y_check</code>,
+<code>test_docsite_chrome</code> — would need a generate step first, and
+<code>test_roadmap_fresh</code> loses its purpose. That is the whole cost, and it is bounded;
+what it is not is a change one loop should make to a live public site on its own initiative.

boost_skill_cli-1.0.287/docs/roadmap/items/scorecard-findings-triage.md

@@ -0,0 +1,74 @@
+---
+id: scorecard-findings-triage
+board: code
+section: pipeline
+status: shipped
+category: Supply chain
+complexity: M
+impact: Med
+wow: 2
+note: 7 open · 3 now hash-pinned, 3 decided, 1 clears itself
+order: 13
+owner: loop/scorecard-pinned-deps
+pr:
+title: OpenSSF Scorecard's findings, triaged into three piles
+---
+Scorecard files into the same code-scanning inbox as CodeQL, so its findings read like
+code defects and get ignored alongside the false positives. They are not defects — they
+are <b>posture metrics</b>, and they must not be dismissed as "false positive" the way the
+<code>serve.py</code> traversal alerts legitimately were, because that misrepresents the
+repo's security posture. Triaged 2026-07-25, re-triaged 2026-07-29 against the 7 still open.
+<b>Fixed</b> — <code>TokenPermissions</code> #26/#27/#28: <code>ci</code>,
+<code>codeql</code> and <code>adapter-conformance</code> had no top-level
+<code>permissions:</code> block at all, scoring 0. Added <code>contents: read</code> as the
+least-privilege default.
+<b>Intentional, leave</b> — <code>TokenPermissions</code> #39/#37/#25/#24:
+<code>publish.yml</code> needs <code>contents: write</code> to create the release and tag,
+<code>osv-scanner</code> needs <code>security-events: write</code> to upload SARIF, and
+<code>ci.yml</code>'s <code>tests</code> job needs <code>contents: write</code> for the
+coverage-badge push. "Fixing" these breaks the release pipeline. They should be
+<b>dismissed as used-in-tests/acceptable-risk with a reason</b>, not left open to rot the list.
+<b>Correction — <code>PinnedDependencies</code> was NOT "not code-fixable".</b> The first
+pass filed #40/#41/#48 under <i>"npx and pip invocations inside steps, not actions, so
+SHA-pinning does not apply"</i>. That reads the check as being about action SHAs, and it
+is not: for npm the remediation is a <b>committed lockfile</b>, and all three hits were
+<code>npm install</code> steps. <code>tests/visual/package.json</code> pinned its two direct
+deps exactly — and <code>.gitignore</code> then <i>excluded the lockfile</i>, so 79
+transitive packages resolved fresh on every run. <code>theme-lint</code> was worse:
+<code>npm install stylelint@16 eslint@9</code> re-resolved the whole linter every run, so
+the linter CI executed was never the linter anyone reviewed. Both trees are now hash-pinned
+(181 + 81 packages, integrity on every one) and installed with <code>npm ci</code>;
+<code>dependabot.yml</code> gains both npm directories, because a pin with no update path is
+only half the job.
+<b>What the pin immediately exposed.</b> Committing the lock made
+<code>osv-scanner</code> able to see the transitive tree for the first time, and it failed
+the branch at once on <b>CVE-2026-14257</b> (<code>brace-expansion</code>, CVSS 7.5,
+unbounded expansion → OOM). Pre-existing, not introduced: the old floating
+<code>npm install eslint@9</code> resolved the same package, invisibly. The advisory's range
+is <i>all versions below 5.0.8</i>, so the 1.x maintenance line has no fix — and the obvious
+patch, an <code>overrides</code> entry forcing <code>brace-expansion@^5</code>, <b>breaks
+eslint</b>: v5 exports <code>{ expand }</code> where <code>minimatch@3</code> requires a
+callable default, so <code>eslint "style/**/*.{js,mjs}"</code> dies with
+<i>"expand is not a function"</i> while plain <code>eslint style/</code> still passes — a
+green-looking linter with a broken glob path. The real fix is upstream:
+<code>eslint@10</code> depends on <code>minimatch@^10.2.5</code>, which requires the patched
+<code>brace-expansion@^5.0.8</code>. Bumped 9.39.5 → 10.8.0; all 262 packages across both
+locks now return zero OSV advisories.
+<b>Open by decision, correctly</b> — <code>BranchProtectionID</code> #33 (4/10) and
+<code>CodeReviewID</code> #34 (0/26 approved changesets) are two readings of one deliberate
+choice recorded in <a href="#main-has-no-branch-protection">its own card</a>: require status
+checks, do <i>not</i> require reviews, because the working model is parallel
+<code>loop/*</code> branches that self-merge and there is no second reviewer. Every warning
+Scorecard prints under #33 — stale-review dismissal, required approvers, CODEOWNERS review,
+last-push approval — follows from that one choice. They stay open because the score is
+<b>accurate</b>: this repo really does merge without human review. Dismissing them would be
+the lie.
+<b>Clears itself</b> — <code>MaintainedID</code> #35 is <i>"repository was created within the
+last 90 days"</i>. Created 2026-07-17, so it resolves on its own around 2026-10-15. Nothing
+to do but not dismiss it.
+<b>Needs a human, not a commit</b> — <code>CIIBestPracticesID</code> #36 is the one
+remaining actionable finding, and it cannot be fixed from a branch: it asks whether the
+project is registered for an OpenSSF Best Practices badge, which means creating a project
+entry at <code>bestpractices.dev</code> under a real account and answering its criteria. The
+prerequisites are already in place (LICENSE, SECURITY.md, CONTRIBUTING.md,
+CODE_OF_CONDUCT.md, a published CI gate); only the registration is missing.

{boost_skill_cli-1.0.285 → boost_skill_cli-1.0.287}/docs/roadmap.html

@@ -47,6 +47,7 @@
   .pill.inflight  { color: var(--cyan); }
   .pill.next      { color: var(--yellow); }
   .pill.planned   { color: var(--violet); }
+  .pill.declined  { color: var(--text-3); }  /* investigated and rejected — not a stage */
 
   .cat { margin-left: auto; font-family: var(--mono); font-size: 11px; color: var(--text-3); letter-spacing: .06em; text-transform: uppercase; }
 
@@ -478,7 +479,7 @@ message, so routing it through the helper would change user-facing errors.</p>
       </article>
 
       <article class="cap rcard" id="bring-commands-under-mutation-testing">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Testing · Gap</span></div>
+        <div class="head"><span class="pill declined">Declined</span><span class="cat">Testing · Gap</span></div>
         <h3>Bring <code>commands/</code> under mutation testing</h3>
         <p>The ~8,100-line command layer has <strong>zero</strong> mutation coverage: mutmut is
            scoped to <code>core/</code> only. A blocking 80% floor was attempted and the
@@ -513,11 +514,37 @@ message, so routing it through the helper would change user-facing errors.</p>
            errors), and a sibling <code>pytest_add_cli_args</code> takes extra pytest flags.
            One prerequisite is already fixed: <code>--no-mcp</code> leaked through
            <code>os.environ</code> and made the suite order-dependent, which mutmut exposes
-           because it runs whichever test subset covers each mutant.</p>
+           because it runs whichever test subset covers each mutant.
+           <b>Declined 2026-07-29.</b> Not "hard" — <em>blocked</em>, and the block is
+           upstream. mutmut <b>3.6.0 is still the latest release</b>, and
+           <code>src/mutmut/__main__.py:120</code> still reads
+           <code>source_paths = [p.resolve(strict=True) for p in Config.get().source_paths]</code>
+           — unconditionally, before the <code>max_stack_depth</code> guard — on paths that
+           <code>configuration.py:102</code> builds as plain relative <code>Path</code>s. Every
+           <code>chdir</code>-ing functional test therefore kills the run, and the functional
+           suite is precisely what takes <code>commands/</code> 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: <b>71.9%</b> against an <b>80%</b> blocking floor, with
+           survivors spread evenly rather than pooled in one testable gap, at
+           <b>2.5–4.5 hours</b> 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 <code>main</code> red.
+           <b>The lead, if anyone reopens this:</b> the crash is a relative-path bug, and
+           <code>source_paths</code> is not required to be relative — an absolute path survives
+           <code>resolve(strict=True)</code> from any working directory. Whether the rest of
+           mutmut's <code>mutants/</code> 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.
+           <b>What is not lost by declining.</b> The architecture already puts behaviour in
+           <code>core/</code> — which <em>is</em> mutation-gated at 80% — and keeps
+           <code>commands/</code> 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.</p>
         <div class="meta">
           <span class="m">Complexity <b>XL</b></span>
           <span class="m hi">Impact <b>High</b></span>
           <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">declined 2026-07-29 — 71.9% measured, and the run cannot complete at all</span>
         </div>
       </article>
 
@@ -2015,13 +2042,13 @@ path is never used — that fixes the behaviour without satisfying Dependabot's
       </article>
 
       <article class="cap rcard" id="scorecard-findings-triage">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Supply chain</span></div>
-        <h3>OpenSSF Scorecard's 15 findings, triaged into three piles</h3>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Supply chain</span></div>
+        <h3>OpenSSF Scorecard's findings, triaged into three piles</h3>
         <p>Scorecard files into the same code-scanning inbox as CodeQL, so its findings read like
 code defects and get ignored alongside the false positives. They are not defects — they
 are <b>posture metrics</b>, and they must not be dismissed as "false positive" the way the
 <code>serve.py</code> traversal alerts legitimately were, because that misrepresents the
-repo's security posture. Triaged 2026-07-25:
+repo's security posture. Triaged 2026-07-25, re-triaged 2026-07-29 against the 7 still open.
 <b>Fixed</b> — <code>TokenPermissions</code> #26/#27/#28: <code>ci</code>,
 <code>codeql</code> and <code>adapter-conformance</code> had no top-level
 <code>permissions:</code> block at all, scoring 0. Added <code>contents: read</code> as the
@@ -2032,19 +2059,55 @@ least-privilege default.
 <code>ci.yml</code>'s <code>tests</code> job needs <code>contents: write</code> for the
 coverage-badge push. "Fixing" these breaks the release pipeline. They should be
 <b>dismissed as used-in-tests/acceptable-risk with a reason</b>, not left open to rot the list.
-<b>Not code-fixable</b> — <code>MaintainedID</code> is repository age; <code>CodeReviewID</code>
-counts approved changesets and is structurally 0 while loops self-merge;
-<code>CIIBestPracticesID</code> is an opt-in badge programme; the four
-<code>PinnedDependencies</code> hits are <code>npx</code> and <code>pip</code> invocations
-inside steps, not actions, so SHA-pinning does not apply to them as written.
-<code>BranchProtectionID</code> is tracked separately in
-<a href="#main-has-no-branch-protection">its own card</a> — it is a workflow decision, not a
-config oversight.</p>
+<b>Correction — <code>PinnedDependencies</code> was NOT "not code-fixable".</b> The first
+pass filed #40/#41/#48 under <i>"npx and pip invocations inside steps, not actions, so
+SHA-pinning does not apply"</i>. That reads the check as being about action SHAs, and it
+is not: for npm the remediation is a <b>committed lockfile</b>, and all three hits were
+<code>npm install</code> steps. <code>tests/visual/package.json</code> pinned its two direct
+deps exactly — and <code>.gitignore</code> then <i>excluded the lockfile</i>, so 79
+transitive packages resolved fresh on every run. <code>theme-lint</code> was worse:
+<code>npm install stylelint@16 eslint@9</code> re-resolved the whole linter every run, so
+the linter CI executed was never the linter anyone reviewed. Both trees are now hash-pinned
+(181 + 81 packages, integrity on every one) and installed with <code>npm ci</code>;
+<code>dependabot.yml</code> gains both npm directories, because a pin with no update path is
+only half the job.
+<b>What the pin immediately exposed.</b> Committing the lock made
+<code>osv-scanner</code> able to see the transitive tree for the first time, and it failed
+the branch at once on <b>CVE-2026-14257</b> (<code>brace-expansion</code>, CVSS 7.5,
+unbounded expansion → OOM). Pre-existing, not introduced: the old floating
+<code>npm install eslint@9</code> resolved the same package, invisibly. The advisory's range
+is <i>all versions below 5.0.8</i>, so the 1.x maintenance line has no fix — and the obvious
+patch, an <code>overrides</code> entry forcing <code>brace-expansion@^5</code>, <b>breaks
+eslint</b>: v5 exports <code>{ expand }</code> where <code>minimatch@3</code> requires a
+callable default, so <code>eslint "style/**/*.{js,mjs}"</code> dies with
+<i>"expand is not a function"</i> while plain <code>eslint style/</code> still passes — a
+green-looking linter with a broken glob path. The real fix is upstream:
+<code>eslint@10</code> depends on <code>minimatch@^10.2.5</code>, which requires the patched
+<code>brace-expansion@^5.0.8</code>. Bumped 9.39.5 → 10.8.0; all 262 packages across both
+locks now return zero OSV advisories.
+<b>Open by decision, correctly</b> — <code>BranchProtectionID</code> #33 (4/10) and
+<code>CodeReviewID</code> #34 (0/26 approved changesets) are two readings of one deliberate
+choice recorded in <a href="#main-has-no-branch-protection">its own card</a>: require status
+checks, do <i>not</i> require reviews, because the working model is parallel
+<code>loop/*</code> branches that self-merge and there is no second reviewer. Every warning
+Scorecard prints under #33 — stale-review dismissal, required approvers, CODEOWNERS review,
+last-push approval — follows from that one choice. They stay open because the score is
+<b>accurate</b>: this repo really does merge without human review. Dismissing them would be
+the lie.
+<b>Clears itself</b> — <code>MaintainedID</code> #35 is <i>"repository was created within the
+last 90 days"</i>. Created 2026-07-17, so it resolves on its own around 2026-10-15. Nothing
+to do but not dismiss it.
+<b>Needs a human, not a commit</b> — <code>CIIBestPracticesID</code> #36 is the one
+remaining actionable finding, and it cannot be fixed from a branch: it asks whether the
+project is registered for an OpenSSF Best Practices badge, which means creating a project
+entry at <code>bestpractices.dev</code> under a real account and answering its criteria. The
+prerequisites are already in place (LICENSE, SECURITY.md, CONTRIBUTING.md,
+CODE_OF_CONDUCT.md, a published CI gate); only the registration is missing.</p>
         <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">15 open · 3 fixed, 4 intentional, 5 not code-fixable</span>
+          <span class="m">7 open · 3 now hash-pinned, 3 decided, 1 clears itself</span>
         </div>
       </article>
 
@@ -3090,12 +3153,42 @@ Options, roughly in order of appeal: have CI regenerate and push the board on th
 driver for the generated boards that reruns the generator instead of merging text; or stop
 committing the HTML and build the site at deploy time (biggest change, and it removes the
 artifact from review). At minimum, make the <code>--check</code> failure message say
-"regenerate after rebasing" so the cause is obvious from the log.</p>
+"regenerate after rebasing" so the cause is obvious from the log.
+<b>Update 2026-07-29 — the three options were measured, and two of them do not work.</b>
+First, the repro, because both halves matter and they fail differently. Two branches each
+adding one item to the same section: the <em>cards</em> hard-conflict (same insertion point),
+while the <em>counters</em> merge silently to a wrong value — base <code>N</code>, both sides
+<code>N+1</code>, git keeps <code>N+1</code>, the truth is <code>N+2</code>. So a clean merge
+still fails <code>--check</code>. That is why one root cause reddens ~6 checks.
+<b>"Custom merge driver" is dead.</b> GitHub's server-side merge ignores
+<code>.gitattributes</code> merge strategies — not just custom drivers, the built-in ones too.
+Measured on this repo with four throwaway branches and
+<code>POST /repos/&hellip;/merges</code>: <b>409 without</b> the attribute and <b>409 with</b>
+<code>docs/roadmap.html merge=union</code>, while the identical merge <em>locally</em> succeeds
+cleanly and one <code>build_roadmap.py</code> run makes it correct. The attribute would help
+only whoever resolves the conflict by hand, which is the case that already works.
+<b>"CI regenerates and pushes on the PR branch" is dead too</b>, at least with
+<code>GITHUB_TOKEN</code>: a push made with it deliberately does not trigger workflows, so the
+fix-up commit would land a new head with <b>no check runs at all</b> and the required contexts
+would never report — the PR blocks forever instead of for one cycle. It needs a PAT or a GitHub
+App, i.e. a new long-lived secret with write access to every branch.
+<b>The survivor is the third one</b> — stop committing the generated HTML and build the site at
+deploy time — and it has a prerequisite that is a repository <em>setting</em>, not a commit:
+Pages is currently <code>build_type: legacy</code> serving <code>main:/</code>, so it publishes
+whatever bytes are committed. The artifact cannot leave git until Pages builds it, which means
+either an Actions-built site or a generated <code>gh-pages</code> branch (the pattern
+<code>ci.yml</code> already uses for the coverage badge, and one that does <b>not</b> re-trigger
+<code>ci</code> → <code>publish</code>, so it cuts no extra release). Everything that reads
+<code>docs/*.html</code> off disk — <code>html-validate</code>, <code>visual</code>,
+<code>lighthouse</code>, <code>check_anchors</code>, <code>a11y_check</code>,
+<code>test_docsite_chrome</code> — would need a generate step first, and
+<code>test_roadmap_fresh</code> loses its purpose. That is the whole cost, and it is bounded;
+what it is not is a change one loop should make to a live public site on its own initiative.</p>
         <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">hit twice on one PR in a single afternoon</span>
+          <span class="m">two of the three fixes measured dead; one survivor, and it needs a Pages change</span>
         </div>
       </article>
 

{boost_skill_cli-1.0.285 → boost_skill_cli-1.0.287}/scripts/build_roadmap.py

@@ -60,6 +60,11 @@ STATUS_LABEL = {
     "inflight": "In flight",
     "next": "Next",
     "planned": "Planned",
+    # A measured "no". Without it, an item that was investigated and rejected
+    # sits on the board as `planned` forever and reads as backlog, so the next
+    # loop scanning for work re-opens the same question. The pill is muted
+    # rather than coloured because a decline is not a lifecycle stage.
+    "declined": "Declined",
 }
 
 # rstatus class -> visible label (design board).