172 lines
5.0 KiB
Markdown
172 lines
5.0 KiB
Markdown
---
|
|
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.
|