HiveGrid-Wireframes/01 Regeln/Obsidian Struktur.md

kind, project, area, status

kind	project	area	status
rule	HiveGrid Screen Project	Obsidian	active

Obsidian Struktur

Dieser Vault ist der Arbeitsbereich fuer Screens, Wireframes und Handoffs.

---

Ordner

Ordner	Zweck
01 Regeln	dauerhafte Regeln und Arbeitsweisen
02 Wireframes	alle Wireframe-Pakete, Screen-Dateien und Canvas-Dateien
02 Wireframes/_Templates	Vorlagen fuer neue Pakete und Screens
03 Quellen und Referenzen	Quellen, Referenz-Repos und Repo-Hinweise
03 Quellen und Referenzen/hivegrid-cloud	mitgepushte HiveGrid-Cloud-Referenz mit Planning-Quellen
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

---

Dateiarten

Dateiart	Beispiel	Zweck
Paket-Datei	WF-[Ticket] [Flow Name].md	sammelt Scope, Brainstorming, Screen-Liste und Handoff
Screen-Datei	S01 Profil auswaehlen.md	beschreibt genau einen Screen
State-Datei	ST01 Keine Suchergebnisse.md	beschreibt einen Zustand, der nicht als eigener Frame gebaut wird
Canvas-Datei	WF-[Ticket] [Flow Name].canvas	visueller Flow-Tree in Obsidian Canvas
Tracker	Screen Paket Tracker.md	Uebersicht ueber Pakete und Status
Todo	Todo.md im Vault-Root	zentrale, projektweite und abhakbare Aufgabenliste

---

Flow-Typen

Typ	Bedeutung
Normaler Flow	eigener Nutzerweg mit Start, Entscheidung und Ziel
Zubringerflow	klaert Vorbedingungen und fuehrt in einen anderen Flow
Auth-Core-Flow	zentraler Sicherheitsflow, der von mehreren Zubringerflows genutzt wird

Aktuelle Auth-Core-Entscheidung:

• WF-P2 Set Password ist ein zentraler Auth-Core-Flow.
• Passwort Reset, Einladung/initialer Mitarbeiterzugang, Passwort aendern, Admin-Reset und Security-Incident koennen dorthin fuehren.
• Neukunden-Signup ist die Ausnahme und setzt das Passwort direkt im Signup-Flow.

---

Benennung

Pakete:

WF-[Ticket] [Name].md

Screens:

S01 [Screen Name].md
S02 [Screen Name].md
B01 [Branch Name].md
ST01 [State Name].md

IDs:

• S01, S02, S03 = Hauptflow
• B01, B02, B03 = Branch/Variante
• M01, M02 = Modal/Overlay
• ST01, ST02 = Zustand

---

Link-Anzeige in Tabellen

In Tabellen werden lange Links mit normalen Markdown-Links gekuerzt.

Warum: Obsidian-Wiki-Aliase nutzen |, und dieses Zeichen kann Markdown-Tabellen kaputt machen.

Beispiel:

[MD](<P2 Auth/WF-P2 Login und 2FA/Screens/S01 Login.md>)
[Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>)

Regel:

• In Tracker-Tabellen kurze Labels verwenden: MD, Canvas, Subframe.
• In Tabellen keine [[Pfad|Alias]]-Links verwenden.
• Lange Pfade nur in der Datei selbst oder im Frontmatter ausschreiben.
• Der sichtbare Tabelleninhalt soll scanbar bleiben.

---

Frontmatter

Jede Paket- und Screen-Datei bekommt oben Metadaten. Dadurch kann Obsidian spaeter Tabellen daraus bauen.

Beispiel Screen:

---
kind: screen
ticket: P2
package: WF-[Ticket] [Flow Name]
id: S01
screen: Profil auswaehlen
umsetzung: Bauen
status: Validiert
subframe: ""
---

---

Obsidian Canvas

Canvas-Dateien liegen direkt im jeweiligen Paketordner.

Grid-Regel:

• Hauptflow nach rechts
• Varianten nach unten
• Varianten laufen danach wieder nach rechts weiter
• wenn es unuebersichtlich wird, entsteht ein neues Paket

Qualitaetsregel:

• keine ueberlappenden Nodes
• keine verdeckten Labels
• keine Kante durch andere Karten
• kurze Kantenlabels mit genug Abstand
• Canvas nach dem Erstellen mit JSON-Check pruefen

Sync-Regel:

• Jeder echte Screen braucht einen Canvas-Node.
• Wenn ein Screen umbenannt, gesplittet, geloescht oder neu angelegt wird, muessen Canvas, Screen-Datei, Paket-MD und Screen Paket Tracker im selben Arbeitsschritt abgeglichen werden.
• Wenn aus einer Variante ein eigener Screen wird, braucht sie einen eigenen Canvas-Node und eine eigene Tracker-Zeile.
• Ohne Davids Freigabe wird ein geplanter Split nur dokumentiert, aber nicht als neuer Subframe-Screen gebaut.

---

Subframe-Schutz

Subframe wird nicht automatisch aus dem Tracker heraus bearbeitet.

Die Subframe UI Standards unter 04 Standards/Subframe UI Standards/ sind ebenfalls geschuetzt:

• Sie sind ein eigenes Standards-Projekt innerhalb dieses Repos.
• Sie werden als Referenz fuer Layout-, Komponenten- und Subframe-Konventionen genutzt.
• Sie duerfen nicht durch normale Screen-/Flow-Arbeit automatisch umgeschrieben werden.
• Aenderungen brauchen eine explizite Aufgabe oder eine vorher validierte systemweite Entscheidung.

Regel:

• Bestehende Subframe-Screens bleiben unberuehrt, auch wenn sie gleich heissen.
• Der Assistant darf Subframe nur nach expliziter Freigabe fuer einen konkreten Flow nutzen.
• Ohne Freigabe werden nur Obsidian-Dateien vorbereitet: Paket, Screens, Canvas, Tracker.
• David kann bestehende oder gleichnamige Subframe-Screens spaeter selbst pruefen, ersetzen oder loeschen.