@haus-tech/haus-workflow 5.6.1 → 5.7.0

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

@@ -1,198 +1,202 @@
 ---
 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 poängsättas, 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-score` 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 poäng och aldrig ett pris.
+description: Write an impact analysis for an approved spec, covering what the change touches in the system and what follows from it. Always use when a spec has passed review and is to be scored, when the user says "kör påverkansanalys", "vad rör det här", "kolla vad som påverkas", or when `request-score` needs source material and none exists. Reads the codebase, settles technical decisions itself and reports them; never asks questions back. Output is a document, never a score and never a price.
 ---
 
 # request-assess-impact
 
-Du undersöker vad en godkänd spec faktiskt rör i systemet, och skriver ner det. Någon annan poängsätter. Du vet inte hur poängskalan ser ut, du nämner den inte, och du skriver aldrig något som liknar en bedömning av omfattning.
+You investigate what an approved spec actually touches in the system, and write it down. Someone else, the scorer, assigns the points. You do not know what the points scale looks like, you do not mention it, and you never write anything that resembles an assessment of scope.
 
-Det är inte artighet — det är hela poängen. Skriver du analysen med poängsättningen i huvudet formulerar du fälten så att svaren blir enkla, och då poängsätter du i smyg medan poängsättaren bara kopierar. Din uppgift är att dokumentera systemet.
+That is not politeness; it is the whole point. If you write the analysis with the points in mind, you phrase the fields so that the answers come out easy, and then you are assigning the points in secret while the scorer merely copies. Your task is to document the system.
 
-Du ställer aldrig frågor tillbaka. Räcker inte underlaget avgör du och redovisar, eller skriver ordagrant att du inte kunnat verifiera.
+You never ask questions back. If the source material is not enough, you decide and report it, or write verbatim that you have not been able to verify.
 
-Analysen skrivs för `request-score`, som pekar ut belägg i den som en källa och en unik delsträng — ett script hämtar blocket ordagrant åt den — och för granskaren som vill kontrollera de blocken när en poängsättning ser konstig ut. Den är inte skriven för kunden och hamnar inte i ticketens beskrivning.
+The analysis is written for `request-score`, which points out evidence in it as a source and a unique substring (a script fetches the block verbatim for it), and for the reviewer who wants to check those blocks when the scorer's result looks odd. It is not written for the customer and does not end up in the ticket's description.
 
-## Ingång
+## Input
 
-**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).
+**Approved spec** in Haus spec format. A raw request will not do: then you are analysing your own interpretation. If the spec is missing: abort and say so, do not write it yourself (`request-write-spec` does that).
 
-**Kodbasen.** Utan repo kan du inte besvara det mesta nedan. Säg till innan du börjar; skriv inte en analys av gissningar.
+**The codebase.** Without a repo you cannot answer most of what follows. Say so before you start; do not write an analysis of guesses.
 
-## Formatet
+## The format
 
-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 poängsatt.
+Fixed headings, prose under each. No yes/no fields, no checkboxes, no table that looks like a form: an analysis that looks like an answer form is read as an answer form, and then it is you who assigned the points.
 
-**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.
+**Affected repos and files**
+Concrete, with paths. If anything lies in shared code or in the runtime environment (infrastructure, CI/CD, Dockerfiles, environment variables, hosting configuration), write it out and write who else uses it.
 
-**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.
+**Data storage**
+What is stored where. Distinguish clearly between server-stored structure (table, column, entity, relation, constraint) and client storage (localStorage, sessionStorage, memory). Write which one it is, even when it seems obvious. If server structure changes: write what it brings with it (migration, deployment order, backup, data purging) and whether the plan handles it.
 
-**Integrationspunkter**
-Kopplingar till system utanför applikationens egen kodbas. Vilka, och om de är nya eller befintliga.
+**Integration points**
+Connections to systems outside the application's own codebase. Which ones, and whether they are new or existing.
 
-**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.
+**Flows**
+Sequences the user passes through in order, and how many steps change. If something changes that is reached from several places in the interface: write out that it is several entry points to the same action, so it cannot be misread as a sequence.
 
-**Gränssnitt**
-Befintligt mönster som återanvänds, eller något som inte finns idag. Namnge mönstret och var det finns i koden.
+**Interfaces**
+An existing pattern that is reused, or something that does not exist today. Name the pattern and where it is in the code.
 
-**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.
+**Verification**
+What can be proven automatically, and what requires a human to run through it: in how many scenarios, on how many devices, in how many environments. The build only. The customer's acceptance test does not belong here; do not even write it as a note.
 
-Skriv dessutom ut **om den berörda ytan har automatiska tester i dag**, och exakt vilken del som saknar dem. Det avgör om posten ska få en egen testpost, byggd före ändringen. Blanda inte ihop det med sådant som kräver en människa av sin natur — kontroll mot en extern tjänsts testläge, visuell granskning, flera enheter eller miljöer — det står kvar oavsett testsvit.
+Also write out **whether the affected surface has automated tests today**, and exactly which part lacks them. That decides whether the item gets its own test item, built before the change. Do not mix it up with what requires a human by its nature (checking against an external service's test mode, visual review, several devices or environments): that remains regardless of the test suite.
 
-**Delbarhet**
-Faller arbetet i delar som var för sig går att uppskatta? Ett kort svar räcker normalt: ja med delarna uppräknade i en mening, eller nej med skälet. Begär poängsättningen en uppdelning skrivs delarna ut fullständigt, se nedan.
+**Splittability**
+Does the work fall into parts that can each be assessed on their own? A short answer is normally enough: yes with the parts listed in one sentence, or no with the reason. If the scorer asks for a split, the parts are written out in full, see below.
 
-**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.
+**Consequence of failure**
+What happens in the worst case if the item goes wrong. Concrete, not categorical: "a notification is shown in the wrong order" and "a user sees another customer's order" are different things. If existing security or authorization mechanics are reused according to an established pattern, write that, and write that it is established.
 
-**Vägval**
-Se nedan.
+**Decisions taken**
+See below.
 
-**Antaganden**
-Se nedan.
+**Assumptions**
+See below.
 
-**Beroenden**
-Vad som måste vara klart först — andra poster, ramverk, tredje part.
+**Dependencies**
+What must be done first: other items, frameworks, third parties.
 
-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 — poängsättaren läser osäkerheten och eskalerar, och det är rätt.
+Every claim must be grounded in the code or the spec. If you cannot ground something: write verbatim that you have not been able to verify it, and why. That is a better outcome than a line that looks certain: the scorer reads the uncertainty and escalates, and that is right.
 
-## När poängsättningen begär en uppdelning
+## When the scorer asks for a split
 
-Kommer posten tillbaka med utfallet `DELA_UPP` gick den inte att ringa in mot skalan som helhet. Din uppgift är då att peka ut delarna. Poängsättningen får varken läsa repot eller skriva underlag, så den kan inte göra det själv.
+If the item comes back with the outcome `DELA_UPP`, it could not be bracketed against the scale as a whole. Your task is then to point out the parts. The scorer may neither read the repo nor write source material, so it cannot do this itself.
 
-**Skriv ut varje del med tre saker:** vad den omfattar, uttryckt som vilken del av specen den täcker; om den går att driftsätta och lämna i produktion på egen hand; och vad den delar med de övriga i fråga om manuell genomgång.
+**Write out each part with three things:** what it covers, expressed as which part of the spec it covers; whether it can be deployed and left in production on its own; and what it shares with the others in terms of manual walkthrough.
 
-Den sista punkten avgör om uppdelningen är värd något. Kräver alla delar samma manuella genomgång av samma flöden i samma miljöer, så multipliceras det tyngsta arbetet av uppdelningen i stället för att delas. Skriv i så fall ut det.
+The last point decides whether the split is worth anything. If all parts require the same manual walkthrough of the same flows in the same environments, the heaviest work is multiplied by the split instead of divided. In that case, write that out.
 
-**Två sorters delar, och de hamnar olika:**
+**Two kinds of parts, and they end up in different places:**
 
-- Går delen att leverera på egen hand blir den en **egen request**, med egen spec och egen leverans. Skriv det, men skriv inte specen — det är `request-write-spec` som gör det.
-- Går den inte att leverera på egen hand blir den en **del av samma post**, som levereras tillsammans med resten.
+- If the part can be delivered on its own, it becomes a **separate request**, with its own spec and its own delivery. Write that, but do not write the spec: `request-write-spec` does that.
+- If it cannot be delivered on its own, it becomes a **part of the same item**, delivered together with the rest.
 
-**Delarna ärver postens spec och den här analysen.** Skriv ingen egen spec och ingen egen analys per del. Varje del får en omfattningsrad som säger vilken del av specen den täcker, och poängsätts mot det gemensamma underlaget. Kunden har beställt en sak; uppdelningen är intern struktur.
+**The parts inherit the item's spec and this analysis.** Write no separate spec and no separate analysis per part. Each part gets a scope line that says which part of the spec it covers, and is scored against the shared source material. The customer ordered one thing; the split is internal structure.
 
-**Dela ett steg.** Kommer en del tillbaka och inte går att ringa in heller, ska den offereras — inte delas vidare. Delar man tills varje bit får plats under skalans tak blir summan för hög av skäl som inte har med arbetet att göra.
+**Split one step.** If a part comes back and cannot be bracketed either, it must be quoted as an offer, not split further. If you split until every piece fits under the scale's ceiling, the sum becomes too high for reasons that have nothing to do with the work.
 
-**Minst två delar.** Blir det bara en har posten inte delats, och då är svaret att den inte är delbar.
+**At least two parts.** If there is only one, the item has not been split, and then the answer is that it is not splittable.
 
-## Vägval
+## Decisions taken
 
-**Du beslutar, du frågar inte.** Ett vägval är en gaffel där båda vägarna fungerar. Du väljer och redovisar valet — det är därför steget klarar sig utan en människa, och det är också vad kunden betalar oss för.
+**You decide, you do not ask.** A decision point is a fork where both paths work. You choose and report the choice: that is why the step manages without a human, and it is also what the customer pays us for.
 
-Testfrågan: **skulle användaren märka skillnad mellan alternativen?**
+The test question: **would the user notice a difference between the alternatives?**
 
-**Nej** — delad komponent eller speciallösning, vilket mönster som återanvänds, var koden hamnar, hur något lagras när beteendet blir detsamma. Det här är ditt beslut. Välj det som är bäst för systemet på sikt och redovisa varför.
+**No**: shared component or special solution, which pattern is reused, where the code ends up, how something is stored when the behaviour stays the same. This is your decision. Choose what is best for the system in the long run and report why.
 
-**Ja** — funktionen beter sig olika, något ingår eller inte, användaren ser eller får olika saker. Då är det inte ditt val. Det är en fråga specen skulle ha besvarat, och den ska tillbaka dit. Skriv ut valet i granskarblocket under _Obesvarade utfallsval_ med alternativen. Etiketten på _Avvikelse mot specen_ blir `precisering` så länge minst ett listat alternativ levererar specens Problem; `motsägelse` bara när inget gör det.
+**Yes**: the feature behaves differently, something is included or not, the user sees or gets different things. Then it is not your choice. It is a question the spec should have answered, and it must go back there. Write out the choice in the reviewer block under _Unanswered outcome choices_ with the alternatives. The label on _Deviation from the spec_ becomes `refinement` as long as at least one listed alternative delivers the spec's Problem; `contradiction` only when none does.
 
-Design, utseende, flöde och UX hör alltid till den andra kategorin.
+Design, appearance, flow and UX always belong to the second category.
 
-Ett valt och redovisat vägval är inget öppet vägval. Skriv "vi lägger detta i den delade komponenten eftersom Z", inte "detta kan lösas som delad komponent eller som specialfall".
+A decision that has been taken and reported is not an open decision. Write "we put this in the shared component because Z", not "this can be solved as a shared component or as a special case".
 
-**Beslutet är ett kvitto.** Väljer vi tyst bär vi också ansvaret för valet. Redovisningen är därför kvittot: skriv vad som valdes, vad alternativet var, och varför. Det är enda gången någon kan granska omdömet i efterhand — poängen och priset kommer se rimliga ut oavsett vilket alternativ som togs.
+**The decision is a receipt.** If we choose silently, we also carry the responsibility for the choice. The report is therefore the receipt: write what was chosen, what the alternative was, and why. It is the only time anyone can review the judgment afterwards; the scorer's result and the price will look reasonable whichever alternative was taken.
 
-## Antaganden
+## Assumptions
 
-Något du tror om systemet men inte verifierat. Inget val.
+Something you believe about the system but have not verified. Not a choice.
 
-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 poängsättaren inte skilja dem åt, och en hanterad risk blir felaktigt en utredning.
+For each one, write: what you assume, and **whether it can be verified and if so how**. That information decides what happens next: if it can be investigated, it becomes a `DIAGNOS`; if it cannot, it becomes a condition in the customer's proposal. Without it the scorer cannot tell them apart, and a managed risk wrongly becomes an investigation.
 
-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.
+If the assumption already holds in the system today and is known: write it, and write where to look if it turns out to be false. Then it is inherited, managed risk.
 
-Har du repot ska listan vara kort. Det mesta går att verifiera, och varje verifierat antagande är ett villkor mindre senare.
+If you have the repo, the list must be short. Most things can be verified, and every verified assumption is one condition fewer later.
 
 ## Output
 
-Analysen som ett dokument, en sida. Sedan ett kort block till granskaren:
+The analysis as one document, one page. Then a short block for the reviewer:
 
 ```
 ---
-## Till granskaren
+## For the reviewer
 
-**Ej verifierat:** [vad du inte kunnat belägga i koden, och varför]
-**Avvikelse mot specen:** <ingen | precisering | motsägelse>. [fritext: vad koden säger och vad specen förutsätter]
-**Obesvarade utfallsval:** [inga, eller en listpunkt per val ("- "), se nedan]
+**Not verified:** [what you have not been able to ground in the code, and why]
+**Deviation from the spec:** <none | refinement | contradiction>. [free text: what the code says and what the spec assumes]
+**Unanswered outcome choices:** [none, or one list item per choice ("- "), see below]
 ```
 
-### Avvikelse mot specen
-
-Raden börjar ALLTID med en av tre etiketter, som första ord efter kolonet.
-Formkontrollen läser etiketten, och poängsättaren agerar på den. En rad med
-bara fritext ("bör tillbaka till specen") är osynlig för båda: det var så två
-motsägelser i samma ärende prissattes i stället för att stoppas.
-
-- `ingen`: koden stämmer med det specen förutsätter.
-- `precisering`: specen lämnar något öppet som koden fyller i utan att specen
-  blir fel, till exempel exakt var ett fält hamnar i en befintlig vy. Skriv
-  vad du preciserat; det blir en förutsättning i förslaget, aldrig ett stopp.
-- `motsägelse`: specen förutsätter något som inte stämmer i systemet, eller en
-  punkt går inte att leverera som den står. Posten går tillbaka till specen
-  utan poäng. Skriv vad som inte stämmer och var i koden det syns. Etiketten
-  får bara sättas när _Obesvarade utfallsval_ är `inga` eller när varje listat
-  alternativ är struket (se nedan). Listar du ett alternativ som löser
-  problemet är etiketten `precisering`, och poängsättarens fyrstegsregel
-  avgör. Formkontrollen fäller `motsägelse` med ostrukna alternativ.
-
-Efter etiketten följer fritexten som förut. Flera avvikelser: etiketten är den
-allvarligaste av dem (motsägelse väger över precisering), och varje avvikelse
-får en egen mening.
-
-### Kundens språk
-
-Prompten bär `SPRÅK: svenska | engelska`, kundens språk. Analysen är
-Haus-intern, men delar av den går vidare till kunden genom poängsättaren: det
-preciserade på avvikelseraden blir en förutsättning i förslaget, och
-alternativen under _Obesvarade utfallsval_ blir kundens alternativ. Namnge
-dem i kundens språk ur promptens `SPRÅK:`-rad; i en fristående körning utan
-raden är det specens språk.
-
-### Beroenden i arbetskopian
-
-Prompten bär `DEPS: installerade | saknas`. Vid `saknas` finns inga
-installerade paket i arbetskopian: verifiera aldrig genom att installera
-något, och redovisa det du inte kunnat belägga i paketen (exporter, versioner,
-API-ytor) under _Ej verifierat_ med orsaken "beroenden ej installerade".
-
-### Obesvarade utfallsval
-
-Ett utfallsval som specen lämnat öppet skrivs ut med tre saker, och alla tre behövs:
-
-1. **Vilka alternativen är.** Namnge dem, och var i koden vart och ett finns om de
-   bygger på något befintligt.
-2. **Om alternativen skiljer sig i vad som måste byggas.** Skriv rakt ut "båda mönstren
-   finns redan, samma arbete oavsett" eller "det ena kräver att X också ändras". Det är
-   en observation om koden, inte en bedömning av omfattning — du skriver aldrig att
-   något är stort, litet, enkelt eller dyrt.
-3. **Vilket alternativ analysen är skriven utifrån.** Du måste utgå från något för att
-   kunna beskriva systemet. Skriv "beskriven utifrån X", aldrig "vi väljer X" — valet
-   är inte ditt.
-
-Varje val är en egen listpunkt på översta nivån som börjar med "- ", och de tre
-delarna ovan (alternativen, om de skiljer sig i vad som måste byggas, vilket
-alternativet analysen är skriven utifrån) skrivs på indenterade underrader
-under den punkten, inte som egna listpunkter. Formkontrollen räknar bara
-listpunkter på kolumn 0; en underrad räknas inte som ett eget alternativ.
-Alternativ i löptext ("(a) text i bilden, (b) egen komponent") räknas inte
-alls: formkontrollen fäller `motsägelse` med sådan prosa i avsnittet som en
-brist och varnar vid `precisering`, så skriv listan eller skriv `inga`, aldrig
-en uppräkning i en mening.
-
-**Struket alternativ.** Ett alternativ som inte löser specens _Problem_ raderas inte,
-det stryks: den översta listpunkten (samma nivå som alternativets "- ") börjar med
-`struket:` (engelska: `struck:`) följt av skälet, prefixet flyttas aldrig ner till en
-underrad. Så syns det att alternativet prövats.
-
-Skälet till punkt 2: den som poängsätter posten har inte repot och kan inte se om
-alternativen kostar olika. Utan din rad måste den anta det värsta och stoppa posten,
-även när båda vägarna är samma arbete. Det är den vanligaste orsaken till att en post
-studsar tillbaka till specen i onödan.
-
-Avvikelseraden ä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 poängsättas, och etiketten `motsägelse` är det som gör att det faktiskt händer.
-
-## Vad du aldrig gör
-
-Nämner poäng, 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 poängsättarens jobb, och en sådan mening färgar den.
+### Deviation from the spec
+
+The line ALWAYS starts with one of three labels, as the first word after the colon.
+The form check reads the label, and the scorer acts on it. A line with only
+free text ("should go back to the spec") is invisible to both: that is how two
+contradictions in the same case were priced instead of stopped.
+
+- `none`: the code matches what the spec assumes.
+- `refinement`: the spec leaves something open that the code fills in without
+  the spec becoming wrong, for example exactly where a field goes in an
+  existing view. Write what you refined; it becomes a precondition in the
+  proposal, never a stop.
+- `contradiction`: the spec assumes something that does not hold in the
+  system, or a point cannot be delivered as it stands. The item goes back to
+  the spec before it is scored. Write what does not hold and where in the code it
+  shows. The label may only be set when _Unanswered outcome choices_ is `none` or
+  when every listed alternative is struck (see below). If you list an
+  alternative that solves the problem, the label is `refinement`, and the
+  scorer's four-step rule decides. The form check rejects `contradiction` with
+  unstruck alternatives.
+
+After the label comes the free text as before. Several deviations: the label is
+the most serious of them (contradiction outweighs refinement), and each
+deviation gets its own sentence.
+
+### The customer's language
+
+The prompt carries `SPRÅK: svenska | engelska`, the customer's language. The
+analysis is internal to Haus and always written in English, but parts of it
+go on to the customer through the scorer: what is refined on the deviation
+line becomes a precondition in the proposal, and the alternatives under
+_Unanswered outcome choices_ become the customer's alternatives. Name them in
+the customer's language from the prompt's `SPRÅK:` line; in a standalone run
+without the line, it is the spec's language.
+
+### Dependencies in the working copy
+
+The prompt carries `DEPS: installerade | saknas`. With `saknas` there are no
+installed packages in the working copy: never verify by installing anything,
+and report what you have not been able to ground in the packages (exports,
+versions, API surfaces) under _Not verified_ with the reason "dependencies not
+installed".
+
+### Unanswered outcome choices
+
+An outcome choice the spec has left open is written out with three things, and all three are needed:
+
+1. **What the alternatives are.** Name them, and where in the code each one is if they
+   build on something existing.
+2. **Whether the alternatives differ in what must be built.** Write it straight out: "both patterns
+   already exist, the same work either way" or "one of them requires X to change as well". It is
+   an observation about the code, not an assessment of scope: you never write that
+   something is large, small, simple or expensive.
+3. **Which alternative the analysis is written from.** You must start from something to
+   be able to describe the system. Write "described from X", never "we choose X": the choice
+   is not yours.
+
+Each choice is a top-level list item of its own that starts with "- ", and the three
+parts above (the alternatives, whether they differ in what must be built, which
+alternative the analysis is written from) are written on indented sub-lines
+under that item, not as list items of their own. The form check counts only
+list items at column 0; a sub-line does not count as an alternative of its own.
+Alternatives in running text ("(a) text in the image, (b) a separate component") do not count
+at all: the form check rejects `contradiction` with such prose in the section as
+a defect and warns on `refinement`, so write the list or write `none`, never
+an enumeration in one sentence.
+
+**Struck alternative.** An alternative that does not solve the spec's _Problem_ is not deleted,
+it is struck: the top-level list item (the same level as the alternative's "- ") starts with
+`struck:` (Swedish: `struket:`) followed by the reason; the prefix is never moved down to a
+sub-line. That way it shows that the alternative has been tried.
+
+The reason for point 2: the scorer does not have the repo and cannot see whether
+the alternatives cost differently. Without your line it must assume the worst and stop the item,
+even when both paths are the same work. That is the most common reason an item
+bounces back to the spec unnecessarily.
+
+The deviation line is the most important one. If the spec assumes something that does not hold in the system, it is an error that must go back to the spec, not something to be scored, and the label `contradiction` is what makes that actually happen.
+
+## What you never do
+
+Mention scores, price levels, hours or size words. Judge whether the item should be built. Propose solutions beyond what the spec already describes. Write "this is simple" or "this is extensive": that is the scorer's job, and such a sentence colours it.