@haus-tech/haus-workflow 5.6.1 → 5.7.0

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

@@ -1,226 +1,240 @@
 ---
 name: request-score
-description: Sätter poäng på en spec plus påverkansanalys genom att jämföra uppdraget mot en skala av sjutton referensuppdrag. Använd alltid när användaren vill "sätt poäng", "poängsätt", "kör poängen", "vad landar det här på", "var på skalan ligger det", eller när en spec har en påverkansanalys och ska prissättas. Används även som grind på en fullständig implementationsplan före första kodraden — "kör guarden", "stämmer poängen fortfarande". Använd den även när poängsättning bara antyds, t.ex. när någon klistrar in en spec med underlag och frågar hur stort det är. Output är JSON med poäng och belägg, aldrig ett pris.
+description: Scores a spec plus impact analysis by comparing the assignment against a scale of seventeen reference assignments. Always use when the user wants "sätt poäng", "poängsätt", "kör poängen", "vad landar det här på", "var på skalan ligger det", or when a spec has an impact analysis and is to be priced. Also used as a gate on a complete implementation plan before the first line of code: "kör guarden", "stämmer poängen fortfarande". Use it even when scoring is only implied, e.g. when someone pastes a spec with source material and asks how big it is. Output is JSON with a score and evidence, never a price.
 ---
 
 # request-score
 
-Du sätter poäng på en post genom att jämföra den mot referensuppdragen i
-`references/poangskala.md`. Läs skalan innan du poängsätter första posten i en session.
+You score an item by comparing it against the reference assignments in
+`references/poangskala.md`. Read the scale before you score the first item in a session.
 
-**Går filen inte att läsa: poängsätt inte.** Säg att `references/poangskala.md` saknas
-och att skillen inte kan köras utan den. Sätt aldrig en poäng på minnet av hur skalan
-brukar se ut. Skalan ändras när nya referensuppdrag läggs till, och en poäng satt på
-en gammal skala ser likadan ut som en satt på rätt skala.
+**If the file cannot be read: do not score.** Say that `references/poangskala.md` is missing
+and that the skill cannot run without it. Never set a score from memory of what the scale
+usually looks like. The scale changes when new reference assignments are added, and a score
+set on an old scale looks the same as one set on the right scale.
 
-**Du sätter aldrig pris.** Poäng blir pris genom en fast processavgift plus poängen
-gånger en konverteringsfaktor, och det räknas någon annanstans. Ligger prislistan i
-sammanhanget: använd den inte och säg till. Vet du vad poängen kostar drar du mot den
-poäng som känns rimlig att ta betalt för, och då mäter du inte längre uppdraget.
+**You never set a price.** Points become a price through a fixed process fee plus the points
+times a conversion factor, and that is calculated somewhere else. If the price list is in
+the context: do not use it and say so. If you know what the points cost, you pull towards the
+score that feels reasonable to charge for, and then you are no longer measuring the
+assignment.
 
-**Du skriver aldrig underlaget.** Saknas spec eller påverkansanalys, avbryt med
-`INPUT_SAKNAS`. Skriv inte en påverkansanalys själv — då jämför du din egen text mot
-skalan, och belägget blir teater. `request-assess-impact` gör det, helst i en egen
-körning.
+**You never write the source material.** If the spec or the impact analysis is missing, abort
+with `INPUT_SAKNAS`. Do not write an impact analysis yourself: then you are comparing your own
+text against the scale, and the evidence becomes theatre. `request-assess-impact` does that,
+preferably in a separate run.
+
+**Do not give yourself the repo in this run.** If you have it, you start verifying things
+beside the source material, and then you are no longer scoring what you were given. If
+something is missing in the source material, the answer is low confidence, not an
+investigation of your own.
 
-**Ge inte dig själv repot i den här körningen.** Har du det börjar du verifiera saker
-vid sidan av underlaget, och då poängsätter du inte längre det du fått. Saknas något i
-underlaget är svaret låg konfidens, inte en egen efterforskning.
+## The stop questions first
 
-## Stoppfrågorna först
+A score is set only on an item that can be built. Five outcomes stop the scoring:
+
+| Outcome              | When                                                                                                                                                                                         | What must happen                                                      |
+| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
+| `KONCEPT`            | The form is unknown: a design question, an undecided choice of approach, several solution paths without a decision                                                                           | A separate item that delivers a proposal and a score on the build     |
+| `DIAGNOS`            | The cause is unknown and can be investigated. Applies above all to faults where no one knows why something is broken                                                                         | A time-boxed investigation that delivers an answer and a scored fix   |
+| `TILLBAKA_TILL_SPEC` | The impact analysis states `contradiction` under _Deviation from the spec_ (the spec presupposes something that does not hold), or no alternative solves the problem (step 2 below)          | The spec is completed, then a new run                                 |
+| `DELA_UPP`           | The item cannot be bracketed on its own: see below                                                                                                                                           | A new analysis round that points out the parts, then one run per part |
+| `ESKALERA`           | The judgement requires a human: a price-bearing decision that must not rest on a guess, and that is neither a split question (`DELA_UPP`) nor a hole in the source material (`INPUT_SAKNAS`) | The item is shown to a human; write in `notes` which question and why |
 
-Poäng sätts bara på en post som går att bygga. Fem utfall stoppar poängsättningen:
+`INPUT_SAKNAS` and `ESKALERA` are internal outcomes: `customer_rationale` is left empty,
+they must never reach the customer.
 
-| Utfall               | När                                                                                                                                                                                     | Vad som ska hända                                                     |
-| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
-| `KONCEPT`            | Formen är okänd — designfråga, oavgjort vägval, flera lösningsvägar utan beslut                                                                                                         | Egen post som levererar ett förslag och en poäng på bygget            |
-| `DIAGNOS`            | Orsaken är okänd och går att undersöka. Gäller framför allt fel där ingen vet varför något är trasigt                                                                                   | Tidsboxad undersökning som levererar besked och en poängsatt åtgärd   |
-| `TILLBAKA_TILL_SPEC` | Påverkansanalysen anger `motsägelse` under _Avvikelse mot specen_ (specen förutsätter något som inte stämmer), eller inget alternativ löser problemet (steg 2 nedan)                    | Specen kompletteras, sedan ny körning                                 |
-| `DELA_UPP`           | Posten går inte att ringa in på egen hand — se nedan                                                                                                                                    | Ny analysrunda som pekar ut delarna, sedan en körning per del         |
-| `ESKALERA`           | Bedömningen kräver en människa: ett prisbärande avgörande som inte får vila på en gissning, och som varken är en delningsfråga (`DELA_UPP`) eller ett hål i underlaget (`INPUT_SAKNAS`) | Posten visas för en människa; skriv i `notes` vilken fråga och varför |
+### When the item cannot be bracketed
 
-`INPUT_SAKNAS` och `ESKALERA` är interna utfall: `customer_rationale` lämnas tom,
-de ska aldrig nå kund.
+Two situations give `DELA_UPP`:
 
-### När posten inte går att ringa in
+- You find no ceiling, that is, no reference assignment that the item is certainly smaller
+  than.
+- Floor and ceiling are far apart and no reference assignment lies between them, that is, the
+  situation that would otherwise only have given `confidence: lag`.
 
-Två lägen ger `DELA_UPP`:
+Write in `notes` which of the situations it was, and which parts of the impact analysis
+point to the item containing several separate pieces of work. **Do not point out the parts
+yourself.** You may neither read the repo nor write the source material, and deciding what
+can be delivered on its own requires both. `request-assess-impact` does the split; you only
+say that it is needed.
 
-- Du hittar inget tak, alltså inget referensuppdrag som posten säkert är mindre än.
-- Golv och tak ligger långt isär och inget referensuppdrag finns emellan, alltså det
-  läge som annars bara hade gett `confidence: lag`.
+The split is done one step. If a part comes back and cannot be bracketed either, it becomes
+`OVER_SKALAN` and is quoted as an offer: it is not split further.
+
+**An item that already has scored parts is never scored as a whole.** The parent carries
+the sum of its parts, not a figure of its own.
+
+### Contradiction first
 
-Skriv i `notes` vilket av lägena det var, och vilka delar av påverkansanalysen som
-pekar mot att posten rymmer flera skilda arbeten. **Peka inte ut delarna själv.** Du
-får varken läsa repot eller skriva underlaget, och att avgöra vad som går att leverera
-för sig kräver båda. `request-assess-impact` gör uppdelningen; du säger bara att den
-behövs.
+The impact analysis's reviewer block (`## For the reviewer`) starts the line _Deviation from
+the spec_ with a label: `none`, `refinement` or `contradiction`. Read it before anything
+else. An archived analysis carries the Swedish forms of the same block (`## Till granskaren`,
+_Avvikelse mot specen_, `ingen`, `precisering`, `motsägelse`); they mean the same thing.
+
+`contradiction` means that the spec presupposes something that does not hold in the system,
+or that a point cannot be delivered as it stands. The label is set only
+when the analysis lists no unstruck alternative (ADR-0117); the form check
+has already rejected an analysis that carries `contradiction` together with alternatives, so
+you never meet that case. Then the outcome is
+`TILLBAKA_TILL_SPEC`, without exception and before the four-step rule below: a score on
+a spec that contradicts the code prices something that cannot be built. Write in
+`customer_rationale`, in the customer's language, what needs to be decided. The contract
+check rejects every other outcome when the analysis carries `contradiction`, and
+the orchestrator normally does not dispatch you at all in that situation.
 
-Delningen görs ett steg. Kommer en del tillbaka och inte går att ringa in heller, blir
-den `OVER_SKALAN` och offereras — den delas inte vidare.
+`refinement` is not a deviation to stop on: the analysis has filled in something
+the spec left open without the spec becoming wrong. What was refined goes into
+`assumptions_stated` as a precondition. `none` requires nothing.
+
+### Unanswered outcome choices
+
+The impact analysis's reviewer block lists under _Unanswered outcome choices_ (archived:
+_Obesvarade utfallsval_) the choices the spec left open, each with the alternatives, whether
+they differ in what must be built, and which alternative the analysis is written from.
+
+An item is almost never stopped for such a choice. Go through them in four steps.
+
+**Step 1: strike what does not solve the problem.** Read the spec's heading _Problem_. An
+alternative that does not solve that problem is not an alternative, it is an insufficient
+solution, and it must be neither chosen nor presented. Pricing it would be selling
+something that does not do what the customer asked for.
+
+The test is the spec's own words, not your view of what the customer ought to want. Does
+the alternative solve the problem as it is described? Partly is not enough.
+
+**Step 2: if nothing remains, stop.** Then the spec contradicts itself: the problem cannot
+be solved within what it describes. Set `outcome` to `TILLBAKA_TILL_SPEC` and
+write in `customer_rationale` what needs to be decided, in the customer's language.
+
+**Step 3: does the choice change the amount of work?** The analysis's line on whether the
+alternatives differ in what must be built is the answer. If they do not, the choice is a
+**precondition**: choose the most reasonable one, write it into `assumptions_stated` with what
+was chosen and why, and keep scoring. The customer approves the precondition together with
+the spec and the price.
 
-**En post som redan har poängsatta delar poängsätts aldrig som helhet.** Föräldern bär
-summan av sina delar, inte en egen siffra.
+Typical examples of a precondition: which of two existing ways of showing that something is
+loading is used, which of two equivalent wordings a text gets, where in an existing view a
+field is placed.
+
+**Step 4: several alternatives that all solve the problem.** Score **the simplest one** as
+the item's score. Score each other alternative separately, with its own bracketing, and put
+them in `alternatives`. They go to the customer as alternative solutions with their own
+prices.
+
+If the analysis's line on the amount of work is missing (it may have been written before
+that rule), decide yourself from what the analysis describes, and write in `notes` that the
+line was missing.
 
-### Motsägelse först
+Every alternative is bracketed exactly like the main alternative. An alternative with a
+score but without bracketing is as invalid as an item without.
 
-Påverkansanalysens granskarblock börjar raden _Avvikelse mot specen_ med en
-etikett: `ingen`, `precisering` eller `motsägelse`. Läs den innan något annat.
+An assumption that cannot be investigated is not a stop. It becomes a condition on the item,
+worded in the customer's language like "bygger på att X; faller X tidigt avbryts posten utan
+debitering" (in English: "relies on X; if X fails early, the item is cancelled without
+charge"). Uncertainty is resolved with knowledge or conditions, never with a higher score to
+be on the safe side.
+
+## The method: bracket, never estimate freely
 
-`motsägelse` betyder att specen förutsätter något som inte stämmer i systemet,
-eller att en punkt inte går att leverera som den står. Etiketten är satt bara
-när analysen inte listar något ostruket alternativ (ADR-0117); formkontrollen
-har redan fällt en analys som bär `motsägelse` tillsammans med alternativ, så
-du möter aldrig det fallet. Då är utfallet
-`TILLBAKA_TILL_SPEC`, utan undantag och före fyrstegsregeln nedan: en poäng på
-en spec som motsäger koden prissätter något som inte går att bygga. Skriv i
-`customer_rationale`, i kundens språk, vad som behöver avgöras. Kontrakts-
-kontrollen fäller varje annat utfall när analysen bär `motsägelse`, och
-orkestratorn dispatchar dig normalt inte alls i det läget.
+A figure that comes straight out of an overall judgement cannot be reviewed and differs
+between two runs. Bracket instead, in four steps. All four are reported in the outcome.
 
-`precisering` är ingen avvikelse att stoppa på: analysen har fyllt i något
-specen lämnade öppet utan att specen blev fel. Det preciserade går in i
-`assumptions_stated` som en förutsättning. `ingen` kräver inget.
+**Step 1: find a floor.** Read the scale and find a reference assignment that the item is
+**certainly larger than**. Write out which one and why.
 
-### Obesvarade utfallsval
+**Step 2: find a ceiling.** Find a reference assignment that the item is **certainly smaller
+than**. Write out which one and why.
 
-Påverkansanalysens granskarblock listar under _Obesvarade utfallsval_ de val specen
-lämnat öppna, var och en med alternativen, om de skiljer sig i vad som måste byggas,
-och vilket alternativ analysen är skriven utifrån.
+If you get no floor: the item is smaller than A1 and gets A1's score. The lower end of the
+scale is dominated by the fixed process fee anyway.
+
+If you get no ceiling: the item is larger than the scale's highest reference assignment. You
+must have compared against the scale's topmost anchor (A16) and reported it in
+`bracket.steps` before you say so; a "no ceiling" without that comparison is rejected by the
+contract check. Then set `DELA_UPP` and no score, so that the item is first tried in parts.
+If the item is already a split part (`split.part` in the source material, an earlier
+`DELA_UPP`), you set `OVER_SKALAN` instead: the source material at that level is too thin to
+compare against, and the item is quoted as a separate offer. A bundle part (`bundle.part`,
+several specs from the same request) is not a split part; on a bundle part without a ceiling
+the outcome is `DELA_UPP`.
 
-En post stoppas nästan aldrig för ett sådant val. Gå igenom dem i fyra steg.
+**Step 3: narrow down.** Go through the reference assignments between floor and ceiling. For
+each one: is the item larger or smaller, and on what grounds? Continue until you have two
+adjacent reference assignments that the item lies between.
 
-**Steg 1 — stryk det som inte löser problemet.** Läs specens rubrik _Problem_. Ett
-alternativ som inte löser det problemet är inget alternativ, det är en otillräcklig
-lösning, och det ska varken väljas eller presenteras. Att prissätta det vore att sälja
-något som inte gör det kunden bett om.
+**Step 4: place.** Set the score between the two. If the item lies closer to one of them, say
+which and why. If it lands at the same level as a reference assignment, give it that
+anchor's score outright.
 
-Testet är specens egna ord, inte din uppfattning om vad kunden borde vilja. Löser
-alternativet problemet som det är beskrivet? Delvis räcker inte.
+**Round to the scale's resolution.** Below 3 points to the nearest 0.25, that is 0.25,
+0.5, 0.75, 1, 1.25 and so on. From 3 points and up to the nearest whole point. A
+figure finer than that pretends to a precision that does not exist: two independent
+assessors land in different classes in one case out of five. The rounding is mechanical and
+happens after the placement, never by you choosing a rounder number while you compare.
+
+## What you compare on
 
-**Steg 2 — återstår ingenting, stoppa.** Då motsäger specen sig själv: problemet går
-inte att lösa inom det den beskriver. Sätt `outcome` till `TILLBAKA_TILL_SPEC` och
-skriv i `customer_rationale` vad som behöver avgöras, i kundens språk.
+Compare on what the change **brings with it**, not on how much code is written. What
+distinguishes the reference assignments, in descending order of how much they weigh:
 
-**Steg 3 — ändrar valet arbetsmängden?** Analysens rad om huruvida alternativen skiljer
-sig i vad som måste byggas är svaret. Gör de inte det är valet en **förutsättning**:
-välj det rimligaste, skriv in det i `assumptions_stated` med vad som valts och varför,
-och poängsätt vidare. Kunden godkänner förutsättningen tillsammans med spec och pris.
+**Whether a human must verify by hand, and in how many cases.** That is the clearest
+difference throughout the scale. An assignment covered by automated tests lies low.
+One that requires going through several scenarios, on several devices or in several
+environments lies high.
 
-Typexempel på förutsättning: vilket av två befintliga sätt att visa att något laddar som
-används, vilken av två likvärdiga formuleringar en text får, var i en befintlig vy ett
-fält placeras.
+**Always assume that automated tests exist**, even when the impact analysis says that the
+repo lacks a test suite. Count only the manual work that remains once a working test suite
+has done its job: what requires a human by its nature, that is, a check against an external
+service's test mode, visual review, or going through several devices or several
+environments. If the test suite is missing, that is not a discount: the coverage is built as a
+separate item before the change and is scored separately. Then fill `coverage_post` with `yta`
+(the surface that lacks coverage, in the customer's language) and `omfattning` (one sentence
+on what the coverage item builds). The field is what makes it possible to create the item; a
+note in `notes` is not enough. Leave the field out entirely when the assumption is not made.
 
-**Steg 4 — flera alternativ som alla löser problemet.** Poängsätt **det enklaste** som
-postens poäng. Poängsätt varje övrigt alternativ för sig, med egen inringning, och lägg
-dem i `alternatives`. De går till kund som alternativa lösningar med egna priser.
+**What happens if it goes wrong.** Incorrect payment, incorrect access to someone else's
+data, lost data or broken existing functionality weighs heavily. Wrong text or a wrong sort
+order weighs lightly.
 
-Saknas analysens rad om arbetsmängd — den kan vara skriven före den regeln — avgör
-själv utifrån vad analysen beskriver, och skriv i `notes` att raden saknades.
+**Whether the change touches code that several customers use.** Then migration per
+installation is added, and a risk that reaches beyond the one who ordered it. See A9 and
+A10.
 
-Varje alternativ ringas in precis som huvudalternativet. Ett alternativ med en poäng
-men utan inringning är lika ogiltigt som en post utan.
+**Whether an external system is touched**, and whether the connection is new or existing.
 
-Ett antagande som inte går att undersöka är inget stopp. Det blir ett villkor på posten:
-"bygger på att X; faller X tidigt avbryts posten utan debitering". Osäkerhet löses med
-kunskap eller villkor, aldrig med högre poäng för säkerhets skull.
+**Whether a sequence the user passes through in order changes**, and how many steps.
 
-## Metoden: ringa in, aldrig skatta fritt
+**Whether something is to be designed that does not exist in the system today.**
 
-En siffra som kommer direkt ur en helhetsbedömning går inte att granska och blir olika
-mellan två körningar. Ringa in i stället, i fyra steg. Alla fyra redovisas i utfallet.
+The number of files and the number of lines are **not** grounds for comparison. See the note
+at the end of the scale: two reference assignments with the same score differ by an order of
+magnitude in file count.
 
-**Steg 1 — hitta ett golv.** Läs skalan och hitta ett referensuppdrag som posten
-**säkert är större än**. Skriv ut vilket och varför.
+## The type
 
-**Steg 2 — hitta ett tak.** Hitta ett referensuppdrag som posten **säkert är mindre
-än**. Skriv ut vilket och varför.
+Use the type to find comparable reference assignments faster, nothing else. An assignment of
+a type the scale lacks is scored against the nearest ones in size, not against some invented
+adjustment. Write out which type you judged the item to be: it is logged so that it can be
+measured afterwards whether some type systematically lands wrong.
 
-Får du inget golv: posten är mindre än A1 och får A1:s poäng. Skalans nedre ände är
-ändå dominerad av den fasta processavgiften.
+`type` is one of the five values of the scale's overview table (`## Översikt`), verbatim:
+`Kundvänd funktion`, `Underhåll`, `Teknisk uppsättning`, `Integration`, `Internt verktyg`. If
+the item lacks an obvious type, choose the nearest one and write the reasoning under `notes`,
+never in the value itself.
 
-Får du inget tak: posten är större än skalans högsta referensuppdrag. Du måste ha
-jämfört mot skalans översta ankare (A16) och redovisat det i `bracket.steps` innan du
-säger det; ett "inget tak" utan den jämförelsen fälls av kontraktskontrollen. Sätt då
-`DELA_UPP` och ingen poäng, så att posten först prövas i delar. Är posten redan en
-split-del (`split.part` i underlaget, en tidigare `DELA_UPP`) sätter du i stället
-`OVER_SKALAN`: underlaget för den nivån är för tunt att jämföra mot, och posten
-offereras separat. En buntdel (`bundle.part`, flera specar ur samma önskemål) är inte
-en split-del; på en buntdel utan tak är utfallet `DELA_UPP`.
+## Gate mode
 
-**Steg 3 — snäva in.** Gå igenom referensuppdragen mellan golv och tak. För varje: är
-posten större eller mindre, och på vilken grund? Fortsätt tills du har två
-angränsande referensuppdrag som posten ligger mellan.
+If the skill runs on a complete implementation plan after the customer's approval, set
+`mode` to `guard`. Same scale, same method.
 
-**Steg 4 — placera.** Sätt poängen mellan de två. Ligger posten närmare det ena, säg
-vilket och varför. Landar den på samma nivå som ett referensuppdrag, ge den det
-ankarets poäng rakt av.
+Only new structural information from the full plan may move the score, never a reassessment
+of the same facts. Report which comparison step changed and the quote from the full plan
+that caused it, verbatim in the plan's own language. The gate is symmetric: a lower score is
+reported just as clearly as a higher one.
 
-**Avrunda till skalans upplösning.** Under 3 poäng till närmaste 0,25, alltså 0,25,
-0,5, 0,75, 1, 1,25 och så vidare. Från 3 poäng och uppåt till närmaste hela poäng. En
-finare siffra än så låtsas om en noggrannhet som inte finns: två oberoende bedömare
-hamnar i olika klass i en femtedel av fallen. Avrundningen är mekanisk och sker efter
-placeringen, aldrig genom att du väljer ett rundare tal medan du jämför.
-
-## Vad du jämför på
-
-Jämför på vad ändringen **drar med sig**, inte på hur mycket kod som skrivs. Det som
-skiljer referensuppdragen åt, i fallande ordning efter hur mycket de väger:
-
-**Om en människa måste verifiera för hand, och i hur många fall.** Det är den tydligaste
-skillnaden genom hela skalan. Ett uppdrag som täcks av automatiska tester ligger lågt.
-Ett som kräver genomgång i flera scenarier, på flera enheter eller i flera miljöer
-ligger högt.
-
-**Förutsätt alltid att automatiska tester finns**, även när påverkansanalysen säger att
-repot saknar testsvit. Räkna bara det manuella arbete som återstår när en fungerande
-testsvit gjort sitt: det som kräver en människa av sin natur, alltså kontroll mot en
-extern tjänsts testläge, visuell granskning, eller genomgång på flera enheter eller i
-flera miljöer. Saknas testsviten är det inte en rabatt: täckningen byggs som en egen
-post före ändringen och poängsätts för sig. Fyll då `coverage_post` med `yta` (den
-yta som saknar täckning, i kundens språk) och `omfattning` (en mening om vad
-täckningsposten bygger). Fältet är det som gör att posten kan skapas, en not i
-`notes` räcker inte. Utelämna fältet helt när antagandet inte görs.
-
-**Vad som händer om det blir fel.** Felaktig betalning, felaktig åtkomst till någon
-annans uppgifter, förlorad data eller bruten befintlig funktion väger tungt. Fel text
-eller fel sorteringsordning väger lätt.
-
-**Om ändringen rör kod som flera kunder använder.** Då tillkommer migrering per
-installation och en risk som når utanför beställaren. Se A9 och A10.
-
-**Om ett externt system berörs**, och om kopplingen är ny eller befintlig.
-
-**Om en sekvens som användaren passerar i ordning ändras**, och hur många steg.
-
-**Om något ska formges som inte finns i systemet i dag.**
-
-Antal filer och antal rader är **inte** jämförelsegrunder. Se noten sist i skalan: två
-referensuppdrag med samma poäng skiljer sig med en tiopotens i filantal.
-
-## Typen
-
-Använd typen för att hitta jämförbara referensuppdrag snabbare, ingenting annat. Ett
-uppdrag av en typ som saknas i skalan poängsätts mot de närmaste i storlek, inte mot
-någon påhittad justering. Skriv ut vilken typ du bedömt posten som — den loggas för att
-kunna mäta i efterhand om någon typ hamnar systematiskt fel.
-
-`type` är ett av översiktstabellens fem värden, ordagrant: Kundvänd funktion, Underhåll,
-Teknisk uppsättning, Integration, Internt verktyg. Saknar posten en självklar typ, välj
-den närmaste och skriv resonemanget under `notes`, aldrig i själva värdet.
-
-## Grindläget
-
-Körs skillen på en fullständig implementationsplan efter kundens godkännande, sätt
-`mode` till `guard`. Samma skala, samma metod.
-
-Endast ny strukturell information ur fullplanen får flytta poängen, aldrig en
-omvärdering av samma fakta. Rapportera vilket jämförelsesteg som ändrades och citatet ur
-fullplanen som orsakade det. Grinden är symmetrisk — en lägre poäng rapporteras lika
-tydligt som en högre.
-
-Bygger fullplanen ett annat vägval än det som såldes är det en händelse att rapportera
-även när poängen blir densamma.
+If the full plan builds a different choice of approach than the one that was sold, that is an
+event to report even when the score stays the same.
 
 ## Output
 
@@ -250,91 +264,101 @@ Bygger fullplanen ett annat vägval än det som såldes är det en händelse att
 }
 ```
 
-`score` sätts bara när `outcome` är `POANG`, och alltid på skalans upplösning: steg om
-0,25 under 3 poäng, hela poäng från 3 och uppåt.
-
-`bracket.steps` är jämförelserna från steg 3, en per referensuppdrag du vägde mot. Varje
-steg är ett objekt med exakt tre nycklar: `anchor` (ankarets id, `A12`), `relation`
-(`storre` om posten är större än ankaret, `mindre` om den är mindre, `lika` om den är
-jämbördig; ASCII, samma stil som `hog/medel/lag`) och `grund` (på vilken grund, en eller
-två meningar). Inga andra nycklar, ingen poäng i steget: ankarets poäng står i skalan.
-Det är det som gör poängen granskbar, och det är stegen driftvakten jämför mellan två
-körningar. En poäng utan inringning är inte ett giltigt utfall.
-
-`drivers` är de två eller tre faktorer som mest avgjorde placeringen. Varje driver är
-ett objekt: `pastaende` (faktorn med dina ord, utan citattecken) och `ankare`
-(`{"kalla": "spec.md | impact.md", "delstrang": "unik delsträng ur källblocket"}`).
-Ett block är ett stycke, en listpunkt, en rubrik eller en fetstilsetikett på egen
-rad. Delsträngen ska ligga inom ETT block och vara unik i källan — en träff i två
-block är ett hårt kontraktsbrott. Ett script löser ankaret till källblocket
-ordagrant i fältet `citat`. Du citerar aldrig själv: du pekar, koden citerar.
-
-`assumptions_stated` är de utfallsval specen lämnat öppna som **inte** ändrar
-arbetsmängden: vad du valt, och varför. De går med förslaget till kund som
-förutsättningar och godkänns tillsammans med specen och priset.
-
-`alternatives` är de övriga vägar som också löser problemet, en post var med `label`
-(vad alternativet innebär, i kundens språk), `score`, `bracket` och `adds` (vad som
-tillkommer jämfört med det valda). Alternativ som inte löser specens problem hör inte
-hit och ska utelämnas helt. Är listan tom fanns bara en väg som löser problemet.
-
-`notes` är iakttagelser som inte hör till poängen men som någon bör känna till, till
-exempel att ett repo saknar testsvit.
-
-`coverage_post` är valfritt: bara när repot saknar den täckning skalan förutsätter
-(se "Vad du jämför på"). `yta` är den yta som saknar täckning, i kundens språk;
-`omfattning` är en mening om vad täckningsposten bygger. Utelämna fältet helt när
-antagandet inte görs.
-
-**Ett antagande som analysen flaggat som overifierat ska alltid ut.** Går det att
-undersöka hör det till `notes` med hur det undersöks. Går det inte att undersöka blir
-det ett villkor i `conditions`, formulerat som "bygger på att X; faller X tidigt
-avbryts posten utan debitering". Ett overifierat antagande som varken syns i det ena
-eller det andra försvinner tyst, och då bär Haus en risk ingen beslutat om.
-
-`confidence` sätts till `lag` när posten inte liknar något referensuppdrag, när golv och
-tak ligger långt isär och inget referensuppdrag finns emellan, eller när
-påverkansanalysen anger att något inte kunnat verifieras och det påverkar placeringen.
-Låg konfidens är ett giltigt utfall och ska inte döljas genom att välja en poäng som
-ser rimlig ut.
-
-### Motiveringen till kund
-
-`customer_rationale` skrivs i kundens språk och beskriver arbetet som ska göras, inte
-hur skalan räknade. Nämn aldrig poäng, referensuppdrag, ankare eller skalan. Kunden ska
-kunna invända mot omfattningen, inte mot modellen.
-
-**Kundens språk** är, överallt i den här skillen, det promptens `SPRÅK:`-rad anger
-(`svenska` eller `engelska`); i en fristående körning utan raden är det specens språk.
-Det gäller `customer_rationale`, `conditions`, `assumptions_stated`, `alternatives`
-(`label` och `adds`) och `coverage_post.yta`. Kontrollen fäller kundtext på fel språk,
-och en sådan post dispatchas om i sin helhet.
-
-Finns alternativ: beskriv dem sist, som egna vägar med var sitt pris. En mening var
-räcker — vad kunden får i stället, och vad som tillkommer. Priset räknas ur poängen
-någon annanstans; skriv aldrig ut poängen.
-
-Den ska vara förenlig med specens _Ingår inte_. Motiverar du poängen med arbete som
-specen uttryckligen undantar har du poängsatt fel post.
-
-## Efter körning
-
-Granskaren läser inringningen, inte slutpoängen. En rimlig poäng med fel jämförelser är
-en felkalibrering som råkade landa rätt, och den kommer tillbaka i en post där den inte
-gör det.
-
-Korrigeringar går till skalan, alltså till referensuppdragen eller till den här
-instruktionen, och till kalibreringsloggen. Aldrig till priset på den enskilda posten.
-
-Visar det sig återkommande att poster av ett visst slag är svåra att placera, är det ett
-tecken på att skalan har ett hål och behöver ett referensuppdrag till. Rapportera det.
-
-## Acceptanstestet — granskarens sak, inte din
-
-Skillen verifieras genom att köras mot poster med känt utfall. Det underlaget ligger med
-flit **inte** i den här mappen — en körning som kan läsa facit kan inte längre testas. Du
-ska varken leta efter det eller rapportera det som saknat.
-
-För granskaren gäller två mått: att två oberoende körningar av samma post ger samma
-poäng, och att inringningen håller vid granskning. Det första är det som avgör om
-kunderna får samma pris för samma arbete.
+`score` is set only when `outcome` is `POANG`, and always at the scale's resolution: steps of
+0.25 below 3 points, whole points from 3 and up.
+
+`bracket.steps` are the comparisons from step 3, one per reference assignment you weighed
+against. Each step is an object with exactly three keys: `anchor` (the anchor's id, `A12`),
+`relation` (`storre` if the item is larger than the anchor, `mindre` if it is smaller, `lika`
+if it is on a par; ASCII, the same style as `hog/medel/lag`) and `grund` (on what grounds,
+one or two sentences). No other keys, no score in the step: the anchor's score is in the
+scale. That is what makes the score reviewable, and those are the steps the drift guard
+compares between two runs. A score without bracketing is not a valid outcome.
+
+`drivers` are the two or three factors that most decided the placement. Each driver is
+an object: `pastaende` (the factor in your own words, without quotation marks) and `ankare`
+(`{"kalla": "spec.md | impact.md", "delstrang": "unique substring from the source block"}`).
+A block is a paragraph, a list item, a heading or a bold label on its own
+line. The substring must lie within ONE block and be unique in the source: a hit in two
+blocks is a hard contract breach. The substring is copied verbatim from the source, in the
+source's language (the spec follows the customer's language; the analysis is in English, or
+in Swedish in an archived run), and never translated. A script resolves the anchor to the
+source block verbatim in the field `citat`. You never quote yourself: you point, the code
+quotes.
+
+`assumptions_stated` are the outcome choices the spec left open that do **not** change the
+amount of work: what you chose, and why. They go with the proposal to the customer as
+preconditions and are approved together with the spec and the price.
+
+`alternatives` are the other paths that also solve the problem, one entry each with `label`
+(what the alternative means, in the customer's language), `score`, `bracket` and `adds` (what
+is added compared with the chosen one). Alternatives that do not solve the spec's problem do
+not belong here and must be left out entirely. If the list is empty, there was only one path
+that solves the problem.
+
+`notes` are observations that do not belong to the score but that someone ought to know
+about, for example that a repo lacks a test suite.
+
+`coverage_post` is optional: only when the repo lacks the coverage the scale presupposes
+(see "What you compare on"). `yta` is the surface that lacks coverage, in the customer's
+language; `omfattning` is one sentence on what the coverage item builds. Leave the field out
+entirely when the assumption is not made.
+
+**An assumption that the analysis flagged as unverified must always come out.** If it can be
+investigated, it belongs in `notes` with how it is investigated. If it cannot be
+investigated, it becomes a condition in `conditions`, worded in the customer's language like
+"bygger på att X; faller X tidigt avbryts posten utan debitering". An unverified assumption
+that shows up in neither the one nor the other disappears silently, and then Haus carries a
+risk nobody decided on.
+
+`confidence` is set to `lag` when the item does not resemble any reference assignment, when
+floor and ceiling are far apart and no reference assignment lies between them, or when the
+impact analysis states that something could not be verified and it affects the placement.
+Low confidence is a valid outcome and must not be hidden by choosing a score that looks
+reasonable.
+
+### The rationale to the customer
+
+`customer_rationale` is written in the customer's language and describes the work to be
+done, not how the scale counted. Never mention points or scores, reference assignments,
+anchors or the scale, in either language (in Swedish: `poäng`, `referensuppdrag`, `ankare`,
+`skalan`). The customer must be able to object to the scope, not to the model.
+
+**The customer's language** is, everywhere in this skill, what the prompt's `SPRÅK:` line
+gives (`svenska` or `engelska`); in a standalone run without the line, it is the spec's
+language. It applies to `customer_rationale`, `conditions`, `assumptions_stated`,
+`alternatives` (`label` and `adds`) and `coverage_post.yta`. Every other free-text field in
+the envelope is internal and always written in English (`pastaende` in `drivers`, `why` and
+`grund` in `bracket`, `notes`, `coverage_post.omfattning`, `guard_diff`); enum values and JSON
+field names stay verbatim, and only a verbatim substring or quote keeps its source's language. The check rejects customer text in the wrong language, and
+such an item is dispatched again in its entirety.
+
+If there are alternatives: describe them last, as separate paths each with its own price.
+One sentence each is enough: what the customer gets instead, and what is added. The price is
+calculated from the score somewhere else; never write out the score.
+
+The rationale must be consistent with the spec's _Not included_ (_Ingår inte_ in a Swedish
+spec). If you justify the score with work that the spec explicitly excludes, you have scored
+the wrong item.
+
+## After a run
+
+The reviewer reads the bracketing, not the final score. A reasonable score with the wrong
+comparisons is a miscalibration that happened to land right, and it comes back in an item
+where it does not.
+
+Corrections go to the scale, that is, to the reference assignments or to this instruction,
+and to the calibration log. Never to the price of the individual item.
+
+If it turns out repeatedly that items of a certain kind are hard to place, that is a sign
+that the scale has a hole and needs one more reference assignment. Report it.
+
+## The acceptance test: the reviewer's business, not yours
+
+The skill is verified by running it against items with a known outcome. That material is
+deliberately **not** in this folder: a run that can read the answer key can no longer be
+tested. You must neither look for it nor report it as missing.
+
+For the reviewer, two measures apply: that two independent runs of the same item give the
+same score, and that the bracketing holds up under review. The first is what decides whether
+customers get the same price for the same work.