--- name: app-roentgen description: | Durchleuchtet eine Android-App systematisch wie ein Roentgengeraet — extrahiert ALLE Funktionen, Bildschirme, Klick-Pfade, Paywall-Stufen und Hidden Features aus dem Quellcode, damit Werbeaussagen 1:1 gegen die Code-Realitaet geprueft werden koennen (UWG §5, EU UCPD, Google Play Policy). Nutze diesen Skill IMMER bei: "App durchleuchten", "App roentgen", "Roentgen-Skill", "X-Ray", "Durchleuchten", "Werbeaussagen pruefen", "Werbeaussagen-Audit", "UWG-Audit", "Paywall-Audit", "Marketing-Compliance", "Feature-Audit", "Feature-Inventar", "App-Architektur extrahieren", "alle Funktionen einer App auflisten", "App komplett analysieren", "App-Analyse fuer Rechtssicherheit", "stimmt was wir versprechen mit der App ueberein", "was kann die App genau", "Compliance-Pruefung". Funktioniert fuer beliebige Android-Apps (Kotlin/Compose bevorzugt, Java/XML auch unterstuetzt). Erzeugt einen strukturierten Audit-Bericht mit 1:1-Wortlauten, Paywall-Inventar, Permission-Mapping und Werbeaussage-vs-Feature-Matrix. NICHT triggern fuer iOS-only-Apps, reine Flutter-/React-Native-/KMP-iOS-Builds, Web-Apps oder Backend-Services — der Skill liest Android-spezifische Patterns (AndroidManifest.xml, strings.xml, BillingClient, Compose) und liefert bei Nicht-Android-Codebases keine sinnvollen Ergebnisse. Bei Hybrid-Apps mit Android-Anteil (z.B. Flutter-Projekt mit `android/`-Ordner): nur den `android/`-Unterordner als Eingabe geben. allowed-tools: - Bash - Read - Grep - Glob - Write --- # App-Roentgen: Vollstaendiges Architektur- und Werbeaussagen-Audit fuer Android-Apps ## Abgrenzung zu anderen Skills Dieser Skill ist eine GRUNDLAGEN-Schicht — sein Output wird von anderen Skills konsumiert. Nicht aufrufen wenn die Hauptaufgabe ein anderes Ziel hat: | Anfragetyp | Richtiger Skill | |-----------|----------------| | Reine DSGVO-/Datenschutz-/Impressums-Pruefung | `rechtssicherheit` | | Hardcoded Strings finden + neue Strings erstellen | `string-extraktor` | | Bestehende deutsche Strings in andere Sprachen uebersetzen | `uebersetzung` | | Monetarisierungs-/Conversion-Beratung (Paywall-Optimierung) | `app-monetizer` | | UI/UX-Design-Audit (Farben, Typografie, Material 3) | `designer` | Wenn Werbeaussagen-Audit, Feature-Inventar oder Paywall-Compliance gefragt sind: **dieser Skill**. Wenn die nachgelagerten Skills explizit den Roentgen-Output brauchen, ist es legitim diesen zuerst zu fahren und dann den anderen — aber nicht "DSGVO-Check" mit diesem Skill anfangen. ## Kernzweck Der Skill durchleuchtet eine Android-App so gruendlich, dass am Ende eine 100-Prozent-vollstaendige Liste vorliegt was die App in jedem einzelnen Bildschirm, bei jedem Klick und in jedem Abbruchpfad genau tut. Ziel ist Rechtssicherheit: Wenn eine Werbeaussage behauptet "Unbegrenzte KI-Analysen" muss der Skill verifizieren ob das im Code wirklich stimmt — oder ob ein Limit von 150 pro Tag drin ist. Der finale Bericht hat vier Teile: 1. **Architektur-Inventar** — alles was die App kann, in 15 Kategorien gegliedert 2. **Wortlaut-Mapping pro Bereich** — fuer JEDEN Bildschirm, Dialog, Bottom-Sheet, jedes Menue und jedes Untermenue (rekursiv, beliebige Tiefe), jedes Settings-Item, jede Notification, jeden Snackbar/Toast/Error-State werden die exakten 1:1-Wortlaute zitiert 3. **Translation-Context** — pro Wortlaut die Daten die ein Uebersetzer braucht (Laengen, xliff:g, Notes, Plurals, HTML, Format-Argumente, Glossar, Du/Sie-Konsistenz) 4. **Werbeaussage-vs-Feature-Matrix** — jede beworbene Aussage gegen die Code-Realitaet geprueft Der Bericht dient zwei nachgelagerten Konsumenten: - **Rechtssicherheits-Skill** — prueft Wortlaute gegen UWG, EU UCPD, DSGVO, Google Play Policy - **Uebersetzungs-Skill** — uebersetzt Wortlaute mit voller Context-Information (Slot, Laenge, Plural-Regeln, Glossar, Argumente) ## Warum 1:1-Wortlaute (KRITISCH) Der Rechtssicherheits-Skill, der nach dem Roentgen-Audit laeuft, prueft jede Formulierung gegen UWG, EU UCPD, Google Play Policy, DSGVO und Verbraucherschutzrecht. **Schon ein einziges falsches oder fehlendes Wort kann eine Abmahnung ausloesen** — Beispiele: "Geld zurueck" statt "Geld-zurueck-Garantie unter Bedingungen X", "unbegrenzt" statt "bis zu 150/Tag", "anonym" statt "pseudonym". Deshalb gilt fuer ALLE Wortlaute im Bericht: | Regel | Bedeutung | |-------|-----------| | **1:1 woertlich** | Exakte Zeichenfolge inkl. Satzzeichen, Gross-/Kleinschreibung, Sonderzeichen, Umlauten, Leerzeichen | | **In Anfuehrungszeichen** | Jeder Wortlaut wird in `"..."` zitiert um sichtbar zu machen wo er anfaengt und endet | | **Mit Quelle** | Datei + Zeile + String-Resource-Key (`strings.xml:42 → R.string.paywall_unlimited_ai`) | | **Pro Sprache** | Wenn die App mehrsprachig ist, jeden Wortlaut in allen Sprachen zitieren | | **Keine Zusammenfassung** | Niemals "der Text sagt sinngemaess..." — IMMER der Original-Text | | **Plurals + Formate** | Auch `` und Format-Strings mit `%s`/`%d` werden so wie sie im Code stehen zitiert | **Verbotsliste:** - ❌ "Headline lautet etwa 'Premium starten'" - ❌ "Im Dialog steht eine Bestaetigungsfrage" - ❌ Nur den String-Key zitieren ohne den Wortlaut - ❌ Bei langen Texten kuerzen mit "..." **Verpflichtend:** - ✅ `Headline (paywall_title @ strings.xml:88): "Jetzt Premium starten und alle Vorteile sichern"` - ✅ `Bestaetigung (delete_confirm_title): "Wirklich loeschen?" / Body (delete_confirm_body): "Diese Aktion kann nicht rueckgaengig gemacht werden."` ## Wann triggern Frank sagt typischerweise Phrasen wie "Lass die BestJournal mal durchleuchten", "Roentgen-Audit fuer App XY", "Werbeaussagen-Pruefung fuer Paywall", "Was macht die App wirklich". Der Trigger ist absichtlich grosszuegig — lieber einmal zu oft als einmal zu wenig. Der Skill wird typischerweise vor einem Marketing-Audit oder vor einem Release ausgefuehrt, oder wenn die Frage aufkommt ob die App das wirklich macht was sie verspricht. ## Pflicht-Vorgehen: Die 7 Schichten der Durchleuchtung Reihenfolge ist wichtig. Jede Schicht baut auf der vorherigen auf. KEINE Schicht ueberspringen — sonst entstehen Luecken im Audit und der Roentgen-Effekt geht verloren. ### Schicht 1 — Manifest-Analyse: Was darf die App? Liest `app/src/main/AndroidManifest.xml` und extrahiert alles was deklariert ist: Permissions, Activities, Services, Receiver, ContentProvider, Intent-Filter, Deep-Links, Backup-Konfiguration. Jede Permission impliziert Features (CAMERA → Foto-Capture, RECORD_AUDIO → Voice-Input). → **Detail-Anleitung**: `references/layer-1-manifest.md` → **Permission-zu-Feature-Tabelle**: `references/permission-feature-map.md` ### Schicht 1.5 — Assets-Scan: Welche Legal- und Web-Dokumente liefert die App aus? (FIN-014) Glob `app/src/main/assets/**/*.{html,htm,md,txt}` ausfuehren. Ergebnis in `roentgen-report.json` unter Key `layer1_5_assets` eintragen. Dieser Schritt MUSS vor Schicht 2 abgeschlossen sein, damit der Rechtssicherheits-Skill keine falschen `missingDocs`-Findings erzeugt. **Sprach-Detection** aus dem Pfad-Locale-Segment (Beispiel: `assets/legal/de/DATENSCHUTZ.html` → Sprache `de`). Wenn kein Locale-Segment vorhanden → `default`. **Doktyp-Detection** aus dem Dateinamen (case-insensitive): | Muster im Dateinamen | Doktyp | |----------------------|--------| | `DATENSCHUTZ`, `PRIVACY`, `PRIVACY_POLICY` | `privacy` | | `IMPRESSUM`, `IMPRINT`, `LEGAL_NOTICE` | `imprint` | | `NUTZUNGSBEDINGUNGEN`, `TERMS`, `TOS`, `AGB` | `terms` | | `HEALTH_DISCLAIMER`, `MEDICAL`, `HEALTH` | `health-disclaimer` | | alles andere | `other` | **Output-Schema** in `roentgen-report.json`: ```json "layer1_5_assets": { "privacy": { "de": "assets/legal/de/DATENSCHUTZ.html", "en": "assets/legal/en/PRIVACY.html" }, "imprint": { "de": "assets/legal/de/IMPRESSUM.html" }, "terms": { "de": "assets/legal/de/NUTZUNGSBEDINGUNGEN.html", "en": "assets/legal/en/TERMS.html" }, "health-disclaimer": {}, "other": [ "assets/help/onboarding.html" ] } ``` **Konsum durch den Rechtssicherheits-Skill:** Der Recht-Skill liest `layer1_5_assets` VOR der `missingDocs`-Generierung. Wenn der gesuchte Doktyp in der Map vorhanden ist, wird das Finding entweder weggelassen oder auf `"Doc existiert — Deep-Link-Verbesserung pruefen"` heruntergestuft (statt 🟥 `missingDoc`). → **Skript-Implementierung**: `scripts/feature-scan.sh` Abschnitt „ASSETS-SCAN (FIN-014)" ### Schicht 2 — Dependency-Analyse: Was kann die App technisch? Liest `build.gradle.kts`, `libs.versions.toml`, `settings.gradle.kts`. Jede Bibliothek impliziert Capabilities (firebase-messaging → Push, play-billing → Paywall, mlkit-* → KI/ML, room-runtime → Datenbank). Auch Pruefung ob Dependencies aktiv genutzt werden oder tot sind. → **Detail-Anleitung**: `references/layer-2-dependencies.md` ### Schicht 3 — Architektur-Inventar: Wie ist die App gebaut? Extrahiert alle ViewModels, Repositories, UseCases, Hilt-Module, Room-Entities, Workers (WorkManager). Das ergibt das Skelett der App: welche Daten existieren, welche Business-Logik laeuft, welche Background-Jobs gibt es. Jeder ViewModel = ein Feature-Cluster. → **Detail-Anleitung**: `references/layer-3-architecture.md` → **Optional — Goldstandard 2026 (Compose Compiler Reports + KSP-NavGraph + ast-grep + mobsfscan)**: `references/layer-3b-compose-compiler-reports.md`. Bei zugaenglichem Build empfohlen — liefert nachweislich vollstaendiges Composable-Inventar direkt vom Compiler statt grep-Heuristik. ### Schicht 4 — Bildschirm-Karte: Was sieht der Nutzer? Extrahiert jeden einzelnen Compose-Screen, jede Navigation-Route, jeden Click-Handler, jeden Side-Effect (LaunchedEffect mit Navigation), jeden Dialog, jedes Bottom-Sheet. Erzeugt eine Bildschirm-Karte als Mermaid-Diagramm UND als Baum. Fuer jeden Bildschirm wird dokumentiert: - Wie kommt der Nutzer dorthin (alle Entry-Points) - Welche Klicks/Aktionen sind moeglich - Wohin fuehrt jeder Klick - Welche Side-Effects gibt es - Welche State-Klassen existieren (sealed class XxxState) - **Alle 1:1-Wortlaute auf dem Screen** (siehe Schicht 4b) → **Detail-Anleitung**: `references/layer-4-screens-and-flows.md` ### Schicht 4b — Wortlaut-Mapping pro Bereich (PFLICHT — Grundlage fuer Rechtssicherheit) Fuer JEDEN Bereich der App werden die exakten Wortlaute extrahiert und einer Tabelle zugeordnet: Screens, Dialoge, Bottom-Sheets, Snackbars, Toasts, Error-States, Empty-States, Loading-States, Push-Notifications, Menues, Settings-Items. **Menues werden rekursiv aufgeloest, beliebige Tiefe.** Wenn Settings einen Eintrag "Konto" hat, der zu "Sicherheit" fuehrt, der wiederum "2FA" enthaelt mit Unter-Optionen "Backup-Codes" → JEDE dieser Ebenen bekommt eine eigene Wortlaut-Tabelle. Keine Abkuerzungen, kein "und so weiter". → **Detail-Anleitung**: `references/layer-4b-wortlaut-mapping.md` ### Schicht 4c — Translation-Context (PFLICHT — Grundlage fuer Uebersetzungs-Skill) Pro Wortlaut werden die Daten erfasst die ein Uebersetzer braucht, damit eine korrekte Lokalisierung moeglich ist: - **Slot-Laengen-Audit** — passt der Text in seinen UI-Slot, wird er nach der Uebersetzung noch passen? - **`translatable="false"`** — welche Strings sind explizit gesperrt (Markennamen, Versionen, URLs) - **`xliff:g`-Tags** — welche Inline-Teile sind nicht-uebersetzbar (Beispiele in Format-Strings) - **XML-Kommentare als Uebersetzer-Notizen** — `` - **CLDR-Plural-Vollstaendigkeit pro Sprache** — Russisch braucht `few`/`many`, Arabisch braucht `zero`/`two` - **HTML/CDATA-Inhalte** — werden bei Uebersetzung oft zerstoert - **Format-Argument-Semantik** — was bedeutet `%1$s`, was `%2$d` - **Glossar-Auto-Erkennung** — haeufige Begriffe die konsistent uebersetzt werden muessen - **Region-Differenzen** — pt-rBR vs pt-rPT, zh-rCN vs zh-rTW - **Du/Sie-Konsistenz** (Deutsch) — Mischanrede wird geflaggt → **Detail-Anleitung**: `references/layer-4c-translation-context.md` ### Schicht 4d — Legal-Text-Inventar (PFLICHT — Grundlage fuer Rechtssicherheits-Skill) 12 rechtlich obligatorische Wortlaut-Bereiche werden vollstaendig erfasst: - Permission-Rationale-Dialoge (pro Permission Title/Body/Allow/Deny-Verhalten) - Consent-Banner (Analytics, Tracking, Marketing — gleichrangige Akzeptieren/Ablehnen-Buttons?) - AGB-, Datenschutz- und Impressums-Links (mit Erreichbarkeit + Sprachvarianten) - Health-Disclaimer (bei Fitness-/Mental-Health-Apps) - AI-Disclaimer (EU AI Act + FTC) - Werbe-Markierungen (UWG §5a — Schleichwerbung) - Account-Deletion-Flow (DSGVO Art. 17 — Wort "unwiderruflich" Pflicht) - Newsletter-/Marketing-Opt-In (UWG §7 Double-Opt-In) - In-App-Kauf-Confirmation (Google Play Subscriptions Policy) - Widerrufsbelehrung (BGB §312g — sonst Frist 12 Monate) - Standort-Begruendung (Play Console seit 2024) - Altersfreigabe-Anzeige (USK/PEGI/IARC) → **Detail-Anleitung**: `references/layer-4d-legal-text-inventory.md` ### Schicht 4e — Externe Inhalte (ergaenzend — Audit ueber die App hinaus) Wortlaute die NICHT im Code-Repository leben aber genauso UWG-/Werberecht-relevant sind: - Google Play Store Listing (Title, Short/Long Description, Screenshot-Texte) — Frank-Aufgabe oder Fastlane-Metadata - Firebase Remote Config Defaults + Live-Werte - Cloud Functions Notification-Templates (Trial-End, Subscription-Status) - Email-Templates (Firebase Auth, Stripe, Sendgrid) - WebView-Inhalte (HTML in assets/ oder externe URLs) - PDF-Export-Vorlagen (oft DE-hardcoded) - Customer-Support-System (Intercom, Zendesk) - Marketing-Materialien (Webseite, Promo-Videos, Social-Media-Bios, Newsletter-Archiv) → **Detail-Anleitung**: `references/layer-4e-external-content.md` ### Schicht 5 — Paywall-Tiefenanalyse: Der WICHTIGSTE Bereich Hier wird mit besonderer Sorgfalt gearbeitet, weil Werbeaussagen rund um die Paywall am haeufigsten rechtlich problematisch sind. Jeder einzelne Subscription-State, jeder Abbruchpfad, jeder Trial-Schritt, jeder Promo-Code, jeder Win-Back-Flow wird dokumentiert. Ergebnis-Tabelle pro Paywall-Bildschirm: - Trigger (wo wird er ausgeloest) - Angezeigte Plaene (Monthly, Yearly, Promo, Trial) - Pflichtangaben (Preis, Laufzeit, Kuendigung, Auto-Renewal) — pro Bildschirm pruefen - Abbruchpfade und was bei jedem passiert - Welcher Subscription-State zeigt welche UI Auch alle 22 Real-Time-Developer-Notification-Typen werden dokumentiert mit ihrem UI-Verhalten. → **Detail-Anleitung**: `references/layer-5-paywall.md` → **Komplette Subscription-State-Machine**: `references/subscription-state-machine.md` ### Schicht 6 — Hidden Features aufdecken Background-Jobs (WorkManager-Worker), Widget-Provider, Quick-Tile-Services, App-Shortcuts, Accessibility-Services, Print-Adapter, NFC-Handler, Boot-Receiver, Notification-Channels, Debug-Menus (Long-Click-Trigger), Feature-Flags via Remote-Config, A/B-Test-Varianten, Account-Deletion-Flows (DSGVO-Pflicht). Diese werden oft in Audits uebersehen. Ohne sie ist das Inventar nicht vollstaendig. → **Detail-Anleitung**: `references/layer-6-hidden-features.md` ### Schicht 7 — Werbeaussagen-vs-Feature-Matrix Jetzt werden die Werbeaussagen aus diesen Quellen zusammengetragen: - `res/values/strings.xml` (alle User-facing Texte) - `res/values-*/strings.xml` (alle Sprachen) - Google Play Store Listing (Long Description, Short Description, Feature-Bullets) - Onboarding-Texte - Push-Notification-Templates - Settings-Texte Fuer jede Aussage wird gegen das Feature-Inventar geprueft. Output-Tabelle: | Aussage | Quelle | Code-Realitaet | Luecke | Risiko (UWG/EU/Google) | Fix-Vorschlag | Risiko-Stufen: KRITISCH / HOCH / MITTEL / NIEDRIG nach UWG §5, EU UCPD, Google Play Policy. → **Detail-Anleitung**: `references/layer-7-marketing-claim-audit.md` ## 15 parallele Worker — Standard-Architektur (FIN-023, Frank-Direktive 2026-05-18) Statt die 7 Schichten sequenziell abzuarbeiten, werden **15 spezialisierte Worker parallel** gestartet. Jeder Worker hat Token-Cap 100k. Sobald ein Worker abgeschlossen ist, wird sofort der nächste für den nächsten Layer oder das nächste Modul gespawnt (Continuous-Spawning). Der Synthesizer aggregiert am Ende alle 14 Fach-Worker-Ergebnisse zu `roentgen-report.json`. ### Die 15 Worker im Überblick | # | Worker-Name | Zuständigkeit | |---|------------|--------------| | 1 | **Manifest-Worker** | `AndroidManifest.xml` — Permissions, Activities, Services, Receivers, ContentProvider, Intent-Filter, Deep-Links, Backup-Konfiguration | | 2 | **Build-Config-Worker** | `build.gradle.kts`, `libs.versions.toml`, `settings.gradle.kts` — Dependencies, Plugins, Version-Catalog, aktive vs. tote Libs | | 3 | **Architecture-Worker** | Module-Struktur, ViewModels, Repositories, UseCases, Hilt-Module, Room-Entities, Dagger-Graphen | | 4 | **Screens-Worker** | Alle Compose-Screens und Activity-Klassen identifizieren, Navigation-Routen, Click-Handler, Side-Effects | | 5 | **Dialogs-Worker** | Alle Dialoge, Bottom-Sheets, Snackbars, Toasts, Error-States, Empty-States, Loading-States | | 6 | **Paywall-Worker** | BillingClient, Subscription-Logik, alle 22 RTDN-Typen, Trial/Promo/Win-Back, Abbruchpfade, Subscription-State-Machine | | 7 | **Permissions-Rationale-Worker** | Permission-Rationale-Dialoge pro Permission (Title/Body/Allow/Deny), Consent-Banner, Health-Disclaimer, AI-Disclaimer | | 8 | **Strings-Inventory-Worker-A** | `strings.xml` Einträge 1–500 (alle String-Keys + 1:1-Wortlaute + Format-Args + xliff:g) | | 9 | **Strings-Inventory-Worker-B** | `strings.xml` Einträge 501–1000 | | 10 | **Strings-Inventory-Worker-C** | `strings.xml` Eintrag 1001 bis Ende (inkl. aller `values-*/strings.xml` Sprachvarianten) | | 11 | **Compose-Literals-Worker** | Hardcoded Texte direkt in `.kt`-Dateien (nicht über `stringResource`) — für den `string-extraktor`-Skill | | 12 | **Assets-Worker** | `assets/**/*.{html,htm,md,txt}` — Legal-Dokumente, Onboarding-HTML, Sprach-Detection, Doktyp-Detection (FIN-014) | | 13 | **Hidden-Features-Worker** | WorkManager-Worker, BootReceiver, FileProvider, Widget-Provider, Quick-Tile, App-Shortcuts, Notification-Channels, Debug-Menüs, Feature-Flags, A/B-Varianten, Account-Deletion-Flow | | 14 | **Marketing-Claims-Worker** | Werbeaussagen aus allen Quellen (strings.xml User-facing, Onboarding, Push-Templates, Settings) + Play-Store-Listing-Texte + Risikobewertung nach UWG §5 / EU UCPD / Google Play Policy | | 15 | **Synthesizer** | Aggregiert die Ergebnisse der Worker 1–14, schreibt `roentgen-report.json` (Schema 2.1) und `app-roentgen-AUDIT-YYYY-MM-DD.md`, führt Vollständigkeits-Validierung durch | ### Continuous-Spawning-Regel - Für größere Apps (>3 Module oder >1000 Strings) gilt: sobald ein Worker sein Ergebnis zurückgibt, wird sofort ein Folge-Worker für das nächste Modul/das nächste String-Segment gespawnt. - Beispiel: Modul-1-Screens-Worker fertig → sofort Modul-2-Screens-Worker starten, während die anderen Worker noch laufen. - Workers 8/9/10 (Strings A/B/C) laufen grundsätzlich parallel, nie sequenziell. - Der Synthesizer (Worker 15) startet erst wenn **alle** anderen 14 Worker zurückgemeldet haben. ### Datei-Ownership (kein Worker darf die Datei eines anderen überschreiben) | Worker-Gruppe | Schreibt in | |--------------|------------| | Worker 1–14 | jeweils eigenen Temp-Slot in `roentgen-checkpoint.json` (Feld `worker_results[N]`) | | Synthesizer (15) | `roentgen-report.json` + `app-roentgen-AUDIT-YYYY-MM-DD.md` | ## Master-Skript fuer den ersten Scan Statt alle Greppable-Patterns einzeln auszufuehren, gibt es ein Master-Skript das den ersten Scan automatisiert macht und einen strukturierten Initial-Bericht erzeugt: ```bash bash ~/.claude/skills/app-roentgen/scripts/feature-scan.sh ``` Das Skript schreibt einen Initial-Bericht ins App-Verzeichnis als `app-roentgen-initial-scan.md`. Dieser ist die Basis fuer die Tiefenanalyse durch Claude in den 7 Schichten. ## JSON-Schnittstelle fuer maschinelle Konsumenten Parallel zum Markdown-Bericht kann ein strukturierter JSON-Export erzeugt werden, den der Rechtssicherheits-Skill und der Uebersetzungs-Skill konsumieren koennen: ```bash python3 ~/.claude/skills/app-roentgen/scripts/export-json.py ``` Output: `/app-roentgen-export.json` mit Schema-Version 2.1. Der Export enthaelt: alle Strings mit Hash + Translatable-Flag + Format-Args + xliff:g-IDs + Slot-Laenge, Plurals mit CLDR-Vollstaendigkeitspruefung pro Sprache, Glossar, Du/Sie-Konsistenz, SDK-Erkennung (AI/Ads/Billing/Health/WebView/Firebase), Permission-Liste. Der JSON-Export ist optional — er wird nur erzeugt wenn der Konsument ihn explizit braucht. Das Markdown-Format reicht fuer den manuellen Audit. ## Output-Format des finalen Berichts Der finale Bericht wird in der App-Wurzel als `app-roentgen-AUDIT-YYYY-MM-DD.md` gespeichert. Die Struktur folgt dem Template `assets/audit-report-template.md`. Pflichtbestandteile: 1. **Zusammenfassung** (3-4 Saetze fuer Frank in einfachem Deutsch) 2. **Schicht 1-7 Detail-Berichte** mit allen extrahierten Daten 3. **Komplette Bildschirm-Karte** (Mermaid + Baum) 4. **Paywall-Bildschirm-Inventar** (sehr detailliert, eigener Hauptabschnitt) 5. **15-Kategorien-Feature-Inventar** (siehe `references/layer-7-marketing-claim-audit.md`) 6. **Werbeaussage-vs-Feature-Matrix** (sortiert nach Risiko) 7. **Don't-Miss-Checkliste** mit Haken pro Punkt (siehe `references/dont-miss-checklist.md`) 8. **Empfohlene naechste Schritte** (was muss vor Release gefixt werden) ## Bekannte Limitierungen (Known Limitations) > **FIX V6 + W5 (Audit 5+6):** Folgende Punkte sind dokumentierte Trade-Offs, keine Bugs: > > - **`` und ``/`` in strings.xml werden NICHT exportiert** (FIX W5): Diese Resource-Typen enthalten keine UI-Texte und sind fuer Werbeaussagen-/Rechtsaudit irrelevant. ``, `` und `` werden vollstaendig erfasst. > > - **audit-report-template.md ist ~1200 Zeilen** (Section-Skeleton mit allen 7 Schichten + 4 Sub-Layern + Checkliste). Beim Schreiben des finalen Berichts laedt Claude die komplette Datei in den Kontext. Bei sehr grossen Apps (>3000 Kotlin-Dateien) plus den Reference-Dateien kann Context-Druck entstehen. Loesung: Bericht inkrementell pro Schicht schreiben statt komplett auf einmal. > - **17 Reference-Dateien** sind absichtlich granular (Progressive Disclosure) — Claude laedt nur was sie braucht. Wenn eine Schicht uebersprungen wird, bleibt die zugehoerige Reference ungeladen. > - **`feature-scan.sh` ist ein Shell-Skript** — auf Windows nur in Git Bash, nicht PowerShell. JSON-Export per Python ist plattformunabhaengig. ## Checkpoint-Mechanik fuer lange Audits (KRITISCH bei grossen Apps) Audits einer mittelgrossen App (500-1500 Kotlin-Dateien) dauern 30-90 Minuten. Vor JEDER neuen Schicht (1, 2, 3, 3b optional, 4, 4b-4e, 5, 6, 7) MUSS eine Checkpoint-Datei `/app-roentgen-checkpoint.json` geschrieben werden. Bei Wiederaufnahme: Checkpoint lesen, bei `current_phase` fortsetzen, erledigte Phasen NICHT erneut bearbeiten. → **Komplettes JSON-Schema, Phasen-Liste, Gitignore-Hinweise**: `references/checkpoint-format.md` ## Vollstaendigkeits-Validierung (PFLICHT) Bevor der Bericht als fertig gilt, MUSS die `dont-miss-checklist.md` durchgegangen werden — alle 92 Punkte muessen geprueft sein. Jeder Punkt der nicht geprueft werden konnte wird mit "NICHT_VERIFIZIERT — Grund" markiert. Das ist die letzte Verteidigungslinie gegen unvollstaendige Audits. → **Liste**: `references/dont-miss-checklist.md` ## Verhalten bei Unklarheit Wenn ein Code-Pfad mehrdeutig ist und der Skill nicht eindeutig sagen kann was die App macht, MUSS das im Bericht als "UNKLAR — bitte manuell pruefen" markiert werden. Lieber ehrlich Luecken zugeben als fadenscheinige Vermutungen abgeben — der Audit ist die Basis fuer Rechtssicherheit, da darf nichts verfaelscht sein. ## Greppable-Patterns als Werkzeugkasten Alle systematischen Suchmuster sind in `references/greppable-patterns.md` gesammelt. Diese Datei ist die taktische Referenz — sie wird vom Master-Skript genutzt und kann auch manuell konsultiert werden wenn ein bestimmter Bereich noch tiefer untersucht werden soll. → **Patterns**: `references/greppable-patterns.md` ## Beispiel-Anwendung: BestJournalAndroid Der typische erste Anwendungsfall fuer Frank ist `~/proggs/BestJournalAndroid/`. Beim ersten Lauf werden die Ergebnisse in `~/proggs/BestJournalAndroid/app-roentgen-AUDIT-YYYY-MM-DD.md` geschrieben. Das ist die Vorlage fuer den nachfolgenden Werbeaussagen-Audit (Memory `project_bestjournal_paywall_marketing_audit.md`). ## Schreibstil im Bericht Da der Bericht spaeter als juristische Grundlage dienen kann, gilt: - **Praezise**: Keine Vermutungen ohne Beleg. Jede Aussage mit Datei + Zeilennummer belegen. - **Vollstaendig**: Lieber zu viele Details als zu wenige. - **Strukturiert**: Tabellen wo immer moeglich, damit der Leser scannen kann. - **Ehrlich**: Wenn etwas unklar ist, das ausdruecklich vermerken. - **Auf Deutsch fuer die Zusammenfassungs-Bloecke**, technische Bezeichner und Code-Snippets bleiben in Originalsprache. ## Zusammenspiel mit anderen Skills | Skill | Zusammenspiel | |-------|--------------| | `rechtssicherheit` | Liest Schicht 4b (Wortlaute) + Schicht 7 (Werbeaussagen-Matrix) und prueft gegen die Wissensbasis in `~/proggs/rechtssicherheit.md` | | `uebersetzung` | Liest Schicht 4b (Original-Wortlaute) + Schicht 4c (Translation-Context: Slot, Laenge, Plurals, Glossar, Argumente) als Uebersetzungs-Grundlage | | `string-extraktor` | Komplementaer zu Schicht 4c — der Extraktor findet hardcoded Strings, der Roentgen-Skill katalogisiert sie inklusive Slot-Zuordnung | | `app-monetizer` | Konsumiert die Paywall-Tiefenanalyse (Schicht 5) als Input | | `superintelligenz` | Bei sehr grossen Apps (>500 Kotlin-Dateien) parallele Researcher fuer einzelne Schichten spawnen | ## Umlaut-Pflicht im Skill-Output (FIN-027, Frank-Direktive 2026-05-18) In allen deutschen Texten die der Skill produziert MÜSSEN echte Umlaute verwendet werden: **Pflicht:** ä ö ü Ä Ö Ü ß **Verboten:** ae oe ue Ae Oe Ue ss (als Umlaut-Ersatz) ### Wo die Pflicht gilt | Output-Datei | Betroffene Felder | |-------------|------------------| | `roentgen-report.json` | `rationale`-Felder, `claim`-Texte, `description`-Felder, alle deutschen Kommentare | | `app-roentgen-AUDIT-YYYY-MM-DD.md` | Alle deutschen Fließtext-Abschnitte, Tabellen-Einträge, Zusammenfassungen | | `app-roentgen-initial-scan.md` | Vollständig | | `audit-log.md` | Alle Einträge | | `roentgen-checkpoint.json` | Deutsche Status-/Beschreibungsfelder | | Alle sonstigen Frank-sichtbaren Texte | Vollständig | ### Ausnahmen (ASCII bleibt erlaubt) - Dateinamen und Verzeichnispfade - Code-Variablen, Funktionsnamen, String-Resource-Keys - 1:1-zitierte Wortlaute aus dem Quellcode (die werden unverändert übernommen) - Eigennamen und Markennamen die "ae/oe/ue" als lateinische Transkription enthalten (z.B. "Goethe") ### Verifikation nach jedem Skill-Output ```bash # Grep auf verdächtige ASCII-Substitutionen in deutschen Text-Blöcken grep -nE '\b(ae|oe|ue|ss)\b' | grep -v '#\|//\|R\.string\|strings\.xml' ``` Falls Treffer in zweifelsfreien deutschen Wörtern (z.B. "uebersetzen", "ausfuehren", "Strasse"): Auto-Convert vor Abgabe des Berichts. Bei Eigennamen und Code-Bezeichnern: unverändert lassen. ## Was NIEMALS passieren darf - ❌ Audit als "fertig" markieren ohne die Don't-Miss-Checkliste durchgegangen zu sein - ❌ Werbeaussagen aus nur einer Sprache pruefen — IMMER alle uebersetzten strings.xml einbeziehen - ❌ Paywall-Bildschirme oberflaechlich abhaken — jeder Bildschirm bekommt eine eigene Sub-Tabelle - ❌ Vermutungen ohne Code-Beleg im Bericht stehen lassen - ❌ Versteckte Features (Feature-Flags, Debug-Menus, Background-Jobs) wegen Aufwand auslassen - ❌ Bei Unklarheit raten — stattdessen "UNKLAR" markieren und dem Benutzer melden - ❌ Wortlaute zusammenfassen, paraphrasieren oder kuerzen — IMMER 1:1 in `"..."` zitieren - ❌ Nur den String-Key nennen ohne den Wortlaut auszuschreiben - ❌ Menue-Tiefen abkuerzen mit "und weitere Untermenues" — JEDE Ebene komplett ausrollen, egal wie tief - ❌ Settings/Preferences als Sammelblock abhandeln — jedes Item bekommt eine eigene Zeile mit Label + Beschreibung + ggf. Switch-/Dropdown-Werten - ❌ Dialog-Texte nur teilweise zitieren (z.B. nur Title) — IMMER Title + Body + alle Buttons komplett - ❌ Plurals, Format-Strings (`%s`, `%d`) und Array-Resources ignorieren