diff --git a/01 Regeln/Screen Agent Workflow.md b/01 Regeln/Screen Agent Workflow.md index 1c1c5589..1e5d7a9d 100644 --- a/01 Regeln/Screen Agent Workflow.md +++ b/01 Regeln/Screen Agent Workflow.md @@ -31,6 +31,7 @@ This file is the operative checklist. `Screen Agent Workflow - Brainstorming.md` - MUST sync structural changes immediately across package MD, screen files, tracker, Canvas and Subframe links. - MUST keep Canvas readable: grouped, labeled, non-confusing and JSON-valid. - MUST ask before committing, unless David explicitly said to commit/push or clearly asked to "mach und push". +- MUST create or update a `Tickets/` handoff file when a ticket is finished or ready for handoff. --- @@ -150,6 +151,21 @@ Then check: - Run `git status --short`. - Stage only intended files. +### 5b. Ticket Handoff + +When a ticket is finished, ready for external ticket-system handoff, or David asks for a ticket summary: + +- Create or update one Markdown file in `Tickets/`. +- Use the same structure as `Tickets/D-P2 Auth Wireframes.md`. +- Name it clearly after the ticket and area, for example `Tickets/D-P2 Auth Wireframes.md`. +- Include ticket id, area, status, repo link, central tracker link and working area. +- Summarize what was done, what David validated and what remains Backlog/Open. +- Link every relevant flow package MD, Canvas and Subframe flow. +- Link relevant screen files. +- Keep detail truth in the package MDs and tracker; the ticket file is the handoff index. +- Before finalizing, verify local links point to existing files. +- If the ticket changes after the handoff file exists, update the same ticket file instead of creating a duplicate. + ### 6. After-Change Impact Check When David says he changed something in Obsidian: @@ -278,5 +294,6 @@ The agent is done only when: - Structural changes are synced across files. - Canvas is valid and readable if changed. - Subframe links are updated if Subframe was used. +- Ticket handoff in `Tickets/` is created/updated when the ticket is finished or handed off. - Git status was checked. - Commit/push handling follows David's instruction. diff --git a/02 Wireframes/Screen Paket Tracker.md b/02 Wireframes/Screen Paket Tracker.md index a5357eac..c68c3b1f 100644 --- a/02 Wireframes/Screen Paket Tracker.md +++ b/02 Wireframes/Screen Paket Tracker.md @@ -91,11 +91,11 @@ Diese Datei ist der erste Ort, um zu sehen: | D01 | Rollen-Dropdown in Mitarbeiterliste | WF-P2 Admin RBAC | Inline-Zustand in S01 | Nur dokumentieren | Validiert | in S01, kein eigener Subframe-Screen | [MD]() | - | [Canvas]() | | M03 | Mitarbeiter deaktivieren | WF-P2 Admin RBAC | Confirm Modal | Bauen | In Subframe | von S01 | [MD]() | [Subframe]() | [Canvas]() | | S02 | Rollen und Berechtigungen | WF-P2 Admin RBAC | Settings Subpage | Bauen | In Subframe | `Settings -> Mitarbeiter`, Tab `Rollen und Berechtigungen` | [MD]() | [Subframe]() | [Canvas]() | -| M04A | Rolle anlegen | WF-P2 Admin RBAC | Modal Step | Bauen | In Subframe | Neue Rolle mit leerem Formular; Subframe: M04 V2 Template Preview | [MD]() | [Subframe]() | [Canvas]() | -| M04B | Rolle duplizieren | WF-P2 Admin RBAC | Modal Step | Bauen | In Subframe | Quellrolle kopieren; Subframe: M04 V3 Duplicate Aware | [MD]() | [Subframe]() | [Canvas]() | -| M02 | Rolle bearbeiten | WF-P2 Admin RBAC | Grosses Modal | Bauen | In Subframe | Finale Variante: V10 Minimal Accordion Editor | [MD]() | [Subframe]() | [Canvas]() | -| D03 | Rolle in Nutzung blockiert | WF-P2 Admin RBAC | Admin Blocker | Nur dokumentieren | In Subframe | von S02/M02 | [MD]() | [Subframe]() | [Canvas]() | -| V01 | Letzter Admin blockiert | WF-P2 Admin RBAC | Admin Blocker | Nur dokumentieren | In Subframe | von S01/M03/Rollenwechsel | [MD]() | [Subframe]() | [Canvas]() | +| M04A | Rolle anlegen | WF-P2 Admin RBAC | Modal Step | Bauen | In Subframe | Neue Rolle mit leerem Formular; an M04B-Stil angeglichen, ohne Duplikat-Modus | [MD]() | [Subframe]() | [Canvas]() | +| M04B | Rolle duplizieren | WF-P2 Admin RBAC | Modal Step | Bauen | In Subframe | Quellrolle kopieren; Duplikat-Modus | [MD]() | [Subframe]() | [Canvas]() | +| M02 | Rolle bearbeiten | WF-P2 Admin RBAC | Grosses Modal | Bauen | In Subframe | Finale Seite: Rolle bearbeiten | [MD]() | [Subframe]() | [Canvas]() | +| D03 | Rolle in Nutzung blockiert | WF-P2 Admin RBAC | Admin Blocker | Nur dokumentieren | In Subframe | von S02/M02 | [MD]() | [Subframe]() | [Canvas]() | +| V01 | Letzter Admin blockiert | WF-P2 Admin RBAC | Admin Blocker | Nur dokumentieren | In Subframe | von S01/M03/Rollenwechsel | [MD]() | [Subframe]() | [Canvas]() | | S01 | Settings -> Workspaces / Loeschbereich | WF-P2 Konto loeschen | Settings | Spaeter | Backlog | spaeter `Settings -> Workspaces` | [MD]() | [Subframe]() | [Canvas]() | | M01 | Loeschung anfragen | WF-P2 Konto loeschen | Modal | Spaeter | Backlog | von zukuenftigem Settings-Einstieg | [MD]() | [Subframe]() | [Canvas]() | | D01 | Anfrage gesendet | WF-P2 Konto loeschen | Toast/Status | Nur dokumentieren | Backlog | nach M01 | [MD]() | - | [Canvas]() | @@ -149,7 +149,7 @@ Diese Datei ist der erste Ort, um zu sehen: | WF-P2 Admin RBAC | Suche/Filter | Genommen | Mitarbeiter-Screen bekommt Suche plus Filter nach Rolle, Abteilung, Status und 2FA; Rollen-Screen bekommt Suche plus Filter nach Typ, Bundle und Nutzung. | Im Paket dokumentiert | | WF-P2 Admin RBAC | Deaktivierung | Genommen | V1 hat nur ein kleines Confirm-Modal; danach Status `Deaktiviert`. | Reassign offener Verantwortlichkeiten ist Backlog | | WF-P2 Admin RBAC | Rollen-Loeschen | Genommen | Rollen koennen nur geloescht werden, wenn keine Mitarbeiter zugewiesen sind; sonst kleines Blocker-Modal. | Ersatzrolle/Bulk-Reassign ist Backlog | -| WF-P2 Admin RBAC | M04A Visual Sync | Offen | M04A `Rolle anlegen` soll optisch wie Davids finaler M04B-Duplikat-Screen aussehen, aber ohne Duplikat-Modus. | Nachholen, sobald Subframe-MCP Page-Operationen nicht mehr timeouten | +| WF-P2 Admin RBAC | M04A Visual Sync | Genommen | M04A `Rolle anlegen` ist optisch an Davids finalen M04B-Duplikat-Screen angeglichen, aber ohne Duplikat-Modus. | Paketdatei und Screen-Datei dokumentieren aktuellen Subframe-Stand | | WF-P2 Admin RBAC | Deaktivieren mit Reassign | Backlog | Offene Aufgaben/Projekte/Verantwortlichkeiten werden spaeter uebertragen. | Nicht Teil der aktuellen Screen-Liste | | WF-P2 Admin RBAC | V2-Backlog | Dokumentiert | Reassign, Rollen-Loeschen mit Ersatzrolle, Gruppen, Rechtekatalog, Rollen-Audit, Rollen-Review, ausgearbeitete Vorlagen, Rechte-Matrix, Bulk-Aktionen, erweiterter Admin-Schutz. | Details im Paket-Backlog | | WF-P2 Konto loeschen | Gesamter Account/Konto-Loeschflow | Backlog | Account/Konto-Loeschen wird geparkt und nicht als aktueller v1-Flow weitergebaut. | Konto loeschen und Workspace loeschen sind zwei getrennte Workflows | @@ -176,7 +176,6 @@ Diese Liste sammelt Punkte, die in einzelnen Paketen als `Backlog`, `Spaeter` od | WF-P2 Profil und Sicherheit | Security / Sessions | Backlog | Eigene Seite fuer aktive Sessions, Trust Devices und Session-Verwaltung | | WF-P2 Profil und Sicherheit | Ueberall abmelden / Session einzeln abmelden | Backlog | Gehoert zur spaeteren Security/Sessions-Seite | | WF-P2 2FA Verwalten | Trust Devices / aktive Sessions | Backlog | Nicht Teil des 2FA-Verwalten-Modals, sondern spaeter Security/Sessions | -| WF-P2 Admin RBAC | M04A Visual Sync | Backlog/Blockiert | M04A an finalen M04B-Stil angleichen; aktuell blockiert durch Subframe-MCP Timeout bei Page-Operationen | | WF-P2 Konto loeschen | Account/Konto-Loeschworkflow | Backlog | Gesamter Flow geparkt; spaeter getrennt von Workspace-Loeschen planen | | WF-P2 Workspace loeschen | Workspace-Loeschworkflow | Backlog | Eigener Workflow fuer Tenant/Workspace-Loeschung; Startpunkt erst nach Workspace-Settings-Klaerung | | WF-P2 Konto/Workspace loeschen | Voller DSGVO-/Export-Wizard | Backlog | Datenexport-Step, Reauth, Confirm Phrase, Countdown und Legal/Billing-Details spaeter | diff --git a/AI README.md b/AI README.md index b4f38ccc..d2e56c90 100644 --- a/AI README.md +++ b/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