## Utforda steg (2026-05-20)

- [x] **Deploy-script uppdaterat:** `deploy.sh` forenklat genom att ta bort `--migrate`; `--clean-database` kor nu migrering explicit innan rensning.
- [x] **Prisma-integrering i deploy:** `--clean-database` kor `prisma migrate deploy` i `recipe-api` med explicit schema-parameter for att sakerstalla uppdaterat schema fore SQL-rensning.
- [x] **Loggsynlighet for Prisma Client:** `deploy.sh` visar nu output fran `npx prisma generate` i terminalen vid migreringsrelaterade deployfloden.
- [x] **Databasrensning standardiserad:** Ny underhallsfil `backend/prisma/maintenance/clean-database.sql` skapad for reset som bevarar kategorier.
- [x] **Produktionsnara fel rattat:** `clean-database.sql` korrigerad efter serverfel (`Table 'ShoppingList' doesn't exist`).
- [x] **Tabellista hardad:** SQL-filen anvander nu existerande tabeller i nuvarande Prisma-schema och tar bort beroenden i saker ordning med `FOREIGN_KEY_CHECKS`.

## Utförda steg (2026-05-21)

- [x] **Flyer AI-trace persisteras:** `AiFlyerParserService` returnerar trace-data (prompt/rawOutput/chunkCount/retryCount) och `FlyerImportService` sparar detta i `AiTrace` med `source=flyer`.
- [x] **Admin AI observability utökad:** `AiTraceService` hämtar kompletterande flyer-trace via `sessionId` och exponerar prompt/output/retry/chunk i detaljvyn.
- [x] **Maskning i trace-detail:** känslig data maskas konsekvent i prompt/raw output/normaliserad output innan retur till admin-UI.
- [x] **Flyer-kvalitet:** dedupe justerad för att minska dubletter utan att slå ihop olika kampanjer; hårdostnamn använder korrekt åäö.
- [x] **Kontextstyrd OCR-korrigering:** kända fel (ex. `Pröd`) korrigeras endast i relevant textkontext för att minska falska rättningar.
- [x] **Flutter Admin AI-panel UX:** selekterbar prompt/output, varningspanel med kopiering och output-trunkering med expandera/kollapsa.

# Nasta steg

Detta ar huvudroadmap for Recipe App.
All detaljhistorik och djup teknisk bakgrund finns i respektive tekniska dokument.

## Dokumentstatus (2026-05-03)

- Fokus: en gemensam prioriteringslista for produkt, utveckling och drift.
- Delplaner for underomraden ska referera hit, inte duplicera hela roadmapen.

## MVP-plan (2026-05-10)

MVP ar uppnadd nar en vanlig anvandare kan importera, granska och spara kvitto/recept utan manuella specialsteg, och admin kan underhalla produkt- och kategoridata stabilt i drift.

### Fas 1 - Scopefrysning och releasekandidater

1. Las MVP-scope till foljande floden:
   - Kvittoimport end-to-end (parse -> granska -> spara).
   - Receptimport end-to-end (url/pdf/ocr/markdown -> granska -> spara).
   - Admin inventarie/product-hantering (CRUD, merge, filter, restore).
2. Markera uttryckligen allt annat som post-MVP i denna fil (t.ex. EAN/Open Food Facts, utokad AI, storre webbsakerhetsomlaggning).
3. Faststall releasekandidat for backend + flutter med versionsetikett.

### Fas 2 - Hard validering i produktionslik miljo

1. Kor manuell verifiering av aliasstrategi med riktiga kvitton (privat alias, global fallback, prioriteringsordning).
2. Kor fulla regressionsfloden for import, matchning, kategorisering, merge och spara.
3. Verifiera deployflode och driftkommandon pa server med healthcheck efter release.

### Fas 3 - MVP-release

1. Publicera releasekandidat nar alla gransvarden ar godkanda.
2. Folj upp med kort hypercare-period (felrattning med hog prioritet, inga nya features).

### Exit-kriterier (Definition of Done for MVP)

- End-to-end importfloden fungerar stabilt for minst ett representativt urval av kvitton och receptkallor.
- Aliasprioritering fungerar deterministiskt: user alias -> global alias -> ordmatchning -> AI.
- User-scope och IDOR-skydd ar verifierat i kritiska domaner.
- Admin kan hantera produkter/inventarie utan datakorruption eller behov av manuella DB-ingrepp.
- Deploy, healthcheck och testkorning ar reproducerbara i driftmiljo.


## Nyligen klart

## Utförda steg (2026-05-19)

- [x] **Flyerimport-sessioner i backend:** Implementerat session-endpoints för senaste och specifik session.
- [x] **Flyerimport-persistens i Flutter:** Lättviktig lagring i `SharedPreferences` med `sessionId` + vald state.
- [x] **Hydreringsflöde i klient:** Restore lokalt -> hämta via sessionId -> fallback till latest-session.
- [x] **HTTP-semantik + optimering:** 404 för saknad session och single-query för latest-session.
- [x] **Regressionstester:** Backendtester för flyer-sessioner tillagda och gröna (3/3).

## Utförda steg (2026-05-18)

- [x] **ESLint i backend + CI:** ESLint-konfiguration tillagd i backend och CI-workflow uppdaterad med lint-step för PR/push.
- [x] **Dart lint-konfig aktiverad:** `flutter/analysis_options.yaml` tillagd för att säkerställa `flutter_lints` i analyskörningar.
- [x] **Prisma query logging styrbar per miljö:** `PRISMA_LOG_QUERIES` implementerad i backend samt kopplad i `compose.yml`.
- [x] **Dokumenterat aktivering av query-loggar:** Instruktion att sätta `PRISMA_LOG_QUERIES=1` och starta om `recipe-api` i test/staging.
- [x] **Korrigerat testförväntan i receipt-import:** Security-test för saknat användar-id uppdaterat till `UnauthorizedException`.

## Utförda steg (2026-05-13)

- [x] **Centralt hjälptextsystem (backend):** Nytt `HelpTextsModule` med service, controller och DTO. `GET /api/help-texts/:key` returnerar rätt hjälptext baserat på användarroll (prioritetsordning: admin → user → default). `PUT /api/help-texts/:key/:scope` kräver admin-roll.
- [x] **Prisma-migration:** `20260513150000_add_help_texts` — `HelpText`-tabell med `@@unique([key, scope])`-constraint och index. Seed-data för `receipt_import` (default + admin-scope) på svenska.
- [x] **Flutter — "Läs hjälp"-knapp:** `TextButton.icon` i receipt_import_tab hämtar hjälptext från backend och visar AlertDialog med scopeindikator och datum.
- [x] **Deploy och verifiering:** Migration tillämpad på produktionsserver (`recipe-api` ombyggd och omstartad). Backend och Flutter live och funktionellt.
- [x] **Copilot-instruktioner:** `.github/copilot-instructions.md` tillagd i samtliga tre repos med robust `.env`-läsningsmönster.

## Utförda steg (2026-05-12)

- [x] **Alias-scopehantering (admin):** Admin kan höja privat alias → globalt via PATCH-endpoint. Backend blockerar omvänd riktning utan owner (`BadRequestException`). Vanliga användare blockeras med `ForbiddenException`.
- [x] **Admin alias-UI:** Switch i edit-dialog begränsad till privat → global (låst om redan globalt). Temporär bekräftelse-chip visas 6 s i listan.
- [x] **Kategori-chip fallback:** "okänd"-chip borttagen globalt – fallback returnerar `SizedBox.shrink()`.
- [x] **Beroendehärdning:** Nest 11 + multer 2.1.1. `npm audit --audit-level=high` = 0 sårbarheter i recipe-app backend.
- [x] **Quality-gates:** `prisma:validate`, `typecheck`, `audit:high`, `quality:ci` tillagda som npm-scripts. CI kör nu typecheck i PR- och push-jobb.
- [x] **Tester:** Ny testtäckning för alias-scope i `receipt-alias.service.spec.ts` och `receipt-alias.security.spec.ts` (16/16 passerar).

## Utförda steg (2026-05-11)

- [x] Löste Flutter web build-fel och säkerställde att Docker-build går igenom på både lokal och server.
- [x] Dokumenterade rutiner för hantering av build-artifacts och merge-konflikter.
- [ ] Säkerställ att .gitignore exkluderar alla genererade Flutter-filer.

- **2026-05-10:** Admin-inventarie (CRUD, merge, filter, sortering, preview, säkerhet), user-scope, IDOR-skydd, säkerhetshärdning, optimeringar och utökad testtäckning är nu genomförda och dokumenterade i README, TEKNISK_BESKRIVNING, SÄKERHETSHÄRDNINGSPLAN och SESSIONLOGGAR.

- Kvittoimport: förbättrad antal/förpackningsinferens och robustare regelmotor.
- Kategorisering: utökade brödregler + contradiction guards och nya regler för pasta, grädde, ägg, juice, godis, och potatis.
- Kategoriträd: nya noder `Korvbröd` under `Fastfoodbröd` och `Grädde` under `Matlagning` i seed-data.
- Flutter: klientpersistens för pågående kvittoimport.
- Produktmodell: user-scoped produkter och seed renodlad till kategorier.
- Testinfrastruktur: parametriserade enhetstester för kvittoimport (18 testfall).
- CI/CD: GitHub Actions-pipeline för automatiserad testkörning vid push och pull request.
- **Node.js versionsparitet:** `package-lock.json` spåras nu i git för båda repos; Dockerfiles kör `npm ci` — reproducerbara byggen i alla miljöer.
- **PDF-kvittoimport stabiliserad:** `pdf-parse` CJS-fix + `pdfjs-dist/legacy` fallback löser `DOMMatrix`-fel i Node.js.
- **Felkods-forwarding fixad:** `receipt-import.service.ts` i recipe-api vidarebefordrar nu 503 från importer-api som `ServiceUnavailableException` istället för att alltid returnera 400.
- **AI-optimering (PDF):** `looksLikeReceiptProductLine()` i importer-api filtrerar bort header/footer-rader — Mistral anropas enbart för rader som faktiskt kan vara produkter.
- **Receptparser hardening:** gemensam parserutility, intervall/parantes/brak-forbattringar samt testtackning for parsern.
- **Receptsakerhet och dataintegritet:** aktiv-produktvalidering, transaktion vid update, orphan-fil-cleanup och striktare owner-hantering av legacy-recept.
- **Alternativa ingredienser (Option A):** lagring i `alternativeProductIds` (JSON), matchning mot flera alternativ och lagerkoll som inkluderar alternativ.
- **Flutter felhantering:** kopierbara felmeddelanden i snackbar + global textselektion for enklare support/felsokning.
- **Kvittoimport — Simplified Matching Logic (2026-05-09):** Unified matcher som konsoliderar product matching + categorization i en explicit flödestre. Eliminar split mellan `matchProducts()` och `enrichWithAiCategories()`. Ger tydligare trace-logging och bättre debuggability för varför ett item matchades på ett visst sätt. Systemet är nu mer underhållsbart och framtida förbättringar på matching/kategorisering går snabbare.

## Huvudprioriteringar

1. 🟡 Aliasstrategi i kvittoimport: DELVIS GENOMFÖRD (2026-05-09)
    - Målbild:
       - Vanliga användare skapar och använder privata alias som bara gäller deras egna importer.
       - Admin kan dessutom skapa globala alias som fungerar som fallback för alla användare.
       - Matchningsordning ska alltid vara: user alias -> global alias -> vanlig produktmatchning.
    - Genomfört nu:
       - Gemensam aliasnormalisering införd för lookup, upsert och alias-inlärning.
       - Guardrails införda för tomma alias och brusalias som `rabatt`, `summa`, `pant`.
       - Receipt import lär inte längre in alias automatiskt; användaren måste välja det explicit i edit-dialogen.
       - Aliasöversikter i Flutter visar nu scope tydligare (`privat` vs `global fallback`).
       - Tester tillagda för normalisering, prioritet och behörighet.
    - Kvar:
       - Manuell verifiering i produktionslik miljö av aliasflödet under riktig receipt import.
       - Eventuell vidareutveckling av separat aliasöversikt om behov uppstår.
    - Backend:
       - Centralisera normalisering av `receiptName` så samma regler används i lookup, upsert och alias-inlärning.
       - Härda guardrails för alias: blockera tomma alias, uppenbart brus (`rabatt`, `summa`, `pant`) och andra olämpliga kvittonamn.
       - Säkerställ deterministisk prioritet mellan privata och globala alias i receipt-import.
       - Behåll nuvarande schema i första fasen; ingen ny migration behövs så länge nuvarande `ReceiptAlias`-modell räcker.
    - Flutter:
       - Lägg alias-lärande nära manuell korrigering i receipt-import så användaren explicit kan välja att spara matchningen för framtida importer.
       - Lägg en enkel aliasöversikt där användaren kan se och ta bort sina privata alias.
       - Admin-UI ska kunna skapa globala alias utan att blanda ihop dem med vanliga användares privata alias.
    - Tester:
       - Verifiera att user alias alltid prioriteras före global alias för samma `receiptName`.
       - Verifiera att global alias används när user alias saknas.
       - Verifiera att vanlig användare inte kan skapa globala alias eller ta bort andras alias.
       - Verifiera att manuell korrigering + `learnAlias` ger direkt träff vid nästa import.
       - Verifiera att normalisering gör alias robust mot versaler, whitespace och enklare stavningsvariationer.
    - Leveransordning:
       - ✅ Fas 1: backend-hardening + tester.
       - ✅ Fas 2: UI-stöd i receipt import för alias-inlärning.
       - 🟡 Fas 3: separat aliasöversikt för användare och admin (grund finns, kan vidareutvecklas vid behov).
2. ✅ **[CLEANUP] Receipt import legacy code (2026-05-09):** KLART
   - Borttaget: `matchProducts()`, `enrichWithAiCategories()`, `findWordMatch()` (gammal), m.fl.
   - Tester uppdaterade och gröna (66/66)
   - Se `SESSION_2026-05-09_RECEIPT_IMPORT.md` för detaljer
3. ✅ **[FEATURE] Product Management & Scroll Fix (2026-05-09):** KLART
   - Scroll-issue i kvittoimport fixat (7 rader nu synliga)
   - Admin rename/merge endpoints implementerade
   - Private rename/merge endpoints för users implementerade
   - Kodduplicering i products.service.ts eliminerad (~80 rader)
   - admin_products_panel optimerad (cache, parallell restore, expression switches)
   - Deploy-script förbättrad med selektiv build och seed-kontroll
   - Se `SESSION_2026-05-09_RECEIPT_IMPORT.md` för detaljer
   - **Todo:** Deploy till prod, testa i live miljö, ev. add UI för user private rename/merge
4. Verifiera flyerimportens sessionhydrering end-to-end i test/staging (tab-byte + app-omstart).
5. Lägg till retention-policy och schemalagd rensning för `AiTrace` (receipt/flyer) för att styra datalivslängd i produktion.
6. Lägg till API-stöd för filtrering av trace-lista på `status` och fri textsökning i varningskoder.
7. Lokalisera kvarvarande stora Flutter-vyer i import/inventarie.
8. Förbereda avancerad AI-integration med tydlig loggning/audit.
9. Påbörja EAN-stöd via Open Food Facts.

## Beslut som styr arbetet

- User-scope for data som ar personligt agd.
- Backend-kontrakt ar sanningskalla; klienter foljer kontrakten.
- Importfunktionalitet ar delegerad till microservice-importer dar det ar beslutat.

## Framtida förbättringsområden

### Säkerhet: httpOnly cookies för Flutter Web

Idag lagras JWT-token i localStorage via SharedPreferences i Flutter Web. För att minska XSS-risk bör backend och Flutter Web stödja httpOnly-cookies för tokens. Detta kräver:
- Backend: endpoint för att sätta och läsa httpOnly-cookie vid login.
- Flutter Web: anpassning så att token inte läses från localStorage utan session hanteras via cookie.
Detta är en större arkitekturändring och endast relevant för webben.

### Säkerhet: Gitea webhook-signaturvalidering

Om Gitea-webhooks används, implementera endpoint i backend som validerar `X-Gitea-Signature` med timing-safe jämförelse. Lägg till `GITEA_WEBHOOK_SECRET` i .env.example. Se säkerhetshärdningsplanen för kodexempel.

### Alternativa ingredienser — migrering till relationsmodell (Option B)

Nuläge: `RecipeIngredient.alternativeProductIds` lagras som JSON-kolumn (Option A).
Detta fungerar men saknar referensintegritet — om en alternativ produkt tas bort uppdateras inte kolumnen automatiskt.

Framtida lösning: Ersätt JSON-kolumnen med en separat tabell:
```prisma
model RecipeIngredientAlternative {
	id                 Int              @id @default(autoincrement())
	recipeIngredientId Int
	recipeIngredient   RecipeIngredient @relation(fields: [recipeIngredientId], references: [id], onDelete: Cascade)
	productId          Int
	product            Product          @relation(fields: [productId], references: [id], onDelete: Cascade)
}
```
Fördelar: FK-integritet, möjlig sortering/prioritering av alternativ, lättare att querrya.
Förutsättning: migration som konverterar befintlig JSON-data till rader i tabellen.

## Relaterade dokument

- `README.md` - anvandarperspektiv.
- `TEKNISK_BESKRIVNING.md` - teknisk huvudreferens.
- [produktlansering.md](_archive/docs/produktlansering.md) - releasechecklista i arkiv.
- [migrering-MSI.md](_archive/docs/migrering-MSI.md) - migreringshistorik for importer i arkiv.
- [flutter/next_steps_flutter.md](_archive/docs/flutter/next_steps_flutter.md) - Flutter-specifik plan i arkiv.
- `_archive/microservice-ai/AI-FUNKTIONER.md` - AI-strategi och historik.

## 2026-05-10: Admin-inventarie (CRUD, merge, filter, sortering, preview, säkerhet), user-scope, IDOR-skydd, säkerhetshärdning, optimeringar och utökad testtäckning är nu genomförda och dokumenterade i README, TEKNISK_BESKRIVNING, SÄKERHETSHÄRDNINGSPLAN och SESSIONLOGGAR.
