research(app-creator): thread A+B — prior art + app-definisjon-sjekkliste

S2 av Akashic-drevet design-research. A-prior-art.md: 8 mønstre å stjele
+ 9 fallgruver fra Kiro/BMAD/MetaGPT/Agent OS/Shape Up/Amazon PR-FAQ/SVPG/
JTBD/Torres + erfaringsrapporter. B-app-definition.md: 12-gruppers app-
definisjons-sjekkliste mot ISO 29148/25010:2023, arc42, WCAG 2.2, MASVS 2.1,
Apple App Store + privacy manifest, GDPR — + mapping mot 7-fasene som
avslører 3 manglende eierfaser. Logget friksjon #7.

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

prototype-run/friksjon.md

@@ -104,4 +104,20 @@ Eventuelt: aksepter at operatør gir kvaliteter, og gjør AI-foreslått-features
 
 **Foreslått revisjon:** Vurder om app-creator skal ha en innebygd flersesjons-mekanikk (à la harness-pluginen eller Voyages trekcontinue/trekendsession) — eller om dette holdes utenfor og overlates til operatørens valgte verktøy. Hvis innebygd: `state.json` bør spore current-session, next-action, og en lett session-logg. Hvis utenfor: dokumenter mønsteret som anbefalt praksis uten å bygge det inn. (Avhenger delvis av design-research thread A/D — hvordan andre håndterer langvarige multi-step-prosesser.)
 
+**S2-oppdatering (2026-05-11):** Design-research thread A bekrefter dette som hard teknisk nødvendighet, ikke pynt. BMAD Discussion #74 / Issue #1343: agent-kontekst degraderer etter 3-4 runder, og store mellomdokumenter (arkitektur, design-tokens, full backlog) spiser kontekst-budsjett nedstrøms-faser trenger. Anbefaling fra research: faser som produserer store artefakter MÅ kunne kjøres i egen sesjon; domain-packs lastes selektivt (max-3-regel à la kiur). Se `research/A-prior-art.md` § P3.
+
+---
+
+## #7: Tre sjekkliste-grupper har ingen eierfase (G9 App Store-submission, G11 test-strategi, G12 release/ops-grense)
+
+**Fase:** cross-cutting
+**Type:** design-friksjon
+**Observert:** 2026-05-11 (via design-research thread B, ikke via Akashic-kjøring direkte — men Akashic er hvorfor researchen ble gjort)
+
+**Beskrivelse:** `phase-design-draft.md`s 7 faser dekker problem/intent/requirements/arkitektur/designsystem/constraints/features/feature-briefer godt, men en uttømmende app-definisjons-sjekkliste (mot ISO/IEC/IEEE 29148, ISO 25010:2023, arc42, WCAG 2.2, OWASP MASVS 2.1, Apple App Store Review Guidelines + privacy manifest, GDPR) avslører at: (G9) App Store-submission-artefakter — alders-spørreskjema, `NSUsageDescription`-inventar, screenshot-spec, eksport-compliance, region-krav, App Store Connect-metadata — har ingen dedikert fase-output; (G11) test-strategi-dokument (dekningsmål, crash-free-rate, device/OS-matrise) har ingen eier (fase 6 "test-infrastruktur som features" dekker E2E-bygging, ikke strategi-beslutningene); (G12) release/ops-grense (versjonering, analytics-stack-valg, force-upgrade-policy) faller mellom "app-bygget" og det allerede out-of-scope-merkede "post-shipping". I tillegg er fase 5 (constraints) dekkende men ad-hoc — ikke strukturert mot standardene den implisitt refererer (ISO 25010:2023 mangler Safety + Flexibility/Scalability; WCAG 2.2s 4 nye AA-kriterier mangler; privacy manifest required-reason-API-deklarasjon mangler helt).
+
+**For Akashic spesifikt:** flere av app-brief-ens constraint-signaler ER i praksis App Store-submission-artefakter (ikke-affiliering-disclaimer i App Store-beskrivelsen, `NSUsageDescription` + onboarding-forklaring for location/notifications, 7%-donasjons-kommunikasjon, paid-app-modell). De har ingen klar fase-hjemme i dagens utkast.
+
+**Foreslått revisjon (avgjøres S4-syntese / S5):** Tre kandidater, ikke gjensidig utelukkende: (a) dedikert "Fase 5b — Store readiness" ELLER obligatorisk submission-checklist appendert til fase 5; (b) test-strategi-artefakt innenfor fase 6 (backlogen driver test-scope) eller en fase 3b avledet fra arkitektur; (c) eksplisitt avklaring av release/ops-grensen — hvilke pre-build-beslutninger eier en fase, hvilke er eksplisitt operatørens ansvar utenfor app-creator. **Trolig reneste løsning:** la `domain-pack`-konseptet bære standard-kunnskapen — en `ios-app`-domain-pack inneholder MASVS-checklist, privacy-manifest-mal, App Store-submission-checklist, WCAG-2.2-AA-checklist — slik at fase 5 (og fase 3/4) konsumerer domene-spesifikk standard-kunnskap i stedet for å gjenoppfinne den per app. Utforskes i thread C (S3), settes i `domain-pack-spec.md` (S5). Se `research/B-app-definition.md` § "Kritiske gap".
+
 ---

prototype-run/research/A-prior-art.md

@@ -0,0 +1,123 @@
+# Thread A — Prior art: spec-to-feature / app-definisjons-pipelines
+
+**Sesjon:** S2 (2026-05-11)
+**Metode:** Voyage-research — `voyage:docs-researcher` (autoritative kilder) + `voyage:community-researcher` (erfaringsrapporter), begge Sonnet, parallelt. Syntese skrevet i hovedkontekst.
+**Confidence:** High på mønstrene (samme konklusjon fra 8+ uavhengige rammeverk og flere uavhengige erfaringsrapporter). Medium på erfaringstall (få datapunkter, men konsistente).
+
+---
+
+## 1. Mønstrene som er verdt å stjele
+
+### M1 — Den universelle triaden: requirements → design → tasks (tre separate artefakter, ulike publikum)
+
+Hvert rammeverk konvergerer på samme tre-lags struktur:
+
+- **AWS Kiro** (spec mode, [kiro.dev/docs/specs](https://kiro.dev/docs/specs/)): tre navngitte filer — `requirements.md` (user stories i EARS-notasjon: `WHEN [condition] THE SYSTEM SHALL [behavior]`), `design.md` (arkitektur, sekvensdiagrammer, dataflyt), `tasks.md` (diskrete sporbare oppgaver). Handover-kontrakten er retningsbestemt: design valideres mot requirements før tasks genereres; endrer du requirements trigges en "Refine" på design, som propagerer til tasks via "Sync Files". Gaten mellom faser er en bevisst bruker-handling, ikke automatisk. "Quick Plan"-modus hopper over alle gates og kjører alle tre faser i én pass — Kiro advarer eksplisitt at dette er en trade-off ([kiro.dev/docs/specs/feature-specs](https://kiro.dev/docs/specs/feature-specs/)).
+- **BMAD-METHOD** ([docs.bmad-method.org](https://docs.bmad-method.org), [workflow-map](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/reference/workflow-map.md)): fire faser — Analysis (valgfri: `product-brief.md`, `prfaq-{project}.md`) → Planning (`PRD.md` + `ux-spec.md`) → Solutioning (`architecture.md` + ADRs + epic/story-filer; `bmad-check-implementation-readiness` gir eksplisitt PASS/CONCERNS/FAIL — den eneste obligatoriske gaten) → Implementation (én story om gangen, code-review-gate). Eksplisitt kontrakt: "The PRD tells the architect what constraints matter. The architecture tells the dev agent which patterns to follow. Story files give focused, complete context for implementation."
+- **MetaGPT** ([github.com/FoundationAgents/MetaGPT](https://github.com/FoundationAgents/MetaGPT)): sekvensielle agent-roller — Product Manager (PRD + competitive analysis) → Architect (system design, datastrukturer, API-kontrakter) → Project Manager (task-fil per kodefil) → Engineer (kode) → QA (testcases). Prinsipp: "Code = SOP(Team)" — handover er en strukturert melding, ingen agent starter før upstream har produsert sin artefakt.
+- **Agent OS / Builder Methods** ([buildermethods.com/agent-os/workflow](https://buildermethods.com/agent-os/workflow)): seks steg — `plan-product` (mission/roadmap/tech-stack) → `shape-spec` (strukturerte spørsmål → `requirements.md`) → `write-spec` (`requirements.md` → formalisert `spec.md`) → `create-tasks` → `implement-tasks`. **v3-changelog: implementerings-orkestrerings-fasen ble pensjonert** fordi frontier-modeller "now handle spec implementation well on their own" — sterkt signal om hvor AI-assistanse gir mest verdi (i shaping/spec, ikke i å holde i hånda under implementering).
+
+**Stjel:** Hold "hva skal bygges" (app-brief / requirements) adskilt fra "hvordan" (arkitektur-brief) adskilt fra "hva er neste steg" (feature-briefer). app-creator gjør dette allerede (fase 1 / fase 3 / fase 7) — det er den riktige strukturen, bekreftet.
+
+### M2 — Appetite før scope (Shape Up)
+
+Shape Up ([basecamp.com/shapeup](https://basecamp.com/shapeup/shape-up.pdf)) inverterer planleggings-rekkefølgen: definer timeboxen ("appetite") FØR løsningen. "An estimate starts with design and asks how long. Appetite starts with a time budget and asks what fits." Shaping-sekvensen: Set Boundaries (appetite + problem) → Find the Elements (breadboarding + fat-marker sketches — bevisst grove for å hindre over-spesifisering) → De-risk (rabbit holes + no-gos) → Write the Pitch (Problem / Appetite / Solution / Rabbit Holes / No-Gos). **Betting Table** er beslutnings-gaten: vurder pitches, satse eller forkast. Ingen backlog — uvalgte pitches bæres ikke videre automatisk, de må re-pitches.
+
+**Stjel:** (a) Et eksplisitt "appetite"/scope-budsjett tidlig — Akashic-friksjon #4 (skala-rekalibrering kom sent) er nettopp dette. (b) "Rabbit holes" (kjente scope-feller) og "no-gos" (eksplisitt ekskludert) som navngitte seksjoner i hver brief — app-creator har allerede "Utenfor (eksplisitt)", men "rabbit holes" (ting som ser små ut men kan eksplodere) er en distinkt og verdifull kategori. (c) Vurder Shape Ups "no backlog"-disiplin for fase 6 — passiv akkumulering av features er en kjent felle.
+
+### M3 — Problemramming som distinkt, gateable artefakt FØR løsningsdesign
+
+- **Amazon PR/FAQ** ([workingbackwards.com](https://workingbackwards.com/concepts/working-backwards-pr-faq-process/)): fiktiv pressemelding (kunde-språk, <1 side) + intern FAQ (brutal feasibility-stress-test, ≤5 sider). Gate: 15-20 min stille lesing + 40 min debatt → binær Go/No-Go. AWS Prescriptive Guidance ([docs.aws.amazon.com/.../start-with-why](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-product-development/start-with-why.html)): Vision → Personas + Journey Maps → PR/FAQ → Epics/Stories → Roadmap.
+- **Cagan/SVPG** ("Inspired"/"Empowered", [svpg.com/four-big-risks](https://www.svpg.com/four-big-risks/)): klassifiser EKSPLISITT hvilken av fire risikoer dominerer FØR du velger discovery-teknikk — Value (vil de velge det?), Usability (kan de bruke det?), Feasibility (kan vi bygge det?), Business Viability (funker det forretningsmessig?). Opportunity Assessment = ett-sides dokument, 10 spørsmål, før noen prototype. Dual-Track: discovery parallelt med delivery; output av discovery er en validert prototype som blir de-facto spec.
+- **JTBD / Outcome-Driven Innovation** (Ulwick/Strategyn, [strategyn.com/jobs-to-be-done](https://strategyn.com/jobs-to-be-done/)): løsnings-nøytralt job-statement ("cut a piece of wood in a straight line", ikke "use a circular saw") → 8-stegs Universal Job Map → 50-150 desired outcomes per steg → kvantitativ scoring (importance × satisfaction) → underserved outcomes blir design-mandatet.
+- **Teresa Torres, Continuous Discovery Habits** (2021, [amazon.com/dp/1736633309](https://www.amazon.com/dp/1736633309)): Opportunity Solution Tree — Desired Outcome → Opportunity Space → Candidate Solutions → Riskiest Assumptions → Experiments. Levende artefakt, ikke fase-sekvens. Kontrakt: ingen løsning designes før den er mappet til en konkret opportunity; hver løsnings-antakelse testes før commitment.
+- **Lenny Rachitsky 1-pager** ([atlassian.com/.../lennys-product-requirements](https://www.atlassian.com/software/confluence/templates/lennys-product-requirements)): Problem → Why it's real → Success → Audience → What it looks like — med Kevin Yiens **"Non-Goals"-seksjon** eksplisitt fremhevet som standout-praksis.
+
+**Stjel:** app-creators fase 1 ER problemramming-artefakten — men vurder (a) et eksplisitt "er dette riktig problem?"-gate-spørsmål (PR/FAQ-stil) før man går videre til fase 3, og (b) Cagans fire-risiko-klassifisering som en lett checklist i fase 1 eller 3 (hvilken risiko dominerer denne appen — value/usability/feasibility/viability — og driver det fase 2-research-planen?). For Akashic: feasibility-risiko (opphavsrett) er allerede identifisert som RESEARCH-TEMA #1 — fire-risiko-rammeverket ville gjort den klassifiseringen eksplisitt.
+
+### M4 — Scope-constraints er forhandlede artefakter, ikke avledede output
+
+Shape Ups no-gos/rabbit holes, BMADs `product-brief.md`-constraints før PRD, Cagans "what I need to believe is true", Lennys Non-Goals — alle navngir det samme: listen over hva som IKKE er i scope er en first-class artefakt, ikke en fotnote. (app-creator har dette i app-brief; bekreftet som riktig.)
+
+### M5 — Context propagation, ikke context reconstruction
+
+MetaGPTs SOP-prinsipp, BMADs "each document becomes context for the next phase", Kiros "validate against prior phase before proceeding" — alle adresserer samme rotfeil: AI (og mennesker) gjenoppbygger forståelse fra null ved hvert steg. BMAD gjør det mekanisk: `PRD.md` → `architecture.md` → story-filer, hver refererer upstream; readiness-gaten sjekker eksplisitt "cohesion across all planning documents". Agent OS' valgfrie `project-context.md` fanger "implementation rules" som persisterer.
+
+**Stjel:** Hver app-creator-brief må eksplisitt referere/embedde constraints fra forrige fase. Dette er nettopp `00-context/`-mappa + `features/{NN}/context.md` fra Akashic-friksjon #5 — bekreftet at retningen er riktig. Vurder også: en eksplisitt "implementation readiness check" (PASS/CONCERNS/FAIL) før fase 7-handover til Voyage, som sjekker koherens på tvers av fase 1-6-briefene.
+
+### M6 — Design-first vs requirements-first som eksplisitt valgpunkt
+
+Kiro ([kiro.dev/docs/specs/best-practices](https://kiro.dev/docs/specs/best-practices/)) formaliserer dette som et påkrevd upfront-valg med dokumenterte trade-offs: Requirements-First (start når oppførsel er kjent, arkitektur fleksibel — produkt-drevet) vs Design-First (start når tekniske constraints driver løsningen — feasibility-begrenset). Bytte etter start = ny spec fra scratch.
+
+**Stjel:** For app-creator: spør operatør hvilken modus før fase 3. Hvis arkitektur MÅ lede ("dette må kjøre offline på iOS med CoreData") endrer det fase-rekkefølgen. For Akashic er det requirements-first (intervjuet drev alt), men ANTAKELSE #2-5 (ingen backend, telemetri-spenning, location-fallback) er arkitektur-constraints som bør resolveres tidlig — grenser mot design-first på de punktene.
+
+### M7 — Feature-scoped spec, ikke system-wide spec
+
+Marc Brooker (Kiro/AWS), sitert i [sudoish.com](https://sudoish.com/spec-driven-development-waterfall-trap/): "you don't need to, and probably shouldn't, develop the entire specification upfront." Kiro, BMAD og agent-os konvergerer alle på feature-scoped spec fra ulike retninger. (app-creator gjør dette i fase 7 — bekreftet. Men obs spenning med fase 1-6 som ER system-wide; se M5 og pitfall P1.)
+
+### M8 — Lagdelt context-injeksjon (standards + product + spec)
+
+Agent-os og BMAD konvergerte på tre-lags context: globale coding standards + per-produkt mission/tech-stack + per-feature spec. Andrew Miller (LinkedIn, aug 2025): "The key is getting the AI to have layers of context." AI kan ikke gis kun feature-briefen — den må vite hvordan denne kodebasen bygger ting. **Dette er nøyaktig domain-pack-konseptet** (Akashic-friksjon #5): domene-laget ("dette er en iOS-app" → konvensjoner, patterns, gotchas) er det manglende mellomlaget mellom app-spesifikk (fase 3-5) og task-spesifikk (fase 7). Bekreftet at det er en reell, gjenkjent kategori — ikke en oppfinnelse.
+
+---
+
+## 2. Fallgruvene å unngå (navngitte, med kilde)
+
+- **P1 — Spec-bloat uten proporsjonalt kode-payoff.** Scott Logic sin hands-on spec-kit-evaluering ([blog.scottlogic.com, nov 2025](https://blog.scottlogic.com/2025/11/26/putting-spec-kit-through-its-paces-radical-idea-or-reinvented-waterfall.html)): Specify+Plan+Tasks for to features produserte **4 839 linjer markdown for ~1 000 linjer kode**; 57 min agent-tid + 3,5 timer human review. Samme to features med iterativ prompting: 23 min totalt. Mye av Plan-output var "obvious and valueless transformations of the spec". Bekreftet av dev.to/casamia918 (mar 2025): 2 577 linjer markdown → 689 linjer kode, ~10x tregere uten kvalitetsgevinst. **Implikasjon:** app-creators 7-fase-pipeline RISIKERER dette. Mottiltak: hver fase-brief må ha et reelt formål utover "transformér forrige brief"; vurder å gjøre faser 2/4/5 lette eller hoppbare når appen er liten (Akashic er eksplisitt "i praksis en liten app").
+- **P2 — Agenten kjører planen i stedet for å stoppe.** spec-kit Issue [#1011](https://github.com/github/spec-kit/issues/1011): `/specify.plan` fikk agenten til å også starte implementering uten å generere task-listen først. Fase-grensen finnes kun som prompt-instruksjon, ikke hard stop. **Implikasjon:** app-creators fase-transisjoner trenger en eksplisitt operatør-handling (oppdater `phase_status`), ikke bare "AI går videre".
+- **P3 — Context-vindu degradering midt i pipelinen.** BMAD Issue [#1343](https://github.com/bmad-code-org/BMAD-METHOD/issues/1343): agent-aktivering konsumerer 67%+ av 200K-vinduet før reelt arbeid; TEA-agentens KB alene 86%. BMAD Discussion [#74](https://github.com/bmad-code-org/BMAD-METHOD/discussions/74) (bmadcode + SWALK10): "after about 3-4 rounds [of agent context], they start to decay, first slowly, then all at once they self-destruct with your code." **Implikasjon:** Akashic-friksjon #6 (én sitting per fase) er reell og dyp — flersesjons-protokollen vi improviserte er ikke valgfri pynt; den er en hard teknisk nødvendighet. Faser som produserer store mellomdokumenter (arkitektur, design-tokens, full backlog) MÅ kunne kjøres i egen sesjon. Domain-packs bør lastes selektivt (max-3-regel à la kiur).
+- **P4 — Spec-drift: spec skrevet én gang, så forlatt.** Loadsys ([loadsys.com](https://www.loadsys.com/blog/spec-driven-development-ai-teams/)): "specs are written once and thrown away". Isoform ([isoform.ai](https://isoform.ai/blog/the-limits-of-spec-driven-development)): "keeping specifications synchronized with code creates a maintenance tax that grows with system complexity". superluminar (apr 2026): "The spec is downstream of the implementation again, just with more steps in between." **Implikasjon:** app-creators brief-revisjons-mekanikk (backtracking, revision-bumps) må faktisk brukes, ikke bare eksistere. For solo-bruk over uker: planlegg for at app-brief vil drifte fra virkeligheten — derav den eksplisitte `revision_reason`-disiplinen og note-feltet i Akashics app-brief.
+- **P5 — Å hoppe over PRD/intervju-fasen krasjer hele pipelinen.** BMAD Issue [#2038](https://github.com/bmad-code-org/BMAD-METHOD/issues/2038): `bmad flow` uten fullført `bmad-create-prd` → agenten hallusinerte hele rammeverket. Uten anker-dokumentet fyller agenten hullene. **Implikasjon:** fase 1 (intervju → app-brief) er load-bearing. Akashic gjorde dette riktig — fase 1 ble kjørt grundig før noe annet. Bekreftet.
+- **P6 — Over-spesifisering gir falsk trygghet og låser ute iterasjon.** Isoform: "detailed specs provide a sense that all cases are covered, but this confidence is misleading since development is inherently exploratory." BMAD Issue [#1818](https://github.com/bmad-code-org/BMAD-METHOD/issues/1818): "the workflow now enforces too much upfront specification, which drowns out the actual functional requirements... bloated documentation and explosive context growth." **Implikasjon:** motstå fristelsen til å gjøre fase 1-6-briefene "komplette". Lett-vekt der mulig.
+- **P7 — Rigid sekvensiell flyt gir friksjon på små endringer.** Kiro ([dev.to/fikuri](https://dev.to/fikuri/kiro-the-good-bad-and-ugly-part-in-my-personal-experience-1neh)): "I just want a design doc. Nope, I have to generate requirements first." Martin Fowler (via Augment Code-review): strukturen "can feel heavy for small fixes". **Implikasjon:** app-creators faser MÅ være re-enterable og hoppbare (utkastet sier dette — "lineær med backtracking, ikke streng pipeline" — bekreftet som riktig). Fase 2 er allerede valgfri; vurder samme for 4 og 5 på små apper.
+- **P8 — Autonom test-generering før featuren virker.** Kiro ([dev.to/fikuri](https://dev.to/fikuri/kiro-the-good-bad-and-ugly-part-in-my-personal-experience-1neh)): task-generatoren inkluderte automatisk unit/integration/E2E-tester for features som ikke passerte ennå → credits brent på feilende tester. **Implikasjon:** app-creators "test-infrastruktur som features"-mønster (fase 6, `F-T`-prefiks) er riktig retning — men test-infrastruktur-features må eksplisitt avhenge av at de underliggende features er shipped (utkastet sier dette: "alle må være shipped" — bekreftet).
+- **P9 — Naturlig-språk-spec-tvetydighet er uløst.** [cesarsotovalero.net](https://cesarsotovalero.net) (forskning): "Practitioners interpret conditionals in requirements inconsistently, even when they believe they are being precise." Loadsys: dev A skriver "use the repository pattern", dev B skriver "call the database service directly" — uavhengig kodede motstridende konvensjoner. For solo: konflikt mellom deg og forrige-deg på tvers av sesjoner. **Implikasjon:** EARS-notasjon (Kiro) for suksess-kriterier der det går; eksplisitte ADRs (app-creator har dette i fase 3) reduserer konvensjons-drift.
+
+---
+
+## 3. Implikasjoner for app-creator (oppsummert)
+
+| Funn | Hva app-creator allerede gjør riktig | Hva som bør endres / vurderes i S5 |
+|------|--------------------------------------|-------------------------------------|
+| M1 triade | fase 1 / fase 3 / fase 7 = requirements/design/tasks-struktur | — (bekreftet) |
+| M2 appetite | "Utenfor (eksplisitt)" finnes | Legg til eksplisitt "appetite"/scope-budsjett tidlig i fase 1 (Akashic-friksjon #4); legg til "rabbit holes"-kategori (distinkt fra "utenfor") |
+| M3 problemramming-gate | fase 1 ER artefakten | Vurder "er dette riktig problem?"-gate før fase 3; vurder Cagans fire-risiko-klassifisering som lett checklist |
+| M5 context propagation | `00-context/` + `features/{NN}/context.md` (besluttet) | Bekreftet — formaliser i fase 7-omskriving; vurder "implementation readiness check" (PASS/CONCERNS/FAIL) før Voyage-handover |
+| M6 design-first valg | "lineær med backtracking" | Legg til eksplisitt requirements-first vs design-first-spørsmål før fase 3 |
+| M8 domain-packs | besluttet konsept; ikke i utkastet ennå | Bekreftet som reell kategori (lagdelt context-injeksjon) — `domain-pack-spec.md` skrives S5 |
+| P1 spec-bloat | fase 2 valgfri | Gjør faser 4/5 lette/hoppbare på små apper; krev at hver brief har formål utover transformasjon |
+| P3 context-degradering | flersesjons-protokoll improvisert | Bekreftet som hard nødvendighet — formaliser i utkastet (Akashic-friksjon #6); selektiv domain-pack-lasting (max-3-regel) |
+| P7 rigid flyt | "re-besøkes når app-en lærer" | Bekreftet — eksplisitt at faser 4, 5 er hoppbare; faser er re-enterable |
+| Agent-os v3-signal | — | Frontier-modeller implementerer specs selv → app-creator skal IKKE absorbere Voyage-eksekvering (allerede invariant — bekreftet av ekstern erfaring) |
+
+**Hovedtakeaway:** Den 7-fase-strukturen er solid og gjenkjennelig prior art — men den største risikoen er ikke at den mangler faser, det er at den blir for tung (P1, P6, P7). Lett-vekt der mulig, hoppbare faser, og flersesjons-protokollen som førsteklasses mekanikk (ikke pynt) er de tre viktigste lærdommene. Domain-pack-konseptet er validert som det manglende mellomlaget.
+
+---
+
+## Kilder
+
+Autoritative (docs-researcher):
+- [Kiro Specs](https://kiro.dev/docs/specs/), [Feature Specs](https://kiro.dev/docs/specs/feature-specs/), [Best Practices](https://kiro.dev/docs/specs/best-practices/)
+- [BMad Method docs](https://docs.bmad-method.org/), [Workflow Map](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/reference/workflow-map.md)
+- [MetaGPT GitHub](https://github.com/FoundationAgents/MetaGPT), [paper 2308.00352](https://arxiv.org/abs/2308.00352)
+- [Agent OS — Builder Methods](https://buildermethods.com/agent-os/workflow)
+- [Shape Up handbook (PDF)](https://basecamp.com/shapeup/shape-up.pdf), [Ch. 2 Principles of Shaping](https://basecamp.com/shapeup/1.1-chapter-02), [Ch. 6 Write the Pitch](https://basecamp.com/shapeup/1.5-chapter-06)
+- [Amazon Working Backwards PR/FAQ](https://workingbackwards.com/concepts/working-backwards-pr-faq-process/), [AWS Prescriptive Guidance — Start with Why](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-product-development/start-with-why.html)
+- [SVPG — Four Big Risks](https://www.svpg.com/four-big-risks/), [Product Discovery](https://www.svpg.com/product-discovery/)
+- [Strategyn — JTBD / ODI](https://strategyn.com/jobs-to-be-done/)
+- [Teresa Torres — Continuous Discovery Habits (2021)](https://www.amazon.com/Continuous-Discovery-Habits/dp/1736633309)
+- [Lenny's PRD template — Atlassian](https://www.atlassian.com/software/confluence/templates/lennys-product-requirements)
+
+Erfaringsrapporter (community-researcher):
+- [Scott Logic — Spec Kit through its paces (nov 2025)](https://blog.scottlogic.com/2025/11/26/putting-spec-kit-through-its-paces-radical-idea-or-reinvented-waterfall.html)
+- [BMAD Discussion #74 (context degradation)](https://github.com/bmad-code-org/BMAD-METHOD/discussions/74), [Issue #1343](https://github.com/bmad-code-org/BMAD-METHOD/issues/1343), [Issue #1818](https://github.com/bmad-code-org/BMAD-METHOD/issues/1818), [Issue #2038](https://github.com/bmad-code-org/BMAD-METHOD/issues/2038)
+- [spec-kit Issue #1011](https://github.com/github/spec-kit/issues/1011)
+- [Kiro: The Good, Bad and Ugly (dev.to/fikuri)](https://dev.to/fikuri/kiro-the-good-bad-and-ugly-part-in-my-personal-experience-1neh)
+- [Isoform — Limits of Spec-Driven Development](https://isoform.ai/blog/the-limits-of-spec-driven-development)
+- [sudoish — SDD waterfall trap](https://sudoish.com/spec-driven-development-waterfall-trap/)
+- [Agent-OS v3 Migration](https://buildermethods.com/agent-os/migration)
+- [Loadsys — SDD breaks at team scale](https://www.loadsys.com/blog/spec-driven-development-ai-teams/)
+- [Ask HN: still using spec driven development?](https://news.ycombinator.com/item?id=46864948)
+- [Petermcaree — Kiro: Hype, Hope and Hard Truths](https://petermcaree.com/posts/kiro-agentic-ide-hype-hope-and-hard-truths/)
+- [dev.to/casamia918 — Why SDD fails](https://dev.to/casamia918/why-spec-driven-development-fails-and-what-we-can-learn-from-it-2pec)
+- [Addy Osmani — My LLM coding workflow going into 2026](https://addyosmani.com/blog/ai-coding-workflow/)

prototype-run/research/B-app-definition.md

@@ -0,0 +1,124 @@
+# Thread B — "Hva definerer en app" — den komplette sjekklista
+
+**Sesjon:** S2 (2026-05-11)
+**Metode:** Voyage-research — `voyage:docs-researcher` (Sonnet), autoritative kilder. Versjons-presisering: ISO/IEC 25010:**2023** (ikke 2011), WCAG **2.2** (okt 2023), OWASP MASVS **2.1** (jan 2024), W3C DTCG **2025.10**.
+**Confidence:** High — alle kilder er primær-standarder eller offisiell vendor-dokumentasjon.
+
+---
+
+## Den komplette sjekklista (gruppert)
+
+### G1 — Problem / intent
+- Problem-statement (én setning), vision-statement, target-user-profil(er), Jobs-to-be-Done, suksess-kriterier (målbare), scope-grenser (eksplisitt utenfor), antakelses-logg, competitive/presedens-analyse.
+- *Kilde: ISO/IEC/IEEE 29148:2018 (requirements engineering life cycle).*
+
+### G2 — Requirements
+**Funksjonelle:** use-case/user-story-sett (actor + action + outcome), acceptance-kriterier per story (testbare Given/When/Then), system-state-modell, datamodell/entiteter, eksterne interface-spesifikasjoner (API-kontrakter, inputs/outputs/feilkoder), requirements traceability matrix (RTM).
+**Ikke-funksjonelle (ISO/IEC 25010:2023 — [iso25000.com](https://iso25000.com/index.php/en/iso-25000-standards/iso-25010)):** 9 karakteristikker — Functional Suitability, Performance Efficiency (p50/p95-latens, ressurs-tak, kapasitet), Compatibility (co-existence, interoperability), **Interaction Capability** (erstatter "Usability" i 2023: learnability, operability, user error protection, user engagement, inclusivity, user assistance, self-descriptiveness), Reliability (faultlessness, availability-SLA, fault tolerance, recoverability RTO/RPO), Security (confidentiality, integrity, non-repudiation, accountability, authenticity + ny *resistance*-subkarakteristikk), Maintainability (modularity, reusability, analysability, modifiability, testability), **Flexibility** (erstatter "Portability": adaptability, installability, replaceability, + ny *scalability*), **Safety** (NY i 2023: operational constraint, risk identification, fail safe, hazard warning, safe integration).
+- *Kilde: [ISO/IEC 25010:2023](https://www.iso.org/standard/78176.html), [arc42 quality model update](https://quality.arc42.org/articles/iso-25010-update-2023).*
+
+### G3 — Arkitektur
+- Arkitektur-oversiktsdokument (arc42-template, ISO/IEC/IEEE 42010:2022) — 12 seksjoner: (1) intro & goals med rangerte kvalitetsmål, (2) constraints (tech/org/regulatorisk), (3) context & scope (systemgrense + eksterne systemer), (4) solution strategy (nøkkel-tech-beslutninger), (5) building-block view (komponent-dekomponering, hierarkisk), (6) runtime view (sekvensdiagrammer for nøkkelscenarier), (7) deployment view (infra, regioner, CI/CD), (8) crosscutting concepts (auth, logging, error handling, i18n, caching), (9) architectural decisions (ADR-indeks), (10) quality requirements (quality tree + scenarier), (11) risks & technical debt, (12) glossary/ubiquitous language.
+- ADR per signifikant beslutning (MADR v3 — [adr.github.io/madr](https://adr.github.io/madr/)): Title → Context & problem → Decision drivers → Considered options → Decision outcome → Consequences → Confirmation → pros/cons per option.
+- Konkrete arkitektur-beslutninger: tech-stack (språk, frameworks, OS-versjoner, SDK-liste med version-pins), persistens (storage-backend, sync-strategi, offline-first vs online-only), auth/identity (Sign in with Apple / OAuth / API-nøkler / session-modell), API-design-kontrakt (OpenAPI eller tilsv.), infra/deployment (cloud-provider, region, CDN, serverless vs containerized), dependency-audit (alle SDKs med lisens-klassifisering + CVE-sjekk).
+- *Kilder: [arc42](https://arc42.org/overview), [ISO 42010 via arc42](https://quality.arc42.org/standards/iso-42010), [MADR v3](https://adr.github.io/madr/).*
+
+### G4 — Designsystem
+**Token-laget (W3C DTCG 2025.10 — [designtokens.org/tr/drafts/format](https://www.designtokens.org/tr/drafts/format/)):** color, dimension (spacing-skala, border-radii, stroke-widths), typography/fontFamily/fontWeight (type-skala med semantiske roller), duration (animasjons-timing), cubicBezier (easing), shadow, border, gradient — totalt ~13 token-typer.
+**Apple HIG-konformans (iOS — [developer.apple.com/design/human-interface-guidelines](https://developer.apple.com/design/human-interface-guidelines/)):** foundations-spec (semantiske farger + Dark Mode, SF Pro/SF Compact + Dynamic Type, safe-area-insets + adaptive layouts, SF Symbols-regler, materials/vibrancy/blur, motion-prinsipper), **Liquid Glass-konformans-notat** (2025 HIG-redesign — translucency/depth/layering), komponent-spec per UI-kontroll (navigation bar, tab bar, toolbar, button-varianter, text field, picker, sheet, alert, action sheet, list, scroll view, form — med states: default/focused/pressed/disabled/error), pattern-spec (onboarding, navigasjons-modell, search, data entry, loading/empty/error-states, account management, settings), Dynamic Type-support-statement (min/maks tekst-størrelser), touch-target-minima (44×44 pt), Dark/Light Mode for hver token, plattform-adaptiv layout (iPhone compact / iPad regular / split-view).
+- *Kilder: [Apple HIG](https://developer.apple.com/design/human-interface-guidelines/), [W3C DTCG Format Module 2025.10](https://www.designtokens.org/tr/drafts/format/).*
+
+### G5 — Ikke-funksjonelle / kvalitets-constraints (spec-nivå, konkrete terskler)
+- Performance-budsjett (cold/warm launch-tid — Apple-guide: <400 ms til first meaningful paint; scroll-framerate 60/120 fps ProMotion; nettverks-timeout-verdier), memory-tak (iOS terminerer uten advarsel ved overskridelse), batteri-bruk (Background App Refresh-strategi), nettverks-effektivitet (payload-grenser, caching, offline-degradering), lokaliserings-scope (språk, RTL, locale-sensitiv formatering), i18n/l10n-arkitektur-beslutning (string-katalog-tilnærming, oversettelses-workflow, pseudo-lokalisering), error-handling-policy (retry-logikk, graceful degradation, brukervennlige feilmeldinger), logging/observability-strategi (hva logges, retensjon, crash-reporting, ingen PII i logger), test-dekningsmål.
+
+### G6 — Tilgjengelighet
+- Konformans-mål deklarert — WCAG 2.2 Level AA (56 AA-kriterier på tvers av POUR: Perceivable/Operable/Understandable/Robust — [w3.org/TR/WCAG22](https://www.w3.org/TR/WCAG22/)).
+- VoiceOver (iOS): alle interaktive elementer har accessibility labels/hints/traits, lese-rekkefølge definert.
+- Dynamic Type-konformans (all tekst skalerer), fargekontrast (≥4.5:1 normal tekst, ≥3:1 stor — SC 1.4.3/1.4.11), touch-target ≥44×44 pt (SC 2.5.8 — ny i 2.2), fokus-håndtering (SC 2.4.11 Focus Not Obscured — ny i 2.2), Reduce Motion-support, ingen avhengighet av farge alene (SC 1.4.1), captions/audio-description for video/lyd (SC 1.2.x), Accessible Authentication (SC 3.3.8 — ny i 2.2: ingen ren kognitiv test uten alternativ), a11y-acceptance-kriterier per feature.
+- *Kilde: [WCAG 2.2 — W3C Recommendation 5. okt 2023](https://www.w3.org/TR/WCAG22/).*
+
+### G7 — Personvern / juss
+**GDPR (der EU-brukere er i scope — Reg. (EU) 2016/679):** data-inventar/data-map (hva samles, hvor lagres, hvor lenge, hvem har tilgang), lawful basis per formål (Art. 6; Art. 9 for spesielle kategorier), purpose limitation, data-minimering (Art. 5(1)(c)), retensjons-skjema per datatype, DSAR-mekanisme (Art. 15-22 — tilgang/korreksjon/sletting/eksport), DPAer signert med hver tredjeparts-prosessor (analytics-SDKs, crash-reporters, CDN, cloud), personvern-policy (hva/hvorfor/lawful basis/retensjon/deling/DSAR/tilsynsmyndighet), privacy by design (Art. 25 — bekreftet i arkitektur), in-app konto-sletting (også App Store-krav §5.1.1(v)).
+**Apple App Privacy Details ("nutrition label") — obligatorisk hver submission ([developer.apple.com/app-store/app-privacy-details](https://developer.apple.com/app-store/app-privacy-details/)):** disclosure per datatype over 15 kategorier (Contact Info, Health & Fitness, Financial Info, Location precise/coarse, Sensitive Info, Contacts, User Content, Browsing/Search History, Identifiers user/device, Purchases, Usage Data, Diagnostics, Surroundings, Body, Other), per datatype: Track / linked-to-Identity / Not-Linked; `NSPrivacyTracking`-boolean (ATT); `NSPrivacyTrackingDomains`.
+**Privacy manifest (`PrivacyInfo.xcprivacy`) — påkrevd siden mai 2024 ([developer.apple.com/documentation/bundleresources/privacy-manifest-files](https://developer.apple.com/documentation/bundleresources/privacy-manifest-files)):** `NSPrivacyTracking`, `NSPrivacyTrackingDomains`, `NSPrivacyCollectedDataTypes`, `NSPrivacyAccessedAPITypes` (deklarasjon per **required-reason API** med godkjent grunn-kode: file timestamp-APIer, system boot time, disk space, active keyboard, UserDefaults). **Krav også for hver tredjeparts-SDK** — hver SDK må shippe sin egen `PrivacyInfo.xcprivacy`.
+- *Kilder: [GDPR](https://gdpr.eu/what-is-gdpr/), [Apple App Privacy Details](https://developer.apple.com/app-store/app-privacy-details/), [Apple privacy manifest](https://developer.apple.com/documentation/bundleresources/privacy-manifest-files).*
+
+### G8 — Sikkerhet (OWASP MASVS 2.1 — [mas.owasp.org/MASVS](https://mas.owasp.org/MASVS/))
+8 kontroll-grupper: **MASVS-STORAGE** (sensitiv data ikke i klartekst, Keychain for credentials/tokens, ingen secrets i logger/backups), **MASVS-CRYPTO** (ingen custom crypto, standard-algoritmer, sikker nøkkel-generering/lagring, ingen hardkodede nøkler), **MASVS-AUTH** (auth-mekanisme-beslutning: biometri/PIN/OAuth 2.0+PKCE; session-token-håndtering, revokering, re-auth for sensitive operasjoner), **MASVS-NETWORK** (TLS 1.2+, certificate pinning-beslutning, ATS enforced, ingen hardkodet API-URL i binær), **MASVS-PLATFORM** (WebView-bruk deklarert, inter-app-kommunikasjon/deep links validert, permission-bruk justifisert, ingen sensitiv data i pasteboard uten expiry), **MASVS-CODE** (input-validering for all ekstern data, ingen deprecated/usikre APIer, dependency-CVE-skann, ingen debug-kode/backdoors i prod), **MASVS-RESILIENCE** (anti-tampering/jailbreak-detection/obfuskering-beslutninger for high-assurance, code-signing verifisert), **MASVS-PRIVACY** (lagt til v2.1: minimale permissions, consent før sensitiv innsamling, ingen unødvendig device-fingerprinting, telemetri opt-out).
+- *Kilde: [OWASP MASVS 2.1](https://mas.owasp.org/MASVS/) (jan 2024).*
+
+### G9 — Plattform / App Store-submission
+**App Store Connect-metadata ([developer.apple.com/help/app-store-connect](https://developer.apple.com/help/app-store-connect/)):** app-navn (2-30 tegn, lokalisert), subtitle (≤30), bundle ID (permanent), SKU, primær-språk/lokaliserings-scope, primær + valgfri sekundær kategori, beskrivelse (≤4000 tegn), keywords (≤100 tegn), "What's New", support-URL + marketing-URL, **personvern-policy-URL (påkrevd)**, custom EULA (eller Apple-standard), screenshots (obligatorisk 6.9" iPhone 1290×2796 px + 13" iPad 2064×2752 px hvis iPad støttes; ≤10 per device; PNG/JPEG), app preview-videoer (valgfri, ≤30 s), app-ikon.
+**Aldersgrense (Review Guidelines §2.3.6):** alders-spørreskjema utfylt i App Store Connect (cartoon/realistisk vold, seksuelt innhold, nakenhet, banning, alkohol/dop/tobakk, gambling, horror, modne temaer, uhindret web-tilgang) → 4+/9+/12+/17+; "Made for Kids"-flagg-beslutning (permanent).
+**Review Guidelines-konformans ([developer.apple.com/app-store/review/guidelines](https://developer.apple.com/app-store/review/guidelines/)) — nøkkel-beslutninger:** §1.2 UGC-moderering, §2.1 app-completeness (ingen placeholder, ingen brutte lenker, test-credentials til reviewer), §2.3 metadata-nøyaktighet (screenshots = faktisk UI, ingen villedende keywords), §2.5.1 kun public Apple-APIer, §3.1 IAP-strategi, §5.1.1(v) konto-sletting in-app, §5.1.2 deling med tredjepart disclosed, §4.2 minimum funksjonalitet.
+**Eksport-compliance ([developer.apple.com/help/app-store-connect/.../overview-of-export-compliance](https://developer.apple.com/help/app-store-connect/manage-app-information/overview-of-export-compliance/)):** krypterings-bruk deklarert; hvis ja: ECCN-klassifisering (5D002 / 5D992 mass market), CCATS fra BIS hvis påkrevd, `ITSEncryptionExportComplianceCode` i Info.plist, Frankrike-spesifikke kontroller hvis aktuelt.
+**Plattform-tekniske krav:** `NSUsageDescription`-strings for hver permission (camera/microphone/location/contacts/health — manglende = umiddelbar avvisning), IPv6-support (§2.5.5), ATT-prompt hvis tracking (`NSUserTrackingUsageDescription`), background modes deklarert med justifisering, Associated Domains-entitlement (Universal Links / Sign in with Apple), APNs-nøkkel hvis push.
+**Region-spesifikke krav:** EU Digital Services Act (DSA) trader-deklarasjon, Kina ICP-filing-nummer + game-permits, Korea GRAC rating-klassifiserings-nummer (spill), regulert medisinsk utstyr-deklarasjon hvis Health/Medical-kategori.
+
+### G10 — Feature-breakdown
+- Feature-backlog (uttømmende, avledet fra requirements) — hver feature: unik ID, user story / acceptance-kriterier, dependency-lenker, NFR-applicability (hvilke NFRs constrainer denne), effort-estimat (T-shirt/story points), prioritet/release-target (MoSCoW e.l.).
+- Dependency-graf (DAG, kritisk sti identifisert), MVP-scope-grense (eksplisitt linje MVP/post-MVP), feature-flag-strategi.
+- Per-feature-brief (én fil per feature, downstream-kompatibelt format): problem, acceptance-kriterier (Given/When/Then), UX-flow-referanse, applicable NFRs, sikkerhets-constraints (relevante MASVS-kontroller), a11y-krav for denne featuren, personvern-notater (data samlet, basis), utenfor-scope-eksklusjoner.
+
+### G11 — Test-strategi
+- Test-strategi-dokument (test-typer, -nivåer, entry/exit-kriterier, miljøer, verktøy, eier).
+- Test-typer deklarert: unit, integration, UI/E2E, performance, security (SAST/DAST), accessibility (automatisk + manuell screen reader), exploratory, regression.
+- Device/OS-matrise (hvilke iPhone/iPad-modeller + iOS-versjoner; min-støttet iOS-versjon-beslutning).
+- Dekningsmål (unit ≥X% line coverage på forretningslogikk; UI-test per kritisk flow), acceptance-kriterier per test-nivå, crash-free-rate-mål (vanlig baseline ≥99.5%), performance-test-plan (baseline + regresjons-terskler), a11y-test-plan (Xcode Accessibility Inspector + manuell VoiceOver-gjennomgang), security-test-plan (SAST-verktøy, dependency-skann, MASVS-checklist-review, pen-test-scope), TestFlight/beta-distribusjons-plan.
+
+### G12 — Release / ops-grense (besluttet ved app-definisjon selv om utført post-build)
+- Versjonerings-skjema (semver + build-number-strategi), phased release-beslutning (Apple 1%→100% over 7 dager), analytics/observability-stack (crash-reporter, analytics uten PII, performance-monitoring — hver SDK med personvern-basis), feature-flag/remote-config-tjeneste + kill-switch, app-update/force-upgrade-policy, support/feedback-kanal + SLA, incident-response-plan, App Store rating-prompt-strategi (`SKStoreReviewAPI` — Apple limiterer til 3/365 dager), ASO-initial-plan (keyword-research, screenshot-copy, lokaliserings-prioritet), post-launch-metrikk-mål (d1/d7/d30 retention, conversion, revenue).
+
+---
+
+## Mapping: hvilke av app-creators 7 faser dekker hva — og hva mangler
+
+| Sjekkliste-gruppe | Eier i app-creator | Status |
+|-------------------|--------------------|--------|
+| G1 Problem/intent | Fase 1 (intervju → app-brief), forfines i fase 2 | ✅ Dekket |
+| G2 Requirements funksjonelle | Fase 1 (stories) → fase 6 (formaliserte acceptance-kriterier) → fase 7 (per brief) | ✅ Dekket på tvers av 1/6/7 |
+| G2 Requirements NFRs (ISO 25010) | Fase 5 (constraints-brief) | ⚠️ Dekket, men ISO 25010:2023-subkarakteristikkene er ikke en navngitt checklist i fase-utkastet — særlig **Safety** (ny i 2023) og **Flexibility/Scalability** mangler eksplisitt |
+| G3 Arkitektur + ADRs | Fase 3 (arkitektur-brief, ADR-style allerede i utkastet) | ✅ Dekket |
+| G4 Designsystem (tokens + HIG) | Fase 4 (design-brief) | ✅ Dekket — men W3C DTCG-token-typene og HIG-pattern-spec kan navngis mer eksplisitt; "Liquid Glass"-konformans bør nevnes |
+| G5 Kvalitets-spec (konkrete terskler) | Fase 5 | ⚠️ Dekket, men performance-budsjett, memory-tak, lokaliserings-scope, i18n-arkitektur trenger navngitte artefakter (ikke bare "Ytelse"-bullet) |
+| G6 Tilgjengelighet | Fase 5 (constraints) + fase 7 (per feature) | ⚠️ Dekket, men WCAG 2.2 SC-nivå-checklist ikke eksplisitt; de 4 nye 2.2-kriteriene (target size, focus not obscured, accessible auth, focus appearance) mangler |
+| G7 Personvern / GDPR + privacy manifest | Fase 5 (constraints) + fase 7 (personvern-notater per brief) | ⚠️ **Delvis** — `PrivacyInfo.xcprivacy` required-reason-API-deklarasjon og per-SDK-privacy-manifest-kravet har ingen eksplisitt artefakt; Apple App Privacy Details ("nutrition label") heller ikke |
+| G8 Sikkerhet (MASVS 2.1) | Fase 3 (auth/crypto-beslutninger) + fase 5 (constraints) + fase 7 | ⚠️ **Delvis** — MASVS-kontroll-gruppene ikke navngitt som strukturert checklist; MASVS-PRIVACY distinkt fra GDPR |
+| G9 Plattform / App Store-submission | Fase 5 (guidelines-compliance, delvis) | 🔴 **Delvis MANGLER** — alders-spørreskjema, `NSUsageDescription`-inventar, screenshot-spec, eksport-compliance, region-krav (DSA/ICP/GRAC), App Store Connect-metadata har ingen dedikert artefakt eller fase-output |
+| G10 Feature-breakdown + per-feature-briefer | Fase 6 + fase 7 | ✅ Dekket |
+| G11 Test-strategi | Fase 5 (nevnt i constraints), fase 6 (test-infrastruktur-features), fase 7 (acceptance-kriterier) | 🔴 **MANGLER** — ingen fase eier et test-strategi-dokument eller device/OS-matrise; "test-infrastruktur som features" dekker E2E-bygging men ikke strategi-beslutningene (dekningsmål, crash-free-rate, device-matrise) |
+| G12 Release / ops-grense | Fase 3 (deployment view, delvis) | 🔴 **MANGLER** — versjonering, phased rollout, analytics-stack, force-upgrade, incident-response, ASO har ingen fase-eier. Merk: noe av dette overlapper app-creators eksplisitte scope-lås "post-shipping ute av scope" (TestFlight-feedback, marketing, ASO) — men release-versjonering, analytics-stack-valg og force-upgrade-policy er pre-build-beslutninger som faller MELLOM "app-bygget" og "post-shipping". Scope-grensen må gjøres eksplisitt: enten eier en fase dem, eller utkastet sier eksplisitt at de er operatørens ansvar utenfor app-creator. |
+
+---
+
+## Kritiske gap i 7-fase-hypotesen (input til S4-syntese / S5-revisjon)
+
+Tre grupper har **ingen eierfase**, og to har **delvis dekning som bør strammes**:
+
+1. **G9 — App Store-submission-artefakter (delvis mangler).** Alders-spørreskjema, `NSUsageDescription`-inventar (hver permission-string med justifisering), screenshot-produksjons-spec, eksport-compliance-bestemmelse, region-spesifikke filings (DSA/ICP/GRAC), App Store Connect-metadata. **Alternativ:** dedikert "Fase 5b — Store readiness" ELLER en obligatorisk checklist appendert til fase 5. For Akashic er dette høyst relevant — paid app, location + notification permissions (krever `NSUsageDescription` + onboarding-forklaring per operatørens eget krav), ikke-affiliering-disclaimer i App Store-beskrivelsen, 7%-donasjons-kommunikasjon. Mange av Akashics constraint-signaler ER i praksis App Store-submission-artefakter.
+
+2. **G11 — Test-strategi (mangler som dokument).** app-creator har "test-infrastruktur som features"-mønsteret (bra — Voyage bygger E2E-suite som hvilken som helst feature), men strategi-beslutningene (dekningsmål, crash-free-rate-mål, device/OS-matrise, hvilke test-typer på hvilke nivåer) har ingen eier. **Alternativ:** artefakt innenfor fase 6 (backlogen driver test-scope) ELLER standalone fase 3b-output avledet fra arkitektur.
+
+3. **G12 — Release / ops-grense (mangler, men delvis bevisst out-of-scope).** Krever en eksplisitt avklaring i S5: hvilke deler eier en fase (release-versjonering, analytics-stack-valg, force-upgrade-policy — pre-build), og hvilke er eksplisitt utenfor app-creator (ASO, marketing, TestFlight-feedback-loops — post-shipping, allerede i scope-lås). Per nå er grensen uskarp.
+
+4. **G2 NFRs / G6 a11y / G7 personvern / G8 sikkerhet — dekket men ikke strukturert.** Fase 5 (constraints-brief) "dekker" disse, men som ad-hoc bullets, ikke som checklists mot ISO 25010:2023 / WCAG 2.2 / privacy manifest / MASVS 2.1. **Alternativ for S5:** fase 5-brief-templaten får navngitte underseksjoner som speiler disse standardene (ikke nødvendigvis uttømmende, men med standarden som referanse slik at gap er synlige). Domain-pack-konseptet kan bære mye av dette: en `ios-app`-domain-pack inneholder MASVS-checklist, privacy-manifest-mal, App Store-submission-checklist, WCAG-2.2-AA-checklist — slik at fase 5 konsumerer domene-spesifikk standard-kunnskap i stedet for å gjenoppfinne den per app. **Dette er trolig den reneste løsningen** og bør utforskes i thread C (S3) og settes i `domain-pack-spec.md` (S5).
+
+---
+
+## Kilder
+
+| Standard / kilde | Versjon | Nøkkel-artefakt | URL |
+|---|---|---|---|
+| ISO/IEC/IEEE 29148 | 2018 | Requirements-engineering-artefakter (use cases, RTM, acceptance-kriterier) | [iso.org/standard/72089.html](https://www.iso.org/standard/72089.html) |
+| ISO/IEC 25010 | 2023 | 9-karakteristikk NFR-taksonomi | [iso.org/standard/78176.html](https://www.iso.org/standard/78176.html) · [arc42 update](https://quality.arc42.org/articles/iso-25010-update-2023) |
+| arc42 / ISO 42010 | arc42 latest / 2022 | 12-seksjons arkitektur-template + ADR-indeks | [arc42.org/overview](https://arc42.org/overview) |
+| MADR | v3 | ADR-template | [adr.github.io/madr](https://adr.github.io/madr/) |
+| W3C DTCG Format Module | 2025.10 | ~13 token-typer | [designtokens.org/tr/drafts/format](https://www.designtokens.org/tr/drafts/format/) |
+| Apple HIG | 2025 (Liquid Glass) | Foundations / Components / Patterns / Platforms | [developer.apple.com/design/human-interface-guidelines](https://developer.apple.com/design/human-interface-guidelines/) |
+| WCAG | 2.2 (okt 2023) | 87 SC / 56 AA / 9 nye i 2.2 | [w3.org/TR/WCAG22](https://www.w3.org/TR/WCAG22/) |
+| OWASP MASVS | 2.1 (jan 2024) | 8 kontroll-grupper (STORAGE/CRYPTO/AUTH/NETWORK/PLATFORM/CODE/RESILIENCE/PRIVACY) | [mas.owasp.org/MASVS](https://mas.owasp.org/MASVS/) |
+| Apple App Store Review Guidelines | gjeldende | 5 seksjoner: Safety/Performance/Business/Design/Legal | [developer.apple.com/app-store/review/guidelines](https://developer.apple.com/app-store/review/guidelines/) |
+| Apple App Privacy Details | gjeldende | 15 datatype-kategorier; Track/Identity/Not-Linked | [developer.apple.com/app-store/app-privacy-details](https://developer.apple.com/app-store/app-privacy-details/) |
+| Apple Privacy Manifest | siden mai 2024 | `PrivacyInfo.xcprivacy`; 5 required-reason-API-kategorier; per-SDK-krav | [developer.apple.com/documentation/bundleresources/privacy-manifest-files](https://developer.apple.com/documentation/bundleresources/privacy-manifest-files) |
+| Apple App Store Connect | 2025 | Metadata-felter; screenshot-spec; eksport-compliance | [developer.apple.com/help/app-store-connect](https://developer.apple.com/help/app-store-connect/) |
+| GDPR | Reg. (EU) 2016/679 | Lawful basis, data-minimering, DSAR, DPAer, personvern-policy | [gdpr.eu/what-is-gdpr](https://gdpr.eu/what-is-gdpr/) |