Doku & Kommentare am Teilschritt (OP-R4-3) — Stand & Roadmap
Status: gebaut — Pflicht-Kommentar (F14) + Pflicht-Fotos mit Mindestanzahl (F15) + inhaltlicher Leitfaden (F16) + Bild-Anzeige live, server-seitig erzwungen; offen: Diktat (OP-DIKTAT-1), Textbausteine (OP-TEXTBLOCK-1), Mehrsprachigkeit (OP-I18N-1), Abschluss-Notiz (OP-ABSCHLUSS-1) — s. Roadmap · Bezug: OP-R4-3 (Owning) · OP-AI-2 (KI-Plausibilität) · OP-R3-3 (Editor-UI) · G-1 · Zielgruppe: Anwender (Werkstatt-Team — was beim Fertigmelden zu tun ist) · IT-Dev/Architektur (Datenmodell + Durchstich) · CISO/Security (Beweis-/Audit-Wert der Doku) · True North: Frage 2 („Wo stehen die Fahrzeuge — auch in der Bearbeitung?") — belastbare Schritt-Doku macht den Bearbeitungsstand prüf- und beweisbar
Kernaussage. Jede Schritt-Kommentierung (Schritt-Abschluss und Übergang zum nächsten Schritt) ist eine strukturierte Doku-Pflicht: ein Pflicht-Kommentar, dazu Pflicht-Fotos in geforderter Mindestanzahl je Perspektive und ein inhaltlicher Leitfaden, der vorgibt, worauf die Beschreibung eingehen soll. Bild-Anzeige, Mindestanzahl-Erzwingung und der inhaltliche Leitfaden sind gebaut; Diktat, Textbausteine und Mehrsprachigkeit sind die nächsten, additiven Ausbaustufen auf demselben Doku-Modell.
Warum (die tragenden Gründe)
- Beweiswert & Haftung. Foto + Beschreibung beim Annahme-, Aufbereitungs- und QM-Schritt belegen den
Zustand vorher/nachher — entscheidend bei Reklamationen und für die Audit-Bereitschaft
(
docs/betrieb/Compliance.md). - Gleichbleibende Qualität. Ein vorgegebener Aspekt-Leitfaden sorgt dafür, dass jeder Werker dieselben relevanten Punkte dokumentiert — unabhängig von Erfahrung und Tagesform.
- Selbsterklärbarkeit. Der Werker muss nicht raten, was „genug Doku" ist: Pflicht-Felder, Foto-Zähler und Aspekt-Liste sagen es konkret.
Was heute gebaut ist
| Baustein | Feld / Mechanik | Quelle |
|---|---|---|
| Pflicht-Kommentar (F14) | Teilschritt.dokuPflicht (Default: pflichtig; explizit false schaltet ab) → Gate beim erledigen | server/src/model/types.ts · server/party/leitstand.ts |
| Pflicht-Fotos + Mindestanzahl (F15) | Teilschritt.fotoPflicht: { perspektive, anzahl }[] → je Perspektive Mindestanzahl, hart erzwungen; Upload→R2, client-seitige Kompression, optionales Original-Archiv | types.ts · client/.../auftrag-detail-panel.component.ts · client/.../foto-kompression.ts |
| Bild-Anzeige | Erfasste Fotos werden als Thumbnails im Kommentar-Gate gezeigt (Klick → Vollbild; „HQ" → Original) | auftrag-detail-panel.component.ts |
| Inhaltlicher Leitfaden (F16, neu) | Teilschritt.dokuAspekte: string[] — kuratierte Aspekte, die die Beschreibung abdecken soll; im Kommentar-Gate als „Worauf eingehen?" eingeblendet (weiche Vorgabe) | types.ts · auftrag-detail-panel.component.ts |
Ein Gate, überall. Alle Kommentar-Einstiege (geteiltes Detail-Panel aus Aufträge, Planung-Gantt,
Tafel und der Werker-Sicht Meine Arbeit) laufen durch dasselbe Doku-Gate
(auftrag-detail-panel.component.ts) — Bild-Anzeige, Foto-Pflicht und Aspekt-Leitfaden gelten damit
automatisch an jeder Stelle, ohne ein zweites Gate.
Ebene = Teilschritt. Alle drei Felder (dokuPflicht/fotoPflicht/dokuAspekte) liegen am
Teilschritt; das Gate feuert je Teilschritt beim Fertigmelden (teilschritt.aktion/erledigen).
Der Lifecycle-Abschluss des ganzen Auftrags (fertigstellen/abholen/kontrollieren) hat kein
eigenes Kommentarfeld — die Auftrags-Doku entsteht aus der Summe der Schritt-Kommentare. Eine separate
Abschluss-/Übergabe-Notiz auf Auftrags-Ebene ist als OP-ABSCHLUSS-1 geparkt (s. Roadmap).
Durchstich (Datenfluss)
Das Gate wird server-seitig geprüft (teilschritt.aktion/erledigen lehnt ohne Pflicht-Kommentar bzw.
ohne vollzählige Fotos ab) — der Client spiegelt es nur, damit „✓ Fertig" erst klickbar ist, wenn alles da
ist.
Bedienung (Anwender)
- Schritt im Detail-Panel öffnen → „✓ Fertig".
- Geforderte Fotos je Perspektive aufnehmen (Zähler z. B.
Detail 1/2); fehlt etwas, bleibt „✓ Fertig" gesperrt und „📷 Pflicht-Fotos fehlen noch" erscheint. - Unter „Worauf eingehen?" stehen die vorgegebenen Aspekte — diese im Kommentar abarbeiten.
- „✓ Fertig" schließt den Schritt ab; Kommentar + Fotos landen in der Auftrags-Chronik.
Roadmap (additiv, auf demselben Modell)
| Ausbaustufe | OP | Idee | Bezug |
|---|---|---|---|
| KI-Plausibilität | OP-AI-2 | Prüft, ob Beschreibung + Fotos die geforderten dokuAspekte/Perspektiven tatsächlich abdecken (Datenschutz „Bilder an API" zu klären) | docs/architektur/Bildbewertung.md |
| Sprach-Diktat | OP-DIKTAT-1 (neu) | Kommentar einsprechen statt tippen (Werker mit belegten Händen); Transkription füllt das Kommentarfeld | dieses Doc |
| Textbausteine | OP-TEXTBLOCK-1 (neu) | Kuratierte, ein-tippbare Bausteine je Schritt/Aspekt („Lack i. O.", „Kratzer Stoßfänger hinten") → schneller, einheitlicher | G-1 (admin-editierbar) |
| Mehrsprachigkeit | OP-I18N-1 | Aspekt-Leitfaden, Bausteine und Pflicht-Texte mehrsprachig; Eingabe ggf. anzeigesprachen-übersetzt | docs/architektur/Billing-Zugang.md (I18N) |
| Auftrags-Abschluss-Notiz | OP-ABSCHLUSS-1 | Separate Doku-/Übergabe-Notiz für den ganzen Auftrag (beim Abholen/QM-Freigabe) mit eigener dokuPflicht + dokuAspekte (Übergabe-Checkliste) — heute liegt Doku nur je Teilschritt | R7 (Lifecycle) · OP-R4 (Unterschrift) |
Reihenfolge-Empfehlung: Textbausteine (kleiner, rein additiver Client-/Vorlagen-Ausbau) vor Diktat (braucht Spracherkennung/Transkriptionspfad) vor Mehrsprachigkeit (zieht sich quer durch alle Doku-Texte und ist mit der allgemeinen I18N-Strategie zu bündeln).
Konfiguration (Stammdaten)
dokuPflicht, fotoPflicht und dokuAspekte sind Teilschritt-Vorlagen-Felder und damit pro Schritt
pflegbar (G-1: taxonomie-artig, admin-editierbar). Server-seitig sind alle drei über den
Prozess-Editor-Pfad (teilschritt.update → setzeTeilschrittFelder) patchbar und normalisiert; eine
eigene Editor-UI für diese Doku-Felder ist noch offen (heute via Seed/Patch gesetzt) und folgt mit dem
Prozess-Editor-Ausbau (OP-R3-3).
↩ Zurück zur Doku-Landkarte · Lesepfade · Register (alle OPs)