iglesio Docs
_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/$personId bietet 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 — teams und groups sind 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: /services zeigt 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-factor fü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/duplicates liefert 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.

On this page