docs(app-creator): import 5 trekbrief-disipliner som kjøre-disiplin i fase 1

Per-app-intervjuet manglet eksekverings-mekanisk disiplin der /trekbrief
har det. Importer fem mønstre som kjøre-disiplin (ikke kode), justert
for at app-scope er bredere og mykere enn task-scope:

1. Weakest-section-first-loop med standard prioritering
2. Anchor / Sharpen-mønster på vage svar
3. Aktiv research-tema-uthenting under dialog (Question / Confidence / Scope)
4. [ANTAKELSE]-markører for ting operatør ikke vet
5. 6 ja/nei kvalitets-sjekk-spørsmål før fase-eksit

Eksplisitt utenfor: mekanisk 1-5-scoring og dedikert reviewer-agent —
hører til per-task-kontekst der suksess-kriterier er command-checkable.

Status-merket [importert fra trekbrief, justert for per-app, hypotese] —
prototypen vil avsløre hvilke mønstre som faktisk hjelper vs er overhead.

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

docs/phase-design-draft.md

@@ -172,9 +172,87 @@ status: active
    - Tidshorisont
 3. AI følger opp på tvetydighet, summerer underveis
 4. Operatør korrigerer
-5. Avsluttes når sjekkliste er dekket og operatør sier OK
+5. Avsluttes når sjekkliste er dekket, alle 6 kvalitets-sjekk-spørsmål er besvart med ja, og operatør sier OK
+
+### Kjøre-disiplin (importert fra Voyage trekbrief) `[importert fra trekbrief, justert for per-app, hypotese]`
+
+Voyages `/trekbrief` har fem disipliner som per-task-intervjuet hviler på. Per-app-intervjuet importerer dem her som *kjøre-disiplin* (ikke kode), justert for at app-scope er bredere og mykere enn task-scope.
+
+**1. Weakest-section-first-loop**
+
+Gå ikke gjennom de 6 sjekkliste-temaene kronologisk. Velg svakeste tema mellom hvert svar. Standard prioritering når flere er like svake:
+
+```
+Problem & motivasjon → Brukere → Suksess-kriterier → Omfang → Plattform → Tidshorisont
+```
+
+Begrunnelse: Suksess-kriterier kan ikke skrives før Brukere er konkretisert; Omfang kan ikke skrives før Problem er tydelig; Plattform-detaljer er tregere å låse hvis Tidshorisont er ukjent. Hopper du tilbake til svakeste tema, blokkerer du deg ikke selv senere i intervjuet.
+
+**2. Anchor / Sharpen-mønster**
+
+Per tema starter med en *Anchor* — åpent spørsmål som åpner temaet uten å lede. Hvis svaret er vagt ("appen skal være rask", "for folk som vil trene mer"), bruk *Sharpen* — krev konkretisering:
+
+- "Du sa appen skal være {raskt / pålitelig / tilfredsstillende} — hvilket tall eller terskel teller som suksess?"
+- "Du sa 'folk som vil trene mer' — kan du peke på én konkret person, eller en persona med kontekst og ferdighetsnivå?"
+- "Du sa 'mest mobil men også web' — er web innenfor MVP-omfang, eller etter v1?"
+
+Aldri repeter samme variant på samme tema. Hvis Sharpen ikke gir mer presisjon: marker som [ANTAKELSE] (mønster 4) og gå videre.
+
+**3. Aktiv research-tema-uthenting under dialog**
+
+Lytt aktivt under intervjuet etter signaler som krever research før arkitektur (fase 3) kan låses:
+
+- Ukjent teknologi nevnt ("jeg har hørt om SwiftData men har ikke brukt det")
+- Ny iOS-versjon eller framework-API ("jeg vil bruke Liquid Glass / nye Observation framework")
+- Security-valg ("brukerne logger inn med Apple ID — hva er beste-praksis?")
+- Arkitektur-valg ("MVVM eller TCA?", "CoreData vs SwiftData")
+- Markedsmessige antakelser som påvirker scope (men obs: markedsanalyse er ute av scope per linje 18)
+
+Idet et tema dukker opp, fang det med struktur i transkript:
+
+```
+[RESEARCH-TEMA]
+Question: Hva er beste-praksis for Apple Sign-In med SwiftData-baserte brukerprofiler i 2026?
+Confidence needed: high  # vil drive arkitektur-beslutning
+Scope hint: ekstern docs (Apple Human Interface Guidelines + dev docs)
+```
+
+Tre felter:
+- **Question** — slutter med `?`, formulert spesifikt nok til at noen kan svare
+- **Confidence needed** — `high` (driver arkitektur-beslutning), `medium` (informerer men låser ikke), `low` (bra-å-vite)
+- **Scope hint** — `lokal kode-research`, `ekstern docs`, eller `begge`
+
+Disse temaene bæres til fase 2-research-plan. Hvis operatør sier "jeg vet allerede svaret", strykes temaet — men svaret skrives kort i transkript som referanse.
+
+**4. [ANTAKELSE]-markører**
+
+Når operatør sier "ikke vet" om noe materielt (målgruppe-størrelse, plattform-versjons-krav, integrasjons-detalj), skriv det eksplisitt i transkript og brief som:
+
+```
+[ANTAKELSE] iOS 17 er minimum — ikke verifisert mot målgruppens enhets-park.
+[ANTAKELSE] Apple Watch ikke i MVP — kan endres etter første brukertest.
+```
+
+Forskjellen fra et research-tema: en antakelse er en bevisst pause — vi går videre uten å vite, og bærer risiko-en. Et research-tema er et åpent svar vi planlegger å hente. Antakelser legges i app-brief sin "Åpne spørsmål"-seksjon med [ANTAKELSE]-prefiks og bæres til fase 3 hvor de må aktivt resolveres eller eksplisitt aksepteres.
+
+**5. Kvalitets-sjekk før fase-eksit (6 ja/nei-spørsmål)**
+
+Ikke en agent, ikke scoring — en check-list operatør må svare ja på før `phase_status: complete`:
+
+1. Er problem & motivasjon skrevet i 1-2 avsnitt operatør står bak?
+2. Er primær målgruppe konkret nok til å peke på én person eller persona med kontekst?
+3. Finnes minst ett suksess-kriterium med konkret målbarhet — selv om målingen først kan gjøres post-shipping?
+4. Er omfang-utenfor-listen ikke-tom? (Ingen ærlig app har tomt utenfor-omfang.)
+5. Er plattform-detaljer (target, min-versjon, eventuelle extensions/widgets) eksplisitte?
+6. Er åpne spørsmål kategorisert som enten *research-tema* (fase 2 håndterer), *arkitektur-beslutning* (fase 3 håndterer), eller *[ANTAKELSE] bæres videre*?
+
+Hvis ett eller flere svar er nei: gå tilbake til svakeste tema (mønster 1) og kjør en runde til. Maks 3 runder før operatør tar eksplisitt beslutning om å eksitere med kjent svakhet (dokumenteres i brief sin "Åpne spørsmål"-seksjon).
+
+### Det som IKKE oversettes fra trekbrief
+
+trekbrief har mekanisk 1-5-scoring og dedikert reviewer-agent. Disse hører hjemme i per-task-kontekst der suksess-kriterier kan være command-checkable. Per-app-intervjuet skal IKKE importere dette — det blir premature lock-down. Hvis prototypen viser at en lett reviewer-pass faktisk hjelper, vurderes det i v0.5.0+.
+
 
-**Output 1: `01-interview-transcript.md`** `[hypotese]`
 
 Full samtale, råform. Ingen frontmatter krevd. Tidsstempel-merket per spørsmål-svar. Råmateriale for senere referanse, ikke en brief.