Erweiterbarkeit — Spezial-Tools (A-6)

Bezug: A-6, R10, OP-EXT-1 · Status: Architektur-Konzept (erstes Tool: Dexman, docs/spezialtools/Dexman.md).

Warum

Medidentas ist die koordinierende Kern-Plattform für den Kunden-Lebenszyklus (Onboarding · Dokumente · Unterschriften · Wiedervorlagen · Beratungsdoku). Darüber hinaus soll sie um fachliche Spezial-Tools erweiterbar sein, die je Kunde/Mandant zusätzlichen Wert liefern — das erste ist Dexman (Praxis- Rentabilität, Umsatzprognose, Behandler-Feedback). Ziel: Tools andocken statt den Kern aufblähen — konsistent zu G-1 (Standardwerkzeuge/Module wiederverwenden) und G-2 (eine Quelle der Wahrheit).

Begriff: „Spezial-Tool"

Ein Spezial-Tool ist eine fachlich abgeschlossene, optional zubuchbare Fähigkeit, die in den Medidentas-Kern eingehängt wird. Es nutzt den Mandanten-Kontext (R1), die Identität/Rollen (R7), das Audit-Log (R8) und die Integrations-Schicht (R9) des Kerns und bringt eigene Datenquellen, eigene Auswertungslogik und eigene Oberflächen mit. Beispiele: Dexman (Controlling/Prognose), Dentmarking (Vorstufe zu Dexman — Daten sammeln + auswerten, niedrigschwelliger Einstieg; OP-DENTMARK-1), künftig denkbar weitere (z. B. Marketing-/Recall-Tool, Personal-Tool).

R10 — Tool-Host & Registry (neues Kern-Modul)

Der Kern bekommt ein schlankes Modul R10, das Tools registriert, aktiviert (je Mandant/Tenant) und isoliert. Es ist bewusst dünn: keine Fachlogik, nur Vertrag + Lebenszyklus + Sichtbarkeit.

Der Tool-Vertrag (Manifest)

Jedes Tool meldet sich mit einem Manifest an. Felder (Arbeitsstand, finalisiert mit OP-EXT-1):

Feld	Bedeutung
id	eindeutige Tool-ID (lowercase), z. B. dexman
name / beschreibung	sprechender Anzeigename (G-3)
signaturfarbe	eigene Akzentfarbe je Tool (Wiedererkennbarkeit)
benoetigte_scopes	welche Kern-Daten das Tool lesen/schreiben darf (least-privilege, R7)
datenquellen	externe Quellen, die das Tool über R9 anbindet (z. B. PVS, DATEV, Bank)
surfaces	wo das Tool sichtbar wird: Cockpit-Kachel(n) + eigener Workspace + Berichte
events_abonniert	Kern-Events, auf die das Tool reagiert (z. B. „Mandant aktiviert")
persistenz_namespace	eigener, isolierter Datenraum des Tools
lizenz/aktivierung	je Mandant/Tenant zubuchbar (Feature-Flag)

Prinzipien (verbindlich)

1. Isolation: Jedes Tool hat einen eigenen Persistenz-Namespace. Tools greifen nicht direkt auf die Daten anderer Tools oder auf interne Kern-Tabellen zu — nur über die Kern-API und die im Manifest deklarierten Scopes. (Verhindert Kopplung + Cross-Tool-Leaks.)
2. Mandanten-/Tenant-Grenze gilt auch für Tools: Ein Tool sieht nur Daten der Mandanten/Tenants, für die es aktiviert ist (R7-Authz je Request) — kein Cross-Tenant-Zugriff (vgl. RISK-10).
3. Audit & Compliance erben: Tool-Aktionen schreiben ins zentrale Audit-Log (R8, G-4); Tools unterliegen denselben Datenschutz-Regeln (G-5) — insbesondere bei Gesundheits-/Personaldaten (siehe Dexman-Compliance).
4. True-North-Beitrag oder eigener, klar benannter Zweck: Ein Tool beantwortet entweder eine der drei Kern-Leitfragen direkter — oder hat einen eigenen, dokumentierten Zweck mit eigenen Leitfragen (Dexman: Rentabilität/Prognose/Reserven). Kein Tool ohne klaren Wertbeitrag.
5. Surfaces, nicht Sonderwege: Tools erscheinen über definierte Surfaces (Cockpit-Kachel, eigener Workspace, Bericht) — sie umgehen nicht die Kern-Navigation/-Auth.
6. Optional & entkoppelt: Der Kern funktioniert ohne jedes Tool; ein Tool-Ausfall darf den Kern nicht beeinträchtigen (lose Kopplung, eigene Fehlertoleranz).

Lebenszyklus

Verhältnis zum Kern-Datenmodell

• Der Mandant (R1) bleibt der gemeinsame Anker. Ein Tool referenziert den Mandanten (mandant_id) und legt seine fachlichen Daten im eigenen Namespace ab — es dupliziert keine Kern-Stammdaten (G-2, analog S-1/S-2).
• Derived State (z. B. eine Kennzahl) wird vom Tool abgeleitet, nicht doppelt im Kern gespeichert.

Offene Punkte

• OP-EXT-1: Finaler Tool-Vertrag (Manifest-Schema, Scope-/Event-Katalog, Persistenz-Isolation, Aktivierungs-/Lizenzmodell) — hängt an OP-STACK-1 (Persistenz/Runtime) und OP-AUTH-1 (Rollen/ Scopes).
• OP-EXT-2: UI-Surface-Konvention (Cockpit-Kachel-Vertrag, eigener Workspace, Signaturfarbe) — abzustimmen mit dem (noch offenen) Design-System.