@haus-tech/haus-workflow 5.0.0 → 5.1.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,40 @@ 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.
+
+### 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 +162,23 @@ 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.
+
+**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

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

@@ -17,7 +17,7 @@ Skapa aldrig en request direkt på samlingsbrädan. En request som föds där sy
 
 ## Sessionsstart
 
-Läs `.haus/request.json` i repo-roten:
+Läs `.haus-workflow/request.json` i repo-roten:
 
 ```json
 {
@@ -39,7 +39,7 @@ Brädnamn är inte unika och flera brädor kan höra till samma kund. Använd al
 
 ## Uppsättning
 
-Kör den här när `.haus/request.json` saknas, och när användaren ber om det — "sätt upp", "koppla repot", "kör uppsättningen igen". Ett steg i taget, med användarens svar emellan. Fråga aldrig allt på en gång.
+Kör den här när `.haus-workflow/request.json` saknas, och när användaren ber om det — "sätt upp", "koppla repot", "kör uppsättningen igen". Ett steg i taget, med användarens svar emellan. Fråga aldrig allt på en gång.
 
 **1 — Var är repo-roten?**
 
@@ -399,7 +399,7 @@ Task name ska vara det förändrade tillståndet, inte uppgiften, samma regel so
 
 ### Sektion på kundbrädan
 
-- **Finns `customer_section` i konfigurationen:** använd den, men verifiera först att sektionen fortfarande finns på brädan — sektioner byter namn och tas bort. Är den borta: fråga vilken som gäller nu och uppdatera `.haus/request.json`.
+- **Finns `customer_section` i konfigurationen:** använd den, men verifiera först att sektionen fortfarande finns på brädan — sektioner byter namn och tas bort. Är den borta: fråga vilken som gäller nu och uppdatera `.haus-workflow/request.json`.
 - **Saknas `customer_section` och brädan har flera sektioner:** fråga **en gång** och använd svaret för hela omgången. Skapar du tio tasks ur ett mejl ska du inte fråga tio gånger. Erbjud att spara svaret i konfigurationsfilen så frågan inte återkommer.
 - **Har brädan bara en sektion:** fråga inte.
 - **Spänner omgången flera sektioner** — ett mejl innehåller ofta önskemål som hör till olika projekt — gissa inte utifrån innehållet. Fråga en gång om alla ska till samma sektion, och be om fördelningen om svaret är nej.

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
 
@@ -88,11 +88,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 +101,19 @@ 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. 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.
+
 ## 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.0",
+  "version": "5.1.0",
   "description": "Haus AI workflow CLI for Claude Code.",
   "type": "module",
   "bin": {