Einmal pflegen

Ökosystem-Prinzip — doppelte Pflege in mehreren Projekten vermeiden, systematisch vereinfachen.

Truth: T-MAINTAIN — kanonische Formulierung in der Truth-Registry. Diese Seite ist die Ausarbeitung (Entscheidungsbaum, Strategien, Beispiele).

Ausarbeitung

Statt …	Lieber …
Dieselbe Komponente in süper und addxion.ai pflegen	Einmal in `@addxion/shell`, beide konsumieren
Auth-Schema pro App	Einmal in `@addxion/auth`
Nav-Listen in Layout-Komponenten	Einmal in `manifest.ts` + `@addxion/xi/nav`
Package-Grenzen in jedem MASTERPLAN	Einmal in addxion-docs, Produkt-Pläne verlinken
Schneller Fork im Consumer	Extraktion planen und Shared Package erweitern

Entscheidungsbaum

Bevor du etwas in einem Consumer-Repo implementierst:

Kommt dieselbe oder ähnliche Logik/UI schon woanders vor?
  ├─ Ja → Gibt es ein Shared Package dafür?
  │         ├─ Ja → Dort erweitern, Consumer nur verdrahten
  │         └─ Nein → Extraktion planen (Package anlegen oder Subpath)
  └─ Nein → Bleibt produktspezifisch (MASTERPLAN des Produkts)

Produktspezifisch bleibt: Domänenlogik (Fahrstunden, Analysen-Prompts), Marken-Copy, app-eigene DB-Tabellen. Geteilt gehört: Identity, Design-Tokens, Shell-UI, Nav-Infrastruktur, LLM-Client, Plattform-Docs.

Bevorzugte Strategien

1. Extraktion in Shared Packages

Wiederkehrende UI oder Logik wandert in das passende Package — nicht in den nächsten Consumer kopiert.

Bedarf	Ziel
Layout, Chat, Gates	`@addxion/shell`
Nav, Cross-App-Protokoll	`@addxion/xi`
Scroll, Haptics	`@addxion/behavior`
Tokens, Primitives	`@addxion/neon`
Session, Grants	`@addxion/auth`
Streaming, Message-Typen	`@addxion/ai`

Referenz: Package-Leitfaden, Package-Grenzen.

2. SSOT pro Ebene

Jede Wahrheit hat eine Heimat. Andere Ebenen verlinken, nicht duplizieren.

addxion-docs          → Plattform-Wahrheit (Packages, Architektur)
manifest.ts pro App   → Nav- und PageHeader-Inhalt
@addxion/shell        → PageHeader-Struktur
brand.css pro Consumer → Markenwerte

Siehe Docs-Sync, Repo Boundaries.

3. Dünne Consumer, dicke Packages

Consumer-Repos verdrahten nur: Manifest, Routing, Domänenfeatures. Keine zweite Implementierung mit Layout- oder Nav-Logik.

Beispiel: PageHeader — Cross-App-Sync.

4. Systematische Vereinfachung vor Quick-Fix

Wenn zwei Apps divergieren, ist die richtige Frage nicht „wie halten wir beide Versionen gleich?“, sondern:

Was ist die gemeinsame Abstraktion?
Welches Package oder welcher Vertrag eliminiert die Doppelpflege?
Lohnt sich die Extraktion jetzt — oder dokumentieren wir bewusst als temporäre Ausnahme mit Exit-Plan?

Kurzfristige Duplikate ohne Exit-Plan gelten als technische Schuld.

Typische Extraktions-Signale

Signal	Typische Lösung
Gleiche Komponente in 2+ Apps	`@addxion/shell` oder `@addxion/neon`
Gleiche Nav-Filterlogik	`@addxion/xi/nav`
Gleiche Scroll-Regeln im Chat	`@addxion/behavior`
Gleiche Docs-Tabellen in MASTERPLANs	addxion-docs + Verlinkung
Gleiche Env-/Deploy-Muster	Pattern-Doc in addxion-docs
Statische Snapshots (z. B. federated manifests)	Automatisierung oder Runtime statt manueller Kopie

Anti-Patterns

„Schnell in süper bauen, später nach addxion.ai portieren“ ohne Package-Plan
Package-Tabellen in Produkt-MASTERPLANs duplizieren
Consumer-Wrapper mit eigener Layout-Logik statt Shell-Erweiterung
Sync per Copy-Paste oder manuellem Abgleich zwischen Repos
Temporäre Duplikate ohne Ticket/Roadmap-Eintrag für Extraktion

Checkliste vor Merge (Ökosystem-relevant)

Existiert dieselbe Logik/UI bereits in einem anderen Repo?
Wenn ja: Shared Package erweitert statt Consumer dupliziert?
SSOT-Ebene klar (Docs, Package, Manifest, Produkt)?
Bei bewusster Ausnahme: Roadmap- oder MASTERPLAN-Eintrag mit Exit-Plan?
addxion-docs aktualisiert, wenn Grenzen oder Architektur sich ändern?

Verweise

ADDXION Ökosystem — North Star und Schichtenmodell
Roadmap — Extraktions-Phasen und offene Konsolidierung
Navigation — Drei getrennte Nav-Schichten, eine Shell
PageHeader — Cross-App-Sync — konkretes Beispiel

Truths

ID	Wahrheit
T-MAINTAIN	Einmal pflegen — keine Doppelpflege
T-TRUTHS-SSOT	Truths-Registry — referenzieren, nicht duplizieren
T-PKG-BOUNDARY	Package-Grenzen nicht ohne Vertrag überschreiten

Für Agents

Scope: Ökosystem-Prinzip — doppelte Pflege in mehreren Projekten vermeiden.

Vor Consumer-Implementierung prüfen: existiert Logik/UI schon woanders?
Bevorzugt Shared Package erweitern, nicht kopieren
Temporäre Duplikate nur mit Exit-Plan in Roadmap oder MASTERPLAN
Konkretes Beispiel: PageHeader — Cross-App-Sync