research(app-creator): thread C+D+E — domain-packs, feature-artefakter, contrarian

S3 av flersesjons-design-arbeidet drevet av Akashic-prototypen.
- C: dekomponering av kunnskaps-bunt i 8 komponenter; format/aktivering/versjonering; failure modes fra Cursor/ESLint/Yeoman-erfaring; forslag til domain-pack-spec.md
- D: Voyages faktiske brief-kontrakt (Handover 1, brief_version 2.0) lest fra kildekode + per-feature-artefakt-anatomi (Shape Up/Linear/Jira/GitHub/BMAD/INVEST); features/{NN}/-layout med brief.md+context.md
- E: contrarian-case mot 7-fase-pipelinen (YAGNI, BDUF, spec-drift, discovery-teater, tracer-bullet); fase-sårbarhets-rangering; 7 anti-seremoni-grep
- friksjon #8 lagt til (pipeline antar full-pipeline-as-default; tilsier brief-first); #7 oppdatert med S3-bekreftelse

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

prototype-run/friksjon.md

@@ -120,4 +120,18 @@ Eventuelt: aksepter at operatør gir kvaliteter, og gjør AI-foreslått-features
 
 **Foreslått revisjon (avgjøres S4-syntese / S5):** Tre kandidater, ikke gjensidig utelukkende: (a) dedikert "Fase 5b — Store readiness" ELLER obligatorisk submission-checklist appendert til fase 5; (b) test-strategi-artefakt innenfor fase 6 (backlogen driver test-scope) eller en fase 3b avledet fra arkitektur; (c) eksplisitt avklaring av release/ops-grensen — hvilke pre-build-beslutninger eier en fase, hvilke er eksplisitt operatørens ansvar utenfor app-creator. **Trolig reneste løsning:** la `domain-pack`-konseptet bære standard-kunnskapen — en `ios-app`-domain-pack inneholder MASVS-checklist, privacy-manifest-mal, App Store-submission-checklist, WCAG-2.2-AA-checklist — slik at fase 5 (og fase 3/4) konsumerer domene-spesifikk standard-kunnskap i stedet for å gjenoppfinne den per app. Utforskes i thread C (S3), settes i `domain-pack-spec.md` (S5). Se `research/B-app-definition.md` § "Kritiske gap".
 
+**S3-bekreftelse (2026-05-11):** Thread C (domain-packs) dekomponerte en moden kunnskaps-bunt i 8 komponenter; checklists + guardrails (App Store-submission-checklist, MASVS 2.1, WCAG 2.2, privacy-manifest-mal) er nettopp det en `ios-app`-pack bærer. Beslutning bekreftet som riktig retning — `domain-pack-spec.md` skrives i S5 med komponent-liste, `pack.json`-format, eksplisitt-fil-sti-lasting + materialisert snapshot i `00-context/`, semver-uformell versjonering med per-app `pack-overrides.md` som escape hatch. Se `research/C-domain-packs.md`.
+
+---
+
+## #8: Pipeline-designet antar "full pipeline" som default — solo-dev-bruk + contrarian-research tilsier "brief-first, faser som opt-in"
+
+**Fase:** cross-cutting
+**Type:** design-friksjon
+**Observert:** 2026-05-11 (via design-research thread E, ikke via Akashic-kjøring direkte — men Akashic ER hvorfor researchen ble gjort, og Akashic er eksplisitt "i praksis en liten app … først og fremst for meg selv", som er nøyaktig profilen contrarian-kritikken rammer)
+
+**Beskrivelse:** `phase-design-draft.md` presenterer 7-fase-flyten som standard-løypa; "fase 2 valgfri" og "lineær med backtracking" er de eneste lettvekt-ventilene. Thread E (YAGNI, BDUF-kritikk, Royce' opprinnelige paper var en *kritikk* av sekvensiell flyt, spec-drift som strukturell uunngåelighet, discovery-/PRD-teater, tracer-bullet/walking-skeleton som alternativ) argumenterer at for en solo-dev som bygger en liten app for seg selv er koordineringsgevinsten ved 7 sekvensielle artefakter ~null — faser er koordineringsverktøy mellom folk som ikke deler samme hjerne. Mest sårbare faser rangert: (1) fase 4 designsystem — ren YAGNI-brudd, bør trigge på *bruk* (etter første Voyage-UI-komponenter) ikke *plan*; (2) fase 5 constraints — kan sjekkes just-in-time og bæres av domain-pack-checklists; (3) fase 1 intervju — å intervjue seg selv er rituell nedskriving, ikke discovery. Unntak som *taler for* eksternalisering: thread A's P3 (AI-kontekst degraderer over sesjoner) — men det gjelder de artefaktene Voyage faktisk konsumerer, ikke nødvendigvis alle syv.
+
+**Foreslått revisjon (avgjøres S4-syntese / S5):** (a) Innfør en eksplisitt "rapid mode" / "sketch brief"-sti — konsept → minimal-men-gyldig app-brief inline → fase 7 feature-brief, uten å passere 2-6; den fulle pipelinen blir eskalering, ikke default. (b) Faser skippbare med eksplisitt én-setnings-begrunnelse loggført i `state.json` (ikke bare "valgfri"). (c) Hard lengde-grense per fase-artefakt (≤500 ord / én skjerm der mulig) — lengde er sterkeste seremoni-signalet. (d) Arkitektur-fasen produserer *åpne spørsmål som lukkes etterpå*, ikke en decisions-log skrevet før koden (decisions-log før kode = grunnlag for spec-drift). (e) Legg til i prototype-protokollen: mål faktisk tid brukt per fase i Akashic-kjøringen; en fase som tar timer og produserer en artefakt ingen Voyage-brief refererer = bevist seremoni. NB: dette *skjerper* thread A's takeaway ("strukturen er solid, men risikoen er at den blir for tung") til "risikoen er ikke bare for tung — det er feil default-retning". Se `research/E-contrarian.md`.
+
 ---

prototype-run/research/C-domain-packs.md

@@ -0,0 +1,130 @@
+# Thread C — Domain-pack-dokumentasjon: hva er det MER enn en skill?
+
+**Sesjon:** S3 (2026-05-11)
+**Metode:** Voyage-research — `voyage:docs-researcher` (autoritative kilder) + `voyage:community-researcher` (erfaringsrapporter), begge Sonnet, parallelt. Syntese skrevet i hovedkontekst.
+**Confidence:** High på komponent-dekomponeringen (samme 6-8 komponenter gjenkommer på tvers av 6 uavhengige systemfamilier). High på failure modes (konsistente, godt dokumenterte erfaringsrapporter). Medium på den konkrete `pack.json`-skissen (design-forslag, ikke observert praksis — låses i S5).
+
+---
+
+## 1. Hva en moden "kunnskaps-bunt" består av — dekomponert
+
+En domain pack i app-creator er en gjenbrukbar kunnskaps-bunt fasene 1/3-7 konsumerer for å realisere en app i et bestemt domene. En Anthropic-skill (SKILL.md + progressive disclosure + `references/`) er **én del** av dette. Research på tvers av seks systemfamilier — Cursor rules, GitHub Copilot custom instructions, Anthropic Agent Skills, scaffolding-verktøy (Yeoman/Cookiecutter/`create-*`), conventions-as-code (ESLint/Prettier/tsconfig shareable configs, EditorConfig), og enterprise landing zones / well-architected frameworks (Azure CAF, AWS WAF) — viser at en moden kunnskaps-bunt har **8 komponent-typer**, hvorav 6 gjenkommer pålitelig:
+
+| # | Komponent | Hva det er | Hvor det dukker opp i prior art |
+|---|-----------|-----------|--------------------------------|
+| 1 | **Conventions** | Forfatter-regler og stilbeslutninger for domenet | Overalt: ESLint-rule-sett, Cursor `alwaysApply`-regler, Copilot `copilot-instructions.md`, Azure-policy-as-code |
+| 2 | **Patterns** | Gjenbrukbare løsnings-former | ESLint shareable configs (koherent stil-pakke), skills' SKILL.md-body + `references/`, Yeoman sub-generators, Azure landing zones' referansearkitekturer |
+| 3 | **Gotchas / pitfalls** | Eksplisitte anti-mønstre / advarsler | `references/`-filer i skills, Cursor rule-body, AWS WAF lens har en dedikert `improvementPlan`-slot per valg — institusjonalisert gotcha-felt |
+| 4 | **Scaffolding** | Fil-/katalog-generering + prompts | Cookiecutters `cookiecutter.json` + `{{cookiecutter.*}}/`-template-katalog; Yeomans `prompts()`+`writing()`; `npm create *`. (Fraværende i rent advisory-systemer som Cursor/Copilot) |
+| 5 | **Review criteria / checklists** | Testbare exit-kriterier | AWS WAF: pillars → questions → choices → risk-regler (HIGH/MEDIUM/NO_RISK). Azure landing zones: design-area-checklists. Skills/Cursor bærer review-instruks uformelt |
+| 6 | **Guardrails / policies** | Ikke-forhandlbare constraints, enforced automatisk eller ved review | Azure landing zones: Azure Policy via Bicep/Terraform — policy-as-code. Copilot path-scoped `applyTo:` = myk guardrail. Skill `allowed-tools` / `disable-model-invocation` = invokasjons-nivå-guardrail |
+| 7 | **Reference implementations** | Eksempel-kode / eksempel-output | Skills' `examples/`-underkatalog, Yeoman-template-filer, Cookiecutters renderte output |
+| 8 | **Glossary** | Delt vokabular | Sjeldnest som eksplisitt komponent (implisitt i AWS-pillar-navn, Azure-design-area-navn). Skills mangler dedikert glossary-slot — havner i `references/` |
+
+**Konklusjon:** en skill dekker primært #2 (patterns) + delvis #3 (gotchas) + #7 (reference impl). En domain pack er MER: den legger til #1 (conventions), #5 (checklists), #6 (guardrails) og #4 (scaffolding) som førsteklasses, navngitte komponenter. Det er nettopp #5+#6 (checklists + guardrails) som ville løse friksjon #7 — App Store-submission-checklist, MASVS-checklist, privacy-manifest-mal, WCAG-2.2-AA-checklist bæres av `ios-app`-pakken i stedet for å gjenoppfinnes per app.
+
+## 2. Format
+
+Hver moden bunt bruker samme grunnform: **én deklarativ manifest-fil + en katalog-konvensjon for støtte-innhold.**
+
+- Cursor `.mdc`-filer: YAML-frontmatter (`description`, `globs`, `alwaysApply`) + markdown-body, i `.cursor/rules/`
+- Copilot: `applyTo:`-frontmatter i `*.instructions.md` i `.github/instructions/`
+- Anthropic skills: YAML-frontmatter (`name`, `description`, `paths`, `allowed-tools`) i `SKILL.md` + søsken-kataloger `references/`, `scripts/`, `assets/`
+- Cookiecutter: `cookiecutter.json` som manifest + en katalog hvis navn er en Jinja-template
+- AWS WAF lens: JSON-manifest med `schemaVersion`, `name`, `pillars[]`
+- ESLint shareable config: npm-pakke med `package.json` + en config-fil som eksporteres
+
+Mønsteret er konsistent: **ett deklarativt manifest + en katalog med innhold.** For app-creator (markdown for alt menneske-leselig, zero-npm): manifest i JSON (eller YAML-frontmatter i en `pack.md`), alt innhold i markdown, ingen build-step.
+
+## 3. Hvordan den refereres / aktiveres
+
+Aktiverings-gradienten på tvers av prior art går fra always-on til materialisering:
+
+| System | Aktivering |
+|--------|-----------|
+| Cursor rules | `alwaysApply: true` = alltid injisert; `globs` = auto-attached når matchende filer i kontekst; bare `description` = agent-requested (AI bestemmer); tom = manuell `@mention` |
+| Copilot instructions | `copilot-instructions.md` = repo-wide automatisk; `*.instructions.md` med `applyTo: glob` = automatisk når matchende filer redigeres |
+| Anthropic skills | Description alltid i kontekst; full body lastes ved invokasjon (bruker eller Claude); `paths:`-glob begrenser auto-aktivering; `disable-model-invocation: true` = manuell |
+| ESLint configs | `extends: [package]` = eksplisitt import; merges ved tool-runtime |
+| Cookiecutter/Yeoman | Eksplisitt CLI-invokasjon; templaten materialiseres inn i filsystemet |
+| AWS WAF lens | Attached til en workload; questions lastes under review-sesjon |
+
+For app-creator (filsystem-som-state, zero runtime-framework): den reneste mekanismen er **eksplisitt fil-sti-lasting** — hver fase-prompt lister hvilke pack-filer den skal `Read` ved oppstart (progressive disclosure, max-3-regel à la kiur), og en per-app `app.md`/`state.json` registrerer `domain_pack: "ios-app@0.1.0"` slik at pack-identiteten er del av app-state. Ingen glob-magi, ingen always-on injeksjon. I tillegg materialiseres et **snapshot** av pakken inn i app-instansens `00-context/`-mappe (den versjonen appen faktisk bruker) — kombinasjonen referanse-i-state + materialisert-snapshot er det Copier-mønsteret gjør for templates (se §4).
+
+## 4. Hvordan den versjoneres uten å brekke konsumenter
+
+Tre versjonerings-mønstre i prior art:
+- **npm semver** (ESLint/Prettier/tsconfig): konsumenten pinner versjon i `package.json`; rule-endringer i major-bumps
+- **git-tag-pinning** (Cookiecutter: `--checkout v1.2`; Copier: tag-baserte oppdateringer der templaten "kjenner" sine genererte prosjekter)
+- **implisitt git HEAD** (Cursor/Copilot/skills): committet til git, konsumenter arver repo-versjonen — ingen formell versjon
+
+**Erfaringsrapport-funn (community-researcher):**
+- **Drift er taus og uunngåelig.** Cursor-forumets ["Cursor just ignores rules"](https://forum.cursor.com/t/cursor-just-ignores-rules/69188) (12+ brukere) + Russell Jones' ["Drift in Cursor AI Rules"](https://jonesrussell.github.io/blog/drift-in-cursor-ai-rules/): regler eksisterer men matcher ikke lenger kodebasen (JS→TS-migrasjon, `.cursorrules` genererte fortsatt utypet kode), OG AI-en slutter stille å følge dem. Noen bygde [agents-doctor CLI](https://forum.cursor.com/t/built-a-small-cli-to-detect-agents-md-drift-missing-commands-dead-paths-conflicting-nested-files/159582) for å statisk oppdage dead paths / missing commands / oversized files. Michael Epelboims ["Cursor Rules: Why Your AI Agent Is Ignoring You"](https://sdrmike.medium.com/cursor-rules-why-your-ai-agent-is-ignoring-you-and-how-to-fix-it-5b4d2ac0b1b0): rot-årsak er context overload — jo flere valgfrie regler, jo høyere sjanse for at AI-en overser det kritiske. **Lang = usynlig.**
+- **Breaking changes bryter alle downstream.** [`eslint-config-love` Discussion #1961](https://github.com/mightyiam/eslint-config-love/discussions/1961) ("The Amount of Breaking Changes is Staggering" — v114, 3-4 breaking changes/mnd): "I dread any time I must upgrade this library." Fellesskapets løsning var ikke bedre innhold, men lavere endrings-frekvens: quarterly release windows, staged "edge releases", differensiell linting (nye regler kun på endrede linjer).
+- **Generatoren lever, prosjektet dør fra den.** [recallstack: "Yeoman and Cookiecutter are dead; long live Copier"](https://recallstack.gitlab.io/en/2020/04/18/yeoman-and-cookiecutter-are-dead-long-live-copier/): begge er dag-1-verktøy — genererer og skjærer båndet. SemVer blir meningsløst fordi du ikke trygt kan shippe breaking template-endringer til allerede genererte prosjekter; ingen backport-mekanisme. Copier er bygget eksplisitt rundt git-tag-baserte oppdateringer der templaten "kjenner" sine genererte prosjekter. [Projen Issue #1563](https://github.com/projen/projen/issues/1563): eject-funksjonen (fluktveien) er buggy — "opinionated + mange brukere + ingen trygg fluktvei = friksjon".
+- **Hva overleverne gjorde annerledes:** (1) scoping ikke universalitet — smalt opinionated domene, eksplisitt stille om resten; (2) versjonsdisiplin som kontrakt — kvartals-/halvårs-release-windows for breaking changes; (3) escape hatch som first-class design — [Projen dokumenterer escape hatches](https://projen.io/docs/concepts/escape-hatches/), Copier lar deg override per-fil, vellykkede ESLint-configs gjør det trivielt å deaktivere enkeltregler. **Stivhet uten fluktvei = tidsbomb.**
+
+## 5. Implikasjoner for `domain-pack-spec.md`
+
+### Hva en domain pack inneholder (komponent-liste)
+
+Hver komponent som dedikert fil/katalog under en `domain-pack/`-rot:
+
+| Komponent | Fil | Note |
+|-----------|-----|------|
+| Manifest | `pack.json` (eller `pack.md` med YAML-frontmatter) | `name`, `version`, `domain`, `schema`, `phases[]`, `verified` (sist-verifisert-dato + mot hvilken versjon av domenet, f.eks. "iOS 18 HIG, WWDC2025") |
+| Conventions | `conventions.md` | Domene-spesifikke ikke-forhandlbare beslutninger (HIG-regler, plugin-frontmatter-regler) + guardrails som underseksjon (App Store-constraints, GDPR-håndtering er conventions med enforcement-vekt) |
+| Patterns | `patterns/` | Én fil per gjenbrukbart mønster; fasene `Read` spesifikke |
+| Gotchas | `gotchas.md` | Eksplisitt "ikke gjør dette"-liste |
+| Checklists | `checklist.md` | Fase-exit-kriterier som checkbokser; mapper til brief-validering i fase 7 — App Store-submission-checklist, MASVS 2.1-checklist, WCAG-2.2-AA-checklist, privacy-manifest-mal lever HER (løser friksjon #7) |
+| Scaffolding | `scaffold/` | Fil-templater som materialiseres inn i per-app-artefakt-treet (f.eks. `PrivacyInfo.xcprivacy`-mal) |
+| Reference impl | `examples/` | Eksempel-briefer, eksempel-artefakter — konsumeres av brief-generator i fase 7 |
+| Glossary | `glossary.md` | Domene-vokabular; lastes selektivt |
+
+### Format
+
+`pack.json` = minimalt JSON-manifest, ingen npm-semantikk. Alt menneske-leselig i markdown. Ingen build-step.
+
+```json
+{
+  "schema": "domain-pack/v1",
+  "name": "ios-app",
+  "version": "0.1.0",
+  "description": "Domene-kunnskap for iOS-app-utvikling med Swift/SwiftUI",
+  "phases": [1, 3, 4, 5, 6, 7],
+  "verified": { "date": "2026-05-11", "against": "iOS 18, HIG WWDC2025, MASVS 2.1, WCAG 2.2" }
+}
+```
+
+`phases` deklarerer hvilke pipeline-faser som kan laste fra pakken. Fasene `Read` kun det de trenger — `conventions.md` i fase 1/3/5, `gotchas.md` i fase 5, `checklist.md` i fase 7. Progressive disclosure, verbatim fra skill-mønsteret. Maks-størrelse per fil (f.eks. én skjerm / ~500 ord der mulig), og eksplisitt "core" vs "supplementary"-merking — fordi lang = usynlig (Cursor-erfaringen).
+
+### Referanse / aktivering
+
+Fasene laster pack-komponenter eksplisitt by file path — ingen glob-magi, ingen always-on injeksjon. Hver fase-prompt lister hvilke pack-filer den skal `Read`. `state.json` registrerer `domain_pack: "ios-app@0.1.0"` → pack-identiteten er del av app-state. I tillegg materialiseres et **snapshot** av pakken (versjonen appen bruker) inn i app-instansens `00-context/`-mappe. Ingen runtime-framework: en fase-agent leser `state.json`, resolver pack-stien, leser relevant fil. Matcher filsystem-som-state-invarianten, krever zero eksterne verktøy. **Voyage-agnostisk:** når en feature-brief overleveres til Voyage, embeddes relevant pack-utdrag i `context.md` (se thread D) — Voyage ser kun en velformet brief, ikke "domain-pack-generert".
+
+### Versjonering
+
+`version` i `pack.json` følger semver-semantikk uformelt: breaking (fjerne komponent, rename felt) → major; additivt → minor; fixes → patch. Pakker lever i `domain-packs/` inni app-creator-pluginen (anbefalt lagrings-sted; alternativt `~/.claude/domain-packs/` — besluttes S5). `@`-notasjon (`ios-app@0.1.0`) muliggjør framtidig snapshot-pinning via git-tag hvis pakken ekstraheres til eget repo. Inntil da er versjons-feltet dokumentasjon — ingen lock-fil trengs fordi forfatteren er eneste konsument og pakker committes sammen med app-creator. **Men:** behandle en breaking pack-bump som det den er — skriv changelog-notat, bump major. Skriv pack-versjon inn i app-artefakter (intervju-output, briefer) slik at du alltid vet hvilken pakke-versjon som genererte et gitt prosjekt (Copier-mønsteret: templaten "kjenner" sine genererte prosjekter). **Escape hatch som first-class:** ethvert pack-felt skal kunne overrides per-app via `00-context/pack-overrides.md` i app-instansen — aldri hardkode en pack-verdi uten at app-konteksten kan si "for denne appen, ikke dette" (Projen-lærdommen).
+
+---
+
+## Kilder
+
+Autoritative (docs-researcher):
+- [Anthropic Agent Skills — Claude Code Docs](https://code.claude.com/docs/en/skills)
+- [Adding repository custom instructions for GitHub Copilot](https://docs.github.com/en/copilot/customizing-copilot/adding-custom-instructions-for-github-copilot) · [Copilot path-scoped instructions changelog](https://github.blog/changelog/2025-09-03-copilot-code-review-path-scoped-custom-instruction-file-support/) · [VS Code custom instructions](https://code.visualstudio.com/docs/copilot/customization/custom-instructions)
+- [Cursor Rules — cursor.com/docs](https://cursor.com/docs)
+- [ESLint Shareable Configs](https://eslint.org/docs/latest/extend/shareable-configs) · [ESLint flat config extends](https://eslint.org/blog/2025/03/flat-config-extends-define-config-global-ignores/)
+- [AWS Well-Architected — Lens format specification](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-format-specification.html)
+- [Azure landing zones — Microsoft Learn](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/) · [design areas](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas) · [governance design area](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance)
+- [Yeoman — Authoring](https://yeoman.io/authoring/) · [Composability](https://yeoman.io/authoring/composability.html)
+- [Cookiecutter — Overview](https://cookiecutter.readthedocs.io/en/stable/overview.html) · [Hooks](https://cookiecutter.readthedocs.io/en/stable/advanced/hooks.html)
+
+Erfaringsrapporter (community-researcher):
+- [Cursor: "Cursor just ignores rules" (12+ user reports)](https://forum.cursor.com/t/cursor-just-ignores-rules/69188) · [Workflow to reduce drift in Cursor sessions](https://forum.cursor.com/t/workflow-to-reduce-drift-in-cursor-sessions/155963)
+- [Russell Jones — Drift in Cursor AI Rules](https://jonesrussell.github.io/blog/drift-in-cursor-ai-rules/)
+- [agents-doctor CLI for AGENTS.md drift](https://forum.cursor.com/t/built-a-small-cli-to-detect-agents-md-drift-missing-commands-dead-paths-conflicting-nested-files/159582)
+- [Michael Epelboim — Cursor Rules: Why Your AI Agent Is Ignoring You](https://sdrmike.medium.com/cursor-rules-why-your-ai-agent-is-ignoring-you-and-how-to-fix-it-5b4d2ac0b1b0)
+- [eslint-config-love Discussion #1961 — "The Amount of Breaking Changes is Staggering"](https://github.com/mightyiam/eslint-config-love/discussions/1961) · [ESLint breaking-changes HN thread](https://news.ycombinator.com/item?id=39972747)
+- [recallstack — "Yeoman and Cookiecutter are dead; long live Copier"](https://recallstack.gitlab.io/en/2020/04/18/yeoman-and-cookiecutter-are-dead-long-live-copier/)
+- [Projen Issue #1563 — eject broken](https://github.com/projen/projen/issues/1563) · [Projen — escape hatches](https://projen.io/docs/concepts/escape-hatches/)

prototype-run/research/D-feature-artifacts.md

@@ -0,0 +1,190 @@
+# Thread D — Per-feature-artefakter + Voyages faktiske brief-kontrakt
+
+**Sesjon:** S3 (2026-05-11)
+**Metode:** Voyage-research — én `general-purpose`-agent (Sonnet) leste Voyage-pluginens kildekode (`docs/HANDOVER-CONTRACTS.md`, `commands/trekbrief.md`, `commands/trekplan.md`, `commands/trekreview.md`, `commands/trekexecute.md`, `templates/*.md`, `docs/profiles.md`, `docs/annotation-quickstart.md`) + `voyage:docs-researcher` (Sonnet) for per-feature-artefakt-anatomi i andre rammeverk. Syntese skrevet i hovedkontekst.
+**Confidence:** High på Voyage-kontrakten (lest direkte fra kildekode/templates — men dette er en levende plugin; verifiseres på nytt rett før fase 7-omskriving i S5, og round-trip-testes når Akashic når fase 7). High på per-feature-anatomi-prior-art.
+
+---
+
+## Seksjon 1 — Voyages faktiske brief-kontrakt (Handover 1)
+
+Dette er det fase 7-formatet i app-creator MÅ matche (round-trip-test-kravet). Lest fra Voyage-pluginen `~/.claude/plugins/marketplaces/ktg-plugin-marketplace/plugins/voyage/`.
+
+### Frontmatter-skjema (`brief_version: "2.0"`, gjeldende)
+
+| Felt | Type | Påkrevd | Note |
+|---|---|---|---|
+| `type` | string | **ja** | Hardkodet: `trekbrief` |
+| `brief_version` | string | **ja** | `"2.0"` |
+| `created` | date | **ja** | `YYYY-MM-DD` |
+| `task` | string | **ja** | Én-linjes task-beskrivelse |
+| `slug` | string | **ja** | URL-trygg slug, avledet fra task |
+| `project_dir` | string | **ja** | `.claude/projects/{YYYY-MM-DD}-{slug}/` |
+| `research_topics` | number | **ja** | Antall research-temaer, ≥ 0 |
+| `research_status` | string | **ja** | `pending \| in_progress \| complete \| skipped` |
+| `auto_research` | bool | valgfri | `true \| false` |
+| `interview_turns` | number | valgfri | ≥ 0 |
+| `source` | string | valgfri | `interview \| manual` |
+| `brief_quality` | string | valgfri | `complete \| partial` — påkrevd når intervju-loop-cap nås |
+
+**State-machine-constraint:** hvis `research_topics > 0` OG `research_status === "skipped"`, MÅ `brief_quality: partial` være satt — ellers avviser validatoren fila.
+
+**Additive annoterings-felter** (skrives kun av `/trekrevise`; fravær = `revision: 0`): `revision` (number), `source_annotations` (liste av dicts), `annotation_digest` (16-tegns hex), `revision_reason` (string, påkrevd kun på ikke-additive revisjoner).
+
+### Markdown-body-struktur (i rekkefølge)
+
+```
+# Task: {title}
+> [generated-by header]
+
+## Intent                       ← PÅKREVD (validator strict mode)
+## Goal                         ← PÅKREVD (validator strict mode)
+## Non-Goals                    ← valgfri, standard
+## Constraints                  ← valgfri, standard
+## Preferences                  ← valgfri, standard
+## Non-Functional Requirements   ← valgfri, standard
+## Success Criteria             ← PÅKREVD (validator strict mode)
+## Research Plan                ← påkrevd av Phase 3 interview-gate
+  ### Topic N: {Short title}     ← per tema, 7 sub-bullets (under)
+## Open Questions / Assumptions  ← valgfri
+## Prior Attempts               ← valgfri
+## Metadata                     ← valgfri (summary-blokk)
+## How to continue              ← footer med invokasjons-kommandoer
+```
+
+De **tre påkrevde body-seksjonene** (validator strict mode, og det HANDOVER-CONTRACTS lister som minimal-sett): `## Intent`, `## Goal`, `## Success Criteria`. `## Research Plan` håndheves via `BRIEF_MISSING_SECTION`-koder gjennom Phase 3-gaten.
+
+Hver `### Topic N:` under Research Plan MÅ ha disse 7 sub-bullets:
+- **Why this matters:**
+- **Research question:** (slutter med `?`)
+- **Suggested invocation:**
+- **Required for plan steps:**
+- **Confidence needed:** `high | medium | low`
+- **Estimated cost:** `quick | standard | deep`
+- **Scope hint:** `local | external | both`
+
+### `/trekbrief`-output vs. hva `/trekplan` minimalt krever
+
+`/trekbrief` produserer: `{project_dir}/brief.md` (frontmatter + full body), en `research/`-katalog-stub, og valgfritt `research/{NN}-{topic-slug}.md` hvis auto-research er på.
+
+`/trekplan` aksepterer to invokasjons-former:
+- `--project <dir>`: auto-discoverer `{dir}/brief.md`, `{dir}/research/*.md`, `{dir}/architecture/overview.md`. Kanonisk sti.
+- `--brief <path>`: vilkårlig brief-fil hvor som helst (ingen research-auto-discovery med mindre `--research` også gis).
+
+**Minimalt subset `/trekplan` faktisk krever:** brief-fila må passere brief-validatoren i `--soft`-modus. Soft mode krever: gyldig YAML-frontmatter, alle påkrevde frontmatter-felter til stede (`type`, `brief_version`, `created`, `task`, `slug`, `project_dir`, `research_topics`, `research_status`), `type === "trekbrief"`, `research_status` i tillatt enum. Body-seksjoner er warned-not-errored i soft mode. Manglende research-briefer er warned-not-blocked. Architecture-note er rent additiv. **I praksis:** gyldig frontmatter + vilkårlig body passerer planning-gaten — men intensjonen er at alle standard-seksjoner er til stede. Hvis `research_status === "pending"` og `research_topics > 0`, spør `/trekplan` "continue with low confidence?" — den hard-stopper ikke, den spør.
+
+→ **For app-creator fase 7:** generer briefen så den passerer **strict mode** (de tre påkrevde + Research Plan med 7-sub-bullet-temaer), ikke bare soft mode. app-creators fase 1-7-pipeline gir oss alt vi trenger for å fylle Intent/Goal/Success Criteria/Non-Goals/Constraints/NFRs ordentlig. Mapping: app-brief Problem→Intent, app-brief features-formål→Goal, feature-suksess-kriterier→Success Criteria (helst command-checkable / Given-When-Then), app-brief utenfor + feature-no-gos→Non-Goals, fase 5-constraints relevant subset→Constraints + NFRs, feature-research-områder→Research Plan-temaer.
+
+### Artefakter en Voyage-kjøring legger i `{project_dir}`
+
+Alt under `{project_dir}` = `.claude/projects/{YYYY-MM-DD}-{slug}/`:
+
+| Artefakt | Skrevet av | Formål |
+|---|---|---|
+| `brief.md` | `/trekbrief` Phase 4g | Kilde-kontrakt; konsumeres av alle nedstrøms |
+| `brief.md.draft` | `/trekbrief` Phase 4b | Transient — slettes etter gate passerer |
+| `research/{NN}-{topic-slug}.md` | `/trekresearch` Phase 7 | Én fil per research-tema, sortert på filnavn |
+| `architecture/overview.md`, `architecture/gaps.md` | Ekstern opt-in architect-plugin (Handover 3) | Valgfri arkitektur-note |
+| `plan.md` | `/trekplan` Phase 8 | Implementerings-plan; konsumeres av `/trekexecute` |
+| `progress.json` | `/trekexecute` per-steg | Resume-checkpoint; step-status, commits, manifest-audit |
+| `.session-state.local.json` | `/trekexecute` + `/trekendsession` | Multi-sesjon resume-state; gitignored (`*.local.json`) |
+| `NEXT-SESSION-PROMPT.local.md` | `/trekexecute` Phase 8 | Prompt for neste sesjon; gitignored |
+| `review.md` | `/trekreview` Phase 7 | Post-execution review; overskrives ved re-run; audit-trail i git |
+
+Utenfor `project_dir`: stats til `${CLAUDE_PLUGIN_DATA}/trekbrief-stats.jsonl` / `trekplan-stats.jsonl`; plan-critic/scope-guardian-intermediate JSON til `/tmp/` (ephemeral).
+
+→ **For app-creator:** `features/{NN}-{slug}/` skal romme app-creators egne artefakter (`brief.md`, `context.md`). Voyage-kjøringen skriver sine artefakter inn i SIN `{project_dir}` (`.claude/projects/{date}-{slug}/`). app-creator linker til Voyage-run-katalogen via `voyage_run_dir` i feature-frontmatter (allerede i utkastet) og leser `progress.json`/`review.md` derfra for status-eksport — den kopierer dem ikke inn i `features/{NN}/`. Alternativt kan operatøren peke Voyages `--project` til `features/{NN}-{slug}/voyage/` — det er en operatør-beslutning, ikke noe app-creator dikterer (Voyage-agnostisk).
+
+### Annoterings-anchor-format (Handover 8)
+
+Anchor-syntaks (HTML-kommentar, kun på blokk-grenser — aldri inni list-items, aldri midt i avsnitt):
+
+```html
+<!-- voyage:anchor id="ANN-0001" target="plan.md#step-3" line="412" -->
+```
+
+Annoterings-ID: `ANN-NNNN` (sekvensiell, 4-sifret zero-padded). `annotation_digest`: første 16 hex-tegn av en kanonisk SHA-256 over sortert `source_annotations`-array (deterministisk). Hver `source_annotations`-entry: `id`, `target_artifact` (`brief.md|plan.md|review.md`), `target_anchor`, `intent` (`change|add|remove|clarify|risk`) — påkrevd; `comment`, `line` — tolerert ekstra. `revision`-teller: fraværende (= 0), inkrementeres av `/trekrevise --apply` per batch. `revision_reason`: påkrevd kun for ikke-additive revisjoner (scope-fjerning, SC-erstatning).
+
+→ **For app-creator:** hvis app-creators briefer skal kunne annoteres (operatør reviewer en fase 7-brief før handover), bruk samme anchor-format. Men: app-creators interne briefer (fase 1-6) trenger ikke nødvendigvis Voyages presise mekanikk — Handover 8-mønsteret er allerede referert i utkastet ("brief-revisjon ved backtracking") som inspirasjon, ikke kopi. Beslutning i S5: arver app-creator hele `/trekrevise`-mekanikken, eller en lettere variant?
+
+---
+
+## Seksjon 2 — Per-feature-artefakt-anatomi fra prior art
+
+### Shape Up "pitch" ([basecamp.com/shapeup/1.5-chapter-06](https://basecamp.com/shapeup/1.5-chapter-06))
+Fem seksjoner i rekkefølge: **Problem** (rå kunde-problem, konkret nok til umiddelbar lesbarhet) → **Appetite** (timebox-commitment 2/6 uker — ikke estimat; dobler som scope-constraint) → **Solution** (bevisst grov: breadboarding eller fat-marker-sketches — grovheten er en feature, byggere eier detaljen) → **Rabbit holes** (navngitte sub-problemer/edge-cases som kan derailе scope) → **No-gos** (eksplisitte ekskluderinger). Skrevet av en shaper, ikke bygge-teamet. ([Principles of Shaping](https://basecamp.com/shapeup/1.1-chapter-02), [Risks and Rabbit Holes](https://basecamp.com/shapeup/1.4-chapter-05))
+
+### Linear ([linear.app/docs/conceptual-model](https://linear.app/docs/conceptual-model))
+Påkrevd: title, status. Valgfri: priority (P0-P4), estimate (points / T-shirt XS-XL), label(s), due date, assignee, team, project, cycle, milestone. Relations: blocking/blocked-by, related, duplicate. Hierarki: sub-issues under parent. Bevisst minimal ved opprettelse — fart over fullstendighet. Ingen strukturert acceptance-criteria-felt; lever i description by convention. ([Create issues](https://linear.app/docs/creating-issues), [Issue relations](https://linear.app/docs/issue-relations))
+
+### Jira story/epic ([support.atlassian.com](https://support.atlassian.com/jira-software-cloud/docs/what-are-story-points/))
+Built-in: summary, description, story points (story/epic), priority, assignee, reporter, labels, components, fix version, parent (erstattet legacy epic-link 2024), linked issues, attachments, sprint. **Acceptance criteria er ikke native Jira-felt** — custom field eller i description. Definition of Ready / Definition of Done er team-konvensjoner, ikke issue-felt.
+
+### GitHub issue/PR-templates ([docs.github.com — syntax-for-issue-forms](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms))
+Template top-level: `name`, `description` (påkrevd); `title`, `labels`, `assignees`, `projects`, `type` (valgfri). Body-input-typer: `textarea` (med `required`), `input`, `dropdown` (options, `multiple`, `required`), `checkboxes`, `markdown` (display only). Typisk feature-request-body: problem (textarea, required), proposed solution, alternatives considered, additional context. Skjemaet håndhever tilstedeværelse, ikke format.
+
+### BMAD story-fil ([docs.bmad-method.org](https://docs.bmad-method.org), [github.com/bdebon/bmad-poc](https://github.com/bdebon/bmad-poc))
+Eksplisitt "context-packing for an AI dev agent" — story-fila er dev-agentens eneste input. Seksjoner: **User story** (Connextra: "As a... I want... So that...") → **Acceptance criteria** (nummerert, hver med klar pass/fail) → **Tasks/subtasks** (checkbokser, actionable steg) → **Dev notes** (embedded arkitektur-resonnement, relevante utdrag fra PRD/architecture-doc, implementerings-guidance — upstream-konteksten *bakt inn*, ikke linket) → **References** (pekere til arkitektur-docs for dypere oppslag). Navn: `{epic}.{story}.story.md`. Dev-agenten får KUN denne fila + arkitektur-doc-sammendrag — ingen ambient kontekst. **Selv-inneholdthet er design-målet.** ([BMAD issues #1002, #496](https://github.com/bmad-code-org/BMAD-METHOD/issues/1002))
+
+### User-story-anatomi ([agilealliance.org/glossary/invest](https://agilealliance.org/glossary/invest/))
+Connextra (Rachel Davies, 2001): "As a [role], I want [feature], so that [benefit]." INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Given-When-Then (BDD): Given [precondition] / When [action] / Then [observable outcome]. Definition of Ready (før sprint: story skrevet, AC til stede, sized, ingen blocking deps) / Definition of Done (kode skrevet, tester passerer, reviewed, dokumentert, deployet til staging).
+
+### Syntese: minimumssett for en AI-implementerer
+
+Universelt til stede på tvers av alle seks formater:
+
+| Felt | Universelt? | Note |
+|---|---|---|
+| Problem / user-story-statement | Ja | Shape Up "Problem", Connextra, BMAD story-header, GitHub textarea |
+| Acceptance criteria (testbar) | Ja | BMAD nummerert AC, Given/When/Then, Linear/Jira via description, GitHub required textarea |
+| Scope-ekskluderinger / no-gos | Ja (Shape Up eksplisitt; andre implisitt) | Shape Up "No-gos", Jira "won't fix", GitHub "alternatives" |
+| Dependencies / relations | Ja | Linear blocking-relations, Jira linked issues, BMAD references, Shape Up rabbit holes |
+| Size / appetite-constraint | Ja | Shape Up appetite, Linear/Jira estimate, INVEST "Small" |
+
+Til stede i de fleste men ikke alle (nice-to-have): cross-cutting constraints (A11Y/security/performance — BMAD dev notes; fraværende i Shape Up by design), UX-referanse/design-sketch (Shape Up breadboard; ikke native ellers), upstream-kontekst embedded (BMAD; andre linker), edge cases (Shape Up rabbit holes, BMAD dev notes), assignee/owner, priority.
+
+**Kritisk innsikt fra BMAD** — det eneste formatet designet for AI-konsum: **selv-inneholdthet over linking.** Story-en embedder relevant arkitektur/PRD-kontekst i stedet for å referere den, fordi AI-agenten ikke har ambient kontekst å trekke på. Alle andre formater (Linear/Jira/GitHub) antar et menneske som kan følge lenker og inferere kontekst. **For en AI-implementerer slår embedding linking.** ← Dette validerer `features/{NN}/context.md` som materialiserer (ikke bare refererer) den relevante delen av fase 1-5-output, og det validerer at en domain-pack-snapshot embeddes i `00-context/` framfor å peke til en ekstern pakke.
+
+---
+
+## Implikasjoner for fase 7-omskriving + `features/{NN}/`-layout
+
+### Katalog-layout
+```
+features/
+  {NN}-{slug}/
+    brief.md          # Voyage-kompatibel (strict mode) — implementerers primær-input
+    context.md        # Hvorfor + upstream-embeds — implementerers sekundær-input
+    research.md        # Valgfri: feature-spesifikk research
+    design-ref.md      # Valgfri: UX-sketch, token-referanser, HIG-pekere
+    voyage_run.md      # Valgfri: peker til Voyage-run-dir + run-status (skrives av app-creator state-eksport)
+```
+`brief.md` + `context.md` obligatorisk; resten kun når innhold finnes. `{NN}`-prefiks håndhever dependency-rekkefølgen fra fase 6 (lavere NN avhenger ikke av høyere NN innen samme app).
+
+### `brief.md` — Voyage-kontrakt-kompatibel
+Frontmatter: alle Voyage-påkrevde felter (`type: trekbrief`, `brief_version: "2.0"`, `created`, `task`, `slug`, `project_dir`, `research_topics`, `research_status`) + app-creator-interne (`brief_type: feature`, `phase: 7`, `parent_app`, `parent_feature`, `revision`, `voyage_run_dir`, `voyage_run_status`) — de interne kan Voyage ignorere, eller app-creator stripper dem ved handover. Body: `## Intent` (fra feature-formål + app-brief-problem), `## Goal`, `## Non-Goals` (feature-no-gos + relevant app-brief-utenfor), `## Constraints` (relevant subset fra fase 5 — IKKE hele constraints-brief-en), `## Preferences`, `## Non-Functional Requirements` (relevante NFRs), `## Success Criteria` (helst Given-When-Then / command-checkable), `## Research Plan` (feature-research-områder som temaer med 7 sub-bullets), `## Open Questions / Assumptions`, `## How to continue`. Generer for **strict mode**, ikke soft.
+
+### `context.md` — embedder upstream (BMAD-prinsippet)
+1. **Dependencies** — features dette avhenger av (`{NN}-{slug}`-referanser) + features som avhenger av dette.
+2. **Cross-cutting constraints** — relevant subset fra fase 5 (kun det som gjelder denne featuren).
+3. **Architecture context** — relevant utdrag fra fase 3 ADRer (datamodell, API-kontrakt, mønster å følge). Maks ~10-15 linjer; ikke lim inn hele arkitektur-brief-en.
+4. **Design system tokens** — relevant subset fra fase 4 for denne featurens UI-overflate.
+5. **Domain-pack-utdrag** — relevante deler av `00-context/`-pakke-snapshot (iOS-konvensjoner, App Store-checklist-items, gotchas) som gjelder denne featuren.
+6. **Research signals** — 2-3 mest relevante punkter fra fase 2-research hvis relevant.
+
+### Fase 7-output-kontrakt
+Fase 7 skriver `brief.md` + `context.md` per feature i backloggen. To-fil-splittet speiler BMAD: `brief.md` er det Voyage MÅ honorere (kontrakten); `context.md` er det Voyage trenger for å forstå kontrakten. Voyage leser begge men er bundet kun av AC i `brief.md`. Avviker Voyage fra AC, er det en handover-feil sporbar til briefen. Round-trip-test før formatet låses i S5: skriv en Akashic-feature-brief → kjør `/trekplan --brief` → bekreft at Voyages validator passerer den i strict mode uten endringer.
+
+---
+
+## Kilder
+
+Voyage-kildekode (general-purpose-agent leste): `~/.claude/plugins/marketplaces/ktg-plugin-marketplace/plugins/voyage/` — `docs/HANDOVER-CONTRACTS.md`, `commands/trekbrief.md`, `commands/trekplan.md`, `commands/trekreview.md`, `commands/trekexecute.md`, `templates/trekbrief-template.md`, `templates/plan-template.md`, `templates/trekreview-template.md`, `templates/research-brief-template.md`, `docs/profiles.md`, `docs/annotation-quickstart.md`.
+
+Autoritative (docs-researcher):
+- [Shape Up — Write the Pitch](https://basecamp.com/shapeup/1.5-chapter-06) · [Principles of Shaping](https://basecamp.com/shapeup/1.1-chapter-02) · [Risks and Rabbit Holes](https://basecamp.com/shapeup/1.4-chapter-05)
+- [Linear — Conceptual Model](https://linear.app/docs/conceptual-model) · [Create issues](https://linear.app/docs/creating-issues) · [Issue relations](https://linear.app/docs/issue-relations) · [Parent and sub-issues](https://linear.app/docs/parent-and-sub-issues)
+- [Jira — What are story points?](https://support.atlassian.com/jira-software-cloud/docs/what-are-story-points/) · [Epic-link replaced with parent](https://support.atlassian.com/jira-software-cloud/docs/upcoming-changes-epic-link-replaced-with-parent/)
+- [GitHub — Syntax for issue forms](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms) · [Form schema syntax](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema)
+- [BMAD Method docs](https://docs.bmad-method.org/) · [BMAD POC story-file example](https://github.com/bdebon/bmad-poc) · [BMAD-METHOD repo](https://github.com/bmad-code-org/BMAD-METHOD)
+- [Agile Alliance — INVEST](https://agilealliance.org/glossary/invest/) · [Given-When-Then](https://www.agilealliance.org/glossary/gwt/) · [Connextra template](https://agilealliance.org/glossary/user-story-template/) · [Definition of Ready](https://agilealliance.org/glossary/definition-of-ready/)

prototype-run/research/E-contrarian.md

@@ -0,0 +1,69 @@
+# Thread E — Contrarian: når feiler spec-tunge / big-design-upfront-pipelines?
+
+**Sesjon:** S3 (2026-05-11)
+**Metode:** Voyage-research — `voyage:contrarian-researcher` (Sonnet). Emerging conclusion stress-testet: "app-creators 7-fase brief-pipeline er riktig tilnærming for å gå fra app-konsept til Voyage-klare feature-briefer." Syntese skrevet i hovedkontekst.
+**Confidence:** High på at kritikken er reell og veldokumentert (YAGNI, BDUF-kritikk, spec-drift, discovery-teater er alle etablerte, kildebelagte posisjoner). Medium på de spesifikke fase-rangeringene (vurderinger, ikke målinger — Akashic-kjøringen skal levere de faktiske tids-tallene).
+
+---
+
+## Det sterkeste caset mot 7-fase-pipelinen
+
+### Royce-feilen i bunnen
+Selve ideen om en sekvensiell fase-pipeline hviler på en historisk misforståelse. Winston Royces 1970-papir, antatt å ha grunnlagt vannfallsmodellen, var faktisk en *kritikk* av sekvensielt design — Royce kalte det eksplisitt "risikofylt og inviterende til fiasko" ([pragtob.wordpress.com](https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a-big-misunderstanding-from-the-beginning-reading-the-original-paper/)). Ingen leste resten av papiret der han foreslo iterasjon. app-creator risikerer samme feil — ta et diagram ment som advarsel og bruke det som design-mal.
+
+### YAGNI som strukturell anklagelse
+YAGNI ("You Aren't Gonna Need It", Ron Jeffries / XP): implementer aldri ting fordi du *forutser* behovet, bare fordi du *faktisk trenger det nå* ([olivercoding.com](https://www.olivercoding.com/2018-09-23-yagni/)). Overført til spec-faser: skriv aldri en artefakt fordi du forutser at du trenger den. For Akashic — én person, én bruker (deg selv), eksplisitt "i praksis en liten app" — er fem av syv faser spekulativ infrastruktur. Fase 4 (designsystem) og fase 5 (constraints) for en liten iOS-app der du selv er bruker er klassiske YAGNI-brudd: et designsystem betaler seg ved konsistens over mange features og kanskje et team — for et enkelt app-forsøk er det prematur abstraksjon. [Sparkbox sier eksplisitt](https://sparkbox.com/foundry/when_not_to_use_a_design_system) at design systems ikke er egnet i tidlige stadier — du trenger stabilitet før du kodifiserer tokens.
+
+### "Tracer bullet" / "walking skeleton" som ekte alternativ
+The Pragmatic Programmer beskriver [tracer bullets](https://www.barbarianmeetscoding.com/notes/books/pragmatic-programmer/tracer-bullets/) som direkte motpol til BDUF: bygg en tynn, fungerende ende-til-ende-slice med en gang, la strukturen vokse fra faktisk kode. En walking skeleton (Growing Object-Oriented Software) gjør det samme. For Akashic ville dette si "åpne Xcode, lag en app med én skjerm som gjør kjernefunksjonen (en sun-window-beregning + et completion-tap), finn ut hva du savner etterpå" — kontrasten til syv sekvensielle artefakter før én linje iOS-kode finnes. Pragmatic Programmer er eksplisitt: upfront-kalkuleringer er "hope-based development" — du *håper* det du spesifiserte treffer; tracer bullets gir faktisk feedback.
+
+### Spec-drift er strukturell, ikke disiplin-feil
+[Kinde sin spec-drift-analyse](https://www.kinde.com/learn/ai-for-software-engineering/ai-devops/spec-drift-the-hidden-problem-ai-can-help-fix/): kode endrer seg under press, specs ikke. For en solo-dev uten team som håndhever specs som kontrakter, er drift garantert. Etter to Voyage-kjøringer vil arkitektur-doc og feature-backlog divergere fra det Voyage faktisk bygde — nå har du to sannheter, og synk-kostnaden er en skjult vedlikeholdsskatt som vokser med fase-artefakt-antallet. Syv faser = syv potensielle divergenspunkter. (Bekrefter thread A's P4 fra et hardere ståsted: ikke "bruk revisjons-mekanikken disiplinert" men "antallet artefakter ER problemet".)
+
+### PRD-teater og discovery-teater
+SVPG ([Discovery vs. Documentation](https://www.svpg.com/discovery-vs-documentation/)): PRD-er skrives i de fleste tilfeller *i stedet for* discovery-arbeid, ikke etter. Marty Cagan navngir dette som "discovery theater" — én av seks teater-varianter i "product management theater" ([Lenny's Newsletter](https://www.lennysnewsletter.com/p/product-management-theater-marty)). En fase kalt "intervju" der du intervjuer deg selv er ikke discovery — det er en rituell gest mot discovery. Ekte discovery er eksplorativ og ustyrt; et intervju-format med forhåndsdefinerte seksjoner er allerede *formet output* som bekrefter hva du allerede tror. Et system der en bug-fix og et nytt produkt får identisk fase-struktur er symptom på at formatet styrer tenkningen, ikke omvendt.
+
+### Kostnad av seremoni for et team av én
+For et team er faser *koordineringsverktøy* — de synkroniserer folk som ikke er i samme rom. En [solo developer](https://thisisglance.com/blog/solo-app-development-the-honest-path-from-concept-to-launch) har ingen koordineringskostnad; alle syv fasene bor allerede i én hjerne. Det skrevne intervjuet, arkitektur-doc-et og designsystemet er eksternalisering av kunnskap til filer ingen andre leser. Overhead uten koordineringsgevinst er rent tap. (Nyanse — *det er ikke helt sant for app-creator*: thread A's P3 viste at AI-kontekst degraderer over sesjoner, så å eksternalisere til filer er *nødvendig for AI-en* selv om mennesket ikke trenger det. Men det gjelder de artefaktene Voyage faktisk konsumerer — ikke nødvendigvis alle syv.)
+
+---
+
+## Hvilke faser/mekanikker er mest sårbare for contrarian-kritikken (rangert)
+
+| Rang | Fase | Sårbarhet | Begrunnelse |
+|------|------|-----------|-------------|
+| 1 (mest) | **Fase 4 — Designsystem** | Kritisk | YAGNI-brudd i ren form. Betaler seg ved stabilisert feature-sett / team. Prematur for eksplorasjons-fase. Bør trigge *etter* første Voyage-kjøring har produsert faktiske UI-komponenter — da vet du hva som eksisterer. |
+| 2 | **Fase 5 — Constraints** | Kritisk | GDPR, App Store-regler, A11Y kan sjekkes just-in-time (og bæres av domain-pack-checklists — thread C). Å dokumentere dem som separat fase-artefakt før koden finnes er seremoni. Motargument: noen constraints (paid-app-modell, ikke-affiliering-disclaimer) ER reelle scope-beslutninger — men de hører i app-brief, ikke et separat dokument. |
+| 3 | **Fase 1 — Intervju** | Høy | Intervju av deg selv er ikke discovery — det er rituell nedskriving av hva du allerede vet. Bare nyttig hvis du genuint er usikker og intervjuet avdekker noe overraskende. Motargument: Akashics fase 1 *avdekket* faktisk noe (skala-rekalibrering, friksjon #4) — men det taler for et mye kortere format, ikke 6 temaer + 6 kvalitets-sjekk-spørsmål. |
+| 4 | **Fase 2 — Research (valgfri)** | Moderat | Allerede valgfri — men trenger sterkere default: "skip unless du genuint ikke vet". For Akashic er opphavsretts-spørsmålet reelt → fase 2 berettiget her. |
+| 5 | **Fase 3 — Arkitektur** | Moderat | Nyttig, men farlig som upfront-fase. Bør være én side med *åpne spørsmål* som lukkes etter koden, ikke en decisions-log skrevet før koden finnes (decisions-log før kode = grunnlag for spec-drift). |
+| 6 | **Fase 6 — Feature-derivasjon** | Lav-moderat | Backloggen er nyttig, men avledet fra over-spesifiserte fase-artefakter blir den falsk presis. En enkel liste er nok. |
+| 7 (minst) | **Fase 7 — Brief per feature** | Lav | Dette er selve *produktet* av systemet — uten briefen har Voyage ingenting. Men briefen bør kunne nås med 90% kortere fase-vei. |
+
+---
+
+## Hva app-creator bør gjøre for å ikke bli seremoni
+
+1. **Bygg inn en "just start"-sti fra starten.** Brukeren skal kunne gå direkte fra app-konsept til én minimal feature-brief (fase 7) uten å passere fasene 1-6 — "rapid mode" / "sketch brief". Systemet er bare nyttig hvis noen faktisk bruker det; en to-timers pipeline ingen gidder å starte er verre enn ingen pipeline. (Spenning mot thread A's P5: "å hoppe over PRD krasjer pipelinen" — løsningen er at "just start" produserer en *minimal men gyldig* app-brief inline, ikke at den hopper over anker-dokumentet helt.)
+2. **Gjør faser skippbare med eksplisitt begrunnelse.** Ikke bare "valgfri" — systemet ber om én setning per hopp: "Hopper over designsystem fordi: early stage, ingen andre brukere." Bevisst hopp uten å tvinge seremoni.
+3. **Erstatt "intervju" med "problem-statement + åpne spørsmål" som lett default.** To spørsmål i fritekst: Hva ville du gjort hvis appen ikke fantes? Hva er det vanskeligste du ikke forstår ennå? Det fulle 6-tema-intervjuet blir opt-in for de tilfellene der operatøren genuint er usikker. (Behold trekbrief-disiplinene som *tilgjengelige*, ikke obligatoriske.)
+4. **Arkitektur-fasen produserer spørsmål, ikke svar.** En "uavklarte arkitektur-spørsmål"-liste som lukkes etterpå er mer ærlig og mer holdbar enn en decisions-log skrevet før koden.
+5. **La designsystem-fasen trigge på bruk, ikke plan.** Fase 4 aktiveres etter første Voyage-kjøring har produsert faktiske UI-komponenter — eller hoppes helt for små apper og erstattes av "bruk HIG / Material direkte" (domain-pack-default).
+6. **Mål overhead eksplisitt i prototypen.** Tid brukt per fase i Akashic-kjøringen. Hvis fase 4 tar to timer og produserer en artefakt som ikke er referert i én eneste Voyage-brief → beviset er at fasen er seremoni og bør droppes som default. (Legg dette inn i `friksjon.md`-protokollen.)
+7. **Harde grenser på artefakt-lengde.** Hvert fase-dokument har et maksimum (f.eks. ≤500 ord / én skjerm). Ingen fase produserer noe du ikke kan lese på 5 minutter. Lengde er det sterkeste signalet på at du skriver for utseendets skyld.
+
+---
+
+**Konklusjon:** Det sterkeste caset mot 7-fase-pipelinen er ikke at noen fase er feil i seg selv — det er at sekvensialiteten og artefakt-kravene er designet for koordinering mellom folk som ikke deler samme hjerne, mens koordineringsgevinsten for en solo-dev som bygger for seg selv er null (med ett unntak: AI-kontekst-degradering tvinger eksternalisering til filer for de artefaktene Voyage faktisk konsumerer — thread A P3). Designkonsekvens: app-creator bør ha **"brief-first, faser som opt-in"** som grunnantakelse, med en lett default-sti og full pipeline som eskalering — ikke den andre veien. Dette skjerper, men motsier ikke, thread A's hovedtakeaway ("strukturen er solid, men risikoen er at den blir for tung"): thread E sier risikoen er ikke bare "for tung" men "feil default-retning".
+
+---
+
+## Kilder
+- [Why Waterfall was a big misunderstanding from the beginning — pragtob.wordpress.com](https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a-big-misunderstanding-from-the-beginning-reading-the-original-paper/)
+- [YAGNI: You Ain't Gonna Need It — olivercoding.com](https://www.olivercoding.com/2018-09-23-yagni/)
+- [Tracer Bullets — barbarianmeetscoding.com (Pragmatic Programmer notes)](https://www.barbarianmeetscoding.com/notes/books/pragmatic-programmer/tracer-bullets/)
+- [Spec Drift: The Hidden Problem AI Can Help Fix — kinde.com](https://www.kinde.com/learn/ai-for-software-engineering/ai-devops/spec-drift-the-hidden-problem-ai-can-help-fix/)
+- [Discovery vs. Documentation — SVPG](https://www.svpg.com/discovery-vs-documentation/)
+- [Product Management Theater — Marty Cagan via Lenny's Newsletter](https://www.lennysnewsletter.com/p/product-management-theater-marty)
+- [When NOT to Use a Design System — Sparkbox](https://sparkbox.com/foundry/when_not_to_use_a_design_system)
+- [Solo App Development: The Honest Path from Concept to Launch — thisisglance.com](https://thisisglance.com/blog/solo-app-development-the-honest-path-from-concept-to-launch)