@haus-tech/haus-workflow 4.2.0 → 4.3.0

package/library/global/skills/haus-workflow/SKILL.md

@@ -171,7 +171,7 @@ upstream gets pruned automatically by `apply`'s existing orphan-pruning.
 
 ### New project (`project:new`)
 
-1. Open and follow `references/new.md` in this skill's directory. It is a seven-phase AI-driven flow: elicit the request and propose features, gate on user intent, scaffold (registry stacks via `haus new --json --yes` with a `--dry-run` preview; any other stack via a user-confirmed official scaffolder plus manual rails), install context via `haus init`, seed `docs/SPEC.md` + `docs/plans/walking-skeleton.md`, build the walking skeleton with one subagent per feature, and verify (build + lint + tests + smoke boot). Failure `detail` is relayed verbatim and nothing is ever auto-deleted. Never run bare interactive `haus new`.
+1. Open and follow `references/new.md` in this skill's directory. It is a seven-phase AI-driven flow: elicit the request and propose features, gate on user intent, scaffold (registry stacks via `haus new --json --yes` with a `--dry-run` preview; any other stack via a user-confirmed official scaffolder plus manual rails), install context via `haus init`, seed `docs/SPEC.md` + `docs/plans/walking-skeleton.md`, build the walking skeleton with one subagent per feature (against a structure recorded in `docs/DESIGN.md`), verify (build + lint + tests + smoke boot), then write the project docs by following `references/init.md` from step 3 (deep read, `CLAUDE.md` body + `docs/`, recommend re-check, opt-ins). Repos are only ever created private. Failure `detail` is relayed verbatim and nothing is ever auto-deleted. Never run bare interactive `haus new`.
 
 ### Add optional skills (`project:add-skills`)
 
@@ -204,6 +204,11 @@ choices.
 2. If the project is already healthy, say so in one line and stop.
 3. Otherwise, for each item that needs attention, run the exact fix command the
    doctor named (commonly `haus apply --write` or `haus apply --refill-config`).
+   One suggestion is not a shell command: if the doctor suggests running the
+   writing-documentation skill (`/docs`) because the project docs were never
+   generated, invoke that skill directly (it's installed in this project at
+   `.claude/skills/writing-documentation/`) instead of running anything in
+   the terminal.
 4. Re-run `haus doctor` to confirm the verdict is now green.
 5. Report what you changed in plain language — what was wrong, what you ran, and
    that it's now resolved.

package/library/global/skills/haus-workflow/references/new.md

@@ -23,9 +23,14 @@ Ask about dimensions, never from a domain template:
    shopping → cart, product pages, login, checkout, search); the user multi-selects
    and may add their own. Generate this list per request; it is never enumerated here.
 3. Auth (none / simple / provider) and data (mocked / real DB / external API).
-4. Practicals: project name (lowercase letters, digits, `. _ -`), GitHub org (default:
-   WeAreHausTech; "personal" = omit `--org`), visibility (private default / public),
-   create the GitHub repo at all (default yes).
+4. Practicals: project name (lowercase letters, digits, `. _ -`) and where the code
+   lives — exactly three choices, all private, never "public":
+   - a private repo in the org (default: WeAreHausTech),
+   - a private repo on personal GitHub (omit `--org`),
+   - local only, no GitHub repo (`--no-github`).
+     NEVER offer or pass `--public`: client projects must not be exposable by one
+     mis-click in a menu. A public repo is a deliberate manual act outside this flow
+     (the CLI flag exists for that; this skill never uses it).
 
 Pick the stack yourself from the answers. Confirm the stack with the user only on
 genuine ambiguity (e.g. web vs native unclear).
@@ -45,7 +50,7 @@ Check the registry first: `haus new --list --json`.
 **Stack in the registry (fast path):**
 
 1. Preview:
-   `haus new <stack> <name> --json --yes --dry-run [--org <org>] [--public] [--no-github]`
+   `haus new <stack> <name> --json --yes --dry-run [--org <org>] [--no-github]`
    and show the planned steps in plain language. Phase 2's approval already covers
    running this for real — no further confirmation needed.
 2. Execute the same command without `--dry-run`. Parse the JSON:
@@ -68,6 +73,9 @@ Everything from here on runs inside the new project directory — `cd` into it f
 stay there.
 
 - Fast path: the chained `haus init` inside `haus new` already ran — go to seeding.
+  (That chained init is the CLI pipeline only: it installs skills and guardrails but
+  does not write project docs — those are written in Phase 6, where the deep read
+  sees the real code instead of an empty scaffold.)
 - Manual path:
   - Read: run `haus init --json --dry-run` and read the envelope yourself.
   - If it refuses with the zero-signal message — literally zero catalog items matched,
@@ -91,8 +99,17 @@ stay there.
    loop needs them installed either way.
 2. Read the new project's `CLAUDE.md` and `.haus-workflow/WORKFLOW.md`; they are
    authoritative from here on.
-3. Per selected feature: dispatch one subagent per feature with a self-contained
-   prompt (spec excerpt, file paths, verify command); it builds the feature end-to-end
+3. Decide the project's file/folder structure BEFORE dispatching any build agent:
+   derive it from the chosen stack's own idioms (e.g. Next.js app-router layout,
+   NestJS module-per-domain, React Router route-module structure, Expo router
+   conventions) plus the installed coding-style rule (organize by feature/domain,
+   not by type; many small files). Record the layout as a short tree with one line
+   of placement guidance per top-level folder in `docs/DESIGN.md`. Parallel agents
+   with no shared conventions each invent their own layout — this step is what
+   keeps the result coherent.
+4. Per selected feature: dispatch one subagent per feature with a self-contained
+   prompt (spec excerpt, file paths, the recorded structure conventions from
+   `docs/DESIGN.md`, verify command); it builds the feature end-to-end
    but minimal — pages/routes/models/navigation wired, core logic TDD-tested — and
    makes one conventional commit on `main`. Not production-complete — a base to
    iterate on. This session orchestrates only.
@@ -103,12 +120,22 @@ stay there.
 
 ## Phase 6 — Verify + hand off
 
-1. Gate: build passes, lint passes, tests green, dev server boots (smoke check).
+1. Gate: build passes, lint passes, tests green, dev server boots (smoke check),
+   and the layout matches the structure conventions recorded in `docs/DESIGN.md`.
    Record the results in `docs/plans/walking-skeleton.md`'s verification blocks.
-2. Push to the remote (if a repo was created).
-3. Summarize: what exists, what is mocked, where the spec and plan live, and the
-   suggested next step — iterate per feature in fresh sessions inside the project
-   directory.
+2. Write the project docs: follow `references/init.md` from step 3 to the end —
+   deep read, `CLAUDE.md` body + `docs/` files, `.haus-workflow/deep-context.json`,
+   the `haus recommend` re-check, the opt-in helpers offer, and the final
+   `haus apply --write`. This runs HERE, after the build, on purpose: the chained
+   CLI init installs the writing-documentation skill but never executes it, and a
+   deep read now sees the real features instead of an empty scaffold — so the docs
+   describe reality and `haus recommend` can match what was actually built.
+   (init.md steps 1–2 are already covered by Phase 4; do not redo them.)
+   Commit the docs output as its own conventional commit.
+3. Push to the remote (if a repo was created).
+4. Summarize: what exists, what is mocked, where the spec, plan, and docs live, and
+   the suggested next step — iterate per feature in fresh sessions inside the
+   project directory.
 
 ## Failure rules
 

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

@@ -11,6 +11,8 @@ Det är inte artighet — det är hela poängen. Skriver du analysen med klassni
 
 Du ställer aldrig frågor tillbaka. Räcker inte underlaget avgör du och redovisar, eller skriver ordagrant att du inte kunnat verifiera.
 
+Analysen skrivs för `request-classify`, som hämtar ordagranna citat ur den som belägg — och för granskaren som vill kontrollera de citaten när en klassning ser konstig ut. Den är inte skriven för kunden och hamnar inte i ticketens beskrivning.
+
 ## Ingång
 
 **Godkänd spec** i Haus specformat. Ett rått önskemål duger inte — då analyserar du din egen tolkning. Saknas specen: avbryt och säg det, skriv den inte själv (`request-write-spec` gör det).
@@ -55,17 +57,19 @@ Varje påstående ska vara belagt i koden eller specen. Kan du inte belägga nå
 
 ## Vägval
 
-En verklig gaffel där båda vägarna fungerar. Du väljer och redovisar valet — det är därför ingen människa behövs i det här steget.
+**Du beslutar, du frågar inte.** Ett vägval är en gaffel där båda vägarna fungerar. Du väljer och redovisar valet — det är därför steget klarar sig utan en människa, och det är också vad kunden betalar oss för.
+
+Testfrågan: **skulle användaren märka skillnad mellan alternativen?**
 
-Två sorter får du inte ta:
+**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.
 
-**Design, utseende, flöde och UX.** De är kundens. Skriv i stället ut att frågan är öppen, med alternativen. Klassaren skickar posten till Koncept, och det är rätt.
+**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.
 
-**Vägval som ändrar arbetets omfattning väsentligt** — typiskt att lagra på servern i stället för i webbläsaren, eller att bygga nytt i stället för att återanvända. Välj inte tyst. Redovisa båda vägarna med varsin konsekvensbeskrivning och skriv ut att valet är öppet, så att klassaren kan klassa båda och kunden får se dem med varsin prislapp.
+Design, utseende, flöde och UX hör alltid till den andra kategorin.
 
-Du avgör _inte_ om skillnaden når över den gränsen — du känner inte klasserna. Regeln är enkel: rör alternativen olika lager (server mot klient, nytt mot återanvänt, ett flöde mot flera), redovisa båda.
+Ett valt och redovisat vägval är inget öppet vägval. Skriv "vi lägger detta i den delade komponenten eftersom Z", inte "detta kan lösas som delad komponent eller som specialfall".
 
-Ett valt och redovisat vägval är inget öppet vägval. Skriv "vi lagrar X i Y eftersom Z", inte "X kan lagras i Y eller Z".
+**Beslutet är ett kvitto.** Väljer vi tyst bär vi också ansvaret för valet. Redovisningen är därför kvittot: skriv vad som valdes, vad alternativet var, och varför. Det är enda gången någon kan granska omdömet i efterhand — klassningen och priset kommer se rimliga ut oavsett vilket alternativ som togs.
 
 ## Antaganden
 
@@ -86,8 +90,7 @@ 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]
-**Öppna vägval:** [de du lämnat öppna med flit — "inga" om inga]
-**Avvikelse mot specen:** [om koden säger något annat än specen förutsätter]
+**Avvikelse mot specen:** [om koden säger något annat än specen förutsätter · utfallsval specen lämnat obesvarade]
 ```
 
 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.

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

@@ -41,7 +41,6 @@ Ge inte dig själv repot i den här körningen. Har du det börjar du verifiera
   "customer": {
     "class": "",
     "rationale": "",
-    "tradeoffs": [],
     "conditions": [],
     "dependencies": []
   },
@@ -67,12 +66,6 @@ Blir utfallet `KONCEPT`, `DIAGNOS` eller `TILLBAKA_TILL_SPEC` sätts `customer.c
 
 `INPUT_SAKNAS` och `ESKALERA` är interna. `customer` lämnas tomt; de ska aldrig nå kund.
 
-### Öppna vägval
-
-Lämnade `request-assess-impact` ett vägval öppet med flit: klassa **båda** vägarna och lägg dem i `tradeoffs` med varsin klass och en rads konsekvens. Välj inte åt kunden.
-
-Kalibreringsloggens Vafab-fall är precis det: samma kundbehov, backend- eller webbläsarlagring, en klass i prisskillnad — och valet kom ur intern designdialog snarare än ur kundens behov. Regeln därifrån gäller.
-
 ## Efter körning
 
 Granskaren läser svaren fråga för fråga, inte slutklassen. Ett rätt slutresultat med fel belägg är en felkalibrering som råkade landa rätt, och den kommer tillbaka i en post där den inte gör det.

package/library/global/skills/request-classify/references/klassningsinstruktion.md

@@ -1,6 +1,6 @@
 # Klassningsinstruktion (maskinversion)
 
-**v0.5 · Internt.** Körbar instruktion för AI-klassning av ett inkommande önskemål. Principerna finns i klassningsprotokollet, som är överordnat vid konflikt. Det dokumentet är för människor och ingår inte i körningen — hittar du en regelkonflikt eskalerar du enligt regel 6, och granskaren avgör mot protokollet. v0.5: kriterier måste vara oberoende — samma förhållande får inte räknas två gånger, och touchpoint-kriteriet räknar bara lager som inget annat kriterium redan gjort anspråk på. Hålet uppstod i v0.4 när kriterier gick från antingen-eller till att adderas. v0.4: LARGE tillagd och stegen gjorda enhetliga — ett Medium-kriterium är basen, varje ytterligare kriterium och varje bump är ett steg upp, taket är LARGE. Tidigare saknades steget mellan MEDIUM och offert helt, vilket gjorde varje Medium med en bump till offert. v0.3 efter divergenstest (två körningar, samma underlag, olika klass utan eskalering): flerstegsflöde och datamodelländring omdefinierade. v0.2 efter två oberoende testkörningar: konsekvens-B1, bygg-avgränsad B2, undantag för ärvda antaganden och robusthetsinstruktioner, genomförbarhetsvillkor.
+**v0.6 · Internt.** Körbar instruktion för AI-klassning av ett inkommande önskemål. Principerna finns i klassningsprotokollet, som är överordnat vid konflikt. Det dokumentet är för människor och ingår inte i körningen — hittar du en regelkonflikt eskalerar du enligt regel 6, och granskaren avgör mot protokollet. v0.6: B2 omdefinierad. Frågan flyttar från vad planen säger om testning till vad ändringen kräver, och gränsen går mellan verifiering (en människa tittar, kostar minuter) och testning (en människa arbetar sig igenom, kostar timmar). Den gamla lydelsen tillät belägg endast ur byggets verifieringssteg, vilket gjorde att en plan som glömde nämna manuell testning slapp bumpen — kriteriet mätte planens utförlighet i stället för arbetets innehåll. v0.5: kriterier måste vara oberoende — samma förhållande får inte räknas två gånger, och touchpoint-kriteriet räknar bara lager som inget annat kriterium redan gjort anspråk på. Hålet uppstod i v0.4 när kriterier gick från antingen-eller till att adderas. v0.4: LARGE tillagd och stegen gjorda enhetliga — ett Medium-kriterium är basen, varje ytterligare kriterium och varje bump är ett steg upp, taket är LARGE. Tidigare saknades steget mellan MEDIUM och offert helt, vilket gjorde varje Medium med en bump till offert. v0.3 efter divergenstest (två körningar, samma underlag, olika klass utan eskalering): flerstegsflöde och datamodelländring omdefinierade. v0.2 efter två oberoende testkörningar: konsekvens-B1, bygg-avgränsad B2, undantag för ärvda antaganden och robusthetsinstruktioner, genomförbarhetsvillkor.
 
 ## Roll och uppgift
 
@@ -100,7 +100,13 @@ Bumpar mäter konsekvens av fel, aldrig att posten tekniskt vidrör en kategori.
 
 **B1 — Konsekvensrisk:** Kan ett fel i just denna post orsaka något av det som listas i KONSEKVENSRISK? Ställ frågan konkret: "vad är det värsta som händer om det här blir fel?" — visas en notis felaktigt är svaret nej; debiteras någon fel eller ser någon annans data är svaret ja. (Att koden anropar eller ligger nära känslig mekanik räcker inte; befintliga mönster som återanvänds räknas aldrig.)
 
-**B2 — Mänskligt testbehov i bygget:** Kräver byggets egen verifiering manuell mänsklig testning i fler än ett scenario, på flera enheter eller i flera miljöer? Belägg får endast hämtas ur byggets verifieringssteg — acceptanstest, kundmoment och verifiering som utförs av någon annan än Haus räknas aldrig (de är leveransvillkor, inte byggkostnad). Automatiska tester och enkel okulär kontroll räknas inte.
+**B2 — Testbehov som inte går att automatisera bort:** Förutsätt att ändringen täcks av automatiska tester, även om de inte finns i dag. Manuell testning ska aldrig göra om det maskinen klarar. Kvarstår något som ändå kräver en människa?
+
+_Skilj på verifiering och testning._ **Verifiering** är att en människa tittar och bekräftar att något blev som tänkt: ett nytt menyval, ett fält i ett befintligt formulär, en knapp enligt befintligt mönster, en kolumn i en befintlig tabell. Det kostar minuter och räknas INTE. **Testning** är att en människa måste arbeta sig igenom något: gå ett flöde steg för steg, pröva olika utfall och feltillstånd, använda en fysisk enhet, eller bedöma om upplevelsen håller. Det kostar timmar och räknas.
+
+Testning krävs typiskt när ändringen rör: ett nytt eller ändrat flöde som någon måste gå igenom från början till slut · identifiering som inte går att köra automatiskt (BankID, extern inloggningstjänst, betalväxelns egen dialog) · affärskritiska flöden där automatiken finns men inte räcker som enda kvitto före driftsättning (betalning, order, behörighet) · upplevd kvalitet, när bedömningen av hur något känns eller ser ut är poängen med uppdraget — en ny vy, ett omgjort flöde; en justerad färg eller marginal är verifiering · fysiska enheter (AR, kamera, riktiga telefoner, utskrift, skanner) · externa system utan testmiljö, där enda sättet att veta är att köra mot skarpt.
+
+Belägg hämtas ur ändringens innehåll: vad som byggs enligt spec och plan. Kundens acceptanstest räknas aldrig — det är ett leveransvillkor, inte en byggkostnad.
 
 **B3 — Blast radius:** Ändras något inom DELAD_KOD eller DRIFTMILJÖ så att fler kunder än beställaren, eller SLA-ytan, kan påverkas?
 
@@ -133,7 +139,7 @@ Svara med exakt denna struktur och inget annat:
 
 ## Hårda regler
 
-1. **Belägg är obligatoriskt.** Varje JA/NEJ ska ha ett ordagrant citat ur spec eller plan. Hittar du inget citat är svaret inte NEJ — det är låg konfidens. Beläggets källa spelar roll: för B2 gäller endast byggets verifieringssteg; citat ur acceptans-/kundmoment är ogiltigt belägg.
+1. **Belägg är obligatoriskt.** Varje JA/NEJ ska ha ett ordagrant citat ur spec eller plan. Hittar du inget citat är svaret inte NEJ — det är låg konfidens. Beläggets källa spelar roll: för B2 ska citatet visa VAD som byggs (flödet, enheten, den externa tjänsten), inte vad planen råkar säga om testning — en plan som glömmer nämna manuell testning ska inte slippa bumpen. Citat ur acceptans-/kundmoment är ogiltigt belägg.
 2. **Konfidens < 0.8 på någon fråga → utfall `ESKALERA`.** Klassa aldrig på gissning. En eskalerad post klassas av människa; det är ett korrekt utfall, inte ett misslyckande. Undantag: om frågan inte är utfallsavgörande (svaret ändrar inte slutklassen åt något håll) räcker det att notera den låga konfidensen i frågeraden.
 3. **Du klassar planen, inte önskemålet.** Önskemålets ton, storleksord ("en liten grej") eller kundens egen bedömning påverkar ingenting.
 4. **Tid existerar inte i klassningen.** Timmar, estimat och tidsord förekommer varken i din bedömning eller i något outputfält — alla gränser i denna instruktion är strukturella (vad som ändras), aldrig temporala (hur länge det tar).

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.3.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",