@haus-tech/haus-workflow 4.2.0 → 4.4.0

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

@@ -23,10 +23,14 @@ Läs `.haus/request.json` i repo-roten:
 {
   "customer": "Vafab Miljö",
   "customer_board": "1202738613029434",
+  "customer_section": "1202738613029441",
+  "customer_section_name": "Mina sidor",
   "collection_board": "1217668109816859"
 }
 ```
 
+`customer_section` saknas när brädan inte är indelad i sektioner, och när uppsättningen kördes innan sektionssteget fanns. `customer_section_name` finns bara för att kunna visas i bekräftelser — **matcha alltid på gid, aldrig på namn.**
+
 **Saknas filen: kör uppsättningen nedan.** Gissa aldrig utifrån repo-namn eller mappnamn.
 
 Finns filen: **verifiera brädan en gång, före första skrivningen.** Slå upp `customer_board` på gid och skriv ut namnet: _"Skriver till Vafab Mina sidor — stämmer det?"_ Att lägga en kunds request på fel kundbräda är det enda felet i hela flödet som en annan kund kan se, och det går inte att städa i tysthet.
@@ -47,11 +51,17 @@ Be om en Asana-URL — `.../project/<gid>/...` ger dig gid:t direkt och är mins
 
 Slå upp gid:t och läs upp namnet för bekräftelse. **Ser namnet ut som en test- eller provbräda — "test", "sandbox", "torrsim", ett årtal som passerat — säg det rakt ut och fråga en gång till.** En felkopplad kundbräda upptäcks först när en kund ser någon annans request.
 
-**3 — Samlingsbräda?**
+**3 — Vilken sektion på kundbrädan?**
+
+Vissa kundbrädor är indelade i sektioner, där varje sektion motsvarar ett projekt. En task som skapas utan sektion hamnar i brädans default och blir svår att hitta.
+
+Hämta brädans sektioner. **En sektion:** ingen fråga, använd den. **Flera sektioner:** lista dem med namn och gid, en per rad, och fråga vilken requests från det här repot ska hamna i.
+
+**4 — Samlingsbräda?**
 
 `1217668109816859` (TECH · Offer pipeline) om inget annat sägs. Nämn den, be om bekräftelse, gå vidare.
 
-**4 — Kontrollera uppsättningen**
+**5 — Kontrollera uppsättningen**
 
 Hämta fälten på båda brädorna och gå igenom tre saker:
 
@@ -59,23 +69,25 @@ Hämta fälten på båda brädorna och gå igenom tre saker:
 - **Ä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.
 
-**5 — Skriv filen**
+**6 — Skriv filen**
 
 ```json
 {
   "customer": "SamSa",
   "customer_board": "1217634399775198",
+  "customer_section": "1217634399775205",
+  "customer_section_name": "Mina sidor",
   "collection_board": "1217668109816859"
 }
 ```
 
-Skriv den även om steg 4 hittade problem — filen handlar om vilka brädor som gäller, fältuppsättningen är ett annat problem och ska inte blockera. Redovisa innehållet, och säg att filen bör checkas in: ett fel board-gid syns då i en diff i stället för att upptäckas i efterhand.
+Skriv den även om steg 5 hittade problem — filen handlar om vilka brädor som gäller, fältuppsättningen är ett annat problem och ska inte blockera. Redovisa innehållet, och säg att filen bör checkas in: ett fel board-gid syns då i en diff i stället för att upptäckas i efterhand.
 
-**6 — Rapportera och gå vidare**
+**7 — Rapportera och gå vidare**
 
 Sammanfatta vad som skrevs och vad som saknas, i den ordningen. Fortsätt sedan med det användaren faktiskt bad om — uppsättningen är en förutsättning, inte ett ärende i sig.
 
-Hittade steg 4 problem som gör nästa operation omöjlig, säg vilket och stanna där. Halvskapade requests är dyrare att reda ut än ett avbrott.
+Hittade steg 5 problem som gör nästa operation omöjlig, säg vilket och stanna där. Halvskapade requests är dyrare att reda ut än ett avbrott.
 
 ## Slå upp fälten, hårdkoda dem aldrig
 
@@ -100,30 +112,109 @@ Hittar du inte ett fält du ska skriva till: avbryt och säg vilket. Skapa aldri
 
 Domän-JSON till vänster, fältnamn till höger. Ingen annan skill får se högerkolumnen.
 
-| Domän                          | Fält                       | Not                                                 |
-| ------------------------------ | -------------------------- | --------------------------------------------------- |
-| `request_id`                   | task gid                   | —                                                   |
-| `original_request`             | Original request           | Skrivs en gång. Ändras aldrig, inte ens för stavfel |
-| `source`                       | Source                     | Kunden skrev själv · Mejl · Möte · Haus initierade  |
-| `customer`                     | Customer                   |                                                     |
-| `requested_by`                 | Requested by               | people-fält, kräver user gid                        |
-| `type`                         | Request type               | Bug · Improvement · Wear                            |
-| `funding`                      | Funding                    |                                                     |
-| `spec`                         | task description           | Ersätter hela beskrivningen                         |
-| `impact`                       | kommentar                  | Ny kommentar, aldrig en ersättning                  |
-| `classification`               | kommentar                  | Ny kommentar, aldrig en ersättning                  |
-| `customer.class`, läge pricing | Class (offered)            | Skrivs aldrig över efter kundbeslut                 |
-| `customer.class`, läge guard   | Class (revised)            |                                                     |
-| `customer.rationale`           | Class rationale            |                                                     |
-| `customer.conditions` ej tom   | Conditional classification | se nedan                                            |
-| `decision`                     | Decision                   | Beställd · Ej beställd · Uppskjuten                 |
-| `decision_reason`              | Decision reason            |                                                     |
-
-**Specen bor i beskrivningen, allt maskinellt i kommentarer.** Beskrivningen ska alltid visa nuvarande spec — den är det granskaren och kunden läser. Påverkansanalys och klassnings-JSON läggs som kommentarer, aldrig som redigeringar: en omkörning ska lägga sig bredvid den förra, inte radera den. Det är den spårbarhet protokollet kräver, och det är också hur man i efterhand ser vad som ändrades mellan varven.
+| Domän                          | Fält                                                         | Not                                                 |
+| ------------------------------ | ------------------------------------------------------------ | --------------------------------------------------- |
+| `request_id`                   | task gid                                                     | —                                                   |
+| `original_request`             | Original request + beskrivningens `## Ursprunglig förfrågan` | Skrivs en gång. Ändras aldrig, inte ens för stavfel |
+| `source`                       | Source                                                       | Kunden skrev själv · Mejl · Möte · Haus initierade  |
+| `customer`                     | Customer                                                     |                                                     |
+| `requested_by`                 | Requested by                                                 | people-fält, kräver user gid                        |
+| `type`                         | Request type                                                 | Bug · Improvement · Wear                            |
+| `funding`                      | Funding                                                      |                                                     |
+| `spec`                         | beskrivningens `## Specifikation`                            | Bara den sektionen. Låst efter `Decision`, se nedan |
+| `impact`                       | subtask `Påverkansanalys vN`                                 | Ny subtask varje varv, aldrig en redigering         |
+| `classification`               | subtask `Klassning vN`                                       | Ny subtask varje varv, aldrig en redigering         |
+| `customer.class`, läge pricing | Class (offered) + beskrivningens `## Klass och pris`         | Skrivs aldrig över efter kundbeslut                 |
+| `customer.class`, läge guard   | Class (revised)                                              |                                                     |
+| `customer.rationale`           | Class rationale + beskrivningens `## Klass och pris`         | Låst efter `Decision`, se nedan                     |
+| `customer.conditions` ej tom   | Conditional classification                                   | se nedan                                            |
+| `decision`                     | Decision                                                     | Beställd · Ej beställd · Uppskjuten                 |
+| `decision_reason`              | Decision reason                                              |                                                     |
 
 `Conditional classification` är härledd: villkorslistan är tom eller inte. Sätt alltid ett värde när en klassning skrivs — aldrig tomt, eftersom tomt är reserverat för "ingen har klassat ä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 spec och kommentarer, inte `notes`, annars tappas struktur.
+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`.
+
+## Beskrivningen och subtaskarna
+
+**Beskrivningen är det enda någon faktiskt läser, och det är dessutom vad kunden ser.** Den ska därför bära requesten i läsbar form och ingenting annat. Maskineriet — påverkansanalys och klassning — ligger i subtasks, som inte ärver kundbrädan och därmed är interna utan att någon behöver komma ihåg det.
+
+Beskrivningen har de här rubrikerna, i den här ordningen, åtskilda av en vågrät linje:
+
+```
+## Ursprunglig förfrågan
+_Så som önskemålet kom in — 2026-08-21_
+
+[kundens ord]
+
+---
+
+## Specifikation
+_Vad vi föreslår att vi bygger — uppdaterad 2026-08-21_
+
+[specen]
+
+---
+
+## Klass och pris
+_Omfattning och pris — uppdaterad 2026-08-21_
+
+[klass och kundvänlig motivering]
+```
+
+**Linjen mellan sektionerna** skrivs som `<hr/>`. Asana renderar den i tasks — till skillnad från `<h3>`, som inte finns i beskrivningsfältet. Håll dig därför till `<h2>` för rubrikerna (`##` i markdown), aldrig en nivå djupare.
+
+**Raden under varje rubrik** säger vad sektionen är och när den senast skrevs. Den finns för att sektionerna kommer från skilda tillfällen: utan den läses beskrivningen som en text skriven i ett svep, och då ser det ut som att allt beslutats samtidigt. Datumet gör det synligt att specen och priset tillkom efter kundens ursprungliga ord — och att de kan ha tillkommit olika dagar.
+
+Raden är i kundens språk, precis som resten av beskrivningen. Aldrig skillnamn, aldrig protokolltermer, aldrig "genererad av". Datumformat `ÅÅÅÅ-MM-DD`. `## Ursprunglig förfrågan` får skapandedagens datum och behåller det för alltid — den sektionen skrivs aldrig om, så "uppdaterad" hör inte hemma där.
+
+**Ta datumet från systemet, inte ur minnet.** En modell som skriver dagens datum på känsla skriver ofta fel år, och ett felaktigt datum är värre än inget: det ser ut som ett faktum.
+
+Varje sektion har exakt en källa:
+
+| Sektion                    | Källa                                                         | Skrivs                      |
+| -------------------------- | ------------------------------------------------------------- | --------------------------- |
+| `## Ursprunglig förfrågan` | kundens ord, eller utdraget ur mejl/brief                     | vid skapandet, sedan aldrig |
+| `## Specifikation`         | `request-write-spec`                                          | vid varje specvarv          |
+| `## Klass och pris`        | `request-classify`: `customer.class` och `customer.rationale` | vid varje klassningsvarv    |
+
+- **Varje steg uppdaterar bara sin egen sektion och lämnar resten orörd.** Tidigare skrev bara en skill till beskrivningen; nu skriver flera, och ett steg som ersätter hela fältet raderar de andras arbete. Det gäller även datumraden: du uppdaterar din egen sektions rad, aldrig någon annans.
+- **Ursprunglig förfrågan** är kundens ord ordagrant, eller det relevanta utdraget ur ett längre mejl eller en brief. Skrivs en gång, redigeras aldrig. Fältet `Original request` behålls parallellt som skrivskyddad kopia.
+- **Klass och pris** är klassen och den kundvänliga motiveringen. Inga protokolltermer, inga frågerader. Samma text står i `Class rationale`-fältet: fältet finns för att kunna filtreras och läsas i listvyer, sektionen för att kunna läsas i sitt sammanhang.
+
+Beskrivningen har ingen sektion för vägval, och ska inte få en. Val som påverkar vad kunden får besvaras i specen — som acceptanskriterium eller under _Ingår inte_ — och är därmed redan en del av `## Specifikation`. Val som bara rör hur vi bygger är interna och ligger i påverkansanalysens subtask.
+
+### Beskrivningen låses vid kundbeslut
+
+Så snart `Decision` har ett värde är beskrivningen det kunden sagt ja till. **Skriv inte om någon sektion efter den punkten.** Det gäller alla tre sektionerna, oavsett vilket läge klassningen kördes i och oavsett vad som ändrats.
+
+Ägartabellen ovan beskriver vad som gäller fram till kundbeslutet.
+
+**Läs `Decision` innan varje skrivning till beskrivningen.** Det är en kontroll som ska utföras, inte något du antar utifrån ärendets status — ett ärende kan ha fått ett beslut mellan två av dina körningar.
+
+Blir klassen en annan vid grinden: fyll `Class (revised)`, lägg klassningen som ny subtask, flytta posten till ⚖️ och stanna där. En människa avgör vad kunden får se, och det blir i så fall ett nytt beslut — inte en tyst redigering av ett gammalt.
+
+Detsamma gäller om en klassning körs om i prisläget på ett ärende som redan har ett `Decision`. Kontrollera fältet innan du skriver, inte vilket läge du kördes i.
+
+Skälet: en klass som ändras uppåt ä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 de fält som bär samma text som den: `Class (offered)` och `Class rationale`. 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 klassning efter kundbeslut landar där som vanligt), `Class (revised)`, `Conditional classification` och räknarna.
+
+**Påverkansanalys och klassning läggs som subtasks, inte som kommentarer.**
+
+```
+Ticket
+├── beskrivning: de tre sektionerna ovan
+├── Påverkansanalys          (subtask)
+└── Klassning                (subtask)
+```
+
+- Subtasks ärver inte kundbrädan och är därmed interna. Kontrollera att de inte multi-homas dit.
+- **Ett nytt varv skapar en ny subtask, den ersätter inte den förra.** Namnge med löpnummer: "Klassning v1", "Klassning v2". Beskrivningen kan inte bära historik, och det är subtaskarna som ger den tillbaka — i läsbar form, till skillnad från en kommentarsström.
+- Klassningens subtask innehåller den läsbara tabellen — fråga, svar, belägg — och därunder den råa JSON:en, som behövs för att diffa vid grinden men som ingen läser.
+- Finns flera parallella underlag namnges subtaskarna så parningen syns: "Klassning — delad komponent", "Klassning — specialfall".
+
+**Kommentarer används inte längre för påverkansanalys eller klassning.** De är kvar för det som faktiskt kommenteras — feedback vid bakåtflytt — och där gäller fortsatt att de är append-only och aldrig redigeras.
 
 ## Var en request kommer ifrån
 
@@ -131,11 +222,11 @@ Ursprunget avgör vad du gör, och det avgör också hur underlaget ska tolkas s
 
 ### Kunden skrev själv på sin bräda
 
-Kundens ord ligger i beskrivningen, och specen ska sedan ta beskrivningens plats. Det är den **enda destruktiva operationen i hela flödet**, och ordningen är inte förhandlingsbar:
+Kundens ord ligger i beskrivningen, och beskrivningen ska sedan skrivas om till sektionsform. Det är den **enda destruktiva operationen i hela flödet**, och ordningen är inte förhandlingsbar:
 
 1. Kopiera beskrivningen ordagrant till `Original request`
 2. **Läs tillbaka fältet och verifiera att texten landat**
-3. Först då skriv specen över beskrivningen
+3. Först då skriv om beskrivningen — samma text ordagrant under `## Ursprunglig förfrågan`, specen under `## Specifikation`
 
 Hoppar du över steg 2 och skrivningen tyst misslyckas är kundens egna ord borta för alltid — vilket är precis det `Original request` finns för att förhindra. `Source` = kunden skrev själv.
 
@@ -143,11 +234,11 @@ Hoppar du över steg 2 och skrivningen tyst misslyckas är kundens egna ord bort
 
 Här skapar agenten både task och spec i ett svep, och kundens ord ligger kvar utanför Asana. Då står granskaren med en spec och inget att hålla den mot.
 
-**Klistra in det relevanta stycket ur mejlet eller anteckningen ordagrant** i `Original request` — inte en sammanfattning, inte en parafras. Risken för glid är störst just här, eftersom underlaget är råare och agenten tolkat mer.
+**Klistra in det relevanta stycket ur mejlet eller anteckningen ordagrant** i `Original request` och under `## Ursprunglig förfrågan` i beskrivningen — inte en sammanfattning, inte en parafras. Risken för glid är störst just här, eftersom underlaget är råare och agenten tolkat mer.
 
 Blir det flera requests ur samma underlag får var och en **sitt eget relevanta stycke**, inte hela mejlet klistrat en gång per post. Ett fält som innehåller allt håller ingenting.
 
-`Source` = mejl eller möte. Offer status sätts till 🔍 Spec redo för granskning, men bara om specen faktiskt är skriven. En tom task i granskningskön ser ut som ett fel i skillen när det är ett fel i regeln.
+`Source` = mejl eller möte. Statusarna sätts enligt skapandesekvensen nedan. Notera bara att en task inte får hamna i ett granskningsläge utan att specen faktiskt är skriven — en tom task i granskningskön ser ut som ett fel i skillen när det är ett fel i regeln.
 
 **Länka syskonposter.** Ett mejl eller ett möte producerar ofta flera saker, och `request-write-spec` avgör var snitten går. Beroendet mellan posterna måste finnas på ärendena, inte bara som en mening i ett granskarblock ingen läser om en vecka.
 
@@ -168,14 +259,41 @@ Ett delat fält är **samma** fält på båda brädorna. Finns två fält med sa
 
 Ordningen spelar roll, eftersom de interna fälten inte existerar på kundbrädan.
 
-1. **Skapa på kundbrädan** med det som finns där: task name, `Original request`, `Customer`, `Requested by`.
-2. **Verifiera att den landat på samlingsbrädan.** Speglingen sker automatiskt men inte alltid direkt — läs tillbaka uppgiftens projekt. Har den inte kommit fram, lägg till den dit själv.
-3. **Sätt `Source` och `Offer status`.** Först nu finns fälten.
+**1 — Skapa på kundbrädan** med det som finns där: task name, `Original request`, `Customer`, `Requested by`. Lägg tasken i rätt sektion (se nedan), och **sätt `Request status` redan här**, explicit:
 
-Försöker du sätta dem i steg 1 avbryter uppslagningen, och du står med en halvskapad request.
+| Läge vid skapandet                   | Request status  |
+| ------------------------------------ | --------------- |
+| Inget skrivet än, bara önskemålet    | Mottaget        |
+| Spec finns och ligger för granskning | Under bedömning |
+
+**2 — Verifiera att den landat på samlingsbrädan.** Speglingen sker via en Asana-regel och är asynkron — läs tillbaka uppgiftens projekt och vänta in den. Har den inte kommit fram, lägg till den dit själv.
+
+**3 — Sätt `Source` och `Offer status`.** Först nu finns fälten. `Offer status` ska motsvara det `Request status` du satte i steg 1:
+
+| Läge             | Offer status                |
+| ---------------- | --------------------------- |
+| Inget skrivet än | 📥 Inkommet                 |
+| Spec finns       | 🔍 Spec redo för granskning |
+
+**4 — Verifiera att båda statusfälten har värden.** Läs tillbaka tasken och kontrollera `Request status` och `Offer status`. Har något inte landat: säg det och stanna.
+
+Försöker du sätta `Offer status` eller `Source` i steg 1 avbryter uppslagningen, och du står med en halvskapad request.
+
+**En task du skapar lämnar aldrig skillen med tomt `Request status` eller tomt `Offer status`.** Kundbrädan grupperas på det ena fältet, offertbrädan på det andra — en task utan värde hamnar utanför alla grupper. Den finns, men ingen ser den, och felet upptäcks först när någon undrar var den tog vägen. Glappet är verkligt: `Offer status` existerar bara på offertbrädan, så mellan steg 1 och steg 3 är det fältet oundvikligen tomt. Därför sätts `Request status` i steg 1 — den täcker glappet.
+
+Efter skapandet rör du aldrig `Request status` igen. Då härleds den av Asana-regeln ur `Offer status`.
 
 Task name ska vara det förändrade tillståndet, inte uppgiften, samma regel som specrubriken. Finns ingen spec än: använd önskemålets egna ord, och byt namn när specen skrivs.
 
+### 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`.
+- **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.
+
+Matcha alltid på gid. `customer_section_name` finns bara för att kunna visas i en bekräftelse.
+
 ## Statusarna
 
 **Offer status** driver arbetet. Varje läge är en inkorg:
@@ -188,7 +306,9 @@ Task name ska vara det förändrade tillståndet, inte uppgiften, samma regel so
 | ⚖️ Klassning redo för granskning | människa                                     |
 | 📤 Klar – till kund              | kundens svar, se `Decision`                  |
 
-**Request status** är kundens vy och ska härledas, inte sättas fritt. Sätt den bara när du också sätter det som styr den, och skriv aldrig ett värde som motsäger Offer status eller Decision.
+**Request status** är kundens vy och härleds av en Asana-regel ur `Offer status`. **Sätt den en enda gång — vid skapandet, innan `Offer status` finns att härleda ur.** Därefter rör du den aldrig; regeln äger den. Startvärdet ska vara exakt det regeln hade härlett, så att fälten aldrig kan säga emot varandra.
+
+Skälet: `Request status` är det enda i hela flödet en kund ser. Två fält som båda sätts för hand driftar isär, och just den driften syns hos någon annan.
 
 **Att hämta en kö** är det vanligaste anropet: alla poster med ett givet Offer status. Filtrera alltid på samlingsbrädan.
 
@@ -200,14 +320,18 @@ Feedback är en kommentar plus en flytt bakåt till närmaste AI-läge. Två reg
 
 **Ändrad spec ogiltigförklarar klassningen.** Går en post bakåt till 📥 ska den passera ⚖️ igen på vägen tillbaka. Skriv inte över `Class (offered)` med ett nytt värde utan att posten gjort den resan.
 
+En bakåtflytt producerar en ny spec, och den ska in i beskrivningen — läs därför `Decision` först. Har posten redan ett kundbeslut gäller låsregeln och beskrivningen rörs inte.
+
 ## Vad du aldrig gör
 
 **Skriver till kund.** Du sätter fält och flyttar statusar. Att skicka förslaget är en människas beslut.
 
-**Skriver över beskrivningen utan att först ha verifierat `Original request`.**
+**Skriver över beskrivningen utan att först ha verifierat `Original request`** — och skriver aldrig över en sektion som ett annat steg äger.
+
+**Skriver till beskrivningen utan att ha läst `Decision`.** Har ärendet ett kundbeslut är beskrivningen låst, oavsett vad som ändrats.
 
-**Rör `Class (offered)` efter att `Decision` är satt.** Den är låst. Blir klassen högre vid grinden är det ett nytt beslut, inte en överskrivning — `Class (revised)` fylls, posten flyttas tillbaka till ⚖️, och människan avgör vad kunden får se.
+**Rör `Class (offered)` eller `Class rationale` efter att `Decision` är satt.** De bär samma text som beskrivningen och är låsta med den. Blir klassen högre vid grinden är det ett nytt beslut, inte en överskrivning — `Class (revised)` fylls, posten flyttas tillbaka till ⚖️, och människan avgör vad kunden får se.
 
 **Sätter `Decision` själv.** Det är kundens svar, det kommer utifrån.
 
-**Raderar eller redigerar kommentarer.** Loggen är append-only.
+**Raderar eller redigerar kommentarer.** Feedbackloggen är append-only.

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

@@ -43,6 +43,12 @@ Frågan är inte estetisk. Klassningen räknar omfattning per post, så en odela
 
 **Inget "eller" i listan.** Ett "eller" i en utfallspunkt är ett obeslutat vägval i förklädnad. Avgör det (se nedan) — skriv aldrig in det.
 
+**Leta efter dolda utfallsval.** En del frågor ser ut som tekniska detaljer men avgör vad användaren faktiskt får — "ska den komma tillbaka på nästa enhet?", "gäller det bara den här användaren eller alla?", "syns ändringen direkt eller vid nästa inloggning?". Sådana frågor är specfrågor, inte byggbeslut, och de ska besvaras här: som acceptanskriterium om svaret är givet, under _Ingår inte_ om avgränsningen är svaret, och som öppen fråga i granskarblocket om det inte går att avgöra ur underlaget.
+
+Testfrågan: **skulle användaren märka skillnad mellan alternativen?** Ja → specfråga, besvara den. Nej → byggbeslut, det tas i påverkansanalysen och du ska inte röra det.
+
+Missar du en sådan fråga blir den ett tyst val längre fram i kedjan, fattat av någon som bedömer teknik och inte behov — och då prissätts något ingen beslutat.
+
 **Lösningen pekar på listan.** Varje mening under Lösning ska motsvara en punkt under När det är klart. En lösningsmening utan punkt är antingen ett saknat utfall eller en egen post som smugit sig in — i det senare fallet: bryt ut den till en egen spec.
 
 **Ingen tid, inget pris.** Timmar, estimat och kronor finns inte i specen. Priset sätts av klassningen och möter kunden i förslaget. Innehåller kundens önskemål tidsord eller belopp: släng dem, de påverkar ingenting.
@@ -93,13 +99,16 @@ Skriv varje spec som ett eget block, exakt enligt formatet. Efter alla specar: e
 ## Till granskaren
 
 **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]
+**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]
 **Struket ur underlaget:** [tidsord, belopp, interna anteckningar som inte hör hemma i spec]
 ```
 
 Behörighets-/betalnings-/dataflaggan finns för att klassningen bumpar sådana poster — 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.
+
 ## 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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haus-tech/haus-workflow",
-  "version": "4.2.0",
+  "version": "4.4.0",
   "description": "Haus AI workflow CLI for Claude Code.",
   "type": "module",
   "bin": {
@@ -58,8 +58,8 @@
     "@types/fs-extra": "11.0.4",
     "@types/node": "22.20.1",
     "@types/semver": "7.8.0",
-    "@typescript-eslint/eslint-plugin": "8.65.0",
-    "@typescript-eslint/parser": "8.65.0",
+    "@typescript-eslint/eslint-plugin": "8.67.0",
+    "@typescript-eslint/parser": "8.67.0",
     "c8": "11.0.0",
     "esbuild": "0.28.2",
     "eslint": "9.39.5",