@haus-tech/haus-workflow 5.0.1 → 5.2.0

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

@@ -86,8 +86,8 @@ med flera specar går inte att bedöma.
 ```
 <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
@@ -133,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" }`.
@@ -226,17 +250,23 @@ Modellkörningar från `utvärdera` bor i ett eget träd och är aldrig prispost
 ├── <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
@@ -245,21 +275,40 @@ 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`.
 - `experiment.json` bär `varianter: []` i deklarationsordning och `status` per
   körning: `"klar"`, `"ofärdig"`, `"stopp"`, `"väntar på dom"`. Literalerna
-  skrivs exakt så, mellanslag och diakritiska tecken inkluderade. Äldre filer
+  skrivs exakt så, mellanslag och diakritiska tecken inkluderade. Startraden
+  (`"ofärdig"`, "startad, inte avslutad") bär dessutom startarens `pid`
+  medan körningen pågår; slutstatusen ersätter raden och tar bort den
+  (#516). Äldre filer
   med `baselinemodell` och `kandidatmodell` läses utan fel; nya skrivningar
-  använder bara `varianter`.
+  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`
@@ -272,6 +321,20 @@ 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. Manifestets första rad är `SPRÅK: <svenska|engelska>`,
+   samma värde som prompten fick: `bedöm` läser språket därifrån till
+   assessorns och scorerns `SPRÅK:`-rad och till `kontroll.mjs --sprak`,
+   aldrig ur en ny gissning (#521).
+   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
@@ -279,10 +342,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
@@ -294,11 +362,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
@@ -309,14 +380,42 @@ 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
    `spec_synced`, döp om slug-katalogen till det myntade gid:t, notera sluggen
    i `former_slug` och uppdatera `request_id` i `state.json`.
+   **Avsluta enligt `## Avslutning: var posten står`** (tabellen ur
+   `archive.mjs nasta-steg`, brädraden, ISÄR-kontrollen), aldrig utan.
 
 ## Uppgift: `bedöm`
 
@@ -348,53 +447,100 @@ 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,
+   och `SPRÅK:`-raden bär manifestets `SPRÅK:`-värde (#521: kundtextens
+   språk gissas aldrig om, samma rad går till scorern i steg 4);
+   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 --sprak <svenska|engelska>`.
+   `--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). `--sprak` ger contract-check kundtextens språk, samma värde som
+   promptens `SPRÅK:`-rad (ur `experiment.json` i utvärdera, ur `SPRÅK:` i
+   `kallmanifest.md` här): kundtext med minst två funktionsord ur fel språk
+   fälls som BROTT och går till omdispatch, aldrig till kundtextfixen, som
+   byter ord men inte översätter (#521).
+   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.
@@ -422,7 +568,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
@@ -430,14 +580,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
@@ -449,13 +603,20 @@ 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
    i huvudkonversationen, bara på uttrycklig begäran — och det är den flytten
    som tar posten ✅ Spec ok → ⚖️ Poängsättning redo för granskning enligt
-   syncens regler.
+   syncens regler. **Avsluta enligt `## Avslutning: var posten står`**
+   (tabellen ur `archive.mjs nasta-steg`, brädraden, ISÄR-kontrollen, och
+   stopputfall eller OLIKA som ett val användaren ska ta), aldrig utan.
 
 **Stopputfall routas, aldrig tolkas.** Ett stopputfall arkiveras som varvets
 fil (steg 7), statusen blir `assessed`, aldrig `priced`, och posten routas:
@@ -463,14 +624,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`
 
@@ -507,6 +677,9 @@ missta:
   bekräftelsefråga. Säg tydligt att detta inte syns för någon annan än arkivet.
 - Verben rör Offer status och kommentarer — aldrig Score, Class eller
   beskrivningsfält.
+- **Avsluta enligt `## Avslutning: var posten står`** när posten har en
+  arkivkatalog: tabellen ur `archive.mjs nasta-steg` plus brädraden, så
+  flytten syns tillsammans med vad den öppnar för (`bedöm`, kund, inget).
 
 ## Uppgift: `döm`
 
@@ -571,6 +744,10 @@ körd igen för samma post, vars återupptagbarhetsregel omvärderar en
    Notisen är råmaterial till nästa instruktionsversion (mekanismen bakom
    v0.2 till v0.6) och läses aldrig in i någon prompt. `archive.mjs kalibrering <arkivrot>`
    listar alla.
+4. **Avsluta enligt `## Avslutning: var posten står`**: tabellen ur
+   `archive.mjs nasta-steg` visar om spärren lyfts (raden pekar då vidare på
+   sync/godkänn) eller fortfarande väntar (`döm` igen efter en beställd
+   omkörning), plus brädraden.
 
 **Granskarutslag skrivs som citat, aldrig som prosa.** När granskarens
 beslut ska in i underlaget, alltså när det ändrar eller preciserar en
@@ -629,12 +806,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
@@ -673,34 +849,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
@@ -710,175 +914,255 @@ 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] [--modeller-parallellt 4] [--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, högst
+   fyra modeller för en ticket i flykt (`--modeller-parallellt`, #526), 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. Lasten
+     väggtiden mättes under står i `korning.json`:s steg som
+     `samtidiga_processer` (levande agentprocesser på maskinen vid stegets
+     start, räknat med `pgrep`, maskinvitt och best effort, `null` när
+     räkningen föll); rapporten visar maxvärdet bredvid väggtiden och märker
+     en körning utan fältet som mätt under okänd samtidighet (#526).
+   - **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, utom när `korning.mjs` fått `--effort`: då får varje
+   agentprocess samma `--effort`-override, stegposten och `runs[]` bär den
+   som begärd (`effort_begard`, `add-run --effort`), aldrig som verifierad,
+   eftersom faktureringen inte bär någon effort (#525). 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, högst
+fyra modeller för en ticket i flykt, 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.
+
+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.
 
-**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.
+`--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.
 
-`--körning <katalog>` pekar ut den körningskatalog som `archive.mjs ny-korning`
-redan allokerat åt den ticketen och modellen. Den inre processen arkiverar
+`--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-workflow/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
   en ny `k<N+1>` under samma modell. Den gamla ofärdiga körningen skrivs
-  ändå aldrig över, den står kvar som historik över vad som gick fel.
+  ändå aldrig över, den står kvar som historik över vad som gick fel. Ett
+  undantag: en `"ofärdig"`-rad som bär en `pid` vars process lever är ingen
+  avbruten körning utan en som pågår i ett annat svep (två konton mot samma
+  checkout, ADR-0093); den hoppas med notisen att den pågår i en annan
+  process och står som `pågår` i sluttabellen, aldrig som en dubblett
+  (#516). En död pid, eller ingen pid alls, körs om som förut.
   `"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
 
@@ -926,10 +1210,63 @@ tvärs poster med olika modelluppsättning, eller uttalar sig om vilket utfall
 som var korrekt. Bedömningen av vad som är ett acceptabelt utfall är
 människans, gjord på erfarenhet av systemet. Rapporten visar spridningen.
 
+## Avslutning: var posten står
+
+Uppgifterna `speca`, `bedöm`, `godkänn`, `underkänn` och `döm` avslutas
+ALLTID med det här blocket (#530). Ett svar som slutar utan det lämnar
+användaren att gissa var posten står, vad hon ska göra och vilket kommando
+som kör vidare, och arkiv och bräda kan då gå isär tyst (`spec_draft`
+lokalt, tom Offer status på brädan). Blocket består av fyra delar, i ordning:
+
+1. **Tabellen ur `node <skillkatalog>/scripts/archive.mjs nasta-steg <katalog>`**
+   klistras in som den är (`| post | står | väntar på | nästa |`, en rad per
+   katalog och del), ALDRIG handskriven, av samma skäl som `bluf`: en
+   handskriven avslutning tappar exakt den rad som skulle ha sagt vad som
+   väntar. Scriptet räknar ut raderna ur `state.json` (status, `stopp`,
+   `respec_varv`, `approval`, olyft OLIKA via spärren, scorerns gällande
+   utfall ur prisfilen) med reglerna ur den här skillens egna grindar;
+   regeltabellen med källhänvisning per rad står ovanför funktionen
+   `nastaStegFor` i scriptet. Ett läge scriptet inte känner skrivs som
+   `okänt läge: <status>`, aldrig som en gissning.
+2. **Brädraden.** Har posten ett gid: hämta Offer status via request-sync i
+   huvudkonversationen (aldrig ur minnet) och skriv raden
+   `Bräda: <Offer status>` direkt under tabellen. Saknar posten gid: skriv
+   `Bräda: ingen (posten ligger inte på brädan)`.
+3. **ISÄR-kontrollen.** Arkivstatus och Offer status ska motsvara varandra
+   enligt tabellen nedan (värdena är request-sync:s, normaliserade på
+   alfabetiska kärnan som där). Avviker de skrivs en rad
+   `ISÄR: arkiv <x>, bräda <y>` följd av det kommando som stänger gapet.
+
+   | arkivstatus (`state.json`)                     | förväntad Offer status               | stänger gapet                                                                       |
+   | ---------------------------------------------- | ------------------------------------ | ----------------------------------------------------------------------------------- |
+   | `spec_draft`                                   | tom eller 📥 Inkommet                | sync via request-sync (🔍) när specen ska granskas                                  |
+   | `spec_synced`                                  | 🔍 Spec redo för granskning          | `godkänn`/`underkänn`, eller sync om brädan står på 📥                              |
+   | `spec_synced`/`spec_draft` med `approval` satt | ✅ Spec ok                           | `bedöm`; står brädan på 🔍 är approval-anteckningen äldre än brädan, läs om grinden |
+   | `assessed`/`priced`, poängen synkad            | ⚖️ Poängsättning redo för granskning | sync via request-sync om brädan står kvar på ✅                                     |
+   | klar (`godkänn` från ⚖️)                       | 📤 Klar – till kund                  | inget, kundens `Decision` avgör resten                                              |
+
+   Arkivet är cache och Asana sanningen (Hårda regler): ett ISÄR löses alltid
+   i riktning mot brädan, aldrig genom att skriva om brädan för att matcha
+   arkivet. En experimentvariant (`experiment: true`) har ingen brädrad och
+   ingen ISÄR-kontroll, den når aldrig Asana.
+
+4. **Valet, när det finns ett.** Ett stopputfall (`TILLBAKA_TILL_SPEC`,
+   `ESKALERA`, `KONCEPT`, `DIAGNOS`) och en olyft `double_run: olika`
+   presenteras som ett val användaren ska ta, inte bara som routing:
+   "här är ditt val", följt av alternativen (vid TILLBAKA_TILL_SPEC det
+   öppna valet ur `stopp.orsak` eller källfilen; vid OLIKA de två
+   körningarnas belägg sida vid sida, se bedöm steg 6) och kommandot som
+   verkställer svaret (`speca <post>` efter `## Avgjorda val` + `respec`,
+   `döm <post>`, kunddialog). Ett stopp som bara routas läses som "maskinen
+   jobbar vidare", och ingen gör något.
+
 ## 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,
@@ -940,13 +1277,23 @@ 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 =
   minst ett OLÖST/FLERTYDIG ankare (kontraktsbrott, mekanisk omdispatch),
   2 = användningsfel.
-- `scripts/contract-check.mjs <run.json> <spec.md> [impact.md] [--expect-id <id>]`
+- `scripts/contract-check.mjs <run.json> <spec.md> [impact.md] [--expect-id <id>] [--state <state.json>] [--sprak <svenska|engelska>]`
   — kontraktskontroll av score-JSON EFTER körning: enums,
   konfidensintervall, poängupplösning, inringningens närvaro (även per
   alternativ; under-A1-fallet med floor null och tak A1 är giltigt), belägg/
@@ -955,6 +1302,19 @@ 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). Med `--sprak` prövas varje kundtextfält mot språket (#521):
+  minst två OLIKA funktionsord ur fel språk, hela ord, skiftlägesokänsligt
+  (listorna i `lib.mjs` `FUNKTIONSORD`), är BROTT `kundtext på fel språk`;
+  diakritiska tecken är ingen signal. Utan flaggan ingen språkkontroll.
 - `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.
@@ -965,8 +1325,97 @@ 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) och
+  `nasta-steg <katalog>` (läs-enbart, markdown-tabellen
+  `| post | står | väntar på | nästa |` över katalogen och dess `del-N/`
+  rekursivt: var posten står, vad en människa väntas göra och vilket
+  `/request`-kommando som kör vidare, ur `state.json` och scorerns gällande
+  utfall enligt regeltabellen i scriptet; okänt läge skrivs som
+  `okänt läge: <status>` med exit 0, trasig `state.json` är exit 2, se
+  `## Avslutning: var posten står`). `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>] [--pid <heltal>]]`
+  ä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. `--pid` (heltal, bara med `--korning`) skriver
+  startarens pid på raden; en statusskrivning utan `--pid` ersätter raden
+  helt, så pid:n försvinner med slutstatusen (#516). 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] [--modeller-parallellt 4] [--om | --hoppa-över]`:
+  utvärderas startare (se `utvärdera` steg 4 och Batch). Kör två tickets åt
+  gången med högst fyra modeller per ticket i flykt, 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`.
+  Startraden i `experiment.json` bär svepets pid (#516).
+  Återupptar ur `experiment.json`: `klar` och `stopp` hoppas utan `--om`,
+  `väntar på dom` prövas med `sparr`, `ofärdig` körs om, utom när raden bär
+  en levande `pid` (pågår i ett annat svep, hoppas som `pågår`, #516). 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] [--effort <low|medium|high|xhigh|max|default>]`:
+  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.
+  `--effort` är en override på varje agentprocess, symmetrisk med
+  `--modell`: `default` ger ingen flagga och add-run läser definitionen som
+  förut; allt annat skickas till processen och till `add-run --effort` som
+  begärd, aldrig verifierad (#525). `korning.json` är summan över stegen
+  (`korningsmotor`, `steg` med `effort_begard` och `samtidiga_processer` per
+  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. `--state <state.json>`
+  och `--sprak <svenska|engelska>` går rakt vidare till contract-check
+  (split-status respektive kundtextens språk; `korning.mjs` tar språket ur
+  `experiment.json`, det manuella flödet ur `SPRÅK:` i `kallmanifest.md`).
+  Ett språkbrott är aldrig kundtextfixbart och går till omdispatch (#521).
+  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
@@ -988,13 +1437,36 @@ 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>
+  SPRÅK: <svenska | engelska>
+  KÄLLOR:
+  <kallmanifest.md ordagrant, eller "inga">
 
   SPEC (godkänd):
   <spec.md bytetroget>
@@ -1009,6 +1481,7 @@ aldrig vidare som om kontrollen passerat.
   REQUEST_ID: <gid eller slug>
   MODE: <pricing|guard>
   DELPOST: <nej | ja, del N av M>
+  SPRÅK: <svenska | engelska>
 
   SPEC: <absolut sökväg till spec.md>
   PÅVERKANSANALYS: <absolut sökväg till impact.md>
@@ -1017,6 +1490,12 @@ aldrig vidare som om kontrollen passerat.
   (guard-läge lägger till `FULLPLAN:` och `TIDIGARE_POANG:` —
   guard-kommandot kommer i ett senare steg.)
 
+  `SPRÅK:` är kundtextens språk för assessorn och scorern (#521): samma
+  värde som specifiern fick, ur `experiment.json` (`sprak`) i utvärdera och
+  ur `SPRÅK:` i `kallmanifest.md` i det manuella flödet. Analysens
+  kundvända delar och kuvertets kundtextfält skrivs på det språket;
+  `contract-check --sprak` fäller kundtext på fel språk.
+
 - **Svansrader efter huvudinnehållet**, i denna ordning: `MODELL: <modell-id>`
   (alla agenter), `LÄSTA: <kommaseparerade absoluta sökvägar eller "inga">`
   (endast scorern — dess Read är promptbegränsad, raden gör regeln