IT2810-H26 · sebasti · Oct 1, 2026 · Oct 1, 2026 · Oct 1, 2026 · Oct 1, 2026
@@ -0,0 +1,30 @@
+---
+name: Oppgave
+about: Ny funksjonalitet, feilretting, dokumentasjon, test eller oppsett
+title: '[FEAT] '
+labels: ''
+assignees: ''
+---
+
+<!--
+Bytt FEAT i tittelen med riktig type: FEAT, FIX, DOCS, TEST, CONFIG eller STYLE.
+Skriv tittelen i imperativ, for eksempel «Lag detaljvisning for annonser».
+Husk label, milestone og hvem som har ansvaret.
+-->
+
+## Beskrivelse
+
+<!-- Hva skal gjøres, og hvorfor? Én til tre setninger. -->
+
+## Akseptansekriterier
+
+- [ ] <!-- Konkret og etterprøvbart, for eksempel «Et tomt søk viser alle annonser.» -->
+- [ ]
+
+## Avgrensning
+
+<!-- Hva hører ikke med i dette issuet? -->
+
+## Avhengigheter
+
+<!-- Issues eller deler som må være på plass først. Skriv «Ingen» hvis det ikke finnes noen. -->
@@ -0,0 +1,31 @@
+## Issue
+
+Closes #
+
+<!--
+GitHub lukker bare issuet automatisk ved merge til main. Ved merge til dev må
+issuet lukkes for hånd. Skriv det her hvis branchen bygger på en annen branch
+som ikke er merget ennå.
+-->
+
+## Endringer
+
+<!-- Hva er endret, og hvorfor? Nevn valg som den som gjennomgår, bør se på. -->
+
+-
+
+## Testing
+
+<!-- Hvilke tester er lagt til, og hva er kontrollert i nettleser? -->
+
+- [ ] `npm run typecheck`
+- [ ] `npm run lint`
+- [ ] `npm run format:check`
+- [ ] `npm test`
+- [ ] `npm run build`
+- [ ] Kontrollert i nettleser, også på smal skjerm og med tastatur
+
+## Sjekkliste
+
+- [ ] README eller `docs/` er oppdatert hvis det trengs
+- [ ] Eventuell KI-bruk er ført i `docs/ki-bruk.md`
@@ -206,33 +206,18 @@ leieforespørsel. Henting og retur samme dag regnes som ett døgn.
 felt er påkrevd, og døgnprisen må være et helt tall fra 0 til 10 000 kroner.
 Serveren skal senere gjøre den samme kontrollen.
 
-`src/data/mockListings.ts` har 10 oppdiktede eksempelannonser. De er ikke ekte
-tilbud og inneholder ingen personopplysninger. Illustrasjonene i
-`src/assets/listings/` er laget for prosjektet. Ekstern datakilde er ikke
-valgt.
+`src/data/mockListings.ts` har 10 eksempelannonser som dekker gratis og betalt
+utlån, korte og lange titler, tomt tilbehør og annonser uten bilde. Se
+[Hva som er mockup](#hva-som-er-mockup) for hvor dataene kommer fra.
 
-Senere skal annonsene hentes fra en egen GraphQL-backend med database
-(planlagt, ikke laget). Komponenter bør derfor få annonser gjennom props i
-stedet for å importere mockdataene direkte. Da kan datakilden byttes uten at
-visningene må skrives om.
+## Dokumentasjon
 
-## Working in this repository
+| Fil                                                  | Innhold                                                  |
+| ---------------------------------------------------- | -------------------------------------------------------- |
+| [docs/prosjektstandard.md](docs/prosjektstandard.md) | Branches, commit-format, pull requests og krav før merge |
+| [docs/design.md](docs/design.md)                     | Farger, typografi, kontrast og felles komponenter        |
+| [docs/testing.md](docs/testing.md)                   | Tester, kontroller, resultater og det som gjenstår       |
+| [docs/ki-bruk.md](docs/ki-bruk.md)                   | Hvordan vi bruker og kontrollerer KI                     |
 
-`main` is protected — you cannot push to it directly. Work on a branch and
-open a pull request:
-
-```bash
-git checkout -b my-feature
-git push -u origin my-feature
-```
-
-Before a pull request can be merged:
-
-1. **A member of IT2810-H26-T36 must approve it.** You cannot approve your own pull
-   request, and approvals from staff do not count — you review each other's
-   code.
-2. **Every review comment must be marked resolved.** Reply to each one, fix it
-   or explain why not, then click _Resolve conversation_.
-3. **Pushing new commits dismisses the approval**, so if you change something
-   after being approved, ask for another review. This is deliberate: what was
-   approved is what gets merged.
+`main` er beskyttet, så alt arbeid går via pull request mot `dev`. Maler for
+issues og pull requests ligger i `.github/`.
@@ -0,0 +1,40 @@
+# KI-bruk
+
+## Verktøy
+
+| Verktøy     | Modell          | Brukes til                                         |
+| ----------- | --------------- | -------------------------------------------------- |
+| Claude Code | Claude Opus 5.5 | Planlegging, issues, kode, tester og dokumentasjon |
+
+## Slik bruker vi KI
+
+- KI får en avgrenset oppgave, normalt ett issue med akseptansekriterier.
+- KI skriver kode i samme stil som resten av repoet og bruker de felles
+  komponentene, typene og hjelpefunksjonene.
+- Alt KI lager, går gjennom vanlig pull request og må godkjennes av et
+  gruppemedlem før merge, på samme måte som annen kode.
+
+## Slik kontrollerer vi resultatene
+
+1. **Automatiske kontroller:** typecheck, lint, format:check, test og build
+   må gå uten feil.
+2. **Nettleser:** endringen prøves i appen, også på smal skjerm og med
+   tastatur.
+3. **Akseptansekriterier:** hvert kriterium i issuet sjekkes mot det som er
+   laget.
+4. **Gjennomgang i pull request:** et annet gruppemedlem leser koden og kan be
+   om endringer.
+
+Feil som KI har gjort og som blir oppdaget, føres i loggen under, slik at vi
+ser hva vi bør være oppmerksomme på.
+
+## Logg
+
+| Issue | Hva KI gjorde                                                                                | Kontroll og funn                                                                                                                                                           |
+| ----- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| –     | Gikk gjennom repoet mot arbeidsplanen og foreslo de resterende issuene til innlevering 1     | Issuene ble lest og opprettet av gruppen                                                                                                                                   |
+| #18   | Laget detaljvisning, `ListingImage`, `RentalRequestForm` og hjelpefunksjoner for leieperiode | Kontroller og nettleser på desktop og 360 px. Første forsøk på datolesing feilet typekontrollen og ble skrevet om                                                          |
+| #19   | Laget utleieskjema, `SelectField`, `TextAreaField` og validering                             | Kontroller og nettleser. Fant at prismerket for betalt leie ble usynlig i forhåndsvisningen, og rettet det før commit                                                      |
+| #20   | Skrev avsnittene om idé, visninger, mockup og planer i README                                | Teksten ble sjekket mot appen. Sortering ble utelatt til #16 var merget                                                                                                    |
+| #7    | Satte opp Vitest og skrev 79 tester, og kontrollerte ren installasjon, bredder og tastatur   | En test sjekket påkrevde felt med `toBeInvalid()` og ville bestått uansett. Byttet til `aria-invalid`. Nettleserkontrollene var automatiserte, se [testing.md](testing.md) |
+| #3    | Skrev prosjektstandard, maler for issues og pull requests og dette dokumentet                | Standarden ble sjekket mot commit-historikken og reglene i repoet                                                                                                          |
@@ -0,0 +1,101 @@
+# Prosjektstandard
+
+Felles regler for hvordan vi jobber i repoet, slik at historikken blir lett å
+følge og alle endringer blir gjennomgått.
+
+## Arbeidsflyt
+
+1. Lag et issue med malen «Oppgave», eller ta et eksisterende.
+2. Lag en branch fra `dev` for issuet.
+3. Commit i små steg og åpne en pull request mot `dev`.
+4. En annen på gruppa gjennomgår og godkjenner før merge.
+5. Ved innlevering merges `dev` til `main` med en egen pull request.
+
+`main` er beskyttet og kan ikke pushes til direkte. `dev` er grenen alt
+arbeid samles i.
+
+## Issues
+
+- Tittel: `[TYPE] Kort beskrivelse i imperativ`, for eksempel
+  `[FEAT] Lag detaljvisning for annonser`.
+- Typer: `FEAT`, `FIX`, `DOCS`, `TEST`, `CONFIG` og `STYLE`.
+- Fyll ut beskrivelse, akseptansekriterier, avgrensning og avhengigheter.
+- Sett label, milestone (for eksempel «Innlevering 1») og hvem som har
+  ansvaret.
+- Større feil som oppdages underveis, får eget issue i stedet for å bli rettet
+  i en urelatert branch.
+
+## Branches
+
+Navnet er `<issue>-<type>-<tittel>`, for eksempel
+`18-feat-lag-detaljvisning-for-annonser`. Det blir slik automatisk med
+«Create a branch» på issuet.
+
+Lag branchen fra `dev`. Hvis arbeidet bygger på en branch som ikke er merget
+ennå, lag den fra den branchen i stedet og skriv det i pull requesten. Når den
+første er merget, viser pull requesten bare de nye commitene.
+
+## Commits
+
+Vi følger [Conventional Commits](https://www.conventionalcommits.org/) med
+norsk beskrivelse:
+
+```
+type(scope): kort beskrivelse i imperativ
+```
+
+Beskrivelsen har liten forbokstav og ikke punktum, for eksempel
+`feat(pages): vis utleieskjemaet på siden for å leie ut verktøy`.
+
+| Type       | Brukes til                             |
+| ---------- | -------------------------------------- |
+| `feat`     | Ny funksjonalitet                      |
+| `fix`      | Feilretting                            |
+| `docs`     | Dokumentasjon                          |
+| `style`    | Utseende og CSS uten ny funksjonalitet |
+| `test`     | Nye eller endrede tester               |
+| `build`    | Avhengigheter, byggoppsett og verktøy  |
+| `refactor` | Omskriving som ikke endrer oppførsel   |
+
+| Scope    | Gjelder                                     |
+| -------- | ------------------------------------------- |
+| `src`    | Komponenter, hooks, utils og data i `src/`  |
+| `pages`  | Sidene i `src/pages/`                       |
+| `app`    | Ruting og oppsett i `App.tsx` og `main.tsx` |
+| `css`    | Felles stiler i `src/styles/`               |
+| `config` | Konfigurasjonsfiler og `package.json`       |
+| `docs`   | README og filene i `docs/`                  |
+| `github` | Maler og innstillinger i `.github/`         |
+
+Én commit skal inneholde én logisk endring. Når flere har jobbet sammen,
+legges de andre til med `Co-authored-by: navn <e-post>` nederst i meldingen.
+
+## Pull requests
+
+- Mot `dev`, med malen som fylles ut automatisk: endringer, testing og
+  hvilket issue som løses.
+- Skriv `Closes #<issue>` i beskrivelsen. GitHub lukker bare issuet
+  automatisk ved merge til standardgrenen, så ved merge til `dev` må issuet
+  lukkes for hånd.
+- Hold pull requesten til ett issue.
+
+## Krav før merge
+
+1. `npm run typecheck`, `npm run lint`, `npm run format:check`, `npm test` og
+   `npm run build` går uten feil.
+2. Et medlem av IT2810-H26-T36 har godkjent. Man kan ikke godkjenne sin egen
+   pull request, og godkjenning fra fagstab teller ikke.
+3. Alle kommentarer er besvart og markert som løst.
+4. Nye commits etter godkjenning fjerner godkjenningen, så be om ny
+   gjennomgang. Det som er godkjent, er det som merges.
+
+## Kode og dokumentasjon
+
+- Prettier bestemmer formateringen og ESLint finner feil. Kjør
+  `npm run format` før commit.
+- Navn i koden er på engelsk. Kommentarer, tekst i grensesnittet og
+  dokumentasjon er på norsk.
+- Kommentarer forklarer hvorfor, ikke hva koden gjør.
+- Oppdater README eller filene i `docs/` i samme pull request som endringen
+  de beskriver.
+- Bruk av KI føres i [ki-bruk.md](ki-bruk.md).
@@ -102,6 +102,19 @@ utleieskjemaet.
 - Annonsekort åpnes med Enter.
 - Etter en innsending med feil havner fokus på første ugyldige felt.
 
+## Gjenstående kontroller
+
+Kontroller som ikke er gjort ennå. Kryss av og skriv dato og hvem når de er
+gjort, og flytt resultatet opp i dokumentet.
+
+- [ ] Tastaturnavigasjon og synlig fokus kontrollert for hånd i Firefox eller
+      Safari
+- [ ] Appen prøvd på en ekte telefon
+- [ ] Hovedflyten prøvd med skjermleser (VoiceOver eller NVDA)
+- [ ] Manuell brukertest med en person utenfor gruppen
+- [ ] API-tester mot testdatabase, når backenden finnes
+- [ ] Ende-til-ende-test med Playwright for en hel leieflyt, når booking finnes
+
 ## Begrensninger
 
 - **Nettleserkontrollene er automatiserte.** Mobil, desktop og tastatur er