ID- & OP-Index — Reverse-Lookup

Zweck. Schneller Einstieg ins Identifikator-System und ein Reverse-Lookup „welches Dokument besitzt einen offenen Punkt (OP-*)?“. Die maßgeblichen Definitionen der ID-Präfixe stehen in agents.md §3 und Lastenheft.md §1.3 — hier nur die kompakte Legende plus die Owning-Doc-Zuordnung. Neue OPs leben als ops/<ID>.md → generierte Offene-Punkte.md (verbindlich seit 07-12, agents.md §6.2); der frühere §4-Archiv-Bestand wurde am 12.07.2026 vollständig dorthin migriert. Diese Tabelle verlinkt nur die OPs, die ein eigenes Entwurfs-/Fachdokument haben.

Navigierbarer Gesamt-Index aller OPs und Entscheidungen (G·A·S·UC·E): OP- & Entscheidungs-Register. IDs.md bleibt die kuratierte Owning-Doc- Zuordnung + Legende; das Register ist die durchsuchbare Karte (bewusste Arbeitsteilung, kein Duplikat).

ID-Präfixe (Kurzlegende)

Präfix	Bedeutung	Maßgeblich definiert in
G-n	Globales Prinzip (z. B. G-2 Kontextwechsel-Pönale)	Lastenheft §3
Rx	Modul / Hauptentität (R1 Mitarbeiter … R9 Persistenz)	Lastenheft §4–§7
Rx-Fnn	Feld innerhalb einer Entität	Lastenheft (jeweilige R-Tabelle)
Rx-Snn	Sub-Entität / Tab	Lastenheft (jeweilige R-Sektion)
A-n	Architektur-Empfehlung (A-3/A-5 Solver)	Lastenheft §9
S-n	Vereinfachung ggü. Altsystem (S-2 Derived-State)	Lastenheft §10
UC-x	Kern-Use-Case (UC-A Verfügbarkeit …)	Lastenheft §2
OP-Rx-n / OP-<Thema>-n	Offener Punkt (modul- bzw. themen-bezogen)	ops/<ID>.md → Offene-Punkte.md (+ Owning-Doc, unten)
FR-n / FM-n	Future-Release- / Future-Module-Note	Lastenheft §12
RISK-n	Risiko-Eintrag	Risikoregister

Details & Pflege-Regeln der IDs: agents.md §3.

Repo-übergreifende IDs (Repo-Key)

IDs sind innerhalb dieses Repos repo-lokal, also ohne Repo-Key (OP-CI-2, RISK-18, D-…), und werden nicht umbenannt. Wird eine ID aus einem anderen Repo zitiert (Commit-Message, PR, Cross-Doc), wird sie mit dem Repo-Key qualifiziert, damit sie org-weit eindeutig bleibt — analog zu GitHubs owner/repo#123:

Repo	Key	Beispiel (cross-repo)
taktano	TKT	TKT-OP-CI-2
medidentas	MED	MED-OP-SIGN-1
gh-self-hosted-runners-director (gh-runner-manager)	GRM	GRM-OP-2

Regel: ohne Repo-Key = repo-lokal; KEY-<ID> nur, wenn die Referenz eine Repo-Grenze überschreitet. Keine Massen-Umbenennung bestehender IDs (Einfachheit/YAGNI). Neue Repos ergänzen hier ihren Key.

OP → Owning-Dokument (Reverse-Lookup)

Offene Punkte mit einem eigenen, verbindlichen Entwurfs- oder Fachdokument. Status jeweils verbindlich in ops/<ID>.md; die verlinkten Dokumente enthalten nur die fachlichen Details.

OP-ID	Thema	Owning-Dokument
OP-OBS-1	Observability / Logging-Backend (OTel/OTLP)	architektur/Observability.md
OP-AUDIT-1	Audit-Log / Änderungshistorie (D1, EU)	architektur/Audit-Log.md
OP-COST-1	Kostenkontrolle & Kosten-Dashboard	architektur/Kosten.md
OP-BILLING-1 / OP-ACCESS-1	Billing & zahlungs-gesteuerter Zugang	architektur/Billing-Zugang.md
OP-R1-3	Akademie & Skill-Niveau-Progression	architektur/Akademie.md
OP-AI-4	In-App-Assistent (Doku-Q&A + Insights, propose-not-execute)	architektur/In-App-Assistent.md
OP-QS-2	Automatische Bildbewertung	architektur/Bildbewertung.md
OP-R3-1	Auftrags-Flow „Phasen first-class“	fachlich/Flow-Analyse.md · fachlich/Flow-Refactor-Plan.md
OP-DOCS-9	Doku-Konsistenz-Check	agents.md §5.1/§6.5 · scripts/check-doc-consistency.sh
OP-DOCS-13	Doku-UX entwirren: Struktur · Lesbarkeit · Navigation (Konzept + Phasen-Roadmap)	betrieb/Doku-UX-Konzept.md
OP-DOCS-11	OP-Verwaltung: Single Source + Query-Views (✅ v1 — ops/*.md + generierte Übersicht + GitHub-Issues-Spiegel)	konventionen/OP-Management-Gold-Standard.md · betrieb/Offene-Punkte.md
OP-DOCS-14	Doku-Review-Folgen (Anwender-Handbuch · Drift-Fix verbindliche Stellen · Doku-Gates scharf)	betrieb/Doku-Review-2026-07.md · ops/OP-DOCS-14.md
OP-DOCS-15	Kanonische PR-Checkliste (✅ — alle Je-PR-Pflichten als PR-Template, Sicht mit Owner-Verweisen)	.github/PULL_REQUEST_TEMPLATE.md · agents.md §6.9 · ops/OP-DOCS-15.md
OP-PM-2	Merge-Strategie & Log-Hygiene (merge=union)	agents.md §6.6 · betrieb/Timesheet.md
OP-CI-1	CI-Build-Minuten sparen (Push nur auf main + concurrency; Folge-Hebel: Pfad-Filter je Bereich, SBOM auf Schedule)	.github/workflows/ci.yml
OP-CI-2	CI/Deploy runner-unabhängig: self-hosted Default via vars.CI_RUNNER-Override + Fork-Gate (fremder Code nie self-hosted, RISK-18); aus medidentas D-29	.github/workflows/ci.yml
OP-DATA-1 / S-SEED-5	Persistenz-Konvention & Migrations-Hygiene	architektur/Persistenz.md
OP-BACKUP-1	Backup & Restore (Point-in-Time)	architektur/Backup-Restore.md
OP-TENANT	Mandantenfähigkeit & Tenant-Isolation	architektur/Mandantenfaehigkeit.md
OP-SEED-1	Seed-Ablöse-Plan & Tenant-Vorlage	architektur/Seed-Abloese-Plan.md
OP-CRUD-1	Entitäten-Lebenszyklus (CRUD · Versionierung · Archiv statt Löschen · laufende Prozesse)	architektur/Entitaeten-Lebenszyklus.md
OP-UX-1	Operative Durchgängigkeit & Werker-Sicht (durchgängige Auftragszeile · Werker-Sicht · Annahme-Maske)	architektur/Operative-Durchgaengigkeit.md
OP-UX-2	Klärfälle-Workspace (Störung-Achse: Sicht + Zähler, Gegenstück zu Konflikte)	architektur/Operative-Durchgaengigkeit.md
OP-UX-3	Nacharbeit nach QS-Mangel live im Gantt (solver-integrierter Nacharbeits-Schritt)	architektur/Operative-Durchgaengigkeit.md
OP-UX-4	v3-Kern-Loop-Redesign (Claude-Design-Handoff) + Ein-Satz-Annahme „Takt-Kommando“	ops/OP-UX-4.md + design/WORKSPACES.md
OP-UX-5	Trennung Auftragsannahme (Buchung) / Fahrzeugannahme (Check-in mit Car-Check-Doku-Pflicht)	ops/OP-UX-5.md + design/WORKSPACES.md §0
OP-UX-6	Überfällige Anlieferung = Klärfall (abgeleitet) + Auftragsstorno (abbrechen mit Pflicht-Grund)	ops/OP-UX-6.md
OP-ORTUNG-1	Echte Live-Ortung: Mitarbeiter (Handy/BLE) + Fahrzeuge (BLE/RFID/UWB) fürs Hof-Radar (heute aus Plan & Belegung abgeleitet)	ops/OP-ORTUNG-1.md
OP-ORTUNG-2	„Standort unbekannt“ = Klärfall + Skill „Fahrzeug finden“ (analog Umparken-Flow; Hardware-loser Fallback zu OP-ORTUNG-1)	ops/OP-ORTUNG-2.md
OP-KOMM-1	Broadcast-Nachrichten ans Team: Durchsagen + Rückfragen mit Kurz-Antwort (One-to-many, kein Chat; Klärfall-anbindbar)	ops/OP-KOMM-1.md
OP-QS-GATE	QS-Vollständigkeits-Gate vor der Abholung (server-hart) + Nacharbeit als QS-Phasen-Schritt	architektur/Operative-Durchgaengigkeit.md
OP-QS-4	QS-Nacharbeit direkt als zuweisbarer Prozessschritt (einstufig, überschreibbare Zeit) + manuelle Zuweisung + Leistungs-Schwellwerte (normal/gesteigert/extrem)	architektur/Operative-Durchgaengigkeit.md
OP-QS-5	Mangel/Nacharbeitsschritt-Dedup — Nacharbeitsschritt = Single Source der Dauer (Mangel bleibt eigenständig, referenziert; Bewertung liest step-authoritativ)	architektur/Operative-Durchgaengigkeit.md
OP-QS-6	Vier-Augen-Prinzip beim Quality-Check hart durchsetzen (Ausführender prüft nie die eigene Arbeit; G-4-Ausnahme)	fachlich/Lastenheft.md §11.1
OP-UMPARK-1	Umparken als zuweisbare Aufgabe, G-4-konform platziert (DO-State + Broadcast + Queue statt client-lokalem Transit)	fachlich/Lastenheft.md §11.1
OP-UMPARK-2	Bucht-Sperre & Bucht-Freiräumen — geparktes Fahrzeug in gesperrter Bucht muss umgeparkt werden (Konflikt geparkt_gesperrt; Slice A gebaut)	ops/OP-UMPARK-2.md + fachlich/Lastenheft.md §11.1
OP-SCHICHT-1	Schicht-Ende-Aufräumen — hochwertige Fahrzeuge in die Halle (konfigurierbar), nächste Schicht vorbereiten, möglichst wenig über Nacht in Arbeit außer Cool-down	ops/OP-SCHICHT-1.md + fachlich/Lastenheft.md §11.1
OP-OFFLINE-1	Offline-Fähigkeit als PWA (Service Worker · Read-Offline-Cache · Upload-Queue)	architektur/Offline-PWA.md
OP-OFFLINE-2	Background Sync — Foto-Uploads nach Tab-Schließen abschließen	architektur/Offline-PWA.md
OP-R4-3	Schritt-Doku & Kommentare (Pflicht-Kommentar F14 · Foto-Mindestanzahl F15 · inhaltlicher Aspekt-Leitfaden F16)	architektur/Doku-und-Kommentare.md
OP-DIKTAT-1	Sprach-Diktat für Kommentare/Doku (Transkription statt Tippen)	architektur/Doku-und-Kommentare.md
OP-TEXTBLOCK-1	Textbausteine für Kommentare/Doku (kuratierte, ein-tippbare Bausteine je Schritt/Aspekt)	architektur/Doku-und-Kommentare.md
OP-ABSCHLUSS-1	Auftrags-Abschluss-Notiz (separate Doku-/Übergabe-Notiz auf Auftrags-Ebene, eigene Pflicht/Aspekte)	architektur/Doku-und-Kommentare.md
OP-COMPETE-1	Wettbewerbsanalyse (Landschaft · Differenzierung · SWOT)	produkt/Wettbewerbsanalyse.md
OP-MARKET-1	Marktabschätzung & Markteintrittsstrategie (TAM/SAM/SOM · Beachhead · Go-to-Market)	produkt/Markt-und-Markteintritt.md
OP-VERTRIEB-1	Vorteilsrechner (ROI) für den Vertrieb (✅ v1 umgesetzt)	ops/OP-VERTRIEB-1.md · Lastenheft §11.6
OP-VERTRIEB-2	Akquise-/Orga-Tool für Anbahnungen — Build vs. Buy (z. B. Hubspot, noch offen)	ops/OP-VERTRIEB-2.md · Lastenheft §11.6
OP-VERTRIEB-3	Verbindlicher Meilensteinplan bis zum Produktivbetrieb	ops/OP-VERTRIEB-3.md · Lastenheft §11.6

Pflege. Bekommt ein OP ein eigenes Dokument (oder zieht um), hier die Zeile ergänzen/ anpassen. Die OP-ID selbst ist immer ein Markdown-Sprung-Link (ID in eckigen, Owning-Doc in runden Klammern) → ein Klick springt direkt ins Owning-Dokument (kein Umweg über die Detail-Spalte). Diese Tabelle ist kurz und kuratiert — kein Voll-Index aller OPs (das wäre Doppelpflege zur generierten Offene-Punkte.md). Der mechanische Check (scripts/check-doc-consistency.sh) erinnert nur an Vollständigkeit der Landkarte/Frontmatter, nicht an diese Tabelle.