feat(app-creator,app-factory): lock three-tier HTML architecture, tool-agnostic invariant

Tre-tier HTML-modell låst som endelig arkitektur:
- Tier 1: Voyage Plugin Playground (per-feature, v4.3+)
- Tier 2: app-creator per-app HTML (per-app, fase-progress + alle artefakter + attention)
- Tier 3: app-factory portefølje-HTML (per-portefølje, alle apper + klikk-til-terminal)

Hver tier har samme arkitektoniske form: AI skriver state i filer, tynt HTML
rendrer, menneske handler i terminal. Ingen backend, ingen RPC, ingen vendor-
låsing.

Verktøy-agnostisk lagt inn som HARD invariant: app-factory må fungere uten
Linear/Jira/Asana/etc. Tredjeparts sync-plugins er opt-in og additivt.
Tidligere Linear-overlag-modell forkastet.

Ny: app-factory/docs/architecture-brief.md (~190 linjer) som låser
arkitektur-invariantene og dokumenterer tekniske spørsmål som må avklares
ved /trekbrief.

Oppdatert i begge plugins:
- CLAUDE.md med tier-language, verktøy-agnostisk-grense, HTML-invarianter
- README.md med tre-tier-pitch
- ROADMAP.md med per-app HTML / portefølje-HTML i Later, sync-plugin-arkitektur
- CHANGELOG.md med arkitektur-låsing dokumentert
- alignment-brief.md: Funn 5 oppdatert (klikk-til-terminal er manuell, ikke autonom),
  ny non-goal om eksterne PM-verktøy som kjerne-avhengighet

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

CHANGELOG.md

@@ -10,3 +10,4 @@ All notable changes to this project will be documented in this file.
 
 ### Changed
 - Pre-design rescope: app-creator omdefinert som fase-basert pipeline (intervju → research → arkitektur → designsystem → constraints → features → briefer per feature). Brief-handover til Voyage er filoverlevering, ikke runtime-kobling. Tidligere scope (HTML-eksekvering via lokal hjelper-prosess) er fjernet — den brøt Voyages v4.3-modell (ingen kommando-utførelse fra HTML) og var symptom av ikke-skarpt definert scope.
+- Arkitektur-låsing til tre-tier HTML-modell (se `../app-factory/docs/architecture-brief.md`): hver tier (Voyage Plugin Playground, app-creator per-app HTML, app-factory portefølje-HTML) har samme arkitektoniske form. Per-app HTML er kjerne-leveranse, ikke tilleggsfunksjon. Verktøy-agnostisk er hard invariant — ingen Linear/Jira/etc i kjerne.

CLAUDE.md

@@ -11,22 +11,28 @@ Implementering starter ikke før:
 
 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.
+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
 
-Lag 2 i et tre-lags AI-utviklings-system. Per-app-disiplin.
+Tier 2 i et tre-tier HTML-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? |
+| 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:
 
 1. **Intervju** — strukturert dialog som henter ut app-intent, målgruppe, omfang, suksesskriterier
@@ -37,15 +43,26 @@ En fase-basert pipeline fra app-konsept til briefer som er ready som input til V
 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).
+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. app-creator orkestrerer én app om gangen.
+- **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.
+- **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
@@ -54,13 +71,15 @@ app-creator skal aldri eksekvere Voyage og aldri modifisere Voyage. Briefer over
 
 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) 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).
+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
 
@@ -73,21 +92,25 @@ app-creator vet ikke om app-factory finnes. Den eksporterer kun strukturert stat
 - Issues velkommen som signaler; pull requests aksepteres ikke
 - Ingen backward compatibility-garantier før v1.0.0
 
-## Tekniske invarianter (arvet fra Voyage)
+## Tekniske invarianter (arvet fra Voyage og v4.3)
 
-- 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)
+- **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-theme` med bootstrap-script + WCAG 2.1 AA-kontrast**
+- **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.
+3. **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.
 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?
+   - 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)?
 6. **Følg samme tone som Voyage** — ærlig, kompromissløs, eksplisitt om grenser. Ingen salgsspråk. Ingen vaporware-formuleringer.

README.md

@@ -1,13 +1,13 @@
 # app-creator
 
-Lag 2 i et tre-lags AI-utviklings-system: en pipeline fra app-konsept til feature-klare briefer som Voyage konsumerer.
+Tier 2 i et tre-tier HTML-system: en pipeline fra app-konsept til feature-klare briefer som Voyage konsumerer, med tynn per-app HTML for review og navigasjon.
 
 > **Status:** Pre-design. Ingen kode er skrevet ennå. Implementering venter på en manuell prototype gjennom hele app-creator → Voyage-pipelinen for én reell iOS app. Se [CLAUDE.md](CLAUDE.md) for full kontekst.
 
-## Tre-lags-systemet
+## Tre-tier-systemet
 
-| Lag | Plugin | Spørsmål den svarer på |
-|-----|--------|------------------------|
+| Tier | Plugin | Spørsmål den svarer på |
+|------|--------|------------------------|
 | 1 | Voyage | Hvordan utfører vi denne oppgaven riktig? |
 | 2 | app-creator | Hva trenger appen, og hva er neste brief? |
 | 3 | app-factory | Hvilken app trenger meg nå, og hvilken handling er nødvendig? |
@@ -16,6 +16,8 @@ Lag 2 i et tre-lags AI-utviklings-system: en pipeline fra app-konsept til featur
 
 Drive én app fra idé til feature-backlog gjennom syv faser: intervju → research (valgfri) → arkitekturavklaringer → designsystem → constraints → feature-derivasjon → brief per feature. Hver fase produserer en artefakt på filsystemet. Brief-fasen genererer Voyage-kompatible markdown-filer som Voyage `/trekplan` konsumerer uten endringer.
 
+Per-app HTML rendrer alle artefakter, viser fase-progress og attention, og lar deg drille ned til hver features Voyage Plugin Playground.
+
 app-creator eksekverer ikke Voyage. Briefer overleveres som filer.
 
 ## Hva app-creator ikke skal gjøre
@@ -23,7 +25,7 @@ app-creator eksekverer ikke Voyage. Briefer overleveres som filer.
 - Utføre tasks (Voyages jobb)
 - Eksekvere Voyage runtime (briefer er filhandover, ikke runtime-kall)
 - Aggregere flere apper (app-factorys jobb)
-- Erstatte Linear/Jira
+- Erstatte Linear/Jira eller forutsette eksterne PM-verktøy (verktøy-agnostisk)
 - Koordinere team
 - Kjøre autonomt uten human-in-the-loop
 

ROADMAP.md

@@ -21,6 +21,7 @@ iOS er det konkrete testtilfellet, ikke et tilfeldig domene-valg — det er der
 - **Fase-engine** som sekvenserer intervju → research → arkitektur → designsystem → constraints → features → briefer
 - **Fase-artefakter** med eksplisitt kontrakt mellom fasene (output fra én er input til neste)
 - **Brief-generator** som produserer Voyage-kompatibel `brief.md` med riktig frontmatter (Handover 1)
+- **Per-app HTML** (single-file, polling, vendored DS — gjenbruker v4.3-mønstre): fase-progress, alle artefakter, attention per app, drill-down til Voyage Plugin Playground per feature. Se `../app-factory/docs/architecture-brief.md` Tier 2.
 - **Levende arkitektur-fil** som oppdateres når Voyage-kjøringer avslører nye constraints
 - **Feature-backlog** med dependency-pekere mellom features (output fra fase 6)
 - **App-state-eksport**: hvor er vi i fase-pipelinen, hvilke briefer er sendt til Voyage, hvilke har returnert, hvilke venter på menneske-beslutning — strukturert slik at app-factory kan aggregere
@@ -31,6 +32,7 @@ v0.4.0 er versjonen som låser kontraktene som krysser lag-grenser (se `../app-f
 
 - [ ] Brief-handover-format mot Voyage låst og dokumentert (Voyage-kompatibel brief.md med frontmatter, round-trip-testet)
 - [ ] App-state-eksport-schema låst og dokumentert (fase-status, feature-backlog, brief-pipeline-status, Voyage-runs-status)
+- [ ] Per-app HTML klar (renderer alle fase-artefakter, fase-progress, attention per app, og drill-down til Voyage Plugin Playground)
 - [ ] Minst én iOS app drevet til shipping gjennom systemet (≥5 features fra brief til ferdig)
 - [ ] Friksjons-data fra produksjons-bruk dokumentert som forutsetning for app-factory-design
 
@@ -42,5 +44,6 @@ Disse er forutsetninger, ikke deadlines. Hvis prototypen tar lengre tid blir mil
 - **Multi-app portefølje-styring.** Tilhører lag 3 (app-factory). app-creator kjenner én app om gangen.
 - **Eksekvering av Voyage fra app-creator.** Briefer er filoverlevering. Voyage kjøres separat. Tidligere idé om "lokal hjelper-prosess som kjører Voyage-kommandoer fra HTML" er parkert — bryter Voyages v4.3-modell (ingen kommando-utførelse fra HTML) og var symptom av ikke-skarpt definert scope.
 - **Modifikasjoner av Voyage.** Voyage er CLI-kallbart, og det er den eneste integrasjonen. Voyage vet ikke om app-creator finnes — den asymmetrien er bevisst.
+- **Innebygd Linear/Jira/Asana-integrasjon.** Verktøy-agnostisk er hard invariant. Tredjeparts sync-plugin er opt-in mulighet, ikke kjerne.
 - **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.
+- **Linear/Jira-erstatning.** Bruk eksisterende verktøy via opt-in sync-plugin hvis ønskelig.