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

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

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.

---

#10: App-brief sprenger 500-ord-lengdegrensen — selv etter stramming

Fase: 1 (fase 1 output: 01-app-brief.md) Type: design-friksjon (lengde-grense) Observert: 2026-05-13 (S7) — under revisjon av Akashic 01-app-brief.md fra revision 0 til revision 1

Beskrivelse: phase-design-draft.md § Hard lengde-grense + domain-pack-spec.md § D2 setter ≤500 ord / én skjerm som default for alle interne briefer (med eksplisitte unntak for examples/-filer og 01-interview-transcript.md). Akashic 01-app-brief.md revision 1 målte 1830 ord etter en bevisst-ikke-oppblåst revisjon. Innholdet som driver lengden er ikke fyllstoff: 11 funksjonelle features (med korte forklaringer som er nødvendige for fase 6 feature-derivasjon), 9 utenfor-punkter, 4 rabbit holes, 6 antakelser med begrunnelser, 4 constraint-signaler, eierskaps-seksjon, appetite-vurdering, release-modell, plattform-detaljer med iOS-versjons-policy. Hver seksjon er kortfattet; problemet er at en app-brief må dekke mange distinkte temaer for å være anker for fem nedstrøms-faser.

Hva som ble gjort i S7: length_words: 1830 satt i frontmatter; length_review_flag brukt eksplisitt for å markere overskridelsen som akseptert med begrunnelse, og pekt på Omfang-listene og Antakelser-seksjonen som komprimerings-kandidater ved neste revisjon. Briefen overstiger grensen, men er ikke oppblåst.

Lærdom for app-creator-designet: 500-ord-grensen er trolig feil for fase 1 app-brief spesifikt (den er passende for fase 3-architecture-ADR-er, fase 5-constraints og fase 7-feature-briefer, som hver er fokusert på én ting). App-briefen er ankeret for alt nedstrøms — den må være uttømmende på problem/eierskap/scope/plattform/antakelser, ellers hallusinerer fase 3+. Vurder:

• (a) Eksplisitt unntak: app-briefen (fase 1) får en høyere grense, f.eks. ~2000 ord eller "unntak — lengden følger app-omfang".
• (b) Strukturelt skille: en kort "essence"-app-brief (≤500 ord — problem, eierskap, suksess, ≤5 funksjonelle features, plattform) + en "details"-app-brief (utenfor, rabbit holes, antakelser, constraints, full feature-liste) som lever som vedlegg.
• (c) La 500-ord-grensen stå som mål, akseptere review-flagg som default for fase 1, og dokumentere at fase 1-overskridelse er vanlig.

Anbefaling: (a) — enklest, og snapshot-erfaringen (Akashic-snapshotet er 3328 ord, eksplisitt unntatt) viser at ulike artefakt-typer trenger ulike grenser. Avgjøres ved neste phase-design-draft.md-revisjon (eventuelt i S8+ når flere fase-briefer er skrevet og lengde-mønsteret er klarere).

Foreslått revisjon: phase-design-draft.md § Hard lengde-grense får en tabell over artefakt-type vs grense:

Artefakt	Grense
01-app-brief.md	~2000 ord (review-flagg ved >2500)
02-research-briefs/NN-*.md, 03-architecture-brief.md (per-ADR), 05-constraints-brief.md	≤500 ord
06-features-brief.md	≤500 ord intro + ≤8 linjer per feature-entry
features/{NN}-{slug}/brief.md (fase 7)	≤500 ord
features/{NN}-{slug}/context.md (fase 7)	≤500 ord
01-interview-transcript.md, 00-context/domain-pack-*.md, examples/*	unntatt

S8-bekreftelse (2026-05-13): Akashic 02-research-briefs/01-sadhguru-copyright.md (Sadhguru/Isha-opphavsrett-research) målte 1278 ord inkl. frontmatter (~1080 ord body) etter en bevisst-stram syntese. Innholdet er ikke fyllstoff: 5 kilde-domener (Isha T&C, YouTube-policy, US/EU-lov, Apple App Review, presedens) × inline-kilde-pekere + 3 nedstrøms-konsekvens-seksjoner (fase 3/5/6) + Kilder + Restrisiko. Bekrefter mønsteret fra #10: ulike fase-artefakter trenger ulike lengde-grenser. Forslag i tabellen over om "≤500 ord for research-briefer" må trolig justeres for research-briefer som dekker 3+ kilde-domener — kandidat ~1000-1500 ord før review-flagg. Avgjøres ved neste phase-design-draft.md-revisjon når også fase 3+ er skrevet og det totale lengde-mønsteret er klart. length_review_flag-mekanikken funket som tiltenkt: overskridelsen er eksplisitt markert, ikke skjult.

---

Ny friksjon oppstått i S7

Én ny design-friksjon: #10 (over — app-brief vs 500-ord-grense). Ingen ny prototype-data-friksjon.

Prosess-/spec-merknader fra restruktureringen + materialiseringen (ikke nummererte friksjons-poeng):

• Snapshot-mekanikk-detaljer som spec ikke spesifiserte eksplisitt. Tre konkrete valg ble tatt under materialisering, og er nå LÅST i domain-pack-spec.md § Åpne spørsmål (S7-oppdatering): (1) heading-nedjustering ett nivå konsekvent (orig H1 → snapshot H2 osv.) for å gi konsistent dokument-hierarki, (2) inline > **[OVERRIDE-N]** ...-blockquote-konvensjon der en override gjelder, med peker til pack-overrides.md § [OVERRIDE-N], (3) "Relevante patterns"-seksjonen plasseres mellom topp-metadata og første core-fil-seksjon, og inneholder kun pekere (én linje per pattern: navn + formål + app-relevans), aldri full pattern-tekst. Ikke design-friksjon — en presisering som ble nødvendig under første materialisering, akkurat som forfatteren av en referanse-implementasjon skal avsløre.
• pack-overrides.md trengte en [STATUS: åpen/lukket]-konvensjon. domain-pack-spec.md § D5 viste eksempel-formatet ("Pack sier / Denne appen / Hvorfor") men sa ikke hvordan håndtere overrides som ennå ikke er endelig bestemt (f.eks. Akashic iOS 17 vs 18 — krever fase 3-ADR; App Privacy Details — krever pre-submission-verifisering). Akashic-overrides bruker [STATUS: åpen — {hva som lukker]-konvensjon for ÅPNE saker og implisitt LUKKET for resten. Bør formaliseres i spec § D5 ved neste revisjon — mindre kontrakt-presisering.
• app.md domain_packs-frontmatter-formen sprikte. Original Akashic-app.md (S1) hadde et komplekst objekt-format med name/version/source/materialized-felter (lagd før spec ble skrevet i S5). phase-design-draft.md § Pre-pipeline app.md-skjema viser bare en array av name@version-strenger (domain_packs: ["ios-app@0.1.0"]). S7 konvergerte til spec-formen. Implisitt: "source" er underforstått (alltid domain-packs/{name}/ i plugin-roten per § D5), "materialized" er underforstått (filen 00-context/domain-pack-{name}.md eksisterer hvis materialisert). Ikke en ny friksjon — bare en oppdagelse at S1-impl var ut av spec siden spec ble skrevet retrospektivt (S5).
• Token-budsjett: sesjonen ble håndterbar (~? K) — leste konteksten, skrev 5 filer (00-context/domain-pack-ios-app.md som lengste — 3328 ord, sammenslåing av eksisterende; 01-app-brief.md revidert; app.md + state.json + pack-overrides.md skrevet ferskt); små Edit-kall til docs/domain-pack-spec.md + denne fila + senere SESSION-orchestreringsfiler.

---

Ny friksjon oppstått i S8

Ingen ny design-friksjon. Ren fase-2-kjøring (research → ett brief) avslørte ikke nye pipeline-flaws — research-modellen (parallell-spawning av docs- + community-researcher, syntese i hovedkontekst) funket akkurat som S2/S3, og fase 2-templaten produserte en brief som direkte driver fase 3 (feature #6-arkitektur låst) og fase 5 (4 nye enforce-regler).

S8-bekreftelse på eksisterende friksjon:

• #10 (app-brief vs lengde-grense): Bekreftet å gjelde også for research-briefer. Sjekk S8-bekreftelses-notat under #10 over. Lengde-tabell-forslaget må trolig differensieres ytterligere: research-briefer som dekker 3+ kilde-domener er kandidat for ~1000-1500 ord før review-flagg.

Prosess-/spec-merknader fra S8 (ikke nummererte friksjons-poeng):

• Confidence-vurderingen i research-brief-frontmatter er én global verdi, ikke per sub-funn. S8 endte på confidence: medium fordi en av de fem sub-domenene (Isha T&C iOS-app-policy) ikke er offentlig avklart, mens de fire andre er high. Differensiert confidence per sub-funn ville vært ærligere, men phase-design-draft.md § Fase 2-frontmatter har bare ett confidence:-felt. Løsning brukt: én global verdi + nyansering i Restrisiko-seksjonen. Ikke nødvendigvis en design-flaw — templaten er enkel og det er forfatterens jobb å markere usikkerhet i body-tekst. Notert som mulig revisjon ved neste phase-design-draft-runde (lav prioritet).
• Action-pending-attention-typen er ny. S8 la til en attention-entry av typen action-pending i Akashic state.json (pre-submission Isha-forespørsel). Eksisterende typer i state.json attention har vært research, decision, risk-accepted. action-pending (handling som ikke hører i en spesifikk fase, men skal skje før shipping) er en ny kategori — egnet for ting som "send brev til X", "registrer hos Y", "kjør test Z". Ikke en formell friksjon, men en kategori-utvidelse vi kan formalisere i phase-design-draft.md § Cross-cutting state.json hvis flere slike dukker opp i fase 3-7.
• Pre-submission-Isha-forespørselen sitter midt mellom fase 5 constraints og post-fase-7 action. Tematisk hører den i fase 5 (compliance-action), men i tid er den en pre-submission-action som skjer etter fase 7 (når appen faktisk er nær klar). Plassert som phase: pre-submission i state.json attention. Liten kontrakt-uklarhet: er "phase-felt" på attention strengt 1-7 (fase i pipelinen), eller kan det være andre verdier? Phase-design-draft § Cross-cutting state.json sier ikke. Bør avklares ved neste revisjon — ikke et reelt problem nå.
• Token-budsjett: sesjonen holdt seg godt under 250K — hovedkontekst-belastning var lavt fordi research-bulk levde i agent-kontekstene (kombinert ~95K der). Hovedkontekst-skrivinger: research-brief (~1278 ord), state.json (~50 linjer), SESSION-LOG S8-seksjon (~3000 ord), NEXT-SESSION-PROMPT-S9 (~3500 ord forventet), SESSION-ROADMAP-edit (mindre).

---

#11: OVERRIDE-numbering-kollisjon mellom state.json attention og pack-overrides.md

Fase: 5 (observert under S10 constraints-syntese) Type: kontrakt-/konvensjons-friksjon Observert: 2026-05-13 (S10) — under lukking av "tekstsitater i feature #6"-beslutningen som var merket [OPEN] OVERRIDE-3 i Akashic state.json attention

Beskrivelse: S8 la til en attention-entry merket [OPEN] OVERRIDE-3: tekstsitat-overlay i feature #6 — fase 5-beslutning (avledet av research-brief § Restrisiko). Numbering brukte neste-ledige-i-prosessen-rekkefølge uten å sjekke pack-overrides.md, hvor [OVERRIDE-3] allerede var i bruk for MASVS-AUTH N/A (LUKKET siden S7). Resultat: to forskjellige beslutninger med samme navn "OVERRIDE-3", én i hvert dokument. S9 NEXT-PROMPT for S10 refererte begge versjonene om hverandre uten å resolvere kollisjonen ("§ OVERRIDE-3 (MASVS-AUTH N/A, allerede LUKKET — gjenbruk begrunnelsen)" + "Lukk OVERRIDE-3 (tekstsitater)"). S10-constraints-brief må håndtere kollisjonen ad hoc.

Hva som ble gjort i S10: "Tekstsitater"-beslutningen behandles som en ny app-spesifikk constraint i 05-constraints-brief.md § Feature #6 mediekildebruk-policy, IKKE som en pack-override (den deviates ingen pack-default-regel — pack-snapshotet sier ingenting om tredjeparts-tekstsitater). pack-overrides.md får ingen ny entry. state.json attention fjerner OVERRIDE-3-entryen (lukket av S10). Friksjons-merknad i constraints-briefen forklarer kollisjonen.

Lærdom for app-creator-designet: state.json attention-konvensjonen tillater fritekst-beskrivelser, men når en entry navngir "OVERRIDE-N" implisitt forventes det at den korresponderer med en entry i pack-overrides.md. Når den ikke gjør det (fordi det er en ny app-spesifikk beslutning, ikke pack-deviasjon), bør den navngis annerledes.

Foreslått revisjon: phase-design-draft.md § Cross-cutting state.json får en regel:

• attention-entries som refererer pack-overrides bruker [OVERRIDE-N] (matcher pack-overrides.md § [OVERRIDE-N]).
• attention-entries som er nye app-spesifikke beslutninger som ikke deviates pack-defaults bruker ikke OVERRIDE-N. Foreslåtte alternative prefikser: [DECISION-NN] (per fase nummerert; bærer beslutnings-id som er fase-stabilt) eller bare beskrivende ID-løs entry med phase + description-felt.
• Når en attention-entry navngis, sjekk eksisterende pack-overrides.md-numbering først — håndhevbar via en pre-commit-sjekk hvis nødvendig (lav prioritet — forfatter-disiplin er nok i prototype-fasen).

Avgjøres ved neste phase-design-draft.md-revisjon. Lav prioritet — én observasjon i en levende prototype, ikke et systematisk problem ennå. Hvis flere kollisjoner dukker opp i fase 6/7: hev prioritet og formaliser.

---

#12: Constraints-brief er den tyngste fase-artefakt-typen — sprenger lengde-grensen sterkere enn andre

Fase: 5 (observert under S10) Type: design-friksjon (lengde-grense, bekreftelse av #10-mønster) Observert: 2026-05-13 (S10) — under skriving av 05-constraints-brief.md

Beskrivelse: S10 constraints-brief målte 3497 ord (inkl. frontmatter). Sammenlignet med tidligere fase-briefer:

Brief	Ord	Fase
01-app-brief.md (rev 1)	1830	1
02-research-briefs/01-sadhguru-copyright.md	1278	2
03-architecture-brief.md (rev 0)	1827	3
05-constraints-brief.md (rev 0)	3497	5

Constraints-briefen er nær 2× alle andre. Innholdet er ikke fyllstoff: ISO 25010 (6 karakteristikker med Akashic-constraints) + WCAG 2.2 AA (4 nye + 14 bærende + 5 iOS-røyktest = 23 items) + MASVS 2.1 (8 kontroll-grupper, hver med 2–4 sub-constraints) + PrivacyInfo.xcprivacy-utfylling + App Privacy Details-beslutning (lukker OVERRIDE-2) + Feature #6 mediekildebruk-policy (5 enforce) + .timeSensitive-entitlement (5 enforce) + App Store-plattform-regler (A 8, B 4, C 11, D 3, E 4 = 30 items) + governance (8 enforce) + test-strategi (9 items) + konflikt-håndtering (6 reelle konflikter) + Referanser. Hver constraint er kortfattet; problemet er at constraints-fasen er anvendelsen-mot-flere-standarder-pluss-app-spesifikke-regler, ikke én fokusert beslutning.

Hva som ble gjort i S10: Brukte length_review_flag med ærlig begrunnelse. Ikke splittet briefen i sub-filer denne sesjonen — vurdert, men droppet fordi sammenhengen mellom MASVS-PRIVACY → App Privacy Details → Feature #6-policy → governance leses best i én fil. Splitting til 05-constraints-brief/{quality,accessibility,security-privacy,platform,governance,test,conflict}.md er en framtidig kandidat hvis briefen vokser ytterligere (lite sannsynlig — det meste er nå dokumentert).

Lærdom for app-creator-designet: Per-artefakt-lengde-tabellen fra #10 må oppdateres med en eksplisitt rad for constraints-brief:

Artefakt	Foreslått grense
01-app-brief.md	~2000 ord (review-flagg ved >2500)
02-research-briefs/NN-*.md	~1500 ord (review-flagg ved >2000)
03-architecture-brief.md (full, med 4+ ADR-er)	~2000 ord (review-flagg ved >2500)
05-constraints-brief.md	~3500 ord (review-flagg ved >4500) — eller splitting-konvensjon ved >4000
06-features-brief.md	≤500 ord intro + ≤8 linjer per feature-entry
features/{NN}-{slug}/brief.md (fase 7)	≤500 ord
features/{NN}-{slug}/context.md (fase 7)	≤500 ord
01-interview-transcript.md, 00-context/domain-pack-*.md, examples/*	unntatt

Bekrefter at fase 5 er bredde-fase (alle standarder + plattform + governance + test-strategi i ett dokument) mens fase 3 er dybde-fase (ADR-er — fokusert per beslutning). Bredde-faser sprenger grenser; dybde-faser holder seg mer kontrollert.

Foreslått revisjon: Oppdater phase-design-draft.md § Hard lengde-grense med differensiert tabell over (en konkretisering av #10-mønsteret). Eller introdusér en [breadth-phase]-merking på fase 5 (og potensielt fase 1, app-brief) som signaliserer at ~3000–4000 ord er normal-tilstand, ikke avvik. Avgjøres ved neste phase-design-draft.md-revisjon (etter fase 6/7 også er kjørt, slik at hele lengde-mønsteret er empirisk).

---

Ny friksjon oppstått i S9

Ingen ny nummerert friksjon. Bekreftelser + prosess-merknader:

• #10 (per-artefakt-lengde-grense) bekreftes igjen. Arkitektur-briefen målte 1827 ord — mellom app-brief (1830) og research-brief (1278). 6 ADR-er à ~150–180 ord + Problem-gate + Stack-sammendrag + Requirements + AQ + Patterns + Integrasjoner = nær 2000. Per-artefakt-lengde-tabell-forslaget fra #10 må justeres: arkitektur-briefer med 4+ ADR-er er ~1500–2000 ord, ikke <500. (Tabell-revisjons-forslag levert i #12 over.)
• AQ-NNN i brief overlap med state.json attention. AQ-002 lever i 03-architecture-brief.md § Uavklarte arkitektur-spørsmål og i state.json attention. Det er ikke duplisering per se — briefen er sannheten, state.json gir bare app-factory en pekepost. Kontrakten "når en AQ også fortjener en attention-entry" er implisitt: vurderingen som driver senere faser (AQ-002 driver fase 6) → ja, attention-entry; AQ-001 driver implementering (ikke fase) → nei, ingen attention-entry. Bør formaliseres i phase-design-draft.md § Cross-cutting state.json ved neste revisjon (lav prioritet).
• Fase 4-skipping første gang i bruk. phase_status."4": {"status": "skipped", "reason": "..."} brukt for første gang per phase-design-draft.md § Cross-cutting state.json. Spec-kompatibelt, ingen friksjon — skip-mekanikken funker som tiltenkt.
• Token-budsjett: sesjonen holdt seg godt under 250K-grensen. Ingen sub-agent-bulk å outsourcs til; hovedkontekst bar all syntese — likevel ikke nær grensen.

---

Ny friksjon oppstått i S10

To nye nummererte friksjons-poeng: #11 (OVERRIDE-numbering-kollisjon, over) og #12 (constraints-brief sprenger lengde-grensen sterkere enn andre, over).

S10-bekreftelse på eksisterende friksjon:

• #10 (lengde-grense): Bekreftes for fjerde fase-artefakt (1, 2, 3, 5 alle sprenger). Lengde-mønsteret er nå empirisk klart: 1500–3500 ord er normal for fase-briefer i Akashic-kjøringen. Tabell-revisjons-forslag konsolidert i #12.

Prosess-/spec-merknader fra S10 (ikke nummererte friksjons-poeng):

• Constraint-eierskap/testbar-form-stress-testen funket. Per S10-prompt Steg 2: "bekreft for deg selv at hvert constraint i briefen har en avklart eier og en testbar form". Praktisk konsekvens: WCAG 2.5.7 Dragging Movements ble eksplisitt N/A (ingen drag i Akashic v1), 1.4.13 Content on Hover or Focus ble droppet (ikke relevant — appen har ingen popovers/tooltips), MASVS-CRYPTO ble eksplisitt N/A (ingen krypto i appen). Briefen er Akashic-tilpasningen, ikke uttømmende-pack-checklist-kopi — testen tvinger denne disiplinen.
• Apple App Privacy Details FAQ var entydig nok til strict-correct posisjon. Operativ konsekvens: ADR-002 + ADR-003 har tvunget bort all telemetri-SDK-overflate; ADR-004 har tvunget bort all location-off-device. Apple-kriteriet "collected = transmitted off-device" er da entydig oppfylt → "Data Not Collected" vinner over pack-pattern-konservativ ("Location → App Functionality"). Pack-pattern-konservativisme er gyldig som default når man ikke vet; her vet vi. Bekrefter app-brief § Eierskap "konservativ vinner ved tvil" — ved tvil, ikke som permanent retning.
• Constraints-eieren-vinner-løsning på donasjons-konflikt. App-brief § Constraint-signaler sier "ikke-affiliering" (enforce), § Release-modell sier "7 % donasjon kommuniseres i App Store-beskrivelse" (constraint). Hvis disse plasseres uforsiktig kan teksten implisere affiliering ("vi gir til Isha" = "vi er nær Isha"). Løsning lever i briefen § Konflikt-håndtering: distinkt formulering ("uavhengig tredjepart-app + frivillig donasjon som anerkjennelse av kilden"). Ikke en ny friksjon — operatør-løsning under syntese fungerer.
• Token-budsjett: sesjonen holdt seg under 250K. Hovedkontekst-belastning: 4 fase-briefer (app, research, architecture, constraints i full lesing) + pack-snapshot relevante seksjoner + pack-overrides.md + state.json + SESSION-LOG S8/S9 + phase-design § Fase 5. Skrivinger: constraints-brief (3497 ord — største fase-artefakt-skriving så langt), state.json (~75 linjer), pack-overrides.md-edit (~30 linjer), friksjon.md-tilskudd (denne + #11 + #12), SESSION-LOG S10-seksjon (kommer), SESSION-ROADMAP-edit (mindre), NEXT-SESSION-PROMPT-S11. Hovedkontekst-belastning er tyngst i S10 så langt fordi ingen sub-agent å outsourcs til OG fordi syntese-output er nær 2× tidligere — men fortsatt ikke nær 250K-grensen.

---

#13: Fase 6-features-brief-lengde-target undervurderer Voyage-handover-1-strukturert backlog

Fase: 6 (observert under S11) Type: design-friksjon (lengde-target, konsolidering av #10 + #12-tabellen) Observert: 2026-05-13 (S11) — under skriving av Akashic 06-features-brief.md

Beskrivelse: Friksjon #10-tabellen + #12-tabellen setter fase 6 til "≤500 ord intro + ≤8 linjer per feature-entry". For Akashic med 13 entries × ~80 ord/entry ≈ ~1040 + ~500 intro + grafer/R14 ≈ ~1700 ord forventet. Faktisk: 06-features-brief.md målte 2789 ord etter en bevisst-stram syntese (~40 % over). Driver: hver entry har 10 strekpunkter (Slug + Intent + Goal + Non-Goals + Constraints + Preferences + Success Criteria + Dependencies + Effort/Prioritet/Status + Open) for å være Voyage-handover-1-kompatibel (per S11-NEXT-PROMPT instruksjon "Voyage-handover-1-kompatibel feature-entry-struktur slik at fase 7 kan bygge direkte"). ≤8 linjer per entry ble offer for fase-7-klar-struktur — fase 7-brief-skrivingen ville ellers måtte gjenoppfinne disse feltene fra fase 1–5-briefene, hvilket motvirker fase 6-formålet.

I tillegg sprenger Scope-stress-test-seksjonen (~280 ord — utfall-begrunnelse for AQ-002), R14-implementation-readiness-check (~270 ord — PASS/CONCERNS per feature), dependency-graf med mermaid (~110 ord), kritisk sti + parallelliserbare grupper (~220 ord) — alle er fase 6-spec-output (per phase-design-draft.md § Fase 6), ikke fyllstoff.

Hva som ble gjort i S11: Brukte length_review_flag med ærlig begrunnelse + dokumenterte ny target-forslag. Ikke splittet briefen — sammenhengen mellom stress-test-utfall, backlog-detaljer, og R14-PASS leses best i én fil.

Lærdom for app-creator-designet: Per-artefakt-lengde-tabellen fra #10 + #12 må oppdateres med faktisk fase 6-erfaring:

Artefakt	Foreslått grense (revidert #11+)
01-app-brief.md	~2000 ord (review-flagg ved >2500)
02-research-briefs/NN-*.md	~1500 ord (review-flagg ved >2000)
03-architecture-brief.md (full, med 4+ ADR-er)	~2000 ord (review-flagg ved >2500)
05-constraints-brief.md	~3500 ord (review-flagg ved >4500)
06-features-brief.md	~3000 ord for ~13 entries med Voyage-handover-1-struktur (review-flagg ved >4000); skalerer ~200 ord/entry
features/{NN}-{slug}/brief.md (fase 7)	≤500 ord (Voyage strict-mode body)
features/{NN}-{slug}/context.md (fase 7)	≤500 ord
01-interview-transcript.md, 00-context/domain-pack-*.md, examples/*	unntatt

Empirisk lengde-mønster etter S11 (fem fase-briefer skrevet):

Fase	Brief	Ord	Type
1	01-app-brief.md (rev 1)	1830	bredde (intent + scope + 11 features + 4 rabbit holes + 6 antakelser + 4 constraint-signaler)
2	02-research-briefs/01-*	1278	dybde-per-tema (5 kilde-domener)
3	03-architecture-brief.md (rev 0)	1827	dybde (6 ADR-er)
5	05-constraints-brief.md (rev 0)	3497	bredde (ISO 25010 + WCAG + MASVS + plattform + governance + test)
6	06-features-brief.md (rev 0)	2789	bredde (13 entries med fase-7-klar struktur) + grafer + R14

Konsolidert observasjon: bredde-faser (1, 5, 6) bruker ~2000–3500 ord; dybde-faser (2, 3) bruker ~1300–1800 ord. Mønsteret er nå empirisk klart over alle fem faser. Forslag: introdusér [breadth-phase]/[depth-phase]-merking i phase-design-draft.md med differensierte targets, ELLER bare oppdater den per-artefakt-tabellen over.

Foreslått revisjon: Oppdater phase-design-draft.md § Hard lengde-grense ved neste revisjons-runde (etter fase 7 også er kjørt — empirisk grunnlag for å justere features/{NN}-{slug}/brief.md-grensen blir tydeligere da). Lav prioritet — length_review_flag-mekanikken funker som tiltenkt (overskridelse er ærlig markert, ikke skjult).

---

Ny friksjon oppstått i S11

Én ny nummerert friksjon: #13 (over — fase 6-features-brief-lengde-target undervurderer Voyage-handover-1-strukturert backlog).

S11-bekreftelse på eksisterende friksjon:

• #10 + #12 (lengde-grenser): Bekreftes for femte fase-artefakt — fase 6 sprenger #10/#12-tabellens forventede ~1700–2000 ord med ~40 %. Mønsteret etter S11: bredde-faser bruker ~2000–3500 ord, dybde-faser ~1300–1800. Konsolidert i #13-tabellen.
• #11 (OVERRIDE-numbering-konvensjon): Bekreftes som "ingen ny kollisjon i S11" — fase 6 introduserer ingen nye attention-entries med OVERRIDE-N-syntaks. AQ-002 var allerede AQ-NNN-formet (ikke OVERRIDE-N), så ingen friksjon. Bekrefter at S10-friksjon-lærdommen ("nye app-spesifikke beslutninger som ikke deviates pack-defaults skal ikke kalles OVERRIDE-N") ble fulgt i praksis.

Prosess-/spec-merknader fra S11 (ikke nummererte friksjons-poeng):

• Scope-stress-test-disiplinen funket. Per S11-prompt Steg 2: stress-test 11-features-scope mot ~2 mnd appetite med eksplisitt utfall (a/b/c). Mage-estimat-arbeidet (effort-tabell + sum + kalender-vurdering + aksellerasjons-vurdering) avslørte at utfall (a) "scope holder" ikke var realistisk (~85d > 8–9 ukers kalender, selv med vibe-coding ~1.5–2× → 10–12 uker). Utfall (b) drop F-009 ga marginal-pluss på ~10d → ~75d → 9–11 uker → innenfor. Beslutningen ble dokumentert med konkrete tall i § Scope-stress-test, ikke gjemt i prosa. Anbefaling for fase 6-templaten: § Scope-stress-test bør være en navngitt påkrevd seksjon i 06-features-brief.md-templaten (per phase-design-draft.md), ikke ad-hoc — den er en av de viktigste fase 6-beslutningene.
• R14 implementation-readiness-check som integrert i 06-features-brief.md vs separat artefakt. phase-design-draft.md § Implementation-readiness-check sier "operatør-gjennomgang med PASS/CONCERNS/FAIL" og listet det som separat steg etter fase 6. S11 plasserte R14-check som siste seksjon i 06-features-brief.md selv. Argumenter for integrering: (1) sjekken er per-feature og lever best ved siden av feature-entryene, (2) ikke separat artefakt-overhead, (3) hvis CONCERNS/FAIL: kreves backtracking til fase 6 uansett, så ingen verdi i separat fil. Argument mot: separasjon gjør R14-resultatet eksplisitt gate-merket, ikke begravd i feature-briefen. Beslutning: integrert som siste § i 06-features-brief.md for v0; vurderes om separasjon trengs etter fase 7 er kjørt og R14-CONCERNS faktisk håndteres i praksis. Forslag for phase-design-draft.md § Implementation-readiness-check: legg til "R14 kan integreres som siste seksjon i 06-features-brief.md ELLER skrives som separat 06-readiness-check.md — operatør-valg, ingen funksjonell forskjell".
• Fase-overhead-tid (R17): ~1 t aktiv sesjons-tid (operatør-bekreftelse 1 min + lese-fase ~10 min + stress-test ~10 min + brief-skriving ~30 min for 13 entries + state-mekanikk + commit ~5 min + SESSION-LOG/ROADMAP/NEXT-PROMPT + friksjon #13-skriving til slutt ~5 min). Lavere enn S10 (~1 t 20 min) fordi syntese-overflaten er smalere (én artefakt-type, mindre cross-referencing mot eksterne kilder) selv om output-volumet er størst i absolutte ord. Bekrefter at fase 6 er anvendelse-fase (alle inputs er ferdig-syntetiserte fase 1–5-briefer), ikke research/integrasjons-fase (som fase 5 var).
• Token-budsjett: sesjonen holdt seg under 250K. Hovedkontekst-belastning: 5 fase-briefer i full lesing (app, research, architecture, constraints, og nå features), pack-snapshot § Relevante patterns, state.json, friksjon.md, phase-design § Fase 6 + R14 + Felles brief-frontmatter + Hard lengde-grense, SESSION-LOG S9 + S10. Skrivinger: 06-features-brief.md (2789 ord), state.json (~80 linjer), friksjon.md-tilskudd (#13 + denne, ~140 linjer), SESSION-LOG S11-seksjon (kommer), SESSION-ROADMAP-edit (mindre), NEXT-SESSION-PROMPT-S12. Fortsatt under grensen — fase 6 er ikke nær like tungt som S10 fordi syntese-input er mindre (alle inputs er strukturerte briefer) selv om output-volumet er størst absolutt.

---

#14: Fase 7 brief.md + context.md sprenger ≤500-ord-grensen — Voyage strict-mode + materialisert kontekst driver opp omfang

Fase: 7 (observert under S12) Type: design-friksjon (lengde-target — utvider #10/#12/#13-tabellen til fase 7) Observert: 2026-05-13 (S12) — under skriving av features/01-sun-position/brief.md + context.md (første ekte fase 7-kjøring)

Beskrivelse: Friksjon #13-tabellen setter både features/{NN}/brief.md og context.md til ≤500 ord. Faktisk S12-måling:

Fil	Ord	Driver
brief.md (F-001)	743	Voyage strict-mode-frontmatter (8 påkrevde + 4 valgfrie + 9 app-creator-interne felter ≈ 21 linjer) + 3 påkrevde body-seksjoner (Intent/Goal/Success Criteria) + 5 standard-seksjoner (Non-Goals/Constraints/Preferences/NFR/Research Plan/Open Questions) + Metadata + How-to-continue. Success Criteria alene er 6 falsifiserbare entries × ~25 ord = ~150 ord (load-bearing for Voyage --validate og plan-critic).
context.md (F-001)	641	Materialisert upstream (BMAD embedding > linking): Dependencies + Cross-cutting constraints (7 enforce-pekere) + Architecture context (5 ADR-utdrag) + Design-system + Domain-konvensjoner/patterns (2 pattern-utdrag embedded) + Gotchas + Research signals. Hver seksjon er kort, men summen er nødvendig kontekst Voyage-agenten ikke har ambient.
research.md (F-001)	584	Ny artefakt-type (ikke i lengde-tabellen). Holder Research Plan langform inkl. kandidat-tabell, 6 evaluerings-kriterier, beslutnings-prosess, konsekvenser. Splittet ut av brief.md per phase-design-draft § Fase 7 (>100 ord ⇒ separat fil).

Brief.md sprenger ≤500-grensen med ~50 %; context.md med ~28 %. Begge er bevisst-stramme — ingen seksjon kan kuttes uten å miste Voyage-handover-verdi. Success Criteria er det største, men også det Voyage-validatoren faktisk konsumerer. Constraints/Preferences-pekere er minimum-form ("ADR-006: én-linjes-rasjonale") — ren peker uten forklaring gir Voyage-agenten for lite.

Hva som ble gjort i S12: Beholdt overskridelsen, satte ikke length_words/length_review_flag i frontmatter (Voyage-frontmatter har ingen slike felter — app-creator-interne felter kan ikke kollidere med Voyage-validatoren; lengde-flagget logges her i friksjon.md i stedet).

Voyage strict-mode round-trip-test PASS: Mental simulering av /trekplan --brief features/01-sun-position/brief.md mot HANDOVER-CONTRACTS.md § Handover 1: alle 8 påkrevde frontmatter-felter til stede, YAML er flat (ingen nestede dicts), enum-verdier gyldige, state-machine (research_topics > 0 && research_status === "skipped" → påkrevd brief_quality: partial) ikke trigget fordi status er pending, ikke skipped. Alle 3 strict-mode-påkrevde body-seksjoner til stede. Ingen template-gap identifisert — fase 7-templaten produserer Voyage-strict-mode-kompatibel output.

Lærdom for app-creator-designet: Per-artefakt-lengde-tabellen fra #13 må oppdateres med faktisk fase 7-erfaring:

Artefakt	Foreslått grense (revidert #14+)
features/{NN}-{slug}/brief.md (fase 7)	~750 ord (review-flagg ved >1000) — driver: Voyage strict-mode-frontmatter (21 linjer) + 8 body-seksjoner inkl. falsifiserbare Success Criteria
features/{NN}-{slug}/context.md (fase 7)	~650 ord (review-flagg ved >900) — driver: materialisert upstream (BMAD embedding > linking)
features/{NN}-{slug}/research.md (fase 7, valgfri)	~600 ord (ny artefakt-type; review-flagg ved >800)

Empirisk lengde-mønster etter S12 (seks fase-artefakter skrevet):

Fase	Artefakt	Ord	Type
1	01-app-brief.md (rev 1)	1830	bredde
2	02-research-briefs/01-*	1278	dybde
3	03-architecture-brief.md	1827	dybde (6 ADR-er)
5	05-constraints-brief.md	3497	bredde
6	06-features-brief.md	2789	bredde
7	features/01-sun-position/brief.md	743	fokus-per-feature (Voyage strict)
7	features/01-sun-position/context.md	641	materialisert upstream-utdrag
7	features/01-sun-position/research.md	584	research-plan langform (valgfri)

Konsolidert mønster: bredde-faser ~2000–3500 ord, dybde-faser ~1300–1800 ord, fokus-per-feature fase 7-artefakter ~600–750 ord per fil (lavere absolutt enn dybde-faser fordi en feature er smalere enn en hel app-tverrsnitts-brief, men over ≤500-grensen pga Voyage-strict-mode-løftet).

Foreslått revisjon: Oppdater phase-design-draft.md § Hard lengde-grense + tabellen ved neste revisjons-runde (lav prioritet — length_review_flag/friksjon-logg-mekanikken funker; ingen Voyage-validator-failure). Vurder også: skal fase 7-templaten få et ## Length budget-notat som forklarer at brief.md naturlig lander ~700-800 ord pga Voyage strict-mode, slik at forfattere ikke prøver å stramme bort substans?

---

Ny friksjon oppstått i S12

Én ny nummerert friksjon: #14 (over — fase 7 brief.md + context.md sprenger ≤500-grensen; Voyage strict-mode round-trip-test PASS uten template-gap).

S12-bekreftelse på eksisterende friksjon:

• **#5 (features/{NN}-{slug}/-layout og 00-context/-konseptet):** Bekreftet i praksis ved første mappe-materialisering. Layouten holder: brief.md+context.mdobligatoriske +research.mdvalgfri (introdusert som ny artefakt-type i S12 for langform-Research Plan).00-context/domain-pack-ios-app.md-snapshot leveres som forventet input til materialisering i context.md` § Domain-konvensjoner & patterns.
• #10 + #12 + #13 (lengde-grenser): Mønsteret bekreftet for sjette gang. Bredde-/dybde-/fokus-per-feature-typologi er nå empirisk klar over alle 7 fase-artefakt-typer. Konsolidert i #14-tabellen.
• #11 (OVERRIDE-numbering-konvensjon): Ingen ny kollisjon i S12 — AQ-001 lukkes i F-001-brief Research Plan og bruker AQ-NNN-syntaks, ikke OVERRIDE-N. Disiplinen holder.

Prosess-/spec-merknader fra S12 (ikke nummererte friksjons-poeng):

• Voyage strict-mode-templaten produserer kompatibel output første gang. Round-trip-test (mental simulering mot ~/.claude/plugins/marketplaces/ktg-plugin-marketplace/plugins/voyage/docs/HANDOVER-CONTRACTS.md + templates/trekbrief-template.md) PASS uten template-gap. Dette er en kritisk validering — fase 7 er den eneste lag-grensen som krysses ut av app-creator til Voyage, og hvis templaten hadde manglet et felt eller en seksjon ville første F-001-runde med /trekplan --brief avvist. Bekrefter at app-creator's invariant "Voyage-agnostisk: brief.md er bare en velformet Voyage-brief" er holdt. Anbefaling for phase-design-draft.md § Fase 7: marker round-trip-test som [testet S12 — PASS uten template-gap].
• research.md som tredje fase 7-artefakt introdusert i S12 (research-plan langform med kandidat-tabell + kriterier + beslutnings-prosess), ut over brief.md + context.md som phase-design-draft § Fase 7 spec-er. Driver: Research Plan-seksjonen i brief.md ble ~400 ord på første utkast (>100-ord-terskelen prompten satte for splitting). Splittet til research.md; brief.md beholdt ~80-ord ## Research Plan-peker-versjon. Mønsteret er sannsynligvis vanlig for features med åpne AQ-er (F-001 har AQ-001; framtidige features med åpne AQ-er vil møte samme valg). Anbefaling: phase-design-draft.md § Fase 7 nevne research.md eksplisitt som valgfri tredje artefakt, ikke bare "valgfritt research.md/design-ref.md/voyage_run.md"-lista den nå er i.
• AQ-001 closure-mekanikk: AQ-001 (NOAA-pakke vs egen impl) ble formelt lukket i F-001-brief.md § Research Plan + research.md-langform-detaljer, men den endelige beslutningen (pakke valgt vs egen impl) tas først i Voyage /trekresearch-runden. Dette er kontrakt-design: app-creator's fase 7 lukker AQ-en i den forstand at den dokumenterer hvordan den lukkes, men selve research-arbeidet skjer i Voyage. Konsekvens: F-001 Effort: L · Status: brief-pending forblir korrekt; effort-revisjon (L→M ved pakke valgt) skjer etter Voyage-runde og er en framtidig revision-bump på 06-features-brief.md, ikke en S12-handling.
• Fase-overhead-tid (R17): ~50 min aktiv sesjons-tid (operatør-bekreftelse 1 min + lese-fase ~10 min + WebSearch + 3× WebFetch for AQ-001-research ~5 min + brief-skriving ~15 min inkl. ett "for langt" → splitt-til-research.md-rebound ~5 min + context-skriving ~10 min + round-trip-test mental ~2 min + state-mekanikk + commit ~5 min + SESSION-LOG/ROADMAP/NEXT-PROMPT ~10 min). Lavere enn S11 (~1 t) fordi syntese-overflaten er smaler (én feature, ikke 13). Bekrefter at fase 7 er per-feature-anvendelse — smal og fokusert.
• Token-budsjett: sesjonen holdt seg under 250K. Hovedkontekst-belastning: phase-design-draft § Fase 7 + § Hard lengde-grense + § Felles brief-frontmatter, Voyage HANDOVER-CONTRACTS.md § Handover 1 + trekbrief-template.md (rask verifisering), Akashic 06-features-brief.md § F-001 (full), 03-architecture-brief.md § ADR-001/002/004/005/006 + AQ-001, 05-constraints-brief.md § Performance/MASVS/Plattform, 00-context/domain-pack-ios-app.md § Conventions/Gotchas/Patterns, friksjon.md (særlig #5/#10/#11/#13), SESSION-LOG S11. Skrivinger: features/01-sun-position/brief.md (743 ord), context.md (641), research.md (584), state.json oppdatering, friksjon.md +#14 + S12-seksjon, SESSION-LOG S12-seksjon, SESSION-ROADMAP-edit, NEXT-SESSION-PROMPT-S13. Lavest hovedkontekst-belastning siden S8.

---

#15: Fase-til-fase går uten review-gate — operatør kan ikke annotere/godkjenne/avvise fase-output før neste fase starter

Fase: alle (observert under S13, men problemet eksisterer fra S1) Type: prosess-friksjon (kritisk — påvirker hver fase-overgang) Observert: 2026-05-13 (S13) — operatør avbrøt S13 fase 7-runde med "jeg har ikke fått muligheten å gjøre review av ditt forslag til features, det må jeg kunne gjøre med annoteringer. Dette vil kunne gå fram og tilbake noen ganger. F.eks. ville jeg ikke godkjent F-006."

Beskrivelse: phase-design-draft.md beskriver fase-overganger som "produserer artefakt → neste fase leser artefakt" uten et eksplisitt operatør-review-/godkjennings-gate imellom. I praksis betyr det at AI-en kan produsere fase n-output og umiddelbart bygge fase n+1 på toppen, selv om operatøren ville endret/avvist deler av n-output gitt sjansen. Friksjons-utløser i S13: S11 skrev 06-features-brief.md med 13 features (10 funksjonelle + 3 F-T) og R14-PASS-verdict; S12 startet umiddelbart fase 7 og skrev F-001 sun-position-brief; S13 skulle skrive andre fase 7-brief — operatør stoppet med "F-006 ville jeg ikke godkjent". Det betyr backloggen S12 bygget F-001 på toppen av inneholder features operatøren ville endret eller fjernet.

Hva som mangler: Et review-gate-mønster mellom hver fase som er strukturelt analogt med Voyage /trekrevise ("Apply operator-annotated brief/plan/review back into the source artifact with audit trail"). Mønsteret må håndtere:

1. Strukturert annotering — sidecar-fil eller inline-kommentar med fast vokabular (approved / revise / defer / drop) per ankerelement (per feature, per ADR, per constraint, per success-kriterium, …).
2. Iterasjon over flere runder — operatør kan annotere, AI applisere, operatør re-annotere; ikke én-shot-godkjenning. Sesjons-grenser skal overleves (annotasjoner committed til fil, ikke i samtale-tråd).
3. Audit trail — hver revisjon dokumenterer hvilke annotasjoner som drev hvilke endringer (revision: N → N+1 med endringslogg per anker).
4. Status-gate i state.json — fase markeres complete (godkjent + applisert) vs pending-review (artefakt skrevet, men ikke godkjent) vs revision-in-progress (annotasjoner mottatt, applisering pågår). Neste fase kan kun starte når forrige er complete.
5. Konsekvens-håndtering oppstrøms — hvis fase n-review avslører at fase n-1 må endres (f.eks. F-006-droping i fase 6 avslører at app-brief § Omfang #6 må re-revideres): operatør får eksplisitt valg mellom backtrack til fase n-1 eller registrere endringen som revision-pending der.

Hva som ble gjort i S13: S13 fase 7-skriving pauset umiddelbart etter operatør-stopp. Friksjon #15 logget. phase-design-draft.md skal oppdateres med review-gate-mønster (eget delsteg av S13). Review-mal for 06-features-brief.md skal lages i Akashic-repoet som første anvendelse av mønsteret. F-001 brief.md fra S12 må inkluderes i samme review-runde siden den ble skrevet uten review-gate.

Lærdom for app-creator-designet: Review-gate er hard-obligatorisk mellom alle fase-overganger, ikke valgfri. Dette er en grunnleggende design-mangel i phase-design-draft.md — pipelinen er strukturert som AI-prosessering, ikke som operatør-styrt syntese. Mønsteret arvet fra Voyage /trekbrief//trekplan//trekreview//trekrevise-flyten er nettopp at hver overgang er en operatør-handling. App-creator må adoptere samme strukturelle disiplin per fase.

Anvendelse på allerede-fullførte faser: Fase 1 (app-brief), fase 2 (research-brief), fase 3 (architecture-brief), fase 5 (constraints-brief), fase 6 (features-brief), fase 7 F-001 (sun-position-brief) ble alle skrevet uten review-gate. Operatør avgjør per artefakt om retroaktiv review er nødvendig:

• Fase 6 (features-brief) — primær drivende for S13-pause; review er obligatorisk nå (operatør har eksplisitt sagt "F-006 ville jeg ikke godkjent").
• Fase 7 F-001 — review er obligatorisk nå siden brief.md ble skrevet på toppen av u-validert fase 6. Hvis fase 6-review endrer/dropper F-001: F-001-brief må revideres eller slettes.
• Fase 1, 2, 3, 5 — review er anbefalt men ikke blokkerende for S13. Hvis fase 6-review avslører at en oppstrøms-fase også må revideres: backtrack håndteres da.

Foreslått revisjon (gjøres i S13):

1. phase-design-draft.md — ny § "Review-gate mellom faser" som spec-er mønsteret (vokabular, sidecar-format, applisering, audit trail, state.json-statuser). Hver fase-seksjon (§ Fase 1..7) får eksplisitt "Review-gate"-understeg som peker til den nye seksjonen.
2. Sidecar-format: <artefakt>.review.md ved siden av hovedartefakten (f.eks. 06-features-brief.review.md). Strukturert med én entry per anker (feature, ADR, constraint, success-kriterium) + fast vokabular.
3. State.json-utvidelse: phase_status.<n> kan være string (eksisterende) ELLER objekt {status: "complete|pending-review|revision-in-progress", revision: N, review_at: "<dato>", reviewer: "<navn>"}.
4. Friksjons-flagg: review_pending som attention-type i state.json.attention[] med peker til sidecar-fil.

Drahjelp fra Voyage-mønster: ~/.claude/plugins/marketplaces/ktg-plugin-marketplace/plugins/voyage/commands/trekrevise.md (kommando-spec) og voyage/docs/HANDOVER-CONTRACTS.md § "operatør-annotert brief/plan/review back into source artifact" — bør leses og adopteres strukturelt. App-creator implementerer ikke trekrevise-kommando, men adopterer mønsteret (anchored comments + canonical annotation_digest + revision in-place).

Fase-overhead-implikasjon: Hvert fase-overgang får +1 review-runde (estimert 20-40 min operatør-tid + 10-20 min applisering-tid). For Akashic: 6 ferdige fase-artefakter (1, 2, 3, 5, 6, 7 F-001) → ~2-3 t retroaktiv review-arbeid hvis alle skal gjennomgås. Fremover: hver ny fase 7-feature får én review-gate (~30-60 min ekstra per feature × 12 gjenværende = 6-12 t). Dette er reell kost — men feilen av å hoppe over review (bygge på u-validert backlog) er større.

---

Ny friksjon oppstått i S13

Én ny nummerert friksjon: #15 (over — fase-til-fase går uten review-gate; kritisk prosess-mangel som påvirker alle fase-overganger).

S13-bekreftelse på eksisterende friksjon:

• Ikke aktuelt — S13 ble avbrutt før selve fase 7-skriving startet. Ingen lengde-måling, ingen template-test, ingen numbering-kollisjon-sjekk.

Prosess-/spec-merknader fra S13 (ikke nummererte friksjons-poeng):

• S13-omfang skiftet fra "skriv andre fase 7-brief" til "implementér review-gate-mønster". Operatør-stopp er ikke en feil i S13-prompten — prompten antok at fase 6-output var godkjent fordi fasen var markert complete i state.json. Friksjon #15 viser at "complete" i phase_status ikke betyr "operatør-godkjent", bare "AI-skrevet". State.json-vokabular må skjerpes (se "Foreslått revisjon" punkt 3 over).
• Token-budsjett: ikke nær 250K-grensen. S13 har dimensjon "design-revisjon", ikke "fase-artefakt-skriving" — vesentlig mindre kontekst.
• Opus-direktiv (operatør S12): "bruk Opus for alt" gjelder fortsatt for S13's design-revisjon-arbeid. Ingen subagenter spawnes i S13 — alt arbeid skjer i hovedkontekst (les + skriv + reasoning er mid-vekt).

---