design(app-creator): S13 — review-gate mellom faser (friksjon #15) + retroaktiv anvendelse

Operatør avslørte i S13 at app-creator-pipelinen mangler review-gate mellom faser.
Implementér mønsteret som spec + førstegangs-anvendelse på Akashic-prototypen.

phase-design-draft.md:
- Ny § Cross-cutting: Review-gate mellom faser (mellom state.json og brief-revisjon
  ved backtracking) — sidecar-format, annoterings-vokabular (approved/revise/defer/
  drop/question), applisering med revisjons-logg, oppstrøms-konsekvens-håndtering
  (backtrack vs revision-pending), nedstrøms for fase 7 (drop→slett mappa, revise→
  bump rev, defer→flytt), retroaktiv review, attention-entry-type, frekvens-regel
  (obligatorisk), all-approved-shortkutt, forhold til status-merking.
- phase_status-vokabular utvidet med pending-review | revision-in-progress
- state.json-eksempelet viser ny objekt-form med sidecar-peker
- § Brief-pattern fikk peker til review-gate som hard krav

friksjon.md:
- #15: Fase-til-fase går uten review-gate (prosess-friksjon, kritisk)
- Beskriver problemet, hva som mangler, 5 strukturelle krav, S13-handling,
  lærdom, anvendelse på allerede-fullførte faser, foreslått revisjon, drahjelp
  fra Voyage /trekrevise-mønster, fase-overhead-implikasjon.
- S13-bekreftelse på eksisterende friksjon + prosess-merknader (operatør-
  pedagogisk friksjon, omdefinert sesjons-omfang).

Akashic-side (separat repo): review-maler 06-features-brief.review.md +
features/01-sun-position/review.md, interim index.html, state.json oppdatert.
Committet i Akashic-repo separat (denne committen påvirker ikke ren instans).

Neste sesjon (S14): applisere review-annoteringer som revisjon 1, propagere
oppstrøms-konsekvenser, re-generere index.html, fortsette fase 7 hvis godkjent.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

prototype-run/friksjon.md

@@ -445,3 +445,53 @@ Prosess-/spec-merknader fra S12 (ikke nummererte friksjons-poeng):
 - **Token-budsjett:** sesjonen holdt seg under 250K. Hovedkontekst-belastning: phase-design-draft § Fase 7 + § Hard lengde-grense + § Felles brief-frontmatter, Voyage HANDOVER-CONTRACTS.md § Handover 1 + trekbrief-template.md (rask verifisering), Akashic `06-features-brief.md` § F-001 (full), `03-architecture-brief.md` § ADR-001/002/004/005/006 + AQ-001, `05-constraints-brief.md` § Performance/MASVS/Plattform, `00-context/domain-pack-ios-app.md` § Conventions/Gotchas/Patterns, friksjon.md (særlig #5/#10/#11/#13), SESSION-LOG S11. Skrivinger: `features/01-sun-position/brief.md` (743 ord), `context.md` (641), `research.md` (584), state.json oppdatering, friksjon.md +#14 + S12-seksjon, SESSION-LOG S12-seksjon, SESSION-ROADMAP-edit, NEXT-SESSION-PROMPT-S13. Lavest hovedkontekst-belastning siden S8.
 
 ---
+
+## #15: Fase-til-fase går uten review-gate — operatør kan ikke annotere/godkjenne/avvise fase-output før neste fase starter
+
+**Fase:** alle (observert under S13, men problemet eksisterer fra S1)
+**Type:** prosess-friksjon (kritisk — påvirker hver fase-overgang)
+**Observert:** 2026-05-13 (S13) — operatør avbrøt S13 fase 7-runde med "jeg har ikke fått muligheten å gjøre review av ditt forslag til features, det må jeg kunne gjøre med annoteringer. Dette vil kunne gå fram og tilbake noen ganger. F.eks. ville jeg ikke godkjent F-006."
+
+**Beskrivelse:** `phase-design-draft.md` beskriver fase-overganger som "produserer artefakt → neste fase leser artefakt" uten et eksplisitt operatør-review-/godkjennings-gate imellom. I praksis betyr det at AI-en kan produsere fase n-output og umiddelbart bygge fase n+1 på toppen, selv om operatøren ville endret/avvist deler av n-output gitt sjansen. Friksjons-utløser i S13: S11 skrev `06-features-brief.md` med 13 features (10 funksjonelle + 3 F-T) og R14-PASS-verdict; S12 startet umiddelbart fase 7 og skrev F-001 sun-position-brief; S13 skulle skrive andre fase 7-brief — operatør stoppet med "F-006 ville jeg ikke godkjent". Det betyr backloggen S12 bygget F-001 på toppen av inneholder features operatøren ville endret eller fjernet.
+
+**Hva som mangler:** Et **review-gate-mønster** mellom hver fase som er strukturelt analogt med Voyage `/trekrevise` ("Apply operator-annotated brief/plan/review back into the source artifact with audit trail"). Mønsteret må håndtere:
+1. **Strukturert annotering** — sidecar-fil eller inline-kommentar med fast vokabular (approved / revise / defer / drop) per ankerelement (per feature, per ADR, per constraint, per success-kriterium, …).
+2. **Iterasjon over flere runder** — operatør kan annotere, AI applisere, operatør re-annotere; ikke én-shot-godkjenning. Sesjons-grenser skal overleves (annotasjoner committed til fil, ikke i samtale-tråd).
+3. **Audit trail** — hver revisjon dokumenterer hvilke annotasjoner som drev hvilke endringer (`revision: N → N+1` med endringslogg per anker).
+4. **Status-gate i `state.json`** — fase markeres `complete` (godkjent + applisert) vs `pending-review` (artefakt skrevet, men ikke godkjent) vs `revision-in-progress` (annotasjoner mottatt, applisering pågår). Neste fase kan kun starte når forrige er `complete`.
+5. **Konsekvens-håndtering oppstrøms** — hvis fase n-review avslører at fase n-1 må endres (f.eks. F-006-droping i fase 6 avslører at app-brief § Omfang #6 må re-revideres): operatør får eksplisitt valg mellom backtrack til fase n-1 eller registrere endringen som revision-pending der.
+
+**Hva som ble gjort i S13:** S13 fase 7-skriving pauset umiddelbart etter operatør-stopp. Friksjon #15 logget. `phase-design-draft.md` skal oppdateres med review-gate-mønster (eget delsteg av S13). Review-mal for `06-features-brief.md` skal lages i Akashic-repoet som første anvendelse av mønsteret. F-001 brief.md fra S12 må inkluderes i samme review-runde siden den ble skrevet uten review-gate.
+
+**Lærdom for app-creator-designet:** Review-gate er **hard-obligatorisk** mellom alle fase-overganger, ikke valgfri. Dette er en grunnleggende design-mangel i `phase-design-draft.md` — pipelinen er strukturert som AI-prosessering, ikke som operatør-styrt syntese. Mønsteret arvet fra Voyage `/trekbrief`/`/trekplan`/`/trekreview`/`/trekrevise`-flyten er nettopp at hver overgang er en operatør-handling. App-creator må adoptere samme strukturelle disiplin per fase.
+
+**Anvendelse på allerede-fullførte faser:** Fase 1 (app-brief), fase 2 (research-brief), fase 3 (architecture-brief), fase 5 (constraints-brief), fase 6 (features-brief), fase 7 F-001 (sun-position-brief) ble alle skrevet uten review-gate. Operatør avgjør per artefakt om retroaktiv review er nødvendig:
+- **Fase 6 (features-brief)** — primær drivende for S13-pause; review er **obligatorisk nå** (operatør har eksplisitt sagt "F-006 ville jeg ikke godkjent").
+- **Fase 7 F-001** — review er **obligatorisk nå** siden brief.md ble skrevet på toppen av u-validert fase 6. Hvis fase 6-review endrer/dropper F-001: F-001-brief må revideres eller slettes.
+- **Fase 1, 2, 3, 5** — review er **anbefalt** men ikke blokkerende for S13. Hvis fase 6-review avslører at en oppstrøms-fase også må revideres: backtrack håndteres da.
+
+**Foreslått revisjon (gjøres i S13):**
+1. **`phase-design-draft.md`** — ny § "Review-gate mellom faser" som spec-er mønsteret (vokabular, sidecar-format, applisering, audit trail, state.json-statuser). Hver fase-seksjon (§ Fase 1..7) får eksplisitt "Review-gate"-understeg som peker til den nye seksjonen.
+2. **Sidecar-format:** `<artefakt>.review.md` ved siden av hovedartefakten (f.eks. `06-features-brief.review.md`). Strukturert med én entry per anker (feature, ADR, constraint, success-kriterium) + fast vokabular.
+3. **State.json-utvidelse:** `phase_status.<n>` kan være string (eksisterende) ELLER objekt `{status: "complete|pending-review|revision-in-progress", revision: N, review_at: "<dato>", reviewer: "<navn>"}`.
+4. **Friksjons-flagg:** `review_pending` som attention-type i `state.json.attention[]` med peker til sidecar-fil.
+
+**Drahjelp fra Voyage-mønster:** `~/.claude/plugins/marketplaces/ktg-plugin-marketplace/plugins/voyage/commands/trekrevise.md` (kommando-spec) og `voyage/docs/HANDOVER-CONTRACTS.md` § "operatør-annotert brief/plan/review back into source artifact" — bør leses og adopteres strukturelt. App-creator implementerer ikke `trekrevise`-kommando, men adopterer mønsteret (anchored comments + canonical annotation_digest + revision in-place).
+
+**Fase-overhead-implikasjon:** Hvert fase-overgang får +1 review-runde (estimert 20-40 min operatør-tid + 10-20 min applisering-tid). For Akashic: 6 ferdige fase-artefakter (1, 2, 3, 5, 6, 7 F-001) → ~2-3 t retroaktiv review-arbeid hvis alle skal gjennomgås. Fremover: hver ny fase 7-feature får én review-gate (~30-60 min ekstra per feature × 12 gjenværende = 6-12 t). Dette er reell kost — men feilen av å hoppe over review (bygge på u-validert backlog) er større.
+
+---
+
+## Ny friksjon oppstått i S13
+
+Én ny nummerert friksjon: #15 (over — fase-til-fase går uten review-gate; kritisk prosess-mangel som påvirker alle fase-overganger).
+
+S13-bekreftelse på eksisterende friksjon:
+- Ikke aktuelt — S13 ble avbrutt før selve fase 7-skriving startet. Ingen lengde-måling, ingen template-test, ingen numbering-kollisjon-sjekk.
+
+Prosess-/spec-merknader fra S13 (ikke nummererte friksjons-poeng):
+- **S13-omfang skiftet fra "skriv andre fase 7-brief" til "implementér review-gate-mønster".** Operatør-stopp er ikke en feil i S13-prompten — prompten antok at fase 6-output var godkjent fordi fasen var markert `complete` i `state.json`. Friksjon #15 viser at "complete" i `phase_status` ikke betyr "operatør-godkjent", bare "AI-skrevet". State.json-vokabular må skjerpes (se "Foreslått revisjon" punkt 3 over).
+- **Token-budsjett:** ikke nær 250K-grensen. S13 har dimensjon "design-revisjon", ikke "fase-artefakt-skriving" — vesentlig mindre kontekst.
+- **Opus-direktiv (operatør S12):** "bruk Opus for alt" gjelder fortsatt for S13's design-revisjon-arbeid. Ingen subagenter spawnes i S13 — alt arbeid skjer i hovedkontekst (les + skriv + reasoning er mid-vekt).
+
+---