Basis CLI

Two ways in, both real. CONTRIBUTING.md has a "Good first tasks" section listing five kinds of contribution sized for someone new — covering a statement make coverage reports as missed, trying the script on a platform the project does not have, correcting documentation, improving an error message, and independently checking a published checksum by hand. And there are open issues labelled good first issue, each one a genuine defect or gap rather than invented busywork: download.sh not checking for curl before using it, testing the macOS shasum fallback on an actual Mac, documenting the three BASIS_CLI_* environment variables, and a test case for a checksum file with CRLF line endings. Each issue says what the task is, why it matters, and which file to start in. https://github.com/basis-network/basis-cli/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22

Two-factor authentication is required for every member of the basis-network GitHub organisation, enforced by the organisation setting rather than by asking people nicely — a member without 2FA is removed from the organisation by GitHub, so it cannot quietly lapse. That covers both things the criterion names, because both go through the same account: write access to this repository, and the private security advisory queue where vulnerability reports arrive. It is publicly verifiable: https://api.github.com/orgs/basis-network reports "two_factor_requirement_enabled": true.

CONTRIBUTING.md has a "How changes are reviewed" section stating how review is conducted and what must be checked, in order: is it correct and does the suite still pass; does it change behaviour without a test, which is a blocking comment; does it weaken a refusal, in which case it is read line by line against the assurance case and "looks fine" is explicitly not an acceptable review; do workflow changes keep least-privilege permissions and SHA-pinned actions; does every new file carry its SPDX header, decided by reuse lint rather than by opinion; and is the documentation still true afterwards. It also states the acceptance condition — all CI checks passing plus approval from a maintainer other than the author — and then states plainly that with one active maintainer this is not always possible today, rather than describing a process the project does not follow. https://github.com/basis-network/basis-cli/blob/main/CONTRIBUTING.md#how-changes-are-reviewed

No building occurs. This is a scripting-language project: download.sh and the test suite are read by the interpreter as they are, and the Makefile has no build target — only check, coverage and lint. There is no generated artefact whose bit-for-bit reproduction could be compared. Reproducibility of the compiled basis binary is a property of basis-core, which is not public and is outside this entry's declared scope; the assurance case lists the Windows build's missing provenance as a known gap rather than claiming otherwise.

make check. Shell has no de facto standard test runner, so the Makefile provides the conventional entry point; test/run.sh also runs directly, and make lint is its counterpart for shellcheck and reuse. https://github.com/basis-network/basis-cli/blob/main/Makefile

.github/workflows/test.yml runs make check on every push to main and every pull request, alongside shellcheck, reuse lint, a checksum-format check and CodeQL. All five are required status checks on main, so nothing merges without them. https://github.com/basis-network/basis-cli/actions/workflows/test.yml

98.1% statement coverage of download.sh, 52 of 53 statements, measured with bashcov rather than estimated. make coverage produces the figure and CI runs it as its own job on every push and every pull request, failing below a hard floor of 90%. The single statement reported uncovered is the done that carries the download loop's redirection, which bash attributes to the while; every case that downloads anything executes it. It is left in the report rather than special-cased, because a coverage tool taught to lie about one line stops being evidence about the others.

There is no FLOSS tool that measures branch coverage for shell, which is the condition the criterion attaches. The two coverage tools that work on bash — bashcov and kcov — both measure statements only; bashcov's branch-coverage support comes from SimpleCov and applies to Ruby, not to the bash it traces. Statement coverage is measured and enforced instead, at 98.1% against a 90% floor. If a branch-coverage tool for shell appears, adding it is on the roadmap and would go into CI the same way.