research(app-creator): thread C+D+E — domain-packs, feature-artefakter, contrarian

S3 av flersesjons-design-arbeidet drevet av Akashic-prototypen.
- C: dekomponering av kunnskaps-bunt i 8 komponenter; format/aktivering/versjonering; failure modes fra Cursor/ESLint/Yeoman-erfaring; forslag til domain-pack-spec.md
- D: Voyages faktiske brief-kontrakt (Handover 1, brief_version 2.0) lest fra kildekode + per-feature-artefakt-anatomi (Shape Up/Linear/Jira/GitHub/BMAD/INVEST); features/{NN}/-layout med brief.md+context.md
- E: contrarian-case mot 7-fase-pipelinen (YAGNI, BDUF, spec-drift, discovery-teater, tracer-bullet); fase-sårbarhets-rangering; 7 anti-seremoni-grep
- friksjon #8 lagt til (pipeline antar full-pipeline-as-default; tilsier brief-first); #7 oppdatert med S3-bekreftelse

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

prototype-run/friksjon.md

@@ -120,4 +120,18 @@ Eventuelt: aksepter at operatør gir kvaliteter, og gjør AI-foreslått-features
 
 **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".
 
+**S3-bekreftelse (2026-05-11):** Thread C (domain-packs) dekomponerte en moden kunnskaps-bunt i 8 komponenter; checklists + guardrails (App Store-submission-checklist, MASVS 2.1, WCAG 2.2, privacy-manifest-mal) er nettopp det en `ios-app`-pack bærer. Beslutning bekreftet som riktig retning — `domain-pack-spec.md` skrives i S5 med komponent-liste, `pack.json`-format, eksplisitt-fil-sti-lasting + materialisert snapshot i `00-context/`, semver-uformell versjonering med per-app `pack-overrides.md` som escape hatch. Se `research/C-domain-packs.md`.
+
+---
+
+## #8: Pipeline-designet antar "full pipeline" som default — solo-dev-bruk + contrarian-research tilsier "brief-first, faser som opt-in"
+
+**Fase:** cross-cutting
+**Type:** design-friksjon
+**Observert:** 2026-05-11 (via design-research thread E, ikke via Akashic-kjøring direkte — men Akashic ER hvorfor researchen ble gjort, og Akashic er eksplisitt "i praksis en liten app … først og fremst for meg selv", som er nøyaktig profilen contrarian-kritikken rammer)
+
+**Beskrivelse:** `phase-design-draft.md` presenterer 7-fase-flyten som standard-løypa; "fase 2 valgfri" og "lineær med backtracking" er de eneste lettvekt-ventilene. Thread E (YAGNI, BDUF-kritikk, Royce' opprinnelige paper var en *kritikk* av sekvensiell flyt, spec-drift som strukturell uunngåelighet, discovery-/PRD-teater, tracer-bullet/walking-skeleton som alternativ) argumenterer at for en solo-dev som bygger en liten app for seg selv er koordineringsgevinsten ved 7 sekvensielle artefakter ~null — faser er koordineringsverktøy mellom folk som ikke deler samme hjerne. Mest sårbare faser rangert: (1) fase 4 designsystem — ren YAGNI-brudd, bør trigge på *bruk* (etter første Voyage-UI-komponenter) ikke *plan*; (2) fase 5 constraints — kan sjekkes just-in-time og bæres av domain-pack-checklists; (3) fase 1 intervju — å intervjue seg selv er rituell nedskriving, ikke discovery. Unntak som *taler for* eksternalisering: thread A's P3 (AI-kontekst degraderer over sesjoner) — men det gjelder de artefaktene Voyage faktisk konsumerer, ikke nødvendigvis alle syv.
+
+**Foreslått revisjon (avgjøres S4-syntese / S5):** (a) Innfør en eksplisitt "rapid mode" / "sketch brief"-sti — konsept → minimal-men-gyldig app-brief inline → fase 7 feature-brief, uten å passere 2-6; den fulle pipelinen blir eskalering, ikke default. (b) Faser skippbare med eksplisitt én-setnings-begrunnelse loggført i `state.json` (ikke bare "valgfri"). (c) Hard lengde-grense per fase-artefakt (≤500 ord / én skjerm der mulig) — lengde er sterkeste seremoni-signalet. (d) Arkitektur-fasen produserer *åpne spørsmål som lukkes etterpå*, ikke en decisions-log skrevet før koden (decisions-log før kode = grunnlag for spec-drift). (e) Legg til i prototype-protokollen: 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. NB: dette *skjerper* thread A's takeaway ("strukturen er solid, men risikoen er at den blir for tung") til "risikoen er ikke bare for tung — det er feil default-retning". Se `research/E-contrarian.md`.
+
 ---