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	Eigenstaendige Aufgabenliste fuer offene Standards-Punkte 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:

![[04_Gruppenregeln#Regel: Control-Hoehen fuer Button und Form Inputs]]

Alternative als normaler Link:

[[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.

- [[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

Zuerst klaeren, ob wirklich an den Subframe UI Standards gearbeitet werden soll oder ob die Information nur in ein HiveGrid-Wireframe-Paket gehoert.
Zuerst klaeren, ob die Aenderung eine Benennung, eine Global Rule, eine Entscheidung, eine Gruppenregel, eine Komponenten-Notiz oder nur den Index betrifft.
Benennungen nur in 03_Benennung pflegen, wenn es um Vokabular geht.
Globale Component-API-Regeln in 07_Global-Rules pflegen.
Wiederverwendbare Gruppenregeln in 04_Gruppenregeln pflegen.
Dauerhafte Layout-Regeln in Layout/ pflegen, aber nur wenn sie als systemweite Regel validiert wurden.
Komponenten-spezifische Notizen in der passenden Datei unter Components/ pflegen.
Der 05_Komponenten-Index bleibt nur Link- und Statusuebersicht.
Offene konkrete Aufgaben oder Pruefpunkte der Subframe UI Standards in 08_Todo pflegen.
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.
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

7.3 KiB Raw Blame History