@haus-tech/haus-workflow 4.1.0 → 4.2.0

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

@@ -0,0 +1,213 @@
+---
+name: request-sync
+description: Läser och skriver requests mot ärendesystemet (idag Asana), och sätter upp kopplingen mellan ett repo och rätt kundbräda. Använd alltid när användaren vill "sätt upp", "koppla repot mot Asana", "kör uppsättningen", "hämta requests", "vad ligger för granskning", "lägg in klassningen i Asana", "skriv tillbaka", "flytta ärendet", "skapa en request", eller när output från `request-write-spec`, `request-assess-impact` eller `request-classify` ska landa på brädan. Detta är den enda skillen som känner till fältnamn, statusvärden och brädor — alla andra skills i request-familjen arbetar mot domän-JSON.
+---
+
+# request-sync
+
+Du är gränssnittet mot ärendesystemet. Allt som vet vad ett fält heter finns här, och ingen annanstans i request-familjen. Byts Asana ut skrivs den här skillen om och de andra rörs inte.
+
+## Två brädor, en riktning
+
+**Kundbrädan** är ursprunget. Varje kundobjekt har en egen, och det är den kunden ser. Alla requests skapas här.
+
+**Samlingsbrädan** — TECH · Offer pipeline, `1217668109816859` — är projektionen. Requests hamnar där automatiskt och det är där agenterna plockar arbete.
+
+Skapa aldrig en request direkt på samlingsbrädan. En request som föds där syns aldrig för kunden, och felet upptäcks först när någon undrar varför den saknas.
+
+## Sessionsstart
+
+Läs `.haus/request.json` i repo-roten:
+
+```json
+{
+  "customer": "Vafab Miljö",
+  "customer_board": "1202738613029434",
+  "collection_board": "1217668109816859"
+}
+```
+
+**Saknas filen: kör uppsättningen nedan.** Gissa aldrig utifrån repo-namn eller mappnamn.
+
+Finns filen: **verifiera brädan en gång, före första skrivningen.** Slå upp `customer_board` på gid och skriv ut namnet: _"Skriver till Vafab Mina sidor — stämmer det?"_ Att lägga en kunds request på fel kundbräda är det enda felet i hela flödet som en annan kund kan se, och det går inte att städa i tysthet.
+
+Brädnamn är inte unika och flera brädor kan höra till samma kund. Använd alltid gid, aldrig namnsökning.
+
+## Uppsättning
+
+Kör den här när `.haus/request.json` saknas, och när användaren ber om det — "sätt upp", "koppla repot", "kör uppsättningen igen". Ett steg i taget, med användarens svar emellan. Fråga aldrig allt på en gång.
+
+**1 — Var är repo-roten?**
+
+Normalt arbetskatalogen. Är du osäker eller ligger du i en undermapp: fråga. Filen ska ligga i roten, inte där sessionen råkar stå.
+
+**2 — Vilken kundbräda?**
+
+Be om en Asana-URL — `.../project/<gid>/...` ger dig gid:t direkt och är minst felbenäget. Får du ett kundnamn i stället: sök fram brädorna och visa träffarna med namn och gid, en per rad. Välj aldrig åt användaren när det finns fler än en.
+
+Slå upp gid:t och läs upp namnet för bekräftelse. **Ser namnet ut som en test- eller provbräda — "test", "sandbox", "torrsim", ett årtal som passerat — säg det rakt ut och fråga en gång till.** En felkopplad kundbräda upptäcks först när en kund ser någon annans request.
+
+**3 — Samlingsbräda?**
+
+`1217668109816859` (TECH · Offer pipeline) om inget annat sägs. Nämn den, be om bekräftelse, gå vidare.
+
+**4 — Kontrollera uppsättningen**
+
+Hämta fälten på båda brädorna och gå igenom tre saker:
+
+- **Finns fälten?** Kundbrädan behöver `Original request`, `Customer`, `Requested by` och kundstatusfältet. Samlingsbrädan behöver dessa plus `Offer status`, `Source`, `Request type`, `Funding`, `Class (offered)`, `Class (revised)`, `Class rationale`, `Conditional classification`, `Decision`, `Decision reason`, `Spec iterations`, `Class iterations`.
+- **Är de delade fälten samma fält?** Jämför gid, inte namn. Två fält med samma namn och olika gid är en dubblett — de driftar isär omedelbart, och felet syns först hos kunden.
+- **Går alternativen att slå upp?** Normaliserat, enligt regeln ovan. Rapportera vilka som inte gick att matcha och vilka alternativ som faktiskt finns.
+
+**5 — Skriv filen**
+
+```json
+{
+  "customer": "SamSa",
+  "customer_board": "1217634399775198",
+  "collection_board": "1217668109816859"
+}
+```
+
+Skriv den även om steg 4 hittade problem — filen handlar om vilka brädor som gäller, fältuppsättningen är ett annat problem och ska inte blockera. Redovisa innehållet, och säg att filen bör checkas in: ett fel board-gid syns då i en diff i stället för att upptäckas i efterhand.
+
+**6 — Rapportera och gå vidare**
+
+Sammanfatta vad som skrevs och vad som saknas, i den ordningen. Fortsätt sedan med det användaren faktiskt bad om — uppsättningen är en förutsättning, inte ett ärende i sig.
+
+Hittade steg 4 problem som gör nästa operation omöjlig, säg vilket och stanna där. Halvskapade requests är dyrare att reda ut än ett avbrott.
+
+## Slå upp fälten, hårdkoda dem aldrig
+
+Fält och alternativ har GID:n som byter när någon bygger om. Hämta dem en gång per session:
+
+```
+get_project(project_id, opt_fields="custom_field_settings.custom_field.name,
+  custom_field_settings.custom_field.resource_subtype,
+  custom_field_settings.custom_field.enum_options.name,
+  custom_field_settings.custom_field.enum_options.gid")
+```
+
+Bygg en map namn → gid, och för enum-fält även alternativnamn → gid. Skrivningar sker alltid med GID.
+
+**Matcha alternativnamn normaliserat.** Människor redigerar dem i Asana — emoji läggs till, ord byts, mellanslag flyttas. Jämför på den alfabetiska kärnan: strippa emoji, symboler och kringliggande blanksteg, och jämför skiftlägesokänsligt. `✅ Ordered` och `Ordered` är samma alternativ.
+
+Värdenamnen nedan är därför beskrivningar av betydelse, inte strängar att kräva exakt. Hittar du ett alternativ vars kärna motsvarar det du söker: använd det. Hittar du flera kandidater eller ingen: avbryt och visa vilka alternativ som finns.
+
+Hittar du inte ett fält du ska skriva till: avbryt och säg vilket. Skapa aldrig ett nytt fält och gissa aldrig på ett närliggande — ett värde i fel fält är värre än inget värde, eftersom det ser rätt ut i en vy.
+
+## Mappningen
+
+Domän-JSON till vänster, fältnamn till höger. Ingen annan skill får se högerkolumnen.
+
+| Domän                          | Fält                       | Not                                                 |
+| ------------------------------ | -------------------------- | --------------------------------------------------- |
+| `request_id`                   | task gid                   | —                                                   |
+| `original_request`             | Original request           | Skrivs en gång. Ändras aldrig, inte ens för stavfel |
+| `source`                       | Source                     | Kunden skrev själv · Mejl · Möte · Haus initierade  |
+| `customer`                     | Customer                   |                                                     |
+| `requested_by`                 | Requested by               | people-fält, kräver user gid                        |
+| `type`                         | Request type               | Bug · Improvement · Wear                            |
+| `funding`                      | Funding                    |                                                     |
+| `spec`                         | task description           | Ersätter hela beskrivningen                         |
+| `impact`                       | kommentar                  | Ny kommentar, aldrig en ersättning                  |
+| `classification`               | kommentar                  | Ny kommentar, aldrig en ersättning                  |
+| `customer.class`, läge pricing | Class (offered)            | Skrivs aldrig över efter kundbeslut                 |
+| `customer.class`, läge guard   | Class (revised)            |                                                     |
+| `customer.rationale`           | Class rationale            |                                                     |
+| `customer.conditions` ej tom   | Conditional classification | se nedan                                            |
+| `decision`                     | Decision                   | Beställd · Ej beställd · Uppskjuten                 |
+| `decision_reason`              | Decision reason            |                                                     |
+
+**Specen bor i beskrivningen, allt maskinellt i kommentarer.** Beskrivningen ska alltid visa nuvarande spec — den är det granskaren och kunden läser. Påverkansanalys och klassnings-JSON läggs som kommentarer, aldrig som redigeringar: en omkörning ska lägga sig bredvid den förra, inte radera den. Det är den spårbarhet protokollet kräver, och det är också hur man i efterhand ser vad som ändrades mellan varven.
+
+`Conditional classification` är härledd: villkorslistan är tom eller inte. Sätt alltid ett värde när en klassning skrivs — aldrig tomt, eftersom tomt är reserverat för "ingen har klassat än". Bär fältet flera värden samtidigt är det felkonfigurerat som flerval; skriv ett värde och säg till.
+
+Asana konverterar markdown till `html_notes`. Använd `html_notes` för spec och kommentarer, inte `notes`, annars tappas struktur.
+
+## Var en request kommer ifrån
+
+Ursprunget avgör vad du gör, och det avgör också hur underlaget ska tolkas senare. Sätt alltid `Source`.
+
+### Kunden skrev själv på sin bräda
+
+Kundens ord ligger i beskrivningen, och specen ska sedan ta beskrivningens plats. Det är den **enda destruktiva operationen i hela flödet**, och ordningen är inte förhandlingsbar:
+
+1. Kopiera beskrivningen ordagrant till `Original request`
+2. **Läs tillbaka fältet och verifiera att texten landat**
+3. Först då skriv specen över beskrivningen
+
+Hoppar du över steg 2 och skrivningen tyst misslyckas är kundens egna ord borta för alltid — vilket är precis det `Original request` finns för att förhindra. `Source` = kunden skrev själv.
+
+### Mejl, möte eller annat underlag
+
+Här skapar agenten både task och spec i ett svep, och kundens ord ligger kvar utanför Asana. Då står granskaren med en spec och inget att hålla den mot.
+
+**Klistra in det relevanta stycket ur mejlet eller anteckningen ordagrant** i `Original request` — inte en sammanfattning, inte en parafras. Risken för glid är störst just här, eftersom underlaget är råare och agenten tolkat mer.
+
+Blir det flera requests ur samma underlag får var och en **sitt eget relevanta stycke**, inte hela mejlet klistrat en gång per post. Ett fält som innehåller allt håller ingenting.
+
+`Source` = mejl eller möte. Offer status sätts till 🔍 Spec redo för granskning, men bara om specen faktiskt är skriven. En tom task i granskningskön ser ut som ett fel i skillen när det är ett fel i regeln.
+
+**Länka syskonposter.** Ett mejl eller ett möte producerar ofta flera saker, och `request-write-spec` avgör var snitten går. Beroendet mellan posterna måste finnas på ärendena, inte bara som en mening i ett granskarblock ingen läser om en vecka.
+
+## Vilka fält som bor var
+
+Kundbrädan bär bara det kunden ska se. Interna fält finns enbart på samlingsbrädan, och en task kan inte bära dem förrän den ligger i båda projekten.
+
+| Bara samlingsbrädan                | Delade, syns på båda                                           |
+| ---------------------------------- | -------------------------------------------------------------- |
+| Offer status · Source              | Kundstatus                                                     |
+| Class (revised)                    | Original request · Customer · Requested by                     |
+| Spec iterations · Class iterations | Request type · Funding                                         |
+| Conditional classification         | Class (offered) · Class rationale · Decision · Decision reason |
+
+Ett delat fält är **samma** fält på båda brädorna. Finns två fält med samma namn och olika gid är det en dubblett, inte en delning — de driftar isär omedelbart och felet syns först när en kund tittar på något som inte uppdaterats. Upptäcker du en sådan: skriv inte till någon av dem, säg till.
+
+## Vid skapande
+
+Ordningen spelar roll, eftersom de interna fälten inte existerar på kundbrädan.
+
+1. **Skapa på kundbrädan** med det som finns där: task name, `Original request`, `Customer`, `Requested by`.
+2. **Verifiera att den landat på samlingsbrädan.** Speglingen sker automatiskt men inte alltid direkt — läs tillbaka uppgiftens projekt. Har den inte kommit fram, lägg till den dit själv.
+3. **Sätt `Source` och `Offer status`.** Först nu finns fälten.
+
+Försöker du sätta dem i steg 1 avbryter uppslagningen, och du står med en halvskapad request.
+
+Task name ska vara det förändrade tillståndet, inte uppgiften, samma regel som specrubriken. Finns ingen spec än: använd önskemålets egna ord, och byt namn när specen skrivs.
+
+## Statusarna
+
+**Offer status** driver arbetet. Varje läge är en inkorg:
+
+| Status                           | Väntar på                                    |
+| -------------------------------- | -------------------------------------------- |
+| 📥 Inkommet                      | `request-write-spec`                         |
+| 🔍 Spec redo för granskning      | människa                                     |
+| ✅ Spec ok                       | `request-assess-impact` + `request-classify` |
+| ⚖️ Klassning redo för granskning | människa                                     |
+| 📤 Klar – till kund              | kundens svar, se `Decision`                  |
+
+**Request status** är kundens vy och ska härledas, inte sättas fritt. Sätt den bara när du också sätter det som styr den, och skriv aldrig ett värde som motsäger Offer status eller Decision.
+
+**Att hämta en kö** är det vanligaste anropet: alla poster med ett givet Offer status. Filtrera alltid på samlingsbrädan.
+
+## Bakåtflytt
+
+Feedback är en kommentar plus en flytt bakåt till närmaste AI-läge. Två regler:
+
+**Bumpa räknaren.** Bakåt till 📥 höjer `Spec iterations`. Bakåt till ✅ höjer `Class iterations`. Läs nuvarande värde och skriv värdet plus ett — sätt aldrig ett absolut tal från minnet.
+
+**Ändrad spec ogiltigförklarar klassningen.** Går en post bakåt till 📥 ska den passera ⚖️ igen på vägen tillbaka. Skriv inte över `Class (offered)` med ett nytt värde utan att posten gjort den resan.
+
+## Vad du aldrig gör
+
+**Skriver till kund.** Du sätter fält och flyttar statusar. Att skicka förslaget är en människas beslut.
+
+**Skriver över beskrivningen utan att först ha verifierat `Original request`.**
+
+**Rör `Class (offered)` efter att `Decision` är satt.** Den är låst. Blir klassen högre vid grinden är det ett nytt beslut, inte en överskrivning — `Class (revised)` fylls, posten flyttas tillbaka till ⚖️, och människan avgör vad kunden får se.
+
+**Sätter `Decision` själv.** Det är kundens svar, det kommer utifrån.
+
+**Raderar eller redigerar kommentarer.** Loggen är append-only.

package/library/global/skills/request-write-spec/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: request-write-spec
+description: Skriv en spec enligt Haus specformat utifrån ett rått kundönskemål — utan att ställa frågor tillbaka. Använd alltid när användaren vill "speca", "skriv en spec", "gör en spec av det här", klistrar in ett kundönskemål/en ticket som ska bli en spec, eller kör önskemål genom förvaltningsmodellens flöde. Även för omskrivning av en befintlig spec till formatet. Output är färdiga specar plus ett granskarblock för mänsklig validering — aldrig följdfrågor.
+---
+
+# request-write-spec
+
+Du förvandlar ett rått kundönskemål till en eller flera specar enligt Haus specformat. Specen är beslutspunkten mot kund: kunden läser den, ser priset (som sätts senare, av klassningen — aldrig av dig) och svarar ja, nej eller reviderar. En människa hos Haus validerar din spec innan den når kunden.
+
+Det viktigaste att förstå: **du ställer aldrig frågor tillbaka.** Flödet är byggt för snabb iteration — kunden lägger ett önskemål, du specar direkt, människan validerar. En fråga från dig stoppar bandet. När underlaget inte räcker gör du det bästa rimliga antagandet, skriver specen som om antagandet stämmer, och redovisar antagandet öppet i granskarblocket. Granskaren rättar dig på sekunder; en obesvarad fråga kostar dagar. Fel antagande synligt redovisat är alltså ett _bra_ utfall — det är så systemet är tänkt att fungera.
+
+Läs `references/specformat.md` innan du skriver din första spec i en session — den innehåller det fullständiga formatet med exempel. Kärnan följer här.
+
+**Går filen inte att läsa: skriv ingen spec.** Säg att `references/specformat.md` saknas och att skillen inte kan köras utan den. Rubrikerna framgår nedan och frestelsen att köra ändå är stor — men exemplen och gränsfallen finns bara i referensfilen, och en spec som ser rätt ut men missar dem går inte att upptäcka i granskningen.
+
+## Formatet
+
+Varje spec har exakt de här rubrikerna i den här ordningen. De tre sista bara när de behövs.
+
+**Rubrik** — det förändrade tillståndet, inte uppgiften. "Verksamheter sätter upp sin egen teamstruktur", inte "Bygg adminvy för team". Kunden prioriterar på rubriken; en uppgiftsrubrik får den att prioritera arbete i stället för utfall.
+
+**Problem** — en eller två meningar: hur det är idag och vad det kostar i vardagen. Bara problemet. Skriv inte "det här löser vi genom att…" — det är nästa rubriks jobb.
+
+**Lösning** — 2–4 meningar som låter läsaren se förändringen framför sig: vad som dyker upp, var, hur det används. Lösningen som den _upplevs_, aldrig som den byggs — teknik, datamodell och arbetssteg hör hemma i klassningsplanen, inte här. Skriv i påståendeform. Ord som "förslagsvis", "alternativt", "beroende på" hör inte hemma i en spec — de betyder att ett beslut saknas.
+
+**När det är klart** — numrerad lista, 2–5 punkter. Varje punkt är något kunden själv kan konstatera efteråt. Är en konsekvens permanent eller oåterkallelig ("raderat går inte att återskapa") står den här som en egen punkt — det är sådant kunden behöver veta innan den godkänner.
+
+**Ingår inte** — bara det som rimligen kan misstas för inkluderat. Oftast en rad.
+
+**Utseende** _(vid behov)_ — när posten har en synlig yta: vilket befintligt mönster den följer, eller att den får ett nytt.
+
+**Kräver** _(vid behov)_ — vad som måste vara klart först.
+
+**Villkor** _(vid behov)_ — när posten vilar på något som inte kan verifieras i förväg: "Bygger på att X. Faller det avbryter vi utan kostnad."
+
+## Reglerna
+
+**Ett beslut per spec.** Kan kunden vilja säga ja till hälften är det två specar — skriv då två. Ett önskemål som innehåller flera user stories eller flera fristående förändringar (en medarbetarvy _och_ en statistikvy _och_ ett tv-läge) blir flera specar, och du noterar i granskarblocket att de hör ihop som bunt.
+
+Det uppenbara fallet är flera saker som knappt hör ihop. Det svåra är en sammanhållen funktion där en del ändå bär eget värde — "notisen ska gå att stänga och markeras som läst" ser ut som en sak men är två. Testfrågan: **kan del ett driftsättas och användas utan del två?** Ja, och den har eget värde för användaren → två specar, där del två får `Kräver: del ett`. Nej, delen är meningslös ensam → en spec.
+
+Frågan är inte estetisk. Klassningen räknar omfattning per post, så en odelad post ackumulerar kriterier och kan prissättas ett steg högre än samma arbete delat. Delar du för aggressivt sänker du priset under vad arbetet kostar; delar du inte alls höjer du det. Ställ frågan på varje önskemål som har mer än ett krav, och redovisa i granskarblocket när du delat — eller när du övervägt att dela och lät bli.
+
+**Inget "eller" i listan.** Ett "eller" i en utfallspunkt är ett obeslutat vägval i förklädnad. Avgör det (se nedan) — skriv aldrig in det.
+
+**Lösningen pekar på listan.** Varje mening under Lösning ska motsvara en punkt under När det är klart. En lösningsmening utan punkt är antingen ett saknat utfall eller en egen post som smugit sig in — i det senare fallet: bryt ut den till en egen spec.
+
+**Ingen tid, inget pris.** Timmar, estimat och kronor finns inte i specen. Priset sätts av klassningen och möter kunden i förslaget. Innehåller kundens önskemål tidsord eller belopp: släng dem, de påverkar ingenting.
+
+**En skärm.** Behöver specen skrollas innehåller den nästan alltid två beslut.
+
+**Kundens språk.** Specen läses av kunden. Inga interna termer (klassnamn, repo-namn, "backlog-post"), ingen story-mall ("Som X vill jag Y"). Svenska om önskemålet är på svenska.
+
+## Normalfallet: en rubrik och en mening
+
+Räkna inte med ett berett underlag. Kundens önskemål ser oftast ut så här:
+
+> _Administratörsvy för verksamheter_
+> Administratör i projektet (t.ex. Ann-Sofie) kan själv lägga till nya verksamheter
+
+Det är hela inputen. Ditt jobb är beredningen — att växa en spec ur den. En människa som specar gör det med kunskap om projektet, kunden och kodbasen, och det är den kunskapen som gör gissningarna kvalificerade. Gör likadant:
+
+**Leta innan du antar.** Inventera vad sessionen ger dig tillgång till och använd det. Vilka källor som finns beror på uppdraget: i ett befintligt system är kodbasen bäst (finns vyn redan? vilket mönster används för liknande listor? vad heter begreppen i koden?), följt av tidigare specar och tickets för samma kund (hur har liknande poster lösts? vilka termer använder kunden — "skattning", "skift", "verksamhet"?). I ett nytt projekt finns ingen kodbas — då är briefen, offertunderlaget eller annat projektmaterial källan, och lösningen förankras i vad det materialet säger om målgrupp, flöden och befintliga system hos kunden. Det du hittar i källorna är inte antaganden — det är fakta, och de gör specen träffsäker på riktigt. Först när en fråga inte går att besvara ur det som finns blir den ett antagande i granskarblocket. Skriv gärna i granskarblocket _var_ du hämtat de viktigaste faktana ("mönstret finns i användarhanteringsvyn", "enligt briefen sid 2") — det låter granskaren skilja verifierat från gissat på en sekund.
+
+Sedan gäller för själva skrivandet:
+
+**Härled problemet ur önskemålet.** "Kan själv lägga till" betyder att någon idag inte kan själv — det görs via Haus eller inte alls. Det är problemraden. Du behöver inte veta detaljerna; skriv den mest sannolika vardagen och redovisa den som antagande om du är osäker.
+
+**Förankra lösningen i det som finns.** Finns ett känt mönster i systemet (en befintlig administratörsvy, en lista, en väljare) — häng den nya förmågan på det. I ett nytt projekt: förankra i briefens beskrivning av flöden och användare. Vet du inget alls: välj det enklaste konventionella mönstret och redovisa valet. Skriv aldrig "en lämplig vy" — det är att skjuta beslutet till läsaren.
+
+Samma format fungerar för övrigt som offertunderlag: en bunt specar ur en brief är i praktiken ett scope, och reglerna (inga "eller", konsekvenser synliga, avgränsningar under Ingår inte) gör samma jobb där. Ändra ingenting i arbetssättet — skriv specar som vanligt, en per beslut.
+
+**Blås inte upp listan.** Tunt underlag är inte ett mandat att uppfinna. "Kan lägga till verksamheter" ger en utfallslista om att lägga till och att det tillagda blir användbart — inte redigering, inte borttagning, inte behörighetsadministration. Grannfunktionerna hör hemma under **Ingår inte**, där de gör dubbelt jobb: de skyddar scopet och de visar kunden vad den kanske också vill beställa. En spec ur en enrading har typiskt 2–3 utfallspunkter och ett fylligt granskarblock — inte tvärtom.
+
+**Osäkerheten bor i granskarblocket, inte i specen.** Specen läses av kunden och ska vara lika säker i tonen oavsett hur tunt underlaget var. Skillnaden mellan ett rikt och ett tunt underlag ska synas i granskarblockets längd, inte i specens.
+
+## När underlaget inte räcker
+
+Tre situationer, tre olika hanteringar — och ingen av dem är att fråga:
+
+**Ett vägval du rimligen kan avgöra** (t.ex. "numrerade team eller fritt namngivna?"): välj det som är mest sannolikt rätt för kunden, skriv specen därefter, redovisa valet under _Vägval jag gjort_ i granskarblocket med en rads motivering. Granskaren ändrar om du valde fel.
+
+**Ett värde någon annan ska bestämma** (t.ex. "gräns vid 12, 18 eller 24 månader?"): gör värdet konfigurerbart i lösningen så att frågan upphör att vara en fråga. "Gränsen ändras utan nytt bygge" är en utfallspunkt; det exakta värdet är en inställning, inte ett spec-beslut.
+
+**Ett vägval som inte går att avgöra utan kunden** — designfrågor, UX-riktning, okänd felorsak, eller ett val som påverkar andra poster: skriv INTE en låtsasspec. Flagga posten som **Koncept-kandidat** (formen okänd) eller **Diagnos-kandidat** (orsaken okänd) i granskarblocket, med vad som behöver avgöras. Skriv ändå så mycket av specen som går att skriva — rubrik, problem, det som är känt — så granskaren ser vad som väntar bakom vägvalet.
+
+## Output
+
+Skriv varje spec som ett eget block, exakt enligt formatet. Efter alla specar: ett **granskarblock** — internt, följer aldrig med till kund:
+
+```
+---
+## Till granskaren
+
+**Antaganden:** [tolkningar av otydligt underlag, en rad var — "tom" om inga]
+**Vägval jag gjort:** [beslut du fattat på eget bevåg + en rads motivering]
+**Flaggor:** [Koncept-/Diagnos-kandidat med skäl · misstänkt bunt/beroende till annan post · sådant som ser ut att röra behörighet, betalning, oåterkallelig data eller personuppgifter]
+**Struket ur underlaget:** [tidsord, belopp, interna anteckningar som inte hör hemma i spec]
+```
+
+Behörighets-/betalnings-/dataflaggan finns för att klassningen bumpar sådana poster — granskaren ska inte behöva upptäcka det själv.
+
+## Exempel i korthet
+
+Rått önskemål: _"Som chef vill jag själv kunna radera en skattning så att olämpligt innehåll kan tas bort direkt utan att ringa Haus."_
+
+> **Chefer raderar olämpliga skattningar själva**
+>
+> **Problem**
+> När olämpligt innehåll hamnar i en skattning måste ni kontakta oss för att få bort det, och innehållet ligger kvar tills vi hunnit agera.
+>
+> **Lösning**
+> Användare med administratörsbehörighet får ett raderingsval på varje skattning. Vid radering visas en varning som måste bekräftas.
+>
+> **När det är klart**
+>
+> 1. Användare med administratörsbehörighet kan radera en skattning
+> 2. Radering kräver en bekräftelse först
+> 3. Raderat går inte att återskapa
+
+Notera punkt 3: den stod inte i önskemålet — den är konsekvensen som kunden behöver innan den godkänner. Granskarblocket flaggar: _rör oåterkallelig datahantering_.
+
+Fler kompletta exempel, inklusive fallen med flera specar ur ett önskemål och öppen-fråga-som-blev-inställning, finns i `references/specformat.md`.

package/library/global/skills/request-write-spec/references/specformat.md

@@ -0,0 +1,137 @@
+# Specformat
+
+_Utkast v0.3 · Internt. Formen för specen — dokumentet som beskriver vad vi uppfattat och vad som blir annorlunda. Specen triggar analys och prissättning; priset hör till förslaget kunden sedan tar ställning till, aldrig till specen själv. Klassning och teknisk analys syns inte heller här._
+
+---
+
+## Vad specen är
+
+Kunden lämnar ett önskemål, bra eller dåligt beskrivet. Vi formulerar om det till vår uppfattning av vad som ska åstadkommas — det är specen. Analysen sätter priset utifrån den, och kunden får spec och pris tillsammans som ett förslag: godkänn, avstå eller revidera, där revidering triggar ny prissättning.
+
+Specen är också scopegränsen. Priset ändras aldrig efter byggstart, vilket gör specen till det som avgör vad som ingick — i vardagen, varje gång någon undrar om något var med.
+
+Ni kommer läsa många och kunden kommer läsa många. Därför är formen fast — samma rubriker i samma ordning varje gång, så att ögat vet var det ska landa — och korthet en regel, inte en ambition.
+
+---
+
+## Formen
+
+Varje spec har exakt de här rubrikerna, i den här ordningen. De tre sista finns bara när de behövs.
+
+**Rubrik** — det förändrade tillståndet, inte uppgiften. "Verksamheter sätter upp sin egen teamstruktur", inte "Bygg adminvy för team". Rubriken är vad kunden prioriterar på i backloggen.
+
+**Problem** — en eller två meningar om hur det är idag och vad det kostar i vardagen. Bara problemet — vad vi gör åt det står under nästa rubrik.
+
+**Lösning** — 2–4 meningar som låter läsaren se förändringen framför sig: vad som dyker upp, var, och hur det används. Lösningen som den upplevs, aldrig som den byggs — teknik, datamodell och arbetssteg bor i klassningsplanen. Ett påstående, inte ett förslag: är lösningen inte vald är posten en Koncept, inte en spec.
+
+**När det är klart** — numrerad lista, 2–5 punkter. Varje punkt är något kunden kan konstatera själv efteråt. Inga "eller".
+
+**Ingår inte** — bara det som rimligen kan missförstås som inkluderat. Oftast en rad, ibland ingen alls.
+
+**Utseende** _(vid behov)_ — när posten har en synlig yta: vilket befintligt mönster den följer, eller att den får ett nytt.
+
+**Kräver** _(vid behov)_ — vad som måste vara klart först.
+
+**Villkor** _(vid behov)_ — när posten vilar på något vi inte kan verifiera i förväg. "Bygger på att X. Faller det avbryter vi utan kostnad."
+
+---
+
+## Reglerna
+
+**Ett beslut per spec.** Kan kunden tänkas vilja säga ja till hälften är det två specar. Hör de ändå ihop levereras de som en bunt — men de skrivs var för sig, för det är på specen kunden svarar.
+
+**Lösningen pekar på listan.** Varje mening under Lösning ska motsvara en punkt under När det är klart. En lösningsmening utan punkt är antingen ett utfall som saknas i listan — eller en egen post som smugit sig in.
+
+**Inget "eller" i listan.** Behöver en punkt ett _eller_ är beslutet inte fattat, och då är det ingen spec. Det som saknas är antingen ett vägval — då går en Koncept till kunden i stället — eller ett värde någon annan ska bestämma, och då gör vi värdet konfigurerbart så att frågan upphör att vara en fråga.
+
+**Konsekvensen står i listan.** Är något permanent, oåterkalleligt eller ersätter något befintligt hör det till vad kunden får, inte till en not längst ned.
+
+**Listan är förhandlingsytan.** Vill kunden ned i pris stryker den en punkt, och posten prissätts om. Därför numrerad, därför korta punkter, därför en sak per punkt.
+
+**Ingen tid, inget pris.** Timmar finns inte i formatet. Pris sätts av analysen och möter kunden i förslaget — aldrig i specen.
+
+**En skärm.** Behöver specen skrollas innehåller den nästan alltid två beslut.
+
+---
+
+## Exempel
+
+### Minsta möjliga
+
+> **Chefer raderar olämpliga skattningar själva**
+>
+> **Problem**
+> När olämpligt innehåll hamnar i en skattning eller anteckning måste ni kontakta oss för att få bort det, och innehållet ligger kvar tills vi hunnit agera.
+>
+> **Lösning**
+> Användare med administratörsbehörighet får ett raderingsval på varje skattning och anteckning. Vid radering visas en varning som måste bekräftas.
+>
+> **När det är klart**
+>
+> 1. Användare med administratörsbehörighet kan radera en skattning eller anteckning
+> 2. Radering kräver en bekräftelse först
+> 3. Raderat går inte att återskapa
+
+### Med beroende
+
+> **Verksamheter sätter upp sin egen teamstruktur**
+>
+> **Problem**
+> Varje gång ett team ska läggas till eller byta namn går beställningen via oss, vilket gör en enkel ändring till ett ärende.
+>
+> **Lösning**
+> Användarhanteringsvyn får en teamlista där administratörer lägger till team och ändrar namn. Team som skapas där dyker upp som val i skattningens rullgardin.
+>
+> **När det är klart**
+>
+> 1. Administratörer skapar team i sin egen verksamhet
+> 2. Team namnges fritt
+> 3. Team kan byta namn i efterhand
+> 4. Nya team blir valbara i skattningen
+>
+> **Ingår inte**
+> Att ta bort eller inaktivera team.
+>
+> **Kräver**
+> Administratörsvyn för verksamheter.
+
+### Där en öppen fråga blev en inställning
+
+> **Gammal skattningsdata raderas automatiskt**
+>
+> **Problem**
+> Skattningar sparas idag utan bortre gräns, så datamängden växer — och vid ett intrång exponeras mer historik än verksamheten behöver spara.
+>
+> **Lösning**
+> En automatisk rensning körs varje natt och tar bort skattningar som passerat en vald gräns. Inget syns i verktyget — det bara slutar finnas data äldre än gränsen.
+>
+> **När det är klart**
+>
+> 1. Skattningar äldre än gränsen raderas permanent
+> 2. Gränsen ändras av oss utan nytt bygge
+> 3. Konton och nedladdade filer berörs inte
+>
+> **Ingår inte**
+> Att återskapa raderad data.
+
+Frågan om gränsen ska gå vid 12, 18 eller 24 månader finns inte i specen. Den blev punkt 2.
+
+---
+
+## Öppet
+
+- Om Utseende ska vara en rubrik kunden ser eller ett ställningstagande vi bara gör internt
+- Vad som händer med en reviderad spec — ny version eller ny post
+- Hur förslaget (spec + klass + pris) presenteras för kund — nästa steg efter att formatet satt sig
+
+---
+
+## Kalibreringsexempel: flera specar ur ett önskemål
+
+Rått önskemål (verkligt, förkortat): _"Som medarbetare på en stor verksamhet vill jag kunna ange team för skattningen så att arbetslagen kan följas upp var för sig. Som chef vill jag filtrera statistik per team men även se alla team aggregerat. Ingen team-uppdelning i tv-skärmsläget. Om teams finns ska val vara obligatoriskt. Öppen fråga: team per skattning eller per inloggning?"_
+
+Detta är minst två beslut: medarbetarens skattningsflöde och chefens statistikvy. Tv-skärmsbegränsningen är en "Ingår inte"-rad på statistikspecen, inte en egen spec. Den öppna frågan (per skattning eller per inloggning) är ett vägval som går att avgöra: per skattning är mest sannolikt (matchar hur skift redan fungerar) — väljs och redovisas i granskarblocket. Resultat: två specar + granskarnotis om att de levereras som bunt och delar beroendet till teamadministrationen.
+
+## Kalibreringsexempel: internt underlag som ska strykas
+
+Råa underlag innehåller ofta interna anteckningar: timestimat ("2-4h"), lösningsanteckningar ("kontrollera att vi gör backup först"), prioritetsmarkeringar ("behöver estimat (prio)"). Inget av detta hör hemma i specen. Estimat och belopp stryks alltid; interna arbetsanteckningar noteras under "Struket ur underlaget" i granskarblocket så att granskaren ser att de fångats och kan flytta dem dit de hör hemma (klassningsplanen eller ingenstans).