135 lines
7.2 KiB
Markdown
135 lines
7.2 KiB
Markdown
# 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
|