app-creator/CLAUDE.md

app-creator

Status

Pre-design. Ingen kode skal skrives i dette repoet ennå.

Implementering starter ikke før:

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

Inntil det: dette repoet eksisterer som et tenke-rom. Hvis du som Claude blir bedt om å "begynne å bygge", stopp og bekreft at forutsetningene over er oppfylt.

Lag-alignment mot Voyage og app-factory er dokumentert i ../app-factory/docs/alignment-brief.md (kontrakter) og ../app-factory/docs/architecture-brief.md (tre-tier HTML-arkitektur og verktøy-agnostisk invariant). Disse dokumentene låser kontrakter og arkitektur-invarianter; runtime-asymmetrien (app-creator vet ikke om app-factory) er bevart — referansene er kun for design-fasen.

Hva app-creator er

Tier 2 i et tre-tier HTML-system. Per-app-disiplin.

Tier	Plugin	Disiplin	Spørsmål den svarer på
1	Voyage	Per-task (Plugin Playground)	Hvordan utfører vi denne oppgaven riktig?
2	app-creator (dette)	Per-app (per-app HTML)	Hva trenger appen, og hva er neste brief?
3	app-factory	Per-portefølje (portefølje-HTML)	Hvilken app trenger meg nå, og hvilken handling er nødvendig?

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".

Hver tier har samme arkitektoniske form: AI skriver state i filer, tynt HTML rendrer dem, menneske handler i terminal. Mønsteret arvet fra Voyages v4.3 Plugin Playground.

Hva app-creator skal levere

To leveranser, sammensatt:

Fase-pipeline (AI-laget)

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.

Per-app HTML (presentasjons-laget)

Et tynt HTML-grensesnitt per app som rendrer:

• Fase-progress — hvor i pipelinen er appen, visuell 1-7
• Alle artefakter — intervju-transkript, research-notater, arkitektur-beslutninger, designsystem (med visuelle prøver), constraints, feature-backlog, alle briefer
• Attention per app — hva må gjøres nå (godkjenn brief, ta arkitektur-beslutning, start neste fase, review feature-backlog)
• Drill-down til Voyage Playground — klikk en feature → åpne v4.3-flaten for den feature-en hvis kjørt; ellers vis dens brief

HTML-grensesnittet gjenbruker v4.3-mønstre 1:1: single-file, vendored DS, polling, theme-bootstrap, WCAG.

Hva app-creator IKKE skal absorbere

• 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.
• Innebygd Linear/Jira-integrasjon — verktøy-agnostisk er hard invariant; tredjeparts sync-plugins er opt-in
• 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 direkte.
• Autonome loops uten human-in-the-loop

Den sentrale arkitektur-grensen

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. 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.

Verktøy-agnostisk er hard invariant — kjerne-arkitekturen forutsetter ingen eksterne PM-verktøy. Sync-plugins er valgfri tredjepart. Se ../app-factory/docs/architecture-brief.md for full begrunnelse.

Forholdet til Voyage

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 er den arkitektoniske forfaren for app-creators per-app HTML — samme single-file-mønster, vendored DS, polling, theme-bootstrap. app-creator gjenbruker disse 1:1.

Forholdet til app-factory

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

• Solo-maintained, fork-and-own
• Primær-konsumert av forfatteren for forfatterens eget arbeid
• Issues velkommen som signaler; pull requests aksepteres ikke
• Ingen backward compatibility-garantier før v1.0.0

Tekniske invarianter (arvet fra Voyage og v4.3)

• Zero npm dependencies utover Node.js built-ins (vendored DS er ok)
• Single-file HTML — ingen build-step
• Hooks og validators som self-contained .mjs-filer
• Filsystem som primær state-backend (fase-artefakter er filer)
• Browser-state er ephemeral — sannheten lever i filer
• Polling, ikke websockets — sub-30s latency er nok
• data-theme med bootstrap-script + WCAG 2.1 AA-kontrast
• 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å at app-creator eksekverer Voyage eller modifiserer den. Aldri forutsett eksterne PM-verktøy i kjerne. Briefer overleveres som filer.
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 i per-app HTML, eller utvider den scope?
   • Tjener det forfatterens egen arbeidsflyt (reell friksjon, ikke spekulativ)?
6. Følg samme tone som Voyage — ærlig, kompromissløs, eksplisitt om grenser. Ingen salgsspråk. Ingen vaporware-formuleringer.