Web Design Reviewer

Nettside-designgjennomgang

Visuell inspeksjon og validering av designkvalitet på nettsider. Identifiserer og fikser problemer på kildekodenivå.

Anvendelse

• Statiske nettsider (HTML/CSS/JS)
• SPA-rammeverk som React / Vue / Angular / Svelte
• Fullstack-rammeverk som Next.js / Nuxt / SvelteKit
• Andre webapplikasjoner

Forutsetninger

Påkrevd

1. Nettsiden må kjøre

   • Lokal utviklingsserver (f.eks. http://localhost:3000)
   • Staging-miljø
   • Produksjon (kun for gjennomgang uten endringer)

2. Browser-automatisering må være tilgjengelig

   • Screenshots
   • Sidenavigasjon
   • DOM-informasjon

3. Tilgang til kildekode (ved feilretting)

   • Prosjektet må finnes i workspace

Arbeidsflyt

Steg 1: Informasjonsinnhenting

1.1 URL-bekreftelse

Hvis URL ikke er oppgitt, spør:

Oppgi URL-en til nettsiden som skal gjennomgås (f.eks. http://localhost:3000)

1.2 Prosjektstruktur

Ved feilretting, finn ut følgende:

1.3 Automatisk prosjektdeteksjon

Forsøk automatisk deteksjon fra filer i workspace:

Copy code
Deteksjonsmål:
├── package.json     → Rammeverk og avhengigheter
├── tsconfig.json    → TypeScript-bruk
├── tailwind.config  → Tailwind CSS
├── next.config      → Next.js
├── vite.config      → Vite
├── nuxt.config      → Nuxt
└── src/ eller app/  → Kildekatalog

1.4 Identifisering av stilmetode

Steg 2: Visuell inspeksjon

2.1 Sidetraversering

1. Naviger til oppgitt URL
2. Ta screenshot
3. Hent DOM-struktur/snapshot (hvis mulig)
4. Traverser gjennom navigasjon hvis flere sider finnes

2.2 Inspeksjonspunkter

Layout-problemer

Responsive problemer

Tilgjengelighetsproblemer

Visuell konsistens

2.3 Viewport-testing (responsiv)

Test ved følgende viewports:

Steg 3: Feilretting

3.1 Prioritering

3.2 Finne kildefiler

Identifiser kildefiler fra problematiske elementer:

1. Selektor-basert søk

   • Søk i kodebasen etter klassenavn eller ID
   • Utforsk stildefinisjoner med grep_search

2. Komponent-basert søk

   • Identifiser komponenter fra elementtekst eller struktur
   • Utforsk relaterte filer med semantic_search

3. Filmønsterfiltrering

   Copy code
   Stilfiler: src/**/*.css, styles/**/*
   Komponenter: src/components/**/*
   Sider: src/pages/**, app/**
   

3.3 Gjennomføre fiks

Se references/framework-fixes.md for rammeverksspesifikke retningslinjer.

Fiks-prinsipper

1. Minimale endringer: Gjør kun nødvendige endringer for å løse problemet
2. Respekter eksisterende mønstre: Følg eksisterende kodestil i prosjektet
3. Unngå breaking changes: Vær forsiktig så du ikke påvirker andre områder
4. Legg til kommentarer: Forklar fiksen der det er relevant

Steg 4: Verifikasjon

4.1 Bekreftelse etter fiks

1. Last inn nettleseren på nytt (eller vent på HMR)
2. Ta screenshot av fiksede områder
3. Sammenlign før og etter

4.2 Regresjonstesting

• Verifiser at fiksen ikke har påvirket andre områder
• Bekreft at responsiv visning fortsatt fungerer

4.3 Iterasjonsbeslutning

Iterasjonsgrense: Hvis mer enn 3 fiks-forsøk trengs for ett problem, konsulter brukeren

Rapportformat

Gjennomgangsresultat

markdownCopy code
# Designgjennomgang — resultater

## Sammendrag

| Element | Verdi |
|---------|-------|
| URL | {URL} |
| Rammeverk | {Detektert rammeverk} |
| Styling | {CSS / Tailwind / etc.} |
| Testede viewports | Desktop, Mobil |
| Problemer funnet | {N} |
| Problemer fikset | {M} |

## Problemer funnet

### [P1] {Problemtittel}

- **Side**: {Sidesti}
- **Element**: {Selektor eller beskrivelse}
- **Problem**: {Detaljert beskrivelse}
- **Fikset fil**: `{Filsti}`
- **Fiks**: {Beskrivelse av endringer}
- **Screenshot**: Før/Etter

### [P2] {Problemtittel}
...

## Ikke-fiksede problemer (hvis aktuelt)

### {Problemtittel}
- **Årsak**: {Hvorfor det ikke ble fikset}
- **Anbefalt handling**: {Anbefalinger til bruker}

## Anbefalinger

- {Forslag til fremtidige forbedringer}

Beste praksis

GJØR

• Ta alltid screenshot før du fikser
• Fiks ett problem om gangen og verifiser hver
• Følg prosjektets eksisterende kodestil
• Bekreft med bruker før store endringer
• Dokumenter fiks-detaljer grundig

IKKE GJØR

• Stor refaktorering uten bekreftelse
• Ignorere design system eller brand guidelines
• Fikser som ignorerer ytelse
• Fikse flere problemer samtidig (vanskelig å verifisere)

Review contract

Axes: the inspection points in Steg 2.2 — layout, responsive, accessibility, visual consistency — across the viewports in Steg 2.3. The block below closes the Rapportformat report.

The review ends here, in this shape. A review with no output section has not run.

Judge primary evidence. The diff, the file, the EXPLAIN output, the rendered page — never your own summary of the change, and never your memory of what you meant to write. Resolve the base first, then cover committed, staged, unstaged and untracked changes. Read untracked files in full: diff output omits them.

Every axis reports. Each axis produces at least one finding, or one line saying what it inspected and what that evidence does not prove. An axis that says nothing has not looked.

Report what you inspected. "No findings in the two files I opened" and "no findings in the change" are different claims, and only the first one is ever true.

Copy code
Inspected:     <files, queries, URLs, viewports actually opened>
Not inspected: <in scope, not examined, and why>
Findings:      <n blocking, n concerns>
Verdict:       BLOCK | CONCERNS | CLEAN

• BLOCK — at least one finding that, shipped as written, risks data loss, a security or privacy breach, a production incident, or a wrong answer to a user.
• CONCERNS — no blocking finding, but at least one a maintainer should fix or answer first.
• CLEAN — every axis inspected against primary evidence, nothing at either bar. CLEAN claims only the axes above and the files on the Inspected line, and it is wrong if a defect is later found in them.

Not a review: LGTM; restating what the change does; cosmetic findings only; reading the changed lines without the code they call.