Merge commit '89e3ad8efe'

shared/docs/plan/2026-07-25-amendment-underlag.md

@@ -406,6 +406,23 @@ hvorfor: det finnes et ANDRE anker vi ikke siterte, og det er normativt.**
 > Et åpenbart tomt treff hadde vært tryggere. **Regel, samme klasse som `git log -S`-regelen
 > under: sitér SEKSJON + ORDRETT TEKST når mottakeren står på en annen ref — eller skriv
 > hvilken ref numrene gjelder.**
+>
+> **⚠️ Failure-moden er ikke lenger hypotetisk — den INNTRAFF (målt 2026-08-01).**
+> `portfolio-optimiser` stilte MCP-spørsmålet **på nytt** fem dager etter at det var avgjort
+> (`20260731T193214Z`), med S2.2 ført som blokkert på oss — nøyaktig utfallet avsnittet over
+> beskrev som «den mest sannsynlige konklusjonen». Kjennelsen var korrekt, allerede levert
+> (`20260726T190922Z`) og allerede ført her i §7.2; **det som ikke overlevde pull-grensen var
+> ankeret.** Svar sendt `20260801T175201Z` med begge refs oppgitt eksplisitt.
+>
+> To ting generaliserer, og de er verdt mer enn korreksjonen:
+>
+> 1. **Et feil linjeanker svikter STILLE.** Kostnaden er ikke at mottakeren blir forvirret —
+>    den er at mottakeren *rimelig* konkluderer at kjennelsen din hviler på løs grunn, og
+>    behandler et avgjort spørsmål som åpent igjen. Ingen av partene ser feilen; begge ser en
+>    uenighet som ikke finnes.
+> 2. **Et spørsmål som kommer TILBAKE er et signal om VÅR formidling, ikke om deres hukommelse.**
+>    Riktig første grep er ikke «det sa vi allerede», men å lese hva den forrige meldingen
+>    faktisk bar (`~/.claude/coord/<dem>/archive/`). Feilen lå der.
 
 `:29-31` sier at MCP-veien ikke krever spec-endring. `http`-punktet sier **normativt hvor den
 hører hjemme** — som en utvidelse av `http`-familien, med **MUST** på de samme kontraktene.

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

@@ -199,6 +199,71 @@ skal bære. O2 fastslår formen (`process:<id>`, som v0.2 §7 eksplisitt tillate
 navngir prosessen specen definerer. Selve id-en er en redaksjonell avgjørelse som tas når
 kontraktslinjene skrives, og bør avklares med `llm-ingestion-okf` i samme runde som pinnen.
 
+### 4.2 Pinnen, id-en og siteringen — avgjort 2026-07-31 (økt 4)
+
+`llm-ingestion-okf` svarte samme dag. Tre ting falt på plass, og ett premiss i §4.1 viste seg
+for svakt formulert. Grunnlaget over står ordrett uendret; dette er status, ikke omskriving.
+
+**Pinnen foreligger: `2504011`** — «feat(okf-v0.2): D5 — the v0.2 golden fixture, with
+`okf_version` in root frontmatter», pushet til `open/llm-ingestion-okf`. Det er en PIN, sagt
+eksplisitt som sådan. `6f42c10`/`ed08ac1` var siterte refs; skillet holdt.
+
+**Deres v0.2-fikstur var aldri rammet, og det er målt, ikke antatt.** Den bar O2-formen fra
+`c90171d` (07-27), vedtatt uavhengig av oss. Vår varsling traff et annet sett: de fire
+DEFAULT-profil-fasitene (`ingest-golden-{file,sql,http}`, alle `:8`), som er VÅRT lag å endre.
+
+**`<fast id>` = `process:okf-ingest`** (operatøren, 2026-07-31). Okfs eget forslag. De foreslo
+først `process:llm-ingestion-okf` og argumenterte samtidig mot den — riktig, og strengere enn
+de kunne se herfra:
+
+| Kilde | Ordrett | Frossen siden |
+|---|---|---|
+| `ingest-spec.md:8-9` | «The prose is framework-neutral by rule: it never names a concrete agent toolkit or vendor stack, and a guard test keeps it that way» | `7aa53fc` (07-03) |
+| `ingest-spec.md:7-8` | «implemented **from this spec alone** — without reverse-engineering any existing implementation» | `7aa53fc` |
+| `ingest-spec.md:282` (§11-seam «Spec integrity») | «this spec goes missing, **names a concrete agent toolkit**, or stops documenting a contract field» | `7aa53fc` |
+
+**Presisjonsforbehold, så raden ikke føres for sterkt:** `llm-ingestion-okf` er en
+ingest-implementasjon, ikke strengt tatt en «agent toolkit» — `:282` treffer derfor ikke
+ordrett. Det er `:7-8` som treffer uten tolkningsrom: å normere produsentens repo-navn ville
+tvunget enhver annen konform implementasjon til å skrive det navnet i sin egen output. Samme
+klasse som `:29` tvang O1 ut på, bare svakere. **Utelukkelsen holder, men på `:7-8`, ikke `:282`.**
+
+**Siteringen er IKKE normativ — formen er usitert.** Okf spurte om anførselstegnene i
+`by: "process:<fast id>"` var normative eller illustrative. **Spørsmålet er avgjort av frossen
+tekst — fjerde gang** (etter D-B, `:29`-vs-O1 og `:158`):
+
+- `method-spec.md:90` (frossen `7d2b46c`, 07-03): «Frontmatter is the leading `---`-delimited
+  block, **parsed line-oriented as `key: value` strings**».
+- Vi parser altså ikke YAML. Verdien ER den rå teksten etter `key: `. Det finnes ingen
+  transparent sitering i formatet: et anførselstegn er **et tegn i verdien**, ikke syntaks som
+  en parser fjerner. Normert sitat ⇒ predikatet måtte matchet anførselstegnene som datainnhold.
+- Målt bekreftelse: v0.3.2s port sammenligner mot **strengen** `"true"` (§3.1 `:100`), ikke mot
+  en boolean — nøyaktig fordi parsingen er line-oriented.
+- Oppstrøms er selv usitert **med kolon i verdien**: `by: human:jsmith@acme` (§3s empiri).
+
+Kanonisk form, vedtatt: `generated: { by: process:okf-ingest, at: <ingested_at> }`
+
+**⛔ KORREKSJON av §4.1: pin var ikke den siste gaten.** §4.1 skrev «Ingen frossen tekst endres
+før `llm-ingestion-okf` er pinnet til en commit». Det er en nødvendig, ikke tilstrekkelig
+betingelse, og formuleringen ville — lest alene — hjemlet å skrive de 5 linjene nå. Den er
+korrigert av avstemt tekst i søsterunderlaget:
+
+> `2026-07-25-amendment-underlag.md:495-496` — «vi forbereder underlaget, **operatøren
+> ratifiserer**, og **frossen tekst endres ikke uten den ratifiseringen**»
+
+Køens rad 8 er B1/D4 — **V1 står ennå ikke i køen**, slik §8 alltid har sagt («V1 er punkt
+nummer 8 *hvis den ratifiseres*»). Pin + id lukket gaten for at V1 kan gå I KØ; ratifiseringen
+er en separat, operatør-eid handling, og amendment-pakken er på bevisst hold. **`ingest-spec.md`
+står uendret på `bfa5a9b`; de 5 linjene bærer fortsatt literal `generated: true`.**
+
+**B1 er ikke presedens for det motsatte:** `8a7d430` rørte `README.md` («katalog, ikke
+kontrakt») og to planfiler — null normative filer. Commit-meldingen sier det selv om V1: «Ingen
+frossen tekst er rørt.»
+
+**Varslet til okf er sendt** (07-31, som svar på pinnen): id + siteringsform vedtatt, og et
+eksplisitt **ikke regenerer ennå** — regenerering mot ikke-ratifisert tekst ville pekt fasiten
+deres på en spec som ikke finnes. Varslingsplikten ved faktisk tekstendring står fortsatt live.
+
 ## 5. Opsjonene, med målt kostnad
 
 Kostnad er talt som **kontraktslinjer som må skrives om** av de 7 (`:34`, `:70`, `:82`, `:152`,
@@ -629,3 +694,88 @@ line-oriented-krav, og `ingest_manifest` som stempelets andre halvdel. Ingen ops
 | …altså ÉN commit bak, ikke to | `git rev-list --count 7aa53fc..HEAD -- ingest-spec.md` | **1** (`bfa5a9b`) |
 | MCP-ankeret finnes i den pinnede kopien | `git show 7aa53fc:ingest-spec.md \| grep -n "An MCP-based"` | `:101` — S2.2/S2.4-ugatingen henger ikke på en pull |
 | `:112-114` hos konsumenten er IKKE tomt | `git show 7aa53fc:ingest-spec.md \| sed -n '112,114p'` | felt-tabellen: `id` / `title` / `query` (`okf_type`/`max_rows` er `:115-116`) |
+
+**Tilført 2026-07-31 (økt 4 — pin, id, sitering, ratifiseringsgaten):**
+
+| Påstand | Sjekk | Resultat |
+|---|---|---|
+| Frontmatter parses som STRENGER, ikke YAML | `method-spec.md:90` | «parsed line-oriented as `key: value` **strings**» — derav er sitering datainnhold, ikke syntaks |
+| …og har vært frossen hele veien | `git log -1 -S 'parsed line-oriented as' -- method-spec.md` | `7d2b46c` (2026-07-03) — eldste spec-commit |
+| Prosaen er framework-nøytral ved regel | `ingest-spec.md:8-9` | «never names a concrete agent toolkit or vendor stack, and a guard test keeps it that way» |
+| …håndhevet som §11-seam | `ingest-spec.md:282` | «Spec integrity \| this spec … names a concrete agent toolkit …» |
+| …men `:282` treffer ikke okf ordrett | lesning: okf er ingest-impl., ikke «agent toolkit» | **utelukkelsen hviler på `:7-8`**, ikke `:282` — ført som forbehold, ikke som treff |
+| Commons har fortsatt INGEN aktørkonvensjon | `grep -n "human:\|process:\|by: " ingest-spec.md method-spec.md CONCEPT.md \| wc -l` | **0** (uendret fra 07-27) |
+| Spec-en kaller laget «ingest», prosessen «materialization» | `grep -io 'materializ[a-z]*' ingest-spec.md \| wc -l` + `:1`, `:18`, `:28` | 27 forekomster; tittel + §1 bruker «Ingest» som lagets navn → `okf-ingest` |
+| `ingest-spec.md` er URØRT | `git log --oneline -2 -- ingest-spec.md` | `bfa5a9b`, forrige `7aa53fc` — ingen commit i økt 3 eller 4 |
+| De 5 linjene er urørte — men bærer IKKE samme form | `grep -n '\`generated' ingest-spec.md` | **4 av 5** bærer `generated: true` ordrett (`:34`, `:70`, `:82`, `:275`). `:214` er §7-feltradstabellens rad («\`generated\` … Literally \`true\` — the machine-generated marker») og bærer ikke literalen. Se raden under |
+| …og `:214` er derfor IKKE en strengerstatning | O2-formen (`generated: { by: …, at: … }`) vs. radens «Literally `true`» | raden **beskriver feltets verdi**. Under O2 er verdien et objekt med `by`/`at`, så raden må skrives om (evt. splittes), ikke søk-og-erstattes. **Egen redigering, samme amendment** |
+| Frossen tekst krever RATIFISERING, ikke bare pin | `2026-07-25-amendment-underlag.md:495-496` | «operatøren ratifiserer, og frossen tekst endres ikke uten den ratifiseringen» |
+| V1 står ikke i køen | samme fil §9, rad 8 | rad 8 = **B1/D4**, ikke V1 — uendret fra 07-27 |
+| B1 rørte ingen normativ fil | `git show 8a7d430 --name-only` | `README.md` + 2 planfiler; **0** normative filer |
+| Pinnen er en pin, ikke en ref | okf-melding 07-31, `2504011` | sagt eksplisitt som pin; skillet fra `6f42c10`/`ed08ac1` holdt |
+| Deres v0.2-fikstur bar O2-formen allerede | okfs måling, `c90171d` (07-27) | **ført som DERES**, ikke reprodusert her |
+
+**Korreksjon 2026-07-31 (økt 6) — «de 5 linjene» er ikke homogene.** Raden «De 5 linjene bærer
+fortsatt literalen» påsto at alle fem bar `generated: true` ordrett. Det er feil, og planen
+motsa seg selv: §5.1 fører `:214` korrekt opp som «Literally `true`»-raden, og
+verifiseringstabellens egen `grep -n '\`generated'`-rad lister `:214` blant de 7 uten å skille
+form. Målt nå: `grep -n 'generated: true' ingest-spec.md` gir **4** treff (`:34`, `:70`, `:82`,
+`:275`) — ikke 5.
+
+Feilen var arvet ordrett inn i `STATE.md`s NESTE-blokk («skriv om de 5 kontraktslinjene … fra
+literal `generated: true`»). Konsekvensen er ikke kosmetisk: en økt som utfører V1 mekanisk
+etter den formuleringen finner 4 av 5 treff og står igjen med to like sannsynlige feiltolkninger
+— (a) drift i frossen tekst, eller (b) `:214` hoppes over, som etterlater **ærlighetsmarkørens
+§7-halvdel** (§3s ærlighetsmarkør-rad: «§1 `:34`, §7 `:214`») ukonvertert mens §1-halvdelen er
+O2. Tellingen «5 av 7» (§4.1, §5) står uendret — det var formen, ikke antallet, som var feil ført.
+
+*Ingen normativ fil rørt av denne korreksjonen; `ingest-spec.md` står fortsatt på `bfa5a9b`.*
+
+---
+
+## 10. RATIFISERT 2026-08-02 — og en andre tabellrad som økt 6 ikke fanget
+
+**Operatøren ratifiserte V1 2026-08-02**, ordrett: *«Jeg kan ta okf-kostnaden nå, men vi må
+starte i en ny sesjon.»* Utførelsen ligger dermed hos neste økt, ikke hos den som mottok
+vedtaket.
+
+**Begge gater er oppløst, og den andre falt av seg selv.** okf-gaten var lukket fra før (pin
+`2504011`, økt 4). Ratifiseringsgaten er nå gitt. Den tredje betingelsen som har ligget i
+STATE — at V1 skulle vente på §9-amendment-pakken — var aldri en gate i egen rett: den var
+**batching** mot at endringen utløser `llm-ingestion-okf`s regenerering av fire DEFAULT-fasiter.
+Når operatøren tar den kostnaden nå, har batchingen ingenting å batche mot. V1 er frikoblet fra
+pakken, og S2.3 (`{type: "doc"}`, spurt `20260802T191837Z`) endrer ikke utfallet.
+
+### Ankere re-målt 2026-08-02 (vår egen ferskvare-regel)
+
+| Sted | Seksjon | Ordrett i dag | Behandling |
+|---|---|---|---|
+| `:34` | §1 Scope | «such (`generated: true` plus a manifest reference, §7) everywhere it is presented.» | prosa — mekanisk |
+| `:70` | §3 Layer separation | «the ingest stamp (`generated: true` plus an `ingest_manifest` reference, §7) and MUST NOT» | prosa — mekanisk |
+| `:82` | §3 Layer separation | «ownership stamp — `generated: true` together with an `ingest_manifest` reference — while» | prosa — mekanisk |
+| `:214` | §7 Provenance | «\| `generated` \| Literally `true` — the machine-generated marker (§1 honesty rule). \|» | feltrad — skriv om/splitt |
+| `:275` | §11 Load-bearing | «\| Stamp integrity (curated writers) \| … the complete ownership stamp (`generated: true` with `ingest_manifest`) stops being rejected … \|» | **rød-betingelse** |
+
+### Korreksjonen: det er TO tabellrader, ikke én
+
+Økt 6 korrigerte «de 5 linjene» fra homogene til 4 + 1 og pekte ut `:214`. Re-målingen viser at
+korreksjonen selv var ufullstendig: **`:275` er også en tabellrad, og den står i §11s
+load-bearing-tabell.** Det er ikke prosa som beskriver stempelet — det er en **rød-betingelse i
+konformanskontrakten**. Å endre den endrer hva en konformant implementasjon må bevise, og er
+derfor en sterkere handling enn å redigere §1- og §3-prosaen.
+
+De «fire mekaniske» er i praksis **tre** (`:34`, `:70`, `:82`). `:214` og `:275` krever hver sin
+vurdering. `:152` og `:309` overlever (feltnavn, ikke literal).
+
+Dette er andre gang en verifiseringsrad i denne planen påsto homogenitet som ikke fantes. Regelen
+står: **sjekk hva linjene FAKTISK bærer — og hvilken tabell de står i — før noe føres som
+mekanisk.**
+
+### Varslingsplikt, utløst av utførelsen
+
+Endringen utløser den lovede meldingen til `llm-ingestion-okf` — den setter i gang deres
+regenerering av de fire DEFAULT-fasitene. Den sendes i **samme økt** som tekstendringen, ikke
+senere. `portfolio-optimiser-claude` varsles samtidig; de vet ennå ikke at id-en er
+`process:okf-ingest`.
+
+*`ingest-spec.md` er fortsatt urørt på `bfa5a9b` i det dette skrives.*

shared/docs/plan/2026-07-31-okf-versjonsakse-sjekk.md

@@ -0,0 +1,93 @@
+# Google OKF v0.2 — sjekken er utført, og hypotesen holdt ikke
+
+**Dato:** 2026-07-31 (økt 5) · **Status:** LUKKET, ingen melding sendt · **Marker:** `okf-second-brain-convention`
+
+STATE bar siden 07-27 en uverifisert observasjon som NESTE STEG: *«catalog bumpet 0.1→0.2 for å
+ikke være forvekslbar med Google OKF v0.1 — er Google nå på 0.2, kan avklaringen ha kollapset.»*
+Sjekken er nå gjort. **Avklaringen har ikke kollapset, og spørsmålet var feilstilt.** Tre av
+premissene i formuleringen viste seg å avvike fra ground truth.
+
+## 1. Google er på v0.2 — men det visste vi allerede
+
+Verifisert mot primærkilde: Google Cloud Blog, *«Open Knowledge format v0.2 tackles agentic
+trust»*, publisert **2026-07-25**.
+
+Men søket var strengt tatt overflødig. Svaret lå i vår egen arkiverte innboks, fem dager gammelt:
+`llm-ingestion-okf`, `20260726T114345Z`, første linje i brødteksten — ordrett **«OKF v0.2 er ute
+(2026-07-25).»** Hele V1-sporet er *bygget på* v0.2 (`generated`-feltets form etter v0.2; se
+`2026-07-26-v1-generated-felt-okf-v0.2.md`, og filnavnet sier det selv).
+
+**Dette er en STATE-defekt, ikke et funn.** Observasjonen ble ført som «uverifisert» i fire økter
+mens den samtidig var bærende premiss for arbeidet i nabosporet. Premiss-verifiseringsregelen ble
+anvendt på output, ikke på STATEs egen påstandsliste. Billigste sjekk som fantes var `grep` i eget
+arkiv — ikke WebSearch.
+
+## 2. Catalog er ikke på 0.2. De er på 0.3.
+
+| Påstand i STATE | Ground truth |
+|---|---|
+| catalog er på 0.2 | **0.3** — `1ca27f6`, 2026-07-31 (i dag) |
+| bumpet skjedde «for å ikke være forvekslbar» | primærgrunnen var **§3-gulvet** |
+
+`6a72b26` (2026-07-25), commit-subjekt ordrett: `feat(okf): enforce §3 okf_version shape, bump
+convention 0.1 -> 0.2`. Og specens egen header, `spec.md:12-14`:
+
+> 0.2 had tightened the §3 floor: `okf_version` enforced on shape. Distinct from — and
+> deliberately no longer numerically confusable with — upstream Google OKF v0.1, which this
+> convention targets and does not version.
+
+Ikke-forvekslbarheten er ført som **bevisst sidegevinst**, ikke som årsak. STATE byttet om primær
+og sekundær og bygget et neste steg på den omvendingen. (Jf. driftsmodellen: *før en rad ikke
+sterkere enn den bærer* — her førte vi vår egen rad for sterkt.)
+
+## 3. Hvorfor avklaringen ikke kan kollapse: det er to akser
+
+Dette er **akse-forveksling nr. 13**, og denne gangen var det vår.
+
+- **Akse A — catalogs konvensjonsversjon:** 0.1 → 0.2 → 0.3. Beskriver catalogs *eget* dokument.
+- **Akse B — `okf_version`-verdien:** hvilken upstream Google-versjon en bundle targeter.
+
+Catalog sier eksplisitt at konvensjonen *«targets and does not version»* upstream (`spec.md:13-14`),
+og i §12 (`:245-246`): *«Its value set is owned by Google.»* Gaten er tilsvarende renset for
+akse-lekkasje (`:70-72`): den *«asserts **nothing** about which upstream versions exist ... a bundle
+targeting a newer upstream version passes.»*
+
+At Google flyttet seg på akse B kan derfor ikke kollapse en avklaring som lever på akse A.
+Tallsammenfallet som hypotesen fryktet inntreffer uansett ikke: catalog 0.3 vs. Google 0.2.
+
+## 4. Det ene som faktisk står igjen — og det er ikke vårt
+
+`spec.md` sier to steder at upstream-versjonen bundelen targeter er «currently `0.1`» (`:63`,
+`:246`), mens `:67` i samme dokument siterer upstreams kanoniske eksempel `okf_version: "0.2"`
+(`okf/SPEC.md:773`).
+
+Det er **ikke en defekt**, og skal ikke meldes som en. Catalog har foregrepet situasjonen i egen
+tekst, §12 `:246-247`: *«When Google bumps OKF, each plugin re-checks conformance.»* Google har nå
+bumpet. Re-sjekken er dermed utløst — men den er **catalogs å utløse, på catalogs akse**, og
+plugin-eiernes å utføre. Vi er ikke respondent.
+
+Per driftsmodellen: navngi aksen, pek på rett respondent, ikke lever en verdi vi ikke eier.
+
+## Konklusjon
+
+- Sjekken STATE hjemlet: **utført**. Hypotesen: **falsifisert**.
+- **Ingen melding skal sendes** på det opprinnelige grunnlaget — grunnlaget fantes ikke.
+- Det som *kan* sendes er noe annet og mindre: en `--fyi` til `catalog` om at Google er på 0.2 og
+  at deres egen §12-re-sjekk dermed er utløst. **Fortsatt gated på operatør-go**, og lavt prioritert
+  — catalog eier både aksen og triggeren, og `1ca27f6` (i dag) viser at de følger upstream tett.
+- Sporet `okf-second-brain-convention` er dermed **lukket fra vår side**.
+
+## Verifiseringslogg
+
+| Påstand | Kilde |
+|---|---|
+| Google OKF v0.2, publisert 2026-07-25 | Google Cloud Blog, `okf-v0-2-adds-trust-signals` (WebFetch) |
+| v0.2 var kjent for oss 2026-07-26 | `coord/.../archive/20260726T114345Z-3155211798-from-llm-ingestion-okf.md` |
+| catalog er på 0.3 per 2026-07-31 | `catalog@1ca27f6`; `spec.md:7` |
+| 0.2-bumpens primærgrunn = §3-gulvet | `catalog@6a72b26` commit-subjekt; `spec.md:12` |
+| konvensjonen versjonerer ikke upstream | `spec.md:13-14`, `:245-246` |
+| gaten godtar nyere upstream-versjon | `spec.md:70-72` |
+| re-sjekk-plikten er plugin-eiernes | `spec.md:246-247` |
+
+Catalog-ankrene er lest read-only i `~/repos/ktg-plugin-marketplace/catalog` @ `1ca27f6`. Ingenting
+skrevet i det repoet.

shared/docs/plan/2026-08-02-ss11-mangler-rad-for-ss8.md

@@ -0,0 +1,83 @@
+# Funn-notat — §11 ankrer ikke §8 (og heller ikke §10)
+
+**Status:** FUNN, registrert. **Ikke et underlag, ikke et forslag, ikke bestilt.**
+Køplassering er operatørens. Commons forbereder underlaget, operatøren ratifiserer — og vi
+bestiller ikke vår egen kø, heller ikke for funn vi selv gjør.
+
+**Foranledning:** `portfolio-optimiser` meldte 2026-08-01 (`20260801T175832Z`) at `method-spec.md`
+§11 mangler en rad for deres portefølje-brede budsjettsøm (S3.4/F10: globalt token-tak håndhevet
+før kall, wave-admission med reservasjon, oppstartsnekt). Undersøkelsen av den forespørselen ga
+to atskilte resultater, og bare det ene er vårt.
+
+---
+
+## 1. Forespørselen: avvist på akse
+
+§1 (Scope and conformance) definerer metoden ordrett som «a swarm of agents generates candidate
+cost-saving measures for **one project at a time**». §8 (Budget and stop criteria) er følgelig
+den **per-run** termineringskontrakten.
+
+Globalt tak på tvers av prosjekter, wave-admission med reservasjon og oppstartsnekt for et
+prosjekt som ikke kan finansieres er **orkestrering over metoden**, ikke en søm i den. Deres
+S3.4/F10 er riktig plassert hos dem, og at de bærer den som
+`tests/test_portfolio_budget_loadbearing.py` (6 målte røde mutasjoner) er sømmen dokumentert der
+den hører hjemme.
+
+Konsekvensen av å legge raden inn likevel er konkret og var avgjørende: §11 er en MUST-tabell.
+En konformant implementasjon som kjører ett prosjekt uten portefølje-orkestrering ville blitt
+**ikke-konform på en søm spec-ens egen scope-klausul ikke governerer**.
+
+Svar sendt `20260802T190344Z`.
+
+## 2. Det undersøkelsen faktisk fant, og det er vårt
+
+§11 har **tolv rader**. Ingen av dem ankrer **§8**:
+
+- fail-closed når `usage` mangler i et svar (MÅ feile, aldri stille slutte å telle),
+- det strukturerte stop-eventet med breached kind + limit + observed value,
+- cap-objektenes nekt av ikke-positive verdier.
+
+**§10** (Startup contracts) har heller ingen rad.
+
+Samtidig sier §1 punkt 3 ordrett:
+
+> proves **every** load-bearing seam with a test that FAILS when that seam is detached (§11).
+
+Enten er §11-tabellen enumereringen av «every» — og da mangler §8 og §10 — eller så er den det
+ikke, og da har «every» ingen enumerering i spec-en. **Spenningen er intern i vår egen frosne
+tekst.** Den er vår å løse, ikke konsumentens.
+
+## 3. Verifisering (målt, ikke antatt)
+
+```
+$ sed -n '421,435p' method-spec.md | grep -ciE 'budget|token|meter|usage|cap|startup|max_rounds'
+1
+```
+
+Det ene treffet er en **substring-falsk-positiv**: «es**cap**ing» i navigasjons-raden. Reelt
+antall §11-rader som nevner budsjett, måler eller oppstart er **null**.
+
+```
+$ sed -n '423,434p' method-spec.md | grep -c '^|'
+12
+$ sed -n '24p' method-spec.md
+3. proves every load-bearing seam with a test that FAILS when that seam is detached (§11).
+```
+
+## 4. Åpent spørsmål stilt til `portfolio-optimiser`
+
+Av de 6 målte røde mutasjonene i `test_portfolio_budget_loadbearing.py` — hvor mange treffer
+**per-run-målerens** søm (usage mangler → feil; cap krysses → strukturert stop), og hvor mange
+treffer portefølje-admissionen? Den første halvdelen er in-scope for §8 og kunne vært
+referansetest-kolonnen i en rad vi faktisk kan skrive. Den andre halvdelen forblir deres.
+
+Ubesvart per 2026-08-02. Ingen purring — de sa selv at det ikke blokkerer noe hos dem.
+
+## 5. Hva som IKKE er gjort her
+
+- Ingen rad er skrevet.
+- Ingen ordlyd er foreslått.
+- `method-spec.md` er ikke rørt.
+
+En §8-rad ville vært en endring i frossen, subtree-konsumert tekst og krever operatørens
+ratifisering på lik linje med V1.

shared/docs/plan/2026-08-09-v1-ss12-undernoekler.md

@@ -0,0 +1,138 @@
+# V1-etterspill — krever `generated.by` / `generated.at` egne rader i §12?
+
+> **Status: UNDERLAG, ikke ratifisert. Ingen frossen tekst er endret på dette punktet.**
+> Funnet under utførelsen av V1 (`54e0ec7`, 2026-08-09). V1 selv er ratifisert og utført;
+> dette er en spenning utførelsen *avdekket*, ikke en del av vedtaket.
+>
+> Beslektet: `2026-07-26-v1-generated-felt-okf-v0.2.md` (V1-vedtaket),
+> `2026-08-02-ss11-mangler-rad-for-ss8.md` (samme klasse: intern spenning i frossen tekst).
+
+---
+
+## 1. Funnet
+
+O2 gjør `generated` om fra en literal til en **inline mapping med to navngitte undernøkler**:
+
+```
+generated: { by: process:okf-ingest, at: <ingested_at> }
+```
+
+§12s kryssjekk-tabell bærer fortsatt **én rad** for `generated` (`| generated | provenance
+frontmatter | §3, §7 |`). Spørsmålet er om `by` og `at` skal ha egne rader.
+
+To setninger i frossen tekst gjør dette til mer enn kosmetikk:
+
+> **§12, ingressen** — «Every field of the machine-readable contracts, mapped to its normative
+> section (completeness is enforced by the spec-integrity test)»
+
+> **§11, søm «Spec integrity»** — «this spec goes missing, names a concrete agent toolkit, or
+> **stops documenting a contract field**»
+
+§12 er altså ikke en bekvemmelighetstabell. Den står under en **load-bearing søm**.
+
+## 2. Presedensen i vår egen tekst — målt begge veier
+
+Dette er poenget som avgjør, og det peker ikke én vei før man skiller aksene.
+
+**Presedens FOR egne rader — `source`:**
+
+`source` er et strukturert kontraktsfelt med navngitte undernøkler. §12 gir det **både** en
+toppnivå-rad **og** en rad per undernøkkel:
+
+| Rad i §12 | Hva den er |
+|---|---|
+| `source` | toppnivå-feltet, «polymorphic on `source.type`» |
+| `type` | undernøkkel (diskriminator) |
+| `id` | undernøkkel (felles) |
+| `root` | undernøkkel, kun `type: "file"` |
+| `connection_ref` | undernøkkel, kun `type: "sql"` |
+| `base_url` | undernøkkel, kun `type: "http"` |
+| `credential_ref` | undernøkkel, kun `type: "http"`, valgfri |
+
+Merk at undernøklene er definert i **prosa** i §4 (punktlisten), ikke i §4s tabell — men de får
+likevel egne rader i §12. Tabell-plassering i §4 avgjør altså ikke §12-plikten.
+
+**Presedens MOT egne rader — `ingest_manifest`:**
+
+`ingest_manifest` har intern struktur (`{stem}@{hash16}`, §5) og får **nøyaktig én** rad. Struktur
+inne i en verdi utløser altså ikke automatisk rader.
+
+**Aksen som skiller dem:**
+
+| Felt | Intern struktur er… | Egne rader? |
+|---|---|---|
+| `source` | **navngitte nøkler i en mapping** | ja (4 undernøkler + felles) |
+| `ingest_manifest` | et **strengformat** med posisjonelle deler | nei |
+| `generated` (etter O2) | **navngitte nøkler i en mapping** | *åpent — men faller på `source`-siden* |
+
+`generated: { by, at }` er en mapping med navngitte nøkler. På den målte aksen ligner den
+`source`, ikke `ingest_manifest`.
+
+## 3. Hvorfor V1-vedtaket ikke fanget dette
+
+`2026-07-26-v1-generated-felt-okf-v0.2.md:161` sier: «`:152` og `:309` navngir bare nøkkelen og
+overlever.»
+
+**Den påstanden er sann om den eksisterende raden** — raden heter fortsatt `generated`, ligger
+fortsatt i provenance-frontmatter, og peker fortsatt på §3/§7. Ingenting ved raden ble usant.
+
+**Den er taus om de to NYE nøklene.** Kostnaden ble talt som «kontraktslinjer som må skrives
+om» (§5) — en *omskrivings*-akse. Rader som må **tilføyes** er en annen akse, og den ble aldri
+stilt. Dette er ikke en feil i ratifiseringen; det er et hull i dens scope-formulering. Samme
+klasse som «de 5 linjene var ikke homogene» og «`:214` er ikke en literal»: kostnadstellingen var
+riktig på sin egen akse og blind for en nabo-akse.
+
+## 4. Er sømmen rød i dag? Nei — og det er grunnen til at dette ikke haster
+
+§11-sømmens ordlyd er «**stops documenting** a contract field». §7s omskrevne feltrad
+**dokumenterer begge undernøklene** ordrett — den navngir `by`, fastslår at det er en
+`process:`-aktør, navngir `at`, og binder den til `ingested_at`. Specen har altså ikke sluttet å
+dokumentere noe.
+
+Eksponeringen er mot **§12s egen ingress** («every field … mapped to its normative section»), som
+er en fullstendighets-påstand om tabellen. Det er en svakere binding enn sømmens ordlyd.
+
+**Konsekvens:** ingen kjent implementasjon går rød av dagens tilstand. Dette er en intern
+spenning, ikke en defekt i drift.
+
+## 5. Opsjoner (ingen anbefaling — operatøren ratifiserer)
+
+| | Hva | Kostnad | Hva den koster i konformans |
+|---|---|---|---|
+| **O-A** | Tilføy to rader i §12 (`by`, `at` → §7) | 2 linjer, ren prosa | Utvider hva §12 påstår fullstendighet over. Ingen fixture-endring, ingen konsument-kostnad. |
+| **O-B** | La §12 stå, men **snevre ingressen** til «every top-level field» | 1 linje | Gjør dagens tilstand eksplisitt konform. Men svekker en påstand `source`-radene allerede motsier. |
+| **O-C** | La alt stå | 0 | Spenningen består, udokumentert. |
+
+**O-B har en målt selvmotsigelse:** `root`/`connection_ref`/`base_url`/`credential_ref` er *ikke*
+toppnivå-felter og står allerede i tabellen. En «top-level»-innsnevring ville gjort fire
+eksisterende rader uhjemlede. Det er ikke et argument mot O-B, men det må løses samtidig.
+
+## 6. Et separat, mindre funn fra samme utførelse
+
+`generated.at` gjentar verdien av `ingested_at`, som er sitt **eget felt i samme
+frontmatter-prefiks** (§5s sju nøkler; §7s tabell). Etter O2 bærer et stemplet dokument altså
+samme tidsstempel to steder.
+
+Dette er **en følge av den ratifiserte formen**, ikke en feil i utførelsen — v0.2s `generated`
+tar `at` som påkrevd del av mappingen, og §1s premiss («der `at` finnes, bindes den til
+`ingested_at`») er innfridd nøyaktig som vedtatt. Ført her fordi det er den slags redundans som
+senere leses som drift hvis ingen skrev ned at den var tilsiktet.
+
+**Ikke oppe til vurdering her.** En eventuell konsolidering ville rørt §5s ordnede prefiks, som er
+en helt annen og dyrere sak.
+
+## 7. Ankere re-målt (2026-08-09, etter `54e0ec7`)
+
+Utførelsen flyttet tre av våre egne ankere. Ført ordrett, ikke som linjenumre:
+
+| Sted | Seksjon | Status |
+|---|---|---|
+| Honesty rule | §1 | omskrevet — «`generated.by` naming the ingest actor» |
+| Ingest owns only its own files | §3 | omskrevet — «`generated.by` equal to the ingest actor» |
+| No other writer may forge the stamp | §3 | omskrevet — samme gjengivelse |
+| Feltraden for `generated` | §7 | omskrevet, definerer begge undernøkler |
+| Load-bearing «Stamp integrity (curated writers)» | §11 | omskrevet — aktør-spesifikt predikat |
+| Frontmatter-prefikset (sju nøkler) | §5 | **uendret** — navngir bare nøkkelen |
+| Kryssjekk-raden for `generated` | §12 | **uendret** — dette dokumentets tema |
+
+`generated: true` finnes ikke lenger i specen (verifisert med `grep`).