@haus-tech/haus-workflow 4.1.0 → 4.2.0

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## [4.2.0](https://github.com/WeAreHausTech/haus-workflow/compare/v4.1.0...v4.2.0) (2026-08-21)
+
+### Features
+
+- **install:** bundle request-pipeline and slack-cowork global skills ([#332](https://github.com/WeAreHausTech/haus-workflow/issues/332)) ([1978b5d](https://github.com/WeAreHausTech/haus-workflow/commit/1978b5d2cb5098a8c87e9db7148633ebef5b4c33))
+
+### Bug Fixes
+
+- haus new empty-cache flag and setupOk signal ([#333](https://github.com/WeAreHausTech/haus-workflow/issues/333)) ([5a9004a](https://github.com/WeAreHausTech/haus-workflow/commit/5a9004ae23d7189d5645dc7e830e3b4cbb420203)), closes [#329](https://github.com/WeAreHausTech/haus-workflow/issues/329) [#330](https://github.com/WeAreHausTech/haus-workflow/issues/330)
+
 ## [4.1.0](https://github.com/WeAreHausTech/haus-workflow/compare/v4.0.1...v4.1.0) (2026-08-21)
 
 ### Features

package/README.md

@@ -138,13 +138,16 @@ waiting on timeouts (catalog sync, npm version check, workflow-template fetch, l
 reference fetch, global-plugin install; the read-only local plugin probe still runs — see
 [docs/cli.md](docs/cli.md) → `--offline` for why). It never changes what gets installed.
 
-The honest-shortfall reporting covers `haus apply`, `haus init`, and `haus workspace
-setup` (issue #325 extended `apply`'s original ADR-0060 gate to the other two): a run
-that cannot install everything it wanted reports `K of N catalog items installed` and
-exits 1 if it installed none, unless `--allow-empty-cache` opts into writing core files
-anyway (still exits 1 having installed nothing). `workspace setup` reports this per
-member repo — a repo that installed zero catalog items is recorded `failed`, not `ok`.
-See [docs/cli.md](docs/cli.md) for each command's exact flags and behaviour.
+The honest-shortfall reporting covers `haus apply`, `haus init`, `haus new`, and
+`haus workspace setup` (issue #325 extended `apply`'s original ADR-0060 gate to `init`
+and `workspace setup`; issue #329 threaded the same `--allow-empty-cache` flag through
+`haus new`): a run that cannot install everything it wanted reports `K of N catalog
+items installed` and exits 1 if it installed none, unless `--allow-empty-cache` opts
+into writing core files anyway (still exits 1 having installed nothing). `workspace
+setup` reports this per member repo — a repo that installed zero catalog items, hit
+the zero-signal guard, or was refused for an unsupported catalog format is recorded
+`failed`, not `ok` (issue #330). See [docs/cli.md](docs/cli.md) for each command's
+exact flags and behaviour.
 
 ## Internal docs
 

package/dist/cli.js

@@ -10585,8 +10585,10 @@ async function runSetupCore(root, opts) {
       hooksOk: false,
       written: [],
       // Pre-existing zero-signal guard, not the #325 catalog-install honesty check —
-      // deliberately left out of scope for `catalogInstallOk` (see its doc comment).
-      catalogInstallOk: true
+      // `catalogInstallOk` stays true; `setupOk` is false so workspace setup cannot
+      // record this repo as ok (issue #330).
+      catalogInstallOk: true,
+      setupOk: false
     };
   }
   await writeJson(hausPath(root, "recommendation.json"), recommendation);
@@ -10616,7 +10618,8 @@ async function runSetupCore(root, opts) {
     warnings: warningLines,
     hooksOk,
     written: [],
-    catalogInstallOk: true
+    catalogInstallOk: true,
+    setupOk: true
   };
   const envelope = (hooksResult) => ({
     scan: scanResult,
@@ -10645,7 +10648,7 @@ async function runSetupCore(root, opts) {
       error(sync.formatRefusal);
       process.exitCode = 1;
       emitJsonEnvelope(json, quiet, envelope(hooks));
-      return baseResult;
+      return { ...baseResult, setupOk: false };
     }
     if (sync.newItems.length > 0) {
       say(`Catalog cache populated: ${sync.newItems.length} new item(s).`);
@@ -10680,7 +10683,7 @@ async function runSetupCore(root, opts) {
           error(message2);
           process.exitCode = 1;
           emitJsonEnvelope(json, quiet, envelope(hooks));
-          return { ...baseResult, catalogInstallOk: false };
+          return { ...baseResult, catalogInstallOk: false, setupOk: false };
         }
       } else {
         warn(
@@ -10727,7 +10730,13 @@ async function runSetupCore(root, opts) {
     say(`- HOOKS OK: ${hooksAfter.message}`);
   }
   emitJsonEnvelope(json, quiet, envelope(hooksAfter));
-  return { ...baseResult, hooksOk: hooksOkAfter, written: files, catalogInstallOk };
+  return {
+    ...baseResult,
+    hooksOk: hooksOkAfter,
+    written: files,
+    catalogInstallOk,
+    setupOk: catalogInstallOk
+  };
 }
 
 // src/commands/init.ts
@@ -11153,13 +11162,15 @@ async function createProject(opts, deps = defaultDeps) {
     phase = "init";
     if (!opts.json) log("\u25B6 init: haus setup pipeline");
     const exitCodeBeforeSetup = process.exitCode;
+    let setupResult;
     try {
-      await deps.setup(projectPath, {
+      setupResult = await deps.setup(projectPath, {
         json: false,
         apply: true,
         dryRun: false,
         quiet: opts.json,
-        confirm: opts.yes ? async () => true : () => confirm("Approve and write Claude files now?")
+        confirm: opts.yes ? async () => true : () => confirm("Approve and write Claude files now?"),
+        allowEmptyCache: opts.allowEmptyCache
       });
     } catch (err) {
       steps.push({
@@ -11169,15 +11180,26 @@ async function createProject(opts, deps = defaultDeps) {
       });
       return { ok: false, projectPath, repoUrl, installHint, steps };
     }
+    const catalogInstallRefused = setupResult?.catalogInstallOk === false;
+    const retryCmd = catalogInstallRefused ? `cd ${opts.name} && haus init --allow-empty-cache` : `cd ${opts.name} && haus init`;
     if (process.exitCode === 1 && exitCodeBeforeSetup !== 1) {
-      steps.push({
-        step: "init",
-        status: "failed",
-        detail: `haus init reported failure. Project and repo are intact \u2014 cd ${opts.name} && haus init to retry.`
-      });
-      return { ok: false, projectPath, repoUrl, installHint, steps };
+      if (opts.allowEmptyCache && catalogInstallRefused) {
+        steps.push({
+          step: "init",
+          status: "done",
+          detail: "core files written; catalog items skipped (--allow-empty-cache)"
+        });
+      } else {
+        steps.push({
+          step: "init",
+          status: "failed",
+          detail: `haus init reported failure. Project and repo are intact \u2014 ${retryCmd} to retry.`
+        });
+        return { ok: false, projectPath, repoUrl, installHint, steps };
+      }
+    } else {
+      steps.push({ step: "init", status: "done" });
     }
-    steps.push({ step: "init", status: "done" });
     phase = "overlay";
     if (!opts.json) log("\u25B6 overlay: haus config items");
     let overlay;
@@ -11264,7 +11286,7 @@ async function createProject(opts, deps = defaultDeps) {
   }
   if (!opts.json) log(`\u2713 Created ${projectPath}${repoUrl ? ` \u2192 ${repoUrl}` : ""}
   ${installHint}`);
-  return { ok: true, projectPath, repoUrl, installHint, steps };
+  return { ok: process.exitCode !== 1, projectPath, repoUrl, installHint, steps };
 }
 
 // src/commands/new.ts
@@ -11297,7 +11319,8 @@ function resolveNewOptions(stackArg, nameArg, flags, parentDir) {
       pm,
       yes: flags.yes === true,
       dryRun,
-      json: flags.json === true
+      json: flags.json === true,
+      allowEmptyCache: flags.allowEmptyCache === true
     }
   };
 }
@@ -14232,8 +14255,8 @@ async function runWorkspaceSetup(workspaceRoot, options = {}) {
       error(`Setup failed for ${repo.name}: ${message2}`);
       continue;
     }
-    if (!res.catalogInstallOk) {
-      const message2 = "No catalog items were installed for this repo (zero installable content) \u2014 see the per-repo output above, or re-run with --allow-empty-cache.";
+    if (!res.setupOk) {
+      const message2 = !res.catalogInstallOk ? "No catalog items were installed for this repo (zero installable content) \u2014 see the per-repo output above, or re-run with --allow-empty-cache." : "Setup wrote nothing for this repo \u2014 see the per-repo output above.";
       statuses.push({
         name: repo.name,
         path: repo.path,
@@ -14769,7 +14792,10 @@ program.command("init").description("Full setup: scan, recommend, and optionally
   "--allow-empty-cache",
   "Proceed when no catalog item has installable content: write core files and skip the catalog items. Still exits 1 if none installed (ADR-0060)"
 ).action(runInit);
-program.command("new").description("Create a new project from an allowed Haus stack, push it to GitHub, and run init").argument("[stack]", "Stack id (omit to pick interactively; see --list)").argument("[name]", "Project directory and repo name").option("--list", "Print the allowed stacks and exit").option("--org <org>", "GitHub org to create the repo in (default: personal account)").option("--public", "Create the GitHub repo public").option("--private", "Create the GitHub repo private (default)").option("--no-github", "Skip GitHub repo creation and push").option("--pm <pm>", "Package manager: yarn | npm | pnpm", "yarn").option("-y, --yes", "Skip confirmations (non-interactive)").option("--dry-run", "Print the full plan without executing anything").option("--json", "Emit a machine-readable result document").action(runNew);
+program.command("new").description("Create a new project from an allowed Haus stack, push it to GitHub, and run init").argument("[stack]", "Stack id (omit to pick interactively; see --list)").argument("[name]", "Project directory and repo name").option("--list", "Print the allowed stacks and exit").option("--org <org>", "GitHub org to create the repo in (default: personal account)").option("--public", "Create the GitHub repo public").option("--private", "Create the GitHub repo private (default)").option("--no-github", "Skip GitHub repo creation and push").option("--pm <pm>", "Package manager: yarn | npm | pnpm", "yarn").option("-y, --yes", "Skip confirmations (non-interactive)").option("--dry-run", "Print the full plan without executing anything").option("--json", "Emit a machine-readable result document").option(
+  "--allow-empty-cache",
+  "Proceed when no catalog item has installable content: write core files and skip the catalog items. Still exits 1 if none installed (ADR-0060)"
+).action(runNew);
 program.command("clone").description("Clone a single git repository by URL").argument("<url>", "Git URL to clone").argument("[dir]", "Target directory (default: repo name derived from the URL)").option("--dry-run", "Print what would happen without cloning").action(
   (url, dir, opts) => runClone(url, { dir, dryRun: opts.dryRun })
 );

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.