ARCHITECTURE_DECISIONS.md — ny ADR-014 dokumenterer de fire uavhengige bryterne (bruk handicap / bruk course handicap / hcp-prosent / bruk matchplay-handicap), bekreftelsen av at prosentene matcher GameBook, og at motoren allerede støtter alle fire som atskilte kall.

FEATURE_BACKLOG.md — ny rad i "Fundament"-tabellen (📋 planlagt, referer ADR-014), pluss oppdatert rad for oppsett-API (✅) og allowance-raden nå refererer ADR-014.
CLAUDE.md — "Neste steg" punkt 1 sier nå eksplisitt at de fire bryterne skal bygges inn samtidig med scoring, ikke bare prosenten.

ARCHITECTURE_DECISIONS.md

@@ -5,7 +5,7 @@
 > Endre aldri en beslutning uten å legge til en ny ADR som erstatter den — historikken skal bevares.
 
 **Status:** Levende dokument
-**Sist oppdatert:** 2026-07-15
+**Sist oppdatert:** 2026-07-16
 
 ---
 
@@ -258,6 +258,41 @@ organisasjon (jf. ADR-010).
 
 ---
 
+## ADR-014 — Konfigurerbar handicap-pipeline: fire uavhengige brytere
+
+**Beslutning:** Handicap-anvendelsen i en økt er FIRE uavhengige, valgfrie steg —
+ikke bare én allowance-prosent:
+
+1. **Bruk handicap** (av/på) — helt av gir scratch-spill.
+2. **Bruk course handicap** (av/på) — om slope/rating-justeringen
+   (`course_handicap_raw`) påføres, eller om rå `handicap_index` brukes direkte.
+3. **HCP-prosent** (allowance-strategien, allerede dekket av ADR-005 /
+   `session.allowance_override`).
+4. **Bruk matchplay-handicap** (av/på) — om resultatet konverteres til relative
+   slag (`match_play_strokes`: beste enhet spiller «av 0», resten får
+   differansen), eller brukes som absolutt Playing Handicap.
+
+**Begrunnelse:** Skjermbilder fra Golf GameBook (referanseprodukt, delt
+2026-07-16) viser nøyaktig denne firedelte bryter-strukturen per runde/format i
+deres oppsettsdialog. Deres standard-prosenter (foursome 50 %, better ball/
+fourball 90 %, singles 100 %) stemmer eksakt med `DEFAULT_MATCHPLAY_ALLOWANCES`
+i `handicap_engine.py` — uavhengig bekreftelse på at defaultene er riktige,
+slik ADR-005 krever verifisert. Motoren støtter allerede alle fire som atskilte,
+komponerbare funksjonskall (`course_handicap_raw`, en `AllowanceStrategy`,
+`match_play_strokes`) — hver kan hoppes over uavhengig av de andre — men
+API-et/skjemaet eksponerer dem ikke som brytere ennå.
+
+**Konsekvens:** `session.allowance_override` (jsonb) skal utvides til å bære
+alle fire bryterne, ikke bare prosent, når motor-/scoring-integrasjonen bygges
+(se FEATURE_BACKLOG.md). Ingen skjemaendring nødvendig (feltet er allerede
+jsonb), men API-lagets validering og motor-kall må håndtere: `bruk_handicap =
+false` → hopp over hele kjeden (brutto = netto), `bruk_course_handicap = false`
+→ bruk `handicap_index`/`handicap_index_snapshot` direkte uten
+slope/rating-justering, `bruk_matchplay_handicap = false` → bruk absolutt
+Playing Handicap i stedet for å kalle `match_play_strokes`.
+
+---
+
 ## Åpne spørsmål (ikke besluttet ennå)
 
 Disse må avklares før eller under de relevante fasene:

CLAUDE.md

@@ -3,7 +3,7 @@
 Les dette først i hver økt. Det koder hva vi har bestemt og hvordan vi jobber.
 
 ## Autoritative kilder (les før du gjør noe)
-- `ARCHITECTURE_DECISIONS.md` — hva som er bestemt og hvorfor (ADR-001…013). Fasit.
+- `ARCHITECTURE_DECISIONS.md` — hva som er bestemt og hvorfor (ADR-001…014). Fasit.
 - `FEATURE_BACKLOG.md` — hva som gjenstår, hva som er utsatt, hva som mangler.
 - Endres en beslutning: legg til en ny ADR, ikke slett historikk. Hold begge
   filene oppdatert når noe avgjøres.
@@ -68,7 +68,12 @@ Neste steg:
 1. Scoring-endepunkter: `hole_score`/`match_hole_result`-skriving,
    matchstatus fra `handicap_engine.compute_match_state`, og
    handicap-beregning (`course_handicap`/`playing_handicap`) for
-   `match_participant` via motoren.
+   `match_participant` via motoren. Bygg samtidig inn de fire konfigurerbare
+   bryterne fra ADR-014 (bruk handicap / bruk course handicap / hcp-prosent /
+   bruk matchplay-handicap) i `session.allowance_override` — IKKE bare
+   prosenten. Motoren støtter allerede alle fire som atskilte kall
+   (`course_handicap_raw`, en `AllowanceStrategy`, `match_play_strokes`); det
+   som mangler er at API-et leser bryterne og hopper over/kaller riktig steg.
 2. Containerisere TeeCup-API-et (Dockerfile + compose-tjeneste), koble mot
    `teecup_db` med `teecup_app`, rute via eksisterende Caddy til
    `teecup.teeoff.no`.

FEATURE_BACKLOG.md

@@ -7,7 +7,7 @@
 > Status-koder: ✅ ferdig · 🔨 pågår · 📋 planlagt/fanget · ❓ trenger beslutning
 > · 🔀 endret fra opprinnelig råd · 💤 utsatt (bevisst)
 >
-> Sist oppdatert: 2026-07-15
+> Sist oppdatert: 2026-07-16
 
 ---
 
@@ -17,14 +17,15 @@
 |---|---|---|
 | Handicap-/matchmotor (testet) | ✅ | 24 tester, R&A-verifisert. Erstatter Geminis løse JS-funksjon. |
 | Formater: singles, fourball, foursome, greensome, scramble | ✅ | I motoren, allowance som konfig. |
-| Brutto/netto + prosent-allowance (75 %, 90 %, 3/4) | ✅ | ADR-005. |
+| Brutto/netto + prosent-allowance (75 %, 90 %, 3/4) | ✅ | ADR-005. Prosentene bekreftet mot Golf GameBook (ADR-014). |
 | 9-hulls (front/back) slagfordeling | ✅ | ADR-008, egen funksjon + test. |
 | Miksede formater per turnering (økter) | ✅ | ADR-007. Ryder Cup-strukturen. |
 | Spiller-pool m/ reserver, delvis deltakelse | ✅ | ADR-007. |
 | Multi-tenant skjema + RLS | ✅ | ADR-001/003. Isolasjon bevist med oppførselstest. |
 | Dedikert app-rolle (ingen superuser/BYPASSRLS) | ✅ | migrasjon 002. |
-| API-fundament m/ trygg org-kontekst | 🔨 | Skjelett klart; CRUD gjenstår. |
+| API: oppsett (spillere/lag/roster/økter/matcher/blind draw) | ✅ | Verifisert for ekte mot scratch-db + engangscontainer. Scoring gjenstår. |
 | Banedata fra teeoff via API | 🔀 | ADR-004. Endret fra Geminis «delt database direkte». |
+| Konfigurerbar handicap-pipeline (4 brytere) | 📋 | ADR-014. Motoren støtter alle fire steg (course handicap / allowance / matchplay-hcp / helt av) som atskilte kall; API/skjema eksponerer dem ikke som brytere ennå. Bygges sammen med scoring-endepunktene. |
 
 ---