open/app-creator
1
0
Fork 0
Code Issues Releases Activity
app-creator/CLAUDE.md
Kjell Tore Guttormsen 89943dcb72 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>
2026-05-10 10:43:01 +02:00

6.5 KiB
Raw Blame History

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.