docs(a1): dok-resync mot verifisert virkelighet per review-2026-07

Sesjon A1 i docs/masterplan.md § Fase A. Fjerner utdaterte/usanne premisser
fra normativ tekst, med docs/review-2026-07.md som fasit. Ingen nye
design-beslutninger (de hører i A2/A5/C2); domain-packs urørt (A3).

- R-01: «v4.3 Plugin Playground» merket historisk overalt (flaten slettet i
  Voyage v5.0.0, 2026-05-12; mønstrene er arven). Drill-down redefinert til
  feature-ens voyage_run_dir-artefakter + annotate-HTML. Handover 8 og
  /trekrevise fjernet som gjeldende mønster — S5-beslutningen om «to
  gate-nivåer» faller bort; det er én, den lette.
- R-05: død annotate-/kontrakt-sti (plugins/marketplaces/…) erstattet med
  cache-sti-regel + oppslag av nyeste versjon. Sidecar-fila
  <artefakt>.review.md korrigert: den finnes ikke — annotasjoner lever i
  localStorage; eksport-til-fil er D7.
- R-09: § Flersesjons-protokoll omskrevet til STATE.md-konvensjonen;
  prototype-run/README-tabellen rettet.
- R-13: iOS-versjonseksempler gjort domene-nøytrale; HTML-invarianten
  avklart til WCAG 2.2 AA.
- R-14: fase 2s pack-input strøket (motsa pack-manifestets phases).
- R-15: max-3-regelen redefinert — snapshot = én lasting, maks 3
  supplementary utover; fase 5-inputlista rettet.
- R-16: runtime-asymmetrien omformulert til skjema-asymmetri (ingen
  runtime-kobling, Handover 1 eneste kobling, ingen privilegert produsent).
- R-06 (delvis): phase_status samlet i én autoritativ enum-tabell,
  pending-review lagt til i frontmatter-enumen; kjente avvik henvist til C2.
- R-04/R-02: § Fase 7 merket STALE (2.0-pin, stale verifikasjonsnote,
  «round-trip PASS» = mental simulering, ikke kjøring).
- R-17: CHANGELOG-referansene rettet + Unreleased-entry for denne resyncen.
- R-20: «6-tema-intervju» → «8-tema» (sjekklisten lister 8).

Verifisering: iOS 19 → 0; iOS 18 → 0; 6-tema-intervju → 0; WCAG 2.1 i
CLAUDE.md → 0; «ROADMAP, TODO» → 0; pending-review → 7; Handover
8/trekrevise og plugins/marketplaces kun i eksplisitt historisk-merkede
eller advarende treff.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TJ99ZtNvvxaDPfNTED7gnC

CHANGELOG.md

@@ -5,9 +5,13 @@ All notable changes to this project will be documented in this file.
 ## [Unreleased]
 
 ### Added
-- Initial repo scaffolding (CLAUDE.md, README, ROADMAP, TODO, CHANGELOG)
+- Initial repo scaffolding (CLAUDE.md, README.md, `docs/roadmap.md`, CHANGELOG)
 - Pre-design dokumentert. Ingen kode ennå.
+- Domain-pack-spec (`docs/domain-pack-spec.md`) og referanse-packs i `domain-packs/` (`ios-app` komplett, `claude-code-plugin` som stub).
+- Prototype-run-materiale: friksjonslogg og design-research (`prototype-run/`).
+- Uavhengig kryssmodell-review (`docs/review-2026-07.md`, Fable 5, 2026-07-10 — 19 funn) og masterplan til v1.0.0 (`docs/masterplan.md`), promotert som gjeldende plan 2026-07-10.
 
 ### 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.
+- 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. *(Merknad lagt til 2026-08-10: «Voyage Plugin Playground» er historisk — flaten ble slettet i Voyage v5.0.0, 2026-05-12. Det som er arvet er mønstrene, ikke flaten.)*
+- Dok-resync mot verifisert virkelighet (sesjon A1, 2026-08-10, per `docs/review-2026-07.md`): v4.3 Plugin Playground merket historisk overalt; drill-down redefinert til feature-ens `voyage_run_dir`-artefakter + annotate-HTML; døde Handover 8-/`trekrevise`-referanser fjernet fra normativ tekst; død annotate-sti erstattet med cache-sti-regel; § Flersesjons-protokoll omskrevet til STATE.md-konvensjonen; iOS-versjonseksempler gjort domene-nøytrale; HTML-invarianten avklart til WCAG 2.2 AA; runtime-asymmetrien omformulert til skjema-asymmetri; max-3-regelen redefinert; fase 2s pack-input fjernet; `phase_status`-enumene samlet i én tabell.

CLAUDE.md

@@ -21,13 +21,13 @@ 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? |
+| 1 | Voyage | Per-task (brief → research → plan → execute → review) | 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.
+Hver tier har samme arkitektoniske form: AI skriver state i filer, tynt HTML rendrer dem, menneske handler i terminal. Mønsteret er arvet fra Voyages v4.3 Plugin Playground — **historisk forfar: flaten ble slettet i Voyage v5.0.0 (2026-05-12), mønstrene er arven.**
 
 ## Hva app-creator skal levere
 
@@ -53,9 +53,9 @@ 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
+- **Drill-down til feature-ens Voyage-artefakter** — klikk en feature → åpne artefaktene fra dens Voyage-kjøring (`voyage_run_dir`) og/eller annotate-HTML-filene; er den ikke kjørt, vis dens brief
 
-HTML-grensesnittet gjenbruker v4.3-mønstre 1:1: single-file, vendored DS, polling, theme-bootstrap, WCAG.
+HTML-grensesnittet gjenbruker **mønstrene** fra v4.3 Plugin Playground 1:1: single-file, vendored DS, polling, theme-bootstrap, WCAG. Selve playground-flaten finnes ikke lenger (slettet i Voyage v5.0.0) — den er forfar, ikke lenke-mål.
 
 ## Hva app-creator IKKE skal absorbere
 
@@ -71,7 +71,9 @@ HTML-grensesnittet gjenbruker v4.3-mønstre 1:1: single-file, vendored DS, polli
 
 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.
+Asymmetrien som skal beskyttes er **skjema-asymmetrien, ikke en kunnskaps-påstand**: ingen runtime-kobling i noen retning; briefen er umerket og bare en velformet Voyage-brief; Handover 1 er eneste koblingspunkt; ingen produsent er privilegert. Det er dette som gjør at lag 1 og lag 2 kan utvikles uavhengig uten å lekke ansvar.
+
+Voyages egen kontrakt navngir «Tier 2 `app-creator`» i en informasjonell produsent-kontekst (`HANDOVER-CONTRACTS.md`) samtidig som den slår fast at ingen produsent er privilegert og at Handover 1 er eneste kobling. Å kreve at Voyage «ikke vet om» app-creator er derfor både usant og verdiløst — kravet er at ingenting i Voyage *avhenger* av app-creator. Ikke «rett» Voyage-dokumentasjon på dette punktet (det ville brutt «aldri modifisere Voyage»).
 
 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.
 
@@ -81,7 +83,7 @@ app-creator produserer briefer. Voyage konsumerer briefer. Handover er en filove
 
 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.
+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 mønstrene 1:1. **Forfaren er historisk:** Voyage v5.0.0 (2026-05-12) slettet `playground/`, Handover 8 og `/trekrevise`; dagens Voyage-flate for annotering er `scripts/annotate.mjs` (per-artefakt HTML). Mønstrene er fortsatt arven — flaten er ikke noe å lenke til.
 
 ## Forholdet til app-factory
 
@@ -102,7 +104,7 @@ app-creator vet ikke om app-factory finnes. Den eksporterer kun strukturert stat
 - **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**
+- **`data-theme` med bootstrap-script + WCAG 2.2 AA-kontrast** (2.2 er gjeldende W3C Rec; konsistent med fase 5 og domain-pack-ene, som alle krever 2.2 — avklart i A1, jf. R-13)
 - **Markdown for alt menneske-leselig** (intervju-transkripter, arkitektur-notater, briefer)
 
 ## Arbeidsregler for Claude Code

README.md

@@ -16,7 +16,7 @@ Tier 2 i et tre-tier HTML-system: en pipeline fra app-konsept til feature-klare
 
 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.
+Per-app HTML rendrer alle artefakter, viser fase-progress og attention, og lar deg drille ned til artefaktene fra hver features Voyage-kjøring (`voyage_run_dir` + annotate-HTML). Mønstrene er arvet fra Voyages v4.3 Plugin Playground — en historisk forfar; selve flaten ble slettet i Voyage v5.0.0.
 
 app-creator eksekverer ikke Voyage. Briefer overleveres som filer.
 

docs/phase-design-draft.md

@@ -3,7 +3,8 @@
 <!-- Skrevet: 2026-05-10 -->
 <!-- Revidert: 2026-05-10 — brief-pattern: hver fase produserer én eller flere briefer med konsistent grunnstruktur -->
 <!-- Revidert: 2026-05-11 (S5) — anvendt revisjons-mandat R1–R17 fra prototype-run/research/research-brief.md: features/{NN}-{slug}/-layout, 00-context/, domain-pack-konsumering per fase, flersesjons-notat, rapid mode, skippbare faser med begrunnelse, hard lengde-grense, fase 4 trigger-på-bruk, fase 3 spørsmål-ikke-spekulasjon, manglende eierfaser, fase 5 mot standarder, fase 1-justeringer fra friksjon #1–4, status-merking. -->
-<!-- Status: ANDREUTKAST. Revidert mot design-research, ikke ennå mot reell pipeline-kjøring forbi fase 1. Innholdet låses ikke før Akashic-prototypen er drevet videre og friksjons-loggen viser hva som faktisk fungerte. -->
+<!-- Revidert: 2026-08-10 (A1, dok-resync mot docs/review-2026-07.md) — fjernet døde premisser: v4.3 Plugin Playground merket historisk (slettet i Voyage v5.0.0); Handover 8/`trekrevise` fjernet som gjeldende mønster; annotate-/kontrakt-stier flyttet til cache-sti-regel; § Flersesjons-protokoll omskrevet til STATE.md-konvensjonen; iOS-versjonseksempler gjort domene-nøytrale; max-3-regelen redefinert (snapshot = én lasting); fase 2s pack-input strøket; `phase_status`-enum samlet i én autoritativ tabell (+ `pending-review`); § Fase 7 merket STALE (2.0-pin, omskrives i A5); «6-tema» → «8-tema». Se docs/masterplan.md § Fase A. -->
+<!-- Status: ANDREUTKAST. Revidert mot design-research, ikke ennå mot reell pipeline-kjøring forbi fase 1. Innholdet låses ikke før Akashic-prototypen er drevet videre og friksjons-loggen viser hva som faktisk fungerte. IKKE LÅST: § Fase 7 (2.0-pin, A5), § Hard lengde-grense (flat 500-ords-grense empirisk motbevist, A2), state.json-schema (C2). -->
 
 ## Hvorfor dette dokumentet finnes
 
@@ -15,7 +16,7 @@ Dette dokumentet er **arbeidshypoteser**, ikke spesifikasjon. Hver brief-templat
 
 Design-researchen avdekket en reell spenning: prior art (threads A, B) sier "strukturen er riktig — fyll gapene"; den contrarian tråden (E) sier "default-retningen er feil — for en solo-dev som bygger en liten app for seg selv er fem av syv faser spekulativ infrastruktur, brief-first ikke full-pipeline-first." S5-stillingstaken (operatør kan overstyre):
 
-1. **Minimal-men-gyldig app-brief er obligatorisk anker.** Aldri hoppbar — uten den hallusinerer AI-en nedstrøms. Men "minimal" kan bety en kort fritekst-variant (`problem-statement + åpne spørsmål`), ikke det fulle 6-tema-intervjuet med kvalitets-sjekk.
+1. **Minimal-men-gyldig app-brief er obligatorisk anker.** Aldri hoppbar — uten den hallusinerer AI-en nedstrøms. Men "minimal" kan bety en kort fritekst-variant (`problem-statement + åpne spørsmål`), ikke det fulle 8-tema-intervjuet med kvalitets-sjekk.
 2. **Fase 2 / 4 / 5 er skippbare med eksplisitt én-setnings-begrunnelse loggført i `state.json`** — ikke bare "valgfri", men "Hopper over designsystem fordi: early stage, ingen andre brukere."
 3. **Fase 4 (designsystem) trigges på bruk, ikke plan** — aktiveres etter at første Voyage-kjøring har produsert faktiske UI-komponenter; ellers "bruk HIG/Material direkte" via domain-pack-default.
 4. **Hard lengde-grense per fase-artefakt** (≤500 ord / én skjerm der mulig). Lengde er det sterkeste seremoni-signalet.
@@ -55,7 +56,9 @@ Hver fase produserer én eller flere **briefer** — strukturerte markdown-dokum
 
 Konsistensen gir én HTML-renderer, lik review-UX, og enkel kryss-referansing. Fase-spesifikk struktur lever inni hver brief, ikke som forskjellige format på tvers.
 
-**Hver brief har en obligatorisk review-gate før neste fase starter** (se § Cross-cutting: Review-gate mellom faser). Brief-en er AI-skrevet; godkjenning gjøres via sidecar-fil `<artefakt>.review.md` med annoteringer per anker. `phase_status` skiller mellom `pending-review` (AI-skrevet, venter på operatør) og `complete` (operatør-godkjent). Neste fase blokkert til `complete`.
+**Hver brief har en obligatorisk review-gate før neste fase starter** (se § Cross-cutting: Review-gate mellom faser). Brief-en er AI-skrevet; godkjenning gjøres ved at operatøren annoterer artefaktens `annotate.mjs`-genererte HTML og leverer annotasjonene tilbake via «Copy Prompt». `phase_status` skiller mellom `pending-review` (AI-skrevet, venter på operatør) og `complete` (operatør-godkjent). Neste fase blokkert til `complete`.
+
+> **Sidecar-fila finnes ikke** *(korrigert 2026-08-10 — A1/R-05, M8)*. Normativ tekst i dette dokumentet omtalte en sidecar `<artefakt>.review.md` som bærer av annotasjonene. `annotate.mjs` skriver **kun** `<input>.html`; annotasjonene lever i nettleserens **localStorage** (nøklet på absolutt filsti), og et `find` over Akashic-instansen finner null `.review.md`-filer. `sidecar`/`ref`-feltene i `state.json`-eksemplene under er derfor **planlagte, ikke realiserte** — behandle dem som en peker til artefakten som skal annoteres, ikke som en fil som eksisterer. Konsekvensen er reell: annotasjonene overlever ikke maskinbytte eller nettleser-rydding. Å gjøre annotasjons-**eksport til fil** til del av gate-protokollen er masterplan **D7** (betinget utvidelse C), operatør-beslutning — ikke besluttet her.
 
 ## Hard lengde-grense per artefakt (R7)
 
@@ -65,14 +68,14 @@ Hvert fase-dokument har et maksimum: **≤500 ord eller én skjerm** (det som er
 
 En **domain pack** er en gjenbrukbar kunnskaps-bunt (conventions, patterns, gotchas, checklists, guardrails, scaffolding, reference-impl, glossary) som fasene 1/3–7 konsumerer for å realisere en app i et bestemt domene. Den ligger mellom app-spesifikk (fase 3–5) og task-spesifikk (fase 7). app-creator shipper referanse-pakker (`ios-app`, `claude-code-plugin`) i `domain-packs/` i plugin-roten; fork-and-own-brukere lager egne. Full spec: `domain-pack-spec.md`.
 
-**Lasting:** eksplisitt fil-sti per fase — ingen always-on injeksjon, ingen glob-magi. **Max-3-regel:** en fase laster aldri mer enn 3 pack-filer ved oppstart. Hver fase-seksjon under lister hvilke pack-filer den `Read`-er. `state.json` registrerer `domain_pack: "ios-app@0.1.0"`; app-artefaktenes frontmatter skriver samme verdi. Ved init av appen materialiseres et **snapshot** av pakken (versjonen appen bruker) inn i `00-context/`; ethvert pack-felt kan overrides per-app via `00-context/pack-overrides.md`.
+**Lasting:** eksplisitt fil-sti per fase — ingen always-on injeksjon, ingen glob-magi. **Max-3-regel** *(redefinert 2026-08-10, A1 — R-15)*: regelen beskytter kontekstbudsjettet, ikke filtellingen. **`00-context/`-snapshotet teller som ÉN lasting** (det er én fil, uansett hvor mange pack-komponenter det bærer); utover snapshotet laster en fase maks **3 supplementary pack-filer** ved oppstart. Den gamle formuleringen («aldri mer enn 3 pack-filer») var både brutt på papir (fase 5 krever 3 checklists + `gotchas.md`) og omgått i praksis (Akashic leste snapshotet med alle fem core-filene gjennom ett filhandle) — den målte antall filhandles, ikke kontekst. Hver fase-seksjon under lister hvilke pack-filer den `Read`-er. `state.json` registrerer `domain_pack: "ios-app@0.1.0"`; app-artefaktenes frontmatter skriver samme verdi. Ved init av appen materialiseres et **snapshot** av pakken (versjonen appen bruker) inn i `00-context/`; ethvert pack-felt kan overrides per-app via `00-context/pack-overrides.md`.
 
 | Fase | Pack-filer den typisk `Read`-er |
 |------|----------------------------------|
 | 1 (intervju) | `conventions.md` (domene-rammer som farger spørsmålene), `glossary.md` (valgfri, ved behov) |
 | 3 (arkitektur) | `conventions.md`, `patterns/{relevant}.md` (max 1–2), evt. `gotchas.md` |
 | 4 (designsystem) | `conventions.md` (HIG/Material-default), `patterns/{ui-relevant}.md` |
-| 5 (constraints) | `checklist.md` (App Store / MASVS / WCAG / privacy-manifest), `gotchas.md` |
+| 5 (constraints) | `00-context/`-snapshotet (bærer alle `checklist*.md` + `gotchas.md`; App Store / MASVS / WCAG / privacy-manifest). Uten snapshot: checklist-filene + `gotchas.md` — se max-3-regelen over |
 | 6 (feature-derivasjon) | `checklist.md` (for å identifisere test-infra-features), `examples/` (eksempel-backlog, valgfri) |
 | 7 (feature-brief) | `checklist.md` (brief-validerings-items), `examples/` (eksempel-feature-brief), `scaffold/` (når artefakter materialiseres) |
 
@@ -80,13 +83,18 @@ En **domain pack** er en gjenbrukbar kunnskaps-bunt (conventions, patterns, gotc
 
 Å drive en reell app gjennom pipelinen tar mange sesjoner — kontekstvindu-grenser, naturlige pauser, research-avstikkere. Design-research (thread A: BMAD Discussion #74 / Issue #1343 — agent-kontekst degraderer etter 3–4 runder; store mellomdokumenter spiser budsjettet) bekrefter at dette er hard teknisk nødvendighet, ikke pynt.
 
-**Mønsteret (dokumentert praksis, ikke innebygd mekanikk i v0.x):**
-- Tre filer i app-creator-instansens rot (eller plugin-roten under prototype-fasen): `SESSION-ROADMAP.local.md` (plan + sesjons-tabell), `NEXT-SESSION-PROMPT.local.md` (instruksjon for neste sesjon), `SESSION-LOG.local.md` (fasit — hva hver sesjon faktisk gjorde). Alle `.local.md` (gitignored).
-- Operatør kjører `/clear` mellom sesjoner; hver ny sesjon starter med "Les og følg NEXT-SESSION-PROMPT.local.md nøyaktig".
-- Faser som produserer store mellomdokumenter (arkitektur, design-tokens, full backlog) MÅ kunne kjøres i egen sesjon.
-- Domain-packs lastes selektivt (max-3-regel) for å holde nedstrøms-budsjett ledig.
+**Mønsteret** *(omskrevet 2026-08-10, A1 — R-09; erstatter det opprinnelige `SESSION-ROADMAP`/`NEXT-SESSION-PROMPT`/`SESSION-LOG`-mønsteret)*:
 
-**Lett `state.json`-felt** (ikke full mekanikk): `session.current` (kort tag), `session.next_action` (én linje), `session.log` (liste av korte sesjons-noter). Dette er nok til at app-factory kan vise "hvor i prosessen er appen, hva er neste handling" uten at app-creator implementerer en `trekcontinue`-aktig orkestrator. **Beslutning (S5):** dokumentert praksis + lett state-felt. Innebygd mekanikk (à la harness / Voyages `trekcontinue`/`trekendsession`) vurderes først hvis prototypen viser at den manuelle protokollen ikke holder — ikke før behovet er bevist (YAGNI, thread E).
+- **Én `STATE.md` per app-creator-instans**, i instans-repoets rot. Den bærer current state-of-play og starter ALLTID med en «👉 NESTE — START HER»-blokk øverst: hvor vi er, neste konkrete steg, og pekere til det som må leses. Den **overskrives** ved hver sesjonsslutt (maks ~60 linjer) — historikk går til git, ikke til fila.
+- **`git log` er langtidsloggen.** Ingen egen sesjons-logg-fil.
+- **Sesjonskøen bor ved siden av staten** (i app-creator selv: `docs/masterplan.md`; i en instans: backlogen i `06-features-brief.md` + `state.json`).
+- Operatør kjører `/clear` eller starter ny sesjon; re-entry er STATE.md-ens NESTE-blokk, som injiseres automatisk. Ingen «les og følg X nøyaktig»-prompt skrives.
+- Faser som produserer store mellomdokumenter (arkitektur, design-tokens, full backlog) MÅ kunne kjøres i egen sesjon.
+- Domain-packs lastes selektivt (max-3-regelen over) for å holde nedstrøms-budsjett ledig.
+
+**Hvorfor omskrivingen:** det opprinnelige tre-fils-mønsteret var improvisert i prototype-runet (friksjon #6/S5) og er siden avviklet i praksis — filene finnes ikke på disk, og operatørens globale konvensjon forbyr eksplisitt lokale kontinuitets-/handover-mekanismer av den typen. Strekker de globale lagene (`STATE.md` + auto-memory + `CLAUDE.md` + git) ikke til, utvides de **globalt**, aldri lokalt i en app-creator-instans.
+
+**Lett `state.json`-felt** (maskinlesbart speil, ikke egen mekanikk): `session.current` (kort tag), `session.next_action` (én linje), `session.log` (liste av korte sesjons-noter). Dette er det app-factory leser for «hvor i prosessen er appen, hva er neste handling» — `STATE.md` er menneske-flaten, `state.json.session` er maskin-flaten, og de skal si det samme. **Beslutning (S5, opprettholdt):** ingen innebygd orkestrator (à la Voyages `trekcontinue`/`trekendsession`) før behovet er bevist (YAGNI, thread E).
 
 ## Status-merking
 
@@ -109,7 +117,7 @@ Konservativ regel: kun det som faktisk er kjørt får `[testet]`. Per S5 har bar
                                   ▼
                   ┌─────────────────────────────────┐
                   │ 1. Intervju → app brief         │  default: minimal-variant
-                  │   (minimal | full)              │  opt-in: full 6-tema-intervju
+                  │   (minimal | full)              │  opt-in: full 8-tema-intervju
                   └─────────────────────────────────┘
                           │                    │
               rapid mode  │                    │  full pipeline (eskalering)
@@ -201,9 +209,9 @@ Alle interne briefer i app-creator (fase 1–6) har disse felles felter:
 ---
 brief_type: app | research | architecture | design | constraints | features
 phase: 1-6
-phase_status: in-progress | complete | revised | skipped
+phase_status: not-started | in-progress | pending-review | revision-in-progress | revised | complete | skipped
 parent_app: {app-slug}
-domain_pack: "ios-app@0.1.0"        # null hvis ingen pack brukt
+domain_pack: "ios-app@{version}"     # null hvis ingen pack brukt; pin til den versjonen appen faktisk bruker
 created: 2026-05-10
 last_modified: 2026-05-10
 revision: 0                          # bumps ved backtracking
@@ -214,6 +222,30 @@ length_words: {N}                    # ordtelling — review-flagg hvis > 500
 
 Fase 7-feature-briefer (`features/{NN}-{slug}/brief.md`) bruker Voyages frontmatter-skjema, ikke dette — se Fase 7.
 
+### `phase_status` — én autoritativ enum `[justert 2026-08-10 — A1/R-06]`
+
+Vokabularet lå tidligere i tre innbyrdes uforenlige varianter (frontmatter-spec, `state.json`-spec, og en tredje form Akashic bruker i praksis). Dette er **den ene** listen; alle andre steder viser hit.
+
+| Verdi | Betyr | Neste fase blokkert? |
+|---|---|---|
+| `not-started` | Fasen er ikke begynt. | ja |
+| `in-progress` | AI arbeider på artefakten. | ja |
+| `pending-review` | Artefakten er **AI-skrevet, ikke operatør-godkjent**. Review-gaten står åpen. | ja |
+| `revision-in-progress` | Annotasjoner mottatt, AI reviderer. | ja |
+| `revised` | Revidert etter annotasjoner; venter på ny gate-passering. | ja |
+| `complete` | **Operatør-godkjent.** Eneste verdi som slipper neste fase gjennom. | nei |
+| `skipped` | Bevisst hoppet over, med `reason`. | nei |
+
+Kritisk skille (friksjon #15 / Akashic S13): `complete` betyr *operatør-godkjent*, aldri «AI ble ferdig». Det er `pending-review` som betyr sistnevnte. Den gamle frontmatter-enumen manglet `pending-review` helt, så en sesjon som fulgte spec-en bokstavelig kunne bare skrive `complete` når den mente `pending-review` — nøyaktig forvekslingen som utløste operatør-stoppen i S13.
+
+**Objektformer** (i `state.json`, der en skalar ikke er nok):
+- Skippet fase: `{ "status": "skipped", "reason": "..." }`
+- Review-gate åpen: `{ "status": "pending-review", "revision": 0, "sidecar": "<filsti>", "blocking": [<faser>] }`
+
+**Kjent avvik, ikke løst her:** Akashic-instansen bruker i praksis to objektformer ingen spec dekker (`revised` med `revision`/`revised_at`/`driver`/`open_questions`, og `complete` med `completed`/`total`/`completed_at`/`completed_note`), og fase 7 er modellert som en skalar selv om den er en **kontinuerlig aktivitet** (`"7": "complete"` ved 1 av 12 briefer er villedende for en aggregator). Begge er utsatt til **C2** (state-schema med per-feature fase 7-semantikk + normalisering av instansen) — A1 samler bare vokabularet, den redesigner det ikke.
+
+**Attention-typene** har samme sprik: spec-en nevnte `review-pending`/`decision`/`review`, mens virkeligheten bruker `decision-pending`, `action-pending`, `environment-blocker`, `revision-pending`, og `phase`-feltet er udefinert fritekst. Lukket enum + `phase`-domene defineres i **C2**.
+
 ## Pre-pipeline: init `[justert 2026-05-11 — R12 / friksjon #1: identitet only]`
 
 **Formål:** Opprette en app-creator-instans og registrere den i state.
@@ -255,7 +287,7 @@ status: active
 
 **To varianter:**
 - **Minimal-variant (default).** En kort fritekst-runde: operatør skriver/dikterer problem & motivasjon + målgruppe + minst ett suksess-kriterium + ikke-tom utenfor-liste + plattform; AI strukturerer det til en `01-app-brief.md` i minimal form. Ingen weakest-section-loop, ingen 6 kvalitets-sjekk-spørsmål, ingen transkript-fil. Dette er nok for rapid mode og for små apper. (Thread E: å intervjue seg selv er rituell nedskriving — den lette varianten respekterer det.)
-- **Full-variant (opt-in).** Det strukturerte 6-tema-intervjuet med trekbrief-disiplinene under. Velges når operatøren genuint er usikker på app-intent og trenger AI til å presse fram presisjon. Produserer `01-interview-transcript.md` i tillegg til `01-app-brief.md`.
+- **Full-variant (opt-in).** Det strukturerte 8-tema-intervjuet (sjekkliste-temaene under) med trekbrief-disiplinene. Velges når operatøren genuint er usikker på app-intent og trenger AI til å presse fram presisjon. Produserer `01-interview-transcript.md` i tillegg til `01-app-brief.md`.
 
 **Input (begge varianter):**
 - `app.md` (fra pre-pipeline).
@@ -312,7 +344,7 @@ Scope hint: ekstern docs       # lokal kode-research | ekstern docs | begge
 
 Disse bæres til fase 2-research-plan. Hvis operatør sier "jeg vet svaret", strykes temaet — svaret skrives kort i transkript som referanse.
 
-**4. `[ANTAKELSE]`-markører.** Når operatør sier "ikke vet" om noe materielt, skriv det eksplisitt: `[ANTAKELSE] iOS 18 er minimum — ikke verifisert mot målgruppens enhets-park.` Forskjellen fra et research-tema: en antakelse er en bevisst pause vi bærer risiko-en for; et research-tema er et åpent svar vi planlegger å hente. Antakelser legges i app-brief sin "Åpne spørsmål"-seksjon med `[ANTAKELSE]`-prefiks, bæres til fase 3 hvor de aktivt resolveres eller eksplisitt aksepteres.
+**4. `[ANTAKELSE]`-markører.** Når operatør sier "ikke vet" om noe materielt, skriv det eksplisitt: `[ANTAKELSE] {plattform-min-versjon} er minimum — ikke verifisert mot målgruppens enhets-park.` Forskjellen fra et research-tema: en antakelse er en bevisst pause vi bærer risiko-en for; et research-tema er et åpent svar vi planlegger å hente. Antakelser legges i app-brief sin "Åpne spørsmål"-seksjon med `[ANTAKELSE]`-prefiks, bæres til fase 3 hvor de aktivt resolveres eller eksplisitt aksepteres.
 
 **5. Kvalitets-sjekk — splittet i to (R12 / friksjon #2).** Ikke en agent, ikke scoring. Det opprinnelige spørsmål #1 ("Er problem & motivasjon skrevet i 1–2 avsnitt operatør står bak?") forutsatte artefakten den skulle validere — kylling-og-egg. Løsning: splitt.
 
@@ -383,7 +415,7 @@ length_words: {N}
 
 ## Plattform
 - **Mål:** {iOS-only / universal / watch+phone / etc.}
-- **Min-versjon:** {iOS 18 / iOS 19}
+- **Min-versjon:** {min-versjon — verifiser mot domain-pack `conventions.md`, ikke mot hukommelse}
 - **Andre plattform-detaljer:** {widgets / extensions / shortcuts / Live Activities / etc.}
 
 ## Tidshorisont
@@ -420,7 +452,7 @@ length_words: {N}
 **Input:**
 - `01-app-brief.md`.
 - Liste over åpne research-temaer (fra app-brief).
-- Domain-pack: `gotchas.md` (kjente fallgruver i domenet), evt. `patterns/{relevant}.md`.
+- **Ingen domain-pack-input.** *(Justert 2026-08-10 — A1/R-14: pack-input for fase 2 er strøket.)* Fase 2 står ikke i noen pack-manifests `phases`-liste (`ios-app/pack.json` lister `[1,3,4,5,6,7]`), står ikke i pack-tabellen over, og er utelatt i `domain-pack-spec.md`. Akashic-kjøringens fase 2 klarte seg uten pack-filer. Den gamle linjen (`gotchas.md` + `patterns/`) var derfor en selvmotsigelse en implementasjon ville måttet velge side i — og hadde den valgt linjen, ville den brutt pack-manifestets kontrakt. Trenger et research-tema domene-kunnskap, kommer den via `01-app-brief.md` (skrevet med pack-input i fase 1) eller via `00-context/`-snapshotet.
 
 **Workflow `[hypotese]`:**
 1. AI foreslår research-plan basert på åpne temaer.
@@ -521,7 +553,7 @@ length_words: {N}
 
 ## Stack-sammendrag
 - **Språk/runtime:** {f.eks. Swift 6 + SwiftUI}
-- **Plattform-target:** {iOS 18+ / iOS 19+}
+- **Plattform-target:** {deployment-target — verifiser mot domain-pack `conventions.md`}
 - **State-management:** {f.eks. Observation framework + SwiftData}
 - **Persistens:** {f.eks. SwiftData, ingen backend}
 - **Nettverk:** {f.eks. URLSession + actor isolation — eller "ingen"}
@@ -593,7 +625,7 @@ length_words: {N}
 **Input:**
 - `01-app-brief.md` (suksess-kriterier, constraint-signaler, release-modell).
 - `03-architecture-brief.md` (plattform-target gir baseline).
-- Domain-pack: `checklist.md` (standardenes innhold lever her — referanse, ikke kopi), `gotchas.md`.
+- Domain-pack: `00-context/`-snapshotet (én lasting — bærer alle core-filene, inkl. samtlige `checklist*.md` og `gotchas.md`; standardenes innhold lever der — referanse, ikke kopi). Uten snapshot: checklist-filene (`ios-app` har dem splittet i tre) + `gotchas.md` lastes direkte — det er >3 filer og derfor **kun** gyldig via snapshotet eller ved å laste dem i to omganger. *(Justert 2026-08-10 — A1/R-15: den gamle linjen sprengte max-3-regelen på papir mens praksis leste snapshotet.)*
 
 **Workflow `[hypotese]`:**
 1. AI går gjennom domain-pack `checklist.md` og lister hvilke punkter som gjelder denne appen.
@@ -622,7 +654,7 @@ length_words: {N}
 ## Kvalitet (mot ISO/IEC 25010:2023 — 9 karakteristikker)
 *Per relevant karakteristikk: hva gjelder. Særlig de nye i 2023-revisjonen: Safety, Flexibility/Scalability.*
 - **Performance efficiency:** **[enforce]** App launch < 1.5s på iPhone 13. **[aspire]** 60fps på alle interaksjoner.
-- **Compatibility / Portability:** **[enforce]** iOS 18 baseline; iOS 19-API-er degraderer ikke iOS 18-funksjonalitet.
+- **Compatibility / Portability:** **[enforce]** {baseline-versjon} som baseline; API-er fra nyere versjoner degraderer ikke baseline-funksjonalitet. (Konkrete versjonstall hentes fra domain-pack `conventions.md` — templaten skal ikke bære dem, jf. friksjon #9.)
 - **Reliability:** **[aspire]** Crash-free-rate > 99.5%.
 - **Security:** se egen seksjon (MASVS).
 - **Maintainability / Flexibility:** {hvis relevant}
@@ -772,12 +804,16 @@ Før den første feature-briefen overleveres til Voyage: en lett koherens-sjekk
 **Workflow `[hypotese]`:**
 1. Operatør velger neste feature å briefe (typisk topp av prioritet, ingen aktive avhengigheter).
 2. AI genererer `brief.md` (Voyage strict-mode-kompatibel) + `context.md` (embedder upstream) i `features/{NN}-{slug}/`.
-3. Operatør reviewer, approver eller annoterer (annoteringer kan bruke Voyages anchor-format — se under).
+3. Operatør reviewer, approver eller annoterer (samme review-gate som for interne briefer — se under).
 4. Approvert: filene er klare for Voyage-handover.
 5. Operatør kjører Voyage manuelt: `/trekplan --brief features/{NN}-{slug}/brief.md` (eller `--project features/{NN}-{slug}/voyage/` hvis operatøren vil ha Voyages artefakter der).
 6. AI/operatør oppdaterer F-XXX-status til `voyage-running` i features-brief; `voyage_run_dir` fylles i `brief.md`-frontmatter.
 
-### `brief.md` — Voyage Handover-1-kontrakt (verifisert mot Voyage-kildekode 2026-05-11)
+### `brief.md` — Voyage Handover-1-kontrakt `[STALE — pinnet til brief_version 2.0; omskrives i A5, testes i B1]`
+
+> **Verifikasjons-status (oppdatert 2026-08-10, A1):** blokken under ble verifisert mot Voyage-kildekode **2026-05-11** og er **ikke re-verifisert siden**. Gjeldende Handover 1 er **brief_version 2.2** (v5.1 innførte 2.1 med sequencing-gate; v5.5 innførte 2.2 med `framing` + `## TL;DR`). 2.0 er fortsatt *gyldig* under kontraktens N-1-vindu — en papir-gjennomgang av F-001 rev 6 mot 5.9.1-validatoren passerte, også i strict — men templaten sitter i kontraktens eget dokumenterte forsvars-hull, og kontrakten adresserer «a Tier-2 per-app producer» direkte med kravet om å emittere 2.2.
+>
+> **Ingen reell round-trip har noensinne kjørt** (`voyage_running: 0`). «Round-trip-test PASS» i friksjon #14 og i Akashic-loggen er en **mental simulering**, ikke en kjøring — behandle den som papir. Omskriving til 2.2 med `framing`-avledning, TL;DR-generering og `phase_signals`-strategi er masterplan **A5**; første reelle kjøring er **B1**. Ikke bygg videre på blokken under før A5 er kjørt.
 
 **Frontmatter** — alle 8 Voyage-påkrevde felter + state-machine-constraint + app-creator-interne felter:
 
@@ -802,7 +838,7 @@ brief_type: feature
 phase: 7
 parent_app: {app-slug}
 parent_feature: F-001
-domain_pack: "ios-app@0.1.0"
+domain_pack: "ios-app@{version}"     # pin til den versjonen appen faktisk bruker
 revision: 0
 voyage_run_dir: null                 # fylles når Voyage kjøres — peker til Voyages {project_dir}
 voyage_run_status: null              # fylles av app-creator state-eksport fra Voyages progress.json/review.md
@@ -862,7 +898,7 @@ voyage_run_status: null              # fylles av app-creator state-eksport fra V
 ```
 ```
 
-**Round-trip-test (krav før formatet låses):** skriv en faktisk Akashic-feature-brief → kjør `/trekplan --brief features/{NN}-{slug}/brief.md` → bekreft at Voyages brief-validator passerer den i **strict mode uten endring**. Gjøres når Akashic når fase 7; formatet over låses ikke før da. **Re-verifiser Voyage-kontrakten fra kildekode** (`~/.claude/plugins/marketplaces/ktg-plugin-marketplace/plugins/voyage/docs/HANDOVER-CONTRACTS.md`, `templates/trekbrief-template.md`) rett før omskrivingen — Voyage er en levende plugin.
+**Round-trip-test (krav før formatet låses):** skriv en faktisk Akashic-feature-brief → kjør `/trekplan --brief features/{NN}-{slug}/brief.md` → bekreft at Voyages brief-validator passerer den i **strict mode uten endring**. Gjøres når Akashic når fase 7; formatet over låses ikke før da. **Re-verifiser Voyage-kontrakten fra kildekode** rett før omskrivingen — Voyage er en levende plugin. Kanonisk sti (samme cache-regel som for `annotate.mjs`, A1/R-05): `~/.claude/plugins/cache/ktg-plugin-marketplace/voyage/<nyeste-versjon>/docs/HANDOVER-CONTRACTS.md` og `templates/trekbrief-template.md`. Slå opp nyeste versjon med `ls` — hardkod ikke versjonsnummeret, og bruk ikke den gamle `plugins/marketplaces/…`-stien (den finnes ikke).
 
 ### `context.md` — embedder upstream (BMAD-prinsippet: embedding slår linking)
 
@@ -879,7 +915,9 @@ To-fil-splittet speiler BMAD: `brief.md` er det Voyage MÅ honorere (kontrakten)
 
 ### Annotering før handover (R-restpunkt 2 — lett variant)
 
-Hvis operatøren reviewer en `brief.md` og vil annotere før handover: bruk Voyages anchor-format (Handover 8) på fase 7-briefer som faktisk skal annoteres — `<!-- voyage:anchor id="ANN-0001" target="brief.md#intent" line="N" -->`, `ANN-NNNN`-IDer, `annotation_digest` = 16-hex SHA-256 over sortert `source_annotations`. For app-creators *interne* briefer (fase 1–6) trengs ikke Voyages presise mekanikk — en lett "operatør reviewer og kommenterer i brief-en, AI reviderer, revision bumps"-variant holder (jf. "brief-revisjon ved backtracking" under). **Beslutning (S5):** lett intern variant; Voyages eksakte anchor-format kun på fase 7-briefer.
+Hvis operatøren reviewer en `brief.md` og vil annotere før handover: bruk **samme review-gate som for interne briefer** — `annotate.mjs` mot artefakten, annoter i HTML-en, Copy Prompt, AI applisere, `revision` bumps (se § Cross-cutting: Review-gate mellom faser).
+
+*(Justert 2026-08-10 — A1/R-01.)* Den tidligere teksten foreskrev **Voyages anchor-format (Handover 8)** for fase 7-briefer spesifikt: `<!-- voyage:anchor id="ANN-0001" … -->`-kommentarer, `ANN-NNNN`-IDer og `annotation_digest` (16-hex SHA-256 over sortert `source_annotations`). **Handover 8, `/trekrevise` og anchor-/revisjonsbibliotekene ble slettet i Voyage v5.0.0** (2026-05-12). Ingen Voyage-versjon konsumerer lenger de kommentarene eller den digesten — å produsere dem er ren støy i en fil som overleveres. S5-beslutningen om «to nivåer» (lett internt, Voyage-presist på fase 7) faller derfor bort: det er **én** gate-mekanikk, den lette, for alle briefer.
 
 **Transisjon:** Brief overleveres til Voyage. app-creators fase 7 er ferdig for den featuren. Voyage tar over. Når Voyage returnerer (plan/review), oppdateres feature-status i features-brief; `voyage_run.md` i feature-mappa skrives av state-eksport. Hvis review avslører behov for arkitektur-/constraint-endringer → backtrack til fase 3 eller 5 (revision-bump).
 
@@ -931,11 +969,11 @@ Hvis operatøren reviewer en `brief.md` og vil annotere før handover: bruk Voya
 }
 ```
 
-`phase_status`-verdier er enten en string (`complete | in-progress | not-started | revised | pending-review | revision-in-progress`) eller et objekt med utvidet form. Skippede faser: `{ "status": "skipped", "reason": "..." }`. Review-gate-pending: `{ "status": "pending-review", "revision": 0, "sidecar": "<filsti>", "blocking": [<faser]> }` (se § Cross-cutting: Review-gate mellom faser). `domain_pack` er `null` hvis ingen pack brukes. `session` er det lette flersesjons-feltet (ikke en innebygd orkestrator). Dette er filen app-factory leser for portefølje-aggregering.
+`phase_status`-verdier er enten en string eller et objekt med utvidet form — **enum og objektformer står i § `phase_status` — én autoritativ enum**, som er eneste kilde. Gjenta dem ikke her. `domain_pack` er `null` hvis ingen pack brukes. `session` er det lette flersesjons-feltet (ikke en innebygd orkestrator). Dette er filen app-factory leser for portefølje-aggregering.
 
 ## Cross-cutting: Review-gate mellom faser `[justert 2026-05-14 — friksjon #15; Voyage annotate.mjs adoptert 1:1]`
 
-Etter at en fase produserer sin brief (eller fase 7 sine feature-artefakter) er artefakten **AI-skrevet, ikke operatør-godkjent**. Neste fase kan ikke starte før operatør har gått gjennom artefakten og signert av. Mønsteret er **gjenbrukt 1:1 fra Voyage** (`scripts/annotate.mjs` + `/trekrevise`-flyten, Handover 8).
+Etter at en fase produserer sin brief (eller fase 7 sine feature-artefakter) er artefakten **AI-skrevet, ikke operatør-godkjent**. Neste fase kan ikke starte før operatør har gått gjennom artefakten og signert av. Mønsteret er **gjenbrukt fra Voyage** (`scripts/annotate.mjs` — per-artefakt annoterings-HTML). *(Justert 2026-08-10 — A1/R-01: den tidligere formuleringen viste til `/trekrevise` og Handover 8. Begge ble **slettet i Voyage v5.0.0** (2026-05-12) sammen med `playground/`; `annotate.mjs` er erstatningen og det eneste som finnes. Merk at annotate.mjs er en Voyage-**intern** fil utenfor Handover 1 — se sti-regelen under, og vendoring-beslutningen i masterplan D7.)*
 
 ### Hvorfor
 
@@ -947,8 +985,9 @@ App-creator adopterer Voyage `scripts/annotate.mjs` direkte uten egen implemente
 
 1. **AI-side:** etter at fase n-brief er skrevet, kjør Voyage-scriptet mot artefakten:
    ```
-   node ~/.claude/plugins/marketplaces/ktg-plugin-marketplace/plugins/voyage/scripts/annotate.mjs <brief.md>
+   node ~/.claude/plugins/cache/ktg-plugin-marketplace/voyage/<nyeste-versjon>/scripts/annotate.mjs <brief.md>
    ```
+   **Sti-regel** *(A1/R-05, 2026-08-10)*: installerte plugins ligger under `~/.claude/plugins/**cache**/<marketplace>/<plugin>/<versjon>/`. Den tidligere dokumenterte stien (`…/plugins/marketplaces/ktg-plugin-marketplace/plugins/voyage/…`) **finnes ikke** — den ga `ENOENT`. Slå opp nyeste versjon før bruk (`ls ~/.claude/plugins/cache/ktg-plugin-marketplace/voyage/`) i stedet for å hardkode et versjonsnummer; katalogen inneholder flere versjoner samtidig. Dette er en Voyage-intern fil uten kontraktsvern — Voyage har slettet interne flater med én dags varsel før. Strukturell fiks (vendore en kopi inn i app-creator) er masterplan **D7**, operatør-beslutning.
    Det produserer `<brief>.html` ved siden av kilde-fila (single-file, zero deps, lokal). HTML-en rendrer markdown som en ordentlig artikkel (overskrifter, lister, kodeblokker — ikke rå-tekst), med `data-anchor-id` på hvert annotérbart element.
 
 2. **Operatør-side:** operatør åpner HTML-en i nettleser (`file://`-lenke), velger tekst eller klikker et element, velger intent (Fiks / Endre / Spørsmål), skriver kommentar, lagrer. Annotasjoner persisterer i nettleserens localStorage (keyed på absolutt fil-sti).
@@ -976,7 +1015,7 @@ Vokabularet er **tre-tier** (lavnivå-Fiks → mellomnivå-Endre → høynivå-S
 5. Bla til F-002. Velg `.timeSensitive`-setningen i Goal-paragrafen. Velg **Endre**. Skriv: "Trim til `.active` for v1. `.timeSensitive`-entitlement-søknad er overkill — flytt til v1.1+-kandidat."
 6. Bla til F-001. Klikk Goal-paragrafen. Velg **Spørsmål**. Skriv: "Skal AQ-001-research-arbeidet skje i app-creator's `research.md` eller flyttes til Voyage `/trekresearch`?"
 7. Klikk **Copy Prompt** i topbar. Strukturert markdown kopieres til clipboard.
-8. `/clear` i Claude, start neste sesjon med "Les og følg NEXT-SESSION-PROMPT.local.md nøyaktig". Lim inn prompten når Claude ber.
+8. `/clear` i Claude (eller start ny sesjon). Re-entry er instansens `STATE.md` § «👉 NESTE — START HER», som injiseres automatisk — ingen prompt-fil å peke på. Lim inn den kopierte annoterings-prompten når sesjonen er i gang.
 
 ### Applisering — AI-side
 
@@ -1060,7 +1099,7 @@ Når en senere fase avdekker behov for endring i en tidligere brief:
 4. Oppdater referanser i nedstrøms briefer hvis kontrakter har endret seg.
 5. Hvis features-brief har features avhengig av forrige form: marker dem `revision-pending` til de er reviderte. For allerede-skrevne fase 7-`brief.md`/`context.md`: bump deres `revision`, sett `voyage_run_status` til `stale` hvis Voyage allerede kjører på den.
 
-Den eksakte backtracking-propagerings-mekanikken (hvordan en fase 3-endring forplanter seg til allerede-skrevne feature-briefer) er fortsatt `[åpent]` — Akashic vil avsløre den når en backtrack faktisk skjer. Mønsteret er inspirert av Voyages annoterings-revisjons-mekanisme (Handover 8), ikke en kopi.
+Den eksakte backtracking-propagerings-mekanikken (hvordan en fase 3-endring forplanter seg til allerede-skrevne feature-briefer) er fortsatt `[åpent]` — Akashic vil avsløre den når en backtrack faktisk skjer. Mønsteret er inspirert av Voyages annoterings-revisjons-mekanisme (`annotate.mjs`), ikke en kopi.
 
 ## Cross-cutting: attention-generering `[hypotese]`
 

docs/roadmap.md

@@ -1,6 +1,8 @@
 # app-creator — roadmap
 
-> **Erstattet 2026-07-10:** Gjeldende plan til v1.0.0 er `masterplan.md` (promotert fra kryssmodell-reviewen; funn i `review-2026-07.md`). v0.4.0-milepælen under står som milepæl underveis i masterplanen. Dette dokumentet revideres i sesjon A1 — flere punkter bærer verifisert utdaterte premisser (bl.a. «drill-down til Voyage Plugin Playground», jf. R-01).
+> **Erstattet 2026-07-10:** Gjeldende plan til v1.0.0 er `masterplan.md` (promotert fra kryssmodell-reviewen; funn i `review-2026-07.md`). v0.4.0-milepælen under står som milepæl underveis i masterplanen.
+>
+> **Revidert 2026-08-10 (sesjon A1):** drill-down-formuleringene er rettet — «Voyage Plugin Playground» er en historisk flate (slettet i Voyage v5.0.0, 2026-05-12), og drill-down peker nå til feature-ens `voyage_run_dir`-artefakter + annotate-HTML (R-01). Selve HTML-spesifikasjonen skrives i masterplan **E1**. Milepæl-boksene under er fortsatt ukrysset og eies av masterplanens fase C–F.
 
 Gjeldende status og aktiv oppgave: se `../STATE.md` (gitignored). Invarianter og scope-grenser: se `../CLAUDE.md`.
 
@@ -24,7 +26,7 @@ v0.4.0 låser kontraktene som krysser lag-grenser (se `../../app-factory/docs/al
 
 - [ ] 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)
+- [ ] Per-app HTML klar (renderer alle fase-artefakter, fase-progress, attention per app, og drill-down til feature-ens Voyage-run-artefakter (`voyage_run_dir`) og annotate-HTML)
 - [ ] 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
 
@@ -37,7 +39,7 @@ Deliverables som hører til app-creator-implementeringen når forutsetningene er
 - **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.
+- **Per-app HTML** (single-file, polling, vendored DS — gjenbruker mønstrene fra v4.3 Plugin Playground, som er historisk forfar): fase-progress, alle artefakter, attention per app, drill-down til feature-ens Voyage-run-artefakter (`voyage_run_dir`) og annotate-HTML. 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

prototype-run/README.md

@@ -12,11 +12,14 @@ app-creator drives gjennom én reell prototype før implementering starter (jf.
 |-----|-----------|-----|
 | `friksjon.md` | ja | Friksjons-logg — alt som ikke fungerte i app-creator-designet, oppdaget via prototype-runet. Driver revisjon av `../docs/phase-design-draft.md`. |
 | `research/` | ja (fra S2) | Råfunn fra design-research-threadene (A-E), og senere `research-brief.md` (syntesen). |
-| `../SESSION-ROADMAP.local.md` | nei (gitignored) | Sesjons-planen for hele prototype-runet + design-arbeidet. |
-| `../SESSION-LOG.local.md` | nei (gitignored) | Hva hver sesjon faktisk gjorde (fasit vs plan). |
-| `../NEXT-SESSION-PROMPT.local.md` | nei (gitignored) | Prompten for neste sesjon. Operatør kjører `/clear` og starter ny sesjon med "Les og følg NEXT-SESSION-PROMPT.local.md nøyaktig" — fra app-creator-pluginens rot (`.../plugins/app-creator/`). |
 
-`.local.md`-filene ligger i plugin-roten (ikke her) fordi operatør arbeider fra plugin-roten og starter hver sesjon derfra — de må være lett å finne. De er ephemeral working state.
+**Flersesjons-state ligger ikke her.** Prototype-runet brukte opprinnelig tre improviserte filer i repo-roten (`SESSION-ROADMAP.local.md`, `SESSION-LOG.local.md`, `NEXT-SESSION-PROMPT.local.md`). Det mønsteret er **avviklet** (commits 8eb625f, c8e6aa5, b8a6a31; filene finnes ikke på disk) og erstattet av operatørens globale kontinuitets-konvensjon:
+
+- **`../STATE.md`** (gitignored) — current state-of-play med «👉 NESTE — START HER»-blokk øverst; overskrives ved hver sesjonsslutt. Erstatter alle tre.
+- **`git log`** — langtidsloggen. Erstatter SESSION-LOG.
+- **`docs/masterplan.md`** — sesjonskøen. Erstatter SESSION-ROADMAP.
+
+Instans-repoets maskinlesbare speil er `state.json.session` (`current`, `next_action`, `log`). Ingen ny lokal kontinuitets-mekanisme skal innføres — strekker de globale lagene ikke til, utvides de globalt.
 
 ## Når prototype-runet er ferdig