design(app-creator): S7 — restrukturer Akashic-instans + materialiser domain-pack-snapshot + revider app-brief

- docs/domain-pack-spec.md: snapshot-materialiserings-mekanikk LÅST (S7) — 6-stegs seksjons-struktur: H1-tittel + topp-metadata + Relevante patterns + per-core-fil H2 (nedjustert ett heading-nivå) + inline OVERRIDE-blockquotes + Overrides-anvendt-tabell. Referanse-impl: Akashic 00-context/domain-pack-ios-app.md.

- prototype-run/friksjon.md: ny #10 — app-brief sprenger 500-ord-grensen (Akashic 01-app-brief.md revision 1 = 1830 ord etter bevisst-ikke-oppblåst revisjon). Foreslår per-artefakt-lengde-tabell ved neste phase-design-draft.md-revisjon (app-brief ~2000 ord; andre ≤500; snapshots/transcripts/examples unntatt). + Ny friksjon oppstått i S7-seksjon med 3 prosess-/spec-merknader (snapshot-mekanikk-detaljer LÅST, pack-overrides [STATUS]-konvensjon foreslått formalisert, app.md frontmatter-form konvergert til spec).

Akashic-side endringer i eget repo: 00-context/ (snapshot + pack-overrides), features/ (med README.md), app.md, state.json, 01-app-brief.md rev 0→1 inkl. iOS-versjons-korreksjon (friksjon #9).

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

prototype-run/friksjon.md

@@ -184,3 +184,44 @@ Mindre prosess-/spec-merknader fra forfatter-arbeidet (ikke nummererte friksjons
 - **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 |
+
+---
+
+## 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.
+
+---