Du er en senior [språk/rammeverk]-utvikler som vurderer kode for [prosjekt/domene].
Mål: [Feilretting | Ytelse | Lesbarhet | Sikkerhet | DX | API-konsistens]
Begrensninger: [Stilguide, støttede versjoner, minne-/tidsbegrensninger, bibliotekbegrensninger]
Kontekst:
- Runtime/Env: [Node 20, JVM 17, Python 3.11, iOS 17, etc.]
- Viktige avhengigheter: [liste]
- Arkitektur: [monolitt, mikrotjeneste, serverløs, heksagonal, etc.]
- Relevante grensesnitt/kontrakter: [lenke eller inline]
Oppgave:
1) Vurder følgende kode for [mål].
2) Identifiser spesifikke problemer med bevis (linjereferanser, kompleksitetsestimater, edge cases).
3) Foreslå minimale, målrettede diffs.
4) Gi en endelig refaktorert versjon.
5) Forklar kompromisser og risikoer.
Kode:
```[språk]
// lim inn kode her

Mål: reduser tids- og minnekompleksitet uten å endre offentlig oppførsel.
Gi: nåværende kompleksitet, foreslått kompleksitet, mikro-optimaliseringer vs algoritmiske endringer, og benchmarks å kjøre.

Refaktor for klarhet: bedre navngiving, mindre funksjoner, single-responsibility.
Legg til docstrings/JSDoc, forenkle kontrollflyt, fjern død kode. Hold offentlig API stabilt.

Trusselmodell: upålitelig input fra [kilde].
Sjekk: injeksjon, deserialisering, SSRF, XSS, CSRF, authZ/authN, hemmelighetshåndtering.
Foreslå: trygge biblioteker, valideringsmønstre og minimale diffs.

Vi migrerer fra [lib A] til [lib B].
List opp breaking changes, foreslå et adapterlag og gi en inkrementell rollout-plan med tester.

Env: Python 3.11, FastAPI, Pydantic v2.
Kontrakt: endepunktet må returnere 200 med { data, meta } selv ved delvise feil.
Begrensning: må forbli async; kan ikke legge til nye tunge deps.

1) Kritikk: list opp konkrete problemer med bevis.
2) Diff: minste endringer for å fikse.
3) Refaktor: ren, idiomatisk endelig kode.
4) Tester: enhetstester som dekker happy path + 3 edge cases.

Foreslå 3 refaktoralternativer:
- Alternativ A: minimal endring
- Alternativ B: moderat redesign
- Alternativ C: full omskriving
For hver: fordeler/ulemper, kompleksitet, risiko, migreringsplan og når du skal velge den.

Begrensninger: samme offentlige API, <50ms p95, <10MB ekstra minne, ingen nye runtime deps.
Vis hvordan din refaktor oppfyller hver begrensning med målinger eller resonnering.

Du er en senior Python-utvikler. Mål: korrekthet + ytelse.
Env: Python 3.11, FastAPI, httpx, Pydantic v2. Kontrakt: aldri raise ved delvis feil.
Oppgave: vurder og refaktorer. Gi kritikk → minimale diffs → endelig refaktor → tester.
Kode:
```python
from fastapi import APIRouter
import httpx
router = APIRouter
@router.get("/users/{user_id}")
async def get_user(user_id: str):
async with httpx.AsyncClient as client:
profile = await client.get(f")
posts = await client.get(f")
return {"data": {"profile": profile.json, "posts": posts.json}}

Annoter hvert forslag med: {alvorlighetsgrad, kategori, begrunnelse}. Inkluder før/etter snippets og en ett-trinns migreringsplan hvis oppførselen kan endres.

Returner output som en unified diff med korrekte filstier fra denne repo-roten. Inkluder kun endrede hunks. Ingen kommentarer i diffen. Inkluder deretter en egen seksjon for notater.

Svar med nøyaktig to blokker:
1) ```diff
...endringer...

Forklar hver endring i én setning med en sitert linje eller snippet. Hvis du er usikker, still et avklarende spørsmål i stedet for å gjette.

Hvis kravene er tvetydige, still opptil 3 avklarende spørsmål før du fortsetter.

Rolle: Senior TypeScript-utvikler.
Mål: forbedre lesbarhet og runtime-sikkerhet uten å endre offentlig API.
Env: Node 20, TypeScript 5.4, Zod for validering, ESLint Airbnb, strictNullChecks.
Begrensninger: ingen nye runtime deps utover Zod, ingen breaking changes, oppretthold O(n)-kompleksitet.
Oppgave:
- Kritikk → Diff → Refaktor → Tester → Notater.
- Tag problemer med {alvorlighetsgrad, kategori, begrunnelse}.
- Inkluder et Zod-skjema for inputvalidering og 4 enhetstester.
Kode:
```ts
export function parseUser(raw: any) {
if (!raw) return null
return {
id: raw.id || '0',
name: raw.name || 'Unknown',
age: parseInt(raw.age),
}
}

Kjør en mental ESLint-pass og list opp brudd du ville forvente, og fiks dem deretter.

For hver endring, nevn refaktoriseringsmønsteret (f.eks. Extract Function, Introduce Parameter Object) og forklar når du skal bruke det i denne kodebasen.

Bruk kun repository-kontekst. Vurder filer som er endret i denne PR for [mål]. Annoter funn inline med alvorlighetsgrad og begrunnelse. Foreslå diffs som bevarer offentlig API og NFRer. Inkluder tester som berører kun endrede paths.