Supply chain and continuity

This page states what the burgee family installs, how it is published, and what a team that forks it keeps. Each statement links the check that holds it in CI. Where a check is missing, the statement is not on this page.

What an install brings inCopy Anchor Link

Installing any burgee package installs that package and the burgee packages it depends on, and nothing else. Each package below was installed alone into an empty directory, offline, from the tarballs npm pack builds from this repository, and its tree listed with npm ls --all --parseable.

Generated by npm run install-graph from an offline install of each package alone, from the tarballs npm pack builds; do not edit by hand.

• Every installed package is a burgee package. The one exception the check allows is an optional peer a family package declares: controlroom/ink renders through the program's own react and react-reconciler, which npm does not install unless the program asks for them. Held by install-graph-lock, which also requires the table above to equal a fresh measurement.
• Nothing runs at install time. No installed package declares a preinstall, install or postinstall script, or ships a binding.gyp, which npm would build without a script asking it to. Held by the same lock, reading the manifests as they land in node_modules.
• Each package loads alone. Every entry in each package's exports map is imported from that install, and no import reaches a package it does not declare. Held by independence-install-lock.
• The dependency counts in the READMEs match the manifests. Held by dependency-claim-lock. The direction of every edge is on The family.

burgee parses argv with Node's own util.parseArgs, so the tokeniser a program depends on ships with Node rather than with a package.

How a release is publishedCopy Anchor Link

• Trusted publishing, with no npm token. Every package is published from the release.yml workflow through npm trusted publishing (OIDC). No workflow names an npm token, and the publish job reads no secret but GITHUB_TOKEN. Held by trusted-publishing-lock.
• SLSA provenance on every version. The publish runs with --provenance, held by the same lock. To verify a version yourself, run npm view burgee dist.attestations for the registry's attestation, or npm audit signatures in a project that installs it.
• An SBOM on every GitHub Release. The release workflow attaches a CycloneDX SBOM of what installing the package brings in, from the lockfile with development, optional and peer dependencies left out. Held by the same lock. Attaching it is a separate step after the publish: if it fails, the release workflow logs a warning and the npm publish stands.

Security postureCopy Anchor Link

• Reporting. SECURITY.md says how to report a vulnerability privately and which versions are supported. Its supported versions are read against the manifests by stable-status-lock.
• OpenSSF Scorecard. Scorecard runs weekly from scorecard.yml. It scored this repository 7.1 of 10 on 2026-10-10; the badge on the README is the live figure. Four checks scored 0: Maintained, Code-Review and CII-Best-Practices, which SECURITY.md explains no file in the repository can close, and Contributors. Vulnerabilities scored 1 of 10. It reads the repository's lockfile, which holds the development tooling; the table above is what an adopter installs. The same question is now asked daily, and on every pull request that changes the lockfile or a manifest, by check:osv, which queries OSV for every locked package. One advisory with no fixed release, in a development tool, is waived until 2026-11-30, and the decision says why.

Licence and continuityCopy Anchor Link

• MIT, every package. The repository is under the MIT licence, and every installed package's manifest declares MIT, held by install-graph-lock.
• One repository. All ten packages are built, tested and released from one repository through one release workflow, so a fork of that repository is a fork of the whole family.
• A fork keeps its conformance tests. Each incumbent's own test suite is vendored under packages/compat-oracle/vendor and run in CI against the drop-in path by compat.yml, which fails below the committed baseline. A fork inherits those suites and that gate, so a change that alters behaviour the incumbent's tests pin fails there, in the fork's own CI. The rates are on Compatibility.