docs(app-creator): prototype-run dir — Akashic-drevet design-arbeid

Starter prototype-runet som driver app-creator-designet før implementering.
- prototype-run/friksjon.md: 6 friksjons-poeng oppdaget i Akashic fase 1
- prototype-run/README.md: forklarer oppsettet

Flersesjons-orkestrering (SESSION-ROADMAP/LOG/NEXT-SESSION-PROMPT.local.md)
ligger i plugin-roten, gitignored. Akashic-instansen ligger i eget repo.

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

prototype-run/README.md

@@ -0,0 +1,23 @@
+# prototype-run/
+
+app-creator drives gjennom én reell prototype før implementering starter (jf. `../CLAUDE.md` § Status). Denne mappa holder arbeids-state for det prototype-runet.
+
+## Prototype-app
+
+**Akashic Intelligence** — en iOS-app for Sadhgurus tre-bukk-praksis. Instans-artefaktene (app-brief, intervju-transkript, fase-briefer, `state.json`) ligger i et eget repo: `/Users/ktg/repos/akashic-intelligence/`. Det repoet er en *ren app-creator-instans* — det en hvilken som helst bruker ville hatt. Det inneholder ikke app-creators egen utviklings-state.
+
+## Hva ligger her
+
+| Fil | Committet? | Hva |
+|-----|-----------|-----|
+| `friksjon.md` | ja | Friksjons-logg — alt som ikke fungerte i app-creator-designet, oppdaget via prototype-runet. Driver revisjon av `../docs/phase-design-draft.md`. |
+| `research/` | ja (fra S2) | Råfunn fra design-research-threadene (A-E), og senere `research-brief.md` (syntesen). |
+| `../SESSION-ROADMAP.local.md` | nei (gitignored) | Sesjons-planen for hele prototype-runet + design-arbeidet. |
+| `../SESSION-LOG.local.md` | nei (gitignored) | Hva hver sesjon faktisk gjorde (fasit vs plan). |
+| `../NEXT-SESSION-PROMPT.local.md` | nei (gitignored) | Prompten for neste sesjon. Operatør kjører `/clear` og starter ny sesjon med "Les og følg NEXT-SESSION-PROMPT.local.md nøyaktig" — fra app-creator-pluginens rot (`.../plugins/app-creator/`). |
+
+`.local.md`-filene ligger i plugin-roten (ikke her) fordi operatør arbeider fra plugin-roten og starter hver sesjon derfra — de må være lett å finne. De er ephemeral working state.
+
+## Når prototype-runet er ferdig
+
+Friksjons-loggen og research-funnene har da drevet: en revidert `../docs/phase-design-draft.md`, en ny `../docs/domain-pack-spec.md`, og referanse-domain-packs. Da kan implementering av app-creator-pluginen starte. Denne mappa beholdes som historikk.

prototype-run/friksjon.md

@@ -0,0 +1,107 @@
+# 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.)
+
+---