Kjell Tore Guttormsen
89943dcb72
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>
93 lines
6.5 KiB
Markdown
93 lines
6.5 KiB
Markdown
# 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`. Den briefen er meta-dokumentet som identifiserer kontrakter som må låses, og den brukes til å vurdere drift mellom lagene. Runtime-asymmetrien (app-creator vet ikke om app-factory) er bevart — referansen er kun for design-fasen.
|
|
|
|
## Hva app-creator er
|
|
|
|
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 | 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 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
|
|
|
|
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. 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 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.
|
|
|
|
## 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) 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 — 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)
|
|
|
|
- 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 (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å 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)?
|
|
6. **Følg samme tone som Voyage** — ærlig, kompromissløs, eksplisitt om grenser. Ingen salgsspråk. Ingen vaporware-formuleringer.
|