portfolio-optimiser-commons/docs/plan/2026-08-02-ss11-mangler-rad-for-ss8.md
Kjell Tore Guttormsen 30e1e71cdf docs(plan): kø SS11-budsjettfunnet — køplassering, ikke utførelse
Operatørbeslutning 2026-08-25 (ordre 20260825T060649Z-9004613141-from-.claude,
punkt 1): saken skal i kø, selve SS11-arbeidet (formanalysen for en
§8-og/eller-§10-rad) skal IKKE utføres. Samme mønster som SS12-køplasseringen
(e307997): banner + ny § i det eksisterende plandokumentet.

Ny §6 sier hva køen forplikter til når turen kommer: re-mål §2–§4s premisser,
skriv underlaget (hvilken form løser spenningen, om noen), legg det fram for
operatøren. I motsetning til SS12 finnes ingen ferdig formanalyse å vise til
her — §2–§4 er et funn, ikke et sett med opsjoner, så køoppføringen kan bare
peke videre, ikke oppsummere valg.

De to andre kandidatene i samme kø (commons-spec-amendments,
commons-shared-golden-referent Q4) er ikke droppet, bare ikke valgt denne
runden.

Ingen normativ tekst rørt, ingen versjonsbump, ingen tag.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-25 08:15:04 +02:00

5.4 KiB
Raw Blame History

Funn-notat — §11 ankrer ikke §8 (og heller ikke §10)

Status: FUNN, registrert — men KØPLASSERT 2026-08-25 (operatørbeslutning, ordre 20260825T060649Z-9004613141-from-.claude, punkt 1). Fortsatt ikke et underlag, ikke et forslag, ikke bestilt — køplasseringen flytter saken fra «ligger her» til «står for tur», ikke fra åpen til avgjort. Hva køen forplikter til: §6. 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: «escaping» 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.

6. Køplassering (operatørbeslutning 2026-08-25)

Operatøren har køplassert denne saken. Ordre 20260825T060649Z-9004613141-from-.claude, punkt 1, sier det eksplisitt: «Kø SS11-budsjettfunnet neste — samme mønster som SS12-køplasseringen (egen commit/notat i det respektive plandokumentet, IKKE selve utførelsen).» Denne seksjonen er derfor køoppføringen, ikke utførelsen — i motsetning til SS12s §8 finnes det her INGEN ferdig formanalyse å henvise til: §2§4 over er et funn, ikke et sett med opsjoner. Det underlaget (hvilke(n) form(er) en eventuell §8/§10-rad skulle ta, om noen) er selve SS11-arbeidet, og er IKKE skrevet av denne oppføringen.

De to andre kandidatene som stod i samme kø (commons-spec-amendments, D-A 1/2/4 + D-F, og commons-shared-golden-referent Q4) er IKKE droppet — ordren plasserte kun SS11 først, den tok ikke stilling til de to andre.

Hva økten som tar denne saken skal gjøre, når turen kommer:

  1. Re-mål §2§4s premisser mot method-spec.md FØR den handler på dem (linjeankere er ferskvare — sitér seksjon + ordrett tekst, ikke linjenummer).
  2. Skriv selve underlaget: hvilken/hvilke form(er) løser spenningen §2 påviser (en §8-rad, en §10-rad, begge, eller ingen — §11-tabellen kan også bevisst IKKE være enumereringen av «every» i §1.3, og da er det ingen spenning å løse). Legg formene fram for operatøren; ikke velg selv.
  3. Vent på ratifisering før method-spec.md røres.

Hva køplasseringen IKKE utløser: ingen rad i method-spec.md, ingen ordlyd foreslått, ingen versjonsbump, ingen tag, ingen coord-melding. Punkt 5 over står uendret av denne oppføringen.