vipink1203/app-compliance

Was macht app-compliance?

Jede App durchläuft diese Prüfungen (Gates), bevor sie zu echten Nutzern gelangt, und durchläuft sie bei jeder Änderung erneut. Ein Gate ist eine Verpflichtung mit einer Regel, was zu bauen ist, und einem „Erledigt, wenn“-Check. Der Status jedes Gates landet im Compliance-Record des Projekts, sodass nichts auf Memory oder guten Vorsätzen basiert.

Dies ist technische Umsetzung auf Basis recherchierter Rechtsquellen, keine Rechtsberatung. Die Regeln stammen aus den mit Quellenangaben versehenen Notizen in research/, datiert auf den 31.10.2026: 01 Datenschutz und Einwilligung, 02 Handel und Behauptungen und 03 Barrierefreiheit, IP und KI. Wenn eine Notiz zum Zeitpunkt der Ausführung älter als 6 Monate ist, überprüfen Sie die in den von Ihnen verwendeten Abschnitten zitierten Primärquellen (mit einer Research-Skill, falls vorhanden) erneut, bevor Sie deren Daten und Schwellenwerte als aktuell behandeln.

Grundsätze

• Ein Build für alle. Bauen Sie für jeden Nutzer nach dem strengsten gemeinsamen Standard (GDPR für Datenschutz, Kalifornien für Abos und Preisangaben, WCAG 2.2 AA für Barrierefreiheit), anstatt nach Ländern zu verzweigen.
• Die Datenkarte ist die Wahrheit. Rechtstexte, Einwilligungsaufforderungen und die Anbieterliste beschreiben, was der Code und die Live-App tatsächlich tun – ermittelt durch Lesen des Codes und Erfassen des Traffics – niemals das, was eine Vorlage annimmt. Wenn sich die App ändert, ändern sich die Seiten im selben Commit.
• Beweise oder nichts. Jede Behauptung, jedes Gütesiegel, Logo, jede Bewertung und Zahl in der App verweist auf einen Beweiseintrag im Record.
• Eigentümer entscheidet, Agent entwirft. Der Agent schreibt Seiten, Code und Tests; Unterschriften, Registrierungen, Berechtigungen und rechtliche Beurteilungen sind Handlungen des Eigentümers, und der Agent markiert niemals eine davon als erledigt im Namen des Eigentümers.

Schritte

1. Daten kartieren. Erstellen Sie die Datenkarte im Compliance-Record aus dem Code und einem Live-Durchlauf: jedes Formularfeld und jeder API-Eingabepunkt mit personenbezogenen Daten, jede Datenbankspalte oder jeder Speicher, der diese Daten enthält, jeder Cookie und jeder localStorage/sessionStorage/IndexedDB-Schlüssel, jede von der App aufgerufene Domain (erfassen Sie ein Playwright-HAR aller Routen und einen Proxy-Mitschnitt wie mitmproxy einer frischen mobilen Installation), jedes SDK im Abhängigkeitsbaum und jede von der App gesendete E-Mail. Für jedes Element: Zweck, Rechtsgrundlage, Speicherort, Aufbewahrungsfrist und welcher Anbieter es erhält. Erledigt, wenn die Code-Suche und das HAR nichts zeigen, was nicht in der Karte enthalten ist.
2. Umfang festlegen. Beantworten Sie im Record: Wer sind die Nutzer (Verbraucher, Unternehmen, Kinder möglich)? Wo (USA, EU/UK, sonstiges)? Wie groß ist das Unternehmen (Mitarbeiter, Umsatz)? Nimmt es Zahlungen oder Abos entgegen? Versendet es Marketing-E-Mails? Speichert es von Nutzern bereitgestellte Inhalte (Beiträge, Kommentare, Dateien, Profile, Avatare)? Zeigt es KI-Ausgaben oder einen KI-Chat an? Verarbeitet es Gesundheits-, Finanz-, biometrische oder genaue Standortdaten? Ein „Ja“ bei sensiblen Daten oder Kindern fügt eine anwaltliche Prüfung zu den Eigentümeraktionen hinzu.
3. Jedes Gate durchgehen. Lesen Sie jede untenstehende Gate-Datei und vergeben Sie für jedes Gate einen Status: pass (bestanden), fail (nicht bestanden), n/a (nicht zutreffend, mit der Umfangsantwort, die es ausschließt) oder owner (wartet auf eine Aktion des Eigentümers).
   • gates/privacy.md: Datenschutzerklärung, Datenminimierung, Aufbewahrung, Auskunfts- und Löschungsanfragen, Kinder, KI-Training mit Nutzerdaten, Anbieter, Auftragsverarbeitungsverträge und Unterauftragsverarbeiter (PRIV).
   • gates/consent-and-tracking.md: Cookie-Banner, Blockieren von Trackern vor Einwilligung, Opt-Out-Signale, separate Marketing-Einwilligung (CONSENT).
   • gates/terms-and-payments.md: AGB-Akzeptanz und deren Aufzeichnung, vollständige Preise, Rückerstattungen, automatische Verlängerung, Kündigung, EU-Widerrufsrecht (TERMS, PAY).
   • gates/marketing-and-claims.md: Behauptungen, Sicherheitssiegel, Bewertungen, Logos, Verfügbarkeit, Dringlichkeit, Dark Patterns, Geschäftsangaben, Marketing-E-Mails (CLAIM, UX, BIZ, EMAIL).
   • gates/accessibility.md: WCAG 2.2 AA-Scan, Kontrast, Alternativtexte, Tastatur, Fokus, Timing und Zielgrößen, EU-Barrierefreiheitserklärung (A11Y).
   • gates/licenses-and-content.md: Lizenzen für Code, Schriftarten, Bilder und Symbole, Melden und Entfernen von Nutzerinhalten (LIC, UGC).
   • gates/ai.md: Offenlegung von KI-Chats, Kennzeichnung und Markierung generierter Inhalte (AI).
4. Beheben und nachweisen. Bauen Sie das, was jedes fail erfordert, und führen Sie dann den zugehörigen „Erledigt, wenn“-Check durch: automatisierte Prüfungen als Tests in der Projekt-Suite, sodass sie weiterlaufen; manuelle Prüfungen mit Datum und Ergebnis dokumentiert. Erledigt, wenn jedes Gate den Status pass, n/a oder owner hat und kein fail mehr übrig ist.
5. Übergeben. Schreiben Sie die Liste der Eigentümeraktionen an den Anfang des Records und teilen Sie dem Eigentümer diese in der Sitzung mit, jede Aktion in einer Zeile: Was zu tun ist, warum und wo.

Bei einer späteren Änderung wiederholen Sie die Schritte 1 und 3 bis 5 für die Gate-Dateien, die von der Änderung betroffen sind, und aktualisieren Sie den Record im selben Commit.

Der Compliance-Record

Jede App führt einen Record unter docs/compliance.md in ihrem Repository, der direkt aktualisiert wird und auf der record-template.md basiert. Er enthält die Umfangsangaben, die Datenkarte, den Status jedes Gates mit Nachweisen, die Beweiseinträge, das Asset-Register und die Eigentümeraktionen. Eine App wird nur dann gestartet, wenn ihr Record kein fail aufweist und der Eigentümer jede offene Eigentümeraktion entweder abgeschlossen oder explizit akzeptiert hat.