Taktano — Sanity-Checkliste (North Star)
Zweck. Diese Liste ist der Realitäts-Check für Produkt & Code: Beantwortet Taktano die zentralen Fragen einer Werkstatt jederzeit, schnell und korrekt? Jedes Feature, jeder Raum, jedes Dokument wird daran gemessen. Pflegen: bei jeder größeren Änderung den Status unten aktualisieren (✅/🟡/⛔) und Lücken benennen.
Die Top‑3-Leitfragen (immer beantwortbar)
- Wie hoch ist die Auslastung?
- Wo stehen die Fahrzeuge? — sowohl physisch (Bucht/Parkplatz) als auch in der Bearbeitung (welcher Prozess-Schritt).
- Wann sind die nächsten freien Kapazitäten?
Jede neue Funktion sollte mindestens eine dieser Fragen direkter, schneller oder genauer beantworten — sonst kritisch hinterfragen.
Status & wo beantwortet (lebend)
| # | Frage | Wo im Produkt | Status | Lücken / nächste Schritte |
|---|---|---|---|---|
| 1 | Auslastung | Gantt (MA- & Bucht-Zeilen, §5.2.1) · Auslastungs-Quote-Kachel (Überblick-Sidebar: % verplante vs. verfügbare Bucht-/MA-Zeit über den Planungszeitraum, insights.auslastungsQuote) · Engpass-Faktor (§5.3.1) | 🟡 | Zeitbasierte Quote gebaut (v0.70.0) — offen: wählbarer Zeitraum (heute/Woche) statt fixem Planungsfenster · Historien-/Trend-Sicht · Engpass-Faktor (OP-R9-2) ausbauen. |
| 2 | Wo stehen die Fahrzeuge? | Physisch: Belegung/Hallenplan + 📍Standort am Auftrag (§4.3) · Bearbeitung: Aufträge-Raum (Fortschritts-Timeline) + Teilschritt-Status (§5.1) | 🟡 | „Standort unbekannt" auflösen (OP-R2-1 Auto-Erkennung/Check-in); maßstäblicher Hofplan (OP-R2-2 Ausbau). „In der Bearbeitung" ist heute unscharf (Analyse Flow-Analyse.md, 06-24): fachliche Phase wird heuristisch aus dem Lifecycle-Status erraten (Aufbereitung↔Produktion fragil), Anlieferung≠Annahme kollabiert auf einen Status → Zielbild „Phasen first-class" (OP-R3-1). |
| 3 | Nächste freie Kapazitäten? | Kapazitäts-Kachel (Überblick-Sidebar, v0.73.0: „ab wann wieder Platz für Leistung X?" je aktiver Leistung, insights.kapazitaet) · Angebotsmodus (Feasibility, §5.2.2) · Reserve-Indikator je Auftrag (§11.1) · „Nächste Aufgaben" je Mitarbeiter/Arbeitsplatz mit „frei ab"/„jetzt frei" (Planung, OP-OPT-9, v0.59.0) | ✅ | Antwort ist jetzt prominent im Cockpit. Ausbau: proaktive Kapazitäts-Angebote an Kunden (OP-R9-6) · Kachel-Klick → vorbefüllte Annahme. |
Legende: ✅ beantwortet · 🟡 teilweise · ⛔ offen.
Externe Bestätigung (07-11): Das UX-/Prozess-Review 2026-07 (Befund B3) stützt die drei 🟡-Bewertungen unabhängig — die Antworten existieren, sind aber verstreut statt auf einen Blick; priorisierte Gegenmaßnahmen dort (E4 → OP-R9-10).
Anwendung
- Review/PR: Trägt die Änderung zu Frage 1–3 bei? Falls nein: bewusst begründen.
- Doku: Lastenheft §1.2 referenziert diese Liste; neue Räume/OPs hier einordnen.
- Dashboards (OP-R9-10): Das Standard-„Werkstatt-Übersicht"-Dashboard sollte die Top‑3 auf einen Blick zeigen.
Security-/Setup-Sanity (wöchentlich, automatisch) — OP-SEC-1/OP-SBOM-1/RISK-4
Zweck. Zweiter Realitäts-Check — diesmal technisch: „Ist alles gesetzt?" Läuft wöchentlich automatisch (Montags, GitHub-Actions-Workflow
weekly-audit.yml; zusätzlich jederzeit per Run workflow manuell auslösbar) und ergänzt den push/PR-Gatesecurity-audit(ci.yml) um die Zeit-Achse — fängt neu bekannt gewordene Advisories auf unveränderten Dependencies, ohne dass ein Commit nötig ist.
Was geprüft wird:
| Prüfung | Mechanik | Verhalten |
|---|---|---|
| Vuln-Audit Produktiv-Deps (Server/Client) | npm audit --omit=dev --audit-level=high | blockierend (Lauf rot bei High/Critical) |
| Vuln-Audit Solver | pip-audit -r requirements.txt | blockierend |
| Vuln-Audit voll inkl. Dev-Toolchain | npm audit (Server/Client) | informativ (nicht-blockierend) |
| Setup-Sanity „ist alles gesetzt?" | scripts/check-security-setup.sh | warnt, blockt nicht (Report in die Step-Summary) |
check-security-setup.sh flaggt, wenn eine Kontrolle fehlt: Dependabot-Config · CI-Jobs
security-audit + sbom · gepinnte Actions (kein @main/@master/@latest) · und — best effort via gh —
die Repo-Settings allow_auto_merge, delete_branch_on_merge und Code-Scanning-Status
(CodeQL läuft über GitHub Default Setup → kein eigener Workflow erwartet). Lokal aufrufbar
(Repo-Settings werden ohne gh/Token übersprungen).
Nicht per MCP/Skript prüfbare Checks (Token ohne Admin-Scope / kein MCP-Tool) sind Agenten-Pflicht — verbindliche Liste + Vorgehen:
docs/konventionen/agents.md§6.7 (Repo-Settings, Code-Scanning-Modus, Branch-Protection bei Session-Start/vor PR verifizieren).
Status der Kontrollen (Stand 06-27):
- ✅ CodeQL aktiv via GitHub Default Setup (TS+Python automatisch, PR/Push; kein eigener Workflow).
- ✅ Squash-only · ✅
allow_auto_merge· ✅delete_branch_on_merge(OP-PM-2). - 🟡 Offen:
superfly/flyctl-actions/setup-flyctl@masterungepinnt (Tag/SHA pinnen); verwaiste Alt-Branches (vor Auto-Delete gemergt) manuell aufräumen; ESLint+ruff/mypy als Lint-Ergänzung.
↩ Zurück zur Doku-Landkarte · Lesepfade · Register (alle OPs)