@haus-tech/haus-workflow 4.9.0 → 5.0.1

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

@@ -1,28 +1,29 @@
 ---
 name: request
-description: Enda ingången till Haus requestflöde. Använd när användaren säger "/request", "kör requestflödet", "speca och bedöm", "prisa den här posten", "ta önskemålet hela vägen", "vad ligger i kön", "detaljer <post>", eller när flera request-skills ska kedjas i en följd. Enskilda request-skills (request-write-spec, request-classify m.fl.) fungerar fortfarande fristående; den här skillen äger kedjan, arkivet och dispatchen till subagenter.
+description: Enda ingången till Haus requestflöde. Använd när användaren säger "/request", "kör requestflödet", "speca och bedöm", "prisa den här posten", "ta önskemålet hela vägen", "vad ligger i kön", "detaljer <post>", eller när flera request-skills ska kedjas i en följd. Enskilda request-skills (request-write-spec, request-score m.fl.) fungerar fortfarande fristående; den här skillen äger kedjan, arkivet och dispatchen till subagenter.
 ---
 
 # /request — requestflödets ingång
 
-Tunn orkestrering ovanpå de fem request-skillsen. Den här skillen innehåller
-**noll domänregler**: allt om specformat, klassning, poäng och Asana-fält bor i
+Tunn orkestrering ovanpå de fyra request-skillsen. Den här skillen innehåller
+**noll domänregler**: allt om specformat, poäng och Asana-fält bor i
 respektive skill. Här bor bara routing, kontextbärande, arkivet och dispatchen.
 
 ## Uppgifter
 
 `/request [uppgift]` — utan argument: visa menyn nedan.
 
-| Uppgift                                | Gör                                                                                      |
-| -------------------------------------- | ---------------------------------------------------------------------------------------- |
-| `speca <önskemål eller gid>`           | Källmanifest → dispatcha `request-specifier` → arkivera spec + granskarblock             |
-| `bedöm <gid, slug eller nr>`           | Grind → säkra analys → dispatcha `request-classifier` ∥ `request-scorer` → arkivera JSON |
-| `status`                               | Kö-läge via request-sync, BLUF-tabell med radnummer                                      |
-| `godkänn <nr eller gid>`               | Flytta Offer status framåt via request-sync — se grindavsnittet                          |
-| `underkänn <nr eller gid> <skäl>`      | Skäl som Asana-kommentar + iterationsräknare via request-sync                            |
-| `detaljer <gid, slug eller nr> [steg]` | Skriv ut arkiverad JSON/dokument för posten                                              |
-| `utvärdera <post…> [modell]`           | A/B-kör hela flödet per modellvariant till experimentytan; `sammanställ` ger svepvyn     |
-| `hjälp`                                | Förklara uppgifterna, rör inga filer                                                     |
+| Uppgift                                | Gör                                                                                                                                    |
+| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| `speca <önskemål eller gid>`           | Källmanifest → dispatcha `request-specifier` → arkivera spec + granskarblock                                                           |
+| `bedöm <gid, slug eller nr>`           | Grind → säkra analys → dispatcha `request-scorer` → arkivera JSON                                                                      |
+| `status`                               | Kö-läge via request-sync, BLUF-tabell med radnummer                                                                                    |
+| `godkänn <nr eller gid>`               | Flytta Offer status framåt via request-sync — se grindavsnittet                                                                        |
+| `underkänn <nr eller gid> <skäl>`      | Skäl som Asana-kommentar + iterationsräknare via request-sync                                                                          |
+| `döm <post>`                           | Människodom vid OLIKA: välj körning, beställ omkörning eller underkänn underlaget                                                      |
+| `detaljer <gid, slug eller nr> [steg]` | Skriv ut arkiverad JSON/dokument för posten                                                                                            |
+| `utvärdera <post…> <modell…>`          | Kör flödet en gång per namngiven modell mot experimentytan, minst en modell; `sammanställ` ger svepvyn, `rapport` en läsbar jämförelse |
+| `hjälp`                                | Förklara uppgifterna, rör inga filer                                                                                                   |
 
 ## Hårda regler
 
@@ -32,20 +33,30 @@ respektive skill. Här bor bara routing, kontextbärande, arkivet och dispatchen
   Skill-verktyget (`request-sync`).
 - **En skrivare i taget mot Asana.** Batchresultat skrivs tillbaka sekventiellt,
   en post i taget, aldrig parallellt.
-- **Dokument klistras bytetroget** in i subagent-prompter. Klassningens och
-  poängens belägg är ordagranna citat; en trunkerad eller omformaterad inklistring
-  ger tyst fel svar. Klistra aldrig in en sammanfattning.
-- **Prislistan och repot hålls borta från classifier/scorer.** Deras
-  agentdefinitioner saknar sök- och shellverktyg (Grep/Glob/Bash), men Read
-  finns kvar för skillens referensfil — läs-scopet är alltså en promptregel,
+- **Dokument klistras bytetroget** in i specifier- och assessor-prompter
+  (önskemål, spec, granskarblock). En trunkerad eller omformaterad
+  inklistring flyttar källtexten under agentens fötter och ger tyst fel
+  svar. Klistra aldrig in en sammanfattning.
+- **Prissättningens underlag pekas ut per sökväg (ADR-0099).** Scorerns
+  prompt bär två namngivna absoluta sökvägar (`spec.md`, `impact.md`) i
+  stället för inklistrad text — agenten läser filerna själv via Read, så
+  ingen avskrift kan trunkeras, och beläggens ankare (källa + delsträng)
+  löses av scripten mot exakt samma filer på disk. Läs-scopet är EXAKT
+  dessa två filer plus skillens egen katalog, aldrig
+  körningskatalogen som helhet: `granskarblock.md` är assessorns underlag
+  och äldre pricing-JSON vore ren kontaminering av dubbelkörningens
+  oberoende.
+- **Prislistan och repot hålls borta från scorern.** Dess
+  agentdefinition saknar sök- och shellverktyg (Grep/Glob/Bash), och Read
+  är promptbegränsad enligt regeln ovan — läs-scopet är en promptregel,
   inte en fysisk spärr. Därför: lägg aldrig prislistans innehåll i prompten,
   och lägg inga egna sökvägar i dispatcherns rader utöver etiketterna i mallen.
-  Sökvägar som redan står i det bytetrogna underlaget (analysen namnger filer,
+  Sökvägar som redan står i underlaget (analysen namnger filer,
   det är dess jobb) är inte ett brott — regeln gäller det dispatchern
   lägger till. Granska `LÄSTA:`-raden i svaret (se dispatch-kontraktet).
 - **Granskarblocken når aldrig kunden.** Specens granskarblock arkiveras separat
   (`granskarblock.md`). Analysens "## Till granskaren"-block ligger kvar i
-  `impact.md` (det är del av underlaget för klassningen) — men inget
+  `impact.md` (det är del av underlaget för poängsättningen) — men inget
   granskarblock får någonsin skickas med i material som går till request-sync
   för kundsynliga fält.
 - **Arkivet är cache, Asana är sanningen.** Vid konflikt vinner brädan.
@@ -54,39 +65,59 @@ 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
+  contract-check har bevisat. En oenighet mellan två GILTIGA körningar är en
+  bedömningsfråga och går alltid till människan via uppgiften `döm`: fler
+  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.
 
 **En katalog = en spec = en prissättningsbar post.** En bunt (flera specar ur
-samma önskemål) blir flera kataloger — klassningen räknar omfattning per spec
-och poängen sätts per post, så en katalog med flera specar går inte att bedöma.
+samma önskemål) blir flera kataloger — poängen sätts per post, så en katalog
+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)
 ├── impact.md                      påverkansanalysen, ordagrann inkl. sitt
 │                                  Till granskaren-block
-├── classification-pricing-vN.json  nytt varv = ny fil, skriv aldrig över
-├── score-pricing-vN.json           N är gemensamt för paret (se bedöm steg 8)
-├── classification-guard-vN.json    guard-utfall synkas aldrig, bara arkiveras
-├── score-guard-vN.json
+├── score-pricing-vN.json           nytt varv = ny fil, skriv aldrig över
+├── score-guard-vN.json             guard-utfall synkas aldrig, bara arkiveras
+│                                   (egen N-sekvens per typ, skild från pricing)
 └── state.json
 ```
 
+Äldre arkiv (före ADR-0098) bär även `classification-pricing-vN.json` /
+`classification-guard-vN.json` från den borttagna klassaxeln. De läses och
+visas som förut (`detaljer`, rapporten, `archive.mjs`) men skrivs aldrig av
+nya körningar.
+
+Förkastade försök bär `-avvisad`-suffix och står utanför N-räkningen:
+prissättningens `<typ>-pricing-vN-avvisad.json` och textstegens
+`spec-avvisad-<datum>.md` / `impact-avvisad-<datum>.md` (ADR-0099) — se
+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`
 
@@ -113,36 +144,44 @@ och poängen sätts per post, så en katalog med flera specar går inte att bed
   `{ "source": "asana" | "manual", "by": "<namn, krävs vid manual>",
  "status_read": "<värde>", "date": "YYYY-MM-DD" }`.
   Anteckningen är spårbarhet, aldrig själva godkännandet.
-- `granskarutslag` är en lista, en rad per viktningsutslag (granskaren
-  konstaterar att en körning hade rätt, utan att någon sakuppgift ändras).
-  `bedöm` steg 6 APPENDAR en rad, skriver ALDRIG över tidigare rader:
-  `{ "varv": N, "date": "YYYY-MM-DD", "beslut": "<granskarens beslut,
-ordagrant>" }`. Tom lista (`[]`) när inget viktningsutslag ännu skett.
-  Listan är ett revisionsspår och läses medvetet ALDRIG tillbaka in i någon
-  prompt: utslaget är granskarens dom över körningarna, och når den agenterna
-  styr den nästa bedömning i stället för att dokumentera den föregående.
-  Nollas (töms) vid respec, av samma skäl som `approval` nollas (se `speca`
-  steg 5): ett utslag mot en ersatt spec är inte längre giltigt. Bor ENDAST
-  i `state.json`. Ett sakändringsutslag går i stället in i `impact.md` som
-  Granskarutslag-blocket (se `bedöm` steg 6), aldrig hit.
+- `granskarutslag` är en lista, en rad per dom, skriven via `archive.mjs utslag`, aldrig för hand.
+  Radform: `{ "typ": "viktning" | "kalibrering" | "sakandring", "date": "YYYY-MM-DD", "beslutad_av": "<namn>", ... }`.
+  Viktning bär dessutom `beslut` (ordagrant), `axel` (`score`; `classification`
+  förekommer i äldre arkiv), `n` och `galler_fil`: raden ÄR spärrlyftet,
+  `archive.mjs sparr` läser den.
+  Kalibrering bär `fraga`, `lasning1`, `lasning2`: en notis om att en
+  protokollfråga lät två giltiga läsningar divergera, underlag för nästa
+  instruktionsversion. Sakändring bär `beslut`: kvittot i `state.json` för
+  samma händelse som citatblocket i `impact.md` (se `döm`, vägen "Underlaget
+  är fel"). Det ordagranna beslutet bor i citatblocket, raden här är bara
+  revisionsspåret, aldrig underlaget självt.
+  Listan läses medvetet ALDRIG tillbaka in i någon prompt, oavsett typ: ett
+  utslag som når agenterna styr nästa bedömning i stället för att dokumentera
+  den föregående. Nollas (töms) vid respec, av samma skäl som `approval`
+  nollas (se `speca` steg 5): ett utslag mot en ersatt spec är inte längre
+  giltigt. Bor ENDAST i `state.json`. Rader skrivs aldrig om.
 - `runs[]` får en rad per dispatch, även spec- och analyskörningar:
   `{ "file": "spec.md" | "impact.md" | "<run>.json", "skill": "...",
- "agent": "...", "model": "<ur MODELL-raden>", "effort": "<ur agentdefinitionen>",
+ "agent": "...",
+ "model": { "uppgiven": "<ur MODELL-svansraden>", "fakturerad": "<känd fakturerad modell, annars null>" },
+ "effort": "<ur agentdefinitionen>",
  "date": "YYYY-MM-DD",
  "reference_sha256": { "<referensfil>": "<sha256>" },
  "underlag_sha256": { "spec.md": "<sha256>", "impact.md": "<sha256>" },
  "double_run": "bekräftad" | "olika" | "tolerans" | null,
- "superseded_by": null, "partial_rerun": false, "pairs_with": null,
- "quote_repairs": <antal> }`.
-  `quote_repairs` är frivilligt (utelämnas när det är 0): antal RÄTTAT-rader
-  från `quote-repair.mjs` för den körningen.
-  `partial_rerun` och `pairs_with` är frivilliga och sätts bara på en
-  pricing-rad ur ett riktat varv (se `bedöm` steg 6): `partial_rerun: true`
-  markerar att raden kom ur en enaxlig omkörning, och `pairs_with` namnger
-  den stående axelns fil den paras med. Pekaren bor på den omkörda axelns
-  nya rad, aldrig på den stående axelns äldre rad, som aldrig skrivs om.
-  Saknas (eller står `false`/`null`) på spec- och analysrader och på rader
-  ur ett fullt varv.
+ "superseded_by": null, "partial_rerun": false, "pairs_with": null }`.
+  `model` bär två fält (ADR-0099): `uppgiven` är agentens självrapport ur
+  MODELL-svansraden, `fakturerad` fylls när dispatchern känner den
+  fakturerade modellen (`add-run --fakturerad`), annars `null` — faktureringens
+  sanning per körning bor i `proveniens.fakturerade_modeller`. Äldre arkiv bär
+  `model` som ren sträng och läses som förut.
+  `quote_repairs` förekommer i äldre arkiv (före ADR-0092) och läses men
+  skrivs aldrig av nya körningar.
+  Stämplingen görs alltid via `archive.mjs add-run`; hur N räknas ut, vilket
+  suffix en fil får och hur en riktad omkörnings parning skrivs bor i
+  scriptet och testerna. VILKA `--typ` som skickas till `archive.mjs next-n`,
+  alltså vilka axlar som faktiskt kördes i varvet, är fortfarande
+  orkestratorns beslut, inte scriptets.
   `underlag_sha256` är underlagsproveniensen: hashen för de dokument körningen
   faktiskt såg. Precheck vägrar bedöma när analysens spec-hash inte matchar
   nuvarande `spec.md`, och guard ska vägra diffa mot en körning vars underlag
@@ -154,46 +193,74 @@ ordagrant>" }`. Tom lista (`[]`) när inget viktningsutslag ännu skett.
   alla arkiverade körningar. Samma verktyg används för `underlag_sha256`.
   Referensfilerna ligger under Claude-konfigkatalogen (`CLAUDE_CONFIG_DIR`
   eller `~/.claude`). En senare guard-körning jämför hash och vägrar diffa vid
-  skevhet ("omklassning krävs, skalan har ändrats").
+  skevhet ("ompoängsättning krävs, skalan har ändrats").
 - `status` blir ALDRIG `priced` när något stopputfall finns i varvets
-  körningar, eller när det GÄLLANDE paret har `double_run: "olika"` olyft.
-  Spärren gäller det gällande paret, inte varje enskild rad för sig: har ett
-  senare riktat varv landat LIKA eller LIKA_TOLERANS, är spärren lyft för
-  hela paret, även om den oeniga axelns äldre rader fortfarande bär
-  `double_run: "olika"` (de skrivs aldrig om, se `partial_rerun`/
-  `pairs_with` ovan). Läs upplåsningen på den omkörda axelns senaste rad,
-  aldrig på en äldre. `double_run: "tolerans"` räknas som bekräftad och
-  blockerar inte `priced`.
+  körningar, eller när den GÄLLANDE raden har `double_run: "olika"` olyft, eller
+  när den gällande raden bär `partial_rerun: true` utan en matchande
+  dom (en beställd omkörning väntar på granskaren, se uppgiften `döm`).
+  `archive.mjs sparr` avgör bägge skälen identiskt (`sparrSkal`).
+  Spärren lyfts av ett viktningsutslag (`archive.mjs sparr` är den enda tolken,
+  se uppgiften `döm`) eller av en beställd omkörning vars dom landat i ett
+  viktningsutslag; ingen annan väg lyfter den, och den oeniga axelns äldre
+  rader skrivs aldrig om även efter lyft.
+  `double_run: "tolerans"` räknas som bekräftad och blockerar inte `priced`.
+  I äldre arkiv som bär en klassaxel (före ADR-0098) vägrar
+  `archive.mjs set-status priced` därutöver ett OFULLSTÄNDIGT par:
+  klass- och poängaxelns gällande varvnummer skiljer sig utan att skillnaden
+  är en förklarad enaxlig omkörning (`partial_rerun: true` på den högre
+  axelns gällande rad), eller poängaxeln saknas helt. Ett arkiv utan
+  klassaxel prövas aldrig mot par-regeln — poängen är den enda axeln.
+  Det här skälet prövas av `pricedBlockers` (`archive.mjs set-status`),
+  inte av `archive.mjs sparr` — reglerna bor i scriptet och dess tester.
 - `spec_synced` sätts av speca steg 7 (posten lagd på brädan);
   `guard_run` reserveras för guard-kommandot (senare byggsteg).
 
 ### Experimentytan: `experiments/`
 
-A/B-körningar från `utvärdera` bor i ett eget träd och är aldrig prisposter:
+Modellkörningar från `utvärdera` bor i ett eget träd och är aldrig prisposter:
 
 ```
-<repo-rot>/.haus/requests/experiments/<slug>/
-├── experiment.json          ticketreferens, datum, kandidatmodell,
-│                            modell per agent per varv, manifest-hash, status
-├── jamforelse.md            skrivs när båda varven är klara
-├── baseline/                full standardstruktur enligt arkivkontraktet ovan
-└── <kandidatmodell>/        samma struktur; delkataloger del-N/ vid DELA_UPP
+<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/matning.json      startarens egen mätning: startad, avslutad, wall_ms
+│   ├── k2/                  senare körning av SAMMA modell
+│   └── k2/del-1/ …          delkataloger vid DELA_UPP
+└── <annan modell>/k1/ …
 ```
 
-- Katalognamnet `experiments` är reserverat — en spec vars rubrik skulle
-  sluggas till `experiments` får suffixet `-post`.
-- Variantkatalogerna följer postkatalogens kontrakt bytetroget (spec.md,
-  granskarblock.md, impact.md, pricing-JSON, state.json, `runs[]`-reglerna) —
-  därför fungerar `precheck.mjs` och `contract-check.mjs` oförändrade, och
-  proveniensen (modell, effort, hashar) följer med gratis.
-- `state.json` i en variantkatalog bär markören `"experiment": true`.
-  `approval` förblir `null` och `status` blir ALDRIG `priced` — ett
+- **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.
+- **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
+  alltid. Varje körning får därför en egen katalog `k<N>` under sin modell.
+- **Körningskatalogen ÄR postkatalogen.** Den följer arkivkontraktet
+  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.
+- **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
   experimentresultat kan inte förväxlas med en prispost.
-- `experiment.json` bär `status` per variant: `"klar"` (båda stegen
-  arkiverade och jämförelse-underlag komplett), `"ofärdig"` (avbruten,
-  subagentdöd, kontraktsbrott eller MODELL-avvikelse), `"stopp"` (arkiverat
-  stopputfall).
-- `experiments/` ärver gitignore-skyddet från `.haus/requests/`.
+- 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
+  med `baselinemodell` och `kandidatmodell` läses utan fel; nya skrivningar
+  använder bara `varianter`.
+- `experiments/` ärver gitignore-skyddet från `.haus-workflow/requests/`.
 
 ## Uppgift: `speca`
 
@@ -218,8 +285,14 @@ A/B-körningar från `utvärdera` bor i ett eget träd och är aldrig prisposter
    kopieras till varje katalog som `granskarblock.md`). 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. Lägg en `runs`-rad (`file: "spec.md"`, med `underlag_sha256`
-   tomt) i varje berörd state.json.
+   vid sync. Stämpla varje berörd `state.json` med
+   `node <skillkatalog>/scripts/archive.mjs add-run <katalog> --file spec.md
+--skill request-write-spec --agent <request-specifier|request-specifier-eskalerad>
+--model <ur MODELL-svansraden> --ref references/specformat.md=<hash via ref-hash.mjs
+på request-write-spec/references/specformat.md>`. Scriptet sätter
+   `underlag_sha256` tomt, en spec har inget underlag i repot — men
+   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`
@@ -228,7 +301,15 @@ A/B-körningar från `utvärdera` bor i ett eget träd och är aldrig prisposter
    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; BRISTER i `state.json` är wrapperns egna filer och
+   enligt omdispatch-regeln. **Det förkastade utkastet får kvitto
+   (ADR-0099, samma regel som prissättningens `-avvisad`):** arkivera det
+   som `spec-avvisad-<datum>.md` innan omdispatchen, och stämpla det med en
+   egen runs-rad via `archive.mjs add-run --file spec-avvisad-<datum>.md
+--note "<kontrollens felrader>"` (övriga flaggor som spec-radens). VARJE
+   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.
+   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.
 7. **Svara BLUF:** en rad per spec (rubrik + ev. flaggor), sedan granskarblocket
@@ -239,8 +320,8 @@ A/B-körningar från `utvärdera` bor i ett eget träd och är aldrig prisposter
 
 ## Uppgift: `bedöm`
 
-Kör prissättningsbenet: påverkansanalys om den saknas, sedan klass ∥ poäng med
-oenighetsgrind.
+Kör prissättningsbenet: påverkansanalys om den saknas, sedan poängsättning med
+driftvakt.
 
 1. **Grind — obligatorisk, aldrig överhoppbar.** Bedömning kräver en granskad
    spec, och godkännandet bor i Asana:
@@ -249,7 +330,7 @@ oenighetsgrind.
      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.
@@ -274,207 +355,110 @@ oenighetsgrind.
    skickas med som internt underlag (samma förtroendedomän; flaggorna där är
    ofta analysens viktigaste ingång). Arkivera svaret som `impact.md`
    (inklusive dess "## Till granskaren"-block — visa blocket för användaren,
-   aldrig till kundfält), lägg en `runs`-rad (`file: "impact.md"`,
-   `underlag_sha256` med hash för `spec.md`). Kör precheck igen med `--impact`.
-4. **Prissättning.** Dispatcha `request-classifier` och `request-scorer`
-   **parallellt i samma meddelande** enligt promptmallarna. Ingen prislista,
-   inget repo, inga andra posters dokument i prompterna.
-5. **Kontraktskontroll.** Strippa svansraderna (`MODELL:`, `LÄSTA:`, ev.
-   `AVVIKELSE:`) ur varje svar, skriv den rena JSON:en till en temporär fil och
-   kör `node <skillkatalog>/scripts/contract-check.mjs <svar.json> <spec.md> <impact.md> --expect-id <katalogens id>`.
-   BROTT → kör först
-   `node <skillkatalog>/scripts/quote-repair.mjs <svar.json> <spec.md> <impact.md>`
-   (deterministisk citaträttning: ett nästan-ordagrant belägg ersätts med sin
-   entydigt närmaste källmening, allt annat lämnas orört; utan citatbrott är
-   scriptet en no-op). Exit 0: kör kontraktskontrollen igen och anteckna
-   `quote_repairs: <antal RÄTTAT-rader>` i runs-raden.
-   **VARJE RÄTTAT-rad (före → efter) visas dessutom ordagrant för användaren i
-   BLUF-svaret**, på samma sätt som en `AVVIKELSE:`-rad alltid visas. En
-   räknare går inte att granska: rättningen byter belägg i en bedömning som
-   redan är gjord, och den som läser svaret ska kunna se exakt vilket citat som
-   byttes mot vilken källmening. Aldrig bara antalet. Kvarstår BROTT efter
-   rättningen, eller gav rättningen exit 1 (orättbara citat): dispatcha om just
-   den agenten EN gång enligt omdispatch-regeln;
-   kvarstår brott, visa dem och stanna utan att arkivera det svaret som giltigt
-   varv — men släng det inte: arkivera det som `<typ>-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 inget av svaren är ett
-   stopputfall — stopproutningen i steg 7 går alltid först, en post som ändå
-   går till människa ska inte kosta fyra extra körningar. Trigger: klassningens
-   **utfall** är MEDIUM, LARGE eller OFFERT, ELLER poängen är ≥ 4 (poängen
-   multipliceras direkt till pris — en hög poäng på låg klass förtjänar samma
-   vakt). Dispatcha då `request-classifier` OCH `request-scorer` EN gång till,
-   samma prompter, nya isolerade körningar, parallellt i samma meddelande.
-   Kostnaden (ett extra par körningar) läggs medvetet exakt där pengarna står
-   på spel — poängen multipliceras direkt till pris och båda skillsens eget
+   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
+   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
+   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.
-   - Kör kontraktskontrollen (steg 5) på båda nya svaren först, med egen
-     omdispatch-budget (EN per agent).
+   - 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-classifications.mjs <klass1.json> <klass2.json>`
      `node <skillkatalog>/scripts/compare-scores.mjs <poäng1.json> <poäng2.json>`
-   - **Båda LIKA** → körning 1-paret gäller: `double_run: "bekräftad"` på dess
-     runs-rader. Körning 2-filerna arkiveras som `...-pricing-vN-run2.json`
-     med SAMMA N som paret och `superseded_by` satt till motsvarande körning
-     1-fil. `-run2`-filer räknas ALDRIG när nästa N bestäms, och guard och
+   - **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.
+     `-run2`-filer räknas ALDRIG när nästa N bestäms, och guard och
      `detaljer` läser alltid filen utan suffix.
-   - **Någon OLIKA** → behandla posten som ESKALERA. Det beskriver routingen,
-     aldrig artefakten: ingen fil ändras, ingen JSON skrivs om, inget
-     ESKALERA-värde patchas in. Arkivera båda körningarna för båda axlarna
-     (den som inte blir axelns huvudfil arkiveras som `-run2`) och stämpla
-     runs-raderna PER AXEL, aldrig per
-     varv. Det finns exakt en regel, och den går efter vad axelns eget
-     jämförelsescript skrev:
-     - **Den OENIGA axeln** (den vars script skrev OLIKA) får
-       `double_run: "olika"` och `superseded_by: null` på bägge sina
-       runs-rader. Körning 1 är huvudfil utan suffix och körning 2 arkiveras
-       som `-run2`, men ingen av dem är utslagen: oenigheten är
-       oavgjord tills en människa eller ett riktat varv avgör den, och
-       `superseded_by` förblir därför `null` på båda.
-     - **Den ENIGA axeln** behåller sitt vanliga utfall och sitt vanliga
-       `superseded_by`: LIKA ger `double_run: "bekräftad"` med körning 1 som
-       suffixfri huvudfil, LIKA_TOLERANS ger `double_run: "tolerans"` med
-       verdiktradens utpekade körning (högsta poängen) som suffixfri
-       huvudfil och den andra som `-run2` med `superseded_by` mot den, precis
-       enligt LIKA_TOLERANS-punkten nedan, oavsett vilken av dem som var
-       körning 1. Regeln "högsta poängen gäller" är densamma oavsett vilken
-       punkt som routar posten.
-
-     Arkivet namnger därmed vilken axel som var oenig: `"olika"` står bara på
-     den axelns rader. Jämförelsescriptens verdikter lever bara i stdout och
-     försvinner med sessionen, så utan den stämplingen kunde ett senare varv
-     köra om fel axel och släppa igenom en oavgjord klassflip till pris.
-     Var BÅDA axlarna OLIKA bär bägge axlarnas rader `"olika"`.
-     Status blir `assessed`. Visa diffen (rad · körning 1 · körning 2)
-     för granskaren. Inget `customer`-block ur någon av körningarna får gå
-     till request-sync medan det GÄLLANDE paret har `double_run: "olika"`
-     olyft (samma scope som `priced`-spärren, se state.json-reglerna ovan):
-     har ett senare riktat varv landat LIKA eller LIKA_TOLERANS är spärren
-     lyft för hela paret, även om den oeniga axelns äldre rader fortfarande
-     bär `"olika"`. Läs upplåsningen på den omkörda axelns senaste rad,
-     aldrig på en äldre. Välj ALDRIG en av körningarna själv och räkna
-     ALDRIG fram ett medelvärde.
-     **Återställningen är ett riktat nytt varv:** spärren (`double_run:
-"olika"`) sitter på den oeniga axelns rader, och ett nytt varv med LIKA
-     (eller LIKA_TOLERANS) låser upp hela paret. VILKEN axel som körs om är
-     ingen bedömning: det är den axel vars runs-rader bär `"olika"`.
-     **Den omkörda axeln dubbelkörs ALLTID i ett riktat varv**, oavsett
-     triggervillkoren i steg 6: spärren kan bara lyftas av ett
-     jämförelseutslag, och en ensam körning ger inget att jämföra mot. En
-     klassomkörning som landar SMALL med stående poäng under 4 skulle annars
-     aldrig få något utslag och raderna förbli låsta för alltid. Hur MÅNGA
-     axlar som körs om beror på vilket slags utslag granskaren gav:
-     - **Viktningsutslag** (granskaren konstaterar att en körning hade rätt,
-       utan att någon sakuppgift ändras): appendas som en ny rad i
-       `state.json.granskarutslag` (se ovan), skriver ALDRIG över en
-       tidigare rad, och går ALDRIG in i `impact.md`. Se
-       Granskarutslag-punkten nedan för varför en fri text i underlaget vore
-       fel. Underlaget är därmed oförändrat, så kör ENDAST den axel om
-       (klass eller poäng) som var OLIKA, och bara den omkörda axelns agent
-       dispatchas, aldrig båda. Triggerns villkor läses fortfarande mot den
-       omkörda axelns nya svar plus den stående axelns gällande fil, aldrig
-       mot ett nytt körningspar, men det är inte triggern som avgör om axeln
-       dubbelkörs: i ett riktat varv dubbelkörs den alltid. Var BÅDA axlarna
-       OLIKA finns ingen enig axel att hålla stilla: kör då BÅDA om ändå,
-       `partial_rerun` förblir `false` på bägge nya rader. Vid enaxlig
-       omkörning paras den stående axelns gällande fil med det nya resultatet
-       (se steg 8) utan att skrivas om. Landar det riktade varvet
-       LIKA/LIKA_TOLERANS lyfts spärren för hela paret, antecknat på den
-       omkörda axelns nya runs-rad (`partial_rerun: true`, `pairs_with` mot
-       den stående filens namn). Pekaren bor på den nya raden, den stående
-       axelns rad skrivs aldrig om, så guard och `detaljer` läser
-       upplåsningen via `pairs_with` på den nya raden, aldrig tvärtom.
-     - **Sakändringsutslag**, eller ett beslut som av annat skäl måste stå i
-       underlaget (se Granskarutslag-punkten nedan): appendas i `impact.md`,
-       och vid en faktisk sakändring körs assessorn om (ny `impact.md`).
-       Underlaget har då ändrats, en körning mot gammalt underlag får aldrig
-       paras med en mot nytt, `underlag_sha256` skulle skilja och
-       proveniens-kontrollen finns just för den skevheten, så kör BÅDA
-       axlarna om, `partial_rerun` `false` på båda nya rader.
-
-   - **Granskarutslag skrivs som citat, aldrig som prosa.** När granskarens
-     beslut ska in i underlaget, alltså när det ändrar eller preciserar en
-     sakuppgift i analysen, eller av annat skäl måste stå i underlaget för
-     spårbarhet: appendas det sist i `impact.md` som ett avgränsat block
-     enligt mallen nedan, beslutet ordagrant citerat, aldrig omformulerat av
-     dispatchern och aldrig invävt i analysens löptext. En fritt formulerad
-     utslagsmening läses av nästa körning som sakuppgift och styr om
-     klassningen, det var precis felet i pilotkörningarna, därför alltid
-     mallen, aldrig fri prosa. Kräver beslutet en faktisk sakändring i
-     analysen: kör om assessorn (ny `impact.md`). Underlaget har i båda
-     fallen ändrats, så `bedöm` kör om BÅDA axlarna (se riktade-varv-stycket
-     ovan). Ett rent viktningsutslag, där granskaren bara konstaterar att en
-     körning hade rätt utan att röra någon sakuppgift, hör ALDRIG hemma här:
-     det appendas i stället som en rad i `state.json.granskarutslag`, se
-     samma stycke, just för att underlaget ska förbli oförändrat och den
-     riktade omkörningen giltig. Blocket är internt underlag med samma status som
-     Till granskaren-blocket och följer aldrig med i kundtext.
-
-     ```
-     ## Granskarutslag (varv <N>, <YYYY-MM-DD>)
-
-     > <granskarens beslut, ordagrant>
-
-     Utslaget gäller endast viktningen mellan körningarna och ändrar inga
-     sakuppgifter i analysen ovan.
-     ```
-
-   - **Klassjämförelsen LIKA men poängjämförelsen skriver LIKA_TOLERANS**
-     (poängskillnad ≤ 0,5 med samma outcome och konfidens; klassjämförelsen
-     har ingen tolerans, en klassflip är alltid OLIKA och routar posten som
-     ESKALERA oavsett poängens tolerans, se föregående punkt) → paret räknas
-     som bekräftat. Bytet gäller ENDAST poängaxelns filer: klassaxeln följer
-     LIKA-regeln som vanligt, klass-körning 1-filen blir huvudfil utan suffix
-     och klass-körning 2 arkiveras som `-run2` med `superseded_by`. För
-     poängaxeln blir verdiktradens utpekade körning (högsta poängen)
-     huvudfilen `score-pricing-vN.json`, och den andra arkiveras som `-run2`
-     med `superseded_by` satt mot huvudfilen, oavsett vilken av dem som var
-     körning 1. N är fortfarande gemensamt för de axlar som kördes i varvet
-     (här: klass och poäng, båda).
-     Huvudfilerna kan alltså komma från olika körningar, till exempel klass ur
-     körning 1 och poäng ur körning 2. Det är avsiktligt: båda körningarna har
-     passerat kontraktskontrollen och skillnaden ligger inom toleransen. Sätt
-     `double_run: "tolerans"` på poängaxelns bägge runs-rader; klassaxelns
-     runs-rader får `double_run: "bekräftad"` som vanligt. 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.
-   - Exit 2 från ett jämförelsescript är ett dispatcherfel (ojämförbara
+   - **OLIKA** → domen är människans, aldrig maskinens. Arkivera båda
+     körningarna (körning 1 utan suffix, körning 2 som `-run2`; på båda
+     raderna `double_run: "olika"` med `superseded_by: null`).
+     Status `assessed`. Ingen kundtext får gå till
+     request-sync medan spärren står (`archive.mjs sparr` är tolken).
+     Visa i BLUF-svaret beläggen bakom oenigheten, sida vid sida:
+     diffraderna (outcome, score, ankare, konfidens) har ingen
+     radkoppling till beläggen, `drivers[]` är en egen lista, så visa
+     samtliga `drivers[].citat`/`pastaende` ur båda körningarna
+     som stöd för hela utfallet. Det var beläggen som avgjorde domen i
+     varje uppmätt äkta oenighet. Hänvisa sedan till `döm <post>` och
+     STANNA: ingen omkörning, ingen eskalering, inget val av körning.
+   - **LIKA_TOLERANS** (poängskillnad ≤ 0,5 med samma outcome, oavsett
+     konfidens, en konfidensskillnad ensam fäller aldrig ett par inom
+     toleransen) → paret räknas som bekräftat. Verdiktradens utpekade
+     körning (högsta poängen) blir huvudfilen `score-pricing-vN.json`,
+     och den andra arkiveras som `-run2` med `superseded_by` satt mot
+     huvudfilen, oavsett vilken av dem som var körning 1. Det är
+     avsiktligt: båda körningarna har passerat kontraktskontrollen och
+     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.
+   - Exit 2 från jämförelsescriptet är ett dispatcherfel (ojämförbara
      körningar) — visa felet och stanna, rapportera aldrig LIKA.
-7. **Oenighetsgrind klass ↔ poäng.** Deterministiska regler, i ordning:
-   - Endera svaret är ett stopputfall → hela posten routas enligt stopplistan
-     nedan. Det andra svaret arkiveras men markeras `superseded_by` mot
-     stopputfallets fil, och statusen blir `assessed`, aldrig `priced`.
-   - Båda levererar (klass + poäng): flagga oenighet i BLUF-tabellen mot
-     ankarbanden — klass TINY/SMALL med poäng ≥ 4, klass MEDIUM med poäng
-     ≤ 0.75 eller ≥ 13, klass LARGE/OFFERT med poäng ≤ 3. Flaggan är
-     information till granskaren — ingen automatisk åtgärd, ingen omkörning.
-8. **Arkivera** godkända JSON-svar. Paret arkiveras atomärt: båda eller inget
-   ("båda eller inget" gäller de axlar som kördes i varvet: vid riktad
-   omkörning arkiveras den omkörda axelns fil ensam, och dess runs-rad får
-   `partial_rerun: true` samt `pairs_with: "<den stående filens namn>"`.
-   Pekaren bor på den nya raden, aldrig på den stående axelns äldre rad, som
-   aldrig skrivs om, så guard och `detaljer` hittar paret genom att läsa den
-   nya raden),
-   och `N` i `-pricing-vN.json` är gemensamt för de axlar som kördes i
-   varvet (nästa N = högsta befintliga för någon av filtyperna + 1, räknat
-   bland de filtyper som kördes; vid riktad omkörning bumpar alltså bara den
-   omkörda filtypens N; `-run2`- och `-avvisad`-filer räknas aldrig;
-   guard-filer har en EGEN N-sekvens, skild från pricing). Uppdatera
-   `state.json.runs` med modell, effort, referens-hash och `underlag_sha256`
-   (hash för `spec.md` och `impact.md` som körningen såg) per fil, status →
-   `priced` (eller `assessed` vid stopputfall).
-9. **Svara BLUF:** tabell `post · klass · poäng · utfall · konfidens`, en rad
-   per avvikelse värd att se (oenighetsflagga, ESKALERA, DELA_UPP,
-   INPUT_SAKNAS, AVVIKELSE-rader, samt varje RÄTTAT-rad från citaträttningen
-   enligt steg 5). JSON:en visas inte i chatten —
+7. **Arkivera** godkända JSON-svar. Hämta varvets N med
+   `node <skillkatalog>/scripts/archive.mjs next-n <katalog> --typ score`,
+   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:
+   `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-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
+   annat, flaggnamnet med bindestreck, aldrig `--double_run` med understreck
+   som i JSON-fältet). Utelämna flaggan helt när ingen dubbelkörning gjorts.
+   `--superseded-by <fil>` och `--partial-rerun` (utan värde) läggs till där
+   de gäller, se runs-kontraktet. Stämplingsreglerna
+   bor i scriptet och dess tester, inte här. Sätt status via
+   `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
+   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.
 
-**Stopputfall routas, aldrig tolkas:**
+**Stopputfall routas, aldrig tolkas.** Ett stopputfall arkiveras som varvets
+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
@@ -524,104 +508,431 @@ missta:
 - Verben rör Offer status och kommentarer — aldrig Score, Class eller
   beskrivningsfält.
 
+## Uppgift: `döm`
+
+Människans dom över en post vars dubbelkörning skrev OLIKA. Adressering som
+`godkänn` (radnummer eller gid, aldrig fuzzy). Kräver att spärren står
+(`archive.mjs sparr` exit 1), annars: visa status och stanna.
+
+**En variantkatalog (från `utvärdera`) adresseras med sin sökväg direkt,
+aldrig med radnummer eller gid.** Experimentets slug är samma sträng som ett
+vanligt gid skulle vara, så gid-adressering skulle resolva till postkatalogen
+på toppnivå, inte till variantkatalogen under `experiments/<slug>/`.
+`archive.mjs` tar ändå en katalog som argument oavsett var den ligger, så
+sökvägen fungerar identiskt.
+
+**En dom på en katalog under `experiments/` skriver aldrig om
+`experiment.json` i sig.** `archive.mjs utslag` och `archive.mjs sparr`
+verkar bara på variantkatalogens egen `state.json`. Statusen i
+`experiment.json` uppdateras inte av `döm` — den uppdateras av `utvärdera`,
+körd igen för samma post, vars återupptagbarhetsregel omvärderar en
+`"väntar på dom"`-variant och gör utfallet synligt för rapporten när den körs
+(se `utvärdera`).
+
+1. **Visa underlaget.** Kör jämförelsescriptet på det gällande paret och visa
+   varje diffrad med beläggen sida vid sida (som i bedöm steg 6). Ingen
+   sammanfattning i stället för beläggen: domen fattas på dem.
+2. **Fråga granskaren** (AskUserQuestion) med tre vägar.
+   - **"Körning N gäller"** (N är 1 eller 2, vilken av de två uppmätta
+     körningarna som hade rätt): skriv domen via `archive.mjs utslag <katalog> --typ viktning --beslut "<ordagrant>" --beslutad-av <namn> --axel score --n <n> --galler-fil <fil>`.
+     (`--axel classification` finns kvar enbart för domar i äldre arkiv
+     med en klassaxel, före ADR-0098.)
+     `--n` är INTE körningsnumret i rubriken ovan: det är det AKTUELLA
+     varvet, avläst ur den senaste pricing-filen
+     `score-pricing-v<n>.json` (aldrig `next-n`s utdata, som pekar på
+     NÄSTA, ännu okörda varv). `--galler-fil` är den arkiverade fil
+     granskaren dömer till
+     förmån för: körning 1 → `score-pricing-v<n>.json` utan suffix,
+     körning 2 → `score-pricing-v<n>-run2.json`. Efter en beställd
+     omkörning (nästa väg) finns TRE arkiverade filer, och
+     `--galler-fil` kan peka på VILKEN som helst av dem: omkörningens egen
+     fil (version = gällande `n`), eller endera av de två ursprungliga
+     körningarnas filer från ett LÄGRE varv, om granskaren dömer att en av
+     dem hade rätt hela tiden. Scriptet vägrar bara ett HÖGRE varv än `--n`
+     (en dom kan aldrig gälla ett varv som inte fanns när den skrevs) och en
+     fil som inte faktiskt arkiverades via `add-run`. Kör `archive.mjs sparr`
+     efteråt: exit 0 betyder att spärren är lyft, exit 1 betyder att
+     något fortfarande väntar (utskriften namnger vad).
+     Inga filer döps om eller skrivs om.
+   - **"Beställ omkörning":** EN ny körning, ingen tvångsdubbling: dispatcha
+     scorern (ordinarie promptmall och kontraktskedja), arkivera med
+     `partial_rerun` och `pairs_with` mot den stående filen. Den nya
+     raden väntar precis som originalraden på en dom (`archive.mjs sparr`
+     spärrar den ensam, oavsett vad den råkar bära i `double_run`): visa
+     scriptdiffen mot BÅDA de stående körningarna och gå till steg 2 igen,
+     det är fortfarande granskaren som dömer. Vill granskaren ha två nya
+     mätningar beställs två.
+   - **"Underlaget är fel":** granskarens beslut appendas i `impact.md` som
+     citatblock enligt mallen nedan, assessorn körs om (ny `impact.md`),
+     därefter kör `bedöm` ett nytt fullt varv. En körning mot
+     gammalt underlag paras aldrig med en mot nytt.
+3. **Kalibreringsnotis.** Är oenigheten äkta (en fråga eller ett ankarval som
+   två giltiga körningar läste olika, inte en etikett): skriv `archive.mjs utslag <katalog> --typ kalibrering --beslutad-av <namn> --fraga <id> --lasning1 "<körning 1:s läsning, en mening>" --lasning2 "<körning 2:s läsning>"`.
+   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.
+
+**Granskarutslag skrivs som citat, aldrig som prosa.** När granskarens
+beslut ska in i underlaget, alltså när det ändrar eller preciserar en
+sakuppgift i analysen, eller av annat skäl måste stå i underlaget för
+spårbarhet: appendas det sist i `impact.md` som ett avgränsat block enligt
+mallen nedan, beslutet ordagrant citerat, aldrig omformulerat av
+dispatchern och aldrig invävt i analysens löptext. En fritt formulerad
+utslagsmening läses av nästa körning som sakuppgift och styr om
+bedömningen, det var precis felet i pilotkörningarna, därför alltid mallen,
+aldrig fri prosa. Kräver beslutet en faktisk sakändring i analysen: kör om
+assessorn (ny `impact.md`). Underlaget har i båda fallen ändrats, så
+`bedöm` kör ett nytt fullt varv (se steg 2 ovan, vägen "Underlaget är fel").
+Skriv samtidigt kvittot `archive.mjs utslag <katalog> --typ sakandring --beslut "<ordagrant>" --beslutad-av <namn>`
+i `state.json` (se `granskarutslag` ovan): citatet i `impact.md` är
+underlaget, sakandring-raden är bara revisionsspåret. Ett rent
+viktningsutslag, där granskaren bara konstaterar att en körning hade rätt
+utan att röra någon sakuppgift, hör ALDRIG hemma här: det skrivs i stället
+via `archive.mjs utslag --typ viktning` (se steg 2 ovan, vägen "Körning N
+gäller"), just för att underlaget ska förbli oförändrat. Blocket är internt
+underlag med samma status som Till granskaren-blocket och följer aldrig
+med i kundtext.
+
+```
+## Granskarutslag (varv <N>, <YYYY-MM-DD>)
+
+> <granskarens beslut, ordagrant>
+
+Utslaget gäller endast viktningen mellan körningarna och ändrar inga
+sakuppgifter i analysen ovan.
+```
+
 ## Uppgift: `detaljer`
 
 `detaljer <gid|slug|nr> [steg]` — skriv ut arkiverade filer för posten: utan
 steg en lista över vad som finns, med steg (`spec`, `granskarblock`, `analys`,
-`klass`, `poäng`, `state`) filens innehåll rått. För `klass`/`poäng`: senaste
+`poäng`, `state`) filens innehåll rått; `klass` läser äldre arkivs
+classification-filer (före ADR-0098). För `klass`/`poäng`: senaste
 `-pricing-vN.json` utan suffix (aldrig `-run2`/`-avvisad`).
 
 ## Uppgift: `utvärdera`
 
-A/B-utvärdering av modellvalet: kör en post genom hela flödet två varv —
-`baseline` med agentdefaults och ett varv med alla agenter tvingade till en
-kandidatmodell (default `opus`) — och arkivera all output sida vid sida under
-experimentytan. Uppgiften samlar underlag; människan analyserar. Ingen dom
-fälls över vilken modell som är bäst.
+Modellutvärdering: `utvärdera <post…> <modell…>`, med minst en modell. Kör en
+post genom hela flödet en gång per namngiven modell, varje varv med samtliga
+tre agenter (specifiern, assessorn, scorern) tvingade till varvets
+modell, så varje varv mäter en faktisk modellskillnad i stället för brus mellan
+en fast produktionsmix och en enda experimentmodell.
+`default` som modellvärde ger agentdefaults (dagens produktionsblandning) och
+kör utan override; katalognamnet blir då `baseline/`, för alla andra värden
+`<modell>/`. Arkivera all output sida vid sida under experimentytan.
+Uppgiften samlar underlag; människan analyserar. Ingen dom fälls över vilken
+modell som är bäst, och ingen dom simuleras: en OLIKA i något varvs
+dubbelkörning väntar på `döm`, precis som i produktion.
+
+**Underkommandon resolvas först.** Är det enda argumentet `sammanställ` eller
+`rapport`, är det underkommandot `utvärdera sammanställ` respektive
+`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.
+
+**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
+om det är ett känt agentmodellnamn (`fable`, `opus`, `sonnet`, `haiku`, …) eller
+literalen `default`, allt annat läses som post-id, och skanningen stannar vid
+det första argumentet som inte är ett modellnamn. Ett argument som varken är
+ett känt modellnamn eller ett giltigt gid/slug är ett FEL, aldrig en gissning:
+visa felet och stanna i stället för att chansa på vilken sida av gränsen det
+hör hemma. De modellargument skanningen hittar bildar sedan modellistan i
+DEKLARATIONSORDNING, vänster till höger.
+
+**Minst en modell krävs.** Hittar skanningen ingen modell alls är det ett FEL,
+aldrig en default. Ett kommando som kostar timmar och pengar ska säga vilka
+modeller det kör; en tyst standarduppsättning gör att en körning kan starta med
+en annan modell än den som avsågs, och den kostnaden syns först efteråt.
+
+**Dubbletter vägras.** Står samma modellvärde två gånger i listan, vägra
+körningen med ett felmeddelande som förklarar varför: två lika värden pekar på
+samma katalognamn och mäter ingen skillnad mot varandra. Vill du köra samma
+modell en gång till, gör det i en egen invokation, då blir det en ny körning
+under samma modell enligt regeln i Experimentytan.
+
+**En namngiven modell rör bara sin egen katalog.** Övriga modellers kataloger
+läses inte och skrivs inte. Det är det som gör att en jämförelse kan byggas i
+etapper: `utvärdera <gid> opus sonnet` idag och `utvärdera <gid> fable` en
+vecka senare ger tre modeller under samma post, utan att de första två körs om.
+
+**Omkörning frågas fram, den antas aldrig.** Namnger invokationen en modell som
+redan har körningar under sig, stanna INNAN något dyrt startas och fråga om de
+ska köras om. Ställ EN fråga som täcker alla kolliderande modeller, inte en per
+modell. Svaret kan ges i förväg med `--om` (kör om) eller `--hoppa-över` (rör
+dem inte); bär invokationen någon av dem ställs ingen fråga.
+
+En omkörning skriver aldrig över den gamla körningen, den blir `k<N+1>`.
+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 kandidatmodell.
+   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 båda varven. Anteckna manifest-hash i
+   återanvänd det byteidentiskt i ALLA varv. Anteckna manifest-hash i
    `experiment.json` (`ref-hash.mjs` på manifesttexten). Enda avsedda
    skillnaden mellan varven är modellen.
-3. **Eskaleringsvalet görs en gång** enligt `speca`:s regler och gäller båda
-   varven — även eskaleringsvalet är en del av det som hålls konstant.
-4. **Varv `baseline`.** Kör speca-stegen (dispatch, kontraktskontroll,
-   arkivering) och därefter bedöm-stegen (analys, klassning ∥ poäng,
-   dubbelkörning, citaträttning, riktad omkörning) enligt ordinarie
-   uppgifter, men mot variantkatalogen `baseline/` och utan
-   godkännandegrind: `approval` förblir `null`, `state.json` får
-   `"experiment": true`. Dispatcherna använder ordinarie promptmallar och
-   agenternas defaults — ingen override. `REQUEST_ID` och `--expect-id`
-   använder alltid ticketens gid/slug, aldrig variantkatalogens namn
-   (`baseline`/modellnamnet).
-5. **Varv `<kandidatmodell>`.** Exakt samma steg, prompter och underlag, men
-   varje Agent-anrop får modell-override till kandidatmodellen.
-   Agentdefinitionerna röres aldrig; effort tas ur definitionen som vanligt.
-   Verifiera via MODELL-svansraden att overriden slog igenom och redovisa
-   avvikelsen om den finns. Generellt för hela uppgiften: subagentdöd,
-   kontraktsbrott (kvarstående BROTT efter citaträttning) eller
-   MODELL-avvikelse — i vilket steg det än inträffar — sätter variantens
-   `status` till `"ofärdig"` i `experiment.json`.
-6. **DELA_UPP körs autonomt.** Ett DELA_UPP-utfall följer bedöms ordinarie
+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
+   `request-specifier`, likadant i alla varv. Modell-overriden i steg 4
+   gäller ändå den eskalerade agenten precis som de två andra: dess egen
+   pinnade modell, den som enligt agentdefinitionen ÄR eskaleringen, skrivs
+   ö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`:
+
+   ```
+   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>
+   ```
+
+   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
+   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,
+   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
+   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
-   `<variant>/del-1/ … del-N/` med `split` satt, förälderns `spec.md` +
-   `granskarblock.md` kopierade in, ny analys + klassning + poäng per del.
+   `<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.
    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
-   varvet och redovisa i jämförelsen — det andra varvet fortsätter oberoende.
-7. **Jämförelse.** När båda varven är klara, skriv
-   `experiments/<slug>/jamforelse.md`: delningsbeslutet per variant (delade
-   sig / delade sig inte), tabell per post/delpost med klass, poäng,
-   inringning, dubbelkörningsutfall, stopputfall och `quote_repairs` per
-   variant, samt kort notis om specskillnader (rubrik, omfång, Ingår
-   inte-avvikelser). Ingen värdering av vilken variant som är bättre —
-   rådatan per katalog är analysunderlaget.
-8. **Rapport.** BLUF i chatten: klart/ofärdigt per varv, stopputfall, och
-   sökvägen till `experiments/<slug>/`. Ingen skrivning mot Asana.
+   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.
+   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
+   Å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
+   när underlaget ska läsas sida vid sida. Ingen skrivning mot Asana.
 
 ### Batch: flera poster
 
-`utvärdera <post1> <post2> … [kandidatmodell]` kör varje ticket i en EGEN
+`utvärdera <post1> <post2> … <modell…>` kör varje ticket och modell i en EGEN
 headless-process, sekventiellt:
 
 ```
-claude -p "/request utvärdera <gid> <kandidatmodell>"
+claude -p --model sonnet --output-format json "/request utvärdera <gid> <modell> --hoppa-över --körning <katalog>"
 ```
 
+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.
+
+**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.
+
+`--körning <katalog>` pekar ut den körningskatalog som `archive.mjs ny-korning`
+redan allokerat åt den ticketen och modellen. Den inre processen 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.
+
 - **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
   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
+  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 ett varv startas kontrolleras arkivet —
-  skippet styrs av variantens `status` i `experiment.json`: `"klar"` eller
-  `"stopp"` hoppas över med en notis, `"ofärdig"` körs om från varvets
-  början. Varven är billiga relativt risken att lappa ihop halva körningar.
-  Ett svep över många tickets kan därmed fortsätta i en senare session utan
-  omkörningar.
+- **Återupptagbart:** 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.
+  `"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
+  `"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.
 
 ### Sammanställning
 
 `utvärdera sammanställ` läser alla `experiments/*/` och skriver
-`experiments/sammanstallning.md`: tabell per ticket med klass/poäng per
-variant, delnings- och stopputfall, och avvikelsemarkering där varianterna
-skiljer sig. Halvfärdiga kataloger märks `ofullständig`, aldrig tyst
+`experiments/sammanstallning.md`: tabell per ticket med en rad per modell som
+bär poäng, delnings- och stopputfall, plus avvikelsemarkering där
+modellerna skiljer sig. Modellens rad tas ur dess GÄLLANDE körning, den högsta
+`k<N>` vars status i `experiment.json` är `"klar"`. En modell utan klar körning
+representeras av sin senaste `k<N>` och märks `ofullständig` tillsammans med
+den körningens status. Halvfärdiga kataloger märks likadant, aldrig tyst
 utelämnade. Bara läsning — inga agentdispatcher, inga Asana-anrop.
 
-## Mekaniska kontroller: `scripts/`
-
-Sju deterministiska script (fem kontroller + `lib.mjs` med de delade
-byggstenarna + `ref-hash.mjs` för stabil hashning) ersätter modellkörningar
-där kontrollen är ren form —
+### Rapport
+
+`utvärdera rapport [--ut <fil>]` renderar en HTML-rapport över experimentytan
+med `scripts/report.mjs`. Rapporten täcker ALLTID hela ytan; något postfilter
+finns inte, menyn i rapporten är där läsaren väljer post. Utan `--ut` skrivs
+HTML på stdout, annars till filen. Publicera den som artefakt när den ska
+läsas.
+
+**Rapporten skrivs ALDRIG automatiskt.** Ingen körning genererar den när den
+blir klar. Den kostar nästan ingenting att regenerera, så det finns ingen
+anledning att skriva den på spekulation, och en fil som ingen bett om är en fil
+ingen litar på.
+
+Rapporten är ren läsning: inga agentdispatcher, inga Asana-anrop, inga
+skrivningar i arkivet utöver utdatafilen.
+
+Vad den visar: en meny över poster med ticketens titel, dess katalogslug och
+vilka modeller posten har, och per vald post en kolumn per körning. Varje delpost ur
+ett DELA_UPP-utfall är en egen kolumn efter sin körning (`opus / k1 / del-1`),
+eftersom det är där utfallen bor när en post delat sig. Sektionerna är fältvisa,
+samma fält på samma rad tvärs kolumnerna: utfall, poängens inringning med
+golv, tak, steg och drivers,
+specens fyra fält, samt `impact.md` och `granskarblock.md` hopfällda per
+körning. Äldre körningar med klassningsfiler (före ADR-0098) får dessutom
+sin Klassning-sektion renderad som förut — kalibreringshistoriken kastas inte.
+Sist står kostnaden (USD, tokens, väggtid, dispatcher) och proveniensen.
+En delkolumn saknar egen mätning och säger `ingår i k<N>`, aldrig omätt.
+Matrisen är ojämn med flit: en post kan ha två modeller och en annan tre,
+eftersom en dyrare modell läggs till bara där de billigare inte räckte.
+
+Vad den ALDRIG gör: rangordnar modeller, rekommenderar en nivå, räknar aggregat
+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.
+
+## 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
+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,
 billigare, snabbare och utan omdömesglidning. Varje script bär sha256 för de
 referensfiler vars regler det speglar och VARNAR när en katalogbump ändrat dem
 (kontraktsdrift ska upptäckas av en check, inte av en kund):
@@ -630,39 +941,39 @@ referensfiler vars regler det speglar och VARNAR när en katalogbump ändrat dem
   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).
+- `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>]`
-  — kontraktskontroll av classify/score-JSON EFTER körning: enums,
+  — 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/
   driver-citat som ordagranna substrängar av underlaget, protokollterm-
   svartlista i kundtextfält, sluten kuvertnyckellista, request_id mot katalogen.
-  INPUT_SAKNAS kräver saknas-lista i stället för frågerader.
-- `scripts/compare-classifications.mjs <a.json> <b.json>` — deterministisk
-  dubbelkörningsdiff: utfall, basklass, varje frågas svar och konfidensens sida
-  om 0.8-gränsen. Skriver `LIKA` eller `OLIKA` + diffrader, exit 0/1; exit 2 =
-  ojämförbara körningar (dispatcherfel, aldrig LIKA).
-- `scripts/compare-scores.mjs <a.json> <b.json>` — samma för poäng: outcome,
+  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.
+- `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.
+  Exit 0 = ok, 1 = kontraktsbrott (BROTT-rader), 2 = användningsfel.
+- `scripts/compare-scores.mjs <a.json> <b.json>` — deterministisk
+  dubbelkörningsdiff: outcome,
   score, confidence, golv- och takankare. Aldrig prosa. Skriver `LIKA`,
-  `LIKA_TOLERANS` (poängskillnad ≤ 0,5 med samma outcome och confidence, och
-  ankarband som överlappar eller angränsar; exit 0, verdiktraden pekar ut
-  körningen med högst poäng) eller `OLIKA` + diffrader; i övrigt samma
-  exit-semantik. Båda compare-scripten kräver mode `pricing`; guard-jämförelser
-  är en medveten utbyggnad i guard-steget.
-- `scripts/quote-repair.mjs <run.json> <spec.md> [impact.md]`: deterministisk
-  citaträttning som körs FÖRE omdispatch när contract-check fällt ett citat: ett
-  nästan-ordagrant belägg (eller citattecken-omgärdat driver-segment) ersätts med
-  sin entydigt närmaste källmening, allt annat lämnas orört. Rättar aldrig över
-  en polaritetsskillnad (negationsord) och skriver allt eller inget, så en
-  halvrättad fil aldrig arkiveras. Exit 0 = inga orättbara citat kvar (rättade
-  eller inga), 1 = orättbara kvar och filen orörd (omdispatch), 2 =
-  användningsfel eller oläsbar input (dispatcherfel).
+  `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.
 
 Kontrollerna bedömer aldrig innehåll och returnerar aldrig protokollutfall —
 en post som passerar kan fortfarande stoppas av protokollen själva, och det är
 deras jobb. Vid script-fel (exit 2 eller krasch): visa felet och stanna, kör
 aldrig vidare som om kontrollen passerat.
 
-## Dispatch-kontrakt (gäller alla fyra agenterna)
+## Dispatch-kontrakt (gäller alla tre agenterna)
 
 - Prompten är självbärande: agenten ser inte den här konversationen.
 - **Promptmallar, etiketterna ordagrant:**
@@ -692,31 +1003,32 @@ aldrig vidare som om kontrollen passerat.
   <granskarblock.md bytetroget>
   ```
 
-  `request-classifier` / `request-scorer`:
+  `request-scorer` (underlag per sökväg, ADR-0099 — aldrig inklistrat):
 
   ```
   REQUEST_ID: <gid eller slug>
   MODE: <pricing|guard>
   DELPOST: <nej | ja, del N av M>
 
-  SPEC:
-  <spec.md bytetroget>
-
-  PÅVERKANSANALYS:
-  <impact.md bytetroget>
+  SPEC: <absolut sökväg till spec.md>
+  PÅVERKANSANALYS: <absolut sökväg till impact.md>
   ```
 
-  (guard-läge lägger till `FULLPLAN:` och `TIDIGARE_KLASSNING:` /
-  `TIDIGARE_POANG:` — guard-kommandot kommer i ett senare steg.)
+  (guard-läge lägger till `FULLPLAN:` och `TIDIGARE_POANG:` —
+  guard-kommandot kommer i ett senare steg.)
 
 - **Svansrader efter huvudinnehållet**, i denna ordning: `MODELL: <modell-id>`
   (alla agenter), `LÄSTA: <kommaseparerade absoluta sökvägar eller "inga">`
-  (endast classifier/scorer — deras Read är promptbegränsad, raden gör regeln
+  (endast scorern — dess Read är promptbegränsad, raden gör regeln
   granskbar), `AVVIKELSE: <text>` (endast om något i prompten bröt mot agentens
   regler, t.ex. en prislista i underlaget). Svansraderna strippas före varje
   maskinell kontroll och före arkivering; MODELL antecknas i runs-raden,
-  LÄSTA verifieras ligga under agentens tillåtna katalog, AVVIKELSE visas
-  alltid för användaren.
+  AVVIKELSE visas alltid för användaren. LÄSTA kontrolleras MEKANISKT av
+  `scripts/check-lasta.mjs` (ADR-0099): raden ska bära underlagens två
+  utpekade sökvägar (båda obligatoriska) och får därutöver bara bära filer
+  under skillens egen katalog (referensfilen) — allt annat är ett
+  kontraktsbrott och behandlas som BROTT i bedöm steg 5 (omdispatch EN
+  gång, sedan stopp), aldrig bara en notis.
 - Agentens svar i övrigt är rådata enligt skillens kontrakt (prosa-dokument
   eller JSON), ingen kommentar runt om.
 - **Omdispatch (max EN per agent och varv):** skicka HELA ursprungsprompten
@@ -726,6 +1038,11 @@ aldrig vidare som om kontrollen passerat.
   <felraderna från kontrollen, citerade ordagrant>
   ```
   En ny subagent minns inget — enbart felrader utan underlag är obrukbart.
+  **Omtaget bokförs alltid (ADR-0099):** det förkastade försöket arkiveras
+  med `-avvisad`-suffix (prissättning: `<typ>-pricing-vN-avvisad.json`;
+  textsteg: `spec-avvisad-<datum>.md` / `impact-avvisad-<datum>.md`) och får
+  en egen runs-rad med kontrollens felrader — två körningar av samma steg
+  utan spår av varför är precis den lucka kvittot stänger.
 
 ## Använd inte när
 
@@ -734,5 +1051,5 @@ aldrig vidare som om kontrollen passerat.
 - Frågan gäller Asana-uppsättning ("koppla repot") — det är request-sync:s
   uppsättningsflöde, kör den direkt.
 - Guard-läget ("kör guarden", före första kodrad) — körs tills vidare via
-  request-classify/request-score direkt; ett `guard`-kommando kommer i ett
+  request-score direkt; ett `guard`-kommando kommer i ett
   senare steg.