PageHeader — Cross-App-Sync

Zielbild

manifest.ts (pro App)
    → @addxion/xi/nav  resolveSection(manifest, pathname)
    → @addxion/shell   PageHeader (Layout, Spacing, Slots)
    → @addxion/neon    Tokens, Typografie

Schicht	SSOT	Verantwortung
Layout & Verhalten	@addxion/shell	Spacing, Tab-Regeln, Slots, Animationen
Styling	@addxion/neon	Tokens, Typografie, Farben
Seitentitel	manifest.ts pro App	label der aktiven Section
Titel-Auflösung	@addxion/xi/nav	resolveSection(manifest, pathname)

süper und addxion.ai konsumieren dieselbe PageHeader-Komponente aus addxion-ai/packages/shell (extrahiert aus süper). Siehe Shell-Architektur.

Verhalten (fest in Shell)

• Tab-Seiten: nur Titel, kein Untertitel
• mb-3 am Header
• Titel ausschließlich über resolveSection, nie hardcodiert in Consumer-Layouts

Consumer-Wiring (dünn halten)

Apps verdrahten nur Manifest und Route. Keine Layout-Logik im Consumer:

import { PageHeader } from "@addxion/shell";
import { resolveSection } from "@addxion/xi/nav";
import { appManifest } from "@/manifest";

export function AppPageHeader({ pathname }: { pathname: string }) {
  const section = resolveSection(appManifest, pathname);
  return <PageHeader title={section?.label} />;
}

Erlaubt im Consumer: Routing-Hook, Manifest-Import, optionale App-Actions als Props (wenn Shell-API das vorsieht).

Nicht erlaubt im Consumer: eigene PageHeader-Implementierung, Spacing-Overrides, app-spezifische Untertitel-Logik.

Sync-Regeln

1. Keine lokalen PageHeader-Forks

Jede strukturelle Änderung (Padding, Back-Button, Actions-Slot, Untertitel-Regeln) gehört nur nach addxion-ai/packages/shell. Consumer-Repos (süper, addxion-ai) halten höchstens einen dünnen Wrapper — keine zweite Komponente mit Layout/CSS.

2. Inhalt nur im Manifest

// süper/src/manifest.ts  bzw.  addxion-ai/src/manifest.ts
sections: [
  { id: "theorie-pruefung", href: "/theorie-pruefung", label: "Theorie & Prüfung", nav: true },
],

Titel-Änderungen = nur manifest.ts der betroffenen App. Shell bleibt unberührt.

3. Gleiche Package-Version

Drift entsteht oft durch unterschiedliche @addxion/shell-Versionen in süper und addxion.ai.

Modus	Empfehlung
Lokal	"@addxion/shell": "file:../addxion-ai/packages/shell"
Release	Beide Apps im gleichen PR-Zyklus auf dieselbe Shell-Version bumpen

4. Framework-Adapter einheitlich

adapters/next und adapters/tanstack existieren in Shell. Beide Apps sollten denselben Adapter-Pfad nutzen — unterschiedliche Einbindung erzeugt subtile Verhaltensunterschiede trotz identischer Komponente.

5. Kein App-CSS auf Shell-Komponenten

Spacing und Typografie kommen aus Shell + Neon. className-Overrides oder brand.css-Hacks am Header führen zu visueller Drift.

Workflow bei Änderungen

Änderung	Wo	Folge
Layout, Spacing, Slots, Verhalten	addxion-ai/packages/shell	Version bump → süper + addxion.ai Dependency aktualisieren
Seitentitel, neue Tab-Labels	manifest.ts der App	Shell unverändert
Architektur-Entscheidung	addxion-docs	Diese Seite oder Shell-Architektur

Checkliste nach Shell-Änderung:

1. addxion-ai/packages/shell — Code
2. süper + addxion.ai — Dependency-Version
3. addxion-docs — shell/guidance/page-header.md bei neuen Regeln
4. Visuell in beiden Apps prüfen (gleiche Route-Struktur, unterschiedliche Titel)

Siehe auch Docs-Sync.

Drift-Audit

Wenn Header zwischen Apps abweichen:

1. Gibt es in süper oder addxion.ai noch eine lokale PageHeader-Implementierung?
2. Stimmen die @addxion/shell-Versionen überein?
3. Nutzen beide Apps den gleichen Framework-Adapter?
4. Gibt es CSS-Overrides am Header in Consumer-brand.css?

Anti-Patterns

Anti-Pattern	Folge
PageHeader in süper und addxion.ai parallel pflegen	Garantierte Drift
Titel in Layout/Route hardcoden	Sync unmöglich
Nav-Items im Header statt Manifest	Verletzt xi-nav-Vertrag
Shell-Versionen auseinanderlaufen lassen	Gleiche Komponente, anderes Verhalten
App-CSS auf Shell-Komponenten	Visuell „fast gleich“, aber nicht identisch

Verweise

• Navigation — Datenfluss Manifest → xi-nav → Shell
• Manifests — Section-Schema pro App
• Package-Grenzen — Was Shell enthält und nicht enthält

Truths

ID	Wahrheit
T-SHELL-PAGEHEADER	PageHeader-Struktur in Shell, Titel im Manifest
T-MAINTAIN	Einmal pflegen — keine Doppelpflege
T-NAV-MANIFEST	Nav aus manifest.ts + xi/nav

Für Agents

Scope: PageHeader strukturell in @addxion/shell, Titel pro App in manifest.ts.

• Keine lokalen PageHeader-Forks in süper oder addxion.ai
• Nach Shell-Änderung: beide Consumer auf gleiche @addxion/shell-Version
• Titel nur via resolveSection, nie hardcoden
• Leitprinzip: Einmal pflegen