@cosmicdrift/kumiko-dev-server 0.152.0 → 0.154.0

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

@@ -1,382 +0,0 @@
-// 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. reset/verify mailen
-// via delivery (ctx.notify → channel-email); der In-Memory-Transport fängt
-// die echte Mail ab — gewollter Capture ohne Mock-API (CLAUDE.md "Kein Mock
-// in *.integration.ts").
-
-import { afterAll, afterEach, beforeAll, beforeEach, describe, expect, test } from "bun:test";
-import { randomBytes } from "node:crypto";
-import {
-  AuthErrors,
-  AuthHandlers,
-  hashPassword,
-} from "@cosmicdrift/kumiko-bundled-features/auth-email-password";
-import {
-  createChannelEmailFeature,
-  createInMemoryTransport,
-} from "@cosmicdrift/kumiko-bundled-features/channel-email";
-import {
-  configValuesTable,
-  createConfigResolver,
-} from "@cosmicdrift/kumiko-bundled-features/config";
-import {
-  createDeliveryFeature,
-  createDeliveryTestContext,
-  notificationPreferencesTable,
-} from "@cosmicdrift/kumiko-bundled-features/delivery";
-import { createRendererFoundationFeature } from "@cosmicdrift/kumiko-bundled-features/renderer-foundation";
-import {
-  createRendererSimpleFeature,
-  simpleRenderer,
-} from "@cosmicdrift/kumiko-bundled-features/renderer-simple";
-import { createTemplateResolverFeature } from "@cosmicdrift/kumiko-bundled-features/template-resolver";
-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 {
-  setupTestStack,
-  type TestStack,
-  TestUsers,
-  unsafeCreateEntityTable,
-  unsafePushTables,
-} from "@cosmicdrift/kumiko-framework/stack";
-import { deleteRows } from "@cosmicdrift/kumiko-framework/testing";
-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;
-
-// Pulls the magic-link out of the rendered mail HTML — the renderer-simple
-// button carries it as the only href. Replaces the old callback-captured
-// resetUrl now that reset/verify mail via delivery.
-function tokenUrlFromHtml(html: string): URL {
-  const match = html.match(/href="([^"]*\?token=[^"]*)"/);
-  if (!match?.[1]) throw new Error("no magic-link href in mail html");
-  return new URL(match[1]);
-}
-
-async function bootStack(
-  authOptionsKind: "with-both" | "with-reset-only" | "without-auth-options",
-): Promise<{ stack: TestStack; emailTransport: ReturnType<typeof createInMemoryTransport> }> {
-  const emailTransport = createInMemoryTransport();
-
-  // Genau das was runProdApp/runDevApp machen würde — composeFeatures als
-  // single-source der Feature-Liste. delivery + channel-email kommen als
-  // App-Features dazu, weil reset/verify ihre Mail via ctx.notify schicken.
-  const features = composeFeatures(
-    [
-      createTemplateResolverFeature(),
-      createRendererFoundationFeature(),
-      createDeliveryFeature(),
-      createRendererSimpleFeature(),
-      createChannelEmailFeature({
-        transport: emailTransport,
-        renderer: simpleRenderer,
-        resolveEmail: async () => "unused@test.local",
-      }),
-    ],
-    {
-      includeBundled: true,
-      ...(authOptionsKind !== "without-auth-options" && {
-        authOptions: {
-          passwordReset: { hmacSecret: RESET_HMAC, tokenTtlMinutes: 15, appUrl: APP_RESET_URL },
-          ...(authOptionsKind === "with-both" && {
-            emailVerification: {
-              hmacSecret: VERIFY_HMAC,
-              tokenTtlMinutes: 60,
-              mode: "off",
-              appUrl: APP_VERIFY_URL,
-            },
-          }),
-        },
-      }),
-    },
-  );
-
-  const stack = await setupTestStack({
-    features,
-    extraContext: (deps) => ({
-      ...createDeliveryTestContext(deps),
-      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,
-      },
-      ...(authOptionsKind === "with-both" && {
-        emailVerification: {
-          requestHandler: AuthHandlers.requestEmailVerification,
-          confirmHandler: AuthHandlers.verifyEmail,
-        },
-      }),
-    },
-  });
-
-  await unsafeCreateEntityTable(stack.db, userEntity);
-  await unsafeCreateEntityTable(stack.db, tenantEntity);
-  await unsafePushTables(stack.db, {
-    configValuesTable,
-    tenantMembershipsTable,
-    notificationPreferencesTable,
-  });
-
-  return { stack, emailTransport };
-}
-
-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 deleteRows(suite.stack.db, userTable, {});
-    await deleteRows(suite.stack.db, tenantMembershipsTable, {});
-    suite.emailTransport.sent.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.emailTransport.sent).toHaveLength(1);
-    const sent = suite.emailTransport.sent[0];
-    if (!sent) throw new Error("no email sent");
-    expect(sent.to).toBe("alice@example.com");
-
-    // Token aus der Mail-URL extrahieren — wie der echte User es täte (Mail
-    // klicken, Browser parsed query-string). Das pinst den vollen
-    // URL-zu-Handler-Roundtrip über delivery.
-    const resetUrl = tokenUrlFromHtml(sent.html);
-    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 deleteRows(suite.stack.db, userTable, {});
-    await deleteRows(suite.stack.db, tenantMembershipsTable, {});
-    suite.emailTransport.sent.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.emailTransport.sent).toHaveLength(1);
-    const sent = suite.emailTransport.sent[0];
-    if (!sent) throw new Error("no verification email sent");
-    expect(sent.to).toBe("bob@example.com");
-    const verifyUrl = tokenUrlFromHtml(sent.html);
-    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 deleteRows(suite.stack.db, userTable, {});
-    await deleteRows(suite.stack.db, tenantMembershipsTable, {});
-    suite.emailTransport.sent.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.emailTransport.sent).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. Kein zweites Mail.
-    const verifyRes = await suite.stack.http.raw("POST", "/api/auth/request-email-verification", {
-      email: "alice@example.com",
-    });
-    expect(verifyRes.status).toBe(404);
-    expect(suite.emailTransport.sent).toHaveLength(1);
-  });
-});
-
-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 deleteRows(suite.stack.db, userTable, {});
-    await deleteRows(suite.stack.db, tenantMembershipsTable, {});
-    suite.emailTransport.sent.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.emailTransport.sent).toHaveLength(0);
-  });
-});

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

@@ -1,128 +0,0 @@
-// 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 { describe, expect, spyOn, test } from "bun:test";
-import { defineFeature } from "@cosmicdrift/kumiko-framework/engine";
-import { composeFeatures } from "../compose-features";
-
-const noopFeature = defineFeature("noop-app", () => {});
-
-// Mirrors what the create-kumiko-app picker hands back when the user
-// ticks an auto-mounted feature: a stub with the same name as a bundled
-// one. The dedupe path drops it and warns.
-const pickerAuthDupe = defineFeature("auth-email-password", () => {});
-
-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, appUrl: "https://app/reset" } },
-    });
-    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, appUrl: "https://app/verify" } },
-    });
-    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("authOptions.signup → signup-request + signup-confirm handlers registriert", () => {
-    const features = composeFeatures([noopFeature], {
-      includeBundled: true,
-      authOptions: { signup: { appUrl: "https://app/signup/complete" } },
-    });
-    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("signup-request");
-    expect(handlerNames).toContain("signup-confirm");
-  });
-
-  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");
-  });
-
-  test("app feature duplicating a bundled name is dropped (no createRegistry crash)", () => {
-    // create-kumiko-app's picker hands back createAuthEmailPasswordFeature()
-    // because the user ticked it in the recommended set; runDevApp then adds
-    // its OWN bundled copy via includeBundled:true, and createRegistry throws
-    // "Duplicate feature: auth-email-password". The dedupe path keeps the
-    // bundled instance (it carries authOptions wiring) and drops the app stub.
-    const warnSpy = spyOn(console, "warn").mockImplementation(() => {});
-    const features = composeFeatures([pickerAuthDupe, noopFeature], {
-      includeBundled: true,
-    });
-    // The warn is part of the fix contract (changeset: "warn so the user can
-    // remove the line") — without this assertion the warn is removable with no RED.
-    expect(warnSpy).toHaveBeenCalledWith(expect.stringContaining("auth-email-password"));
-    warnSpy.mockRestore();
-    expect(features.map((f) => f.name)).toEqual([
-      "config",
-      "user",
-      "tenant",
-      "auth-email-password",
-      "noop-app",
-    ]);
-    // The kept instance is the bundled one — confirmed by the presence of
-    // login/logout handlers (the picker stub has none).
-    const auth = features.find((f) => f.name === "auth-email-password");
-    expect(auth).toBeDefined();
-    if (!auth) return;
-    expect(Object.keys(auth.writeHandlers)).toContain("login");
-  });
-});

package/src/__tests__/config-seed-boot.integration.test.ts

@@ -1,158 +0,0 @@
-// Pins the boot-wiring contract for config-seeds. runDevApp's onAfterSetup
-// and runProdApp's seed-block both call `applyBootSeeds(...)` — this test
-// calls the SAME helper, so if someone removes the call site from
-// runDevApp / runProdApp the helper still has at least one caller (this
-// test). Code review then sees an orphaned helper, not a silently broken
-// boot. For a stricter end-to-end pin you'd start an actual runDevApp;
-// that's heavy and not done here.
-//
-// Tests:
-//   1. seed rows land in the projection after applyBootSeeds runs,
-//   2. a re-boot is a no-op (idempotent),
-//   3. an admin set on top of a seed wins the resolver cascade; coexistence
-//      vs. override semantics depend on the admin user's tenantId.
-
-import { afterAll, beforeAll, describe, expect, test } from "bun:test";
-import {
-  configValuesTable,
-  createConfigAccessorFactory,
-  createConfigFeature,
-  createConfigResolver,
-} from "@cosmicdrift/kumiko-bundled-features/config";
-import { selectMany } from "@cosmicdrift/kumiko-framework/bun-db";
-import {
-  access,
-  createSystemConfig,
-  createSystemSeed,
-  createTenantConfig,
-  createTenantSeed,
-  defineFeature,
-} from "@cosmicdrift/kumiko-framework/engine";
-import {
-  setupTestStack,
-  type TestStack,
-  TestUsers,
-  unsafePushTables,
-} from "@cosmicdrift/kumiko-framework/stack";
-import { applyBootSeeds } from "../boot/apply-boot-seeds";
-
-const bootSeedsFeature = defineFeature("boot-seeds-test", (r) => {
-  r.requires("config");
-  r.config({
-    keys: {
-      siteName: createTenantConfig("text", {
-        default: "DEFAULT_SITE",
-        read: access.all,
-        write: access.all,
-      }),
-      maintenance: createSystemConfig("boolean", {
-        default: false,
-        read: access.all,
-        write: access.systemAdmin,
-      }),
-    },
-    seeds: {
-      siteName: createTenantSeed({ value: "from-seed" }),
-      maintenance: createSystemSeed({ value: true }),
-    },
-  });
-});
-
-const SITE_KEY = "boot-seeds-test:config:site-name";
-const MAINT_KEY = "boot-seeds-test:config:maintenance";
-
-let stack: TestStack;
-const resolver = createConfigResolver();
-
-beforeAll(async () => {
-  stack = await setupTestStack({
-    features: [createConfigFeature(), bootSeedsFeature],
-    extraContext: ({ registry }) => ({
-      configResolver: resolver,
-      _configAccessorFactory: createConfigAccessorFactory(registry, resolver),
-    }),
-  });
-  await unsafePushTables(stack.db, { configValuesTable });
-});
-
-afterAll(async () => {
-  await stack.cleanup();
-});
-
-describe("config-seed boot wiring", () => {
-  test("first boot: applyBootSeeds writes one row per seed", async () => {
-    await applyBootSeeds({ registry: stack.registry, db: stack.db });
-
-    const rows = await selectMany(stack.db, configValuesTable);
-    expect(rows.length).toBe(2);
-
-    const siteKeyDef = stack.registry.getConfigKey(SITE_KEY);
-    expect(siteKeyDef).toBeDefined();
-    const sitePeek = await resolver.get(
-      SITE_KEY,
-      siteKeyDef!,
-      TestUsers.systemAdmin.tenantId,
-      TestUsers.systemAdmin.id,
-      stack.db,
-    );
-    expect(sitePeek).toBe("from-seed");
-
-    const maintKeyDef = stack.registry.getConfigKey(MAINT_KEY);
-    expect(maintKeyDef).toBeDefined();
-    const maintPeek = await resolver.get(
-      MAINT_KEY,
-      maintKeyDef!,
-      TestUsers.systemAdmin.tenantId,
-      TestUsers.systemAdmin.id,
-      stack.db,
-    );
-    expect(maintPeek).toBe(true);
-  });
-
-  test("re-boot: idempotent — every seed already on disk → no extra rows", async () => {
-    await applyBootSeeds({ registry: stack.registry, db: stack.db });
-
-    const rows = await selectMany(stack.db, configValuesTable);
-    expect(rows.length).toBe(2);
-  });
-
-  test("admin set on top of seed wins resolver — Re-Boot preserves admin", async () => {
-    // siteName is a TENANT-scope key. The seed writes a row under
-    // SYSTEM_TENANT_ID (= "for all tenants"). An admin on a real tenant
-    // writes a row under THAT tenantId — higher specificity. Both rows
-    // coexist; the resolver returns the more specific one.
-    //
-    // If the admin happens to write as SYSTEM_TENANT_ID (e.g. test user
-    // is the system-admin on the system-tenant), the admin write hits
-    // the seed-row directly and updates the same aggregate stream. Both
-    // paths end up with the admin value winning — the row-count
-    // assertion makes the path explicit.
-    await stack.http.writeOk(
-      "config:write:set",
-      { key: SITE_KEY, value: "admin-override", scope: "tenant" },
-      TestUsers.systemAdmin,
-    );
-
-    await applyBootSeeds({ registry: stack.registry, db: stack.db });
-
-    const siteKeyDef = stack.registry.getConfigKey(SITE_KEY);
-    expect(siteKeyDef).toBeDefined();
-    const peek = await resolver.get(
-      SITE_KEY,
-      siteKeyDef!,
-      TestUsers.systemAdmin.tenantId,
-      TestUsers.systemAdmin.id,
-      stack.db,
-    );
-    expect(peek).toBe("admin-override");
-
-    // Row-count tells us which path was hit:
-    //   - 2 rows = override path (admin tenantId === SYSTEM_TENANT_ID,
-    //     updated the seed-stream in place).
-    //   - 3 rows = coexistence path (admin tenantId !== SYSTEM_TENANT_ID,
-    //     new specific-tenant row sits next to the seed system-row).
-    // Either is correct as long as the resolver picks the admin value.
-    const rows = await selectMany(stack.db, configValuesTable);
-    expect([2, 3]).toContain(rows.length);
-  });
-});