docs(plan): V1 §4.1 — serialiseringsformen er bundet av :158, så 6 sider er invariant

portfolio-optimiser-claude reiste samme spørsmål to ganger (deres 15:14:41Z
og 15:19:19Z, sistnevnte etter å ha krysset O2-varselet vårt): binder §4.1
inline flow normativt, eller er serialiseringen implementasjonsvalg? De målte
at forskjellen er 6 mot 7 sider hos dem, fordi ordens-testens slice er
lines[1 : lines.index("---", 1)] — hele frontmatter-blokken, ikke toppnivå-
nøklene. Under blokk-form havner '  by' og '  at' i nøkkel-lista og bryter
likheten mot sju-nøkkel-lista.

Målingen deres er reprodusert i resonnementet og står — men spørsmålet er
allerede avgjort av frossen tekst:

  ingest-spec.md:158  «All values MUST be single-line»

Verifisert lest fra HEAD: setningen står i §5s frontmatter-punkt, altså
punktet som definerer det påkrevde ordnede prefikset `generated` ligger i, og
den har stått uendret siden bfa5a9b. Blokk-form er per definisjon flerlinjes
og dermed allerede ikke-konform — ikke som følge av O2, men som følge av en
MUST som har vært i kraft hele tiden. Inline flow er den eneste konforme
serialiseringen.

Konsekvens ført i §4.1:
- 6 sider er INVARIANT, ikke betinget. Den betingede 7-raden beskriver en form
  specen ikke tillater.
- V1 skal IKKE binde formen — det ville vært å vedta noe som allerede gjelder.
  Ingen ny kontraktslinje; :152 og :309 overlever fortsatt.
- Samme klasse som D-B: et spørsmål som ser åpent ut, men er avgjort av tekst
  som allerede er frossen.

Funnet under funnet, som ingen av oss så: målingen viser at
test_provenance_keys_are_in_the_spec_order i praksis er en søm på
:158-konformitet — den går rød nøyaktig når noen bryter single-line-regelen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017dEaxg1rhRsAchm67jLUvU

docs/plan/2026-07-26-v1-generated-felt-okf-v0.2.md

@@ -166,6 +166,28 @@ V1 hører hjemme i `2026-07-25-amendment-underlag.md`s kø ved ratifisering.
 vedtatt, så plikten er live og forfaller ved deres neste fikstur-frys — ikke ved vår utførelse.
 Varslet sendt 2026-07-31, samtidig som dette føres.
 
+**Serialiseringsformen er BUNDET, og ikke av dette vedtaket** (tilført 2026-07-31 etter at
+`portfolio-optimiser-claude` og deres måling reiste spørsmålet to ganger). Begge spurte om §4.1
+binder inline flow normativt eller lar serialiseringen være implementasjonsvalg — forskjellen er
+6 mot 7 sider hos dem. **Svaret er at spørsmålet allerede er avgjort av frossen tekst, og at V1
+derfor ikke skal binde noe:**
+
+- `ingest-spec.md:158` (inne i §5s frontmatter-punkt, som definerer det påkrevde ordnede
+  prefikset `generated` ligger i): **«All values MUST be single-line»**. `MUST`, i kraft i dag,
+  uendret siden `bfa5a9b`.
+- Blokk-form er per definisjon flerlinjes. Den er derfor **allerede ikke-konform** — ikke som
+  følge av O2, men som følge av en regel som har stått hele tiden.
+- **Inline flow er den eneste konforme serialiseringen.** `generated: { by: …, at: … }` er
+  single-line og line-oriented, og oppfyller `:150` og `:158` slik §5 allerede slår fast.
+
+**Konsekvens: 6 er invariant, ikke betinget.** Den betingede raden (`O2, blokk-form → 7 sider`)
+beskriver en form specen ikke tillater. V1 trenger ingen ny kontraktslinje for å binde formen,
+og `:152`/`:309` overlever fortsatt. Samme klasse som D-B: **et spørsmål som ser åpent ut, men
+er avgjort av tekst som allerede er frossen.** Målingen deres er likevel verdifull, og av en
+annen grunn enn de sendte den: den viser at `test_provenance_keys_are_in_the_spec_order`
+faktisk er en søm på `:158`-konformitet — den ville gått rød hvis noen emitterte blokk-form,
+altså brøt `:158`. Det er en egenskap ingen hadde lagt merke til.
+
 **Konsument-kostnaden er kjent på forhånd** (§5.1, målt @ `8a14137`): **6 sider** hos
 `portfolio-optimiser-claude` — 4 byte-frosne fasit-blober + 2 verbatim likhets-assert. De 3
 navn/orden-sidene rører O2 **ikke** (ordens-testen bygger nøkkelen med `ln.split(":", 1)[0]`, som