Trenne allgemeine und projektspezifische Architektur

docs/technical_architecture.md

@@ -116,28 +116,6 @@ Verbindliche Regel:
 - wenn Text im DOM sichtbar ist, gilt er als GUI-String und unterliegt dieser Regel auch dann, wenn er clientseitig zusammengesetzt wird
 - zusammengesetzte UI-Texte duerfen keine fachliche Logik enthalten; sie kombinieren nur locale-gebundene Textbausteine mit stabilen technischen Werten
 
-### 2.5 GUI-/MCP-Paritaet
-
-Die MCP-Schnittstelle ist im Grundsatz funktional paritaetisch zur GUI. Ein
-MCP-Nutzer ist hinsichtlich der fachlichen Nutzung einem GUI-Nutzer
-gleichzustellen.
-
-Verbindliche Regel:
-
-- jeder fachliche Anwendungsfall, den ein GUI-Nutzer ausfuehren kann, muss auch
-  ueber die MCP-Schnittstelle ausfuehrbar sein
-- alle fachlichen Lese-, Anlege-, Aenderungs-, Archivierungs- und
-  Reaktivierungsmoeglichkeiten der GUI muessen im MCP-Interface abgebildet sein
-- GUI und MCP verwenden dieselben fachlichen Validierungen, Berechtigungen,
-  Statusregeln und Ownership-Grenzen; fachliche Logik darf nicht doppelt in
-  GUI und MCP implementiert werden
-- jede Erweiterung oder Aenderung eines GUI-Anwendungsfalls erfordert zwingend
-  die gleichzeitige Pruefung und, falls erforderlich, Anpassung des MCP-Interfaces
-- ein MCP-Nutzer darf gegenueber einem gleich berechtigten GUI-Nutzer weder
-  fachlich eingeschraenkt noch durch abweichende Regeln bevorzugt werden
-- die Paritaet betrifft die fachliche Funktion und den Datenzugriff, nicht die
-  visuelle Darstellung oder den Interaktionsablauf der GUI
-
 ## 3. Modulmodell
 
 ### 3.1 Zulaessige Modulbereiche
@@ -148,7 +126,6 @@ Fachliche Hauptmodule:
 - `ratings`
 - `groups`
 - `lists`
-- `market_management`
 
 Technische Modulbereiche:
 
@@ -203,6 +180,7 @@ Verbindliche Regel:
 
 - jede Tabelle, View, materialisierte View und DB-Funktion besitzt genau eine primaere Ownership
 - primaere Ownership folgt genau einem Hauptmodul oder einem technischen Shared-Bereich
+- fachliche Beziehungen sowie Ownership- und Berechtigungsschluessel verwenden stabile interne Entitaets-IDs; veraenderliche Attribute wie E-Mail, Username oder Anzeigename duerfen dafuer nicht verwendet werden
 - nur das owning Modul definiert Struktur, Write-Logik, Constraints und fachliche Semantik eines DB-Artefakts
 - direkte Cross-Modul-Writes in fremde Owned Tabellen sind verboten
 - andere Module duerfen fremde Artefakte nur ueber definierte Schnittstellen des owning Moduls nutzen
@@ -287,7 +265,7 @@ Prueffragen vor jeder Erweiterung:
 
 Verbindliche Regel:
 
-- neue Hauptmodule sind nur zulaessig, wenn eine neue fachliche oder technische Primaerverantwortung entsteht, die nicht sauber in `company`, `ratings`, `groups`, `lists`, `market_management`, `system` oder `shared` aufgeht
+- neue Hauptmodule sind nur zulaessig, wenn eine neue fachliche oder technische Primaerverantwortung entsteht, die nicht sauber in `company`, `ratings`, `groups`, `lists`, `system` oder `shared` aufgeht
 - neue Submodule sind nur zulaessig, wenn innerhalb eines bestehenden Hauptmoduls eine klar isolierbare Verantwortung mit eigener Schnittstelle entsteht
 - neue Prozess- und Sub-Prozess-Dokumente werden im owning Modulpfad angelegt und folgen `component.subcomponent.process_name`
 - `admin`, `public/api/`, `scripts/` oder `lib/` begruenden kein neues fachliches Hauptmodul
@@ -303,3 +281,38 @@ Verbindlich ist:
 - `docs/technical_architecture.md` ist der einzige aktive Architektur-Master des Repositories
 - andere Dokumente duerfen diese Architektur erklaeren, anwenden oder historisieren, aber keine konkurrierende Master-Struktur definieren
 - konkrete Inventare wie Tabellenlisten, Submodullisten, Prozesslisten oder Runtime-Artefakte werden in Detaildokumenten gepflegt und nicht hier dupliziert
+
+## 10. Projektspezifische Architekturvorgaben
+
+Dieses Kapitel enthaelt Architekturentscheidungen, die fuer dieses Projekt
+gelten und nicht Teil der allgemeinen, projektuebergreifend wiederverwendbaren
+Modularitaet sind.
+
+### 10.1 Fachliches Hauptmodul `market_management`
+
+Dieses Projekt besitzt zusaetzlich das fachliche Hauptmodul
+`market_management`. Seine fachliche Ownership, Datenstruktur und
+Schnittstellen werden in den Modulvertraegen unter
+`docs/modules/market_management/` dokumentiert.
+
+### 10.2 GUI-/MCP-Paritaet
+
+Die MCP-Schnittstelle ist im Grundsatz funktional paritaetisch zur GUI. Ein
+MCP-Nutzer ist hinsichtlich der fachlichen Nutzung einem GUI-Nutzer
+gleichzustellen.
+
+Verbindliche Regel:
+
+- jeder fachliche Anwendungsfall, den ein GUI-Nutzer ausfuehren kann, muss auch
+  ueber die MCP-Schnittstelle ausfuehrbar sein
+- alle fachlichen Lese-, Anlege-, Aenderungs-, Archivierungs- und
+  Reaktivierungsmoeglichkeiten der GUI muessen im MCP-Interface abgebildet sein
+- GUI und MCP verwenden dieselben fachlichen Validierungen, Berechtigungen,
+  Statusregeln und Ownership-Grenzen; fachliche Logik darf nicht doppelt in
+  GUI und MCP implementiert werden
+- jede Erweiterung oder Aenderung eines GUI-Anwendungsfalls erfordert zwingend
+  die gleichzeitige Pruefung und, falls erforderlich, Anpassung des MCP-Interfaces
+- ein MCP-Nutzer darf gegenueber einem gleich berechtigten GUI-Nutzer weder
+  fachlich eingeschraenkt noch durch abweichende Regeln bevorzugt werden
+- die Paritaet betrifft die fachliche Funktion und den Datenzugriff, nicht die
+  visuelle Darstellung oder den Interaktionsablauf der GUI