app-creator/prototype-run/friksjon.md

Prototype-run friksjons-logg

Hva dette er: app-creator drives gjennom en reell prototype — én faktisk iOS-app (Akashic Intelligence, ligger i /Users/ktg/repos/akashic-intelligence/) kjøres manuelt gjennom 7-fase-pipelinen. Denne loggen fanger alt som ikke fungerte som forventet i app-creator-designet, slik at ../docs/phase-design-draft.md kan revideres med reell friksjons-data. Loggen er app-creators utviklings-artefakt, ikke en del av Akashic-appens definisjon.

Prototype-app: akashic-intelligence Startet: 2026-05-10

Format

## #N: Kort-tittel
**Fase:** {1-7 eller pre-pipeline / cross-cutting}
**Type:** design-friksjon | innhold-friksjon | mekanikk-friksjon | kontrakt-friksjon
**Observert:** YYYY-MM-DD
**Beskrivelse:** Hva skjedde, hva forventet vi, hva var feil.
**Foreslått revisjon:** Hva phase-design-draft.md burde si i stedet (skisse, ikke ferdig formulert).

---

#1: Pre-pipeline init duplikerer fase 1 sin intent-ekstraksjon

Fase: pre-pipeline Type: design-friksjon Observert: 2026-05-10

Beskrivelse: phase-design-draft.md linje 124-152 sier pre-pipeline init skal opprette app.md med en "Hvorfor denne appen"-seksjon (én avsnitt fra operatørens initial-begrunnelse) FØR fase 1 starter. Men fase 1 sin Anchor for Problem & motivasjon (per importerte trekbrief-mønstre) spør i praksis det samme spørsmålet, bare grundigere. Operatør risikerer å skrive ett svar i init og et annet i intervjuet — vi sitter med to versjoner som ikke matcher, og den ene må overstyres.

Foreslått revisjon: To alternativer:

• (A) Pre-pipeline init samler KUN identitets-data (slug, navn, plattform, dato). "Hvorfor denne appen" og "Pre-fase-notater" droppes fra init. Genereres retrospektivt etter fase 1 complete, som ett-avsnitts-destillering av app-brief sin Problem & motivasjon-seksjon.
• (B) Init-spørsmålet gjøres eksplisitt provisorisk ("én linje, du justerer i fase 1") og fase 1 sjekker om init-versjonen stemmer eller må endres.

Anbefaler (A) for renere kontrakt — app.md blir identitets-fil only, intent-fil-en er 01-app-brief.md.

---

#2: Kvalitets-sjekk #1 forutsetter artefakten den skal validere

Fase: 1 Type: mekanikk-friksjon Observert: 2026-05-11

Beskrivelse: Det første av de 6 kvalitets-sjekk-spørsmålene er "Er problem & motivasjon skrevet i 1-2 avsnitt operatør står bak?" Men app-brief-en (som inneholder problem & motivasjon-seksjonen) skrives ETTER kvalitets-sjekken passerer. Kylling-og-egg: sjekken kan ikke besvares før artefakten finnes, men artefakten skrives ikke før sjekken passerer.

Foreslått revisjon: Splitt kvalitets-sjekken i to faser:

• Pre-draft-sjekk (5 spørsmål): Målgruppe konkret? Minst ett målbart suksess-kriterium? Utenfor-liste ikke-tom? Plattform eksplisitt? Åpne spørsmål kategorisert? — alle besvarbare fra transkriptet.
• Post-draft-sjekk (1 spørsmål): Står operatør bak problem & motivasjon-avsnittet slik AI formulerte det? — besvares når brief-utkastet leses.

Eller: omformuler #1 til "Har vi nok materiale i transkriptet til å skrive et problem & motivasjon-avsnitt operatør vil stå bak?" — da er det besvarbart før draft.

---

#3: "Omfang innenfor"-spørsmålet henter produkt-kvaliteter, ikke features

Fase: 1 Type: innhold-friksjon Observert: 2026-05-11

Beskrivelse: Da AI spurte "list de viktigste tingene appen MÅ kunne gjøre i v1", svarte operatør med produkt-kvaliteter ("visuelt innbydende", "$1-pris", "brukervennlig", "app du får lyst til å bruke") — ikke funksjonelle features. AI måtte deretter foreslå en funksjonell-features-hypotese (Tur 7) for å få konkrete features på bordet. Det fungerte, men tok en ekstra runde.

Foreslått revisjon: Anchor-formuleringen for Omfang burde eksplisitt skille:

• "Hva appen GJØR" (funksjonelle features — det som hører i fase 1-brief og driver fase 6 feature-derivasjon)
• "Hvordan appen ER" (kvalitative egenskaper — visuelt, brukervennlig, ytelse — hører i fase 4 designsystem og fase 5 constraints)

Eventuelt: aksepter at operatør gir kvaliteter, og gjør AI-foreslått-features-hypotese til standard neste-steg i Omfang-fasen i stedet for en ad-hoc redning.

---

#4: Skala-/eierskaps-rekalibrering kom for sent i intervjuet

Fase: 1 Type: design-friksjon Observert: 2026-05-11

Beskrivelse: I Tur 4 (Brukere) snakket operatør om 11 millioner Isha-frivillige som målgruppe-skala — som om appen primært var et fellesskaps-produkt. I Tur 9 (Tidshorisont) sa operatør "Den er først og fremst for meg selv". Disse er ikke i konflikt, men den andre rekalibrerer tolkningen av den første betydelig: scope-beslutninger bør favorisere "hva operatør vil ha" over "maksimer reach". Hadde dette kommet tidlig, ville Brukere- og Suksess-kriterier-svarene blitt rammet annerledes.

Foreslått revisjon: Legg til et tidlig spørsmål — Tur 1 eller 2, under Problem & motivasjon — om eierskap/intensjon: "Hvem er dette egentlig for: deg selv, andre, eller begge? Og hvis du måtte velge én — hvilken vinner når de er i konflikt?" Dette rammer alle påfølgende svar riktig fra start.

---

#5: Flat artefakt-layout antok ikke per-feature-akkumulering eller domain-pack-kontekst

Fase: cross-cutting (oppstått rett etter fase 1, før fase 2) Type: kontrakt-friksjon Observert: 2026-05-11

Beskrivelse: phase-design-draft.md sin filsystem-layout (linje 80-99) er flat: 07-feature-briefs/{NN}-{slug}.md — én fil per feature. Men i det øyeblikket man tenker forbi fase 1, dukker to ting opp: (1) hver feature akkumulerer flere artefakter (brief, materialisert kontekst, senere Voyage-plan/review), så feature trenger egen mappe; (2) en feature-brief som overleveres til Voyage trenger domene-kontekst ("dette er en iOS-app" → konvensjoner, patterns, gotchas) som verken er app-spesifikk (fase 3-5) eller task-spesifikk (fase 7) — et tredje lag som mangler helt. Operatør har besluttet features/{NN}-{slug}/-mappe-struktur, og vi har skissert en 00-context/-mappe for materialiserte domain-pack-snapshots, men hele "domain pack"-konseptet og dets dokumentasjons-format er ikke i design-utkastet.

Foreslått revisjon: Etter design-research (S2-S5):

• Erstatt 07-feature-briefs/{NN}-{slug}.md med features/{NN}-{slug}/ som inneholder brief.md, context.md (materialisert domene + app-kontekst for denne featuren), og senere Voyage-output-artefakter.
• Legg til 00-context/ for materialiserte domain-pack-snapshots på versjonen appen bruker.
• Skriv en domene-nøytral domain-pack-spec.md: hva en pakke inneholder (konvensjoner, patterns, gotchas, scaffolding, review-kriterier, referanse-impl), hvilket format, hvordan fasene 3-7 konsumerer den, hvordan den refereres i Voyage-handover uten å bryte Voyage-agnostisk-invarianten.
• app-creator shipper referanse-pakker (ios-app, claude-code-plugin) som eksempel-implementasjoner; fork & own-brukere lager egne.

---

#6: Design-utkastet behandler hver fase som om den skjer i én sitting

Fase: cross-cutting Type: mekanikk-friksjon Observert: 2026-05-11

Beskrivelse: Å drive en reell app gjennom pipelinen tar mange sesjoner (kontekstvindu-grenser, naturlige pauser, research-avstikkere). phase-design-draft.md har ingen notasjon av flersesjons-state — ingen "session roadmap", ingen handover-mellom-sesjoner, ingen logg av hva som faktisk er gjort vs planlagt. I dette prototype-runet improviserte vi en flersesjons-protokoll (SESSION-ROADMAP.local.md + NEXT-SESSION-PROMPT.local.md + SESSION-LOG.local.md i app-creator-pluginens rot) — operatør kjører /clear mellom sesjoner og starter hver med "Les og følg NEXT-SESSION-PROMPT.local.md nøyaktig".

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.mds 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".

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.

---