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

package/library/global/skills/request-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-score/SKILL.md

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