@haus-tech/haus-workflow 5.0.0 → 5.1.0

package/library/global/skills/request/SKILL.md

@@ -65,7 +65,7 @@ respektive skill. Här bor bara routing, kontextbärande, arkivet och dispatchen
 - **Experimentdata når aldrig Asana.** `utvärdera` skriver aldrig via
   request-sync; dess enda Asana-kontakt är läsande hämtning av önskemålet i
   huvudkonversationen. `experiments/`-trädet är inte postkataloger: sync,
-  batch och guard läser bara `.haus/requests/<gid-eller-slug>/` på toppnivån
+  batch och guard läser bara `.haus-workflow/requests/<gid-eller-slug>/` på toppnivån
   och rör aldrig `experiments/`.
 - **Maskinen kör om enbart vid scriptbevisat kontraktsbrott.** Omdispatch
   (budget EN per agent) svarar på ett fel som precheck, resolve-anchors eller
@@ -74,7 +74,7 @@ respektive skill. Här bor bara routing, kontextbärande, arkivet och dispatchen
   maskinkörningar producerar fler röster, aldrig mer sanning. Ingen ny
   omkörningsmekanism får läggas till som bryter mot detta.
 
-## Arkivet: `.haus/requests/`
+## Arkivet: `.haus-workflow/requests/`
 
 Orkestreringens kuvert. De haus-hanterade request-skillsen känner inte till det;
 den här skillen (och agenterna via sina prompter) underhåller det.
@@ -84,10 +84,10 @@ samma önskemål) blir flera kataloger — poängen sätts per post, så en kata
 med flera specar går inte att bedöma.
 
 ```
-<repo-rot>/.haus/requests/<gid-eller-slug>/
+<repo-rot>/.haus-workflow/requests/<gid-eller-slug>/
 ├── spec.md                        EN spec, bytetrogen — det granskaren godkänner
-├── granskarblock.md               "## Till granskaren" (bunt: samma block
-│                                  kopieras till varje delkatalog)
+├── granskarblock.md               "## Till granskaren" (bunt: delens eget
+│                                  block, aldrig ett kopierat, ADR-0118)
 ├── impact.md                      påverkansanalysen, ordagrann inkl. sitt
 │                                  Till granskaren-block
 ├── score-pricing-vN.json           nytt varv = ny fil, skriv aldrig över
@@ -109,10 +109,15 @@ omdispatch-regeln i dispatch-kontraktet.
 - Katalognamn: Asana-gid när posten finns på brädan, annars en kebab-slug av
   spec-rubriken. Bunt utan gid: `<slug>-1`, `<slug>-2`, … När gid myntas senare:
   döp om katalogen till gid och notera sluggen i `state.json.former_slug`.
-- **Första gången arkivet skapas i ett repo:** säkerställ att `.haus/requests/`
-  står i repots `.gitignore` (lägg till raden om den saknas, säg det).
-  Prisunderlag ska inte in i kundens historik. `.haus/request.json` (syncens
-  config) förblir spårad.
+- **Gitignore ägs av haus, inte av dig.** `.haus-workflow/requests/` står i den
+  haus-hanterade `.gitignore`-blocken och skrivs av `haus apply` — lägg aldrig till
+  raden själv, och hand-editera aldrig blocket. Står arkivet ändå spårat i git:
+  kör `haus apply --write`, som både skriver regeln och avspårar filerna.
+  Prisunderlag ska inte in i kundens historik. `.haus-workflow/request.json` (syncens
+  config) förblir spårad — den är konfiguration, inte arbetsmaterial.
+- **Gammalt arkiv under `.haus/`:** flyttas av `haus apply` till
+  `.haus-workflow/` (ADR-0103). Skriv aldrig till `.haus/` igen, och flytta inte
+  själv — kör `haus apply --write` och låt kommandot göra det.
 
 ### `state.json`
 
@@ -128,13 +133,37 @@ omdispatch-regeln i dispatch-kontraktet.
   "approval": null,
   "granskarutslag": [],
   "note": null,
+  "stopp": null,
+  "respec_varv": 0,
+  "coverage_post": null,
   "runs": []
 }
 ```
 
 - `bundle` = specar ur samma önskemål (sätts av speca vid bunt).
   `split` = delposter ur ett DELA_UPP-utfall (sätts av bedöm). Båda formen
-  `{parent…, part: N, of: M}`.
+  `{parent…, part: N, of: M}`. Aldrig båda på samma katalog.
+- `stopp` = ett stopputfall som scripten bevisat utan scorer:
+  `{ "utfall": "KONCEPT" | "DIAGNOS" | "TILLBAKA_TILL_SPEC" | "ESKALERA", "kalla": "spec.md" | "impact.md" | "granskarblock.md", "date": "YYYY-MM-DD", "orsak"?: string }`.
+  Skrivs BARA av `archive.mjs stopp` (som själv kontrollerar att källan bär
+  det påstådda: kandidatmarkören i `spec.md`, etiketten `motsägelse` i
+  `impact.md`, det prisavgörande öppna valet i `granskarblock.md`, ADR-0118)
+  och nollas BARA av `archive.mjs respec`. `orsak` sätts när `utfall` är
+  `ESKALERA` (kommandot kräver `--orsak` då, så en människa ser varför posten
+  inte gick tillbaka till specen en gång till) och saknas annars.
+  `archive.mjs set-status priced` vägrar medan fältet är satt. Äldre arkiv
+  saknar fältet och läses som `null`.
+- `respec_varv` är en monoton räknare, höjd med 1 av varje `archive.mjs
+respec`-anrop (#505), aldrig nollad. Grinden i bedöm läser den för att
+  avgöra om ett kvarstående prisavgörande öppet val ska stoppa med
+  `TILLBAKA_TILL_SPEC` (första varvet) eller `ESKALERA` (andra varvet och
+  senare): en post går aldrig en tredje specrunda på samma val. Äldre arkiv
+  saknar fältet och läses som `0`.
+- `coverage_post` speglar score-kuvertets valfria `coverage_post: { yta,
+omfattning }` (ADR-0119). `archive.mjs add-run` kopierar fältet från den
+  senaste pricing-filen som bär det, skelettet (`ny-korning`/`ny-del`) sätter
+  det till `null`. `bluf` visar `täckningspost: <yta>` i `anm`-kolumnen när
+  fältet är satt.
 - `approval` skrivs av grinden i bedöm:
   `{ "source": "asana" | "manual", "by": "<namn, krävs vid manual>",
  "status_read": "<värde>", "date": "YYYY-MM-DD" }`.
@@ -215,23 +244,29 @@ omdispatch-regeln i dispatch-kontraktet.
 Modellkörningar från `utvärdera` bor i ett eget träd och är aldrig prisposter:
 
 ```
-<repo-rot>/.haus/requests/experiments/<slug>/
+<repo-rot>/.haus-workflow/requests/experiments/<slug>/
 ├── experiment.json          ticketreferens, datum, modellista, manifest-hash,
 │                            status per körning
 ├── <modell>/                `default` som modellvärde ger katalognamnet
 │                            `baseline/`
 │   ├── k1/
-│   ├── k1/korning.json      headless-svaret RÅTT: USD, tokens, dispatcher
+│   ├── k1/steg/             råsvaret per agentsteg (claude -p-JSON), inklusive
+│   │                        omdispatcher och kundtextfixar
+│   ├── k1/korning.json      summan över stegen: USD, tokens, modelUsage, antal
+│   │                        steg (report.mjs läser samma nycklar som förut)
 │   ├── k1/matning.json      startarens egen mätning: startad, avslutad, wall_ms
 │   ├── k2/                  senare körning av SAMMA modell
-│   └── k2/del-1/ …          delkataloger vid DELA_UPP
+│   └── k2/del-1/ …          delkataloger: bunt ur speca (`bundle`) eller
+│                            delning ur DELA_UPP (`split`), aldrig båda
 └── <annan modell>/k1/ …
 ```
 
-- **Två filer, två ägare.** `korning.json` är headless-svaret ordagrant och
-  ägs av CLI:n; `matning.json` är startarens klocka och ägs av oss. En
-  haus-nyckel inne i `korning.json` skulle göra den till ett blandat format
-  som inte längre går att ställa mot CLI:ns egen utdata.
+- **Två filer, två ägare.** `korning.json` skrivs av `korning.mjs` som summan
+  över stegens råsvar, som ligger orörda i `steg/`; `matning.json` är
+  startarens klocka. En haus-nyckel i ett råsvar under `steg/` skulle göra det
+  till ett blandat format; summan bär därför sina egna nycklar
+  (`korningsmotor`, `steg`, `modellverifiering`) och råsvaren rörs aldrig
+  (ADR-0113 amends ADR-0094).
 - **Ingen körning skrivs någonsin över.** Värdet i en gammal körning är att
   kunna jämföra samma modell före och efter en ändring i skillen eller
   agentprompterna; skriver en ny körning över den är den jämförelsen borta för
@@ -240,13 +275,28 @@ Modellkörningar från `utvärdera` bor i ett eget träd och är aldrig prispost
   bytetroget (spec.md, granskarblock.md, impact.md, pricing-JSON, state.json,
   `runs[]`-reglerna), så `precheck.mjs` och `contract-check.mjs` fungerar
   oförändrade, de pekas bara på `<modell>/k<N>/`. Proveniensen följer med gratis.
+- **Buntregeln: `del-N/` är antingen bunt eller delning, aldrig båda.** En
+  bunt ur speca (flera specar ur samma önskemål) läggs som `del-1/ … del-N/`
+  under körningskatalogen med `bundle` satt i varje dels `state.json`; en
+  delning ur DELA_UPP läggs likadant men med `split` satt. Del 1 ligger ALDRIG
+  i körningsroten: roten bär bara `state.json` (skelettet `ny-korning` skrev),
+  `korning.json` och `matning.json`, så en rot utan `spec.md` men med delar
+  läses som `bunt (N delar)` av `bluf` och rapporten. DELA_UPP inuti en
+  buntdel ger `del-N/del-M`. `sparr`, `precheck` och `stopp` körs per del;
+  `proveniens` och `bluf` pekas på `k<N>` och går rekursivt genom delarna.
+  **Produktionslayouten är oförändrad** (`speca` steg 5: del 1 behåller
+  gid-katalogen, syskonen blir `<slug>-N`); det är `korning.mjs` som väljer
+  experimentlayouten, alltid mot katalogen `--katalog` pekar ut.
 - **Numret allokeras aldrig av skillen själv**, alltid med
-  `archive.mjs ny-korning <modellkatalog>`, som skapar katalogen
-  atomiskt och skriver dess sökväg. Två samtidiga processer, till exempel två
-  Claude-konton mot samma checkout, får då `k2` och `k3`, aldrig samma katalog.
-  Räknar skillen själv förlorar den ena processens körning tyst.
-- `state.json` i en körningskatalog bär markören `"experiment": true`.
-  `approval` förblir `null` och `status` blir ALDRIG `priced`: ett
+  `archive.mjs ny-korning <modellkatalog> [--request-id <gid eller slug>]`,
+  som skapar katalogen atomiskt, skriver skelettet till dess `state.json`
+  (`"experiment": true`, `"stopp": null`, `approval: null`, tomma `runs[]`)
+  och skriver katalogens sökväg på stdout. Två samtidiga processer, till
+  exempel två Claude-konton mot samma checkout, får då `k2` och `k3`,
+  aldrig samma katalog. Räknar skillen själv förlorar den ena processens
+  körning tyst.
+- `state.json` i en körningskatalog bär markören `"experiment": true` ur
+  skelettet. `approval` förblir `null` och `status` blir ALDRIG `priced`: ett
   experimentresultat kan inte förväxlas med en prispost.
 - Katalognamnet `experiments` är reserverat: en spec vars rubrik skulle sluggas
   till `experiments` får suffixet `-post`.
@@ -254,8 +304,9 @@ Modellkörningar från `utvärdera` bor i ett eget träd och är aldrig prispost
   körning: `"klar"`, `"ofärdig"`, `"stopp"`, `"väntar på dom"`. Literalerna
   skrivs exakt så, mellanslag och diakritiska tecken inkluderade. Äldre filer
   med `baselinemodell` och `kandidatmodell` läses utan fel; nya skrivningar
-  använder bara `varianter`.
-- `experiments/` ärver gitignore-skyddet från `.haus/requests/`.
+  använder bara `varianter`. Filen skrivs BARA av `archive.mjs experiment`
+  (se `utvärdera` steg 1), aldrig för hand.
+- `experiments/` ärver gitignore-skyddet från `.haus-workflow/requests/`.
 
 ## Uppgift: `speca`
 
@@ -267,6 +318,17 @@ Modellkörningar från `utvärdera` bor i ett eget träd och är aldrig prispost
    (vyer/termer önskemålet nämner), tidigare specar för samma kund (arkivet +
    brädan), ev. brief. **Alla sökvägar i manifestet absoluta.** Finns inget repo
    i sessionen: skriv `KÄLLOR: inga — allt blir antaganden` så specifiern vet.
+   Starten avgör samtidigt två rader som specifiern aldrig får gissa:
+   `SPRÅK:` (`svenska` eller `engelska`, avläst ur önskemålets brödtext;
+   rubrikskelettet i `RUBRIKER:` följer det språket, se promptmallen) och
+   `DEPS:` (`installerade` när `node_modules/` eller motsvarande finns under
+   REPO-ROT, annars `saknas`; utan repo alltid `saknas`).
+   Skriv manifestet till `<katalog>/kallmanifest.md` i varje katalog specen
+   arkiveras i (steg 5), så att `bedöm` kan ge assessorn samma manifest utan
+   att bygga ett nytt.
+   Manifestet har sist sektionen `## Avgjorda val`: varje val som en människa
+   avgjort efter ett tidigare stopp, en rad var, ordagrant som svaret gavs;
+   `inga` om inga. Specifiern får aldrig flagga ett val som står där.
 3. **Eskaleringsbedömning.** Misstänkt bunt (flera beslut), behörighet/betalning/
    oåterkallelig data/personuppgifter, eller offertunderlag → utfallet är
    prisbärande och eskaleringen är ett MODELLBYTE, inte en flagga: dispatcha
@@ -274,10 +336,15 @@ Modellkörningar från `utvärdera` bor i ett eget träd och är aldrig prispost
    `request-specifier`, med `ESKALERAD: ja` plus orsaken i prompten.
 4. **Dispatcha `request-specifier`** (eller den eskalerade varianten enligt
    steg 3) enligt promptmallen i dispatch-kontraktet.
-5. **Arkivera.** Dela svaret vid `## Till granskaren`. En spec → en katalog:
-   allt före blocket är specarna; VARJE spec får sin egen katalog med egen
-   `spec.md` och eget `state.json` (bunt: `bundle`-fältet ifyllt, blocket
-   kopieras till varje katalog som `granskarblock.md`). Bunt ur en gid-post:
+5. **Arkivera.** Specifierns svar delas per spec (ADR-0118): varje titelrad
+   startar en ny spec, och specens EGET `## Till granskaren`-block avslutar
+   den. Ett svar med bara ETT block efter flera specar (gamla formatet) är en
+   brist: `korSpecifier` dispatchar om HELA specifierprompten en gång med
+   `RÄTTNINGAR:` innan någon katalog skapas, och kvarstår bristen (delat block
+   eller ett saknat block) blir steget `ofärdig` direkt, utan katalog. En
+   spec → en katalog: VARJE spec får sin egen katalog med egen `spec.md`,
+   eget `granskarblock.md` (delens eget block, aldrig ett kopierat) och eget
+   `state.json` (bunt: `bundle`-fältet ifyllt). Bunt ur en gid-post:
    del 1 behåller gid-katalogen, resterande delar får slug-kataloger med
    `bundle.parent_slug` satt till gid:t; syskontasks på brädan mintas först
    vid sync. Stämpla varje berörd `state.json` med
@@ -289,11 +356,14 @@ på request-write-spec/references/specformat.md>`. Scriptet sätter
    referens-hashen måste sättas explicit precis som för poängen, annars
    tappas specformatets proveniens (se runs-kontraktet).
    **Respec över befintlig katalog invaliderar analysen:** när `spec.md`
-   ersätts döps ev. `impact.md` om till `impact-superseded-<datum>.md`,
-   status sätts till `spec_draft`, `approval` nollas och `granskarutslag`
-   töms — en ny spec är ogranskad per definition, ett utslag mot en ersatt
-   spec är inte längre giltigt, och en gammal analys mot ny spec är exakt
-   den skevhet proveniens-kontrollen finns för att stoppa.
+   ersätts i en katalog som redan har en, kör
+   `node <skillkatalog>/scripts/archive.mjs respec <katalog>` INNAN den nya
+   specen skrivs. Kommandot äger hela invalideringen (analysen läggs undan
+   som superseded, status, `approval`, `granskarutslag` och `stopp` återställs,
+   `runs[]` rörs aldrig); skriv aldrig de fälten för hand. Skälet står i
+   runs-kontraktet: en ny spec är ogranskad per definition, ett utslag mot en
+   ersatt spec är inte längre giltigt, och en gammal analys mot ny spec är
+   exakt den skevhet proveniens-kontrollen finns för att stoppa.
 6. **Formkontroll.** Kör `node <skillkatalog>/scripts/precheck.mjs <katalog>`
    per katalog. BRISTER i spec/granskarblock → dispatcha om specifiern EN gång
    enligt omdispatch-regeln. **Det förkastade utkastet får kvitto
@@ -304,9 +374,35 @@ på request-write-spec/references/specformat.md>`. Scriptet sätter
    dispatch får sin egen runs-rad — även den förkastade — så arkivet bär
    både att ett omtag skedde och varför; en spec godkänd i andra försöket
    får aldrig se ut som en som blev rätt direkt.
+   **Omdispatch gäller endast den spec som föll.** I en bunt rörs de specar
+   som passerade inte: omdispatchprompten bär hela ursprungsprompten plus
+   `RÄTTNINGAR:` med felraderna för just den specen och raden
+   `Returnera endast spec <N>`; svaret ersätter bara den katalogens utkast.
+   **Kvarstår brist efter omdispatch blir utkastet aldrig `spec.md`:** även
+   det andra utkastet arkiveras som `spec-avvisad-<datum>.md` med egen
+   runs-rad, katalogen står utan `spec.md` och behåller status `spec_draft`,
+   och i `utvärdera` blir körningen `"ofärdig"`. Visa bristerna och stanna.
+   **Kandidat stoppas här, aldrig i bedöm.** Skriver precheck raden
+   `KANDIDAT: KONCEPT` eller `KANDIDAT: DIAGNOS` (specen bär markörraden ur
+   specformatets kandidatform), kör direkt
+   `node <skillkatalog>/scripts/archive.mjs stopp <katalog> --utfall <utfallet ur raden> --kalla spec.md`
+   på den katalogen: en kandidat har inget analys- eller poängsteg att vänta
+   på, och `stopp`-fältet är det som gör utfallet synligt för `bluf`,
+   rapporten och `set-status`. Kandidatens katalog kan fortfarande läggas på
+   brädan i steg 7 (kunddialogen är nästa steg för den), men `bedöm` hoppar
+   över den.
+   **Prisavgörande öppet val stoppas här (ADR-0118).** Skriver precheck raden
+   `PRISAVGORANDE: <valet>` (granskarblockets rad `Prisavgörande öppet val:
+ja: …`), kör `archive.mjs stopp <katalog> --utfall TILLBAKA_TILL_SPEC
+--kalla granskarblock.md` och visa valet i kundens språk; ingen assessor.
+   Är `state.json.respec_varv` redan ≥ 1 kör i stället `--utfall ESKALERA
+--kalla granskarblock.md --orsak "prisavgörande val kvarstår efter respec:
+<valet>"`: en människa dömer, posten går aldrig en tredje specrunda. När
+   valet avgjorts skrivs svaret under `## Avgjorda val` i manifestet, sedan
+   `respec` och ny specifier-dispatch.
    BRISTER i `state.json` är wrapperns egna filer och
-   rättas av wrappern själv, aldrig via omdispatch. Kvarstår brister, visa dem
-   och stanna. VARNING:ar visas men stoppar inget.
+   rättas av wrappern själv, aldrig via omdispatch. VARNING:ar visas men
+   stoppar inget.
 7. **Svara BLUF:** en rad per spec (rubrik + ev. flaggor), sedan granskarblocket
    i sin helhet. Erbjud att lägga specarna på brädan via request-sync (🔍) — gör
    det bara på uttrycklig begäran. När en post läggs på brädan: sätt status
@@ -325,7 +421,7 @@ driftvakt.
      Endast `✅ Spec ok` (normaliserad på alfabetiska kärnan) släpper igenom.
      Annan status: visa den och stanna. En inklistrad spec för en post som har
      gid räknas inte — det är brädstatusen som gäller, läs den ändå.
-   - **Posten saknar gid MEN repot har `.haus/request.json`:** vägra — repot är
+   - **Posten saknar gid MEN repot har `.haus-workflow/request.json`:** vägra — repot är
      kopplat till en bräda, så en gid-lös post ska in via intaget och granskas
      där, inte prissättas vid sidan av. Grinden är värd något bara om den inte
      går att kliva runt.
@@ -343,53 +439,93 @@ driftvakt.
    specblock är en BRIST — dela posten enligt arkivregeln innan något dispatchas.
    Övriga BRISTER → åtgärda ledet som brister (om spec: tillbaka till
    speca-steget) innan något dyrt dispatchas.
+   **`KANDIDAT:`-raden avgör före allt annat.** Skriver precheck
+   `KANDIDAT: KONCEPT` eller `KANDIDAT: DIAGNOS` (raden kommer alltid, även
+   vid exit 1) är posten en kandidat: hoppa över steg 3 till 7, kör
+   `archive.mjs stopp <katalog> --utfall <utfallet ur raden> --kalla spec.md`
+   om `stopp` inte redan är satt (speca steg 6 brukar ha gjort det;
+   ett identiskt omanrop är ofarligt), och routa posten som stopputfallet
+   nedan. Ingen analys och ingen poäng får någonsin dispatchas på en
+   kandidat.
 3. **Analys.** Saknas `impact.md`, eller fäller precheck den på
    underlagsproveniens (analysen gjordes mot en annan spec): kräver repo i
    sessionen (annars stopp — en gissad analys är förbjuden av skillen själv).
    Dispatcha `request-assessor` enligt promptmallen — specens granskarblock
    skickas med som internt underlag (samma förtroendedomän; flaggorna där är
-   ofta analysens viktigaste ingång). Arkivera svaret som `impact.md`
+   ofta analysens viktigaste ingång). Promptens `KÄLLOR:`-rad bär
+   `kallmanifest.md` ur katalogen ordagrant, eller `inga` när filen saknas;
+   assessorn verifierar manifestet själv och ska aldrig ta det för sant
+   (ADR-0113: assessorn utforskade repot från noll trots att manifestet redan
+   fanns). Arkivera svaret som `impact.md`
    (inklusive dess "## Till granskaren"-block — visa blocket för användaren,
    aldrig till kundfält), stämpla med
    `node <skillkatalog>/scripts/archive.mjs add-run <katalog> --file impact.md
 --skill request-assess-impact --agent request-assessor
 --model <ur MODELL-svansraden>` (scriptet sätter `underlag_sha256` mot
-   `spec.md`). Kör precheck igen med `--impact`. Fäller precheck det nya
+   `spec.md`). Kör precheck igen med `--impact`. Läs sedan raden
+   `AVVIKELSE: <etikett>` ur precheck-utskriften (etiketten på analysens rad
+   `**Avvikelse mot specen:**`; inte att förväxla med agenternas svansrad):
+   `motsägelse` betyder att specen förutsätter något som inte stämmer i
+   systemet, och då kör
+   `node <skillkatalog>/scripts/archive.mjs stopp <katalog> --utfall TILLBAKA_TILL_SPEC --kalla impact.md`
+   (kommandot sätter status `assessed`), hoppa över steg 4 till 7 och routa
+   posten som stopputfallet nedan: ingen scorer dispatchas på ett underlag
+   som redan säger att specen måste tillbaka. `ingen` och `precisering` går
+   vidare till steg 4. Fäller precheck det nya
    utkastet → omdispatcha assessorn EN gång enligt omdispatch-regeln, och ge
    det förkastade utkastet kvitto precis som i speca steg 6: arkivera det som
    `impact-avvisad-<datum>.md` och stämpla en egen runs-rad med kontrollens
    felrader i `--note` (ADR-0099).
 4. **Prissättning.** Dispatcha `request-scorer` enligt promptmallen.
    Ingen prislista, inget repo, inga andra posters dokument i prompten.
-5. **Ankarlösning och kontraktskontroll.** Strippa svansraderna (`MODELL:`,
-   `LÄSTA:`, ev. `AVVIKELSE:`) ur svaret. Kör
-   `node <skillkatalog>/scripts/check-lasta.mjs "<LÄSTA-radens innehåll>" <spec.md> <impact.md>`
-   (exit 1 = kontraktsbrott, se dispatch-kontraktet). Skriv sedan den rena
-   JSON:en till fil och kör i ordning:
-   `node <skillkatalog>/scripts/resolve-anchors.mjs <svar.json> <spec.md> <impact.md>`
-   (löser beläggsankare till ordagranna källblock; OLÖST/FLERTYDIG är ett
-   kontraktsbrott), sedan
-   `node <skillkatalog>/scripts/contract-check.mjs <svar.json> <spec.md> <impact.md> --expect-id <katalogens id>`.
-   BROTT från något av scripten → dispatcha om scorern EN gång enligt
+5. **Ankarlösning och kontraktskontroll.** Skriv agentens hela svarstext (JSON
+   plus svansrader) till fil och kör
+   `node <skillkatalog>/scripts/kontroll.mjs <svar.txt> <spec.md> <impact.md> --expect-id <katalogens id> --ut <svar.json> --fixa-kundtext --state <katalog>/state.json`.
+   `--state` ger contract-check split-status: `OVER_SKALAN` på något som inte
+   är en split-del fälls, och ett inget-tak-utfall utan steg mot A16 fälls
+   (#503). Scriptet strippar svansraderna (`MODELL:`, `LÄSTA:`, ev. `AVVIKELSE:`),
+   reparerar det dispatchern redan vet (`request_id`, enumform,
+   siffersträngar, LÄSTA-radens sökvägsform) och kör check-lasta,
+   `resolve-anchors.mjs` (beläggsankare till ordagranna källblock;
+   OLÖST/FLERTYDIG är ett kontraktsbrott) och contract-check i en process; ett
+   protokollterm-brott i ett rent kundtextfält skrivs om av en billig modell i
+   stället för att kosta en ny scorerkörning. `REPARERAT:`-raderna visas i
+   BLUF-svaret och skrivs i runs-radens `--note`.
+   `impact.md` skickas ALLTID med till contract-check, aldrig bara specen:
+   scriptet läser etiketten på `**Avvikelse mot specen:**` och fäller varje
+   annat utfall än TILLBAKA_TILL_SPEC när analysen bär `motsägelse`
+   (motsägelsegrinden i scriptet är bältet, steg 3 hängslena; en post som
+   ändå nått hit har ett underlag scriptet ska få se). Samma script kräver
+   att varje `bracket.steps[i]` är exakt `{anchor, relation, grund}`.
+   BROTT som kvarstår efter reparationerna → omdispatch EN gång enligt
    omdispatch-regeln, med felraderna i prompten. Kvarstår brott: visa dem och
    stanna utan att arkivera svaret som giltigt varv, men släng det inte:
    arkivera som `score-pricing-vN-avvisad.json` (utanför N-räkningen) med
    kontrollens felrader i en runs-rad, så även misslyckade körningar har
    kvitto. En `AVVIKELSE:`-rad visas alltid för användaren.
-6. **Dubbelkörning (driftvakt).** Körs BARA när svaret inte är ett
-   stopputfall — stopproutningen nedan går alltid först, en post som ändå
-   går till människa ska inte kosta extra körningar. Trigger: poängen är ≥ 1
-   (ADR-0098: tröskeln täcker minst det den borttagna klassaxelns
-   MEDIUM/LARGE/OFFERT-villkor täckte; poängen multipliceras direkt till
-   pris). Dispatcha då `request-scorer` EN gång till,
-   samma prompt, ny isolerad körning.
-   Kostnaden (en extra körning) läggs medvetet exakt där pengarna står
-   på spel — poängen multipliceras direkt till pris och skillens eget
-   acceptanstest är att två oberoende körningar ger samma resultat.
+6. **Dubbelkörning (driftvakt).** Körning 2 startar ALLTID samtidigt med
+   körning 1, med samma prompt och i en ny isolerad körning; i produktion
+   dispatchas båda Agent-anropen på en gång (#500, ADR-0113), promptarna är
+   identiska och körningarna oberoende. Trigger: poängen är ≥ 1 (ADR-0098),
+   eller utfallet är `OVER_SKALAN` (ADR-0116: det utfallet skickar posten
+   till manuell offert och är prisbärande; två OVER_SKALAN med olika golv är
+   OLIKA och går till dom). Övriga stopputfall dubbelkörs inte: DELA_UPP körs
+   om per del, KONCEPT/DIAGNOS/TILLBAKA_TILL_SPEC går till människa ändå.
+   Tröskeln avgör bara om paret RÄKNAS som dubbelkörning, aldrig om
+   körning 2 startar. Blir körning 1 ett stopputfall utom OVER_SKALAN, eller
+   poäng under 1, arkiveras körning 2 som `-run2` med `superseded_by` mot
+   huvudfilen och en notering om att den inte krävdes, den räknas aldrig som
+   dubbelkörning, och stopproutningen nedan gäller som förut. I övriga fall
+   jämförs paret som nedan; skillens eget acceptanstest är att två oberoende
+   körningar ger samma resultat.
    - Kör hela steg 5 (ankarlösning, sedan kontraktskontroll) på det nya
      svaret först, med egen omdispatch-budget (EN).
    - Jämför sedan deterministiskt:
-     `node <skillkatalog>/scripts/compare-scores.mjs <poäng1.json> <poäng2.json>`
+     `node <skillkatalog>/scripts/compare-scores.mjs <poäng1.json> <poäng2.json>`.
+     Scriptet diffar även de inre stegen: samma ankare i `bracket.steps` läst
+     som `storre` i ena körningen och `mindre` i den andra är en hård diffrad
+     (OLIKA), aldrig en toleransrad. Golv- och takankaren är undantagna, de
+     flippar av konstruktion när banden angränsar och ägs av toleransregeln.
    - **LIKA** → körning 1 gäller: `double_run: "bekräftad"` på dess
      runs-rad. Körning 2-filen arkiveras som `score-pricing-vN-run2.json`
      med SAMMA N och `superseded_by` satt till körning 1-filen.
@@ -417,7 +553,11 @@ driftvakt.
      skillnaden ligger inom toleransen. Sätt `double_run: "tolerans"` på
      bägge runs-raderna. Toleransen är en medveten prisregel: högsta
      värdet skyddar marginalen, och ett medelvärde räknas fortfarande
-     aldrig fram. Visa toleransraderna i BLUF-svaret.
+     aldrig fram. Visa toleransraderna i BLUF-svaret. Ett par av två
+     `OVER_SKALAN` med SAMMA golv där bara konfidensen skiljer skriver
+     också `LIKA_TOLERANS`, men utan poäng att jämföra (OVER_SKALAN bär
+     `score: null`) vinner körning 1 deterministiskt, aldrig "högsta
+     poängen" (ADR-0116).
    - Exit 2 från jämförelsescriptet är ett dispatcherfel (ojämförbara
      körningar) — visa felet och stanna, rapportera aldrig LIKA.
 7. **Arkivera** godkända JSON-svar. Hämta varvets N med
@@ -425,14 +565,18 @@ driftvakt.
    skriv filerna (`score-pricing-vN.json`, körning 2
    som `-run2`, avvisade som `-avvisad`), och stämpla VARJE körning med
    `archive.mjs add-run` (flaggor för fil, skill, agent, modell ur
-   MODELL-svansraden, effort ur agentdefinitionen, referens-hash via `--ref`
-   för skillens referensfil (se runs-kontraktet), double-run-utfall,
-   superseded-by, partial-rerun och pairs-with där de gäller). Exempel för
-   huvudfilen vid ett bekräftat par:
+   MODELL-svansraden som förut, referens-hash via `--ref` för skillens
+   referensfil (se runs-kontraktet), double-run-utfall, superseded-by,
+   partial-rerun och pairs-with där de gäller). Effort läser scriptet självt
+   ur agentdefinitionen under Claude-konfigkatalogen när `--effort`
+   utelämnas, så utelämna flaggan; `--model` förblir obligatorisk och kommer
+   ur svansraden, aldrig ur definitionen (under `utvärdera` körs agenterna
+   med override, så definitionens modell är per konstruktion inte den som
+   kördes). Exempel för huvudfilen vid ett bekräftat par:
    `node <skillkatalog>/scripts/archive.mjs add-run <katalog>
 --file score-pricing-v1.json --skill request-score
 --agent request-scorer --model <ur MODELL-svansraden>
---effort <ur agentdefinitionen> --ref poangskala.md=<hash via
+--ref poangskala.md=<hash via
 ref-hash.mjs på request-score/references/poangskala.md>
 --double-run bekräftad`. `--double-run` tar ENDAST de tre
    literalerna `bekräftad`, `olika` eller `tolerans` (scriptet vägrar allt
@@ -444,7 +588,12 @@ ref-hash.mjs på request-score/references/poangskala.md>
    `archive.mjs set-status <katalog> priced` (scriptet vägrar vid spärr,
    stopputfall och experiment — se runs-kontraktet)
    eller `assessed`.
-8. **Svara BLUF:** tabell `post · poäng · utfall · konfidens`, en rad
+8. **Svara BLUF:** tabellen kommer ur
+   `node <skillkatalog>/scripts/archive.mjs bluf <katalog>` och klistras in
+   som den är (`| post | poäng | utfall | konfidens | anm |`, en rad per
+   katalog och del; poängen ur filerna, stopputfall ur `stopp`, OLIKA och
+   tolerans i `anm`), ALDRIG handskriven: en handskriven tabell
+   felrapporterade i skarp körning. Under tabellen en rad
    per avvikelse värd att se (ESKALERA, DELA_UPP,
    INPUT_SAKNAS, AVVIKELSE-rader). JSON:en visas inte i chatten —
    `detaljer <post>` gör det. Skriv-tillbaka till brädan sker via request-sync
@@ -458,14 +607,23 @@ fil (steg 7), statusen blir `assessed`, aldrig `priced`, och posten routas:
 - `DELA_UPP` → föreslå ny analysrunda per del; delarna blir egna kataloger med
   `split` satt (`part`/`of`), och en del utan tak blir `OVER_SKALAN`, aldrig
   DELA_UPP igen. Delposter ärver enligt skillen postens spec och skriver aldrig
-  en egen: förälderns `spec.md` och `granskarblock.md` KOPIERAS in i varje
-  delkatalog (som buntens granskarblock), medan `impact.md` skrivs per del av
-  den nya analysrundan.
+  en egen: förälderns `spec.md` och `granskarblock.md` KOPIERAS oförändrade in
+  i varje delkatalog, var för sig (ett granskarblock per delkatalog, ADR-0118,
+  ingen delkatalog delar sitt block med en annan), medan `impact.md` skrivs per
+  del av den nya analysrundan.
 - `OVER_SKALAN` → posten offereras separat; delas aldrig vidare (delningen görs
   ett steg, skillens egen regel).
 - `TILLBAKA_TILL_SPEC` / `KONCEPT` / `DIAGNOS` → tillbaka till spec-steget
-  respektive kunddialog; visa skälet.
-- `ESKALERA` / `INPUT_SAKNAS` → visa skälet och stanna.
+  respektive kunddialog; visa skälet. Kom utfallet ur scripten (kandidat i
+  `spec.md`, `motsägelse` i `impact.md`, prisavgörande öppet val i
+  `granskarblock.md`, ADR-0118) bär `state.json.stopp` det via
+  `archive.mjs stopp` och det finns ingen varvsfil; kom det ur scorern
+  arkiveras varvsfilen som förut och `stopp` förblir `null` (kommandot tar
+  bara de tre scriptbevisade källorna: `spec.md`, `impact.md`,
+  `granskarblock.md`). En respec nollar `stopp`.
+- `ESKALERA` / `INPUT_SAKNAS` → visa skälet och stanna, eller ett prisavgörande
+  val som kvarstår efter respec (källa `granskarblock.md`, orsak i
+  `stopp.orsak`, ADR-0118).
 
 ## Uppgift: `status`
 
@@ -624,12 +782,11 @@ dubbelkörning väntar på `döm`, precis som i produktion.
 `utvärdera rapport` (se avsnitten nedan). Argumentreglerna nedan gäller aldrig
 de orden; de klassificeras varken som modell eller post-id.
 
-**Flaggorna plockas bort först.** `--om`, `--hoppa-över` och `--körning
-<katalog>` (flaggan plus dess värde) lyfts ur argumentlistan INNAN skanningen
-nedan börjar, och räknas varken som modell eller post-id. Utan det steget
-stoppar svepets egen rad, som slutar med `--körning <katalog>`, skanningen
-omedelbart, noll modeller hittas, och kommandot faller på "Minst en modell
-krävs" trots att modellen står där.
+**Flaggorna plockas bort först.** `--om` och `--hoppa-över` lyfts ur
+argumentlistan INNAN skanningen nedan börjar, och räknas varken som modell
+eller post-id. Utan det steget stoppar en flagga skanningen, noll modeller
+hittas, och kommandot faller på "Minst en modell krävs" trots att modellen
+står där.
 
 **Argumenttolkning.** Kvarvarande avslutande argument avgörs höger till vänster
 för att hitta GRÄNSEN mot post-id-listan: ett argument räknas som modell bara
@@ -668,34 +825,62 @@ Frågan gäller alltså kostnaden, inte risken att förlora data.
 
 1. **Underlag.** Som `speca` steg 1: rått önskemål eller gid — vid gid hämtas
    posten läsande via request-sync i huvudkonversationen, uppgiftens ENDA
-   Asana-kontakt. Skapa `experiments/<slug>/` och `experiment.json` med
-   ticketreferens, datum och `varianter` i deklarationsordning.
-
-   Anteckna samtidigt postens `permalink_url` i `experiment.json` när gid-svaret
-   bär det. Det kommer ur samma läsande hämtning som redan görs, så steget får
-   ingen ny Asana-kontakt. Saknas fältet i svaret skrivs det inte, och rapporten
-   visar då gid som ren text: Asanas permalänk bär ett workspace-gid som inte
-   finns på experimentytan, så en konstruerad URL vore en gissning.
-
-   **`experiment.json` skrivs läs-modifiera-skriv, aldrig från noll.** Saknas
-   filen skapas den. Finns den redan läses den in FÖRST och uppdateras sedan:
-   `varianter` slås ihop som UNION med bevarad deklarationsordning, de
-   befintliga namnen först och invokationens nya namn efter, och en befintlig
-   körnings `status` skrivs aldrig över av en process som inte äger just den
-   körningen. En headless-process med en enmodellslista rör alltså bara sin
-   egen modell. Utan regeln raderar `fable`-körningen en vecka senare `opus`
-   och `sonnet` ur filen, och eftersom det är den här filen
-   återupptagningsregeln läser (se Återupptagbart nedan) slutar ett återupptaget
-   svep känna igen färdiga körningar och betalar om för dem. Skrivningen ska
-   vara ATOMISK: skriv till en temporärfil i samma katalog och byt namn.
-   `experiment.json` är den enda filen på experimentytan som delas mellan
-   samtidiga processer utan den låsning `archive.mjs ny-korning` ger
-   körningskatalogerna, så samtidighetsdisciplinen måste stå här i stället.
-
-2. **Källmanifest EN gång.** Bygg manifestet som i `speca` steg 2 och
-   återanvänd det byteidentiskt i ALLA varv. Anteckna manifest-hash i
-   `experiment.json` (`ref-hash.mjs` på manifesttexten). Enda avsedda
+   Asana-kontakt. Skapa `experiments/<slug>/` och skriv underlaget till disk
+   med fasta namn: önskemålet ordagrant som `experiments/<slug>/onskemal.md`
+   och källmanifestet (steg 2) som `experiments/<slug>/kallmanifest.md`.
+   Namnen är fasta därför att `korning.mjs` (steg 4) läser dem därifrån och
+   bygger varje agentprompt av dem; ett underlag som bara finns i
+   konversationen når aldrig en headless-process.
+
+   Skapa sedan `experiment.json` med ticketreferens, datum och `varianter` i
+   deklarationsordning, alltid genom kommandot:
+
+   ```
+   node <skillkatalog>/scripts/archive.mjs experiment experiments/<slug> \
+     --satt request_id=<gid> --satt title=<titel> --satt permalink_url=<url> \
+     --satt datum=<YYYY-MM-DD> --satt sprak=<svenska|engelska> --satt manifest_sha256=<hash> \
+     --satt eskalerad=<true|false> --satt eskaleringsorsak=<text> \
+     --variant <m>...
+   ```
+
+   Nyckelnamnen är rapportens: `report.mjs` läser `request_id`, `title`,
+   `permalink_url` och `datum`, och `svep.mjs` läser `request_id` (med
+   `ticket` som reserv i äldre filer) till varje varvs REQUEST_ID. Äldre
+   filer med `ticket`/`titel` läses som förut men skrivs inte längre.
+   `manifest_sha256` (steg 2) och `eskalerad`/`eskaleringsorsak` (steg 3)
+   sätts när de är kända, i egna anrop av samma kommando; ett fält som redan
+   bär samma värde är no-op. `sprak` avläses ur önskemålets brödtext av
+   huvudkonversationen, precis som i `speca` steg 2; `korning.mjs` vägrar
+   starta utan den (den gissar aldrig språk, ADR-0114).
+
+   Anteckna samtidigt postens `permalink_url` (`--satt permalink_url=<url>`)
+   när gid-svaret bär det. Det kommer ur samma läsande hämtning
+   som redan görs, så steget får ingen ny Asana-kontakt. Saknas fältet i
+   svaret skrivs det inte, och rapporten visar då gid som ren text: Asanas
+   permalänk bär ett workspace-gid som inte finns på experimentytan, så en
+   konstruerad URL vore en gissning.
+
+   **`archive.mjs experiment` är den ENDA skrivaren av `experiment.json`.**
+   Ingen process, varken huvudkonversationen, startaren eller den inre
+   processen, skriver filen för hand. Kommandot skapar filen om den saknas
+   och läser annars in den först: `varianter` slås ihop som UNION med bevarad
+   deklarationsordning (befintliga namn först, invokationens nya efter), en
+   befintlig körnings `status` skrivs aldrig över av en process som inte äger just den
+   körningen, och skrivningen är ATOMISK under ett lås i experimentkatalogen. Skälet till att det är ett kommando: `experiment.json`
+   är den enda filen på experimentytan som delas mellan samtidiga processer,
+   och låset är det som gör parallella körningar (steg 4) säkra. Utan det
+   tappar två samtidiga processer varandras rader, vilket är exakt vad som
+   hände sonnet/k4 i IPC 14001 (#493).
+
+2. **Källmanifest EN gång.** Bygg manifestet som i `speca` steg 2, skriv det
+   till `experiments/<slug>/kallmanifest.md` (steg 1) och
+   återanvänd det byteidentiskt i ALLA varv. Anteckna manifest-hash med
+   `archive.mjs experiment experiments/<slug> --satt manifest_sha256=<hash>`
+   (`ref-hash.mjs` på manifesttexten). Enda avsedda
    skillnaden mellan varven är modellen.
+   Manifestet har sist sektionen `## Avgjorda val`: varje val som en människa
+   avgjort efter ett tidigare stopp, en rad var, ordagrant som svaret gavs;
+   `inga` om inga. Specifiern får aldrig flagga ett val som står där.
 3. **Eskaleringsvalet görs en gång** enligt `speca`:s regler och gäller alla
    varv, även eskaleringsvalet är en del av det som hålls konstant.
    Triggar valet: agenten blir `request-specifier-eskalerad` i stället för
@@ -705,157 +890,223 @@ Frågan gäller alltså kostnaden, inte risken att förlora data.
    över av varvets modell. Eskaleringsmekanismen kollapsar alltså medvetet
    under override, det är avsett, inte en lucka: `utvärdera` mäter en ren
    modellskillnad över alla tre rollerna och testar aldrig
-   eskaleringsbeslutet i sig.
-4. **Ett varv per modell i listan**, sekventiellt, i deklarationsordning.
-   Varje varv är EN egen headless-process, och det är det som ger mätningen
-   gratis. Ansvaret delas, eftersom en process aldrig kan känna sin egen
-   slutkostnad:
-
-   **Startaren** (huvudkonversationen, eller svepets loop) gör per modell:
-   allokerar körningskatalogen med `archive.mjs ny-korning`, startar
-   `claude -p --model sonnet --output-format json` med katalogen som explicit
-   argument, väntar in processen, och skriver JSON-svaret rått till
-   `<modell>/k<N>/korning.json`. Rapporten läser sedan `total_cost_usd`,
-   `usage.input_tokens`, `usage.output_tokens`,
-   `usage.cache_read_input_tokens`, `usage.cache_creation_input_tokens` och
-   `subagent_stats.spawned` ur den filen.
-
-   **Startaren tar tiden runt processen** och skriver `<modell>/k<N>/matning.json`
-   med `startad`, `avslutad` (båda ISO 8601) och `wall_ms` (differensen).
-   Filen skrivs ÄVEN när processen faller: en kraschad körning har en klocktid,
-   och den är ofta det intressantaste talet i tabellen. Rapporten läser
-   väggtiden därifrån, aldrig ur `korning.json`. Skälet är detsamma som för
-   kostnaden: en process kan inte känna sin egen klocktid när arbetet ligger i
-   bakgrundssubagenter, och svarets `duration_ms` räknar inte in väntan på dem.
-   `korning.json` förblir headless-svaret rått, därav den egna filen.
-
-   Startaren stämplar samtidigt körningens `state.json` med `proveniens`:
+   eskaleringsbeslutet i sig. Valet antecknas med
+   `archive.mjs experiment experiments/<slug> --satt eskalerad=<true|false> --satt eskaleringsorsak=<text>`;
+   det är därifrån `svep.mjs` läser `ESKALERAD:` till varje varvs prompt.
+4. **Ett varv per modell i listan**, startat av `svep.mjs`. Huvudkonversationen
+   förbereder steg 1 till 3 och kör sedan, även för en enda post och en enda
+   modell:
 
    ```
-   node <skillkatalog>/scripts/archive.mjs proveniens <modell>/k<N> \
-     --modell <varvets modellvärde> --konto <vilket Claude-konto som körde> \
-     --underlag <sökväg till källmanifestet>
+   node <skillkatalog>/scripts/svep.mjs --repo-rot <abs> --konto <namn> \
+     --modell <modell> [--modell <modell>]... \
+     --exp experiments/<slug> [--exp experiments/<slug>]... \
+     [--tickets-parallellt 2] [--om | --hoppa-över]
    ```
 
-   Kommandot räknar själv `skill_sha256` (över `SKILL.md` plus de fyra
-   agentdefinitionerna) och `underlag_sha256`, läser `korning.json` och
-   antecknar `fakturerade_modeller` (den kanoniserade nyckelmängden ur
-   `modelUsage`, suffix som `[1m]` strippade — ADR-0099), och stämplar även varje
-   `del-N/`. Utan den stämpeln går det inte att avgöra
-   vad som skilde `k1` från `k2`, och en jämförelse över tid blir en
-   gissning. Anropet står här som ett
-   kommando och inte som en beskrivning med flit: ett steg som ålägger
-   startaren en skrivning utan att peka ut vem som utför den är en skrivning
+   Varje varv startas av `svep.mjs` som EN `korning.mjs`-process, och det är
+   det som ger mätningen gratis. Parallellregeln: två tickets åt gången, alla
+   modeller för en ticket startar samtidigt, och nästa ticket startar först när en tickets samtliga
+   modeller är klara. Det är säkert därför att körningskatalogerna redan är
+   isolerade (`ny-korning` är atomisk, varje varv har egen katalog, manifest
+   och repo läses bara) och det enda delade tillståndet, `experiment.json`,
+   skrivs under lås (steg 1). Ansvaret delas, eftersom en process aldrig kan känna sin egen
+   slutkostnad:
+
+   **Startaren** är `svep.mjs`. Dess ansvar per varv, i en mening: allokera
+   körningskatalogen med
+   `archive.mjs ny-korning <modellkatalog> --request-id <gid eller slug>`
+   (kommandot skriver också skelettet till körningens `state.json`, se
+   Experimentytan; den inre processen skriver aldrig den filen från noll),
+   starta `korning.mjs` för varvet med körningskatalogen, experimentkatalogen,
+   repo-roten, request-id:t och modellen som argument (stderr till
+   `stderr.log`; `korning.json` skriver `korning.mjs` själv),
+   ta tiden runt processen och skriva
+   `<modell>/k<N>/matning.json` (`startad`, `avslutad`, `wall_ms`,
+   `exit_code`; skrivs ÄVEN när processen faller), stämpla `proveniens` i
+   körningens `state.json` med
+   `archive.mjs proveniens <modell>/k<N> --modell <varvets modellvärde> --konto <Claude-kontot som körde> --underlag <sökväg till kallmanifest.md>`
+   EFTER att `korning.json` skrivits, verifiera modellen mot `modelUsage`,
+   och sätta körningens status via `archive.mjs experiment`. Hur vart och ett
+   görs bor i scriptet och dess tester, inte här. Att stegen står som
+   kommandon är med flit (ADR-0094): ett steg som ålägger startaren en
+   skrivning utan att peka ut vem som utför den är en skrivning
    som inte blir av, och den syns först som tomma celler långt senare.
-   Kör därför proveniens-stämpeln EFTER att `korning.json` skrivits, aldrig
-   före — annars saknar stämpeln faktureringsdatan.
-
-   **Modellverifiering görs av startaren mot faktureringen (ADR-0099),
-   aldrig mot svansraden ensam.** När processen är klar: jämför
-   `fakturerade_modeller` mot varvets begärda modell plus orkestratorns
-   (sonnet). En modellnyckel som varken är varvets modell eller
-   orkestratorns är en faktisk MODELL-avvikelse → körningen blir
-   `"ofärdig"`. En MODELL-svansrad som säger något annat än vad
-   `modelUsage` visar är en RAPPORTERINGSAVVIKELSE: den visas i rapporten
-   och står kvar i `runs[]` (raden bär agentens uppgift i
-   `model.uppgiven`), men den fäller ALDRIG ensam körningen — modeller är
-   opålitliga källor om sin egen identitet, och att kasta en korrekt
-   körning på en felskriven svansrad betalar om ett riktigt resultat.
-   Modellvärdet `default` kör agenternas egna defaults och får lagligt
-   producera flera modellnycklar: ingen mängdjämförelse görs där.
-
-   **Den inre processen** känns igen på invokationen, aldrig på gissning: bär
-   den `--körning`, är du den inre processen. Allokera då ingen katalog, starta
-   ingen ny process, och kör stegen direkt mot den anvisade katalogen. Utan det
-   stoppvillkoret läser den inre processen samma uppgift som startaren, startar
-   ett varv till och dubblar notan.
-
-   Den inre processen kör speca-stegen (dispatch, kontraktskontroll,
+
+   Fyra regler i den kedjan är kontrakt mot rapporten och arkivet och står
+   därför kvar här med sitt skäl:
+
+   - **Väggtiden bor i `matning.json`, aldrig i `korning.json`.** Rapporten
+     läser `total_cost_usd`, `usage.input_tokens`, `usage.output_tokens`,
+     `usage.cache_read_input_tokens`, `usage.cache_creation_input_tokens` och
+     `subagent_stats.spawned` ur `korning.json`, men väggtiden ur
+     `matning.json`: en process kan inte känna sin egen klocktid när arbetet
+     ligger i bakgrundsprocesser, och stegsvarens `duration_ms` räknar inte in väntan på dem.
+     `korning.json` bär summan över stegen, därav den egna filen. En kraschad körning har en klocktid, ofta det intressantaste
+     talet i tabellen, därför skrivs `matning.json` även vid krasch.
+   - **Proveniensen stämplas EFTER `korning.json`, aldrig före**, annars
+     saknar stämpeln faktureringsdatan. Kommandot räknar själv `skill_sha256`
+     (över `SKILL.md` plus de fyra agentdefinitionerna) och `underlag_sha256`,
+     läser `korning.json` och antecknar `fakturerade_modeller` (den
+     kanoniserade nyckelmängden ur `modelUsage`, suffix som `[1m]` strippade,
+     ADR-0099), och stämplar även varje `del-N/`. Utan den stämpeln går det
+     inte att avgöra vad som skilde `k1` från `k2`, och en jämförelse över tid
+     blir en gissning.
+   - **Modellverifiering görs av startaren mot faktureringen (ADR-0099),
+     aldrig mot svansraden ensam.** När processen är klar: jämför
+     `fakturerade_modeller` mot varvets begärda modell plus de två tolererade
+     avvikelserna, kundtextfixens `sonnet` och CLI:ns `haiku`-hjälpanrop. En
+     modellnyckel som varken är varvets begärda modell, kundtextfixens
+     `sonnet` eller CLI:ns `haiku`-hjälpanrop är en faktisk MODELL-avvikelse →
+     körningen blir `"ofärdig"`. Startaren tolererar `haiku`-nyckeln i summan;
+     taket på 200 output-tokens, som skiljer hjälpanropet från en riktig
+     körning, prövas per steg av `korning.mjs`. Resultatet ligger i
+     `korning.json` som `modellverifiering` (`ok` plus `avvikelser`, där varje
+     rad namnger sitt steg), så avvikelsen går att peka ut i det steg den
+     uppstod. En MODELL-svansrad som säger något annat än vad
+     `modelUsage` visar är en RAPPORTERINGSAVVIKELSE: den visas i rapporten
+     och står kvar i `runs[]` (raden bär agentens uppgift i
+     `model.uppgiven`), men den fäller ALDRIG ensam körningen — modeller är
+     opålitliga källor om sin egen identitet, och att kasta en korrekt
+     körning på en felskriven svansrad betalar om ett riktigt resultat.
+     Modellvärdet `default` kör agenternas egna defaults och får lagligt
+     producera flera modellnycklar: ingen mängdjämförelse görs där.
+   - **Statusen sätts via `archive.mjs experiment`**, aldrig genom att skriva
+     filen: exit ≠ 0 eller en faktisk MODELL-avvikelse ger `"ofärdig"` med
+     `--orsak`; har den inre processen redan satt `"stopp"`, `"väntar på dom"`
+     eller `"ofärdig"` behålls den; annars `"klar"`.
+
+   **`korning.mjs` är den inre processen: ett script utan modellturer.** Det
+   bygger prompterna ur `onskemal.md`, `kallmanifest.md` och `experiment.json`,
+   startar varje agentsteg som en egen process
+   `claude -p --agent <agent> --output-format json --max-turns <tak> [--model <modell>]`
+   med prompten på stdin, sparar råsvaret under `k<N>/steg/`, kör precheck,
+   `kontroll.mjs` och compare-scores, arkiverar via `archive.mjs` och skriver
+   `korning.json` som summan. Det gör ingen Asana-hämtning och bygger inget
+   nytt manifest. Buntens delar körs parallellt (två åt gången) och de två
+   scorerkörningarna samtidigt (#500).
+
+   `korning.mjs` kör speca-stegen (dispatch, kontraktskontroll,
    arkivering) och därefter bedöm-stegen (analys, poäng,
    ankarlösning, dubbelkörning enligt bedöm) mot den anvisade katalogen, utan
    godkännandegrind, och rör ingenting utanför den. Är modellen `default`
    används ordinarie promptmallar och agenternas defaults, ingen override. Är
-   den ett modellnamn får varje Agent-anrop modell-override till den på ALLA
-   tre agenter; agentdefinitionerna röres aldrig, effort tas ur definitionen
-   som vanligt. Overriden verifieras av STARTAREN mot `modelUsage` (se
-   modellverifieringen ovan) — svansraden arkiveras men avgör aldrig ensam.
-   `approval` förblir `null`, `state.json`
-   får `"experiment": true`. `REQUEST_ID` och `--expect-id` använder alltid
-   ticketens gid/slug, aldrig katalogens namn.
-
-   Orkestratorn pinnas till sonnet i ALLA körningar. Dess kostnad blir då en
-   konstant som går att räkna bort, och `modelUsage` i JSON-svaret skiljer den
-   från agenternas kostnad utan extra arbete.
-
-   Subagentdöd, kontraktsbrott (kvarstående BROTT efter omdispatch) eller
+   den ett modellnamn får varje agentprocess modell-override till den på ALLA
+   tre agenter; overriden är `--model` på processen, aldrig en promptrad, och
+   agentdefinitionerna röres aldrig, effort tas ur definitionen
+   som vanligt. Overriden verifieras per steg mot `modelUsage` i råsvaret
+   (ADR-0099, se modellverifieringen ovan), svansraden arkiveras men avgör
+   aldrig ensam. `approval` förblir `null`, `state.json`
+   får `"experiment": true` ur skelettet `ny-korning` skrev. `REQUEST_ID`
+   och `--expect-id` använder alltid ticketens gid/slug, aldrig katalogens
+   namn.
+
+   **Bunt i den inre processen:** ger specifiern flera specar läggs de som
+   `del-1/ … del-N/` under körningskatalogen med `bundle` satt (buntregeln i
+   Experimentytan), aldrig del 1 i roten; varje del får sin egen `spec.md`,
+   `granskarblock.md` och `state.json`, och speca steg 6 (precheck,
+   omdispatch per del, `stopp` vid kandidat) körs per del. Faller en del på
+   kvarstående brist blir körningen `"ofärdig"`; övriga delar körs ändå
+   klart så arkivet visar vad som gick att bedöma.
+
+   **DELA_UPP körs inte autonomt av `korning.mjs` (v1).** Utfallet arkiveras
+   och körningen får status `stopp` med orsak; delningsanalysen saknar
+   promptmall i den här skillen, och ett script får inte improvisera en
+   (ADR-0113).
+
+   Ett fallet agentsteg, kontraktsbrott (kvarstående BROTT efter omdispatch) eller
    en faktisk MODELL-avvikelse (obegärd nyckel i `modelUsage`, aldrig en
    ensam svansradsavvikelse), i vilket steg det än inträffar, sätter
-   körningens `status` till `"ofärdig"` i `experiment.json`.
-
-5. **DELA_UPP körs autonomt.** Ett DELA_UPP-utfall följer bedöms ordinarie
-   delningsregler men utan paus för granskare: delkataloger
+   körningens `status` till `"ofärdig"` via `archive.mjs experiment`
+   (`experiments/<slug> --korning <modell>/k<N> --status ofärdig --orsak <vad som föll>`),
+   aldrig genom att skriva filen.
+
+5. **DELA_UPP i experimentet.** Ett DELA_UPP-utfall följer bedöms ordinarie
+   delningsregler men utan paus för granskare (i v1 kör `korning.mjs` inte
+   delningen själv, se steg 4; reglerna här gäller när den körs):
+   delkataloger
    `<modell>/k<N>/del-1/ … del-N/` med `split` satt, förälderns `spec.md` +
-   `granskarblock.md` kopierade in, ny analys + poäng per del.
+   `granskarblock.md` kopierade in, ny analys + poäng per del. Delas en
+   buntdel blir det `del-N/del-M/` under den delen, aldrig ett nytt
+   syskon i roten (`bundle` och `split` sätts aldrig på samma katalog).
    En del utan tak blir `OVER_SKALAN` och delas aldrig vidare. Övriga
    stopputfall (`TILLBAKA_TILL_SPEC`, `KONCEPT`, `DIAGNOS`, `ESKALERA`,
-   `INPUT_SAKNAS`) kräver människa eller kund: arkivera utfallet, avbryt det
+   `INPUT_SAKNAS`) kräver människa eller kund: arkivera utfallet, sätt
+   körningens status till `"stopp"` via `archive.mjs experiment`, avbryt det
    varvet, gör det synligt i rapporten när den körs, och övriga körningar i
    listan fortsätter oberoende.
 
    **OLIKA väntar på dom.** Skriver dubbelkörningen OLIKA i ett varv:
    arkivera enligt bedöms regler (spärren står), sätt körningens status till
-   `"väntar på dom"` i `experiment.json`, synligt i rapporten när den körs.
+   `"väntar på dom"` via `archive.mjs experiment`, synligt i rapporten när
+   den körs.
    Domen är människans även i experimentet: `döm` körs mot körningskatalogen
    när granskaren vill (adresserad via sin sökväg, se `döm`), och ingen dom
    simuleras av uppgiften. Domen i sig skriver inte om `experiment.json`,
-   det gör `utvärdera` självt, nästa gång det körs för samma post (se
+   det gör `svep.mjs` (via `archive.mjs experiment`) nästa gång `utvärdera`
+   körs för samma post (se
    Återupptagbart i avsnittet Batch nedan för hur och när statusen går
    till `"klar"` och rapporten kan visa utfallet). Övriga körningar i listan
    fortsätter oberoende oavsett när, eller om, domen fälls.
 
 6. **Rapport.** BLUF i chatten: klart eller ofärdigt per körning, stopputfall,
-   och sökvägen till `experiments/<slug>/`. Nämn att `utvärdera rapport` finns
+   och sökvägen till `experiments/<slug>/`. Tabellen per körning kommer ur
+   `node <skillkatalog>/scripts/archive.mjs bluf <modell>/k<N>` (rekursivt
+   över delarna, rotraden för en bunt lyder `bunt (N delar)`) och klistras in
+   som den är, aldrig handskriven. Nämn att `utvärdera rapport` finns
    när underlaget ska läsas sida vid sida. Ingen skrivning mot Asana.
 
 ### Batch: flera poster
 
 `utvärdera <post1> <post2> … <modell…>` kör varje ticket och modell i en EGEN
-headless-process, sekventiellt:
+`korning.mjs`-process, parallellt enligt `svep.mjs`: två tickets åt gången, alla
+modeller för en ticket samtidigt, och nästa ticket startar när en ticket är
+helt klar (steg 4). Raden `svep.mjs` kör per varv:
 
 ```
-claude -p --model sonnet --output-format json "/request utvärdera <gid> <modell> --hoppa-över --körning <katalog>"
+node <skillkatalog>/scripts/korning.mjs --katalog <k<N>> --exp <experiments/<slug>> --repo-rot <abs> --request-id <gid> --modell <modell>
 ```
 
-Orkestratorn är huvudloopens modell och pinnas till sonnet i headless:
-agenternas modeller styrs av definition plus override och verifieras av
-startaren mot `modelUsage` i `korning.json` (ADR-0099) —
-aldrig av huvudloopens val, och aldrig av svansraden ensam.
+Underlaget läses från disk av `korning.mjs`; ingenting går via stdin till
+orkestreringen, bara till agentprocesserna. Vilka rader varje agentprompt bär
+(ÖNSKEMÅL, KÄLLOR, REPO-ROT, DEPS, SPRÅK, RUBRIKER, ESKALERAD, REQUEST_ID) bor
+i scriptet och dess tester.
 
-**Raden bär ALLTID `--om` eller `--hoppa-över`, och väljer `--hoppa-över`.**
-Det är inte en stilregel utan det som gör svepet möjligt: en `claude -p`-process
-kan inte svara på en fråga, så en rad utan flagga skulle hänga eller gissa.
-`--hoppa-över` är dessutom precis återupptagningens semantik, ett avbrutet svep
-som startas om plockar upp där det stannade i stället för att betala om för
-allt färdigt.
+Det finns ingen orkestratormodell: agenternas modeller styrs av definition plus
+`--model`-override och verifieras per steg mot `modelUsage` i råsvaret, aldrig
+av svansraden ensam.
 
-`--körning <katalog>` pekar ut den körningskatalog som `archive.mjs ny-korning`
-redan allokerat åt den ticketen och modellen. Den inre processen arkiverar
+`--om` och `--hoppa-över` är svepets egna flaggor; `korning.mjs` frågar aldrig
+något och kan därför inte hänga. `--hoppa-över` är dessutom precis
+återupptagningens semantik, ett avbrutet svep som startas om plockar upp där
+det stannade i stället för att betala om för allt färdigt.
+
+`--katalog` pekar ut den körningskatalog som `archive.mjs ny-korning`
+redan allokerat åt den ticketen och modellen. `korning.mjs` arkiverar
 bara dit, aldrig någon annanstans.
 
-Svepets loop är startaren och har startarens hela ansvar per rad: den tar tiden
-runt `claude -p`-anropet och skriver `matning.json`, och den kör
-`archive.mjs proveniens` mot körningskatalogen när processen är klar.
+Svepets loop är startaren, och den heter `svep.mjs`: den bär startarens hela
+ansvar per rad (`ny-korning`, tidtagningen som skriver `matning.json`,
+`archive.mjs proveniens` mot körningskatalogen när processen är klar,
+modellverifieringen och status via `archive.mjs experiment`), se steg 4.
 
-- **En ticket = ett färskt kontextfönster.** Allt tillstånd bor i arkivet på
-  disk; huvudsessionen samlar bara exitstatus och en radssammanfattning per
-  ticket. `/clear` mellan tickets behövs inte — processgränsen är
+- **En ticket, en modell = en `korning.mjs`-process; varje agentsteg är ett
+  eget kontextfönster.** Allt tillstånd bor i arkivet på
+  disk; `svep.mjs` skriver en rad per ticket och modell när den startar och
+  när den slutar (status, väggtid, USD) och en sluttabell, och huvudsessionen
+  samlar bara det. `/clear` mellan tickets behövs inte — processgränsen är
   motsvarigheten. Headless-körningen förutsätter att uppgiften kan köra utan
   interaktiva permission-frågor, vilket håller: den läser repot och skriver
-  enbart under `.haus/requests/` — plus EN läsande Asana-hämtning per ticket
-  (steg 1), så MCP-behörigheten för läsning måste täcka headless-körning.
-- **Kör vidare vid fel.** En ticket vars gid inte går att hämta eller vars
-  process kraschar noteras i sammanfattningen; resten av listan fortsätter.
-- **Återupptagbart:** innan en körning startas kontrolleras arkivet, styrt av
+  enbart under `.haus-workflow/requests/`. Asana-hämtningen gjordes redan i
+  steg 1 av huvudkonversationen, som skrev `onskemal.md`, så `korning.mjs`
+  behöver ingen MCP-kontakt alls.
+- **Kör vidare vid fel.** En ticket vars underlag saknas (`onskemal.md`,
+  `kallmanifest.md` eller `experiment.json` med `request_id`) märks och hoppas
+  över; en vars process kraschar blir `"ofärdig"` med orsak. Resten av svepet
+  fortsätter, och `svep.mjs` avslutar med exit 1 när någon körning blev
+  `"ofärdig"`, annars 0.
+- **Återupptagbart:** det gör `svep.mjs`: innan en körning startas
+  kontrolleras arkivet, styrt av
   körningens `status` i `experiment.json`. `"klar"` och `"stopp"` hoppas
   över med en notis. `"ofärdig"` är avbruten data, inget resultat värt att
   skydda: den utlöser aldrig omkörningsfrågan, utan körs om automatiskt som
@@ -864,16 +1115,16 @@ runt `claude -p`-anropet och skriver `matning.json`, och den kör
   `"väntar på dom"` OMVÄRDERAS i stället för att hoppas över, det är den
   enda platsen som är aktören för den statusen: kör `archive.mjs sparr` på
   körningskatalogen. Exit 0 betyder att domen är fälld: sätt körningens
-  status till `"klar"` och fortsätt där den stannade (rapporten kan köras
-  separat när alla körningar för posten är klara). Exit 1 betyder att
-  den fortfarande väntar: notera det och gå vidare till nästa ticket.
-  `döm` fäller domen men rör aldrig `experiment.json` (se `döm`), det är
-  bara genom att `utvärdera` körs igen för samma post som statusen
-  uppdateras. Omkörningsfrågan (se `utvärdera` ovan) gäller alltså bara
+  status till `"klar"` via `archive.mjs experiment` och fortsätt där den
+  stannade (rapporten kan köras separat när alla körningar för posten är
+  klara). Exit 1 betyder att den fortfarande väntar: notera det och gå vidare
+  till nästa varv. `döm` fäller domen men rör aldrig `experiment.json` (se
+  `döm`), det är bara genom att `utvärdera` körs igen för samma post som
+  statusen uppdateras. Omkörningsfrågan (se `utvärdera` ovan) gäller alltså bara
   `"klar"`-körningar: det är resultat värda att skydda mot ett fingerfel,
-  en ofärdig körning har inget att skydda. Körningar är billiga relativt
-  risken att lappa ihop halva resultat. Ett svep över många tickets kan
-  därmed fortsätta i en senare session utan onödiga omkörningar.
+  en ofärdig körning har inget att skydda. Körningar är billiga
+  relativt risken att lappa ihop halva resultat. Ett svep över många tickets
+  kan därmed fortsätta i en senare session utan onödiga omkörningar.
 
 ### Sammanställning
 
@@ -923,8 +1174,11 @@ människans, gjord på erfarenhet av systemet. Rapporten visar spridningen.
 
 ## Mekaniska script: `scripts/`
 
-Nio deterministiska script bor i katalogen: de fem kontrollerna nedan,
-`archive.mjs` som äger arkivets kataloger och spärrar, `report.mjs` som
+Tolv deterministiska script bor i katalogen: de fem kontrollerna nedan,
+`kontroll.mjs` som kör scorerns kontrollkedja i en process,
+`archive.mjs` som äger arkivets kataloger, spärrar och `experiment.json`,
+`svep.mjs` som är utvärderas startare,
+`korning.mjs` som är utvärderas inre process, `report.mjs` som
 renderar modellrapporten (se `utvärdera rapport`), `lib.mjs` med de delade
 byggstenarna och `ref-hash.mjs` för stabil hashning. Kontrollerna ersätter
 modellkörningar där kontrollen är ren form,
@@ -935,7 +1189,17 @@ referensfiler vars regler det speglar och VARNAR när en katalogbump ändrat dem
 - `scripts/precheck.mjs <arkivkatalog> [--impact]` — formkontroll FÖRE dyra
   dispatcher: rubriker, exakt ett specblock, 2–5 punkter, förbjuden vokabulär,
   granskarblocksrader, state.json-fält. Skiljer på BRISTER (exit 1, stoppar)
-  och VARNING (heuristik — visas, stoppar inte).
+  och VARNING (heuristik — visas, stoppar inte). Rubrikerna matchas via
+  aliastabellen i `lib.mjs` på svenska eller engelska; rubriker ur båda
+  språken i samma spec är en BRIST. Kandidatformen känns igen på markörraden
+  (`**Koncept-kandidat**`/`**Diagnos-kandidat**`, eller de engelska
+  motsvarigheterna) och skrivs som `KANDIDAT: KONCEPT` eller
+  `KANDIDAT: DIAGNOS` på stdout, alltid, även vid exit 1; en kandidat med en
+  Lösning är en BRIST. Med `--impact` läses etiketten på analysens rad
+  `**Avvikelse mot specen:**` och skrivs som `AVVIKELSE: ingen`,
+  `AVVIKELSE: precisering` eller `AVVIKELSE: motsägelse`; en rad utan
+  etikett är en BRIST. Orkestratorn läser kandidat och avvikelse ur de
+  raderna, aldrig ur filerna själv.
 - `scripts/resolve-anchors.mjs <run.json> <spec.md> [impact.md]` — löser
   beläggsankare (`belagg_ankare`/`ankare`) till ordagranna källblock, körs
   FÖRE contract-check. Exit 0 = allt löst (eller inga ankare i filen), 1 =
@@ -950,6 +1214,16 @@ referensfiler vars regler det speglar och VARNAR när en katalogbump ändrat dem
   INPUT_SAKNAS kräver saknas-lista i stället för frågerader. Ett olöst ankare
   (belägg saknas trots `belagg_ankare`, eller `ankare` utan `citat`) är
   dispatcherns fel, inte agentens: exit 2 med hänvisning till resolve-anchors.mjs.
+  Stegschemat: varje `bracket.steps[i]` (även per alternativ) är exakt
+  `{anchor, relation, grund}` med `relation` ur `storre`, `mindre`, `lika`;
+  egna nycklar och tomma grunder är BROTT. Motsägelsegrinden: ges `impact.md`
+  och analysens `**Avvikelse mot specen:**` bär `motsägelse` är varje annat
+  utfall än TILLBAKA_TILL_SPEC ett BROTT. Prövar dessutom inringningens
+  konsistens (golv före tak, between angränsande och inuti golv–tak, poäng
+  mellan between-paret, relation mot poäng; poäng PÅ ett ankare trots
+  storre/mindre är VARNING bara vid avrundningskollaps), att `type` är en av
+  skalans fem typer, och undantar svartlistade ord som står i specen
+  (ADR-0115).
 - `scripts/check-lasta.mjs "<LÄSTA-innehåll>" <spec.md> <impact.md>` —
   kontrollerar scorerns läs-scope: LÄSTA-raden ska bära underlagens två
   sökvägar och får därutöver bara bära filer under skillens egen katalog.
@@ -960,8 +1234,75 @@ referensfiler vars regler det speglar och VARNAR när en katalogbump ändrat dem
   `LIKA_TOLERANS` (poängskillnad ≤ 0,5 med samma outcome, oavsett confidence,
   och ankarband som överlappar eller angränsar; exit 0, verdiktraden pekar ut
   körningen med högst poäng) eller `OLIKA` + diffrader; exit 0/1, exit 2 =
-  ojämförbara körningar (dispatcherfel, aldrig LIKA). Scriptet kräver mode
-  `pricing`; guard-jämförelser är en medveten utbyggnad i guard-steget.
+  ojämförbara körningar (dispatcherfel, aldrig LIKA). Diffar även de inre
+  stegen: samma ankare i `bracket.steps` med `storre` i ena körningen och
+  `mindre` i den andra ger diffraden
+  `bracket.steps[A<n>].relation: "mindre" ↔ "storre"`, en hård diff som
+  aldrig faller under toleransen; golv- och takankare i någon av körningarna
+  undantas, de flippar av konstruktion när banden angränsar. Scriptet kräver
+  mode `pricing`; guard-jämförelser är en medveten utbyggnad i guard-steget.
+  Angränsning avgörs av skalans ordning (lib.mjs ANKARE, A17 mellan A12 och
+  A13), och utöver poäng och ankare diffas `type` (toleransrad), antalet
+  `conditions` (hård diff) och `alternatives` per label (ADR-0115).
+- `scripts/archive.mjs <kommando> <katalog> [flaggor]`: arkivets mekanik
+  (fullständig lista i scriptets huvud): `add-run`, `next-n`, `sparr`,
+  `utslag`, `set-status`, `kalibrering`, `ny-korning`, `proveniens`, samt
+  `stopp <katalog> --utfall KONCEPT|DIAGNOS|TILLBAKA_TILL_SPEC --kalla spec.md|impact.md`
+  (skriver `state.stopp` efter att ha kontrollerat att källan bär utfallet;
+  `--kalla impact.md` sätter status `assessed`, `--kalla spec.md` rör inte
+  status), `respec <katalog>` (lägger undan `impact.md` som
+  `impact-superseded-<datum>.md`, återställer status `spec_draft`,
+  `approval`, `granskarutslag` och `stopp`, rör aldrig `runs[]`) och
+  `bluf <katalog>` (markdown-tabellen `| post | poäng | utfall | konfidens | anm |`
+  över katalogen och dess `del-N/` rekursivt, bunt-roten som
+  `bunt (N delar)`; värdena ur filerna, aldrig ur prosa). `add-run` läser
+  `effort:` ur agentdefinitionen när `--effort` utelämnas och kanoniserar
+  `--model`; `set-status priced` vägrar när `stopp` är satt.
+  `experiment <experimentkatalog> [--satt nyckel=värde]... [--variant <modell>]... [--korning <modell>/k<N> --status <klar|ofärdig|stopp|väntar på dom> [--orsak <text>]]`
+  är den ENDA skrivaren av `experiment.json` (se `utvärdera` steg 1): låst
+  läs-modifiera-skriv med atomisk skrivning, katalog och fil skapas om de
+  saknas. `--satt` skriver toppnivåfält append-only (samma värde är no-op,
+  ett annat värde är exit 2; `eskalerad` tolkas som boolean), `--variant` är
+  UNION med bevarad ordning, och `--korning` kräver `--status` ur de fyra
+  statusliteralerna, rör ingen annan körning och kräver att katalogen
+  `<modell>/k<N>` finns. Exit 0 ok, 2 användnings- eller tillståndsfel.
+- `scripts/svep.mjs --repo-rot <abs> --konto <namn> --modell <m>... --exp experiments/<slug>... [--tickets-parallellt 2] [--om | --hoppa-över]`:
+  utvärderas startare (se `utvärdera` steg 4 och Batch). Kör två tickets åt
+  gången med alla modeller per ticket samtidigt, nästa ticket när en är helt
+  klar, och gör per varv `ny-korning`, starten av `korning.mjs`,
+  `stderr.log`, `matning.json`, `proveniens`,
+  modellverifiering mot `modelUsage` och status via `archive.mjs experiment`.
+  Återupptar ur `experiment.json`: `klar` och `stopp` hoppas utan `--om`,
+  `väntar på dom` prövas med `sparr`, `ofärdig` körs om. En `--exp` utan
+  `onskemal.md`, `kallmanifest.md` eller `experiment.json` med `request_id` märks
+  och hoppas över. Exit 0 när ingen körning blev `ofärdig`, 1 annars, 2 vid
+  användningsfel.
+- `scripts/korning.mjs --katalog <abs k<N>> --exp <abs experimentkatalog> --repo-rot <abs> --request-id <gid eller slug> --modell <modell|default> [--claude <kommando>] [--delar-parallellt 2]`:
+  utvärderas inre process (se `utvärdera` steg 4), ett script utan
+  modellturer. Bygger prompterna ur `onskemal.md`, `kallmanifest.md` och
+  `experiment.json`, där `sprak` är OBLIGATORISK: saknas den skrivs en
+  instruktion på stderr och scriptet avslutar med exit 2 innan någon prompt
+  byggs (ADR-0114). Varje agentsteg är en egen `claude -p --agent`-process med
+  råsvaret under `k<N>/steg/`, och kontrollerna (precheck, `kontroll.mjs`,
+  compare-scores) plus arkiveringen (`archive.mjs`) är scriptanrop.
+  Buntens delar körs två åt gången och scorerns två körningar samtidigt;
+  `DELA_UPP` körs inte autonomt i v1 utan ger status `stopp` med orsak.
+  `korning.json` är summan över stegen (`korningsmotor`, `steg`,
+  `modellverifiering` plus rapportens vanliga nycklar). Exit 0 när körningen
+  gick igenom, 1 när minst en del blev ofärdig, 2 vid användningsfel.
+- `scripts/kontroll.mjs <svar.txt> <spec.md> <impact.md> --expect-id <id> --ut <ren.json> [--fixa-kundtext] [--claude <kommando>] [--fix-modell sonnet] [--fix-fil <rå.json>]`:
+  scorerns kontrollkedja i EN process (se `bedöm` steg 5): svansrader,
+  JSON-extraktion, deterministiska reparationer, sedan check-lasta,
+  resolve-anchors och contract-check i EN process. Reparerar det dispatchern
+  redan vet: `request_id`, versaler och gemener på `outcome`, `mode`,
+  `confidence` och `bracket.steps[].relation`, sträng till tal på `score`, och
+  LÄSTA-radens sökvägsform. Reparationerna rör aldrig poäng, utfall eller
+  belägg, och varje reparation skrivs som en `REPARERAT:`-rad som anroparen
+  bokför i runs-radens `note`. `--fixa-kundtext` skriver om ett
+  protokollterm-brott i ett rent kundtextfält med en billig modell i stället
+  för att kosta en hel scorerkörning, högst en runda. stdout bär `MODELL:`,
+  `LÄSTA:`, ev. `AVVIKELSE:`, `REPARERAT:`-rader och sist verdiktet. Exit 0 =
+  kedjan håller, 1 = BROTT (omdispatch enligt ADR-0092), 2 = användningsfel.
 
 Kontrollerna bedömer aldrig innehåll och returnerar aldrig protokollutfall —
 en post som passerar kan fortfarande stoppas av protokollen själva, och det är
@@ -983,13 +1324,35 @@ aldrig vidare som om kontrollen passerat.
   <manifest med absoluta sökvägar, eller "inga — allt blir antaganden">
 
   REPO-ROT: <absolut sökväg eller "saknas">
+  DEPS: <installerade | saknas>
+  SPRÅK: <svenska | engelska>
+  RUBRIKER:
+  **Problem**
+  **Lösning**
+  **När det är klart**
+  **Ingår inte**
+  **Utseende**
+  **Kräver**
+  **Villkor**
   ESKALERAD: <ja|nej>
   ```
 
+  `RUBRIKER:` är skelettet på specens språk, literalerna ordagrant. Det
+  svenska står ovan; vid `SPRÅK: engelska` tas de sju raderna ur
+  rubriktabellen i `request-write-spec/references/specformat.md`
+  (Problem, Solution, Done when, Not included, Appearance, Requires,
+  Conditions). Fotnot: en kandidat ersätter Lösning och När det är klart med
+  markörraden (`**Koncept-kandidat**` eller `**Diagnos-kandidat**`, på
+  engelska `**Concept candidate**` eller `**Diagnosis candidate**`), det
+  avgör specifiern själv enligt skillen.
+
   `request-assessor`:
 
   ```
   REPO-ROT: <absolut sökväg>
+  DEPS: <installerade | saknas>
+  KÄLLOR:
+  <kallmanifest.md ordagrant, eller "inga">
 
   SPEC (godkänd):
   <spec.md bytetroget>