@rakay-technology/kraft 0.7.4

package/dist/server/migrations/0080_deployment_error_classification.sql

@@ -0,0 +1,26 @@
+-- Durable failure classification for a deployment.
+--
+-- The pipeline already classifies failures precisely: a port conflict throws
+-- DeployError(msg, "PORT_IN_USE", {port, pid, command, systemdUnit,
+-- isManagedDeployment, …}) and that reaches onFailure intact. It was then split,
+-- and only half of it was kept: `error_message` went to this table while
+-- `errorCode`/`errorDetails` went ONLY to the in-memory SSE session. Once that
+-- session was evicted (or the API restarted) all that survived a port conflict
+-- was an English sentence, so nothing could offer the operator — or an MCP agent
+-- — a way forward.
+--
+-- The one attempt to recover the code was inverted: build-status re-derived it
+-- with error_message.includes("PORT_IN_USE"), and none of the coded messages
+-- contain that token (they read "Port 3000 is already in use by …"). So the
+-- failures we DID classify lost their code and the ones we didn't got it guessed.
+--
+-- `error_code` is free text with no check constraint, matching `status` on this
+-- table: codes come from DeployError call sites across packages/adapters and must
+-- be extendable without a migration. `error_details` is the DeployError details
+-- bag verbatim (never contains secrets — it is process/port metadata).
+--
+-- Both nullable with no backfill: NULL means "not classified", which is exactly
+-- true of every pre-existing row.
+ALTER TABLE "deployment" ADD COLUMN IF NOT EXISTS "error_code" text;
+--> statement-breakpoint
+ALTER TABLE "deployment" ADD COLUMN IF NOT EXISTS "error_details" jsonb;

package/dist/server/migrations/0081_project_readiness_repair.sql

@@ -0,0 +1,34 @@
+-- Repair: create `project.readiness` on a database that skipped 0079.
+--
+-- WHY THIS EXISTS (and why it is not just "0079 again"):
+--
+-- 0079 was originally `0079_project_health_check` (adding `project.health_check`)
+-- and was replaced in place by `0079_project_readiness` (adding
+-- `project.readiness`) before either shipped. Both journal entries carry the SAME
+-- `when` — 1785882107324 — because the second reused the first's slot.
+--
+-- drizzle's migrator reads only the single most recent applied row and applies a
+-- migration when `lastDbMigration.created_at < migration.folderMillis`
+-- (pg-core/dialect.js). That comparison is STRICT, so on any database that had
+-- already run the old 0079, the new one is equal, not greater — it is skipped
+-- without a word. 0080 carried a later stamp and applied normally, which is why
+-- such a database ends up with 0080's columns, an orphan `health_check`, and no
+-- `readiness` at all. Every query selecting the project row then dies with
+-- `column "readiness" does not exist` (42703).
+--
+-- Bumping 0079's `when` would NOT fix it: the max applied stamp is now 0080's, so
+-- anything ordered before 0080 still compares as already-applied. The repair has
+-- to sort AFTER 0080, which is what this file is.
+--
+-- Idempotent on purpose. A fresh database creates the column at 0079 and this is
+-- a no-op; a database that skipped 0079 creates it here. Either way the end state
+-- is identical, so this is safe to leave in history permanently rather than being
+-- a one-off someone has to remember to delete.
+ALTER TABLE "project" ADD COLUMN IF NOT EXISTS "readiness" jsonb;--> statement-breakpoint
+
+-- Drop the column the replaced migration left behind. `health_check` was only
+-- ever created by 0079_project_health_check, which never shipped in a release and
+-- is referenced by no schema, query, or type in the codebase — so on the
+-- databases that have it, it is dead weight with a confusingly similar name to
+-- the compose service `healthcheck`. Guarded, so this is a no-op everywhere else.
+ALTER TABLE "project" DROP COLUMN IF EXISTS "health_check";

package/dist/server/migrations/0082_edge_target_verification.sql

@@ -0,0 +1,39 @@
+-- Proof that a routing TARGET is ours, as Kraft Cloud's shared edge now requires
+-- before forwarding `<slug>.kraft.io` to it.
+--
+-- Keyed on (organization_id, target) because that is what the upstream keys it on:
+-- one target serves every free domain on that box, so this is target-level state,
+-- not domain-level. One install holds several rows — its own address plus one per
+-- remote server it deploys to.
+--
+-- The token is persisted HERE, not only on the edge, because the upstream's list
+-- endpoint returns id/target/status/expiry but NOT the token. Verification lasts 90
+-- days and the upstream re-probes THE SAME token within 7 days of expiry; a 404 then
+-- expires it and the free domain stops resolving ~83 days after a green deploy with
+-- nothing in our logs. So a token that lived only on a box's disk would be
+-- unrecoverable after a rebuild, and rows here are never deleted when a free domain
+-- is dropped.
+--
+-- `server_id` is ON DELETE SET NULL, not cascade: losing the server row must not
+-- take the token with it.
+CREATE TABLE IF NOT EXISTS "edge_target_verification" (
+  "id" text PRIMARY KEY NOT NULL,
+  "organization_id" text NOT NULL REFERENCES "organization"("id") ON DELETE CASCADE,
+  "target" text NOT NULL,
+  "host" text NOT NULL,
+  "server_id" text REFERENCES "servers"("id") ON DELETE SET NULL,
+  "verification_id" integer,
+  "token" text,
+  "retired_tokens" jsonb,
+  "challenge_path" text,
+  "status" text NOT NULL DEFAULT 'pending',
+  "validated_ip" text,
+  "expires_at" timestamp,
+  "last_checked_at" timestamp,
+  "last_error" text,
+  "created_at" timestamp NOT NULL DEFAULT now(),
+  "updated_at" timestamp NOT NULL DEFAULT now()
+);
+--> statement-breakpoint
+CREATE UNIQUE INDEX IF NOT EXISTS "uq_edge_target_verification"
+  ON "edge_target_verification" ("organization_id", "target");

package/dist/server/migrations/0083_service_incident.sql

@@ -0,0 +1,84 @@
+-- Continuous container health monitoring: the durable memory behind the alerts.
+--
+-- Kraft knew a container had crashed at exactly ONE moment — the ~15s post-deploy
+-- stabilization watch. After that nobody looked again, so an OOM-kill at 3am or a
+-- Postgres that starts bouncing after a host reboot reached the operator only when a
+-- user complained. The health watch closes that, but a poller that alerts on "the
+-- container isn't running" gets muted within a day: a redeploy recreating containers,
+-- an operator's `docker stop`, an unreachable host, and a crash loop all look exactly
+-- like a failure at a point in time.
+--
+-- So the unit of alerting is an INCIDENT, not a state reading: opened once, escalated
+-- only when it gets worse, resolved once with a downtime duration. This table is that
+-- memory — it survives the control-plane restart that in-process state would not (a box
+-- down for three days must not re-page on every API restart), and it doubles as the
+-- project Health tab's history.
+CREATE TABLE IF NOT EXISTS "service_incident" (
+  "id" text PRIMARY KEY NOT NULL,
+  "organization_id" text NOT NULL REFERENCES "organization"("id") ON DELETE CASCADE,
+  -- Null for SERVER-scoped incidents (an unreachable box gets ONE incident, not one
+  -- per service on it — that fan-out is the single loudest source of alert fatigue).
+  "project_id" text REFERENCES "project"("id") ON DELETE CASCADE,
+  -- The resolved service row, when there is one. SET NULL, not cascade: deleting a
+  -- service must not erase the record of the outage it had (`service_key` still
+  -- identifies it, and `service_name` is snapshotted below).
+  "service_id" text REFERENCES "service"("id") ON DELETE SET NULL,
+  -- Stable identity across a container RECREATE, which is the whole point: every
+  -- deploy mints a new container id, so keying incidents on container id would open a
+  -- fresh incident for the same workload after each redeploy. Service id when we
+  -- resolved one, else the container name (single-app deploys have no service row);
+  -- `server:<id>` for server-scoped rows.
+  "service_key" text NOT NULL,
+  -- Snapshot of the display name at incident time — the alert text must still read
+  -- correctly after a rename, and history rows must not silently change meaning.
+  "service_name" text NOT NULL,
+  "server_id" text REFERENCES "servers"("id") ON DELETE SET NULL,
+  "container_id" text,
+  -- down | crash_loop | unhealthy | server_unreachable. Ordered by severity in the
+  -- watcher: an incident escalates upward (and re-notifies), never downward.
+  "kind" text NOT NULL,
+  "status" text NOT NULL DEFAULT 'open', -- open | resolved
+  "reason" text,
+  "exit_code" integer,
+  "restart_count" integer NOT NULL DEFAULT 0,
+  "oom_killed" boolean NOT NULL DEFAULT false,
+  -- Consecutive ticks that agreed on this verdict. An incident is only opened (and
+  -- only notified) at >= 2, so a snapshot taken mid-restart or during a slow
+  -- healthcheck start never pages anyone.
+  "confirmations" integer NOT NULL DEFAULT 0,
+  -- Notification bookkeeping. Deliberately a count, not a flag: open, escalation and
+  -- resolve each notify exactly once, and nothing else ever does.
+  "notify_count" integer NOT NULL DEFAULT 0,
+  "notified_at" timestamp,
+  "log_excerpt" text,
+  "opened_at" timestamp NOT NULL DEFAULT now(),
+  "resolved_at" timestamp,
+  -- Last tick that actually OBSERVED this workload. Not advanced when the host is
+  -- unreachable — during a connectivity loss we know nothing, so nothing is claimed.
+  "last_seen_at" timestamp NOT NULL DEFAULT now(),
+  "created_at" timestamp NOT NULL DEFAULT now(),
+  "updated_at" timestamp NOT NULL DEFAULT now()
+);
+--> statement-breakpoint
+-- One open incident per workload — the dedup primitive. As a partial unique index,
+-- "we are already alerting about this" is a DB invariant rather than sweep
+-- bookkeeping: two overlapping ticks (a manual Run now landing on a cron tick) cannot
+-- both open one and double-notify.
+CREATE UNIQUE INDEX IF NOT EXISTS "uq_service_incident_open"
+  ON "service_incident" ("project_id", "service_key")
+  WHERE "status" = 'open' AND "project_id" IS NOT NULL;
+--> statement-breakpoint
+-- Same invariant for server-scoped rows. Needs its own index because Postgres treats
+-- NULLs as distinct in a unique index, so the one above would happily allow a second
+-- open row for the same box.
+CREATE UNIQUE INDEX IF NOT EXISTS "uq_service_incident_open_server"
+  ON "service_incident" ("server_id")
+  WHERE "status" = 'open' AND "project_id" IS NULL;
+--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS "idx_service_incident_project"
+  ON "service_incident" ("project_id", "opened_at" DESC);
+--> statement-breakpoint
+-- Intent marker. `disableProject` stopped the container and recorded NOTHING, so
+-- "the operator turned this off" was unknowable — the health watch would page about
+-- every deliberately-disabled project, forever. Set on disable, cleared on enable.
+ALTER TABLE "project" ADD COLUMN IF NOT EXISTS "disabled_at" timestamp;

package/dist/server/migrations/0084_analytics_daily_rollup.sql

@@ -0,0 +1,72 @@
+-- Widen the daily analytics rollup: distinct visitors, top paths, status mix.
+--
+-- The visitor pipeline already persisted per-country counts, and the dashboard
+-- already rendered cards for "unique IPs" and a top-paths table. Neither was real:
+-- `top_paths` was hardcoded `[]` in the service layer, and "unique IPs" was
+-- `unique_requests` — the count of non-static REQUESTS — so five page views from
+-- one browser read as five visitors. These columns are what makes those two
+-- numbers mean what the UI has been claiming.
+--
+-- All three land HERE, on the daily table, rather than on the per-minute one:
+-- visitors and paths are the high-cardinality metrics, and holding them per-minute
+-- would multiply the edge's shared-dict key count by ~1440 to feed a chart nobody
+-- asked for — evicting, in the process, the request counters they annotate.
+-- Countries already live here for the same reason, and the edge keeps all four
+-- under one `g:{domain}:{day}:` key prefix so a reader gets the whole day in a
+-- single dict scan.
+--
+-- Additive with defaults on purpose: `migrations-additive.test.ts` rejects a
+-- NOT NULL column without a DEFAULT, because an older cross-version dump omits the
+-- column entirely and Drizzle then emits DEFAULT for it — with no default that's a
+-- NULL into NOT NULL on the newer receiver, i.e. a broken cloud/project transfer.
+
+-- Distinct visitors for the day, deduplicated AT THE EDGE and stored as a count.
+--
+-- Privacy is a property of where the dedup happens: the edge hashes each address
+-- with a salt that is generated on that box, rotates daily, and never leaves its
+-- shared memory. Only the cardinality of that set is written here. No address and
+-- no per-visitor row exists at any layer, which is what keeps the published
+-- "we don't collect behavioural analytics on your end users" true while still
+-- reporting a real visitor number.
+--
+-- Understates on a very busy domain: the edge's `visitors` zone LRU-evicts past
+-- roughly 1M distinct/day. mgmt_api `GET /status` reports that zone's free space so
+-- a reader can label the number approximate instead of presenting an eviction
+-- artifact as a measurement.
+ALTER TABLE "server_analytics_geo" ADD COLUMN IF NOT EXISTS "visitors" integer DEFAULT 0 NOT NULL;
+--> statement-breakpoint
+
+-- Top paths: { "/": 900, "/orders/:id": 120, "other": 40 }.
+--
+-- Normalized at the edge before it ever becomes a key: query string stripped (so a
+-- ?token= or ?session= can never be persisted here), numeric and UUID segments
+-- collapsed to `:id`, key length capped, and the tail past a cardinality cap folded
+-- into "other" — otherwise a scanner walking /wp-admin variants mints thousands of
+-- permanent keys and evicts the real counters.
+ALTER TABLE "server_analytics_geo" ADD COLUMN IF NOT EXISTS "paths" jsonb;
+--> statement-breakpoint
+
+-- Status-code mix: { "200": 4210, "404": 17, "502": 3 }. Status was captured into
+-- the edge's raw-request ring buffer (RAM, 1h) but never aggregated, so error rate
+-- was unanswerable from any persisted data. Bounded by construction.
+ALTER TABLE "server_analytics_geo" ADD COLUMN IF NOT EXISTS "statuses" jsonb;
+--> statement-breakpoint
+
+-- Widen the per-minute bandwidth counters from int4 to int8.
+--
+-- These are bytes for ONE MINUTE, and int4 caps at 2,147,483,647 — about 2.1 GB,
+-- which a single minute reaches at roughly 286 Mbps. That is unremarkable for a
+-- site serving video or large downloads. Past it Postgres raises "integer out of
+-- range", the upsert for that minute fails, and the scrape for the whole domain
+-- dies with it — so the busiest domains on a box would be precisely the ones with
+-- no analytics, and it would look like the feature simply didn't work for them.
+--
+-- Now that collection runs unattended on a schedule rather than only when someone
+-- opens the tab, that failure would happen in a job with nobody reading the error.
+--
+-- Widening is lossless and there is no application change: the edge already
+-- accumulates these as Lua numbers (doubles, exact to 2^53) and Drizzle reads them
+-- back with mode:"number", which is exact over the same range.
+ALTER TABLE "server_analytics" ALTER COLUMN "bandwidth_in" TYPE bigint;
+--> statement-breakpoint
+ALTER TABLE "server_analytics" ALTER COLUMN "bandwidth_out" TYPE bigint;

package/dist/server/migrations/0085_resource_usage.sql

@@ -0,0 +1,68 @@
+-- Resource usage history: the persisted series behind the Monitoring tab's
+-- CPU/memory chart.
+--
+-- Usage existed only as a live 5-second SSE stream, so closing the tab discarded
+-- everything. "Was memory climbing before the OOM at 3am" was unanswerable, which is
+-- the question the data exists to answer.
+--
+-- ── Why this is a SAMPLED series, not a counter series like server_analytics ──
+--
+-- Traffic is counted for free: the edge increments a shared-dict key on every
+-- request, so per-minute granularity costs nothing and is exact. Resource usage has
+-- to be PROBED, and `docker stats` occupies the daemon for roughly a second per
+-- container because it must collect two CPU samples to compute a delta — about 500x
+-- a `docker inspect`. The sampling cadence therefore IS the resolution, and the cost
+-- scales with container count. 5-minute buckets are the compromise between catching
+-- a spike and not pinning every daemon on the estate; ~288 rows/day/service.
+--
+-- ── serviceKey is NOT NULL text, not a nullable service_id FK ────────────────
+--
+-- Postgres treats NULLs as DISTINCT in a unique index, so a nullable column cannot
+-- carry the "this row is the project itself" case without the partial-index
+-- workaround migration 0083 needed for service_incident. A sentinel ('__app__',
+-- matching the health watch's own constant so both features name the same workload
+-- identically) keeps one plain unique index correct.
+--
+-- Accepted consequence: deleting a service leaves its samples behind until retention
+-- prunes them. That is the right trade — history should outlive the thing it
+-- describes — and the project cascade still bounds the growth.
+--
+-- ── What is deliberately absent ─────────────────────────────────────────────
+--
+-- No project-total row. For a compose project the total is the per-bucket SUM of its
+-- services, computed at read. Storing it too would duplicate rows that are free to
+-- drift from their own sources, and would be wrong the moment a service is added or
+-- removed mid-window.
+CREATE TABLE IF NOT EXISTS "resource_usage" (
+  "id" text PRIMARY KEY NOT NULL,
+  "project_id" text NOT NULL REFERENCES "project"("id") ON DELETE CASCADE,
+  -- service.id, or '__app__' for a single-container project.
+  "service_key" text NOT NULL,
+  -- Bucket start in epoch MINUTES (not a timestamp), floored to a multiple of 5 —
+  -- same integer-bucket convention as server_analytics.
+  "minute" integer NOT NULL,
+  -- Per-CORE percent, as the runtimes report it: >100 is correct on a multi-core box
+  -- and must not be clamped. Readers divide by core count for "share of this host".
+  "cpu_percent" real DEFAULT 0 NOT NULL,
+  "memory_mb" real DEFAULT 0 NOT NULL,
+  -- CUMULATIVE since container start, not per-bucket deltas — that is what the
+  -- runtimes expose. Readers difference consecutive buckets and clamp negatives to
+  -- zero, because a restart resets the counter and would otherwise plot as a large
+  -- negative spike. bigint: a long-lived busy container passes int4 in days.
+  -- Always 0 for bare deploys (per-process accounting needs eBPF or a netns), so a
+  -- reader must not present 0 here as "no network traffic".
+  "network_rx_bytes" bigint DEFAULT 0 NOT NULL,
+  "network_tx_bytes" bigint DEFAULT 0 NOT NULL,
+  "created_at" timestamp DEFAULT now() NOT NULL
+);
+--> statement-breakpoint
+
+-- Makes a repeated sample for the same bucket a no-op (insert ... on conflict do
+-- nothing) rather than a double count, so the whole sweep is safely re-runnable.
+CREATE UNIQUE INDEX IF NOT EXISTS "uq_resource_usage_project_service_minute"
+  ON "resource_usage" ("project_id", "service_key", "minute");
+--> statement-breakpoint
+
+-- Every read is "this project over this window".
+CREATE INDEX IF NOT EXISTS "idx_resource_usage_project_minute"
+  ON "resource_usage" ("project_id", "minute");

package/dist/server/migrations/0086_remote_infra_updates.sql

@@ -0,0 +1,41 @@
+-- Remote infra (edge / mail container) update tracking.
+--
+-- When the control plane's APP_VERSION moves forward, the edge/mail containers
+-- already deployed on remote servers stay on their old image tag. Two additions
+-- drive the "monitor → advise → apply" loop for that drift:
+--
+--   instance_settings.auto_update_infra / last_seen_version — the instance-wide
+--     auto-update toggle and the version the infra reconcile last ran for (so the
+--     boot hook fires exactly once per upgrade). Both additive: the boolean
+--     carries a DEFAULT, last_seen_version is nullable.
+--
+--   server_container_status — the container sibling of server_module_status.
+--     One row per (server, component); "behind" is a plain tag comparison
+--     (running image ref != pinned image ref), since infra images are pinned to
+--     APP_VERSION. Mirrors the module table's org+behind index and unique key.
+ALTER TABLE "instance_settings" ADD COLUMN IF NOT EXISTS "auto_update_infra" boolean DEFAULT false NOT NULL;
+--> statement-breakpoint
+ALTER TABLE "instance_settings" ADD COLUMN IF NOT EXISTS "last_seen_version" text;
+--> statement-breakpoint
+CREATE TABLE IF NOT EXISTS "server_container_status" (
+  "id" text PRIMARY KEY NOT NULL,
+  "organization_id" text REFERENCES "organization"("id") ON DELETE CASCADE,
+  "server_id" text NOT NULL REFERENCES "servers"("id") ON DELETE CASCADE,
+  "component" text NOT NULL,
+  "running_label" text,
+  "pinned_label" text,
+  "running_version" text,
+  "pinned_version" text,
+  "behind" boolean DEFAULT false NOT NULL,
+  "latest_in_progress" boolean DEFAULT false NOT NULL,
+  "detail" jsonb,
+  "checked_at" timestamp DEFAULT now() NOT NULL,
+  "created_at" timestamp DEFAULT now() NOT NULL,
+  "updated_at" timestamp DEFAULT now() NOT NULL
+);
+--> statement-breakpoint
+CREATE UNIQUE INDEX IF NOT EXISTS "uq_server_container_status"
+  ON "server_container_status" ("server_id", "component");
+--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS "idx_server_container_status_org_behind"
+  ON "server_container_status" ("organization_id", "behind");

package/dist/server/migrations/0087_server_container_version_columns.sql

@@ -0,0 +1,17 @@
+-- Repair: add `server_container_status.running_version` / `pinned_version` on a
+-- database that ran an earlier form of 0086.
+--
+-- 0086 was edited in place after it had already been applied: the version columns
+-- were added to its CREATE TABLE, but that create is `IF NOT EXISTS`, so on any
+-- database that had already run the older 0086 the table exists and the amended
+-- create is a silent no-op — the columns never appear. drizzle's migrator then
+-- refuses to re-run 0086 (its `when` equals the last-applied stamp, and the
+-- comparison is strict `<`; see 0081_project_readiness_repair for the same trap),
+-- so nothing else patches it either. Every `listByOrg` then dies with
+-- `column "running_version" does not exist` (42703).
+--
+-- Idempotent and stamped after 0086, so it sorts as a fresh migration: a database
+-- created cleanly gets the columns at 0086 and this is a no-op; a database that
+-- ran the stale 0086 gets them here. Safe to keep in history permanently.
+ALTER TABLE "server_container_status" ADD COLUMN IF NOT EXISTS "running_version" text;--> statement-breakpoint
+ALTER TABLE "server_container_status" ADD COLUMN IF NOT EXISTS "pinned_version" text;

package/dist/server/migrations/0088_audit_source_and_settings.sql

@@ -0,0 +1,27 @@
+-- Audit log: call source + per-org recording switch.
+--
+--   audit_event.source — WHERE the action came in from: "dashboard", "mcp",
+--     "cli", "api", "webhook", "system". Nullable on purpose: rows written
+--     before this migration have no knowable source and must not be
+--     mislabelled as any particular one, so they render as "Unknown". This is
+--     what makes "show me only what the AI assistant did" answerable at all —
+--     MCP tool calls re-enter the app through app.fetch() with nothing but an
+--     Authorization header, so until now an MCP-driven write and a CLI write
+--     produced identical rows.
+--
+--   audit_settings — recording on/off + retention, PER ORGANIZATION. Not
+--     instance_settings (one row would let a single tenant disable auditing for
+--     every org on a CLOUD_MODE instance) and not organization.metadata (Better
+--     Auth owns those writes, which is why the auditRetentionDays documented
+--     there never got a writer). Default enabled = true: auditing stays on
+--     unless an admin turns it off.
+ALTER TABLE "audit_event" ADD COLUMN IF NOT EXISTS "source" text;
+--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS "audit_event_org_source_idx" ON "audit_event" ("organization_id","source","created_at" DESC);
+--> statement-breakpoint
+CREATE TABLE IF NOT EXISTS "audit_settings" (
+  "organization_id" text PRIMARY KEY NOT NULL REFERENCES "organization"("id") ON DELETE CASCADE,
+  "enabled" boolean DEFAULT true NOT NULL,
+  "retention_days" integer DEFAULT 90 NOT NULL,
+  "updated_at" timestamp DEFAULT now() NOT NULL
+);

package/dist/server/migrations/0089_auto_scan_infra.sql

@@ -0,0 +1,7 @@
+-- instance_settings.auto_scan_infra — when on (default), the dashboard runs one
+-- detect-only container scan on a relevant surface load (Infrastructure tab /
+-- home) if the cached drift state is stale, so the attention dot + issue list
+-- stay fresh without a manual Scan. Detect-only; auto-APPLY stays the separate
+-- auto_update_infra. Idempotent ADD COLUMN IF NOT EXISTS + DEFAULT true so both
+-- a clean create and an existing settings row converge on "on".
+ALTER TABLE "instance_settings" ADD COLUMN IF NOT EXISTS "auto_scan_infra" boolean DEFAULT true NOT NULL;

package/dist/server/migrations/0090_project_collect_paths.sql

@@ -0,0 +1,18 @@
+-- Top Paths becomes opt-in.
+--
+-- The per-path aggregation is the one analytics dimension that isn't effectively free.
+-- Measured on the shipped edge image, per request:
+--
+--   paths (whole block)     1.72 us   <- 57% of the log handler's counter path
+--     of which string work  1.38 us   normalize_path + is_static_asset
+--   minute buckets          0.61 us
+--   country                 0.24 us
+--   status                  0.14 us
+--
+-- It is also the highest-cardinality dimension (up to 2000 keys per domain per day) and
+-- the largest column in the daily rollup. So it is now a per-project switch, read on the
+-- hot path from the edge's `rules` shared dict and pushed there on every route apply.
+--
+-- DEFAULT false, which turns it off for existing projects as well. Deliberate: no one
+-- opted into the cost, so no one should keep paying it without asking.
+ALTER TABLE "project" ADD COLUMN IF NOT EXISTS "collect_paths" boolean DEFAULT false NOT NULL;

package/dist/server/migrations/0091_project_server_id.sql

@@ -0,0 +1,26 @@
+-- Durable server ownership on the project.
+--
+-- A project's deploy target lived ONLY in the active deployment's volatile
+-- meta.serverId. When resolveSnapshotTarget couldn't re-derive that binding from
+-- a fresh/partial snapshot, the deploy fell back to "local", which then nulled
+-- the project's verified custom-domain ports and regressed the Access URL to
+-- localhost:3000. This makes the server binding a durable, first-class column.
+--
+-- cloudWorkspaceId still owns "is this a cloud project", so we deliberately do
+-- NOT add a deployTarget column (that would be a second source of truth for the
+-- same fact); the effective target is derived — cloudWorkspaceId ? "cloud" :
+-- server_id ? "server" : "local".
+--
+-- ON DELETE SET NULL: removing a server unbinds its projects rather than
+-- cascade-deleting them.
+ALTER TABLE "project" ADD COLUMN IF NOT EXISTS "server_id" text REFERENCES "servers"("id") ON DELETE SET NULL;
+--> statement-breakpoint
+-- Backfill the binding from each project's active-deployment meta so existing
+-- server-hosted projects survive the next redeploy without regressing to local.
+UPDATE "project" SET "server_id" = (
+  SELECT d."meta"->>'serverId'
+  FROM "deployment" d
+  WHERE d."id" = "project"."active_deployment_id"
+)
+WHERE "server_id" IS NULL
+  AND "active_deployment_id" IS NOT NULL;

package/dist/server/migrations/0092_project_internal_alias.sql

@@ -0,0 +1,13 @@
+-- User-chosen internal DNS alias for a single-app native project.
+--
+-- Single-app containers now join their own `kraft-<slug>` network with a
+-- stable default alias (`<slug>`), the same east-west reachability compose
+-- services already have. This column lets an operator add a custom hostname
+-- that resolves ALONGSIDE the default (both point at the container) — it never
+-- replaces the default and never changes public exposure (the edge stays the
+-- sole public ingress; publishing is loopback-only).
+--
+-- Nullable, no default: absence means "default alias only" and existing rows
+-- need no backfill. Compose services store the equivalent in the zero-migration
+-- `service.advanced.alias` JSONB, so only single-app needs a column.
+ALTER TABLE "project" ADD COLUMN IF NOT EXISTS "internal_alias" text;

package/dist/server/migrations/0093_service_incident_org_index.sql

@@ -0,0 +1,13 @@
+-- Org-wide incident reads for the global issue tracker.
+--
+-- The existing indexes on this table are project-keyed (`idx_service_incident_project`)
+-- or exist to enforce the one-open-incident invariant. Both are wrong shapes for the
+-- new question: "every incident in THIS organization, newest first" — the Issues feed's
+-- Open tab and its Resolved tab, which sorts org-wide across up to 30 days of retained
+-- history. Without this the feed sequentially scans the whole table and filters, which
+-- gets slower exactly as an instance accumulates the history that makes the tab useful.
+--
+-- Covers both scopes: server-scoped rows have `project_id IS NULL`, so a project-keyed
+-- index can't serve them at all.
+CREATE INDEX IF NOT EXISTS "idx_service_incident_org"
+  ON "service_incident" ("organization_id", "opened_at" DESC);

package/dist/server/migrations/0094_backup_restore_meta.sql

@@ -0,0 +1,15 @@
+-- Record WHICH integrity check a restore actually performed.
+--
+-- Prepare used to comment that it verified every artifact's sha256 while
+-- comparing only byte sizes. Now that it really re-hashes the archive, the row
+-- has to say so — because the check is downgradeable (a run with no recorded
+-- digest falls back to size-only, and a policy can defer verification to apply
+-- time), and "restore succeeded" means something different in each case. An
+-- operator reading a month-old restore has no other way to tell a re-hashed
+-- archive from a length-matched one.
+--
+-- Keys written today: `integrity` ("sha256" | "size-only" | "deferred"),
+-- `verifiedBytes`, `verifyMs`, `manifest` ("verified" | "missing").
+-- JSONB rather than columns so the cancel/partial-write facts that follow need
+-- no further migration.
+ALTER TABLE "backup_restore" ADD COLUMN IF NOT EXISTS "meta" jsonb DEFAULT '{}'::jsonb;

package/dist/server/migrations/0095_backup_restore_cancel.sql

@@ -0,0 +1,19 @@
+-- Make "cancel a restore" durable.
+--
+-- Cancel used to be advisory at best: it refused `applying` outright, and for
+-- `preparing` it wrote the row while the running phase carried on and
+-- overwrote it with `prepared` — so the operator saw a cancel that never
+-- happened. Cancelling has to survive the phase it interrupts, and the node
+-- receiving the request is not guaranteed to be the node running the apply, so
+-- the in-process AbortController cannot be the only signal.
+--
+-- `cancel_requested_at` is also the force-terminal window: an `applying` row
+-- whose request is older than a couple of minutes (operator pressed cancel,
+-- waited, pressed again) can be force-terminaled without a second endpoint,
+-- which is the only escape from a wedged row that otherwise blocks project
+-- deletion.
+ALTER TABLE "backup_restore" ADD COLUMN IF NOT EXISTS "cancel_requested" boolean DEFAULT false NOT NULL;
+--> statement-breakpoint
+ALTER TABLE "backup_restore" ADD COLUMN IF NOT EXISTS "cancel_requested_at" timestamp;
+--> statement-breakpoint
+ALTER TABLE "backup_restore" ADD COLUMN IF NOT EXISTS "cancelled_at" timestamp;

package/dist/server/migrations/0096_backup_policy_retention_defaults.sql

@@ -0,0 +1,20 @@
+-- Turn retention on for policies that never said anything about it.
+--
+-- `retain_count` and `retain_days` were the only two fields on the policy
+-- insert with neither an API default nor a column default, so every policy
+-- created through the API or MCP stored NULL for both. `prunePolicy`
+-- short-circuits on "no retention configured", so retention silently never ran
+-- for those policies and their runs accumulated until the destination filled.
+-- The dashboard's form defaults to 7, so a human creating a policy in the UI
+-- got retention and the same policy created over the API did not.
+--
+-- 7 = the dashboard's own default (PolicyEditor), now shared as
+-- DEFAULT_RETAIN_COUNT so the column, the API fallback, and the form agree.
+--
+-- The backfill is what actually fixes instances running today, and it is
+-- narrowed to rows where BOTH fields are null: a policy with only `retain_days`
+-- set has retention configured deliberately, and writing a count there would
+-- silently tighten a window the operator chose.
+ALTER TABLE "backup_policy" ALTER COLUMN "retain_count" SET DEFAULT 7;
+--> statement-breakpoint
+UPDATE "backup_policy" SET "retain_count" = 7 WHERE "retain_count" IS NULL AND "retain_days" IS NULL;

package/dist/server/migrations/0097_update_status_upstream_only.sql

@@ -0,0 +1,35 @@
+-- update_status becomes an UPSTREAM-only cache.
+--
+-- The table used to cache both halves of the drift answer: what the source offers
+-- (upstream) and what is currently deployed. Only the first half is expensive and
+-- poll-only. The second half — `behind`, `latest_in_progress`, `current_label` —
+-- is derived from the project's ACTIVE deployment, which seven separate code paths
+-- write (deploy success, rollback, reconcile, activate, clear, self-deploy,
+-- migrate). Caching it meant each of those needed an invalidation hook; only one
+-- ever had it, so rows froze mid-window and the dashboard advertised updates for
+-- commits the operator had already shipped.
+--
+-- Those columns are now computed on read, so keeping them would leave a copy that
+-- looks authoritative while describing a superseded release. `latest_label` goes
+-- too: it's rendered from `detail` alongside the live current label, in one code
+-- path, so the two can never disagree.
+--
+-- Existing rows keep `detail`, but rows written before this migration carry only
+-- the 7-char sha prefix in the dropped `latest_label` — never a full `latestSha`
+-- in `detail` — so a commit row cannot be compared until it is re-polled. Clear
+-- them and let `updates:scan` (or the dashboard's explicit check) repopulate;
+-- until then those projects simply report no update, which is the conservative
+-- direction.
+DELETE FROM "update_status";
+--> statement-breakpoint
+DROP INDEX IF EXISTS "idx_update_status_org_behind";
+--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS "idx_update_status_org" ON "update_status" ("organization_id");
+--> statement-breakpoint
+ALTER TABLE "update_status" DROP COLUMN IF EXISTS "behind";
+--> statement-breakpoint
+ALTER TABLE "update_status" DROP COLUMN IF EXISTS "latest_in_progress";
+--> statement-breakpoint
+ALTER TABLE "update_status" DROP COLUMN IF EXISTS "current_label";
+--> statement-breakpoint
+ALTER TABLE "update_status" DROP COLUMN IF EXISTS "latest_label";

package/dist/server/migrations/0098_instance_product_mode.sql

@@ -0,0 +1,12 @@
+-- Kraft Mail: which product this instance presents itself as.
+--
+-- Nullable with NO default, deliberately. The instance_settings row exists on
+-- every instance, so a NOT NULL DEFAULT 'platform' would write a concrete value
+-- everywhere and permanently shadow the KRAFT_PRODUCT env var — the resolver
+-- reads `settings.product_mode ?? env.KRAFT_PRODUCT`, so "unset" has to stay
+-- representable. NULL means "no instance override".
+--
+-- Presentation scope only: this hides nav entries and rebrands the shell. It is
+-- not an authorization boundary and no route reads it — webmail deploys through
+-- the ordinary project pipeline, so the platform endpoints stay live in mail mode.
+ALTER TABLE "instance_settings" ADD COLUMN IF NOT EXISTS "product_mode" text;

package/dist/server/migrations/0099_mail_webmail_project.sql

@@ -0,0 +1,24 @@
+-- The webmail project serving a mail server, as a stored FK.
+--
+-- Webmail is now an ordinary catalog app (packages/core/src/apps/catalog/webmail.json)
+-- installed through the SAME generic installer as every other app, so its slug is
+-- derived from the project NAME the operator typed. The link therefore cannot be a
+-- naming convention any more: the old lookup parsed `webmail-<serverId>` back out of
+-- the slug, which the generic installer never produces — and which, while it existed,
+-- mislinked any project a user happened to name "Webmail Prod" (slug `webmail-prod`,
+-- read back as mail server "prod").
+--
+-- Nullable: most servers have no webmail, and an operator may run one outside
+-- kraft. ON DELETE SET NULL so deleting the webmail project clears the link and
+-- /emails falls back to the install CTA rather than pointing at a row that is gone.
+--
+-- No backfill. A pre-existing webmail project still carries the retired
+-- `mail-webmail` template id and the `webmail-<serverId>` slug; the mail status
+-- resolver keeps that legacy slug lookup as a fallback for exactly those rows, and
+-- stamps this column the first time it resolves one.
+ALTER TABLE "mail_servers" ADD COLUMN IF NOT EXISTS "webmail_project_id" text;--> statement-breakpoint
+
+DO $$ BEGIN
+  ALTER TABLE "mail_servers" ADD CONSTRAINT "mail_servers_webmail_project_id_project_id_fk"
+    FOREIGN KEY ("webmail_project_id") REFERENCES "public"."project"("id") ON DELETE set null ON UPDATE no action;
+EXCEPTION WHEN duplicate_object THEN NULL; END $$;