# 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

## Prototype-protokoll-tillegg (R17, lagt til 2026-05-11 / S5)

**Mål faktisk fase-overhead-tid i Akashic-kjøringen.** Per fase som kjøres (2–7): noter omtrentlig tid brukt og hvilken artefakt fasen produserte. En fase som tar timer og produserer en artefakt ingen Voyage-brief refererer = bevist seremoni → kandidat for å bli skippbar-by-default eller fjernes (jf. thread E). Loggføres i `SESSION-LOG.local.md` per fase-sesjon, oppsummeres i en revisjon av `phase-design-draft.md` § "Når dette utkastet skal oppdateres".

## 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`.

**S5-bekreftelse (2026-05-11):** Anvendt (R12, alternativ A). `phase-design-draft.md` § Pre-pipeline: init samler kun identitets-data (slug, navn, plattform, dato, evt. domain-pack); "Hvorfor denne appen" er tom ved init, genereres retrospektivt etter fase 1 complete som destillering av app-brief Problem & motivasjon; "Pre-fase-notater" fjernet helt.

---

## #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.

**S5-bekreftelse (2026-05-11):** Anvendt (R12). `phase-design-draft.md` § Fase 1 § Kjøre-disiplin disiplin 5: kvalitets-sjekken splittet — 5 pre-draft-spørsmål (besvarbare fra transkriptet, inkl. omformulert #1: "Har vi nok materiale ...?") + 1 post-draft-spørsmål ("Står operatør bak problem & motivasjon-avsnittet slik AI formulerte det?"). Gjelder kun full-variant; minimal-variant har ingen kvalitets-sjekk.

---

## #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.

**S5-bekreftelse (2026-05-11):** Anvendt (R12 + R13). `phase-design-draft.md` § Fase 1 § Kjøre-disiplin disiplin 2 (Anchor/Sharpen): Omfang skiller eksplisitt "Hva appen GJØR" (funksjonelle features → fase 1-brief, driver fase 6) fra "Hvordan appen ER" (kvalitative egenskaper → fase 4/5); AI-foreslått funksjonell-features-hypotese er nå standard neste steg, ikke ad-hoc redning. App-brief-templaten har egen "Innenfor (funksjonelle features — 'hva appen GJØR')"-overskrift + en distinkt "Rabbit holes"-seksjon (R13).

---

## #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.

**S5-bekreftelse (2026-05-11):** Anvendt (R12 + R13). `phase-design-draft.md` § Fase 1: "Tidlig eierskaps-spørsmål" stilles som ett av de første spørsmålene i begge varianter ("Hvem er dette egentlig for ... hvilken vinner ved konflikt?"); weakest-section-loopen i full-variant starter med "Eierskap & intensjon" før "Problem & motivasjon"; app-brief-templaten har egen "Eierskap & intensjon"-seksjon. I tillegg lagt til "Appetite / scope-budsjett" tidlig (R13 — adresserer at skala-rekalibreringen i Akashic kom for sent).

---

## #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.

**S5-bekreftelse (2026-05-11):** Anvendt fullt (R1 + ny `docs/domain-pack-spec.md`). `phase-design-draft.md` § Filsystem-layout: flat `07-feature-briefs/{NN}-{slug}.md` erstattet med `features/{NN}-{slug}/` (`brief.md` + `context.md` obligatoriske, + valgfritt `research.md`/`design-ref.md`/`voyage_run.md`); `00-context/` lagt til (materialiserte domain-pack-snapshots + `pack-overrides.md`). `domain-pack-spec.md` skrevet domene-nøytralt: 8-komponent-liste med fil-navn, `pack.json`-skjema, eksplisitt-fil-sti-lasting + max-3-regel + materialisert snapshot, uformell semver med `pack-overrides.md` som first-class escape hatch, Voyage-agnostisk håndtering (pack-utdrag embeddes i `context.md`, aldri "domain-pack-generert"-merking). Lagrings-sted besluttet: `domain-packs/` i plugin-roten.

---

## #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.

**S5-bekreftelse (2026-05-11):** Anvendt (R3). `phase-design-draft.md` § Flersesjons-protokoll: den improviserte protokollen (`SESSION-ROADMAP` + `NEXT-SESSION-PROMPT` + `SESSION-LOG`, `/clear` mellom sesjoner, "Les og følg ... nøyaktig" som re-entry) er formalisert som dokumentert praksis; faser som produserer store mellomdokumenter MÅ kunne kjøres i egen sesjon. **Beslutning:** dokumentert praksis + lett `state.json`-felt (`session.current`, `session.next_action`, `session.log`) — IKKE innebygd `trekcontinue`-aktig mekanikk ennå (YAGNI; vurderes hvis prototypen viser at manuell protokoll ikke holder). Også lagt til hard lengde-grense per artefakt (R7, ≤500 ord / én skjerm) som adresserer at store mellomdokumenter spiser budsjett.

---

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

**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`.

**S5-bekreftelse (2026-05-11):** Anvendt (R10 + R11 + `domain-pack-spec.md`). `domain-pack-spec.md` § D2: `checklist.md`-komponenten bærer App Store-submission-checklist, MASVS 2.1, WCAG 2.2 AA, privacy-manifest-mal — den eksplisitt nevnte løsningen på "manglende eierfaser". `phase-design-draft.md` § Scope-lås: ny "Release/ops-grensen"-underseksjon gjør grensen eksplisitt (app-brief eier scope-relevante release-valg: distribusjons-modell, analytics ja/nei, versjonerings-strategi; domain-pack-checklist eier operasjonelle submission-artefakter; force-upgrade/TestFlight/ASO/marketing eksplisitt utenfor). Test-strategi: ikke egen fase — strategi-beslutninger som constraints i fase 5 (strukturert mot domain-pack-checklist), infrastruktur som `F-T`-features i fase 6. `phase-design-draft.md` § Fase 5: constraints-brief-templaten har navngitte underseksjoner mot ISO/IEC 25010:2023 (9 karakteristikker, særlig de nye Safety + Flexibility), WCAG 2.2 AA (de 4 nye 2.2-kriteriene navngitt), OWASP MASVS 2.1 (8 kontroll-grupper), privacy manifest (`PrivacyInfo.xcprivacy`, App Privacy Details) — som referanse, med checklisten i domain-pack-en som det uttømmende grunnlaget. Fase 5 er nå merket SKIPPBAR (bæres av domain-pack-checklists for apper som følger defaults).

---

## #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`.

**S5-bekreftelse (2026-05-11):** Anvendt fullt (R5–R9, R14, R17). `phase-design-draft.md` ny § "Den sentrale design-spenningen (S5-stillingstaken)" + workflow-oversikten omtegnet som **eskalerings-stige** (default er kort; hver ekstra fase er et bevisst valg). (a) Rapid mode: ny § + egen gren i workflow-diagrammet — app-konsept → minimal-men-gyldig app-brief → fase 7, uten 2–6; minimal-men-gyldig = problem & motivasjon + målgruppe + ≥1 suksess-kriterium + ikke-tom utenfor-liste + plattform. (b) Skippbare faser: fase 2/4/5 merket SKIPPBAR; `state.json` `phase_status` aksepterer `{"status": "skipped", "reason": "..."}`-objekt. (c) Hard lengde-grense: ny § (≤500 ord / én skjerm), `length_words`-felt i alle interne brief-frontmatter, overskridelse = review-flagg. (d) Fase 3: ADR-er skrives idet beslutningen tas; egen "Uavklarte arkitektur-spørsmål (AQ-NNN)"-seksjon som lukkes etter hvert; problem-gate (PR/FAQ-stil) + requirements-first-vs-design-first-spørsmål før fasen (R14). (e) R17: lagt til i prototype-protokollen i denne fila (§ Prototype-protokoll-tillegg) — mål fase-overhead-tid i Akashic-kjøringen. I tillegg: fase 1 har nå minimal-variant (default, kort fritekst) vs full-variant (opt-in, 6-tema-intervju med trekbrief-disipliner) — adresserer "å intervjue seg selv er rituell nedskriving"; fase 4 trigges på bruk (R8 — aktiveres etter første Voyage-UI-komponenter, ellers HIG/Material direkte); implementation-readiness-check (PASS/CONCERNS/FAIL) før fase 7-handover (R14).

## Ny friksjon oppstått i S5

Ingen ny design-friksjon. S5 var en ren revisjons-/spec-skrivings-sesjon mot research-brief-mandatet — ingen reell pipeline-kjøring som kunne avsløre nye gap. Prosess-merknad: revisjonen av `phase-design-draft.md` ble stor (førsteutkast ~900 linjer → andreutkast tilsvarende), men holdt seg innenfor token-budsjett ved å skrives som ett `Write`-kall etter at all kontekst var lest. Neste reelle friksjons-belegg kommer når Akashic kjøres videre (fase 2+) i S8+.

---

## #9: Prototype-data (Akashic `01-app-brief.md`) refererer en iOS-versjon som ikke finnes ("iOS 19")

**Fase:** fase 1 (Akashic-brief), oppdaget i fase-arbeid utenfor Akashic (S6 domain-pack-forfatting + verifisering)
**Type:** prototype-data-friksjon (ikke en design-flaw i app-creator selv, men en konkret demonstrasjon av hvorfor Verifiseringsplikten + fase-1-research-tema-uthenting trengs)
**Observert:** 2026-05-12 (S6) — under verifisering av `ios-app`-pakkens `pack.json` `verified`-felt mot offisielle Apple-kilder

**Beskrivelse:** Akashic `01-app-brief.md` § Plattform sier "Min-versjon: iOS 18 (gjeldende per mai 2026). Oppdateres til iOS 19 etter at den lanseres høst 2026". Verifisering mot Apple Newsroom / Apple Developer: **iOS 19 finnes ikke.** Apple gikk på WWDC juni 2025 fra iOS 18 rett til **iOS 26** (år-basert navn), med "Liquid Glass" som nytt designspråk; iOS 26 ble lansert september 2025. I mai 2026 er iOS 26 gjeldende versjon; neste store versjon er iOS 27 (WWDC juni 2026, lansering høst 2026). Briefen ble skrevet i S1 uten å verifisere iOS-navne-endringen — et lite, men konkret eksempel på at en udokumentert/feilhusket plattform-faktum sniker seg inn i en brief hvis den ikke verifiseres.

**Hva S6 gjorde med det:** `ios-app/pack.json` `verified.against` reflekterer den verifiserte tilstanden (iOS 26 / HIG-Liquid Glass WWDC 2025 / deployment-baseline iOS 17–18 / MASVS 2.1.0 / WCAG 2.2 AA). `domain-pack-spec.md` § D7 fikk en korreksjons-note. `ios-app/conventions.md` og `gotchas.md` sier eksplisitt at "iOS 19 finnes ikke" og at en spec/brief som refererer den er feil. **Selve Akashic-briefen rettes i S7** (revision 0→1 uansett — operatør har sagt det som mangler skal fylles inn da; iOS-versjons-korreksjonen er en del av det).

**Lærdom for app-creator-designet:** fase 1-malen bør ha plattform-versjons-felter merket som verifiserings-pliktige (datert "verifisert mot {kilde} {dato}"), og domain-pack `conventions.md` er det rette stedet for "gjeldende plattform-versjon"-fakta — slik at app-briefen arver dem fra pakken i stedet for å gjette. Allerede delvis dekket av at `phase-design-draft.md` § Fase 1 har trekbrief-disiplinen "research-tema-uthenting" og `[ANTAKELSE]`-markører, og at `ios-app`-pakken nå bærer iOS-versjons-policyen. Ingen ny revisjon av `phase-design-draft.md` nødvendig — men verdt å huske at domain-pack-`conventions.md` skal være kilden for slike fakta, ikke per-app-briefen.

---

## Ny friksjon oppstått i S6

Én ny prototype-data-friksjon: #9 (over). Ingen ny *design*-friksjon i selve pipeline-designet — S6 var forfatter-arbeid (domain-packs), ikke pipeline-kjøring.

Mindre prosess-/spec-merknader fra forfatter-arbeidet (ikke nummererte friksjons-poeng — bare ting verdt å notere):
- **`checklist.md` sprenger lengde-grensen for `ios-app`.** App Store-submission + MASVS 2.1 (8 grupper) + WCAG 2.2 AA + privacy-manifest-mal + App Privacy Details får ikke plass på én skjerm. Løst som `domain-pack-spec.md` § D2 forutser: splittet i `checklist.md` (App Store-submission + index) + `checklist-security-privacy.md` + `checklist-accessibility.md`, hver lastbar uavhengig, hver med egen `components`-oppføring. Bekrefter at split-konvensjonen i § D2 var nødvendig, ikke teoretisk.
- **`pack.json` trengte et `components`-felt.** D3-skjemaet (S5) hadde ikke en maskinlesbar core/supplementary-merking; D2 sa "merkes i toppen av hver fil eller sentralt". S6 valgte sentralt (`components`-map i `pack.json`) fordi en snapshot-generator da kan lese det direkte. `domain-pack-spec.md` § D3/D4 oppdatert. Liten spec-gap fylt under forfatter-arbeidet — akkurat den typen ting forfatting av en referanse-implementasjon skal avsløre.
- **Verifiserings-asymmetri pakkene imellom.** `ios-app` er verifisert mot offisielle eksterne kilder (Apple/W3C/OWASP). `claude-code-plugin` er ekstrahert fra interne ktg-konvensjoner og er en stub — plattform-detaljene der (hooks-API, `${CLAUDE_PLUGIN_ROOT}`, auto-discovery) er *ikke* uttømmende verifisert mot offisiell Claude Code-dokumentasjon. Markert eksplisitt i pakkens `pack.json` `verified.note` og i `domain-pack-spec.md` § Kilder. Ikke et problem (pakken er ikke i bruk av Akashic), men ærlig om status.

---