Abschlussquote-Familie N2 — zwei Dashboard-Vorlagen, zehn Kacheln
Die zweite Bauart des Reporting-Umzugs nach dem E-Mail-Trichter (M1):
`assignment-appointments` und `assignment-events`, die Stufe 4 als falsch
einsortiert nachgewiesen hat (Matrix-Befund B4). Beide standen im Ledger auf
`covered-by-template` OHNE Beleg.
Je Achse fuenf Vorlagen: zwei Zaehler, die Abschlussquote, ein Ring nach dem
Verknuepfungs-Zustand und eine Uebersicht mit zwei Spalten.
Sechs gemessene Befunde bestimmen die Bauform:
- Der Ring geht NICHT nach `type`. In der Alt-Antwort ist `chart[].type` ein
Beschriftungs-Text, kein Feld; `calendarentries.typ` ist bei 13.477 von
13.492 `standard` — das waere ein Ring mit einem Segment.
- Das Zeitfenster ist ZWEISEITIG (sieben Tage bis morgen, wie die
Alt-Steuerung). Ohne Obergrenze faellt es auf 1.639 statt 22 Termine,
Faktor 74. M1 durfte die Obergrenze weglassen, weil Kennzahl-Zeilen nicht
in der Zukunft liegen — Termine schon.
- Die Verknuepfung braucht die Unter-Pipeline-Form MIT `_customerID`, also das
Gegenteil der M1-Regel: der Pruefer weist ein `$lookup` ueber ein
Nicht-`_id`-Feld sonst als moeglichen mandanten-uebergreifenden Lesezugriff
ab. Auf der obersten Ebene bleibt der Vergleich weiterhin verboten.
- Der Mandanten-Vergleich ist typ-tolerant (`$toString` beidseitig) —
`assignments._customerID` ist gemischt typisiert (96 Objekte, 1 Zeichenkette).
- Der Alt-Feldname `attendees_tookPart.attendee` ist gebrochen (das Schema
kennt nur `_attendee`) und hier korrigiert, nicht portiert.
- Die Alt-Beschriftungen sind irrefuehrend: `stats.total` zaehlt die
Basis-Menge, nicht das, was das Etikett sagt.
Beide Verknuepfungs-Achsen sind im Bestand leer (`assignments.calendarentry`
bei 0 von 97, `meetings.attendees_tookPart` bei 0 von 32) — beide Quoten stehen
auf 0 %. Dass die Rechnung traegt, ist mit drei Positiv-Kontrollen belegt:
dieselbe Quoten-Pipeline mit gelockerter Verknuepfung rechnet 57,5 %, die
Veranstaltungs-Verknuepfung ohne den Teilnehmer-Vergleich findet 21 von 97, und
`$in` ueber einen gepunkteten Listen-Pfad trifft 89 Dokumente.
35 neue Proben, reine Reihe 225/225 ueber 12 Suiten. Sieben Flip-Proben, sechs
beissen; die siebte (`RING_SPALTEN` 5 -> 8) beisst zu Recht NICHT, weil sie
keine Verletzung erzeugt. Eine Flip-Probe hat eine eigene Probe als zu schwach
entlarvt (`let: {cid: "$_customerID"}` enthaelt die Zeichenkette schon) — die
nachgeschaerfte Probe haelt jetzt den Vergleich selbst fest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`assignment-appointments` und `assignment-events`, die Stufe 4 als falsch
einsortiert nachgewiesen hat (Matrix-Befund B4). Beide standen im Ledger auf
`covered-by-template` OHNE Beleg.
Je Achse fuenf Vorlagen: zwei Zaehler, die Abschlussquote, ein Ring nach dem
Verknuepfungs-Zustand und eine Uebersicht mit zwei Spalten.
Sechs gemessene Befunde bestimmen die Bauform:
- Der Ring geht NICHT nach `type`. In der Alt-Antwort ist `chart[].type` ein
Beschriftungs-Text, kein Feld; `calendarentries.typ` ist bei 13.477 von
13.492 `standard` — das waere ein Ring mit einem Segment.
- Das Zeitfenster ist ZWEISEITIG (sieben Tage bis morgen, wie die
Alt-Steuerung). Ohne Obergrenze faellt es auf 1.639 statt 22 Termine,
Faktor 74. M1 durfte die Obergrenze weglassen, weil Kennzahl-Zeilen nicht
in der Zukunft liegen — Termine schon.
- Die Verknuepfung braucht die Unter-Pipeline-Form MIT `_customerID`, also das
Gegenteil der M1-Regel: der Pruefer weist ein `$lookup` ueber ein
Nicht-`_id`-Feld sonst als moeglichen mandanten-uebergreifenden Lesezugriff
ab. Auf der obersten Ebene bleibt der Vergleich weiterhin verboten.
- Der Mandanten-Vergleich ist typ-tolerant (`$toString` beidseitig) —
`assignments._customerID` ist gemischt typisiert (96 Objekte, 1 Zeichenkette).
- Der Alt-Feldname `attendees_tookPart.attendee` ist gebrochen (das Schema
kennt nur `_attendee`) und hier korrigiert, nicht portiert.
- Die Alt-Beschriftungen sind irrefuehrend: `stats.total` zaehlt die
Basis-Menge, nicht das, was das Etikett sagt.
Beide Verknuepfungs-Achsen sind im Bestand leer (`assignments.calendarentry`
bei 0 von 97, `meetings.attendees_tookPart` bei 0 von 32) — beide Quoten stehen
auf 0 %. Dass die Rechnung traegt, ist mit drei Positiv-Kontrollen belegt:
dieselbe Quoten-Pipeline mit gelockerter Verknuepfung rechnet 57,5 %, die
Veranstaltungs-Verknuepfung ohne den Teilnehmer-Vergleich findet 21 von 97, und
`$in` ueber einen gepunkteten Listen-Pfad trifft 89 Dokumente.
35 neue Proben, reine Reihe 225/225 ueber 12 Suiten. Sieben Flip-Proben, sechs
beissen; die siebte (`RING_SPALTEN` 5 -> 8) beisst zu Recht NICHT, weil sie
keine Verletzung erzeugt. Eine Flip-Probe hat eine eigene Probe als zu schwach
entlarvt (`let: {cid: "$_customerID"}` enthaelt die Zeichenkette schon) — die
nachgeschaerfte Probe haelt jetzt den Vergleich selbst fest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>