Document validation architecture and renderer faithfulness findings

- document Entity Registry and Meeting Context V2 architecture
- preserve meeting_context.yaml as the authoritative meeting-specific input
- define immutable authoritative metadata across all pipeline stages
- restrict Constraint Repair to deterministic structured-data operations
- record BUG-003 root cause and deferred entity-verification resolution
- document BUG-005 attendance-consistency design
- add BUG-006 renderer faithfulness root-cause analysis
- distinguish Engineering Readiness from Practical Usability
- update the persistent regression bug tracker

README.md

@@ -114,6 +114,17 @@ optional validieren, als autoritative Metadaten in den Prompt aufnehmen und
 minimale Kontext-Provenienz im Extraction JSON speichern. Konsolidierung,
 Canonical Meeting Knowledge und Rendering sind noch nicht daran angeschlossen.
 
+Als akzeptierte, aber noch nicht implementierte Architektur soll Meeting
+Context V2 kuenftig nicht mehr primaer manuell geschrieben werden. Nach Whisper
+soll ein Entity-Detection- und User-Confirmation-Schritt unbekannte Namen und
+Begriffe sichtbar machen. Bestaetigte Entitaeten werden in einer persistenten
+Entity Registry als cross-meeting Wissensquelle mit stabilen internen IDs,
+Anzeigenamen und Aliasen gepflegt. Aus Registry, Nutzerbestaetigungen und
+Meeting-Metadaten erzeugt ein Meeting Context Builder dann das
+meeting-spezifische `meeting_context.yaml`. Diese YAML-Datei bleibt der
+authoritative meeting-spezifische Point of Truth und ein reproduzierbares
+Input-Artefakt fuer den jeweiligen Pipeline-Lauf.
+
 Der gemeinsame Extraktionsprompt besteht aktuell aus `common.md`,
 `decisions.md` und `todos.md`. Die Todo-Regeln verlangen explizite Zuweisung,
 Freiwilligenmeldung oder Annahme, bevor eine verantwortliche Person gesetzt