Reorganize repo structure and standards references

AI README.md

@@ -6,19 +6,19 @@ Diese Datei ist fuer AI-Agenten gedacht, die in diesem Repo weiterarbeiten.
 
 Dieses Repo ist der Obsidian-/Wireframe-Vault fuer HiveGrid. Es enthaelt Planung, UX-Regeln, Screen-Pakete, Canvas-Flows, Subframe-Handoffs und Ticket-Handoff-Dateien.
 
-Die HiveGrid-Cloud-Referenz liegt im Ordner `hivegrid-cloud/` und wird mit diesem Repo mitgepusht, damit Planning, Ticket-Docs und Code-Kontext fuer alle Agents/Menschen verfuegbar bleiben.
+Die HiveGrid-Cloud-Referenz liegt im Ordner `03 Quellen und Referenzen/hivegrid-cloud/` und wird mit diesem Repo mitgepusht, damit Planning, Ticket-Docs und Code-Kontext fuer alle Agents/Menschen verfuegbar bleiben.
 
 ## Start jeder Arbeit
 
-Bevor neue Planung, Research oder Subframe-Arbeit beginnt, immer den Stand von `hivegrid-cloud/` pruefen und bei Bedarf aktualisieren:
+Bevor neue Planung, Research oder Subframe-Arbeit beginnt, immer den Stand von `03 Quellen und Referenzen/hivegrid-cloud/` pruefen und bei Bedarf aktualisieren:
 
 ```bash
-cd hivegrid-cloud
+cd "03 Quellen und Referenzen/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. Relevante Planning-/Ticket-Aenderungen in `hivegrid-cloud/` sollen zusammen mit dem Wireframe-Repo committed und gepusht werden.
+Gemeint ist der lokale Ordner `./03 Quellen und Referenzen/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. Relevante Planning-/Ticket-Aenderungen in der HiveGrid-Cloud-Referenz sollen zusammen mit dem Wireframe-Repo committed und gepusht werden.
 
 ## Wichtige Bereiche
 
@@ -30,23 +30,27 @@ Gemeint ist der lokale Ordner `./hivegrid-cloud/`. Wenn fuer die aktuelle Aufgab
 | `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 |
-| `Tickets/` | Ticket-Handoff-Dateien fuer fertige/uebergabereife Tickets |
-| `hivegrid-cloud/` | Mitgepushte HiveGrid-Cloud-Referenz inklusive Planning und Ticket-Docs |
+| `03 Quellen und Referenzen/` | Quellen, Referenz-Repos und Repo-Hinweise |
+| `03 Quellen und Referenzen/hivegrid-cloud/` | Mitgepushte HiveGrid-Cloud-Referenz inklusive Planning und Ticket-Docs |
+| `04 Standards/Subframe UI Standards/` | Eigenes Standards-Projekt fuer dauerhafte Subframe-, Komponenten- und Layout-Standards |
+| `Tickets/` | Ticket-Handoff-Index |
+| `Tickets/Fertige Tickets/` | Fertige oder handofffaehige Ticket-Zusammenfassungen |
 
 ## 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`.
+- Die Subframe UI Standards unter `04 Standards/Subframe UI Standards/` sind ein eigenes Standards-Projekt. Sie dienen als Referenz fuer dauerhafte Subframe-, Komponenten- und Layout-Standards, duerfen aber bei normaler Screen-Arbeit nicht nebenbei geaendert werden.
+- Aenderungen an den Subframe UI Standards sind nur erlaubt, wenn David explizit daran arbeiten will oder eine konkrete systemweite Regel vorher validiert wurde.
 - 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.
-- Wenn ein Ticket fertig oder uebergabereif ist, immer eine Ticket-Handoff-Datei in `Tickets/` anlegen bzw. aktualisieren. Formatvorlage ist `Tickets/D-P2 Auth Wireframes.md`.
+- Wenn ein Ticket fertig oder uebergabereif ist, immer eine Ticket-Handoff-Datei in `Tickets/Fertige Tickets/` anlegen bzw. aktualisieren. Formatvorlage ist `Tickets/Fertige Tickets/D-P2 Auth Wireframes.md`.
 - Bei Subframe-Arbeit bestehende Nutzer-Anpassungen nicht rueckgaengig machen.
-- `hivegrid-cloud/` als Referenz und Planning-Quelle verwenden; relevante Updates mittracken.
+- `03 Quellen und Referenzen/hivegrid-cloud/` als Referenz und Planning-Quelle verwenden; relevante Updates mittracken.
 
 ## Subframe-Kontext
 
@@ -80,7 +84,7 @@ git commit -m "Update wireframe planning"
 git push
 ```
 
-Vor jedem Commit pruefen, dass keine fremden lokalen Aenderungen wie `.obsidian/workspace.json` oder unrelated Canvas-Aenderungen versehentlich committed werden. `hivegrid-cloud/` darf und soll mitgestaged werden, wenn dort Planning-, Ticket- oder Referenzstand fuer die aktuelle Arbeit relevant ist.
+Vor jedem Commit pruefen, dass keine fremden lokalen Aenderungen wie `.obsidian/workspace.json` oder unrelated Canvas-Aenderungen versehentlich committed werden. `03 Quellen und Referenzen/hivegrid-cloud/` darf und soll mitgestaged werden, wenn dort Planning-, Ticket- oder Referenzstand fuer die aktuelle Arbeit relevant ist.
 
 ## Aktueller Remote