---
kind: rule
project: HiveGrid Screen Project
area: Obsidian
status: 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:

```text
WF-[Ticket] [Name].md
```

Screens:

```text
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
[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:

```yaml
---
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.