Kjell Tore Guttormsen
43b3d9a04a
app-creator (lag 2): per-app-orkestrering. CLAUDE.md med Status/lag-tabell/ arkitektur-grense/scope-test/arbeidsregler. ROADMAP med v0.4.0-milepæl som låser kontraktene app-factory bygger på. iOS som eksplisitt testtilfelle, ikke tilfeldig domene. app-factory (lag 3): per-portefølje state-aggregator. Allerede scaffolded fra tidligere /repo-init; legger til docs/alignment-brief.md (174 linjer) som identifiserer 5 kontrakter på tvers av Voyage/app-creator/app-factory: Voyage stability promise, app-creator state-eksport schema, hjelper- prosess-API, versjons-milepæl-konsistens, autonom-utløse-grensen. Begge plugins er pre-design — ingen kode shipped. Implementering venter på iOS app-prototype gjennom app-creator + Voyage som datagrunnlag. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
4.7 KiB
app-creator
Status
Pre-design. Ingen kode skal skrives i dette repoet ennå.
Implementering starter ikke før:
- Forfatteren har drevet én reell app gjennom tre-lags-mønsteret manuelt — håndholdte filer, Voyage som engine
- Friksjons-data fra prototypen er sammenstilt
- 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 | Hvilken oppgave er nestemann, og hvorfor passer den i appen? |
| 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.
Hva app-creator skal levere (over tid)
- 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
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
- 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.
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.
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.
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.
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
- Markdown for alt menneske-leselig
Arbeidsregler for Claude Code
- Forstå at dette er konseptuelt, ikke leveringsklart. Ikke generer kode med mindre forutsetningene under "Status" er oppfylt og forfatteren eksplisitt har bedt om det.
- 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.
- 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.
- Respekter posisjoneringen. Solo-maintained, fork-and-own, ærlig om status. Ikke skriv som om dette var et offentlig produkt med brukere.
- 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)?
- Tjener det forfatterens egen arbeidsflyt (reell friksjon, ikke spekulativ)?
- Kan det bygges med Node.js built-ins (zero-deps-invariant)?
- Følg samme tone som Voyage — ærlig, kompromissløs, eksplisitt om grenser. Ingen salgsspråk. Ingen vaporware-formuleringer.