docs(readme,security,contributing): meet the repo standard — 0 ERROR
The per-repo gate flagged four ERRORs and two WARNs. Fixed, in the order the work actually gets done in: MISSING - `## Honest limitations` -> `## Known limitations`, `## Out-of-scope (documented boundary)` -> `## Non-goals`. Both sections existed under names no reader or agent scans for; the contract wants predictable top-level headings. Pointers followed: the in-README anchor, SECURITY.md's out-of-scope preamble, CONTRIBUTING.md's scope section, and the consumer-facing docs/ADOPTION-BRIEF.md. Historical records (CHANGELOG, docs/PLAN.md, docs/OKF-INGESTION-BRIEF.md) keep the name they were written with. WEAKENING - README now opens with one line identical to the forge description, above the badges. That is the only place a machine can check description == README. - Forge description shortened 207 -> 178 codepoints (bound 180), and the same string written to pyproject's `description` so the fourth copy cannot drift. The tests badge is dropped, not updated. `tests-699_passing` as a static image is a claim dressed as evidence: there is no CI runner on this forge, so nothing verifies it. Replaced with the honest substitute in Install — the single command that runs the suite from a clean clone, stated together with the fact that nothing runs it automatically. Two WARNs deliberately left standing: - H1 `# llm-ingestion-guard` != repo name. The register itself records llm-ingestion-guard as "a package, not a repo"; the H1 names what you pip install. Renaming the repo is the operator's call, not this commit's. - The `Status` badge trips the same claim-badge regex, but `alpha` asserts maturity, not a run — the same reason version/license/platform are exempt. Measured false positive in the gate's classifier, reported upstream.
This commit is contained in:
parent
0add3e7e96
commit
0bf07295c2
5 changed files with 20 additions and 11 deletions
|
|
@ -59,7 +59,7 @@ The suite is the release gate: a change is not done until the whole suite is gre
|
|||
## Scope and honest limits
|
||||
|
||||
New detection is welcome, but the project ships its **limitations** as a control (see
|
||||
`README.md` → *Honest limitations*). If a change narrows a stated gap, update that
|
||||
`README.md` → *Known limitations*). If a change narrows a stated gap, update that
|
||||
section. If it introduces a new deliberate boundary, document it there rather than
|
||||
leaving a silent miss. Absolute claims ("catches all …", "cannot be bypassed") do not
|
||||
belong in this codebase.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue