Ajit-ApTech/premium-glass-android

Premium Glass für Android

Ziel: eine Oberfläche, die sich ruhig, räumlich und hochwertig anfühlt. Glas ist ein Material für die Steuerelemente, die über dem Inhalt schweben. Es ist kein Stil, der überall verteilt wird. Erfolgstest: Leute sagen „das fühlt sich sauber und geschichtet an“, niemals „jemand hat überall Unschärfe hinzugefügt“.

Diese Fähigkeit steuert Material, Hierarchie, Tiefe, Bewegung und Barrierefreiheit. Die Marke des Projekts steuert Identität und Text. Standard-Markenwerte befinden sich in assets/tokens.json (Palette beibehalten) und können ersetzt werden.

0. Sicherheit und Umfang

• Arbeiten Sie nur innerhalb des vom Benutzer ausgewählten Projekts. Lesen Sie keine Geheimnisse, Schlüssel oder Umgebungsvariablen aus. Führen Sie keine Netzwerkanfragen durch und installieren Sie keine Pakete; wenn eine Bibliothek benötigt wird, nennen Sie sie und lassen Sie den Benutzer entscheiden.
• Überschreiben Sie keine vorhandenen Dateien ohne Aufforderung; schlagen Sie zuerst vor (Abschnitt 2).
• Verwenden Sie nur fiktive Beispielinhalte.
• Verwenden Sie niemals Apple-Schriftarten (San Francisco), SF-Symbole, Apple-Logos oder iOS-Chrome. Verwenden Sie Inter und Material Symbols/Lucide-Stil-Icons.
• Fakten, die mit (VERIFY) gekennzeichnet sind, können veralten (APIs, Versionen). Sagen Sie dem Benutzer, sie zu bestätigen.

1. Die fünf harten Regeln

1. Inhalt ist niemals Glas. Karten, Listeneinträge, Formulare, Seitenhintergründe und Medien bleiben opak oder weiche Oberfläche.
2. Glas nur auf der schwebenden Ebene: Bottom-Navigation-Pille, obere Leiste über scrollendem Inhalt, schwebender Aktionsbutton, Bottom-Sheets und Menüs, Suchfeld, Toasts/Snackbars, kleine schwebende Chips.
3. Niemals Glas auf Glas. Trennen Sie innerhalb einer Glasoberfläche Elemente durch Füllungen, Trennlinien oder Transparenz.
4. Lesbarkeit geht vor Aussehen. Fließtext benötigt 4.5:1 (große Texte und Symbole 3:1) gegenüber dem schlechtestmöglichen Hintergrund. Führen Sie scripts/contrast_check.py aus.
5. Jede Glasoberfläche hat einen soliden Fallback (altes Android, Transparenz reduzieren, hoher Kontrast, Energiesparmodus, Unschärfe vom Gerät deaktiviert).

Gate-Frage vor dem Anwenden von Glas auf ein Element: „Welche funktionale Rolle vermittelt dieses Material?“ Gültige Antworten: Es schwebt über scrollendem Inhalt; es ist vorübergehend oder kontextabhängig; es muss erreichbar bleiben, während sich Inhalt darunter bewegt. Keine Antwort = kein Glas.

2. Arbeitsablauf

1. Prüfen: Plattform, min/target SDK, vorhandenes Theme/Tokens, Navigationsstruktur, Barrierefreiheitsanforderungen, Leistungsziele. Offene Fragen auflisten, anstatt zu raten.
2. Ebenenkarte (vor jedem Code): Tabelle der Elemente -> Ebene (Inhalt / Struktur / schwebend) -> Glas ja/nein -> Stufe -> Begründung. Präsentieren Sie sie mit dem Plan.
3. Tokens: Beginnen Sie mit assets/tokens.json; passen Sie Markenfarben an; führen Sie den Kontrastcheck für jede Stufe in beiden Modi erneut aus.
4. Bauen Sie mit den Vorlagen in assets/GlassTheme.kt und der Anleitung in references/compose-implementation.md.
5. Überprüfen Sie mit references/review-checklist.md und scripts/audit_compose.py. Berichten Sie über Belege (Kontrastwerte, Glas-Ebenen-Anzahl pro Bildschirm, Fallback-Screenshots). Behaupten Sie nicht, dass ein Check bestanden wurde, ohne Belege.

3. Materialstufen (Startwerte, dp)

Stufe	Verwendung	Unschärfe	Füllung (dunkel)	Füllung (hell)
keine	Inhalt, Karten, Listen, Hintergründe	-	-	-
dünn	Nur-Symbol- oder große-Beschriftung-Steuerelemente	16	Tinte @ 0,55	weiß @ 0,55
regelmäßig	Nav-Pille, obere Leiste, Suche, FAB, Toasts	24	Tinte @ 0,66	weiß @ 0,70
dick	Sheets, Menüs, Dialoge, textlastige Overlays	32	Tinte @ 0,78	weiß @ 0,82
Scrim	Abdunkelung hinter modalen Sheets	0-8	schwarz @ 0,20-0,45	schwarz @ 0,20-0,45
Details und geprüfte Kontrastzahlen: references/tokens.md. Füllungen werden mit der Tintenfarbe der Oberfläche getönt, nicht mit reinem Weiß, sodass Text im Dunkelmodus auf hellen Hintergründen überlebt.

4. Android-Realitätscheck (vor dem Versprechen von irgendetwas lesen)

• Modifier.blur() / RenderEffect verwischen den eigenen Inhalt des Elements, nicht das, was dahinter ist. Echter Hintergrundunschärfe benötigt eine Bibliothek (Haze ist Apache-2.0 und unterstützt Compose auf Android) oder Fensterunschärfe für Dialoge. Die API-Namen von Bibliotheken ändern sich zwischen Versionen: Lesen Sie die README der installierten Version (VERIFY).
• Unschärfeeffekte benötigen Android 12 (API 31) oder höher (VERIFY). Darunter verwenden Sie die solide Fallback-Oberfläche.
• Modale Bottom-Sheets und Dialoge befinden sich in einem separaten Fenster, daher kann die Hintergrundunschärfe innerhalb der Komposition den Inhalt dahinter möglicherweise nicht sehen. Verwenden Sie Fensterhintergrundunschärfe, wo unterstützt, und prüfen Sie WindowManager.isCrossWindowBlurEnabled (VERIFY), andernfalls ein dickes, nahezu opakes Sheet mit einem Scrim.
• Unschärfe über einem flachen Farbverlauf ist unsichtbar; Glas benötigt Struktur dahinter (Inhalt, Bilder oder einen bewussten sanften Glanz). Sonst kostet es Leistung für nichts.
• Budget: höchstens 2-3 gleichzeitige verschwommene Ebenen pro Bildschirm (1-2 auf Low-End-Telefonen). Verwischen Sie niemals Listenelemente oder ganze Bildschirme. Animieren Sie den Unschärferadius nicht auf großen Oberflächen; animieren Sie Alpha oder Transformation.
• Testen Sie auf einem Low-End-Telefon (3-4 GB RAM) in einem release-ähnlichen Build.

5. Barrierefreiheitsmodi (alle implementieren)

• Transparenz reduzieren (In-App-Einstellung + System „Bewegungen entfernen“/hoher Kontrast-Signale): Glas gegen solide Oberflächentoken mit einem sichtbaren 1 dp Rand austauschen.
• Große Schrift (200%) und TalkBack: keine Informationen nur in Farbe; Beschriftungen auf reinen Symbolsteuerelementen; Fokus-Reihenfolge sinnvoll.
• Reduzierte Bewegung: Bewegung durch Überblendungen ersetzen; Zustandsfeedback beibehalten.
• Berührungsziele mindestens 48 dp. Gesten (Wischen) haben immer eine Schaltfläche oder customActions-Alternative.

6. Komponenten

Spezifikationen für Navigationspille, obere Leiste, FAB, Sheets, Suchfeld, Chips, Karten, Wischzeilen, Triage-Stapel, Chat-Eingabe, maskierte Wert-Chips: references/components.md. Verwenden Sie einen Radius pro Rolle (Chip 999, Steuerelement 16, Karte 24, Nav-Pille 28, Sheet 32); verschachtelter Radius = äußerer Radius - Abstand.

7. Bewegung

Federn 250-350 ms, kurze Überblendungen 150 ms, kein Überschwingen. Haptischer Ticken beim Wisch-Schwellenwert. Gedrückter Zustand: Skalierung 0,97 plus eine sanfte Hervorhebung. Reduzierte Bewegung respektieren.

8. Bild-Prompt-Modus (Referenzbildschirme)

Wenn nach Mock-up-Prompts gefragt wird, folgen Sie references/image-prompts.md: ein Bildschirm pro Prompt, eigenständiger Stilblock, exakter Text auf dem Bildschirm, Glas nur auf der schwebenden Ebene, „Karten sind opak“, Android-Statusleiste, keine Apple-Elemente. Sechs ausgearbeitete Bildschirm-Prompts befinden sich in der Referenz. Erinnern Sie den Benutzer daran, dass Generatoren kleinen Text und Devanagari verstümmeln; verwenden Sie Ausgaben als Layout- und Stimmungsreferenzen, dann bauen Sie in Figma/Compose neu auf.

9. Überprüfungsmodus

Wenn aufgefordert, ein Design oder einen Code zu überprüfen: klassifizieren Sie jedes Element nach Ebene, zählen Sie die Glas-Ebenen pro Bildschirm, führen Sie das Audit-Skript aus (python scripts/audit_compose.py <src>), führen Sie das Kontrast-Skript aus, listen Sie dann die Ergebnisse nach Schweregrad auf, mit der Korrektur aus references/review-checklist.md.

10. Ausgabeerwartungen

Geben Sie für jede Aufgabe an: was ist Glas und warum; welche Stufe; Kontrastbelege; Fallbacks; alles Näherungsweise oder Ungeprüfte. Halten Sie Änderungen begrenzt: Redesignen Sie keine nicht zusammenhängende UX; listen Sie nicht zusammenhängende Probleme separat auf.

Referenzen und Dateien

• references/principles.md - Von Apple abgeleitete Prinzipien und Quellen
• references/tokens.md - Token-Tabellen und geprüfte Kontrastergebnisse
• references/compose-implementation.md - Compose-Architektur, Codeausschnitte, Fallbacks, Leistung
• references/components.md - Komponentenspezifikationen und Zustände
• references/image-prompts.md - Prompt-Vorlage und Arbeitsablauf
• references/review-checklist.md - Qualitätsprtüfungen und Anti-Patterns
• scripts/contrast_check.py, scripts/audit_compose.py - lokale Prüfungen (kein Netzwerk)
• assets/tokens.json, assets/GlassTheme.kt (optional: das 45-Bildschirm-Retain-Promptset als assets/retain-screen-prompts.md hinzufügen)