OP- & Entscheidungs-Register — Navigations-Index
Kernaussage. Diese Seite ist ein einziger Einstieg zu allen offenen Punkten (OP-*) und allen festen Entscheidungen/Constraints (G · A · S · UC · E) — je Eintrag nur ID · Kurz-Gloss · Link. Sie dupliziert nichts: Status, Begründung und Detail leben in den verlinkten Quellen.
So liest du dieses Register (Nicht-Duplikat-Vertrag)
Das Register ist ein Index, keine Quelle der Wahrheit. Maßgeblich bleibt jeweils:
| Wofür | Maßgebliche Quelle |
|---|---|
| OP-Status (neue OPs, seit 07-12) | ops/<ID>.md (Frontmatter = Lebenszyklus) → generierte Offene-Punkte.md — verbindlich, agents.md §6.2 |
| OP-Status (Alt-Bestand) | HANDOFF.md §4 (Repo-Root) — Archiv (Alt-OPs wandern bei Berührung ins ops/-Format; Migrations-Stand in Offene-Punkte.md) |
| OP → Owning-Dokument | ID- & OP-Index (kuratierte Reverse-Lookup-Tabelle) |
| ID-Präfix-Definitionen | agents.md §3 · Lastenheft |
| G / A / S / UC (Definition) | Lastenheft §2/§3/§9/§10 (unten verlinkt) |
| Änderungs-Historie je PR | CHANGELOG.md (Repo-Root) |
Regel: Änderungen an einem OP/Entscheid landen zuerst in der maßgeblichen Quelle —
neue OPs in ops/<ID>.md (ops/-first, agents.md §6.2), Alt-Bestand bleibt bis zur Migration
im HANDOFF-§4-Archiv, Entscheidungen/Fachliches im Lastenheft bzw. Owning-Doc —, danach ggf.
eine Zeile hier. Wird hier etwas ausführlich beschrieben statt verlinkt, ist es falsch am Platz.
1 · Offene Punkte (OP-*)
Gruppiert nach Thema. Modul-gebundene Familien (OP-R*-n) sind als Sammelzeile geführt
(Detail-Enumeration in HANDOFF.md §4 + Lastenheft §4–§9); thematische/eigenständige OPs
einzeln. „Owning-Doc" = eigenes Entwurfs-/Fachdokument (siehe IDs.md); sonst Detail in
HANDOFF.md §4.
Jede OP-ID ist ein Sprung-Link — Klick auf
`OP-…`springt direkt zu ihrem Zuhause (Owning-Doc bzw. der passende Lastenheft-§11-Anker /HANDOFF.md§4). So bleibt die Liste nicht nur Karte, sondern auch direkte Navigation (verbindlich, s. Pflege).
Produkt · Flow · Operativ
| OP | Kurz-Gloss | Detail / Owning-Doc |
|---|---|---|
OP-R3-1 | Standard-Prozess + Klärfälle-Prozess modellieren | Flow-Analyse · Flow-Refactor-Plan |
OP-R3-2 | Produktions-Vorbereitung als Vorbedingung (Bestellvorlauf) | HANDOFF.md §4 |
OP-CRUD-1 | Entitäten-Lebenszyklus (CRUD · Archiv statt Löschen) | Entitaeten-Lebenszyklus |
OP-UX-1 | Operative Durchgängigkeit & Werker-Sicht | Operative-Durchgaengigkeit |
OP-UX-2 | Klärfälle-Workspace (Störung-Achse: Sicht + Zähler) | Operative-Durchgaengigkeit |
OP-UX-3 | Nacharbeit nach QS-Mangel live im Gantt | Operative-Durchgaengigkeit |
OP-SKILL-1 | Verwaiste Skills sichtbar machen + Skills näher an Prozesse/Teilschritte (Var. A+B+C ✅) | HANDOFF.md §4 · Lastenheft §11.7 |
OP-R1-6 | Mitarbeiter-Seite für 10–50 MA skalieren (erst Konzepte vergleichen, dann bauen) | HANDOFF.md §4 · Lastenheft §11.3 |
OP-KIOSK-1 | Kiosk-Mode mit Reverse-Pairing (ohne Login) | HANDOFF.md §4 |
OP-STANDORT-1 | „Standort unbekannt" sichtbar (✅ abgeschlossen) | HANDOFF.md §4 |
OP-STANDORT-2 | Hat Anlieferung immer schon einen Standort? | HANDOFF.md §4 |
OP-COMPETE-1 | Wettbewerbsanalyse (Landschaft · Differenzierung · SWOT) | Wettbewerbsanalyse |
OP-MARKET-1 | Marktabschätzung & Markteintrittsstrategie (TAM/SAM/SOM · Beachhead · GTM) | Markt-und-Markteintritt |
OP-VERTRIEB-1 | Vorteilsrechner (ROI) für den Vertrieb (✅ v1 umgesetzt) | HANDOFF §4 |
OP-VERTRIEB-2 | Akquise-/Orga-Tool für Anbahnungen — Build vs. Buy (z. B. Hubspot, noch offen) | HANDOFF §4 |
OP-VERTRIEB-3 | Verbindlicher Meilensteinplan bis zum Produktivbetrieb | HANDOFF §4 |
OP-R4-3 | Schritt-Doku & Kommentare (Kommentar F14 · Foto-Mindestanzahl F15 · Aspekt-Leitfaden F16) | Doku-und-Kommentare |
OP-DIKTAT-1 | Sprach-Diktat für Kommentare/Doku | Doku-und-Kommentare |
OP-TEXTBLOCK-1 | Textbausteine für Kommentare/Doku | Doku-und-Kommentare |
OP-ABSCHLUSS-1 | Auftrags-Abschluss-Notiz (Doku auf Auftrags-Ebene) | Doku-und-Kommentare |
Module (R1–R10) — Sammelzeilen
| OP-Familie | Thema (Kern-Sub-OPs) | Detail |
|---|---|---|
OP-R1-* | Mitarbeiter (inkl. OP-R1-3 Akademie) | Akademie · HANDOFF.md §4 · Lastenheft §11.1 |
OP-R2-* | Arbeitsplätze/Belegung (Abweichungs-Erkennung, Hofplan) | HANDOFF.md §4 · Lastenheft §11.7 |
OP-R4-* | Protokolle/Doku/Foto (Bild-Auflösung/-Größe) | HANDOFF.md §4 · Lastenheft §11.4 |
OP-R7-* | Aufträge (Preismodell OP-R7-6, Owner OP-R7-11) | HANDOFF.md §4 · Lastenheft §11.1 |
OP-R8-* | Planung/Gantt/Konflikte (Heute-Linie, Zoom, Engpässe) | HANDOFF.md §4 · Lastenheft §11.2 |
OP-R9-* | Leitstand/Dashboard/Theme (OP-R9-9 Light/Dark, OP-R9-10 Dashboard) | HANDOFF.md §4 · Lastenheft §11.3 |
OP-R10-* | Infrastruktur | HANDOFF.md §4 |
Optimierung (Scheduler/CP-SAT)
| OP | Kurz-Gloss | Detail |
|---|---|---|
OP-OPT-1 | Terminklassen-Modell | HANDOFF.md §4 · design/OPTIMIERER_TERMINKLASSEN.md |
OP-OPT-2 | Kunden-Wunsch vs. interne Priorität | HANDOFF.md §4 |
OP-OPT-3 | Vorschlags-Modell vereinheitlicht | HANDOFF.md §4 · design/OPTIMIERER_TERMINKLASSEN.md |
OP-OPT-4 | Neuer Auftrag optimal einlasten (konfigurierbar) | HANDOFF.md §4 |
OP-OPT-5 | CP-SAT ↔ TS-Scheduler-Parität | HANDOFF.md §4 |
OP-OPT-6 / OP-OPT-7 | Optimierer-Refinement · Fairness (Wunschfrei) | HANDOFF.md §4 |
Daten · Persistenz · Mandanten · Audit
| OP | Kurz-Gloss | Detail / Owning-Doc |
|---|---|---|
OP-DATA-1 | Persistenz-Konvention & Migrations-Hygiene | Persistenz |
OP-BACKUP-1 | Backup & Restore (Point-in-Time) | Backup-Restore |
OP-SEED-1 | Seed-Ablöse-Plan & Tenant-Vorlage | Seed-Abloese-Plan |
OP-TENANT | Mandantenfähigkeit & Tenant-Isolation | Mandantenfaehigkeit |
OP-AUDIT-1 | Audit-Log / Änderungshistorie (D1, EU) | Audit-Log |
OP-AUTH-1 / OP-AUTH-2 | Identity-Provider & Mandanten-Trennung (Better Auth) | Lastenheft §11.5 |
Observability · Logging
| OP | Kurz-Gloss | Detail / Owning-Doc |
|---|---|---|
OP-OBS-1 | OpenTelemetry-Logging verdrahten (OTLP-Backend) | Observability |
OP-LOG-1 | Logger-Wrapper, strukturierte Logs, PII-Scrubbing | HANDOFF.md §4 |
Security · Compliance
| OP | Kurz-Gloss | Detail / Owning-Doc |
|---|---|---|
OP-SEC-1 | Penetration-/Sicherheitstests vor Multi-Tenant-Betrieb | HANDOFF.md §4 · Risikoregister |
OP-SBOM-1 | SBOM (CycloneDX) immer pflegen | Compliance |
OP-COMPLIANCE-1 | Zertifizierungs-/Audit-Bereitschaft (DE/AT/CH) | Compliance |
Kosten · Billing · Zugang · Reporting
| OP | Kurz-Gloss | Detail / Owning-Doc |
|---|---|---|
OP-COST-1 … OP-COST-4 | Kostenkontrolle & Dashboard (API-Pull, Owner-Gate, Token) | Kosten |
OP-BILLING-1 / OP-ACCESS-1 | Abrechnung (SevDesk) & zahlungs-gesteuerter Zugang | Billing-Zugang |
OP-PAY-1 | Vermarktung: Paygate/Billing-Anbieter | Lastenheft §11.6 |
OP-EXPORT-1 / OP-REPORT-1 | Reports mit Diagramm + Export (PDF/CSV/Excel) | HANDOFF.md §4 |
DevOps · PM · Docs · Design
| OP | Kurz-Gloss | Detail / Owning-Doc |
|---|---|---|
OP-PM-1 / OP-PM-2 | Merge-Strategie & Log-Hygiene (merge=union) | agents.md §6.6 |
OP-DOCS-1 … OP-DOCS-12 | Doku-Infrastruktur (OP-DOCS-9 Konsistenz, OP-DOCS-10 Glossar, OP-DOCS-12 OP-ID-Sprünge) | agents.md §5.1/§6.5 |
OP-DOCS-11 | OP-Verwaltung: Single Source + Query-Views (✅ v1) | OP-Management-Gold-Standard |
OP-DOCS-14 | Doku-Review-Folgen: Anwender-Handbuch · Drift-Fix · Gates scharf | Doku-Review 2026-07 · ops/OP-DOCS-14.md |
OP-DOCS-15 | Kanonische PR-Checkliste (✅ — Sicht mit Owner-Verweisen, kein neuer Regel-Owner) | PR-Template · agents.md §6.9 |
OP-DEPLOY-1 / OP-DEPLOY-2 | Deployment & CI/CD | HANDOFF.md §4 |
OP-DESIGN-1 … OP-DESIGN-3 | Design-System-Integration · A11y · Gantt-Light | HANDOFF.md §4 · design/ |
OP-DEVTOOL-1 | CodeRabbit ↔ MCP-Integration prüfen | HANDOFF.md §4 |
OP-BRAND-1 | Branding | HANDOFF.md §4 |
KI · QS · i18n · Sonstiges
| OP | Kurz-Gloss | Detail / Owning-Doc |
|---|---|---|
OP-AI-1 … OP-AI-4 | KI-Layer (OP-AI-4 In-App-Assistent, propose-not-execute) | In-App-Assistent |
OP-QS-1 / OP-QS-2 | Qualitätssicherung · automatische Bildbewertung | Bildbewertung |
OP-QS-GATE / OP-QS-4 / OP-QS-5 | QS-Vollständigkeits-Gate + QS-Nacharbeit direkt/zuweisbar + Leistungs-Schwellwerte + Dauer-Dedup (Schritt = Single Source) | Operative-Durchgaengigkeit |
OP-I18N-1 | Mehrsprachigkeit + Multi-Currency (EU-Expansion) | HANDOFF.md §4 |
OP-PROD-1 | Etikettendrucker Folienproduktion | Lastenheft §11.7 |
Vollständige, tagesaktuelle Liste (mit Status, PR-Nummern, Begründung):
HANDOFF.md§4. Diese Tabelle ist die navigierbare Karte, nicht der Stand.
2 · Entscheidungen & Constraints
Feste Festlegungen — anders als OPs abgeschlossen. Definition jeweils in der verlinkten Quelle.
Globale Constraints (G-n) — Lastenheft §3
| ID | Festlegung |
|---|---|
G-1 | Taxonomie-artige Enums admin-editierbar; logik-tragende Enums fix |
G-2 | 5 Min Pönale bei Mitarbeiter-Kontextwechsel (konfigurierbar) |
G-3 | Auto-Scheduler plant keine Arbeit in Fenster < 15 Min |
Architektur-Empfehlungen (A-n) — Lastenheft §9
| ID | Festlegung |
|---|---|
A-1 … A-4 | Stack/Architektur-Leitplanken (Client · Server/DO · Live-State · KI-Layer) |
A-5 | Optimierungs-Pragma: OR-Tools (CP-SAT) + XState + LLM-API |
Vereinfachungen ggü. Altsystem (S-n) — Lastenheft §10
| ID | Festlegung |
|---|---|
S-1 | Single-Modal-Geist (Annahme als ein Formular) |
S-2 | Derived-State nie speichern — immer ableiten |
S-6 | Auftrags-Lifecycle in drei Phasen (Anlieferung · Produktion · Abholung) |
S-8 | Vorlagen-Bibliothek (einheitliches Pattern für Leistungen/Formulare) |
S-10 | Attachment/Dokument-Entität |
| (weitere) | S-3 … S-9 / S-SEED-* — siehe Lastenheft §10 + Owning-Docs |
Kern-Use-Cases (UC-x) — Lastenheft §2
| ID | Use-Case |
|---|---|
UC-A | Auftrag annehmen mit verlässlichem Termin (Angebotsmodus) |
UC-B | Tagesablauf disponieren (Teilschritt-Instanzen, Zuweisung) |
UC-C | Arbeit ausführen (Mitarbeiter-Sicht: starten/abschließen/QM) |
UC-D | Live-Steuerung (Leitstand: Auslastung · Konflikte · Vorschläge) |
UC-E | Qualität & Beleg (Protokolle, Zustandsdoku, Unterschriften) |
UC-F | Kunden-Kommunikation (Bring/Abholtermin, Self-Service-Link) |
UC-G | Stammdaten pflegen (Skills, Leistungen, Mitarbeiter, Taxonomien) |
Getroffene Entscheidungen je OP (E-*)
Begründung + Datum im jeweiligen Owning-Doc bzw. HANDOFF.md §3/§4.
| ID | Thema | Quelle |
|---|---|---|
E-CRUD-1 … E-CRUD-4 | Archiv-Flag · Materialisierung-bei-Start · Slice-Reihenfolge · Hard-Delete-Ausnahmen | Entitaeten-Lebenszyklus |
E-UX-1 … E-UX-3 | Eigene Workspaces (Tafel · Meine Arbeit · Annahme) | Operative-Durchgaengigkeit |
E-DATA-1 | Persistenz-/Migrations-Entscheidung | Persistenz |
E-TENANT-1 | Tenant-Isolations-Entscheidung | Mandantenfaehigkeit |
E-BACKUP-1 … E-BACKUP-3 | Snapshot vs. PITR · Restore-Punkt · Append-only | Backup-Restore |
Pflege
Neuer OP/Entscheid → erst Detail in der maßgeblichen Quelle (HANDOFF §4 / Lastenheft /
Owning-Doc), dann eine Zeile hier (ID · Gloss · Link). Die OP-ID wird dabei immer als
Markdown-Sprung-Link gesetzt (ID in eckigen, Ziel in runden Klammern) — Ziel ist das
Owning-Doc, sonst der per-OP-Anker in Lastenheft §11 (#op-<id>) bzw. HANDOFF.md §4
(#op-<id>); Familien-/Sammelzeilen zeigen auf den §11-Sektions-Anker (#11-1-auftraege …
#11-10-tests-qs). So trägt jede OP-Liste in der Doku klickbare Direkt-Sprünge (verbindlich). Bekommt ein OP
ein eigenes Dokument, zusätzlich die IDs.md-Reverse-Lookup-Zeile pflegen. Keine
Status-/Verlaufs-Pflege hier — das bleibt HANDOFF §4 / CHANGELOG. Alle OP-IDs lassen sich
zentral prüfen: grep -ohrE "OP-[A-Z]+-?[0-9]*" HANDOFF.md | sort -u.