1
0
Fork 0

docs(plan): the v1.0 gate rested on okf's old pin, and its file list on four surfaces

TWO STALE PREMISES IN THE SAME SECTION, BOTH NOW MEASURED

1. The pin. Session G's gate was written against okf pinning the guard
   `>=0.2,<0.3` with `[tool.uv.sources]` tag `v0.2.0` — true when written
   (their HEAD 4ea00a9), and the whole reason the gate says a green answer
   proves nothing: `<0.3` excluded the versions the fixtures were meant to
   exercise, so uv resolved v0.2.0 and came back green for free.

   Read from their pyproject.toml today, not from their coord message: they are
   on `>=0.3,<0.4` with tag `v0.3.4`. That inverts the consequence — an
   unchanged tree now resolves v0.3.4, which is inside what the gate asks for,
   so the null result is gone.

   Two things follow and neither is settled here. `<0.4` excludes 0.4.0 and
   0.5.0, so the axis separation and the input-cap refusal are outside anything
   okf can measure today. And the gate says "passes against guard 0.3.1" while a
   run today measures 0.3.4 — whether that counts as satisfied is an operator
   decision, deliberately not taken. The transitive-arrival bullet is corrected
   the same way: an accidental consumer lands on v0.3.4 now, not v0.2.0.

2. The file list. It named four release surfaces. The 0.5.0 sweep found five
   more carrying a version claim that no release had ever touched — and one of
   those five was `**Status:** v0.3`, which this very line already named, and
   0.4.0 missed anyway. Writing down a trap is not applying it.

   Replaced with the nine current-state surfaces, plus the rule that made the
   sweep safe: sort every hit into current-state or measurement provenance
   BEFORE editing, because a version sweep also hits "verified identical on
   0.2.0 and 0.3.1" and bumping that falsifies the record. So it can never be a
   sed pass.

   The key-assumption test went with it. "grep all four files" presupposed the
   list it was supposed to verify. It is now a git grep over all tracked files
   with each hit classified, plus `git show <pre-tag-sha>:README.md` — the check
   that proves what the tag will carry, run while the tag does not yet exist.
   That ordering is the fix; v0.4.0 verified afterwards and carries a stale
   README permanently as a result. SECURITY.md gets a note that at 1.0.0 its
   sentence is rewritten, not bumped: "pre-1.0" stops being true.
This commit is contained in:
Kjell Tore Guttormsen 2026-08-11 06:46:29 +02:00
commit 0dce50fb05

View file

@ -241,13 +241,22 @@ Nøkkelantakelser (+ test) · Verifisering. Testkommando alltid:
de øvrige (ms-ai-architect bygde sitt eget, `okr` er operatør-parkert).
- **⚠️ GATEN KAN IKKE ÅPNES AV ET GRØNT SVAR ALENE — verifiser hvilken versjon som ble
resolvet (funnet 2026-07-25, premiss-verifisering).** Setningen «v0.4.0 kjører grønt
mot v0.3.1» var skrevet mot en pin vi ikke hadde lest. okf pinner guarden
`>=0.2,<0.3` i `[project].dependencies` **og** `[tool.uv.sources]`-taggen til
`v0.2.0` — verifisert på deres `v0.4.0`-tag OG deres HEAD (`4ea00a9`). `<0.3`
ekskluderer både 0.3.0 og 0.3.1. Kjører de fixturene på et uendret tre, **feiler det
ikke** — uv resolver v0.2.0, constrainten er tilfredsstilt, og fixturene kommer
grønt tilbake fordi v0.2.0 aldri hadde regresjonen. Et grønt svar er dermed det
ENESTE utfallet som intet forteller og ser ut som det forteller alt.
mot v0.3.1» var skrevet mot en pin vi ikke hadde lest. Den gang pinnet okf guarden
`>=0.2,<0.3` i `[project].dependencies` og `[tool.uv.sources]`-taggen til `v0.2.0`
(verifisert på deres `v0.4.0`-tag og HEAD `4ea00a9`). `<0.3` ekskluderte både 0.3.0
og 0.3.1, så et grønt svar var det ENESTE utfallet som intet forteller og ser ut som
det forteller alt.
**OPPDATERT PREMISS (2026-08-11, lest fra deres `pyproject.toml`, ikke fra en
coord-melding):** okf står nå på `dependencies = ["llm-ingestion-guard>=0.3,<0.4"]`
og `[tool.uv.sources]`-tagg `v0.3.4`. Det snur konsekvensen: en kjøring på et
uendret tre resolver nå **v0.3.4**, som ligger *innenfor* det gaten ber om, ikke
utenfor. Nullresultatet over er dermed borte — men to ting følger, og ingen av dem
avgjøres her:
- `<0.4` ekskluderer 0.4.0 **og** 0.5.0. Aksesplittelsen (`Risk`/`action_map`) og
input-cap-refusjonen er per definisjon utenfor enhver måling okf gjør i dag.
- Gaten er formulert som «passerer mot guard 0.3.1», og en kjøring i dag måler
0.3.4. Om det teller som oppfylt er en **operatørbeslutning**, ikke en
premissoppdatering, og den er bevisst ikke tatt i denne økten.
**Gate-kravet, presist formulert (okf spurte rett ut 2026-07-25 — svaret er låst):**
gaten krever at **fixture-settet passerer mot guard 0.3.1**, med den resolvede
versjonen lest fra `importlib.metadata` ved kjøretid og oppgitt i resultatet. Gaten
@ -260,19 +269,45 @@ Nøkkelantakelser (+ test) · Verifisering. Testkommando alltid:
direkte fra `v0.3.1`-taggen, resolved versjon assertert) tilfredsstiller gaten.
- **Transitiv ankomst teller IKKE som integrasjon** (portfolio-optimisers innsikt,
2026-07-25). okf v0.4.0 gjør guarden til en OBLIGATORISK runtime-dep, så en
konsument kan få oss i grafen uten å velge oss — og i dag lander de da på v0.2.0,
uten 0.3.0-hardningen og uten 0.3.1-fiksen. Stille under-forsvar, ikke brudd. En
konsument kan få oss i grafen uten å velge oss — og lander da på det okfs pin
slipper inn, i dag v0.3.4 (var v0.2.0 da dette ble skrevet), altså uten
aksesplittelsen og uten input-cap-refusjonen. Stille under-forsvar, ikke brudd. En
konsument som fikk oss ved uhell måler ingenting med hensikt; grønt derfra beviser
mindre enn rødt fra en som valgte oss.
- **Filer:** `pyproject.toml` (`version = "1.0.0"`, `Development Status :: 3 → 5 -
Production/Stable`); `README.md` badge + **`**Status:** \`v0.3\`, alpha`-linjen** +
**install-pinnen `@v0.3.1`**; `__init__.py` `__version__`; `CHANGELOG.md`.
- **Filer — NI current-state-flater, ikke fire (korrigert 2026-08-11).** Denne
linjen listet fire, og 0.5.0-sveipet fant at fem til bar et versjonsutsagn ingen
release noensinne hadde rørt. Én av dem sto allerede navngitt her (`**Status:**`-
linjen) og ble likevel oversett i 0.4.0 — å føre en felle er ikke å anvende den.
- `pyproject.toml` (`version`, + `Development Status :: 3 → 5 - Production/Stable`)
- `src/llm_ingestion_guard/__init__.py` (`__version__`)
- `README.md`: badge, `**Status:**`-linjen, install-pinnen
- `SECURITY.md`: «pre-1.0 (`0.x.x`, alpha)» — den ENESTE med konsekvens for en
utenforstående, siden den navngir støttevinduet. Ved 1.0.0 skal setningen ikke
bumpes, den skal **skrives om**: «pre-1.0» er ikke lenger sant.
- `docs/BRIEF.md` og `CLAUDE.md`: status-linjen (sistnevnte også modultallet)
- `docs/ADOPTION-BRIEF.md`: status-linjen, «As of `vX.Y.Z`»-linjen, testtallet
- Forge-beskrivelsen: ingen versjon, men ≤180 kodepunkter — verifiser mot API-et.
**Sorteringen kommer FØR første redigering, og den er ufravikelig:** et sveip etter
versjonsstrengen treffer også *målingsproveniens* («New in v0.4.0», «verified
identical on 0.2.0 and 0.3.1», «measured against the v0.3.1 tag», hver «post-0.4.0
tree» i LIMITATIONS). De skal ALDRI bumpes — det falsifiserer journalen i stedet for
å oppdatere den. Derfor kan dette ikke være et `sed`-sveip.
**NB — entryen kan ikke lenger «liste A-F»:** A/A2/B ligger allerede ute under
`[0.3.0]`. `[1.0.0]` skal referere `[0.3.0]` + `[0.3.1]` for atferdsendringene og selv bære
frysepunktet (API-stabilitet + det integrasjonen beviste), ikke gjenta dem.
- **TDD-plan:** ingen ny test; hele suiten grønn er release-gaten.
- **Nøkkelantakelser (+ test):** *«alle versjonsreferanser er synkrone.»* Test:
grep alle fire filer for versjonsstreng, bekreft `1.0.0` overalt.
- **Nøkkelantakelser (+ test):** *«alle versjonsreferanser er synkrone.»* Testen
«grep alle fire filer» holdt ikke — den forutsatte listen den skulle verifisere.
Erstattet av to sjekker som gjøres FØR taggen finnes (rekkefølgen er poenget —
v0.4.0 verifiserte etter, og bærer derfor feil README permanent):
1. `git grep -n -E 'v?0\.[0-9]+(\.[0-9]+)?'` over ALLE sporede filer, hvert treff
klassifisert current-state eller proveniens. Ingen current-state-treff igjen
som ikke sier `1.0.0`.
2. `git show <pre-tagg-sha>:README.md` — den beviser hva taggen kommer til å bære.
En vellykket install fra sha-en beviser bare at pakken bygger; teksten er en
annen påstand. Begge kjøres, i den rekkefølgen, og taggen settes etterpå.
Etter taggen: kjør install-blokka **ordrett slik README-en trykker den** (anonym
https mot `open/`-speilet, mot `@v1.0.0`) — det er kommandoen en fremmed utfører.
- **Verifisering:**
- `PYTHONPATH=src .venv/bin/pytest` → alle grønne.
- `grep -rn "1\.0\.0" pyproject.toml README.md src/llm_ingestion_guard/__init__.py CHANGELOG.md` → treffer i alle fire; `grep -rn "0\.3\.0" …` → ingen dangling ref utenfor CHANGELOG-historikken.