Lastenheft — Werkstatt-Betriebssystem (Neuentwicklung)

Kernaussage. Dies ist die fachliche Master-Spec von Taktano: Module R1–R9, das Datenmodell (Auftrag R7 als zentraler Träger), der Standard-Prozess (Annahme → … → Abholung) und das Optimierungsziel des Schedulers — alles über stabile IDs referenzierbar. Bei jeder fachlichen Frage: die verbindliche Antwort steht hier.

Basis: Strukturanalyse von automotivo.de · Auftraggeber: Dr. K (m.kirchhof@drkv.com) · Stand: 25.05.2026

Dieses Dokument ist die einzige fachliche Quelle der Wahrheit. Diagramme als Mermaid inline. Identifikatoren (G-, R-, F-, S-, A-, OP-, FR-, FM-) sind über das gesamte Repo stabil und referenzierbar.

1. Einleitung

1.1 Zweck

Dieses Lastenheft beschreibt die fachlichen Anforderungen an eine Neuentwicklung des Werkstatt-Betriebssystems für Fahrzeug-Veredelungsbetriebe. Es basiert auf einer strukturierten Analyse des bestehenden Systems automotivo.de inklusive aller relevanten Module, Entitäten, Workflows und Geschäftslogik.

1.2 Abgrenzung

Technologie-agnostisch im Kern. Definiert das WAS (Anforderungen). Technologie- und Architekturhinweise sind als Empfehlungen markiert (§9).

Sanity-Check (North Star): Jedes Feature/Dokument muss helfen, die Top‑3-Leitfragen besser zu beantworten — (1) Wie hoch ist die Auslastung? · (2) Wo stehen die Fahrzeuge? (physisch & in Bearbeitung) · (3) Wann sind die nächsten freien Kapazitäten? Lebende Prüfliste: Sanity-Checkliste.md.

Leitprinzip Selbsterklärbarkeit: Taktano soll selbsterklärend sein — durchgängig sprechende, eindeutige Bezeichnungen für Status, Aktionen, Felder und Räume (ein Nutzer versteht ohne Schulung, was gemeint ist). Bevorzuge klare Begriffe aus der Werkstatt-Praxis statt technischer/abstrakter Labels (z. B. Status „Fahrzeug angeliefert" statt „Reserviert"). Gilt für UI und Doku.

1.3 Identifikator-Schema

Präfix	Bedeutung
`Rx`	Modul / Hauptentität (R1 = Mitarbeiter, R2 = Arbeitsplätze, …)
`Rx-Fnn`	Feld innerhalb einer Entität
`Rx-Snn`	Sub-Entität / Tab
`G-n`	Globales Prinzip
`A-n`	Architektur-Empfehlung
`S-n`	Vereinfachungs-/Optimierungs-Empfehlung
`UC-x`	Kern-Use-Case
`OP-Rx-n`	Offener Punkt
`FR-n`	Future-Release-Note
`FM-n`	Future-Module-Note

2. Kern-Use-Cases

UC-A — Verfügbarkeit prüfen (Angebotsmodus), Auftrag mit zugesagtem Bring/Abholtermin anlegen.
UC-B — Aufträge in Teilschritt-Instanzen zerlegen; Mitarbeiter + Arbeitsplätze zuweisen unter Skill-, Standzeit-, Abhängigkeits- und Eilauftrags-Constraints.
UC-C — Teilschritt starten/abschließen, QM-Formular ausfüllen, Mängel dokumentieren.
UC-D — Leitstand: Echtzeit-Auslastung, Empfehlungen, Konflikte, Überstunden-Vorschläge.
UC-E — Protokolle, Zustandsdokumentation, Unterschriften.
UC-F — Bring/Abholtermin, Self-Service-Link, Übergabe.
UC-G — Skills, Leistungen, Teilschritte, Mitarbeiter, Arbeitsplätze, Zweigstellen, Taxonomien.

3. Globale Prinzipien

G-1 — Admin-editierbare Taxonomien

Alle taxonomie-artigen Aufzählungswerte (Kategorien, Statuswerte, Reason-Codes, Typen, Qualifikationen, Ausstattung, Abteilungen, Dokumenttypen) sind admin-editierbare Stammdaten. Seed-Werte aus der heutigen Plattform werden als Default ausgeliefert; Admins können hinzufügen, umbenennen oder deaktivieren.

Ausnahme: logik-tragende Enums (z. B. Abhängigkeit Nach vorherigem / Parallel / Frei, die den Scheduler steuern) bleiben systemfest.

G-2 — Wechsel-Pönale Mitarbeiter

Der Scheduler rechnet eine konfigurierbare Pönale (Default 5 Minuten) auf die Mitarbeiter-Allokation auf, wenn der Mitarbeiter zwischen Prozessen oder Fahrzeugen wechselt. Modelliert den Kontextwechsel-Aufwand. Ausnahme: Helfer-/Ausbildungs-Tätigkeit (§6.4.1) ist kein produktiver Kontext — ein Helfer kann penaltyfrei abgezogen werden, wenn er auf einem echten Auftrag gebraucht wird (Helfer sind nicht Teil des Solvers).

G-3 — Minimum Auto-Scheduling-Fenster

Der Auto-Scheduler plant keine Arbeit in verfügbare Fenster kürzer als 15 Minuten ein. Kleinere Lücken bleiben ungenutzt.

G-4 — Kontextwechsel-Minimierung bei der Aufgaben-Platzierung (außer QS: Vier-Augen)

Regel (PO, 07-12): Bei der Zuweisung/Platzierung von Aufgaben sollen möglichst wenige Kontextwechsel entstehen — wer bereits im Kontext eines Fahrzeugs/Auftrags ist (oder als Nächstes dort arbeitet), übernimmt bevorzugt auch die angrenzenden Neben-/Logistikaufgaben. Beispiel: Ein Mitarbeiter, der umparken und folieren kann, parkt das Auto um, das er als Nächstes foliert — statt dass ein Dritter dafür den eigenen Kontext verlässt.

Ausnahme QS (Vier-Augen, hart): Beim Quality-Check gilt das Gegenteil — wer eine Arbeit ausgeführt hat, darf ihr Ergebnis nicht selbst verifizieren. Der QS-/Quality-Check-Schritt eines Auftrags wird nie dem Mitarbeiter zugewiesen, der die zu prüfenden Produktionsschritte ausgeführt hat (→ OP-QS-6). Kontextwechsel-Minimierung ist hier bewusst nachrangig. Abweichen darf nur der Chef (PO, 07-12): je Prüfschritt eine begründete, auditierte Chef-Freigabe — nie still, nie pauschal.

Einordnung: G-2 (Wechsel-Pönale) ist die Kosten-Seite derselben Politik im Solver — G-4 verallgemeinert sie zur Zuweisungs-Leitregel für alle Platzierungsentscheidungen (Scheduler, Queues, manuelle Beauftragung wie Umparken → OP-UMPARK-1). Bezug: §6.1 (Solver-Ziele), OP-OPT-9 (Queues), OP-QS-6, OP-UMPARK-1.

4. Stammdaten und Master-Entitäten

4.0 Datenmodell-Überblick (vereinfacht)

4.1 Skill / Qualifikation (neu, first-class)

Ersetzt das alte Modell, in dem jeder Teilschritt seine eigene implizite Qualifikation darstellte.

ID	Feld	Typ	Anmerkung
F01	Name	Text, req	z. B. „PPF Premium", „Keramik Felgen"
F02	Beschreibung	Text	frei
F03	Aktiv	Bool	Soft-Deaktivierung

Relationen: Skill ↔ Teilschritt (genau ein geforderter Skill je Teilschritt + Personenanzahl, R3b-F11/F12); Skill ↔ Mitarbeiter (M:N, beherrscht mit Niveau); Skill ↔ Bucht (M:N, „ausführbare Skills", §4.3-F05a).

Skill-Niveau & Vertrauensstufe & Güteklasse (umgesetzt v1) — drei Stufen-Dimensionen steuern die Zuordnung:

Skill-Niveau („Sterne", 1–3) je Mitarbeiter-Skill: 1 = Grundkenntnisse/wenig Erfahrung · 2 = 1–2 Jahre, kann auch schwierige Fahrzeuge · 3 = Experte. (MitarbeiterSkill.niveau)
Vertrauens-/Handling-Stufe (1–3) je Mitarbeiter: 1 = solide, aber nicht sehr sauber · 2 = ordentlich, auch höherwertige/innen-weiße Fahrzeuge · 3 = sehr ordentlich/akkurat/erfahren, auch Super-Premium. (Mitarbeiter.vertrauensstufe)
Güteklasse (1–3) je Fahrzeug/Auftrag: wie wertvoll/empfindlich. (Auftrag.gueteklasse)
Teilschritt-Anforderung: ein Teilschritt kann einen Skill in bestimmter Güte verlangen (Teilschritt.mindestSkillNiveau, Default 1) — z. B. Super-Premium-Folierung fordert das Folie-Skill auf Niveau 3.
Zuteilungsregel (harter Constraint, §6.1): ein Mitarbeiter darf einen Schritt nur übernehmen, wenn er (a) jeden geforderten Skill mindestens auf dem geforderten Niveau beherrscht und (b) vertrauensstufe >= gueteklasse des Fahrzeugs erfüllt. Gilt identisch im TS-Scheduler und im CP-SAT-Service (vorab aufgelöste Eligibility je Schritt).

4.2 Mitarbeiter (R1)

ID	Feld	Typ	Anmerkung
F01	Vorname	Text, req
F02	Nachname	Text, req
F03	E-Mail	Text
F04	Telefonnummer	Text
F05	Abteilung	Enum (G-1)	Folierung, Detailing, Lackschutz, Keramik, Reinigung, Werkstattleitung, Verwaltung, Sonstige
F06	Position / Berufsbezeichnung	Text frei	dekorativ; keine System-Logik (Skill ist Backbone)
F07	Wochenstunden	Zahl	Default 40
F08	Eintrittsdatum	Datum
F09	Geburtsdatum	Datum
F10	Status	Enum (G-1)	Aktiv, Pause, Urlaub, Krank, Inaktiv. Manuell setzbar durch Admin und Mitarbeiter selbst.
F11	Personal-Nr.	Text, system	auto, Format `EMP-####`
F12	Interne Notizen	Text lang

Sub-Entitäten / Tabs:

S1 Skills (Qualifikationsmatrix) — M:N → Skill mit Niveau (1–3) je Skill (siehe 4.1). Ersetzt das alte „Teilschritt-Qualifikationen"-Modell.
S1b Vertrauens-/Handling-Stufe (1–3) — wie wertvolle/empfindliche Fahrzeuge der Mitarbeiter bewegen/bearbeiten darf (Fahrzeugwert-Gate, siehe 4.1).
S2 Schichtzuweisungen — Liste von Referenzen auf Einträge im unternehmensweiten Schicht-Katalog (4.4). Keine freien Intervalle.
S3 Abwesenheiten & Soft-Blocks — Typ, Zeitraum, Reichweite (ganzer Tag | bestimmte Schichten), Härtegrad (hart=Abwesenheit | weich=Wunschfrei). Verfügbarkeit = Σ Schichten − Σ harte Abwesenheiten (Soft-Blocks reduzieren nicht, werden nur gemieden). Details §4.4a.
S4 Einsatzplan (derived) — Zuweisungen zu Auftrag/Teilschritt/Fahrzeug, Zeitraum, Status.
S5 Notizen über den Mitarbeiter — Manager verfasst. Zwei Sichtbarkeitsklassen:
- (a) Manager-Notiz (intern, nicht für Mitarbeiter sichtbar)
- (b) Nachricht an Mitarbeiter (für ihn sichtbar)
S6 Dokumente — generisches Attachment-Modell (4.10).
S7 Protokolle — ausgefüllte QM-Formulare (statisch nach Abgabe).
S8 Mitarbeiter-QR — Geräte-gebundener Token zum Login als Alternative zu Username/Passwort. Felder: Token, Erstellt am, Zuletzt genutzt, Gültig bis. Aktionen: Neu generieren, Sperren.

Abgeleitete Kennzahlen (read-only):

Urlaubstage (Rest), Überstundenkonto, Krankheitstage (Jahr) — abgeleitet aus Schichten + Abwesenheiten + Einsatzplan.
Auslastung heute — verplante Stunden / verfügbare Stunden.

4.3 Arbeitsplätze / Räume (R2)

ID	Feld	Typ	Anmerkung
F01	Name	Text, req
F02	Kategorie / Typ	Enum (G-1)	Seed: Folierbucht, Detailing-Bucht, Waschplatz, Innenraum, Empfang, Parkplatz, Lager, Sonstige
F03	Maximale Kapazität	Zahl	Anzahl gleichzeitiger Fahrzeuge
F04	Status (Konfiguration)	Enum	Aktiv, In Wartung, Gesperrt
F05	Ausstattung	M:N (G-1)	Seed: Hebebühne, Absauganlage, Tageslichtlampen, Druckluft, Nassbereich, Starkstrom
F05a	Ausführbare Skills	M:N → Skill	welche Skills an dieser Bucht ausgeführt werden können; ein Prozessschritt läuft nur in einer Bucht, die seinen geforderten Skill anbietet (Planung, §6.1).
F06	Interne Notizen	Text lang
F07	Erstellt am	System

Sub-Entitäten:

S1 Sperren — Beginn (datetime), Ende (datetime), Grund (Enum G-1: Defekt, Wartung/Instandhaltung, Reinigung, Umbau, Mitarbeiter-Ausfall, Sonstiges), Beschreibung (optional), Status (System), Erstellt von (System).
S2 Einsatzplan (derived) — Zuweisungen.
S3 Aktuelle Belegung (derived) — aktuelles Fahrzeug + Auftrag.
S4 Nächste Reservierungen (derived).
S5 Chronik — Audit-Log.

Live-Status (derived): Frei / Belegt / Überbucht / Gesperrt — abgeleitet aus Konfig-Status (F04) + aktuellen Zuweisungen vs. Kapazität (F03) + aktiven Sperren. Kein gespeicherter Wert — Badge, Karte und „Aktuelle Belegung"-Panel müssen aus derselben Berechnung kommen.

Physische Ist-Belegung / Inventur (umgesetzt v1): Neben der geplanten Belegung gibt es die physische Ist-Belegung je Arbeitsplatz/Parkplatz (welches Fahrzeug steht tatsächlich wo). Sie ist manuell korrigierbar („Inventur: steht alles an seinem Platz?") — Fahrzeuge entfernen/verschieben. Ein Auftrag kann geparkt werden (Fahrzeug auf einen Parkplatz mit freier Kapazität fahren, auswählbar). Doppelbelegungen (mehr Fahrzeuge als Kapazität) werden rot hervorgehoben. Auto-Erkennung von Abweichungen → OP-R2-1.

Fahrzeuge kommen nur über Aufträge oder Umparken in eine Bucht (umgesetzt v1): Eine Bucht wird ausschließlich über Auftrags-Aktionen (Produktion starten, Bucht wechseln) oder Umparken (Drag&Drop) belegt — kein manuelles Einsetzen beliebiger Fahrzeuge. Steht ein Fahrzeug in einer Bucht, ohne dass der Auftrag „in Arbeit" ist (angeliefert/pausiert/fertiggestellt, oder als Park-Überlauf), wird es als „geparkt – keine produktive Nutzung" markiert (gestrichelt, ähnlich Cool-down) — die Bucht ist belegt, aber nicht produktiv genutzt.

4.4 Schicht-Katalog (neu)

Unternehmensweite Stammdaten. Mitarbeiter beziehen sich auf Einträge (R1.S2).

ID	Feld	Typ	Anmerkung
F01	Name	Text, req	„Frühschicht", „Spätschicht", „Wochenende"
F02	Tage	Multi-Enum	Mo, Di, Mi, Do, Fr, Sa, So
F03	Startzeit / Endzeit	Zeit	mehrere Slots pro Tag möglich (Pause)
F04	Aktiv	Bool
F05	Art	Enum (logik-tragend)	`regulaer` (Default) · `standard` (Default-/Standard-Schicht) · `ueberlauf` (Überlauf-/Bereitschafts-Schicht — nur bei Bedarf belegen). Umgesetzt (OP-OPT-7 #180): `ueberlauf`-Schichten zählen nicht zur normalen Verfügbarkeit (nie still belegt); eine bestätigungspflichtige Hybrid-Variante öffnet sie unter Pönale (`BEREITSCHAFT_POENALE_PRO_MIN=5` — Wunsch 2 < Bereitschaft 5 < genehmigt 200) und zeigt die Wirkung als Vorschlag. (Wunschfrei-Pönale = #179.)

4.4a Abwesenheiten & Soft-Blocks (R1-S3)

Ein Block reduziert oder reserviert die aus Schichten abgeleitete Verfügbarkeit. Zwei orthogonale Achsen, im Editor (Mitarbeiter-Raum) erfassbar:

Härtegrad — hart (Urlaub/Krank): reduziert die Verfügbarkeit (D-2). weich = Soft-Block / „Wunschfrei": idealerweise frei zu halten, reduziert die Verfügbarkeit nicht, erscheint aber als eigenes Band im Plan und wird vom Optimierer bevorzugt gemieden (Pönale umgesetzt #179 in CP-SAT + TS-Fallback; abgestuft über genehmigt — einfacher Wunsch ×1 vs. genehmigt = quasi-hart ×100). Verallgemeinert das weiche Freihalte-Fenster aus OP-R8-11.
Reichweite — ganzerTag blockt den vollen Zeitraum [von,bis]; alternativ bestimmte Schichten: nur die Slots der gewählten schichtIds innerhalb des Zeitraums.

ID	Feld	Typ	Anmerkung
F01	Typ	Enum (G-1)	Urlaub/Krank … (nur bei hartem Block; leer bei Soft-Block)
F02	Von / Bis	Datum/Zeit	Zeitraum [von,bis); ganzer Tag = Tagesgrenzen
F03	Ganzer Tag	Bool	false ⇒ nur die Slots der `schichtIds`
F04	Schichten	Liste → Schicht-Katalog	betroffene Schichten, wenn !ganzerTag
F05	Hart	Bool	true = Abwesenheit (reduziert Verfügbarkeit) · false = Soft-Block (Wunschfrei)

4.5 Leistungen (R3a)

ID	Feld	Typ	Anmerkung
F01	Leistungsname	Text, req
F02	Kategorie	Enum (G-1)	Folierung, Versiegelung, Reinigung, Aufbereitung, Lackschutz, Sonstiges
F03	Status	Enum (G-1)	Aktiv, Inaktiv
F04	Standzeit	Stunden	Mindestdauer Fahrzeug vor Ort. NICHT Werktage.
F05	Interne Beschreibung	Text
F06	Richtwert eff. Arbeitszeit	Stunden, derived	Σ Teilschritte-Dauer
F07	Prozess-Definition	Ordered List	siehe unten

F07 Prozess-Definition (Reihenfolge relevant), pro Eintrag:

Teilschritt (FK)
Abhängigkeit (Enum, logik-tragend):
- Nach vorherigem = streng sequenziell, nach Abschluss aller vorherigen Schritte.
- Parallel = darf mit vorherigen überlappen.
- Frei = ohne Reihenfolge.
Dauer-Override (optional, sonst aus Teilschritt-Master).

4.6 Teilschritte (R3b)

ID	Feld	Typ	Anmerkung
F01	Name	Text, req
F02	Standarddauer	Minuten, req	Default-Arbeitszeit
F03	Beschreibung	Text
F04	Parallel möglich	Bool	verträglich mit anderen Schritten
F05	Optionaler Schritt	Bool	darf im Auftrag übersprungen werden
F06	Mehrtägig erlaubt	Bool	darf über mehrere Tage gestreckt werden
F07	Cool-down / Settle Time	Minuten	nach Schritt; Fahrzeug bleibt im selben Bay (Bay-Belegung), aber kein Mitarbeiter mehr nötig. Inkl. Nächte/Wochenenden (Echtzeit).
F08	Annahme-Schritt (Kunden-Intro)	Bool	wird auf Bringtermin terminiert
F09	QM-Schritt (Formular = Aufgabe)	Bool	Ausfüllen des Pflichtformulars IST die Aufgabe; auto-Abschluss bei Absenden
F10	Benötigte Arbeitsplatztypen	M:N → Arbeitsplatz-Typ
F11	Benötigter Skill	FK → Skill	genau einer (Regel: ein Prozessschritt erfordert immer nur einen Skill)
F11a	Mindest-Skill-Niveau (Güte)	1–3, Default 1	der geforderte Skill muss mind. dieses Niveau haben; z. B. Super-Premium-Folierung = 3
F12	Anzahl Personen	Zahl ≥ 1	wie viele Mitarbeiter mit diesem Skill gleichzeitig nötig sind (ersetzt „distinkte Skills")
F12a	Bucht-Anforderung	abgeleitet	Schritt läuft nur in einer Bucht, die F11 anbietet (Arbeitsplatz §4.3-F06) und vom passenden Typ (F10) ist
F13	Benötigte Rollen	Text frei	rein dekorativ
F14	QM-Protokollvorlagen	M:N → Formular + Pflicht-Flag	siehe 4.7
F15	Unterbrechung	Enum `erlaubt`/`vermeiden`/`verboten`	Darf ein laufender Schritt unterbrochen/pausiert werden (Preemption)? `verboten` = hart (z. B. Aushärtung), `vermeiden` = Soft-Goal. Default aus Indoor-Pflicht. Durchsetzung Scheduler: OP-R3-3
F16	Übernahme durch anderen MA	Enum `erlaubt`/`vermeiden`/`verboten`	Darf ein anderer Mitarbeiter den laufenden Schritt übernehmen? Default `erlaubt`. Durchsetzung: OP-R3-3

Implementiert (v1): F15/F16 als Stammdaten am Teilschritt (unterbrechung/uebernahme, server/src/model/types.ts); verboten bei der Unterbrechung wirkt bereits hart auf die Preemption (istUnterbrechbar). vermeiden (Unterbrechung) + die uebernahme-Regel werden server-seitig am manuellen Preemption-Hebel durchgesetzt (Reihung „erlaubt vor vermeiden" + Soft-Hinweis; das Resume behält die Crew → uebernahme: verboten bleibt gewahrt). Eine in CP-SAT integrierte Pönale bleibt offen — heute ohne Wirkung, da der Solver Schritte weder splittet noch auto-preemptet (erst bei künftigem Step-Splitting sinnvoll).

Prozess-Editor (OP-R3-3 — Editor komplett): Im Workspace „Prozesse" (Tabs Teilschritte/Leistungen) admin-editierbar — Teilschritte: Skill-Anforderung (F11/F11a/F12) + Eigenschaften (Dauer F02 · Cool-down F07/F07a · optional F05 · parallel F04 · mehrtägig F06 · Bucht-Typen F10 · Unterbrechung/Übernahme F15/F16); Leistungen: Stammfelder (Name/Standzeit/Status) + Prozess-Komposition (Schritt-Reihenfolge · Teilschritt je Schritt · Abhängigkeit · Dauer-Override · hinzufügen/entfernen). Teilschritte und Leistungen im Durable Object persistiert (schemaVersion 10, OP-R1-1-Muster; schedulerInput speist sie ein → Edits wirken hart auf Eignung/Machbarkeit/Taktung neuer Aufträge), pure Logik server/src/operativ/prozess.ts (setzeSkillAnforderung/setzeTeilschrittFelder/setzeLeistungFelder/setzeLeistungProzess, Self-Test npm run test:prozess), Editor pages/processes.component.ts. Die Eingriffsregeln (unterbrechung: vermeiden / uebernahme) werden seit #178 server-seitig am Preemption-Hebel durchgesetzt → OP-R3-3 ist damit server-seitig abgeschlossen. Offen nur noch (optional): eine in CP-SAT integrierte Pönale (erst bei Step-Splitting sinnvoll) + Leistung anlegen/löschen (kleiner Folgepunkt).

Scheduler-Wirkung: Ein Teilschritt belegt den Arbeitsplatz für (Dauer + Cool-down), Mitarbeiter nur für Dauer.

4.7 Formulare und Protokolle (R4)

4.7.1 Formular (Vorlage)

ID	Feld	Typ	Anmerkung
F01	Vorlagenname	Text, req
F02	Beschreibung	Text
F03	Aktiv	Bool	nur aktive Vorlagen sind verwendbar
F04	Version	Zahl, system	reiner Zähler, kein echtes Versioning; alte Versionen werden nicht aufbewahrt
F05	Felder	Ordered List	siehe 4.7.2

4.7.2 Feldtypen (systemfester Katalog, logik-tragend)

Checkbox — Ja/Nein-Abfrage
Kurztext — einzeilig
Langtext — mehrzeilig
Zahl — numerisch
Auswahl — Dropdown mit komma-separierter, pro Feld konfigurierbarer Optionsliste (admin-managed je Feld)
Foto-Upload — mit Min/Max Anzahl
Unterschrift — mit konfigurierbarer Signer-Rolle (Kunde oder Mitarbeiter, je Feld)

Pro Feld zusätzlich: Label (Text), Pflicht (Bool), typ-spezifische Konfiguration.

4.7.3 Protokoll (ausgefülltes Formular)

Bindung an: Auftrag + Teilschritt-Instanz + Mitarbeiter + Zeitstempel.
Speicherung als statischer Snapshot: ausgefüllte Werte + Labels werden eingebettet; keine Referenz auf Vorlagen-Version.
Nach Absenden unveränderlich — kein Edit, kein Resume, keine Drafts.
Submit ist nur möglich, wenn alle Validierungen passen (Pflicht, Min/Max Fotos, ggf. Zahl-Bereiche).
Bild-Auflösung/-Größe: offen — siehe OP-R4-1 (Altsystem speichert Originalauflösung → sehr große PDFs, langsames Speichern).

4.8 Kunden (R5)

Definition v1 (Vereinfachung, gilt verbindlich): Die Kundenverwaltung erfolgt zunächst extern (CRM). Wir pflegen hier nur einen Namen + einen Link ins CRM — keine vollständige Kunde-Entität. Die folgende Feldliste beschreibt das Vollmodell (Future); v1 nutzt davon nur Name + CRM-Link (am Auftrag geführt). Siehe Datenmodell-Definition in §4.9.

Eine Kunde-Entität mit Variantenfeldern für Privat- und Geschäftskunden. Anlegen und Bearbeiten in einem Single-Modal (kein Wizard).

ID	Feld	Typ	Anmerkung
F01	Kundentyp	Enum, logik-tragend	Privatkunde, Geschäftskunde (B2B)
F02	Vorname	Text, req
F03	Nachname	Text, req
F04	E-Mail	Text
F05	Telefon	Text
F06	Straße	Text
F07	PLZ	Text
F08	Ort	Text
F09	Interne Notizen	Text lang
F10	Status	Enum (G-1)	Aktiv, Blockiert, Archiviert
F11	Kdn-Nr.	Text, system	auto, Format `KD-#####`
F12	Kunde seit	Datum, system
F13	Zweigstelle	FK → Zweigstelle	siehe FM-1
F14	Firmenname	Text, req für B2B	nur B2B
F15	Anspruchs-Score	1–3, Default 1	1 = Normal/Gewerbekunden/Rennsport · 2 = gehobener Anspruch · 3 = Ultra-Premium-Anspruch. Fließt in die Wertigkeit des Auftrags ein (Reserve-Priorisierung, §6.2). Am Auftrag als `anspruch` geführt (vom Kunden abgeleitet, R7-F07b).
F15	Abweichende Rechnungsadresse	Bool, B2B	blendet ein: Firmenname (Rechnung), Straße, PLZ, Ort, USt-IdNr.

Tabs: Übersicht (Kontaktdaten + Auftragshistorie + Kennzahlen), Fahrzeuge (1:N), Dokumente, Chronik.

4.9 Fahrzeuge (R6)

Datenmodell-Definition v1 (Vereinfachung, gilt verbindlich):

Für jedes Fahrzeug (= alles, was ein Kunde bringt) besteht immer ein Auftrag — der Auftrag (R7) ist der zentrale Träger, das Fahrzeug existiert im System nur im Kontext eines Auftrags.

Ein Fahrzeug wird nicht als eigenständiges Datenobjekt geführt/getrackt (keine Fahrzeug-Registry, keine Stammdaten-Historie). Die nötigen Fahrzeug-Angaben werden am Auftrag erfasst und nur während des Auftrags getrackt.

Kunde: nur Name + CRM-Link am Auftrag (§4.8), Verwaltung extern.

Die folgende Feldliste (Kennzeichen, VIN, Marke …) ist das Vollmodell (Future); in v1 sind diese Felder — soweit nötig — Attribute am Auftrag, kein separater Datensatz. Damit entfallen für v1 u. a. FR-1 (Besitzerhistorie) und die Kunde↔Fahrzeug-1:N-Pflege; OP-R6-1 (Fahrzeug-Auftragsübersicht) und der Fahrzeug-Teil von OP-R7-11 (Owner) sind damit weitgehend gegenstandslos.

Umgesetzt v1 (OP-R7-16, 07-12): Auftrag.fahrzeug = { fin?, kennzeichen?, beschreibung? } — deckt F01 (Kennzeichen), F02 (FIN) und F03–F05/F07 als Freitext-Beschreibung ab. FIN ist Pflicht spätestens bei der Fahrzeugannahme (Check-in-Guard); Plausibilität ISO 3779 warn-only. Fotos über den Annahme-Schritt (OP-R4-3).

ID	Feld	Typ	Anmerkung
F01	Kennzeichen	Text
F02	Fahrgestellnummer (VIN)	Text
F03	Marke	Text
F04	Modell	Text
F05	Baureihe	Text
F06	Baujahr	Zahl
F07	Lackierung (Original)	Text
F08	Kilometerstand	Zahl
F09	Kunde	FK → Kunde	aktueller Besitzer (1:N)
F10	Interne Notizen	Text lang
F11	Eingang	Datum, system

Abgeleitete Felder (nicht gespeichert):

Status — In Bearbeitung / Pausiert / Blockiert / Abholbereit. Abgeleitet aus aktuellem Auftrag.
Standort / Arbeitsplatz — abgeleitet aus aktuell laufendem Teilschritt.

Sub-Entitäten:

Zustandsdokumentation (Mängel) — siehe 4.9.1
Medien (Fotos & Videos) — via Attachment-Modell (4.10)
Dokumente — via Attachment-Modell (4.10)
Chronik — Audit-Log
Auftragshistorie (derived)

4.9.1 Mangel (Zustandsdokumentation)

ID	Feld	Typ	Anmerkung
M01	Titel	Text, req
M02	Kategorie	Enum (G-1)	Lack, Karosserie, Folie, Innenraum, Glas, Sonstige
M03	Schwere	Enum (G-1)	Leicht, Mittel, Schwer, Kritisch
M04	Beschreibung	Text
M05	Bildnachweis	M:N → Medien	min. 1 Foto/Video (Future; in v1 noch nicht erfasst)
M06	Status	Enum (fest, logik-tragend — steuert das QS-Abnahme-Gate, daher nicht G-1-admin-editierbar)	Offen (Default), In Nacharbeit, Behoben (OP-QS-1 v1: 3-stufig)
M07	Entdeckt am	Datum
M08	Bezug	FK → Teilschritt-Instanz (optional)	Worauf bezieht sich der Mangel — die Schritt-Ausführung; daraus abgeleitet: Skill + ausführende Mitarbeiter (inkl. Helfer) → Bewertung deren Leistung. Ohne Bezug = allgemeiner Mangel.
M09	Nacharbeit-Aufwand	Zahl (min)	Aufwand für die Behebung/Nacharbeit in Minuten (geht in die Mitarbeiter-Statistik ein).

Implementiert (v1): erfasst in der Endkontrolle/QS am Auftrag (Auftrag.maengel, server/src/operativ/leistung.ts · qs.mangelErfassen). Kategorien v1 als feste Liste (G-1: künftig admin-editierbar). Nacharbeit (OP-UX-3): ein Mangel mit Behebungs-Aufwand kann per „Nacharbeit einplanen" zu einem echten, solver-eingeplanten Teilschritt werden (Auftrag zurück in Produktion, fertiggestellt → angeliefert); die Nacharbeit erscheint live im Gantt und verschiebt Fertigstellung/Reserve. Re-Entry-Bezug: §5.1 (Klärfälle/Wieder-Einstieg).

4.10 Attachment / Dokument (S-10)

Generische, modulübergreifende Datei-Entität. Ersetzt separate „Dokumente"-Tabs pro Modul.

ID	Feld	Typ	Anmerkung
F01	Datei	Blob	PDF, Word, Excel, Bild, Video
F02	Dokumenttyp	Enum (G-1)	z. B. Fahrzeugschein, Kaufvertrag, Servicebuch, Foto Anlieferung
F03	Ziel-Entität	Polymorph FK	Auftrag oder Fahrzeug oder Kunde
F04	Hochgeladen von	FK → Mitarbeiter
F05	Hochgeladen am	Datetime, system
F06	Quelle	Enum, system	Direkt-Upload, aus Formular-Feld

Beim Hochladen aus einem Formularfeld zur Laufzeit wählt der Mitarbeiter das Ziel (Auftrag / Fahrzeug / Kunde). Datei erscheint in der entsprechenden Sammlung.

Abgeleitete Sicht: „Dokument-Status" eines Fahrzeugs = Menge aller Dokumenttypen, für die mindestens eine Datei vorliegt.

5. Operative Entitäten

5.1 Auftrag (R7)

Zentrale operative Einheit. Verbindet Kunde, Fahrzeug, Leistungen und Ressourcen.

ID	Feld	Typ	Anmerkung
F01	Auftragsnummer	Text, system	auto, Format `#000.KW00.JJJJ` — `000` = laufende Nummer in der Kalenderwoche der Anlage, `KW00` = Kalenderwoche der Anlage, `JJJJ` = Jahr der Anlage (z. B. `#003.KW25.2026`).
F02	Status	Enum (G-1)	Geplant, Fahrzeug angeliefert (Key `angeliefert`), In Arbeit, Pausiert, Fertiggestellt, Abgeschlossen, Kontrolliert, Archiviert, Abgebrochen (terminal, Storno mit Pflicht-Grund) (S-6)
F03	Bringtermin / Wunsch-Anlieferung	Datetime, req
F04	Wunsch-Abholung	Datetime
F05	Fixer Abholtermin	Bool	Abholdatum unverschiebbar
F06	Eilauftrag	Bool	Scheduler-Priorisierung; verschiebt ggf. bestehende
F07	Kunde	FK → Kunde
F08	Fahrzeug	FK → Fahrzeug
F08b	Güteklasse	1–3, Default 1	Fahrzeugwert/-sensibilität; nur Mitarbeiter mit `vertrauensstufe >= gueteklasse` dürfen ran (siehe §4.1). Aus dem Fahrzeug ableitbar.
F09	Leistungen	M:N → Leistung	1..N; werden zu Teilschritt-Instanzen expandiert
F10	Besonderheiten / Sonderwünsche	Text lang	✅ gebaut (0.58.0): `Auftrag.sonderwuensche` — Freitext bei der Annahme erfasst (`auftrag.create`), im Bestätigungs-Dialog + Aufträge-Detail sichtbar. Struktur/Häufigkeits-Auswertung → OP-FIND-1; als geprüfter QS-Punkt → OP-QS-GATE-Erweiterungspunkt (vertagt).
F11	Interne Notizen	Text lang
F12	Auftragswert	Geld €	(siehe OP-R7-6)
F13	Geplante Fertigstellung	Datetime, derived	Ende des letzten Teilschritts
F14	Erstellt am	Datetime, system
F15	Zweigstelle	FK → Zweigstelle	siehe FM-1

Lifecycle (S-6) — drei Phasen: Anlieferung · Produktion · Abholung

Der Auftrag trennt klar zwischen Anlieferung (Fahrzeug kommt), Produktion (hier laufen die Prozesse) und Abholung (Fahrzeug geht). Jede Phase hat eigene Status:

Status	Bedeutung	Reservierung (§6.3)
Geplant	eingeplant auf Basis einer frühesten und spätesten Anlieferung, Fahrzeug noch nicht da	weich (umplanbar)
Fahrzeug angeliefert (Status-Key `angeliefert`)	Fahrzeug wurde angeliefert, Produktion noch nicht begonnen	hart
In Arbeit	Prozess wurde begonnen	hart
Pausiert	Prozess unterbrochen	hart
Fertiggestellt	Prozess abgeschlossen, Fahrzeug noch nicht abgeholt	keine
Abgeschlossen	Fahrzeug abgeholt	keine
Kontrolliert	Nachkontrolle durchgeführt	keine
Archiviert	nach 7 Tagen (ab Abholung) automatisch oder manuell	keine
Abgebrochen	Auftrag storniert (terminal; aus Geplant/Angeliefert/In Arbeit/Pausiert, Pflicht-Grund — auch als Klärfall-Lösungsweg „Abbruch")	keine

Zuweisungs-Invariante (R7): „Ohne Zuweisung kann ein Auftrag nicht in Arbeit sein." Jeder Übergang nach In Arbeit (Aktionen starten und fortsetzen) setzt voraus, dass dem Auftrag mindestens ein produktiver Mitarbeiter an einem (Nicht-Annahme-)Teilschritt zugeteilt ist (hatZuweisung). Helfer/Auszubildende (helferIds) zählen nicht als Zuweisung (sie tragen die Arbeit nicht), der nicht solver-geplante Annahme-Doku-Schritt zählt nicht. Ohne Zuweisung wird der Start abgelehnt und im UI als „⚠ Zuweisung nötig" ausgewiesen (die Start-Aktion ist dann nicht verfügbar). Da der Optimierer beim Materialisieren jedem Schritt Mitarbeiter zuteilt, ist die Invariante im Normalfall erfüllt; sie ist die Leitplanke gegen einen Produktionsstart ohne verantwortliche Person.
Nur geplante Aufträge werden vom Optimierer umgeplant (weich); ab Angeliefert sind die Ressourcen fix (hart, §6.3).
Fertigstellen schließt auch die noch offenen (geplanten) Teilschritte ab (Status → erledigt) und hält die tatsächliche Fertigstellung fest (§11.1); übersprungene/erledigte bleiben unverändert.
Nacharbeiten (Rückkante Fertiggestellt → Angeliefert): stellt sich vor der Abholung ein Mangel heraus, geht der Auftrag zurück in die Produktion (Nacharbeits-Schritt, §11.1 OP-QS-4); die ursprüngliche Plan-Fertigstellung bleibt für die Termintreue erhalten.
Abbrechen (terminal, mit Pflicht-Grund): aus jedem aktiven Status möglich — direkt oder als Klärfall-Lösungsweg „✕ Abbruch" (§5.1 Klärfälle); gibt Reservierungen frei und landet in der Chronik.
Auto-Archivierung: 7 Tage nach der Abholung (abgeschlossenAm) wird der Auftrag automatisch archiviert (oder jederzeit manuell ab „abgeschlossen"/„kontrolliert").
Archivierte Aufträge erscheinen nur im separaten Archiv-Bereich, nicht in Planung/Gantt; sie belegen keine Ressourcen.
Auftrags-Ende: Der Auftrag endet nach dem letzten Prozessschritt — geplanteFertigstellung = Ende des letzten Teilschritts. Annahme und Endausgabe sind keine eigenen Teilschritte, sondern belegen Parkplätze (R2).
In der UI erklärt ein FAQ/Howto-Panel („Wie funktioniert der Auftrags-Status?") die Phasen und Status direkt im Leitstand.

Produktion ↔ Bucht ↔ Parken (umgesetzt v1):

Produktion starten bedeutet, dass das Fahrzeug in eine Bucht gefahren wird — die Bucht wird damit belegt (Bucht-Auswahl beim Start; auch per Drag&Drop auf eine Bucht).
Bucht-Wechsel jederzeit möglich (Auswahl „Bucht wechseln" oder Drag&Drop Bucht→Bucht); wird protokolliert.
Parken (Fahrzeug auf einen Parkplatz) pausiert oder beendet die laufende Produktion: vorher wird nachgefragt (Pausieren ↔ Beenden) und ein Grund erfasst; beides landet in der Chronik des Auftrags. „Beenden" = Übergang nach fertiggestellt, „Pausieren" = pausiert; in beiden Fällen verlässt das Fahrzeug die Bucht.
Jeder Auftrag führt eine Chronik/Protokoll (Start, Bucht-Wechsel, Pause/Beenden …), sichtbar auf der Karte.

Teilschritt-Tracking & Bucht-Typ-Bindung (umgesetzt v1):

Jeder Prozessschritt ist einzeln trackbar: Status geplant → in Arbeit ⇄ pausiert → erledigt (übersprungen aus geplant). Buttons Start / Pause / Fortsetzen / Fertig je Schritt (nur wenn der Auftrag „in Arbeit" ist).
Ein Schritt ist an bestimmte Bucht-Typen gebunden (benoetigteArbeitsplatzTypIds). Steht das Fahrzeug nicht im geforderten Bucht-Typ, ist Umparken erforderlich — der Start des Schritts wird blockiert und „⚠ Umparken nötig" angezeigt (per Bucht-Wechsel/Drag&Drop lösen).
Schritt-Ereignisse landen in der Chronik; „Auftrag fertigstellen" schließt alle noch offenen Schritte ab.

Standard-Prozess (immer) & Klärfälle

Grundlegend — gilt für jeden Auftrag: Der Standard-Prozess besteht immer aus fünf Phasen, jede mit Dokumentation & Kommentieren:

Annahme — Fahrzeug entgegennehmen, dokumentieren & kommentieren (Zustand bei Annahme).
Vorbereitung — Fahrzeug vorbereiten (Waschen/Reinigen), Car-Check (technische/optische Prüfung) und Folien-Produktion (Zuschnitt/Druck der Folie — kann nach der Annahme beginnen, parallel zur Fahrzeug-Vorbereitung), dokumentieren & kommentieren. Sprechendes Label „Vorbereitung" (vormals „Aufbereitung", Selbsterklärbarkeit); der technische Phasen-Key bleibt aufbereitung.
Produktion — die eigentliche Wertschöpfung (z. B. Folien-Applikation) mit konfigurierbaren Prozessen/Prozess-Schritten (Leistung → Teilschritte, R3). Bessere Benennung + Differenzierung Vor-Produktion (Folien-Zuschnitt, Material-Bestellung) → OP-PHASE-1.
Endkontrolle / Quality-Check. Sprechendes Label „Quality-Check" (vormals „QS"); technischer Phasen-Key bleibt qs. QS-Vollständigkeits-Gate (OP-QS-GATE, server-hart): Die Abholung (abholen, fertiggestellt → abgeschlossen) ist erst möglich, wenn alle nicht übersprungenen Prozessschritte erledigt und (falls pflichtig) dokumentiert sind (Doku-Kommentar + Foto-Pflicht) und kein QS-Mangel mehr offen ist — geprüft über istAbnahmebereit (der Server lehnt sonst ab + meldet die offenen Punkte). Nacharbeit nach einem QS-Mangel wird als QS-Phasen-Schritt (TeilschrittInstanz.phase = 'qs') geführt und dokumentiert so, dass Nacharbeit nötig war; nach Erledigung läuft die QS frisch (kein veraltetes „Bestanden"). QS-Nacharbeit direkt & zuweisbar (OP-QS-4, v0.46.0): Die Nacharbeit wird einstufig direkt in der Endkontrolle als Prozessschritt erfasst (qs.nacharbeitErfassen, überschreibbare Zeit; der Mangel entsteht automatisch im Hintergrund und speist die Qualitätsbewertung), lässt sich manuell zuweisen (teilschritt.zuweisen, bleibt bei Re-Opt fix) oder automatisch vom Optimierer besetzen, und offene Nacharbeits-Schritte werden nicht mehr auto-erledigt → das Abnahme-Gate erzwingt sie lückenlos. Pro Leistung definieren Minuten-Schwellwerte (nacharbeitSchwelleGesteigertMin/ExtremMin), ab wann ein Auftrag als gesteigert/extrem markiert wird (aus geplanter oder tatsächlicher Nacharbeit, abgeleitet). Sonderwünsche als geprüfter QS-Punkt → künftiger Ausbau (eigener PR).
Abholung.

Klärfälle-Prozess (Unterbrechung, separater Skill): Jeder Prozess kann an jeder Stelle unterbrochen werden — dann startet der Klärfälle-Prozess (eigener Skill „Klärung"): Eskalation, Dokumentieren & Kommentieren. Nach Klärung führt der Weg zurück in den Prozess (an die unterbrochene Stelle) oder per Sprung zu Quality-Check oder zu einem anderen Schritt oder in den Abbruch.

Umgesetzt — Klärungs-Engine (07-11, v0.74.0, OP-R3-1-Folge): Das Melden ist eine echte Unterbrechung (laufende Schritte werden pausiert, der auslösende Schritt wird am Klärfall erfasst); das Lösen ist geroutet entlang genau dieser vier Wege — zurueck (Schritte bleiben pausiert, Weiterarbeit über ▶) · qs (offene Nicht-QS-Schritte werden Klärungs-übersprungen — die sanktionierte Pflicht-Skip-Ausnahme, OP-R3-5) · schritt („ab hier weiter" bei offenem Ziel oder Einschub-Wiederholung eines Katalog-Schritts, den der Optimierer einplant) · abbruch (Storno). Lösungs-Kommentar ist Pflicht; jede Meldung/Lösung landet in Chronik + D1-Audit und triggert die Re-Optimierung. Kapazitätstragender Klärungs-Arbeitsschritt ✅ (07-12, v0.75.0): die Klärungsarbeit selbst ist opt-in als geplanter Schritt einplanbar (auftrag.klaerungEinplanen, Presets 15/30/60 min) — Katalog-Template ts-klaerung mit Skill „Klärung" (Seed + Migration v19, mind. ein Seed-Mitarbeiter trägt den Skill), Instanz in der aktuellen Auftrags-Phase, vom Optimierer einer qualifizierten Person zugeteilt (nacharbeit-/zusatzSchritt-Muster). Klärzeit zählt damit als Auslastung (True-North-Frage 1), der Klärende ist nicht doppelt verplanbar; Doku-Pflicht beim Erledigen = Klärungs-Doku. Max. eine offene Klärung je Klärfall; kurze formlose Klärungen bleiben bewusst ohne Planschritt.

Umgesetzt — Notfall-/Schaden-Alert (07-14, v0.85.0, OP-ALERT-1 Slice 1): Der Klärfall trägt jetzt eine Art (regulaer | notfall). Der Notfall ist der härtere, sofort sperrende Spezialfall für einen unerwarteten, nicht vom Betrieb verursachten Fahrzeugschaden (Beule/Kratzer, bei Annahme nicht sichtbar) — „eskalieren statt verschlimmbessern": der Werker soll nicht still selbst nachbessern, sondern Alarm schlagen. Zusatzregeln ggü. dem regulären Klärfall: (1) Hard-Stop aller laufenden Schritte, (2) erzwungene Eskalation, (3) Fahrzeug gesperrt („nicht weiter anfassen", abgeleitet fahrzeugGesperrt = art === 'notfall', D-2). Auslösung über den auffälligen 🚨 Notfall / Schaden-Knopf im geteilten Detail-Panel (Grund pflicht); eigener Audit- Event notfall.gemeldet (Grund + gestoppte Schritte); Auflösung über dieselbe Klärungs-Engine (zurück/QS/Schritt/Abbruch). Bewusst keine Parallel-Mechanik (Leitprinzip Einfachheit). Offene Folge-Slices: Foto-/Video-Zwang (OP-QS-1), Alarm-Optik/-Ton auf dem Leit-Bildschirm (OP-KOMM-1), Alert-Knopf im Werker-Modus. Design/Slice-Plan: architektur/Notfall-Alert.md.

Verhältnis zum Status-Lifecycle (oben): Der Standard-Prozess beschreibt die fachlichen Arbeitsphasen/-schritte; der Lifecycle die Reservierungs-/Status-Sicht (geplant…archiviert). „Produktion" entspricht in Arbeit, eine Unterbrechung/Klärfall entspricht pausiert mit Klärungs-Kontext. Annahme/Vorbereitung/Quality-Check sind hier — anders als die frühere Vereinfachung „Annahme/Endausgabe sind keine Teilschritte" — explizite Phasen mit Doku-Aktivität; ihre Ressourcen-/Skill-/Zeit-Modellierung ist Umsetzungs-Thema → OP-R3-1. Hinweis (06-24): Eine Analyse aus Daten-/Prozess-/UX-Sicht — warum die heutige Trennung Lifecycle ↔ Phasen unscharf/nicht intuitiv wirkt und welches Zielbild („Phasen first-class") empfohlen wird — steht in Flow-Analyse.md.

Sub-Entitäten / Tabs:

Leistungen & Teilschritte — geordnete Teilschritt-Instanzen, je mit Sollzeit, Dauer-Override, Planung (Arbeitsplatz, Datetime, Mitarbeiter(s) inkl. Helfer), Status (Geplant/Erledigt), QM-Protokoll-Status, Überspringen-Flag (erfordert Begründung).
Protokolle — ausgefüllte QM-Formulare im Auftrags-Kontext.
Pausen & Sperren — Auszeiten innerhalb des Auftrags.
Dokumente — via Attachment-Modell.
Chronik — Audit-Log.

Eilauftrag: Der Scheduler zieht den Auftrag vor; bestehende Aufträge werden bei Bedarf verschoben (sofern nicht „Fixer Abholtermin" verletzt würde).

Termin-Ampel auf der Liste (abgeleitet aus geplanter Fertigstellung vs. Wunsch-Abholung):

Fortschritts-Indikator (R7-P1)

✅ Umgesetzt (07-14, v0.84.0). FortschrittsIndikatorComponent (client/.../leitstand/fortschritts-indikator.component.ts, geteilt): eine 🚗-Kette Annahme→Teilschritte→Ausgabe, Farbe je Status (teilschrittStatusColor, eine Quelle mit orders/auftrag-detail-panel — Emoji-Glyphen tragen selbst keine CSS-Farbe, daher färbt der Chip/Ring dahinter). Kompakt auf der Fluss-Karte (orders.component.ts) und im Fly-in-Header (auftrag-detail-panel.component.ts), ausführlich im Aufträge-Detailpanel — anklicken öffnet dort wie zuvor das geteilte Detail-Fly-in, fokussiert auf den Schritt.

Jeder Auftrag zeigt seinen Fortschritt als Linie kleiner Fahrzeug-Symbole entlang der Prozesskette: je ein Auto pro Prozessschritt (Teilschritt-Instanz), plus je ein Symbol am Anfang für Annahme (Bring/Intro) und am Ende für Ausgabe (Abholung/Übergabe).

Farbliche Darstellung je Schritt-Status: abgeschlossene Schritte sind farblich abgesetzt (erledigt), der aktuell laufende Schritt hervorgehoben, geplante Schritte neutral; übersprungene Schritte (R7, optionale Teilschritte) erkennbar markiert.
Die Kette gibt auf einen Blick wieder, wo das Fahrzeug im Ablauf steht (von Annahme bis Ausgabe).
Animation: Plan-Änderungen/Optimierungen (R8-G1) aktualisieren den Indikator animiert; ein abgeschlossener Schritt färbt sich mit einem kurzen Übergang ein.
Erscheint sowohl in der Auftrags-Liste/-Karte als auch im Auftrags-Detail; speist sich aus den Teilschritt-Instanz-Status (Geplant/Erledigt/Übersprungen) und der Prozess-Reihenfolge.
Auftrags-Karte zeigt zusätzlich: die geplante Fertigstellung sprechend/relativ („morgen 08:00", „Dienstag 17:00", „Montag nächste Woche 08:00") neben dem absoluten Datum, sowie ein Mini-Gantt (kompakte Zeitleiste der Teilschritte dieses Auftrags). (Umgesetzt im Prototyp.)

5.2 Planung (R8)

Operative Disposition aller Ressourcen über die Zeit. Drei Unterseiten.

5.2.1 Tages-/Wochen-/Monatsansicht (Gantt)

Vertikal: Mitarbeiter-Zeilen + Arbeitsplatz-Zeilen (Mitarbeiter-Bereich umschaltbar).
Horizontal: Zeitachse, Granularität abhängig von Ansicht.
Hatched cells = außerhalb Arbeitszeiten/Sperren – nicht buchbar.
Termin-Block: Fahrzeug + Teilschritt + Zeit. Erscheint auf Mitarbeiter- und Arbeitsplatz-Zeile (gespiegelt).
Drag & Drop zur Neuzuweisung mit Validierung: keine Überlappung, Skill-Match (hart), innerhalb Schichten, Standzeit/Cool-down-Konsistenz.
„Nicht zugewiesene Schritte (n)" – einklappbare Liste.
Klick auf Termin-Block → Termin-Details-Panel mit voller Auftrags-Chronologie.
R8-G1 Animierte Plan-Änderungen — Optimierungen (Solver-Lauf) und Umplanungen werden animiert dargestellt: Termin-Blöcke bewegen sich sichtbar von ihrer alten an ihre neue Position (statt hart zu springen), neu eingeplante Blöcke blenden ein, entfallende aus. Von einer Änderung betroffene Aufträge werden kurz hervorgehoben. Die Sichtbarkeit der Änderung gilt auch auf der Auftrags-Darstellung selbst (Karte/Liste, nicht nur im Gantt) — z. B. Hervorhebung der geänderten Fertigstellung und des Fortschritts-Indikators (R7-P1).
R8-G2 Optimierungs-Vorschau (Was-wäre-wenn, A-4) — Vor dem Anwenden zeigt der Optimierer, was er ändern würde: Diff je Auftrag (Fertigstellung vorher → nachher, verschobene Teilschritte/Buchten), das Δ der Σ-Durchlaufzeit und des Makespan, sowie pro Auftrag „früher/später" (grün/rot). Dazu ein sprechendes Narrativ („was wurde besser/schlechter und warum"). Wichtig: die „vorher"-Termine sind je Auftrag einzeln geschätzt; im gemeinsamen, konfliktfreien Plan konkurrieren Aufträge um knappe Ressourcen → manche rücken nach hinten (Σ-Durchlaufzeit kann steigen, ist aber erstmals haltbar). Der Nutzer bestätigt („Anwenden") oder verwirft. Narrativ v1 regelbasiert; optional als KI-Text (A-4 LLM-Layer), siehe OP-AI-1.

5.2.2 Angebotsmodus

Feasibility-Tool. Eingaben: Kunde (optional), Leistung, Wunsch-Anlieferung, Wunsch-Abholung, Fixer Abholtermin. Ausgabe: Liste verfügbarer Start-Zeitfenster, durchsatzoptimiert (kein automatischer Auftrag wird angelegt).

Termin-Vorschlag in der Annahme (✅ gebaut, 0.58.0, OP-UX-1/U9): Sobald in der Annahme die Leistung (+ Anlieferung/Güteklasse) gewählt ist, wird der frühestmögliche Abholtermin (TS-Scheduler-Dry-Run auftrag.terminvorschlag, abholbereit inkl. Standzeit) direkt angeboten — ein leeres Wunsch-Abholung-Feld wird vorbefüllt, ein Hand-Wert bleibt (mit „Übernehmen"-Angebot). Detail: docs/architektur/Operative-Durchgaengigkeit.md §U9.

5.2.3 Planungs-Konflikte

Liste aller offenen Konflikte mit zwei Auflösungspfaden pro Konflikt:

Auto = automatische Auflösung durch den Scheduler
Wizard = geführte manuelle Auflösung

Tabs: Akute / Gelöste. Filter: Typ, Schwere, Datum (noch offen, OP-R8-1). Konflikt-Typen sind erweiterbar (G-1). Alle 6 Beispiel-Typen umgesetzt (OP-R8-1):

Mitarbeiter fehlt (Hoch) — ✅ eingeplanter Mitarbeiter hat im Zeitfenster einen harten Ausfall (krank/Urlaub/inaktiv)
Arbeitsplatz fehlt (Mittel) — ✅ eingeplante Bucht ist als Ganzes außer Betrieb (KonfigStatus)
Sperre kollidiert mit Auftrag (Mittel) — ✅ ein Sperr-Fenster einer sonst aktiven Bucht überschneidet das geplante Zeitfenster
Standzeit-Verletzung — ✅
Skill-Lücke — ✅
Überbuchung — ✅

Detaillierte Festlegung siehe §11 (Offene Punkte). Header-Aktion: „Alle automatisch lösen" – Bulk-Auflösung; darf keine neuen Konflikte erzeugen (✅ umgesetzt, OP-R8-7).

Direkte Anzeige (umgesetzt, v1): Konflikte werden direkt im Leitstand angezeigt (Konflikt-Feed) und mit einem ⚡-Symbol am betroffenen Auftrag markiert. v1 erkennt den Termin-Konflikt „Abholung gefährdet/überfällig" (geplante Fertigstellung > Wunsch-Abholung). Die vollständige Konflikt-Engine (weitere Typen) ist OP-R8-1.

Konflikt-Lösen-Wizard (umgesetzt, v1 — OP-R8-2/3): Pro Konflikt bietet ein „Konflikt lösen"-Wizard die volle Hebel-Liste, abgeleitet aus der Prozess-Definition des Auftrags, jeweils mit berechneter Auswirkung (neue Fertigstellung, Δ früher/später, „Konflikt gelöst ✓"):

Wunsch-Abholtermin anpassen — auf die geplante Fertigstellung setzen (löst den Termin-Konflikt ohne Planänderung; ursprünglicher Wunschtermin bleibt gespeichert, §11.1).
Optionalen Teilschritt überspringen — je optionalem Schritt der Leistung (teilschritt.optional) ein Hebel; Auswirkung = Neuplanung ohne diesen Schritt (die restlichen rücken vor). Anwenden markiert den Schritt als übersprungen (Begründung gesetzt) und plant den Auftrag neu.
Als Eilauftrag priorisieren — gemeinsame Neuplanung mit Vorrang; zeigt konkret, welche anderen weichen Aufträge dadurch nach hinten rücken (Auftragsnummer, vorher → nachher, Verzögerung) und ob deren Wunsch-Abholtermin trotzdem noch eingehalten werden kann (Reserve in Tagen) oder verletzt würde.
Engpass beheben — Hinweis (nicht automatisch lösbar): knapp besetzte geforderte Qualifikation(en) der noch offenen Schritte (Skill, den nur ≤1 Mitarbeiter beherrscht) → Überstunde/zusätzliche Kraft.

Auto-Resolve — Header-Aktion „Alle automatisch lösen" (umgesetzt, Slice 1 — OP-R8-7): wählt je Termin-Konflikt den wirksamsten Hebel aus derselben Liste, den der Wizard anzeigt (Rang: optionalen Schritt überspringen > Eilauftrag > Preemption/Unterbrechen > Wunsch-Abholtermin anpassen als letzter Ausweg) — Garantie: kein bislang unkonfliktierter Auftrag gerät dabei neu in Terminverzug (Prüfung gegen die zu Beginn bekannten Konflikte). Ohne sicheren Hebel bleibt der Konflikt für den manuellen Wizard offen. Noch offen: Überstunden-/Kapazitäts-Modellierung als anwendbarer Engpass-Hebel (würde die Auto-Resolve-Trefferquote erhöhen).

5.3 Dashboard / Leitstand (R9)

5.3.1 Dashboard (Überblick)

KPI-Strip: Offene Aufträge, Heute geplant, Planungsscore (%), Mitarbeiter aktiv, Freie Kapazität nächste 30 Tage.
Tägliche Highlights: Geburtstage, Jubiläen der nächsten 14 Tage.
Planungsstatus mit Ampel + offene Konflikte + Link zur Planungsübersicht.
Freie Kapazitäten pro Leistung – mit Anzeige des Engpass-Faktors (limitierende Ressource: Skill, Arbeitsplatz oder Mitarbeiter).
Heutige Aufträge.
Schnellaktionen: Auftrag planen, Krankmeldung.

5.3.2 Leitstand (Live-Steuerung)

Live-Zeitstempel.
KPI-Strip: Aktive Aufträge, Fixe Abholungen, Pausiert, Blockiert, Ø Auslastung.
Mitarbeiter-Karten: Status, AKTUELL (laufende Arbeit) oder EMPFEHLUNG (nächster Schritt).
Empfehlungs-Algorithmus (OP-R9-1 entschieden): harte Bedingung = Skill-Match; unter eligiblen Kandidaten = global durchsatz-optimal.
Zusätzlich: Überstunden-Vorschläge – Hinweis, welche Überstunde welcher Person den Durchsatz verbessern würde, mit quantifiziertem Effekt.
Side-Rail: Blockierte Aufträge, Pausierte Aufträge, Fixe Abholungen heute, Ressourcen-Konflikte (Counter + Anzeigen).
Arbeitsplätze-Live: Belegungs-Karte je Bay.

6. Scheduler-Verhalten

6.1 Harte Constraints

Skill-Match (mit Niveau): Mitarbeiter muss den einen geforderten Skill (F11) des Teilschritts mindestens auf dem geforderten Niveau (mindestSkillNiveau) halten.
Personenanzahl: ein Teilschritt braucht F12 Personen mit diesem (einen) Skill gleichzeitig (distinkte Mitarbeiter).
Bucht-Skill: der Schritt läuft nur in einer Bucht, die den geforderten Skill anbietet (Arbeitsplatz §4.3-F05a) und vom passenden Typ (F10) ist.
Vertrauensstufe ↔ Güteklasse: nur Mitarbeiter mit vertrauensstufe >= gueteklasse des Fahrzeugs dürfen zugeteilt werden (Fahrzeugwert-Gate; siehe §4.1).
Arbeitszeit-Schicht: Zuweisung nur innerhalb assignierter Schichten minus Abwesenheiten.
Sperren: Arbeitsplatz darf während aktiver Sperre nicht zugewiesen werden.
Standzeit: Fahrzeug muss F04 Standzeit (Stunden) in Summe vor Ort verbringen. Bestimmt die früheste Endausgabe/Abholbereitschaft (= max(Ende letzter Schritt, Anlieferung + Standzeit)) und verlängert ggf. die Stellplatz-Belegung — nicht das Auftrags-Ende (der Auftrag endet nach dem letzten Prozessschritt).
Cool-down: nach jedem Teilschritt bleibt der Bay für F07 belegt, ohne Mitarbeiter.
Abhängigkeit: Nach vorherigem = nach Abschluss aller vorherigen Schritte; Parallel = darf überlappen; Frei = ohne Reihenfolge.
Fixer Abholtermin: harte Deadline für Auftrags-Ende.

6.2 Weiche Ziele (Optimierungsfunktion)

Maximierung Werkstattdurchsatz (globales Optimum, nicht lokale Mitarbeiter-Auslastung).
Vermeidung von Mitarbeiter-Wechseln (Pönale G-2 = 5 Min Default).
Vermeidung von Lücken < 15 Min (G-3, nicht eingeplant).
Eilauftrag: Priorität anheben.
Reserve-Kriterium (umgesetzt v1): möglichst wenige Aufträge mit < 1 Tag Reserve bis zum Wunsch-Abholtermin (primäre Pönale je „knappem" Auftrag); sekundär höhere Reserve bei höherwertigen Aufträgen — gewichtet mit der Wertigkeit = max(Güteklasse, Kunden-Anspruch) (höherwertige Aufträge werden bevorzugt früher fertig). Im CP-SAT als gewichtete Zielterme (tight-Pönale + wertigkeits-gewichtetes Reserve-Defizit), im TS-Fallback über die Einplan-Reihenfolge (Deadline, dann Wertigkeit).

6.3 Reservierungsmodi

Weich (Unbestätigt-Auftrag): Ressourcen reserviert, können bei Bedarf überschrieben werden.
Hart (Aktiv-Auftrag): Ressourcen blockiert.

Konfliktauflösung bei Kollision weich/hart: harte Reservierungen gewinnen; weiche werden zur Konfliktbehandlung gemeldet (Detail OP-R7-3).

6.4 Mehrere Personen je Schritt (vormals „Helfer")

Ein Teilschritt erfordert genau einen Skill (R3b-F11), aber ggf. mehrere Personen mit diesem Skill gleichzeitig (F12 ≥ 1). Alle zugeteilten Personen müssen den einen Skill auf dem geforderten Niveau halten (kein „distinkter Helfer-Skill" mehr). Im Termin-Detail werden alle beteiligten Mitarbeiter angezeigt.

6.4.1 Ausbildung als Helfer-Leistung (implementiert v1)

Neben den produktiv zugeteilten Personen (F12, planungsrelevant) kann ein Schritt Helfer/Auszubildende tragen (TeilschrittInstanz.helferIds). Zweck: Ausbildung am echten Auftrag.

Helfer reduzieren die Zeit NICHT und blockieren keine zusätzliche Kapazität — sie sind rein operativ und gehen nicht in den Solver ein (Ausbildung ≠ Kapazität). Sie werden während/vor der Ausführung im Aufträge-Detail zugeteilt.
Beim Abschluss eines Schritts entsteht je Teilnehmer (produktiv und Helfer) ein Leistungsnachweis (Fakt). Helfer sammeln so Erfahrung, ohne als produktive Ressource zu zählen. Produktive Zuteilung gewinnt über Helfer (kein Doppel-Nachweis).
Ausbildungsziele & Vorschlag: Je Mitarbeiter sind Ausbildungsziele (Skill-IDs, Mitarbeiter.ausbildungsZiele) pflegbar. Für jeden Mitarbeiter mit einem Ziel-Skill, der frei/verfügbar ist (Stammdatum „aktiv", nicht auf einem laufenden Auftrag), schlägt das System die Einplanung als Helfer auf passende offene Schritte (mit diesem Skill) vor — als „Optimierung" auf der Mitarbeiter-Karte (Ein-Klick „+ Helfer") und hervorgehoben (🎓) in der Helfer-Auswahl des Auftrags. Abgeleitet (ausbildungsVorschlaege), nichts gespeichert. Verfügbar = Stammdatum „aktiv" + nicht auf einem laufenden Auftrag und zum geplanten Schritt-Beginn tatsächlich verfügbar (Schicht aktiv + keine Abwesenheit, über mitarbeiterAvailability geprüft — OP-R1-2 #6). Der Vorschlag bleibt unverbindlich.
Penalty-freies Abziehen (G-2-Ausnahme): Helfer-/Ausbildungs-Tätigkeit ist kein produktiver Kontext im Sinne der Wechsel-Pönale (G-2). Kann ein Helfer auf einem echten Auftrag gebraucht werden, lässt er sich jederzeit ohne Pönale abziehen (er steckt nicht im Solver, sein Entfernen verschiebt keinen Plan).

6.5 Leistungsnachweis, Mitarbeiter-Statistik & Erfahrung (implementiert v1)

Beim Abschluss eines Teilschritts wird je beteiligtem Mitarbeiter ein Leistungsnachweis gespeichert (Fakt): Auftrag, Teilschritt, verwendeter Skill, produktiv/Helfer, Vorgabe-Dauer (geplant) vs. Ist-Dauer (aus tatsächlichen Start/Ende-Stempeln). Mängel (§4.9.1) referenzieren die Schritt-Ausführung und tragen den Nacharbeit-Aufwand.

Daraus abgeleitet (nie gespeichert — D-2 „Derived State nie speichern"), gezeigt auf der Mitarbeiter-Karte:

wie oft welcher Schritt mit welchem Skill durchgeführt wurde (inkl. Helfer-Anteil),
Dauer als Verteilung min/avg/median/max,
durchschnittliche Abweichung von der Vorgabe,
Nacharbeit-Quote + Ø-Aufwand (aus den in der QS gefundenen Mängeln),
eine Bewertung (0–100) und Erfahrungspunkte.

Erfahrungspunkte (XP) — Regeln (konfigurierbar): produktiv > Helfer · Bonus bei „im Plan" · Malus je Mangel × Schwere · güteklassen-gewichtet (schwerere Fahrzeuge zählen mehr: Faktor 1 / 1,25 / 1,5 für Güteklasse 1/2/3) · Helfer anteilig: ein Helfer-Einsatz, der unterbrochen wird oder verspätet beginnt, gibt nur anteilige XP (lernanteil ∈ (0,1]; Verspätung mindert proportional ab einer Toleranz, Unterbrechung halbiert). Produktive Einsätze behalten vollen Anteil.

Niveau-Aufstieg-Vorschlag (OP-R1-2): Hat ein Mitarbeiter auf einem Skill (Niveau < 3) genug produktive, fehlerarme Praxis (≥ N Ausführungen, niedrige Nacharbeit-Quote, hohe Bewertung), schlägt das System auf der Karte vor, das Skill-Niveau anzuheben (Ein-Klick). Abgeleitet (niveauVorschlaege), nichts gespeichert.

Code: server/src/operativ/leistung.ts (pures, getestetes Modul · npm run test:leistung), Verdrahtung in server/party/leitstand.ts; UI in pages/staff.component.ts (Karte + Aufstieg/Ausbildung-Vorschläge), pages/orders.component.ts (Helfer-Zuteilung), pages/quality.component.ts (Mangelerfassung).

7. Querschnittsfunktionen

7.1 Vorlagen-Bibliothek (einheitliches Pattern für Leistungen und Formulare, S-8)

Zwei Quellen: plattform-kuratiert (Vendor-Katalog) + tenant-eigen.
Versionierungs-Anzeige (v1, v2 …) und „Bereits vorhanden"-Indikator.
Import = Snapshot (Kopie). Spätere Änderungen an der Vorlage propagieren NICHT in importierte Instanzen.
Filter: Kategorie, „Nur neue Vorlagen".

Standard: Username + Passwort.
Alternativ: Mitarbeiter-QR-Code (geräte-gebunden, mit Token-Verfall, neu generierbar, sperrbar).

7.3 Zwei UI-Modi

Werkstattleitung-Sicht: Dashboard, Leitstand, Planung, Stammdaten.
Mitarbeiter-Ansicht: Ein-Karten-Sicht „dein nächster Schritt" + QM-Formular-Ausfüllung + Mängel-Erfassung. Details OP-R9-4.

7.4 Kunden-Self-Service-Link

Optional bei Auftragsanlage: Kunde erhält Link, um Kontakt- und Fahrzeugdaten selbst zu vervollständigen (Datenfelder und Security-Modell zu klären, OP-R7-7).

7.5 Audit / Chronik

Jede relevante Entität führt eine Chronik: Änderungen, Statusübergänge, Zuweisungen, Skip-Begründungen, etc. werden automatisch protokolliert.

7.6 Validierung

Speichern/Submit ist nur möglich, wenn alle definierten Regeln passen (Pflichtfelder, typ-spezifische Bereiche, etc.). Inkonsistente Daten gelangen nicht in den Datenbestand.

7.7 Single-Source-of-Truth für Derived State

Status, Standort, Auslastung und ähnliche abgeleitete Werte werden nirgends doppelt gespeichert. Jede UI-Komponente, die einen derived Wert anzeigt, holt ihn aus derselben Berechnung – Voraussetzung, um Inkonsistenzen wie im Altsystem (Folierbucht-1-Bug) zu vermeiden.

8. Nicht-funktionale Anforderungen

Mehrmandantenfähig (Vendor-curated Vorlagen + tenant-eigene Daten klar getrennt).
Multi-Zweigstelle pro Mandant (FM-1).
Rollenbasierte Sichten: mindestens Werkstattleitung und Mitarbeiter. Admin-Rolle für Stammdaten.
Echtzeit-Updates im Leitstand und in der Planung (Live-Belegung sichtbar).
Mobil-fähige Mitarbeiter-Ansicht (Tablets in der Werkstatt).
Foto-/Video-Capture aus der Mitarbeiter-Ansicht.
Digitale Unterschrift auf Touch-Geräten (Kunde und Mitarbeiter).
Audit-Trail vollständig (Chronik je Entität).
Datenexport (CSV/Excel) für Berichte.
DSGVO-Konformität: Recht auf Auskunft, Löschung (Status „Archiviert" bzw. Soft-Delete).
Backups, Snapshot-Wiederherstellung.
Internationalisierung: Default Deutsch; UI-Sprachen vorbereitend, ausdrücklich auch Chinesisch und Ukrainisch (mehrsprachige Werkstatt-Belegschaft, nicht nur EU-Markt). Domänenbegriffe bleiben deutsch (Selbsterklärbarkeit), übersetzbar ist das UI-Chrome → OP-I18N-1.

9. Architektur-Empfehlungen

Empfehlungen sind nicht bindend, aber begründet aus der Analyse.

A-1 — Dreischichtiger Ansatz

Trennung von Lifecycle-State-Machine (Auftrag, Teilschritt), Constraint-Solver (Scheduler) und KI-Layer (Empfehlungen, Erklärungen, Kunden-Kommunikation).

A-2 — Workflow-/State-Machine-Layer für Lifecycle

Kandidaten: Camunda / Temporal / Zeebe. Für Auftrags-Lifecycle und Teilschritt-Ausführungs-Zustände. Nicht für Planung.

A-3 — Constraint Solver für Scheduling

Kandidaten: OR-Tools CP-SAT, OptaPlanner, oder eigener MIP/CSP-Resolver. Deterministisch, erklärbar, beweisbar zulässig. Kernintelligenz des Systems.

A-4 — KI-Layer für unscharfe Aufgaben

LLMs (oder kleinere ML-Modelle) erklären Empfehlungen, schlagen Überstunden vor, formulieren Kunden-Mails, fassen Konflikte in Klartext. NICHT als primärer Scheduler — LLMs garantieren keine harten Constraints.

A-5 — Pragma-Stack für v1

Scheduler: OR-Tools CP-SAT (oder OptaPlanner).
Lifecycle: leichtgewichtige State-Machine (XState o. Ä.) statt heavyweight Workflow-Engine.
KI: LLM-API on demand für Empfehlungstexte und Konflikt-Wizards.
Workflow-Engine erst dann einführen, wenn Chronik / Genehmigungslogik eigenständig zu komplex wird.

10. Vereinfachungen gegenüber Altsystem

S-1 Einheitliche Formular-UX — alle Anlegen/Bearbeiten als Single-Modal mit progressive disclosure; keine Multi-Step-Wizards.
S-2 Single-Source-of-Truth für Derived State — Status, Standort, Auslastung niemals doppelt speichern.
S-3 Zentrale Taxonomie-Verwaltung — alle admin-editierbaren Enums in einem „Stammdaten/Taxonomien"-Bereich, nicht verstreut.
S-4 Skill als Rückgrat — ein einziger Mechanismus für Zuweisungen; Rolle/Position bleibt dekorativ.
S-5 Schicht-Katalog + Abwesenheiten = Verfügbarkeit — kein separates „Reguläre Arbeitszeiten"-Modell.
S-6 Ein Auftrags-Lifecycle ohne „Anlege-Modus" — jeder Auftrag startet Unbestätigt, Bestätigung erfolgt als Aktion.
S-7 Recommender als zentrales Nervensystem — eine EMPFEHLUNG-Engine speist Mitarbeiter-Ansicht, Leitstand und Konfliktauflösung.
S-8 Generisches Template-Bibliothek-Pattern — wiederverwendbare Infrastruktur für Leistungen, Formulare und künftige Templates.
S-9 Vereinheitlichte Konflikt-Engine — jeder Konflikttyp durchläuft denselben Resolver (Auto/Wizard/Defer).
S-10 Generisches Attachment-Modell — ein Datei-Modell mit Dokumenttyp und polymorpher Ziel-Referenz.

11. Offene Punkte (zu klären)

⚠ Status-Führung seit 12.07.2026 in ops/<ID>.md (→ generierte Offene-Punkte.md) — der komplette Alt-Bestand ist dorthin migriert (OP-DOCS-11, Big-Bang auf PO-Auftrag). Dieser Abschnitt bleibt die fachliche Detailbeschreibung (detail:-Ziel der ops/-Dateien, per-OP-Anker #op-<id>); Status- Marker hier werden nicht mehr gepflegt und können älter sein als die ops/-Datei.

11.1 Aufträge

QS-Mangelerfassung & Mitarbeiter-Leistung (umgesetzt v1): In der Endkontrolle/QS wird je Mangel worauf er sich bezieht (Teilschritt-Instanz → Skill + ausführende Mitarbeiter inkl. Helfer), Kategorie/Schwere/Beschreibung und der Nacharbeit-Aufwand (min) erfasst (§4.9.1, Auftrag.maengel). Beim Abschluss eines Schritts entsteht je Mitarbeiter ein Leistungsnachweis (Vorgabe vs. Ist-Dauer, produktiv/Helfer). Die Mitarbeiter-Karte zeigt daraus abgeleitet (nie gespeichert) Erfahrungspunkte + Statistik je Schritt/Skill (Anzahl, Helfer-Anteil, Dauer min/avg/median/max, Ø-Abweichung von der Vorgabe, Nacharbeit-Quote+Aufwand, Bewertung). Ausbildung als Helfer-Leistung: Helfer/Auszubildende je Schritt reduzieren die Zeit nicht (nicht im Solver), sammeln aber Erfahrung (§6.4.1/§6.5). Code: server/src/operativ/leistung.ts.

OP-QS-1 — QS-Mangel vertiefen. Aufbauend auf v1 (Bezug + Schwere + Nacharbeit-Aufwand): Foto-Doku am Mangel (M05, via Attachment-Modell §4.10), Mangel-Status-Workflow (offen → in Nacharbeit → behoben) inkl. Nacharbeit als planbarer Schritt/Auftrag (Ressourcen-/Skill-Bedarf, Bezug OP-R8-9 Nachkontrolle), admin-editierbare Kategorien (G-1), Mangel-Auswertung je Kategorie/Skill/Mitarbeiter über die Zeit. Zu klären: Verhältnis QS-Checkliste ↔ Mangel (jeder ✕ erzwingt Mangel?), Pflicht-Foto, wer „behoben" setzen darf.

Umgesetzt — Mangel-Status-Workflow (07-14, v0.86.0, OP-QS-1 Slice 1): M06 ist jetzt 3-stufig offen → in_nacharbeit → behoben (zuvor nur offen/behoben). Übergänge: ein Mangel wechselt offen → in_nacharbeit, sobald ein Nacharbeitsschritt für ihn eingeplant wird (markiereMangelInNacharbeit; die einstufige Erfassung qs.nacharbeitErfassen startet direkt in in_nacharbeit), und → behoben, sobald der verknüpfte Schritt erledigt wird. Das server-harte QS-Abnahme-Gate (istAbnahmebereit, OP-QS-GATE) blockt jetzt bis der Mangel behoben ist (offen und in_nacharbeit blocken). QS-Workspace zeigt die 3 Zustände als Badge (offen=amber · in Nacharbeit=cyan · behoben=grün; Rot bleibt Warnungen vorbehalten). Migration v22 hebt Bestands-Mängel mit laufendem Schritt auf in_nacharbeit. Selbsttest test:mangel-status (CI-Gate). Offene Folge-Slices: Foto-Beweismittel am Mangel (M05, liefert auch dem Notfall-Alert OP-ALERT-1 die Beweismittel-Mechanik) · manuelles „behoben"-Setzen + Vier-Augen-Frage (wer darf, G-4/OP-QS-6) · Auswertung je Kategorie/Skill/MA über die Zeit · admin-editierbare Kategorien (G-1). Umgesetzt — Beweisfotos am Mangel (07-15, v0.87.0, OP-QS-1 Slice 2 / M05): Jeder Mangel trägt in der QS-Sicht die Beweisfotos des Teilschritts, an dem er entdeckt wurde (abgeleitet/D-2, beweisfotosZuMangel). Entscheidung (Einfachheit): bestehende Teilschritt-Fotos wiederverwenden statt einen zweiten Upload-Pfad durch die Offline-Foto-Queue zu fädeln; DTO reicht Mangel.fotos (geteilter FotoRefDTO) durch, QS-Workspace zeigt Thumbnails je aktivem Mangel (Klick → volle Anzeige). Selbsttest test:beweisfoto. Offen: dedizierte, mangel-eigene Foto-/Video-Erfassung (getrennt von Schritt-Fotos) — speist dann auch den Notfall-Alert (OP-ALERT-1). (Pflicht-Foto für schwere Mängel: siehe Slice 3 unten.) Umgesetzt — Pflicht-Beweisfoto für schwere Mängel (07-15, v0.88.0, OP-QS-1 Slice 3): Ein schwerer/kritischer Mangel (M03) braucht ≥1 Beweisfoto für die saubere Beweislage — das server-harte QS-Abnahme-Gate (istAbnahmebereit) blockt die Abholung, bis das Foto dokumentiert ist, auch wenn der Mangel bereits behoben ist (das Beweismittel muss vor Abholung vorliegen). Leichte/mittlere Mängel bleiben ohne Foto-Zwang (geringe Friktion). Helfer mangelBrauchtBeweisfoto(schwere); QS-Workspace zeigt „📷 Beweisfoto nötig" am betroffenen Mangel. Selbsttest-Erweiterung test:beweisfoto. Das Beweisfoto ist ein Foto des Teilschritts, an dem der Mangel entdeckt wurde (M05); eine mangel-eigene Erfassung folgt in Slice 4 (s. u.). Umgesetzt — Dedizierte mangel-eigene Foto-Erfassung (07-16, v0.89.0, OP-QS-1 Slice 4 / M05): Ein Beweisfoto kann jetzt direkt am Mangel erfasst werden (nicht nur am Schritt) — schließt die Lücke, wenn ein Mangel an einem Schritt ohne Foto-Pflicht entdeckt wird und das Pflicht-Foto (schwer/kritisch) sonst nicht erfüllbar wäre. FotoAttachment trägt eine polymorphe Ziel-Referenz (teilschrittInstanzId oder mangelId); Upload-Endpoint akzeptiert ?mangel=, foto.registriert bindet ans Mangel-Ziel, der Mangel-DTO merged Schritt-Fotos (projiziert) + mangel-eigene, und das Abnahme-Gate zählt beide fürs Pflicht-Foto. Entscheidung: mangel-eigene Fotos laufen als Direkt-Upload im verbundenen QS-Kontext (nicht durch die Werker-Offline-Queue — hält den zweiten Pfad minimal). QS-Workspace: 📷-Aufnahme-Knopf je Mangel. Liefert zugleich die Beweismittel- Mechanik für den Notfall-Alert (OP-ALERT-1 Foto-Zwang). Verifikations-Grenze: der R2-Byte-Roundtrip ist ohne FOTOS-Binding dormant (wie die bestehende Schritt-Foto-Funktion) — verifiziert via Typecheck/Build/Selbsttest, Live-R2 in einer Umgebung mit Binding nachziehen.
OP-QS-3 — Während der Bearbeitung verursachte Schäden erfassen → Nacharbeit-Kette mit Ersatzteil (06-28, Nutzer). Beim Bearbeiten eines Fahrzeugs kann der Betrieb selbst etwas beschädigen — z. B. ein Befestigungs-Clip bricht. Das muss direkt am laufenden Schritt/Auftrag als Schaden/Mangel erfassbar sein (nicht erst in der Endkontrolle) und eine durchgängige Nacharbeit-Kette auslösen: Schaden erfassen → Nacharbeit anlegen → Ersatzteil-Bedarf → Bestellung (als Vorbedingung OP-R3-4, sichtbar im Back-Office-Backlog OP-BACKOFFICE-1, mit Vorlauf/Lieferzeit) → bei Eintreffen des Teils den Einbau-Schritt planen/freigeben → Teil eingebaut → Nacharbeit behoben. Status-Workflow: Schaden offen → Teil bestellt → Teil eingetroffen → Einbau geplant → behoben (erweitert den Mangel-Status-Workflow aus OP-QS-1). Wirkung: der Nacharbeit-/Einbau-Schritt trägt Ressourcen/Skill/Bucht → Taktung (Termin/Reserve verschieben sich ggf., Verzug sichtbar); Verursachung intern → Kosten-/Verantwortungs-Bezug (ggf. nicht berechenbar; OP-COST-1/OP-R10-1 Material). Abgrenzung: gleicher Mechanismus wie der QS-Mangel (OP-QS-1, §4.9.1 Auftrag.maengel), aber Auslöser = während der Bearbeitung (selbst verursacht), nicht erst die QS. Zu klären: Erfassung am Teilschritt (Werker-Sicht/Detail-Panel, mit Foto/Voice OP-R7-12), Verknüpfung Mangel↔Ersatzteil-Vorbedingung↔Einbau-Schritt, wer „behoben" setzt, Klärfall bei Blockade. Bezug: OP-QS-1, OP-R3-4 (Ersatzteil-Vorbedingung), OP-BACKOFFICE-1 (Bestell-Backlog), OP-R10-1 (Material), OP-COST-1, OP-R7-12 (Doku am Schritt), §4.9.1, §5.1 (Klärfall).
OP-R1-2 — Mitarbeiter-Leistung & Erfahrung vertiefen. (Umgesetzt v1: Ausbildungsziele → ausbildungsVorschlaege; #6 echte Verfügbarkeitsprüfung (mitarbeiterAvailability); güteklassen-gewichtete XP (Faktor 1/1,25/1,5); anteilige Helfer-XP bei Unterbrechung/Verspätung (lernanteil); Erfahrung → Skill-Niveau-Aufstieg-Vorschlag (niveauVorschlaege, Ein-Klick auf der Karte).) Weiter offen: Team-/Zeitraum-Vergleich & Trends (Zeitreihen, Ranking, Filter — größeres UI-Thema), niveau-gewichtete XP (höheres gefordertes mindestSkillNiveau zählt mehr), Verhältnis zu Vertrauensstufe (§4.1) und Mitarbeiter-Ansicht (OP-R9-4). Zu klären: XP-Formel-Tuning (Parameter in leistung.ts), Sichtbarkeit/Datenschutz (wer sieht wessen Statistik), ob XP planungsrelevant werden (Empfehlungs-Engine bevorzugt Erfahrene) oder rein informativ bleiben.
OP-R1-4 — Rückwirkende Abwesenheiten (Urlaub/Krank) vs. erfasste Arbeit + Abgrenzung zu Datev/Lohnbuchhaltung (06-28, Nutzer). Zwei verbundene Fragen:
1. Rückwirkendes Eintragen von Urlaub/Krankheit, obwohl im Zeitraum Arbeit ausgeführt wurde. Heute reduziert eine harte Abwesenheit (Urlaub/Krank) die Verfügbarkeit (§4.4a, D-2); sie kann aber mit bereits erfassten Leistungsnachweisen (leistung.ts) bzw. einem belegten Einsatz im selben Fenster kollidieren (jemand war „krank" und hat trotzdem an Schritten gearbeitet — widersprüchlich). Zu klären: erlauben + als Widerspruch flaggen (Konflikt/Klärfall, analog QS-Plausibilität) vs. blocken; was passiert mit den abgeleiteten Urlaubs-/Krankheitstagen + Überstundenkonto (§4.1/§4.4a — heute „derived"); wer darf rückwirkend ändern (Admin vs. Self) und ab welchem Abstand; Pflicht-Grund; lückenlose Auditierung rückwirkender Änderungen (OP-AUDIT-1, manipulationssicher/„nicht reverse-engineerbar").
2. Generelle Abgrenzung gegen Datev/Lohnbuchhaltung. Leitthese (zu bestätigen): taktano ist System-of-Record für die operative Planung/Kapazität + die Arbeits-Ist-Erfassung (Schichten, Abwesenheiten als Verfügbarkeits-Input, Schritt-Zeiten), nicht für die rechtsverbindliche Lohn-/Gehaltsabrechnung — Lohnfortzahlung, Urlaubsanspruch-Konto, AU-Bescheinigung, Entgelt bleiben in Datev/Lohnbuchhaltung (deren SoR). Zu klären: Schnittstelle/Export taktano → Datev (oder Lohn-SoR) statt Doppelpflege; welche Größen taktano nur operativ führt (planungs-relevant) vs. welche es autoritativ hält; Vermeidung divergierender „Wahrheiten" über Anwesenheit/Stunden.
⚠ Proaktives Flagging (DE/AT/CH, kein Rechtsrat): (a) gesetzliche Arbeitszeiterfassungspflicht (BAG 2022 / EuGH „Stechuhr") — Ist-Zeiten müssen vollständig & nachträglich nachvollziehbar (auditierbar) sein; (b) Krankheitsdaten = besondere Kategorie personenbezogener Daten (DSGVO Art. 9) → strenge Zugriffsbeschränkung/Zweckbindung, nur „abwesend/krank" statt Diagnose; (c) eAU (elektronische Arbeitsunfähigkeitsbescheinigung) ist der offizielle Krank-Nachweis-Kanal → taktanos Krank-Flag ist operativ, nicht der gesetzliche Nachweis; (d) rückwirkende Korrekturen sind ein typisches Manipulations-/Compliance-Risiko → Audit + Vier-Augen ggf. nötig. Bezug: R1 §4.1/§4.4a, OP-OPT-7, OP-AUDIT-1, OP-COMPLIANCE-1, OP-EXPORT-1 (Export), docs/betrieb/Risikoregister.md, docs/betrieb/Compliance.md.
OP-CAL-1 — Feiertage je Bundesland vorschlagen (Betriebskalender) (06-28, Nutzer). Gesetzliche Feiertage unterscheiden sich je Bundesland (DE, 16 Länder; analog AT-Bundesländer und CH-Kantone für die Zielmärkte). taktano soll sie aus dem Region-Stammdatum des Tenants (Bundesland/Kanton) vorschlagen / automatisch vorbefüllen — inkl. beweglicher Feiertage (Ostern-basiert, berechnet) — statt sie pro Werkstatt von Hand zu pflegen. Vorschlag, nicht hart: der Betrieb bestätigt/überschreibt (Brückentage, abweichende Schließzeiten, Betriebsferien). Wirkung: Feiertage/Schließtage sind betriebsweite Nicht-Arbeitstage → reduzieren Kapazität/Verfügbarkeit, fließen in den Scheduler (keine Planung an Feiertagen, Angebotsmodus/earliest-completion §5.2.2), erzeugen das Ausfall-Band „Geschlossen" (scheduler/ausfall.ts) und wirken auf Termin-/Reserve-Berechnung. Datenmodell: Tenant-weiter Betriebskalender (Feiertage + manuelle Schließtage/Betriebsferien), admin-editierbar (G-1), Region als Tenant-Stammdatum (Bezug Mandantenfähigkeit/Seed). Zu klären: Feiertags-Quelle (statische Tabellen je Land/Region + Computus vs. Bibliothek), DE/AT/CH-Abdeckung, halbe Feiertage/regionale Sonderfälle, Verhältnis zum Schicht-Katalog (Feiertag schlägt Schicht) und zu Mitarbeiter-Abwesenheiten (orthogonal). Abgrenzung: die lohnrechtliche Feiertagsbehandlung (Feiertagszuschläge, Lohnfortzahlung) bleibt Datev/Lohnbuchhaltung (OP-R1-4) — taktano nutzt Feiertage operativ (Kapazität/Planung). Bezug: R1 §4.4/§4.4a, OP-OPT-7, OP-R1-4, OP-TENANT/OP-SEED-1, scheduler/ausfall.ts, §5.2.2.
OP-R1-5 — Arbeitszeitkonten & Abfeiern + „Auftrag fertigstellen trotz Schichtende" (06-28, Nutzer). Zwei verbundene Aspekte:
1. Arbeitszeitkonto / Überstundenkonto + Abfeiern: Über-/Unterstunden je Mitarbeiter führen (heute „Überstundenkonto = derived", §4.1) und Abfeiern ermöglichen — angesammelte Überstunden durch Freizeit ausgleichen (Comp-Time als planbare Abwesenheit, reduziert die Verfügbarkeit wie Urlaub/Wunschfrei, §4.4a). Saldo abgeleitet aus Ist-/Plan-Zeiten vs. Sollzeit (Schicht-Katalog), nichts doppelt speichern (D-2).
2. „Erst nach Hause, wenn das fertig ist" — Auftrag über das Schichtende hinaus fertigstellen: der operative Fall, dass ein Auftrag bewusst fertig gemacht wird, auch wenn das Überstunden bedeutet. Heute deckt das der Scheduler nicht aktiv ab (Verfügbarkeit = Schichten; es gibt Überstunden-Vorschläge R9 + Bereitschaft/Überlauf OP-OPT-7). Neu/zu klären: einen Auftrag/Schritt als „muss heute/jetzt fertig" markieren → erlaubt/plant Überstunden (pönalisiert, mit Zustimmung) — und die Mehrzeit landet im Arbeitszeitkonto (→ später abfeierbar). Schließt den Kreis: Überstunde jetzt ⇄ Abfeiern später.
⚠ Abgrenzung (OP-R1-4): das rechtsverbindliche Arbeitszeit-/Überstundenkonto (Lohn, ArbZG-Grenzen, Zuschläge) bleibt Datev/Lohnbuchhaltung; taktano führt es operativ (Planung/Kapazität/Verfügbarkeit) + liefert ggf. Export dorthin. ⚠ Flagging (DE/AT/CH): ArbZG-Grenzen (Höchstarbeitszeit/Ruhezeiten) bei geplanten Überstunden beachten (nicht blind „bis fertig"); Mitbestimmung/Arbeitszeit-Konto-Vereinbarungen. Zu klären: Konto-Datenmodell + Abfeier-Erfassung/Genehmigung, Scheduler-Anbindung (Überstunde als pönalisierte Kapazität + Konto-Effekt), Datev-Export. Bezug: R1 §4.1/§4.4a, OP-R1-4 (Datev-Abgrenzung), OP-OPT-7 (Überstunden/Bereitschaft-Pönale), OP-R8-13 (Kapazitäts-Hebel), R9 (Überstunden-Vorschläge), G-2/G-3.

Plan-Ist & Termintreue (umgesetzt v1): Pro Auftrag werden ursprünglich geplante Fertigstellung und ursprünglicher Wunsch-Abholtermin dauerhaft separat gespeichert (durch Re-Planung/Anpassung nicht überschrieben). Bei Abschluss wird die tatsächliche Fertigstellung (Zeitpunkt des Abschlusses) festgehalten. Abgeschlossene Aufträge zeigen die tatsächliche statt der geplanten Fertigstellung; die Differenz Plan↔Ist ist damit auswertbar (Termintreue-Reporting → künftige Auswertung). Wird der Wunsch-Abholtermin angepasst (z. B. Konflikt-Hebel), bleibt der ursprüngliche Termin sichtbar.

Standort-Anzeige (umgesetzt v1): Jeder Auftrag zeigt, wo das Fahrzeug aktuell physisch steht (Slot aus der Ist-Belegung, §4.3), bzw. „Standort unbekannt".

Reserve-Indikator (umgesetzt v1): Jede Auftragskarte zeigt die Reserve in Tagen bis zum Wunsch-Abholtermin (geplante Fertigstellung ↔ Wunsch-Abholung): grün bei Puffer, rot bei 0 Tagen oder überfällig. Der Kunden-Anspruchs-Score (R5-F15) wird als Chip angezeigt.

OP-R7-1 — vollständige Bestätigung der Auftrag-Status-Enum-Liste.
OP-R7-2 — Manuell vs. Auto-Scheduling – per Auftrag oder system-weite Einstellung; wie wird Auto-Modus erreicht?
OP-R7-3 — Soft (Unbestätigt) vs. Hard (Aktiv) Reservierung – exakte Konflikt-Auflösungsregeln.
OP-R7-4 — Scope des Per-Auftrag Override auf Teilschritt-Instanzen (nur Dauer oder mehr)?
OP-R7-6 — Auftragswert – manuell vs. abgeleitet; Preismodell auf Leistungen.
OP-R7-7 — Customer Self-Service (Web-Portal + WhatsApp). (Ursprünglich: Kunden-Self-Service-Link – Felder, Security/Token-Modell.) Schärfung 06-28 (Nutzer, Roadmap): über den reinen Link hinaus ein Kunden-Self-Service als eigener Kanal — per Web-Portal und WhatsApp. Use-Cases: Auftragsstatus/Fortschritt verfolgen (Phasen Annahme → Vorbereitung → Produktion → Quality-Check → Abholung), Freigaben / Kostenvoranschlag bestätigen (Bezug OP-R3-4 Kundenfreigabe als Vorbedingung), Rückfragen/Kommunikation, Fotos/Doku ansehen (OP-R7-12/-16), Wunsch-/Abholtermin abstimmen, Kontakt-/Fahrzeugdaten selbst vervollständigen (R5/§7.4). Zielgruppe Customer Service (Onboarding/Support). Sicherheit: Token-/Magic-Link (kein Voll-Login) bzw. IdP (OP-AUTH-1, §7.4), DSGVO (Kundendaten/Fotos, EU-Residenz), klare Kanal-Abgrenzung. WhatsApp: Business-API — Provider, Opt-in, Template-Nachrichten, EU-Datenresidenz/AVV klären (⚠ Meta/US-Transfer → Datenschutz prüfen). Bezug: R5 (Kunde v1 Name+CRM), §7.4, OP-AUTH-1, OP-AI-1 (Kunden-Kommunikation/LLM), OP-R3-4 (Freigaben), OP-R7-12/-16 (Fotos/Doku), OP-BILLING-1, docs/architektur/Billing-Zugang.md, Zielgruppe Customer Service.
OP-R7-8 — Geplante-Fertigstellung-Ampel: Schwellwerte für Im Zeitplan / Abholung gefährdet / Überfällig.
OP-R7-9 — Laufzettel – Inhalt und Layout des druckbaren Routenscheins.
OP-R7-10 — Verzögerungen melden/anmelden. (umgesetzt v1): „Verzögerung melden" am Auftrag erfasst Dauer (Presets +30 min/+1 h/+2 h/+1 Tag oder frei) + Grund; die noch geplanten Teilschritte und die geplante Fertigstellung rücken um die Dauer nach hinten (ursprünglicher Plan bleibt → Termintreue), der Eintrag landet in der Chronik, die Auswirkung ist sofort in Reserve/Termin-Ampel/⚡ sichtbar. Offen: Gründe-Enum, automatische Verschiebung abhängiger Aufträge (nicht nur des eigenen), Kunden-Info, Erfassung in der Mitarbeiter-Ansicht (OP-R9-4).
OP-R3-1 — Standard-Prozess & Klärfälle modellieren (siehe §5.1). Die fünf Standard-Phasen (Annahme → Vorbereitung → Produktion → Endkontrolle/Quality-Check → Abholung; sprechende Labels, technische Keys aufbereitung/qs), jeweils mit Dokumentation & Kommentieren, als konfigurierbares Prozess-Template abbilden; Annahme/Vorbereitung/Quality-Check als echte (Standard-)Schritte inkl. Ressourcen-/Skill-/Zeitbedarf (vs. frühere Vereinfachung „keine Teilschritte"). Klärfälle-Prozess als jederzeit auslösbare Unterbrechung mit eigenem Skill „Klärung" (Eskalation + Doku) und Wieder-Einstieg zurück / Sprung zu Quality-Check / anderer Schritt / Abbruch. Zu klären: Datenmodell (Phasen vs. Teilschritte, Doku/Kommentar-Entität), Status-Mapping (Unterbrechung ↔ pausiert + Klärungs-Kontext), „Abbruch"-Übergang im Lifecycle (S-6), Skill-Seed „Klärung". Schärfung 06-24 (Analyse Flow-Analyse.md): Der heutige Flow ist nicht intuitiv, weil drei nicht deckungsgleiche „Flows" existieren (8-Status-Lifecycle vs. 5-Phasen-Standard-Prozess vs. UI-Flow-Band) und der gefühlte 7-Schritt-Flow zwei orthogonale Achsen vermischt (Lifecycle/Reservierung vs. fachliche Phase). Daher zusätzlich: (1) Anlieferung ≠ Annahme entkoppeln (Sammelstatus angeliefert auflösen — „da, aber noch nicht angenommen" abbildbar machen); (2) QS-Doppelmodellierung auflösen (QS heute zugleich Status fertiggestellt und Teilschritt ts-qm) und Endkontrolle (vor Abholung) von Nachkontrolle (kontrolliert, nach Abholung) trennen — inkl. falschem Flow-Band-Mapping kontrolliert↔Abholung; (3) die fragile Aufbereitung/Produktion-Heuristik durch eine First-Class-Phase ersetzen; (4) eine konsistente Flow-Sprache über Flow-Band/Orders/Detail/Gantt. Umsetzung: inkrementeller 7-PR-Plan in Flow-Refactor-Plan.md. Fortschritt: PR 1 ✅ (06-25) — fachliche Phase als First-Class-Tag am Teilschritt (Teilschritt.phase, F13; Enum Phase=annahme|aufbereitung|produktion|qs; Ableitungs-Helfer phaseEffektiv), Seed getaggt, Migration SCHEMA_VERSION 11 (untaggte Altdaten abgeleitet). PR 3 ✅ (06-25) — aktuellePhase() leitet die aktuelle Auftrags-Phase ab (laufender>pausierter>nächster offener Schritt) und liefert sie als AuftragDTO.phase; ersetzt die Flow-Band-Heuristik serverseitig. Aktuelle Auftrags-Phase bleibt abgeleitet (kein Derived State gespeichert). PR 2 ✅ (06-25) — QS bereits first-class (ts-qm); Annahme als Doku-Schritt, nicht solver-geplant (ts-annahme, Phase annahme, belegt Parkplatz statt Bucht, G-3) jedem neuen Auftrag vorangestellt — löst die frühere Vereinfachung „Annahme/Endausgabe keine Teilschritte" für die Annahme ab. PR 4 ✅ (06-25) — UI liest die First-Class-Phase: Flow-Band ohne Heuristik, kontrolliert↔Abholung-Mapping korrigiert; gemeinsame Flow-Sprache (phase.ts) mit Phasen-Chip in Flow-Band/Orders/Detail, getrennt von Status/Terminklasse. PR 5 ✅ (06-25) — QS-Seite: Endkontrolle/Abnahme vor der Übergabe klar von der Abholung (Handover-Button) und der optionalen Nachkontrolle (abgeschlossen→kontrollieren, neue Sektion) getrennt — kontrolliert nicht mehr verwaist; Minimal-Variante ohne neuen Lifecycle-Status. PR 6 ✅ (06-25) — Klärfälle: Aktion abbrechen + terminaler Status abgebrochen (S-6, aus jedem Arbeitsstatus; Reservierung keine), Klärfall-Kontext (Auftrag.klaerfall: Grund/Eskalation, orthogonal zum Status, melden/lösen) + Skill „Klärung" geseedet; Re-Entry-Routing (zurück/Sprung-zu-QS/anderer-Schritt) über bestehende Teilschritt-Aktionen; Klärungs-Engine ✅ (07-11, v0.74.0): geroutetes Lösen (zurueck/qs/schritt/abbruch, Pflicht-Kommentar, Melden pausiert + erfasst den Auslöser-Schritt, D1-Audit + Reopt) — Details §5.1. PR 7 ✅ (06-25, OP-R4-3-Kern) — Pflicht-Doku-Gate beim Schrittabschluss: Teilschritt.dokuPflicht (F14, Default an) erzwingt mind. 1 Kommentar beim „erledigen" (TeilschrittInstanz.kommentar); per-Schritt „Fertig (mit Doku)" im UI. Foto-Perspektiven + KI-Plausibilität + Diktat (Rest OP-R4-3/OP-AI-2/3) bleiben Folge-Ausbau. ➡ Flow-Refactor (OP-R3-1) PR 1–7 komplett — siehe Flow-Refactor-Plan.md.
OP-R3-2 — Produktions-Vorbereitung als Vorbedingung der Produktion. Eine eigene Vorbereitungs-Perspektive/-Phase (Arbeitsvorbereitung), deren Abschluss Vorbedingung für den Produktionsstart ist (Produktion kann erst beginnen, wenn die Vorbereitung „fertig" ist) — z. B. Material/Folie bestellt & eingetroffen, Fahrzeug freigegeben, Doku vollständig. Je Folie ist ein Bestellvorlauf/Lieferzeit einzukalkulieren: der früheste Produktionsstart = max(Anlieferung, Bestelldatum + Lieferzeit der Folie). Zu klären: Datenmodell (Vorbereitungs-Checkliste/-Schritt je Auftrag; Folien-/Material-Stammdaten mit Lieferzeit, Bezug OP-R10-1), Scheduler-Anbindung (Lieferzeit als zusätzliche Release-/Earliest-Start-Schranke, vgl. Angebotsmodus §5.2.2), Status/Gate (Vorbereitung offen → Produktion blockiert; sichtbar im Cockpit), Beschaffungs-Status (bestellt/unterwegs/eingetroffen) + Warnung bei drohendem Lieferverzug ggü. Wunschtermin (Reserve/Konflikt §5.2.3).
OP-R3-3 — Unterbrechung & Übernahme je Prozessschritt durchsetzen. Die Prozessdefinition trägt jetzt zwei Regeln je Teilschritt (§4.6 F15/F16): Unterbrechung und Übernahme durch anderen Mitarbeiter, je erlaubt/vermeiden/verboten. (Umgesetzt v1: Stammdaten + Katalog-Anzeige; unterbrechung: verboten wirkt hart auf die Preemption.) Offen: (a) vermeiden als Soft-Goal im Optimierer (Pönale fürs Unterbrechen/den MA-Wechsel, vgl. §6.2 + G-2) statt nur hart/erlaubt; (b) Übernahme-Logik — wenn ein anderer Mitarbeiter einen laufenden/pausierten Schritt fortsetzt, das im Modell abbilden (mehrere mitarbeiterIds über die Zeit / Wechsel protokollieren) und bei verboten verhindern bzw. bei vermeiden bepönalisieren; (c) Prozess-Editor-UI zum Pflegen der Regeln (heute Seed-seitig). Bezug: §6.1/§6.3 (Preemption), G-2 (Wechsel-Pönale), §6.4.1 (Helfer-Lernanteil bei Unterbrechung).
OP-R3-4 — Vorbedingungen je Auftrag/Schritt erfassen (rechtzeitig veranlassen) (06-28, Nutzer). Verallgemeinert OP-R3-2 (dort speziell Folie/Material „bestellt & eingetroffen" + Lieferzeit) auf beliebige Vorbedingungen, die den Start eines Auftrags/Teilschritts gaten und rechtzeitig veranlasst werden müssen — z. B. Ersatzteil für eine kleine Reparatur bestellen, Spezialwerkzeug, Material, Kundenfreigabe/Kostenvoranschlag, Gutachten. Datenmodell: Vorbedingungs-Liste am Auftrag/Schritt — Typ (Ersatzteil/Material/Freigabe/Werkzeug …) · Beschreibung · Status (offen → veranlasst/bestellt → eingetroffen/erfüllt) · benötigt bis / Vorlauf-/Lieferzeit · Verantwortlicher. Scheduler: Vorlaufzeit als früheste Startschranke (frühester Start = max(Anlieferung, Veranlasst-Datum + Lieferzeit), wie OP-R3-2), Start-Gate (Schritt/Produktion blockiert bis erfüllt) + Warnung bei drohendem Verzug ggü. Wunschtermin (Reserve/Konflikt §5.2.3), sichtbar im Cockpit (ggf. als Klärfall). Zu klären: Taxonomie der Vorbedingungs-Typen (G-1), Verhältnis zu Material/Beschaffung (OP-R10-1) und zur Vor-Produktion (OP-PHASE-1), Pflichtfelder, wer „erfüllt" setzt. Die offenen Vorbedingungen werden zudem als Backlog für Back-Office/Vorgesetzte angezeigt → OP-BACKOFFICE-1. Bezug: OP-R3-2, OP-PHASE-1, OP-R10-1, OP-BACKOFFICE-1, §5.2.2 (Angebotsmodus/Release-Schranke), §5.2.3 (Konflikt), §5.1 (Klärfall).
OP-R3-5 — Reihenfolge der Prozessschritte hart durchsetzen — kein Überspringen (06-28, Nutzer). Die definierte Reihenfolge der Prozessschritte muss unbedingt berücksichtigt werden: ein Schritt startet erst, wenn die laut Abhängigkeit (nach_vorherigem) vorausgehenden Schritte erledigt sind; kein Out-of-Order-Start, kein Überspringen von Pflicht-Schritten. Schließt die in der Flow-Analyse benannte Lücke (die frühere Heuristik erlaubte z. B. Start von Schritt 3 vor Schritt 1). Durchsetzung: Guard in teilschritt.aktion (Start blockiert, bis Vorgänger erledigt) — der Optimierer respektiert die Abhängigkeiten bereits hart (§6.1); hier geht es um die manuelle Ausführung/UI. ⚠ Abgrenzung/Konsistenz (OP-DOCS-9 — wichtig, scheinbarer Widerspruch): Es gibt heute bewusst Ausnahmen vom „nicht überspringen": (a) als optional (F05) markierte Schritte dürfen übersprungen werden; (b) der Konflikt-Hebel „optionalen Schritt überspringen" (§5.2.3) nutzt genau das; (c) frei/parallel-Abhängigkeit (G-1) = keine feste Reihenfolge; (d) Klärfall „Sprung zu QS" (§5.1). Entscheidung (E-R3-5 ✅ 06-28, PO): Pflicht-Schritte mit nach_vorherigem = harte, nicht überspringbare Reihenfolge; als optional/frei/parallel markierte Schritte bleiben überspringbar, und der Konflikt-Hebel „optionalen Schritt überspringen" (§5.2.3) bleibt erhalten. Der dokumentierte Klärfall (§5.1) bleibt als Ausnahme zulässig. Offen nur noch: Override-Recht (Admin/Klärfall) + Audit der Ausnahmen. Konsistenz-Check Bestand (06-28, Nutzer): Mit Einführung der harten Reihenfolge müssen bestehende, bereits materialisierte Prozess-Instanzen (TeilschrittInstanz je Auftrag, E-CRUD-2) auf Status-Konsistenz geprüft werden — die frühere Heuristik ließ Out-of-Order-Zustände zu, also kann es Instanzen geben, bei denen ein Schritt erledigt ist, obwohl ein nach_vorherigem-Vorgänger noch geplant/offen ist (oder analoge Widersprüche in_arbeit/pausiert). Vorgehen: einmaliger Prüf-/Reparatur-Lauf (idempotente Migration, schemaVersion-Muster in server/party/leitstand.ts, OP-DATA-1) + laufender Invarianten-Check: inkonsistente Instanzen erkennen und entweder automatisch glätten (wo eindeutig) oder als Klärfall (§5.1) zur manuellen Auflösung markieren (nicht still überschreiben). Als blockierender Self-Test absichern (analog test:running-process, E-CRUD-3). Bezug: E-CRUD-2 (Materialisierung), OP-DATA-1 (Migrations-Hygiene), OP-AUDIT-1, §5.1 (Klärfall). Bezug: G-1 (Abhängigkeits-Enum), §6.1 (harte Constraints), Flow-Analyse.md, OP-R3-1, OP-R8-2/3 (Skip-Hebel), F05 (optional), §5.1 (Klärfall), §5.2.3.
OP-R3-6 — Kommentare & besondere Hinweise je Teilschritt und Leistung (Katalog-Ebene) (06-28, Nutzer). An der Vorlage (Teilschritt und Leistung) dauerhafte Hinweise/Kommentare hinterlegen — z. B. „bei diesem Schritt X beachten", Sicherheits-/Qualitäts-/Werkzeug-Hinweis. Abgrenzung (wichtig): das ist der Katalog-Hinweis (gilt bei jeder Verwendung der Vorlage) — zu unterscheiden vom auftragslokalen Kommentar (OP-R7-12, dieser eine Auftrag) und der modellspezifischen Besonderheit (OP-R6-2, dieses Fahrzeugmodell). Datenmodell: Teilschritt.hinweis / Leistung.hinweis (Text + optional Anhänge), editierbar im Prozess-Editor (OP-R3-3); mit Foto/Voice über dieselbe Kommentar-Komponente (OP-R7-12). Anzeige dort, wo der Schritt ausgeführt wird (Werker-Sicht/Detail-Panel) + bei der Prozess-Vorschau in der Annahme (OP-R7-15). Bezug: OP-R3-3 (Editor), OP-R7-12 (Kommentare/Foto/Voice), OP-R6-2 (Modell-Besonderheiten), OP-AI-3 (Diktat/Übersetzer).
OP-PHASE-1 — Bessere Benennung der Produktions-Phase + Differenzierung „Vor-Produktion" (Anlass 06-28, Nutzer). Die fachliche Phase produktion trägt heute das generische Label „Produktion". Zwei Aspekte:
1. Bessere/sprechendere Benennung — generisch „Produktion" vs. gewerk-/leistungs-spezifisch (z. B. „Folien-Applikation", „Lackierung" je dominierendem Gewerk/Leistung des Auftrags). Taktano ist multi-Gewerk (Folie, Lack, Detailing, Keramik); zu klären: Ableitung aus der Leistung vs. Tenant-/Admin-Konfiguration (G-1: taxonomie-artige Enums admin-editierbar).
2. „Vor-Produktion" als eigene, ressourcen-tragende Aktivität differenzieren — die Folien-Produktion (Folien-Zuschnitt/Druck) und die Material-Bestellung sind der eigentlichen Applikation vorgelagert. Sie kann nach der Annahme beginnen (sobald der Auftrag angenommen ist), unabhängig davon, ob das Fahrzeug schon in einer Bucht steht — sie belegt Plotter/Druck-/Zuschnitt-Kapazität, nicht die Fahrzeug-Bucht. Scheduler-Anspruch: Zeitraum und Auslastung der Folienproduktion als eigene Ressource/Kapazität in der Taktung berücksichtigen (Plotter als Arbeitsplatz-Typ?), damit Vorlauf/Engpass dort den Produktionsstart am Fahrzeug nicht überraschend blockiert. Verhältnis zur Phase „Vorbereitung" (§5.1, dort konzeptionell „inkl. Folien-Produktion") und zur Material-/Lieferzeit-Schranke aus OP-R3-2 (frühester Produktionsstart = max(Anlieferung, Bestelldatum + Lieferzeit)) klären — ggf. eigene fachliche (Vor-)Phase/Teilschritt statt nur Label.
Auswirkung: PHASE_LABEL.produktion (client/src/app/leitstand/phase.ts), Flow-Band, Scheduler (server/src/scheduler/), Datenmodell (Arbeitsplatz-Typ Plotter, Folien-Stammdaten), Doku §5.1. Bezug: True North Frage 1 (Auslastung), Selbsterklärbarkeit, OP-R3-1 (Phasen first-class), OP-R3-2 (Folien-Vorlauf/Lieferzeit als Release-Schranke). Anlass 06-28: Umbenennung Phase 2 „Aufbereitung" → „Vorbereitung" (inkl. Car-Check + Folien-Produktion) und „QS" → „Quality-Check".
OP-R7-11 — Owner/Verantwortlicher je Auftrag/Fahrzeug? Braucht ein Auftrag (bzw. das Fahrzeug) eine fest zugeordnete verantwortliche Person (z. B. betreuender Disponent/„Auftragspate"), getrennt von den ausführenden Bearbeitern der einzelnen Teilschritte? Zu klären: Nutzen (klare Zuständigkeit, Eskalation, Kundenkontakt) vs. Pflegeaufwand; Verhältnis zu Teilschritt-mitarbeiterIds; ob Owner pro Auftrag oder pro Fahrzeug (R6) sinnvoll ist; Auto-Zuweisung vs. manuell; Anzeige im Cockpit (Aufträge-Detail, Filter „meine Aufträge").
OP-R7-12 — Kommentare durchgängig erlauben — je mit Foto/Voice (06-28, Nutzer). Leitlinie (Nutzer): „Am besten immer Kommentare erlauben — jeweils mit Fotos/Voice etc." → Kommentieren ist kein Sonderfall einzelner Masken, sondern eine überall verfügbare, einheitliche Fähigkeit (jede Phase, jeder Auftrag/Teilschritt, jede Ansicht), und jeder Kommentar kann Anhänge tragen: Foto (R4/OP-R4-3) und Voice/Audio-Notiz (mit Transkript + Übersetzer + Domänen-Anpassung, OP-AI-3) sowie Freitext. Konkreter Auslöser: Bei der Auftragsaufnahme (Annahme) fehlt das heute — das Formular (/annahme, annahme.component.ts) erfasst nur strukturierte Felder (Kunde/Leistung/Güteklasse/Termine), kein Freitext-Kommentar, obwohl §5.1 je Phase „Doku & Kommentar" fordert (Zustand bei Annahme, Kundenhinweise, Sonderwünsche, Vorschäden). Gewünscht: eine wiederverwendbare Kommentar-Komponente (Freitext + Foto + Voice), eingebunden mindestens bei der Annahme und am Teilschritt/Auftrag, gespeichert am Auftrag (Chronik/protokoll, sichtbar in Aufträge/Detail-Panel) — als Verlauf (mehrere Kommentare), nicht ein Einzelfeld. Zu klären: Pflicht vs. optional je Stelle (Doku-Gate OP-R4-3 / ts-annahme); Sichtbarkeit (intern/Manager-only vs. an Mitarbeiter — zwei Notiz-Sichtbarkeiten R1 §4.1); Speichermodell der Anhänge (R2/Attachment §4.10). Bezug: R4 (Formulare/Protokolle), OP-R4-3, OP-AI-3, OP-FEEDBACK-1 (gleiche Foto-/Annotations-Bausteine), OP-UX-1, §5.1.
OP-R7-13 — Umgang mit „freien Aufträgen" (06-28, Nutzer). Offene Begriffs- und Modellfrage — der Begriff ist zunächst zu schärfen; plausible Lesarten (eine, mehrere oder alle treffen zu):
- (a) Freier Prozess / ad-hoc-Leistung: ein Auftrag ohne vordefinierte Leistung aus dem Katalog (Sonder-/Einmal-Arbeit). Heute ist alles auf Leistung → Teilschritte (R3) aufgebaut; ein „freier" Auftrag bräuchte frei zusammengestellte/manuelle Teilschritte — wie taktet der Scheduler das (Dauer/Skill/Bucht müssen trotzdem benannt sein, sonst keine harte Planung A-3)?
- (b) Freier Termin / frei einplanbar: Auftrag ohne festen Wunschtermin → reine best_effort-Terminklasse, Reserve unkritisch; Scheduler füllt Lücken (Bezug §5.2.2/§6.2).
- (c) Frei = ohne Kunde/Fahrzeug: interner Auftrag (eigenes/Demo-Fahrzeug, Werkstattaufgabe ohne externen Kunden) — Verhältnis zum Datenmodell „Auftrag ist zentral, Kunde = Name + CRM-Link" (§4.9).
Zu klären: welche Lesart(en) gemeint sind; falls (a) — Mindestangaben für die Taktung eines freien Auftrags (Dauer/Skill/Bucht je freiem Schritt), Verhältnis zum Prozess-Editor (OP-R3-3, „neue Teilschritte/Leistungen anlegen" gibt es bereits) vs. wirklich auftragslokaler Ad-hoc-Schritt; ob freie Aufträge Kapazität/Auslastung mitzählen (True-North-Frage 1). Bezug: R3 (Leistungen/Prozesse), R7 (Auftrag), G-1 (Abhängigkeit frei), §5.2.2 (Angebotsmodus), §6.2 (Terminklassen), Datenmodell §4.9.
OP-R7-14 — Anzahlungen (Feststellung 06-28, Nutzer: werden in taktano nicht erfasst). Ist-Stand: taktano erfasst keine Anzahlungen/Zahlungen — heute nur ein Preis-/Auftragswert-Snapshot (Auftrag.preisCent, OP-R7-6-Erstschnitt), keine Geldflüsse. Abgrenzung (Leitthese, vgl. OP-R1-4): Zahlungsabwicklung, Rechnung/Mahnwesen und Buchhaltung sind SevDesk (OP-BILLING-1) bzw. PSP — nicht taktano (kein Finanz-System-of-Record). Offene Entscheidung: Soll taktano operativ ein „Anzahlung erhalten?"-Flag/Indikator führen, wenn es den Werkstatt-Flow steuert (z. B. Produktion erst nach geleisteter Anzahlung starten — analog zahlungs-gesteuerter Zugang OP-ACCESS-1), ohne Beträge zu verbuchen? Zu klären: reines operatives Flag (Datum/erhalten ja-nein) vs. Betrag; Quelle (manuell vs. SevDesk-Sync); Gate-Wirkung auf Lifecycle/Start; Sichtbarkeit/Rolle. Bezug: OP-R7-6 (Preismodell), OP-BILLING-1 (SevDesk), OP-PAY-1, OP-ACCESS-1, OP-R1-4 (Abgrenzungsprinzip operativ ↔ Finanz-SoR).
OP-R7-15 — Prozess-Vorschau bei der Auftragserfassung + auftragslokal anpassen/kommentieren (06-28, Nutzer). Bei der Annahme (/annahme) soll nach Wahl der Leistung sofort eine Vorschau des resultierenden Prozesses erscheinen — die geordneten Teilschritte mit Dauer/Skill/Bucht/Phase (abgeleitet aus dem Katalog buildProzessKatalog) — damit der Erfasser (a) weitere Schritte hinzufügen und (b) bestehende Schritte kommentieren kann, bevor/bei der Anlage. Kernunterscheidung: das ist eine auftragslokale Anpassung der Prozess-Instanz (nur dieser Auftrag) — abzugrenzen vom Katalog-Edit (OP-R3-3, wirkt auf alle Aufträge). Passt zur Materialisierung bei Auftragsstart (E-CRUD-2, TeilschrittInstanz statt Live-Vorlage) → die Instanz wird bei Anlage gebildet und ist auftragsspezifisch erweiter-/kommentierbar. Wirkung: zusätzliche Schritte brauchen Dauer/Skill/Bucht, fließen in die Taktung (Angebotsmodus §5.2.2 → Machbarkeit/Preis/Reserve). Zu klären: UI in der Annahme (Vorschau-Liste + „+ Schritt" + Kommentar je Schritt, Kommentar mit Foto/Voice via OP-R7-12), ob ad-hoc-Schritte = „freie" Schritte (OP-R7-13 (a)), Speichern der auftragslokalen Abweichung, Verhältnis zu Dauer-Override (bereits in der Leistungs-Komposition). Bezug: OP-UX-1 (Annahme-Workspace), OP-R3-3 (Prozess-Editor), OP-R7-12 (Kommentare mit Foto/Voice), OP-R7-13 (freie/ad-hoc Schritte), OP-R3-4 (Vorbedingungen je Schritt), E-CRUD-2 (Materialisierung), §5.2.2.
OP-R7-16 — Fahrzeug-Angaben bei der Annahme erfassen (Beschreibung, Fotos, FIN/Kennzeichen) (06-28, Nutzer). Bei der Annahme (/annahme) direkt am Auftrag erfassen — konform zum Datenmodell §4.9 (Fahrzeug = kein eigenes Objekt, Attribute am Auftrag, nur während des Auftrags): Fahrzeugbeschreibung (Hersteller/Modell/Farbe/Variante — strukturiert und/oder Freitext), ein paar Fotos (Zustands-/Annahme-Doku, R4/OP-R4-3), Fahrgestellnummer (FIN/VIN) — immer (Pflicht) als eindeutige Fahrzeug-Identität, Kennzeichen — optional/„manchmal" (z. B. abgemeldete/saisonale Fahrzeuge ohne Kennzeichen). Nutzen: eindeutige Identifikation (FIN), Zustands-/Beweissicherung bei Annahme (Vorschäden — verknüpft mit OP-R7-12 Kommentar+Foto und OP-QS-3 Schadens-Erfassung), Wiedererkennung/Historie (OP-R6-1). Datenmodell: Auftrag-Feld fahrzeug: { beschreibung, fin (Pflicht), kennzeichen?, fotos[] } (oder Einzelfelder); optionale FIN-Plausibilität (17 Stellen, ISO 3779). ⚠ Flagging (DSGVO): FIN + Kennzeichen + Fotos sind personen-/fahrzeugbezogene Daten → Zweckbindung, Zugriff, Löschkonzept (Klasse C Foto = hart löschbar + Recht auf Vergessen, OP-CRUD-1/E-CRUD-4; Fotos R2 jurisdiction=eu). Zu klären: strukturierte vs. freie Beschreibung, Pflicht-Fotoperspektiven (OP-R4-3), FIN-Validierung/-Scan (OCR?), Verhältnis zum R6-Future-Vollmodell. Bezug: §4.9 (Datenmodell), R6, OP-UX-1 (Annahme), OP-R7-15 (Annahme-Erfassung), OP-R7-12, OP-R4-3, OP-AI-2 (Bild-Plausibilität Farbe), OP-QS-3, OP-CRUD-1. ✅ Umgesetzt (07-12, v0.77.0): Auftrag-Feld fahrzeug: { fin?, kennzeichen?, beschreibung? } (Freitext-Beschreibung, v1) — erfassbar optional bei der Buchung (Annahme-Satz-Seite), Pflicht spätestens beim Check-in („Fahrzeug da": FIN-Pflichtfeld, vorbefüllt; Guard in fahrzeugAnnahme), nachtragbar im Auftrag-Detail (Muster Kunde/CRM). FIN-Plausibilität (ISO 3779: 17 Zeichen ohne I/O/Q) ist warn-only (Sonder-/Altfahrzeuge blockieren nie); Kennzeichen-Chip auf der Tafel. Fotos laufen über den bestehenden Annahme-Schritt mit Foto-Pflichtperspektiven (OP-R4-3) — kein zweiter Foto-Pfad. Offen (Folge): strukturierte Beschreibung/Modell-Katalog (OP-R6-2 Aspekt 2), FIN-OCR-Scan, Löschkonzept-Detail (OP-CRUD-1/E-CRUD-4).
OP-R7-17 — Rabatte / Nachlässe (06-28, Nutzer). Welche Rabatte sind möglich/abbildbar? Aufsetzend auf das Preismodell (OP-R7-6, Auftrag.preisCent + Leistung.grundpreisCent): Rabatt-Arten klären — prozentual vs. absolut, je Auftrag/Position/Kunde, Aktions-/Mengen-/Treue-/B2B-Rabatt, Kulanz. Wirkung: auf den Auftragswert/Preis-Snapshot und damit auf die Marge (OP-COST-1 Sicht A); jede Rabattvergabe als Audit-Event (wer/wieviel/warum, OP-AUDIT-1). Berechtigung/Grenzen: wer darf welchen Rabatt geben (Freigabe-Schwellen, Rolle — OP-AUTH-1). Abgrenzung: die rechnerische/steuerliche Abbildung der Rechnung bleibt SevDesk (OP-BILLING-1); taktano führt den Rabatt operativ am Auftrag. Zu klären: Rabatt-Datenmodell, Rabatt-Typen (admin-editierbar G-1), Stapelung/Grenzen, Sichtbarkeit. Bezug: OP-R7-6 (Preis), OP-COST-1 (Marge), OP-BILLING-1 (Rechnung), OP-AUDIT-1, OP-AUTH-1, G-1.
OP-R6-1 — (Fahrzeuge, R6) Scope der fahrzeugbezogenen Auftragsübersicht. Marktbeobachtung: im Altsystem vorhanden, aber nicht genutzt. Klären, ob/wo eine Fahrzeug-Historie echten Nutzen stiftet (Reklamation, Wiederkehr, Folien-Spezifikation) — sonst weglassen statt Pflegeaufwand zu erzeugen. Bezug: Produkt-und-Marketing.md §1.
OP-R6-2 — Fahrzeug-Visualisierung (Silhouette/3D/AR) + Besonderheiten-Wissensbasis je Modell (06-28, Nutzer). Drei verbundene Aspekte:
1. Immer eine Fahrzeug-Silhouette anzeigen — am Auftrag/Fahrzeug stets eine visuelle Darstellung; Minimum 2D-Silhouette, Ziel 3D (drehbar), AR vorbereiten (AR-fähige Architektur/Assets). Nutzen: räumliches Markieren von Vorschäden/Besonderheiten/Folierungs-Zonen direkt am Modell (verknüpft OP-R7-16 Fotos, OP-QS-3 Schäden, OP-R7-12 Doku, OP-FEEDBACK-1-Annotations-Bausteine). Schon bei der Annahme nutzen (06-28, Nutzer): die Silhouette direkt in der Annahme einsetzen, um Arbeitsbereiche/Scope direkt am Fahrzeug zu markieren (z. B. „länger gezogene Ladekante") — die markierten Zonen verknüpfen den Arbeitsumfang/die Leistung mit dem Ort am Fahrzeug (Bezug Prozess-Vorschau OP-R7-15, Fahrzeug-Angaben OP-R7-16) und dienen später als gemeinsame Referenz für Produktion/Quality-Check. ⚠ Aufwand-Flag: 3D-Asset-Pipeline je Fahrzeugmodell ist erheblich → stufenweise (2D-Silhouette → generisches 3D je Karosserieform → modellgenaues 3D → AR); Asset-Lizenzen klären. Für die Annahme reicht als erster Schritt eine 2D-Silhouette mit Zonen-Markierung. Recherche 07-04 (Quellen/Rendering/iOS, Nutzer-Frage): generische Karosserietyp-Modelle (CC0, GLB — Quaternius/Poly Pizza/Kenney) + <model-viewer> (Drehen + nummerierte Hotspot-Markierungen mit Kommentar/Foto-Verknüpfung out of the box) + USDZ-Pfad für iOS-nativ/AR → das Aufwand-Flag relativiert sich (es galt für fahrzeuggenaue Modelle), Stufe 1 kann direkt generisches 3D sein; fahrzeuggenaue Marken-Modelle bewusst nicht (Marken-/Lizenzrecht, Redistribution offener Formate). Detail + Markierungs-Datenmodell (FahrzeugMarkierung, renderer-neutral): docs/architektur/Fahrzeug-3D.md.
2. Besonderheiten je Fahrzeugmodell festhalten (aus dem Learning) — modellspezifische Hinweise, die fürs Gewerk relevant sind (Beispiel Nutzer: Porsche 911 ab GT mit Leichtbauscheiben → andere Behandlung beim Folieren/Reinigen). Aufgebaut über die Zeit aus den Aufträgen (Learning). Bei der Annahme: erkanntes Modell (über FIN/Beschreibung, OP-R7-16) → bekannte Besonderheiten vorschlagen; nicht vorhanden → Modell + Besonderheit anlegen. Datenmodell: Fahrzeugmodell-Katalog (Hersteller/Modell/Baureihe/Variante) mit Besonderheiten — getrennt von der auftragslokalen Fahrzeug-Instanz (§4.9).
3. Cross-Tenant-Wissen als kostenpflichtiges Add-on — Besonderheiten anderer Betriebe/Tenants als Zusatzleistung / Add-on-Subscription verfügbar machen (Schwarm-Wissen). ⚠ Flagging (wichtig): widerspricht der Tenant-Isolation (OP-TENANT: Daten physisch getrennt) → braucht eine bewusst geteilte, zentrale Wissensbasis mit Opt-in + Anonymisierung (kein Leak von Auftrags-/Kunden-/PII-Daten, nur generisches Modell-Wissen) und Wettbewerbs-/Einwilligungs-Abwägung (Werkstatt-Know-how teilen). Geschäftsmodell als Add-on (OP-BILLING-1 — Add-on-Subscription neben dem Basis-Abo). Zu klären: Governance/Kuratierung der geteilten Einträge (Qualität/Fehler), Vergütungsmodell für beitragende Betriebe, Datenschutz/DSGVO der geteilten Inhalte.
Bezug: R6, OP-R6-1, OP-R7-16 (Fahrzeug-Angaben Annahme), OP-TENANT (Isolation ↔ geteiltes Wissen), OP-SEED-1, OP-BILLING-1 (Add-on), OP-AI-4 (Wissens-/Assistent-Layer), OP-QS-3/OP-R7-12 (Markieren/Doku), design/ (Visualisierung), Produkt-und-Marketing (Monetarisierung).
OP-UMPARK-1 — Umparken als zuweisbare Aufgabe, G-4-konform platziert (07-12, aus dem Umparken-Check). Befund (Check 07-12): „Umparken beauftragt" ist heute reine Leitstand-Optik — es gibt keinen Skill „Umparken", keinen Teilschritt, keine Queue-Platzierung; der Umpark-Auftrag erscheint in keiner „Meine Arbeit"/„Nächste Aufgaben"-Liste, und der „unterwegs"-Status lebt nur client-lokal im Browser des Beauftragenden (nicht im DO-State, nicht gebroadcastet → anderes Terminal sieht nichts, Reload vergisst es, „Angekommen" kann nur der Beauftragende bestätigen). Zudem toastet der Client Erfolg vor der Server-Antwort (stille Ablehnungen — z. B. starten ohne Zuweisung — erzeugen Phantom-Transit). staff.component.ts trägt eine tote Cyan-Hervorhebung für einen Skill „Umparken", den der Vest-Seed nicht kennt (v3-Prototyp-Rest). Ziel: (a) Umpark-Beauftragung wird eine echte, zuweisbare Aufgabe (leichtgewichtig — kein voller Teilschritt nötig, aber DO-State + Broadcast + Queue-Sichtbarkeit + Quittung); (b) Platzierung nach G-4: bevorzugt der Mitarbeiter, der als Nächstes am Fahrzeug arbeitet (aus der Plan-Queue OP-OPT-9 ableitbar) und den Skill hat — erst dann ein freier Logistik-fähiger Mitarbeiter; (c) Skill „Umparken/Rangieren" als Stammdatum (G-1) einführen oder bewusst skill-frei lassen (Führerschein-/Versicherungs-Frage klären); (d) „Angekommen" von jedem Terminal bestätigbar, Chronik + Audit. Abgrenzung: Server-seitiges Auto-Umparken bei Preemption (Konflikt-Hebel „unterbrechen") bleibt wie es ist (parkt auf freien Stellplatz, protokolliert). Bezug: G-4 (§3), OP-OPT-9 (Queues), OP-ORTUNG-2 (Fahrzeug-finden-Flow, gleiches Beauftragungs-Muster), repark.service.ts; Befunde-Detail: CHANGELOG 07-12 + HANDOFF §4 (Umparken-Check). ✅ Umgesetzt (07-12, v0.78.0): Umpark-Auftrag = geteilter Fakt im DO-State (umparkAuftraege) — den geteilten Unterwegs-/Ankunfts-Zustand broadcastet der DO an alle Terminals; umpark.result ist nur die Quittung an die auslösende Verbindung (Erfolg inkl. Zuweisung bzw. Ablehnungs-Grund — kein Phantom-Transit mehr); G-4-Platzierung als pure Funktion waehleUmparkMitarbeiter (1. wer als Nächstes am Fahrzeug arbeitet und den Skill hat → 2. freier Umpark-fähiger, stört keinen laufenden Schritt → 3. „offen"); Skill „Umparken" (skill-umparken) als Stammdatum eingeführt (Seed: Julian + Marco; Migration v20 zieht den Katalog nach; wer darf = Mitarbeiter-Workspace-Pflege — Führerschein-/Versicherungsfrage bleibt Betriebs-Entscheidung); Aufgabe erscheint in „Meine Arbeit" (zugewiesen + offene) mit „✓ Angekommen"; Ankunft von jedem Terminal bestätigbar (Chronik + D1-Audit je Beauftragung/Ankunft); die tote „Umparken"-Skill-Hervorhebung im Mitarbeiter-Workspace ist damit live. Drag&Drop in der Belegung bleibt bewusst direkte Inventur-Korrektur (kein Umpark-Auftrag — dort wird Ist dokumentiert, nicht beauftragt). Offen (Folge): Umpark-Dauer als Solver-Kapazität (bewusst nicht — Minutensache), Rollen-Gate fürs Bestätigen (OP-AUTH-1).
OP-UMPARK-2 — Bucht-Sperre & Bucht-Freiräumen — geparktes Fahrzeug muss umgeparkt werden (07-17, PO). Zwei bislang offene Fälle: (1) eine Bucht wird gesperrt, während ein Auto physisch dort parkt; (2) zwischen zwei Leistungen soll eine Bucht freigeräumt werden, damit ein anderer Auftrag dort laufen kann. Befund: Die Konflikt-Erkennung (sperre_kollidiert/arbeitsplatz_fehlt) prüfte nur geplante Arbeit (teilschritt.bayId), nie die physische belegung — eine Sperre konnte still über ein parkendes Auto hinweggehen; und der Scheduler hält zwischen zwei eigenen Schritten die Bucht via inBayStays belegt (Trade-off „warten vs. ausparken" bewusst noch nicht modelliert). Policy (PO 07-17): eine Bucht mit geparktem Auto lässt sich nicht still sperren — der Umpark-Bedarf bleibt sichtbar bis umgeparkt; Sofort-Sperre → sofort umparken (G-4), geplante Sperre → vor beginn; Zwischen-zwei-Leistungen bleibt „Auto wartet in Bucht" + aktiver Hebel „Bucht freiräumen". ✅ Slice A (07-17, v0.90.0): neuer Konflikt-Typ geparkt_gesperrt (Hoch) via konflikteGeparktInGesperrt(arbeitsplaetze, belegung) (rein abgeleitet, D-2) + Direkt-Knopf „📍 Umparken" an der Konfliktkarte (Repark-Modal OP-UMPARK-1). ✅ Slice B (07-18, v0.96.0): geplante Sperre zur Laufzeit anleg-/entfernbar (arbeitsplatz.update.sperren, server-validiert) + Sperren-Editor (Administration) + Vorlauf-Konflikt geparkt_vor_sperre. ✅ Slice C (07-18, v0.96.0): manueller Hebel „🅿️ Bucht freiräumen" (wartendes Auto → freier Parkplatz, G-4-Umpark-Auftrag) — OP-UMPARK-2 abgeschlossen; die CP-SAT-Abwägung „warten vs. ausparken" → OP-OPT-10. Bezug: OP-UMPARK-1, OP-R8-1, OP-R2-3, OP-ORTUNG-2; Detail: ops/OP-UMPARK-2.md.
OP-PERF-1 — Initial-Bundle des Cockpits reduzieren (07-18). Das Client-Initial-Bundle liegt bei ~1,0 MB (raw) und wächst mit jedem Feature; bei OP-ALERT-1 Slice 3 überschritt es die harte Angular-Budget-Grenze maximumError: 1mb um wenige KB → Sofortmaßnahme: Budget bewusst auf maximumWarning 1mb/maximumError 1.25mb angehoben (client/angular.json, Headroom, kein Fix). Eigentliche Lösung: Workspaces per Route-Level-Lazy-Loading (loadComponent) aus dem Initial-Chunk holen (nur Shell + erster Workspace initial), Budget danach wieder straffen. Bezug: OP-ALERT-1, OP-OFFLINE-1 (SW/PWA-Cache-Interaktion); Detail: ops/OP-PERF-1.md.
OP-SCHICHT-1 — Schicht-Ende-Aufräumen — hochwertige Fahrzeuge in die Halle, Nacht ruhig (07-17, PO). Zum Schichtende die Werkstatt in einen definierten Nacht-Zustand bringen und die nächste Schicht vorbereiten. Devise: möglichst wenig über Nacht in Arbeit — Ausnahme legitime Nachruhe/Cool-down (kein offener Arbeitsschritt). Zielbild: hochwertige Fahrzeuge zum Schichtende in die Halle (konfigurierbar: Kriterium „hochwertig" + Nacht-Hallen-Buchten, knüpft an Indoor-/Luxus-Handling erlaubteParkplatzTypIds an); Aufräum-Routine (offene Umpark-/Logistikaufgaben abarbeiten, Standort je Fahrzeug bekannt); Plan/Reihenfolge steht zum Schichtstart, keine unnötig offenen Schritte über Nacht. Offen/zu klären: „hochwertig"-Kriterium + Nacht-Halle als editierbare Stammdaten (G-1); Trennung „darf über Nacht laufen" (Cool-down) vs. „soll nicht offen sein" im Datenmodell/Scheduler; Auslöser erst manueller „Schicht-Ende-Check", später Scheduler-Integration. Slice 1 ✅ (07-20): Aufräum-Reserve am Schichtende — jede Schicht reserviert die letzten X Min (aufraeumReserveMin, Default 30, admin-editierbar pro Schicht, 0…120) fürs Aufräumen; der Scheduler plant dort keine reguläre Arbeit. Abzug an einer Stelle (mitarbeiterAvailability, nur am spätesten Slot) → paritätisch für TS-Scheduler und CP-SAT-Solver (der die vorab expandierten avail-Intervalle konsumiert); Anzeige als grünes „Aufräumen"-Band im Gantt; Minuten-Eingabe im Schicht-Editor. Slice 2 ✅ (07-20): Nacht-Halle-Check — abgeleitete Überblick-Karte „🌙 Nacht-Halle", die hochwertige Fahrzeuge (Güteklasse ≥ Schwelle, Default 2) zeigt, die zum Schichtende noch nicht in einer Halle/Indoor-Bucht stehen (reine Insight nachtHalleReste, D-2; „Halle" via INDOOR_TYP_RE markiert). Slice 3 ✅ (07-20): Nacht-Halle-Konfig — Schwelle „hochwertig" und Nacht-Hallen-Buchten admin-editierbar (optionales nachtHalleKonfig-Feld, istNachtHalleSlot: Bucht-Allowlist ODER Indoor-Fallback; Karte „🌙 Nacht-Halle (Schicht-Ende)" im Administration-Workspace). Slice 4 ✅ (07-20): Schicht-Ende-Aufräum-Checkliste — konsolidierte Überblick-Karte „🧹 Schicht-Ende-Aufräumen", die vor Feierabend alle offenen Nebenaufgaben zeigt (📍 ohne Standort · 🌙 nicht in der Halle · 🅿️ Umparken offen); rein abgeleitet (D-2, reine Client-Komposition), auto-klärend (kein Abhaken). Offener Folge-Baustein: Nacht-Zustand als Scheduler-Planungsziel. Bezug: OP-UMPARK-2, OP-R2-3, OP-STANDORT-2; Detail: ops/OP-SCHICHT-1.md.
OP-EDIT-1 — Bearbeiten-Modus & gleichzeitiges Editieren von Stammdaten (07-18, PO). Stammdaten öffnen immer zuerst read-only; Bearbeiten ist explizit. Beim Wechsel in den Bearbeiten-Modus warnt das System, wenn ein anderer Benutzer/ein anderes Fenster denselben Datensatz bereits bearbeitet; Schreiben bleibt trotzdem möglich — der erste Schreibvorgang entwertet die konkurrierenden Sitzungen (die anderen können nicht mehr speichern, erhalten eine Meldung „bitte neu laden"). Mechanik: View-first-Toggle · Edit-Präsenz als gebroadcasteter DO-Live-State · optimistische Nebenläufigkeit (Versionsstempel je Datensatz, Speichern mit veralteter Basis wird abgelehnt). Querschnitts-Muster für alle Stammdaten-Editoren; verhindert stilles last-write-wins-Überschreiben. Referenz ✅ Arbeitsplatz-Editor (Slice A/B/C); Rollout ✅ Schicht-Editor (07-21) + Mitarbeiter-Editor (07-22: rev-Optimistik + Präsenz-Warnung + ✎-Badge, view-first schon durch expliziten „Bearbeiten"-Knopf; rev guardt gezielt das Stammdaten-Speichern, additive Sub-Aktionen heben rev nicht) + Taxonomie-Editor (07-23: inline „Umbenennen" mit rev-Optimistik + Präsenz-✎-Badge; Inline-Konflikt-UX = schließen + Banner, Aktiv-Quick-Toggle ohne baseRev) + Leistungen/Teilschritte (07-23: Slice A architektonisch N/A — der Prozesse-Editor ist durchgängig sofort-anwendend inline, kein Formular/Speichern-Fenster, also kein last-write-wins-auf-Save zu bewachen; Slice B adaptiert = Ko-Bearbeiter-Banner „wird gerade auch bearbeitet, Änderungen wirken sofort" für die geteilte, taktungs-harte Live-Konfig). ✅ Rollout KOMPLETT über alle Stammdaten-Editoren. Auslöser: OP-UMPARK-2 Slice B (Sperren-Editor „ganze Liste patchen"). Bezug: OP-AUTH-1 (Identität), OP-DATA-1 (Versionierung); Detail: ops/OP-EDIT-1.md.
OP-OPT-10 — Scheduler-Abwägung „Auto in der Bucht warten lassen vs. ausparken" (07-18). Der Scheduler soll selbst entscheiden, ob ein Fahrzeug zwischen zwei Leistungen in der Bucht wartet oder ausgeparkt wird, um die Bucht zwischenzeitlich freizugeben (heute hält der TS-Scheduler sie via inBayStays belegt; der manuelle Hebel OP-UMPARK-2 Slice C deckt es reaktiv ab). Zielbild: „wait-in-bay vs. move-out" im CP-SAT-Modell als Kosten/Variable (Rangier-Aufwand + G-4/G-2 vs. freigegebene Bucht-Kapazität), unter G-3/G-4 + Nacht-Ausnahme (OP-SCHICHT-1); TS-Fallback behält das einfache Warten. Bezug: OP-UMPARK-2 (Slice C = Vorstufe), OP-R2-3, OP-SCHICHT-1; Detail: ops/OP-OPT-10.md.
OP-STEP-1 — Schritt-Abschluss nutzbarer machen (07-19, PO). Befund am Auftrag-Detail-Panel: jeder offene Schritt bietet gleichzeitig „✓ Fertig (mit Doku)" (Reihenfolge nicht durchgesetzt), und die Foto-Pflicht ist optisch schwach bzw. oft nicht hinterlegt. Zielbild (PO: „hart"): nur der aktuelle Schritt ist fertigmeldbar/hervorgehoben („▶ jetzt dran"), spätere sind gesperrt („🔒 kommt später — erst nach "); Parallelität über die Scheduler-Startzeiten (Front = früheste Startzeit der offenen Schritte). Abschluss als geführte Checkliste (Pflicht-Fotos je Perspektive + Doku, „Fertig" gesperrt mit klarer Restliste); Foto-Vorgaben je Leistung/Teilschritt als gepflegte Stammdaten. Slice 1 ✅ Sequenz-Gating (Client), Slice 2 ✅ geführter Foto-/Doku-Abschluss, Slice 3 ✅ Vorgabe-Pflege im Prozesse-Workspace, Slice 4 ✅ Server-Backstop (07-19): der teilschritt.aktion 'erledigen'-Handler lehnt out-of-order-Abschluss serverseitig ab (istAktuellerSchritt/istOffenerSchritt in operativ/auftrag.ts, Defense-in-Depth; Gate greift vor Doku-/Foto-Gate; Selbsttest test:step-gate, CI). Erledigt — offen nur noch die bedingte Verfeinerung „feinere Parallelität" (G-1-Abhängigkeit explizit ins Instanz-DTO heben, falls die Startzeit-Heuristik nicht reicht). Bezug: OP-PHASE-1, OP-QS-1, OP-R4-3, OP-UX-1, G-1; Detail: ops/OP-STEP-1.md.
OP-UMPARK-3 — Umparken: passendste Plätze nach aktuellem Schritt + Prozess pausieren (07-19, PO). Der Repark-Flow soll freie Zielplätze nach Eignung für den aktuellen/nächsten Schritt ranken (Bucht-Typ/Skill/Ausstattung, Indoor/Cool-down, Nähe/G-4) — bester zuerst, mit Begründung — statt generischer Auswahl; und Umparken pausiert den laufenden Schritt bis zur Ankunft am Ziel (umpark.angekommen), statt ihn scheinbar weiterlaufen zu lassen. Baut auf OP-UMPARK-1 (Umpark-Auftrag/Transit) + Pausier-Mechanik. Slice 1 ✅ kontextbezogener Vorschlag (Typ + Kapazität), Slice 2 ✅ (07-19) Ranking-Verfeinerung Skill-Eignung: die Empfehlung rankt zuerst nach dem vom Schritt geforderten Skill (Arbeitsplatz.skillIds ⊇ {Skill}, §6.1-Regel — eine typ-gleiche Bucht ohne den Skill ist gar kein gültiges Ziel), dann Kapazität; „🎯 "-Badge. Rein Client (teilschritteKatalog.benoetigteSkillId + arbeitsplaetze().skillIds, kein DTO-Change). Pause (Teil B) weitgehend via modus:'pausieren' vorhanden. Offen: Ausstattung (kein Schritt-seitiges Anforderungsfeld) + Nähe/G-4 (kein Standort-/Zonen-Modell) — beide ehrlich vertagt (Datenmodell-Erweiterung nötig). Bezug: OP-UMPARK-1/-2, OP-STEP-1, OP-R2-3, G-4; Detail: ops/OP-UMPARK-3.md.
OP-UMPARK-4 — Klären, wo „Umparken" sichtbar/erreichbar ist (07-19, PO — Klärungs-OP). „Umparken" ist heute verstreut auslösbar (Belegungs-Board Drag&Drop + „🅿️ Freiräumen", Konflikt-Karte „📍 Umparken", Detail-Panel, ggf. Werker-Modus). Zu klären: widerspruchsfreie, sprechende Soll-Platzierung + einheitlicher Wortlaut + Sichtbarkeitsregeln (immer vs. nur bei Bedarf). ✅ Erledigt (07-19): Ist-Bestandsaufnahme (8 Auslöse-Stellen, 1 ReparkService + 1 globales Modal, Verteilung kontextrichtig → bleibt); Entscheidung: 2 Begriffe („Standort zuweisen" vs. „Umparken", Ausreißer angeglichen), 2 Direkt-Pfade (Drag&Drop + Freiräumen) bleiben, Sichtbarkeits-Referenztabelle im OP. Bezug: OP-UMPARK-1/-2/-3, OP-UX-1; Detail: ops/OP-UMPARK-4.md.
OP-QS-6 — Vier-Augen-Prinzip beim Quality-Check hart durchsetzen (07-12, PO — Teil der G-4-Regel). Regel: Wer eine Arbeit ausgeführt hat, darf ihr Ergebnis nicht selbst verifizieren — der QS-/Quality-Check-Schritt eines Auftrags wird nie dem Mitarbeiter zugewiesen, der die zu prüfenden Produktionsschritte ausgeführt hat. Befund (Check 07-12): Der Scheduler kennt heute keine solche Constraint — QS-Schritte werden rein skill-basiert (skill-qm) vergeben; ein Mitarbeiter mit skill-qm, der zuvor foliert hat, kann seine eigene Folierung prüfen. Umsetzung (zu klären): harte Constraint in TS-Scheduler und CP-SAT (Ausführenden-Set je Auftrag aus den erledigten Produktions-Instanzen ableiten → als verbotene Zuweisung für qs-Phase-Schritte); Verhalten bei Ein-Personen-Engpass (einziger skill-qm-Träger ist der Ausführende → Konflikt-Hebel/Klärfall statt stiller Selbst-Prüfung); manuelle Zuweisungs-UI ebenso gaten (nicht nur der Solver); Nacharbeit-Schleife (Nacharbeiter ≠ Prüfer der Nacharbeit). Bezug: G-4 (§3, Ausnahme), OP-QS-GATE/OP-QS-4 (QS-Phase), §6.1 (Solver-Constraints), OP-AUTH-1 (wer darf manuell übersteuern — mit Audit). ✅ Umgesetzt (07-12, v0.79.0): Prüfschritt = Phase qs ohne Nacharbeit-/Klärungs-Marker (Nacharbeit + Klärung sind Ausführung in der QS-Phase, kein Prüfen). Pure Domäne istPruefschritt/qsAusfuehrende/vierAugenVerletzung (Helfer zählen bewusst nicht — der Produktive verantwortet). Durchsetzung an vier Punkten: (1) TS-Scheduler schließt für Prüfschritte die Crews der Nicht-Prüfschritte desselben Auftrags aus (prospektiv, im Lauf) + G-4-Heuristik „zwingende Ausführende zuerst" (der einzige Könner eines Schritts übernimmt bevorzugt auch andere — sonst verbrennt der Greedy den letzten freien Prüfer); Infeasible-Grund nennt Vier-Augen. (2) CP-SAT-Payload entfernt Ist-Ausführende aus der Prüfschritt-Eligibility (⚠ prospektive Co-Zuweisung im selben CP-SAT-Lauf bleibt offene Lücke — echte Cross-Task-Constraint in model.py = Folge; gedeckt durch (3)). (3) Ausführungs-Guard (hart): Start/Fortsetzen eines Prüfschritts mit Ausführenden in der Crew wird serverseitig abgelehnt; UI zeigt „⚠ Vier-Augen" (Detail-Panel + Meine Arbeit). (4) Hand-Zuweisung wird gleich gegated (Ablehnung sichtbar in der Chronik). Chef-Abweichung (PO): je Prüfschritt qs.vierAugenFreigabe mit Pflicht-Begründung — Chef-gegated (interim = Werkstattleitungs-Allowlist wie Kosten-Admin, bis OP-AUTH-1 Rollen liefert), Chronik + D1-Audit qs.vieraugen.freigabe; Freigabe wirkt für GENAU eine Instanz. Seed-Folge: Marco erhielt skill-qm ★2 — im Premium-Prozess führen Julian (Folie ★3) und Sina (Keramik) selbst aus; ohne dritten Prüfer wäre die Endkontrolle unplanbar (realer Staffing-Punkt für den Vest-Stammdaten-Abgleich: wer prüft Güteklasse-3-Aufträge, wenn beide Stufe-3-Kräfte ausgeführt haben?).

11.2 Planung

OP-R8-1 — vollständige Konflikt-Typ-Enum-Liste. (✅ alle 7 Typen umgesetzt, §5.2.3. Offen: Feed-Filter, Hebel-Wizard-Integration der neuen Typen.)
OP-R8-2 — Auto-Resolve-Algorithmus – konkrete Entscheidungsregeln. (v1: Hebel mit berechneter Auswirkung vorhanden, §5.2.3; automatische Hebel-Wahl jetzt umgesetzt, vgl. OP-R8-7.)
OP-R8-3 — Wizard-Modus – schrittweiser Resolution-Flow. (umgesetzt v1: „Konflikt lösen"-Wizard mit voller Hebel-Liste aus der Prozess-Definition, §5.2.3.)
OP-R8-4 — Drag-and-Drop-Validierungsregeln im Detail.
OP-R8-5 — Helfer-Semantik vs. Skill-Anzahl – Klärung der Beziehung.
OP-R8-6 — Angebotsmodus-Output – Ranking-Kriterien.
OP-R8-7 — „Alle automatisch lösen" – Garantien, dass keine neuen Konflikte entstehen. (✅ Slice 1 umgesetzt, §5.2.3: sicherste-Hebel-Wahl je Konflikt + Sicherheits-Prüfung gegen die zu Beginn bekannten Konflikte. Offen: Überstunden-/Kapazitäts-Hebel würde die Trefferquote erhöhen.)
OP-R8-8 — Skill-bewusste Arbeitsschritt-Vorschläge in der UI. Marktbeobachtung: das Altsystem schlägt Schritt-/Personen-Zuordnungen vor, die die vergebenen Skills ignorieren. Unsere Engine ist skill-getrieben (benoetigteSkillId + anzahlPersonen + Bucht-Skill); zu klären ist die UI-Darstellung der Vorschläge (nur qualifizierte Mitarbeiter anbieten, Engpass-Hinweis). Bezug: Produkt-und-Marketing.md §1.
OP-R8-9 — Nachkontrolle nach 14 Tagen als Prozessschritt modellieren. (Teil-Status „kontrolliert" im Lifecycle vorhanden, §5.1; die terminierte, off-site Nachkontrolle als planbarer Schritt ist noch offen.) Nach Auslieferung folgt eine terminierte Nachkontrolle (~14 Tage später). Besonderheit: das Fahrzeug ist dabei i. d. R. NICHT in der Firma — der Schritt belegt also normalerweise keinen Stellplatz/keine Bucht, ist aber ein planbarer Termin (Personal-/Zeitbedarf). Ausnahme: das Fahrzeug kann auch vor Ort geparkt bleiben (dann doch Stellplatz-Belegung). Zu klären: Modellierung als „off-site"-Teilschritt (kein Bay-Bedarf, optionaler Stellplatz), Termin-Logik (relativ zur tatsächlichen Abholung), Erinnerung/Benachrichtigung, Verhältnis zur Standzeit/§6.1.
OP-R8-10 — Güteklasse-/Niveau-Engpass bei Mehr-Personen-Schritten. Folgt aus dem Stufen-Modell (§4.1): ein Teilschritt, der mehrere Personen mit dem geforderten Skill braucht (anzahlPersonen > 1), kann für ein hochwertiges Fahrzeug unbesetzbar werden, wenn weniger Personen den Skill auf dem nötigen Niveau und die Vertrauensstufe erfüllen als gefordert. Aktuell wird das ehrlich als nicht machbar gemeldet. Zu klären: (a) weitere Kraft qualifizieren, (b) Personenanzahl/Niveau für die Güteklasse anpassen, oder (c) Überstunde/externe Kraft (Engpass-Hebel §5.2.3). Idealerweise benennt der Engpass-Hebel die fehlende Stufe konkret.
OP-R8-11 — „Möglichst freizuhaltende Zeit" je Mitarbeiter & Bucht. Pro Mitarbeiter und pro Bucht sollen weiche Sperr-/Freihalte-Fenster einplanbar sein, die der Optimierer nach Möglichkeit respektiert (Soft-Goal, §6.2), aber im Konflikt mit harten Terminen überschreiben darf (anders als eine harte Sperre, §4.3-S1). Use-Cases: Puffer/Wartung/Schulung/„Springer freihalten". Zu klären: Datenmodell (wiederkehrend vs. einmalig, Ressourcen-Bezug), Pönale-Gewicht, Darstellung (Gantt-Schraffur), Verhältnis zu harten Sperren.
OP-R8-12 — Optimierung nach verschiedenen Kriterien / Gewichtungen. Die Zielfunktion (§6.2: Durchsatz, Reserve/Termintreue, Wechsel-Pönale, Lücken, Freihalte-Fenster …) soll konfigurierbar gewichtet werden — z. B. wählbare Profile („Durchsatz-Max", „Termintreue-Max", „ruhiger Tag/wenige Wechsel"). Zu klären: welche Kriterien wählbar/gewichtbar, UI (Slider/Profile, ggf. pro Optimierungslauf), wie die Gewichte in CP-SAT-Zielgewichte übersetzt werden (Skalierung), Default-Profil, Vorschau-Vergleich zweier Profile.
OP-R8-13 — Konfliktvermeidungs-Hebel: Bereitschaft / (genehmigte) Wunschfrei heranziehen (06-28, Nutzer). Bei einem Termin-/Kapazitätskonflikt (§5.2.3) sollen als zusätzliche Hebel Kapazitätsquellen explizit angeboten werden — als Beispiel des Nutzers: (1) Bereitschaft heranziehen (Überlauf-/Bereitschaftsschicht öffnen) und (2) eine (genehmigte) „Wunschfrei" heranziehen (den weichen Frei-Wunsch zugunsten der Konfliktlösung überschreiben). Anschluss: Die Bausteine existieren bereits aus OP-OPT-7 — Bereitschaftsschichten als pönalisierte Hybrid-Variante + „Wunschfrei" als Soft-Block, mit fertiger Eskalations-/Pönale-Reihung (Wunsch 2 < Bereitschaft 5 < genehmigte Überstunde 200) → der Hebel zieht zuerst die „weichste" Quelle. Neu: diese Quellen als konkrete, quantifizierte Hebel im Konflikt-Wizard (§5.2.3) anbieten (welcher MA/welche Schicht, Wirkung auf Termin/Reserve), Propose-not-execute (Mensch entscheidet). Zu klären: das „Ziehen" einer Wunschfrei braucht ggf. Mitarbeiter-Zustimmung/Benachrichtigung (eine genehmigte/zugesagte Freizeit zu überschreiben ist sensibel — arbeitsrechtlich/Fairness); Reihenfolge/Default der Hebel, Darstellung der Auswirkung, Audit (OP-AUDIT-1). Bezug: OP-OPT-7 (Bereitschaft/Wunschfrei + Pönale-Reihung), §5.2.3 (Konflikt-Hebel), OP-R8-2/3/7 (Hebel/Auto-Resolve), G-2, R1 §4.4a (Abwesenheiten/Soft-Blocks).
OP-OPT-8 — Zeitlage-Präferenz je Leistung/Teilschritt: „asap" vs. „optimiert/spät (jit)" (06-28, Nutzer). Auf Prozess-/Leistungs-Ebene festlegen, ob ein Schritt so früh wie möglich (asap) oder so spät wie möglich / just-in-time (jit, „optimiert/geplant") eingetaktet werden soll. Beispiele (Nutzer): Folierung möglichst früh (asap); Fahrzeug-Aufbereitung/Endreinigung eher spät (jit, kurz vor Abholung — damit es nicht wieder einstaubt). Heute steuert die Terminklasse je Auftrag (garantiert/ziel/best_effort) + globale asap/jit-Zielmodi (§6.2, design/OPTIMIERER_TERMINKLASSEN.md); neu = prozess-/leistungs-/teilschritt-spezifisch. Datenmodell: Feld am Teilschritt/Leistung (z. B. zeitlage: 'asap' | 'jit' | 'neutral'), admin-editierbar im Prozess-Editor (OP-R3-3, G-1). Scheduler: als Soft-Goal/Zielterm — asap minimiert die Startzeit, jit schiebt so spät wie möglich (bei Wahrung harter Constraints/Termine), in CP-SAT je Schritt + TS-Scheduler analog. ⚠ Abwägung: jit reduziert die Reserve/den Puffer (höheres Risiko bei Störung/Verzug) → bewusst nur weich + nachrangig gegenüber Termintreue. Zu klären: Default (neutral), Gewicht ggü. den übrigen Zielen (§6.2/OP-R8-12-Profile), Wechselwirkung mit Cool-down/Standzeit (§6.1) und mit der Vor-Produktion (OP-PHASE-1). Bezug: §6.2 (asap/jit-Zielfunktion), design/OPTIMIERER_TERMINKLASSEN.md, OP-R3-3 (Editor), OP-R8-12 (Gewichtung/Profile), OP-PHASE-1, G-3.
OP-OPT-9 — Ressourcen-Queues („Nächste Aufgaben") + Auto-Anwenden terminneutraler Re-Opt-Verbesserungen (07-03, Nutzer; Slices 1+2 umgesetzt v0.59.0). Nutzer-Impuls: „Hat jeder Platz/Mitarbeiter eine priorisierte Queue geeigneter nächster Aufträge? Wird bei jeder Veränderung neu das nächste Optimum vorgeschlagen?" Entscheidung — Architektur bleibt globaler Plan: echte lokale Dispatch-Queues (greedy „nimm den nächsten geeigneten Auftrag") verworfen, weil sie gegen den globalen Optimierer Abhängigkeiten, Termingarantien, Park-/Buchtkonflikte und G-2/G-3 verlieren; die Queue ist die Ressourcen-Projektion des globalen Optimums. (1) Umgesetzt — „Nächste Aufgaben" je Mitarbeiter/Arbeitsplatz (Planung, unter dem Gantt; naechste-aufgaben.component.ts): priorisierte Queue je Ressource als reine Projektion des Plans (Derived State §7.7/S-2) — läuft jetzt (▸) · pausiert (⏸) · als Nächstes (1…n, Plan-Reihenfolge), je Eintrag Start/Auftrag/Schritt/🎓-Helfer/⚡-Terminkonflikt; Kopf „frei ab …"/„jetzt frei" je Ressource (True North 3); Tabs Mitarbeiter/Arbeitsplätze (Bucht inkl. Cool-down); Klick → geteiltes Detail-Panel. (2) Umgesetzt — Auto-Anwenden: die event-getriggerte Re-Opt wendet terminneutrale Pareto-Verbesserungen (≥1 Auftrag echt früher und keiner später — damit kann kein Wunsch-Abholtermin neu reißen) direkt an statt nur vorzuschlagen; reine Umsortierungen ohne Zeitgewinn bewusst nicht (Plan-Stabilität, keine Oszillation durch gleichwertige CP-SAT-Alternativlösungen). Kriterium pure in server/src/operativ/autoopt.ts (autoAnwendbar, Selbsttest test:autoopt); Anwenden mit Chronik je Auftrag + Audit-Event plan.auto (docs/architektur/Audit-Log.md); Trade-offs bleiben bestätigungspflichtiger Vorschlag („Vorschlag statt Zwang"). (3) Umgesetzt — persönliche Queue in „Meine Arbeit" (gleicher PR): die Werker-Sicht sortiert die eigenen Schritte in Plan-Reihenfolge (laufend → pausiert → geplant nach Optimierer-Startzeit statt Auftragsnummer), nummeriert wartende Schritte (1 = als Nächstes), zeigt „ab " je geplantem Schritt + „laut Plan frei " im Kopf. (4) Umgesetzt — Schalter + Benachrichtigung (v0.60.0): Auto-Nachführung an-/abschaltbar — persistiertes Feld autoOptAktiv (Default an, onStart-Backfill), Toggle in der Planung-Toolbar, jeder Schaltvorgang auditiert (plan.autoopt.konfiguriert); aus ⇒ jede Verbesserung bleibt bestätigungspflichtiger Vorschlag. Entscheidung: Schalter global je Werkstatt-DO (= je Tenant, OP-TENANT) — Planungs-Policy ist Betriebs-, keine Personen-Einstellung; Rollen-Gate folgt mit OP-AUTH-1. Bei Auto-Anwendung broadcastet der DO plan.autoAngewendet (Grund + betroffene Aufträge/Δ) → Toast an alle Verbindungen inkl. Werker-Terminals („die Queue springt nicht kommentarlos"). Entscheidung: In-App-Broadcast statt Push/E-Mail — ohne Mitarbeiter-Login (OP-AUTH-1) gibt es keinen personalisierten Kanal; Toast an alle = ehrliche v1. (5) Umgesetzt — Queue-Hinweis in der Tafel (v0.61.0): jede Tafel-Auftragszeile zeigt unter dem aktuellen Schritt „→ als Nächstes: · ab " — den nächsten wartenden Schritt in Queue-Reihenfolge (geteilter queueVergleich-Helfer, dieselbe Semantik wie Planung-Queues/„Meine Arbeit"; reine Projektion, kein Server-Change). Offen (beides an OP-AUTH-1 gekoppelt): personalisierte Werker-Zustellung (Push, OP-R1-2) · Rollen-Gate für den Auto-Schalter. Bezug: §6.2 (Ziele), §7.7 (Derived State), OP-R2-3 (Bucht-Gantt, verwandte True-North-3-Sicht), OP-R9-6 (Kapazitäts-Angebote), G-2, G-3.
OP-R2-3 — Buchten-Gantt aus der Planung in die Belegung verschieben + mehr Detail (06-28, Nutzer). Der Bucht-bezogene Gantt (zeitliche Belegung je Arbeitsplatz/Bucht) soll aus dem Planung-Workspace in den Belegung-Workspace wandern — dort gehört die zeitliche Buchten-Belegung thematisch hin (Belegung = „wo stehen Fahrzeuge, wann ist welche Bucht frei"), ergänzend zum heutigen Hallen-/Hofplan (Ist-Belegung jetzt, OP-R2-2). Beantwortet True-North-Frage 2 (Standort über die Zeit) und 3 (nächste freie Kapazität — Bucht-Lücken sichtbar). Mehr Detail auf dem Gantt (Voraussetzung): je Bucht-Block Auftrag/Fahrzeug · Teilschritt · Mitarbeiter · Status/Phase · Standort, Cool-down/Settle-Zeiten, Ausfall-Bänder (Wartung/gesperrt, scheduler/ausfall.ts) und freie Slots/Lücken hervorheben (nächste freie Kapazität). Zu klären: verschieben vs. duplizieren (Planung behält ggf. den MA-zentrierten Gantt + Optimierungs-Sicht, Belegung bekommt die Bucht-zentrierte zeitliche Sicht), geteilte gantt.component.ts parametrisieren (Zeilen=Buchten), Detailtiefe vs. Übersichtlichkeit, Interaktion (Klick → geteiltes Detail-Panel, Drag&Drop?). Bezug: R8 (Planung/Gantt), R2 (Belegung/Arbeitsplätze), OP-R2-2 (Hallen-/Hofplan), OP-UX-1, client/.../gantt.component.ts, scheduler/ausfall.ts, True North 2+3.

11.3 Leitstand

OP-R9-2 — Berechnung des Engpass-Faktors in „Freie Kapazitäten".
OP-R9-3 — Berechnung von Planungsstatus / Planungsscore.
OP-R9-4 — Detail-Spezifikation der Mitarbeiter-Ansicht (zwei-tier UX).
OP-R9-5 — Krankmeldung – Self-Service oder Admin-Aktion.
OP-R1-6 — Mitarbeiter-Seite für 10–50 Mitarbeiter skalieren — erst Konzepte entwickeln & vergleichen, dann umsetzen (06-29, Nutzer). Befund: die Mitarbeiter-Seite (client/src/app/leitstand/pages/staff.component.ts) rendert je Mitarbeiter eine Karte mit voller Qualifikationsmatrix (Skill × Niveau ★1–3) + Ausbildungszielen + Beförderungs-Historie. Das ist auf wenige Demo-Mitarbeiter ausgelegt; bei 10–50 Mitarbeitern (realistische Werkstatt-/Multi-Standort-Größe) wird die Karten-Liste unübersichtlich: Scrollen, jemanden finden, mehrere vergleichen („wer kann Keramik ★≥2?") und pflegen (Skill/Schicht/Abwesenheit mehrfach setzen) werden mühsam. Vorgehen (Nutzer-Vorgabe, bewusst zweistufig): (1) Konzeptphase zuerst — 2–3 Konzepte als Mockup/Skizze (Markdown + Mermaid/Wireframe, Everything-as-Code, keine Binär-Master), gegeneinander bewerten entlang Übersicht bei N≈50 · Pflege-/Bulk-Effizienz · True-North-Beitrag (Eignung/Verfügbarkeit) · Aufwand; (2) dann Slice-weise umsetzen. Konzept-Kandidaten (zu vergleichen, nicht-bindend):
- Qualifikations-Matrix/Heatmap — Mitarbeiter (Zeilen) × Skill (Spalten), Zelle = Niveau-Sterne/leer; beantwortet „wer kann was, wie gut?" auf einen Blick, kompakt, vergleichend (deckt sich mit der „Wer-kann-was"-Frage hinter der Taktung).
- Tabellen-/Listen-Sicht mit Suche · Filter · Sortierung (Abteilung/Rolle/Skill/Niveau/Vertrauensstufe/Auslastung/„beförderungsreif") + geteiltes Detail-Panel (wiederverwendetes Muster wie Tafel/Klärfälle — Klick öffnet die volle Karte rechts).
- Karten-Grid + Virtualisierung + Filterleiste — das heutige Karten-Muster skaliert (nur sichtbare Karten rendern, Filterleiste oben).
- Gruppierung nach Abteilung/Rolle, einklappbar (Akkordeon), ggf. kombiniert mit einer der obigen.
Querschnitt (für alle Konzepte): Suche/Filter/Sortierung; Verdichtung sekundärer Infos (Auslastung/Verfügbarkeit/„beförderungsreif"-Badge aus OP-R1-3); optional Bulk-Aktionen (Skill/Schicht/Abwesenheit mehreren zuweisen); Verhältnis zu Personalisierung/sichtbare MA (OP-R9-7) und Mobile (OP-R9-8). Status: Konzeptphase — kein Code jetzt. Zu klären: Default-Ansicht, ob Matrix und Liste (Umschalter), Schwelle ab der die Karten-Liste kippt, Editierbarkeit direkt in Matrix/Tabelle vs. nur im Panel. Bezug: OP-R9-4 (Mitarbeiter-Ansicht-Detailspez, zwei-tier UX — diese skaliert sie konkret), OP-R9-7 (personalisierbarer Leitstand), OP-R9-8 (mobile Ansicht), OP-R9-10 (Dashboard), OP-R1-3 (Niveau/Badges), OP-SKILL-1 (prozess-getragene Skills → schlankere Qualifikationsmatrix), G-1, True North 1+3.
OP-R9-7 — Personalisierbarer Leitstand. Marktbeobachtung: im Altsystem erscheinen alle Mitarbeiter mit Zugang im Leitstand. Nicht jeder mit Zugang muss sichtbar sein. Klären: filter-/rollenbasierte Personalisierung (sichtbare Mitarbeiter/Ressourcen je Nutzer/Ansicht, gespeicherte Ansichten). Bezug: Produkt-und-Marketing.md §1.
OP-R9-8 — Mobile/Responsive Leitstand-Ansicht für Werkstatt-/Betriebsleiter. Marktbeobachtung: keine gute mobile Ansicht. Leitung ist mobil unterwegs und braucht Überblick + einfache Eingriffe von unterwegs. Klären: Umfang der mobilen Ansicht (read-only Überblick vs. Aktionen), Geräteklassen.
OP-R9-9 — Light/Dark-Mode umschaltbar (immer). Die Anwendung muss jederzeit zwischen hellem und dunklem Design umschaltbar sein (Toggle immer erreichbar; Wahl persistiert je Nutzer/Gerät; „System" als Option). Status: ✅ umgesetzt. Umsetzung: zweites Token-Set (Light) wird aus design/tokens/tokens.json generiert (Hell-Wert je theme-abhängigem Token unter $extensions.taktano.light; build.mjs schreibt :root[data-theme="light"] + @media (prefers-color-scheme: light) :root[data-theme="system"]). ThemeService (Angular-Signal light/dark/system) setzt data-theme am <html>, persistiert je Gerät in localStorage und folgt bei „System" live prefers-color-scheme; ein Inline-Skript in index.html setzt das Theme vor dem ersten Paint (kein Flash). Der Toggle sitzt immer erreichbar im Sidebar-Fuß (Ein-Klick-Zyklus System→Hell→Dunkel). Default = System. Detailvertrag/Palette: design/DESIGN_TOKENS.md → „Light theme".
OP-R9-10 — Dashboard-Funktionalität mit Quick-Schalter. Ein immer präsenter Schnellzugriff (auch per Tastenkürzel) öffnet ein Vollbild-Dashboard. Dashboards sind konfigurierbar (Kacheln/KPIs/Listen frei anordnen). Auslieferung mit zwei Standard-Dashboards: (1) Werkstatt-Übersicht (Gesamtlage für Leitung/Disposition), (2) je Mitarbeiter ein persönliches Standard-Dashboard („deine nächsten Schritte/Aufträge"). Zu klären: Widget-Katalog, Speicherung/Sharing der Layouts, Rollen/Default-Zuordnung, Kiosk-/TV-Modus, Verhältnis zum Überblick-Raum + OP-R9-4 (Mitarbeiter-Ansicht).
OP-R9-6 — Proaktive Kapazitäts-Angebote auf Basis des Leistungskatalogs. Über „Freie Kapazität pro Leistung" (§5.3.1) hinaus sprechende Vorschläge wie „Wir hätten morgen noch Kapazität für eine Innenaufbereitung und nächsten Montag ein Lackschutz-Paket.". Zu klären: Berechnung (Angebotsmodus §5.2.2 je Katalog-Leistung über die nächsten N Tage gegen die aktuelle Belegung), Auswahl/Ranking der angezeigten Leistungen (z. B. margenstärkste oder schnell einschiebbare), Aktualität/Live-Update, Darstellung (Dashboard/Leitstand) und ob daraus direkt ein Angebot/Auftrag entstehen kann.
OP-COST-5 — Rentabilitätsberechnung & Prognosen / Ziel-Tracking (Roadmap, 06-28, Nutzer — „muss noch ordentlich ausgearbeitet werden"). Über die reine Kostensicht hinaus (OP-COST-1 Sicht A: Marge je Auftrag/Leistung) den Betrieb rentabilitäts- und prognose-seitig betrachten. Leitfrage des Nutzers: „Wieviele Aufträge (welcher Art) muss ich noch abwickeln, um unser Ziel zu erreichen?" → kombiniert Umsatz/Marge (OP-R7-6 / SevDesk OP-BILLING-1) × Auslastung/Kapazität (True North 1+3, Angebotsmodus §5.2.2) × Zielvorgabe (Periodenziel) zu einer Hochrechnung/Forecast (Ist vs. Plan, „noch X Aufträge à Ø-Marge bis Ziel", Best/Worst-Case-Szenarien, Trend). Status: Roadmap, grob umrissen — Konzept noch ordentlich auszuarbeiten (Datenmodell für Ziele/Perioden, Forecast-Methodik + Annahmen, Umgang mit Saisonalität/Pipeline, Darstellung im Dashboard OP-R9-10, Rollen/Sichtbarkeit). Bezug: OP-COST-1 (Sicht A/Marge), OP-R7-6 (Preis), OP-R7-17 (Rabatte → Marge), OP-BILLING-1 (Umsatz/SevDesk), OP-R9-6 (Kapazitäts-Angebote), OP-R9-10 (Dashboard), True North 1+3, docs/architektur/Kosten.md.

11.4 Formulare & Protokolle (R4)

OP-R4-1 — Bild-Auflösung/-Größe in Protokollen. Das Altsystem speichert Fotos in Originalauflösung; Folgen: PDF-Belege werden 50–100 MB groß (Versand an Kunden problematisch), und das Speichern eines Protokolls dauert sehr lange bei vielen Bildern. Zu klären, ob das eine bewusste Entscheidung war (Archiv-/Beweis-Qualität) und welche Strategie v1 fährt. Lösungsoptionen: clientseitige Komprimierung/Downscaling beim Upload; getrennte Auflösungen (hochauflösendes Archiv vs. komprimierte Versand-/PDF-Variante); asynchrones Speichern/Hintergrund-Verarbeitung statt blockierendem Submit; konfigurierbare Größen-/Megapixel-Limits je Foto-Feld (R4.7.2 Foto-Upload); PDF-Generierung mit reduzierter Bildauflösung. Bezug: §4.7.3 Protokoll, §4.10 Attachment-Modell. Fortschritt: clientseitige Komprimierung/Downscaling ✅ (06-26) — komprimiereFoto() (client/.../leitstand/foto-kompression.ts) skaliert Annahme-Fotos vor dem R2-Upload auf längste Kante 1600 px + JPEG q0.82 (best-effort; Nicht-Bild/Decode-Fehler/kein Gewinn → Original), eingehängt in LeitstandService.uploadFoto. Getrennte Auflösungen (Archiv vs. Anzeige) ✅ (06-26) — optionaler Toggle archiviert das Original in voller Auflösung im Hintergrund (variante=original, eigener R2-Key-Pfad, 30 MB; FotoAttachment.originalR2Key); Anzeige nutzt weiter die komprimierte Variante. Default opt-in/aus. Noch offen: reduzierte PDF-Auflösung, asynchrones Speichern (Submit nicht blockierend), konfigurierbare Megapixel-Limits je Feld.
OP-R4-2 — Datenverlust beim „Raustabben" verhindern. Marktbeobachtung: im Altsystem gehen beim Wechsel in einen anderen Tab oder bei einem Refresh alle Eingaben der Maske verloren. Klären: Entwurf-Autospeicherung / lokaler Formular-State (übersteht Tabwechsel/Refresh), Wiederherstellungs-Hinweis, Konflikt-Handling bei parallelen Bearbeitungen. Bezug: Produkt-und-Marketing.md §1.
OP-R4-3 — Pflicht-Dokumentation bei jedem Prozess-Schritt-Wechsel (Standard-Anforderung, gilt immer; Bezug §5.1 Standard-Prozess / OP-R3-1). Jeder Schritt-Wechsel erfordert mindestens einen Kommentar, optional/erforderlich Bilder. Pro Schritt konfigurierbar, wie viele Bilder je Perspektive (z. B. Front/Heck/Seite/Innen/Detail) nötig sind. Zu klären: Konfig-Modell je Teilschritt (Perspektiven-Liste + Mindestanzahl), Pflicht-Gate vor dem Weiterschalten (verhindert Schritt-Abschluss ohne Doku), Speicherung als Protokoll/Chronik-Eintrag (R4.7.3 / §5.1-Chronik), Verhältnis zu Annahme/Aufbereitung/QS-Doku. Fortschritt: Kommentar-Gate ✅ (PR7/#194: Teilschritt.dokuPflicht (F14) erzwingt ≥1 Kommentar beim Abschluss). Konfig-Modell Foto-Perspektiven ✅ (06-26): Teilschritt.fotoPflicht (F15, {perspektive, anzahl}) + Normalisierung fotoAnforderungen + Seed-Annahme (Front/Heck/Seite L/R/Innen); editierbar (teilschritt.update), angezeigt am Schritt im Detail-Panel. Foto-Upload ✅ (06-26): FotoAttachment (§4.10) + R2-Worker-Routen (/api/foto/upload+/api/foto, deploy-sicher dormant ohne Binding) + Aufnahme-UI je Perspektive + Erledigen-Gate (Pflicht-Fotos erforderlich); lokal mit Miniflare-R2 verifiziert. R2 aktiviert ✅ (06-26): Bucket taktano-fotos (EU-Jurisdiction) + [[r2_buckets]]-Binding live deployed. Client-Kompression ✅ (06-26): Downscale 1600 px/JPEG q0.82 vor Upload (OP-R4-1). Offen: KI-Plausibilität (OP-AI-2; DSGVO: Bilder an externe API klären).

11.5 Auth & Mandanten

OP-AUTH-1 — Produktiver Identity-Provider. Der aktuelle Zugangsschutz ist Cloudflare Access (Zero Trust) als Interim-Gate für den Prototyp (interne Nutzer Vest + Demo, kein Self-Service). Entscheidung 06-23: Ziel-IdP = Better Auth (OSS, self-host auf dem Worker, Identitätsdaten in eurer EU-D1 — EU-Datenresidenz/DSGVO; Organizations-Plugin für Mandanten/Seats, JWT/JWKS zur Edge-Verifizierung). Nachrangig (Fallback, nur falls „schnell ohne Ops" bzw. SAML-Enterprise-SSO dominiert): Clerk (gehostet, US, per-MAU) bzw. WorkOS; die früheren Kandidaten Zitadel/Ory sind mit dieser Entscheidung abgelöst. Maßgeblich = ops/OP-AUTH-1.md. Umsetzung phasiert (A-1…A-5, s. ops/OP-AUTH-1.md); A-1 ✅ (v0.154.1): das überladene istKostenAdmin-Gate in benannte Fähigkeiten (kosten·verwaltung·chef) hinter darf(conn, …) aufgetrennt (verhaltensgleich, Naht für Rollen). Zu klären bleibt (A-2+): Mitarbeiter-Login-Modell (§7.2, jeder MA eigenes Konto vs. geteiltes Terminal) + Kunden-Self-Service (§7.4, OP-R7-7). Detail: docs/architektur/Billing-Zugang.md §7.
OP-AUTH-2 — Mandanten-Trennung. Datenisolation pro Mandant (NFR „Mehrmandantenfähig", §8). Ein Nutzer kann mehreren Standorten/Mandanten zugeordnet sein (Cross-Tenant-Zugriff): Datenmodell, Sichtbarkeits- und Rollenregeln sowie das Verhältnis zu FM-1 Zweigstellen (§12.1) klären.

11.6 Vermarktung

OP-PAY-1 — Paygate/Billing für die SaaS-Vermarktung. Kein MVP-Scope. Zu klären: Merchant of Record (Paddle, übernimmt MwSt-Handling automatisch) vs. Stripe Billing + Stripe Tax; SEPA-Lastschrift und Rechnungskauf für DE-B2B sind Pflicht. Querverweis zu OP-R7-6 (Preismodell/Auftragswert).
OP-VERTRIEB-1 — Vorteilsrechner (ROI) für den Vertrieb umsetzen (07-08, Gründer-Call; ✅ v1 umgesetzt 07-11). Konzept bereits in docs/produkt/Produkt-und-Marketing.md §3 ausgearbeitet (Kunde-/Industrie-Eingangsdaten, erwartete Effekte); umgesetzt als eigenständige Landingpage docs-site/src/pages/vorteilsrechner.js — einfacher/primitiver Rechner (keine Vollversion aller §3-Datenpunkte, Leitprinzip Einfachheit), Entscheidung „Web-Tool vs. Sales-Deck/Excel" zugunsten Web-Tool getroffen. Branchen-Benchmark-Datenquelle bleibt Annahme bis Pilot-Validierung. Lead-Erfassung noch offen, s. OP-VERTRIEB-2. Bezug: OP-MARKET-1, OP-COMPETE-1, OP-VERTRIEB-2/-3. Detail: HANDOFF §4.
OP-VERTRIEB-2 — Akquise-/Orga-Tool für Anbahnungen — Build vs. Buy (07-08, Gründer-Call). Arbeitstitel „Orga-Tool": ca. 50–100 Folierer-Betriebe als Leads erfassen (Anruf-Status + Video-Call-Link zur Produktvorführung). Kernfrage offen: Eigenbau vs. Standard-CRM/Marketing-Tool (z. B. HubSpot) — Leitprinzip Einfachheit „vorhandene Bausteine nutzen statt neu erfinden" verlangt die Prüfung vor Eigenbau. Zu klären: nötiger Funktionsumfang, Kosten HubSpot vs. Aufwand Eigenbau, DSGVO bei externem Tool (Fremdfirmen-Kontaktdaten). Bezug: OP-VERTRIEB-1, OP-VERTRIEB-3. Detail: HANDOFF §4.
OP-VERTRIEB-3 — Verbindlicher Meilensteinplan bis zum Produktivbetrieb (07-08, Gründer-Call). Mündlich skizzierter, noch nicht verbindlicher Rollout-Fahrplan: Ende Juli 2026 Probebetrieb-Start bei Vest Automotive (intern, Go bereits gegeben) → ca. 2–3 Monate Probebetrieb → weiterer „Friendly User" (externe Firma) → Ziel 10–20 Firmen bis Jahresende 2026 („Grundrauschen") → aktiver Vertriebspush ab Januar 2027. Zu klären: Owning-Dokument (Kandidat docs/betrieb/Roadmap.md, führt heute nur OP-Priorisierung, kein Kunden-Rollout-Datum), konkrete Kalenderdaten statt Monatsangaben. Bezug: OP-MARKET-1 (Go-to-Market-Phasen), OP-PM-3, OP-VERTRIEB-1/-2. Detail: HANDOFF §4.

11.7 Arbeitsplätze & Produktion (R2/R3)

OP-R2-1 — Automatische Abweichungs-Erkennung der physischen Belegung (Inventur). Über die manuelle Korrektur (§4.3) hinaus: Check-in-Prozess (z. B. „Auto A steht auf Parkplatz X" per Scan/QR/Sensor), Abgleich Ist vs. Plan, Doppelbelegungen klar hervorheben und Auflösungs-Hilfe anbieten. Zu klären: Erfassungsweg (QR am Stellplatz/Fahrzeug, Kamera, manuell), Konflikt-Darstellung, Verhältnis zu R8-Konflikten.
OP-PROD-1 — Etikettendrucker für die Folienproduktion. Druck von Etiketten (z. B. Auftrag/Fahrzeug/Folien-Spezifikation) im Produktionsprozess. Details folgen.
OP-SKILL-1 — Verwaiste Skills sichtbar machen + Skills näher an Prozesse/Teilschritte verankern (06-29, Nutzer). Anlass (mit Screenshot des Prozesse-Workspace): „Zeige mir Skills, die in keinem Prozess vorkommen — die Skills sollten zu den Prozessen und Teilschritten wandern, da passt es besser (und es macht die Mitarbeiter-Sicht leichter)." Befund (Code): Der Skill-Katalog ist eine eigenständige, admin-editierbare Stammdaten-Liste (Skill {id, name, aktiv}, server/src/model/types.ts; Seed server/src/tenants/vest-automotive.ts = 7 Skills), getrennt von den Prozessen. Jeder Teilschritt fordert genau einen Skill (Teilschritt.benoetigteSkillId, F11 — ein Schritt = ein Skill). Heute referenzieren nur 5 von 7 Skills tatsächlich einen Teilschritt; verwaist (in keinem Prozess/Teilschritt): skill-ppf (PPF Premium) und skill-klaerung (Klärung). Der Prozesse-Workspace zeigt je Teilschritt zwar „Verwendet in …" (welche Leistungen den Baustein nutzen), aber die Inverse — welche Skills in keinem Prozess vorkommen — fehlt. Zwei Aspekte:
1. Verwaiste Skills sichtbar machen — ein abgeleiteter Hinweis/Badge „in keinem Prozess verwendet" (derived aus teilschritte[].benoetigteSkillId gegen den Skill-Katalog, nichts gespeichert, S-2) im Skill-Katalog-Dialog (staff.component.ts) und/oder als Liste. Wichtig: verwaist ≠ inaktiv — ein Skill kann aktiv:true und trotzdem unbenutzt sein; die Sicht macht genau diese „toten" Stammdaten sichtbar.
2. Skills näher an die Prozesse/Teilschritte — Skills dort pflegen/anlegen, wo sie gebraucht werden (im Prozess-Editor beim Teilschritt, OP-R3-3: Skill direkt anlegen/wählen statt im abstrakten Separat-Katalog). Nutzen: schlankere Mitarbeiter-Sicht — nur prozess-getragene Skills als Qualifikationsmatrix/Ausbildungsziel anbieten oder priorisieren, statt aller Katalog-Einträge.
Optionen (eskalierend): (A) ✅ gebaut (0.35.0) — reiner Diagnose-Hinweis: der Skill-Katalog-Dialog (client/src/app/leitstand/pages/staff.component.ts) markiert verwaiste Skills mit Badge „⚠ in keinem Prozess verwendet" + Kopf-Hinweis mit Zähler. Umsetzung abgeleitet: verwendeteSkillIds = computed-Set über teilschritteKatalog().benoetigteSkillId (LeitstandService), istVerwaist(id) = nicht im Set; nichts gespeichert (S-2), Amber/Hinweis-Farbe (nicht Rot — Selbsterklärbarkeit/Design G). Reiner Client-Pfad (kein Server/Solver/Schema/Token). (B) ✅ gebaut (0.39.0) — Skill-Pflege im Prozess-Editor: der Prozesse-Workspace (client/src/app/leitstand/pages/processes.component.ts) bietet je Teilschritt am „Geforderter Skill"-Picker „+ neu" (Inline-Anlegen eines Skills, der serverseitig atomar direkt als geforderter Skill dieses Teilschritts gesetzt wird) und „✎ umbenennen" (wirkt katalogweit). Server: die skill.create-Message trägt optional teilschrittId; nach dem Anlegen/Reaktivieren weist der Handler den Skill via setzeSkillAnforderung dem Teilschritt zu (Mindest-Niveau/Personenzahl bleiben, ein State-Broadcast → race-frei trotz server-generierter Skill-ID). Katalog bleibt Single Source (kein Schema-Change, ungegated wie die übrigen Skill-Handler bis OP-AUTH-1). So „wandern" die Skills zu den Prozessen, wo sie gebraucht werden. (C) ✅ gebaut (0.40.0) — Mitarbeiter-Sicht priorisiert prozess-getragene Skills: an den beiden Skill-Auswahl-Pickern (Qualifikation hinzufügen · Ausbildungsziel, staff.component.ts) werden verwaiste Skills ans Ende sortiert (verwaisteAnsEnde, stabil — prozess-getragene zuerst), gedimmt (--tk-text-faint) und mit Tooltip + Suffix „· in keinem Prozess" markiert. Bewusst nicht ausgeblendet (Selbsterklärbarkeit / „gestaffelt statt verstecken"): sie bleiben wählbar, nur nachrangig; bestehende Zuweisungen unberührt. Reine Anzeige-/Sortier-Logik (derived aus istVerwaist, kein Server/Schema). ➡ OP-SKILL-1 vollständig (A+B+C). Wechselwirkung / bewusste Sonderfälle: skill-klaerung ist absichtlich für OP-R3-1 (Klärfall-Bearbeitung) reserviert und hat (noch) keinen Teilschritt; skill-ppf ist eine Variante von skill-folie → entweder konsolidieren oder einen eigenen PPF-Teilschritt anlegen. Die verwaist-Sicht macht solche Entscheidungen sichtbar (ein Befund, kein Automatismus). Abgrenzung: Skill = Klasse A im Lebenszyklus (archiv/deaktivieren statt löschen, OP-CRUD-1/E-CRUD-1; Skill.aktiv-Soft-Delete existiert) → die Sicht schlägt vor (Propose-not-execute), löscht/archiviert nicht selbsttätig. True North: genauere, prozess-verankerte Eignung → bessere Taktung (Frage 1/3) + Selbsterklärbarkeit (Mitarbeiter-Sicht). Geklärt (durch A/B/C): verwaist-Anzeige im Skill-Katalog-Dialog (A) · Skill-Pflege im Prozess-Editor (B) · Priorisierung in der Mitarbeiter-Sicht (C); der Katalog bleibt Single Source (Aspekt 2 belässt die Skill-Quelle im Katalog, Pflege nur zusätzlich im Prozess-Kontext); bewusst reservierte Skills (skill-klaerung) bleiben unangetastet (nur als verwaist markiert, nicht entfernt). Offen bleibt nur die fachliche Einzelfall-Entscheidung, ob skill-ppf konsolidiert oder mit eigenem PPF-Teilschritt belegt wird (Stammdaten-Pflege, kein Feature). Bezug: OP-R3-3 (Skill-Anforderung je Teilschritt/Prozess-Editor), OP-R1-3 (Skill-Niveau/Ausbildungsziele), OP-CRUD-1 (Lebenszyklus/aktiv), OP-R3-1 (skill-klaerung/Klärfall), OP-R1-6 (Mitarbeiter-Sicht skalieren), G-1, S-2, §4.1 (Mitarbeiter/Qualifikation).
OP-R2-2 — Grafische Visualisierung der Buchten und Parkplätze mit Belegung (Hallen-/Hof-Layout statt Liste). (umgesetzt v1: Hallen-/Hofplan im Leitstand — Slots gruppiert in „Halle" (Arbeitsplätze/Buchten) und „Hof" (Parkplätze), je Tile mit Typ-Label, Kapazitäts-Zellen belegt/frei, Doppelbelegung rot, Drag&Drop zum Umparken + ✕ zum Entfernen.) Offen: maßstäbliches Layout/Positionen, Status „gesperrt", Anzeige der Parkplatz-Restriktion je Fahrzeug (z. B. nur Indoor).

11.8 KI-Layer (A-4)

OP-AI-1 — KI-Narrative für Erklärungen (Claude API). Das regelbasierte Vorschau-Narrativ (R8-G2) optional durch einen LLM-Text ersetzen/ergänzen, der Trade-offs in Klartext erklärt („#2026-007 rückt 4 Tage nach hinten, weil Keramik nur von einer Person abgedeckt wird; dafür wird die Gesamtauslastung …"). Auch für Konflikt-Wizards (§5.2.3), Kunden-Mails (UC-F), Überstunden-Begründungen (R9). Zu klären: Trigger (on-demand-Button vs. automatisch), Datenschutz/Datenminimierung (nur aggregierte Plandaten an die API), Kosten/Latenz, ANTHROPIC_API_KEY als Worker-Secret. NICHT als Scheduler (A-4: LLM garantiert keine harten Constraints).
OP-AI-2 — KI-Plausibilitätsprüfung von Doku (Bild & Text). Zu OP-R4-3: Hochgeladene Bilder werden automatisch bewertet, ob sie der geforderten Perspektive entsprechen und plausibel sind (z. B. Fahrzeugfarbe passt zum Auftrag/Fahrzeug); Abweichungen erscheinen als Warnung am Bild. Der Kommentar wird auf Plausibilität geprüft → Warnung am Text. Alle Befunde zusätzlich als Warnungs-Summary neben dem „Speichern"-Knopf. Zu klären: Vision-Modell/Provider, Schwellen, Datenschutz (Bilder an API), On-device vs. Cloud, Latenz, Falsch-Positiv-Handling (Warnung blockiert nicht, informiert).
OP-AI-3 — Spracheingabe, Mehrsprachigkeit & Text-Verbesserung je Textfeld. Jedes Textfeld bietet: (a) mehrsprachige Erfassung (Eingabe auch in anderen Sprachen möglich), (b) Mikrofon-Symbol für Diktat / Audio-Notizen mit kontextbezogener Transkription (kennt Auftrag/Schritt/Fachbegriffe), (c) Improve-Symbol für kontextbezogene Textverbesserung als Übernahme-Vorschlag (Nutzer entscheidet), (d) Übersetzer / Translator (06-28, Nutzer): Audio-Notizen werden — passend zur mehrsprachigen Belegschaft (inkl. Chinesisch/Ukrainisch, OP-I18N-1) — in der Muttersprache des Sprechers aufgenommen, transkribiert und automatisch in die Auftrags-/UI-Sprache (Default Deutsch) übersetzt (Original + Übersetzung erhalten). (e) Domänen-Anpassung an taktano (06-28, Nutzer): ASR und Übersetzung werden auf das taktano-Vokabular getrimmt — Werkstatt-/Domänenbegriffe (Auftrag, Teilschritt, Bucht, Folie, Güteklasse … aus dem Glossar) als Custom-Vocabulary/Prompt-Kontext, damit Fachwörter korrekt erkannt und konsistent (statt wörtlich) übersetzt werden. Zu klären: ASR-/Übersetzungs-/LLM-Provider (EU-Residenz/DSGVO), Sprach-Auswahl/-Erkennung, Offline-Fall, Kosten/Latenz, Domänen-Glossar als Quelle (Bezug Glossar/glossar.mjs), einheitliche Textfeld-Komponente (überall wiederverwendbar). Bezug: OP-I18N-1, OP-AI-2, OP-R4-3 (Doku-Pflicht).
OP-AI-5 — KI-gestützte Meeting-Minutes (Transkript → Zusammenfassung in taktano-Lingo) (06-28, Nutzer). Besprechungs-Protokolle (Struktur besteht bereits: docs/betrieb/meetings/, Everything-as-Code, Index + Vorlage) auch per KI/Spracherkennung erfassen: Audio/Transkript rein (ASR) → automatische Zusammenfassung, passend auf das taktano-Vokabular/Glossar („taktano lingo" — Werkstatt-Begriffe statt generischer Formulierungen). Ergebnis als .md-Protokoll (JJJJ-MM-TT-thema-slug.md), Beschlüsse zusätzlich am verbindlichen Ort spiegeln (HANDOFF/Lastenheft/CHANGELOG). Zu klären: ASR-/LLM-Provider (EU-Residenz/DSGVO), Domänen-Glossar als Prompt-Kontext (wie OP-AI-3 (e)), PII in Transkripten (Scrubbing), Speicherort der Roh-Audios, Halluzinations-/Korrektur-Schleife (Mensch bestätigt). Bezug: docs/betrieb/meetings/, OP-AI-3 (Transkription/Übersetzung/Domäne), OP-AI-4 (Assistent), Glossar (glossar.mjs), Selbsterklärbarkeit/„Dokumentation als Meisterwerk".
OP-FEEDBACK-1 — In-App-Feedback mit Screenshot-Markierung (06-28, Nutzer). Anwender sollen direkt in der App Feedback geben können — am besten mit Markierung auf einem Screenshot der aktuellen Ansicht. Frage des Nutzers: als Chatbot oder braucht es ein Plugin? Empfehlung (pyramidal): schlankes, eigenes Widget statt SaaS-Plugin — Begründung: (1) DSGVO/EU-Residenz (Screenshots können PII/Auftragsdaten zeigen) spricht gegen externe Feedback-SaaS (Marker.io/Userback/Jam/Sentry-User-Feedback); (2) die nötige Infrastruktur ist bereits da — R2 (jurisdiction=eu) für das Screenshot-Bild, D1/DO für den Eintrag, OTel/Audit für Kontext, der In-App-Assistent (OP-AI-4) als Dialog-Oberfläche. Skizze: globaler Feedback-Knopf (schwebend) → html2canvas-pro-Aufnahme der aktuellen Ansicht → Annotations-Overlay (zeichnen/markieren auf Canvas, nur --tk-*-Tokens) → Eintrag mit Auto-Kontext (Route/Workspace, App-Version+Build, trace_id, anonymisierter State-Auszug) → Speicherung (R2-Bild + D1-Eintrag) → Triage-Sicht (intern). Chatbot vs. Plugin: kein Drittanbieter-Plugin; der Chatbot-Weg ist optional als zusätzlicher Kanal sinnvoll (Feedback per Konversation über den bestehenden Assistenten, OP-AI-4), das Screenshot-Markup bleibt aber ein eigenes UI-Element. Zu klären: Foto-Annotation-Bibliothek vs. eigenes Canvas, PII-Scrubbing im State-Auszug, Berechtigung/Sichtbarkeit der Triage, Verhältnis zu OP-AI-4 (Assistent) und OP-AUDIT-1. Bezug: OP-AI-4, OP-R4-3 (Foto-Upload-Bausteine wiederverwenden), OP-OBS-1 (trace_id), Selbsterklärbarkeit/„Dokumentation als Meisterwerk". Teilentscheidung (07-01): eigenes Canvas (keine externe Annotation-Lib) — die R4-Bild-Schutz-Bausteine tragen das. GEBAUT (07-02, PR-A v0.43.0 + PR-B v0.44.0): (PR-A) der nummerierte Markierungs-Layer im wiederverwendbaren Bild-Schutz-Baustein (Markierung-Typ + reine Helfer + Komponenten-Modus „① Punkt markieren" + Einbrennen ins Bild + bildQuelle/ladeBlob-Eingang; s. Bildbewertung.md §7 Phase 1c). (PR-B) der Screenshot-Fluss: „📷 Screenshot aufnehmen" → Ziehen-Auswahl → html2canvas-pro (lazy; seit 07-02 der gepflegte Fork statt html2canvas — moderne CSS-Farbfunktionen color()/oklch, iPad/Safari-Fix) → Bild-Schutz (Verpixeln + Markierungen) → Upload /api/feedback/screenshot → EU-FOTOS-Bucket (feedback/<uuid>) → Access-gated Link + Markierungs-Liste am internen GitHub-Issue (feedbackZuIssue); dormant-sicher (kein FOTOS → Feedback als Text). S. In-App-Assistent.md §9 (Slice 10). ➡ vollständig. Offen: Kunden-Sichtbarkeit der Triage einschränken = OP-FEEDBACK-2; separate D1-Triage-Sicht (heute: GitHub-Issue) optional.
OP-ONBOARD-1 — In-App-Tutorials + sukzessive Feature-Freischaltung (06-28, Nutzer). Zwei verbundene Hebel fürs Onboarding (Zielgruppen Anwender + Customer Service):
1. Tutorials / geführtes Onboarding — kontextuelle, schrittweise Anleitungen direkt in der App für die Kern-Flows (Annahme → Vorbereitung → Produktion → Quality-Check → Abholung; Werker-Sicht; Planung/Optimierer). In Werkstatt-Sprache (Selbsterklärbarkeit), wiederverwendet was da ist: Glossar-Sprechblasen, Empty-State-CTAs (OP-UX-1), In-App-Assistent (OP-AI-4) als Erklär-/Q&A-Kanal. Formen zu klären: geführte Tour (Coachmarks) vs. kurze Videos/GIFs vs. Doku-Verweise (Doku-Site); „erledigt/übersprungen"-Status je Nutzer; Wiederaufruf über Hilfe-Menü.
2. Features sukzessive freischalten (progressive disclosure) — nicht jede Werkstatt/jeder Nutzer sieht von Tag 1 alle Workspaces (Optimierer-Szenarien, Kosten, Prozess-Editor … würden Einsteiger überfordern). Stufenweise Freischaltung nach Onboarding-Fortschritt / Rolle / Reifegrad — Kern zuerst (Tafel · Annahme · Meine Arbeit), Fortgeschrittenes später. Zu klären: Mechanik — Feature-Flags je Tenant (G-1, admin-konfigurierbar) und/oder je Rolle/Berechtigung (OP-AUTH-1) und/oder gekoppelt an Onboarding-Abschluss bzw. Akademie-Niveau (OP-R1-3); Default-Stufenplan; Override durch Admin; Verhältnis zu „Selbsterklärbarkeit" (Freischaltung darf Funktionen nicht verstecken, sondern gestaffelt einführen). Bezug: OP-UX-1 (Workspaces/Nav), OP-AI-4 (Assistent), OP-R1-3 (Akademie/Progression), OP-AUTH-1 (Rollen), G-1, docs/zielgruppen/Lesepfade.md, Leitprinzip Selbsterklärbarkeit/„Dokumentation als Meisterwerk".
OP-BACKOFFICE-1 — Backlog der Vorarbeiten für Back-Office / Vorgesetzte (06-28, Nutzer). Die Vorarbeiten/Vorbedingungen (OP-R3-4/OP-R3-2 — z. B. Teile/Material bestellen, Beschaffung, Freigaben einholen) müssen auftragsübergreifend als Backlog/Arbeitsliste für eine Back-Office-Rolle bzw. den Vorgesetzten sichtbar sein — damit nichts liegen bleibt und rechtzeitig veranlasst wird. Form: eigene Sicht analog zur Werker-Sicht „Meine Arbeit" (OP-UX-1/U2), aber für dispositive/nicht-produktive Aufgaben: je offener Vorbedingung Auftrag/Fahrzeug-Bezug · Typ (Bestellung/Freigabe …) · Status (offen→veranlasst/bestellt→eingetroffen/erfüllt) · Fälligkeit (benötigt-bis aus Vorlauf-/Lieferzeit) · Priorität (Termindruck). Aktionen setzen den Vorbedingungs-Status (OP-R3-4) und heben damit das Start-Gate auf. Reine Projektion aus den Vorbedingungs-Fakten (S-2, derived — nichts Neues gespeichert); dringlichkeits-/fälligkeits-sortiert. Beantwortet operativ „Was muss jetzt beschafft werden, damit Termine halten?". Zu klären: Rolle/Berechtigung Back-Office/Vorgesetzter (OP-AUTH-1), Benachrichtigung bei Fälligkeit, Verhältnis zur Mitarbeiter-Ansicht (OP-R9-4) und zum Klärfall-Prozess. Bezug: OP-R3-4 (Vorbedingungen, Datenquelle), OP-R3-2, OP-PHASE-1 (Vor-Produktion), OP-UX-1 (Rollen-Sichten), OP-R9-4, OP-AUTH-1, True North.
OP-DATE-1 — Konsistente, kontext-bewusste Datums-/Zeit-Darstellung (06-28, Nutzer). Problem: Termine werden teils nur als „Di 08:00 Uhr" gezeigt — mehrdeutig (welcher Dienstag?), ohne Datum/relativen Bezug. Heute gemischt: relative Logik („morgen 08:00" auf Karten) neben rohen toLocale*-Aufrufen (Shell-Uhr/-Datum, Gantt-Tooltips) — kein einheitlicher Stil. Gewünscht: generell Wochentag + Uhrzeit + Datum + relativer Bezug („heute", „morgen", „nächste Woche Dienstag"). Vorgeschlagener Ansatz (zu diskutieren): ein zentraler Formatter (Single-Source-Helfer, analog phase.ts für Phasen-Labels), der distanz-abhängig rendert:
- heute/morgen/übermorgen → relativ + Zeit („heute 08:00", „morgen 08:00").
- gleiche Woche → Wochentag + Zeit + Datum („Di, 08.07. · 08:00").
- nächste Woche → „nächste Woche Di, 08.07. · 08:00".
- weiter weg → volles Datum („08.07.2026 · 08:00").
- Vergangenheit analog („gestern", „vor 2 Tagen" + Datum).
- Immer disambiguieren: Datum mit anzeigen, sobald über „morgen/übermorgen" hinaus; Tooltip/title zeigt stets den vollen, absoluten Zeitstempel (Sekundengenauigkeit/ISO) für Präzision.
- Locale-aware (de-DE Default; weitere Sprachen via OP-I18N-1, inkl. Datums-/Wochentags-Format).
- Konsistenz: ein formatZeitpunkt(ts, { now, stil }) ersetzt die ad-hoc-toLocale*-Aufrufe und die bestehende „morgen 08:00"-Logik — überall verwendet (Karten, Gantt-Tooltips, Detail-Panel, Tafel, Annahme, Shell).
Zu klären (Diskussion): Schwellen (ab wann „nächste Woche" vs. volles Datum), Kurz- vs. Langform je Kontext (enge Chips vs. Detail-Panel), Umgang mit „diese Woche Mo, der schon vorbei ist", Zeitzone/Sommerzeit, Default-Granularität. Bezug: Selbsterklärbarkeit, OP-I18N-1 (Locale), client/.../leitstand.service.ts (relative Zeit heute), shell.component.ts (Uhr/Datum), gantt.component.ts (Tooltips).
OP-FIND-1 — Sonderwünsche: Häufigkeit + Auffindbarkeit (Synonyme/Nutzen) + Chatbot (06-28, Nutzer; Owner: Dominik & Julian). Fragen (fachliche Vorarbeit Dominik/Julian): Welche Sonderwünsche kommen häufig vor? → Erfassung + Häufigkeits-Auswertung (aus Aufträgen/Leistungen/Sonderwünschen). Auffindbarkeit: Leistungen/Sonderwünsche auch über Synonyme und über den Nutzen („ich will erreichen, dass …") finden — nicht nur über den exakten Fachbegriff (Selbsterklärbarkeit; ein Werkstatt-Begriff ≠ Kundenwort). Später: ein Chatbot macht die Begrifflichkeiten natürlichsprachlich zugänglich (OP-AI-4). Zu klären: Datenquelle/Erfassung der Sonderwünsche (frei vs. strukturiert — Bezug OP-R7-13 freie Aufträge, OP-R6-2 Besonderheiten, OP-R3-6 Hinweise), Synonym-/Nutzen-Index (Suche + Glossar, ggf. semantisch/Embeddings), Häufigkeits-Report. Owner: Dominik & Julian (fachliche Sammlung der häufigen Sonderwünsche als Input). Bezug: Glossar, OP-AI-4 (Chatbot), OP-R9-6 (Kapazitäts-/Leistungs-Vorschläge), OP-R3-6, OP-R6-2, OP-R7-13.

11.9 Material & Auswertung (R10)

OP-R10-1 — Strukturierte Materialerfassung & Auswertung. Marktbeobachtung: im Altsystem ist Materialverbrauch nur über selbst angelegte Protokolle abbildbar → keine vernünftige Auswertbarkeit. Klären: strukturierte Erfassung des Material-/Folienverbrauchs je Auftrag/Teilschritt (Menge, Charge, Verschnitt), Auswertungen (Verbrauch, Verschnittquote, Materialkosten je Leistung/Fahrzeug) und Anbindung an den Vorteilsrechner (Produkt-und-Marketing.md §3) sowie das Preismodell (OP-R7-6).

11.10 Tests & Qualitätssicherung (Technik)

Guideline (verbindlich): Alle automatischen Tests sind on demand ausführbar (Anleitung in README.md) und laufen in der CI/CD-Pipeline. Neue Tests werden beiden Wegen hinzugefügt. Aktuell: Server-Typecheck + Scheduler-/Operativ-/Solver-Demos + CP-SAT-model.py-Self-Tests + Client-Build laufen in der CI; ein echtes Test-Framework ist noch aufzubauen (OPs unten).

OP-TEST-1 — Automatische funktionale Tests (End-to-End/Fachlogik): Schlüssel-Workflows automatisiert prüfen (z. B. Auftrag anlegen → liefern → starten → fertigstellen → abholen; Konflikt-Hebel; Belegung/Umparken; Skill/Bucht-Constraints). Zu klären: Framework (z. B. Playwright gegen lokalen Worker, oder Server-Integrationstests gegen das DO), Testdaten/Seed, Ausführung lokal + CI.
OP-TEST-2 — Automatische Komponenten-/Unit-Tests: für Scheduler/Solver-Logik, Operativ-Modell (Transitions/Migrationen), Service-Computeds. Zu klären: Runner (z. B. Vitest/Jest für TS, pytest für solver-service), Coverage-Ziel, Platzierung neben dem Code.
OP-TEST-3 — Automatische UI-Tests: Cockpit-Räume/Interaktionen (Drag&Drop-Umparken, Dialoge, Routing, Badges) sowie visuelle Regression. Zu klären: Tooling (Playwright/Cypress, ggf. Screenshot-Diffs), Stabilität gegen Animationen, Ausführung in CI (headless).
OP-STAGE-1 — Mehrere Stages / Release-Stände (Umgebungen) (06-28, Nutzer). Heute gibt es nur Produktion (App-Worker app.taktano.com, solver-service.fly.dev, Docs taktano-docs; Auto-Deploy bei Push auf main, OP-DEPLOY-1/2). Ziel: getrennte Stages — z. B. dev/test → staging/preview → production — um Änderungen vor Prod gefahrlos zu prüfen (Preview je Branch/PR) und Releases kontrolliert zu promoten. Bausteine: Cloudflare Worker-Environments ([env.staging] in wrangler.toml) mit je eigenem DO-Namespace/D1/R2 + eigenem Access je Stage; Fly separate App je Stage (solver-service-staging); Docs-Preview (Pages-Preview gibt es bereits via *.pages.dev); Promotion-Flow (z. B. develop→staging, main→prod) + Cloudflare Versions/Gradual Deployments (schrittweiser Rollout/Canary). Release-Stände: SemVer + auto-Build (OP-PM-2) bestehen; ergänzbar um Channels (canary/stable) — komplementär zur Feature-Freischaltung (OP-ONBOARD-1). ⚠ Flagging (DSGVO): Non-Prod-Stages dürfen keine echten Prod-/Tenant-Daten (PII) tragen → synthetischer Seed in dev/staging, strikte Datentrennung (Bezug Mandantenfähigkeit OP-TENANT, Seed OP-SEED-1). Zu klären: Anzahl/Schnitt der Stages, Secrets-/Access-Verwaltung je Stage, CI-Matrix + Promotion-Gates, Kosten (mehr Umgebungen), IaC (Terraform für Access/Pages, §10). Bezug: OP-DEPLOY-1/2, OP-PM-2, OP-ONBOARD-1, OP-TENANT, OP-SEED-1, OP-OBS-1.

OP-DOCS-11 — OP-Verwaltung: Single Source + Query-Views (06-28, Nutzer; ✅ entschieden + v1 umgesetzt 07-11). Problem (vom Nutzer benannt): OPs liegen heute redundant über Lastenheft §11 · HANDOFF §4 · Roadmap.md · Timesheet · CHANGELOG → Inkonsistenz-Risiko (heute nur manuell via OP-DOCS-9 + ID-Index gehütet). Frage: OPs als GitHub Issues (oder etwas anderes Passendes) führen und per Query in der Doku anzeigen, um Drift zu vermeiden — sinnvoll? Optionen (knapp):
- (A) Status quo — Markdown-Listen je Dokument. Pro: in-Repo, versioniert, offline, Docusaurus-gerendert. Con: keine native Status/Assignee/Query, Duplizierung über mehrere Dateien (Drift), manuelle Pflege.
- (B) GitHub Issues als Quelle + Query-Rendering in der Doku (API/Action → generierter Index; Labels=Area, Milestones=Roadmap, Assignees). Pro: native Status/Assignee/Query/PR-Verknüpfung/Notifications. Con: Quelle der Wahrheit verlässt das Repo (widerspricht „Everything-as-Code: Entscheidungen als .md-Commit"), Offline/Portabilität/Tenant-Sichtbarkeit, Sync-Tooling nötig.
- (C) Hybrid — ein Markdown-File je OP (docs/op/OP-….md mit Frontmatter id/status/area/owner/prio/bezug) als In-Repo-Single-Source → generierte Sichten (Index nach Area, Roadmap nach Dringlichkeit, nach Owner) via Build-Skript analog gen-glossar.mjs + CI-Staleness-Gate; HANDOFF §4 / Lastenheft §11 / Roadmap werden generierte Views (kein Doppelpflegen). Optional Einbahn-Spiegel zu GitHub Issues für Workflow (Assignee/Notifications/PR-Link). Pro: bewahrt Everything-as-Code, beendet die Duplizierung, Query/Filter wie das Glossar, automatisiert einen Teil von OP-DOCS-9. Con: Generator + Migration der Bestands-OPs.
- (D) In-Doc-Feedback (Giscus o. ä.) = anderes Thema (Leser-Feedback an der Doku), kein OP-Tracking.
Entschieden + v1 umgesetzt (07-11): (C) Hybrid, weil es die Inkonsistenz an der Wurzel löst (eine Quelle statt fünf) ohne das Repo-als-Wahrheit-Prinzip aufzugeben — verschärft durch eine zweite Anforderung desselben Tages: Stakeholder sollen offene Punkte diskutieren/priorisieren können, ohne Git/GitHub lernen zu müssen, und Claude Code/Codex sollen sauber damit arbeiten (umsetzen, abhaken). GitBook (reines Doku-Rendering, kein Status/Board/Diskussions-Modell → dritte Quelle) und ein separates SaaS wie Linear (neuer Vendor/Kosten/Sync-Aufwand) wurden dafür verworfen. Umgesetzt: ops/<ID>.md (Frontmatter id/title/status/prio/bereich/bezug/detail) als Quelle → scripts/gen-ops.mjs generiert docs/betrieb/Offene-Punkte.md → scripts/sync-ops-issues.mjs + .github/workflows/sync-ops.yml spiegeln einseitig nach GitHub Issues (Label op-sync) für die Stakeholder-Diskussion (optional darüber ein GitHub-Projects-Board). Pilot: ops/OP-DOCS-11.md + ops/OP-VERTRIEB-1/-2/-3.md. Migration der ~150 Bestands-OPs bewusst nicht Teil dieses Schritts — neue OPs entstehen ab sofort hier, bestehende wandern schrittweise bei Berührung. Als wiederverwendbares Muster für andere drkv-Projekte dokumentiert: docs/konventionen/OP-Management-Gold-Standard.md. Bezug: Everything-as-Code (CLAUDE.md), OP-DOCS-9 (Konsistenz), OP-PM-2 (Log-Hygiene), OP-PM-3 (Roadmap), docs/konventionen/IDs.md, docs-site/scripts/gen-glossar.mjs (Generator-Muster).

12. Future-Module und Future-Releases

12.1 Future-Module

FM-1 Zweigstellen — explizite Multi-Branch-Unterstützung. Kunde, Mitarbeiter, Arbeitsplatz, Auftrag können einer Zweigstelle zugeordnet sein. Sichtbarkeit/Zuständigkeit darüber steuerbar. Cross-Branch-Workflows (Fahrzeug bewegt sich zwischen Zweigstellen) zu klären.

12.2 Future-Releases

FR-1 Fahrzeug-Besitzerhistorie — Cars können den Besitzer wechseln. v1 hält nur den aktuellen Besitzer; spätere Version führt Eigentumshistorie ein.
FR-2 Inline Kunde-Anlage aus dem Auftrag — in v1 nicht enthalten, später möglich.

13. Glossar → zentrales Glossar

Begriffe werden zentral gepflegt: docs/glossar/Glossar.md (generiert aus der Single Source docs-site/src/glossar/glossar.mjs, OP-DOCS-10 — speist auch die Begriffs-Sprechblasen der Doku-Site). Die frühere Tabelle hier war ein zweites, driftendes Glossar (Doku-Review 2026-07, Befund D7): Sie definierte u. a. „Helfer" als „anderer geforderter Skill" (widersprach §6.4: Helfer = nicht-planungsrelevante Auszubildende) und „Standort (Fahrzeug)" als „abgeleitet aus laufendem Teilschritt" (widersprach §4.3: physische Ist-Belegung) — daher 07-12 eingedampft. Neue Fachbegriffe → glossar.mjs ergänzen (npm run glossar), nicht hier.

↩ Zurück zur Doku-Landkarte · Lesepfade · Register (alle OPs)

Inhalt​

1. Einleitung​

1.1 Zweck​

1.2 Abgrenzung​

1.3 Identifikator-Schema​

2. Kern-Use-Cases​

3. Globale Prinzipien​

G-1 — Admin-editierbare Taxonomien​

G-2 — Wechsel-Pönale Mitarbeiter​

G-3 — Minimum Auto-Scheduling-Fenster​

G-4 — Kontextwechsel-Minimierung bei der Aufgaben-Platzierung (außer QS: Vier-Augen)​

4. Stammdaten und Master-Entitäten​

4.0 Datenmodell-Überblick (vereinfacht)​

4.1 Skill / Qualifikation (neu, first-class)​

4.2 Mitarbeiter (R1)​

4.3 Arbeitsplätze / Räume (R2)​

4.4 Schicht-Katalog (neu)​

4.4a Abwesenheiten & Soft-Blocks (R1-S3)​

4.5 Leistungen (R3a)​

4.6 Teilschritte (R3b)​

4.7 Formulare und Protokolle (R4)​

4.7.1 Formular (Vorlage)​

4.7.2 Feldtypen (systemfester Katalog, logik-tragend)​

4.7.3 Protokoll (ausgefülltes Formular)​

4.8 Kunden (R5)​

4.9 Fahrzeuge (R6)​

4.9.1 Mangel (Zustandsdokumentation)​

4.10 Attachment / Dokument (S-10)​

5. Operative Entitäten​

5.1 Auftrag (R7)​

Lifecycle (S-6) — drei Phasen: Anlieferung · Produktion · Abholung​

Standard-Prozess (immer) & Klärfälle​

Fortschritts-Indikator (R7-P1)​

5.2 Planung (R8)​

5.2.1 Tages-/Wochen-/Monatsansicht (Gantt)​

5.2.2 Angebotsmodus​

5.2.3 Planungs-Konflikte​

5.3 Dashboard / Leitstand (R9)​

5.3.1 Dashboard (Überblick)​

5.3.2 Leitstand (Live-Steuerung)​

6. Scheduler-Verhalten​

6.1 Harte Constraints​

6.2 Weiche Ziele (Optimierungsfunktion)​

6.3 Reservierungsmodi​

6.4 Mehrere Personen je Schritt (vormals „Helfer")​

6.4.1 Ausbildung als Helfer-Leistung (implementiert v1)​

6.5 Leistungsnachweis, Mitarbeiter-Statistik & Erfahrung (implementiert v1)​

7. Querschnittsfunktionen​

7.1 Vorlagen-Bibliothek (einheitliches Pattern für Leistungen und Formulare, S-8)​

7.2 Mitarbeiter-Login​

7.3 Zwei UI-Modi​

7.4 Kunden-Self-Service-Link​

7.5 Audit / Chronik​

7.6 Validierung​

7.7 Single-Source-of-Truth für Derived State​

8. Nicht-funktionale Anforderungen​

9. Architektur-Empfehlungen​

A-1 — Dreischichtiger Ansatz​

A-2 — Workflow-/State-Machine-Layer für Lifecycle​

A-3 — Constraint Solver für Scheduling​

A-4 — KI-Layer für unscharfe Aufgaben​

A-5 — Pragma-Stack für v1​

10. Vereinfachungen gegenüber Altsystem​

11. Offene Punkte (zu klären)​

11.1 Aufträge​

11.2 Planung​

11.3 Leitstand​

11.4 Formulare & Protokolle (R4)​

11.5 Auth & Mandanten​

11.6 Vermarktung​

11.7 Arbeitsplätze & Produktion (R2/R3)​

11.8 KI-Layer (A-4)​

11.9 Material & Auswertung (R10)​

11.10 Tests & Qualitätssicherung (Technik)​

12. Future-Module und Future-Releases​

12.1 Future-Module​

12.2 Future-Releases​

13. Glossar → zentrales Glossar​