Taktano — Arbeitsanweisung (Kurzfassung; Tiefe siehe Tiefenquellen unten)

Taktano (technisch taktano, vormals Codename folie2000) — Werkstatt-Betriebssystem für Fahrzeug-Veredelungsbetriebe (Folie, Lack, Detailing, Keramik …). Herz des Systems ist die Taktung/Reihenfolge-Optimierung (Scheduler + CP-SAT). Dies ist die gebündelte Leitplanke; Details stehen in den verlinkten Dokumenten.

True North — diese 3 Fragen jederzeit/schnell/korrekt beantworten

1. Wie hoch ist die Auslastung?
2. Wo stehen die Fahrzeuge? (physisch und in der Bearbeitung)
3. Wann sind die nächsten freien Kapazitäten?

Regel: Jedes Feature/PR/Doc muss ≥1 dieser Fragen direkter, schneller oder genauer beantworten — sonst kritisch hinterfragen. Lebende Prüfliste mit Status: docs/betrieb/Sanity-Checkliste.md. Und: jedes Doc ist zielgruppen-gerecht, pyramidal und — wo es trägt — visuell aufbereitet (s. Dokumentation als Meisterwerk).

Leitprinzip: Einfachheit (geringste Komplexität)

Immer die einfachste tragfähige Lösung wählen — in Code, Technik, UI und UX. Komplexität ist ein Kostenfaktor (Wartung, Onboarding, Fehlerfläche, Bündelgröße), kein Qualitätsmerkmal. Konkret: Code — kleinste sinnvolle Änderung, bestehende Funktionen/Muster wiederverwenden statt neu erfinden, reine/testbare Kerne, keine spekulative Abstraktion (YAGNI), keine ungefragten Refactorings. Technik — vorhandene Bausteine (R2/D1/DO/OTel …) nutzen statt neuer Abhängigkeiten/Dienste; eine neue Lib/ein neues System muss seinen Aufwand klar rechtfertigen. UI/UX — wenige, klare Schritte; sprechende Defaults; nichts, was die drei True-North-Fragen nicht direkter/schneller/genauer beantwortet. Regel: Steht eine einfachere Variante mit gleichem Nutzen zur Wahl, ist sie die richtige — sonst begründen. (Verwandt: S-n Vereinfachungen, YAGNI, Selbsterklärbarkeit.)

Leitprinzip: Selbsterklärbarkeit

Sprechende, eindeutige Begriffe aus der Werkstatt-Praxis statt technischer/abstrakter Labels — in UI und Doku. Beispiel: Status „Fahrzeug angeliefert“ (Key angeliefert) statt „Reserviert“.

Leitprinzip: Dokumentation als Meisterwerk (zielgruppen-gerecht · pyramidal · visuell)

Doku ist Produkt, nicht Beiwerk — klar, knapp, korrekt und für jede Zielgruppe in deren Sprache. Dies ist Teil des North Star: gute Doku ist kein Nice-to-have, sondern Liefergegenstand jedes PR. Verbindlich:

• Pyramidal (Minto): zuerst die Kernaussage/Antwort, dann die tragenden Gründe, dann die Details. Wer nach dem ersten Absatz aufhört, hat trotzdem das Wesentliche — kein Spannungsbogen, kein „Detail zuerst“.
• Zielgruppen-gerecht: geschrieben für eine klar benannte Rolle, in deren Begriffen und Tiefe — die sieben Leserkreise: Anwender (Werkstatt-Team) · Business/Management (nicht-IT: Nutzen/Wirtschaftlichkeit) · IT-Dev/Architektur · IT-Ops · DevOps (CI/CD · Deploy · IaC) · CISO/Security (Compliance/Risiko/Audit, DE/AT/CH) · Customer Service (Support/Onboarding/FAQ). Einstieg & kuratierte Lesepfade: docs/zielgruppen/Lesepfade.md.
• Visuell, wo es trägt: ein Diagramm spart oft drei Absätze — Mermaid (Flow/Sequence/State/Gantt/ER), Tabellen für Vergleiche, Beispiele für Konkretes. Bilder erklären, nicht schmücken; Everything-as-Code (Markdown + Mermaid, keine Binär-Master, kein Hardcoded-Hex — vgl. Design-Prinzipien).
• Selbsterklärbar & konsistent: sprechende Begriffe (s. o.), Glossar-Verweise, widerspruchsfrei zum Code (OP-DOCS-9). Regel: Jedes Doc beantwortet ≥1 True-North-Frage und ist für mindestens eine benannte Zielgruppe pyramidal + (wo hilfreich) visuell aufbereitet — sonst kritisch hinterfragen.
• Way-of-Working sichtbar in der Doku (verbindlich, drkv-Standard): docs/konventionen/Entwicklungsansatz.md zeigt den Ansatz (True North · Leitprinzipien · Way-of-Working) an einer Stelle — Einstieg für „wie entwickeln wir hier?“, je PR aktuell halten. CLAUDE.md bleibt verbindlich.

Standard-Bausteine (drkv) — Taktano ist Referenz-Implementierung

Der bewirtschaftete drkv-Standard-Tech-Stack lebt kanonisch im Template (everything-as-code-template/docs/Standard-Tech-Stack.md, Single Source G-2); Taktano ist dessen Referenz. Die vier Default-Eigenschaften sind hier gebaut: Echtzeit (DO-Live-State + WebSocket- Broadcast) · moderne Frameworks (Angular 22 u. a.) · In-App-Chatbot (LLM + RAG auf Live-Daten und Doku, vorschlagend, dormant — docs/architektur/In-App-Assistent.md) · Feedback (im Kontext sammeln

• in App und Doku anzeigen). Neue drkv-Produkte starten mit diesen Bausteinen als Default (Abweichung begründen).

Instruktions-Scoping (Nested CLAUDE.md — Konsistenz über Subsystem-Grenzen)

Taktano trägt mit client/ (Angular), server/ (Cloudflare Worker/TS) und solver-service/ (Python/ CP-SAT) den heterogensten Stack der vier Schwester-Repos — der Referenzfall für diese Regel. Wächst ein Repo mehrere eigenständige Tech-Stacks in Unterverzeichnissen, darf jeder Stack ein eigenes, nested CLAUDE.md bekommen — damit nicht jede Session stack-fremde Details mitladen muss. Diese Aufteilung folgt repo-weit demselben Muster, damit die vier Repos trotz unabhängiger Weiterentwicklung vergleichbar bleiben:

• Root-CLAUDE.md bleibt die einzige Stelle für stack-unabhängige, repo-weite Governance: True North, Leitprinzipien (G-n), ID-System, Compliance/Golden Rules, Repo-Konventionen (Decision-Log/ CHANGELOG/Branching), Versionierung. Diese gelten immer — sie werden nie in ein nested CLAUDE.md verschoben oder dort dupliziert.
• Nested CLAUDE.md ist ausschließlich für stack-lokale Details reserviert: Build-/Test-/Lint- Befehle, Sprach-/Framework-Idiome, Datei-Konventionen, die nur beim Arbeiten in genau diesem Verzeichnis relevant sind. Ein Unterverzeichnis bekommt eins, sobald es einen eigenständigen Tech-Stack trägt (andere Sprache/Runtime/Build-Tool als der Rest) — nicht als Standard-Gliederung für jedes Verzeichnis.
• Festes Skelett (verbindlich, damit nested Files über Repos hinweg gleich aussehen):

  # <Subsystem> — <Repo> (Stack-Detail; Governance siehe Root-`CLAUDE.md`)
  **Stack:** <Sprache/Runtime/Framework>
  **Build:** <Befehl> · **Test:** <Befehl> · **Lint/Typecheck:** <Befehl>
  
  ## Konventionen
  - <stack-spezifische Regeln — keine Wiederholung der Root-Prinzipien>

  Jedes nested CLAUDE.md beginnt mit dem Verweis „Governance siehe Root-CLAUDE.md" — verhindert Drift zwischen Root- und nested Files, falls sich die Root-Governance später ändert.
• Regel bei Unsicherheit: vor dem Anlegen kurz prüfen, ob ein Inhalt root-weit gilt (→ bleibt im Root) oder stack-lokal ist (→ nested). Im Zweifel: root — lieber einmal zu viel gelesen als in einem Subsystem übersehen.

Repo (Everything-as-Code)

• Repo = einzige Quelle der Wahrheit; Entscheidungen landen als .md-Commit, bevor die Session endet.
• Audit-Trail (verbindlich): Jede Design-/Architektur-/Prozess-Entscheidung und jedes Diskussionsergebnis wird in der Doku festgehalten — fachlich in docs/fachlich/Lastenheft.md, offene Punkte als ops/<ID>.md (ops/-first, agents.md §6.2; Alt-Bestand am 12.07.2026 vollständig aus HANDOFF.md §4 / Lastenheft §11 hierher migriert — Lastenheft §11 bleibt fachliches Detail-Ziel; die generierte Übersicht docs/betrieb/Offene-Punkte.md führt immer eine aktuelle Statistik + Grafik offen vs. abgeschlossen mit — PO-Vorgabe 07-12, auto via gen-ops), Design in design/, Guiding Principles hier in dieser Datei — und als CHANGELOG.md-Eintrag je PR (Datum · PR-Link · kurze Beschreibung inkl. getroffener Entscheidungen). Changelog immer aktuell halten.
• Chat-Zusammenfassung bei wichtigen Entscheidungen (Multi-Projekt-Arbeit): Bei wichtigen Entscheidungen und vor jedem Push/PR am Ende der Antwort eine kurze Chat-Zusammenfassung ausgeben (3–5 Zeilen: Was gebaut · Warum/Entscheidung · Offen/nächster Schritt) — als Chat-Sicht fürs Arbeiten über mehrere Projekte/Chats, zusätzlich zu (nicht Ersatz für) CHANGELOG/HANDOFF. Nur bei relevanten Punkten (Merge/Push, Architektur-/Design-Entscheidung, fertiges Feature) — nicht nach jedem trivialen Zwischenschritt. Rückfragen sparsam: nur an echten Weggabelungen (Architektur, irreversible/außenwirksame Aktionen, mehrdeutige Anforderungen) nachfragen; klare Standard-Defaults selbst wählen, kurz nennen, weitermachen.
• Doku-Konsistenz-Check (verbindlich, OP-DOCS-9): Die Doku muss in sich widerspruchsfrei und zur Implementierung passen — zu Session-Beginn sichten, vor jedem PR gegenprüfen (beide Achsen Doku↔Doku · Doku↔Code, inkl. Version/Build = server/src/version.ts). Mechanik (Teilmenge): bash scripts/check-doc-consistency.sh — die harte Teilmenge blockt in CI (--strict im Job doc-consistency am ci-gate: tote Links · Version-SoT · Offene-Punkte-Staleness), der Rest warnt; der semantische Teil ist Agenten-Pflicht. Bei Unklarheit: nachfragen. Volltext (beide Achsen im Detail): docs/konventionen/agents.md §5.1/§6.5 (Owner der Regel).
• Merge-Strategie & Log-Hygiene (OP-PM-2): Die append-only Logs (CHANGELOG.md, HANDOFF.md, docs/betrieb/Timesheet.md) nutzen merge=union (.gitattributes) → parallele PRs konkatenieren statt zu blocken; Preis sind gelegentliche Duplikate → Logs regelmäßig glätten (Session-Beginn + nach Merges: npm run smooth-logs in server/ entfernt byte-identische Duplikate, scripts/check-doc-consistency.sh flaggt Kandidaten; das Urteils-Glätten bleibt Agenten-Sache). Session-IDs (repo-/branch-abgeleitet, OP-PM-3, kollisionsfrei) & Build-Nummern sind auto-vergeben. Volltext (lokaler union-Merge-Workflow, sync-pr-logs, Merge-Queue-Empfehlung): docs/konventionen/agents.md §6.6 (Owner der Regel).
• Markdown + Mermaid, keine Binärformate (.docx/.pdf/.pptx) als Master.
• ID-System (Commits referenzieren IDs): G-n global · R-n Module · Rn-F## Felder · A-n Architektur · S-n Vereinfachungen · OP-Rn-n offene Punkte · UC-x · FR-n · FM-n. Projekt-Kürzel TKT (verbindlich): jede neue ID trägt das Repo-Kürzel als Prefix (TKT-D-n, TKT-OP-Rn-n, analog MED-/SERA- in den Schwester-Repos) → git-/repo-übergreifend eindeutig. Bestehende IDs bleiben unverändert (kein retroaktiver Umbau) — beim nächsten inhaltlichen Anfassen mitziehen. Session-ID sprechend & branch-abgeleitet: TKT-<Datum>-<branch-slug>.
• Branch-first (nie direkt auf main); nach Merge den Feature-Branch löschen (remote+lokal; bevorzugt GitHub „Automatically delete head branches“); jeder PR/Merge pflegt HANDOFF.md + docs/betrieb/Timesheet.md mit (plus fachlich betroffene Docs); keine ungefragten Refactorings; keine PII/Secrets im Klartext. Vollständige Je-PR-Pflichten an einem Ort: kanonische PR-Checkliste .github/PULL_REQUEST_TEMPLATE.md (Sicht mit Owner-Verweisen, OP-DOCS-15; Pflege: agents.md §6.9).
• GitHub-Operationen via GitHub-API/MCP (nicht lokales git/gh für Remote-Writes): PR anlegen/mergen, Review-/Issue-Kommentare, Remote-Commits/-Pushes über die GitHub-MCP-Tools; CI-Status & Mergeability über pull_request_read prüfen (nicht erraten). Lokale git-Pushes/-Commits sind in der Remote-Session unzuverlässig (Permission-Stream bricht ab); lokales git nur für lokale Arbeit (Branch/Merge/Konflikte/Reads). Detail: docs/konventionen/agents.md §7.
• Feature-Branches aktuell halten: Laufende Feature-Branches regelmäßig mit main abgleichen (zwischenzeitlich gemergte PRs einpflegen — git fetch origin main → merge/rebase), mindestens zu Session-Beginn und vor dem PR, damit Konflikte klein bleiben und gegen den aktuellen Stand entwickelt wird.
• Session-Start lesen: HANDOFF.md → docs/fachlich/Lastenheft.md → docs/konventionen/agents.md.

Versionierung (SemVer) & Build-Nummer

• Erstes Ziel: MVP = Version 1.0.0. Bis dahin (Vor-MVP) bleibt die Version 0.x; der Sprung auf 1.0.0 markiert das fertige MVP.
• SemVer MAJOR.MINOR.PATCH, bewusst (manuell) hochgezählt — jede PR entscheidet die passende Ebene:
  • PATCH (1.1.0 → 1.1.1): Bugfixes & kleine Tweaks (keine neue Funktion).
  • MINOR (1.0.0 → 1.1.0): Optimierungen / neue, rückwärtskompatible Features.
  • MAJOR (1.x.x → 2.0.0): großer Meilenstein / Breaking Change (das MVP selbst = 1.0.0).
• Build-Nummer = automatisch aus dem Git-Commit-Count (git rev-list --count HEAD), Build-Zeit = Stempel-/Deploy-Zeitpunkt (ISO-UTC) — beide beim Deploy gestempelt (scripts/stamp-build.mjs → server/src/build-number.ts, via predeploy-Hook) — monoton & kollisionsfrei auch bei parallelen PRs (löst die frühere Hand-+1-Kollision ab, OP-PM-2; Umstellung bei Build 19 → fortan Commit-Count). Nicht von Hand pflegen. Der committete Wert in build-number.ts ist nur Dev-/Fallback-Stand; der deployte Worker trägt den gestempelten Wert (CI-Deploy-Checkout braucht fetch-depth: 0).
• Single Source of Truth: APP_VERSION (SemVer, manuell je PR-Ebene) in server/src/version.ts; APP_BUILD + APP_BUILD_ZEIT in server/src/build-number.ts (auto-gestempelt, s. o.; Zeit leer = ungestempelter Dev-Stand). Der Client erhält beide über den State (kein zweiter Pflegeort). Beim PR nur APP_VERSION passend setzen (Build kommt automatisch).
• Sichtbar (verbindlich): Version, Build-Nummer und Build-Zeit stehen in der UI (Planung-Statushinweis, neben dem Solver-Build) und in den Logs (Startup-Zeile via APP_VERSION_LABEL; Version/Build als Standard-Felder im Logger-Wrapper).

Compliance, Sicherheit & Risiko (Zielmärkte DE · AT · CH)

• Golden Rule — Zero Trust vor Public: Jedes Online-Deployment wird zunächst hinter Cloudflare Zero Trust (Access) von der Öffentlichkeit abgeschottet — offener Zugriff ist die Ausnahme, die explizit freigegeben und begründet wird (nie der Default beim ersten Go-Live). Gilt für jede neue Umgebung/jeden neuen Hostname, bevor Traffic von außen zugelassen wird. automotivo.de-Analyse und produktive Kundenzugänge (Vest-POC) sind hiervon nicht ausgenommen — Zugang bleibt Access-gated.
• SBOM immer pflegen (OP-SBOM-1): je npm-Paket eine CycloneDX-SBOM (npm run sbom); der CI-Job sbom erzeugt Server- + Client-SBOM als Artefakt — auf jedem main-Push (Release-Stand; seit OP-CI-1 nicht mehr je PR → spart Minuten, „immer aktuell“ auf main gewahrt). Python-Solver-SBOM folgt. Grobe Systemstruktur + SBOM-Fundstelle stehen verbindlich in docs/architektur/Architektur-Uebersicht.md — bei jeder architektonischen Änderung mitziehen.
• Zertifizierungs-/Audit-Bereitschaft laufend mitpflegen (OP-COMPLIANCE-1), nicht erst zum Audit: Belege/Checklisten für TÜV · ISO (z. B. 27001) · Security-Audit als lebende Doku in docs/betrieb/Compliance.md; bei jedem relevanten Feature den Compliance-Bezug dort nachziehen.
• Proaktives Flagging (verbindlich): Tauchen kritische / regulatorisch relevante Themen für DE/AT/CH (DSGVO, E-Rechnung, Arbeitszeit, Produkt-/Datensicherheit …) oder generell auf, aktiv darauf hinweisen und Handlungsoptionen aufzeigen — nie still übergehen.
• Risikoregister docs/betrieb/Risikoregister.md führen und regelmäßig prüfen (zu Session-/PR-Beginn: relevante Risiken sichten, neue eintragen, Status/Maßnahme pflegen).
• Log-Handling → OP-LOG-1: zentraler Logger-Wrapper, strukturierte Logs (inkl. Version/Build + trace_id), keine rohe console im Laufzeitpfad (CLI/Self-Tests ausgenommen, CI-Gate check-no-console.sh), PII-Scrubbing; Transport/Backend via OP-OBS-1 (OTel/OTLP → Grafana Cloud EU, live). Owner/Stand: docs/architektur/Observability.md.

Globale Constraints

• G-1 Taxonomie-artige Enums sind admin-editierbar; logik-tragende (z. B. Abhängigkeit nach_vorherigem/parallel/frei) bleiben fix.
• G-2 Scheduler rechnet 5 Min Pönale bei Mitarbeiter-Kontextwechsel (konfigurierbar).
• G-3 Auto-Scheduler plant keine Arbeit in Fenster < 15 Min.
• G-4 Aufgaben-Platzierung minimiert Kontextwechsel (wer als Nächstes am Fahrzeug arbeitet, übernimmt bevorzugt auch dessen Neben-/Logistikaufgaben wie Umparken) — Ausnahme QS/Quality-Check (Vier-Augen, hart): wer eine Arbeit ausgeführt hat, verifiziert ihr Ergebnis nie selbst. Abweichen darf nur der Chef — je Prüfschritt, begründet + auditiert (OP-QS-6).

Datenmodell (v1, verbindlich)

• Auftrag (R7) ist der zentrale Träger. Ein Fahrzeug ist kein eigenständiges Objekt — Angaben werden am Auftrag und nur während des Auftrags getrackt. Kunde = nur Name + CRM-Link (extern).
• Versioniert + idempotente Auto-Migration (schemaVersion/onStart-Remaps in server/party/leitstand.ts). Derived State nie speichern — immer ableiten.
• Geplante Persistenz-Konvention (noch nicht im Code, künftig OP-DATA-1): Drizzle-Schema als Single Source → generierte SQL-Migrationen + CI-Gate (Token-Muster).

Standard-Prozess

Jeder Auftrag: Annahme → Vorbereitung → Produktion → Quality-Check → Abholung, je mit Doku/Kommentar. (Sprechende Labels — technische Keys bleiben aufbereitung/qs: Phase „Vorbereitung“ [vormals „Aufbereitung“] inkl. Car-Check + Folien-Produktion/Zuschnitt; „Quality-Check“ [vormals „QS“]. Bessere Benennung der Produktions-Phase + Differenzierung Vor-Produktion (Folien-Zuschnitt, Material-Bestellung) → OP-PHASE-1.) Klärfälle-Prozess (Skill „Klärung“): Unterbrechung an jeder Stelle → Eskalation/Doku → zurück / Sprung zu Quality-Check / anderer Schritt / Abbruch. Lifecycle-Status (geplant→…→archiviert) und fachliche Phasen sind getrennt zu denken. Fachquelle: docs/fachlich/Lastenheft.md §5.1.

Architektur / Stack

Drei eigenständige Tech-Stacks, je mit eigenem nested CLAUDE.md (s. Instruktions-Scoping oben): client/ (Angular 22), server/ (Cloudflare Worker + Durable Object), solver-service/ (Python/OR-Tools CP-SAT, Fly.io, Fallback: TS-Optimierer im Worker). Domänen-Code deutsch (Auftrag, Teilschritt, Mitarbeiter, Bucht …) — repo-weit, über alle drei Stacks hinweg; technische Identifier lowercase englisch (taktano).

Observability / Logging

• Leitlinie (07-03): OTLP/Grafana ist DER zentrale Log-Sink. Alles operativ Relevante meldet Warnungen/Fehler dorthin — die Laufzeiten (Worker/DO · Angular-Client · Python-Solver) und Tooling-/CI-Schritte (z. B. Doku-Index-Push): lokale Ausgaben (console, GitHub-Actions- Annotationen) sind Ergänzung für den jeweiligen Kontext, nie Ersatz — was nur dort steht, ist im Betrieb unsichtbar. Best-effort + dormant ohne OTEL_EXPORTER_OTLP_ENDPOINT (Observability bricht nie den Laufzeit-/Deploy-Pfad).
• Logging via OpenTelemetry (OTLP). Anwendungs-Logs (und Traces/Metrics) laufen über das OTel-SDK je Laufzeit — Worker/DO · Angular-Client · Python-Solver —, nicht roh über console.log/print im Laufzeit-/Produktivpfad (CLI-Demos & Self-Tests dürfen weiterhin console/print). Strukturiert, über einen Logger-Wrapper (nicht direkt das SDK streuen), mit trace_id-Korrelation über die Laufzeiten. Verdrahtung + Collector/Backend: OP-OBS-1 (heute noch console-basiert → migrieren).

Design-Prinzipien

Brand: Cyan = Signatur-/Markenfarbe, Rot nur für Warnungen (nie dekorativ) — Produktidentität, gilt repo-weit. Alle Token-/Komponenten-/No-Hex-Regeln (Detailvertrag) leben in client/CLAUDE.md + design/CLAUDE.md — hier nicht dupliziert, dort lesen/pflegen.

• Taktano-lokale Ausnahme „Rot als Primärfarbe" (PO-Entscheidung 07-23, OP-REDESIGN-1): Mit dem Redesign „Flusslinie/Modernist" wird in Taktano Rot (#ec3013) zur Primär-/Markenfarbe (Primär-Aktionen und Warnungen). Das ist eine bewusste, begründete Ausnahme von der Regel „Rot nur für Warnungen" — die als drkv-Default bestehen bleibt und in den Schwester-Repos (MED-/SERA-) unverändert gilt. Konsequenz für Taktano: Warnungen brauchen eine eigene, nicht rein-farbliche Kennzeichnung (Icon/Label/Rahmen/Blink), da Rot nicht mehr warn-exklusiv ist. Voller Kontext + Phasen-Roadmap: ops/OP-REDESIGN-1.md; Detailvertrag: design/CLAUDE.md.

Tests & CI

Tests on-demand (lokal) und in CI (.github/workflows/ci.yml, Node 22 / Python 3.12): Server-Smoke (npm run spike|operativ|replan|solve|test:teilplan), Client ng build, Design-Gate (no-hex + Token-Staleness). Neue Tests beiden Wegen hinzufügen.

• Test-Übersicht immer mitführen (verbindlich): die vollständige, lebende Liste aller automatischen Tests/Selbsttests/Gates steht in docs/betrieb/Tests.md (Befehl · Prüfgegenstand · OP-Bezug · CI-Job). Jede neue/entfernte Prüfung wird dort je PR nachgezogen — wie CHANGELOG/HANDOFF/Timesheet. Mechanischer Rückhalt: scripts/check-doc-consistency.sh warnt, wenn ein test:*-Script (server/ + client/) dort fehlt; der semantische Teil (stimmt Beschreibung/OP-Bezug) bleibt Agenten-Pflicht (OP-DOCS-9).

Tiefenquellen

Datei	Zweck
docs/README.md	Doku-Landkarte — alle docs/ nach Zweck gruppiert (Einstieg/Navigation)
HANDOFF.md	aktueller Stand/Handoff (zuerst lesen); offene Punkte → docs/betrieb/Offene-Punkte.md (ops/*.md)
docs/fachlich/Lastenheft.md	fachliche Master-Spec (IDs, Mermaid)
docs/konventionen/agents.md	verbindliche Agenten-Konventionen (Way-of-Working)
docs/konventionen/Entwicklungsansatz.md	Entwicklungsansatz auf einen Blick — True North · Leitprinzipien · Way-of-Working (lesbare Übersicht; CLAUDE.md bleibt verbindlich)
docs/architektur/In-App-Assistent.md	In-App-Chatbot (OP-AI-4): LLM + RAG auf Live-Daten & Doku (Doku-Q&A · Insights · Feedback) — drkv-Standard-Baustein, Referenz-Implementierung
docs/zielgruppen/Lesepfade.md	Lesepfade nach Zielgruppe (Anwender · Business · IT-Dev/Arch · Ops · DevOps · CISO · Support)
docs/glossar/Glossar.md	Glossar (generiert aus docs-site/src/glossar/glossar.mjs) → Begriffe + Begriffs-Sprechblasen, klassifiziert nach Art (fachlich/technisch) × Ebene (Grundprinzip/erweitert) + interaktiver Filter, OP-DOCS-10
docs/konventionen/IDs.md	ID-Präfix-Legende + Reverse-Lookup „OP → Owning-Dokument“ (volle OP-Liste: docs/betrieb/Offene-Punkte.md)
docs/betrieb/Timesheet.md	Arbeitszeit-Timesheet (Start/Stop je Session · Gap-Regel · Methodik)
docs/betrieb/Sanity-Checkliste.md	True-North-Prüfliste (Status ✅/🟡/⛔)
docs/betrieb/Doku-UX-Konzept.md	Doku-UX-Konzept (OP-DOCS-13): Doku entwirren — Struktur · Lesbarkeit · Navigation; Diagnose + Zielmodell + 5-Phasen-Roadmap
docs/betrieb/Tests.md	Test-Übersicht (lebend) — alle automatischen Tests/Selbsttests/Gates: Befehl · Prüfgegenstand · OP-Bezug · CI-Job; je PR mitführen (§Tests & CI)
docs/betrieb/Compliance.md · docs/betrieb/Risikoregister.md	Compliance/Zertifizierung (DE/AT/CH) + Risiko (OP-COMPLIANCE-1/OP-SBOM-1/OP-LOG-1)
docs/architektur/Audit-Log.md	Audit-Log-Architektur (OP-AUDIT-1): D1, Event-Modell, „nicht reverse-engineerbar“, Retention
docs/architektur/Observability.md	Observability/Logging-Backend (OP-OBS-1): OTel/OTLP-Backend-Kandidaten (Grafana/Sentry/CF-nativ/Honeycomb), EU-Residenz, Empfehlung; Abgrenzung Cockpit/Kosten/Audit + Snyk/SonarQube-Befund
docs/architektur/Kosten.md	Kosten-Dashboard-Architektur (OP-COST-1): zwei Sichten (betriebswirtschaftlich/Infra), Datenmodell, Rollen, Slices
docs/architektur/Akademie.md	Skill-Niveau-Progression & Akademie (OP-R1-3): niveau-gezielte Ausbildungsziele, XP-Schwellen, begründete Beförderung, Zertifizierungs-Vorbereitung
docs/architektur/Seed-Abloese-Plan.md	Seed-Ablösung (OP-SEED-1 / S-SEED-1..5) + Mandantenfähigkeit (OP-TENANT): Audit, Purge, Tenant-Vorlage, Stammdaten persistiert/editierbar
docs/architektur/Mandantenfaehigkeit.md	Tenant-Isolation (OP-TENANT): Daten pro Tenant physisch getrennt (DO-SQLite je Tenant, inkl. Audit), Registry zentral (Better Auth), Enforcement, Slices T-1..T-6
docs/architektur/Persistenz.md	Persistenz-Konvention & Migrations-Hygiene (OP-DATA-1 / S-SEED-5): DO-Blob · DO-SQLite · D1, Drizzle als Single Source + CI-Gate
docs/architektur/Backup-Restore.md	Backup & Restore / Point-in-Time (OP-BACKUP-1): Snapshot vs. PITR, Restore-Punkt via Audit-Log, Audit-Log bleibt append-only
docs/architektur/Fahrzeug-3D.md	Fahrzeug-3D (OP-R6-2): CC0-Karosserietyp-Modelle (GLB) + <model-viewer> (drehbar, Hotspot-Markierungen) + USDZ-Pfad iOS/AR; Markierungs-Datenmodell renderer-neutral
docs/architektur/Architektur-Uebersicht.md	Grobe Systemstruktur (Mermaid) + SBOM-Fundstelle — Client · Worker/DO · Solver-Service · D1/DO-SQLite · OTel
design/CLAUDE.md · design/DESIGN_TOKENS.md · design/COMPONENTS.md	Design-System-Detailvertrag
client/CLAUDE.md	Stack-Detail Client (Angular, Build/Test, Konventionen)
server/CLAUDE.md	Stack-Detail Server (Cloudflare Worker/DO, Build/Test, Konventionen)
solver-service/CLAUDE.md	Stack-Detail Solver-Service (Python/CP-SAT, Run, Konventionen)