K-33-Tabellen-Arbitrage — welche Implementierung ist der Kanon?

Entscheidungs-Dossier (E-1-Muster) · SCREEN-FERTIG-Lane 02.08.2026 · Entscheid: JC/Tower · aufgetaucht beim E-36-Inhalt-Port, nicht vorher sichtbar

Lage

Der Baustein K-33 „data-table" existiert zweimal — beide gebaut, beide live, beide als K-33 geführt. Beim Port der Dokumente-Sektion in die Shell (E-36, Auflage 2) fiel es auf: Das Zeilen-⋯-Menü (K-40) und der Detail-Knopf je Zeile hängen an einer der beiden — die Shell-Sektion kann sie nicht bekommen, ohne die Tabelle zu wechseln.

Warum das jetzt entschieden werden muss: Wer den Port ohne Entscheid weiterbaut, erzeugt entweder eine dritte Variante oder kopiert Funktionen quer — genau die Doppelführung, die zuletzt bei der Geheimhaltungs-Pille aufgeräumt wurde. Diese Lane baut deshalb nicht weiter am Tabellen-Teil, bis der Entscheid steht.

A — TGVEngine.dataTableFullEmpfehlungengine.js (SSOT)9 Surfaces

Fähigkeit	Stand
Zeilen-⋯-Menü (K-40)	ja — `rowMenu`/`onRowMenu`
Detail-Knopf je Zeile	ja — `rowAction`
Spaltenbreiten-Griff (E-25 B1.9)	ja
Multiselect + Bulk	ja
Suche · Sortierung · Pager · Vollbild	ja
Filter-Slot	ja — `filters`

Wer nutzt sie: dokumente2 · abgleich2 · rka2 · fragekai2 · inbox2 · versand2 · rka_chat · katalog · vertical_slice — und core_shell an einzelnen Stellen bereits auch.
Dafür: liegt in der Design-SSOT (engine.js), wird von allen Kanon-Screens genutzt, trägt die jüngsten JC-Entscheide (K-40-Zeilenmenü, Spaltengriff). Dagegen: die Shell müsste ihre 14 Aufrufstellen umstellen — Aufwand + Regressionsrisiko in Live-Finanz-Screens (phasiert nötig).

B — fxDataTablecore_shell-intern14 Aufrufe

Fähigkeit	Stand
Zeilen-⋯-Menü (K-40)	nein
Detail-Knopf je Zeile	nein (nur Zeilen-Klick `onRow`)
Spaltenbreiten-Griff	nein
Multiselect + Bulk	ja
Suche · Sortierung · Pager · Vollbild	ja
Zeilen-Klassen	ja — `rowCls`

Wer nutzt sie: ausschließlich core_shell (14 Stellen: Dokumente, Buchungen, Verträge, Monatsabschluss, Buchhalter-Paket …).
Dafür: kein Umbau der Live-Finanz-Screens nötig. Dagegen: ihr fehlen die zuletzt beschlossenen Kanon-Features — sie müssten nachgebaut werden, also dieselbe Funktion ein zweites Mal. Genau das Muster, das wir gerade abschaffen.

Konkrete OK-Frage

OK zu A — dataTableFull ist der K-33-Kanon, fxDataTable wird phasiert abgelöst (Screen für Screen, jeder mit Gegenprobe „gleiche Spalten, gleiche Zahlen"), beginnend bei der Dokumente-Sektion?

A · dataTableFull = Kanon, fxDataTable phasiert ablösen (Empfehlung: die Kanon-Entscheide leben dort, sonst baut man sie zweimal)
B · fxDataTable bleibt in der Shell, fehlende Features werden dort nachgebaut (kein Umbau, aber bewusst zwei Implementierungen auf Dauer)
C · Zwischenweg: fxDataTable bekommt nur rowMenu+rowAction, alles andere bleibt getrennt (kleinster Eingriff, Doppelführung bleibt)

Quellen

K-33 data-table (SSOT-Def) · K-40 file-actions · Shell-Dokumente (nutzt B) · dokumente2 (nutzt A) · JC_ENTSCHEIDE (E-25 B1.8/B1.9 · E-31 · E-36)

Gemessen 02.08. an beiden Implementierungen (Options-Vergleich + Nutzer-Zählung), nicht geschätzt.