refactor(app-creator,app-factory): rescope to phase-based brief-pipeline model

app-creator omdefinert som 7-fase pipeline (intervju → research → arkitektur
→ designsystem → constraints → features → briefer per feature) som produserer
Voyage-kompatible briefer. Brief-handover er filoverlevering, ikke
runtime-kobling.

Tidligere scope (lokal hjelper-prosess som eksekverer Voyage-kommandoer fra
HTML) er parkert — den brøt Voyages v4.3-modell (ingen kommando-utførelse
fra HTML) og var symptom av ikke-skarpt definert scope.

app-factory tilsvarende rescope: leser app-state, eksekverer ingenting.
Operatørens handling er context-switch til riktig app-creator-instans.

alignment-brief Funn 3 omskrevet fra hjelper-prosess-API til
brief-handover-format. Hard invariant lagt inn: runtime-kobling mellom
lagene er forbudt — alt går via filer.

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

CHANGELOG.md

@@ -7,3 +7,6 @@ All notable changes to this project will be documented in this file.
 ### Added
 - Initial repo scaffolding (CLAUDE.md, README, ROADMAP, TODO, CHANGELOG)
 - Pre-design dokumentert. Ingen kode ennå.
+
+### Changed
+- Pre-design rescope: app-creator omdefinert som fase-basert pipeline (intervju → research → arkitektur → designsystem → constraints → features → briefer per feature). Brief-handover til Voyage er filoverlevering, ikke runtime-kobling. Tidligere scope (HTML-eksekvering via lokal hjelper-prosess) er fjernet — den brøt Voyages v4.3-modell (ingen kommando-utførelse fra HTML) og var symptom av ikke-skarpt definert scope.

CLAUDE.md

@@ -5,7 +5,7 @@
 **Pre-design.** Ingen kode skal skrives i dette repoet ennå.
 
 Implementering starter ikke før:
-1. Forfatteren har drevet én reell app gjennom tre-lags-mønsteret manuelt — håndholdte filer, Voyage som engine
+1. Forfatteren har drevet én reell iOS app gjennom hele app-creator → Voyage-pipelinen manuelt — håndholdte fase-artefakter, briefer skrevet for hånd, Voyage som engine
 2. Friksjons-data fra prototypen er sammenstilt
 3. Pre-brief er skrevet basert på det observerte mønsteret
 
@@ -20,39 +20,51 @@ Lag 2 i et tre-lags AI-utviklings-system. Per-app-disiplin.
 | Lag | Plugin | Disiplin | Spørsmål den svarer på |
 |-----|--------|----------|------------------------|
 | 1 | Voyage | Per-task | Hvordan utfører vi denne oppgaven riktig? |
-| 2 | app-creator (dette) | Per-app | Hvilken oppgave er nestemann, og hvorfor passer den i appen? |
+| 2 | app-creator (dette) | Per-app | Hva trenger appen, og hva er neste brief? |
 | 3 | app-factory | Per-portefølje | Hvilken app trenger meg nå, og hvilken handling er nødvendig? |
 
-app-creator tar over der Voyage slutter. Voyage er optimalisert for én oppgave; app-creator er optimalisert for én app over hele dens livssyklus (typisk 15–30 features). Den er bevisst designet som **per-app-orkestrator**, ikke som task-executor.
+app-creator er en pipeline fra app-konsept til feature-klare briefer. Voyage konsumerer briefene og leverer features. app-creator er pre-Voyage — den løser problemet "hva skal bygges" før Voyage løser "hvordan bygges det".
 
-## Hva app-creator skal levere (over tid)
+## Hva app-creator skal levere
 
-- Levende arkitektur-fil som oppdateres som bivirkning av at features lukkes
-- Feature-kø med dependency-pekere mellom features
-- Lokal hjelper-prosess (localhost-only) som lar HTML-grensesnittet utføre Voyage-kommandoer i riktig prosjekt-mappe uten kopier-lim-friksjon
-- State-modell som kategoriserer hva som krever menneske-vurdering
+En fase-basert pipeline fra app-konsept til briefer som er ready som input til Voyage:
+
+1. **Intervju** — strukturert dialog som henter ut app-intent, målgruppe, omfang, suksesskriterier
+2. **Research** (valgfri) — markedsanalyse, presedens, feasibility-sjekk, plattform-spesifikke gotchas
+3. **Arkitekturavklaringer** — tech-stack, deployment-modell, integrasjoner, sentrale patterns
+4. **Designsystem** — visuelle + interaksjons-tokens som binder alle features (HIG for iOS, Material for Android, egen for web osv.)
+5. **Constraints** — A11Y, ytelse, sikkerhet, plattform-regler (App Store, GDPR), governance
+6. **Feature-derivasjon** — backlog avledet fra alt over, med dependency-pekere mellom features
+7. **Brief per feature** — én markdown-fil per feature, formatert som Voyage-kompatibel input (Handover 1)
+
+Hver fase produserer en artefakt på filsystemet. Faser kan re-besøkes når app-en lærer av Voyage-kjøringer (særlig fase 3 og 6 — arkitektur-beslutninger og feature-backlog kan endre seg basert på hva som faktisk fungerte i shipped features).
 
 ## Hva app-creator IKKE skal absorbere
 
-- **Per-task pipeline-disiplin** — det er Voyages ansvar
-- **Multi-app portefølje-styring** — det er app-factorys ansvar
-- **Team-koordinering** — solo-først per design
-- **Project management** — Linear, Jira, GitHub Projects gjør det bedre
+- **Per-task pipeline-disiplin** — det er Voyages ansvar. app-creator skriver briefer; Voyage utfører dem.
+- **Eksekvering av Voyage** — app-creator overleverer briefer som filer. Aldri runtime-kall, aldri helper-process som kjører Voyage-kommandoer.
+- **Multi-app portefølje-styring** — det er app-factorys ansvar. app-creator orkestrerer én app om gangen.
+- **Team-koordinering** — solo-først per design.
+- **Project management-erstatning** — Linear, Jira, GitHub Projects gjør det bedre. Bruk dem hvis du trenger dem; app-creator integrerer ikke.
 - **Autonome loops uten human-in-the-loop**
 
 ## Den sentrale arkitektur-grensen
 
-app-creator skal aldri modifisere Voyage. Voyage er CLI-kallbart, og det er den eneste integrasjonen. Hvis app-creator trenger noe Voyage ikke gir, er det en arkitektur-feil i app-creator — ikke en grunn til å patche Voyage.
+app-creator skal aldri eksekvere Voyage og aldri modifisere Voyage. Briefer overleveres som markdown-filer. Voyage kjøres separat med brief-fila som input.
 
-Voyage vet ikke om app-creator finnes, og skal ikke vite det. Den asymmetrien er **bevisst** og er det som gjør at lag 1 og lag 2 kan utvikles uavhengig uten å lekke ansvar.
+Voyage vet ikke om app-creator finnes, og skal ikke vite det. Briefen er ikke merket som "app-creator-generert" — den er bare en velformet Voyage-brief. Den asymmetrien er bevisst og er det som gjør at lag 1 og lag 2 kan utvikles uavhengig uten å lekke ansvar.
 
 ## Forholdet til Voyage
 
-app-creator forutsetter Voyage som lag 1 og bygger over Voyages eksisterende handover-kontrakter via CLI-kall. Aldri direkte modifikasjon, aldri patching, aldri shadow-implementering av Voyages oppgaver.
+app-creator produserer briefer. Voyage konsumerer briefer. Handover er en filoverlevering, ikke en runtime-kobling.
+
+Brief-format-kontrakten er det eneste integrasjonspunktet. app-creator må produsere briefer som Voyage `/trekplan` kan konsumere uten endringer (Handover 1). Hvis Voyage endrer brief-formatet, må app-creator oppdatere sin generator — Voyage skal ikke kjenne til app-creator som downstream-konsument.
+
+Voyages v4.3 (Plugin Playground) og v6.0 (iOS domain) er komplementære, ikke overlappende: v4.3 viser artefakter for én pipeline-kjøring; app-creator viser app-nivå tilstand på tvers av mange. v6.0 gir Voyage iOS-regler under task-execution; app-creator håndterer iOS på app-nivå (HIG-baserte designsystem-beslutninger, App Store-constraints, plattform-arkitektur).
 
 ## Forholdet til app-factory
 
-app-creator vet ikke om app-factory finnes. Den eksporterer kun strukturert state som app-factory kan **lese og aggregere**. Ingen tilbake-kall, ingen avhengighet andre veien.
+app-creator vet ikke om app-factory finnes. Den eksporterer kun strukturert state — fase-status, feature-backlog, brief-pipeline-status, Voyage-runs-status — som app-factory kan **lese og aggregere**. Ingen tilbake-kall, ingen avhengighet andre veien.
 
 ## Posisjonering
 
@@ -65,17 +77,17 @@ app-creator vet ikke om app-factory finnes. Den eksporterer kun strukturert stat
 
 - Zero npm dependencies utover Node.js built-ins der det er mulig
 - Hooks og validators som self-contained `.mjs`-filer
-- Filsystem som primær state-backend
-- Markdown for alt menneske-leselig
+- Filsystem som primær state-backend (fase-artefakter er filer)
+- Markdown for alt menneske-leselig (intervju-transkripter, arkitektur-notater, briefer)
 
 ## Arbeidsregler for Claude Code
 
 1. **Forstå at dette er konseptuelt, ikke leveringsklart.** Ikke generer kode med mindre forutsetningene under "Status" er oppfylt og forfatteren eksplisitt har bedt om det.
 2. **Hold lag-grensene rene.** Ikke absorbere ansvar fra Voyage eller app-factory. Hvis en idé sklir inn i task-execution eller portefølje-aggregering, hører den hjemme i et annet lag.
-3. **Respekter den sentrale arkitektur-grensen.** Aldri foreslå modifikasjoner av Voyage. Forslag som krever Voyage-endringer må flagges eksplisitt som arkitektur-spørsmål, ikke implementeres som drive-by.
+3. **Respekter den sentrale arkitektur-grensen.** Aldri foreslå at app-creator eksekverer Voyage eller modifiserer den. Briefer overleveres som filer. Forslag som krever runtime-kobling må flagges eksplisitt som arkitektur-spørsmål.
 4. **Respekter posisjoneringen.** Solo-maintained, fork-and-own, ærlig om status. Ikke skriv som om dette var et offentlig produkt med brukere.
 5. **Anvend scope-testen for nye ideer.** Tre spørsmål, alle må besvares ja:
    - Er dette per-app-disiplin (ikke per-task, ikke per-portefølje)?
+   - Hører ideen hjemme i en av de syv fasene, eller utvider den scope?
    - Tjener det forfatterens egen arbeidsflyt (reell friksjon, ikke spekulativ)?
-   - Kan det bygges med Node.js built-ins (zero-deps-invariant)?
 6. **Følg samme tone som Voyage** — ærlig, kompromissløs, eksplisitt om grenser. Ingen salgsspråk. Ingen vaporware-formuleringer.

README.md

@@ -1,24 +1,27 @@
 # app-creator
 
-Lag 2 i et tre-lags AI-utviklings-system: per-app-orkestrering som holder én app sammenhengende over hele dens livssyklus.
+Lag 2 i et tre-lags AI-utviklings-system: en pipeline fra app-konsept til feature-klare briefer som Voyage konsumerer.
 
-> **Status:** Pre-design. Ingen kode er skrevet ennå. Implementering venter på en manuell prototype gjennom tre-lags-mønsteret som datagrunnlag for friksjons-mønsteret. Se [CLAUDE.md](CLAUDE.md) for full kontekst.
+> **Status:** Pre-design. Ingen kode er skrevet ennå. Implementering venter på en manuell prototype gjennom hele app-creator → Voyage-pipelinen for én reell iOS app. Se [CLAUDE.md](CLAUDE.md) for full kontekst.
 
 ## Tre-lags-systemet
 
 | Lag | Plugin | Spørsmål den svarer på |
 |-----|--------|------------------------|
 | 1 | Voyage | Hvordan utfører vi denne oppgaven riktig? |
-| 2 | app-creator | Hvilken oppgave er nestemann, og hvorfor passer den i appen? |
+| 2 | app-creator | Hva trenger appen, og hva er neste brief? |
 | 3 | app-factory | Hvilken app trenger meg nå, og hvilken handling er nødvendig? |
 
 ## Hva app-creator skal gjøre
 
-Holde én app koherent over 15–30 features. Levende arkitektur-fil som oppdateres når features lukkes, feature-kø med dependency-pekere, lokal hjelper-prosess som broer HTML-grensesnitt til Voyage-CLI uten kopier-lim-friksjon, og en state-modell som tydeliggjør hva som krever menneske-vurdering.
+Drive én app fra idé til feature-backlog gjennom syv faser: intervju → research (valgfri) → arkitekturavklaringer → designsystem → constraints → feature-derivasjon → brief per feature. Hver fase produserer en artefakt på filsystemet. Brief-fasen genererer Voyage-kompatible markdown-filer som Voyage `/trekplan` konsumerer uten endringer.
+
+app-creator eksekverer ikke Voyage. Briefer overleveres som filer.
 
 ## Hva app-creator ikke skal gjøre
 
 - Utføre tasks (Voyages jobb)
+- Eksekvere Voyage runtime (briefer er filhandover, ikke runtime-kall)
 - Aggregere flere apper (app-factorys jobb)
 - Erstatte Linear/Jira
 - Koordinere team

ROADMAP.md

@@ -8,28 +8,30 @@ Pre-design. Ingen aktivt arbeid. Repoet eksisterer som tenke-rom inntil forutset
 
 Forutsetninger før implementering kan starte:
 
-- [ ] Én reell iOS app drevet manuelt gjennom tre-lags-mønsteret med håndholdte filer og Voyage som engine
+- [ ] Én reell iOS app drevet manuelt gjennom hele app-creator → Voyage-pipelinen — håndholdte fase-artefakter, briefer skrevet for hånd, Voyage konsumerer dem
 - [ ] Friksjons-data fra prototypen er sammenstilt og dokumentert
-- [ ] State-format og hjelper-prosess-kontrakt er observert i bruk, ikke bare designet
+- [ ] Brief-handover-format mot Voyage er observert i praksis (round-trip-testet på reell brief), ikke bare designet
+- [ ] App-state-format er observert i bruk
 - [ ] Pre-brief skrevet basert på det observerte mønsteret
 
-iOS er det konkrete testtilfellet, ikke et tilfeldig domene-valg — det er der friksjonen som rettferdiggjør app-creator faktisk oppstår (Xcode-prosjekter, simulator, code-signing, TestFlight).
+iOS er det konkrete testtilfellet, ikke et tilfeldig domene-valg — det er der friksjonen som rettferdiggjør app-creator faktisk oppstår (Xcode-prosjekter, simulator, code-signing, TestFlight, App Store-constraints, HIG-baserte designsystem-beslutninger).
 
 ## Later
 
-- Levende arkitektur-fil som oppdateres når features lukkes
-- Feature-kø med dependency-pekere mellom features
-- Lokal hjelper-prosess (localhost-only) som broer HTML-grensesnitt til Voyage-CLI
-- State-modell som kategoriserer menneske-vurderings-typer
-- Strukturert state-eksport som app-factory kan aggregere
+- **Fase-engine** som sekvenserer intervju → research → arkitektur → designsystem → constraints → features → briefer
+- **Fase-artefakter** med eksplisitt kontrakt mellom fasene (output fra én er input til neste)
+- **Brief-generator** som produserer Voyage-kompatibel `brief.md` med riktig frontmatter (Handover 1)
+- **Levende arkitektur-fil** som oppdateres når Voyage-kjøringer avslører nye constraints
+- **Feature-backlog** med dependency-pekere mellom features (output fra fase 6)
+- **App-state-eksport**: hvor er vi i fase-pipelinen, hvilke briefer er sendt til Voyage, hvilke har returnert, hvilke venter på menneske-beslutning — strukturert slik at app-factory kan aggregere
 
 ### v0.4.0-milepæl
 
-v0.4.0 er versjonen som låser kontraktene app-factory bygger på (se `../app-factory/docs/alignment-brief.md` Funn 4). Definisjonen er fastsatt nå (intensjon, ikke implementering — innholdet låses når prototypen viser hva som faktisk fungerer):
+v0.4.0 er versjonen som låser kontraktene som krysser lag-grenser (se `../app-factory/docs/alignment-brief.md` Funn 2-4). Definisjonen er fastsatt nå (intensjon, ikke implementering — innholdet låses når prototypen viser hva som faktisk fungerer):
 
-- [ ] State-eksport-schema låst og dokumentert
-- [ ] Hjelper-prosess-API låst og dokumentert
-- [ ] Minst én iOS app drevet til shipping gjennom systemet
+- [ ] Brief-handover-format mot Voyage låst og dokumentert (Voyage-kompatibel brief.md med frontmatter, round-trip-testet)
+- [ ] App-state-eksport-schema låst og dokumentert (fase-status, feature-backlog, brief-pipeline-status, Voyage-runs-status)
+- [ ] Minst én iOS app drevet til shipping gjennom systemet (≥5 features fra brief til ferdig)
 - [ ] Friksjons-data fra produksjons-bruk dokumentert som forutsetning for app-factory-design
 
 Disse er forutsetninger, ikke deadlines. Hvis prototypen tar lengre tid blir milepælen stående — den skal ikke presse fram låsing før kontraktene er reelle.
@@ -38,6 +40,7 @@ Disse er forutsetninger, ikke deadlines. Hvis prototypen tar lengre tid blir mil
 
 - **Per-task pipeline-disiplin.** Tilhører lag 1 (Voyage). Hvis app-creator trenger noe Voyage ikke gir, er det en arkitektur-feil — ikke en grunn til å duplisere Voyages ansvar.
 - **Multi-app portefølje-styring.** Tilhører lag 3 (app-factory). app-creator kjenner én app om gangen.
+- **Eksekvering av Voyage fra app-creator.** Briefer er filoverlevering. Voyage kjøres separat. Tidligere idé om "lokal hjelper-prosess som kjører Voyage-kommandoer fra HTML" er parkert — bryter Voyages v4.3-modell (ingen kommando-utførelse fra HTML) og var symptom av ikke-skarpt definert scope.
 - **Modifikasjoner av Voyage.** Voyage er CLI-kallbart, og det er den eneste integrasjonen. Voyage vet ikke om app-creator finnes — den asymmetrien er bevisst.
 - **Autonome loops uten human-in-the-loop.** Solo-først per design.
 - **Linear/Jira-erstatning.** Bruk eksisterende verktøy. app-creator orkestrerer én app, den dupliserer ikke generell project management.