Taktano — Design-Entscheidungen (Decision Log)
Kernaussage. Dieses Dokument hält das WARUM hinter dem Redesign „Flusslinie / Modernist" (OP-REDESIGN-1) fest — als ADR-Stil-Decision-Log (ein Eintrag je Entscheidung,
DD-NNN). Es stammt aus dem Claude-Design-Handoff („Taktano — Flusslinie") und ist die verbindliche Begründungsquelle; die fachliche Wahrheit bleibtLastenheft.md, der verbindliche Design-Vertrag istdesign/CLAUDE.md.Zielgruppe: IT-Dev/Architektur & Product Owner — „warum sieht/verhält sich das so?".
Regeln: Neueste unten anfügen, bestehende Einträge nie umschreiben — Revisionen als neuer Eintrag mit
ersetzt DD-NNN. DieScreenshots:-Zeile je Eintrag verweist auf die Referenzbilder unterdesign/prototype/flusslinie/screenshots/(NN-screen.png); der komplette klickbare Prototyp liegt daneben (design/prototype/flusslinie/Taktano Neu v2 - Flusslinie.dc.html, im Browser öffnen), das verbindliche Wording indesign/prototype/flusslinie/Taktano Wording.md. Bei Arbeit an Doku/Implementierung: betroffene DD-Einträge lesen und referenzieren (z. B. „gemäß DD-003").
DD-001 · Vier Orte statt zwölf Workspaces
Status: beschlossen (07/2026) · Betrifft: Shell, Navigation, IA Kontext: Rail mit 12 Workspaces in 3 Gruppen; UX-Review: unklarer Einstieg, wirkt unfertig. Entscheidung: Genau vier Orte — Lage · Fluss · Takt · Team. Seltene Funktionen (Leistungen, Team & Skills, Schichten, Buchten, Kosten, Chronik, System) gebündelt unter Verwaltung hinter einem einzigen ⋯-Menü. Begründung: Jeder Ort beantwortet eine True-North-Frage; tägliche Loop-Arbeit braucht keine Konfigurationsflächen im Sichtfeld. Verworfen: 12er-Rail beibehalten und nur gruppieren; Werker-Modus als Rail-Filter (ersetzt durch eigene Welt, s. DD-004). Code-Impact: shell.component.ts (Rail → 4 Items + ⋯), Routing, Badges konsolidieren. Screenshots: 01 (Lage) · 07 (Fluss) · 12 (Takt) · 15 (Team) · 16 (Verwaltung)
DD-002 · Flusslinie als Rückgrat
Status: beschlossen · Betrifft: Fluss (Hauptansicht), Auftragsmodell Kontext: Drei konkurrierende Flüsse (8-Status-Lifecycle / 5 fachliche Phasen / UI-Band) machten Fortschritt unlesbar. Entscheidung: Fortschritt = Position auf einer fünfstationigen Linie: Annahme → Aufbereitung → Produktion → QS → Abholung. Die Linie ist die zentrale Steuerungsansicht. Begründung: Physische Werkstatt-Metapher; ein Blick beantwortet „wo steht was". Verworfen: Pipeline-Spalten (v3), Kanban pro Lifecycle-Status. Code-Impact: Phase wird primäre Anzeige-Achse; Lifecycle nur noch Zustand am Auftrag (DD-003). Screenshots: 07 (Linie + Entscheiden) · 08 (Karte) · 09 (Auftrag-Detail, Stationen-Strip)
DD-003 · Lifecycle als Form, Rot nur für Störung
Status: beschlossen · Betrifft: alle Status-Darstellungen, tokens Kontext: Alt: 9 Statusfarben + 5 Phasenfarben + Terminfarben — Farbe war überladen, nichts stach heraus. Entscheidung: Lifecycle monochrom als Form: ■ läuft · ◪ pausiert · □ wartet · ☐ bereit. Farbe (Akzentrot) ausschließlich für Probleme: Klärfall, Terminrisiko, Notfall. Begründung: Rot behält Signalwert; Modernist-System ist monochrom + ein Akzent. Verworfen: Farbrampen pro Status (Alt-System tokens.css). Code-Impact: Status-Farbmap in tokens/labels.ts ersetzen durch Form-Glyphen + eine Warnfarbe. Screenshots: 07 (Legende ■◪□☐) · 09 (Marken am Arbeitsschritt) · 12 (Gantt-Blöcke)
Taktano-lokale Abweichung (dokumentiert, PO 07-23 / OP-REDESIGN-1): In Taktano ist Rot (
#ec3013) Primär-/Markenfarbe UND Warnfarbe — der Modernist-Brief („Rot nur für Störung") wird bewusst erweitert. Konsequenz: Warnungen tragen zusätzlich ein nicht-rein-farbliches Signal (Icon/Label/Rahmen/Blink). Die drkv-Default-Regel „Rot nur für Warnung" gilt in den Schwester-Repos (MED-/SERA-) unverändert. Siehe Root-CLAUDE.md§ Design-Prinzipien.
DD-004 · Zwei getrennte Welten: Disponent vs. Werker
Status: beschlossen · Betrifft: Rollen, Einstieg, Terminal Kontext: UX-Review B1: Rollen fehlen — größte Lücke. Werker-Modus war nur ein Rail-Filter. Entscheidung: Disponent bekommt Lage/Fluss/Takt/Team; Werker bekommt ein eigenes Terminal (Tablet, fette Buttons ≥44px, Aufgaben-Queue, Doku-/Foto-Upload mit Blur & Markup, Notfall-Button 🚨). Kein geteiltes Layout. Begründung: Werker-Flow = „nächste Aufgabe, null Nachdenken"; Disponenten-Loop = morgens prüfen → steuern → abends schließen. Verworfen: Ein Layout mit Rollen-Toggle. Code-Impact: Eigene Terminal-Route/Shell; Geräte-Setting statt Auth bleibt vorerst. Screenshots: 20–22 (Terminal, Doku-Modal) vs. 01/07 (Disponent)
DD-005 · Zeithorizonte: Heute vs. Review
Status: beschlossen · Betrifft: Lage, Reporting Kontext: Tagesgeschäft und Trends konkurrierten um dieselben Flächen. Entscheidung: Heute = operativer Loop (Lage/Fluss/Takt/Team). Woche/Monat = Review-Ansicht: Trends, Skill-Fortschritt (n/10), Root-Cause der Klärfälle, Team-Ziele. Begründung: True-North-KPIs brauchen beide Zeitskalen, aber nie gleichzeitig. Verworfen: Dashboard mit umschaltbaren KPI-Kacheln überall. Code-Impact: Review als eigener Zustand von Lage, nicht als eigener Workspace. Screenshots: 01 (Heute) · 02 (Review Woche)
DD-006 · Wording: Leistung / Ablauf / Arbeitsschritt
Status: beschlossen · Betrifft: labels.ts, alle Copy, Datenmodell-Benennung
Kontext: Begriffe (Prozess, Teilschritt, Vorlage …) inkonsistent über UI und Code.
Entscheidung: Leistung = was der Kunde bucht · Ablauf = geordnete Schrittfolge einer Leistung · Arbeitsschritt = Einheit mit Skill-Anforderung, Doku-Flag, Parallel-Flag. Skill-Fortschritt zählt „begleitete Schritte". Vollglossar: design/prototype/flusslinie/Taktano Wording.md.
Begründung: Eine Sprache in UI, Doku und Code verhindert Drift.
Verworfen: „Prozess/Prozessvorlage" (zu technisch), „Task" (englisch).
Code-Impact: labels.ts + Entity-Namen angleichen; Glossar in Doku übernehmen.
Screenshots: 16–17 (Leistung Editor mit Ablauf/Arbeitsschritten) · 18 (Kann-was-Matrix)
DD-007 · Visuelles System: Modernist statt Dark-Mission-Control
Status: beschlossen · Betrifft: gesamtes Theming Kontext: Alt: dunkles Glass-Panel-Theme, Space Grotesk/JetBrains Mono, Radien 9–22px, 14 Statusfarben. Entscheidung: Modernist: Archivo, heller Grund, 0 Radius, 2px-Kanten, sichtbares Raster, Labels linksbündig (auch in Buttons), Fotos schwarzweiß, ein Akzentrot. Begründung: Flache, architektonische Ruhe unterstützt DD-003 (Form statt Farbe); weniger visuelle Konkurrenz zum Inhalt. Verworfen: Light-Variante des Alt-Themes. Code-Impact: tokens.css ersetzen; Radien/Farb-Variablen entfallen ersatzlos. Screenshots: alle; exemplarisch 01 · 07 · 20
Taktano-Umsetzung: Der Modernist-Token-Layer ist gebaut (Phase 1,
design/tokens/tokens.jsonLIGHT-first + Dark-Mode mitgeneriert). Taktano behält bewusst den Dark-Mode (OP-R9-9) — abweichend vom „Light-only"-Brief —, beide Themes aus einer Token-Quelle.
DD-008 · Achsentrennung: Phase = Position, Lifecycle = Zustand
Status: beschlossen · Betrifft: Datenmodell-Interpretation, jede Auftragsdarstellung Kontext: Flow-Analyse: Lifecycle (8 Status) und fachliche Phase (5) wurden vermischt dargestellt. Entscheidung: Die zwei Achsen bleiben im Modell getrennt und werden getrennt visualisiert: Phase als Position auf der Flusslinie (DD-002), Lifecycle als Form-Glyph am Auftrag (DD-003). Keine UI-Fläche mischt beide Achsen in einer Skala. Begründung: Kern der Redesign-Arbeit; beendet die drei konkurrierenden Flüsse. Verworfen: Kombinierte Status×Phase-Matrix als Board. Code-Impact: Anzeige-Logik strikt aus zwei Feldern ableiten, nie aus einem synthetischen Kombi-Status. Screenshots: 07 (Position auf Linie) · 09 (Lifecycle-Glyph je Schritt)
↩ Zurück zur Doku-Landkarte · Lesepfade · Register (alle OPs)