@agent-team-foundation/first-tree-hub 0.14.5 → 0.14.6

package/dist/drizzle/0038_chat_membership_user_state.sql

@@ -1,223 +0,0 @@
--- Chat data model restructure — Step 2 (migration N).
--- See proposals/chat-data-model-restructure.20260512.md §8 (schema)
--- and §9 (migration path).
---
--- Replaces the chat_participants / chat_subscriptions split with a
--- three-layer model: chats (entity) + chat_membership (structure) +
--- chat_user_state (per-user private state). This migration creates
--- the two new tables and back-fills them from the legacy two; the
--- legacy tables stay in place. A follow-up migration (0038, separate
--- PR) drops them once the new code stabilises ≥1 workday in prod —
--- see §9.2 step 6 for why those are split.
---
--- Pre-flight collision probe (§9.1) MUST be run against staging and
--- prod read-replicas before this PR is opened. If
---   SELECT chat_id, agent_id
---     FROM chat_participants p JOIN chat_subscriptions s USING (chat_id, agent_id)
--- returns any rows, the cutover preference (speaker row wins) applies
--- automatically via the insert ordering below, but the surprise should
--- be investigated first.
---
--- Service-layer integrity (no FK / CHECK / trigger): consistent with
--- messages / inbox_entries / notifications. The DB-level
--- `ON DELETE CASCADE` from chats.id is intentionally NOT carried over
--- — chat hard-delete paths must explicitly clean these tables (see
--- §8.5, §11.7 chat-delete integration test).
---
--- Migration 0037 is hand-written. drizzle-kit generate refuses to
--- diff against the pre-0019 snapshot; we have followed this convention
--- for every migration since 0019 (see 0036's header).
-
-CREATE TABLE IF NOT EXISTS "chat_membership" (
-  "chat_id"     text NOT NULL,
-  "agent_id"    text NOT NULL,
-  "role"        text NOT NULL DEFAULT 'member',
-  "access_mode" text NOT NULL,
-  "mode"        text NOT NULL DEFAULT 'full',
-  "source"      text NOT NULL DEFAULT 'manual',
-  "joined_at"   timestamp with time zone NOT NULL DEFAULT now(),
-  CONSTRAINT "chat_membership_pkey" PRIMARY KEY ("chat_id", "agent_id")
-);
-
---> statement-breakpoint
-CREATE INDEX IF NOT EXISTS "idx_membership_agent"
-  ON "chat_membership" ("agent_id");
-
---> statement-breakpoint
--- Index name matches §8.2 of the proposal (`idx_membership_chat_role`).
--- The trailing token is `role` (the legacy speaker/watcher *role* concept)
--- rather than `access_mode` (the literal column name) to align with the
--- design checklist.
-CREATE INDEX IF NOT EXISTS "idx_membership_chat_role"
-  ON "chat_membership" ("chat_id", "access_mode");
-
---> statement-breakpoint
-CREATE TABLE IF NOT EXISTS "chat_user_state" (
-  "chat_id"              text NOT NULL,
-  "agent_id"             text NOT NULL,
-  "last_read_at"         timestamp with time zone,
-  "unread_mention_count" integer NOT NULL DEFAULT 0,
-  CONSTRAINT "chat_user_state_pkey" PRIMARY KEY ("chat_id", "agent_id")
-);
-
---> statement-breakpoint
-CREATE INDEX IF NOT EXISTS "idx_user_state_agent"
-  ON "chat_user_state" ("agent_id");
-
---> statement-breakpoint
--- Partial index for the unread-badge / ?filter=unread lookup. Most rows
--- have unread_mention_count = 0; bounding the index by the actual
--- unread row count keeps the scan cheap regardless of table size.
-CREATE INDEX IF NOT EXISTS "idx_user_state_unread"
-  ON "chat_user_state" ("agent_id")
-  WHERE unread_mention_count > 0;
-
---> statement-breakpoint
--- Back-fill chat_membership from chat_participants. These are the
--- "speaker" rows — they retain their owner/member role from the legacy
--- table and gain access_mode = 'speaker'. `joined_at` carries over
--- verbatim. `source = 'manual'` is the conservative default; we do not
--- attempt to reconstruct the original add-path retroactively.
--- Speaker-wins merge policy per proposal §9.2 step 3 and §11.7 checklist.
--- Since `chat_participants` is loaded BEFORE `chat_subscriptions`, the
--- INSERT below cannot produce a conflict in a clean cutover. The
--- ON CONFLICT DO UPDATE is the explicit double-protection requested by
--- the proposal: if a dirty write between the §9.1 probe and the
--- maintenance window has somehow planted a watcher row first (e.g. a
--- partial / aborted prior migration), upgrade it in place to speaker
--- rather than silently leaving it as a watcher (which DO NOTHING would
--- have done). `joined_at` keeps the earliest known timestamp so the
--- audit trail is not flattened.
-INSERT INTO "chat_membership"
-  ("chat_id", "agent_id", "role", "access_mode", "mode", "source", "joined_at")
-SELECT
-  cp."chat_id",
-  cp."agent_id",
-  COALESCE(cp."role", 'member'),
-  'speaker',
-  COALESCE(cp."mode", 'full'),
-  'manual',
-  COALESCE(cp."joined_at", now())
-FROM "chat_participants" cp
-ON CONFLICT ("chat_id", "agent_id") DO UPDATE SET
-  "access_mode" = 'speaker',
-  "role"        = EXCLUDED."role",
-  "mode"        = EXCLUDED."mode",
-  "source"      = EXCLUDED."source",
-  "joined_at"   = LEAST("chat_membership"."joined_at", EXCLUDED."joined_at");
-
---> statement-breakpoint
--- Back-fill chat_membership from chat_subscriptions. These are the
--- "watcher" rows.
---
--- Speaker-wins on collision: if a row already exists for this
--- (chat, agent) pair it is by construction a speaker (the previous
--- INSERT just wrote it). The guarded UPDATE makes this a no-op for
--- existing speaker rows (the `WHERE chat_membership.access_mode =
--- 'watcher'` guard is never satisfied), so the speaker is preserved
--- untouched. We use ON CONFLICT DO UPDATE rather than DO NOTHING per
--- proposal §9.2 step 3 — the merge policy lives in the SQL itself,
--- not implicitly in the INSERT ordering.
---
--- source = 'auto_manager' captures that watcher rows historically came
--- from recomputeChatWatchers' anchor-based set rebuild. This default is
--- harmless even for the rare manually-attached watcher rows.
-INSERT INTO "chat_membership"
-  ("chat_id", "agent_id", "role", "access_mode", "mode", "source", "joined_at")
-SELECT
-  cs."chat_id",
-  cs."agent_id",
-  'member',
-  'watcher',
-  'full',
-  'auto_manager',
-  COALESCE(cs."created_at", now())
-FROM "chat_subscriptions" cs
-ON CONFLICT ("chat_id", "agent_id") DO UPDATE SET
-  "joined_at" = LEAST("chat_membership"."joined_at", EXCLUDED."joined_at")
-WHERE "chat_membership"."access_mode" = 'watcher';
-
---> statement-breakpoint
--- Back-fill chat_user_state from chat_participants. Only rows whose
--- read state was actually touched (lastReadAt non-null OR
--- unreadMentionCount > 0) are materialised — the rest can be served
--- via COALESCE-defaults at read time and would only bloat the table.
---
--- Speaker-wins: no prior row can exist for this (chat, agent) pair in
--- a clean cutover. The ON CONFLICT DO UPDATE is defensive against a
--- partial / aborted prior migration leaving a stale row behind — we
--- overwrite with the authoritative speaker-side read state per §9.2.
-INSERT INTO "chat_user_state"
-  ("chat_id", "agent_id", "last_read_at", "unread_mention_count")
-SELECT
-  cp."chat_id",
-  cp."agent_id",
-  cp."last_read_at",
-  cp."unread_mention_count"
-FROM "chat_participants" cp
-WHERE cp."last_read_at" IS NOT NULL
-   OR cp."unread_mention_count" > 0
-ON CONFLICT ("chat_id", "agent_id") DO UPDATE SET
-  "last_read_at"         = EXCLUDED."last_read_at",
-  "unread_mention_count" = EXCLUDED."unread_mention_count";
-
---> statement-breakpoint
--- Same back-fill from chat_subscriptions. Speaker-wins: if a row was
--- written above from chat_participants, that participant-side row
--- represents the speaker's authoritative read state and must not be
--- clobbered. The guarded UPDATE has WHERE FALSE so the conflict path
--- is a true no-op; we use DO UPDATE (over DO NOTHING) to keep the
--- merge policy explicit in the SQL itself per §9.2 step 3.
-INSERT INTO "chat_user_state"
-  ("chat_id", "agent_id", "last_read_at", "unread_mention_count")
-SELECT
-  cs."chat_id",
-  cs."agent_id",
-  cs."last_read_at",
-  cs."unread_mention_count"
-FROM "chat_subscriptions" cs
-WHERE cs."last_read_at" IS NOT NULL
-   OR cs."unread_mention_count" > 0
-ON CONFLICT ("chat_id", "agent_id") DO UPDATE SET
-  "last_read_at" = "chat_user_state"."last_read_at"
-WHERE FALSE;
-
---> statement-breakpoint
--- Row-count assertions. Fail the migration loudly if the back-fills
--- did not materialise the expected number of rows. UNION (deduping by
--- (chat_id, agent_id)) matches the speaker-wins merge policy above.
-DO $$
-DECLARE
-  expected_membership int;
-  actual_membership   int;
-  expected_state      int;
-  actual_state        int;
-BEGIN
-  SELECT COUNT(*) INTO expected_membership FROM (
-    SELECT "chat_id", "agent_id" FROM "chat_participants"
-    UNION
-    SELECT "chat_id", "agent_id" FROM "chat_subscriptions"
-  ) sub;
-
-  SELECT COUNT(*) INTO actual_membership FROM "chat_membership";
-
-  IF expected_membership <> actual_membership THEN
-    RAISE EXCEPTION 'chat_membership row count mismatch: expected % got %',
-      expected_membership, actual_membership;
-  END IF;
-
-  SELECT COUNT(*) INTO expected_state FROM (
-    SELECT "chat_id", "agent_id" FROM "chat_participants"
-     WHERE "last_read_at" IS NOT NULL OR "unread_mention_count" > 0
-    UNION
-    SELECT "chat_id", "agent_id" FROM "chat_subscriptions"
-     WHERE "last_read_at" IS NOT NULL OR "unread_mention_count" > 0
-  ) sub;
-
-  SELECT COUNT(*) INTO actual_state FROM "chat_user_state";
-
-  IF expected_state <> actual_state THEN
-    RAISE EXCEPTION 'chat_user_state row count mismatch: expected % got %',
-      expected_state, actual_state;
-  END IF;
-END $$;

package/dist/drizzle/0039_drop_chat_participants_subscriptions.sql

@@ -1,26 +0,0 @@
--- Chat data model restructure — Step 3 (drop legacy).
--- See proposals/chat-data-model-restructure.20260512.md §9.2 step 6
--- and §12.2 (catastrophic rollback boundary).
---
--- PR-B of the two-PR cutover. PR-A (#325, migration 0038) created
--- `chat_membership` + `chat_user_state` and back-filled them from
--- `chat_participants` + `chat_subscriptions`. The service layer has
--- been cutover to read/write only the new tables since PR-A. This
--- migration drops the legacy tables now that ≥1 workday of post-deploy
--- observation has passed without anomalies.
---
--- ROLLBACK is catastrophic post-this-migration: the legacy tables are
--- gone and require a backup-restore + re-run of 0038 to recover. This
--- is the explicit reason PR-A and PR-B were split — PR-A's reverse
--- migration is loss-free, PR-B's is not (§12.2). Do NOT merge this
--- before ops confirms PR-A stability.
---
--- Service-layer dependency check (run before merging):
---   git grep 'chat_participants\|chat_subscriptions' packages/server/src/
--- should return only doc / comment hits — any live query reference is
--- a blocker.
-
-DROP TABLE IF EXISTS "chat_subscriptions";
-
---> statement-breakpoint
-DROP TABLE IF EXISTS "chat_participants";

package/dist/drizzle/0040_chat_user_state_engagement.sql

@@ -1,24 +0,0 @@
--- Per-(chat, user) engagement state on `chat_user_state`.
--- Replaces the design of closed PR #316, which originally tried to add
--- this column to both `chat_participants` and `chat_subscriptions` and
--- was rejected for forcing double-writes + state-carry across the
--- speaker/watcher boundary. After the data-model restructure
--- (proposals/chat-data-model-restructure.20260512.md, migrations
--- 0038/0039), the natural home is `chat_user_state` — sitting next to
--- the other per-user private columns (`last_read_at`,
--- `unread_mention_count`).
---
--- Values: 'active' (default) | 'archived' | 'deleted'. Auto-revive
--- archived → active happens on new message in `applyAfterFanOut`;
--- `deleted` is sticky and reachable only via the chat detail page +
--- Restore button.
---
--- `chat_user_state` rows are lazy-materialised (row only created on
--- first markRead / mention / engagement write). The service layer
--- reads via `COALESCE(engagement_status, 'active')`, so existing rows
--- without an explicit value (and rows that don't yet exist) both
--- resolve to `'active'` — no back-fill needed and the NOT NULL DEFAULT
--- handles new INSERTs.
-
-ALTER TABLE "chat_user_state"
-  ADD COLUMN "engagement_status" text NOT NULL DEFAULT 'active';

package/dist/drizzle/0041_notifications_dedup_key.sql

@@ -1,29 +0,0 @@
--- DB-backed deduplication for the notifications table.
---
--- Before this migration, the server kept an in-memory Map keyed by
--- `(agentId, notificationType)` to suppress duplicate notifications within a
--- five-minute window. That broke in two important ways:
---
---   1. Multi-instance deployments: each server process owned its own Map, so
---      a notification produced on instance A passed instance B's dedupe gate
---      unchanged. Operators saw the same row inserted multiple times during
---      load-balancer failover or rolling restart.
---   2. Process restart wiped the Map, re-opening the dedupe window for
---      whatever events had fired just before.
---
--- The new model is purely DB-driven. A producer optionally supplies a
--- `dedup_key` (e.g. `agent:{uuid}:error`, `chat:{uuid}:completed`). The
--- partial unique index below scopes uniqueness to `(organization_id,
--- dedup_key)` *while the prior row is still unread*. Re-emitting the same
--- key while the previous notification sits unread is a no-op (the
--- application uses `ON CONFLICT DO NOTHING`); after the user acknowledges
--- the prior row, a fresh notification can land again.
---
--- Producers without a `dedup_key` keep the legacy always-insert behaviour,
--- so this column is purely additive — no back-fill, no NOT NULL constraint.
-
-ALTER TABLE "notifications" ADD COLUMN "dedup_key" text;
-
-CREATE UNIQUE INDEX "uq_notifications_org_dedup_unread"
-  ON "notifications" ("organization_id", "dedup_key")
-  WHERE read = false AND dedup_key IS NOT NULL;

package/dist/drizzle/0042_notifications_drop_legacy_types.sql

@@ -1,36 +0,0 @@
--- Drop notification rows whose `type` is no longer in the shared schema.
---
--- Three types were removed in earlier work but their rows were left behind:
---
---   * `agent_disconnected` — producer deleted by PR #348 (the
---     systemctl-restart spam fix), schema enum entry deleted later. 37 rows
---     still in dev hub at the time of writing, with no UI label and no
---     click target.
---   * `session_completed` — removed end-to-end in this PR (was 56% of recent
---     notifications, duplicating the conversation list's "latest message"
---     signal). Without the cleanup, the bell would keep surfacing them
---     until each org's user marks them all read manually.
---   * `session_error` — long-dead type: schema entry + UI label existed,
---     but no producer ever wrote one. Cleanup is defensive — any stray
---     rows from a hand-written test or prod-DB experiment go.
---
--- `notifications.type` is a `text` column (not a PG enum), so this is a
--- pure data-cleanup migration — no schema change, no type-cast risk.
---
--- The unread-only branch handles the transition window for rows still on
--- the previous per-type dedup key (`agent:{id}:agent_error|blocked|stale`).
--- They co-exist with new `agent:{id}:fault` rows for the same agent until
--- one or the other is marked read, which is exactly the redundancy this PR
--- is fixing — so wipe them too. Read rows on those keys stay (history).
-
-DELETE FROM "notifications"
-WHERE "type" IN ('agent_disconnected', 'session_completed', 'session_error');
-
-DELETE FROM "notifications"
-WHERE "read" = false
-  AND "dedup_key" IN (
-    SELECT "dedup_key" FROM "notifications"
-    WHERE "dedup_key" LIKE 'agent:%:agent_error'
-       OR "dedup_key" LIKE 'agent:%:agent_blocked'
-       OR "dedup_key" LIKE 'agent:%:agent_stale'
-  );

package/dist/drizzle/0043_onboarding_completed_at.sql

@@ -1,32 +0,0 @@
--- Onboarding terminal-state stamp. Distinct from `onboarding_dismissed_at`:
---
---   * `onboarding_dismissed_at` means "the user clicked ✕ on the stepper" —
---     a UI hide, not a setup-complete signal. The user can resume the
---     wizard from Settings → Onboarding to land back on whichever step is
---     still incomplete.
---
---   * `onboarding_completed_at` means "the user actually walked Step 3 to
---     success" (admin Continue, invitee Confirm/Continue). Once set, the
---     Settings → Onboarding entry point and Resume button disappear
---     permanently. Subsequent tree / source-repo edits go through Settings
---     → Team and /agents/:uuid.
---
--- The two stamps are intentionally orthogonal: `inferOnboardingStep()`
--- keeps its existing "infer from current resources" semantics and never
--- consults this column. This field is UI-gate only.
---
--- Backfill: every already-dismissed user is treated as completed. The pre-
--- column population (mid-2025) had no terminal-state concept, so the only
--- signal we have is "they hid the stepper" — and the alternative (showing
--- the Onboarding sidebar entry to every legacy user forever) is worse than
--- the off-by-one risk that a few users dismissed-without-finishing and
--- will lose their Resume affordance.
-
-ALTER TABLE "users"
-  ADD COLUMN IF NOT EXISTS "onboarding_completed_at" timestamp with time zone;
-
---> statement-breakpoint
-UPDATE "users"
-   SET "onboarding_completed_at" = "onboarding_dismissed_at"
- WHERE "onboarding_dismissed_at" IS NOT NULL
-   AND "onboarding_completed_at" IS NULL;

package/dist/drizzle/0044_agent_avatar_color.sql

@@ -1,11 +0,0 @@
--- Add avatar_color_token to agents.
---
--- Manager-selected avatar fill color override for the web client. One of
--- "hue-0".."hue-7", matching the `--avatar-hue-*` CSS tokens in
--- `packages/web/src/index.css`. NULL means "auto" — the renderer falls
--- back to the deterministic djb2 hash of `uuid` (the previous default).
---
--- Nullable, no default, no backfill: existing rows continue to render the
--- hashed color until their manager picks something explicit. This is a
--- pure additive change; no NOT NULL constraint, no enum, no FK.
-ALTER TABLE "agents" ADD COLUMN "avatar_color_token" text;

package/dist/drizzle/0045_agent_avatar_image.sql

@@ -1,17 +0,0 @@
--- Add inline avatar image storage to agents.
---
--- The PRD chose PG bytea over object storage for the first cut: clients
--- always pre-resize to 256×256 WEBP (typically < 50 KB), and a few KB ×
--- N agents per org sits well within row-size budgets. Switching to S3/R2
--- later is a follow-up migration; the column shape stays the same except
--- avatar_image_data flips to NULL and avatar_image_url moves to a real
--- external URL.
---
--- All three columns are nullable and move together — either all three
--- carry an image (data + mime + updated_at) or all are NULL. The service
--- layer enforces that invariant on writes; SQL keeps it loose so a partial
--- backfill / restore doesn't break inserts.
-ALTER TABLE "agents"
-  ADD COLUMN "avatar_image_data" bytea,
-  ADD COLUMN "avatar_image_mime" text,
-  ADD COLUMN "avatar_image_updated_at" timestamp with time zone;