@haus-tech/haus-workflow 4.0.1 → 4.2.0

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

@@ -29,7 +29,7 @@ repo's files. The short legacy aliases still work but the names below are canoni
 | `project:reinit` (`reinit`, `re-init`)                            | _Reinit procedure below_        | project | **Full re-setup.** Removes all haus-managed project files (backed up first, user content preserved), then re-runs `project:init` from scratch                                                                                                                                             |
 | `project:clone [name]` (`clone`)                                  | _Clone procedure below_         | project | With a `name`: find & clone one repo by name from GitHub. No name: asks single-repo-vs-workspace first, then either mode — workspace mode clones from `repos.manifest.json`                                                                                                               |
 | `project:cloneandsetup [name]` (`cloneandsetup`)                  | _Clone & setup procedure below_ | project | Run `project:clone`, then set up each repo for local dev — deps, databases, cross-repo links, and env — via each repo's `.haus-workflow/localdev.yml` (+ the workspace's order/links/env)                                                                                                 |
-| `project:new [stack] [name]` (`new`, `create`)                    | _New-project procedure below_   | project | Create a **brand-new** project from an allowed stack (Next.js, Vite+React, NestJS, Expo): scaffold, haus configs, git + GitHub repo, then full init                                                                                                                                       |
+| `project:new [description]` (`new`, `create`)                     | _New-project procedure below_   | project | Create a **brand-new** project from a plain-language request: elicit features, pick the stack (any — registry stacks use the haus new rails), scaffold, git + GitHub repo, full init, then build a walking skeleton — all in one session                                                  |
 | `project:add-skills` (`add-skills`, `opt-in`)                     | _Add-skills procedure below_    | project | Add optional skills, agents, or config (ESLint/Prettier) to an already-set-up project without re-running full setup                                                                                                                                                                       |
 | `project:refresh` (`apply`, `refresh`, `claude-md`, `regenerate`) | _Refresh procedure below_       | project | **Full non-destructive sync.** Updates the haus package + catalog first, then re-runs `project:init`'s pipeline in place — nothing is removed up front; new catalog items get added, changed ones updated, and anything removed upstream gets pruned by `apply`'s existing orphan-pruning |
 | `project:doctor` (`doctor`, `check`)                              | `haus doctor`                   | project | Check for install drift                                                                                                                                                                                                                                                                   |
@@ -57,8 +57,8 @@ Question 1: "What would you like to do?"
 Options:
   1. [project] project:init — add haus to an existing project for the first time
      (AI skills + commands + workflow into a repo you already have, then a deep read to write the CLAUDE.md docs body + docs/)
-  2. [project] project:new [stack] [name] — create a brand-new project from an allowed stack
-     (Next.js, Vite+React, NestJS, Expo — scaffold, haus configs, git + GitHub repo, then full init)
+  2. [project] project:new [description] — create a brand-new project from a plain-language request
+     (elicit features, pick any stack, scaffold, git + GitHub repo, full init, then build a walking skeleton)
   3. [project] project:refresh — full non-destructive sync with the latest haus
      (updates the haus package + catalog, then re-runs setup in place — nothing removed first)
   4. [—] More options — see: project:clone, project:cloneandsetup, project:add-skills, and 7 more
@@ -109,7 +109,7 @@ Run the mapped command via Bash. Quote the exact command you are running before
 
 **Exception — `project:cloneandsetup` (`cloneandsetup`):** clone followed by a per-repo setup pass, with confirmations. Skip to **Clone & setup (`project:cloneandsetup`)** under Step 3 and follow it.
 
-**Exception — `project:new` (`new` / `create`):** collects the stack/name/org/visibility via `AskUserQuestion` and drives `haus new` non-interactively — not a single command. Skip to **New project (`project:new`)** under Step 3 and follow it.
+**Exception — `project:new` (`new` / `create`):** a multi-phase AI-driven procedure — elicits the request via `AskUserQuestion`, picks the stack itself, scaffolds (registry rails or a user-confirmed official scaffolder), then builds a walking skeleton. Skip to **New project (`project:new`)** under Step 3 and follow it.
 
 **Exception — `project:add-skills` (`add-skills` / `opt-in`):** a short scan → recommend → choose → apply procedure. Skip to **Add optional skills (`project:add-skills`)** under Step 3 and follow it.
 
@@ -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 lists allowed stacks via `haus new --list --json`, collects the stack/name/org/visibility with `AskUserQuestion`, previews with `--dry-run`, confirms, then runs `haus new <stack> <name> --json --yes [flags]` for real and narrates the JSON result — including relaying any failure `detail` (resume commands) verbatim and surfacing `installHint`. 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, and verify (build + lint + tests + smoke boot). Failure `detail` is relayed verbatim and nothing is ever auto-deleted. Never run bare interactive `haus new`.
 
 ### Add optional skills (`project:add-skills`)
 

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

@@ -1,24 +1,117 @@
-# project:new — create a new project from an allowed stack
-
-Drives `haus new` non-interactively. NEVER run bare `haus new` without flags —
-its interactive prompts don't work through the agent; collect answers with
-AskUserQuestion and pass everything as flags.
-
-1. **List stacks.** Run `haus new --list --json`. Present the stacks via
-   AskUserQuestion (one option per stack, id + title).
-2. **Collect inputs.** Ask for: project name (free text; lowercase letters, digits,
-   `. _ -`), GitHub org (default: WeAreHausTech; "personal" = omit --org),
-   visibility (private default / public), and whether to create the GitHub
-   repo at all (default yes; no → add `--no-github`).
-3. **Preview.** Run
+# project:new — create a new project (AI-driven)
+
+You own the decisions (stack, features, code); `haus` owns the rails (git/GitHub
+mechanics, safety gates, context install). The registry is the fast path, not a
+boundary — any stack this machine can scaffold works. The full flow runs in THIS
+session, from request to running app.
+
+NEVER run bare `haus new` without flags — its interactive prompts don't work through
+the agent; collect answers with AskUserQuestion and pass everything as flags.
+
+## Phase 0 — Entry
+
+A description argument ("a frontend app for shopping") goes straight to Phase 1.
+No-argument invocation: ask "What do you want to build?" as free text. Do not present
+a stack menu.
+
+## Phase 1 — Elicit (at most 5 AskUserQuestion rounds)
+
+Ask about dimensions, never from a domain template:
+
+1. Purpose — only if not given at entry.
+2. Features — propose a domain-typical list for the stated purpose yourself (e.g.
+   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).
+
+Pick the stack yourself from the answers. Confirm the stack with the user only on
+genuine ambiguity (e.g. web vs native unclear).
+
+## Phase 2 — Intent gate
+
+Present: chosen stack + why, selected features, what gets mocked, walking-skeleton
+depth (every feature wired end-to-end but minimal), and that the skeleton will be
+committed to `main` in the new repo and pushed to the remote if one is created. Get
+ONE explicit user OK before anything touches disk — this one approval covers those
+actions.
+
+## Phase 3 — Scaffold
+
+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]`
-   and show the user the planned steps in plain language. Confirm before executing.
-4. **Execute.** Re-run the same command without `--dry-run`. Parse the JSON:
-   - `ok: true` → summarize: project path, repo URL, init result, and the
-     `installHint` (dependencies are NOT installed automatically).
-   - `ok: false` → report the failed step's `detail` verbatim — it contains the
-     exact resume commands (e.g. `gh repo create … && git push -u origin main`).
-     Do NOT retry destructively; the project directory is never auto-deleted.
-5. **Hand off.** Tell the user to `cd <name>` and run the install command from
-   `installHint` — the project is fully initialized (no separate `project:init`
-   needed).
+   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:
+   - `ok: true` → note project path, repo URL, and `installHint`.
+   - `ok: false` → report the failed step's `detail` verbatim — it contains the exact
+     resume commands. Do NOT retry destructively; the project directory is never
+     auto-deleted.
+
+**Stack not in the registry:**
+
+1. Toolchain preflight: check the binaries the scaffolder needs actually exist;
+   report anything missing instead of failing mid-flow.
+2. Show the exact official-scaffolder command; the user confirms; execute it.
+3. Manual rails: `git init` (if the scaffolder didn't), `git branch -M main`, initial
+   commit; then `gh repo create` (confirm first) unless the user declined a repo.
+
+## Phase 4 — Context install
+
+Everything from here on runs inside the new project directory — `cd` into it first and
+stay there.
+
+- Fast path: the chained `haus init` inside `haus new` already ran — go to seeding.
+- 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,
+    not merely an unknown stack (catalog defaults normally still match, so most tier-3
+    projects write fine without `--force`) — tell the user plainly: "no stack-specific
+    assets in the catalog; installing workflow defaults." Confirm with the user, then
+    re-run `haus init --json --dry-run --force`.
+  - Write: run `haus apply --write`.
+  - Guard: NEVER run write-mode `haus init` (i.e. `haus init` without `--json
+--dry-run`) — it prompts for confirmation, and an agent's non-answer means nothing
+    is written despite exit 0.
+- Seeding: write the elicited requirements into the project as `docs/SPEC.md`
+  (purpose, features, auth/data choices, what is mocked) and
+  `docs/plans/walking-skeleton.md` (one task per selected feature with acceptance
+  criteria and a verify command).
+
+## Phase 5 — Build the walking skeleton
+
+1. Install dependencies: run the install command for the chosen package manager (fast
+   path: the `installHint` from the JSON — it does not exist off-registry). The test
+   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
+   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.
+
+   Committing to `main` is a deliberate, narrow exception to the NEVER-work-on-main
+   rule: it applies only to a freshly created single-author repo during this initial
+   walking-skeleton build; standard branch rules apply afterwards.
+
+## Phase 6 — Verify + hand off
+
+1. Gate: build passes, lint passes, tests green, dev server boots (smoke check).
+   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.
+
+## Failure rules
+
+- Relay `haus` failure `detail` verbatim; never retry destructively; the project
+  directory is never auto-deleted — the same rules apply on the manual path.
+- 3 failed verifications on one build task → stop and ask the user.

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

@@ -0,0 +1,97 @@
+---
+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.
+
+## 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
+
+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.
+
+Två sorter får du inte ta:
+
+**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.
+
+**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.
+
+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 lagrar X i Y eftersom Z", inte "X kan lagras i Y eller Z".
+
+## 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]
+**Ö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]
+```
+
+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,86 @@
+---
+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": "",
+    "tradeoffs": [],
+    "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.
+
+### Ö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.
+
+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,146 @@
+# 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.
+
+## 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 — 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.
+
+**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 gäller endast byggets verifieringssteg; 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.