research(app-creator): S4-syntese — triangulert research-brief + revisjons-mandat

Syntetiserer threads A-E til research-brief.md: 8 triangulerte funn med
confidence-rating, stillingstaken på default-retning-spenningen (A/B vs E),
restrisiko, revisjons-mandat R1-R17 for phase-design-draft.md, og
innholds-mandat D1-D7 for domain-pack-spec.md (skrives i S5).

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

prototype-run/research/research-brief.md

@@ -0,0 +1,214 @@
+# Research-brief — app-creator design-revisjon (triangulert syntese av threads A–E)
+
+**Sesjon:** S4 (2026-05-11)
+**Hva dette er:** Syntese av all design-research kjørt i S2–S3 — threads A (prior art), B (app-definisjons-sjekkliste), C (domain-packs), D (per-feature-artefakter + Voyages brief-kontrakt), E (contrarian). Strukturert som en Voyage-research-brief: triangulerte funn med confidence-rating, uenigheter med eksplisitt stillingstaken, restrisiko, og konkret revisjons-mandat for `docs/phase-design-draft.md` + innholds-mandat for `docs/domain-pack-spec.md`. **S4 syntetiserer; S5 utfører.** Ingen ny research er kjørt her.
+**Threads syntetisert:** A, B, C, D, E. Thread F (gemini-bridge, uavhengig andre-mening på pipeline-strukturen) ble forsøkt i S3 men feilet (Gemini Deep Research API HTTP 500, transient, ingen kostnad). Triangulering på pipeline-strukturen baseres derfor på A–E uten et eksternt uavhengig sjekkpunkt. Kan re-submittes som fersk gemini-task hvis operatør ønsker det — spørsmålet er velformet.
+**Dato:** 2026-05-11.
+
+---
+
+## 1. Triangulerte funn (der ≥2 threads konvergerte)
+
+Confidence-skala: **high** = samme konklusjon fra flere uavhengige rammeverk/kilder + konsistent erfaringsbelegg; **medium** = konsistent, men færre datapunkter eller delvis vurdering; **low** = enkelt-kilde eller spekulativ.
+
+### T1 — Triaden requirements → design → tasks er riktig grunnstruktur
+**Threads:** A (M1), bekreftet implisitt av D (Voyage-handover-kjeden brief→plan→review følger samme form).
+**Confidence:** high. Kiro (`requirements.md`/`design.md`/`tasks.md`), BMAD (PRD→architecture→story), MetaGPT (PM→Architect→PM→Engineer), Agent OS (`shape-spec`→`write-spec`→`create-tasks`) konvergerer alle på samme tre-lags skille fra ulike retninger. app-creators fase 1 (app-brief) / fase 3 (arkitektur-brief) / fase 7 (feature-briefer) er denne triaden. **Ingen endring i selve triaden** — den er validert prior art.
+**Konsekvens:** behold tre-lags-skillet. Det er ikke triaden som er problemet (se T7), det er de fem mellomliggende/parallelle artefaktene.
+
+### T2 — Lagdelt context-injeksjon (domain-packs) er det manglende mellomlaget
+**Threads:** A (M8 — agent-os + BMAD konvergerer på standards/product/spec-lag), C (8-komponent-dekomponering av en moden kunnskaps-bunt på tvers av 6 systemfamilier), D (BMAD `dev notes` embedder upstream — domene-laget er en del av det som må embeddes for AI-konsum).
+**Confidence:** high på at det er en reell, gjenkjent kategori; medium på den konkrete `pack.json`-formen (design-forslag, ikke observert praksis — låses i S5).
+**Konsekvens:** domene-laget ("dette er en iOS-app" → konvensjoner/patterns/gotchas/checklists/guardrails/scaffolding/reference-impl/glossary) ligger mellom app-spesifikk (fase 3–5) og task-spesifikk (fase 7) og finnes ikke i utkastet. `domain-pack-spec.md` skrives i S5. Domain-packs er også løsningen på T6 (manglende eierfaser): checklists + guardrails i en `ios-app`-pack bærer App Store-submission-checklist / MASVS / WCAG / privacy-manifest-mal i stedet for at hver app gjenoppfinner dem.
+
+### T3 — Flersesjons-protokoll er hard teknisk nødvendighet, ikke pynt
+**Threads:** A (P3 — BMAD Issue #1343: agent-aktivering spiser 67%+ av 200K; Discussion #74: kontekst degraderer etter 3–4 runder, "first slowly, then all at once"), bekreftet av Akashics egen kjøring (friksjon #6 — å drive pipelinen tok 3+ sesjoner med `/clear` mellom).
+**Confidence:** high.
+**Konsekvens:** den improviserte protokollen (`SESSION-ROADMAP.local.md` + `NEXT-SESSION-PROMPT.local.md` + `SESSION-LOG.local.md`, `/clear` mellom sesjoner) må formaliseres i `phase-design-draft.md`. Faser som produserer store mellomdokumenter (arkitektur, design-tokens, full backlog) MÅ kunne kjøres i egen sesjon. Domain-packs lastes selektivt (max-3-regel à la kiur). **Åpen S5-beslutning:** bygges flersesjons-mekanikken inn i app-creator (à la harness / Voyages `trekcontinue`/`trekendsession`), eller dokumenteres som anbefalt praksis uten å bygges inn? (Anbefaling: dokumenter mønsteret + lett `state.json`-felt for current-session/next-action; ikke full mekanikk før prototypen viser at det trengs — unngå å bygge infrastruktur før behovet er bevist, jf. YAGNI fra thread E.)
+
+### T4 — Embedding slår linking for AI-konsum (BMAD-prinsippet) → `context.md` materialiserer
+**Threads:** A (M5 — context propagation, ikke reconstruction), C (materialisert pack-snapshot i `00-context/` framfor ekstern peker — Copier-mønsteret), D (BMAD story-fil er det eneste formatet designet for AI-konsum, og det embedder upstream-kontekst i `dev notes` i stedet for å linke).
+**Confidence:** high.
+**Konsekvens:** `features/{NN}-{slug}/context.md` skal *materialisere* (ikke bare referere) det relevante utdraget av fase 1–5-output + det relevante domain-pack-utdraget. Tilsvarende: `00-context/`-mappa holder et materialisert snapshot av pack-versjonen appen bruker, ikke en peker til ekstern pakke. Maks-lengde på embeds (D foreslår ~10–15 linjer per upstream-kilde i `context.md` — ikke lim inn hele arkitektur-brief-en).
+
+### T5 — Voyages Handover-1-kontrakt er presist kjent; fase 7 må generere strict-mode
+**Threads:** D (lest direkte fra Voyage-pluginens kildekode — `brief_version: "2.0"`, 8 påkrevde frontmatter-felter, state-machine-constraint, 3 påkrevde body-seksjoner + Research Plan med 7-sub-bullet-temaer, soft vs strict validator).
+**Confidence:** high på kontrakten slik den var ved S3-lesingen — men Voyage er en levende plugin; **re-verifiser rett før fase 7-omskrivingen i S5**, og round-trip-test når Akashic når fase 7 (skriv en Akashic-feature-brief → `/trekplan --brief` → bekreft strict-mode-pass uten endring).
+**Konsekvens:** fase 7-output (`brief.md`) skal genereres for **strict mode**, ikke bare soft. Mapping fra app-creators faser: app-brief Problem→`## Intent`, feature-formål→`## Goal`, feature-suksess-kriterier→`## Success Criteria` (helst Given-When-Then / command-checkable), app-brief utenfor + feature-no-gos→`## Non-Goals`, fase 5-constraints relevant subset→`## Constraints` + `## Non-Functional Requirements`, feature-research-områder→`## Research Plan`-temaer (7 sub-bullets hver). Voyage-run-artefakter blir i Voyages egen `{project_dir}` (`.claude/projects/{date}-{slug}/`) — app-creator linker via `voyage_run_dir` i feature-frontmatter, kopierer ikke inn i `features/{NN}/`.
+
+### T6 — Tre sjekkliste-grupper har ingen eierfase; fase 5 er ad-hoc mot standardene
+**Threads:** B (G9 App Store-submission, G11 test-strategi, G12 release/ops-grense har ingen fase-output; G2-NFRs/G6-a11y/G7-personvern/G8-sikkerhet dekkes som ad-hoc bullets, ikke strukturert mot ISO 25010:2023 / WCAG 2.2 / MASVS 2.1 / privacy manifest), C (checklists + guardrails er nettopp komponentene som bærer dette i en moden kunnskaps-bunt).
+**Confidence:** high.
+**Konsekvens:** den reneste løsningen er at domain-pack-en bærer standard-kunnskapen (`ios-app`-pack inneholder App Store-submission-checklist, MASVS-2.1-checklist, WCAG-2.2-AA-checklist, privacy-manifest-mal, `NSUsageDescription`-inventar-mal) — fase 3/4/5 konsumerer domene-spesifikk standard-kunnskap i stedet for å gjenoppfinne den. Pluss: fase 5-brief-templaten får navngitte underseksjoner som speiler ISO 25010:2023 / WCAG 2.2 / MASVS 2.1 / privacy manifest (referanse, ikke uttømmende inline). **Åpen S5-beslutning:** release/ops-grensen (versjonering, analytics-stack-valg, force-upgrade-policy) — eier en fase det, eller er det eksplisitt operatørens ansvar utenfor app-creator? (Anbefaling: app-brief eier de release-beslutningene som er reelle scope-valg; resten — ASO, TestFlight-loops, marketing — forblir out-of-scope per eksisterende scope-lås; gjør grensen eksplisitt i utkastet.)
+
+### T7 — Pipelinen risikerer å bli for tung / seremoni
+**Threads:** A (P1 spec-bloat — Scott Logic: 4 839 linjer markdown for ~1 000 linjer kode, 10x-overhead-data; P6 over-spesifisering gir falsk trygghet; P7 rigid sekvensiell flyt), E (skjerper A's "for tung" til "feil default-retning" — for solo-dev som bygger liten app for seg selv er koordineringsgevinsten ved 7 sekvensielle artefakter ~null; faser er koordineringsverktøy mellom folk som ikke deler samme hjerne).
+**Confidence:** high på at risikoen er reell og veldokumentert; medium på de spesifikke fase-sårbarhetsrangeringene (vurderinger, ikke målinger — Akashic-kjøringen skal levere de faktiske tids-tallene).
+**Konsekvens:** se § 2 (uenigheter) — dette er den sentrale spenningen S4 må løse.
+
+### T8 — Sekundære konvergenser (kortere, men flere threads peker likt)
+- **Eksplisitte fase-transisjoner = operatør-handling, ikke "AI går videre"** [A-P2: spec-kit #1011 — agenten implementerte uten å stoppe ved fase-grensen]. Fase-grensen må være en bruker-handling (`phase_status`-oppdatering), ikke kun en prompt-instruksjon. Utkastet sier dette delvis ("operatør markerer fasen complete"); styrk det.
+- **Anker-dokumentet er load-bearing** [A-P5: BMAD #2038 — `bmad flow` uten fullført PRD → agenten hallusinerte rammeverket; E erkjenner dette som unntaket fra "alt er seremoni"]. En "rapid mode"-sti kan ikke hoppe over app-brief-en helt — den må produsere en *minimal men gyldig* app-brief inline.
+- **Spec-drift er strukturell** [A-P4, E]. For solo-bruk over uker vil app-brief drifte fra virkeligheten — `revision`/`revision_reason`-disiplinen må faktisk brukes; men E's hardere poeng (antallet artefakter ER drift-overflaten — syv faser = syv divergenspunkter) støtter T7-konklusjonen om å redusere default-antallet.
+- **Escape hatch som first-class** [C — Projen/Copier-lærdom: "stivhet uten fluktvei = tidsbomb"]. Ethvert domain-pack-felt skal kunne overrides per-app via `00-context/pack-overrides.md`.
+- **Appetite/scope-budsjett tidlig** [A-M2: Shape Up; bekreftet av Akashic-friksjon #4 — skala-rekalibrering kom for sent]. Et eksplisitt scope-budsjett tidlig i fase 1.
+- **"Rabbit holes" distinkt fra "utenfor"** [A-M2, D — Shape Up: rabbit holes = ting som ser små ut men kan eksplodere; en annen kategori enn no-gos].
+- **Frontier-modeller implementerer specs selv** [A — agent-os v3 pensjonerte implementerings-orkestrerings-fasen]. Bekrefter app-creators invariant: ikke absorbér Voyage-eksekvering.
+
+---
+
+## 2. Uenigheter / spenninger
+
+### Den sentrale spenningen: hva er default-retningen?
+- **A + B sier:** "Strukturen er riktig — fyll gapene (T6) og gjør lettvekt der mulig (T7)." 7-fase-flyten er solid prior art; risikoen er bloat, ikke feil arkitektur.
+- **E sier:** "Default-retningen er feil — brief-first, ikke full-pipeline-first." For solo-dev + liten app er fem av syv faser spekulativ infrastruktur. Mest sårbare faser rangert: fase 4 designsystem (ren YAGNI-brudd, bør trigge på *bruk* ikke *plan*) > fase 5 constraints (just-in-time-sjekkbar, bæres av domain-pack-checklists) > fase 1 intervju (å intervjue seg selv er rituell nedskriving, ikke discovery).
+
+**Disse er ikke uforenlige.** E erkjenner eksplisitt unntaket: AI-kontekst degraderer over sesjoner (T3), så eksternalisering til filer er *nødvendig for AI-en* — men det gjelder de artefaktene Voyage faktisk konsumerer, ikke nødvendigvis alle syv. A's "behold strukturen" og E's "endre default-retningen" peker mot samme kompromiss.
+
+### Stillingstaken (S4-anbefaling; S5 implementerer, operatør kan overstyre)
+
+**Kompromisset:**
+1. **Minimal-men-gyldig app-brief er obligatorisk anker.** Aldri hoppbar — uten den hallusinerer AI-en nedstrøms (A-P5). Men "minimal" kan bety en kort fritekst-variant, ikke det fulle 6-tema-intervjuet med 6 kvalitets-sjekk-spørsmål.
+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." Bevisst hopp uten å tvinge seremoni.
+3. **Fase 4 (designsystem) trigges på bruk, ikke plan** — aktiveres etter at første Voyage-kjøring har produsert faktiske UI-komponenter; ellers hoppes for små apper og erstattes av "bruk HIG/Material direkte" (domain-pack-default).
+4. **Hard lengde-grense per fase-artefakt** (≤500 ord / én skjerm der mulig — eksakt grense besluttes S5). Lengde er det sterkeste seremoni-signalet.
+5. **En "rapid mode"-sti finnes**: app-konsept → minimal-men-gyldig app-brief inline → fase 7 feature-brief, uten å passere 2–6. Den fulle pipelinen blir eskalering, ikke default.
+6. **Fase 3 (arkitektur) produserer åpne spørsmål som lukkes etterpå**, ikke en decisions-log skrevet før koden finnes (decisions-log før kode = grunnlag for spec-drift, jf. E #4). ADR-formatet beholdes, men ADR-ene skrives/oppdateres *idet beslutningen faktisk tas*, ikke spekulativt opp front.
+
+Dette er nettopp mønsteret NEXT-SESSION-PROMPT (Steg 2) skisserte som "sannsynlig" — S4 bekrefter det som anbefaling. **Restpunkt operatøren bør avgjøre i S5:** hvor aggressiv default-letten skal være (f.eks. om fase 1 sin lette default virkelig skal være "to fritekst-spørsmål" som E foreslår, eller en mellomting). Resten av kompromisset er trygt.
+
+---
+
+## 3. Restrisiko / åpne spørsmål
+
+Punkter ingen thread svarte godt på — bæres til S5 (eller senere):
+
+1. **Eksakt backtracking-propagerings-mekanikk.** Når fase 3 endres, hvordan propagerer det til allerede-skrevne feature-briefer? Utkastet sier "revision-bump + marker revision-pending"; den faktiske mekanikken er åpen. (Akashic vil avsløre det når en backtrack faktisk skjer.)
+2. **Arver app-creator hele Voyages `/trekrevise`-mekanikk, eller en lettere variant?** Anchor-format Handover 8 (`<!-- voyage:anchor id="ANN-0001" ... -->`, `annotation_digest` = 16-hex SHA-256) er presist kjent (D). Spørsmålet er om app-creators interne briefer (fase 1–6) trenger Voyages presise mekanikk, eller om en lettere "operatør reviewer og kommenterer"-variant holder. S5-beslutning. (Anbefaling: lett variant internt; bruk Voyages eksakte anchor-format kun på fase 7-briefer som faktisk skal annoteres før handover.)
+3. **Domain-pack-lagrings-sted.** `domain-packs/` inni app-creator-pluginen vs `~/.claude/domain-packs/` (delt på tvers av apper). Thread C anbefaler i-plugin; alternativet er global. S5-beslutning. (Anbefaling: `domain-packs/` i plugin — pakker committes sammen med app-creator, ingen lock-fil trengs siden forfatteren er eneste konsument; flytt til global eller eget repo senere hvis det blir behov.)
+4. **Flersesjons-mekanikk: innebygd vs dokumentert.** Se T3. S5-beslutning.
+5. **Test-strategi + release/ops-grense: domain-pack-checklists vs dedikert fase.** Se T6. S5-beslutning. (Anbefaling: domain-pack-checklists bærer det meste; gjør release/ops-grensen eksplisitt i scope-lås-seksjonen.)
+6. **Eksakt lengde-grense per artefakt.** ≤500 ord? Én skjerm? Per-fase-differensiert? S5-beslutning.
+7. **Hvordan "rapid mode" sin minimal-men-gyldige app-brief unngår P5.** Hva er minimumssettet en app-brief MÅ ha for at nedstrøms ikke hallusinerer? (Sannsynlig: Problem/motivasjon + målgruppe + minst ett suksess-kriterium + ikke-tom utenfor-liste + plattform — altså en delmengde av dagens 6 kvalitets-sjekk-spørsmål.) Konkretiseres i S5.
+8. **Ingen uavhengig eksternt sjekkpunkt på pipeline-strukturen** (gemini-bridge feilet). Trianguleringen i § 1 hviler på A–E. Lav restrisiko (A–E er internt konsistente og godt kildebelagt), men verdt å notere.
+
+---
+
+## 4. Revisjons-mandat for `docs/phase-design-draft.md` (S5 utfører)
+
+Konkret liste — hvilke seksjoner endres, hva legges til, hva fjernes. (S5 skal gjøre dette; S4 produserer kun mandatet.)
+
+**R1 — Filsystem-layout (§ "Filsystem-layout `[hypotese]`").** Erstatt flat `07-feature-briefs/{NN}-{slug}.md` med:
+- `features/{NN}-{slug}/` som inneholder `brief.md` (Voyage strict-mode-kompatibel) + `context.md` (embedder upstream) — begge obligatoriske — og valgfritt `research.md`, `design-ref.md`, `voyage_run.md` (peker til Voyage-run-dir + run-status).
+- Legg til `00-context/` for materialiserte domain-pack-snapshots (versjonen appen bruker) + `00-context/pack-overrides.md` (escape hatch).
+- `{NN}`-prefiks håndhever dependency-rekkefølgen fra fase 6 (lavere NN avhenger ikke av høyere NN innen samme app).
+- Behold `{app-creator-instance-dir}`-plassering som `[åpent]` (Akashic-instansen ligger i eget repo; det er én gyldig variant).
+
+**R2 — Fase 7-omskriving (§ "Fase 7 — Brief per feature").** Omskriv mot Voyages faktiske Handover-1-kontrakt (D):
+- `brief.md`-frontmatter: alle 8 Voyage-påkrevde felter (`type: trekbrief`, `brief_version: "2.0"`, `created`, `task`, `slug`, `project_dir`, `research_topics`, `research_status`) + state-machine-constraint (`research_topics>0` ∧ `research_status==="skipped"` ⇒ `brief_quality: partial`) + app-creator-interne felter (`brief_type: feature`, `phase: 7`, `parent_app`, `parent_feature`, `revision`, `voyage_run_dir`, `voyage_run_status`) som Voyage ignorerer eller app-creator stripper ved handover.
+- `brief.md`-body: `## Intent`, `## Goal`, `## Non-Goals`, `## Constraints` (relevant subset fra fase 5 — IKKE hele constraints-brief-en), `## Preferences`, `## Non-Functional Requirements`, `## Success Criteria` (helst Given-When-Then / command-checkable), `## Research Plan` (feature-research-områder som temaer med 7 sub-bullets hver: Why this matters / Research question (slutter med ?) / Suggested invocation / Required for plan steps / Confidence needed / Estimated cost / Scope hint), `## Open Questions / Assumptions`, `## How to continue`. **Generer for strict mode, ikke soft.**
+- `context.md`: embedder upstream — (1) dependencies (features dette avhenger av + features som avhenger av dette), (2) cross-cutting constraints (relevant subset fra fase 5), (3) architecture context (relevant utdrag fra fase 3 ADRer, maks ~10–15 linjer), (4) design-system tokens (relevant subset fra fase 4 for denne featurens UI-overflate), (5) domain-pack-utdrag (relevante deler av `00-context/`-snapshot), (6) research signals (2–3 mest relevante punkter fra fase 2 hvis relevant).
+- Round-trip-test-krav: skriv en Akashic-feature-brief → `/trekplan --brief {sti}` → bekreft strict-mode-pass uten endring. Gjøres når Akashic når fase 7; formatet låses ikke i utkastet før da. **Re-verifiser Voyage-kontrakten fra kildekode rett før omskrivingen** (levende plugin).
+- Voyage-run-link, ikke kopi: `voyage_run_dir` peker til Voyages `.claude/projects/{date}-{slug}/`; app-creator leser `progress.json`/`review.md` derfra for status-eksport.
+
+**R3 — Flersesjons-notat (ny § eller utvid "Cross-cutting").** Formaliser den improviserte protokollen: `SESSION-ROADMAP` + `NEXT-SESSION-PROMPT` + `SESSION-LOG`-mønsteret, `/clear` mellom sesjoner, "Les og følg NEXT-SESSION-PROMPT.local.md nøyaktig" som re-entry. Faser som produserer store mellomdokumenter MÅ kunne kjøres i egen sesjon. **Beslutt:** innebygd mekanikk vs dokumentert praksis (anbefaling: dokumenter + lett `state.json`-felt for current-session/next-action; ikke full mekanikk ennå). Adresserer friksjon #6.
+
+**R4 — Domain-pack-konsumering per fase (ny § + endringer i hver fase-seksjon).** For hver fase som konsumerer en pack: list hvilke pack-filer fasen `Read`-er ved oppstart (f.eks. `conventions.md` i fase 1/3/5, `gotchas.md` i fase 5, `checklist.md` i fase 7, `patterns/{spesifikk}.md` etter behov). Max-3-regel (aldri last hele pack-katalogen). `domain_pack: "ios-app@0.1.0"`-felt i `state.json` og i app-artefaktenes frontmatter. Krysshenvis til `domain-pack-spec.md`. Adresserer friksjon #5, #7.
+
+**R5 — "Rapid mode"-sti (ny § + endring i Workflow-oversikt).** Innfør en eksplisitt rask sti: app-konsept → minimal-men-gyldig app-brief inline → fase 7 feature-brief, uten å passere 2–6. Den fulle pipelinen blir eskalering. Beskriv hva "minimal men gyldig" betyr (delmengde av kvalitets-sjekk-spørsmålene — se restrisiko #7). Adresserer friksjon #8.
+
+**R6 — Skippbare-faser-med-begrunnelse (endring i fase 2/4/5 + `state.json`).** Faser 2, 4, 5 markeres skippbare med eksplisitt én-setnings-begrunnelse loggført i `state.json` (`"4": {"status": "skipped", "reason": "early stage, ingen andre brukere"}`). Ikke bare "valgfri". Adresserer friksjon #8.
+
+**R7 — Hard lengde-grense per artefakt (ny § + note i hver fase-template).** Hvert fase-dokument har et maksimum (≤500 ord / én skjerm der mulig — eksakt grense besluttes S5). Adresserer friksjon #8 og A-P1/P6.
+
+**R8 — Fase 4 trigges på bruk (endring i "Fase 4 — Designsystem").** Designsystem-fasen aktiveres etter at første Voyage-kjøring har produsert faktiske UI-komponenter; ellers hoppes for små apper med "bruk HIG/Material direkte" (domain-pack-default). Omskriv formålet fra "tokens som binder alle features" til "kodifiser tokens når feature-settet er stabilt nok til at det lønner seg". Adresserer friksjon #8 og E's fase-4-rangering.
+
+**R9 — Fase 3 produserer spørsmål, ikke spekulative svar (endring i "Fase 3 — Arkitektur").** ADR-formatet beholdes, men ADR-ene skrives/oppdateres idet beslutningen faktisk tas — ikke en full decisions-log opp front. Legg til en "Uavklarte arkitektur-spørsmål"-seksjon som lukkes etter hvert. Adresserer E #4.
+
+**R10 — Manglende eierfaser (endring i scope-lås + fase 5 + krysshenvis til domain-pack).** App Store-submission-artefakter, test-strategi-dokument, release/ops-grense: primær løsning er domain-pack-checklists (`ios-app`-pack bærer App Store-submission-checklist, MASVS 2.1, WCAG 2.2 AA, privacy-manifest-mal, `NSUsageDescription`-inventar-mal). Pluss: gjør release/ops-grensen eksplisitt i scope-lås — hvilke release-beslutninger eier app-brief (reelle scope-valg: paid-app-modell, versjonerings-skjema hvis det er en bevisst beslutning), hvilke er eksplisitt utenfor (ASO, TestFlight-loops, marketing — allerede i scope-lås). Adresserer friksjon #7, B-G9/G11/G12.
+
+**R11 — Fase 5 strukturert mot standarder (endring i "Fase 5 — Constraints").** Constraints-brief-templaten får navngitte underseksjoner som speiler ISO 25010:2023 (9 karakteristikker — særlig de nye: Safety, Flexibility/Scalability), WCAG 2.2 AA (de 4 nye 2.2-kriteriene: target size, focus not obscured, accessible auth, focus appearance), OWASP MASVS 2.1 (8 kontroll-grupper), privacy manifest (required-reason-API-deklarasjon, per-SDK-krav, App Privacy Details "nutrition label"). Standarden som referanse slik at gap er synlige — ikke uttømmende inline. Merk constraints som just-in-time-sjekkbare (bæres av domain-pack-checklists). Adresserer B-G2/G6/G7/G8, E's fase-5-rangering.
+
+**R12 — Fase 1-justeringer (endringer i "Pre-pipeline" + "Fase 1").**
+- Pre-pipeline init = identitets-data only (slug, navn, plattform, dato). "Hvorfor denne appen" + "Pre-fase-notater" droppes fra init; "Hvorfor"-avsnittet genereres retrospektivt etter fase 1 complete som ett-avsnitts-destillering av app-brief-ens Problem & motivasjon. (Friksjon #1, alternativ A.)
+- Splitt kvalitets-sjekken: 5 pre-draft-spørsmål (besvarbare fra transkriptet) + 1 post-draft-spørsmål ("står operatør bak problem & motivasjon-avsnittet slik AI formulerte det?"). Eller omformuler #1 til "har vi nok materiale til å skrive et problem & motivasjon-avsnitt operatør vil stå bak?" (Friksjon #2.)
+- Anchor-formuleringen for Omfang skiller eksplisitt "Hva appen GJØR" (funksjonelle features → fase 1-brief, driver fase 6) fra "Hvordan appen ER" (kvalitative egenskaper → fase 4/5). Gjør AI-foreslått-features-hypotese til standard neste-steg i Omfang-fasen. (Friksjon #3.)
+- Legg til et tidlig eierskaps/intensjon-spørsmål (Tur 1–2): "Hvem er dette egentlig for: deg selv, andre, eller begge? Hvis du må velge én — hvilken vinner når de er i konflikt?" Rammer alle påfølgende svar riktig fra start. (Friksjon #4.)
+- Lett default-variant: "problem-statement + åpne spørsmål" (kort fritekst) som standard; det fulle 6-tema-intervjuet med trekbrief-disiplinene blir opt-in for når operatøren genuint er usikker. (E's fase-1-rangering — men behold trekbrief-disiplinene som *tilgjengelige*.)
+
+**R13 — Appetite + rabbit holes (endringer i fase 1 + fase 7-templates).** Legg til eksplisitt "appetite"/scope-budsjett tidlig i fase 1 (friksjon #4, A-M2). Legg til "rabbit holes"-kategori (distinkt fra "utenfor"/no-gos) i app-brief og feature-brief-templates (A-M2, D — Shape Up).
+
+**R14 — Problem-gate + design-first-valg + readiness-check.**
+- Vurder "er dette riktig problem?"-gate-spørsmål før fase 3 (A-M3, PR/FAQ-stil). Eventuelt Cagans fire-risiko-klassifisering (value/usability/feasibility/viability) som lett checklist i fase 1 eller 3 — hvilken risiko dominerer, og driver det fase 2-research-planen? (For Akashic: feasibility-risiko = opphavsrett, allerede identifisert.)
+- Legg til eksplisitt requirements-first vs design-first-spørsmål før fase 3 (A-M6, Kiro). For Akashic er det requirements-first, men ANTAKELSE #2–5 er arkitektur-constraints som grenser mot design-first.
+- Vurder "implementation readiness check" (PASS/CONCERNS/FAIL) før fase 7-handover til Voyage — sjekker koherens på tvers av fase 1–6-briefene (A-M5, BMAD `bmad-check-implementation-readiness`).
+
+**R15 — Eksplisitte fase-transisjoner (styrk eksisterende formuleringer).** Hver fase-transisjon = operatør-handling (`phase_status`-oppdatering), ikke "AI går videre". Utkastet sier dette delvis; gjør det utvetydig. (A-P2.)
+
+**R16 — Status-merking (gjennomgående).** Oppdater `[hypotese]`→`[testet]`/`[justert YYYY-MM-DD]` der prototypen har gitt belegg: fase 1 er delvis testet via Akashic (intervju-mønstrene fungerte, alle 6 kvalitets-sjekk-spørsmål passerte — men friksjon #1–4 viser hva som må justeres); friksjon #5–8 gir belegg for cross-cutting-revisjonene. Vær konservativ: kun det som faktisk er kjørt får `[testet]`; resten forblir `[hypotese]` eller blir `[justert]` med dato + begrunnelse.
+
+**R17 — Mål fase-overhead-tid i prototypen (note i prototype-protokollen, ikke utkastet selv).** Legg til i `friksjon.md`-protokollen / SESSION-ROADMAP: mål faktisk tid brukt per fase i Akashic-kjøringen. En fase som tar timer og produserer en artefakt ingen Voyage-brief refererer = bevist seremoni. (E #6 — dette er en prototype-protokoll-endring, ikke en `phase-design-draft.md`-endring, men hører i revisjons-mandatet som påminnelse.)
+
+---
+
+## 5. Innholds-mandat for `docs/domain-pack-spec.md` (S5 skriver, domene-nøytral)
+
+Konkret innhold spec-en skal ha:
+
+**D1 — Hva en domain pack er.** En gjenbrukbar kunnskaps-bunt fasene 1/3–7 konsumerer for å realisere en app i et bestemt domene. MER enn en Anthropic-skill: en skill dekker primært patterns + delvis gotchas + reference-impl; en domain pack legger til conventions, checklists, guardrails og scaffolding som førsteklasses navngitte komponenter.
+
+**D2 — 8-komponent-listen (med fil-navn), hver som dedikert fil/katalog under en `domain-pack/`-rot:**
+| Komponent | Fil | Note |
+|---|---|---|
+| Manifest | `pack.json` | se D3 |
+| Conventions | `conventions.md` | domene-spesifikke ikke-forhandlbare beslutninger + guardrails som underseksjon (App Store-constraints, GDPR-håndtering = conventions med enforcement-vekt) |
+| Patterns | `patterns/` | én fil per gjenbrukbart mønster; fasene `Read` spesifikke filer |
+| Gotchas | `gotchas.md` | eksplisitt "ikke gjør dette"-liste |
+| Checklists | `checklist.md` | fase-exit-kriterier som checkbokser; mapper til brief-validering i fase 7 — App Store-submission-checklist, MASVS 2.1, WCAG 2.2 AA, privacy-manifest-mal lever HER |
+| Scaffolding | `scaffold/` | fil-templater som materialiseres inn i per-app-artefakt-treet (f.eks. `PrivacyInfo.xcprivacy`-mal) |
+| Reference impl | `examples/` | eksempel-briefer, eksempel-artefakter — konsumeres av brief-generator i fase 7 |
+| Glossary | `glossary.md` | domene-vokabular; lastes selektivt |
+
+**D3 — `pack.json`-skjema** (minimalt JSON-manifest, ingen npm-semantikk, ingen build-step):
+```json
+{
+  "schema": "domain-pack/v1",
+  "name": "ios-app",
+  "version": "0.1.0",
+  "domain": "iOS-app-utvikling (Swift/SwiftUI)",
+  "description": "Domene-kunnskap for iOS-app-utvikling med Swift/SwiftUI",
+  "phases": [1, 3, 4, 5, 6, 7],
+  "verified": { "date": "2026-05-11", "against": "iOS 18, HIG WWDC2025, MASVS 2.1, WCAG 2.2" }
+}
+```
+`phases` deklarerer hvilke pipeline-faser som kan laste fra pakken. `verified` = sist-verifisert-dato + mot hvilken versjon av domenet.
+
+**D4 — Referanse/aktiverings-mekanisme.** Eksplisitt fil-sti-lasting per fase (hver fase-prompt lister hvilke pack-filer den `Read`-er ved oppstart — progressive disclosure, verbatim fra skill-mønsteret) + materialisert snapshot i app-instansens `00-context/` + `domain_pack: "ios-app@0.1.0"`-felt i `state.json`. Ingen glob-magi, ingen always-on injeksjon. Max-3-regel (aldri last hele pack-katalogen). "core" vs "supplementary"-merking på hver fil. Hard lengde-grense per fil (~500 ord / én skjerm der mulig — fordi lang = usynlig, Cursor-erfaringen). Ingen runtime-framework: en fase-agent leser `state.json`, resolver pack-stien, leser relevant fil.
+
+**D5 — Versjonerings-regel.** `version` følger semver-semantikk uformelt: breaking (fjerne komponent, rename felt) → major; additivt → minor; fixes → patch. Per-app `00-context/pack-overrides.md` som escape hatch — ethvert pack-felt skal kunne overrides per-app (Projen-lærdom: aldri hardkode en pack-verdi uten at app-konteksten kan si "for denne appen, ikke dette"). Skriv pack-versjon inn i app-artefakter (intervju-output, briefer) slik at man alltid vet hvilken pack-versjon som genererte et gitt prosjekt (Copier-mønsteret: templaten "kjenner" sine genererte prosjekter). Behandle en breaking pack-bump som det den er: skriv changelog-notat, bump major. `@`-notasjon (`ios-app@0.1.0`) muliggjør framtidig snapshot-pinning via git-tag hvis pakken ekstraheres til eget repo. Lagrings-sted: `domain-packs/` inni app-creator-pluginen (anbefalt; alternativt `~/.claude/domain-packs/` — operatør-beslutning i S5).
+
+**D6 — Voyage-agnostisk håndtering.** Når en feature-brief overleveres til Voyage, embeddes relevant pack-utdrag i `context.md` (ikke i `brief.md`). Voyage ser kun en velformet brief — aldri "domain-pack-generert"-merking. Pack-identiteten er app-creator-intern state.
+
+**D7 — Hva referanse-pakkene `ios-app` og `claude-code-plugin` skal inneholde** (S6 forfatter dem — bare skisser her):
+- **`ios-app`-pack** (fra Akashics reelle behov): `conventions.md` (HIG-regler, Swift/SwiftUI-konvensjoner, MVVM-vs-TCA-veiledning, "Liquid Glass"-konformans-notat); `patterns/` (offline-first med SwiftData, lokale notifications, widget/Live-Activities-deling av datamodell, current-location-regenerering); `gotchas.md` (required-reason-API-deklarasjon, ATS, `NSUsageDescription` manglende = umiddelbar avvisning, App Store-avvisnings-triggere); `checklist.md` (App Store-submission-checklist, MASVS-2.1-checklist, WCAG-2.2-AA-checklist, privacy-manifest-mal, App Privacy Details "nutrition label"-felter, eksport-compliance, region-krav DSA/ICP/GRAC); `scaffold/` (`PrivacyInfo.xcprivacy`-mal, `NSUsageDescription`-inventar-mal, App Store Connect-metadata-mal); `examples/` (eksempel-feature-brief for en iOS-feature); `glossary.md` (iOS/App Store-vokabular).
+- **`claude-code-plugin`-pack** (ekstraksjon fra eksisterende CLAUDE.md + `.claude/rules/`): `conventions.md` (plugin.json-manifest-regler, frontmatter-regler fra ktg-privat CLAUDE.md, navnekonvensjoner, context-budget-regler); `patterns/` (command-router-mønster, agent-definisjoner, skill progressive disclosure, 3-lags arkitektur à la kiur); `gotchas.md` (hooks er objekt ikke array, matcher er string ikke nestet objekt, ikke deklarer "hooks" i plugin.json, aldri last hele kataloger); `checklist.md` (plugin-validator-pass, CLAUDE.md grade B, hook-format-regler); `scaffold/` (plugin-katalog-skjelett); `examples/` (eksisterende plugin-strukturer i ktg-privat); `glossary.md` (plugin-vokabular).
+
+---
+
+## 6. Kilder
+
+**Threads (denne research-runden):**
+- `prototype-run/research/A-prior-art.md` — prior art: spec-to-feature / app-definisjons-pipelines (Kiro, BMAD, MetaGPT, Agent OS, Shape Up, Amazon PR/FAQ, SVPG, JTBD, Torres, Lenny + erfaringsrapporter: Scott Logic, BMAD-issues, spec-kit, Kiro-reviews, Isoform, Loadsys m.fl.)
+- `prototype-run/research/B-app-definition.md` — komplett app-definisjons-sjekkliste (ISO/IEC/IEEE 29148, ISO 25010:2023, arc42/ISO 42010, MADR v3, W3C DTCG 2025.10, Apple HIG, WCAG 2.2, OWASP MASVS 2.1, Apple App Store Review Guidelines + App Privacy Details + privacy manifest, GDPR)
+- `prototype-run/research/C-domain-packs.md` — domain-pack-dekomponering (Cursor rules, Copilot instructions, Anthropic skills, Yeoman/Cookiecutter/Copier, ESLint/Prettier shareable configs, Azure CAF / AWS WAF + erfaringsrapporter: Cursor-drift, eslint-config-love, Projen)
+- `prototype-run/research/D-feature-artifacts.md` — Voyages faktiske brief-kontrakt (lest fra Voyage-pluginens kildekode) + per-feature-artefakt-anatomi (Shape Up, Linear, Jira, GitHub issue-templates, BMAD story-filer, INVEST/Connextra/Given-When-Then)
+- `prototype-run/research/E-contrarian.md` — contrarian-case mot 7-fase-pipelinen (Royce-papiret, YAGNI, tracer-bullet/walking-skeleton, spec-drift, discovery-/PRD-teater, solo-dev-overhead, Sparkbox "when not to use a design system")
+- Thread F (gemini-bridge) — **ikke tilgjengelig** (S3-kjøring feilet, HTTP 500).
+
+**Kontekst:**
+- `CLAUDE.md` (app-creator) — invarianter, scope-grenser, lag-arkitektur
+- `docs/phase-design-draft.md` — det revisjons-mandatet i § 4 gjelder
+- `/Users/ktg/repos/akashic-intelligence/01-app-brief.md` — Akashic fase 1-resultatet (prototypen som driver alt)
+- `prototype-run/friksjon.md` — friksjons-logg #1–8
+
+**Nøkkel-eksterne kilder** (fulle URL-lister i A–E-filene): Kiro Specs, BMAD Method docs + Discussion #74 / Issues #1343/#1818/#2038, MetaGPT, Agent OS, Shape Up handbook, Scott Logic spec-kit-evaluering (nov 2025), ISO/IEC 25010:2023, arc42, WCAG 2.2 (W3C Rec okt 2023), OWASP MASVS 2.1 (jan 2024), Apple HIG / App Store Review Guidelines / App Privacy Details / privacy manifest, Anthropic Agent Skills docs, Cursor/Copilot/ESLint/Cookiecutter/Copier-docs, recallstack "Yeoman and Cookiecutter are dead", Projen escape-hatches, Voyage-pluginens kildekode (`docs/HANDOVER-CONTRACTS.md`, `commands/trekbrief.md`, `templates/*.md`).