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>
43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
# Roadmap
|
|
|
|
## Now
|
|
|
|
Pre-design. Ingen aktivt arbeid. Repoet eksisterer som tenke-rom inntil forutsetningene under "Next" er oppfylt.
|
|
|
|
## Next
|
|
|
|
Forutsetninger før implementering kan starte:
|
|
|
|
- [ ] Én reell iOS app drevet manuelt gjennom tre-lags-mønsteret med håndholdte filer og Voyage som engine
|
|
- [ ] Friksjons-data fra prototypen er sammenstilt og dokumentert
|
|
- [ ] State-format og hjelper-prosess-kontrakt er observert i bruk, ikke bare designet
|
|
- [ ] Pre-brief skrevet basert på det observerte mønsteret
|
|
|
|
iOS er det konkrete testtilfellet, ikke et tilfeldig domene-valg — det er der friksjonen som rettferdiggjør app-creator faktisk oppstår (Xcode-prosjekter, simulator, code-signing, TestFlight).
|
|
|
|
## Later
|
|
|
|
- Levende arkitektur-fil som oppdateres når features lukkes
|
|
- Feature-kø med dependency-pekere mellom features
|
|
- Lokal hjelper-prosess (localhost-only) som broer HTML-grensesnitt til Voyage-CLI
|
|
- State-modell som kategoriserer menneske-vurderings-typer
|
|
- Strukturert state-eksport som app-factory kan aggregere
|
|
|
|
### v0.4.0-milepæl
|
|
|
|
v0.4.0 er versjonen som låser kontraktene app-factory bygger på (se `../app-factory/docs/alignment-brief.md` Funn 4). Definisjonen er fastsatt nå (intensjon, ikke implementering — innholdet låses når prototypen viser hva som faktisk fungerer):
|
|
|
|
- [ ] State-eksport-schema låst og dokumentert
|
|
- [ ] Hjelper-prosess-API låst og dokumentert
|
|
- [ ] Minst én iOS app drevet til shipping gjennom systemet
|
|
- [ ] Friksjons-data fra produksjons-bruk dokumentert som forutsetning for app-factory-design
|
|
|
|
Disse er forutsetninger, ikke deadlines. Hvis prototypen tar lengre tid blir milepælen stående — den skal ikke presse fram låsing før kontraktene er reelle.
|
|
|
|
## Parked
|
|
|
|
- **Per-task pipeline-disiplin.** Tilhører lag 1 (Voyage). Hvis app-creator trenger noe Voyage ikke gir, er det en arkitektur-feil — ikke en grunn til å duplisere Voyages ansvar.
|
|
- **Multi-app portefølje-styring.** Tilhører lag 3 (app-factory). app-creator kjenner én app om gangen.
|
|
- **Modifikasjoner av Voyage.** Voyage er CLI-kallbart, og det er den eneste integrasjonen. Voyage vet ikke om app-creator finnes — den asymmetrien er bevisst.
|
|
- **Autonome loops uten human-in-the-loop.** Solo-først per design.
|
|
- **Linear/Jira-erstatning.** Bruk eksisterende verktøy. app-creator orkestrerer én app, den dupliserer ikke generell project management.
|