# 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. --- ## #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.md` obligatoriske + `research.md` valgfri (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:** `.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.` kan være string (eksisterende) ELLER objekt `{status: "complete|pending-review|revision-in-progress", revision: N, review_at: "", reviewer: ""}`. 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). **Adopsjon i S13 (oppdatert 2026-05-14):** Etter at operatør pekte på at Voyage `scripts/annotate.mjs` (921 linjer, claude-code-100x-mønster — pencil-toggle, Fiks/Endre/Spørsmål-intent, popover-form, localStorage-persistens, Copy Prompt-eksport) **allerede løser** review-gate-mekanikken: forkastet egen-spec'd sidecar-format (`.review.md` med approved/revise/defer/drop/question-vokabular per anker), adopterte Voyage `annotate.mjs` 1:1 i stedet. Konsekvens for `phase-design-draft.md` § Cross-cutting: Review-gate: forenklet fra fem-tier fast taksonomi til tre-tier fri-form intent (Fiks/Endre/Spørsmål med fri kommentar). Voyage-mønsteret matcher bedre hvordan operatør faktisk tenker — "drop F-006" er en Endre-annotasjon med kommentar "drop fra v1", ikke en separat `drop`-status. Generering: `node ~/.claude/.../voyage/scripts/annotate.mjs ` produserer `.html` ved siden av kilde-fila. HTML-filer er gitignored i Akashic-repoet (regenererbare, annotasjoner lever i localStorage). Dette er konkret anvendelse av app-creator-invarianten "Voyage v4.3 Plugin Playground er arkitektonisk forfar — app-creator gjenbruker disse 1:1" fra `app-creator/CLAUDE.md`. **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). --- ## #16: Review-gate er formelt aktivt men innholdsmessig passivt — retroaktiv 0-annotasjons-review godkjente en faktafeil **Fase:** 7 (observert S14e, etterregistrert 2026-08-10) **Type:** mekanikk-friksjon **Observert:** 2026-05-14 (S14e) **Beskrivelse:** #15 innførte review-gate (Voyage `annotate.mjs`-mønsteret) som hard-obligatorisk mellom faseoverganger. Mekanismen ble anvendt retroaktivt på `features/01-sun-position/` (F-001-brief skrevet i S12, før gaten fantes) — men review-runden mottok **0 annotasjoner** (`review_gate_history[1].annotations_received: 0`) og ble likevel markert `status: complete` i `state.json`. Gaten sjekker *at* en review-runde fant sted, ikke *hvor grundig* den var. Konsekvens: F-001 brief.md gikk videre til Voyage-klar status (rev 0→1 via AQ-004-arbeidet) med en feil i vindu-reglene urørt — Sadhguru Surya Kriya-tradisjonen bruker 3 tidspunkter (sunrise, 30°-stigende, sunset), men brief.md rev 0–3 spesifiserte 4. Feilen ble ikke fanget av review-gaten (som passerte med 0 annotasjoner), men av at operatøren **aktivt ba om verifisering** i S14e — en ad hoc-handling utenfor gate-mekanikken. WebSearch bekreftet 3-punkts-tradisjonen; brief rev 3→4 og research rev 3→4 rettet feilen (jf. Akashic `state.json.session.log` S14e: "KRITISK FIX av F-001 vindu-regler... Konsekvens: case A strict = 1/3 vindu (kveld), ikke 3 reduserte"). **Hva som mangler:** Review-gaten (§ "Review-gate mellom faser", innført via #15) har et fullført/ufullført-vokabular (`annotations_received`, `status: complete`), men intet grundighets-signal. En 0-annotasjons-runde og en 12-annotasjons-runde er strukturelt identiske i `state.json` — begge blir `complete`. Det finnes ingen mekanisme som skiller "operatør leste og fant ingenting å endre" fra "operatør scrollet forbi" eller "operatør stolte blindt på AI-produsert innhold". Domenefakta (som Surya Kriya-tradisjonens 3 vs 4 tidspunkter) er ikke noe review-gate-mønsteret er designet for å fange — det fanger *prosess*-avvik (feil rekkefølge, manglende godkjenning), ikke *faktuelle* avvik i innholdet selv. **Foreslått revisjon:** En **aktiv gate-sjekkliste** — operatøren bekrefter eksplisitt (ikke bare stilltiende ved at runden settes til `complete`) et lite sett spørsmål før en 0-annotasjons-review kan lukkes: (1) Er hele artefakten lest, ikke skummet? (2) Er domenepåstander (presedens/regler/tall AI-en har lagt til grunn) sjekket mot en kilde utenfor AI-ens egen skriving? (3) Er minst ett element i artefakten aktivt vurdert for annotering, selv om utfallet ble "ingen endring nødvendig"? Dette svarer direkte på hva #15s gate-mønster mangler i dag: en 0-annotasjons-runde og en 12-annotasjons-runde er strukturelt identiske i `state.json` (`status: complete` uansett) — sjekklisten gjør den stilltiende antakelsen ("gaten passerte, altså ble det sett") til en eksplisitt handling. Hedge: skulle sjekklisten vise seg tung å håndheve i praksis, kan et enklere `reviewed_actively: true/false`-flagg operatøren selv setter vurderes som alternativ — men sjekklisten er hovedforslaget. --- ## #17: Revisjonslogg-eksplosjon — brief.md vokste fra 743 til 4523 ord over 6 revisjoner, drevet av akkumulerende revisjonslogg-seksjon **Fase:** 7 (observert S14b–S14g, etterregistrert 2026-08-10) **Type:** design-friksjon **Observert:** 2026-05-14 (S14b gjennom S14g) **Beskrivelse:** `features/01-sun-position/brief.md` var 743 ord ved rev 0 (S12, jf. #14). Over seks revisjonsrunder innenfor én dag (S14b: rev 0→1, S14c: rev 1→2, S14d: rev 2→3, S14e: rev 3→4, S14f: rev 4→5, S14g: rev 5→6 — hver drevet av AQ-004-iterasjonen: polare edge cases → case-taksonomi → skip-dag-fallback → vindu-regel-fix → pragmatisk hybrid → lås) vokste filen til 4523 ord (verifisert `wc -w`, 2026-08-10) — en 6× økning. Drivkraften er ikke innholdsvekst i selve brief-en (task/Goal/Preferences/Success Criteria), men at `## Revisjons-logg`-seksjonen akkumulerer én fullstendig "Endringer i brief.md (rev N → N+1)"-oppføring **per runde, uten trimming eller sammendrag** — hver oppføring gjentar kontekst fra forrige (jf. `grep -n "Endringer i brief.md" features/01-sun-position/brief.md` i Akashic: 6 separate blokker). Dette kobler til #10/#12/#13/#14-mønsteret (bredde- vs dybde- vs fokus-per-feature-lengdegrense) men er et **nytt** friksjonsmønster: ikke lengden på *innholdet*, men lengden på *historikken om innholdet*, som vokser ubegrenset med antall review-gate-runder. **Kobling til A2 — presisert:** Denne friksjonen kobler til A2 (revisjonslogg-plassering, 2026-08-10), men motsatt av hva en overflatisk lesning skulle tilsi. A2 besluttet at revisjonslogg **flyttes ut** av kilde-artefakten til en append-only sidecar (`.revisions.md`; for fase 7: `features/{NN}-{slug}/revisions.md`) og teller uttrykkelig **ikke** mot lengdegrensen — nettopp fordi historikk ikke skal ha tak: «Sidecaren er ikke unntatt fordi den er uviktig, men fordi den er append-only per definisjon: å sette tak på den ville bety å slette historikk» (`phase-design-draft.md`, A2-beslutning 2026-08-10). F-001s 743→4523-ord-vekst i S14b–S14g brukte den **eldre** mekanikken — revisjonslogg embedded i `brief.md` selv — fordi A2 ikke fantes ennå da veksten skjedde. Denne entryen er derfor ikke et åpent problem A2 lot stå, men **empirisk bevis for hvorfor A2s beslutning er riktig**: den observerte veksten er nøyaktig symptomet en uncapped-i-artefakten revisjonslogg produserer. **Foreslått revisjon:** Ingen ny revisjon foreslås her — A2 har allerede løst dette for fase 1–7-artefakter generelt (sidecar, uncapped, teller ikke mot lengdegrensen). Gjenstående fakta, utenfor A4s scope å foreslå løsning på: `akashic-intelligence/features/01-sun-position/brief.md` bærer fortsatt den gamle embedded-revisjonsloggen fra før A2 eksisterte — filen er ikke migrert til sidecar-mønsteret. Om og når denne migreringen skal skje er en operatør-/B-fase-beslutning. --- ## #18: Versjonsdisiplin-brudd — pack-endring committet uten versjonsbump eller changelog-entry **Fase:** cross-cutting / domain-pack-vedlikehold (observert S15, etterregistrert 2026-08-10) **Type:** kontrakt-friksjon **Observert:** 2026-05-14 (S15) **Beskrivelse:** Under S15 (Xcode-bootstrap) ble `domain-packs/ios-app/`-pakken utvidet med MCP-toolchain-gotchas (XcodeBuildMCPs `mcp`-subkommando + mcpbridge-krav om aktivt workspace-prosjekt) i commit `b59928b` — men pakkens `version`-felt i `pack.json` ble **ikke** bumpet, og ingen changelog-entry ble skrevet for endringen. `domain-pack-spec.md` § D5 krever patch-bump + changelog-entry for denne typen tillegg (nytt pattern-innhold, ikke et brytende skjema-endring). Bruddet ble stående umerket til A3 (2026-08-10, tre måneder senere) oppdaget det ved premiss-verifisering (`git log -- domain-packs/ios-app/` mot manifestert `version`-felt) og rettet det (`version` 0.2.0 → 0.2.1 + changelog-entry, commit `4f152c7`). I mellomtiden hadde Akashic-instansen konsumert `ios-app@0.2.0`-pinnen mens det faktiske pack-innholdet allerede var 0.2.1-verdig — en **stille skjema-drift**: konsumenten pekte på en versjon som ikke lenger representerte hva filene faktisk inneholdt. **Kobling til A3:** A3s app-creator-halvdel (committet `4f152c7`) rettet symptomet (versjonsnummer + changelog). Akashic-halvdelen (re-materialisering av snapshot + pin-oppdatering til `ios-app@0.2.1`) er sendt som coord-melding og utestående ved etterregistrering av denne entryen (2026-08-10) — se STATE.md § Åpne tråder. **Hva som mangler:** Ingen mekanisk gate hindrer at en pack-endrende commit går inn uten tilhørende versjonsbump. `domain-pack-spec.md` § D5 er en *prosa*-regel, ikke en håndhevet en — den forutsetter at forfatteren husker å følge den midt i en Xcode-bootstrap-sesjon med mye annet i fokus (S15 var en tung miljø-/verktøy-sesjon, ikke en pack-vedlikeholdssesjon; pack-endringen var et sideprodukt av læring fanget "på farten"). **Foreslått revisjon:** Vurder en lettvekts pack-lint-sjekk (nevnt som mulig D8 i masterplanen) som en pre-commit- eller pre-materialiserings-sjekk: diff `domain-packs//` mot siste tag/manifestert versjon, og flagg (ikke blokker — dette er solo-fork-and-own, ingen CI) hvis innhold har endret seg uten at `version` fulgte med. Enklere alternativ uten ny tooling: `phase-design-draft.md` eller `domain-pack-spec.md` § D5 legger til en eksplisitt sjekkliste-linje i pre-pipeline/fase-avslutning: "endret du noe under `domain-packs/`? bump `version` + changelog nå, ikke senere." --- ## Ny friksjon etterregistrert i A4 (2026-08-10) Tre nummererte friksjons-entries etterregistrert per masterplanens § A4-scope-grense (kun etterregistrering av allerede-observert friksjon fra Akashic `state.json` S14–S15-loggen og git-historikk; ingen nye design-forslag utover det kildene bærer): - **#16** (over — passiv-gate-svikt: retroaktiv 0-annotasjons-review i S14 markerte `complete` uten at noen faktisk fant den 4-punkts-vindu-regel-feilen review-gaten var ment å fange; operatørens aktive spørring i S14e fanget den i stedet. Foreslått revisjon: aktiv gate-sjekkliste, per masterplanens ordlyd). - **#17** (over — revisjonslogg-eksplosjon: `features/01-sun-position/brief.md` 743→4523 ord over rev 0→6 i S14b–S14g, drevet av embedded `## Revisjons-logg` uten tak — den *eldre* mekanikken, fra før A2 flyttet revisjonslogg til uncapped sidecar. Entryen er bevis for hvorfor A2s beslutning er riktig, ikke et åpent problem den lot stå). - **#18** (over — versjonsdisiplin-brudd: `ios-app`-pack endret i `b59928b` (S15) uten versjonsbump/changelog, stod urettet i tre måneder til A3 fant og rettet det i `4f152c7`). Alle tre er etterregistrert 2026-08-10 — betydelig etter observasjonstidspunktet (S14–S15, 2026-05-14) — per R-08s funn om at friksjonsloggen lå åtte sesjoner bak. Ingen S16-kjøring fant sted; dette er en dedikert etterregistrerings-sesjon (A4), ikke en ny prototype-fase-sesjon. --- ## #19: Snapshot-overrides kan drive fra pack-overrides.md uavhengig av pack-versjon — en versjonssammenligning fanger det ikke **Fase:** cross-cutting / domain-pack-vedlikehold (observert og rettet av Akashic-instansen 2026-08-11, under A3s Akashic-halvdel) **Type:** kontrakt-friksjon **Observert:** 2026-08-11 (A3-eksekvering, `akashic-intelligence` commit `bd38b23`) **Beskrivelse:** A3 (pack-versjonsreparasjon) instruerte Akashic om å re-materialisere `00-context/domain-pack-ios-app.md`-snapshotet fra `ios-app@0.2.2` og — som steg 4 — «kontrollere at pack-overrides fortsatt gjelder mot nytt snapshot». Under den kontrollen oppdaget Akashic at snapshotets egne override-markører (inline `[OVERRIDE-N]`-blokker + Overrides-anvendt-tabellen) hadde **driftet fra `00-context/pack-overrides.md`, uavhengig av at pack-versjonen (0.1.0) ikke hadde endret seg**: OVERRIDE-1 (deployment-target, iOS 17-baseline) og OVERRIDE-2 (App Privacy Details, "Data Not Collected") sto begge som «ÅPEN» i snapshotet, mens de hadde vært «LUKKET» i `pack-overrides.md` siden 2026-05-13 (ADR-001 og S10-fase 5). Snapshotet var altså aldri re-materialisert siden sin første skriving (2026-05-13) — verken pack-bumps (0.1.0→0.2.0→0.2.1→0.2.2) eller override-lukkinger i mellomtiden hadde forplantet seg dit. Dette er en **ny og strukturelt distinkt friksjon fra #18**: #18 handlet om at PACK-en endret seg uten versjonsbump; #19 handler om at et per-app-dokument (`pack-overrides.md`, som ikke er en del av pakken i det hele tatt) endret seg uten at snapshotet — som er ment å reflektere BEGGE kilder — fulgte med. En ren versjonssammenligning (`pack.json` X → Y) kan aldri fange dette, fordi `pack-overrides.md` ikke har noen versjon å sammenligne mot. Snapshotet har med andre ord to uavhengige stalenesskilder (pack-innhold og override-dokument), men mekanikken (`domain-pack-spec.md:184-192`) og A3s formulering («kontroller at overrides fortsatt gjelder») adresserer eksplisitt kun den ene. **Relatert funn samme commit:** snapshotets `Pack-kilde`-felt pekte på en slettet plugin-marketplace-sti (`~/.claude/plugins/marketplaces/ktg-privat/plugins/app-creator/domain-packs/ios-app/`, verifisert `ls -d` → finnes ikke) i stedet for pakkens faktiske plassering (`/Users/ktg/repos/app-creator/domain-packs/ios-app/`). Trolig fordi mekanikken skriver materialiseringstidspunktets sti verbatim uten normalisering — samme dødlenke vil sannsynligvis gjenoppstå ved neste flytting av pakken, uavhengig av override-problemet over. Ikke undersøkt videre i denne omgang. **Hva som mangler:** `domain-pack-spec.md` § D5s materialiserings-mekanikk (linje 184-192) beskriver snapshotet som en funksjon av pack-versjonen alene. Den beskriver ikke at snapshotet også skal re-speile `pack-overrides.md`s gjeldende status, og gir ingen retningslinje for NÅR en override-lukking (uavhengig av pack-bump) skal trigge en snapshot-oppdatering. Den nære årsaken er app-creators egen A3-ordlyd i `docs/masterplan.md` («kontroller at pack-overrides fortsatt gjelder mot nytt snapshot») — den sier «gjelder», ikke «gjengis korrekt», og dekker dermed ikke tilfellet der reglene fortsatt er gyldige men snapshotets *visning* av dem har driftet. Feilen ligger i instruksjonen app-creator skrev, ikke i noe Akashic gjorde galt. **Foreslått revisjon:** To mulige retninger, ingen valgt her (utenfor denne loggens scope å beslutte): - (A) Utvid steg 4s ordlyd i A3-typen oppgaver fra «kontroller at overrides fortsatt gjelder» til eksplisitt «kontroller OGSÅ at snapshotet *gjengir* override-status korrekt (åpen/lukket), ikke bare at reglene fortsatt anvender seg» — en presisering av kontrollens innhold, ikke av mekanikken. - (B) Knytt snapshot-re-materialisering til to uavhengige triggere i stedet for én: pack-versjon-bump (eksisterende) OG override-status-endring i `pack-overrides.md` (ny). Krever at spec-en definerer et "sist synket mot overrides"-tidsstempel i snapshotet, adskilt fra "sist synket mot pack"-tidsstempelet. - Pack-kilde-dødlenken (relatert funn over) peker mot en tredje, uavhengig fiks: normaliser kilde-stien til en relativ eller symbolsk referanse (f.eks. `domain-packs/{name}/` relativt til app-creator-repo-roten) i stedet for en absolutt sti på materialiseringstidspunktet. Kandidat for D-fasen (domain-pack-spec.md-revisjon) eller B2 (sammen med de andre revision-pending-postene). Ikke besluttet her. --- ## #20: B1s faktiske kjøring diskonterer A5s brief_version 2.2-antakelse — F-001 kjørte på 2.0 **Fase:** B (round-trip/prototype) **Type:** nøkkelantakelse-brudd **Observert:** 2026-08-11/12 (S16–S18 i akashic-intelligence), ground-truth-verifisert herfra 2026-08-13 **Beskrivelse:** Masterplanens B1 § Fremgangsmåte steg 1 forutsatte «Sesjon: oppgrader F-001 til 2.2 per A5 (framing, TL;DR, phase_signals, korrigert How-to-continue)» som forutgående steg før operatørens Voyage-kjøring. Ground truth (`akashic-intelligence/features/01-sun-position/brief.md`, lest direkte 2026-08-13): `brief_version: "2.0"` står fortsatt ved `revision: 10`, etter at `/trekresearch` (AQ-001, commit `e6b5890`) og `/trekplan` (rev 1.7 → Fase 9 REPLAN 54/100 → restrukturert rev 2.0, commits `b41e241`/`89ea1ed`) allerede har kjørt. 2.2-oppgraderingssteget ble aldri utført — verken i app-creator eller i Akashic. B1s Nøkkelantakelse (a) i masterplanen, «2.2-brief passerer strict», er dermed **ikke** testet av den faktiske kjøringen: Voyage aksepterte en 2.0-brief (trolig N-1-kompatibilitet), ikke en 2.2-brief. A5-designet (framing-avledning, TL;DR-generering, phase_signals-strategi) står følgelig fortsatt uverifisert mot en reell kjøring, selv etter at B1 i praksis har produsert både research og en (replanned) plan. **Kobling:** Dette oppdages via samme premiss-verifiseringsdisiplin som fant #19s baseline-feil — STATE.md/masterplanens forventning («B1 er ren venting på operatør») var allerede forbigått av faktisk fremdrift i Akashic (S16→S18) uten at det var kommunisert via coord-melding. **Foreslått revisjon:** Når B1 formelt dokumenteres (masterplan § B1 steg 3, når Akashics Fase 9-review + evt. `/trekexecute` er avklart), merk eksplisitt at Nøkkelantakelse (a) forblir **uverifisert av den kjøringen som faktisk skjedde**. Ingen fiks foreslås herfra — avgjøres i B2: enten en lettvekts 2.0→2.2-oppgradering av F-001s eksisterende brief (uten å re-kjøre research/plan), eller utsett 2.2-verifisering til neste feature-brief skrives fra bunnen på 2.2-malen. --- ## #21: A5s `voyage/`-underkatalog-konvensjon er ikke det B1 faktisk brukte — Akashics egen drift-innvending rammer A5 symmetrisk **Fase:** B / A5-revisjonskandidat **Type:** design-friksjon (åpent spørsmål, ingen retning valgt) **Observert:** 2026-08-11 (akashic-intelligence commit `e662735`, koordinert til app-creator samme kveld) — kryssjekket mot A5 (commit `a96b3a9`, samme dag 6 timer tidligere) 2026-08-13 **Beskrivelse:** A5 (2026-08-11 12:55) formaliserte `project_dir`-konvensjonen for § Fase 7 til `features/{NN}-{slug}/voyage/`, med et eksplisitt materialiseringssteg (`mkdir -p features/{NN}-{slug}/voyage/ && cp features/{NN}-{slug}/brief.md features/{NN}-{slug}/voyage/brief.md`) for å holde Voyages egne artefakter atskilt fra app-creators. Samme dag, 6 timer senere (19:55), meldte Akashic via coord at F-001s eksisterende `project_dir` (`.claude/projects/2026-05-13-sun-position/`) var en død peker — uvitende om at A5 allerede hadde korrigert § Fase 7-malen (meldingen var skrevet mot en STATE.md-forståelse som ikke inkluderte A5 ennå). Akashic rettet sin egen fil uavhengig til `features/01-sun-position/` — **uten** `/voyage/`-underkatalogen — og begrunnet valget eksplisitt: å materialisere til en separat sti ville krevd kopi eller symlenke av `brief.md`, «nettopp den drift-klassen A3 brukte en økt på å rydde» (to brief-filer for samme feature). Ground truth (2026-08-13): F-001s faktiske Voyage-artefakter (`research/`, `plan.md`) ligger i `features/01-sun-position/` direkte — A5s `voyage/`-segregering ble aldri brukt i den ene reelle round-tripen som har kjørt. Akashics kopi-drift-innvending rammer symmetrisk A5s egen mekanikk, som også foreskriver nøyaktig én kopi-operasjon av `brief.md`. **Foreslått revisjon:** To retninger, ingen valgt her: - (A) Behold A5s `voyage/`-segregering; bring F-001 i samsvar retroaktivt (og la fremtidige briefer følge A5 fra start) — krever at kopi-drift-innvendingen adresseres eksplisitt (f.eks. symlink i stedet for kopi, eller en dokumentert regel om at `brief.md` aldri redigeres etter kopiering til `voyage/`). - (B) Dropp `voyage/`-underkatalogen; standardiser på Akashics faktiske, allerede fungerende mønster (`features/{NN}-{slug}/` direkte som `project_dir`, samme mappe som `brief.md`/`context.md`) — enklere og empirisk bevist, men lar Voyages artefakter blande seg med app-creators egne i samme katalog. Kandidat for B2 eller D-fasen (§ Fase 7-revisjon). **Ikke besluttet her — § Fase 7 er ikke re-åpnet i denne sesjonen.** ---