docs(a3): lukk A3 — Akashic-halvdel committet (bd38b23), logg override-drift-friksjon #19

Akashic-instansen utforte og committet sin halvdel av A3 (commit bd38b23
+ d39b7b8). Verifisert direkte mot deres repo: pin-inventar matcher
eksakt det de rapporterte (6x0.1.0 historisk, 1x0.2.0 bootstrap-markor,
6x0.2.2 live, sum 13). A3 lukket pa begge sider.

To feil i vart eget arbeid denne A3-runden, funnet og bekreftet av
Akashic: (1) det faktiske hoppet var 0.1.0 -> 0.2.2, ikke 0.2.1 -> 0.2.2
-- live-pinsene var aldri oppdatert forbi forste materialisering. (2)
snapshotets pack-kilde-felt pekte pa en slettet plugin-marketplace-sti.
Begge dokumentert i masterplan.md § A3 med korrekt framstilling.

Nytt friksjonsfunn logget som #19: snapshot-overrides kan drive fra
pack-overrides.md uavhengig av pack-versjon -- en ren versjonssammen-
ligning fanger det ikke, siden override-dokumentet ikke er del av
pakken. To spec-revisjonsretninger skissert, ingen valgt (kandidat
D-fase eller B2).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XpFPJDg8XKNxSHxH9uxGZr

prototype-run/friksjon.md

@@ -553,3 +553,26 @@ Tre nummererte friksjons-entries etterregistrert per masterplanens § A4-scope-g
 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.
+
+**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.
+
+---