Merge commit 'e0fa223591'
This commit is contained in:
commit
e0d499d3d1
8 changed files with 428 additions and 46 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -730,3 +730,52 @@ etter den formuleringen finner 4 av 5 treff og står igjen med to like sannsynli
|
|||
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.*
|
||||
|
|
|
|||
83
shared/docs/plan/2026-08-02-ss11-mangler-rad-for-ss8.md
Normal file
83
shared/docs/plan/2026-08-02-ss11-mangler-rad-for-ss8.md
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue