@haus-tech/haus-workflow 4.3.0 → 4.4.0

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## [4.4.0](https://github.com/WeAreHausTech/haus-workflow/compare/v4.3.0...v4.4.0) (2026-08-24)
+
+### Features
+
+- **skills:** add request-score and let assess describe open outcome choices ([#347](https://github.com/WeAreHausTech/haus-workflow/issues/347)) ([09bd070](https://github.com/WeAreHausTech/haus-workflow/commit/09bd0709c5123fb9d82a0410fa995020beb384a6))
+
 ## [4.3.0](https://github.com/WeAreHausTech/haus-workflow/compare/v4.2.0...v4.3.0) (2026-08-24)
 
 ### Features

package/library/global/skills/request-assess-impact/SKILL.md

@@ -90,9 +90,29 @@ Analysen som ett dokument, en sida. Sedan ett kort block till granskaren:
 ## Till granskaren
 
 **Ej verifierat:** [vad du inte kunnat belägga i koden, och varför]
-**Avvikelse mot specen:** [om koden säger något annat än specen förutsätter · utfallsval specen lämnat obesvarade]
+**Avvikelse mot specen:** [om koden säger något annat än specen förutsätter]
+**Obesvarade utfallsval:** [ett stycke per val — se nedan]
 ```
 
+### Obesvarade utfallsval
+
+Ett utfallsval som specen lämnat öppet skrivs ut med tre saker, och alla tre behövs:
+
+1. **Vilka alternativen är.** Namnge dem, och var i koden vart och ett finns om de
+   bygger på något befintligt.
+2. **Om alternativen skiljer sig i vad som måste byggas.** Skriv rakt ut "båda mönstren
+   finns redan, samma arbete oavsett" eller "det ena kräver att X också ändras". Det är
+   en observation om koden, inte en bedömning av omfattning — du skriver aldrig att
+   något är stort, litet, enkelt eller dyrt.
+3. **Vilket alternativ analysen är skriven utifrån.** Du måste utgå från något för att
+   kunna beskriva systemet. Skriv "beskriven utifrån X", aldrig "vi väljer X" — valet
+   är inte ditt.
+
+Skälet till punkt 2: den som poängsätter posten har inte repot och kan inte se om
+alternativen kostar olika. Utan din rad måste den anta det värsta och stoppa posten,
+även när båda vägarna är samma arbete. Det är den vanligaste orsaken till att en post
+studsar tillbaka till specen i onödan.
+
 Sista raden är den viktigaste. Förutsätter specen något som inte stämmer i systemet är det ett fel som ska tillbaka till specen, inte något som ska klassas.
 
 ## Vad du aldrig gör

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

@@ -0,0 +1,239 @@
+---
+name: request-score
+description: Sätter poäng på en spec plus påverkansanalys genom att jämföra uppdraget mot en skala av sexton referensuppdrag. Använd alltid när användaren vill "sätt poäng", "poängsätt", "kör poängen", "vad landar det här på", "var på skalan ligger det", eller när en spec har en påverkansanalys och ska prissättas. Används även som grind på en fullständig implementationsplan före första kodraden — "kör guarden", "stämmer poängen fortfarande". Använd den även när poängsättning bara antyds, t.ex. när någon klistrar in en spec med underlag och frågar hur stort det är. Output är JSON med poäng och belägg, aldrig ett pris.
+---
+
+# request-score
+
+Du sätter poäng på en post genom att jämföra den mot referensuppdragen i
+`references/poangskala.md`. Läs skalan innan du poängsätter första posten i en session.
+
+**Går filen inte att läsa: poängsätt inte.** Säg att `references/poangskala.md` saknas
+och att skillen inte kan köras utan den. Sätt aldrig en poäng på minnet av hur skalan
+brukar se ut. Skalan ändras när nya referensuppdrag läggs till, och en poäng satt på
+en gammal skala ser likadan ut som en satt på rätt skala.
+
+**Du sätter aldrig pris.** Poäng blir pris genom en fast processavgift plus poängen
+gånger en konverteringsfaktor, och det räknas någon annanstans. Ligger prislistan i
+sammanhanget: använd den inte och säg till. Vet du vad poängen kostar drar du mot den
+poäng som känns rimlig att ta betalt för, och då mäter du inte längre uppdraget.
+
+**Du skriver aldrig underlaget.** Saknas spec eller påverkansanalys, avbryt med
+`INPUT_SAKNAS`. Skriv inte en påverkansanalys själv — då jämför du din egen text mot
+skalan, och belägget blir teater. `request-assess-impact` gör det, helst i en egen
+körning.
+
+**Ge inte dig själv repot i den här körningen.** Har du det börjar du verifiera saker
+vid sidan av underlaget, och då poängsätter du inte längre det du fått. Saknas något i
+underlaget är svaret låg konfidens, inte en egen efterforskning.
+
+## Stoppfrågorna först
+
+Poäng sätts bara på en post som går att bygga. Tre utfall stoppar poängsättningen:
+
+| Utfall | När | Vad som ska hända |
+| --- | --- | --- |
+| `KONCEPT` | Formen är okänd — designfråga, oavgjort vägval, flera lösningsvägar utan beslut | Egen post som levererar ett förslag och en poäng på bygget |
+| `DIAGNOS` | Orsaken är okänd och går att undersöka. Gäller framför allt fel där ingen vet varför något är trasigt | Tidsboxad undersökning som levererar besked och en poängsatt åtgärd |
+| `TILLBAKA_TILL_SPEC` | Specen lämnar ett utfallsval obesvarat **och valet ändrar arbetsmängden** | Specen kompletteras, sedan ny körning |
+
+### Obesvarade utfallsval: förutsättning eller stopp
+
+Påverkansanalysens granskarblock listar under _Obesvarade utfallsval_ de val specen
+lämnat öppna, var och en med alternativen, om de skiljer sig i vad som måste byggas,
+och vilket alternativ analysen är skriven utifrån. De ska inte behandlas lika. Ställ en
+fråga per val:
+
+**Ändrar valet hur mycket arbete posten kräver?** Analysens rad om huruvida
+alternativen skiljer sig i vad som måste byggas är svaret. Saknas den raden — analysen
+kan vara skriven före den här regeln — behandla valet som ett stopp och skriv i `notes`
+att analysen behöver kompletteras.
+
+**Nej** — då är det en **förutsättning**, inte ett stopp. Välj det rimligaste
+alternativet, skriv in det i `assumptions_stated` med vad som valts och varför, och
+poängsätt vidare. Förutsättningarna följer med förslaget till kund tillsammans med
+specen och priset, så kunden godkänner alla tre på en gång. Väljer kunden annorlunda
+är det en ändring som inte rör priset.
+
+Typexempel: vilket av två befintliga sätt att visa att något laddar som används, vilken
+av två likvärdiga formuleringar en text får, var i en befintlig vy ett fält placeras.
+
+**Ja** — då stoppar posten. Utfallsvalet avgör vad som ska byggas och därmed vad det
+kostar, och att gissa vore att prissätta något kunden inte beställt.
+
+Typexempel: om en funktion ska finnas på både mobil och dator eller bara en av dem, om
+befintlig data ska konverteras eller lämnas, om ett flöde ska ha ett steg till.
+
+Är du osäker på om valet ändrar arbetsmängden: behandla det som ett stopp och skriv
+ut varför. Ett onödigt stopp kostar några minuter, ett gissat utfallsval kostar en
+felprissatt post.
+
+Ett antagande som inte går att undersöka är inget stopp. Det blir ett villkor på posten:
+"bygger på att X; faller X tidigt avbryts posten utan debitering". Osäkerhet löses med
+kunskap eller villkor, aldrig med högre poäng för säkerhets skull.
+
+## Metoden: ringa in, aldrig skatta fritt
+
+En siffra som kommer direkt ur en helhetsbedömning går inte att granska och blir olika
+mellan två körningar. Ringa in i stället, i fyra steg. Alla fyra redovisas i utfallet.
+
+**Steg 1 — hitta ett golv.** Läs skalan och hitta ett referensuppdrag som posten
+**säkert är större än**. Skriv ut vilket och varför.
+
+**Steg 2 — hitta ett tak.** Hitta ett referensuppdrag som posten **säkert är mindre
+än**. Skriv ut vilket och varför.
+
+Får du inget golv: posten är mindre än A1 och får A1:s poäng. Skalans nedre ände är
+ändå dominerad av den fasta processavgiften.
+
+Får du inget tak: posten är större än skalans högsta referensuppdrag. Sätt utfallet
+till `OVER_SKALAN` och sätt ingen poäng — underlaget för den nivån är för tunt för att
+jämföra mot, och posten ska offereras separat.
+
+**Steg 3 — snäva in.** Gå igenom referensuppdragen mellan golv och tak. För varje: är
+posten större eller mindre, och på vilken grund? Fortsätt tills du har två
+angränsande referensuppdrag som posten ligger mellan.
+
+**Steg 4 — placera.** Sätt poängen mellan de två. Ligger posten närmare det ena, säg
+vilket och varför. Landar den på samma nivå som ett referensuppdrag, ge den det
+ankarets poäng rakt av.
+
+**Avrunda till skalans upplösning.** Under 3 poäng till närmaste 0,25, alltså 0,25,
+0,5, 0,75, 1, 1,25 och så vidare. Från 3 poäng och uppåt till närmaste hela poäng. En
+finare siffra än så låtsas om en noggrannhet som inte finns: två oberoende bedömare
+hamnar i olika klass i en femtedel av fallen. Avrundningen är mekanisk och sker efter
+placeringen, aldrig genom att du väljer ett rundare tal medan du jämför.
+
+## Vad du jämför på
+
+Jämför på vad ändringen **drar med sig**, inte på hur mycket kod som skrivs. Det som
+skiljer referensuppdragen åt, i fallande ordning efter hur mycket de väger:
+
+**Om en människa måste verifiera för hand, och i hur många fall.** Det är den tydligaste
+skillnaden genom hela skalan. Ett uppdrag som täcks av automatiska tester ligger lågt.
+Ett som kräver genomgång i flera scenarier, på flera enheter eller i flera miljöer
+ligger högt.
+
+**Förutsätt alltid att automatiska tester finns**, även när påverkansanalysen säger att
+repot saknar testsvit. Räkna bara det manuella arbete som återstår när en fungerande
+testsvit gjort sitt: det som kräver en människa av sin natur, alltså kontroll mot en
+extern tjänsts testläge, visuell granskning, eller genomgång på flera enheter eller i
+flera miljöer. Att ett repo saknar tester är Haus egen tekniska skuld, och den ska
+kunden inte betala för. Skriv i så fall en rad om det under `notes`, så att skulden
+syns i stället för att bakas in i priset.
+
+**Vad som händer om det blir fel.** Felaktig betalning, felaktig åtkomst till någon
+annans uppgifter, förlorad data eller bruten befintlig funktion väger tungt. Fel text
+eller fel sorteringsordning väger lätt.
+
+**Om ändringen rör kod som flera kunder använder.** Då tillkommer migrering per
+installation och en risk som når utanför beställaren. Se A9 och A10.
+
+**Om ett externt system berörs**, och om kopplingen är ny eller befintlig.
+
+**Om en sekvens som användaren passerar i ordning ändras**, och hur många steg.
+
+**Om något ska formges som inte finns i systemet i dag.**
+
+Antal filer och antal rader är **inte** jämförelsegrunder. Se noten sist i skalan: två
+referensuppdrag med samma poäng skiljer sig med en tiopotens i filantal.
+
+## Typen
+
+Använd typen för att hitta jämförbara referensuppdrag snabbare, ingenting annat. Ett
+uppdrag av en typ som saknas i skalan poängsätts mot de närmaste i storlek, inte mot
+någon påhittad justering. Skriv ut vilken typ du bedömt posten som — den loggas för att
+kunna mäta i efterhand om någon typ hamnar systematiskt fel.
+
+## Grindläget
+
+Körs skillen på en fullständig implementationsplan efter kundens godkännande, sätt
+`mode` till `guard`. Samma skala, samma metod.
+
+Endast ny strukturell information ur fullplanen får flytta poängen, aldrig en
+omvärdering av samma fakta. Rapportera vilket jämförelsesteg som ändrades och citatet ur
+fullplanen som orsakade det. Grinden är symmetrisk — en lägre poäng rapporteras lika
+tydligt som en högre.
+
+Bygger fullplanen ett annat vägval än det som såldes är det en händelse att rapportera
+även när poängen blir densamma.
+
+## Output
+
+```json
+{
+  "request_id": "",
+  "mode": "pricing | guard",
+  "outcome": "POANG | KONCEPT | DIAGNOS | TILLBAKA_TILL_SPEC | OVER_SKALAN | INPUT_SAKNAS",
+  "score": null,
+  "type": "",
+  "bracket": {
+    "floor": { "anchor": "", "score": null, "why": "" },
+    "ceiling": { "anchor": "", "score": null, "why": "" },
+    "between": ["", ""],
+    "steps": []
+  },
+  "drivers": [],
+  "confidence": "hog | medel | lag",
+  "conditions": [],
+  "assumptions_stated": [],
+  "dependencies": [],
+  "notes": [],
+  "customer_rationale": "",
+  "guard_diff": []
+}
+```
+
+`score` sätts bara när `outcome` är `POANG`, och alltid på skalans upplösning: steg om
+0,25 under 3 poäng, hela poäng från 3 och uppåt.
+
+`bracket.steps` är jämförelserna från steg 3, en per referensuppdrag du vägde mot, var
+och en med ankarets id, om posten är större eller mindre, och på vilken grund. Det är
+det som gör poängen granskbar. En poäng utan inringning är inte ett giltigt utfall.
+
+`drivers` är de två eller tre faktorer som mest avgjorde placeringen, med citat ur
+påverkansanalysen. Citat, inte parafras.
+
+`assumptions_stated` är de utfallsval specen lämnat öppna som **inte** ändrar
+arbetsmängden: vad du valt, och varför. De går med förslaget till kund som
+förutsättningar och godkänns tillsammans med specen och priset.
+
+`notes` är iakttagelser som inte hör till poängen men som någon bör känna till, till
+exempel att ett repo saknar testsvit.
+
+`confidence` sätts till `lag` när posten inte liknar något referensuppdrag, när golv och
+tak ligger långt isär och inget referensuppdrag finns emellan, eller när
+påverkansanalysen anger att något inte kunnat verifieras och det påverkar placeringen.
+Låg konfidens är ett giltigt utfall och ska inte döljas genom att välja en poäng som
+ser rimlig ut.
+
+### Motiveringen till kund
+
+`customer_rationale` skrivs i kundens språk och beskriver arbetet som ska göras, inte
+hur skalan räknade. Nämn aldrig poäng, referensuppdrag, ankare eller skalan. Kunden ska
+kunna invända mot omfattningen, inte mot modellen.
+
+Den ska vara förenlig med specens _Ingår inte_. Motiverar du poängen med arbete som
+specen uttryckligen undantar har du poängsatt fel post.
+
+## Efter körning
+
+Granskaren läser inringningen, inte slutpoängen. En rimlig poäng med fel jämförelser är
+en felkalibrering som råkade landa rätt, och den kommer tillbaka i en post där den inte
+gör det.
+
+Korrigeringar går till skalan, alltså till referensuppdragen eller till den här
+instruktionen, och till kalibreringsloggen. Aldrig till priset på den enskilda posten.
+
+Visar det sig återkommande att poster av ett visst slag är svåra att placera, är det ett
+tecken på att skalan har ett hål och behöver ett referensuppdrag till. Rapportera det.
+
+## Acceptanstestet — granskarens sak, inte din
+
+Skillen verifieras genom att köras mot poster med känt utfall. Det underlaget ligger med
+flit **inte** i den här mappen — en körning som kan läsa facit kan inte längre testas. Du
+ska varken leta efter det eller rapportera det som saknat.
+
+För granskaren gäller två mått: att två oberoende körningar av samma post ger samma
+poäng, och att inringningen håller vid granskning. Det första är det som avgör om
+kunderna får samma pris för samma arbete.