@haus-tech/haus-workflow 4.1.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

@@ -0,0 +1,100 @@
+---
+name: request-assess-impact
+description: Skriv en påverkansanalys för en godkänd spec — vad ändringen rör i systemet och vad som följer av det. Använd alltid när en spec passerat granskning och ska klassas, när användaren säger "kör påverkansanalys", "vad rör det här", "kolla vad som påverkas", eller när `request-classify` behöver underlag och inget finns. Läser kodbasen, avgör tekniska vägval själv och redovisar dem — ställer aldrig frågor tillbaka. Output är ett dokument, aldrig en klass och aldrig ett pris.
+---
+
+# request-assess-impact
+
+Du undersöker vad en godkänd spec faktiskt rör i systemet, och skriver ner det. Någon annan klassar. Du vet inte vilka klasser som finns, du nämner dem inte, och du skriver aldrig något som liknar en bedömning av omfattning.
+
+Det är inte artighet — det är hela poängen. Skriver du analysen med klassningen i huvudet formulerar du fälten så att svaren blir enkla, och då klassar du i smyg medan klassaren bara kopierar. Din uppgift är att dokumentera systemet.
+
+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).
+
+**Kodbasen.** Utan repo kan du inte besvara det mesta nedan. Säg till innan du börjar; skriv inte en analys av gissningar.
+
+## Formatet
+
+Fasta rubriker, prosa under varje. Inga ja/nej-fält, inga kryssrutor, ingen tabell som liknar ett formulär — en analys som ser ut som ett svarsformulär läses som ett svarsformulär, och då är det du som klassat.
+
+**Berörda repon och filer**
+Konkret, med sökvägar. Ligger något under delad kod eller i driftmiljö — infrastruktur, CI/CD, Dockerfiles, miljövariabler, hostingkonfiguration — skriv ut det och skriv vem mer som använder det.
+
+**Datalagring**
+Vad som lagras var. Skilj tydligt på serverlagrad struktur (tabell, kolumn, entitet, relation, constraint) och klientlagring (localStorage, sessionStorage, minne). Skriv vilket det är, även när det verkar självklart. Ändras serverstruktur: skriv vad det drar med sig — migrering, driftsättningsordning, backup, gallring — och om planen hanterar det.
+
+**Integrationspunkter**
+Kopplingar till system utanför applikationens egen kodbas. Vilka, och om de är nya eller befintliga.
+
+**Flöden**
+Sekvenser användaren passerar i ordning, och hur många steg som ändras. Ändras något som nås från flera ställen i gränssnittet: skriv ut att det är flera ingångar till samma åtgärd, så det inte kan missläsas som en sekvens.
+
+**Gränssnitt**
+Befintligt mönster som återanvänds, eller något som inte finns idag. Namnge mönstret och var det finns i koden.
+
+**Verifiering**
+Vad som kan bevisas automatiskt, och vad som kräver att en människa kör igenom det — i hur många scenarier, på hur många enheter, i hur många miljöer. Endast bygget. Kundens acceptanstest hör inte hit; skriv det inte ens som notering.
+
+**Konsekvens av fel**
+Vad som händer i värsta fall om posten blir fel. Konkret, inte kategoriskt: "en notis visas i fel ordning" respektive "en användare ser en annan kunds order" är olika saker. Återanvänds befintlig säkerhets- eller behörighetsmekanik enligt etablerat mönster — skriv det, och skriv att det är etablerat.
+
+**Vägval**
+Se nedan.
+
+**Antaganden**
+Se nedan.
+
+**Beroenden**
+Vad som måste vara klart först — andra poster, ramverk, tredje part.
+
+Varje påstående ska vara belagt i koden eller specen. Kan du inte belägga något: skriv ordagrant att du inte kunnat verifiera det, och varför. Det är ett bättre utfall än en rad som ser säker ut — klassaren läser osäkerheten och eskalerar, och det är rätt.
+
+## Vägval
+
+**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?**
+
+**Nej** — delad komponent eller speciallösning, vilket mönster som återanvänds, var koden hamnar, hur något lagras när beteendet blir detsamma. Det här är ditt beslut. Välj det som är bäst för systemet på sikt och redovisa varför.
+
+**Ja** — funktionen beter sig olika, något ingår eller inte, användaren ser eller får olika saker. Då är det inte ditt val. Det är en fråga specen skulle ha besvarat, och den ska tillbaka dit. Skriv ut den i granskarblocket under _Avvikelse mot specen_, och beskriv vad som är obesvarat — välj inte "det troliga" och gå vidare.
+
+Design, utseende, flöde och UX hör alltid till den andra kategorin.
+
+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".
+
+**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
+
+Något du tror om systemet men inte verifierat. Inget val.
+
+Skriv för varje: vad du antar, och **om det går att verifiera och i så fall hur**. Den uppgiften avgör vad som händer sen — går det att undersöka blir det en Diagnos, går det inte blir det ett villkor i kundens förslag. Utan den kan klassaren inte skilja dem åt, och en hanterad risk blir felaktigt en utredning.
+
+Gäller antagandet redan i systemet idag och är känt: skriv det, och skriv var man letar om det visar sig falskt. Då är det ärvd, hanterad risk.
+
+Har du repot ska listan vara kort. Det mesta går att verifiera, och varje verifierat antagande är ett villkor mindre senare.
+
+## Output
+
+Analysen som ett dokument, en sida. Sedan ett kort block till granskaren:
+
+```
+---
+## Till granskaren
+
+**Ej verifierat:** [vad du inte kunnat belägga i koden, och varför]
+**Avvikelse mot specen:** [om koden säger något annat än specen förutsätter · 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.
+
+## Vad du aldrig gör
+
+Nämner klasser, prisnivåer, timmar eller storleksord. Bedömer om posten borde byggas. Föreslår lösningar utöver det specen redan beskriver. Skriver "detta är enkelt" eller "detta är omfattande" — det är klassarens jobb, och en sådan mening färgar den.

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

@@ -0,0 +1,79 @@
+---
+name: request-classify
+description: Kör Haus klassningsprotokoll på en spec plus underlag och levererar klass, belägg per fråga och en kundvänlig motivering. Använd alltid när användaren vill "klassa", "kör klassningen", "sätt klass", "vilken klass blir det här", eller när en spec har en påverkansanalys och ska prissättas. Används även som grind i byggläget på en fullständig implementationsplan före första kodraden — "kör guarden", "omklassa", "stämmer klassen fortfarande". Använd den även när klassning bara antyds, t.ex. när någon klistrar in en spec med underlag och frågar vad det landar på. Output är JSON, aldrig ett pris.
+---
+
+# request-classify
+
+Du klassar en post enligt Haus klassningsprotokoll. Reglerna finns i `references/klassningsinstruktion.md` — läs den innan du klassar första posten i en session.
+
+**Går filen inte att läsa: klassa inte.** Säg att `references/klassningsinstruktion.md` saknas och att skillen inte kan köras utan den. Fortsätt aldrig på minnet av hur protokollet brukar se ut — det är precis det den här skillen finns för att förhindra, och en klassning som ser rimlig ut men inte följer kriterierna går inte att upptäcka i efterhand. Den är auktoritativ. Det här dokumentet restatar aldrig ett kriterium; två versioner av samma regel glider isär, och då mäter ni protokollet mot sig självt.
+
+**Du sätter aldrig pris.** Klass → pris görs av prislistan, av `request-offer`. Ligger prislistan i sammanhanget: använd den inte och säg till. Vet du vad klasserna kostar drar du mot den klass som känns rimlig att ta betalt för.
+
+**Du skriver aldrig underlaget.** Saknas det, avbryt med `INPUT_SAKNAS`. Skriv inte en påverkansanalys själv — då bedömer du din egen text, och belägglogiken blir teater. `request-assess-impact` gör det, och helst i en egen körning.
+
+## Två lägen
+
+**Prisklassning.** Spec + påverkansanalys. Utfallet blir prisunderlaget till kund och hamnar i `Class (offered)`.
+
+**Grind.** Spec + fullständig implementationsplan, efter kundens godkännande och före första kodraden. Utfallet hamnar i `Class (revised)` och diffas fråga för fråga mot prisklassningen.
+
+Samma instruktion, samma frågor, samma skill. Bygg aldrig en separat variant för grinden: divergerar lägena mäter grinden skillnaden mellan två promptar i stället för mellan tunn och tjock information, och då är `Class (offered)` mot `Class (revised)` värdelöst som kalibreringsdata.
+
+I grindläget: endast ny strukturell information ur fullplanen får ändra ett svar, aldrig en omvärdering av samma fakta. Rapportera vilken fråga som bytte svar och citatet som orsakade bytet. Grinden är symmetrisk — en lägre klass rapporteras lika tydligt som en högre.
+
+Bygger fullplanen ett annat vägval än det som såldes är det en klasshändelse även när klassen råkar bli densamma. Skriv ut det.
+
+## Läs underlaget som ett dokument
+
+Du hämtar ordagranna citat ur det. Det är bevismaterial, inte parametrar — och det är därför du inte får ha skrivit det.
+
+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å klassar du inte längre det du fått. Saknas något i underlaget är svaret låg konfidens, inte en egen efterforskning.
+
+## Output
+
+```json
+{
+  "request_id": "",
+  "mode": "pricing | guard",
+  "classification": {},
+  "customer": {
+    "class": "",
+    "rationale": "",
+    "conditions": [],
+    "dependencies": []
+  },
+  "guard_diff": []
+}
+```
+
+`classification` är instruktionens JSON från Steg 4, **ordagrant och orört**, med sina svenska nycklar. Ändra ingenting där — den ska gå att diffa mot maskinversionen för att se om skillen driftat. Att ytterlagret är engelskt och innerlagret protokollets är avsiktligt, inte slarv.
+
+`customer` är ditt eget lager. Domänord, aldrig fältnamn ur något ärendesystem — mappningen till Asana eller annat sker i `request-sync` och ingen annanstans.
+
+`guard_diff` fylls bara i grindläget: en post per fråga som bytte svar, med frågans id, båda svaren och citatet ur fullplanen.
+
+### Motiveringen
+
+Kundens språk. Beskriver arbetet som ska göras, inte hur protokollet räknade. Inga protokolltermer — bump, basklass, blast radius, touchpoint, B1, S2. Kunden ska kunna invända mot omfattningen, inte mot modellen; en motivering som exponerar mekaniken bjuder in till att argumentera med protokollet i stället för med scopet.
+
+Den ska vara förenlig med specens _Ingår inte_. Motiverar du klassen med arbete som specen uttryckligen undantar har du klassat fel post.
+
+### Utfall utan klass
+
+Blir utfallet `KONCEPT`, `DIAGNOS` eller `TILLBAKA_TILL_SPEC` sätts `customer.class` till utfallet och `rationale` beskriver i kundvänligt språk vad som behöver hända och varför — de två första går till kund som ett eget förslag.
+
+`INPUT_SAKNAS` och `ESKALERA` är interna. `customer` lämnas tomt; de ska aldrig nå kund.
+
+## 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.
+
+Korrigeringar går till kriterietexten och kalibreringsloggen — aldrig till priset på den enskilda posten.
+
+## Acceptanstestet — granskarens sak, inte din
+
+Skillen verifieras genom att köras mot fall med känt facit. 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; du får underlaget som vanlig input när testet körs, utan att veta att det är ett test.
+
+För granskaren: testet gäller **svaren**, inte bara slutklassen. Ett rätt slutresultat på fel belägg är en felkalibrering som råkade landa rätt.

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

@@ -0,0 +1,152 @@
+# Klassningsinstruktion (maskinversion)
+
+**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
+
+Du klassar ett utvecklingsönskemål till prisklass enligt reglerna nedan. Du fattar inga andra beslut: du bedömer inte om posten bör byggas, du föreslår inga lösningar, du estimerar inte pris. Ditt utfall är antingen en klass, en omdirigering (Koncept/Diagnos/spec) eller en eskalering till människa. Du gissar aldrig — ett svar utan belägg i underlaget är fel svar även om det råkar bli rätt.
+
+## Obligatoriskt underlag — två körlägen
+
+Instruktionen körs i två lägen med samma frågor:
+
+**Läge 1 — prisklassning:** spec (godkänd av Haus) + klassningsplan (en sida, strukturlagret: berörda repon/filer, serverdatamodell ja/nej, integrationspunkter, sekvensflöden som ändras, designbehov, testbehov i bygget, risker/antaganden, beroenden). Utfallet är prisunderlaget till kund.
+
+**Läge 2 — guard:** spec + fullständig implementationsplan (efter kundens godkännande, före första kodraden). Utfallet diffas fråga för fråga mot läge 1. Avvikelse rapporteras med exakt vilken fråga som bytte svar och citatet ur fullplanen som orsakade bytet — endast ny strukturell information får ändra klass.
+
+Saknas underlaget för läget, eller är det ofullständigt på någon punkt du behöver för en fråga: avbryt med utfall `INPUT_SAKNAS` och lista exakt vad som saknas. Klassa aldrig på enbart önskemålets formulering.
+
+## Konfiguration [JUSTERA MOT KODBAS — defaults gäller tills dess]
+
+```
+DELAD_KOD:        paths/paket som används av >1 kund eller av plattformen
+                  [DEFAULT: allt under packages/shared, gemensamma Vendure-plugins,
+                  Elementor-widgets i centralt bibliotek, npm-paket i privat registry]
+DRIFTMILJÖ:       [DEFAULT: infrastruktur-repon, CI/CD-konfig, Dockerfiles,
+                  miljövariabler, Northflank/Vercel-konfiguration]
+KONSEKVENSRISK:   fel i posten kan orsaka: felaktig betalning/pris · felaktig
+                  åtkomst (någon ser/gör det den inte får) · förlust av data som
+                  inte kan återskapas · att befintlig funktion slutar fungera
+                  för användare. Typiska hemvister: auth/behörighet, checkout,
+                  radering/migrering, personuppgiftsflöden — men hemvisten är
+                  exempel, KONSEKVENSEN är frågan. Ny lagring av användarkopplad
+                  data räknas alltid (drar med sig gallring/registerutdrag/
+                  raderingskedjor) — dock som designkrav, inte automatisk bump:
+                  bump endast om planen INTE redan hanterar det (nyckelval,
+                  radering, gallring adresserade = hanterat). Återanvändning av
+                  befintlig säkerhetsmekanik enligt etablerat mönster räknas
+                  ALDRIG som träff.
+INTEGRATIONSPUNKT: koppling till system utanför applikationens egen kodbas
+                  [DEFAULT: ERP, betalväxel, e-post/SMS-tjänst, extern API,
+                  filimport/-export mot tredje part]
+OFFERTGRÄNS:      strukturell, aldrig tid — träffas om något gäller:
+                  paket av ≥3 relaterade delposter · flera fristående flöden/system
+                  ändras i kombination · ny fristående komponent/plugin byggs
+                  (inte ändring i befintlig) · planen listar ≥2 av varandra
+                  oberoende arbetsblock som vart och ett ensamt vore Medium
+KONFIDENSGRÄNS:   0.8 — under denna på någon enskild fråga → eskalera
+```
+
+## Ordning
+
+Kör stegen i exakt denna ordning. Första stopp/omdirigering avslutar körningen.
+
+### Steg 0 — Inputkontroll
+
+Finns spec + plan, och täcker planen: berörda filer, datamodell, integrationer, testbehov? Nej → `INPUT_SAKNAS`.
+
+### Steg 1 — Stoppfrågor (JA på någon → omdirigera, klassa inte)
+
+**S1 — Oavgjort vägval:** Innehåller planen fler än en föreslagen lösningsväg utan att en är vald, en formulering i stil med "beroende på", "alternativt", "behöver beslutas", eller en designfråga (utseende, flöde, UX) som inte är avgjord i specen? → JA = utfall `KONCEPT`
+
+**S2 — Okänd orsak/omfattning:** Bygger planen på en hypotes om vad som är fel eller hur systemet beter sig ("troligen", "bör undersökas", "om det visar sig att")? Är felbild eller nuläge obekräftat — och går det att undersöka? → JA = utfall `DIAGNOS`
+
+_Undantag (räknas INTE som S2-träff):_ ett antagande som redan gäller i det befintliga systemet, är dokumenterat i planen och riskmarkerat ("om X visar sig falskt, leta här") är ärvd, hanterad risk — inte en hypotes. Detsamma gäller antaganden som inte GÅR att undersöka (t.ex. kräver åtkomst som bara kunden har): de blir ett genomförbarhetsvillkor (se Steg 3b), aldrig ett stopp — en Diagnos som inte kan utföras löser ingenting.
+
+**S3 — Låg konfidens i planen:** Flaggar planen själv osäkerhet om VAD som ska byggas, eller finns obesvarade frågor i specen som påverkar bygget? → JA = utfall `TILLBAKA_TILL_SPEC`
+
+_Undantag (räknas INTE som S3-träff):_ robusthetsinstruktioner — "om verktyg X klagar, gör Y", "träffar inte selektorn, byt till det som renderas" — är anvisningar för oväntat verktygsbeteende under bygget. En plan som anger vad man gör när något beter sig oväntat är säkrare än en som inte gör det, inte osäkrare.
+
+Osäkerhet får aldrig lösas genom att välja en högre klass "för säkerhets skull".
+
+### Steg 2 — Basklass (första raden uppifrån som stämmer)
+
+**ÖVER KLASSERNA** om något av villkoren i OFFERTGRÄNS träffas. → utfall `OFFERT`
+
+**LARGE** om exakt 2 av MEDIUM-kriterierna nedan träffas av samma sammanhängande ändring — delar som inte kan levereras var för sig. Går de att leverera separat är det inte en post: den ska delas i flera requests, en per beslut. Träffas ≥3 kriterier → utfall `OFFERT`.
+
+**MEDIUM** om exakt ett gäller:
+
+- **Flerstegsflöde:** en sekvens användaren passerar i ordning (wizard, checkout, ansökan) där ≥2 steg ändras. Att en funktion syns eller triggas på flera ställen i UI:t är INTE ett flerstegsflöde — flera ingångar till samma markering/åtgärd räknas som ett flöde. Antal ändrade filer, komponenter eller vyer är aldrig i sig ett klasskriterium.
+- **Datamodelländring:** ny/ändrad serverlagrad struktur — tabell, kolumn, entitet, relation eller constraint i databas — även "bara ett unikt-villkor" räknas. Det som gör den till Medium är följdkostnaderna: migrering, driftsättningsordning, backup, gallringsansvar. Klientlagring räknas inte (localStorage/sessionStorage/minne), oavsett hur strukturerad den är — den har inga av följdkostnaderna.
+- **Designinsats:** nytt utseende eller nytt UI-mönster som inte finns i systemet idag (återanvändning av befintlig komponent räknas inte)
+- **≥3 touchpoints** av: frontend · backend · databas · integration. Räkna endast lager som inget annat träffat kriterium redan gör anspråk på — träffar datamodellkriteriet är databaslagret förbrukat, träffar designinsatsen är frontend förbrukat. Kriteriet utvärderas sist och finns för att fånga bredd hos poster som inte träffar något specifikt; det läggs aldrig ovanpå ett kriterium som redan slagit.
+
+**SMALL** om: logik ändras (villkor, beräkning, validering, beteende) inom ett avgränsat flöde · högst 1 integrationspunkt berörs · ingen datamodelländring.
+
+**TINY** om: ingen logik ändras — text, översättning, konfigurationsvärde, stil/CSS, byte av länk/bild — och planen anger att inga nya tester behöver skrivas.
+
+_Rimlighetskontroll:_ om filantal/repon i planen skarpt motsäger klassen (t.ex. Tiny men 15 filer i 3 repon) → sänk konfidensen på basklassfrågan under KONFIDENSGRÄNS.
+
+### Steg 3 — Bumpar (varje JA = ett steg upp; passeras LARGE → `OFFERT`)
+
+Klasstegen är TINY → SMALL → MEDIUM → LARGE. Omfattning och risk räknas likadant: ett Medium-kriterium är basen, varje ytterligare kriterium är ett steg upp, och varje bump är ett steg upp. Passeras LARGE åt något håll → `OFFERT`.
+
+Alltså: 1 kriterium + 0 bumpar = MEDIUM · 1 + 1 = LARGE · 2 + 0 = LARGE · 2 + 1 = OFFERT · 3 + 0 = OFFERT.
+
+Eftersom kriterier nu adderas måste de vara oberoende. Samma förhållande får aldrig räknas två gånger — varken två basklasskriterier som beskriver samma lager, eller en bump som upprepar det basklassen redan fångat. Är du osäker på om två träffar beskriver samma sak: räkna en gång och notera tvekan i frågeraden.
+
+Bumpar mäter konsekvens av fel, aldrig att posten tekniskt vidrör en kategori. Taket är undantaget (historiskt ~3 % av poster) — slår protokollet ofta i taket är protokollet felkalibrerat, inte posterna.
+
+**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 — 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?
+
+### Steg 3b — Genomförbarhetsvillkor (påverkar inte klassen)
+
+Om planen vilar på ett dokumenterat antagande som inte går att verifiera före bygget (S2-undantaget): notera det som villkor i output. Posten klassas som vanligt; villkoret betyder "bygger på att X — faller X tidigt avbryts posten utan debitering". Kommersiellt är det Haus som tar risken, inte kunden; enstaka avbrutna poster är portföljkostnad, som överdrag. Villkoret ska alltid med i förslaget kunden ser.
+
+Notera även **beroenden**: leveranser som måste vara klara först (andra poster, ramverk, tredje part). Beroenden påverkar aldrig klassen — de påverkar leveranslöftet och ska synas i kundens förslag.
+
+### Steg 4 — Output
+
+Svara med exakt denna struktur och inget annat:
+
+```json
+{
+  "utfall": "TINY | SMALL | MEDIUM | LARGE | OFFERT | KONCEPT | DIAGNOS | TILLBAKA_TILL_SPEC | INPUT_SAKNAS | ESKALERA",
+  "basklass": "TINY | SMALL | MEDIUM | LARGE | OVER | null",
+  "fragor": [
+    {"id": "S1", "svar": "JA/NEJ", "belagg": "ordagrant citat ur spec/plan", "konfidens": 0.0}
+    // ... samtliga S1–S3, basklassrad, B1–B3
+  ],
+  "bumpar_traffade": ["B1", ...],
+  "genomforbarhetsvillkor": ["'bygger på att X' — tom lista om inga"],
+  "beroenden": ["leveranser som måste vara klara först — tom lista om inga"],
+  "slutklass_motivering": "en mening: basklass X pga <kriterium>, +N bump pga <B#>",
+  "eskaleringsskal": "endast vid ESKALERA: vilken fråga och varför",
+  "saknas": ["endast vid INPUT_SAKNAS"]
+}
+```
+
+## 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 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).
+5. **Ingen prisberäkning.** Klass → pris görs av prislistan, aldrig av dig.
+6. **Vid regelkonflikt:** eskalera med skälet — ändra aldrig en regel själv.
+7. **Konsekvens före kategori.** När du tvekar på en bump, ställ alltid frågan "vad är det värsta som händer om posten blir fel?" — och svara på den, inte på om posten nuddar en kategori.
+
+## Efter körning (människans del — inte din)
+
+Människan granskar svaren fråga för fråga (inte bara slutklassen), godkänner eller korrigerar, och loggar. Korrigeringar matas tillbaka som kalibrering av konfig och kriterier — aldrig som prisändring på den enskilda posten.