research(app-creator): thread A+B — prior art + app-definisjon-sjekkliste

S2 av Akashic-drevet design-research. A-prior-art.md: 8 mønstre å stjele
+ 9 fallgruver fra Kiro/BMAD/MetaGPT/Agent OS/Shape Up/Amazon PR-FAQ/SVPG/
JTBD/Torres + erfaringsrapporter. B-app-definition.md: 12-gruppers app-
definisjons-sjekkliste mot ISO 29148/25010:2023, arc42, WCAG 2.2, MASVS 2.1,
Apple App Store + privacy manifest, GDPR — + mapping mot 7-fasene som
avslører 3 manglende eierfaser. Logget friksjon #7.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-05-11 20:45:39 +02:00
commit e739f0a8d5
3 changed files with 263 additions and 0 deletions

View file

@ -104,4 +104,20 @@ Eventuelt: aksepter at operatør gir kvaliteter, og gjør AI-foreslått-features
**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.
---
## #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".
---