Der Status kommt aus den Daten, nicht aus der Spalte

Die Liste filterte ueber die Datumsspalten, beschriftete die Zeilen aber mit
employees.status. Sobald die Spalte nachhaengt, widersprechen sich die
beiden — und sie haengt regelmaessig nach: terminate_employee setzt sie nur,
wenn das Austrittsdatum nicht in der Zukunft liegt, und es gibt keinen Lauf,
der das spaeter nachzieht (Migration 20260814100000 sagt das selbst).

Beim Kunden waren beide Richtungen zu sehen. Der Filter "Ausgetreten" fand
48 Personen, von denen mehrere als "Aktiv" beschriftet waren; der Filter
"Geplant" zeigte Nichtantritte, deren Spalte laengst "Ausgetreten" trug.

StatusChip nimmt deshalb jetzt die Zeile und den Stichtag und leitet selbst
ab. Die Spalte laesst sich nicht mehr hineinreichen — die zweite Quelle ist
nicht bloss ungenutzt, es gibt sie an dieser Stelle nicht mehr.

Dazu drei Stellen, die an derselben Spalte hingen:

  * Die Akte entschied mit ihr ueber die Knoepfe. An einer Person, die seit
    zwei Wochen ausgetreten ist, stand "Austritt" weiter zur Verfuegung.
  * Die Sortierung nach Status ordnete nach einem Wert, der nirgends auf der
    Seite steht.
  * Die Karte "Anstehend" zaehlte kuenftige Eintritte und Rueckkehren ueber
    die Spalte und damit anders als die Liste, auf die sie verlinkt.

Und eine Klausel, die in der Ableitung fehlte: ein Nichtantritt traegt als
Austrittsdatum den Eintrittstag. Liegt der in der Zukunft, ist auch der
Austritt groesser als der Stichtag — die vorige Korrektur verglich nur gegen
den Stichtag und blieb damit wirkungslos. Endet ein Verhaeltnis nicht
spaeter, als es beginnt, gab es keinen Tag Beschaeftigung, zu keinem
Stichtag.

tests/unit/employee-sort.test.ts

@@ -119,8 +119,10 @@ const db = new Kysely<Schema>({
   },
 });
 
+const STICHTAG = "2026-09-15";
+
 const ordnung = (feld: Sortierfeld, richtung: "asc" | "desc") =>
-  sortiere(db.selectFrom("employees").select("id"), feld, richtung)
+  sortiere(db.selectFrom("employees").select("id"), feld, richtung, STICHTAG)
     .compile()
     .sql.replace(/^.*?order by /s, "")
     .replace(/\s+/g, " ");
@@ -222,9 +224,46 @@ describe("das erzeugte SQL", () => {
   it("setzt keinen Wert aus der Adresse in die Abfrage", () => {
     // Die Richtung ist ausgeschrieben, nicht eingesetzt. Kämen je Werte aus
     // der Adresse hierher, stünden sie im SQL statt als Parameter.
+    //
+    // Gebunden wird genau ein Wert, und er kommt nicht aus der Adresse: der
+    // Stichtag der Statusableitung. Deshalb wird er hier namentlich
+    // zugelassen und alles andere ausgeschlossen — „gar keine Parameter"
+    // wäre die schärfere Zusicherung, aber die falsche.
     for (const f of SORTIERFELDER) {
-      const { parameters } = sortiere(db.selectFrom("employees").select("id"), f.value, "desc").compile();
-      expect(parameters, f.value).toEqual([]);
+      const { parameters } = sortiere(db.selectFrom("employees").select("id"), f.value, "desc", STICHTAG).compile();
+      expect(new Set(parameters), f.value).toEqual(new Set(f.value === "status" ? [STICHTAG] : []));
     }
   });
+
+  // ── Status: abgeleitet, nicht aus der Spalte gelesen ──────────────────
+  //
+  // Die Zeile zeigt den zum Stichtag abgeleiteten Status. Nach
+  // `employees.status` zu sortieren hiesse, nach einem Wert zu ordnen, der
+  // nirgends auf der Seite steht — eine als „Ausgetreten" beschriftete Person
+  // stünde mitten unter den aktiven.
+  describe("Status", () => {
+    it("ordnet nach der Ableitung und nicht nach der Spalte", () => {
+      const sql = ordnung("status", "asc");
+      expect(sql).toContain("exit_date");
+      expect(sql).toContain("entry_date");
+      expect(sql).toContain("karenz_start_date");
+      expect(sql).not.toContain('"status"');
+    });
+
+    it("hält die Reihenfolge des Dienstverhältnisses ein", () => {
+      // Aktiv (1), Karenz (2), Geplant (3), Ausgetreten (4) — dieselbe
+      // Folge wie im Aufzählungstyp, und aussagekräftiger als alphabetisch.
+      const sql = ordnung("status", "asc");
+      expect(sql.indexOf("then 4")).toBeLessThan(sql.indexOf("then 3"));
+      expect(sql.indexOf("then 3")).toBeLessThan(sql.indexOf("then 2"));
+      expect(sql).toContain("else 1");
+    });
+
+    it("erkennt den Nichtantritt wie die Ableitung", () => {
+      // exit_date <= entry_date: kein einziger Tag Beschäftigung. Fehlte der
+      // Vergleich, sortierte ein künftiger Nichtantritt unter „Geplant",
+      // während sein Chip „Ausgetreten" zeigt.
+      expect(ordnung("status", "asc")).toContain("exit_date <= entry_date");
+    });
+  });
 });

tests/unit/employee-status-filter.test.ts

@@ -46,9 +46,16 @@ describe("derivedStatusFilter — Geplant", () => {
 
   // Die eigentliche Zusicherung: ohne diese Hälfte war der Filter falsch.
   it("schliesst aus, wessen Austritt schon vollzogen ist", () => {
-    const sql = bedingung(["Geplant"]);
-    expect(sql).toContain('"exit_date" is null');
-    expect(sql).toContain('"exit_date" >');
+    expect(bedingung(["Geplant"])).toContain('"exit_date" <=');
+  });
+
+  // Und ohne *diese* Hälfte blieb er wirkungslos. Ein Nichtantritt trägt als
+  // Austrittsdatum den Eintrittstag; liegt der in der Zukunft, ist auch der
+  // Austritt grösser als der Stichtag. Ein Vergleich, der nur den Stichtag
+  // kennt, lässt ihn durch — deshalb muss exit_date auch gegen entry_date
+  // stehen.
+  it("vergleicht den Austritt auch mit dem Eintritt", () => {
+    expect(bedingung(["Geplant"])).toContain('"exit_date" <= "entry_date"');
   });
 });
 
@@ -58,6 +65,10 @@ describe("derivedStatusFilter — Ausgetreten", () => {
     expect(sql).toContain('"exit_date" is not null');
     expect(sql).toContain('"exit_date" <=');
   });
+
+  it("zählt den Nichtantritt mit, dessen Eintritt noch bevorsteht", () => {
+    expect(bedingung(["Ausgetreten"])).toContain('"exit_date" <= "entry_date"');
+  });
 });
 
 describe("derivedStatusFilter — nicht abgedeckte Auswahl", () => {
@@ -90,6 +101,41 @@ describe("Filter und Anzeige meinen dasselbe", () => {
       e: { ...basis, entry_date: "2026-10-01", exit_date: "2026-12-31" },
       erwartet: "Geplant",
     },
+    // Der Fall, der nach der ersten Korrektur noch durchrutschte. So und nicht
+    // anders legt ihn terminate_employee an: bei „No Show" wird das übergebene
+    // Austrittsdatum verworfen und der Eintrittstag eingesetzt.
+    {
+      was: "Nichtantritt: Austritt am Eintrittstag, beides in der Zukunft",
+      e: { ...basis, entry_date: "2026-10-01", exit_date: "2026-10-01" },
+      erwartet: "Ausgetreten",
+    },
+    {
+      was: "Nichtantritt in der Vergangenheit",
+      e: { ...basis, entry_date: "2026-08-01", exit_date: "2026-08-01" },
+      erwartet: "Ausgetreten",
+    },
+    // Die Gegenprobe: ein einziger Tag Beschäftigung genügt, und es ist kein
+    // Nichtantritt mehr. Läge die Grenze bei „<" statt „<=", fiele genau
+    // dieser Fall auf die falsche Seite.
+    {
+      was: "ein Tag Beschäftigung, Austritt am Folgetag des Eintritts",
+      e: { ...basis, entry_date: "2026-08-01", exit_date: "2026-08-02" },
+      erwartet: "Ausgetreten",
+    },
+    {
+      was: "laufendes Verhältnis",
+      e: { ...basis, entry_date: "2020-04-30", exit_date: null },
+      erwartet: "Aktiv",
+    },
+    // Aigner, Christian aus dem Testbestand: Austritt zum 01.09.2026 erfasst,
+    // in der Spalte `status` steht bis heute „Aktiv", weil kein Lauf sie
+    // nachzieht. Abgeleitet ist er ausgetreten — und danach richtet sich jetzt
+    // auch der Chip in der Liste und in der Akte.
+    {
+      was: "Austritt liegt zurück, Spalte hängt nach",
+      e: { ...basis, entry_date: "2020-04-30", exit_date: "2026-09-01" },
+      erwartet: "Ausgetreten",
+    },
   ];
 
   for (const { was, e, erwartet } of faelle) {