boost-skill-cli 1.2.27__tar.gz → 1.2.29__tar.gz

{boost_skill_cli-1.2.27 → boost_skill_cli-1.2.29}/.vale/styles/config/vocabularies/boost/accept.txt

@@ -7,6 +7,12 @@ argparse
 Arize
 ASan
 Attio
+Autofix
+autofix
+Backfilling
+backfilling
+backport
+backported
 backtick
 backticks
 Bagisto
@@ -46,6 +52,7 @@ fuzzer
 GEO
 GIF
 gitignored
+gitleaks
 GitOps
 glassmorphic
 Grafana
@@ -72,6 +79,7 @@ mcp
 mergeable
 minisign
 misconfiguration
+mitigations
 MLflow
 mutmut
 mypy
@@ -93,6 +101,7 @@ Quarkus
 rebased
 reimplement
 reimplemented
+reimplements
 reindex
 repo
 repo's
@@ -112,8 +121,10 @@ Saltzer
 sandboxed
 sandboxing
 scrollbar
+sdist
 SEO
 setuptools
+SHAs
 Shopify
 Sigstore
 SonarCloud
@@ -129,6 +140,7 @@ subprocess
 tappable
 teardown
 tempdir
+textarea
 toggleable
 Tokenization
 tokenization
@@ -144,6 +156,7 @@ unkilled
 unlinking
 unpatched
 unregister
+unremediated
 unstaged
 untap
 untrusted

{boost_skill_cli-1.2.27 → boost_skill_cli-1.2.29}/.vale.ini

@@ -20,5 +20,12 @@ Vale.Terms = NO
 [docs/roadmap/items/*.md]
 BasedOnStyles =
 
+; docs/commit-audit.md is a generated record: a table of short SHAs, file paths
+; and tool identifiers produced by an audit pass, not authored prose. Spelling
+; it would mean adding ~27 one-off identifiers to the shared vocabulary, which
+; would weaken the check everywhere else to lint one machine-written file.
+[docs/commit-audit.md]
+BasedOnStyles =
+
 [.claude/**/*.md]
 BasedOnStyles =

{boost_skill_cli-1.2.27 → boost_skill_cli-1.2.29}/CONTRIBUTING.md

@@ -98,6 +98,36 @@ list, and neither should be added to it.
 | `refurb boost_cli` | modernization smells the ruff families miss, zero findings |
 | `scripts/lock_toolchain.py --check` | the hash-pinned toolchain matches its `.in` declarations |
 
+## Sign your commits (DCO)
+
+Every commit needs a `Signed-off-by` trailer naming **you**, the author. It is
+your assertion, under the [Developer Certificate of Origin](DCO), that you have
+the right to submit the work. Git writes it for you:
+
+```bash
+git commit -s              # sign off as you go
+git commit --amend --signoff --no-edit    # fix the last commit
+git rebase --signoff origin/main          # fix a whole branch
+```
+
+`scripts/check_dco.py` enforces it as a required check, and you can run the
+exact same check locally:
+
+```bash
+python3 scripts/check_dco.py              # HEAD against origin/main
+```
+
+Two things it deliberately will not accept. The trailer must name the **author** of
+the commit it sits on — a sign-off from anyone else certifies nothing, so it is
+rejected rather than counted. And the check only ever looks at the commits your
+pull request adds: DCO applies from the commit that introduced it, and history
+before that is left alone. Backfilling sign-offs would mean rewriting `main`,
+breaking 478 tags and invalidating the build-provenance attestation on every
+published release, to record an assertion nobody actually made.
+
+Bot authors (Dependabot and friends) are exempt — an account cannot agree to a
+certificate.
+
 ## Code of conduct
 
 Participation is governed by the [Code of Conduct](CODE_OF_CONDUCT.md)

boost_skill_cli-1.2.29/DCO

@@ -0,0 +1,34 @@
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.

boost_skill_cli-1.2.29/MAINTAINERS.md

@@ -0,0 +1,102 @@
+# Maintainers
+
+Who has access to what, what each role is expected to do, and what has to
+happen before anyone is granted more. This file is the authoritative list; if it
+disagrees with someone's memory, this file is right and the memory is stale.
+
+## Current maintainers
+
+| Name | GitHub | Role | Since |
+|---|---|---|---|
+| Jonathan Reyes | [@jonnyeclectic](https://github.com/jonnyeclectic) | Lead maintainer | 2026-07 |
+
+boost is a **single-maintainer project today**. That is stated plainly rather
+than glossed, because it is the single largest risk to the project and it
+changes what you should expect: review latency depends on one person, and the
+bus factor is one. See [Continuity](#continuity) for what happens if that
+person becomes unavailable, and [Becoming a maintainer](#becoming-a-maintainer)
+for how that changes.
+
+## Access to sensitive resources
+
+Every credential and privileged surface the project depends on, and who holds
+it. Nothing not listed here grants access to anything.
+
+| Resource | Who has access | How access works |
+|---|---|---|
+| GitHub repository (admin) | Lead maintainer | GitHub account with 2FA |
+| `main` branch | **No one directly.** | A ruleset requires a pull request and the full required-check gate; `non_fast_forward` blocks history rewrites. Admin included. |
+| PyPI project `boost-skill-cli` | **No stored credential exists.** | Publishing is a [PyPI Trusted Publisher](https://docs.pypi.org/trusted-publishers/): GitHub mints a short-lived OIDC token for `publish.yml` on `main` only. There is no API token to leak, share, or rotate. |
+| GitHub Actions secrets | Lead maintainer | Only optional dashboard tokens (`CODECOV_TOKEN`, `SONAR_TOKEN`) and optional evaluation API keys. Every job reading one skips itself when it is absent, so none is required to build, test, or release. |
+| Security advisories / private vulnerability reports | Lead maintainer | GitHub private vulnerability reporting |
+| GitHub Pages docs site | Lead maintainer | Published from `main` by CI; no separate credential |
+
+## Roles and responsibilities
+
+**Lead maintainer.** Sets direction; reviews and merges pull requests; owns the
+release process; is the recipient of private vulnerability reports and owns the
+response; administers repository settings, branch rulesets and the required-check
+list; maintains this file.
+
+**Maintainer** (none appointed yet). Reviews and merges pull requests within an
+agreed area; may not change repository settings, rulesets, or the release path.
+A maintainer is expected to keep the quality gates green rather than route
+around them, and to say so publicly when a gate is wrong instead of disabling it
+quietly.
+
+**Contributor.** Anyone who opens a pull request. No standing permissions; a
+contribution is merged by a maintainer after the gates pass. See
+[CONTRIBUTING.md](CONTRIBUTING.md).
+
+**Security reporter.** Anyone who reports a vulnerability through the process in
+[SECURITY.md](SECURITY.md). Reporters are credited by name in the advisory and
+the release notes unless they ask not to be.
+
+## Becoming a maintainer
+
+Escalated permission is granted deliberately and never by default. The policy:
+
+1. **A track record first.** A sustained series of merged, non-trivial
+   contributions — enough that their judgement on this codebase is a known
+   quantity, not an assumption.
+2. **Review before the grant.** The lead maintainer reviews that history and
+   proposes the change in a public issue, naming the scope of access being
+   granted and why. Existing maintainers may object there.
+3. **Least privilege at the grant.** New collaborators receive the lowest
+   permission that lets them do the job. Write access is a separate, later
+   decision from repository administration, which is a separate decision again
+   from anything touching the release path.
+4. **This file is updated in the same change** that grants the permission. An
+   access grant that is not recorded here has not happened.
+
+The same review applies when an existing maintainer is given more access, not
+only to a first grant.
+
+## Removing access
+
+Access is removed promptly when a maintainer steps down, becomes unreachable for
+an extended period, or at their own request — and immediately if an account is
+believed compromised. Removal does not require agreement from the person losing
+access. Because publishing uses a short-lived OIDC identity rather than a stored
+token, removing someone's GitHub access removes their ability to release; there
+is no separate credential left behind to revoke.
+
+## Continuity
+
+If the lead maintainer becomes unavailable:
+
+- **The code is safe regardless.** It is GPL-3.0, the full history is public,
+  and every release is reproducible from a public tag. Anyone may fork.
+- **The published artifacts stay published.** PyPI releases and GitHub releases
+  remain available; nothing expires if no one logs in.
+- **Recovery of the canonical repository** would go through
+  [GitHub's account-recovery and inactive-repository processes](https://docs.github.com/en/site-policy).
+  Because the release path is a GitHub OIDC identity bound to this repository,
+  whoever legitimately controls the repository controls releases — there is no
+  personal token that has to be handed over.
+- **The practical answer is to fork.** Until a second maintainer exists, that
+  is the honest continuity plan, and the project would rather say so than
+  imply a succession process it does not have.
+
+Reducing this risk is open work: if you have been contributing and want to help
+carry it, say so in an issue.

{boost_skill_cli-1.2.27 → boost_skill_cli-1.2.29}/PKG-INFO

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

boost_skill_cli-1.2.29/SECURITY.md

@@ -0,0 +1,86 @@
+# Security policy
+
+## Supported versions
+
+Only the latest release receives security fixes. [SUPPORT.md](SUPPORT.md) sets
+out the scope and duration of support in full, including when a version stops
+receiving security updates.
+
+## Reporting a vulnerability
+
+Please **do not** open a public issue for security reports. Instead, use
+GitHub's private vulnerability reporting:
+
+**[Report a vulnerability](https://github.com/jonnyeclectic/boost/security/advisories/new)**
+
+You can expect an acknowledgement within a few days. Please include steps to
+reproduce and the affected command(s).
+
+## Vulnerability fixes in release notes
+
+Every merge to `main` cuts a release, so a fix reaches users within minutes of
+landing. When a release fixes a publicly known vulnerability in boost itself —
+one that already had a CVE or an equivalent identifier when the release was
+cut — the [release notes](https://github.com/jonnyeclectic/boost/releases) will
+name it and its identifier, so you can tell an upgrade that matters from one
+that does not. No such vulnerability has been reported to date.
+
+Vulnerabilities in boost's *dependencies* are handled separately: the runtime
+has none, and the development toolchain is watched by `osv-scanner`, `pip-audit`
+and Dependabot.
+
+## Scope notes
+
+boost executes `git` against registry URLs you tap and symlinks skills into
+agent directories. Reports about tap-supplied content escaping the store,
+path traversal via `SKILL.md` frontmatter, or command injection through
+skill/tap names are especially valuable.
+
+## Secrets and credentials
+
+The policy in one line: **boost stores no credential it could leak.**
+
+- **Releases use no stored token.** Publishing goes through PyPI Trusted
+  Publishing — GitHub mints a short-lived OIDC identity for `publish.yml` at the
+  moment of upload. There is no PyPI API token in a secret, on a laptop, or in a
+  password manager, so there is nothing to rotate and nothing to steal.
+- **Every secret that does exist is optional.** Only `CODECOV_TOKEN`,
+  `SONAR_TOKEN` and the optional evaluation API keys are configured, all as
+  GitHub Actions repository secrets. Every job reading one skips itself when it
+  is absent, so none is required to build, test or release.
+- **Secrets never reach untrusted code.** No workflow uses
+  `pull_request_target`, so a fork's pull request runs with a read-only token
+  and no secret access. Secrets are bound at job level, never interpolated into
+  a `run:` block, and `zizmor` fails a pull request that breaks either rule.
+- **Access follows the maintainer list.** Who holds what is recorded in
+  [MAINTAINERS.md](MAINTAINERS.md), which also states the policy that escalated
+  permissions are reviewed before they are granted. Access is removed promptly
+  when someone steps down and immediately if an account is believed compromised.
+- **Rotation.** An optional dashboard token is rotated on suspicion of exposure
+  or when the holder's access is removed — revoked at the issuing service, then
+  replaced or deleted in repository settings. Because none is required, deleting
+  one is always a safe first move.
+- **Committed secrets are caught.** `gitleaks` runs in CI on every push and
+  fails the build on a hit; the allowlist covers only boost's own synthetic
+  scanner test fixtures.
+
+If you believe a boost credential has been exposed, report it through the
+private channel above rather than opening an issue.
+
+## How boost is designed to resist this
+
+[`docs/security-design.md`](docs/security-design.md) is the threat model: what
+boost trusts and what it does not, the design principles the code is held to,
+and the table of error classes — path traversal, command injection, zip-slip,
+untrusted deserialization, supply-chain compromise — each paired with the
+mitigation that counters it. It also states the known limits plainly, including
+the one that matters most: boost gives you a skill's provenance, integrity and
+diff, but judging what the skill *tells your agent to do* is yours.
+
+For how boost's badge-level security posture is assessed, see
+[`docs/openssf-badge.md`](docs/openssf-badge.md). Two companion documents cover
+the supply chain either side of a release:
+[`docs/dependencies.md`](docs/dependencies.md) — how dependencies are chosen,
+pinned by hash, tracked, and at what threshold a finding blocks a merge — and
+[`docs/verifying-releases.md`](docs/verifying-releases.md) — how to verify for
+yourself that an artifact you installed was built by this repository.

boost_skill_cli-1.2.29/SUPPORT.md

@@ -0,0 +1,78 @@
+# Support
+
+What boost supports, for how long, and where to ask.
+
+## Where to ask
+
+| You want to | Go here |
+|---|---|
+| Report a bug | [Open an issue](https://github.com/jonnyeclectic/boost/issues/new/choose) |
+| Request a feature | [Open an issue](https://github.com/jonnyeclectic/boost/issues/new/choose) |
+| Report a vulnerability | **Not an issue** — [SECURITY.md](SECURITY.md) |
+| Diagnose a broken install | [`docs/DEBUGGING.md`](docs/DEBUGGING.md), then `boost doctor` |
+| Contribute a change | [CONTRIBUTING.md](CONTRIBUTING.md) |
+
+`boost doctor` is the first thing to run for anything that looks like a
+misconfiguration. It names the single next action for each problem it finds
+rather than printing a menu, and its output is the most useful thing to paste
+into an issue.
+
+## What is supported
+
+**Only the latest release.** boost releases on every merge to `main`, so the
+latest version is usually minutes old and the gap between "what you have" and
+"what is fixed" is small by design. Bug fixes and security fixes go into the
+next release; there are no backport branches and no long-term-support line.
+
+If you are on an older version, the supported answer is to upgrade:
+
+```bash
+pipx upgrade boost-skill-cli     # or: pip install -U boost-skill-cli
+```
+
+**Supported environments** — these are what CI runs on every pull request, so a
+regression on any of them fails the build:
+
+| | Supported |
+|---|---|
+| Python | 3.12, 3.13, 3.14 (and a non-blocking 3.14 free-threaded canary) |
+| Operating system | Linux, macOS, Windows |
+| Required external tools | `git` |
+
+Python 3.11 and earlier are **not** supported: the project's floor is
+`requires-python = ">=3.12"`.
+
+## When a version stops receiving security updates
+
+**The moment a newer release exists.** A version other than the latest receives
+no security updates, and none will be backported to it.
+
+This is stated as a policy rather than left implicit because the alternative
+would be misleading. With a release cut on every merge, maintaining a supported
+older line would mean supporting hundreds of versions; the project does not do
+that and will not pretend to. In exchange, the upgrade path is deliberately
+cheap — a single `pipx upgrade`, a stdlib-only runtime with no dependency
+resolution to go wrong, and no configuration migration between patch releases.
+
+If a release fixes a publicly known vulnerability, the release notes name it and
+its identifier — see
+[SECURITY.md](SECURITY.md#vulnerability-fixes-in-release-notes).
+
+## What is not supported
+
+- **The content of third-party skills, rules and workflows.** boost gives you a
+  skill's provenance, its integrity digest and a diff. Judging what a skill
+  tells your agent to do is yours; see the limits section of
+  [`docs/security-design.md`](docs/security-design.md).
+- **`boost serve`** as a hardened server. It is a local development
+  convenience for a trusted network.
+- **Optional extras** (`[rag]`, `[eval]`, `[bdd]`, `[langchain]`) carry
+  third-party dependencies and their own compatibility constraints. The default
+  install is stdlib-only and is what the support statement above covers.
+
+## Response expectations
+
+This is a single-maintainer project ([MAINTAINERS.md](MAINTAINERS.md)), so
+response times depend on one person's availability. Vulnerability reports are
+acknowledged within a few days and are the highest priority; ordinary issues are
+triaged as they arrive but carry no service-level guarantee.

{boost_skill_cli-1.2.27 → boost_skill_cli-1.2.29}/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.27'
-__version_tuple__ = version_tuple = (1, 2, 27)
+__version__ = version = '1.2.29'
+__version_tuple__ = version_tuple = (1, 2, 29)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.27 → boost_skill_cli-1.2.29}/boost_cli/commands/quality.py

@@ -1187,9 +1187,20 @@ def cmd_trust(argv) -> int:
         key_path = paths.expand(args.key)
         key_text = (key_path.read_text(encoding="utf-8")
                     if key_path.is_file() else args.key)
-        provenance.add_trusted_key(args.name, key_text)
+        rec = provenance.add_trusted_key(args.name, key_text)
         journal.log("trust", args.name, op="add-key")
-        out.ok("trusted key added")
+        # The fingerprint is the point of this line, not incidental detail: it
+        # is how the user checks by eye that the key they just trusted is the
+        # one the publisher advertises. CodeQL's py/clear-text-logging-sensitive
+        # -data flags it because `name` is user-supplied and `fingerprint` reads
+        # like a credential, but a minisign PUBLIC key fingerprint is meant to
+        # be published — printing it is the verification, and an autofix that
+        # replaced this with a constant string (dc6e827) removed the only check
+        # `trust add` offers. Restored, suppressed with the reason, and pinned
+        # by tests/functional/test_tap_signing.py so it cannot be quietly
+        # dropped a second time.
+        out.ok("trusted key %s (%s)"  # codeql[py/clear-text-logging-sensitive-data]
+               % (rec["name"], rec["fingerprint"]))
         return 0
 
     if args.action == "remove":

{boost_skill_cli-1.2.27 → boost_skill_cli-1.2.29}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.2.27 → boost_skill_cli-1.2.29}/boost_skill_cli.egg-info/SOURCES.txt

@@ -11,11 +11,14 @@
 CLAUDE.md
 CODE_OF_CONDUCT.md
 CONTRIBUTING.md
+DCO
 LICENSE
+MAINTAINERS.md
 MANIFEST.in
 Makefile
 README.md
 SECURITY.md
+SUPPORT.md
 boost
 codecov.yml
 eslint.config.mjs
@@ -122,10 +125,12 @@ docs/adapters.html
 docs/carousel.html
 docs/chat.html
 docs/commands.html
+docs/commit-audit.md
 docs/demo-index.json
 docs/demo.gif
 docs/demo.html
 docs/demo.tape
+docs/dependencies.md
 docs/design-roadmap.html
 docs/eval-latest.json
 docs/eval.html
@@ -133,9 +138,11 @@ 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
+docs/verifying-releases.md
 docs/.claude/settings.local.json
 docs/architecture/README.md
 docs/architecture/c4-components-core.md
@@ -342,6 +349,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/osps-baseline-levels.md
 docs/roadmap/items/package-metadata-validation-twine-check-friends.md
 docs/roadmap/items/patch-coverage-gate-diff-cover.md
 docs/roadmap/items/path-traversal-unsanitized-rule-workflow-name.md
@@ -485,6 +494,7 @@ scripts/build_registries.py
 scripts/build_roadmap.py
 scripts/build_scale_corpus.py
 scripts/check_anchors.py
+scripts/check_dco.py
 scripts/check_licenses.py
 scripts/check_required_checks.py
 scripts/ensure_eval_corpus.sh
@@ -607,6 +617,7 @@ tests/unit/test_catalog.py
 tests/unit/test_catalogbundle.py
 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_claude_settings.py
 tests/unit/test_clean_internal_cache.py