13 KiB
B1 / D4 — skal nav-golden-klassen ha en normativ referanse?
Status: AVGJORT OG UTFØRT 2026-07-31 — operatøren valgte O1 (form C: informativ kataloglenke
fra README.md). Utført i samme økt; se §5.1. Underlaget under står uendret som grunnlaget
vedtaket ble tatt på.
Opprinnelig status: operatør-spørsmål. Dette dokumentet endrer ingen normativ tekst og foreslår ingen. Det svarer på det commons kan svare på uten å foregripe en ratifisering: hva som allerede er avgjort, hva tilstanden er i dag (fil + linje), hvilke referanseformer specen faktisk har, og hva hver av dem koster å ta i bruk her.
Grunnlag: commons HEAD 29ad8ca. Normativ spec-tekst uendret siden 9801d35
(method-spec) / bfa5a9b (ingest-spec), fixturene siden b641741 — alle 2026-07-21. Alle
linjeankere under er lest fra HEAD, ikke gjengitt fra hukommelse.
Avgrensning: dette er commons' eget punkt. Det står utenfor amendment-pakken
(portfolio-optimiser bekreftet 2026-07-25 at B1 ikke har adferds-interesse oppstrøms), og
ingen venter på oss. Det kan avgjøres når som helst, også etter pakken.
1. Det som allerede er avgjort — ikke oppe til vurdering
D4 fra OKF-runden, ratifisert i trinn F 2026-07-21, deler arbeidet i to:
- commons eier nav-golden-bundleklassen og det forventede utfallet, og leverer den inn.
- catalog eier korpus-containeren, de adversarielle aksene og runner/gate.
llm-ingestion-okf bekreftet 2026-07-25 04:19Z at klassen aldri var deres, og at beskrivelsen
matcher D4. Commons-halvdelen er levert i b641741:
| Case | Innhold | Rolle |
|---|---|---|
examples/nav-golden-hierarchy/ |
bundle/ (nestet a/b/, c/orphan.md), expected-read-context.md, README.md |
positiv: ni Q3-beslutninger utøves |
examples/nav-golden-escape/ |
bundle/, expected-read-context.md, README.md, SHOULD-NOT-BE-READ.md |
negativ: porten må kunne gå rød |
Splitten, eierskapet og fixturenes innhold er altså ikke spørsmålet. Spørsmålet er hva spec-teksten sier om dem — i dag: ingenting.
2. Tilstanden i dag, verifisert
Ingen normativ fil nevner klassen. Ikke «få treff» — null, i hver enkelt:
| Fil | grep -c 'nav-golden' |
|---|---|
method-spec.md |
0 |
ingest-spec.md |
0 |
CONCEPT.md |
0 |
README.md |
0 |
skills/expert-reviewer/SKILL.md |
0 |
Fixturene er dermed i dag rene artefakter: de finnes, de er dokumentert i sine egne
README.md-filer, og ingenting utenfor katalogen deres viser til dem.
Merk om sjekken: grep -rn 'nav-golden' *.md gir i dag 3 treff, alle i STATE.md
(LOCAL-ONLY, gitignored, ikke-normativ). Underlagets verifiseringslogg
(2026-07-25-amendment-underlag.md:350) noterte «0 treff» på nettopp den kommandoen, og den
reproduserer ikke lenger. Påstanden er uendret sann — sjekken var for vid. Korrigert i samme
commit som dette dokumentet.
3. Specen har tre referanseformer, ikke én
Dette er kjernen, og grunnen til at spørsmålet ikke er binært. «Normativ referanse» er ikke én ting i dette repoet — tre distinkte former er allerede i bruk, med forskjellig bindingskraft:
| Form | Hvor den er brukt | Hva den binder | |
|---|---|---|---|
| A | Artefaktnavn som fasit | method-spec §7 :332-333: «The shared example bundle ships two JSON files that are the only ground truth ("fasit") … Implementations MUST consume them unchanged» |
navngir validator-input.json / golden.json; konformans-krav på verdiene |
| B | Katalogkonvensjon + oppføringstabell | ingest-spec §11 :259-267: «Golden extraction format: one directory per case, convention examples/ingest-golden-{source type}/» + tabell over påkrevde oppføringer |
navngir et format for en case-klasse, ikke enkeltcaser |
| C | Informativ kataloglenke | README.md:19 — examples/bygg-energi-mikro/, beskrevet som «a small dev fixture» |
oppdagbarhet; null konformansvekt |
nav-golden har i dag ingen av de tre. Det er den presise mangelen — skarpere enn «0 treff».
En egenskap ved method-spec som begrenser opsjonsrommet: den navngir aldri en katalogsti
i repoet. grep -c 'examples/' → 0, grep -c 'bygg-energi-mikro' → 0. Den navngir filnavn
(validator-input.json, golden.json, test_okf.py) og aldri hvor de bor. De ti
/-holdige tokenene i filen er lenke-syntaks inne i en bundle (sub/index.md, /a/b.md),
ikke repo-stier. En form B-referanse i method-spec ville være den første repo-stien i det
dokumentet.
4. Spørsmålet
Skal nav-golden-klassen gis en normativ referanse, og i så fall i hvilken form?
Underspørsmål som følger med, uansett svar: hvis klassen blir normativ, må serialiserings- sammenligningen pinnes? (Se O2 og O3 under — det er den ene konsekvensen som ikke er kosmetisk.)
5. Opsjonene, med målt kostnad
| Opsjon | Berørt tekst | Frossen tekst endres? | Reverserbar | |
|---|---|---|---|---|
| O0 | Forbli informativ fixture (status quo) | ingen | nei | — |
| O1 | Form C: lenke fra README.md |
README.md:19-blokken |
nei (README er ikke normativ) | trivielt |
| O2 | Form B: katalogkonvensjon i method-spec §11 | ny avsnitt/rad ved :425 |
ja, tillegg | middels |
| O3 | Form A: løft til fasit i §7 | §7:332-333 og §1:23 |
ja, omskriving av tellende påstand | dyrt |
O0 — forbli informativ fixture
Ingen endring. Fixturene er fortsatt levert, catalog kan fortsatt bygge runner/gate på dem,
og D4s commons-halvdel er fortsatt oppfylt (D4 krevde levering, ikke normativ referanse).
Kostnaden er at bindingen mellom §11-raden :425 og beviset for den bare finnes i catalogs
runner og i fixturenes egne README-er — ingen spec-tekst sier at de hører sammen.
O1 — form C, lenke fra README
Billigst mulige forbedring av oppdagbarhet. README.md er katalog, ikke kontrakt, så ingen
implementasjon får en ny plikt. Løser ikke bindingsproblemet i O0; gjør det bare synlig.
O2 — form B, katalogkonvensjon i method-spec §11
Den formen som passer klassen best: en nav-golden-case er en formatklasse (bundle/ inn,
expected-read-context.md ut), akkurat som ingest-golden er det. Naturlig plassering er ved
Navigation boundary-raden :425, som i dag beskriver rød-betingelsen og siterer
referansetesten test_okf.py (navigation boundary), men ikke navngir noe korpus som beviser
den.
Tre konkrete kostnader, alle verifisert:
- Første repo-sti i method-spec (se §3). Enten aksepteres det som et bevisst brudd, eller så må konvensjonen formuleres uten sti — og da mister den det meste av verdien.
- Oppføringstabellen blir ikke uniform. ingest-goldens tabell (
:262-267) har fire påkrevde oppføringer og ingen valgfrie. nav-golden-casene har ulike oppføringssett: escape-casen trengerSHOULD-NOT-BE-READ.mdsom bevisst ligger utenforbundle/(den er lokkematen../SHOULD-NOT-BE-READ.mdpeker på), hierarchy-casen har ingen slik fil. En felles konvensjon må derfor ha en valgfri rad — noe ingest-golden ikke har presedens for. - Serialiseringen er ikke pinnet. Dette er den reelle.
nav-golden-hierarchy/README.mdsier eksplisitt: «The spec does not pin whitespace beyond this shape; a gate MAY compare byte-exact or after trailing-whitespace normalization.» ingest-goldens motstykke er pinnet::267«compared file by file, byte for byte» og §11-raden:280«any byte … diverges». Gjør man nav-golden normativ i form B uten å ta stilling, arver klassen enMAYder søsterklassen har enMUST— to konforme porter kan da være uenige om samme fixture. Enten pinnes sammenligningen, eller så uttalesMAY-en som bevisst.
O3 — form A, løft til fasit i §7
Dyrest, og kostnaden er ikke størrelsen på diffen, men at to tellende påstander må skrives om:
§7:332-333: «The shared example bundle ships two JSON files that are the only ground truth» — «two» og «the only» er begge usanne i det øyeblikket en tredje ground truth finnes. I tillegg er setningen scoped til én bundle («the shared example bundle»), mens nav-golden-casene er andre bundler.§1:23, konformansledd 2: «reproduces the shared golden suite's decided outcomes (§7) on the shared example bundle» — samme entallsbinding, i selve konformansdefinisjonen.
O3 er altså ikke et tillegg, men en utvidelse av hva «fasit» betyr i denne specen, fra én
bundle til en mengde. Det er en reell arkitekturbeslutning, ikke en redaksjonell.
Serialiseringspoenget fra O2 punkt 3 gjelder her med full tyngde: en fasit med en MAY i
sammenligningsregelen er ikke en fasit.
5.1 Svaret, og hva som faktisk ble gjort (2026-07-31)
Vedtatt: O1 — form C. Én oppføring i README.mds «Contents (growing)»-liste, i samme form
som examples/bygg-energi-mikro/ på :19, som lenker begge casene og peker på deres egne
README.md-filer for detaljene.
Frossen tekst er ikke rørt, og klassen har ikke fått bindingskraft. Verifisert etter
endringen: grep -c 'nav-golden' gir fortsatt 0 i method-spec.md, ingest-spec.md,
CONCEPT.md og skills/expert-reviewer/SKILL.md. Bare README.md gikk fra 0 til treff, og
README er katalog, ikke kontrakt (§3, form C: «oppdagbarhet; null konformansvekt»). Ingen
implementasjon har fått en ny plikt. git status viste README.md som eneste endrede fil.
Oppføringen sier eksplisitt at den er informativ, og at sammenligningsregelen ikke er pinnet — nettopp for å hindre den ene misforståelsen O1 kunne skapt: at en lenke fra rot-README gjør klassen til fasit i den forstand method-spec §7 bruker ordet.
Det O1 med vilje IKKE løser (uendret fra §5s beskrivelse): bindingsproblemet i O0 står. Ingen
spec-tekst sier at §11-raden :425 og disse fixturene hører sammen — O1 gjør mangelen synlig,
ikke borte. Å lukke den krever O2/O3 og en ratifiseringsrunde.
Serialiseringsspørsmålet er fortsatt åpent, og er uavhengig av dette vedtaket (§6): to implementasjoner som sammenligner ulikt vil være uenige om nav-golden enten specen nevner klassen eller ikke. Det kan avgjøres separat og tidligere, og O1 verken løser eller foregriper det.
6. Hva commons vil peke på (ikke en anbefaling)
Én asymmetri er verdt å ha for hånden når spørsmålet avgjøres: O0 og O1 er reverserbare, O2 og O3 er det ikke på samme måte. Frossen tekst i dette repoet endres bare ved ratifisering, og en normativ referanse som senere skal fjernes koster en ny runde. Motsatt koster det ingenting å utsette O2/O3 — fixturene er levert, catalog kan bygge på dem uansett, og ingen implementasjon blokkeres av at referansen mangler.
Serialiseringsspørsmålet (O2 punkt 3) er derimot uavhengig av om referansen kommer: to implementasjoner som sammenligner ulikt vil være uenige om nav-golden enten specen nevner klassen eller ikke. Det kan avgjøres separat, og tidligere.
7. Det som ikke er commons' å avgjøre
- Runner og gate — catalogs eierskap per D4. Om porten sammenligner byte-eksakt eller normalisert er catalogs implementasjonsvalg inntil specen pinner det; da blir det vårt.
- De adversarielle aksene og korpus-containeren — catalog.
- Ingenting her berører amendment-pakken. Køpunkt 1–7 i
2026-07-25-amendment-underlag.mdstår uendret.
8. Det som ikke endres uansett utfall
Fixturene selv. b641741 er levert og korrekt, og ingen av opsjonene over foreslår å røre
bundle/, expected-read-context.md eller case-README-ene. Spørsmålet gjelder utelukkende
om — og hvordan — spec-teksten viser til dem.
Verifiseringslogg
| Påstand | Sjekk | Resultat |
|---|---|---|
| Fixturene levert 2026-07-21 | git log --oneline -- examples/nav-golden-* |
b641741, eneste commit |
| Ingen normativ fil nevner klassen | grep -c 'nav-golden' per fil |
0 / 0 / 0 / 0 / 0 |
| Den siterte sjekken reproduserer ikke | grep -rn 'nav-golden' *.md |
3 treff, alle STATE.md |
| method-spec navngir ingen repo-sti | grep -c 'examples/' method-spec.md |
0 |
| method-spec navngir ikke fasit-bundelen | grep -c 'bygg-energi-mikro' method-spec.md |
0 |
/-tokenene er lenke-syntaks, ikke stier |
grep -oE '\[^`]/[^`]`' method-spec.md`, alle 10 lest |
sub/index.md, /a/b.md, ./a.md, / |
| §7 sier «two» og «the only» | method-spec.md:332-333 |
ordrett sitert over |
| §1 binder konformans til én bundle | method-spec.md:23 |
«on the shared example bundle» |
| §11-raden navngir ingen fixture | method-spec.md:425 |
seam + rød-betingelse + test_okf.py |
| ingest-golden er en katalogkonvensjon | ingest-spec.md:259-267 |
«one directory per case, convention …» + 4-rads tabell |
| ingest-golden er byte-pinnet | ingest-spec.md:267, :280 |
«byte for byte» / «any byte … diverges» |
| nav-golden er IKKE byte-pinnet | examples/nav-golden-hierarchy/README.md:31-33 |
«a gate MAY compare byte-exact or after … normalization» |
Escape-casen har fil utenfor bundle/ |
ls examples/nav-golden-escape/ |
SHOULD-NOT-BE-READ.md er søsken av bundle/ |
| README er eneste kataloglenke | grep -n 'examples/' README.md |
:19, bygg-energi-mikro |
| B1 = D4, ikke okf-eid | ~/.claude/coord/portfolio-optimiser/archive/20260725T041948Z-* |
okf: «never owned here; it is D4» |
| Spec-tekst uendret siden 07-21 | git log --oneline -- method-spec.md ingest-spec.md |
9801d35 / bfa5a9b |