boost-skill-cli 1.2.28__tar.gz → 1.2.30__tar.gz

{boost_skill_cli-1.2.28 → boost_skill_cli-1.2.30}/.vale/styles/config/vocabularies/boost/accept.txt

@@ -52,6 +52,7 @@ fuzzer
 GEO
 GIF
 gitignored
+gitleaks
 GitOps
 glassmorphic
 Grafana
@@ -100,6 +101,7 @@ Quarkus
 rebased
 reimplement
 reimplemented
+reimplements
 reindex
 repo
 repo's
@@ -138,6 +140,7 @@ subprocess
 tappable
 teardown
 tempdir
+textarea
 toggleable
 Tokenization
 tokenization

{boost_skill_cli-1.2.28 → boost_skill_cli-1.2.30}/CONTRIBUTING.md

@@ -128,6 +128,13 @@ published release, to record an assertion nobody actually made.
 Bot authors (Dependabot and friends) are exempt — an account cannot agree to a
 certificate.
 
+## Governance
+
+Who decides, how a decision gets made, and what happens when people disagree:
+[GOVERNANCE.md](GOVERNANCE.md). Who holds which role and which credential:
+[MAINTAINERS.md](MAINTAINERS.md). Both say plainly that this is a
+single-maintainer project today rather than implying a committee.
+
 ## Code of conduct
 
 Participation is governed by the [Code of Conduct](CODE_OF_CONDUCT.md)

boost_skill_cli-1.2.30/GOVERNANCE.md

@@ -0,0 +1,103 @@
+# Governance
+
+How boost makes decisions, who makes them, and what happens when people
+disagree. [MAINTAINERS.md](MAINTAINERS.md) is the companion: it lists who holds
+which role and which credential. This file is about the *process*.
+
+## The short version
+
+boost is a **single-maintainer project** run in the open. The lead maintainer
+decides; everything that shapes a decision — the roadmap, the quality gates, the
+reasoning behind a change — is public and arguable before it lands. That is a
+benevolent-dictator model, and naming it plainly is better than implying a
+committee that does not exist.
+
+This is stated as the current state, not an aspiration. It changes when a second
+maintainer is appointed under
+[MAINTAINERS.md](MAINTAINERS.md#becoming-a-maintainer), and this file changes
+with it.
+
+## How a decision gets made
+
+**1. Anyone may propose.** Open an issue, or open a pull request. There is no
+membership requirement and no form to fill in.
+
+**2. The argument happens in public, on the artifact.** Issues, pull requests,
+and the roadmap boards. A decision made in a private channel is not a decision
+this project recognises; if something was settled elsewhere, it gets written
+down in the open before it is acted on.
+
+**3. The gates decide what they can.** A large class of decisions is not a
+matter of opinion here — the change either passes the required checks or it does
+not. Coverage, mutation score, retrieval quality, the lint and type gates, the
+generated-file freshness checks: these are stated thresholds, and a maintainer
+does not get to wave one through. Changing a *threshold* is itself a decision
+that goes through this process, in its own pull request, with the measurement
+that justifies it.
+
+**4. The lead maintainer decides what the gates cannot.** Scope, design,
+priority, and whether a proposal fits the project at all. The decision is
+recorded where the work is: in the pull request, or as a roadmap card.
+
+**5. A "no" is recorded, not dropped.** The roadmap has a `declined` status
+precisely so a rejected proposal stops reading as backlog. Without it the same
+refuted question gets re-opened by the next person — or the next agent — who
+scans the board for work. If your proposal is declined you get the reason in
+writing, and it stays there.
+
+## Disagreements
+
+**With a decision.** Say so on the issue or pull request. Bring the thing that
+would change the answer: a measurement, a failing case, a constraint that was
+missed. This project changes its mind on evidence and says so when it does —
+several roadmap cards exist specifically to record that an earlier claim was
+wrong.
+
+**With the process, or with a person.** Conduct concerns go through the private
+reporting route in [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md), never a public
+issue.
+
+**When you cannot reach agreement.** With a single maintainer there is no appeal
+body, and pretending otherwise would be dishonest. The real backstop is the
+licence: boost is GPL-3.0 with full public history, so anyone who thinks the
+project is being run badly can fork it and prove it. That is a genuine check on
+the maintainer, not a consolation prize.
+
+## What is deliberately not decided by discussion
+
+Some things are settled by rule, and a pull request arguing the opposite gets
+declined on sight unless it changes the rule first:
+
+- **The runtime imports no third-party package.** Enforced by `import-linter`.
+- **Generated files are never hand-edited.** `registries.json`, both roadmap
+  boards, `commands.html`. Edit the source and regenerate.
+- **A suppressed finding needs a written argument**, naming what would have to
+  change for the suppression to stop being true. See
+  [`docs/dependencies.md`](docs/dependencies.md).
+- **A badge answer or a security claim must be checkable.** If the evidence
+  needs credentials nobody reading has, the claim gets softened to what *is*
+  checkable rather than asserted.
+
+## Roadmap and priority
+
+Priority is public and data-driven. Both boards are generated from one file per
+item under `docs/roadmap/items/`, so proposing work is a pull request adding a
+card, and claiming work is a pull request setting `status` and `owner` on one.
+Two people claiming different items touch different files and merge cleanly; two
+claiming the *same* item conflict on that one small file, which is the intended
+"already claimed" signal — first to merge wins.
+
+There is no private backlog. What is on the boards is what is planned.
+
+## Releases
+
+Every merge to `main` cuts a release. There is no release manager, no release
+meeting, and no window: the decision to release *is* the decision to merge.
+Consequences of that are set out in [SUPPORT.md](SUPPORT.md) — only the latest
+release is supported — and in
+[`docs/verifying-releases.md`](docs/verifying-releases.md), which is how you
+check that a release came from this repository.
+
+## Changing this document
+
+Like anything else: a pull request, argued in public, merged through the gates.

{boost_skill_cli-1.2.28 → boost_skill_cli-1.2.30}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.28
+Version: 1.2.30
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE
@@ -725,6 +725,7 @@ Dynamic: license-file
 [![Mutation score](https://img.shields.io/badge/mutation_score-%E2%89%A580%25_killed-blueviolet)](https://github.com/jonnyeclectic/boost/blob/main/scripts/mutation_gate.py)
 [![Platform](https://img.shields.io/badge/platform-macOS%20%7C%20Linux-lightgrey)](https://github.com/jonnyeclectic/boost/actions/workflows/ci.yml)
 [![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14275/badge)](https://www.bestpractices.dev/projects/14275)
+[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14275/baseline)](https://www.bestpractices.dev/projects/14275/baseline-2)
 [![License](https://img.shields.io/github/license/jonnyeclectic/boost)](LICENSE)
 
 **Homebrew for AI coding skills.** boost finds, installs, and version-tracks

{boost_skill_cli-1.2.28 → boost_skill_cli-1.2.30}/README.md

@@ -7,6 +7,7 @@
 [![Mutation score](https://img.shields.io/badge/mutation_score-%E2%89%A580%25_killed-blueviolet)](https://github.com/jonnyeclectic/boost/blob/main/scripts/mutation_gate.py)
 [![Platform](https://img.shields.io/badge/platform-macOS%20%7C%20Linux-lightgrey)](https://github.com/jonnyeclectic/boost/actions/workflows/ci.yml)
 [![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14275/badge)](https://www.bestpractices.dev/projects/14275)
+[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14275/baseline)](https://www.bestpractices.dev/projects/14275/baseline-2)
 [![License](https://img.shields.io/github/license/jonnyeclectic/boost)](LICENSE)
 
 **Homebrew for AI coding skills.** boost finds, installs, and version-tracks

{boost_skill_cli-1.2.28 → boost_skill_cli-1.2.30}/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.28'
-__version_tuple__ = version_tuple = (1, 2, 28)
+__version__ = version = '1.2.30'
+__version_tuple__ = version_tuple = (1, 2, 30)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.28 → boost_skill_cli-1.2.30}/boost_skill_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.28
+Version: 1.2.30
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE
@@ -725,6 +725,7 @@ Dynamic: license-file
 [![Mutation score](https://img.shields.io/badge/mutation_score-%E2%89%A580%25_killed-blueviolet)](https://github.com/jonnyeclectic/boost/blob/main/scripts/mutation_gate.py)
 [![Platform](https://img.shields.io/badge/platform-macOS%20%7C%20Linux-lightgrey)](https://github.com/jonnyeclectic/boost/actions/workflows/ci.yml)
 [![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14275/badge)](https://www.bestpractices.dev/projects/14275)
+[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14275/baseline)](https://www.bestpractices.dev/projects/14275/baseline-2)
 [![License](https://img.shields.io/github/license/jonnyeclectic/boost)](LICENSE)
 
 **Homebrew for AI coding skills.** boost finds, installs, and version-tracks

{boost_skill_cli-1.2.28 → boost_skill_cli-1.2.30}/boost_skill_cli.egg-info/SOURCES.txt

@@ -12,6 +12,7 @@ CLAUDE.md
 CODE_OF_CONDUCT.md
 CONTRIBUTING.md
 DCO
+GOVERNANCE.md
 LICENSE
 MAINTAINERS.md
 MANIFEST.in
@@ -138,6 +139,7 @@ docs/index.html
 docs/langchain.html
 docs/mcp-hub.html
 docs/openssf-badge.md
+docs/openssf-playbook.md
 docs/rag-architecture.md
 docs/roadmap.html
 docs/security-design.md
@@ -348,6 +350,8 @@ docs/roadmap/items/one-commit-can-cut-two-releases.md
 docs/roadmap/items/one-dead-tap-broke-every-update.md
 docs/roadmap/items/one-shared-atomic-write-helper.md
 docs/roadmap/items/openssf-best-practices-badge.md
+docs/roadmap/items/openssf-playbook.md
+docs/roadmap/items/openssf-silver.md
 docs/roadmap/items/osps-baseline-levels.md
 docs/roadmap/items/package-metadata-validation-twine-check-friends.md
 docs/roadmap/items/patch-coverage-gate-diff-cover.md

{boost_skill_cli-1.2.28 → boost_skill_cli-1.2.30}/docs/openssf-badge.md

@@ -248,6 +248,13 @@ or a repository setting, so they cannot be landed as a commit.
    silently a second time. The missing test was the real defect; the alert was
    only the trigger.
 
+## Doing this on another project
+
+[`openssf-playbook.md`](openssf-playbook.md) is the repeatable method behind
+this document: where the authoritative criteria actually live, how to audit a
+repository against them rather than assuming, the three buckets every criterion
+sorts into, and the four documents Baseline Level 2 asks for.
+
 ## Keeping this document honest
 
 Re-check it when any of these change, since each one moves an answer:

boost_skill_cli-1.2.30/docs/openssf-playbook.md

@@ -0,0 +1,238 @@
+# Earning the OpenSSF badges: a playbook
+
+boost went from unregistered to three badges — **passing**, **Baseline Level 1**
+and **Baseline Level 2** — in one working session. This is the method, written
+so another project can follow it, including the parts that cost time to
+discover and the parts where the honest answer is "no".
+
+It is not a checklist of criteria. The criteria live upstream and change; what
+transfers is how to find them, how to decide an answer, and which kinds of
+criterion are worth attacking in which order.
+
+## What you are actually applying for
+
+bestpractices.dev issues **four independent badges**, not one with tiers. This
+is the first thing most people get wrong, including this project's own earlier
+notes.
+
+| Badge | Criteria | Nature |
+|---|---|---|
+| **Passing** | 67 | The classic CII set — process, quality, security basics |
+| **Baseline Level 1** | 24 | OSPS Baseline: repository hygiene and CI safety |
+| **Baseline Level 2** | 19 | OSPS Baseline: governance, supply chain, documented policy |
+| **Baseline Level 3** | 21 | OSPS Baseline: review, VEX, SCA policy |
+
+Passing also has **silver** (55 more criteria) and **gold** (20 more) above it,
+which *are* tiers — silver requires passing, gold requires silver.
+
+Each badge is a separate form at
+`bestpractices.dev/en/projects/<id>/<level>/edit`, where `<level>` is `passing`,
+`baseline-1`, `baseline-2`, `baseline-3`, `silver` or `gold`. They share a
+project id and nothing else. Register once, then work them independently.
+
+## Step 1 — get the real criteria, not a summary
+
+Do not work from a blog post, and do not work from what an LLM recalls. Both
+will be plausible and subtly wrong about which criteria allow N/A, which demand
+a URL, and which are MUST versus SHOULD — and those three facts decide most of
+your answers.
+
+The authoritative source is the badge application's own repository, and it takes
+**two files**, because they are split:
+
+```bash
+# Metadata: category (MUST/SHOULD/SUGGESTED), na_allowed, met_url_required,
+# met_justification_required. Carries NO descriptions.
+curl -sL https://raw.githubusercontent.com/coreinfrastructure/best-practices-badge/main/criteria/criteria.yml
+
+# The actual description: and details: prose for each criterion.
+curl -sL https://raw.githubusercontent.com/coreinfrastructure/best-practices-badge/main/config/locales/en.yml
+```
+
+`https://www.bestpractices.dev/criteria/0.json` looks like the obvious endpoint
+and returns **HTTP 406**. Skip it.
+
+`criteria.yml` is an ordered map keyed by level — `- '0':` is passing, `'1'` is
+silver, `'2'` is gold. Indentation is 2 / 4 / 6 / 10 spaces for major group,
+minor group, criterion name, and keys. A parser that does not stop at `- '1':`
+will silently fold silver criteria into your passing set; passing is **exactly
+67**, so check your count before trusting your parse.
+
+The OSPS Baseline criteria are not in that file at all. The fastest way to read
+them, and the one that guarantees you are looking at what the form will actually
+ask, is to open the form and scrape it — each criterion's full text sits in an
+element whose `id` is the criterion name (`osps_qa_05_02`). Collapsed panels
+return empty `innerText`, so read `textContent`.
+
+## Step 2 — audit, do not assume
+
+**The single highest-value finding: most unanswered criteria are already
+satisfied and merely unrecorded.**
+
+Nine of Baseline Level 1's 24 criteria were open when boost started. Every one
+was already true. Branch protection plus a ruleset already refused direct
+commits to `main`. No workflow used `pull_request_target`, so a fork's code
+already could not reach a secret. An audit of every tracked file for binary
+content turned up three zero-byte marker files and a 10-byte fuzz seed. The work
+was proving it, not building it — and the badge went from 63% to 100% without a
+line of code.
+
+So audit before you plan. Concretely, for each open criterion, find the evidence
+or establish that it is missing:
+
+```bash
+# Branch protection and rulesets (rulesets are separate from classic protection,
+# and a repo can have both — checking only one will mislead you)
+curl -s https://api.github.com/repos/OWNER/REPO/branches/main
+curl -s https://api.github.com/repos/OWNER/REPO/rules/branches/main
+
+# Private vulnerability reporting — a yes/no you should never guess
+curl -s https://api.github.com/repos/OWNER/REPO/private-vulnerability-reporting
+
+# Untrusted code reaching secrets
+grep -rl pull_request_target .github/workflows/
+
+# Binary and executable artifacts in version control
+git ls-files | while read -r f; do
+  [ -x "$f" ] && echo "EXEC: $f"
+  file -b --mime "$f" | grep -q charset=binary && echo "BINARY: $f"
+done
+```
+
+Two traps in that last one. Files carrying the executable bit are usually
+*source scripts*, not the "generated executable artifacts" the criterion means.
+And `file` reports zero-byte files as binary, so `__init__.py` and `py.typed`
+will show up; check sizes before you believe them.
+
+## Step 3 — sort every criterion into three buckets
+
+This is the whole planning step, and it is what stops the work sprawling.
+
+**Bucket 1 — documentation you can write.** By far the largest, and the one an
+agent can close. Nothing about the software changes; you are recording what is
+already true. Attack these first.
+
+**Bucket 2 — a repository setting.** A checkbox or a field. Fast, but you cannot
+do it from a branch, so collect them into one list and hand it over. For boost:
+the empty `homepage` field, a CodeQL alert dismissal, enabling private
+vulnerability reporting.
+
+**Bucket 3 — structurally blocked.** Requires something you do not have, usually
+another person. **Say so and move on.** Do not stretch an answer to make a
+number go up; a badge that misrepresents your posture is worse than a missing
+one, and the criteria are written by people who have seen every stretch.
+
+For boost, bucket 3 was one thing wearing four hats: `OSPS-QA-07.01` (Level 3),
+`two_person_review`, `bus_factor` and `contributors_unassociated` (gold) all
+require a **non-author human reviewer**. A single-maintainer project cannot
+satisfy them, and no commit changes that.
+
+## Step 4 — write the four documents Level 2 asks for
+
+Every project that reaches Baseline Level 2 writes approximately these four.
+They are worth having irrespective of any badge, which is the test of whether a
+compliance exercise was worth doing.
+
+| Document | The question it answers | Where it usually goes wrong |
+|---|---|---|
+| `MAINTAINERS.md` | Who holds which credential, what each role may do, how someone gets more access, what happens if you vanish | Listing people but not *credentials*. The criterion asks about access to sensitive resources. If you publish with OIDC/Trusted Publishing, the honest entry is "nobody holds it — there is no token", which is a stronger answer than a name |
+| `SUPPORT.md` | What is supported, on what platforms, for how long, and when a version stops getting security fixes | Implying a supported older line you do not actually maintain. If you only support latest, say only latest |
+| `docs/dependencies.md` | How a dependency is chosen, obtained, tracked — and **the severity threshold at which a finding blocks a release** | Describing your scanners and calling it a policy. "We run osv-scanner" is not a policy; "critical and high block the merge, medium blocks if reachable, suppression requires a written argument" is |
+| `docs/verifying-releases.md` | The exact commands a consumer runs to verify an artifact came from you | Omitting the identity check. `gh attestation verify FILE --repo O/R` proves *someone* built it; adding `--signer-workflow O/R/.github/workflows/publish.yml` proves **which workflow** did |
+
+And a threat model — `docs/security-design.md` — which passing needs for
+`know_secure_design` and `know_common_errors`, and Baseline Level 2 reuses for
+`osps_sa_01_01` and `osps_sa_03_01`. One document, four criteria. Write it early.
+
+Make it specific or it satisfies nobody. Work through Saltzer and Schroeder's
+eight principles as **claims about your code**, each pointing at the file that
+implements it. Table your CWE classes with the mitigation that counters each,
+and **omit the ones that do not apply** rather than padding — a threat model
+listing SQL injection for a project with no database advertises that nobody
+thought about it.
+
+## Step 5 — answer honestly, including when the answer is "no"
+
+A `SHOULD` may be answered **Unmet with a justification** and the badge still
+passes. Use that. It is there precisely so you do not have to lie.
+
+boost answered `crypto_call` Unmet: it reimplements Ed25519 verification in pure
+Python because its stdlib-only rule leaves no alternative. The justification
+states the trade, bounds the exposure (verify-only, public keys, no secret for a
+timing channel), and cites the RFC test vectors that pin correctness. That is a
+better answer than a stretched "Met", and it is the kind of thing a reviewer
+reads and trusts the rest of your form because of.
+
+Three specific honesty traps worth naming, all of which caught this project:
+
+- **Do not claim a setting you cannot read.** `no_leaked_credentials` was
+  drafted asserting "GitHub secret scanning is on". That setting needs
+  repo-admin credentials to read. The answer became what *was* checkable —
+  gitleaks failing the build, OIDC publishing leaving no stored token — plus a
+  note asking the registrant to confirm the setting themselves.
+- **Do not restate a claim your own repo refuses to make.** A draft said `main`
+  "takes changes only through reviewed pull requests". The ruleset deliberately
+  requires status checks and *not* human approval, and this repo's Scorecard
+  triage keeps that finding open rather than dismissing it, because the score is
+  accurate. The badge form nearly contradicted the repo's own honesty.
+- **Re-verify anything you inherited.** A note said the licence was MIT. It is
+  GPL-3.0. That single check changed three answers.
+
+## Step 6 — filling the forms
+
+Each form is one radio group per criterion (`project[<name>_status]`, values
+`Met` / `Unmet` / `N/A` / `?`) and one textarea
+(`project[<name>_justification]`). Filling 67 by hand is a bad use of a
+session; drive it, then audit that nothing is left at `?` before submitting:
+
+```javascript
+// Set a status + justification, dispatching the events the app listens for
+const r = document.querySelector(
+  `input[type=radio][name="project[${key}_status]"][value="${status}"]`);
+r.click();
+const ta = document.querySelector(`textarea[name="project[${key}_justification]"]`);
+ta.value = justification;
+ta.dispatchEvent(new Event('input',  {bubbles: true}));
+ta.dispatchEvent(new Event('change', {bubbles: true}));
+```
+
+Two operational notes. Prefer the **"Submit (and exit)"** button over "Save (and
+continue) 🤖" — the latter runs automation that fills unknown values, which you
+do not want once you have answered everything deliberately. And the form's
+progress percentage is the fastest correctness check you have: if you answered
+every criterion and it does not read 100%, something did not take.
+
+## Step 7 — keep the answer sheet in the repository
+
+Write your answers into a tracked document — boost's is
+[`openssf-badge.md`](openssf-badge.md) — with each answer's evidence beside it.
+This matters more than it sounds:
+
+- The badge site periodically asks you to reconfirm. Re-reading your own
+  reasoning beats re-deriving it.
+- Answers go stale in predictable ways. Note them: a vulnerability being
+  reported moves three answers; adding a runtime dependency moves three more; a
+  licence change moves three.
+- It makes the claims reviewable by people who do not have a badge account,
+  which is most of your users.
+
+## What this cost, and what it found
+
+Three badges, six new documents, and — the part worth the whole exercise — a
+**live regression on `main`**. Auditing commits against their messages surfaced
+a merged Copilot autofix that had replaced `boost trust add`'s printed key
+fingerprint with a constant string, deleting the only verification the command
+offered. It passed every gate because no test asserted that line.
+
+That is the honest argument for doing this. The badges are a forcing function;
+what you get is the audit.
+
+## Related
+
+- [`openssf-badge.md`](openssf-badge.md) — boost's worked answers, all 67
+  passing criteria with evidence
+- [`security-design.md`](security-design.md) — the threat model the knowledge
+  criteria require
+- [`dependencies.md`](dependencies.md) · [`verifying-releases.md`](verifying-releases.md)
+  · [`../MAINTAINERS.md`](../MAINTAINERS.md) · [`../SUPPORT.md`](../SUPPORT.md)
+  — the Level 2 four

boost_skill_cli-1.2.30/docs/roadmap/items/openssf-playbook.md

@@ -0,0 +1,33 @@
+---
+id: openssf-playbook
+board: code
+section: docsite
+status: shipped
+category: Docs
+complexity: S
+impact: Med
+wow: 3
+note: the method, not the answers — so another repo can repeat it
+order: 6
+owner: loop/openssf-playbook
+pr:
+title: The OpenSSF badge playbook
+---
+Three badges in one session left two kinds of artifact behind. <a href="roadmap.html#openssf-best-practices-badge">The
+answer sheets</a> record <i>what boost answered</i>, which is worth exactly nothing to
+anybody else. This records <b>the method</b>.
+The parts that cost real time to discover: the badge site issues <b>four independent
+badges</b>, not one with tiers, each at its own <code>/&lt;level&gt;/edit</code> form. The
+authoritative criteria need <b>two</b> upstream files — <code>criteria.yml</code> has the
+MUST/SHOULD and <code>na_allowed</code> flags but no prose, <code>en.yml</code> has the
+prose — and the obvious <code>/criteria/0.json</code> endpoint returns 406. A parser that
+does not stop at <code>- '1':</code> folds silver into passing; passing is exactly 67, so
+the count is the check.
+The part that changes how you plan: <b>most unanswered criteria are already satisfied and
+merely unrecorded</b>. Nine of Baseline Level 1's 24 were open and every one was already
+true — the work was proving it, not building it, and the badge went 63% → 100% with no code.
+So every criterion sorts into three buckets: documentation you can write, a repository
+setting you cannot do from a branch, and <b>structurally blocked — say so and move on</b>.
+Also records the three honesty traps this project walked into and had to back out of:
+claiming a setting that needs credentials to read, restating a claim the repo's own
+Scorecard triage refuses to make, and inheriting "the licence is MIT" when it is GPL-3.0.

boost_skill_cli-1.2.30/docs/roadmap/items/openssf-silver.md

@@ -0,0 +1,39 @@
+---
+id: openssf-silver
+board: code
+section: health
+status: inflight
+category: Security · Posture
+complexity: S
+impact: Med
+wow: 3
+note: 55 criteria, 31% → the gap was two documents, not fifty
+order: 7
+owner: loop/openssf-silver
+pr:
+title: OpenSSF silver — reachable solo, and mostly already true
+---
+Silver reads like a wall — <b>55 criteria</b> on top of passing — and the board showed 31%
+with 37 unanswered. Reading them rather than assuming turned the estimate from "a day" into
+<b>two documents</b>. The same lesson <a href="roadmap.html#osps-baseline-levels">the Baseline
+audit</a> taught: most unanswered criteria are already satisfied and merely unrecorded.
+Eighteen were <b>already answered</b>, because the badge site carries a justification across
+levels wherever a criterion name repeats — so <code>assurance_case</code>,
+<code>signed_releases</code>, <code>dco</code> and <code>roles_responsibilities</code> arrived
+already Met from the passing and Baseline work. Most of the remaining 37 are evidence that
+exists and had never been written into a form: the coverage and mutation gates, the
+hash-pinned toolchain, the C4 architecture docs, the generated command reference with its
+freshness check.
+<b>The two genuine gaps.</b> <code>governance</code> wanted the decision-making model, which
+<code>MAINTAINERS.md</code> did not cover — it lists roles, not how a decision gets made or
+what happens when people disagree. <code>GOVERNANCE.md</code> now says it plainly: a
+benevolent-dictator model, the gates decide what they can, a "no" is recorded rather than
+dropped, and the real backstop on a single maintainer is the GPL and a public history —
+anyone who thinks it is run badly can fork and prove it. <code>documentation_achievements</code>
+wanted the badges hyperlinked from the front page.
+<b>What stays honestly Unmet</b>, all SHOULD or SUGGESTED, so the badge still passes:
+<code>bus_factor</code> (one maintainer), <code>version_tags_signed</code> (tags are
+unsigned; releases carry SLSA provenance instead), <code>crypto_algorithm_agility</code>
+(minisign is Ed25519-only by format) and <code>internationalization</code> (the CLI is
+English-only). Gold remains out of reach for the reason it always was — it needs a second
+human, not a commit.

{boost_skill_cli-1.2.28 → boost_skill_cli-1.2.30}/docs/roadmap.html

@@ -133,7 +133,7 @@
       <div class="stat"><b>16</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>7</b><span>Planned</span></div>
-      <div class="stat"><b>269</b><span>Loop finds</span></div>
+      <div class="stat"><b>271</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -4759,6 +4759,41 @@ improvement is real (or isn't)."</p></details>
         </div>
       </article>
 
+      <article class="cap rcard" id="openssf-silver">
+        <div class="head"><span class="pill inflight">In flight</span><span class="cat">Security · Posture</span></div>
+        <h3>OpenSSF silver — reachable solo, and mostly already true</h3>
+        <p>Silver reads like a wall — <b>55 criteria</b> on top of passing — and the board showed 31%
+with 37 unanswered. Reading them rather than assuming turned the estimate from "a day" into
+<b>two documents</b>. The same lesson <a href="roadmap.html#osps-baseline-levels">the Baseline
+audit</a> taught: most unanswered criteria are already satisfied and merely unrecorded.
+Eighteen were <b>already answered</b>, because the badge site carries a justification across
+levels wherever a criterion name repeats — so <code>assurance_case</code>,
+<code>signed_releases</code>, <code>dco</code> and <code>roles_responsibilities</code> arrived
+already Met from the passing and Baseline work. Most of the remaining 37 are evidence that
+exists and had never been written into a form: the coverage and mutation gates, the
+hash-pinned toolchain, the C4 architecture docs, the generated command reference with its
+freshness check.
+<b>The two genuine gaps.</b> <code>governance</code> wanted the decision-making model, which
+<code>MAINTAINERS.md</code> did not cover — it lists roles, not how a decision gets made or
+what happens when people disagree. <code>GOVERNANCE.md</code> now says it plainly: a
+benevolent-dictator model, the gates decide what they can, a "no" is recorded rather than
+dropped, and the real backstop on a single maintainer is the GPL and a public history —
+anyone who thinks it is run badly can fork and prove it. <code>documentation_achievements</code>
+wanted the badges hyperlinked from the front page.
+<b>What stays honestly Unmet</b>, all SHOULD or SUGGESTED, so the badge still passes:
+<code>bus_factor</code> (one maintainer), <code>version_tags_signed</code> (tags are
+unsigned; releases carry SLSA provenance instead), <code>crypto_algorithm_agility</code>
+(minisign is Ed25519-only by format) and <code>internationalization</code> (the CLI is
+English-only). Gold remains out of reach for the reason it always was — it needs a second
+human, not a commit.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">55 criteria, 31% → the gap was two documents, not fifty</span>
+        </div>
+      </article>
+
       <article class="cap rcard" id="property-based-tests-hypothesis-on-the-parsers">
         <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Testing · Bug</span></div>
         <h3>Property-based tests — <code>hypothesis</code> on the parsers</h3>
@@ -9405,6 +9440,36 @@ and the work stays visible.</p></details>
         </div>
       </article>
 
+      <article class="cap rcard" id="openssf-playbook">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Docs</span></div>
+        <h3>The OpenSSF badge playbook</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p>Three badges in one session left two kinds of artifact behind. <a href="roadmap.html#openssf-best-practices-badge">The
+answer sheets</a> record <i>what boost answered</i>, which is worth exactly nothing to
+anybody else. This records <b>the method</b>.
+The parts that cost real time to discover: the badge site issues <b>four independent
+badges</b>, not one with tiers, each at its own <code>/&lt;level&gt;/edit</code> form. The
+authoritative criteria need <b>two</b> upstream files — <code>criteria.yml</code> has the
+MUST/SHOULD and <code>na_allowed</code> flags but no prose, <code>en.yml</code> has the
+prose — and the obvious <code>/criteria/0.json</code> endpoint returns 406. A parser that
+does not stop at <code>- '1':</code> folds silver into passing; passing is exactly 67, so
+the count is the check.
+The part that changes how you plan: <b>most unanswered criteria are already satisfied and
+merely unrecorded</b>. Nine of Baseline Level 1's 24 were open and every one was already
+true — the work was proving it, not building it, and the badge went 63% → 100% with no code.
+So every criterion sorts into three buckets: documentation you can write, a repository
+setting you cannot do from a branch, and <b>structurally blocked — say so and move on</b>.
+Also records the three honesty traps this project walked into and had to back out of:
+claiming a setting that needs credentials to read, restating a claim the repo's own
+Scorecard triage refuses to make, and inheriting "the licence is MIT" when it is GPL-3.0.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">the method, not the answers — so another repo can repeat it</span>
+        </div>
+      </article>
+
       <article class="cap rcard" id="prose-and-terminology-linting-vale">
         <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Quality · Content</span></div>
         <h3>Prose &amp; terminology linting — <code>vale</code></h3>