Clean up ticket workflow and admin tracker

AI README.md

@@ -4,13 +4,13 @@ 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.
+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 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.
+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.
 
 ## Start jeder Arbeit
 
-Bevor neue Planung, Research oder Subframe-Arbeit beginnt, immer den Stand der Referenz-Codebase pruefen:
+Bevor neue Planung, Research oder Subframe-Arbeit beginnt, immer den Stand von `hivegrid-cloud/` pruefen und bei Bedarf aktualisieren:
 
 ```bash
 cd hivegrid-cloud
@@ -18,7 +18,7 @@ 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.
+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.
 
 ## Wichtige Bereiche
 
@@ -31,6 +31,8 @@ Gemeint ist der lokale Ordner `./hivegrid-cloud/`. Wenn fuer die aktuelle Aufgab
 | `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 |
 
 ## Arbeitsregeln
 
@@ -42,8 +44,9 @@ Gemeint ist der lokale Ordner `./hivegrid-cloud/`. Wenn fuer die aktuelle Aufgab
 - 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`.
 - Bei Subframe-Arbeit bestehende Nutzer-Anpassungen nicht rueckgaengig machen.
-- `hivegrid-cloud/` nur als Referenz verwenden.
+- `hivegrid-cloud/` als Referenz und Planning-Quelle verwenden; relevante Updates mittracken.
 
 ## Subframe-Kontext
 
@@ -77,7 +80,7 @@ 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.
+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.
 
 ## Aktueller Remote