@haus-tech/haus-workflow 5.0.1 → 5.2.0

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

@@ -87,7 +87,7 @@ Testfrågan: **skulle användaren märka skillnad mellan alternativen?**
 
 **Nej** — delad komponent eller speciallösning, vilket mönster som återanvänds, var koden hamnar, hur något lagras när beteendet blir detsamma. Det här är ditt beslut. Välj det som är bäst för systemet på sikt och redovisa varför.
 
-**Ja** — funktionen beter sig olika, något ingår eller inte, användaren ser eller får olika saker. Då är det inte ditt val. Det är en fråga specen skulle ha besvarat, och den ska tillbaka dit. Skriv ut den i granskarblocket under _Avvikelse mot specen_, och beskriv vad som är obesvarat — välj inte "det troliga" och gå vidare.
+**Ja** — funktionen beter sig olika, något ingår eller inte, användaren ser eller får olika saker. Då är det inte ditt val. Det är en fråga specen skulle ha besvarat, och den ska tillbaka dit. Skriv ut valet i granskarblocket under _Obesvarade utfallsval_ med alternativen. Etiketten på _Avvikelse mot specen_ blir `precisering` så länge minst ett listat alternativ levererar specens Problem; `motsägelse` bara när inget gör det.
 
 Design, utseende, flöde och UX hör alltid till den andra kategorin.
 
@@ -114,10 +114,49 @@ 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]
-**Obesvarade utfallsval:** [ett stycke per val — se nedan]
+**Avvikelse mot specen:** <ingen | precisering | motsägelse>. [fritext: vad koden säger och vad specen förutsätter]
+**Obesvarade utfallsval:** [inga, eller en listpunkt per val ("- "), se nedan]
 ```
 
+### Avvikelse mot specen
+
+Raden börjar ALLTID med en av tre etiketter, som första ord efter kolonet.
+Formkontrollen läser etiketten, och poängsättaren agerar på den. En rad med
+bara fritext ("bör tillbaka till specen") är osynlig för båda: det var så två
+motsägelser i samma ärende prissattes i stället för att stoppas.
+
+- `ingen`: koden stämmer med det specen förutsätter.
+- `precisering`: specen lämnar något öppet som koden fyller i utan att specen
+  blir fel, till exempel exakt var ett fält hamnar i en befintlig vy. Skriv
+  vad du preciserat; det blir en förutsättning i förslaget, aldrig ett stopp.
+- `motsägelse`: specen förutsätter något som inte stämmer i systemet, eller en
+  punkt går inte att leverera som den står. Posten går tillbaka till specen
+  utan poäng. Skriv vad som inte stämmer och var i koden det syns. Etiketten
+  får bara sättas när _Obesvarade utfallsval_ är `inga` eller när varje listat
+  alternativ är struket (se nedan). Listar du ett alternativ som löser
+  problemet är etiketten `precisering`, och poängsättarens fyrstegsregel
+  avgör. Formkontrollen fäller `motsägelse` med ostrukna alternativ.
+
+Efter etiketten följer fritexten som förut. Flera avvikelser: etiketten är den
+allvarligaste av dem (motsägelse väger över precisering), och varje avvikelse
+får en egen mening.
+
+### Kundens språk
+
+Prompten bär `SPRÅK: svenska | engelska`, kundens språk. Analysen är
+Haus-intern, men delar av den går vidare till kunden genom poängsättaren: det
+preciserade på avvikelseraden blir en förutsättning i förslaget, och
+alternativen under _Obesvarade utfallsval_ blir kundens alternativ. Namnge
+dem i kundens språk ur promptens `SPRÅK:`-rad; i en fristående körning utan
+raden är det specens språk.
+
+### Beroenden i arbetskopian
+
+Prompten bär `DEPS: installerade | saknas`. Vid `saknas` finns inga
+installerade paket i arbetskopian: verifiera aldrig genom att installera
+något, och redovisa det du inte kunnat belägga i paketen (exporter, versioner,
+API-ytor) under _Ej verifierat_ med orsaken "beroenden ej installerade".
+
 ### Obesvarade utfallsval
 
 Ett utfallsval som specen lämnat öppet skrivs ut med tre saker, och alla tre behövs:
@@ -132,12 +171,27 @@ Ett utfallsval som specen lämnat öppet skrivs ut med tre saker, och alla tre b
    kunna beskriva systemet. Skriv "beskriven utifrån X", aldrig "vi väljer X" — valet
    är inte ditt.
 
+Varje val är en egen listpunkt på översta nivån som börjar med "- ", och de tre
+delarna ovan (alternativen, om de skiljer sig i vad som måste byggas, vilket
+alternativet analysen är skriven utifrån) skrivs på indenterade underrader
+under den punkten, inte som egna listpunkter. Formkontrollen räknar bara
+listpunkter på kolumn 0; en underrad räknas inte som ett eget alternativ.
+Alternativ i löptext ("(a) text i bilden, (b) egen komponent") räknas inte
+alls: formkontrollen fäller `motsägelse` med sådan prosa i avsnittet som en
+brist och varnar vid `precisering`, så skriv listan eller skriv `inga`, aldrig
+en uppräkning i en mening.
+
+**Struket alternativ.** Ett alternativ som inte löser specens _Problem_ raderas inte,
+det stryks: den översta listpunkten (samma nivå som alternativets "- ") börjar med
+`struket:` (engelska: `struck:`) följt av skälet, prefixet flyttas aldrig ner till en
+underrad. Så syns det att alternativet prövats.
+
 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 poängsättas.
+Avvikelseraden ä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 poängsättas, och etiketten `motsägelse` är det som gör att det faktiskt händer.
 
 ## Vad du aldrig gör
 

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

@@ -35,7 +35,7 @@ Poäng sätts bara på en post som går att bygga. Fem utfall stoppar poängsät
 | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
 | `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                                 |
+| `TILLBAKA_TILL_SPEC` | Påverkansanalysen anger `motsägelse` under _Avvikelse mot specen_ (specen förutsätter något som inte stämmer), eller inget alternativ löser problemet (steg 2 nedan)                    | Specen kompletteras, sedan ny körning                                 |
 | `DELA_UPP`           | Posten går inte att ringa in på egen hand — se nedan                                                                                                                                    | Ny analysrunda som pekar ut delarna, sedan en körning per del         |
 | `ESKALERA`           | Bedömningen kräver en människa: ett prisbärande avgörande som inte får vila på en gissning, och som varken är en delningsfråga (`DELA_UPP`) eller ett hål i underlaget (`INPUT_SAKNAS`) | Posten visas för en människa; skriv i `notes` vilken fråga och varför |
 
@@ -62,6 +62,26 @@ den `OVER_SKALAN` och offereras — den delas inte vidare.
 **En post som redan har poängsatta delar poängsätts aldrig som helhet.** Föräldern bär
 summan av sina delar, inte en egen siffra.
 
+### Motsägelse först
+
+Påverkansanalysens granskarblock börjar raden _Avvikelse mot specen_ med en
+etikett: `ingen`, `precisering` eller `motsägelse`. Läs den innan något annat.
+
+`motsägelse` betyder att specen förutsätter något som inte stämmer i systemet,
+eller att en punkt inte går att leverera som den står. Etiketten är satt bara
+när analysen inte listar något ostruket alternativ (ADR-0117); formkontrollen
+har redan fällt en analys som bär `motsägelse` tillsammans med alternativ, så
+du möter aldrig det fallet. Då är utfallet
+`TILLBAKA_TILL_SPEC`, utan undantag och före fyrstegsregeln nedan: en poäng på
+en spec som motsäger koden prissätter något som inte går att bygga. Skriv i
+`customer_rationale`, i kundens språk, vad som behöver avgöras. Kontrakts-
+kontrollen fäller varje annat utfall när analysen bär `motsägelse`, och
+orkestratorn dispatchar dig normalt inte alls i det läget.
+
+`precisering` är ingen avvikelse att stoppa på: analysen har fyllt i något
+specen lämnade öppet utan att specen blev fel. Det preciserade går in i
+`assumptions_stated` som en förutsättning. `ingen` kräver inget.
+
 ### Obesvarade utfallsval
 
 Påverkansanalysens granskarblock listar under _Obesvarade utfallsval_ de val specen
@@ -119,10 +139,14 @@ mellan två körningar. Ringa in i stället, i fyra steg. Alla fyra redovisas i
 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 då `DELA_UPP`
-och ingen poäng, så att posten först prövas i delar. Är detta redan en del av en delad
-post sätter du i stället `OVER_SKALAN` — underlaget för den nivån är för tunt för att
-jämföra mot, och posten ska offereras separat.
+Får du inget tak: posten är större än skalans högsta referensuppdrag. Du måste ha
+jämfört mot skalans översta ankare (A16) och redovisat det i `bracket.steps` innan du
+säger det; ett "inget tak" utan den jämförelsen fälls av kontraktskontrollen. Sätt då
+`DELA_UPP` och ingen poäng, så att posten först prövas i delar. Är posten redan en
+split-del (`split.part` i underlaget, en tidigare `DELA_UPP`) sätter du i stället
+`OVER_SKALAN`: underlaget för den nivån är för tunt att jämföra mot, och posten
+offereras separat. En buntdel (`bundle.part`, flera specar ur samma önskemål) är inte
+en split-del; på en buntdel utan tak är utfallet `DELA_UPP`.
 
 **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å
@@ -153,8 +177,10 @@ repot saknar testsvit. Räkna bara det manuella arbete som återstår när en fu
 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. Saknas testsviten är det inte en rabatt: täckningen byggs som en egen
-post före ändringen och poängsätts för sig. Skriv en rad under `notes` om vilken yta
-som saknar täckning, så att den posten går att skapa.
+post före ändringen och poängsätts för sig. Fyll då `coverage_post` med `yta` (den
+yta som saknar täckning, i kundens språk) och `omfattning` (en mening om vad
+täckningsposten bygger). Fältet är det som gör att posten kan skapas, en not i
+`notes` räcker inte. Utelämna fältet helt när antagandet inte görs.
 
 **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
@@ -179,6 +205,10 @@ uppdrag av en typ som saknas i skalan poängsätts mot de närmaste i storlek, i
 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.
 
+`type` är ett av översiktstabellens fem värden, ordagrant: Kundvänd funktion, Underhåll,
+Teknisk uppsättning, Integration, Internt verktyg. Saknar posten en självklar typ, välj
+den närmaste och skriv resonemanget under `notes`, aldrig i själva värdet.
+
 ## Grindläget
 
 Körs skillen på en fullständig implementationsplan efter kundens godkännande, sätt
@@ -205,7 +235,7 @@ Bygger fullplanen ett annat vägval än det som såldes är det en händelse att
     "floor": { "anchor": "", "score": null, "why": "" },
     "ceiling": { "anchor": "", "score": null, "why": "" },
     "between": ["", ""],
-    "steps": []
+    "steps": [{ "anchor": "A12", "relation": "storre | mindre | lika", "grund": "" }]
   },
   "drivers": [],
   "confidence": "hog | medel | lag",
@@ -214,6 +244,7 @@ Bygger fullplanen ett annat vägval än det som såldes är det en händelse att
   "alternatives": [],
   "dependencies": [],
   "notes": [],
+  "coverage_post": { "yta": "…", "omfattning": "…" },
   "customer_rationale": "",
   "guard_diff": []
 }
@@ -222,9 +253,13 @@ Bygger fullplanen ett annat vägval än det som såldes är det en händelse att
 `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.
+`bracket.steps` är jämförelserna från steg 3, en per referensuppdrag du vägde mot. Varje
+steg är ett objekt med exakt tre nycklar: `anchor` (ankarets id, `A12`), `relation`
+(`storre` om posten är större än ankaret, `mindre` om den är mindre, `lika` om den är
+jämbördig; ASCII, samma stil som `hog/medel/lag`) och `grund` (på vilken grund, en eller
+två meningar). Inga andra nycklar, ingen poäng i steget: ankarets poäng står i skalan.
+Det är det som gör poängen granskbar, och det är stegen driftvakten jämför mellan två
+körningar. En poäng utan inringning är inte ett giltigt utfall.
 
 `drivers` är de två eller tre faktorer som mest avgjorde placeringen. Varje driver är
 ett objekt: `pastaende` (faktorn med dina ord, utan citattecken) och `ankare`
@@ -246,6 +281,11 @@ hit och ska utelämnas helt. Är listan tom fanns bara en väg som löser proble
 `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.
 
+`coverage_post` är valfritt: bara när repot saknar den täckning skalan förutsätter
+(se "Vad du jämför på"). `yta` är den yta som saknar täckning, i kundens språk;
+`omfattning` är en mening om vad täckningsposten bygger. Utelämna fältet helt när
+antagandet inte görs.
+
 **Ett antagande som analysen flaggat som overifierat ska alltid ut.** Går det att
 undersöka hör det till `notes` med hur det undersöks. Går det inte att undersöka blir
 det ett villkor i `conditions`, formulerat som "bygger på att X; faller X tidigt
@@ -264,6 +304,12 @@ ser rimlig ut.
 hur skalan räknade. Nämn aldrig poäng, referensuppdrag, ankare eller skalan. Kunden ska
 kunna invända mot omfattningen, inte mot modellen.
 
+**Kundens språk** är, överallt i den här skillen, det promptens `SPRÅK:`-rad anger
+(`svenska` eller `engelska`); i en fristående körning utan raden är det specens språk.
+Det gäller `customer_rationale`, `conditions`, `assumptions_stated`, `alternatives`
+(`label` och `adds`) och `coverage_post.yta`. Kontrollen fäller kundtext på fel språk,
+och en sådan post dispatchas om i sin helhet.
+
 Finns alternativ: beskriv dem sist, som egna vägar med var sitt pris. En mening var
 räcker — vad kunden får i stället, och vad som tillkommer. Priset räknas ur poängen
 någon annanstans; skriv aldrig ut poängen.

package/library/global/skills/request-score/references/poangskala.md

@@ -39,6 +39,9 @@ saknar tester i dag.
 Skälet är att alla sjutton referensuppdrag är satta som om en testsvit fanns. Jämförs en
 post mot dem på annan grund mäter den inte samma sak, och skalan slutar hålla ihop.
 
+Saknar repot täckningen: sätt poängen som om den fanns och fyll `coverage_post` i
+utfallet, så att täckningen blir en egen post före ändringen och poängsätts för sig.
+
 Saknas täckningen är det inte en rabatt. Den byggs då som en egen post före ändringen
 och poängsätts för sig. Räkna här bara det manuella arbete som återstår när testerna
 gjort sitt: kontroll mot en extern tjänsts testläge, visuell granskning, och genomgång

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

@@ -65,7 +65,7 @@ Hämta brädans sektioner. **En sektion:** ingen fråga, använd den. **Flera se
 
 Hämta fälten på båda brädorna och gå igenom tre saker:
 
-- **Finns fälten?** Kundbrädan behöver `Original request`, `Customer`, `Requested by` och kundstatusfältet. Samlingsbrädan behöver dessa plus `Offer status`, `Source`, `Request type`, `Funding`, `Score`, `Conditional classification`, `Decision`, `Decision reason`, `Spec iterations`, `Class iterations`.
+- **Finns fälten?** Kundbrädan behöver `Original request`, `Customer`, `Requested by` och kundstatusfältet. Samlingsbrädan behöver dessa plus `Offer status`, `Source`, `Request type`, `Funding`, `Score`, `Has conditions`, `Decision`, `Decision reason`, `Spec iterations`, `Score iterations`.
 - **Är de delade fälten samma fält?** Jämför gid, inte namn. Två fält med samma namn och olika gid är en dubblett — de driftar isär omedelbart, och felet syns först hos kunden.
 - **Går alternativen att slå upp?** Normaliserat, enligt regeln ovan. Rapportera vilka som inte gick att matcha och vilka alternativ som faktiskt finns.
 
@@ -130,7 +130,7 @@ Domän-JSON till vänster, fältnamn till höger. Ingen annan skill får se hög
 | `customer_rationale`        | beskrivningens `## Lösning och omfattning`                   | Låst efter `Decision`, se nedan                                                                                       |
 | `assumptions_stated` ej tom | beskrivningens `## Lösning och omfattning`                   | Kunden godkänner dem med priset                                                                                       |
 | `alternatives` ej tom       | beskrivningens `## Lösning och omfattning`                   | Egna vägar med var sitt pris                                                                                          |
-| `conditions` ej tom         | Conditional classification                                   | se nedan                                                                                                              |
+| `conditions` ej tom         | Has conditions                                               | se nedan                                                                                                              |
 | `decision`                  | Decision                                                     | Beställd · Ej beställd · Uppskjuten                                                                                   |
 | `decision_reason`           | Decision reason                                              |                                                                                                                       |
 
@@ -139,16 +139,15 @@ där kunden faktiskt läser den. Att skriva samma text på två ställen gav tv
 som kunde glida isär, och fältet fanns bara för att kunna filtrera på en text ingen
 filtrerar på. Fältet får ligga kvar i Asana med sina gamla värden som historik.
 
-**Två fältnamn är historiska.** `Class iterations` och `Conditional classification`
-döptes när modellen satte klasser i stället för poäng. Innehållet är oförändrat i sak —
-en varvräknare och en ja/nej-flagga för villkor — så de används vidare under sina gamla
-namn hellre än att data flyttas. Döps de om i Asana måste den här mappningen uppdateras
-samtidigt.
+**Fältnamnen byttes 2026-09-08 (ADR-0121):** `Score iterations` hette `Class iterations`
+och `Has conditions` hette `Conditional classification`. Innehållet är oförändrat i sak,
+en räknare över poängsättningsvarv och en ja/nej-flagga för villkor. En bräda som
+fortfarande bär de gamla namnen är inte uppdaterad: säg till i stället för att gissa.
 
 `Score` är ett taltfält. Skriv poängen som tal, inte som text, så att den går att
 sortera och summera i listvyer.
 
-`Conditional classification` är härledd: villkorslistan är tom eller inte. Sätt alltid ett värde när en poängsättning skrivs — aldrig tomt, eftersom tomt är reserverat för "ingen har poängsatt än". Bär fältet flera värden samtidigt är det felkonfigurerat som flerval; skriv ett värde och säg till.
+`Has conditions` är härledd: villkorslistan är tom eller inte. Sätt alltid ett värde när en poängsättning skrivs — aldrig tomt, eftersom tomt är reserverat för "ingen har poängsatt än". Bär fältet flera värden samtidigt är det felkonfigurerat som flerval; skriv ett värde och säg till.
 
 Asana konverterar markdown till `html_notes`. Använd `html_notes` för beskrivningen, för subtaskarnas innehåll och för kommentarer, inte `notes`, annars tappas struktur — rubriker, kursiv text och de vågräta linjerna mellan sektionerna försvinner alla med `notes`.
 
@@ -217,7 +216,7 @@ körningen gjordes.
 
 Skälet: en poäng som stiger är en prishöjning. Sker den genom att beskrivningen skrivs om finns inget spår av vad kunden faktiskt godkände, och den fria exiten — modellens centrala kundlöfte — går inte att lösa ut, eftersom det inte längre går att visa vad som ändrats.
 
-Låset gäller beskrivningen och `Score`, som bär den poäng priset räknades ur. Det som är internt får alltid skrivas — subtaskarna (det är hela poängen med dem: de är löpnumrerade och ärver inte kundbrädan, så en poängsättning efter kundbeslut landar där som vanligt), `Conditional classification` och räknarna.
+Låset gäller beskrivningen och `Score`, som bär den poäng priset räknades ur. Det som är internt får alltid skrivas — subtaskarna (det är hela poängen med dem: de är löpnumrerade och ärver inte kundbrädan, så en poängsättning efter kundbeslut landar där som vanligt), `Has conditions` och räknarna.
 
 ### Grindläget stöds inte
 
@@ -361,8 +360,8 @@ Kundbrädan bär bara det kunden ska se. Interna fält finns enbart på samlings
 | Bara samlingsbrädan                | Delade, syns på båda                       |
 | ---------------------------------- | ------------------------------------------ |
 | Offer status · Source              | Kundstatus                                 |
-| Spec iterations · Class iterations | Original request · Customer · Requested by |
-| Conditional classification         | Request type · Funding                     |
+| Spec iterations · Score iterations | Original request · Customer · Requested by |
+| Has conditions                     | Request type · Funding                     |
 |                                    | Score · Decision · Decision reason         |
 
 Ett delat fält är **samma** fält på båda brädorna. Finns två fält med samma namn och olika gid är det en dubblett, inte en delning — de driftar isär omedelbart och felet syns först när en kund tittar på något som inte uppdaterats. Upptäcker du en sådan: skriv inte till någon av dem, säg till.
@@ -428,7 +427,7 @@ Skälet: `Request status` är det enda i hela flödet en kund ser. Två fält so
 
 Feedback är en kommentar plus en flytt bakåt till närmaste AI-läge. Två regler:
 
-**Bumpa räknaren.** Bakåt till 📥 höjer `Spec iterations`. Bakåt till ✅ höjer `Class iterations` (fältets namn är historiskt; det räknar poängsättningsvarv). Läs nuvarande värde och skriv värdet plus ett — sätt aldrig ett absolut tal från minnet.
+**Bumpa räknaren.** Bakåt till 📥 höjer `Spec iterations`. Bakåt till ✅ höjer `Score iterations` (räknar poängsättningsvarv). Läs nuvarande värde och skriv värdet plus ett — sätt aldrig ett absolut tal från minnet.
 
 **Ändrad spec ogiltigförklarar poängsättningen.** Går en post bakåt till 📥 ska den passera ⚖️ igen på vägen tillbaka. Skriv inte över `Score` med ett nytt värde utan att posten gjort den resan.
 

package/library/global/skills/request-write-spec/SKILL.md

@@ -55,7 +55,7 @@ Missar du en sådan fråga blir den ett tyst val längre fram i kedjan, fattat a
 
 **En skärm.** Behöver specen skrollas innehåller den nästan alltid två beslut.
 
-**Kundens språk.** Specen läses av kunden. Inga interna termer (protokolltermer, repo-namn, "backlog-post"), ingen story-mall ("Som X vill jag Y"). Svenska om önskemålet är på svenska.
+**Kundens språk.** Specen läses av kunden. Inga interna termer (protokolltermer, repo-namn, "backlog-post"), ingen story-mall ("Som X vill jag Y"). Specen skrivs på önskemålets språk, svenska eller engelska, och rubrikerna tas ur specformatets rubriktabell på samma språk som brödtexten, aldrig blandat. Granskarblocket är internt och alltid på svenska. Anger prompten `SPRÅK:` är det avgjort där.
 
 ## Normalfallet: en rubrik och en mening
 
@@ -68,6 +68,8 @@ Det är hela inputen. Ditt jobb är beredningen — att växa en spec ur den. En
 
 **Leta innan du antar.** Inventera vad sessionen ger dig tillgång till och använd det. Vilka källor som finns beror på uppdraget: i ett befintligt system är kodbasen bäst (finns vyn redan? vilket mönster används för liknande listor? vad heter begreppen i koden?), följt av tidigare specar och tickets för samma kund (hur har liknande poster lösts? vilka termer använder kunden — "skattning", "skift", "verksamhet"?). I ett nytt projekt finns ingen kodbas — då är briefen, offertunderlaget eller annat projektmaterial källan, och lösningen förankras i vad det materialet säger om målgrupp, flöden och befintliga system hos kunden. Det du hittar i källorna är inte antaganden — det är fakta, och de gör specen träffsäker på riktigt. Först när en fråga inte går att besvara ur det som finns blir den ett antagande i granskarblocket. Skriv gärna i granskarblocket _var_ du hämtat de viktigaste faktana ("mönstret finns i användarhanteringsvyn", "enligt briefen sid 2") — det låter granskaren skilja verifierat från gissat på en sekund.
 
+**Leta efter det som redan finns innan du skriver Lösning.** Sök i källmanifestet (`KÄLLOR:`) och med Grep i repot efter en inbyggd funktion i plattformen eller ett redan installerat paket som gör det önskemålet ber om: en väljare, en meny, en export, en behörighetsmodell som redan finns. Redovisa fyndet i granskarblocket under _Vägval jag gjort_ eller _Prisavgörande öppet val_, även när du inte hittade något ("ingen inbyggd yta för X funnen i KÄLLOR eller repot"). Det du inte letat efter kan du inte välja bort medvetet, och ett omedvetet egenbygge är det dyraste valet specen kan göra åt kunden (se regeln under Output).
+
 Sedan gäller för själva skrivandet:
 
 **Härled problemet ur önskemålet.** "Kan själv lägga till" betyder att någon idag inte kan själv — det görs via Haus eller inte alls. Det är problemraden. Du behöver inte veta detaljerna; skriv den mest sannolika vardagen och redovisa den som antagande om du är osäker.
@@ -88,11 +90,11 @@ Tre situationer, tre olika hanteringar — och ingen av dem är att fråga:
 
 **Ett värde någon annan ska bestämma** (t.ex. "gräns vid 12, 18 eller 24 månader?"): gör värdet konfigurerbart i lösningen så att frågan upphör att vara en fråga. "Gränsen ändras utan nytt bygge" är en utfallspunkt; det exakta värdet är en inställning, inte ett spec-beslut.
 
-**Ett vägval som inte går att avgöra utan kunden** — designfrågor, UX-riktning, okänd felorsak, eller ett val som påverkar andra poster: skriv INTE en låtsasspec. Flagga posten som **Koncept-kandidat** (formen okänd) eller **Diagnos-kandidat** (orsaken okänd) i granskarblocket, med vad som behöver avgöras. Skriv ändå så mycket av specen som går att skriva — rubrik, problem, det som är känt — så granskaren ser vad som väntar bakom vägvalet.
+**Ett vägval som inte går att avgöra utan kunden** — designfrågor, UX-riktning, okänd felorsak, eller ett val som påverkar andra poster: skriv INTE en låtsasspec. Skriv posten i **kandidatformen** (se `references/specformat.md`, avsnittet Kandidatform): rubriken, direkt under den markörraden `**Koncept-kandidat**` (formen okänd) eller `**Diagnos-kandidat**` (orsaken okänd), på engelska `**Concept candidate**` / `**Diagnosis candidate**`, sedan **Problem** och det som är känt under Ingår inte, Kräver eller Villkor. Ingen Lösning och ingen När det är klart: en kandidat har inget utfall att lova, och med en Lösning är det ingen kandidat längre. Formen är entydig med flit, formkontrollen läser markören och flödet stoppar posten som KONCEPT eller DIAGNOS utan analys eller poäng. Nämn kandidaten även under _Flaggor_ i granskarblocket, med vad som behöver avgöras.
 
 ## Output
 
-Skriv varje spec som ett eget block, exakt enligt formatet. Efter alla specar: ett **granskarblock** — internt, följer aldrig med till kund:
+Skriv varje spec som ett eget block, exakt enligt formatet. Efter VARJE spec: ett eget **granskarblock** (`## Till granskaren`) för just den specen, internt, följer aldrig med till kund. I en bunt bär varje block bara det som gäller sin egen spec; det som gäller bunten som helhet (att delarna hör ihop, ordningen dem emellan) står under Flaggor i första specens block. Ett block delat över flera specar fälls av formkontrollen (ADR-0118):
 
 ```
 ---
@@ -101,14 +103,21 @@ Skriv varje spec som ett eget block, exakt enligt formatet. Efter alla specar: e
 **Antaganden:** [tolkningar av otydligt underlag, en rad var — "tom" om inga]
 **Vägval jag gjort:** [beslut du fattat på eget bevåg + en rads motivering — märk ut de som rör vad användaren får, de är specbeslut och det är dem granskaren måste titta på]
 **Öppna utfallsval:** [frågor om vad användaren får som inte gick att avgöra ur underlaget — "inga" om inga. Rena byggbeslut hör inte hit]
-**Flaggor:** [Koncept-/Diagnos-kandidat med skäl · misstänkt bunt/beroende till annan post · sådant som ser ut att röra behörighet, betalning, oåterkallelig data eller personuppgifter]
+**Prisavgörande öppet val:** [nej · eller "ja: <valet i en mening, i kundens språk>" när alternativen skiljer sig i vad som måste byggas och du inte kan välja ett utan att gissa kundens avsikt. Inbyggd funktion kontra egenbygge är ALLTID ett ja med båda alternativen namngivna, se nedan. Ett ja stoppar posten före analys tills valet är avgjort; ett val som redan står under "Avgjorda val" i KÄLLOR flaggas aldrig]
+**Flaggor:** [Koncept-/Diagnos-kandidat med skäl (specen själv bär markörraden, det här är granskarens sammanfattning) · misstänkt bunt/beroende till annan post · sådant som ser ut att röra behörighet, betalning, oåterkallelig data eller personuppgifter]
 **Struket ur underlaget:** [tidsord, belopp, interna anteckningar som inte hör hemma i spec]
 ```
 
+**Avgjorda val i KÄLLOR.** Under `## Avgjorda val` i KÄLLOR står val en människa redan tagit. De är fast indata: skriv specen utifrån dem och flagga dem aldrig som öppna eller prisavgörande.
+
 Behörighets-/betalnings-/dataflaggan finns för att poängsättningen väger sådana poster tyngre — granskaren ska inte behöva upptäcka det själv.
 
 De två vägvalsraderna är åtskilda för att de kräver olika sak av granskaren: den första är beslut som redan är fattade och bara ska bekräftas, den andra är hål i specen som måste fyllas innan posten går vidare. Ett öppet utfallsval som ligger kvar i den första raden ser ut som ett fattat beslut och passerar granskningen.
 
+Prisavgörande öppet val är det enda i granskarblocket som stoppar posten. Vanliga öppna utfallsval löses av poängsättarens fyrstegsregel; den här raden är för valet där två alternativ ger två olika priser och bara kunden kan välja.
+
+**Egen lösning kontra plattformsfunktion.** Finns i källmanifestet, eller i din egen sökning i repot, en inbyggd funktion i plattformen eller ett redan installerat paket som täcker önskemålet, och du väljer att bygga en egen yta i stället, eller tvärtom väljer bort en fungerande inbyggd yta för en egen, är det ALLTID `Prisavgörande öppet val: ja` med båda alternativen namngivna (inbyggd funktion respektive egenbygge), aldrig ett Vägval jag gjort. Skillnaden i pris mellan de två är som störst just där, och bara kunden kan välja. Ett egenbygge som inte ens nämner den inbyggda ytan ser ut som det enda sättet, och kunden betalar tre gånger priset utan att ha valt det.
+
 ## Exempel i korthet
 
 Rått önskemål: _"Som chef vill jag själv kunna radera en skattning så att olämpligt innehåll kan tas bort direkt utan att ringa Haus."_

package/library/global/skills/request-write-spec/references/specformat.md

@@ -34,6 +34,54 @@ Varje spec har exakt de här rubrikerna, i den här ordningen. De tre sista finn
 
 **Villkor** _(vid behov)_ — när posten vilar på något vi inte kan verifiera i förväg. "Bygger på att X. Faller det avbryter vi utan kostnad."
 
+### Språk
+
+Specen skrivs på önskemålets språk, svenska eller engelska. Rubrikerna tas ur
+tabellen nedan på samma språk som brödtexten, aldrig blandat: kunden ser
+rubrikerna, och en engelsk spec under svenska rubriker läses som ett
+klipp-och-klistra-fel. Granskarblocket är internt och alltid på svenska.
+Formkontrollen känner båda kolumnerna och fäller en spec som blandar dem.
+
+| Svenska          | English      |
+| ---------------- | ------------ |
+| Problem          | Problem      |
+| Lösning          | Solution     |
+| När det är klart | Done when    |
+| Ingår inte       | Not included |
+| Utseende         | Appearance   |
+| Kräver           | Requires     |
+| Villkor          | Conditions   |
+
+### Kandidatform
+
+När formen eller orsaken inte går att avgöra utan kunden (designfråga,
+UX-riktning, okänd felorsak) skrivs ingen låtsasspec. Posten skrivs i
+kandidatform: rubriken, en markörrad direkt under den, sedan Problem. Lösning
+och När det är klart finns inte, det är hela poängen: en kandidat har inget
+utfall att lova ännu. Ingår inte, Kräver och Villkor får stå med när de är
+kända.
+
+Markörraden är en av två, som egen fetstilsrad:
+
+| Svenska                | English                   | Utfall                                  |
+| ---------------------- | ------------------------- | --------------------------------------- |
+| `**Koncept-kandidat**` | `**Concept candidate**`   | KONCEPT, formen ska tas fram med kunden |
+| `**Diagnos-kandidat**` | `**Diagnosis candidate**` | DIAGNOS, orsaken ska undersökas först   |
+
+En kandidat går aldrig till analys eller poängsättning. Formkontrollen läser
+markören och flödet stoppar posten som KONCEPT eller DIAGNOS direkt, så att
+den når kunddialogen utan att kosta en bedömning. Skriver du en kandidat med
+en Lösning är det ingen kandidat längre, och formkontrollen fäller den.
+
+> **Förhandsgranskning visar ändringen innan den publiceras**
+>
+> **Diagnos-kandidat**
+>
+> **Problem**
+> Förhandsgranskningen svarar "Unable to connect" i skarpt läge medan samma
+> sida fungerar lokalt. Ingen vet ännu om felet sitter i vår konfiguration
+> eller i tjänsten bakom.
+
 ---
 
 ## Reglerna

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haus-tech/haus-workflow",
-  "version": "5.0.1",
+  "version": "5.2.0",
   "description": "Haus AI workflow CLI for Claude Code.",
   "type": "module",
   "bin": {