diff --git a/README.md b/README.md
index 760d687..c3351e3 100644
--- a/README.md
+++ b/README.md
@@ -62,6 +62,7 @@ Prosjektet kan testes med kommandoen `pnpm test:run`.
 Fra prosjektbeskrivelsen er det krav om "ingen feilmeldinger eller advarsler ved linting", og at koden skal formatteres med `prettier`.
 
 Dette kan sjekkes med følgende kommandoer:
+
 ```bash
 # sjekk linting
 pnpm lint
@@ -135,7 +136,7 @@ Når man har lagt inn denne skal prosjektet kunne kjøre lokalt, og api-kall ska
 > Filen `.env.local` er derfor lagt til i `.gitignore`.
 
 > [!NOTE]
-> Vi vurderte å sette opp en reverse-proxy på serveren for å skjule api-token helt, men dette 
+> Vi vurderte å sette opp en reverse-proxy på serveren for å skjule api-token helt, men dette
 > ble unødvendig komplekst for prosjektets omfang. Fordi Vite bygger inn alle 'Vite_'-prefikser inn i
 > prosjektfilene vli api-tokenet teknisk sett være synlig for alle som inspiserer api-kallene.
 > Vi anser risikoen som lav i dette tilfellet ettersom serveren kjører på en VM på ntnu sitt låste nettverk
@@ -312,22 +313,23 @@ Hjerteknappen som markerer en film som favoritt. Eier ingen state selv, men får
 
 ###### MovieDetails.tsx + MovieDetails.css
 
-Detaljvisningen som legger seg over siden når man åpner en film. Viser backdrop, tittel, utgivelsesdato, vurdering, sammendrag og skuespillere, og henter skuespillerne via `useMovieCredits` på samme måte som kortet — så cachen deles og det blir ikke et nytt kall. 
+Detaljvisningen som legger seg over siden når man åpner en film. Viser backdrop, tittel, utgivelsesdato, vurdering, sammendrag og skuespillere, og henter skuespillerne via `useMovieCredits` på samme måte som kortet — så cachen deles og det blir ikke et nytt kall.
 
 ###### SortFilterBar.tsx + SortFilterBar.css
+
 Raden med sorteringsvalg og minimumsvurdering, vises på søkesiden. En
 nedtrekksmeny og en slider, begge egenutviklet uten tredjepartsbibliotek.
 Komponenten eier ingen state selv, den får verdier og callbacks som props fra
 App.tsx. Selve sorteringen skjer i sortAndFilterMovies, ikke her.
 
 ###### TrendingPreview.tsx + TrendingPreview.css
+
 Banneret øverst på forsiden. Viser én film om gangen med pil til venstre og
 høyre, og bytter automatisk hvert femte sekund. Tre bilder ligger side om side i
 en track som flyttes med translateX, så overgangen blir en glidende animasjon i
 stedet for et hopp. Klikk midt på banneret åpner detaljvisningen. Pilene og
 midtfeltet er button-elementer med aria-label, siden de ikke har synlig tekst.
 
-
 #### hooks
 
 ###### useMovieCredits.ts
@@ -343,14 +345,13 @@ En generisk, gjenbrukbar hook som fungerer som `useState`, men som leser fra og
 Vil returnere true eller false for en media query, i mine tilfeller var dette ved bruk av (max-width:700px), som lar meg si at hvis noen åpner ned en brudde under 700px så rendre den riktige menyen. useState passer her på at riktig verdi settes før første render, slik at det ikke skal vises feil visning først. useEffect henger på via window.matchMedia, og return funksjonen fjerner lytteren igjen. uten det hoper lytterne seg opp for hver rendring.
 Da desktop og mobil har ulik DOM struktur trenger vi dette både i JSX og CSS og ikke bar ei CSS. I desktop som sagt tidligere ligger undermenyen i HOME og på mobil ligger alle fire knappene flatt på bunnen ved siden av hverandre. Dette vil ikke CSS kunne gjøre.
 
-
 ##### useFavorites.ts
 
 Holder lista over favoritt-id-er og lagrer den i localStorage under nøkkelen favorites-movies. Kun id-ene lagres og ikke hele filmobjektet. Dette er fordi at den skal ikke mellomlagre API-data og lagrede filmer kunne blitt utdatert. Lista leses ved første render og en `useEffect` skriver tilbake når den endrer seg.
 
 ###### useDebouncedValue.ts
 
-En generisk hook som forsinker en verdi til den har vært uendret i et gitt antall millisekunder. Brukes på søketeksten med 400ms. Hvis denne ikke hadde blitt brukt hadde man sendt et API-kall for hver bokstav man trykker inn. Dette gjør at man kun sender et API-kall, ikke flere.  
+En generisk hook som forsinker en verdi til den har vært uendret i et gitt antall millisekunder. Brukes på søketeksten med 400ms. Hvis denne ikke hadde blitt brukt hadde man sendt et API-kall for hver bokstav man trykker inn. Dette gjør at man kun sender et API-kall, ikke flere.
 
 ###### useMovies.ts
 
@@ -361,12 +362,15 @@ Samler alle filmspørringene mot TMDB.øke-spørringen har `enabled: query.trim(
 Layout-komponentene setter sammen seksjoner og bestemmer hva som vises i hovedområdet. `App.tsx` velger mellom dem ut fra tilstand, slik at `App` slipper å inneholde tre ulike JSX-trær.
 
 ###### MainLayout.tsx
+
 Forsiden: hero-karusell med trending filmer, og seksjoner for populære og nye filmer.
 
 ###### SearchLayout.tsx
+
 Vises så snart søkefeltet har innhold. Rendrer `SortFilterBar` over søkeresultatene og kjører `sortAndFilterMovies` på treffene før de sendes til `MovieList`.
 
 ###### FavoritesLayout.tsx
+
 Favorittsiden. Får `favoriteIds` inn og henter filmene på nytt via
 `useFavoriteMovies`. Viser "Du har ingen favoritter ennå." når lista er tom, i stedet for en blank side.
 
@@ -416,16 +420,17 @@ regner som om adresselinja i mobilnettleseren ikke finnes, så bunnen av kortet
 ## Tilgjengelighet
 
 Prinsippet gjennom appen er at alt som kan klikkes på også skal kunnes nå ved tastatur og gi mening for en nettleser. I praksis betyr det at interaktive elementer er
-ekte `<button>`-elementer, ikke `<div>` med `onClick` 
+ekte `<button>`-elementer, ikke `<div>` med `onClick`
 
 **Filmkortet** er en `<article>` med tittelen i en `<button>` inni `<h3>`. Knappen har en `::after {inset: 0 }` som gjør at treffområdet trekkes over hele filmkortet ved hjelp av mus. Fokusringen flyttes ut til kortkanten med `:has(...)`, siden en
 ring rundt teksten alene ikke viser tydelig hvilket kort som er valgt.
 
-I **Detaljvisningen** blir fokus flyttet inn i dialogen ved åpning, og Escape lukker den slik at den kan lukkes uten mus. 
+I **Detaljvisningen** blir fokus flyttet inn i dialogen ved åpning, og Escape lukker den slik at den kan lukkes uten mus.
 Fokus flyttes inn i dialogen ved åpning og tilbake til kortet den ble åpnet fra ved lukking, og en fokusfelle holder Tab inne i dialogen så lenge den er åpen. Escape lukker, slik at den kan forlates uten mus. `body.modal-open` låser scroll bak overlayet.
 Ellers brukes semantiske elementer gjennomgående — `<main>` `<article>` per filmkort og `<h2>`/`<h3>` i riktig rekkefølge — slik at overskriftsnavigasjon i en skjermleser gir en meningsfull struktur.
 
 ## Git-arbeidsflyt
+
 Gjennom hele prosjektet har vi forsøkt å bruke git i henhold til anbefalingene som ligger på canvas. Vi har i hovedsak opprettet en ny lokal branch hver gang vi skal jobbe, og så push-et endringene opp til ny branch på github, og sammen gått gjennom endringer og godkjent pull-request.
 
 Det var mye usikkerhet i starten hvordan vi var ment å bruke git, bl.a. angående `issues`. Dette begynte vi å benytte litt senere i prosjektet for å holde oversikt over hvilke oppgaver som fortsatt måtte gjøres.
@@ -442,34 +447,37 @@ Det var mye usikkerhet i starten hvordan vi var ment å bruke git, bl.a. angåen
 
 #### Leona
 
-KI (Claude, Anthropic) ble brukt til å foreslå strukturen på filmkortet: hvilke props komponenten burde ta imot (movieId, title, posterUrl, rating) versus hva den burde hente selv. Forslaget var at kortet henter skuespillerne sine via useMovieCredits(movieId) internt, i stedet for at forelderen henter og sender ned skuespillerlisten som en egen prop. Dette holder MovieList enkel og fri for ansvar den ikke trenger.
+Jeg har brukt Claude (Anthropic) som støtte gjennom prosjektet, spesielt i arbeidet med filmkort-komponenten, filmlisten og styling.
+
+Jeg brukte KI til å tenke gjennom strukturen på filmkortet: hvilke props komponenten burde ta imot (movieId, title, posterUrl, rating) versus hva den burde hente selv. Vi landet på at kortet henter skuespillerne sine via useMovieCredits(movieId) internt, i stedet for at forelderen henter og sender ned skuespillerlisten som egen prop. Dette holder MovieList enkel og fri for ansvar den ikke trenger.
 
-KI ble brukt til å foreslå ansvarsdelingen mellom MovieList og resten av appen: MovieList skal kun rendre en liste med MovieCard-komponenter ut fra en ferdig hentet movies-prop, og skal ikke vite noe om TMDB, fetching, lasting eller feilhåndtering — det ansvaret ligger i hookene (useMovies.ts m.fl.) og i Section-komponenten. Denne separasjonen ble foreslått av KI som god praksis for å holde komponentene testbare og gjenbrukbare hver for seg.
+Jeg diskuterte også ansvarsdelingen mellom MovieList og resten av appen med KI: MovieList skal kun rendre en liste med MovieCard-komponenter ut fra en ferdig hentet movies-prop, og skal ikke vite noe om TMDB, fetching, lasting eller feilhåndtering - det ansvaret ligger i hookene (useMovies.ts m.fl.) og i Section-komponenten. Denne separasjonen fikk jeg forslått som god praksis for å holde komponentene testbare og gjenbrukbare hver for seg.
 
-KI foreslo også staleTime: 1000 * 60 * 60 (én time) som en fornuftig cache-varighet, med begrunnelsen at skuespillerlister for en film praktisk talt aldri endrer seg i løpet av en brukerøkt. Dette var spesielt viktig fordi hvert MovieCard gjør sitt eget kall til /credits-endepunktet — uten caching ville samme film blitt hentet på nytt hver gang kortet ble rendret på nytt, noe som kunne gått på bekostning av kravet om å unngå unødvendige API-kall.
+Jeg spurte KI om en fornuftig cache-varighet for skuespillerdata, og landet på staleTime: 1000 * 60 * 60 (én time), med begrunnelsen at skuespillerlister for en film praktisk talt aldri endrer seg i løpet av en brukerøkt. Dette var spesielt viktig fordi hvert MovieCard gjør sitt eget kall til/credits-endepunktet - uten caching ville samme film blitt hentet på nytt hver gang kortet ble rendret på nytt, noe som kunne gått på bekostning av kravet om å unngå unødvendige API-kall.
 
-Løsningen (hook, ren funksjon for sortering/filtrering, UI-komponent og kobling i `App.tsx`) ble utviklet i samarbeid med Claude (Anthropic). KI ble brukt til å foreslå arkitektur (separasjon mellom persistens-hook, ren logikk-funksjon og presentasjonskomponent), generere startkode, og til å vurdere om løsningen faktisk dekket prosjektkravene til filtrering/sortering og bruk av Web Storage API. Koden er gjennomgått og forstått av gruppen før den ble tatt i bruk.
+I tillegg brukte jeg KI til å:
 
-KI ble også brukt til å:
+- foreslå lastetilstand ("Laster skuespillere...") mens useMovieCredits henter data, slik at brukeren får tilbakemelding i stedet for et tomt felt
+- generere responsiv styling i MovieCard.css, inkludert plassering av rating-badge, layout med plakat til venstre/info til høyre, og tilpasning under @media (max-width: 480px)
+- generere logikken for å bygge full plakat-URL fra TMDB sin poster_path, inkludert fallback til tom streng når poster_path er null (for å unngå en ødelagt bilde-URL som .../w200null)
 
-1. Foreslå lastetilstand ("Laster skuespillere...") mens useMovieCredits henter data, slik at brukeren får tilbakemelding i stedet for et tomt felt
-2. Generere responsiv styling i Movie_card.css, inkludert plassering av rating-badge, layout med plakat til venstre/info til høyre, og tilpasning under @media (max-width: 480px)
-3. Gjennomgå og forstått av gruppen før den ble tatt i bruk, og tilpasset til resten av prosjektets struktur (bl.a. typene fra types/tmdb.ts).
-4. Generere logikken for å bygge full plakat-URL fra TMDB sin poster_path, inkludert fallback til tom streng når poster_path er null (for å unngå en ødelagt bilde-URL som .../w200null)
-5. Foreslå omregningen fra TMDB sin vote_average (skala 0–10) til prosent (0–100) som vises i UI
-6. Sette opp det responsive grid-oppsettet i MovieList.css (repeat(auto-fill, minmax(320px, 1fr))), som går til én kolonne på mobil
+Jeg gikk gjennom og forsto koden KI foreslo før jeg tok den i bruk, og tilpasset den til resten av prosjektets struktur (bl.a. typene fra types/tmdb.ts).
+
+Erfaringer:
+
+KI var mest nyttig når jeg allerede hadde tenkt gjennom problemet selv og kunne stille et konkret spørsmål, for eksempel om ansvarsfordeling mellom komponenter eller cache-strategi: da fikk jeg ikke bare et forslag men også begrunnelsen bak, noe som gjorde det lettere å vurdere om løsningen faktisk passet. jeg merket at KI noen ganger foreslo løsninger som var litt større eller mer generelle enn det jeg egentlig trengte, så jeg måtte være bevisst på å teste og forstå koden før jeg tok den i bruk, i stedet for å kopiere den rett inn. Spesielt på styling var KI til god hjelp, siden responsiv CSS med flere brytningspunkter var noe jeg ikke hadde mye erfaring med fra før. Alt jeg har brukt fra KI er lest gjennom, forstått og testet manuelt før det ble commitet.
 
 #### Johannes
 
-Jeg har hovedsakelig brukt Claude (Anthropic) gjennom hele prosjektet. Jeg har brukt KI som en støttepartner, i hovedsak til tre ting: å forstå React og tilgjengelighetsmønstre jeg ikke kunne fra før, å feilsøke, og å gå kritisk gjennom kode og dokumentasjon i forhold til kravene. Min bruk av KI så slik ut: Jeg kom med en spesifikk problemstilling som jeg ikke visste hvordan jeg skulle løse, KI kommer med eventuelle løsninger, jeg prøver å skrive koden og teste den før vi eventuelt går videre. Dette gjorde at jeg fikk kontroll over all kode som var lagt til, og dermed hadde jeg forståelse og kunne ta ansvar for hva som hadde blir lagt til.På de delene jeg har hatt hovedansvar for, søk, favoritter og tilgjengelighet, gikk det konkret ut på ting som dette: 
+Jeg har hovedsakelig brukt Claude (Anthropic) gjennom hele prosjektet. Jeg har brukt KI som en støttepartner, i hovedsak til tre ting: å forstå React og tilgjengelighetsmønstre jeg ikke kunne fra før, å feilsøke, og å gå kritisk gjennom kode og dokumentasjon i forhold til kravene. Min bruk av KI så slik ut: Jeg kom med en spesifikk problemstilling som jeg ikke visste hvordan jeg skulle løse, KI kommer med eventuelle løsninger, jeg prøver å skrive koden og teste den før vi eventuelt går videre. Dette gjorde at jeg fikk kontroll over all kode som var lagt til, og dermed hadde jeg forståelse og kunne ta ansvar for hva som hadde blir lagt til.På de delene jeg har hatt hovedansvar for, søk, favoritter og tilgjengelighet, gikk det konkret ut på ting som dette:
 
-- at søket burde ha en debounce slik at det ikke sendes ett API-kall per tastetrykk 
+- at søket burde ha en debounce slik at det ikke sendes ett API-kall per tastetrykk
 - at favoritter hører hjemme i localStorage og ikke sessionStorage fordi de skal overleve at nettleseren lukkes
 - at det ikke holdt med en `<div>` for å få fikse tilgjengelighetfunskjon, det måtte være en `<button>`
 
 Erfaringer:
 
-KI var definitivt mest nyttig når jeg hadde et konkret problem og kunne stille et presist spørsmål. Da fikk jeg hjelp til løsning og begrunnelsen på hvorfor, noe som hjalp meg med videre vurdering, da jeg fikk bedre forståelse for det selv. Jeg måtte være veldig tydelig på hvordan jeg ville jobbe. Det var et par ganger da Claude gikk inn og forandret kode selv, noe som jeg ga tilbakemelding på at den ikke skulle. Noe annet som er verdt å merke seg. KI tar seg ofte friheter og kommer med løsninger utover hva du faktisk har spurt den om. Dette kan være bra fordi da kan du vite hva neste steg er, men kan også være veldig irriterende hvis den ikke greier å løse det du egentlig spurte om. All kode er lest gjennom og forstått før den er tatt i bruk, og endringene er testet manuelt. 
+KI var definitivt mest nyttig når jeg hadde et konkret problem og kunne stille et presist spørsmål. Da fikk jeg hjelp til løsning og begrunnelsen på hvorfor, noe som hjalp meg med videre vurdering, da jeg fikk bedre forståelse for det selv. Jeg måtte være veldig tydelig på hvordan jeg ville jobbe. Det var et par ganger da Claude gikk inn og forandret kode selv, noe som jeg ga tilbakemelding på at den ikke skulle. Noe annet som er verdt å merke seg. KI tar seg ofte friheter og kommer med løsninger utover hva du faktisk har spurt den om. Dette kan være bra fordi da kan du vite hva neste steg er, men kan også være veldig irriterende hvis den ikke greier å løse det du egentlig spurte om. All kode er lest gjennom og forstått før den er tatt i bruk, og endringene er testet manuelt.
 
 #### Clemens
 
@@ -485,7 +493,7 @@ KI er brukt til:
 
 Erfaringer:
 
-KI var klart best på feilsøking. Flere av feilene vi hadde var slik at ingenting kom opp i terminal, og det er nesten umulig å google. Da var KI en super hjelp da den kunne få en bedre oversikt over filene noe som var fint når vi var flere som jobbet samtidig. 
+KI var klart best på feilsøking. Flere av feilene vi hadde var slik at ingenting kom opp i terminal, og det er nesten umulig å google. Da var KI en super hjelp da den kunne få en bedre oversikt over filene noe som var fint når vi var flere som jobbet samtidig.
 
 Jeg tok med først god tid til å fortså kode som KI foreslo slik at jeg fikk utbytte av lærestoffet og ikke bare kopierte og limte inn koden. Det å få Claude til å forklare koden til meg først hjalp også meg med å kunne gjøre små endringer senere uten bruk av KI, samt å kunne justere koden til KI før jeg pushet og merget det til main.
 
@@ -495,9 +503,7 @@ Det som ikke var like bra ved bruk av KI var når den ville gjøre veldig store
 
 Når jeg hadde problemer med min personlige kode, spurte jeg Claude også om å gi meg flere alternativ til problemet og ikke bare ett sett med kode. Dette lærte meg nyansene og de forskjellige måtene jeg kunne håndtere feil i koden på, uten å føle at KI gjorde alt for meg.
 
-Ki hjalp også med testene. Det å la KI hjelpe ved lagingen hjalp oss også med å finne ekte feil i koden. Vi merket da at MovieList manglet key, og MovieCard sender en tom streng som src når en film ikke har plakat. Begge ga advarsler som var nyttige for å feilsøke og fikse. 
-
-
+Ki hjalp også med testene. Det å la KI hjelpe ved lagingen hjalp oss også med å finne ekte feil i koden. Vi merket da at MovieList manglet key, og MovieCard sender en tom streng som src når en film ikke har plakat. Begge ga advarsler som var nyttige for å feilsøke og fikse.
 
 #### Albert
 
@@ -523,4 +529,4 @@ Dette prosjektet har brukt Claude (Anthropic) som støtte gjennom utviklingspros
 **Oppsummert:** KI er brukt til prosjektplanlegging, komponentarkitektur, feilsøking, API-sikkerhet, styling og CI/CD-oppsett. All kode er gjennomgått og forstått før den er tatt i bruk.
 
 **Erfaringer:**
-KI var nyttig gjennom hele prosjektet, spesielt til å effektivisere lesing av dokumentasjon — i stedet for å lese gjennom store mengder API- eller bibliotek-dokumentasjon selv, kunne KI raskt oppsummere det som var relevant. Den var også til hjelp for å finne kilder og eksempler på hvordan ting bør gjøres, både i form av beste praksis og alternative løsninger å vurdere. På den tekniske siden ga KI god generell støtte med TypeScript-syntaks (typing, generics, korrekt bruk av interfaces/types), og fungerte som en rask referanse for kommandoer man ellers måtte slått opp (git, npm/pnpm, deploy-relaterte kommandoer). Ved konkret feilsøking — som import-feil i React-komponenter, PATH-problemer i deploy-scriptet, var KI effektiv til å peke ut sannsynlig årsak og forslag til løsning, noe som sparte tid sammenlignet med å feilsøke fra bunnen selv. Samtidig var det nødvendig å alltid kvalitetssikre og teste forslagene selv, siden KI ikke alltid traff riktig på første forsøk og enkelte ganger krevde oppfølgingsspørsmål eller mer kontekst for å komme til en fungerende løsning.
\ No newline at end of file
+KI var nyttig gjennom hele prosjektet, spesielt til å effektivisere lesing av dokumentasjon — i stedet for å lese gjennom store mengder API- eller bibliotek-dokumentasjon selv, kunne KI raskt oppsummere det som var relevant. Den var også til hjelp for å finne kilder og eksempler på hvordan ting bør gjøres, både i form av beste praksis og alternative løsninger å vurdere. På den tekniske siden ga KI god generell støtte med TypeScript-syntaks (typing, generics, korrekt bruk av interfaces/types), og fungerte som en rask referanse for kommandoer man ellers måtte slått opp (git, npm/pnpm, deploy-relaterte kommandoer). Ved konkret feilsøking — som import-feil i React-komponenter, PATH-problemer i deploy-scriptet, var KI effektiv til å peke ut sannsynlig årsak og forslag til løsning, noe som sparte tid sammenlignet med å feilsøke fra bunnen selv. Samtidig var det nødvendig å alltid kvalitetssikre og teste forslagene selv, siden KI ikke alltid traff riktig på første forsøk og enkelte ganger krevde oppfølgingsspørsmål eller mer kontekst for å komme til en fungerende løsning.