boost

https://github.com/jonnyeclectic/boost/blob/main/SUPPORT.md documents the policy and the upgrade path. Only the latest release is supported, and the upgrade is a single command ('pipx upgrade boost-skill-cli'), which is practical here rather than aspirational: the runtime is standard-library only so there is no dependency resolution to break, versions come from git tags via setuptools-scm, and no configuration migration is required between patch releases. Because a release is cut on every merge, the gap between an installed version and the fixed one is small by construction.

GitHub Issues, used as the sole tracker: https://github.com/jonnyeclectic/boost/issues

MAINTAINERS.md states the policy in the roles table: 'Security reporter - anyone who reports a vulnerability through the process in SECURITY.md. Reporters are credited by name in the advisory and the release notes unless they ask not to be.' https://github.com/jonnyeclectic/boost/blob/main/MAINTAINERS.md . No vulnerability has been reported to date, so the policy has not yet had an occasion to be exercised.

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] [osps_vm_01_01]

https://github.com/jonnyeclectic/boost/blob/main/CONTRIBUTING.md#ground-rules states the coding standards: standard-library only at runtime, the cli -> commands -> core layering rule with core importing neither of the outer layers, new commands as def cmd_<name>(argv) -> int dispatched lazily from cli.py, behaviour changes requiring tests, and everything under boost_cli/core being mutation-tested. Style itself is delegated to tooling rather than prose - the ruff configuration in pyproject.toml states the enabled rule families explicitly, with comments explaining each choice.

Enforced mechanically on every pull request as required checks, not by review: ruff (an explicitly enumerated rule set - E/F, flake8-bandit S, bugbear B, SIM, C4, PERF, RUF, pyupgrade UP, isort I), mypy and pyright as two independent type checkers, vulture for dead code, xenon as a complexity ratchet, refurb for modernization smells, and import-linter enforcing the layering rule from CONTRIBUTING. Zero findings are permitted from any of them - a single finding fails the build - so a standard cannot erode gradually. pre-commit runs the same tools locally before a commit is made.

boost produces no native binaries. It is a pure-Python package built with the standard PEP 517 toolchain from pyproject.toml, so there is no compiler or linker invocation and CC, CFLAGS, CXX, CXXFLAGS and LDFLAGS have nothing to be honoured by.

There is no compilation step and therefore no debugging information to strip or preserve. Python source is installed as source; tracebacks carry full file and line information by construction.

There is no recursive build. The package is built in one PEP 517 invocation from a single pyproject.toml with no subdirectory build systems and no cross-dependencies between them.

A build is repeatable and its inputs are pinned by hash. requirements/*.txt pin an exact version and every artifact's sha256 for the full transitive closure of the toolchain, enforced by pip --require-hashes, so a contributor's make venv and a CI runner resolve to identical bytes; scripts/lock_toolchain.py --check runs in the lint gate and fails on drift between the .in declaration and the locked .txt. The runtime itself has no third-party dependency to vary. The version is derived deterministically from the git tag by setuptools-scm rather than from a hand-edited constant, and noxfile.py reproduces the exact CI gate in isolated environments across every supported interpreter.

Installation uses the standard Python mechanisms and nothing bespoke: pipx install boost-skill-cli (recommended, for an isolated CLI) or pip install boost-skill-cli. The package is published to PyPI with standard metadata, so any conventional Python installation method works. Prerequisites are Python 3.12+ and git, stated in the README.

There is no bespoke installation system whose destination boost chooses. Installation is performed by pip or pipx, which already honour the standard Python conventions (--prefix, --target, --user, virtual environments and PEP 668 handling); DESTDIR is a POSIX build-system convention that does not apply to a wheel installed by pip.

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. [osps_do_07_01]

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 [osps_br_05_01]

https://github.com/jonnyeclectic/boost/blob/main/docs/dependencies.md documents the monitoring and the thresholds. Dependabot proposes upgrades; pip-audit fails the build when a resolved dependency matches a known OSV or PyPI advisory and also runs on a weekly schedule so a newly published advisory against unchanged code is still caught; OSV-Scanner runs diffed against the base branch and fails on what a pull request adds; a licence gate fails on a licence outside the allowed set; and a CycloneDX SBOM is generated per released wheel. pip-audit and osv-scan are both required checks. The runtime has no third-party dependency to monitor, which is the strongest form of this.

pyproject.toml declares the project's direct dependencies (the runtime is deliberately standard-library only; the optional [rag], [eval], [bdd] and [langchain] extras declare theirs). The development and CI toolchain is enumerated in requirements/.in and locked in requirements/.txt, which pin an exact version and every artifact's sha256 for the full transitive closure, enforced by pip --require-hashes. https://github.com/jonnyeclectic/boost/blob/main/pyproject.toml [osps_qa_02_01]

The project holds the line on dated idioms mechanically rather than by intention: ruff's pyupgrade (UP) family is enabled as a selected rule set with zero findings permitted, so a deprecated construct fails the build as it is written rather than accreting. The supported floor is Python 3.12+, which allowed the typing.List -> list and X | Y union sweeps to be completed rather than deferred. refurb additionally reports modernization smells the ruff families miss. Dependencies in the optional extras are tracked by Dependabot, so a deprecated upstream API surfaces as an upgrade pull request.

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] [osps_qa_06_01]

Well above 50%, and enforced rather than encouraged: a changed-line coverage gate requires at least 80% of the lines a pull request adds to be covered, and it is a required check. The mutation gate compounds it - 80% of mutants in boost_cli/core must be killed, so new logic that is executed but not asserted on still fails. Recent history bears it out; the most recent bug fix in this repository (a restored key fingerprint that a static-analysis autofix had deleted) shipped with a regression test verified to fail against the broken code and pass against the fix.

The coverage gate is set at exactly this threshold and is a required check: fail_under = 80 in the coverage configuration, run as part of make test over the unit and functional suites. A pull request that drops line coverage below 80% fails. The changed-line gate applies the same 80% to the diff specifically, so overall coverage cannot be held up by old code while new code arrives untested.

The policy is mandated by automation rather than by convention, which is the stronger form. CONTRIBUTING.md states that behaviour changes need tests and that anything under boost_cli/core is mutation-tested; the changed-line coverage gate and the mutation gate then enforce it as required status checks, so a change adding major functionality without tests cannot be merged into main even by the maintainer - main is protected and takes changes only through a pull request that has passed the full gate.

Documented in CONTRIBUTING.md ('The gates' table and 'Ground rules') and restated in the pull-request template checklist.

The gates are already maximally strict: zero tolerance on six linters and two type checkers, plus a complexity ratchet (xenon) that fails on regression rather than against an absolute threshold.

The principles from know_secure_design are implemented, not just understood, and https://github.com/jonnyeclectic/boost/blob/main/docs/security-design.md maps each to the code. Fail-safe defaults: archive members, path components and served skill names are accepted only against allowlists and rejected otherwise. Complete mediation: exactly one place asks whether a name may be joined onto a directory (util.is_safe_component) and one place joins a relative path inside a base; archive extraction validates a member's name and then discards it, rebuilding the destination from the basename, because a check that feeds its input forward is one refactor from being decorative. Least privilege: no elevation, no shell (shell=True appears nowhere), every subprocess an argument vector, and per-job CI permissions audited by zizmor. Economy of mechanism: a standard-library-only runtime enforced by import-linter, so there is no dependency tree to compromise.