@haus-tech/haus-workflow 4.7.0 → 4.9.0

package/library/catalog/validation-rules.json

@@ -140,7 +140,9 @@
     "myid",
     "oidc",
     "azure-ad",
-    "saml2"
+    "saml2",
+    "auth",
+    "next-auth"
   ],
   "intentsRequiredTags": [
     "stripe",
@@ -150,7 +152,9 @@
     "myid",
     "oidc",
     "azure-ad",
-    "saml2"
+    "saml2",
+    "auth",
+    "next-auth"
   ],
   "alwaysAllowedTags": [
     "haus",

package/library/global/agents/request-classifier.md

@@ -2,7 +2,7 @@
 name: request-classifier
 description: Kör request-classify-skillen isolerat på spec + påverkansanalys och returnerar klassnings-JSON enligt skillens kontrakt. Dispatchas av /request-skillen (uppgift bedöm, parallellt med request-scorer). Saknar medvetet sök- och shellverktyg (Grep/Glob/Bash); Read finns kvar för skillens referensfil och är promptbegränsad till skillkatalogen — därför redovisas varje läst sökväg i svaret. Underlaget kommer bytetroget i prompten; output är JSON-kuvertet plus svansraderna, inget annat.
 model: fable
-effort: max
+effort: high
 tools: Skill, Read
 ---
 

package/library/global/agents/request-scorer.md

@@ -2,7 +2,7 @@
 name: request-scorer
 description: Kör request-score-skillen isolerat på spec + påverkansanalys och returnerar poäng-JSON med inringning enligt skillens kontrakt. Dispatchas av /request-skillen (uppgift bedöm, parallellt med request-classifier). Saknar medvetet sök- och shellverktyg (Grep/Glob/Bash); Read finns kvar för skillens referensfil och är promptbegränsad till skillkatalogen — därför redovisas varje läst sökväg i svaret. Underlaget kommer bytetroget i prompten; output är JSON-kuvertet plus svansraderna, inget annat.
 model: fable
-effort: max
+effort: high
 tools: Skill, Read
 ---
 

package/library/global/settings-fragments/hooks.json

@@ -5,7 +5,7 @@
       "id": "hook.guard.file-access",
       "gate": "keep",
       "event": "PreToolUse",
-      "matcher": "Read|Edit|Write",
+      "matcher": "Read|Edit|Write|NotebookEdit",
       "command": "haus guard file-access --from-hook"
     },
     {

package/library/global/skills/haus-workflow/references/new.md

@@ -15,11 +15,12 @@ the agent; collect answers with AskUserQuestion and pass everything as flags.
 before anything else: "Add the new project as a member of this workspace, or scaffold it
 standalone elsewhere?"
 
-- **Add as workspace member** — scaffold under the workspace root (default folder: the
-  project name, sibling to the other member repos) instead of the cwd. After Phase 3
-  creates the repo, tell the user to add an entry for it to `haus.workspace.yaml` /
-  `repos.manifest.json` themselves — this flow only scaffolds and does not write either
-  file (no CLI command mutates them yet).
+- **Add as workspace member** — pass `--dir <workspace-root>` in Phase 3 so the project
+  lands beside the other member repos (folder name: the project name) instead of nested
+  inside whatever repo this session is standing in. The cwd is the only other placement
+  lever, and it is not yours to change. After Phase 3 creates the repo, tell the user to
+  add an entry for it to `haus.workspace.yaml` / `repos.manifest.json` themselves — this
+  flow only scaffolds and does not write either file (no CLI command mutates them yet).
 - **Standalone** — proceed exactly as below, unaffected by the workspace.
 
 Skip this ask entirely when Step 1.5 found Project or Not-set-up scope — proceed straight
@@ -65,13 +66,16 @@ Check the registry first: `haus new --list --json`.
 **Stack in the registry (fast path):**
 
 1. Preview:
-   `haus new <stack> <name> --json --yes --dry-run [--org <org>] [--no-github]`
+   `haus new <stack> <name> --json --yes --dry-run [--dir <path>] [--org <org>] [--no-github]`
    and show the planned steps in plain language. Phase 2's approval already covers
    running this for real — no further confirmation needed.
 2. Execute the same command without `--dry-run`. Parse the JSON:
    - `ok: true` → note project path, repo URL, and `installHint`.
-   - `ok: false` → report the failed step's `detail` verbatim — it contains the exact
-     resume commands. Do NOT retry destructively; the project directory is never
+   - `ok: false` → report the `detail` of every step whose status is not `done`,
+     verbatim — they contain the exact resume commands. A step may be `failed` (it did
+     not run), `skipped` (it did not happen, e.g. setup was declined), or `partial`
+     (it ran and part of it did not land, e.g. the config files were copied but the
+     follow-up push failed). Do NOT retry destructively; the project directory is never
      auto-deleted.
 
 **Stack not in the registry:**
@@ -109,9 +113,12 @@ stay there.
 
 ## Phase 5 — Build the walking skeleton
 
-1. Install dependencies: run the install command for the chosen package manager (fast
-   path: the `installHint` from the JSON — it does not exist off-registry). The test
-   loop needs them installed either way.
+1. Install dependencies. On the fast path the JSON's `installHint` is written for the
+   parent directory — it starts with `cd <name>`, so running it verbatim from inside
+   the project (where Phase 4 left you) fails. From in here, run the bare command for the
+   chosen package manager instead: `yarn` / `npm install` / `pnpm install`. Off-registry
+   there is no hint; run the same bare command. The test loop needs them installed either
+   way, so confirm the install actually succeeded before continuing.
 2. Read the new project's `CLAUDE.md` and `.haus-workflow/WORKFLOW.md`; they are
    authoritative from here on.
 3. Decide the project's file/folder structure BEFORE dispatching any build agent:

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

@@ -21,6 +21,7 @@ respektive skill. Här bor bara routing, kontextbärande, arkivet och dispatchen
 | `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                                                     |
 
 ## Hårda regler
@@ -50,6 +51,11 @@ respektive skill. Här bor bara routing, kontextbärande, arkivet och dispatchen
 - **Arkivet är cache, Asana är sanningen.** Vid konflikt vinner brädan.
 - **Godkännande antas aldrig.** Att en spec finns i arkivet betyder inte att den
   är granskad. Se grinden under `bedöm`.
+- **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
+  och rör aldrig `experiments/`.
 
 ## Arkivet: `.haus/requests/`
 
@@ -94,6 +100,7 @@ och poängen sätts per post, så en katalog med flera specar går inte att bed
   "bundle": { "parent_slug": null, "part": null, "of": null },
   "split": { "parent": null, "part": null, "of": null },
   "approval": null,
+  "granskarutslag": [],
   "note": null,
   "runs": []
 }
@@ -106,14 +113,36 @@ 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.
 - `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>",
  "date": "YYYY-MM-DD",
  "reference_sha256": { "<referensfil>": "<sha256>" },
  "underlag_sha256": { "spec.md": "<sha256>", "impact.md": "<sha256>" },
- "double_run": "bekräftad" | "olika" | null,
- "superseded_by": null }`.
+ "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.
   `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
@@ -127,10 +156,45 @@ och poängen sätts per post, så en katalog med flera specar går inte att bed
   eller `~/.claude`). En senare guard-körning jämför hash och vägrar diffa vid
   skevhet ("omklassning krävs, skalan har ändrats").
 - `status` blir ALDRIG `priced` när något stopputfall finns i varvets
-  körningar, eller när dubbelkörningen gav OLIKA (`double_run: "olika"`).
+  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`.
 - `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:
+
+```
+<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
+```
+
+- 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
+  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/`.
+
 ## Uppgift: `speca`
 
 1. **Underlag.** Rått önskemål inklistrat, eller ett gid — hämta då posten via
@@ -158,9 +222,10 @@ och poängen sätts per post, så en katalog med flera specar går inte att bed
    tomt) i varje berörd state.json.
    **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` och `approval` nollas — en ny spec är
-   ogranskad per definition, och en gammal analys mot ny spec är exakt den
-   skevhet proveniens-kontrollen finns för att stoppa.
+   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.
 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
@@ -217,7 +282,19 @@ oenighetsgrind.
 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 → dispatcha om just den agenten EN gång enligt omdispatch-regeln;
+   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
@@ -245,15 +322,124 @@ oenighetsgrind.
      `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 paren (körning 2 som `-run2`),
-     sätt `double_run: "olika"` och `superseded_by: null` på alla berörda
-     runs-rader, status `assessed`. Visa diffen (rad · körning 1 · körning 2)
+     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 så länge `double_run` står på `"olika"`. Välj ALDRIG
-     en av körningarna själv och räkna ALDRIG fram ett medelvärde.
-     **Återställningen är ett nytt varv:** efter granskarens beslut (justera
-     underlaget, eller konstatera att en körning hade rätt) körs `bedöm` om —
-     spärren sitter på varvets rader, ett nytt varv med LIKA låser upp.
+     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
      körningar) — visa felet och stanna, rapportera aldrig LIKA.
 7. **Oenighetsgrind klass ↔ poäng.** Deterministiska regler, i ordning:
@@ -264,16 +450,25 @@ oenighetsgrind.
      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,
-   och `N` i `-pricing-vN.json` är gemensamt (nästa N = högsta befintliga för
-   någon av filtyperna + 1; `-run2`- och `-avvisad`-filer räknas aldrig;
+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). JSON:en visas inte i chatten —
+   INPUT_SAKNAS, AVVIKELSE-rader, samt varje RÄTTAT-rad från citaträttningen
+   enligt steg 5). 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
@@ -336,9 +531,95 @@ 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
 `-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.
+
+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.
+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
+   `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
+   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.
+   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.
+
+### Batch: flera poster
+
+`utvärdera <post1> <post2> … [kandidatmodell]` kör varje ticket i en EGEN
+headless-process, sekventiellt:
+
+```
+claude -p "/request utvärdera <gid> <kandidatmodell>"
+```
+
+- **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
+  (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.
+
+### 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
+utelämnade. Bara läsning — inga agentdispatcher, inga Asana-anrop.
+
 ## Mekaniska kontroller: `scripts/`
 
-Sex deterministiska script (fyra kontroller + `lib.mjs` med de delade
+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 —
 billigare, snabbare och utan omdömesglidning. Varje script bär sha256 för de
@@ -361,9 +642,20 @@ referensfiler vars regler det speglar och VARNAR när en katalogbump ändrat dem
   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,
-  score, confidence, golv- och takankare. Aldrig prosa. Samma exit-semantik.
-  Båda compare-scripten kräver mode `pricing`; guard-jämförelser är en medveten
-  utbyggnad i guard-steget.
+  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).
 
 Kontrollerna bedömer aldrig innehåll och returnerar aldrig protokollutfall —
 en post som passerar kan fortfarande stoppas av protokollen själva, och det är

package/library/global/skills/request/scripts/compare-scores.mjs

@@ -6,9 +6,17 @@
  * prosa) och inringningens golv- och takankare. Prosa (why, drivers,
  * rationale) jämförs ALDRIG.
  *
- * Skriver LIKA (exit 0) eller OLIKA + diffrader (exit 1) på stdout; varningar
- * går på stderr. Vid OLIKA väljer dispatchern ALDRIG en körning och räknar
- * ALDRIG medelvärde — posten eskaleras till granskaren med båda inringningarna.
+ * Toleransregel: en poängskillnad ≤ 0,5 med samma outcome och confidence är
+ * prisbrus, inte oenighet. En ankarskillnad tolereras dessutom bara när banden
+ * överlappar eller angränsar; icke-angränsande band är hård diff även vid samma
+ * poäng. LIKA_TOLERANS hör till LIKA-familjen (exit 0) med
+ * en deterministisk vinnare (högsta poängen, skyddar marginalen). Den
+ * skriver aldrig om en fil och räknar aldrig fram ett medelvärde.
+ *
+ * Skriver LIKA, LIKA_TOLERANS (exit 0) eller OLIKA + diffrader (exit 1) på
+ * stdout; varningar går på stderr. Vid OLIKA väljer dispatchern ALDRIG en
+ * körning och räknar ALDRIG medelvärde — posten eskaleras till granskaren med
+ * båda inringningarna.
  *
  * Exit 2 = jämförelsen kan inte göras alls (dispatcherns fel, aldrig LIKA) —
  * rälsen bor i lib.mjs och delas med compare-classifications.
@@ -37,14 +45,56 @@ if (a.outcome !== b.outcome) diffs.push(`outcome: ${show(a.outcome)} ↔ ${show(
 // säkerhet är information granskaren ska se, precis som klassningens konfidenssida.
 if (a.confidence !== b.confidence)
   diffs.push(`confidence: ${show(a.confidence)} ↔ ${show(b.confidence)}`)
+// Toleransregel (beslut 2026-08-28, ADR-0078): en poängskillnad inom 0,5 med
+// samma outcome och confidence är prisbrus, inte oenighet. Båda pilotfallens
+// eskaleringar gällde Δ = 0,25 och kostade ett helt nytt varv styck. Högsta
+// poängen gäller (skyddar marginalen); ett medelvärde räknas fortfarande aldrig.
+const TOLERANS = 0.5
+
+/**
+ * Ankarnummer på skalan A1..A17. Golv null (under-A1-fallet) läses som 0, alltså
+ * steget under A1. Ett ankare som inte går att tolka ger null och behandlas som
+ * icke-angränsande, så en oläslig inringning aldrig kan tystas som brus.
+ */
+const ankarNr = (v) => {
+  if (v === null || v === undefined) return 0
+  const m = /^A(\d+)$/.exec(String(v))
+  return m ? Number(m[1]) : null
+}
+/**
+ * Inringningarna får toleransbehandling bara när de faktiskt pekar på samma del
+ * av skalan: överlappande eller angränsande band. Två körningar som landar på
+ * samma poäng men ringar in A5/A6 respektive A11/A12 är inte prisbrus, det är
+ * precis den drift dubbelkörningen finns för att visa, även när summan råkar bli
+ * densamma.
+ */
+const nastanSammaBand = (fa, ta, fb, tb) => {
+  const [l1, h1, l2, h2] = [ankarNr(fa), ankarNr(ta), ankarNr(fb), ankarNr(tb)]
+  if ([l1, h1, l2, h2].some((n) => n === null)) return false
+  return l1 <= h2 + 1 && l2 <= h1 + 1
+}
+
+const tolerans = []
 if (a.outcome === 'POANG' && b.outcome === 'POANG') {
-  if (a.score !== b.score) diffs.push(`score: ${show(a.score)} ↔ ${show(b.score)}`)
+  const delta = Math.abs(a.score - b.score)
+  const inomTolerans = Number.isFinite(delta) && delta <= TOLERANS
+  if (a.score !== b.score)
+    (inomTolerans ? tolerans : diffs).push(`score: ${show(a.score)} ↔ ${show(b.score)}`)
   const fa = a.bracket?.floor?.anchor ?? null
   const fb = b.bracket?.floor?.anchor ?? null
   const ta = a.bracket?.ceiling?.anchor ?? null
   const tb = b.bracket?.ceiling?.anchor ?? null
-  if (fa !== fb) diffs.push(`bracket.floor.anchor: ${show(fa)} ↔ ${show(fb)}`)
-  if (ta !== tb) diffs.push(`bracket.ceiling.anchor: ${show(ta)} ↔ ${show(tb)}`)
+  const ankarDiffs = []
+  if (fa !== fb) ankarDiffs.push(`bracket.floor.anchor: ${show(fa)} ↔ ${show(fb)}`)
+  if (ta !== tb) ankarDiffs.push(`bracket.ceiling.anchor: ${show(ta)} ↔ ${show(tb)}`)
+  ;(inomTolerans && nastanSammaBand(fa, ta, fb, tb) ? tolerans : diffs).push(...ankarDiffs)
 }
 
-reportDiffs(diffs)
+if (diffs.length === 0 && tolerans.length > 0) {
+  const winner = b.score > a.score ? 2 : 1
+  console.log(`LIKA_TOLERANS: högsta gäller ${Math.max(a.score, b.score)} (körning ${winner})`)
+  for (const t of tolerans) console.log(`- ${t}`)
+  process.exit(0)
+}
+// Hårda diffar visas tillsammans med toleransraderna: granskaren ska se helheten.
+reportDiffs([...diffs, ...tolerans])