@haus-tech/haus-workflow 4.9.0 → 5.0.1

package/library/global/skills/request/scripts/compare-classifications.mjs

@@ -1,94 +0,0 @@
-/**
- * Deterministisk dubbelkörningsdiff för klassningar (driftvakten på MEDIUM+).
- * Jämför utfall, basklass, varje frågas svar och vilken sida om KONFIDENSGRÄNS
- * (0.8) konfidensen ligger, mellan två oberoende körningar på samma underlag.
- * Prosafält (belägg, motiveringar) jämförs INTE — två korrekta körningar
- * formulerar sig olika, det är svaren som ska vara stabila. Konfidensens SIDA
- * om gränsen är däremot inte prosa: den avgör ESKALERA enligt protokollet.
- *
- * Skriver LIKA (exit 0) eller OLIKA + diffrader (exit 1) på stdout; varningar
- * går på stderr så en verdiktparser aldrig sväljer dem. Vid OLIKA väljer
- * dispatchern ALDRIG en körning och räknar ALDRIG medelvärde — posten
- * eskaleras till granskaren med båda körningarna.
- *
- * Exit 2 = jämförelsen kan inte göras alls (dispatcherns fel, aldrig LIKA) —
- * rälsen bor i lib.mjs och delas med compare-scores.
- *
- * Användning: node compare-classifications.mjs <körning1.json> <körning2.json>
- */
-import { loadRunPair, refDriftWarning, reportDiffs } from './lib.mjs'
-
-// KONFIDENSGRANS speglar klassningsinstruktionen — varna (stderr) vid katalogdrift.
-const REF_SHA = '811f0bff62c749255e86da7ea8db0ea868ebc9df14262f9889101c110d9d14ff'
-{
-  const w = refDriftWarning('request-classify/references/klassningsinstruktion.md', REF_SHA)
-  if (w) console.error(`VARNING: ${w} — kontrollera KONFIDENSGRANS`)
-}
-const KONFIDENSGRANS = 0.8
-
-const { a: docA, b: docB } = loadRunPair(
-  'användning: node compare-classifications.mjs <körning1.json> <körning2.json>',
-)
-const a = docA.classification
-const b = docB.classification
-if (!a || !b) {
-  console.error('minst en fil saknar classification-nyckeln — är båda classify-körningar?')
-  process.exit(2)
-}
-
-// Frågelagret är jämförelsens kärna — utan kompletta, unikt id-satta rader kan
-// en äkta oenighet tyst försvinna. Då vägrar vi hellre än gissar.
-const validateFragor = (rows, label) => {
-  if (!Array.isArray(rows) || rows.length === 0) {
-    console.error(`${label}: fragor saknas eller är tom — kan inte jämföra`)
-    process.exit(2)
-  }
-  const seen = new Set()
-  for (const f of rows) {
-    if (typeof f?.id !== 'string' || f.id.trim() === '') {
-      console.error(`${label}: en frågerad saknar id — kan inte jämföra`)
-      process.exit(2)
-    }
-    if (seen.has(f.id)) {
-      console.error(`${label}: dubblett-id "${f.id}" — kan inte jämföra`)
-      process.exit(2)
-    }
-    seen.add(f.id)
-  }
-}
-validateFragor(a.fragor, 'körning 1')
-validateFragor(b.fragor, 'körning 2')
-
-const show = (v) => JSON.stringify(v ?? null)
-const normSvar = (v) =>
-  String(v ?? '')
-    .trim()
-    .toUpperCase()
-
-const diffs = []
-if (a.utfall !== b.utfall) diffs.push(`utfall: ${show(a.utfall)} ↔ ${show(b.utfall)}`)
-if ((a.basklass ?? null) !== (b.basklass ?? null))
-  diffs.push(`basklass: ${show(a.basklass)} ↔ ${show(b.basklass)}`)
-
-const byId = (rows) => new Map(rows.map((f) => [f.id, f]))
-const mapA = byId(a.fragor)
-const mapB = byId(b.fragor)
-for (const id of new Set([...mapA.keys(), ...mapB.keys()])) {
-  const fa = mapA.get(id)
-  const fb = mapB.get(id)
-  if (!fa || !fb) {
-    // Körningarna stannade på olika steg — samma fakta gav olika väg.
-    diffs.push(`fråga ${id}: besvarad i ${fa ? 'körning 1' : 'körning 2'} men inte i den andra`)
-    continue
-  }
-  if (normSvar(fa.svar) !== normSvar(fb.svar))
-    diffs.push(`fråga ${id}: ${show(fa.svar)} ↔ ${show(fb.svar)}`)
-  const sideA = (fa.konfidens ?? 0) >= KONFIDENSGRANS
-  const sideB = (fb.konfidens ?? 0) >= KONFIDENSGRANS
-  if (sideA !== sideB)
-    diffs.push(
-      `fråga ${id}: konfidens på olika sida om ${KONFIDENSGRANS} (${show(fa.konfidens)} ↔ ${show(fb.konfidens)})`,
-    )
-}
-
-reportDiffs(diffs)

package/library/global/skills/request/scripts/quote-repair.mjs

@@ -1,166 +0,0 @@
-#!/usr/bin/env node
-/**
- * Deterministisk citaträttning FÖRE omdispatch. Pilotsessionerna 2026-08-28
- * visade att classifiern komponerar belägg i stället för att citera (4 av 4
- * förstapass fälldes av contract-check), och varje fällning kostade en full
- * omkörning på 6-9 min. Det här scriptet räddar det räddningsbara: ett citat
- * som inte är exakt substräng ersätts med sin ENTYDIGT närmaste källmening.
- * Ingen entydig träff = ingen rättning (hellre omdispatch än fel belägg), och
- * skrivningen är allt eller inget så en halvrättad fil aldrig arkiveras.
- * En kandidat med annan polaritet än citatet (se NEGATIONER) är aldrig giltig:
- * rättningen får byta form på pekaren, aldrig vända påståendet.
- *
- * Rättar samma fält som contract-check kontrollerar: classification.fragor[].belagg
- * samt citattecken-omgärdade segment (>= 15 tecken) i score-JSON:ens drivers.
- * Bedömer aldrig innehåll; byter aldrig mening, bara formen på pekaren.
- *
- * Användning: node quote-repair.mjs <run.json> <spec.md> [impact.md]
- * Stdout: "RÄTTAT (N):" + rader, "ORÄTTBART (N):" + rader, eller "INGET ATT RÄTTA".
- * Exit 0 = inga orättbara citat kvar (rättade eller inga), 1 = orättbara kvar
- * (filen orörd), 2 = användningsfel/oläsbar input (dispatcherfel).
- */
-import { readFileSync, writeFileSync } from 'node:fs'
-
-import { norm, quoteOk } from './lib.mjs'
-
-const [jsonPath, specPath, impactPath] = process.argv.slice(2)
-if (!jsonPath || !specPath) {
-  console.error('användning: node quote-repair.mjs <run.json> <spec.md> [impact.md]')
-  process.exit(2)
-}
-let doc, sourceRaw
-try {
-  doc = JSON.parse(readFileSync(jsonPath, 'utf8'))
-  sourceRaw =
-    readFileSync(specPath, 'utf8') + '\n' + (impactPath ? readFileSync(impactPath, 'utf8') : '')
-} catch (e) {
-  console.error(`kunde inte läsa input: ${e.message}`)
-  process.exit(2)
-}
-const source = norm(sourceRaw)
-
-// Kandidater: källans meningar (rad- och meningsgränser) plus par av
-// angränsande meningar, så ett tvåmeningscitat kan få en exakt motsvarighet.
-const sentences = sourceRaw
-  .split(/\n+|(?<=[.!?])\s+(?=[A-ZÅÄÖ0-9])/u)
-  .map((s) => s.trim())
-  .filter((s) => norm(s).length >= 15)
-const candidates = [...sentences]
-for (let i = 0; i + 1 < sentences.length; i++)
-  candidates.push(`${sentences[i]} ${sentences[i + 1]}`)
-
-const tokens = (s) =>
-  new Set(
-    norm(s)
-      .toLowerCase()
-      .split(/[^\p{L}\p{N}]+/u)
-      .filter(Boolean),
-  )
-const dice = (A, B) => {
-  let inter = 0
-  for (const t of A) if (B.has(t)) inter++
-  return (2 * inter) / (A.size + B.size || 1)
-}
-
-/**
- * Polaritetsvakt. Dice över tokenmängder är blind för negation: "Ingen" är ett
- * ord av nio, men vänder påståendet. Utan den här listan "rättas" ett belägg som
- * säger att behörighetslogik ÄNDRAS till källmeningen som säger att den INTE
- * ändras, och contract-check släpper igenom det, alltså tvärtemot vad
- * citatgrinden finns för. Ett citat får bara ersättas av en kandidat med exakt
- * samma uppsättning negationsord.
- */
-const NEGATIONER = new Set([
-  'ingen',
-  'inga',
-  'inget',
-  'inte',
-  'icke',
-  'aldrig',
-  'utan',
-  'ej',
-  'saknas',
-  'varken',
-])
-const negationer = (s) => {
-  const found = []
-  for (const t of tokens(s)) if (NEGATIONER.has(t)) found.push(t)
-  return found.sort().join(' ')
-}
-
-// Entydighetskravet är själva säkerhetsregeln: bästa träffen måste vara både
-// nära nog (>= 0.6) och klart ensam (marginal >= 0.15), annars rättas inget.
-// Polaritetsvakten går FÖRE poängsättningen: en kandidat med annan uppsättning
-// negationsord är aldrig en giltig ersättare, hur nära den än ligger i Dice.
-// En par-kandidat som bara är bästa träffen med en angränsande mening bilagd
-// (delsträngsöverlapp åt endera hållet) är samma källplats, inte en
-// konkurrerande: annars slår varannan stark enmeningsträff ut sig själv på
-// marginalkravet så snart en granne delar ett enda vanligt ord.
-const findReplacement = (quote) => {
-  const q = tokens(quote)
-  const pol = negationer(quote)
-  const scored = candidates
-    .filter((c) => negationer(c) === pol)
-    .map((c) => ({ c, s: dice(q, tokens(c)) }))
-    .sort((a, b) => b.s - a.s)
-  const best = scored[0]
-  if (!best || best.s < 0.6) return null
-  const second =
-    scored.find((x) => x.c !== best.c && !x.c.includes(best.c) && !best.c.includes(x.c))?.s ?? 0
-  if (best.s - second >= 0.15 && quoteOk(best.c, source)) return best.c
-  return null
-}
-
-const trunc = (s) => (s.length > 60 ? `${s.slice(0, 60)}…` : s)
-// Citattecken i en ersättning som ska splitsas IN mellan citattecken skulle
-// stänga citatet för tidigt: strängen blir obalanserad och nästa läsning ser ett
-// annat citat än det som godkändes. Sådana kandidater refuseras.
-const CITATTECKEN = /["“”„«»]/
-const repaired = []
-const unfixable = []
-const fixQuote = (val, label, forbidQuoteChars = false) => {
-  if (quoteOk(val, source)) return val
-  const r = findReplacement(val)
-  if (r && !(forbidQuoteChars && CITATTECKEN.test(r))) {
-    repaired.push(`- ${label}: "${trunc(val)}" → "${trunc(r)}"`)
-    return r
-  }
-  unfixable.push(`- ${label}: "${trunc(val)}"`)
-  return val
-}
-
-if (doc.classification && typeof doc.classification === 'object') {
-  for (const f of Array.isArray(doc.classification.fragor) ? doc.classification.fragor : [])
-    if (f && typeof f.belagg === 'string' && norm(f.belagg).length > 0)
-      f.belagg = fixQuote(f.belagg, `fråga ${f.id}`)
-} else if (doc.outcome !== undefined) {
-  // Samma citat-regex som contract-check: raka och typografiska citattecken.
-  const fixInString = (str, label) =>
-    str.replace(
-      /(["“”„«»])([^"“”„«»]{15,})(["“”„«»])/g,
-      (_m, o, inner, c) => o + fixQuote(inner, label, true) + c,
-    )
-  const walk = (v, label) =>
-    typeof v === 'string'
-      ? fixInString(v, label)
-      : Array.isArray(v)
-        ? v.map((x) => walk(x, label))
-        : v && typeof v === 'object'
-          ? Object.fromEntries(Object.entries(v).map(([k, x]) => [k, walk(x, label)]))
-          : v
-  if (Array.isArray(doc.drivers)) doc.drivers = doc.drivers.map((d, i) => walk(d, `drivers[${i}]`))
-}
-
-if (unfixable.length > 0) {
-  console.log(`ORÄTTBART (${unfixable.length}):`)
-  for (const u of unfixable) console.log(u)
-  process.exit(1)
-}
-if (repaired.length > 0) {
-  writeFileSync(jsonPath, JSON.stringify(doc, null, 2) + '\n')
-  console.log(`RÄTTAT (${repaired.length}):`)
-  for (const r of repaired) console.log(r)
-} else {
-  console.log('INGET ATT RÄTTA')
-}
-process.exit(0)

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

@@ -1,79 +0,0 @@
----
-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

@@ -1,152 +0,0 @@
-# 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.