85 lines
4.6 KiB
Markdown
85 lines
4.6 KiB
Markdown
# AI README
|
|
|
|
Diese Datei ist fuer AI-Agenten gedacht, die in diesem Repo weiterarbeiten.
|
|
|
|
## Repo-Zweck
|
|
|
|
Dieses Repo ist der Obsidian-/Wireframe-Vault fuer HiveGrid. Es enthaelt Planung, UX-Regeln, Screen-Pakete, Canvas-Flows und Subframe-Handoffs. Es ist nicht die Produkt-Codebase.
|
|
|
|
Die eigentliche Referenz-Codebase liegt lokal in `hivegrid-cloud/` und ist bewusst per `.gitignore` ausgeschlossen. Dieses Verzeichnis darf gelesen werden, soll aber nicht in dieses Wireframe-Repo committed oder gepusht werden.
|
|
|
|
## Start jeder Arbeit
|
|
|
|
Bevor neue Planung, Research oder Subframe-Arbeit beginnt, immer den Stand der Referenz-Codebase pruefen:
|
|
|
|
```bash
|
|
cd hivegrid-cloud
|
|
git status --short
|
|
git pull --ff-only
|
|
```
|
|
|
|
Gemeint ist der lokale Ordner `./hivegrid-cloud/`. Wenn fuer die aktuelle Aufgabe ein bestimmter Branch oder Pull Request in HiveGrid Cloud relevant ist, diesen Stand dort zuerst auschecken bzw. aktualisieren und erst danach die Planung in diesem Wireframe-Repo bearbeiten. `hivegrid-cloud/` bleibt trotzdem Referenzmaterial und wird nicht in dieses Repo committed.
|
|
|
|
## Wichtige Bereiche
|
|
|
|
| Pfad | Zweck |
|
|
|---|---|
|
|
| `00 Start Here.md` | Einstieg in den Vault |
|
|
| `01 Regeln/` | Arbeitsregeln fuer Wireframing, Obsidian, Subframe und Brainstorming |
|
|
| `01 Regeln/Screen Agent Workflow.md` | Operative Checkliste fuer AI-Agenten bei Screen-/Flow-Arbeit |
|
|
| `02 Wireframes/Screen Paket Tracker.md` | Zentrale Paket- und Flow-Uebersicht |
|
|
| `02 Wireframes/P2 Auth/` | Aktuell aktive Auth-/Account-/Admin-Wireframe-Pakete |
|
|
| `02 Wireframes/_Templates/` | Vorlagen fuer neue Pakete und Screens |
|
|
| `03 Quellen und Repo/` | Repo- und Quellenhinweise |
|
|
|
|
## Arbeitsregeln
|
|
|
|
- Fuer Screen-/Flow-Arbeit zuerst `01 Regeln/Screen Agent Workflow.md` lesen und anwenden. Die Brainstorming-Datei dazu ist nur Archiv, nicht operative Regel.
|
|
- Danach die bestehenden Detailregeln lesen, besonders `01 Regeln/Wireframing Playbook.md`.
|
|
- Flows einzeln bearbeiten und nur validierte Entscheidungen final dokumentieren.
|
|
- Keine bestehenden Subframe-Screens loeschen oder ueberschreiben, wenn der Nutzer das nicht explizit verlangt.
|
|
- Neue Screens/Flows immer in Tracker, Paketdatei, Screen-Dateien und Canvas konsistent halten.
|
|
- Bei jeder Screen-Umbenennung, Screen-Aufteilung, Screen-Loeschung oder neuem Subframe-Screen muss der komplette Sync geprueft werden: Screen-Datei, Paket-MD, `Screen Paket Tracker`, Canvas und Subframe-Flow. Wenn daraus mehrere echte Screens entstehen, brauchen sie eigene Tracker-Zeilen und eigene Canvas-Nodes.
|
|
- Wenn eine moegliche Screen-Aufteilung noch nicht von David validiert ist, nur als offene Entscheidung dokumentieren und keine neuen Subframe-Screens anlegen.
|
|
- Backlog-Punkte klar markieren, damit V2-Themen nicht verloren gehen.
|
|
- Bei Subframe-Arbeit bestehende Nutzer-Anpassungen nicht rueckgaengig machen.
|
|
- `hivegrid-cloud/` nur als Referenz verwenden.
|
|
|
|
## Subframe-Kontext
|
|
|
|
Subframe-Links stehen in den jeweiligen Screen-Dateien im Frontmatter-Feld `subframe`.
|
|
|
|
Modal-Screens muessen als echte Subframe-Dialoge gebaut werden:
|
|
|
|
- Struktur: `DialogLayout` -> `Dialog` -> `Dialog.Content` -> Modal-Inhalt.
|
|
- Nicht erlaubt: Modal per `Card`, freiem `div`, absolutem Overlay, Blur-Hintergrund oder Fullscreen-Container nur visuell nachbauen.
|
|
- Beim Subframe-Prompt fuer jedes Modal explizit die echte Dialog-Struktur verlangen; sonst baut Subframe haeufig nur ein Fake-Modal nach.
|
|
- Vor Handoff per `get_page_info` pruefen, ob `Dialog` importiert wird und `Dialog.Content` im JSX existiert.
|
|
- Layout bevorzugt mit Subframe-Komponenten und Auto Layout/Flex aufbauen.
|
|
- Custom Tailwind-Klassen nur verwenden, wenn sie fuer feste Groessen, Max-Breiten, Scroll-/Overflow-Verhalten oder responsive Constraints wirklich noetig sind.
|
|
|
|
## Git- und Sync-Regel
|
|
|
|
Dieses Repo soll haeufig committed und gepusht werden, damit die Planung fuer andere Agents und Menschen synchron bleibt.
|
|
|
|
Empfohlener Rhythmus:
|
|
|
|
1. Nach abgeschlossenem Flow-/Screen-Paket committen.
|
|
2. Nach wichtigen Nutzer-Validierungen committen.
|
|
3. Nach laengeren Subframe- oder Canvas-Aenderungen pushen.
|
|
|
|
Standardbefehle:
|
|
|
|
```bash
|
|
git status --short
|
|
git add <konkrete Dateien>
|
|
git commit -m "Update wireframe planning"
|
|
git push
|
|
```
|
|
|
|
Vor jedem Commit pruefen, dass `hivegrid-cloud/` nicht staged ist und keine fremden lokalen Aenderungen wie `.obsidian/workspace.json` oder Canvas-Aenderungen versehentlich committed werden.
|
|
|
|
## Aktueller Remote
|
|
|
|
Das Repo soll nach `git.tool-ctrl.de/david/Hivegrid-Wireframes` gepusht werden. Falls Push nicht funktioniert, liegt es wahrscheinlich an SSH-/HTTPS-Zugriff oder Server-Port-Konfiguration, nicht an der lokalen Repo-Struktur.
|