Documentation
Every packaged system ships the same documentation set. There is no separate docs site to fall out of date: the README in the package is the documentation, and the tests are the specification.
What every README contains
- Outcome — what changes in your pipeline once it is wired in
- Intended user, and an explicit not for list
- Requirements and supported platforms
- File structure, setup and a configuration example
- Validation command and a sample input and output you can reproduce
- Known limitations — written to be believed, not to reassure
- Failure handling and rollback
- Security notes, version and update policy, licence, support boundary
Per-system documentation
| System | README | Changelog | Validation |
|---|---|---|---|
| Truth Gate | README.md | CHANGELOG.md | npm test · 14 tests |
| Duplicate Guard | README.md | CHANGELOG.md | npm test · 16 tests |
| Attribution Contract | README.md | CHANGELOG.md | npm test · 18 tests |
Running the tests
Every package uses the Node standard-library test runner. There is nothing to install.
cd <package>
node --test test/*.test.mjsEach package also has a check script that runs its CLI over the shipped
example files. Two of the three deliberately exit non-zero, because the examples are
written to fail — that is how you confirm the gate is actually gating.
Support boundary
These packages are provided as-is. The README and the tests are the support. There is no SLA, no installation service, no configuration consulting included, and no guarantee that a heuristic catches every case your pipeline can produce.