_meta
Spec Drift
Divergenzen zwischen ausgeliefertem Verhalten und FEATURE-LIST.md
Stand: 2026-04-17.
Nur Fälle, in denen das ausgelieferte Verhalten von FEATURE-LIST.md abweicht. "Noch nicht gebaut" gehört nicht hierher (siehe coverage.md), sondern nur echte Divergenzen zwischen Spezifikation und Code.
2.2 People Profiles — Aktivitäts-Timeline
- Spec: Chronologische Timeline aller Interaktionen (Gruppen, Events, Formulare, Spenden, Notizen, Kommunikation) auf dem Profil.
- Code: Personen-Detailseite hat Tabs (Profil, Verlauf). Keine aggregierte Timeline-Ansicht.
- Konsequenz: Dokumentation beschreibt die Tab-Struktur, nicht die Timeline.
2.3 People Categories — Single-Select
- Spec: "Eine Person kann genau eine Kategorie haben (Single-Select)."
- Code: Das UI-Formular in
/people/$personIdbietet Kategorie als Single-Select; Status wird separat als zweite Dimension geführt. Die Spec unterscheidet zwischen Kategorie (2.3) und Status (2.5), der Code ebenfalls. - Konsequenz: Keine echte Drift, aber Nutzer könnten Kategorie und Status verwechseln. In der Doku als zwei getrennte Konzepte erklären.
6.4 Service Teams vs. Groups OS
- Spec: Service Teams sind eine eigenständige Entität (eigenes DB-Schema, Positionen, Skill-Matrix). Klar getrennt von Community-Gruppen.
- Code: Umgesetzt —
teamsundgroupssind getrennte Tabellen mit eigenen Routen. Positionen nur auf Teams. - Konsequenz: Keine Drift. In der Doku früh unterscheiden, damit Admins Teams nicht in Groups anlegen.
6.7 Song Database — Transponieren
- Spec: Tonart ändern, Chords automatisch anpassen.
- Code: i18n-Keys
songs.transpose.*vorhanden, aber Transpose-UI in Web und Mobile im Audit nicht bestätigt. Chord Chart wird als Text-Field angezeigt. - Konsequenz: Dokumentiert wird nur das Anzeigen und Bearbeiten des Chord Charts. Transponieren als nicht verfügbar markieren (Callout).
6.8 Service Templates — Inhaltsumfang
- Spec: Template enthält Reihenfolge der Elemente (Song, Predigt, Gebet), zugewiesene Teams/Positionen, Zeitangaben pro Element, Notizen pro Element.
- Code: Template-Formular (
templates.form.*) enthält Name, Beschreibung,defaultDescription. Elemente-Struktur im Template-Editor nicht sichtbar (Zeitleiste ist am Service selbst, nicht am Template). - Konsequenz: Templates in der Doku als leichtgewichtige Vorlage (Titel + Standardbeschreibung) beschreiben. Das detaillierte Orchestrieren passiert auf Service-Ebene.
6.10 Sunday Planning Module — Wochenansicht
- Spec: Wochenansicht mit allen Services einer Woche, Multi-Service-Planung.
- Code:
/serviceszeigt Grid- und Wochenansicht. Multi-Service-Planung am selben Tag über Anlage mehrerer Services; kein dedizierter Multi-Service-Editor. - Konsequenz: Dokumentieren als "mehrere Services pro Tag werden als separate Einträge angelegt".
10.9 Aufgaben-Management — Zuweisung an Rolle
- Spec: Aufgabe zugewiesen an Person oder Rolle.
- Code: Task-Formular zeigt nur
assignee(Person). Rollen-Zuweisung nicht bestätigt. - Konsequenz: Dokumentieren nur Personen-Zuweisung.
1.1 Mehrsprachige Plattform — System-Emails in Empfänger-Sprache
- Spec: System-Emails in der Sprache des Empfängers.
- Code: Sprachwahl pro User vorhanden. Ob Email-Templates dynamisch pro Empfänger-Sprache geladen werden, ist nicht verifiziert — nur DE-Locale ist vollständig.
- Konsequenz: Dokumentieren: DE als einzige vollständig unterstützte Sprache zum aktuellen Stand.
1.5 2FA — Organisations-weite Erzwingung
- Spec: Admins können 2FA für die Org oder für bestimmte Rollen erzwingen, mit Grace Period und Recovery Codes.
- Code:
/me/account/two-factorfür Einzelnutzer vorhanden. Org-weite Erzwingungs-UI nicht im Audit gefunden. - Konsequenz: Dokumentieren nur als persönliche 2FA-Einrichtung.
2.10 Duplikate-Erkennung — Merge-Assistent
- Spec: Beim Merge wird pro Feld entschieden, welcher Wert übernommen wird.
- Code:
/settings/church/duplicatesliefert Duplikat-Liste. Der feldweise Merge-Dialog ist im Audit angezeigt, Feld-Auswahl-UI nicht eindeutig belegt. - Konsequenz: Funktionalität grob beschreiben; Details aufnehmen, sobald UI-Screenshot vorliegt.
9.5 Conditional Logic in Formularen
- Spec: Dynamisches Ein-/Ausblenden von Feldern basierend auf Bedingungen (UND/ODER).
- Code: Im Form-Builder-Audit nicht eindeutig gefunden. Feld-Palette enthält Standardtypen, keine Condition-Node.
- Konsequenz: Feature als "nicht verfügbar" dokumentieren (Callout). Wird über Workflows teilweise ersetzt.