@cosmicdrift/kumiko-dev-server 0.1.0

package/src/__tests__/compose-features-wiring.integration.ts

@@ -0,0 +1,352 @@
+// Wrapper-spezifischer Integration-Test für composeFeatures + auth-routes-
+// Verdrahtung. Ergänzt password-reset.integration.ts (das das Feature
+// direkt instantiiert) — hier wird der EXAKTE Bootstrap-Pfad gefahren den
+// runProdApp / runDevApp produzieren:
+//
+//   composeFeatures([], { includeBundled: true, authOptions: {...} })
+//     → setupTestStack(features=..., authConfig=...)
+//     → POST /api/auth/request-password-reset
+//
+// Bug-Pattern den dieser Test pinst: composeFeatures.authOptions wird
+// NICHT an createAuthEmailPasswordFeature durchgereicht → routes mounten
+// (auth-routes-config tut das blind), aber die request-password-reset/
+// reset-password Handler fehlen im Feature → dispatcher kennt den
+// QualifiedName nicht → 5xx in Production. Whitebox-Variante in
+// compose-features.test.ts checkt nur Object.keys(writeHandlers); dieser
+// Test fährt den vollen HTTP-Roundtrip und kann den dispatch-error nicht
+// übersehen.
+//
+// Kein Mocking: setupTestStack bootet echte DB + Redis. Die
+// sendResetEmail-callback (analog runProdApp's createAuthMailerConfig)
+// schreibt in ein lokales Array — gewollter Capture-Spy ohne vitest-
+// Mock-API (CLAUDE.md "Kein Mock in *.integration.ts").
+
+import { randomBytes } from "node:crypto";
+import {
+  AuthErrors,
+  AuthHandlers,
+  hashPassword,
+} from "@cosmicdrift/kumiko-bundled-features/auth-email-password";
+import {
+  configValuesTable,
+  createConfigResolver,
+} from "@cosmicdrift/kumiko-bundled-features/config";
+import { tenantEntity, tenantMembershipsTable } from "@cosmicdrift/kumiko-bundled-features/tenant";
+import { seedTenantMembership } from "@cosmicdrift/kumiko-bundled-features/tenant/testing";
+import { UserHandlers, userEntity, userTable } from "@cosmicdrift/kumiko-bundled-features/user";
+import type { TenantId } from "@cosmicdrift/kumiko-framework/engine";
+import {
+  createEntityTable,
+  pushTables,
+  setupTestStack,
+  type TestStack,
+  TestUsers,
+} from "@cosmicdrift/kumiko-framework/stack";
+import { afterAll, afterEach, beforeAll, beforeEach, describe, expect, test } from "vitest";
+import { composeFeatures } from "../compose-features";
+
+const RESET_HMAC = randomBytes(32).toString("base64");
+const VERIFY_HMAC = randomBytes(32).toString("base64");
+const APP_RESET_URL = "https://app.example.com/reset-password";
+const APP_VERIFY_URL = "https://app.example.com/verify-email";
+const TEST_TENANT_ID: TenantId = "00000000-0000-4000-8000-000000000001" as TenantId;
+const systemAdmin = TestUsers.systemAdmin;
+
+type CapturedReset = { email: string; resetUrl: string; expiresAt: string };
+type CapturedVerify = { email: string; verificationUrl: string; expiresAt: string };
+
+async function bootStack(
+  authOptionsKind: "with-both" | "with-reset-only" | "without-auth-options",
+): Promise<{
+  stack: TestStack;
+  resetEmails: CapturedReset[];
+  verifyEmails: CapturedVerify[];
+}> {
+  const resetEmails: CapturedReset[] = [];
+  const verifyEmails: CapturedVerify[] = [];
+
+  // Genau das was runProdApp/runDevApp machen würde — composeFeatures als
+  // single-source der Feature-Liste, je nach authOptionsKind variiert die
+  // Konfiguration. Dieser Test cared explizit um die DURCHREICHE — also
+  // dass das Wrapper-API-Object an createAuthEmailPasswordFeature ankommt.
+  const features = composeFeatures([], {
+    includeBundled: true,
+    ...(authOptionsKind !== "without-auth-options" && {
+      authOptions: {
+        passwordReset: { hmacSecret: RESET_HMAC, tokenTtlMinutes: 15 },
+        ...(authOptionsKind === "with-both" && {
+          emailVerification: { hmacSecret: VERIFY_HMAC, tokenTtlMinutes: 60, mode: "off" },
+        }),
+      },
+    }),
+  });
+
+  const stack = await setupTestStack({
+    features,
+    extraContext: { configResolver: createConfigResolver() },
+    authConfig: {
+      membershipQuery: "tenant:query:memberships",
+      loginHandler: AuthHandlers.login,
+      // Routes IMMER mounten — egal welche authOptionsKind. Genau das
+      // ist die Bug-Bedingung: Routes da, Handler eventuell nicht.
+      passwordReset: {
+        requestHandler: AuthHandlers.requestPasswordReset,
+        confirmHandler: AuthHandlers.resetPassword,
+        appResetUrl: APP_RESET_URL,
+        sendResetEmail: async (args) => {
+          resetEmails.push(args);
+        },
+      },
+      ...(authOptionsKind === "with-both" && {
+        emailVerification: {
+          requestHandler: AuthHandlers.requestEmailVerification,
+          confirmHandler: AuthHandlers.verifyEmail,
+          appVerifyUrl: APP_VERIFY_URL,
+          sendVerificationEmail: async (args) => {
+            verifyEmails.push(args);
+          },
+        },
+      }),
+    },
+  });
+
+  await createEntityTable(stack.db, userEntity);
+  await createEntityTable(stack.db, tenantEntity);
+  await pushTables(stack.db, { configValuesTable, tenantMembershipsTable });
+
+  return { stack, resetEmails, verifyEmails };
+}
+
+async function seedUser(
+  stack: TestStack,
+  opts: { email: string; password: string },
+): Promise<{ id: string }> {
+  const hash = await hashPassword(opts.password);
+  const created = await stack.http.writeOk<{ id: string }>(
+    UserHandlers.create,
+    {
+      email: opts.email,
+      passwordHash: hash,
+      displayName: opts.email.split("@")[0] ?? "user",
+    },
+    systemAdmin,
+  );
+  await seedTenantMembership(stack.db, {
+    userId: created.id,
+    tenantId: TEST_TENANT_ID,
+    roles: ["User"],
+  });
+  return { id: created.id };
+}
+
+describe("composeFeatures wiring — passwordReset", () => {
+  let suite: Awaited<ReturnType<typeof bootStack>>;
+
+  beforeAll(async () => {
+    suite = await bootStack("with-both");
+  });
+
+  afterAll(async () => {
+    await suite.stack.cleanup();
+  });
+
+  beforeEach(async () => {
+    await suite.stack.db.delete(userTable);
+    await suite.stack.db.delete(tenantMembershipsTable);
+    suite.resetEmails.length = 0;
+    suite.verifyEmails.length = 0;
+  });
+
+  test("full reset roundtrip: request → email → reset → login with new password", async () => {
+    // Beweis: composeFeatures(authOptions.passwordReset) hat den Handler
+    // im Feature registriert UND auth-routes hat die /api/auth/...-Routes
+    // gemountet — der Wrapper-Pfad ist konsistent. password-reset.
+    // integration.ts beweist das gleiche für direkten Feature-Aufruf;
+    // dieser Test pinst dass der Wrapper das Pattern repliziert.
+    await seedUser(suite.stack, { email: "alice@example.com", password: "old-password-1234" });
+
+    const requestRes = await suite.stack.http.raw("POST", "/api/auth/request-password-reset", {
+      email: "alice@example.com",
+    });
+    expect(requestRes.status).toBe(200);
+    expect(suite.resetEmails).toHaveLength(1);
+    const captured = suite.resetEmails[0];
+    if (!captured) throw new Error("no email captured");
+    expect(captured.email).toBe("alice@example.com");
+
+    // Token aus URL extrahieren — wie der echte User es täte (Mail klicken,
+    // Browser parsed query-string). Das macht dieser Test "echter" als ein
+    // signResetToken-Bypass: er pinst den vollen URL-zu-Handler-Roundtrip.
+    const resetUrl = new URL(captured.resetUrl);
+    expect(`${resetUrl.origin}${resetUrl.pathname}`).toBe(APP_RESET_URL);
+    const token = resetUrl.searchParams.get("token");
+    expect(token).toBeTruthy();
+    if (!token) return;
+
+    const resetRes = await suite.stack.http.raw("POST", "/api/auth/reset-password", {
+      token,
+      newPassword: "brand-new-pw-9876",
+    });
+    expect(resetRes.status).toBe(200);
+
+    // Confirmation: das neue Passwort funktioniert für /api/auth/login.
+    // Das ist der echte End-to-End-Beweis (DB-Read würde nur
+    // password_hash != old verifizieren — hier prüfen wir die User-
+    // visible Konsequenz).
+    const loginRes = await suite.stack.http.raw("POST", "/api/auth/login", {
+      email: "alice@example.com",
+      password: "brand-new-pw-9876",
+    });
+    expect(loginRes.status).toBe(200);
+  });
+
+  test("invalid token via wrapper-routes → 422 invalid_reset_token", async () => {
+    await seedUser(suite.stack, { email: "carol@example.com", password: "keep-me-1234" });
+
+    const res = await suite.stack.http.raw("POST", "/api/auth/reset-password", {
+      token: "tampered.totally.fake",
+      newPassword: "should-not-stick-1234",
+    });
+    expect(res.status).toBe(422);
+    const body = (await res.json()) as { error?: { details?: { reason?: string } } };
+    expect(body.error?.details?.reason).toBe(AuthErrors.invalidResetToken);
+  });
+});
+
+describe("composeFeatures wiring — emailVerification", () => {
+  let suite: Awaited<ReturnType<typeof bootStack>>;
+
+  beforeAll(async () => {
+    suite = await bootStack("with-both");
+  });
+
+  afterAll(async () => {
+    await suite.stack.cleanup();
+  });
+
+  beforeEach(async () => {
+    await suite.stack.db.delete(userTable);
+    await suite.stack.db.delete(tenantMembershipsTable);
+    suite.resetEmails.length = 0;
+    suite.verifyEmails.length = 0;
+  });
+
+  test("emailVerification authOption durchgereicht → request handler dispatched", async () => {
+    // Symmetric zum reset-Test — pinst dass authOptions.emailVerification
+    // genauso durchgereicht wird wie passwordReset. Bug-Pattern wäre dass
+    // der Wrapper EINS funktioniert, ANDERES vergisst.
+    await seedUser(suite.stack, { email: "bob@example.com", password: "any-pw-1234" });
+
+    const res = await suite.stack.http.raw("POST", "/api/auth/request-email-verification", {
+      email: "bob@example.com",
+    });
+    expect(res.status).toBe(200);
+    expect(suite.verifyEmails).toHaveLength(1);
+    const captured = suite.verifyEmails[0];
+    if (!captured) throw new Error("no verification email captured");
+    expect(captured.email).toBe("bob@example.com");
+    const verifyUrl = new URL(captured.verificationUrl);
+    expect(`${verifyUrl.origin}${verifyUrl.pathname}`).toBe(APP_VERIFY_URL);
+    expect(verifyUrl.searchParams.get("token")).toBeTruthy();
+  });
+});
+
+describe("composeFeatures wiring — asymmetric activation", () => {
+  // Pinst dass passwordReset und emailVerification UNABHÄNGIG durchgereicht
+  // werden. Bug-Pattern: ein Refactor des Helpers könnte einen Block
+  // versehentlich an den anderen koppeln (z.B. emailVerification nur
+  // durchreichen wenn passwordReset auch gesetzt ist) — dann würde eine
+  // App die NUR Reset-Flow will plötzlich keine Reset-Mails mehr kriegen,
+  // oder eine die NUR Verify-Flow will keine Verify-Mails. Asymmetric-
+  // activation ist also ein eigenständiger Wrapper-Vertrag.
+
+  let suite: Awaited<ReturnType<typeof bootStack>>;
+
+  beforeAll(async () => {
+    suite = await bootStack("with-reset-only");
+  });
+
+  afterAll(async () => {
+    await suite.stack.cleanup();
+  });
+
+  beforeEach(async () => {
+    await suite.stack.db.delete(userTable);
+    await suite.stack.db.delete(tenantMembershipsTable);
+    suite.resetEmails.length = 0;
+    suite.verifyEmails.length = 0;
+  });
+
+  test("nur passwordReset gesetzt → reset-flow live, verify-flow fail-closed", async () => {
+    await seedUser(suite.stack, { email: "alice@example.com", password: "any-pw-1234" });
+
+    // Reset-flow funktioniert: Mail wird produziert.
+    const resetRes = await suite.stack.http.raw("POST", "/api/auth/request-password-reset", {
+      email: "alice@example.com",
+    });
+    expect(resetRes.status).toBe(200);
+    expect(suite.resetEmails).toHaveLength(1);
+
+    // Verify-Routes sind in dieser bootStack-Variante NICHT gemounted
+    // (authConfig.emailVerification fehlt). Der Endpoint existiert also
+    // gar nicht — Hono returnt 404. Unterscheidet sich vom 200-silent-
+    // success-Pfad: hier ist die ROUTE selbst nicht da.
+    const verifyRes = await suite.stack.http.raw("POST", "/api/auth/request-email-verification", {
+      email: "alice@example.com",
+    });
+    expect(verifyRes.status).toBe(404);
+    expect(suite.verifyEmails).toHaveLength(0);
+  });
+});
+
+describe("composeFeatures wiring — fail-closed ohne authOptions", () => {
+  // Der Bug den der Review-Agent gefangen hat. Whitebox-Variante in
+  // compose-features.test.ts checkt nur Object.keys(writeHandlers); hier
+  // pinst der Test das User-visible Verhalten: WENN user existiert + POST
+  // request-password-reset gefeuert wird, MUSS der Wrapper-Pfad eine Mail
+  // produzieren. Tut er das nicht, ist der composeFeatures-authOptions-
+  // Bug zurück.
+  //
+  // Subtilität: auth-routes mountet die request-Route by-design als
+  // enumeration-safe (always-200, silently swallow handler-Failures —
+  // siehe registerTokenRequestRoute in auth-routes.ts). Ein fehlender
+  // Handler endet daher nicht in 4xx/5xx, sondern silent in "200 + 0
+  // mails". Genau das pinnt dieser Test gegen die Regression: ohne
+  // resetEmails-Capture als Counter-Evidence wäre der Bug unsichtbar.
+
+  let suite: Awaited<ReturnType<typeof bootStack>>;
+
+  beforeAll(async () => {
+    suite = await bootStack("without-auth-options");
+  });
+
+  afterAll(async () => {
+    await suite.stack.cleanup();
+  });
+
+  afterEach(async () => {
+    await suite.stack.db.delete(userTable);
+    await suite.stack.db.delete(tenantMembershipsTable);
+    suite.resetEmails.length = 0;
+  });
+
+  test("authOptions fehlt → POST returnt enumeration-safe 200, ABER NULL Mails (der echte Bug-Beweis)", async () => {
+    // User EXISTIERT — das pinst dass die fehlende Mail auf dem
+    // composeFeatures-bug beruht, nicht auf "user not found"
+    // (welcher legitim 0 mails produziert: enumeration-safety).
+    await seedUser(suite.stack, { email: "noop@example.com", password: "any-pw-1234" });
+
+    const res = await suite.stack.http.raw("POST", "/api/auth/request-password-reset", {
+      email: "noop@example.com",
+    });
+
+    // 200 ist by-design (registerTokenRequestRoute swallowt handler-
+    // Failures). Bug-Beweis ist die fehlende Mail — wenn der "with-both"-
+    // Test 1 Mail bekommt und dieser Test 0 bekommt für denselben
+    // existierenden User, ist die Differenz EXAKT der composeFeatures-
+    // Bug. Diese Asymmetrie zwischen den beiden describe-Blöcken IST
+    // der Test.
+    expect(res.status).toBe(200);
+    expect(suite.resetEmails).toHaveLength(0);
+  });
+});

package/src/__tests__/compose-features.test.ts

@@ -0,0 +1,81 @@
+// Unit-Tests für composeFeatures.authOptions — pinst dass die
+// passwordReset / emailVerification options an
+// createAuthEmailPasswordFeature durchgereicht werden, sodass die
+// request- und confirm-Handler im resultierenden Feature registriert
+// sind. Bug-Pattern: ohne diesen Wiring würde runProdApp.options.auth.
+// passwordReset = {sendResetEmail, appResetUrl} die routes mounten,
+// aber die Handler fehlen → POST /api/auth/request-password-reset
+// dispatched ins Leere → 500.
+
+import { defineFeature } from "@cosmicdrift/kumiko-framework/engine";
+import { describe, expect, test } from "vitest";
+import { composeFeatures } from "../compose-features";
+
+const noopFeature = defineFeature("noop-app", () => {});
+
+const HMAC_SECRET = "test-secret-with-at-least-32-bytes-aaa";
+
+describe("composeFeatures", () => {
+  test("includeBundled=false → nur App-Features", () => {
+    const features = composeFeatures([noopFeature], { includeBundled: false });
+    expect(features.map((f) => f.name)).toEqual(["noop-app"]);
+  });
+
+  test("includeBundled=true → 4 bundled Features davor", () => {
+    const features = composeFeatures([noopFeature], { includeBundled: true });
+    expect(features.map((f) => f.name)).toEqual([
+      "config",
+      "user",
+      "tenant",
+      "auth-email-password",
+      "noop-app",
+    ]);
+  });
+
+  test("authOptions.passwordReset → request-password-reset + reset-password handlers registriert", () => {
+    const features = composeFeatures([noopFeature], {
+      includeBundled: true,
+      authOptions: { passwordReset: { hmacSecret: HMAC_SECRET } },
+    });
+    const auth = features.find((f) => f.name === "auth-email-password");
+    expect(auth).toBeDefined();
+    if (!auth) return;
+    const handlerNames = Array.from(Object.keys(auth.writeHandlers));
+    expect(handlerNames).toContain("request-password-reset");
+    expect(handlerNames).toContain("reset-password");
+  });
+
+  test("authOptions.emailVerification → request-email-verification + verify-email handlers registriert", () => {
+    const features = composeFeatures([noopFeature], {
+      includeBundled: true,
+      authOptions: { emailVerification: { hmacSecret: HMAC_SECRET } },
+    });
+    const auth = features.find((f) => f.name === "auth-email-password");
+    expect(auth).toBeDefined();
+    if (!auth) return;
+    const handlerNames = Array.from(Object.keys(auth.writeHandlers));
+    expect(handlerNames).toContain("request-email-verification");
+    expect(handlerNames).toContain("verify-email");
+  });
+
+  test("OHNE authOptions → KEINE reset/verify-handlers (anti-default-deploy-bug)", () => {
+    // Genau der Bug der vom Review-Agent gefangen wurde: composeFeatures
+    // ohne authOptions registriert die handler nicht. Wenn jemand das
+    // versehentlich vergisst und nur die routes (auth-routes-config)
+    // wired, schlagen die requests auf prod fehl. Der Test pinst dass
+    // dieser default-deny-Pfad bewusst leer ist.
+    const features = composeFeatures([noopFeature], { includeBundled: true });
+    const auth = features.find((f) => f.name === "auth-email-password");
+    expect(auth).toBeDefined();
+    if (!auth) return;
+    const handlerNames = Array.from(Object.keys(auth.writeHandlers));
+    expect(handlerNames).not.toContain("request-password-reset");
+    expect(handlerNames).not.toContain("reset-password");
+    expect(handlerNames).not.toContain("request-email-verification");
+    expect(handlerNames).not.toContain("verify-email");
+    // Die regulären auth-handlers (login/logout/change-password) MÜSSEN
+    // aber immer da sein — das ist der core-flow.
+    expect(handlerNames).toContain("login");
+    expect(handlerNames).toContain("logout");
+  });
+});

package/src/__tests__/crash-tracker.test.ts

@@ -0,0 +1,89 @@
+// Unit-Tests für createCrashTracker — die rollende-Fenster-Logik aus
+// kumiko-dev. Hier steckt der Crash-Loop-Schutz, der entscheidet ob der
+// Wrapper aufgibt oder noch eine Runde respawnt; off-by-one am Fenster-
+// Rand würde im Bin-Skript schlecht auffallen.
+
+import { describe, expect, test } from "vitest";
+import { createCrashTracker } from "../crash-tracker";
+
+describe("createCrashTracker", () => {
+  test("erste maxCrashes Crashes sind erlaubt, der nächste nicht", () => {
+    const t = createCrashTracker({ maxCrashes: 3, windowMs: 10_000 });
+    expect(t.noteCrash(1000)).toBe(true);
+    expect(t.noteCrash(1100)).toBe(true);
+    expect(t.noteCrash(1200)).toBe(true);
+    // 4. Crash innerhalb des Fensters → über Limit
+    expect(t.noteCrash(1300)).toBe(false);
+  });
+
+  test("alte Crashes außerhalb des Fensters werden geprunt", () => {
+    const t = createCrashTracker({ maxCrashes: 2, windowMs: 1000 });
+    t.noteCrash(0);
+    t.noteCrash(500);
+    // bei t=1500 ist t=0 raus (1500 - 1000 = 500, alles < 500 fliegt),
+    // im Fenster bleibt nur t=500. Mit dem neuen Crash bei 1500 sind
+    // wir bei 2 → noch im Limit.
+    expect(t.noteCrash(1500)).toBe(true);
+    expect(t.crashCountInWindow(1500)).toBe(2);
+  });
+
+  test("crashCountInWindow zählt nur, was im Fenster liegt", () => {
+    const t = createCrashTracker({ maxCrashes: 5, windowMs: 1000 });
+    t.noteCrash(0);
+    t.noteCrash(0);
+    t.noteCrash(2000); // pruned beide alten weg
+    expect(t.crashCountInWindow(2000)).toBe(1);
+  });
+
+  test("crashCountInWindow prunt lazy auch ohne vorheriges noteCrash", () => {
+    // Wichtig: crashCountInWindow muss eigenständig korrekt sein, nicht
+    // nur als Folge eines vorangegangenen noteCrash. Sonst lügt der Name.
+    const t = createCrashTracker({ maxCrashes: 5, windowMs: 1000 });
+    t.noteCrash(0);
+    t.noteCrash(100);
+    // Direkter Aufruf bei now=2000 — alle alten Crashes sind raus.
+    expect(t.crashCountInWindow(2000)).toBe(0);
+    // Idempotent: zweiter Aufruf liefert dasselbe.
+    expect(t.crashCountInWindow(2000)).toBe(0);
+  });
+
+  test("Boundary: Crash genau am Fenster-Endpoint bleibt im Fenster", () => {
+    // Endpoint inklusive: cutoff = now - windowMs. Crash bei t=cutoff
+    // soll noch zählen. Hier: now=1000, windowMs=1000 → cutoff=0.
+    // Ein vorheriger Crash bei t=0 darf nicht als "alt" geprunt werden.
+    const t = createCrashTracker({ maxCrashes: 2, windowMs: 1000 });
+    t.noteCrash(0);
+    expect(t.noteCrash(1000)).toBe(true);
+    expect(t.crashCountInWindow(1000)).toBe(2);
+    // Dritter Crash bei 1000 → 3 im Fenster, über Limit
+    expect(t.noteCrash(1000)).toBe(false);
+  });
+
+  test("Mehrere Crashes am gleichen Timestamp zählen einzeln", () => {
+    const t = createCrashTracker({ maxCrashes: 2, windowMs: 1000 });
+    expect(t.noteCrash(500)).toBe(true);
+    expect(t.noteCrash(500)).toBe(true);
+    expect(t.noteCrash(500)).toBe(false);
+  });
+
+  test("Nach Wartezeit > windowMs ist das Limit zurückgesetzt", () => {
+    const t = createCrashTracker({ maxCrashes: 2, windowMs: 1000 });
+    t.noteCrash(0);
+    t.noteCrash(100);
+    expect(t.noteCrash(200)).toBe(false); // über Limit
+    // Wartezeit, alte Crashes raus
+    expect(t.noteCrash(2000)).toBe(true);
+    expect(t.crashCountInWindow(2000)).toBe(1);
+  });
+
+  test("maxCrashes=1 erlaubt genau einen Crash pro Fenster", () => {
+    const t = createCrashTracker({ maxCrashes: 1, windowMs: 1000 });
+    expect(t.noteCrash(0)).toBe(true);
+    expect(t.noteCrash(500)).toBe(false);
+    // Bei t=1600 sind beide vorigen Crashes (0 und 500) außerhalb
+    // (cutoff = 600, 0 < 600 und 500 < 600), Tracker ist leer
+    // bevor der neue gepusht wird.
+    expect(t.noteCrash(1600)).toBe(true);
+    expect(t.crashCountInWindow(1600)).toBe(1);
+  });
+});