boost

GitHub Actions is configured so a task with no permissions block gets the lowest permissions in the pipeline: every workflow declares a top-level read-only default (ci.yml opens with 'permissions: contents: read'), and write scopes are granted per job only where required. zizmor's excessive-permissions audit runs on every pull request as a required check and fails a workflow that grants more than it needs, so the default cannot quietly widen.

Versions come from setuptools-scm reading git tags, so there is no hand-maintained version constant to fall out of sync and a version is unique by construction. 'boost --version' reports it. [version_unique]

https://github.com/jonnyeclectic/boost/releases - one GitHub release per version, with notes assembled by release-drafter from the merged pull-request titles. CONTRIBUTING asks contributors to write the PR description as the release note for exactly this reason. [release_notes]

Dependencies are ingested with standard ecosystem tooling only - pip, driven by pyproject.toml for the project's own extras and by requirements/*.txt for the toolchain. Those lock files pin an exact version and every artifact's sha256 for the full transitive closure, enforced by pip --require-hashes, so a build resolves to identical bytes on a contributor's machine and on a CI runner. Nothing is vendored or fetched ad hoc. See https://github.com/jonnyeclectic/boost/blob/main/docs/dependencies.md

Every release is signed with SLSA build provenance at build time. publish.yml runs actions/attest-build-provenance over dist/* after 'twine check' and before the PyPI upload, so the exact bytes published are the bytes signed, and the attestation records which workflow built which artifact from which commit. Upload to PyPI additionally uses Trusted Publishing (a short-lived OIDC identity, no stored token). A CycloneDX SBOM is generated per released wheel and attached to the GitHub release. Verification instructions: https://github.com/jonnyeclectic/boost/blob/main/docs/verifying-releases.md

https://github.com/jonnyeclectic/boost/blob/main/docs/dependencies.md documents selection (the runtime may import no third-party package at all, enforced by import-linter; extras and the toolchain are the only two places dependencies exist, with four stated tests a new one must pass), acquisition (by sha256 over HTTPS, enforced by pip --require-hashes, regenerated with scripts/lock_toolchain.py), and tracking (Dependabot, pip-audit and osv-scan as required checks, a licence gate, per-release CycloneDX SBOMs, and SHA-pinned actions audited by zizmor).

https://github.com/jonnyeclectic/boost/blob/main/CONTRIBUTING.md documents the build from a clean clone: 'make venv' installs every gate tool from the hash-pinned requirements, and the full gate table lists each command. noxfile.py reproduces the exact CI gate in isolated venvs across every supported interpreter, so 'green on my machine' and 'green in CI' mean the same thing. Prerequisites are Python 3.12+ and git, stated in the README; the runtime itself has no third-party dependencies.

https://github.com/jonnyeclectic/boost/blob/main/MAINTAINERS.md lists the project members and, in a dedicated 'Access to sensitive resources' table, every credential and privileged surface with who holds it: repository admin, the main branch (no one directly - a ruleset requires a pull request), the PyPI project (no stored credential exists, because publishing uses Trusted Publishing), GitHub Actions secrets, security advisories, and the docs site.

The same file describes each role and what it is responsible for - lead maintainer, maintainer, contributor and security reporter - along with the policy for granting and removing access, and a continuity section. It states plainly that boost is a single-maintainer project today rather than implying a succession process that does not exist.

CONTRIBUTING.md's 'Ground rules' section states the requirements: stdlib-only runtime, the cli -> commands -> core layering rule, and that behaviour changes need tests. https://github.com/jonnyeclectic/boost/blob/main/.github/PULL_REQUEST_TEMPLATE.md pre-fills the same checklist on every PR. [contribution_requirements]

The repository requires a Developer Certificate of Origin sign-off on every commit a pull request adds. The certificate is the standard DCO 1.1 text at https://github.com/jonnyeclectic/boost/blob/main/DCO ; enforcement is scripts/check_dco.py, wired as the 'dco' required status check (.github/workflows/dco.yml) and listed in .github/required-checks.txt, so a commit without a sign-off cannot merge. Contributors are told how in CONTRIBUTING.md ('Sign your commits'), and the same check runs locally.

One design point worth stating, because it is what makes the assertion meaningful: the checker compares the trailer against each commit's OWN AUTHOR and rejects a sign-off naming anybody else. A DCO is the contributor certifying they have the right to submit the work, so a trailer added later by a reviewer or a script certifies nothing; tests/unit/test_check_dco.py::test_signoff_naming_someone_else_is_rejected pins that behaviour, and it is the test the file exists for.

The requirement applies from the commit that introduced it forward, which is how DCO adoption normally works. Sign-offs were deliberately NOT backfilled onto the 569 pre-existing commits: doing so would have rewritten main, breaking 478 git tags, every setuptools-scm version derived from them, and the SLSA build-provenance attestation on every published release - all to record an assertion nobody actually made. Bot authors are exempt because an account cannot agree to a certificate.

GitHub Actions runs the full gate on every push and every pull request: https://github.com/jonnyeclectic/boost/actions/workflows/ci.yml [test_continuous_integration]

GitHub Actions runs the full gate on every push and every pull request: https://github.com/jonnyeclectic/boost/actions/workflows/ci.yml [test_continuous_integration]

https://github.com/jonnyeclectic/boost/tree/main/docs/architecture holds C4 design documentation - system context, containers, core components, and a dynamic view of the install flow - showing the actors and the actions between them. https://github.com/jonnyeclectic/boost/blob/main/docs/security-design.md adds the security view of the same system: the trust boundaries, which actors are trusted and which are not (a tap author is treated as an attacker for modelling purposes), and where each untrusted input crosses into privileged behaviour. docs/rag-architecture.md covers the retrieval subsystem.

https://jonnyeclectic.github.io/boost/docs/commands.html documents every command and every flag. It is generated from the CLI itself - the COMMANDS registry plus each command's argparse parser - and a CI --check fails the build if it drifts, so the reference cannot go stale. 'boost --help' and 'boost <cmd> --help' are the same data. [documentation_interface]

https://github.com/jonnyeclectic/boost/blob/main/docs/security-design.md is that assessment. It identifies the most likely and impactful problems for a CLI that clones third-party repositories and writes files into the directories an AI agent reads - path traversal via attacker-controlled frontmatter, command injection through skill and tap names, archive extraction escapes, link following, untrusted deserialization, supply-chain and CI-action compromise - and pairs each with the mitigation in the codebase. It also states the residual risks plainly, including the most important one: boost can give provenance, integrity and a diff, but cannot vet what a skill instructs an agent to do.

https://github.com/jonnyeclectic/boost/blob/main/SECURITY.md states the channel, the expected acknowledgement time, and what a useful report contains. [vulnerability_report_process]

GitHub private vulnerability reporting is enabled on the repository. Reports go to https://github.com/jonnyeclectic/boost/security/advisories/new and never to a public issue; SECURITY.md says so explicitly. [vulnerability_report_private]

GitHub Security Advisories on this repository is the project's public channel for vulnerability data, and it is the same channel private reports are triaged through, so a fix and its advisory are published together. SECURITY.md commits in writing that any release fixing a publicly known vulnerability will name it and its identifier in the release notes, which are public per release. No vulnerability has been discovered in boost to date, so the channel currently has nothing to publish - the policy and the channel exist ahead of need rather than after it. https://github.com/jonnyeclectic/boost/blob/main/SECURITY.md