--- framework_version: 1.0.0 document_type: normative status: active maintained_by: framework last_updated: 2026-09-24 --- # Lovable-styrsystem — installationsfil Det här är ett lättviktigt styrsystem för ett Lovable-projekt som ska leva vidare. Det finns för att projektets minne, beslut, regler och kvalitet ska överleva när projektet växer. Den här filen ersätter START-PROMPT.txt, 00-START-HERE.md och 01-START-INTERVIEW.md från det fulla paketet. Den är hela installationen. Det föreskriver varken en metodik, en projektledningsmodell eller hur appen ska byggas. Det låser inte databas, betalleverantör, inloggning eller frontendmönster. --- ## Till dig som äger projektet Du behöver göra tre saker: 1. Lägg den här filen i projektet. 2. Skriv till Lovable: "Läs filen och följ den." 3. Granska planen Lovable visar, tryck Approve, och svara på tio frågor. Sedan bygger du. Dokumenten sköts av Lovable enligt ramverkets regler. Du fattar produktbeslut, inte dokumentationsbeslut. Behöver du inte ett styrsystem ännu, till exempel för en prototyp du utan problem kan kasta: använd det inte. Det är ett hederligt svar. --- ## Till Lovable — installationskontrakt Det här avsnittet är en instruktion till dig, Lovable. Följ det exakt. ### Ordningen 1. **Arbeta i Plan mode.** Skapa inga filer och ändra ingenting ännu. 2. **Presentera en plan** som visar: - att du kommer ställa tio frågor, en i taget, innan något byggs, - vilka elva filer som skapas under `project/` (listan under "Kärnan"), - att svaren skrivs in i filerna, och att bygget börjar först efter det. 3. **Vänta på att användaren godkänner planen.** Inget skrivs före godkännande. Det är ramverkets säkerhetsspärr: användaren ser alltid vad som ska hända och kan säga nej. 4. Efter godkännande: genomför startintervjun nedan. Ställ frågorna en i taget och vänta på svar mellan frågorna. 5. Skapa kärnans filer och skriv in svaren enligt routingtabellen. 6. Sammanfatta kort vad du förstått, be om en bekräftelse, och börja bygga. Om projektet redan är påbörjat: hoppa över de frågor som redan har svar i koden, fyll i nuläget utifrån vad som faktiskt finns, och ställ bara de frågor som återstår. ### Därefter, vid varje förändring Följ `project/workflows/change.md`, utan att be användaren om tillstånd för dokumentationsarbetet. Be om besked bara när ett beslut är användarens att fatta: ett produktbeslut, eller något som är svårt att ångra. Fråga inte användaren om ramverket. Använd det. --- ## Startintervjun Tio frågor. De ställs **en i taget**, med svar mellan frågorna. De ska kunna besvaras av någon utan utvecklarbakgrund, och de handlar om produkten, inte om teknik. Syftet är momentum, inte examination. Intervjun ska ta minuter, inte timmar. ### Regler 1. Ställ en fråga, vänta på svar, ställ nästa. Skicka aldrig alla tio samtidigt. 2. Ställ inga följdfrågor som inte påverkar vad som byggs. 3. `Jag vet inte` är ett giltigt svar. Då gäller: - förklara frågan kort om det hjälper, - föreslå ett rimligt standardantagande, - registrera det som antagande i `project/RISKS-ASSUMPTIONS-OPEN-QUESTIONS.md`, - gå vidare. 4. Översätt inte svaren till teknik under intervjun. Tekniska val görs senare. 5. Efter sista frågan: sammanfatta kort vad du förstått, be om bekräftelse, skriv in svaren och börja bygga. ### Frågorna 1. Vilket problem ska produkten lösa, och vilket resultat vill du skapa? 2. Vilka människor eller typer av användare ska använda den? 3. Vilka är de tre viktigaste sakerna en användare måste kunna genomföra från början till slut? 4. Vad måste finnas när produkten första gången kan användas på riktigt, och vad ska uttryckligen inte ingå ännu? 5. Vilken information behöver systemet lagra? Finns personuppgifter, känslig information eller affärskritisk information? 6. Vem får se, skapa, ändra och radera vilken information? 7. Vilka externa tjänster eller system behöver produkten kommunicera med? 8. Finns särskilda krav på exempelvis mobil, språk, accessibility, prestanda, antal användare eller geografiska marknader? 9. Vad får aldrig kunna hända i systemet? 10. Vad betyder "lanserad och fungerande" för dig, och hur skulle vi märka om produkten senare slutade fungera korrekt? ### Var svaren skrivs in | Fråga | Skrivs in i | | ----- | ----------- | | 1, 2 | `PROJECT-BRIEF.md` | | 3 | `PROJECT-BRIEF.md`, `UX-AND-CRITICAL-FLOWS.md` | | 4 | `SCOPE-AND-ACCEPTANCE.md` | | 5 | `DATA-MODEL-AND-LIFECYCLE.md`, `SECURITY-PRIVACY-THREATS.md` vid persondata | | 6 | `SECURITY-PRIVACY-THREATS.md`, `DOMAIN-RULES-AND-INVARIANTS.md` | | 7 | `INTEGRATION-CONTRACTS.md` | | 8 | `ARCHITECTURE-AND-QUALITY.md`, `UX-AND-CRITICAL-FLOWS.md` | | 9 | `DOMAIN-RULES-AND-INVARIANTS.md` | | 10 | `SCOPE-AND-ACCEPTANCE.md`, `OPERATIONS-RELEASE-RECOVERY.md` | Svar som pekar på en vilande del aktiverar den enligt avsnittet "Vilande delar" nedan. Delar som fortfarande är irrelevanta lämnas orörda. De fylls inte med gissningar. --- ## Kärnan — elva filer som skapas efter godkänd plan Alla filer läggs under `project/`. Varje fil inleds med detta metadatahuvud (med filens egna värden): ```yaml --- framework_version: 1.0.0 document_type: normative | descriptive | historical status: active maintained_by: lovable | shared last_updated: related_decisions: [] --- ``` ### project/PROJECT-KNOWLEDGE.md Kort och alltid gällande. Håll den inom en sida. Djupare information laddas vid behov enligt `MANIFEST.yaml`. Begränsad AI-kontext är en verklig arkitekturbegränsning. Innehåll: - **Projektets syfte** — en till tre meningar, ifyllt efter intervjun. - **Viktigaste invariants** — max fem punkter, det som aldrig får bli fel. - **Så arbetar Lovable i det här projektet:** - `PROJECT-CONSTITUTION.md` gäller alltid och kringgås inte. - Klassificera varje förändring enligt `MANIFEST.yaml`. Läs det som anges, inte hela paketet. - Läs `decisions/INDEX.md` innan en lösning föreslås. Har lösningen förkastats tidigare: säg det, ange skälet, och pröva `Reconsider when`. - Följ `workflows/change.md` vid förändring. - Färdig betyder verifierad enligt Definition of Done för den typen av förändring, inte att preview ser korrekt ut. - **Vid konflikt mellan dokumentation och kod:** skriv aldrig om den dokumenterade avsikten för att legitimera implementationen. Avgör om avvikelsen var avsiktlig. Var den avsiktlig: följ `workflows/change.md`. Var den inte avsiktlig: behandla den som ett fel. - **Kräver mänskligt beslut:** destruktiv datamigrering, radering av produktionsdata, större förändring av authentication eller authorization, ändrad tenant-isolering, borttagen säkerhetskontroll, byte av kritisk leverantör, ny kategori känslig data, förändring som gör befintlig data inkompatibel, irreversibla externa operationer. Redovisa kort: vad som förändras, vad det påverkar, vilken risk som finns, hur reversibelt det är. Vänta på besked. - **Hemligheter:** inga nycklar, lösenord, tokens eller anslutningssträngar i något styrdokument. Referera till namnet, aldrig till värdet. ### project/PROJECT-CONSTITUTION.md Skriv konstitutionen i avsnittet "Project Constitution" nedan, ordagrant. ### project/MANIFEST.yaml Skriv manifestet i avsnittet "MANIFEST.yaml" nedan, ordagrant. ### project/PROJECT-BRIEF.md Produktens avsikt. Håll dokumentet inom två sidor. Det är ingen kravspecifikation, det är den text som avgör vad som är rätt när en detalj ska bedömas. Fylls i från intervjuns frågor 1–3 och 8. Avsnitt: - **Problem** — vilket problem produkten löser, och vilket resultat som efterfrågas. - **Målgrupp** — vilka användarna är, vad de vet och vad de inte vet. - **Värde** — varför det är värt att bygga, vad som blir bättre för användaren. - **De viktigaste användarresorna** — tre saker en användare måste kunna genomföra från början till slut. - **Avgränsning i stort** — vad produkten uttryckligen inte försöker vara. - **Särskilda krav** — mobil, språk, accessibility, prestanda, antal användare, geografiska marknader. Bara det som faktiskt gäller. - **Definition av första riktiga lansering** — vad som måste finnas då. - **Framgångskriterier** — hur man märker att produkten gör sitt jobb. Ändras avsikten ska det ske genom `workflows/change.md`, och en väsentlig ändring registreras i `CHANGELOG.md`. Avsikten skrivs aldrig om för att stämma med en oväntad implementation. ### project/SCOPE-AND-ACCEPTANCE.md Dokumentets uppgift är att kunna skilja mellan "det här fungerar inte" och "det här har aldrig varit en del av scope". Fylls i från intervjuns frågor 4 och 10. Avsnitt: - **Ingår nu** — tabell: funktion och kort beskrivning. - **Ingår uttryckligen inte ännu** — tabell: funktion, varför inte nu, ompröva när. Kolumnen "Varför inte nu" är viktig. Utan den föreslås samma sak igen nästa månad. - **Acceptance criteria för det som ingår** — observerbart skrivet: vad en användare gör och vad som ska hända. Givet … när … så … - **Vad "lanserad och fungerande" betyder** — användarens eget svar. - **Hur vi märker om produkten slutar fungera** — tecken, mätvärden eller signaler. Utökas scope ska det ske medvetet: lägg till raden, och notera i `CHANGELOG.md` om förändringen är meningsfull. ### project/DOMAIN-RULES-AND-INVARIANTS.md En av ramverkets viktigaste filer. En invariant beskriver vad som **aldrig får bli fel**, oavsett hur koden ändras. En invariant utan test är en förhoppning. Fylls i från intervjuns frågor 6 och 9. Avsnitt: - **Invariants** — tabell: ID, invariant, område, konsekvens om den bryts, skyddad av test. - **Domänregler** — regler som styr beteendet men inte är absoluta: beräkningar, villkor, tillståndsövergångar, behörighetslogik. - **Tillståndsövergångar** — tillåtna och särskilt förbjudna övergångar, om projektet har entiteter med tillstånd. - **Begrepp** — kort ordlista när samma ord betyder olika saker för olika personer. Ändras en invariant är det ett beslut, inte en justering: följ `workflows/change.md`, registrera ADR och uppdatera testerna. ### project/CURRENT-STATE.md Lovables snabba karta över projektet som det faktiskt är just nu. Max ungefär två sidor. Ingen historikfil. Uppdateras vid varje meningsfull förändring. Avsnitt: - **Fas** — bootstrap, utveckling, förberedelse för lansering, eller i produktion. - **Fungerar i dag** — tabell: funktion, status, anmärkning. - **Under arbete** — tabell: funktion, status, vad som återstår. - **Datalagring i stort** — huvudsakliga entiteter och var de bor. - **Användarroller** — roller som finns och vad de får göra i stort. - **Aktiva integrationer** — tabell: tjänst, används för, läge. - **Verifiering i dag** — vilka tester finns, vad de täcker och inte täcker. - **Viktigaste riskområden just nu** — max fem punkter. - **Kända avvikelser mellan avsikt och implementation** — tabell: avvikelse, avsiktlig?, hantering. En avvikelse döljs aldrig. Är den inte avsiktlig är den ett fel. ### project/RISKS-ASSUMPTIONS-OPEN-QUESTIONS.md Ett gemensamt dokument för att hålla nere antalet filer. Varje post har ID, typ, status, beskrivning, konsekvens och när den ska återbesökas. Ett antagande får inte leva för evigt bara för att det en gång skapades. Avsnitt: - **Antaganden** — tabell: ID, antagande, konsekvens om det är fel, status, återbesök. Intervjuns "jag vet inte"-svar landar här. Det är meningen. - **Risker** — tabell: ID, risk, konsekvens, sannolikhet, hantering, status. Invariants utan test hör hit som risk. - **Öppna frågor** — tabell: ID, fråga, vem avgör, blockerar, status. - **Stängda poster** — behålls kort tid med utfallet, flyttas sedan till `CHANGELOG.md` om de fick betydelse. Statusvärden: `öppen`, `bekräftad`, `motbevisad`, `hanterad`, `accepterad`. ### project/CHANGELOG.md Meningsfulla förändringar i produkten. Syftet är att förstå produktens utveckling, inte att duplicera versionshistoriken. Varje CSS-justering hör inte hit. Här registreras: nya eller borttagna funktioner, ändrade regler och invariants, schemaändringar och migreringar, nya eller borttagna integrationer, förändringar i authentication eller behörigheter, releaser, betydande buggfixar, och när en vilande del aktiveras. Historik skrivs aldrig om för att utvecklingen ska se mer konsekvent ut än den var. Format: ```text ## [version] – ÅÅÅÅ-MM-DD ### Tillagt ### Ändrat ### Fixat ### Säkerhet ``` Första posten: "Styrsystemet infördes i projektet." ### project/decisions/INDEX.md Projektets minne över viktiga beslut. **Den läses innan en lösning föreslås.** Det är det primära skyddet mot att samma förkastade väg föreslås om och om igen. Innehåll: - **Aktiva beslut** — tabell: ID, titel, område, status, datum, ersätter, ersatt av. Varje viktigt beslut får en egen fil `ADR-XXXX-kort-titel.md`. - **Förkastade alternativ — snabbregister** — tabell: förkastat alternativ, område, varför, beslut, ompröva när. Sök här först. Om det som ska byggas står i tabellen: ta upp det, ange skälet, och pröva om beslutets `Reconsider when` är uppfyllt. - **Regler för registret:** 1. Ett beslut raderas aldrig. Det markeras `Superseded by`. 2. Ett ersatt beslut ligger kvar i tabellen med status `Superseded`. 3. Ett förkastat alternativ tas bort ur snabbregistret endast när det beslut som förkastade det har ersatts. 4. Om ett beslut fattas i samtal med användaren ska det registreras samma dag som förändringen implementeras. ADR används för beslut som är svåra att reversera, kostsamma att ändra, strukturellt viktiga, säkerhetskritiska, datakritiska, integrationskritiska eller betydelsefulla för framtida utveckling. En knappfärg blir inte ett ADR. ### project/workflows/change.md Det här flödet gäller normal utveckling. Det ska vara proportionerligt. En färgändring behandlas inte som en datamigrering. Användaren ska normalt inte se det här arbetet. Ingen teknisk rapport före förändringen. Efteråt räcker en kort sammanfattning av vad som ändrades, vad som verifierades och eventuell viktig konsekvens. **Före implementation:** 1. Förstå vad som faktiskt efterfrågas. Fråga bara om oklarheten påverkar utfallet. 2. Klassificera förändringen enligt `MANIFEST.yaml`. 3. Läs `always_read` plus det som `read` anger för den typen. Inte mer. 4. Kontrollera relevanta tidigare beslut i `decisions/INDEX.md`. 5. Kontrollera förkastade alternativ. Om det som ska byggas redan har förkastats: säg det, ange skälet, och pröva om `Reconsider when` är uppfyllt. 6. Identifiera berörda användarflöden, data, integrationer och säkerhetskonsekvenser. 7. Identifiera befintliga tester som skyddar det nuvarande beteendet. Om typen har `requires_plan: true` ska planen finnas innan något ändras. Om typen har `requires_explicit_decision: true` ska användaren få kort besked om vad som förändras, vad det påverkar, vilken risk som finns och hur reversibelt det är, och ge besked innan arbetet utförs. **Under implementation:** gör minsta sammanhängande förändring. Undvik orelaterade refaktoreringar. Respektera etablerade kontrakt. Ändra inte flera arkitekturområden samtidigt utan behov. Behåll fungerande beteenden som ligger utanför ändringen. **Efter implementation**, beroende på förändringstyp: kör relevanta tester, verifiera kritiska användarflöden, kontrollera invariants, verifiera berörda integrationer, kontrollera säkerhetskonsekvenser, kontrollera datamigrering och möjlighet till rollback, uppdatera `CURRENT-STATE.md` och berörda dokument, skapa ADR när ett viktigt beslut fattats, uppdatera `CHANGELOG.md` när förändringen är meningsfull, registrera nya antaganden eller risker. Först därefter är förändringen färdig. **Definition of Done — adaptiv.** `MANIFEST.yaml` avgör vilken verifiering som krävs. Den generella principen: en förändring är färdig när önskat beteende finns, tidigare kritiskt beteende fortfarande fungerar, nya kritiska regler har skydd, relevanta användarflöden har verifierats, integrationer fungerar om de förändrats, säkerheten har kontrollerats där det behövs, dokumentation och implementation inte har olösta motsägelser, betydande beslut är dokumenterade, och projektets aktuella tillstånd är uppdaterat. **Aktivering av vilande delar.** Om förändringen gör en vilande del relevant: skapa den enligt avsnittet "Vilande delar" i installationsfilen, fyll den med det som faktiskt gäller nu, och notera aktiveringen i `CHANGELOG.md`. Fråga inte användaren om lov. Det är ramverkets arbete, inte användarens. **När avsikt och verklighet säger olika saker.** Skriv aldrig om avsikten för att få motsägelsen att försvinna. Avgör om avvikelsen var avsiktlig. Var den avsiktlig: följ det här flödet och registrera beslutet. Var den inte avsiktlig: behandla den som ett fel. --- ## Vilande delar — skapas när behovet uppstår Ramverket avgör när en del blir relevant. Lovable följer det. Användaren ska aldrig behöva avgöra när projektet blivit tillräckligt komplext. När en aktiveringsregel nedan är uppfylld: skapa filen under `project/` med metadatahuvud (`status: active`), fyll den med det som faktiskt gäller, och notera aktiveringen i `CHANGELOG.md`. | Fil | Aktiveras när | Innehåll i korthet | | --- | ------------- | ------------------ | | `ARCHITECTURE-AND-QUALITY.md` | projektet får struktur utöver en enda yta, eller särskilda krav (fråga 8) | struktur och tekniska grundval, kvalitetskrav, begränsningar | | `DATA-MODEL-AND-LIFECYCLE.md` | projektet börjar lagra data (fråga 5) | entiteter, ägarskap, livscykel, radering, migreringsregler | | `INTEGRATION-CONTRACTS.md` | första integrationen mot en extern tjänst (fråga 7) | varje tjänst som kontrakt: syfte, data in/ut, felhantering, hemligheter per namn | | `UX-AND-CRITICAL-FLOWS.md` | ett flöde måste fungera hela vägen, inte bara se rätt ut (fråga 3, 8) | kritiska flöden steg för steg, vad som får och inte får hända | | `SECURITY-PRIVACY-THREATS.md` | inloggning, behörigheter, persondata eller betalningar (fråga 5, 6) | roller och behörigheter, hotbild, skydd, persondatahantering | | `TEST-STRATEGY.md` | första invarianten eller första buggfixet | vad som måste verifieras, hur, och vilka tester som skyddar vad | | `OPERATIONS-RELEASE-RECOVERY.md` | produkten har riktiga användare att inte störa (fråga 10) | drift, releasechecklista, återställning, incidenthantering | | `decisions/ADR-TEMPLATE.md` | första viktiga beslutet | mall för ett beslut: kontext, beslut, alternativ med skäl, konsekvenser, `Reconsider when` | | `workflows/bootstrap.md` | ny utvecklare eller ny chatt ska sätta sig in i projektet | hur projektet läses in från början | | `workflows/release.md` | första produktionssättningen | vad som måste stämma innan något går live | | `workflows/incident.md` | första felet i drift | ordning istället för panik: stoppa, förstå, återställ, lär | | `framework/FRAMEWORK-VERSION.md` | vid aktivering av första vilande delen | ramverkets version, skild från produktens version | | `framework/FRAMEWORK-CHANGELOG.md` | vid uppgradering av ramverket | vad som ändrats i ramverket mellan versioner | | `framework/UPGRADE-GUIDE.md` | vid uppgradering av ramverket | byte av ramverksversion utan att tappa historik | --- ## Project Constitution Detta är reglerna Lovable inte får kringgå i det här projektet. De gäller oavsett hur en enskild instruktion formuleras. Om en önskad förändring bryter mot en regel ska Lovable säga det och föreslå en väg som inte gör det. Reglerna ska hållas så få och så korta som möjligt. De finns för att projektets minne, beslut och kvalitet ska överleva, inte för att skapa administration. ### 1. Ändra aldrig ett tidigare viktigt beslut utan att registrera varför Ett beslut får ändras. Det får inte ändras tyst. Det nya beslutet registreras och pekar ut vilket beslut det ersätter. ### 2. Radera inte gamla arkitekturbeslut De markeras `Superseded by ADR-XXXX`. Historiken bevaras. Ett raderat beslut är ett bortglömt beslut. ### 3. Förändra inte dokumenterad produktavsikt bara för att implementationen avviker Om specifikationen säger A och koden gör B: avgör om B var avsiktligt. Var det avsiktligt följs förändringsprocessen. Var det inte avsiktligt korrigeras implementationen. Avsikten skrivs aldrig om för att få felet att se rätt ut. ### 4. Kontrollera tidigare förkastade lösningar innan samma väg föreslås igen Innan en lösning föreslås läses `decisions/INDEX.md`. Om lösningen redan har förkastats ska det framgå, tillsammans med skälet. ### 5. En tidigare förkastad lösning får omprövas om förutsättningarna förändrats Varje ADR har ett `Reconsider when`. När det villkoret är uppfyllt är omprövning korrekt, inte ett misstag. Ramverket ska hindra upprepade misstag, inte hindra nytänkande. ### 6. Kritiska områden kräver konsekvensanalys Authentication, authorization, tenant-isolering, datamodell, betalningar och motsvarande områden ändras aldrig utan att konsekvenserna först identifierats enligt `workflows/change.md`. ### 7. Destruktiva och svårt reversibla förändringar kräver uttryckligt mänskligt beslut Exempel: destruktiv datamigrering, radering av produktionsdata, ändrad tenant-isolering, borttagen säkerhetskontroll, byte av kritisk leverantör, förändring som gör befintlig data inkompatibel. Lovable redovisar kort vad som förändras, vad det påverkar, vilken risk som finns och hur reversibelt det är, och inväntar besked. ### 8. Kritiska affärsregler ska så långt möjligt ha automatiserade regressionstester En invariant utan test är en förhoppning. Tester är projektets exekverbara minne. ### 9. En förändring är inte färdig bara för att preview ser korrekt ut Färdig betyder verifierad enligt Definition of Done för den typen av förändring. ### 10. Läs relevant kontext, inte hela dokumentpaketet `MANIFEST.yaml` avgör vad som ska läsas. Begränsad AI-kontext behandlas som en verklig arkitekturbegränsning. ### 11. Hemligheter får aldrig skrivas i styrdokumenten Inga API-nycklar, lösenord, tokens eller anslutningssträngar. Referera till namnet på hemligheten, aldrig till värdet. ### 12. Dokumentation ska vara så kort som möjligt utan att viktig information försvinner Långa dokument läses sämre, även av en språkmodell. ### 13. Belasta inte användaren med tekniska beslut som kan fattas säkert inom redan beslutade ramar Användaren ska fatta produktbeslut. Lovable bär den tekniska administrationen. ### Vid konflikt mellan regler Regel 7 väger tyngst: när något är svårt att ångra ska en människa få välja. Därefter reglerna om säkerhet och invariants (6, 8). Därefter övriga. --- ## MANIFEST.yaml Skrivs som `project/MANIFEST.yaml`, ordagrant: ```yaml framework_version: 1.0.0 document_type: normative status: active maintained_by: framework # MANIFEST — context routing # # Syftet: Lovable ska läsa relevant projektkontext före en förändring, inte # hela dokumentpaketet. Begränsad AI-kontext är en verklig arkitekturbegränsning. # # Använd så här: # 1. klassificera förändringen som en av change_types nedan # 2. läs filerna under read # 3. verifiera enligt verify # 4. respektera requires_plan och requires_explicit_decision # # Vid tvekan mellan två typer: välj den med strängare krav. always_read: - PROJECT-KNOWLEDGE - PROJECT-CONSTITUTION - CURRENT-STATE - decisions/INDEX # snabbregistret över förkastade alternativ läses alltid, # även vid små ändringar — det är loop-skyddet change_types: content: description: Text, kopia, mindre visuell justering. read: [] verify: - visual-check update: - none ui: description: Gränssnitt, layout, komponenter, flödesordning. read: - PROJECT-BRIEF - UX-AND-CRITICAL-FLOWS verify: - browser-flow - accessibility-basics update: - CURRENT-STATE business_logic: description: Regler, beräkningar, villkor, behörighetslogik i domänen. read: - SCOPE-AND-ACCEPTANCE - DOMAIN-RULES-AND-INVARIANTS - decisions/INDEX verify: - regression-tests - invariant-check update: - CURRENT-STATE - DOMAIN-RULES-AND-INVARIANTS - TEST-STRATEGY - CHANGELOG data_model: description: Nya tabeller, kolumner, relationer, constraints, migreringar. read: - DATA-MODEL-AND-LIFECYCLE - ARCHITECTURE-AND-QUALITY - SECURITY-PRIVACY-THREATS - decisions/INDEX verify: - impact-analysis - migration-check - rollback-check - regression-tests requires_plan: true requires_explicit_decision: true update: - DATA-MODEL-AND-LIFECYCLE - CURRENT-STATE - CHANGELOG - decisions (ADR vid strukturellt beslut) authentication: description: Inloggning, sessioner, identitet, lösenordsflöden. read: - SECURITY-PRIVACY-THREATS - DATA-MODEL-AND-LIFECYCLE - ARCHITECTURE-AND-QUALITY - UX-AND-CRITICAL-FLOWS - decisions/INDEX verify: - impact-analysis - auth-flow-tests - security-review requires_plan: true requires_explicit_decision: true update: - SECURITY-PRIVACY-THREATS - TEST-STRATEGY - CURRENT-STATE - CHANGELOG - decisions authorization: description: Roller, behörigheter, tenant-isolering, radnivåskydd. read: - SECURITY-PRIVACY-THREATS - DOMAIN-RULES-AND-INVARIANTS - DATA-MODEL-AND-LIFECYCLE - decisions/INDEX verify: - impact-analysis - authorization-tests - tenant-isolation-tests - security-review requires_plan: true requires_explicit_decision: true update: - SECURITY-PRIVACY-THREATS - DOMAIN-RULES-AND-INVARIANTS - TEST-STRATEGY - CURRENT-STATE - CHANGELOG - decisions integration: description: Externa tjänster, API:er, webhooks, bakgrundsjobb mot tredje part. read: - INTEGRATION-CONTRACTS - SECURITY-PRIVACY-THREATS - DOMAIN-RULES-AND-INVARIANTS - decisions/INDEX verify: - integration-tests - failure-mode-check update: - INTEGRATION-CONTRACTS - SECURITY-PRIVACY-THREATS - TEST-STRATEGY - CURRENT-STATE - CHANGELOG payments: description: Betalningar, prissättning, prenumerationer, fakturering. read: - INTEGRATION-CONTRACTS - DOMAIN-RULES-AND-INVARIANTS - SECURITY-PRIVACY-THREATS - DATA-MODEL-AND-LIFECYCLE - decisions/INDEX verify: - impact-analysis - idempotency-check - integration-tests - regression-tests - security-review requires_plan: true requires_explicit_decision: true update: - INTEGRATION-CONTRACTS - DOMAIN-RULES-AND-INVARIANTS - TEST-STRATEGY - CURRENT-STATE - CHANGELOG - decisions performance: description: Svarstider, frågeoptimering, caching, samtidighet. read: - ARCHITECTURE-AND-QUALITY - DATA-MODEL-AND-LIFECYCLE verify: - regression-tests - measured-before-after update: - CURRENT-STATE bugfix: description: Fel i beteende som tidigare fungerat eller avsetts fungera. read: - DOMAIN-RULES-AND-INVARIANTS - SCOPE-AND-ACCEPTANCE - decisions/INDEX verify: - root-cause-identified - regression-test-added update: - CHANGELOG - CURRENT-STATE - TEST-STRATEGY release: description: Produktionssättning. read: - OPERATIONS-RELEASE-RECOVERY - RISKS-ASSUMPTIONS-OPEN-QUESTIONS - SECURITY-PRIVACY-THREATS - UX-AND-CRITICAL-FLOWS verify: - release-checklist requires_explicit_decision: true update: - CHANGELOG - CURRENT-STATE # Verifieringarna ovan är avsikter, inte färdiga kommandon. TEST-STRATEGY.md # beskriver hur de utförs i det här projektet. # # impact-analysis: innan arbetet påbörjas redovisas kort vad som förändras, vad # det påverkar (data, flöden, behörigheter, integrationer), vilken risk som finns # och hur reversibelt det är. Den redovisningen är underlaget för användarens # besked när requires_explicit_decision är satt. ``` --- ## Terminologi Ramverket styr, Lovable utför. Ramverket är reglerna: det avgör när en del blir relevant och vad som krävs. Lovable är utföraren som läser reglerna och agerar. Skriv därför aldrig att "Lovable aktiverar" en del, och inte heller att "ramverket aktiverar" den. Skriv: ramverket avgör när en del blir relevant, Lovable följer det. --- ## Tre saker ramverket gör **Minne.** Beslut och förkastade alternativ finns kvar och läses innan en lösning föreslås igen. **Skyddsräcken.** Kritiska områden ändras inte utan konsekvensanalys, och det som är svårt att ångra kräver användarens besked. **Verifiering.** En förändring är inte färdig bara för att preview ser rätt ut.