@haus-tech/haus-workflow 4.5.0 → 4.7.0

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

@@ -0,0 +1,446 @@
+---
+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.
+---
+
+# /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
+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                                              |
+| `hjälp`                                | Förklara uppgifterna, rör inga filer                                                     |
+
+## Hårda regler
+
+- **request-sync körs ALDRIG i en subagent.** Uppsättning och brädverifiering är
+  interaktiva, fältkartan är sessionsstate, och en enda skrivare mot Asana
+  eliminerar races. All Asana-läsning/skrivning sker i huvudkonversationen via
+  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,
+  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,
+  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
+  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.
+- **Godkännande antas aldrig.** Att en spec finns i arkivet betyder inte att den
+  är granskad. Se grinden under `bedöm`.
+
+## Arkivet: `.haus/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.
+
+```
+<repo-rot>/.haus/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
+└── state.json
+```
+
+- 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.
+
+### `state.json`
+
+```json
+{
+  "request_id": "<gid eller null>",
+  "slug": "<kebab-rubrik>",
+  "former_slug": null,
+  "title": "<spec-rubrik>",
+  "status": "spec_draft | spec_synced | assessed | priced | guard_run",
+  "bundle": { "parent_slug": null, "part": null, "of": null },
+  "split": { "parent": null, "part": null, "of": null },
+  "approval": null,
+  "note": null,
+  "runs": []
+}
+```
+
+- `bundle` = specar ur samma önskemål (sätts av speca vid bunt).
+  `split` = delposter ur ett DELA_UPP-utfall (sätts av bedöm). Båda formen
+  `{parent…, part: N, of: M}`.
+- `approval` skrivs av grinden i bedöm:
+  `{ "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.
+- `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 }`.
+  `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
+  bytts ut — utan detta är ett respec-varv mot gammal analys osynligt.
+  Referens-hashen bor i run-raden (inte på toppnivå) och räknas vid körning med
+  `node <skillkatalog>/scripts/ref-hash.mjs <referensfil>` — ALDRIG rå
+  `shasum` på hela filen: installern stämplar filerna med paketversionen, så en
+  hel-fils-hash byter värde vid varje haus-release och skulle ogiltigförklara
+  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").
+- `status` blir ALDRIG `priced` när något stopputfall finns i varvets
+  körningar, eller när dubbelkörningen gav OLIKA (`double_run: "olika"`).
+- `spec_synced` sätts av speca steg 7 (posten lagd på brädan);
+  `guard_run` reserveras för guard-kommandot (senare byggsteg).
+
+## Uppgift: `speca`
+
+1. **Underlag.** Rått önskemål inklistrat, eller ett gid — hämta då posten via
+   request-sync (huvudkonversationen) och använd `## Ursprunglig förfrågan`
+   ordagrant.
+2. **Källmanifest.** Isolerade subagenter kan inte "leta innan de antar" utan
+   hjälp. Bygg ett manifest innan dispatch: relevanta grep-träffar i repot
+   (vyer/termer önskemålet nämner), tidigare specar för samma kund (arkivet +
+   brädan), ev. brief. **Alla sökvägar i manifestet absoluta.** Finns inget repo
+   i sessionen: skriv `KÄLLOR: inga — allt blir antaganden` så specifiern vet.
+3. **Eskaleringsbedömning.** Misstänkt bunt (flera beslut), behörighet/betalning/
+   oåterkallelig data/personuppgifter, eller offertunderlag → utfallet är
+   prisbärande och eskaleringen är ett MODELLBYTE, inte en flagga: dispatcha
+   `request-specifier-eskalerad` (frontier-modell) i stället för
+   `request-specifier`, med `ESKALERAD: ja` plus orsaken i prompten.
+4. **Dispatcha `request-specifier`** (eller den eskalerade varianten enligt
+   steg 3) enligt promptmallen i dispatch-kontraktet.
+5. **Arkivera.** Dela svaret vid `## Till granskaren`. En spec → en katalog:
+   allt före blocket är specarna; VARJE spec får sin egen katalog med egen
+   `spec.md` och eget `state.json` (bunt: `bundle`-fältet ifyllt, blocket
+   kopieras till varje katalog som `granskarblock.md`). Bunt ur en gid-post:
+   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.
+   **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.
+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
+   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
+   i sin helhet. Erbjud att lägga specarna på brädan via request-sync (🔍) — gör
+   det bara på uttrycklig begäran. När en post läggs på brädan: sätt status
+   `spec_synced`, döp om slug-katalogen till det myntade gid:t, notera sluggen
+   i `former_slug` och uppdatera `request_id` i `state.json`.
+
+## Uppgift: `bedöm`
+
+Kör prissättningsbenet: påverkansanalys om den saknas, sedan klass ∥ poäng med
+oenighetsgrind.
+
+1. **Grind — obligatorisk, aldrig överhoppbar.** Bedömning kräver en granskad
+   spec, och godkännandet bor i Asana:
+   - **Posten har gid:** läs Offer status via request-sync (huvudkonversationen)
+     omedelbart före körningen — aldrig från minnet eller en tidigare listning.
+     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
+     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.
+   - **Posten saknar gid OCH repot saknar brädkoppling:** fråga uttryckligen
+     "Är specen godkänd av en människa — och av vem?" via AskUserQuestion och
+     kör bara på ja med namn. Anta aldrig, och låt aldrig "specen ser klar ut"
+     eller ett tidigare samtal ersätta frågan.
+   - **Posten har gid men saknar lokal arkivkatalog:** stöds inte ännu
+     (hydrering från brädan kommer med batch-steget) — säg det och stanna;
+     granskarblocket går inte att återskapa ur Asana.
+   - Anteckna passerad grind i `state.json.approval` (manual-fallet med `by`).
+     Nästa `bedöm` läser om statusen igen.
+2. **Formkontroll.** Kör `node <skillkatalog>/scripts/precheck.mjs <katalog> --impact`
+   (utan `--impact` om analysen ännu inte finns). En `spec.md` med mer än ett
+   specblock är en BRIST — dela posten enligt arkivregeln innan något dispatchas.
+   Övriga BRISTER → åtgärda ledet som brister (om spec: tillbaka till
+   speca-steget) innan något dyrt dispatchas.
+3. **Analys.** Saknas `impact.md`, eller fäller precheck den på
+   underlagsproveniens (analysen gjordes mot en annan spec): kräver repo i
+   sessionen (annars stopp — en gissad analys är förbjuden av skillen själv).
+   Dispatcha `request-assessor` enligt promptmallen — specens granskarblock
+   skickas med som internt underlag (samma förtroendedomän; flaggorna där är
+   ofta analysens viktigaste ingång). Arkivera svaret som `impact.md`
+   (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 → 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
+   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).
+   - 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
+     `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)
+     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.
+   - 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:
+   - 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,
+   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;
+   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 —
+   `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:**
+
+- `DELA_UPP` → föreslå ny analysrunda per del; delarna blir egna kataloger med
+  `split` satt (`part`/`of`), och en del utan tak blir `OVER_SKALAN`, aldrig
+  DELA_UPP igen. Delposter ärver enligt skillen postens spec och skriver aldrig
+  en egen: förälderns `spec.md` och `granskarblock.md` KOPIERAS in i varje
+  delkatalog (som buntens granskarblock), medan `impact.md` skrivs per del av
+  den nya analysrundan.
+- `OVER_SKALAN` → posten offereras separat; delas aldrig vidare (delningen görs
+  ett steg, skillens egen regel).
+- `TILLBAKA_TILL_SPEC` / `KONCEPT` / `DIAGNOS` → tillbaka till spec-steget
+  respektive kunddialog; visa skälet.
+- `ESKALERA` / `INPUT_SAKNAS` → visa skälet och stanna.
+
+## Uppgift: `status`
+
+Kör request-sync:s kö-läsning i huvudkonversationen för lägena
+📥 Inkommet, 🔍 Spec redo för granskning, ✅ Spec ok och ⚖️ Poängsättning redo
+för granskning. Svara som BLUF-tabell med **radnummer**: `nr · post · Offer
+status`. Spara nr → gid-mappningen i sessionen (gid behöver inte visas i
+tabellen) — numren är vad `godkänn`/`underkänn`/`bedöm`/`detaljer` refererar
+till, och varje verb slår upp och agerar på **gid**, aldrig på numret självt.
+Ingen JSON i chatten.
+
+## Uppgifter: `godkänn` / `underkänn`
+
+Genvägar till samma spak som i Asana — **Offer status på brädan förblir enda
+beslutet**. Verben gör beslutet snabbare att verkställa, aldrig lättare att
+missta:
+
+- **Adressering:** radnummer ur senaste `status`-listningen i samma session
+  (slås upp till gid via den sparade mappningen), eller ett gid direkt. ALDRIG
+  fuzzy rubrikmatchning — fel post godkänd är värre än ett stopp. Finns ingen
+  färsk listning och inget gid: kör `status` först.
+- **En post per verb-anrop.** "Godkänn 2 och 4" är två anrop i följd, vart och
+  ett läser och flyttar sin post. Aldrig batch-godkännande på "allt ser bra ut".
+- **Lägesgrind för båda verben:** läs postens nuvarande Offer status via
+  request-sync först. Verben verkar bara från gransknings-lägena
+  (🔍 Spec redo för granskning, ⚖️ Poängsättning redo för granskning). Står
+  posten någon annanstans: visa status och stanna i stället för att gissa.
+- **`godkänn <nr|gid>`:** 🔍 → ✅ Spec ok, respektive ⚖️ → 📤 Klar – till kund.
+- **`underkänn <nr|gid> <skäl>`:** skäl är obligatoriskt — utan skäl, fråga
+  efter det. request-sync lägger skälet som kommentar på posten, bumpar
+  iterationsräknaren och flyttar status bakåt enligt sina bakåtflyttsregler.
+- **Post utan bräda** (bara arkiv): `godkänn` antecknar
+  `approval: {source: "manual", date}` i `state.json` efter en uttrycklig
+  bekräftelsefråga. Säg tydligt att detta inte syns för någon annan än arkivet.
+- Verben rör Offer status och kommentarer — aldrig Score, Class eller
+  beskrivningsfält.
+
+## 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
+`-pricing-vN.json` utan suffix (aldrig `-run2`/`-avvisad`).
+
+## Mekaniska kontroller: `scripts/`
+
+Sex deterministiska script (fyra 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
+referensfiler vars regler det speglar och VARNAR när en katalogbump ändrat dem
+(kontraktsdrift ska upptäckas av en check, inte av en kund):
+
+- `scripts/precheck.mjs <arkivkatalog> [--impact]` — formkontroll FÖRE dyra
+  dispatcher: rubriker, exakt ett specblock, 2–5 punkter, förbjuden vokabulär,
+  granskarblocksrader, state.json-fält. Skiljer på BRISTER (exit 1, stoppar)
+  och VARNING (heuristik — visas, stoppar inte).
+- `scripts/contract-check.mjs <run.json> <spec.md> [impact.md] [--expect-id <id>]`
+  — kontraktskontroll av classify/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,
+  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.
+
+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)
+
+- Prompten är självbärande: agenten ser inte den här konversationen.
+- **Promptmallar, etiketterna ordagrant:**
+
+  `request-specifier`:
+
+  ```
+  ÖNSKEMÅL:
+  <rått önskemål, ordagrant>
+
+  KÄLLOR:
+  <manifest med absoluta sökvägar, eller "inga — allt blir antaganden">
+
+  REPO-ROT: <absolut sökväg eller "saknas">
+  ESKALERAD: <ja|nej>
+  ```
+
+  `request-assessor`:
+
+  ```
+  REPO-ROT: <absolut sökväg>
+
+  SPEC (godkänd):
+  <spec.md bytetroget>
+
+  GRANSKARBLOCK (internt underlag, följer aldrig med i analysens kundtext):
+  <granskarblock.md bytetroget>
+  ```
+
+  `request-classifier` / `request-scorer`:
+
+  ```
+  REQUEST_ID: <gid eller slug>
+  MODE: <pricing|guard>
+  DELPOST: <nej | ja, del N av M>
+
+  SPEC:
+  <spec.md bytetroget>
+
+  PÅVERKANSANALYS:
+  <impact.md bytetroget>
+  ```
+
+  (guard-läge lägger till `FULLPLAN:` och `TIDIGARE_KLASSNING:` /
+  `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
+  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.
+- 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
+  oförändrad, följd av ett block:
+  ```
+  RÄTTNINGAR:
+  <felraderna från kontrollen, citerade ordagrant>
+  ```
+  En ny subagent minns inget — enbart felrader utan underlag är obrukbart.
+
+## Använd inte när
+
+- Användaren vill köra en enskild skill fristående ("skriv bara en spec") —
+  invokera den skillen direkt.
+- 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
+  senare steg.

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

@@ -0,0 +1,94 @@
+/**
+ * Deterministisk dubbelkörningsdiff för klassningar (driftvakten på MEDIUM+).
+ * Jämför utfall, basklass, varje frågas svar och vilken sida om KONFIDENSGRÄNS
+ * (0.8) konfidensen ligger, mellan två oberoende körningar på samma underlag.
+ * Prosafält (belägg, motiveringar) jämförs INTE — två korrekta körningar
+ * formulerar sig olika, det är svaren som ska vara stabila. Konfidensens SIDA
+ * om gränsen är däremot inte prosa: den avgör ESKALERA enligt protokollet.
+ *
+ * Skriver LIKA (exit 0) eller OLIKA + diffrader (exit 1) på stdout; varningar
+ * går på stderr så en verdiktparser aldrig sväljer dem. Vid OLIKA väljer
+ * dispatchern ALDRIG en körning och räknar ALDRIG medelvärde — posten
+ * eskaleras till granskaren med båda körningarna.
+ *
+ * Exit 2 = jämförelsen kan inte göras alls (dispatcherns fel, aldrig LIKA) —
+ * rälsen bor i lib.mjs och delas med compare-scores.
+ *
+ * Användning: node compare-classifications.mjs <körning1.json> <körning2.json>
+ */
+import { loadRunPair, refDriftWarning, reportDiffs } from './lib.mjs'
+
+// KONFIDENSGRANS speglar klassningsinstruktionen — varna (stderr) vid katalogdrift.
+const REF_SHA = '811f0bff62c749255e86da7ea8db0ea868ebc9df14262f9889101c110d9d14ff'
+{
+  const w = refDriftWarning('request-classify/references/klassningsinstruktion.md', REF_SHA)
+  if (w) console.error(`VARNING: ${w} — kontrollera KONFIDENSGRANS`)
+}
+const KONFIDENSGRANS = 0.8
+
+const { a: docA, b: docB } = loadRunPair(
+  'användning: node compare-classifications.mjs <körning1.json> <körning2.json>',
+)
+const a = docA.classification
+const b = docB.classification
+if (!a || !b) {
+  console.error('minst en fil saknar classification-nyckeln — är båda classify-körningar?')
+  process.exit(2)
+}
+
+// Frågelagret är jämförelsens kärna — utan kompletta, unikt id-satta rader kan
+// en äkta oenighet tyst försvinna. Då vägrar vi hellre än gissar.
+const validateFragor = (rows, label) => {
+  if (!Array.isArray(rows) || rows.length === 0) {
+    console.error(`${label}: fragor saknas eller är tom — kan inte jämföra`)
+    process.exit(2)
+  }
+  const seen = new Set()
+  for (const f of rows) {
+    if (typeof f?.id !== 'string' || f.id.trim() === '') {
+      console.error(`${label}: en frågerad saknar id — kan inte jämföra`)
+      process.exit(2)
+    }
+    if (seen.has(f.id)) {
+      console.error(`${label}: dubblett-id "${f.id}" — kan inte jämföra`)
+      process.exit(2)
+    }
+    seen.add(f.id)
+  }
+}
+validateFragor(a.fragor, 'körning 1')
+validateFragor(b.fragor, 'körning 2')
+
+const show = (v) => JSON.stringify(v ?? null)
+const normSvar = (v) =>
+  String(v ?? '')
+    .trim()
+    .toUpperCase()
+
+const diffs = []
+if (a.utfall !== b.utfall) diffs.push(`utfall: ${show(a.utfall)} ↔ ${show(b.utfall)}`)
+if ((a.basklass ?? null) !== (b.basklass ?? null))
+  diffs.push(`basklass: ${show(a.basklass)} ↔ ${show(b.basklass)}`)
+
+const byId = (rows) => new Map(rows.map((f) => [f.id, f]))
+const mapA = byId(a.fragor)
+const mapB = byId(b.fragor)
+for (const id of new Set([...mapA.keys(), ...mapB.keys()])) {
+  const fa = mapA.get(id)
+  const fb = mapB.get(id)
+  if (!fa || !fb) {
+    // Körningarna stannade på olika steg — samma fakta gav olika väg.
+    diffs.push(`fråga ${id}: besvarad i ${fa ? 'körning 1' : 'körning 2'} men inte i den andra`)
+    continue
+  }
+  if (normSvar(fa.svar) !== normSvar(fb.svar))
+    diffs.push(`fråga ${id}: ${show(fa.svar)} ↔ ${show(fb.svar)}`)
+  const sideA = (fa.konfidens ?? 0) >= KONFIDENSGRANS
+  const sideB = (fb.konfidens ?? 0) >= KONFIDENSGRANS
+  if (sideA !== sideB)
+    diffs.push(
+      `fråga ${id}: konfidens på olika sida om ${KONFIDENSGRANS} (${show(fa.konfidens)} ↔ ${show(fb.konfidens)})`,
+    )
+}
+
+reportDiffs(diffs)

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

@@ -0,0 +1,50 @@
+/**
+ * Deterministisk dubbelkörningsdiff för poängsättningar (driftvakten på
+ * MEDIUM+). Poängen har större driftyta än klassens enum och multipliceras
+ * direkt till pris — request-score:s eget acceptanstest är att två oberoende
+ * körningar ger samma poäng. Jämförs: outcome, score, confidence (enum, inte
+ * 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.
+ *
+ * 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.
+ *
+ * Användning: node compare-scores.mjs <körning1.json> <körning2.json>
+ */
+import { loadRunPair, refDriftWarning, reportDiffs } from './lib.mjs'
+
+// Jämförelsefälten speglar poängskalans kontrakt — varna (stderr) vid katalogdrift.
+const REF_SHA = 'cb5a6c221b5d39c445ca31a427fd3f96c648388ac5441c22ea2ea5f72e1f8e31'
+{
+  const w = refDriftWarning('request-score/references/poangskala.md', REF_SHA)
+  if (w) console.error(`VARNING: ${w}`)
+}
+
+const { a, b } = loadRunPair('användning: node compare-scores.mjs <körning1.json> <körning2.json>')
+if (a.outcome === undefined || b.outcome === undefined) {
+  console.error('minst en fil saknar outcome-nyckeln — är båda score-körningar?')
+  process.exit(2)
+}
+
+const show = (v) => JSON.stringify(v ?? null)
+const diffs = []
+if (a.outcome !== b.outcome) diffs.push(`outcome: ${show(a.outcome)} ↔ ${show(b.outcome)}`)
+// confidence är ett enum (hog/medel/lag), inte prosa — samma poäng med olika
+// 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)}`)
+if (a.outcome === 'POANG' && b.outcome === 'POANG') {
+  if (a.score !== b.score) 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)}`)
+}
+
+reportDiffs(diffs)