docs: Entity-Zuordnung korrigieren und Navigationsfrage festhalten

Drei Fehler in der Übergabedoku gefunden und behoben. Die Zuordnung in
DATENMODELL.md nannte HiveGrid-Entities, die es nach AD-20 nicht gibt:

- 'Auftrag' → 'order': Auftrag ist eine Pipeline-View auf den Projekt-Kern,
  keine eigene Entität. Status ist pipeline-intern (stage_id).
- 'Kunde' → 'company': Kunde ist ein Status am Kontakt (kontakt_status),
  keine Entität. Kontakt ist der Oberbegriff.
- 'Rechnung' → 'invoice': heißt Rechnung und ist Sub-Entity am Projekt; ihr
  Status kennt kein 'ueberfaellig' — Überfälligkeit wird aus faellig_am
  abgeleitet.

Dazu ein Befund mit Konsequenz: Zeiterfassung steht im ENTITY-MODEL im
v2-Backlog. Damit hat die gesamte Team-Seite in v1 keine Datenquelle. Drei
Wege sind in DATENMODELL.md festgehalten; die Entscheidung gehört vor den
Einbau.

Neu in ZIELSYSTEM.md 3.1b: wohin die Analyse-Seiten in der Navigation gehören.
Die Software hat heute keine Analyse-Gruppe, aber bereits zwei konkurrierende
Muster (Rollen-Dashboard unter /dashboard, Domänen-Analyse unter
leads/analytics). Drei Optionen mit Konsequenzen und eine Empfehlung.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX

docs/DATENMODELL.md

@@ -8,13 +8,33 @@ Einbau nur die Datenquelle getauscht werden muss.
 
 ## Zuordnung zu HiveGrid
 
-| Prototyp | HiveGrid-Entity | Verwendete Felder |
-|---|---|---|
-| `Rechnung` | `invoice` | `amount`, `status`, `issuedAt`, `dueDate`, bezahlt-am |
-| `Auftrag` | `order` | `totalValue`, `status`, `startDate`, `endDate`, Gewerk, Marge, Förderung |
-| `Kunde` | `company` | `name`, `source`, `createdAt`, Typ, Region |
-| `Mitarbeiter` | `TenantUser` + `User` | Name, Rolle, Gewerk, Status, Wochenstunden |
-| `Zeiteintrag` | `timeEntry` | `hours`, `date`, Auftragsbezug, Abwesenheitsgrund |
+| Prototyp | HiveGrid-Entity | Verfügbar | Anmerkung |
+|---|---|---|---|
+| `Rechnung` | **`Rechnung`** (Sub-Entity am Projekt) | v1 | Status dort `entwurf/gestellt/bezahlt/storniert` — **kein `ueberfaellig`**. Überfälligkeit wird aus `faellig_am` gegen heute abgeleitet, nicht als Status geführt |
+| `Auftrag` | **`Projekt`** in einer Pipeline mit `typ_hint = auftrag` | v1 | „Auftrag" ist nach **AD-20 keine eigene Entität**, sondern eine Pipeline-View auf den Projekt-Kern. Wert = `auftragsvolumen`, Status = `stage_id` und damit **pipeline-intern** |
+| `Kunde` | **`Kontakt`** mit `kontakt_status = kunde` | v1 | „Kunde" ist ein **Status am Kontakt**, keine Entität. Kontakt ist der Oberbegriff (Privatperson/Organisation); die Verknüpfung zum Projekt läuft über `ProjektKontakt` mit Rolle `auftraggeber` |
+| `Mitarbeiter` | `TenantUser` + `User` | v1 | |
+| `Zeiteintrag` | — | **v2** | **Zeiterfassung steht im v2-Backlog.** Damit hat die gesamte Team-Seite in v1 keine Datenquelle — siehe unten |
+
+> **Die Begriffe des Prototyps sind SHK-Fachsprache, nicht das Datenmodell der
+> Software.** „Auftrag" und „Kunde" existieren dort nicht als Entitäten. Das ist
+> kein Fehler des Prototyps — der Betrieb spricht so, und die Oberfläche soll so
+> sprechen. Beim Einbau ist es aber eine Übersetzungsleistung und keine
+> Eins-zu-eins-Zuordnung.
+
+### Die Team-Seite hat in v1 keine Datenquelle
+
+Auslastung, Produktivquote, erfasste Stunden und Abwesenheiten beruhen alle auf
+`Zeiteintrag`. Zeiterfassung steht im ENTITY-MODEL ausdrücklich im
+**v2-Backlog**. Drei Wege:
+
+1. Team-Seite als v2 einplanen und in v1 nicht ausliefern;
+2. Stunden aus einem Drittsystem anbinden (der Betrieb erfasst sie ohnehin
+   irgendwo) — dann ist es eine Integrationsfrage, keine Modellfrage;
+3. Zeiterfassung nach v1 ziehen — die größte Entscheidung von den dreien.
+
+Das ist eine Produktentscheidung, keine Gestaltungsfrage. Sie gehört vor den
+Einbau geklärt, weil sie eine von fünf Seiten betrifft.
 
 **Felder, die es so noch nicht gibt** und beim Einbau ergänzt werden müssen: