Kjell Tore Guttormsen
2011507ea1
- domain-packs/ios-app/: komplett referanse-pakke (8 komponenter) — pack.json med components-map, conventions.md, 4 patterns/, gotchas.md, checklist.md splittet i 3 (App Store-submission + security-privacy/MASVS 2.1 + accessibility/WCAG 2.2 AA), 3 scaffold/-maler (PrivacyInfo.xcprivacy-plist, NSUsageDescription-inventar, ASC-metadata), eksempel-feature-brief i Voyage strict-mode-format, glossary.md. Hver teknisk påstand verifisert mot Apple Developer / W3C WAI / OWASP MAS. - domain-packs/claude-code-plugin/: stub — pack.json + conventions.md + gotchas.md + checklist.md + glossary.md ferdige (ekstrahert fra ktg-privat-konvensjoner); patterns/scaffold/examples er stubs. - docs/domain-pack-spec.md: § D2/D3/D4/D7 + restrisiko oppdatert — pack.json components-felt, core/supplementary låst til manifestet, checklist-splitt-konvensjon, snapshot-materialiserings-mekanikk presisert, iOS-versjons-korreksjon (iOS 26, ikke "iOS 18/19"), D7 → "forfattet i S6". - prototype-run/friksjon.md: #9 (Akashic-briefen refererer "iOS 19" som ikke finnes — rettes i S7) + S6-prosessnotater (checklist-splitt bekreftet nødvendig, components-gap fylt, verifiserings-asymmetri ios-app vs claude-code-plugin notert). - CLAUDE.md: peker til domain-packs/ under § Status. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
8.2 KiB
app-creator
Status
Pre-design. Ingen kode skal skrives i dette repoet ennå.
Implementering starter ikke før:
- 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
- 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.
Design-/kunnskaps-artefakter finnes (de er ikke implementerings-kode): docs/phase-design-draft.md (7-fase-designet), docs/domain-pack-spec.md (domene-nøytral spec), domain-packs/ (referanse-domain-packs — ios-app komplett, claude-code-plugin som stub), prototype-run/ (friksjons-logg + research fra prototype-arbeidet drevet av Akashic-instansen). "Ingen kode i pre-design" gjelder Swift/implementerings-kode, ikke disse markdown-/data-fil-artefaktene.
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:
- Intervju — strukturert dialog som henter ut app-intent, målgruppe, omfang, suksesskriterier
- Research (valgfri) — markedsanalyse, presedens, feasibility-sjekk, plattform-spesifikke gotchas
- Arkitekturavklaringer — tech-stack, deployment-modell, integrasjoner, sentrale patterns
- Designsystem — visuelle + interaksjons-tokens som binder alle features (HIG for iOS, Material for Android, egen for web osv.)
- Constraints — A11Y, ytelse, sikkerhet, plattform-regler (App Store, GDPR), governance
- Feature-derivasjon — backlog avledet fra alt over, med dependency-pekere mellom features
- 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-thememed bootstrap-script + WCAG 2.1 AA-kontrast- Markdown for alt menneske-leselig (intervju-transkripter, arkitektur-notater, briefer)
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å at app-creator eksekverer Voyage eller modifiserer den. Aldri forutsett eksterne PM-verktøy i kjerne. Briefer overleveres som filer.
- 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)?
- 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)?
- Følg samme tone som Voyage — ærlig, kompromissløs, eksplisitt om grenser. Ingen salgsspråk. Ingen vaporware-formuleringer.