ratchet

Repository on GitHub, which uses git. git is distributed.

https://github.com/thearchitect0x-glitch/ratchet/labels/good%20first%20issue - four tasks, each self-contained and carrying file paths and acceptance criteria: guard the per-file licence headers with a test, property-test normalizeText directly, fuzz the MCP JSON-RPC parser, and document which error codes are worth retrying. All four are real work identified during development, not tasks invented to satisfy this criterion.

GitHub requires 2FA as of March 2023. [osps_ac_01_01]

Two-factor authentication on the account that controls the repository, the deployment path and the npm publish workflow uses a TOTP authenticator application, not SMS. TOTP is a cryptographic mechanism and is the example this criterion names as meeting it; GitHub supports it directly. SMS was in use previously and was recorded here as unmet until it was replaced, because SMS is not encrypted and can be taken by SIM swap without access to any device the holder owns. That mattered more than the criterion: npm releases are signed with SLSA provenance generated by a workflow in this repository, so an attacker holding the account could have shipped artifacts carrying genuine, verifiable provenance.

https://github.com/thearchitect0x-glitch/ratchet/blob/main/docs/CODE_REVIEW.md documents what is checked automatically (full suite, property-based fuzzing, production dependency audit, CodeQL), what is checked by reading against the project contract in CLAUDE.md, what makes a change unacceptable, and the rule that a test must be broken on purpose and watched to fail before it is trusted. It also states plainly that review here is not two people agreeing, and why - see two_person_review, recorded unmet.

Enforced, not intended. main carries a repository ruleset with no bypass actors: a change reaches it only through a pull request carrying an approving review from somebody other than the last pusher (require_last_push_approval is on). It binds the maintainer too, which was confirmed by attempting a direct push and being refused rather than read off a settings page. What a reviewer checks: https://github.com/thearchitect0x-glitch/ratchet/blob/main/docs/CODE_REVIEW.md . The first change to go through the rule is the change that documents it: https://github.com/thearchitect0x-glitch/ratchet/pull/14 . Instituted 2026-09-05, so the proportion is 100% of proposed modifications from that date; the prior history of 3 reviewed of 247 commits is stated rather than claimed.

Two clean builds produce byte-identical output - 183 files, same manifest - and the output carries nothing specific to the machine that produced it. Source maps reference sources relatively with an empty sourceRoot, no file in dist contains the checkout's absolute path, TypeScript is pinned to an exact version, every Docker base image is pinned by digest, and npm ci resolves from a committed lockfile. Verified by a command rather than asserted: npm run verify:build, which runs in CI on every push and exits non-zero if two builds differ or if a source map references an absolute path. https://github.com/thearchitect0x-glitch/ratchet/blob/main/scripts/verify-reproducible.sh

GitHub Actions runs the full suite on every push: https://github.com/thearchitect0x-glitch/ratchet/blob/main/.github/workflows/ci.yml

90.87% statement coverage of src/, measured with c8 (FLOSS) across all three automated suites - unit, integration and end-to-end - against a disposable PostgreSQL database. npm run coverage reproduces it and fails below 90% statements, so the figure cannot drift beneath this claim without the build going red. Two earlier figures in this answer were wrong in opposite directions and both are worth stating: 85.68% counted the test files themselves in the denominator, and 80.01% then measured only unit and integration, leaving out the suite that covers the MCP handlers and the OAuth routes almost entirely.

81.56% branch coverage of src/, measured with c8 (FLOSS) across the unit, integration and end-to-end suites against a disposable PostgreSQL database. npm run coverage reproduces it and fails below 78% branches. Full measurement: 90.87% statements, 81.56% branches, 91.75% functions, 90.87% lines.

All network communication uses TLS. HSTS is set with max-age=31536000 and includeSubDomains, and outbound webhook delivery is https-only with private, loopback, link-local, CGNAT and metadata ranges refused.

TLS 1.2 or later, negotiated by the hosting platform; nothing older is offered.

A security review has been performed and written down rather than asserted: https://github.com/thearchitect0x-glitch/ratchet/blob/main/ASSURANCE_CASE.md . It states seven security requirements, the threat model including what is explicitly out of scope, the trust boundary and what crosses it, the secure design argument, and a table of common implementation weaknesses with the countermeasure and the test holding each one. The security boundary is the product's central claim: Ratchet performs no side effect itself, holds no vendor credential, and has no outbound access to customer systems. The review was performed by the maintainer - this criterion asks for a review considering the security requirements and boundary, not for an outside reviewer, and no outside reviewer is claimed.

The end-to-end suite exercises the built application over real HTTP against a real PostgreSQL database, and the deploy gate additionally runs a smoke test against the running staging build before any production release — a build that fails it is refused rather than promoted.

Assertions are enabled throughout the test suites, which run the application rather than mocking it. TypeScript strict mode and runtime JSON Schema validation act as always-on assertions at the API boundary in production too.