@haus-tech/haus-workflow 4.3.0 → 4.5.0

package/library/global/skills/request-score/references/poangskala.md

@@ -0,0 +1,1288 @@
+# Poängskalan
+
+Sjutton referensuppdrag med poäng. Skalan används för att placera in ett nytt uppdrag
+genom jämförelse, aldrig genom fri skattning.
+
+Poängen är ett relativt mått på arbetets omfattning. Den innehåller inget timpris, inga
+timmar och ingen valuta. Omräkningen till kronor sker någon annanstans.
+
+**Typen är en sökhjälp, aldrig en prisfaktor.** Den finns för att du snabbt ska hitta
+jämförbara referensuppdrag. Ingen typ har högre poäng än en annan vid samma
+arbetsmängd, och inget påslag får göras för att ett uppdrag är en integration, ett
+internt verktyg eller ett underhåll.
+
+**Skalan är inte linjär i kodmängd.** Ett uppdrag med tio gånger mer kod har inte tio
+gånger fler poäng. Jämför med vad ändringen drar med sig, inte med hur mycket som
+skrivs.
+
+## Poängens upplösning
+
+Poängen sätts aldrig finare än var som helst i den här skalan:
+
+- **Under 3 poäng:** steg om 0,25. Alltså 0,25 · 0,5 · 0,75 · 1 · 1,25 · 1,5 · 1,75 · 2 · 2,25 · 2,5 · 2,75.
+- **Från 3 poäng och uppåt:** hela poäng.
+
+Skälet är att en finare siffra låtsas om en noggrannhet som inte finns. Två oberoende
+bedömare hamnar i olika klass i en femtedel av fallen, så skillnaden mellan 16 och 16,5
+är mindre än osäkerheten i bedömningen.
+
+Stegen är finare i botten därför att samma relativa skillnad kräver det. Från 1 till 1,25
+är en fjärdedels ökning; från 16 till 17 är en sextondel. I den nedre änden dominerar
+dessutom den fasta processavgiften priset, så poängen betyder minst där.
+
+## Verifiering förutsätter automatiska tester
+
+Referensuppdragens beskrivningar av vad som kan bevisas automatiskt utgår från att en
+fungerande testsvit finns. Jämför ett nytt uppdrag på samma grund, även om dess repo
+saknar tester i dag.
+
+Skälet är att alla sjutton referensuppdrag är satta som om en testsvit fanns. Jämförs en
+post mot dem på annan grund mäter den inte samma sak, och skalan slutar hålla ihop.
+
+Saknas täckningen är det inte en rabatt. Den byggs då som en egen post före ändringen
+och poängsätts för sig. Räkna här bara det manuella arbete som återstår när testerna
+gjort sitt: kontroll mot en extern tjänsts testläge, visuell granskning, och genomgång
+på flera enheter eller i flera miljöer.
+
+## Översikt
+
+| Ankare | Poäng | Typ                 | Uppdrag                                                |
+| ------ | ----- | ------------------- | ------------------------------------------------------ |
+| A1     | 0,25  | Kundvänd funktion   | Uppdatera texter i en översättningsfil                 |
+| A2     | 0,75  | Kundvänd funktion   | Visa ett kontonummer i användarens kontovy             |
+| A3     | 0,75  | Kundvänd funktion   | Härled landval ur webbadressens språkdel               |
+| A4     | 1     | Kundvänd funktion   | Gör en rad i en produktlista klickbar                  |
+| A5     | 2     | Underhåll           | Säkerhetsuppdatering av beroenden                      |
+| A6     | 2,25  | Kundvänd funktion   | Normalisera filnamn vid uppladdning                    |
+| A7     | 2,5   | Teknisk uppsättning | Konfigurerbart spårningsskript per webbplats           |
+| A8     | 3     | Integration         | Kundmatchning mot affärssystem via momsnummer          |
+| A9     | 4     | Internt verktyg     | Låt administratörer sätta en kunds lösenord            |
+| A10    | 4     | Kundvänd funktion   | Förpackningsstorlek med decimaler                      |
+| A11    | 7     | Integration         | Hantera felaktigt pris vid sidladdning i betalflödet   |
+| A12    | 9     | Kundvänd funktion   | Förbättrad kartvy för val av upphämtningsplats         |
+| A17    | 10    | Underhåll           | Uppgradering av e-handelsramverket till ny delversion  |
+| A13    | 12    | Internt verktyg     | Import av användare och konton från fil                |
+| A14    | 13    | Kundvänd funktion   | Delad komponent för lägg i varukorg                    |
+| A15    | 16    | Integration         | Inloggning med extern e-legitimation, gränssnittsdelen |
+| A16    | 17    | Kundvänd funktion   | Strukturerad produktdata för sökmotorer                |
+
+Fördelningen speglar materialet: kundvänd funktion är 56 procent av allt arbete,
+internt verktyg 10, integration 7 och underhåll 5. Uppdrag över 25 poäng är utelämnade
+eftersom bara tre sådana finns 2025 och 2026.
+
+Numren är fasta beteckningar satta när ankaret skrevs, inte platser i ordningen. A17
+tillkom efteråt och ligger därför på 10 poäng mellan A12 och A13. Ett nummer byts
+aldrig ut, eftersom satta poäng hänvisar till det.
+
+---
+
+# A1 · Uppdatera texter i en översättningsfil
+
+**0,25 poäng · Kundvänd funktion**
+
+## Spec
+
+**Problem.** Flera texter i bokningsflödet använder fel ord för ombokning på norska.
+Kunder hör av sig och undrar vad som menas.
+
+**Lösning.** De felaktiga texterna byts till rätt term, på alla ställen där de
+förekommer i den norska språkfilen.
+
+**När det är klart.** De berörda texterna visar rätt term i det norska flödet. Övriga
+språk är oförändrade.
+
+**Ingår inte.** Ingen ändring av flödets steg eller logik.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Språkfilerna för norska i bokningsdelen, samt
+versionsanteckningarna. Ingen kod med logik ändras. Ingen delad kod, ingen driftmiljö.
+
+**Datalagring.** Ingen.
+
+**Integrationspunkter.** Inga.
+
+**Flöden.** Bokningen är en sekvens användaren passerar i ordning, men inget steg
+ändras. Bara texten inuti stegen byts.
+
+**Gränssnitt.** Inget nytt mönster. Texterna visas i befintliga fält, och de nya
+formuleringarna är ungefär lika långa som de gamla.
+
+**Verifiering.** Automatiska tester täcker att språkfilen laddas och att inga nycklar
+saknas. Att texterna läser rätt i sitt sammanhang behöver ses över för hand en gång i
+det norska flödet, eftersom en text kan vara korrekt i sig och ändå fel på sin plats.
+
+**Konsekvens av fel.** Fel eller missvisande text visas för kunden. Inget beteende
+ändras, ingen data påverkas, och en felaktig text går att rätta lika enkelt som den
+lades in.
+
+**Vägval.** Texterna byts på alla förekomster i språkfilen i stället för bara i det
+ställe som anmäldes, eftersom samma felaktiga term används på flera ställen och ett
+delvis byte hade gett två olika ord för samma sak.
+
+**Antaganden.** Att den nya termen är den kunden själv använder. Bekräftad av
+beställaren i ärendet.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Om samma term förekommer i marknadsföringstexter utanför
+applikationen.
+**Avvikelse mot specen:** Ingen.
+
+---
+
+# A2 · Visa ett kontonummer i användarens kontovy
+
+**0,75 poäng · Kundvänd funktion**
+
+## Spec
+
+**Problem.** Supportpersonalen ser inte vilket konto en användare tillhör när de läser
+ett supportärende, utan måste slå upp det i ett annat system.
+
+**Lösning.** Kontots identifierare visas i användarens kontovy och följer med när ett
+supportärende skapas.
+
+**När det är klart.** En användare som tillhör ett konto ser identifieraren i sin
+kontovy. Ett supportärende som skapas innehåller samma identifierare.
+
+**Ingår inte.** Identifieraren går inte att redigera.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Innehållssystemets datamodell för konto, och webbklientens
+kontovy. Klientens typdefinition för användare utökas. Ingen delad kod, ingen
+driftmiljö.
+
+**Datalagring.** Serverlagrad struktur ändras: kontots innehållstyp får ett nytt
+valfritt textfält. Befintliga konton saknar värde, så ingen bakåtfyllning och ingen
+driftsättningsordning krävs. Ingen klientlagring.
+
+**Integrationspunkter.** Inga nya. Supportärendets skapande sker redan i systemet och
+utökas med ett fält.
+
+**Flöden.** Ingen sekvens ändras. Kontovyn nås från en plats.
+
+**Gränssnitt.** Befintligt mönster återanvänds: fältet visas i den lista av
+kontouppgifter som redan finns i vyn. Inget nytt mönster byggs.
+
+**Verifiering.** Automatiska tester täcker att fältet visas när det finns och att vyn
+fungerar när det saknas. Ingen manuell genomgång behövs.
+
+**Konsekvens av fel.** Fel identifierare visas, eller ingen alls. Uppgiften är läsande
+och styr ingen behörighet.
+
+**Vägval.** Fältet läggs på kontots innehållstyp i stället för på användaren, eftersom
+identifieraren hör till kontot och flera användare kan dela konto.
+
+**Antaganden.** Att alla befintliga konton har en identifierare i källsystemet. Går att
+verifiera genom att räkna konton utan värde efter en första inläsning.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Om identifieraren är unik över alla konton. Den behandlas som en
+visningsuppgift, inte som en nyckel.
+**Avvikelse mot specen:** Ingen.
+
+---
+
+# A3 · Härled landval ur webbadressens språkdel
+
+**0,75 poäng · Kundvänd funktion**
+
+## Spec
+
+**Problem.** I kassan får kunden välja land i en lista, trots att de redan kommit in via
+en landsspecifik webbadress. Fel val ger fel frakt och fel moms.
+
+**Lösning.** Landet härleds ur webbadressens språkdel och förväljs. Kunden kan fortfarande
+byta.
+
+**När det är klart.** En kund som kommer via en landsspecifik adress ser rätt land
+förvalt. En kund på den generella adressen får välja som förut.
+
+**Ingår inte.** Ingen ändring av vilka länder som är valbara.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Två komponenter i butikens kassa: kassans behållare och
+landvalssteget. Ingen delad kod, ingen serverdel, ingen driftmiljö.
+
+**Datalagring.** Ingen. Språkdelen finns i adressen och landlistan hämtas som förut.
+
+**Integrationspunkter.** Inga.
+
+**Flöden.** Kassan är en sekvens användaren passerar i ordning, och ett av dess steg får
+ett förvalt värde. Antalet steg ändras inte.
+
+**Gränssnitt.** Befintligt mönster återanvänds: samma landväljare som förut, med ett
+förvalt värde i stället för tomt.
+
+**Verifiering.** Automatiska tester täcker att rätt land förväljs per språkdel och att
+det generella fallet lämnar valet tomt. Att frakt och moms följer med det förvalda
+landet behöver ses över för hand i kassan, eftersom det avgörs längre fram i flödet.
+
+**Konsekvens av fel.** Fel förvalt land ger fel fraktkostnad och fel moms på ordern,
+alltså felaktigt pris för kunden. Kunden kan rätta det själv, men det syns bara om de
+tittar.
+
+**Vägval.** Landet härleds ur adressens språkdel i stället för ur webbläsarens
+språkinställning, eftersom adressen är det kunden faktiskt valt och
+språkinställningen ofta står på något annat.
+
+**Antaganden.** Att varje språkdel motsvarar exakt ett land. Går att verifiera mot
+listan av publicerade adresser; håller det inte behövs en uttrycklig koppling i stället
+för en härledning.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Inget.
+**Avvikelse mot specen:** Specen säger inte vad som ska hända för en språkdel som saknar
+land. Implementationen lämnar valet tomt.
+
+---
+
+# A4 · Gör en rad i en produktlista klickbar
+
+**1 poäng · Kundvänd funktion**
+
+## Spec
+
+**Problem.** I produktlistan går det bara att klicka på produktens namn. Kunder klickar
+på bilden eller priset och ingenting händer.
+
+**Lösning.** Hela raden blir klickbar och leder till produktsidan.
+
+**När det är klart.** Klick var som helst på raden leder till rätt produktsida. Knappar
+inuti raden fungerar oförändrat utan att raden aktiveras.
+
+**Ingår inte.** Ingen ändring av produktsidan.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** En komponent i butikens gränssnitt med tillhörande
+formatmall. Används av en butik. Ingen serverdel, ingen driftmiljö.
+
+**Datalagring.** Ingen. Länkmålet finns redan i den produktdata komponenten tar emot.
+
+**Integrationspunkter.** Inga.
+
+**Flöden.** Ingen sekvens ändras. Produktsidan var redan nåbar från raden, nu från en
+större yta av samma rad.
+
+**Gränssnitt.** Befintligt mönster återanvänds: samma länkelement som omslöt namnet
+omsluter nu raden. Formatmallen justeras så att den inre knappen behåller sitt
+klickområde.
+
+**Verifiering.** Automatiska tester täcker att klick på raden navigerar rätt och att
+klick på den inre knappen inte gör det. Ingen manuell genomgång behövs.
+
+**Konsekvens av fel.** Klick på knappen inuti raden kan råka navigera i stället för att
+lägga i varukorgen. Irriterande men ofarligt; ingen data påverkas.
+
+**Vägval.** Raden omsluts av ett länkelement i stället för att lyssna på klick i
+JavaScript, eftersom det bevarar öppna i ny flik och fungerar för skärmläsare.
+
+**Antaganden.** Inga.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Inget.
+**Avvikelse mot specen:** Ingen.
+
+---
+
+# A5 · Säkerhetsuppdatering av beroenden
+
+**2 poäng · Underhåll**
+
+## Spec
+
+**Problem.** Säkerhetsgenomsökningen rapporterar kända sårbarheter i flera av
+applikationens beroenden.
+
+**Lösning.** Beroendena uppdateras till versioner utan kända sårbarheter. Ändringarna
+dokumenteras i versionsanteckningarna.
+
+**När det är klart.** Genomsökningen rapporterar inga kvarstående sårbarheter av hög
+allvarlighetsgrad. Applikationen bygger och testsviten går igenom.
+
+**Ingår inte.** Ingen uppgradering av huvudramverket till ny huvudversion.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Beroendeförteckningarna för både serverdelen och
+klientdelen, samt versionsanteckningarna. Ingen egen kod ändras. Ingen driftmiljö, men
+en driftsättning krävs för att uppdateringarna ska nå produktion.
+
+**Datalagring.** Ingen.
+
+**Integrationspunkter.** Inga nya. Befintliga beroenden byter version, vilket i sig kan
+ändra beteende hos de bibliotek som talar med externa tjänster.
+
+**Flöden.** Ingen sekvens ändras avsiktligt. En beteendeändring i ett beroende kan
+däremot slå var som helst, vilket är hela svårigheten i posten.
+
+**Gränssnitt.** Inget nytt mönster. Beroenden som påverkar utseende kan ge små visuella
+skillnader.
+
+**Verifiering.** Den automatiska testsviten är huvudkontrollen och täcker applikationens
+egen logik. Eftersom ändringen kan slå brett behöver de mest använda vyerna dessutom
+gås igenom för hand i testmiljö, som ett stickprov snarare än en fullständig genomgång.
+
+**Konsekvens av fel.** En beteendeändring i ett beroende kan bryta befintlig funktion på
+ett ställe ingen tänkt på, och felet upptäcks då först i drift. Å andra sidan är
+alternativet att låta kända sårbarheter stå kvar.
+
+**Vägval.** Uppdateringarna görs i en samlad omgång i stället för en i taget, eftersom
+flera av dem har beroenden till varandra och en i taget hade krävt lika många
+driftsättningar. Huvudramverkets huvudversion lämnas orörd och hanteras som en egen
+post, eftersom den för med sig ändringar i egen kod.
+
+**Antaganden.** Att testsvitens täckning räcker för att fånga de vanligaste
+regressionerna. Går att verifiera genom att läsa täckningsrapporten innan uppdateringen
+görs.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Om något av de uppdaterade beroendena har ändringar som bryter mot
+tidigare beteende. Ändringsloggarna är lästa men inte alla i detalj.
+**Avvikelse mot specen:** Ingen.
+
+---
+
+# A6 · Normalisera filnamn vid uppladdning
+
+**2,25 poäng · Kundvänd funktion**
+
+## Spec
+
+**Problem.** Uppladdade filer behåller sina originalnamn. Namn med mellanslag, svenska
+tecken eller versaler ger trasiga länkar och dubbletter.
+
+**Lösning.** Filnamnet normaliseras vid uppladdning: gemener, bindestreck i stället för
+mellanslag, och svenska tecken översatta. Redan uppladdade filer lämnas orörda.
+
+**När det är klart.** En fil med mellanslag och svenska tecken i namnet får ett rensat
+namn och en fungerande länk. Två filer med samma normaliserade namn krockar inte.
+
+**Ingår inte.** Ingen omdöpning av befintliga filer.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** En ny namngivningsstrategi i e-handelsplattformen, samt
+plattformens konfiguration där strategin registreras. Strategin gäller alla
+uppladdningar i installationen, alltså både administratörers och kunders.
+
+**Datalagring.** Ingen strukturändring. Filnamnet som lagras för nya filer får ett annat
+format än tidigare, vilket innebär att lagringen från och med nu innehåller två
+namnformat sida vid sida.
+
+**Integrationspunkter.** Inga nya. Filerna lagras där de lagrades förut.
+
+**Flöden.** Ingen sekvens ändras. Uppladdning nås från flera ställen i administrationen,
+alltså flera ingångar till samma åtgärd, och alla får den nya namngivningen.
+
+**Gränssnitt.** Inget nytt mönster. Ändringen är osynlig i gränssnittet utom genom att
+det visade filnamnet ser annorlunda ut.
+
+**Verifiering.** Automatiska tester täcker normaliseringen för mellanslag, versaler,
+svenska tecken och krockande namn. Att länken till filen fungerar efter uppladdning
+behöver kontrolleras för hand en gång, eftersom det involverar lagringen.
+
+**Konsekvens av fel.** En felaktig normalisering kan ge två filer samma namn, så att den
+ena skriver över den andra. Det är förlust av data som inte går att återskapa, och det
+är därför krockhanteringen är den viktigaste delen av posten.
+
+**Vägval.** Normaliseringen läggs som en strategi i plattformens egen
+uppladdningsmekanik i stället för i varje anropande vy, så att den gäller alla
+uppladdningsvägar utan att någon behöver komma ihåg den. Befintliga filer lämnas orörda,
+eftersom en omdöpning hade brutit alla länkar som redan pekar på dem.
+
+**Antaganden.** Att inga befintliga länkar innehåller filnamn som skulle ändras. Går att
+verifiera med en genomsökning av innehållet.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Om lagringen är skiftlägeskänslig. Normaliseringen till gemener gör
+frågan mindre viktig men inte irrelevant.
+**Avvikelse mot specen:** Ingen.
+
+---
+
+# A7 · Konfigurerbart spårningsskript per webbplats
+
+**2,5 poäng · Teknisk uppsättning**
+
+## Spec
+
+**Problem.** Spårningsskriptet för webbanalys är hårdkodat. Varje ny webbplats kräver en
+kodändring och en driftsättning för att få sin egen mätning.
+
+**Lösning.** Skriptets identifierare läggs som en inställning i innehållssystemet och
+läses in när sidan byggs. Saknas den laddas inget skript.
+
+**När det är klart.** En webbplats med angiven identifierare får skriptet i sidhuvudet.
+En utan får inget skript och inga fel i webbläsarkonsolen.
+
+**Ingår inte.** Ingen konfiguration av vad som mäts.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Innehållssystemets globala inställningar, samt
+webbklientens rotlayout, dess ruttdefinitioner och en ny omslutande komponent som lägger
+in skriptet. Ingen delad kod. Ingen driftmiljö, eftersom värdet nu kommer ur
+innehållssystemet i stället för ur en miljövariabel.
+
+**Datalagring.** Serverlagrad struktur ändras: den globala inställningstypen får ett nytt
+textfält. Det är en enda rad i systemet, så ingen datamigrering krävs.
+
+**Integrationspunkter.** Ett externt spårningsskript laddas från tredje part. Nytt som
+konfigurerbar integration; skriptet självt användes redan hårdkodat.
+
+**Flöden.** Ingen sekvens ändras. Skriptet laddas på varje sida, alltså vid varje ingång.
+
+**Gränssnitt.** Inget synligt gränssnitt byggs. Den nya komponenten är teknisk och saknar
+egen visuell form. Inställningen redigeras i innehållssystemets befintliga formulär.
+
+**Verifiering.** Automatiska tester täcker att skriptet läggs in när identifieraren finns
+och utelämnas när den saknas. Att skriptet faktiskt rapporterar till rätt mottagare går
+inte att bevisa automatiskt och behöver kontrolleras för hand en gång per miljö.
+
+**Konsekvens av fel.** Fel identifierare skickar mätdata till fel mottagare. Mätdata som
+gått fel är svår att ta tillbaka. Ett skript som laddas felaktigt kan fördröja
+sidladdningen.
+
+**Vägval.** Skriptet läggs in genom en omslutande komponent i rotlayouten i stället för
+i det statiska sidhuvudet, eftersom värdet nu är dynamiskt. Alternativet hade krävt en
+byggtidsvariabel och därmed en driftsättning per ändring, vilket är precis problemet som
+skulle lösas.
+
+**Antaganden.** Att en webbplats bara behöver ett spårningsskript. Går att verifiera med
+förvaltningen; om flera behövs blir fältet en lista.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Om identifieraren behöver skilja sig mellan test och drift för samma
+webbplats. Fältet är i dag ett per webbplats.
+**Avvikelse mot specen:** Ingen.
+
+---
+
+# A8 · Kundmatchning mot affärssystem via momsnummer
+
+**3 poäng · Integration**
+
+## Spec
+
+**Problem.** Ordrar från företagskunder hamnar ibland på fel kund i affärssystemet, för
+att kundnumret eller organisationsnumret inte matchar. Ordern måste då flyttas för hand.
+
+**Lösning.** Matchningen mot affärssystemet försöker med kundnummer först, sedan
+organisationsnummer, och slutligen momsnummer. Hittas ingen kund skapas ingen order på
+fel kund utan ärendet flaggas.
+
+**När det är klart.** En order från en kund som bara går att matcha på momsnummer hamnar
+på rätt kund. En order som inte matchar alls skapas inte, utan flaggas för manuell
+hantering.
+
+**Ingår inte.** Ingen ändring av hur kunder skapas i affärssystemet.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Kopplingen mot affärssystemet: de anrop som slår upp kund,
+och de frågor som definierar vad som hämtas. Kopplingen används av en kund. Ingen
+driftmiljö.
+
+**Datalagring.** Ingen strukturändring. Uppslaget läser ur affärssystemet, och resultatet
+avgör vilken kund ordern knyts till.
+
+**Integrationspunkter.** Affärssystemet är en befintlig extern integration. Ett nytt
+uppslagssätt läggs till på ett befintligt anrop, alltså ingen ny koppling.
+
+**Flöden.** Ingen sekvens som användaren passerar. Matchningen sker i bakgrunden när en
+order förs över.
+
+**Gränssnitt.** Inget. Flaggningen av omatchade ordrar syns i den befintliga listan över
+ärenden som kräver hantering.
+
+**Verifiering.** Automatiska tester täcker matchningsordningen och att ingen order skapas
+när alla tre uppslagen misslyckas. Att uppslaget mot affärssystemet faktiskt returnerar
+det som förväntas behöver provas för hand mot systemets testmiljö, för en kund som bara
+har momsnummer och en som inte finns alls.
+
+**Konsekvens av fel.** En order kan hamna på fel kund, vilket innebär att en kunds
+uppgifter och köp syns för en annan, och att fakturan går till fel mottagare. Det är
+felet posten finns för att åtgärda, så en felaktig lösning gör problemet värre snarare än
+oförändrat.
+
+**Vägval.** Uppslagen görs i tur och ordning med momsnummer sist, eftersom det är det
+minst tillförlitliga av de tre och bara ska användas när de säkrare misslyckats.
+Omatchade ordrar flaggas i stället för att skapas på en uppsamlingskund, eftersom en
+felplacerad order är svårare att upptäcka än en som saknas.
+
+**Antaganden.** Att momsnummer är unikt per kund i affärssystemet. Går att verifiera med
+en fråga mot systemet som räknar dubbletter.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Hur många av de historiska felplacerade ordrarna som skulle ha matchat
+på momsnummer. Det avgör hur mycket posten faktiskt löser.
+**Avvikelse mot specen:** Specen säger inte vad som ska hända med de ordrar som redan
+hamnat fel. Ingen rättning av historiken ingår.
+
+---
+
+# A9 · Låt administratörer sätta en kunds lösenord
+
+**4 poäng · Internt verktyg**
+
+## Spec
+
+**Problem.** När en kund inte kan logga in måste supporten be dem gå igenom
+återställningsflödet själva. För kunder som inte når sin mejl går det inte alls.
+
+**Lösning.** En administratör kan sätta ett nytt lösenord för en kund direkt i
+administrationsgränssnittet. Åtgärden loggas i kundens historik.
+
+**När det är klart.** En administratör med rätt behörighet kan sätta ett nytt lösenord
+och kunden kan logga in med det. En administratör utan behörighet ser inte funktionen.
+Åtgärden syns i kundens händelsehistorik med vem som utförde den.
+
+**Ingår inte.** Ingen förändring av kundens egen återställning via mejl.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Ett nytt instick i e-handelsplattformen, med en serverdel som
+exponerar åtgärden, en behörighetsdefinition, och en gränssnittsdel som lägger till
+fältet på kundens detaljsida och en post i händelsehistoriken. Bygget av
+administrationsgränssnittet konfigureras om för att inkludera insticket. Insticket ligger
+i kundens egen installation och delas inte. Administrationsgränssnittet måste byggas om
+vid driftsättning.
+
+**Datalagring.** Ingen ny struktur. Lösenordet skrivs genom plattformens befintliga
+mekanik, som hashar värdet. Händelsehistoriken använder plattformens befintliga
+historikpost.
+
+**Integrationspunkter.** Inga externa.
+
+**Flöden.** Ingen sekvens ändras. Åtgärden nås från kundens detaljsida, som är en ingång.
+
+**Gränssnitt.** Ett nytt fält och en knapp på en befintlig detaljsida, med plattformens
+egna formulärkomponenter. Historikposten använder plattformens befintliga mönster.
+Översättningar läggs till på två språk.
+
+**Verifiering.** Automatiska tester täcker att åtgärden avvisas utan rätt behörighet och
+att lösenordet ändras med den. Att kunden faktiskt kan logga in med det nya lösenordet
+involverar butikens inloggning och behöver provas för hand. Behörighetsspärren behöver
+också ses över för hand i gränssnittet, eftersom en dold knapp inte är samma sak som en
+skyddad åtgärd.
+
+**Konsekvens av fel.** En administratör utan rätt behörighet skulle kunna sätta en kunds
+lösenord och därmed komma åt kundens konto, alltså felaktig åtkomst till en annan persons
+uppgifter. Ett fel i lösenordshanteringen kan också låsa ute kunden helt.
+Behörighetsmekaniken som används är plattformens etablerade.
+
+**Vägval.** Åtgärden byggs som ett eget instick i stället för som en ändring i
+plattformens kärna, eftersom det överlever framtida uppgraderingar. Lösenordet sätts
+genom plattformens egen mekanik i stället för genom direkt skrivning, så att hashning och
+regler för lösenordsstyrka gäller oförändrat.
+
+**Antaganden.** Att en administratörsroll med den nya behörigheten går att tilldela. Går
+att verifiera i rolladministrationen.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Om kunden ska aviseras när lösenordet ändras av en administratör.
+**Avvikelse mot specen:** Specen nämner inte behörighetsnivå. Åtgärden har lagts bakom en
+egen behörighet, vilket är ett utfallsval specen inte besvarat.
+
+---
+
+# A10 · Förpackningsstorlek med decimaler
+
+**4 poäng · Kundvänd funktion**
+
+## Spec
+
+**Problem.** Förpackningsstorlek anges bara i heltal. Produkter som säljs i halva
+förpackningar eller med decimalvikt går inte att ange rätt, vilket ger fel fraktpris.
+
+**Lösning.** Förpackningsstorlek kan anges med decimaler. Antal decimaler och enhet
+konfigureras per installation.
+
+**När det är klart.** En produkt kan få en förpackningsstorlek med decimaler, den visas
+med rätt antal decimaler i butiken, och fraktberäkningen använder det exakta värdet.
+Befintliga heltalsvärden fungerar oförändrat.
+
+**Ingår inte.** Ingen ändring av fraktprismodellen i sig.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Ett instick för förpackningsstorlek i ett delat
+paketbibliotek: insticket självt, dess gränssnitt utåt och dess dokumentation.
+**Insticket är delad kod och används av flera kunders installationer**, så ändringen når
+fler än den som beställt den.
+
+**Datalagring.** Serverlagrad struktur påverkas: fältets datatyp går från heltal till
+decimaltal. Befintliga värden är giltiga decimaltal, så migreringen är en typändring
+utan omräkning, men den måste köras innan den nya koden driftsätts, annars avvisas
+skrivningar.
+
+**Integrationspunkter.** Inga nya. Fraktberäkningen läser fältet som förut.
+
+**Flöden.** Ingen sekvens ändras.
+
+**Gränssnitt.** Inget nytt mönster. Fältet i administrationen byter från heltalsfält till
+decimalfält med konfigurerbart antal decimaler.
+
+**Verifiering.** Automatiska tester täcker att decimalvärden sparas och läses, att
+befintliga heltal fungerar, och att avrundningen följer konfigurationen. Att fraktpriset
+faktiskt blir rätt behöver kontrolleras för hand för minst ett decimalfall, eftersom det
+avgörs i beräkningen längre fram.
+
+**Konsekvens av fel.** Fel avrundning ger fel fraktpris, alltså att kunden debiteras fel
+belopp. Eftersom insticket är delat kan felet dessutom slå hos kunder som inte begärt
+ändringen och som inte vet att den skett.
+
+**Vägval.** Antal decimaler görs konfigurerbart i stället för att sättas till ett fast
+antal, eftersom de installationer som delar insticket har olika enheter och ett fast
+antal hade tvingat fram en ny ändring för nästa kund. Datatypen ändras i botten i stället
+för att lagra decimaltal som text, så att beräkningar kan ske i databasen.
+
+**Antaganden.** Att inga befintliga installationer förutsätter heltal i sin egen
+fraktberäkning. Går att verifiera genom att söka igenom de installationer som använder
+insticket.
+
+**Beroenden.** Migreringen måste köras före driftsättning i varje installation som
+använder insticket.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Vilka installationer som i dag använder insticket. Listan är hämtad ur
+paketberoenden och kan vara ofullständig.
+**Avvikelse mot specen:** Specen talar om en installation. Insticket är delat, så
+ändringen berör flera, vilket specen inte förhåller sig till.
+
+---
+
+# A11 · Hantera felaktigt pris vid sidladdning i betalflödet
+
+**7 poäng · Integration**
+
+## Spec
+
+**Problem.** När kunden laddar om betalsidan visas ibland ett pris som inte stämmer med
+ordern, eftersom betalleverantörens vy skapas innan orderns rader hunnit uppdateras.
+
+**Lösning.** Betalvyn skapas först när ordern är i ett stabilt läge. Ändras ordern medan
+betalvyn är öppen laddas den om med rätt belopp.
+
+**När det är klart.** En kund som ändrar sin varukorg och går tillbaka till betalningen
+ser rätt belopp. En omladdning av betalsidan visar rätt belopp. Ett betalförsök på ett
+inaktuellt belopp går inte att slutföra.
+
+**Ingår inte.** Ingen ändring av vilka betalsätt som erbjuds.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Ett instick för betalleverantören i ett delat
+paketbibliotek: gränssnittet som skapar betalvyn, tjänsten som talar med leverantören,
+och lyssnaren på ändringar i orderrader. **Insticket är delad kod och används av flera
+installationer.**
+
+**Datalagring.** Ingen strukturändring. Orderns befintliga tillstånd läses för att avgöra
+om den är stabil.
+
+**Integrationspunkter.** Betalleverantören är en befintlig extern integration. Anropet som
+skapar betalvyn ändras till att returnera ett återanvändbart fragment i stället för en
+färdig vy, vilket är en ändring i hur integrationen används snarare än en ny koppling.
+
+**Flöden.** Kassan är en sekvens användaren passerar i ordning. Betalsteget ändras, och
+återgången till tidigare steg och tillbaka ändras. Betalsidan nås dessutom genom
+omladdning, alltså finns flera vägar in till samma steg.
+
+**Gränssnitt.** Inget nytt mönster byggs; betalleverantörens egen vy återges som förut. En
+laddningsindikering återanvänds från befintliga komponenter medan vyn byggs om.
+
+**Verifiering.** Automatiska tester täcker att betalvyn inte skapas på en instabil order
+och att lyssnaren utlöser omladdning vid ändring. Hela kedjan behöver provas för hand mot
+betalleverantörens testläge, i minst tre fall: ändrad varukorg med återgång, omladdning av
+betalsidan, och betalförsök på ett inaktuellt belopp.
+
+**Konsekvens av fel.** En kund kan debiteras ett annat belopp än ordern visar, alltså
+felaktig betalning. Det kan slå åt båda håll och upptäcks ofta först i avstämningen mot
+betalleverantören. Eftersom insticket är delat kan felet nå kunder som inte begärt
+ändringen.
+
+**Vägval.** Betalvyn byggs om vid ändring i stället för att låsas mot ändringar, eftersom
+en låst varukorg i kassan hade ändrat vad kunden kan göra och det är ett utfall specen
+inte tar ställning till. Stabilitetskontrollen läggs i insticket i stället för i
+butikens gränssnitt, så att den gäller alla installationer som använder betalsättet.
+
+**Antaganden.** Att betalleverantörens fragment går att återge flera gånger på samma sida
+utan att deras egen kod ställer till det. Går att verifiera med ett provanrop innan
+bygget.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Hur betalleverantören beter sig om ordern ändras i samma ögonblick som
+betalningen bekräftas. Kapplöpningen är inte utesluten.
+**Avvikelse mot specen:** Specen säger att ett betalförsök på inaktuellt belopp inte ska
+gå att slutföra, men inte vad kunden ska se när det inträffar.
+
+---
+
+# A12 · Förbättrad kartvy för val av upphämtningsplats
+
+**9 poäng · Kundvänd funktion**
+
+## Spec
+
+**Problem.** Kartan där kunden väljer upphämtningsplats visar bara de platser som fanns
+vid första sökningen. Drar kunden kartan åt sidan syns inga nya platser, och på mobil
+täcker kartan hela skärmen så att sökrutan försvinner.
+
+**Lösning.** Kartan laddar platser för det område som visas när kunden slutat dra. Kartan
+visas först efter en sökning, och dess höjd anpassas så att sökrutan är kvar. Ett besked
+visas när området saknar platser.
+
+**När det är klart.** Kunden kan dra kartan och se nya platser laddas. Ett område utan
+platser ger ett besked i stället för en tom karta. På mobil syns både karta och sökruta
+samtidigt.
+
+**Ingår inte.** Ingen ändring av hur platser hämtas eller vilka som visas.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Kartkomponenten i butikens gränssnitt och dess formatmall.
+Komponenten används av en butik. Ingen serverdel utöver den befintliga sökningen efter
+platser, ingen driftmiljö.
+
+**Datalagring.** Ingen. Platser hämtas vid behov och hålls i komponentens eget minne under
+sessionen.
+
+**Integrationspunkter.** Karttjänsten är en befintlig extern integration. Nytt är att
+komponenten lyssnar på när kunden slutat dra och gör en ny sökning på det synliga
+området, vilket ger fler anrop än förut.
+
+**Flöden.** Val av upphämtningsplats är ett steg i kassans sekvens. Steget ändras men
+antalet steg är detsamma. Kartan nås både från kassan och från en fristående sökning,
+alltså två ingångar till samma vy.
+
+**Gränssnitt.** Ett nytt mönster byggs för mobilvyn: kartans höjd och lagerordning
+anpassas så att sökrutan ligger kvar ovanpå. Beskedet för tomt område är en ny textyta i
+befintligt formspråk.
+
+**Verifiering.** Automatiska tester täcker att en ny sökning utlöses när dragningen
+avslutas och att beskedet visas för ett tomt område. Kartans beteende går inte att
+bevisa automatiskt: dragning, laddning under dragning och höjdanpassningen behöver gås
+igenom för hand på både mobil och dator, och i minst två skärmstorlekar på mobil.
+
+**Konsekvens av fel.** Kunden kan välja en upphämtningsplats som inte längre finns, eller
+inte hitta någon plats alls och avbryta köpet. Ingen betalning eller data påverkas
+felaktigt, men ett fel i kassan stoppar köp.
+
+**Vägval.** Ny sökning görs när dragningen avslutats i stället för löpande under
+dragningen, eftersom det senare hade gett många anrop mot karttjänsten och en ryckig
+upplevelse. Kartan visas först efter en sökning i stället för direkt vid sidladdning, så
+att kunden inte möts av en karta utan innehåll.
+
+**Antaganden.** Att karttjänstens anropsgräns tål det ökade antalet sökningar. Går att
+verifiera mot tjänstens villkor och nuvarande förbrukning.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Hur många platser som laddas per område innan prestandan påverkas.
+Ingen övre gräns är satt.
+**Avvikelse mot specen:** Ingen.
+
+---
+
+# A17 · Uppgradering av e-handelsramverket till ny delversion
+
+**10 poäng · Underhåll**
+
+_Poängen vilar på sex uppgraderingar av samma ramverk under 2025 och 2026, inte på ett
+enda uppdrag. Fyra rena versionssteg låg tätt kring 10. Två som bar med sig extra
+arbete låg kring 18. Poängen är satt på de rena stegen; vägvalen säger när posten i
+stället ligger dubbelt så högt._
+
+## Spec
+
+**Problem.** E-handelsramverket ligger kvar på en äldre delversion. Rättningar och nya
+tillägg från ramverkets community görs mot senare versioner, och avståndet växer för
+varje månad som går.
+
+**Lösning.** Ramverket lyfts till den nya delversionen, både i applikationen och i det
+tilläggspaket applikationen bygger på. Egen kod som den nya versionen bryter anpassas,
+och den strukturändring i databasen som versionen kräver körs.
+
+**När det är klart.** Applikationen bygger och startar på den nya versionen, testsviten
+går igenom, strukturändringen är körd i testmiljö och i produktion, och de egna vyerna i
+administrationen fungerar som förut.
+
+**Ingår inte.** Ingen ny funktion. Inget byte av administrationens grundgränssnitt och
+ingen flytt av driftmiljön.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Beroendeförteckningen och låsfilen i applikationen, och
+samma två filer i det tilläggspaket applikationen bygger på. Båda måste till samma
+version i samma omgång, eftersom applikationen inte startar med tillägg byggda mot den
+gamla versionen. Till det kommer en ny fil för strukturändringen i databasen,
+omgenererade typdefinitioner för dataförfrågningar, och de egna vyerna i
+administrationen som skrivs om mot ramverkets nya gränssnittsdel.
+**Tilläggspaketet delas mellan flera kunders applikationer**, så lyftet av det når
+vidare till dem och behöver planeras därefter.
+
+Merparten av de ändrade raderna är låsfilen, alltså listan över exakta versioner av
+alla tredjepartspaket. Egen kod som ändras är omkring 800 rader. Radantalet säger
+alltså nästan ingenting om posten.
+
+**Datalagring.** En strukturändring i den egna databasen krävs. Den genereras av
+ramverket men körs mot verklig data, och går inte att backa utan att en sparad kopia
+läses tillbaka.
+
+**Integrationspunkter.** Inga nya. Sökmotorn byter däremot huvudversion i samma omgång,
+eftersom ramverkets nya version kräver en nyare klient, och ett par tillägg som
+underhållits på egen hand ersätts av communityns motsvarigheter. Byten av det slaget är
+regel snarare än undantag vid ett versionssprång och hör till posten.
+
+**Flöden.** Ingen sekvens ändras avsiktligt. Som vid all uppdatering av beroenden kan en
+beteendeändring slå var som helst, och det är hela svårigheten i posten.
+
+**Gränssnitt.** Inget nytt mönster formges. Däremot byggs de egna vyerna i
+administrationen om mot ramverkets nya gränssnittsdel: dataförfrågningarna skrivs om,
+och logiken för att spara och för att välja bild likaså. Utseendet ska vara oförändrat
+för den som använder vyerna.
+
+**Verifiering.** Den automatiska testsviten är huvudkontrollen och täcker applikationens
+egen logik. Strukturändringen provas mot en kopia av produktionsdata innan den körs
+skarpt. De egna vyerna i administrationen gås igenom för hand eftersom de skrivits om,
+och de mest använda kundvyerna gås igenom som stickprov, eftersom ändringen kan slå
+brett.
+
+**Konsekvens av fel.** Ett fel i strukturändringen drabbar data och kräver återläsning
+från säkerhetskopia. Ett fel i de egna administrationsvyerna stoppar personalens arbete
+men rör inte kundens köpflöde. Ett fel som kommer ur ett bytt beroende kan bryta
+funktion som fungerade förut, på en yta ingen tittade på, och upptäcks då först i drift.
+
+**Vägval.** Hela versionssprånget görs i en omgång i stället för stegvis, eftersom
+tilläggspaketet och applikationen måste ligga på samma version för att applikationen ska
+starta. Tilläggspaketet lyfts först och applikationen sedan. Bär uppgraderingen dessutom
+ett byte av administrationens grundgränssnitt eller en flytt av driftmiljön är det egen
+post: de två mätta fallen av det slaget landade på nästan dubbla poängen, 18 i stället
+för 10.
+
+**Antaganden.** Att testsvitens täckning räcker för att fånga de vanligaste
+regressionerna. Går att verifiera genom att läsa täckningsrapporten innan arbetet
+påbörjas. Att ramverkets ändringslogg är fullständig i fråga om brytande ändringar.
+
+**Beroenden.** Egna tillägg som byggts mot den gamla versionen måste vara lyfta först.
+Följdarbete i dem efter uppgraderingen, när ett tillägg behöver anpassas till en ändrad
+datamodell i ramverket, är egen post. I det mätta fallet tillkom ett sådant på ungefär
+8 poäng en månad senare.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Om ramverkets ändringslogg tar upp alla brytande ändringar som rör de
+egna tilläggen. Loggen är läst, men tilläggen är inte genomgångna ett och ett i förväg.
+**Avvikelse mot specen:** Specen säger att ingen ny funktion ingår. Bytet av sökmotorns
+huvudversion och av ett par egna tillägg mot communityns motsvarigheter ändrar ändå
+beteende i sök och i betalning, utan att vara ny funktion.
+
+---
+
+# A13 · Import av användare och konton från fil
+
+**12 poäng · Internt verktyg**
+
+## Spec
+
+**Problem.** Nya användare läggs in en och en för hand. Vid större påfyllningar tar det
+dagar och blir fel.
+
+**Lösning.** En administratör laddar upp en fil med användare och konton, får se vad som
+kommer att skapas eller uppdateras, och bekräftar innan något skrivs. Rader med fel visas
+med orsak och hindrar inte de övriga.
+
+**När det är klart.** En korrekt fil skapar användare och konton och kopplar dem rätt. En
+fil med några felaktiga rader importerar de korrekta och listar de felaktiga med orsak. En
+avbruten import lämnar inget skrivet.
+
+**Ingår inte.** Ingen schemaläggning av återkommande importer.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Ett nytt instick i innehållssystemet med en gränssnittsdel
+som har egen vy i administrationen, och en serverdel som tolkar, validerar och skriver.
+Insticket har egen konfiguration, egna typdefinitioner, valideringsregler per fält och
+egna översättningar. Innehållssystemets startkonfiguration ändras för att registrera det.
+Delas inte. Ingen driftmiljö.
+
+**Datalagring.** Serverlagrad struktur skrivs men ingen struktur ändras: befintliga
+innehållstyper för användare och konto tar emot rader, och kopplingen mellan dem skapas i
+samma skrivning. Uppladdad fil hålls i minnet under granskningssteget och lagras inte
+permanent.
+
+**Integrationspunkter.** Inga externa. Skrivningen sker genom innehållssystemets egna
+gränssnitt.
+
+**Flöden.** En ny sekvens i tre steg som administratören passerar i ordning: ladda upp
+fil, granska vad som kommer att hända, bekräfta. Stegen har bestämd ordning och går inte
+att nå var för sig.
+
+**Gränssnitt.** Ett nytt mönster byggs. Administrationen har i dag ingen vy för
+filuppladdning med granskningssteg, så uppladdningsytan, resultattabellen och
+felredovisningen formges nytt inom systemets befintliga formspråk.
+
+**Verifiering.** Automatiska tester täcker tolkning av filen, valideringsreglerna per fält
+och att en avbruten import inte skriver något. Hela sekvensen behöver provas för hand,
+eftersom den involverar filuppladdning i webbläsaren och tre steg som ska hänga ihop.
+Minst tre fall: en korrekt fil, en med felaktiga rader och en som avbryts mitt i.
+
+**Konsekvens av fel.** En felaktig import kan skapa användare med fel kontokoppling,
+vilket ger en person tillgång till fel konto, och kan skriva över uppgifter på befintliga
+användare. Eftersom importen skriver många rader i följd är felmängden potentiellt stor
+och det finns ingen ångra-funktion. Granskningssteget finns just för att fånga detta före
+skrivning.
+
+**Vägval.** Importen byggs som ett eget instick med egen vy i stället för som en utökning
+av en befintlig listvy, eftersom sekvensen med granskning före skrivning inte får plats i
+det befintliga mönstret. Valideringen körs i två omgångar, först på filens form och sedan
+per rad, så att en trasig fil avvisas direkt medan en i övrigt korrekt fil kan importeras
+delvis.
+
+**Antaganden.** Att filens kolumnuppsättning är stabil mellan påfyllningar. Går att
+verifiera genom att jämföra de filer som använts hittills. Varierar den behöver
+kolumnmappning bli en del av granskningssteget, vilket den inte är i dag.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Om befintliga användare ska uppdateras eller hoppas över när de
+förekommer i filen. Implementationen uppdaterar.
+**Avvikelse mot specen:** Specen säger "skapar eller uppdaterar" utan att ange hur en
+dubblett känns igen. Nyckeln har valts till användarens mejladress, vilket är ett
+utfallsval specen inte besvarat.
+
+---
+
+# A14 · Delad komponent för lägg i varukorg
+
+**13 poäng · Kundvänd funktion**
+
+## Spec
+
+**Problem.** Knappen för att lägga i varukorgen finns i tre olika versioner på olika ytor,
+med olika beteende. Ändringar måste göras på tre ställen och glöms bort.
+
+**Lösning.** En delad komponent ersätter de tre. Den hanterar antal med plus och minus,
+bekräftelse innan en rad tas bort, och beteende för både inloggad och utloggad kund.
+
+**När det är klart.** Samma komponent används på produktsida, i listor och i
+varukorgswidgeten, med samma beteende. Att ändra antal till noll frågar innan raden tas
+bort. Befintliga ytor beter sig som förut eller bättre, aldrig sämre.
+
+**Ingår inte.** Ingen ändring av kassan.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** En ny komponent i det delade komponentbiblioteket, en
+komponent i butikens eget gränssnitt som bygger på den, en bekräftelsedialog, ikoner för
+plus och minus, samt de tre ytor som byter till den nya komponenten: produktsidan,
+produktlistans widget och inloggningsknappen i kassan. Formatmallar för knapp och dialog
+justeras. **Komponentbiblioteket är delat mellan flera applikationer**, så ändringar i
+knapp- och dialogformatet syns även utanför de tre ytorna.
+
+**Datalagring.** Ingen strukturändring. Komponenten läser och ändrar den aktiva ordern
+genom befintliga anrop.
+
+**Integrationspunkter.** Inga externa.
+
+**Flöden.** Ingen sekvens ändras. Komponenten används på tre ytor, alltså flera ingångar
+till samma åtgärd, och det är just det som är skälet till posten.
+
+**Gränssnitt.** Ett befintligt mönster förenas till ett. Bekräftelsedialogen före
+borttagning är nytt beteende och behöver formges, men den bygger på biblioteket
+befintliga dialogkomponent.
+
+**Verifiering.** Automatiska tester täcker antalshanteringen, bekräftelsen vid noll och
+beteendet för inloggad respektive utloggad kund. Att de tre ytorna faktiskt beter sig
+likadant efter bytet går inte att bevisa automatiskt och behöver gås igenom för hand på
+varje yta, i både inloggat och utloggat läge.
+
+**Konsekvens av fel.** Fel antal kan hamna i varukorgen, eller en rad tas bort utan att
+kunden avsett det, vilket ger fel order och fel belopp. Eftersom komponenten ersätter tre
+befintliga kan ett fel dessutom bryta funktion som fungerade förut, på ytor som inte var i
+fokus för ändringen.
+
+**Vägval.** Komponenten läggs i det delade biblioteket i stället för i butikens egen kod,
+eftersom syftet är att den ska kunna användas av flera applikationer. Bekräftelsen vid
+noll läggs i komponenten i stället för på varje anropande yta, så att beteendet inte kan
+glida isär igen, vilket är precis det problem posten ska lösa.
+
+**Antaganden.** Att de tre befintliga versionerna inte har beteendeskillnader som någon
+yta är beroende av. Går att verifiera genom att jämföra deras kod före bytet; en
+skillnad som visar sig behövd måste bli en inställning på den delade komponenten.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Om någon extern integration förlitar sig på den gamla komponentens
+markering i sidan, till exempel för spårning.
+**Avvikelse mot specen:** Specen säger att befintliga ytor aldrig ska bli sämre, men anger
+inte vad som gäller om en yta har ett beteende de andra saknar.
+
+---
+
+# A15 · Inloggning med extern e-legitimation, gränssnittsdelen
+
+**16 poäng · Integration**
+
+## Spec
+
+**Problem.** Kunder måste skapa lösenord för att handla, och många avbryter i det steget.
+Butiken vill erbjuda inloggning med e-legitimation.
+
+**Lösning.** Kunden kan logga in och registrera sig med e-legitimation. Inloggningen sker
+i ett eget flöde med väntesteg medan legitimeringen pågår. Registrering av en ny kund
+sker i två steg efter legitimeringen, där de uppgifter legitimationen ger fylls i
+automatiskt. Inloggning med lösenord finns kvar.
+
+**När det är klart.** En befintlig kund kan legitimera sig och blir inloggad. En ny kund
+legitimerar sig, fyller i återstående uppgifter och får ett konto. Ett avbrutet eller
+nekat försök leder tillbaka till inloggningsvalet med ett besked. Inloggning med lösenord
+fungerar oförändrat.
+
+**Ingår inte.** Ingen ändring av kassans betalflöde.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Butikens gränssnittsdel: en ny komponentgrupp för
+legitimering, ett omskrivet inloggningsformulär, ett tvåstegs registreringsflöde, samt
+justeringar i de generella fält- och kryssrutekomponenterna. Två applikationer berörs,
+butiken på webben och motsvarande mobilapplikation, som delar komponentbibliotek.
+**Fält- och kryssrutekomponenterna är delade** och används av fler ytor än inloggningen,
+så ändringar i dem syns på andra ställen. Widgetkonfigurationen utökas med de nya ytorna.
+
+**Datalagring.** Ingen serverlagrad struktur ändras här; den delen ligger i serverdelen av
+samma satsning. Klientlagring används för att hålla legitimeringens tillstånd mellan
+väntesteg och återkomst, och rensas när flödet avslutas eller avbryts.
+
+**Integrationspunkter.** Legitimeringstjänsten är extern och anropas genom serverdelen,
+inte direkt från klienten. Ur gränssnittets perspektiv är integrationen ny, och den för
+med sig väntetider och avbrottslägen som gränssnittet måste hantera.
+
+**Flöden.** Två sekvenser som användaren passerar i ordning. Inloggningen har start,
+väntesteg och utfall. Registreringen har två steg efter legitimeringen. Båda kan avbrytas
+i varje läge och måste då lämna kunden i ett begripligt tillstånd. Inloggningsytan nås
+dessutom från flera ställen i butiken, alltså flera ingångar till samma åtgärd.
+
+**Gränssnitt.** Ett nytt mönster byggs. Väntesteget med statusbesked, avbrottsknapp och
+återkomst finns inte i butiken sedan tidigare och formges nytt. Registreringsstegen
+återanvänder befintliga formulärkomponenter i en ny stegindelning.
+
+**Verifiering.** Automatiska tester täcker formulärens validering och att komponenterna
+återger de tillstånd de får. Själva legitimeringen går inte att prova automatiskt,
+eftersom den kräver den externa tjänstens testläge och en riktig legitimation. Hela kedjan
+behöver gås igenom för hand för befintlig kund, ny kund, avbrutet försök och nekat försök,
+på både webb och mobil eftersom flödet lämnar och återvänder till applikationen olika på
+de två.
+
+**Konsekvens av fel.** Ett fel i kopplingen mellan legitimering och konto kan logga in en
+kund på fel konto, alltså felaktig åtkomst till en annan persons uppgifter och
+orderhistorik. Ett fel i väntestegets tillståndshantering kan lämna kunden inloggad utan
+att legitimeringen fullföljts. De delade fält- och kryssrutekomponenterna används av
+andra formulär, så ett fel där kan bryta befintlig funktion utanför inloggningen.
+
+**Vägval.** Legitimeringen anropas genom serverdelen i stället för direkt från klienten,
+eftersom nycklarna inte får finnas i webbläsaren. Väntesteget bygger på att klienten
+frågar serverdelen om status med jämna mellanrum i stället för att hålla en öppen
+förbindelse, eftersom det klarar att kunden byter flik eller låser skärmen.
+Registreringen delas i två steg i stället för ett långt formulär, så att de uppgifter
+legitimationen redan gett kan visas ifyllda innan kunden ombeds fylla i resten.
+
+**Antaganden.** Att legitimeringstjänstens testläge går att nå från utvecklingsmiljön. Går
+att verifiera med ett provanrop innan bygget startar. Att mobilapplikationen kan återvända
+till rätt vy efter att legitimeringsappen öppnats — går att verifiera i mobilens
+testbygge, och om det inte fungerar krävs en annan återkomstmekanik.
+
+**Beroenden.** Serverdelen som talar med legitimeringstjänsten måste finnas innan flödet
+kan provas i sin helhet.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Hur länge en påbörjad legitimering ska anses giltig innan väntesteget
+ger upp. Implementationen använder tjänstens egen gräns.
+**Avvikelse mot specen:** Specen säger att lösenordsinloggning finns kvar men inte om en
+kund som legitimerat sig också ska kunna sätta ett lösenord.
+
+---
+
+# A16 · Strukturerad produktdata för sökmotorer
+
+**17 poäng · Kundvänd funktion**
+
+## Spec
+
+**Problem.** Produktsidorna saknar strukturerad data, så sökmotorer visar dem utan pris,
+lagerstatus och omdömen. Konkurrenter syns med den informationen.
+
+**Lösning.** Produktsidorna får strukturerad data med pris, tillgänglighet och de fält
+sökmotorernas handelsprogram kräver. Datan genereras i bakgrunden och uppdateras när
+produkten ändras. Vilka fält som ingår konfigureras per installation.
+
+**När det är klart.** En produktsida innehåller strukturerad data som validerar mot
+sökmotorernas verktyg. Ändras pris eller lagerstatus uppdateras datan inom ett dygn. En
+installation som inte vill ha handelsfälten får bara grunddata.
+
+**Ingår inte.** Ingen registrering hos sökmotorernas handelsprogram.
+
+## Påverkansanalys
+
+**Berörda repon och filer.** Ett nytt instick som genererar strukturerad data, med en
+tjänst som bygger datan, en bakgrundsuppgift som håller den aktuell, egna typer och
+konstanter. Dessutom nya fält på produktvarianten, en migrering för dem, ett instick som
+länkar till butiken, och plattformens konfiguration. Även butikens egen konfiguration
+berörs, eftersom sidan ska återge datan. Ingen driftmiljö, men bakgrundsuppgiften måste
+vara igång i drift.
+
+**Datalagring.** Serverlagrad struktur ändras: produktvarianten får flera nya fält, med en
+migrering. Fälten är valfria och saknar värde för befintliga produkter, så ingen
+bakåtfyllning krävs, men migreringen måste köras före driftsättning. Den genererade datan
+lagras för att slippa byggas om vid varje sidvisning.
+
+**Integrationspunkter.** Inga anrop till externa system. Datan konsumeras av sökmotorer
+som läser sidan, alltså en ensidig koppling utan anrop åt något håll.
+
+**Flöden.** Ingen sekvens användaren passerar. Genereringen sker i bakgrunden när en
+produkt ändras.
+
+**Gränssnitt.** Inget kundvänt gränssnitt. De nya fälten redigeras i administrationens
+befintliga formulär för produktvarianter, med plattformens egna fältkomponenter.
+
+**Verifiering.** Automatiska tester täcker att datan byggs med rätt innehåll, att den
+konfigurerbara delen respekteras och att bakgrundsuppgiften utlöses vid ändring. Att datan
+faktiskt godkänns av sökmotorernas valideringsverktyg går inte att bevisa i egna tester
+och behöver kontrolleras för hand mot verktygen, för minst en produkt med och en utan
+handelsfälten. Att uppdateringen sker inom ett dygn behöver följas upp i drift.
+
+**Konsekvens av fel.** Felaktig strukturerad data kan ge sökmotorerna fel pris eller fel
+lagerstatus, vilket möter kunden som ett annat pris i sökresultatet än i butiken. I värsta
+fall kan sökmotorernas handelsprogram stänga av butiken för felaktig data, vilket tar tid
+att få tillbaka. Ingen order eller betalning påverkas direkt.
+
+**Vägval.** Datan genereras i en bakgrundsuppgift och lagras i stället för att byggas vid
+varje sidvisning, eftersom den kräver flera uppslag och sidvisningarna är många.
+Fördröjningen på upp till ett dygn är priset för det, och den är godtagbar eftersom pris
+och lagerstatus i sökresultat ändå uppdateras med fördröjning hos sökmotorn. Vilka fält
+som ingår görs konfigurerbart, eftersom handelsprogrammens krav skiljer sig mellan
+marknader och ett fast fältset hade tvingat fram en ändring per installation.
+
+**Antaganden.** Att produktens omdömen finns tillgängliga i systemet. Går att verifiera
+genom att söka efter fältet på produktvarianten; saknas de utgår den delen och kravet
+behöver tillbaka till specen.
+
+**Beroenden.** Inga.
+
+---
+
+## Till granskaren
+
+**Ej verifierat:** Om bakgrundsuppgiftens körintervall räcker för att hålla löftet om ett
+dygn vid stora produktkataloger.
+**Avvikelse mot specen:** Specen säger "de fält sökmotorernas handelsprogram kräver" utan
+att räkna upp dem. Fältuppsättningen är vald ur dagens dokumentation och kan ändras av
+sökmotorn.
+
+---
+
+# Poängen samlat
+
+| Ankare | Poäng | Typ                 | Uppdrag                                                |
+| ------ | ----- | ------------------- | ------------------------------------------------------ |
+| A1     | 0,25  | Kundvänd funktion   | Uppdatera texter i en översättningsfil                 |
+| A2     | 0,75  | Kundvänd funktion   | Visa ett kontonummer i användarens kontovy             |
+| A3     | 0,75  | Kundvänd funktion   | Härled landval ur webbadressens språkdel               |
+| A4     | 1     | Kundvänd funktion   | Gör en rad i en produktlista klickbar                  |
+| A5     | 2     | Underhåll           | Säkerhetsuppdatering av beroenden                      |
+| A6     | 2,25  | Kundvänd funktion   | Normalisera filnamn vid uppladdning                    |
+| A7     | 2,5   | Teknisk uppsättning | Konfigurerbart spårningsskript per webbplats           |
+| A8     | 3     | Integration         | Kundmatchning mot affärssystem via momsnummer          |
+| A9     | 4     | Internt verktyg     | Låt administratörer sätta en kunds lösenord            |
+| A10    | 4     | Kundvänd funktion   | Förpackningsstorlek med decimaler                      |
+| A11    | 7     | Integration         | Hantera felaktigt pris vid sidladdning i betalflödet   |
+| A12    | 9     | Kundvänd funktion   | Förbättrad kartvy för val av upphämtningsplats         |
+| A17    | 10    | Underhåll           | Uppgradering av e-handelsramverket till ny delversion  |
+| A13    | 12    | Internt verktyg     | Import av användare och konton från fil                |
+| A14    | 13    | Kundvänd funktion   | Delad komponent för lägg i varukorg                    |
+| A15    | 16    | Integration         | Inloggning med extern e-legitimation, gränssnittsdelen |
+| A16    | 17    | Kundvänd funktion   | Strukturerad produktdata för sökmotorer                |
+
+## Ett mönster värt att lägga märke till
+
+A9 och A10 har samma poäng, 4, men ser olika ut. A9 bygger ett helt nytt instick med
+gränssnitt, behörighet och historik. A10 ändrar en datatyp i tre filer. Skillnaden är att
+A10 rör delad kod som används av flera installationer, vilket drar med sig migrering per
+installation och en risk som sträcker sig utanför beställaren.
+
+Det är den sortens jämförelse skalan finns för. Antalet filer säger lite; vad ändringen
+drar med sig säger mycket.