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:
parent
f669479777
commit
0dce50fb05
1 changed files with 49 additions and 14 deletions
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue