# AI-References Tags: #AIReference Diese Datei ist der Startkontext fuer AI-Arbeit an den Subframe UI Standards. Sie beschreibt, wie das Standards-Projekt aufgebaut ist und welcher Ablauf bei Aenderungen eingehalten werden muss. ## HiveGrid-Integration Die Subframe UI Standards liegen als eigenes Standards-Projekt im HiveGrid-Wireframe-Repo. Vor jeder Arbeit an diesem Standards-Projekt muss [[00_HiveGrid-Einordnung]] gelesen werden. Wichtig: - Normale HiveGrid-Screen- oder Flow-Arbeit darf dieses Standards-Projekt nicht automatisch veraendern. - Aenderungen an den Standards brauchen eine explizite Aufgabe oder eine vorher validierte Entscheidung von David. - Werte aus Screen-Paketen, D-D0b oder Subframe-Screens werden erst dann globale Regeln, wenn David sie explizit validiert. - Die Standards sind nicht der Ort fuer Ticket-spezifische UX-Entscheidungen; diese bleiben in den Wireframe-Paketen. - Dauerhafte Layout-, Komponenten- oder Subframe-Konventionen koennen hier dokumentiert werden, wenn sie als systemweite Regel validiert sind. ## Projektstruktur | Bereich | Zweck | | --- | --- | | [[00_HiveGrid-Einordnung]] | Einordnung im HiveGrid-Repo, Zweck, Abgrenzung und Aenderungsschutz | | [[00_Start]] | Einstieg und kurze Orientierung fuer die Subframe UI Standards | | [[01_Brainstorming]] | Offene Ideen, Fragen und noch nicht entschiedene Punkte | | [[02_Entscheidungen]] | Entscheidungslog fuer final getroffene Entscheidungen | | [[03_Benennung]] | Allgemeines Vokabular fuer Namen, States, Varianten und Sizes | | [[04_Gruppenregeln]] | Wiederverwendbare Regeln fuer Komponenten-Gruppen | | [[05_Komponenten-Index]] | Link- und Statusuebersicht fuer Komponenten | | [[06_Backlog]] | Spaetere Aufgaben, offene Themen und Erweiterungen | | [[07_Global-Rules]] | Globale Component-API- und Arbeitsregeln | | [[08_Todo]] | Laufende Aufgaben, Pruefpunkte und Nacharbeiten | | [[AI/08_AI-Change-History]] | AI-Verlauf nur fuer Aenderungen am Subframe UI Standards / Component Library Regelwerk | | `Layout/` | Validierte Layout-, Spacing-, Dialog-, Table- und Composition-Regeln | | `Components/` | Einzelne Komponenten-Notizen mit Subframe-Link, Bereich, Notizen und Regel-Referenzen | ## AI-Dateien Alle Dateien, die nur fuer AI-Arbeitskontext, AI-Verlauf oder AI-Pflege gedacht sind, tragen den Tag `#AIReference`. Neue AI-Dateien muessen diesen Tag ebenfalls bekommen. ## Regel 1: Gruppenregeln gezielt referenzieren Jede wiederverwendbare Regel in [[04_Gruppenregeln]] muss eine eigene Ueberschrift haben. Jeder Bereich in [[04_Gruppenregeln]] muss ebenfalls eine eigene Ueberschrift haben. Wenn eine Komponente von einer Gruppenregel betroffen ist, soll die Komponenten-Datei nicht nur pauschal auf [[04_Gruppenregeln]] verweisen. Sie soll die konkrete Regel referenzieren. Bevorzugte Referenz als Obsidian-Embed: ```md ![[04_Gruppenregeln#Regel: Control-Hoehen fuer Button und Form Inputs]] ``` Alternative als normaler Link: ```md [[04_Gruppenregeln#Regel: Control-Hoehen fuer Button und Form Inputs]] ``` Wenn eine Komponente mehrere Regeln betrifft, werden alle passenden Regel-Referenzen in der Komponenten-Datei gelistet. ## Regel 2: Global Rules pauschal verlinken Globale Regeln aus [[07_Global-Rules]] gelten projektweit. Sie werden in Komponenten-Dateien nur pauschal direkt nach [[03_Benennung]] verlinkt. ```md - [[03_Benennung]] - [[07_Global-Rules]] ``` Keine einzelnen Heading-Embeds fuer Global Rules in Komponenten-Dateien anlegen, ausser das wird spaeter bewusst entschieden. Spezifische Obsidian-Embeds bleiben fuer Gruppenregeln aus [[04_Gruppenregeln]] reserviert. ## Regel 3: Layout-Regeln bei Subframe-MCP-Arbeit verwenden Bei jeder Subframe-MCP-Arbeit an HiveGrid-Screens, Dialogen oder Varianten muessen die validierten Layout-Regeln als aktive Referenz genutzt werden. Pflicht: - Vor dem Prompten oder Editieren `Layout/README.md` lesen. - Im Subframe-Prompt explizit erwaehnen, dass die validierten HiveGrid/Subframe-Layout-Standards verwendet werden sollen. - Page Padding, Card/Surface Padding, Grid Gap, Text-Rhythmus, Dialog Sizes, Dialog Padding und Dialog Internal Gaps nicht frei neu definieren. - Komponenten-Defaults und Varianten verwenden, wenn sie den Standard bereits abbilden. - Modale immer als echte Subframe-Dialog-Struktur bauen, nicht als Fake-Modal. - Nach MCP-Aenderungen per Readback pruefen, ob die Struktur und die Layout-Regeln wirklich angewendet wurden. ## Ablauf fuer Aenderungen 0. Zuerst klaeren, ob wirklich an den Subframe UI Standards gearbeitet werden soll oder ob die Information nur in ein HiveGrid-Wireframe-Paket gehoert. 1. Zuerst klaeren, ob die Aenderung eine Benennung, eine Global Rule, eine Entscheidung, eine Gruppenregel, eine Komponenten-Notiz oder nur den Index betrifft. 2. Benennungen nur in [[03_Benennung]] pflegen, wenn es um Vokabular geht. 3. Globale Component-API-Regeln in [[07_Global-Rules]] pflegen. 4. Wiederverwendbare Gruppenregeln in [[04_Gruppenregeln]] pflegen. 5. Dauerhafte Layout-Regeln in `Layout/` pflegen, aber nur wenn sie als systemweite Regel validiert wurden. 6. Komponenten-spezifische Notizen in der passenden Datei unter `Components/` pflegen. 7. Der [[05_Komponenten-Index]] bleibt nur Link- und Statusuebersicht. 8. Offene konkrete Aufgaben oder Pruefpunkte in [[08_Todo]] pflegen. 9. Jede inhaltliche Datei-Aenderung am Subframe UI Standards / Component Library Regelwerk in [[AI/08_AI-Change-History]] mit Datum, Uhrzeit, Kontext, betroffenen Dateien, Aenderungen und offenen Punkten dokumentieren. 10. Nach jeder Aenderung die Referenzen pruefen. ## Pflichtpruefung am Ende Nach jeder Aenderung muss geprueft werden: | Pruefung | Bedeutung | | --- | --- | | Wurde eine Global Rule geaendert? | Dann pruefen, ob sie wirklich global ist und nicht in [[03_Benennung]] oder [[04_Gruppenregeln]] gehoert. Komponenten brauchen nur den pauschalen Link. | | Wurde eine Gruppenregel geaendert? | Dann alle betroffenen Komponenten-Dateien pruefen. | | Wurde eine Regel-Ueberschrift geaendert? | Dann alle Obsidian-Links und Embeds auf diese Regel pruefen. | | Wurde eine Komponente neu hinzugefuegt? | Dann [[03_Benennung]], [[07_Global-Rules]] und die passenden Gruppenregeln referenzieren. | | Wurde eine Komponente geaendert? | Dann pruefen, ob alle passenden Gruppenregeln referenziert sind. | | Entstand ein offener Pruefpunkt? | Dann in [[08_Todo]] eintragen, nicht nur im Chat behalten. | | Wurden Dateien im Subframe UI Standards / Component Library Regelwerk erstellt, geaendert, verschoben oder geloescht? | Dann [[AI/08_AI-Change-History]] mit Datum, Uhrzeit, Kontext, Dateien, Aenderungen und offenen Punkten aktualisieren. | | Wurde eine Regel entfernt oder verschoben? | Dann alte Referenzen in `Components/` bereinigen. | Ziel: Regeln und Komponenten muessen in beide Richtungen konsistent bleiben. Eine Regel, die eine Komponente einschliesst, muss in der passenden Komponenten-Datei referenziert sein. Eine Komponenten-Datei soll nur Regeln referenzieren, die wirklich fuer diese Komponente gelten. ## Offene Arbeitsregeln Diese Punkte werden spaeter konkretisiert: - Was AI automatisch aendern darf - Was AI vor Aenderungen fragen muss - Welche Dateien nie ohne Rueckfrage geaendert werden sollen - Wie mit Subframe-Links und Subframe-MCP-Daten gearbeitet wird - Wie neue Komponenten-Dateien angelegt werden