portfolio-optimiser-claude/docs/2026-08-18-funn-koeer-og-gater.md

Målte funn, køer og gater (flyttet ut av STATE.md 2026-08-18)

Bakgrunn: STATE.md er current state-of-play og har et tak på ~120 linjer. Den 18.08 lå fila på 149. Operatørbeslutningen samme dag var å flytte tre punkter hit og la STATE beholde ÉN peker per punkt på formen fil § Overskrift — et grep-bart paragraf-anker, aldri et linjenummer. Ingenting er slettet: state er flyttet, ikke fjernet.

Alt under er MÅLERESULTATER med en dato, ikke fakta om verden. Datoen står ved hver påstand, og en påstand herfra er et premiss som skal verifiseres på nytt før den handles på — særlig tall som råtner (versjoner, testantall, oppstrøms-tilstand).

Negative funn

Steder som ER undersøkt for en manglende søm, og hvor svaret var «ingen søm å feste». De er ferdig avklart i økt 17–22 og skal ikke re-måles — enumerert her nettopp for at ingen senere økt skal bruke tid på dem igjen:

• test_preflight (9 tilfeller)
• test_zero_model_calls
• notify :224
• ir :69
• validator :56
• step1_expel :99
• cli_paritet-parene
• method_spec + ingest_spec (6 tilfeller — merk: ikke lenger dekkende, se under)
• alle 8 fra økt 22

Korreksjon 2026-08-18 (økt 32): ingest_spec-oppføringen gjaldt den §12-ankrede vakten. Økt 32 målte et hull den enumereringen ikke fanget — enhver seksjon §1–§11 kunne tømmes uten at én test i suiten ble rød (10 av 11 seksjoner; §7 var eneste overlapp, via O2-ratchet-en). Hullet er lukket med _STRUCTURE_MARKERS i tests/test_ingest_spec_loadbearing.py (commit 40b4631). Lærdommen er generell: et negativt funn har et scope, og scopet er den spørringen som ble kjørt — ikke fila den ble kjørt mot.

D7-speilingskøen

Åtte kandidater for speiling mellom D7-søsknene. Ingen er besluttet — de står som kandidater, ikke som planlagt arbeid. Seks er målt, 2 står igjen:

• S2.7 — MÅLT 2026-09-07, se under
• S3.2 — MÅLT 2026-09-12, se under
• S4.0 (126807a) — MÅLT 2026-09-13, se under
• (p) to_ore — MÅLT 2026-09-13, se under
• (a)/(i) unquote_scalar — MÅLT 2026-08-31, se under
• mandate.py
• A5 — TO halvdeler
• B4 ToolCallRecorder — BESVART 2026-08-25, se under

B4 spurte OSS: gir Claude-SDK-siden serveridentiteten gratis? MAF får verktøynavn UTEN server-prefiks. Åpent hos søskenet: MAF S3.4 (F10).

B4 — svaret er NEI (målt 2026-08-25, offline, mot claude-agent-sdk 0.2.139)

create_sdk_mcp_server emitterer det bare verktøynavnet. Serveridentiteten finnes — på McpSdkServerConfig["name"] og Server.name — men den er disjunkt fra hvert navn verktøylista bærer. Strengen mcp__ forekommer i 0 av 24 Python-filer i pakken (positiv kontroll: create_sdk_mcp_server blir funnet av samme spørring, så spørringen KAN finne). Konstruksjonssiden namespacer altså ingenting: en ToolCallRecorder hengt der ser record_call, ikke mcp__tool_call_recorder__record_call, og må få servernavnet fortalt. Det er samme pris som søskenet betaler.

Ærlig grense — hva målingen IKKE sier. Den navnerommede formen mcp__<server>__<tool> eksisterer: den bygges inne i CLI-en som følger med SDK-en (_bundled/claude, 178 literale mcp__-forekomster, konstruksjonen på formen `mcp__${…}__${…}`). Det er lest av artefaktet, ikke observert i en kjøring hos oss — å se den emittert krever en live query(), som både D6-kostnadsregelen og suitens offline-invariant forbyr. Funnet er derfor scopet til den sømmen vi faktisk kan bygge på: den in-process konstruksjonssiden. Prefikset finnes på et lag vi bevisst ikke kjører, og et lag vi ikke kjører er ikke en søm vi kan feste en recorder i.

Pinnet av tests/test_sdk_tool_namespace_loadbearing.py (4 tester). Value-beviset er kjørt, ikke påstått: SDK-en ble mutert til å namespace ved konstruksjon ("name": f"mcp__{name}__{tool_def.name}") — grønn før, 3 av 4 røde etter, og den ene som forble grønn er nettopp populasjons-kontrollen, som den skal. SDK-fila ble restaurert byte-identisk (sha256 verifisert begge veier).

Datering (D7-rammen): dette er arbeid ETTER 2026-08-09 og skal ikke leses som uavhengig konvergens selv om svaret er identisk med søskenets.

(a)/(i) unquote_scalar — svaret er JA, den var ÉN regel, men pinnet bare i kanten (målt 2026-08-31)

Kandidaten står i køen fordi søskenet vokste en navngitt unquote_scalar etter at en duplisert konvertering hadde driftet — to steder som fjernet anførselstegn fra en frontmatter-skalar, etter to regler. Speilings-spørsmålet er derfor ikke «har vi funksjonen», men det søskenets defekt faktisk stiller: er den ÉN regel hos oss, og er selve regelen load-bearing?

Populasjonen først. unquote_scalar finnes ikke hos oss: 0 treff av 76 undersøkte .py-filer i src+tests (positiv kontroll: samme spørring finner parse_frontmatter i okf.py), og unquote finnes ikke i repoet utenfor .venv. Vår motpart er okf._strip_matching_quotes — én definisjon, ett kallsted (_parse_frontmatter_and_body). Søskenets drift-form finnes altså ikke her.

Men regelen var dekket bare i kanten. Med scripts/mutation_harness.py, nevner tests/ (hele suiten, 950 tester), hver kjøring sha256-restaurert:

• Å detache regelen helt (return value[1:-1] → return value) er RØD — test_okf.py::TestFrontmatter::test_unknown_fields_preserved_and_quotes_stripped fanger den.
• Hver av de tre klausulene var grønn-men-død: å svekke lengdevakten (>= 2 → >= 1), å droppe matching-kravet (value[0] == value[-1] and), og å utvide quote-settet med en symmetrisk delimiter (backtick) lot hele suiten stå grønn.

Samme klasse som _STRUCTURE_MARKERS-hullet i økt 32: sømmen var NAVNGITT og kant-dekket, som ikke er det samme som dekket. Pinnet av tests/test_okf_unquote_loadbearing.py (5 tester, 950 → 955). Value-beviset er kjørt, ikke påstått: hver klausul-test er grønn før og rød etter nøyaktig sin egen mutasjon, med populasjons-kontrollen grønn i begge (mutasjonen landet ikke for bredt), og ledd 3 pinnet på linje via --red-at.

EN MÅLETRAP, MÅLT — ny lærdom om harnesset. Første forsøk på klausul 3 utvidet settet med '['. Suiten forble grønn, hvilket leses som «klausulen er ikke dekket» — men mutasjonen er en no-op: '[' kan aldri tilfredsstille matching-kravet, siden [ ikke er ]. Flow-form- verdier er altså beskyttet av matching-klausulen, ikke av quote-settet, og en grønn kjøring under den mutasjonen var aldri bevis om quote-settet i det hele tatt. Harnesset kan ikke skille en oppførsels-bevarende mutasjon fra en udekket søm — begge kommer ut som «stayed GREEN». En mutasjon må vises å endre oppførsel før dens grønne leses som et hull. Dette er Verifiseringsloven ansikt 4 anvendt på selve måleapparatet: et negativt resultat fra en spørring som ikke KAN finne, er ikke null — det er ikke målt.

Ærlig grense — hva dette IKKE sier. Å pinne at flow-verdier passerer urørt er ikke flow-DEKODING, og fila legger ingen til: tags: [a, b] forblir strengen "[a, b]". Den linje-orienterte parseren har ingen nesting-modell ved design (§1 ærlighets-regelen). Den additive flow-dekoderen er søskenets B4-arbeid i portfolio-optimiser og er bevisst ikke bygget her; testene pinner dagens grense slik at det arbeidet ikke kan lande stille på denne siden.

Datering (D7-rammen): arbeid ETTER 2026-08-09 — skal ikke leses som uavhengig konvergens.

S2.7 — gaten er ÉN regel, og den var pinnet i ARITMETIKKEN, ikke i BESLUTNINGEN (målt 2026-09-07)

Kandidaten står i køen fordi søskenet strammet validatoren i to halvdeler: (a) en strukturell blokk på claimed > nominal_feasible, og (b) en IR-invariant low ≤ unit_cost ≤ high. Begge halvdeler er GATET her på D-A pkt. 1 + commons-pull (paritetsplanens rad 12), og defekten de svarer på er bekreftet på vår side som C-F2 (docs/review-2026-07.md). Speilings-spørsmålet som KAN besvares offline i dag er derfor et annet: er dagens grense — «den ENE numeriske gaten er p90» — load-bearing?

Populasjonen først. En claim er numerisk avgrenset i nøyaktig TO steder i src/, med hver sin spec-rolle: skjema-invarianten (claim ≤ items-total, §7.1, ir.py:50) og validator-gaten (claim ≤ p90, §3 Steg 4, validator.py:68). _FEASIBLE_FRACTION forekommer kun i validator.py, og det finnes ingen annen Monte Carlo eller quantiles-beregning i pakken (positiv kontroll: samme spørring finner validate_proposal i loop.py:284). Søskenets drift-form — to gater som har glidd fra hverandre — finnes altså ikke her.

Men dekningen deler seg rent på tvers av regelen. Med scripts/mutation_harness.py, nevner tests/ (hele suiten, 955 tester), hver kjøring sha256-restaurert:

• Å detache gaten helt (if … > p90: → if False:) er RØD — test_validator.py fanger den.
• Alt gaten REGNER UT er RØDT, og goldenen er grunnen: policy-taket (0.30 → 0.31), band-grenen (ignorér bands), band-endepunktenes rekkefølge, MC-seeden, p90-kuttpunkt-indeksen og nominal_feasible-formelen reddet alle suiten.
• Alt gaten BESLUTTER MED er grønn-men-dødt: å bytte grensen til p10, å bytte den til nominal_feasible, og å løsne > til >= lot alle 955 testene stå grønne.

Det skillet ER funnet, og det er skarpere enn «sømmen er tynn»: goldenen fryser hvert tall validatoren PRODUSERER, og kan derfor ikke hjelpe med det ene den ikke observerer — hvilken grense gaten LESER. Konsekvensen er konkret: å bytte p90 mot nominal_feasible ER den gatede S2.7-halvdel (a), og den ville landet med suiten grønn, før D-A er besluttet.

Pinnet av tests/test_validator_gate_loadbearing.py (8 tester, 955 → 963). Value-beviset er kjørt, ikke påstått: hver klausul-test er grønn før og rød etter nøyaktig sin egen mutasjon, med golden-tallene grønne i BEGGE kjøringer — som mekanisk viser at mutasjonen flyttet BESLUTNINGEN, ikke aritmetikken. De to IR-testene er pinnet med --red-at mot invariantens egen feilmelding, fordi de dør i en hjelpefunksjon og ikke i testkroppen.

Mutasjonene ble vist å endre oppførsel FØR deres grønne ble lest som hull (fellen fra økt 39). Alle tre grensetilfellene er nåbare og ble kjørt: en claim nøyaktig PÅ p90 finnes (degenerert band, 0.30 × 1000 == 300.0), og med goldenens eget band valideres en claim på 100 000 mens nominal_feasible er 90 000 — C-F2s første moteksempel, reprodusert live på p90 = 121 057.09, sammen med det andre (claim 55 000 mot nominal 30 000, p90 = 65 058.49). Begge tallene er identiske med review-ens, som bekrefter at defekten er spec-båren.

To ting målingen ga i tillegg. (1) Populasjonskontrollen (AST) ble bevist mot en oppførselsbevarende mutasjon — > p90 utvidet til > p10 and > p90, som er logisk identisk når p10 ≤ p90 — og alle tre oppførselskontrollene forble grønne. En ny gate-plassering er usynlig for enhver oppførselstest; det er nettopp derfor AST-kontrollen står der. (2) Under containment-mutasjonen forble golden-testen grønn, hvilket mekanisk bekrefter review-ens påstand om at S2.7 halvdel (b) er golden-kompatibel når D-A lander.

Nytt utover C-F2: IR-en har heller ingen ORDNING på band-endepunktene. (1.40, 0.70) aksepteres; random.uniform(1.40, 0.70) trekker fortsatt fra [0.70, 1.40], så området korrumperes ikke — men den seedede strømmen vandres baklengs, hvilket er en ANNEN p90 (målt: 120 456.91 mot 121 057.09). Et band hvis betydning avhenger av argument-rekkefølgen er ennå ikke et band.

Ærlig grense — hva dette IKKE sier. Å pinne at en claim over nominal_feasible validerer i dag er ingen godkjenning av oppførselen; C-F2 kaller den en MAJOR spec-nivå-defekt, og fiksen er GATET, ikke avvist. Testene pinner grensen slik at det gatede arbeidet MÅ ankomme som en synlig rød test og en beslutning, aldri som et stille bytte. Ingen src/-endring er gjort, ingen spec-tekst rørt, og fasiten er ikke berørt.

Datering (D7-rammen): arbeid ETTER 2026-08-09 — skal ikke leses som uavhengig konvergens.

S3.2 — id-en er pinnet, NØKLINGEN er ikke, og de to nøklings-stiene er uenige (målt 2026-09-12)

Kandidaten står i køen fordi søskenet fikset flerkandidat-ExpeL-seeding: frøet skal lese den dømte kandidaten fra verdict-filas EGEN frontmatter (promoteringen skriver den), med dagens nøkling som fallback. Feature-halvdelen av den defekten er bekreftet her som C-F5 (docs/review-2026-07.md) og GATET på D-A pkt. 4 + commons-pull (paritetsplanens rad 14), mens id-halvdelen alt er løst: en lastet verdict_id leses VERBATIM (§4.2). Speilings- spørsmålet som KAN besvares offline i dag er derfor: er dagens grense — «id-en kommer fra FILA, nøklingen kommer fra BUNDELEN» — load-bearing i BEGGE halvdeler?

Populasjonen først. En dom nøkles i nøyaktig TO steder i src/, med hver sin spec-rolle: bundle-frøet (experience.py:146, §3 Steg 1 — nøklet på bundelens ENE IR-projeksjon) og fil/inbox-stien (inbox.py:105, §4.2 — nøklet på dommens egne proposal_features). Ingen tredje konstruksjon finnes (AST-målt over hele pakken; positiv kontroll: samme AST-spørring finner VerdictStore-konstruksjon i tre moduler, så spørringen KAN finne). Og her finnes søskenets drift-form — i motsetning til S2.7 og unquote_scalar: de to stiene nøkler ETTER ULIKE REGLER.

Dekningen deler seg rent mellom id og nøkling. Med scripts/mutation_harness.py, nevner tests/ (hele suiten, 963 tester), hver kjøring sha256-restaurert:

• Å detache sømmen (frøet itererer ingenting) er RØD; det samme er type-filteret, decision-defaulten og description-lesningen.
• ID-halvdelen er pinnet på BEGGE sider: å re-minte i stedet for å lese frontmatter-id-en er RØD (test_step8), og å droppe mint-fallbacken — slik at ikke-promoterte dommer nøkles på en tom id — er også RØD.
• NØKLINGS-halvdelen er grønn-men-død. Å bytte bundle-projeksjonen mot tomme features lot alle 963 stå grønne, og det gjorde også den gatede fiksens EGEN form (les kandidaten fra verdict-filas frontmatter, fallback dagens nøkling). Ingenting i suiten observerte hva en seedet dom er nøklet PÅ.
• Én klausul i rasjonalet var grønn-men-død i tillegg: kravet om BEGGE læringsfeltene før markøren emitteres. Svekket til enten-eller forble suiten grønn — og konsekvensen er en ærlighets-defekt (§1): markøren navngir da det fraværende feltet som None.

Mutasjonene ble vist å endre oppførsel FØR deres grønne ble lest som hull (fellen fra økt 39). Tom nøkling senker den seedede dommens similarity mot sin egen bundle-projeksjon fra 1.00 til 0.15 — observerbart, og rangerings-relevant i det øyeblikket en andre oppføring finnes. C-F5s rest-defekt er reprodusert live: to promoterte dommer om ULIKE kandidater (LED vs. ventilasjon) seedes begge nøklet på bundelens ENE projeksjon, så en spørring som bærer ventilasjons-kandidatens egne features scorer BEGGE til 0.0 og avgjøres av hex-id-rekkefølge, ikke av struktur.

NYTT UTOVER C-F5 — nøklingen er sti-avhengig, og dermed rekkefølge-avhengig. Samme dom — samme kandidat, samme mintede id (c8c97c9d992229dc), altså samme first-write-wins-slot — nøkles på VENT-AGG-01/250 000 via inbox-stien og på ENERGI-TOTAL-EL/30 000 via bundle-frøet. Hvilken nøkling som overlever avgjøres av LASTE-REKKEFØLGEN, ingenting annet. Og fiksen kan ikke være ensidig: promote skriver verdict_id og description, men ingen kandidat-felt (målt frontmatter-nøkkelsett: decision, description, provenance, tags, title, type, verdict_id) — hvilket er grunnen til at fiksens egen form er en no-op mot enhver fixture i repoet i dag, og derfor måtte måles mot en fixture som bærer feltene.

Pinnet av tests/test_experience_keying_loadbearing.py (11 tester, 963 → 974, strengt supersett: 0 tapte node-id-er). Value-beviset er kjørt, ikke påstått: hver test er grønn før og rød etter nøyaktig sin egen mutasjon, med fold-markøren grønn i BEGGE kjøringer — som mekanisk viser at mutasjonen flyttet NØKLINGEN, ikke sømmen. To sammensatte tester ble SPLITTET fordi en rød test bare beviser sin FØRSTE assert (§1-halvdelen er i tillegg pinnet med --red-at None).

To kontroller utover oppførselen. (1) Populasjonskontrollen (AST) ble bevist mot en oppførselsbevarende mutasjon — en tredje, ubrukt VerdictRecord-konstruksjon — med alle oppførselstestene grønne. (2) Å heve projeksjons-lesningen INN i seedings-loopen er likeledes oppførselsbevarende (tre oppførselskontroller grønne), og er samtidig første halvdel av den gatede fiksen; derfor er formen pinnet strukturelt (load_validator_input kalles nøyaktig ÉN gang i seed_store_from_bundle) eller ikke i det hele tatt.

Ærlig grense — hva dette IKKE sier. Å pinne at alle dommer i en bundle deler ÉN nøkling i dag er ingen godkjenning; C-F5 kaller den en MAJOR spec-nivå-defekt, og fiksen er GATET, ikke avvist. Testene pinner grensen slik at det gatede arbeidet MÅ ankomme som en synlig rød test og en D-A pkt. 4-beslutning — samme ratchet-rolle test_ingest_stamp_conformance_loadbearing.py har oppstrøms. Ingen src/-endring er gjort, ingen spec-tekst rørt, og fasiten er ikke involvert i nøklingen i det hele tatt — hvilket er nettopp derfor den ikke kunne hjelpe.

Datering (D7-rammen): arbeid ETTER 2026-08-09 — skal ikke leses som uavhengig konvergens.

S4.0 — baselinen er lastet, og den er strukturelt utenfor dommerens rekkevidde (målt 2026-09-13)

Kandidaten står i køen fordi søskenet forankrer affected_items mot en kostbaseline. Defekten er bekreftet her som C-F3 (docs/review-2026-07.md, MAJOR, spec-nivå: en diktet kostlinje validerer en 2,9 MNOK-claim), og fiksen — en fail-closed avstemmings-stage — er GATET på D-A pkt. 2 + et commons-amendment for cost-baseline.json (paritetsplanens rad 19). Speilings-spørsmålet som KAN besvares offline i dag er derfor: er dagens grense — «hvert kosttall validatoren dømmer på stammer fra forslaget selv» — load-bearing?

Populasjonen først. En SavingsProposal blir til i nøyaktig TRE steder, med hver sin proveniens: det modell-forfattede parset (loop.py:89), bundelens baseline-projeksjon (ir.py:64) og det re-leste system-outputet (hitl.py:132). AST-målt over alle 27 src/*.py (positiv kontroll: samme spørring finner validate_proposals ENE kallsted, loop.py:284). Kun den FØRSTE når validatoren. Det er C-F3 uttrykt som en måling.

Baselinen LASTES på hver komposisjonssti — run.py:123, run_s10.py:71, experience.py:132 — og det eneste feltet noen leser direkte av den er project_id (fire steder). Alt annet forlater lastingen gjennom CandidateFeatures.from_proposal, som leser kodene, measure og claimen. quantity, unit_cost og usikkerhets-bandene er skjema-validert og deretter aldri lest igjen av noe. Fiksens egen input ligger altså i minnet i samme ComposedRunContext som dommen felles fra, og ingen sti fører den dit.

Målingene. Med scripts/mutation_harness.py, nevner tests/ (hele den gamle suiten, 974 tester), hver kjøring sha256-restaurert fra disk:

• M1 — baselinen erstattes med den svakeste skjemagyldige varianten (kodene, measure, claimen og project_id bevart; quantity/unit_cost flatet, band tømt): tre nye tester RØDE, og alle 974 gamle GRØNNE i begge kjøringer. Bundelens kosttall kan byttes ut på run-stien uten at én eneste eksisterende test merker det.
• M2 — ComposedRunContext.ir_projection: SavingsProposal → object: AST-testen RØD, alle oppførselstester GRØNNE. En stille innsnevring av det bårne feltet er usynlig for oppførsel — og ville slettet den eneste kostbaselinen på run-stien.
• M3 — S10-stien slutter å kalle load_validator_input (oppførselsbevarende alias): loader-populasjonen RØD, test_s10_run_layer.py + test_preflight.py GRØNNE.
• M4 — validatoren får en baseline-parameter (den gatede fiksens signatur, default None): signatur-ratchet-en RØD, goldenen GRØNN — som mekanisk bekrefter at S4.0s signatur-halvdel er golden-kompatibel når D-A pkt. 2 lander.
• M5 — kallstedets argument blir et keyword: proveniens-kontrollen RØD, oppførselen uendret.
• M6 — fail-closed kodesett-gate i validatoren (fiksens EGEN form, hardkodet baseline): grense-testen RØD, goldenen GRØNN i begge.
• M7 — retrieval slutter å lese kodene: disjunkthets-testen RØD, golden + validator GRØNNE.

En måletrap unngått — mutasjonen må vises å endre oppførsel, ikke bare å være skrevet (økt 39, her i motsatt retning). Første M1-forsøk flatet kostlinjene til 1.0 × 1.0 og gjorde test_run_entrance_loadbearing.py RØD. Det så ut som dekning, men var det ikke: total 1,0 < claim 30 000 bryter IR-invarianten (ir.py:46), så mutasjonen var en konstruksjonsfeil, ikke en baseline-fjerning, og rødheten attribuerte til pydantic. Harnessets kollateral-kontroll fanget den. Den korrekte mutasjonen holder invarianten — og da er alle 974 grønne.

NYTT UTOVER C-F3 — bundelen BÆRER en kostbaseline, og retrieval ser den allerede. C-F3 formulerer defekten som «ingenting i bundle-formatet bærer en kostbaseline å avstemme mot». Målt her er det for sterkt: validator-input.json bærer ENERGI-TOTAL-EL à 300 000 NOK, og den lastes på hver run-sti. C-F3s kjørte bevis er reprodusert med review-ens egne tall (claim 2 900 000, degenererte percentiler 3 000 000) og skjerpet: det diktede kostgrunnlaget er 33,3× hele bundelens baseline, claimen er 9,67× byggets totale årlige energikost, og den diktede koden har null overlapp med bundelens kodesett. Det overlappet BEREGNES — CandidateFeatures bruker det til å rangere erfaring. Systemet holder altså beviset som ville avslørt dikteringen, bruker det på rangering, og aldri på å dømme. Defekten er ikke at baselinen mangler; den er at den ikke er koblet til dommeren.

Hvor bredt fiksen slår ut (en telling, ikke et load-bearing-bevis — derfor ikke harnesset, men git-verifisert restaurering): med fiksens form hardkodet til bundelens kodesett er 30 av 974 røde. Fiksen er altså bredt synlig i suiten, ikke stille. Ærlig grense: det tallet er målt på en HARDKODET baseline; den ekte fiksen ville lest bundelens baseline per kjøring, og hver testfixtures egen baseline ville da definert sitt eget kodesett — så 30 er et tak på støyen, ikke et estimat på arbeidet.

Pinnet av tests/test_cost_baseline_loadbearing.py (10 tester, 974 → 984, strengt supersett: 0 tapte node-id-er). To testpar er SPLITTET fordi en rød test bare beviser sin FØRSTE assert: kostlinjene fra bandene, og valideringen av den diktede linja fra dens magnitude.

Ærlig grense — hva dette IKKE sier. Å pinne at baselinen ankommer intakt er ingen påstand om at den BRUKES; det gjør den ikke, og C-F3 står som MAJOR. Testene pinner grensen slik at det gatede arbeidet MÅ ankomme som en synlig rød test og en D-A pkt. 2-beslutning — samme ratchet-rolle test_ingest_stamp_conformance_loadbearing.py har oppstrøms. Ingen src/-endring er gjort, ingen spec-tekst rørt, og goldenen kan ikke hjelpe: den fryser hva validatoren REGNER UT av et forslag, og baselinen er ikke en input til den beregningen i det hele tatt. De to magnitude-/disjunkthets-påstandene er dessuten faktapåstander om bundle-fixturen og deler anker med goldenen — de er konsistens-tester, ikke uavhengige søm-bevis, og er merket som det over.

Datering (D7-rammen): arbeid ETTER 2026-08-09 — skal ikke leses som uavhengig konvergens.

(p) to_ore — regelen finnes i FIRE kopier, tre av dem kjøres aldri, og gaten den skulle tjene er slått av (målt 2026-09-13)

Kandidaten står i køen fordi søskenet vokste en navngitt to_ore etter at en pengekonvertering hadde driftet i to kopier — run.py re-implementerte ledger.to_ore privat, og de to kopiene møttes på hver sin side av én målsammenligning (_goal_limit_if_reached). Søskenets beslutning ble «kvantiser per linje, summer heltall», pinnet med assert run_mod.to_ore is ledger_mod.to_ore. Speilings-spørsmålet er derfor ikke «har vi funksjonen», men: er vår pengekonvertering ÉN regel, og er den load-bearing der den beslutter noe?

Populasjonen først. to_ore finnes ikke hos oss: 0 treff av 80 undersøkte .py-filer i src+tests (positiv kontroll: samme spørring finner unit_cost i 19 av dem, så spørringen KAN finne). Vi har ingen NOK→øre-akse i det hele tatt — vår pengeakse er den akkumulerte USD-forbruket total_cost_usd, og vår konvertering er avrundingen til seks desimaler. Den finnes i fire literale kopier uten navngitt kilde: run.py:159 (_client_cost_usd), run_s10.py:110 og :130 (de to persisterings-kallstedene) og costsim.py:125 (per-celle-estimatet). Én fil unna gjør det samme pakket det motsatte: valuereport.py avrunder gjennom _SHARE_DIGITS. Søskenets drift-form finnes altså her — i den halvdelen som ikke har fått sin ene kilde.

Og driften har et møtested. På en cost_usd-stopp skriver ETT kall begge tall: stop.json bærer observed fra BudgetExceeded — den rå verdien gaten sammenlignet — mens usage.json bærer cost_usd avrundet. To tall for samme størrelse, fra samme kall, etter to regler.

Men det skarpeste funnet er at tre av de fire kopiene aldri kjøres. Med scripts/mutation_harness.py, nevner tests/ (hele den gamle suiten, 984 tester), hver kjøring sha256-restaurert fra disk — og med positivkontrollen først: å erstatte HELE avrundingsuttrykket med konstanten 999.0 lot alle 984 stå grønne på run.py:159, run_s10.py:110 og :130. Grenene utøves aldri med en kost. Deres grønne under en detach var derfor aldri bevis om avrundingen — det var «ikke målt» (økt 39, Verifiseringsloven ansikt 4 på måleapparatet). Kun costsim.py var dekket. DEFAULT-en var derimot pinnet: getattr(client, "total_cost_usd", None) → 0.0 er rød i test_run_entrance_loadbearing.py. Nøkkelen var pinnet i sitt navn og fri i sin verdi (økt 41) — her: default-grenen pinnet, verdi-grenen ukjørt.

Gaten som skulle bruke tallet er slått av på hver eneste sti. max_cost_usd settes i 0 av 27 src-moduler (positiv kontroll: samme AST-skann finner max_budget_usd_per_call, som ER wiret). Alle fire BudgetMeter(...)-konstruksjoner i src tar default None, og guard_before_call returnerer før den sammenligner. C3.5-beltet er altså ikke-no-op kun i sin egen enhetstest. Samme klasse som S4.0, ett hakk verre: der var feltet lastet og utenfor dommerens rekkevidde; her er dommeren bygget og ingen sti gir den et tak.

SYV mutasjoner, alle VALUE-PROVED (grønn før / rød etter, hver med kollateral-kontroll grønn i begge kjøringer); anker → erstatning ordrett:

• M1 — avrundingen detaches (run.py): return None if cost is None else round(float(cost), 6) → return None if cost is None else float(cost). To RØDE (kvantiseringen og «ikke den rå verdien», splittet); kontroll test_the_value_branch_is_reached_at_all GRØNN i begge.
• M2 — sifferantallet drifter (run.py): return None if cost is None else round(float(cost), 6) → return None if cost is None else round(float(cost), 2). Kvantiserings-testen RØD; samme kontroll GRØNN.
• M3 — beltet leser den AVRUNDEDE kosten (loop.py, søskenets drift innført): meter.guard_before_call(spent_usd) → meter.guard_before_call(round(spent_usd, 6)). Stopp-testen RØD; kontrollen «den avrundede ville ikke ha stoppet» GRØNN i begge.
• M4 — stop-eventet rapporterer den avrundede (budget.py): raise BudgetExceeded("cost_usd", self._max_cost_usd, spent_usd) → raise BudgetExceeded("cost_usd", self._max_cost_usd, round(spent_usd, 6)). observed-testen RØD; at beltet fortsatt STOPPER GRØNN — rødheten attribuerer til rapporteringen, ikke til gaten.
• M5 — én kopi drifter til et annet sifferantall (costsim.py): cost = round(estimated_tokens * price.usd_per_mtok / _TOKENS_PER_MTOK, 6) → samme med , 2). Siffer-settet RØDT; kopi-tellingen GRØNN (mutasjonen endrer siffer, ikke antall).
• M6 — én kopi foldes bort (run_s10.py, fiksens retning): cost_usd=round(client.total_cost_usd, 6), → cost_usd=client.total_cost_usd,. Kopi-tellingen RØD; siffer-settet og modul-settet GRØNNE.
• M7 — noen wirer run-total-taket (run.py, ratchet-en): run_label = run_id or out_dir.name
  • meter = BudgetMeter(contracts.termination) → samme med meter = BudgetMeter(contracts.termination, max_cost_usd=1.0). Fraværs-testen RØD; positivkontrollen og «en meter uten tak stopper aldri» GRØNNE.

Fixturen fiksen LESER, bygget (økt 41). ScriptedClient bærer ingen total_cost_usd i det hele tatt, og det er nettopp derfor hver eksisterende run-sti-test bare utøver den ærlige null-grenen. CostingScriptedClient legger på en — 0.1234567891 USD, mer presisjon enn regelen beholder, så den persisterte verdien forteller hvilket tall som ble skrevet. Belte-testene bruker en forbruks-verdi som ligger STRENGT MELLOM taket og sin egen avrunding (0.10000004 mot tak 0.1, round(…, 6) == 0.1): rå verdi stopper, avrundet slipper gjennom. Uten den konstruksjonen er M3 en no-op og ville sett ut som en udekket søm.

Pinnet av tests/test_cost_usd_quantization_loadbearing.py (13 tester, 984 → 997, strengt supersett: 0 tapte node-id-er). Tre testpar er SPLITTET fordi en rød test bare beviser sin FØRSTE assert: «kvantisert til seks desimaler» fra «ikke den rå verdien», «beltet stopper» fra «stoppet bærer den rå verdien», og siffer-settet fra kopi-tellingen.

Ærlig grense — hva dette IKKE sier. Ingen src/-endring er gjort, og det er en beslutning, ikke en forglemmelse. Å gi de fire kopiene én navngitt kilde er en refaktorering, ikke en fiks på en målt defekt; å wire run-total-taket inn i inngangen er en FEATURE — et CLI-flagg og et kontraktsfelt, med --help/README-paritetsvakten bak seg — og per-kall-taket max_budget_usd_per_call binder allerede et live forbruk gjennom SDK-en. Testene sier heller ikke at dagens tilstand er ønskelig: de sier at den er MÅLT, og de gjør hver av de tre endringene synlig som en rød test i stedet for en stille landing. Kopi-tellingen er dessuten en tekstlig AST-egenskap, ikke et oppførselsbevis — den fanger en femte kopi og et endret sifferantall, ikke en femte kopi skrevet på en annen form (f"{x:.6f}", Decimal). Og run_s10.py er byte-frossen og importeres aldri i suiten: dens to kallsteder er pinnet ved AST, ikke ved kjøring, hvilket er den sterkeste sømmen som finnes mot en fil vi ikke kjører.

Datering (D7-rammen): arbeid ETTER 2026-08-09 — skal ikke leses som uavhengig konvergens.

Rammen rundt køen: å lese søskenets kode er tillatt (3bdf7f0), men kopiering skal kun skje der det tjener løsningen, aldri som snarvei. Uavhengighets-beviset er DATERT t.o.m. 2026-08-09; arbeid etter den datoen kan ikke leses som uavhengig konvergens.

D-A-gater og fasit-berøring

• D-A#5 mangler story-etikett oppstrøms — avklar med MAF før teksten låses. En ny hovedbok-kontrakt MÅ inn i §12s kryssjekktabell i SAMME amendment; ellers blir tabellen ufullstendig i det øyeblikket kontrakten finnes.
• D-A#2 rører fasiten. commons er meldt at vår §12-vakt keyer på ordrett | generated | ⇒ et amendment som ERSTATTER raden gjør oss RØDE. Det er by design: en fasit-endring skal koste en synlig rød test, ikke gli gjennom.
• Gates: D-F/D-G → K13 · D-B → K14/K15 · D-E · okf-toolkit-§8 · delbarhet av ledger-/ outbox-format. R-9 er valgfri.