utdype-implementasjon

name	utdype-implementasjon
description	Utdyp en eksisterende .feature-fil med UI- og design-patterns i en sidecar-fil (<feature>.design.md). Bruk når brukeren vil "utdype implementasjon", "legge til designdetaljer", "beskrive UI for en feature", eller "lage designnotater" knyttet til et konkret krav. Skillen holder .feature-filen ren BDD (hva) og legger hvordan-detaljer ved siden av.

Utdype implementasjon

Lag en sidecar-fil <feature-navn>.design.md som beskriver UI/design-patterns for en eksisterende .feature-fil. Feature-filen forblir uendret.

Når denne skillen brukes

• Brukeren refererer til en konkret .feature-fil og vil utdype hvordan den skal se ut / oppføre seg i UI
• Domeneeksperter har skrevet hva-et; nå trenger utviklere hvordan-et

Arbeidsflyt

1. Forstå utgangspunktet

• Les .feature-filen som ble pekt ut
• Identifiser scenarioene og hvilke UI-elementer de implisitt forutsetter (knapper, lister, skjemaer, navigasjon)
• Sjekk om det finnes en eksisterende <feature-navn>.design.md — i så fall, oppdater i stedet for å overskrive

2. Identifiser hull

For hvert scenario, vurder hva som mangler av UI-detaljer:

• Hvilken sidetype/komponent? (liste, detaljside, modal, wizard)
• Hva er primær handling? Sekundære handlinger?
• Hvilke felter vises, og i hvilken rekkefølge?
• Hvordan håndteres tom tilstand, lasting, feil?
• Hvilke navigasjons- eller filtreringsmønstre forventes?
• Hvordan kobles dette til eksisterende komponenter?

3. Still målrettede spørsmål

Bruk AskUserQuestion for å avklare. Eksempler:

• "Hvilken layout brukes for listevisningen — tabell, kort, eller liste?"
• "Hvor utløses primærhandlingen — toppen av siden, ved hver rad, eller begge?"
• "Hva skjer ved tom tilstand?"

Spør om én ting av gangen. Ikke gjett — be om svar når noe er uklart.

4. Skriv sidecar-filen

Lagre som <feature-navn>.design.md i samme mappe som .feature-filen.

Mal:

# Designnotater: <Feature-tittel>

**Relatert feature:** [`<feature-navn>.feature`](./<feature-navn>.feature)

## Overordnet UI-mønster

<Sidetype, hovedlayout, plassering i applikasjonen>

## Komponenter og layout

<Hvilke komponenter, struktur, hierarki — kort og presist>

## Interaksjonsmønstre

### Primærhandling
<Hva, hvor, hvordan utløses>

### Sekundære handlinger
<Liste>

### Navigasjon
<Hvordan kommer brukeren hit, hvor går de videre>

## Tilstander

| Tilstand | UI-håndtering |
|----------|---------------|
| Tom | ... |
| Laster | ... |
| Feil | ... |
| Suksess | ... |

## Per-scenario detaljer

### Scenario: <navn fra feature-filen>
<UI-spesifikke notater som utdyper akkurat dette scenarioet>

## Åpne designspørsmål

- [ ] <spørsmål>

Konvensjoner

• Ikke endre .feature-filen. Sidecar-filen er rent tillegg.
• Bruk relative lenker til feature-filen.
• Hold det kort. Notatene skal være lesbare, ikke uttømmende.
• Marker uavklarte ting under "Åpne designspørsmål" — ikke gjett.
• Følg terminologi-reglene i .claude/rules/gherkin-conventions.md (organisasjon vs. lærested, osv.)