@checkstack/healthcheck-backend 1.8.0 → 1.9.0

package/CHANGELOG.md

@@ -1,5 +1,276 @@
 # @checkstack/healthcheck-backend
 
+## 1.9.0
+
+### Minor Changes
+
+- 551eaa9: AI assistant context-window management + leaner health-check history for chat.
+
+  The assistant previously sent the full conversation history verbatim every turn
+  with no size bounds, so analyzing historical health-check runs blew the model's
+  context window fast. Two problems are addressed:
+
+  **Verbosity.** Read-tool results are now shaped for the model:
+
+  - A generic, last-resort size clamp on every read result (head-trims the largest
+    arrays and adds a `_truncated` hint to narrow/paginate) so one wide pull can't
+    blow the context — and, since history replays each turn, keep blowing it.
+  - Projections can declare an optional `projectResult` to return a LEANER
+    model-facing shape than the UI procedure (authz + audit still see the full
+    result). `healthcheck.runHistory` uses it to drop the opaque ids the model
+    merely echoes, keeping time/status/latency/source.
+  - New `healthcheck.runStats` AI tool (backed by a new public `getRunStats`
+    procedure): compact window totals (counts by status, uptime %, latency
+    avg/min/max/p95) plus a small capped time series, so "how often / how much
+    downtime / uptime over the last N days" questions return aggregates instead of
+    thousands of rows. `runHistory`'s description now steers wide-window questions
+    here.
+
+  **Context limits.** The chat loop now estimates the prompt's tokens (a
+  provider-agnostic heuristic) against a budget derived from the connection's
+  context window, and COMPACTS the conversation before it overflows: the oldest
+  turns are summarized into a durable running summary (persisted on the
+  conversation row in shared Postgres, so any pod resumes consistently) and dropped
+  from the verbatim replay, with the summary folded into the system prompt.
+  Splitting at message-row boundaries keeps tool-call/result pairs intact, and the
+  summarization step is fail-open. A new optional `contextWindowTokens` on the
+  OpenAI-compatible connection sets the window (blank = conservative default).
+
+  All additive: a new optional connection field, a new public read endpoint, and an
+  additive `ai-backend` migration (`0009`) adding nullable `summary` /
+  `summarized_through_message_id` columns to `ai_conversations`.
+
+- d2077bd: Platform-wide team-scoped access control on a unified relation-tuple store.
+
+  Admins can scope any resource to teams, and the **platform** (not each plugin)
+  enforces it. A plugin opts in declaratively by adding `instanceAccess` to a
+  procedure's contract; the auth middleware does the rest, so enforcement is
+  consistent across catalog, health checks, incidents, maintenances, SLOs,
+  automations, and the dependency map, and any third-party plugin gets it for free.
+
+  Core model:
+
+  - **Teams are optional.** A resource with no team grants behaves exactly as
+    before.
+  - **Team grants are additive and restrict who can CHANGE a resource, not who can
+    SEE it.** Granting a team `Manage` lets its members view and change the
+    resource; `Read-only` lets them view it. Either level grants access to team
+    members **even when they lack the global permission**, and granting never
+    removes read from anyone who already had it (e.g. a public status page stays
+    readable). Privacy is a separate, explicit opt-in via the **Private** toggle,
+    which removes the global read path so only the resource's teams can see it.
+  - **Ownership at creation.** Create forms expose an **Owning team** picker. A
+    non-admin can create a resource for a team they belong to that holds a
+    create-capability grant for that type; the new resource is auto-granted to that
+    team. Incidents and maintenances are **parent-gated**: anyone who can manage a
+    system may open incidents/maintenances for it, no separate grant needed.
+  - **Meaningful authorization errors.** A caller with neither the global rule nor
+    any team grant for a resource type gets a `403` with a structured body instead
+    of a silently-empty `200`. Anonymous callers on public endpoints are never
+    `403`'d, so status pages keep rendering.
+
+  Unified relation-tuple store:
+
+  - The previously separate access primitives (`resource_team_access.canRead` /
+    `.canManage`, ownership, `resource_access_settings.teamOnly`, and
+    `resource_create_grant`) are collapsed onto ONE
+    `relation_tuple(object, relation, subject)` store: "a team has
+    `viewer`/`editor`/`owner` on an object, or `creator` on a type". Privacy is an
+    explicit **`private` marker** tuple — its **presence** closes the global read
+    path (team grants only), its **absence** is the readable-by-default state, so a
+    private resource with zero grants is correctly inaccessible to everyone rather
+    than silently globalized. The access decision is a pure, unit-tested function.
+  - The auth API is generic: `writeRelation` / `removeRelation` / `setObjectPublic`
+    / `listObjectRelations` / `listSubjectRelations` / `setCreateGrant` /
+    `listTeamCreateGrants` (user-facing) and `check` / `listAccessibleObjectIds` /
+    `hasAnyTypeGrant` / `authorizeCreate` / `setOwner` / `deleteObjectRelations`
+    (service-to-service). Migration `0008` backfills tuples from the legacy tables
+    and drops them.
+
+  Explicit per-procedure scoping:
+
+  - Access rules (`access()` / `accessPair()`) define only the rule (id, level,
+    defaults); every procedure declares its own `instanceAccess`. This removes a
+    "loaded gun" default that silently applied a shared `idParam` to any procedure
+    which forgot its own override.
+  - Modes: `idParam` (single-resource pre-check, fails **closed** if the id does
+    not resolve), `listKey` / `recordKey` (post-filter a list/record to the
+    accessible subset), `create` (authorize creation + write the owning-team
+    grant), `parentScope` (scope by read/manage access to a PARENT type,
+    cross-plugin single-hop: "you may see incidents/maintenances/SLOs/health for
+    system S iff you may see S"), and `global: true` (the honest "intentionally not
+    team-scoped" opt-out). A boot-time validator **rejects** any procedure gated on
+    a team-scopable resource type that declares no `instanceAccess`, turning the
+    previous fail-open into a boot error.
+
+  Teams administration:
+
+  - **Team managers** manage their own team's members and managers without the
+    global `auth.teams.manage` rule; creating, deleting, and granting a team access
+    remain admin-only.
+  - A **standalone Teams page** (gated on `auth.teams.read`) lets managers reach
+    team administration without the admin Auth Settings page; members are added via
+    a debounced directory picker.
+  - A **cross-plugin `ResourceResolverRegistry`** lets owning plugins register a
+    name/search resolver for their resource types, so the Teams page lists a team's
+    grants **by name** (grouped by type) and offers a resource picker — an admin can
+    change a grant's level, revoke it, or add one, without auth depending on every
+    plugin. Resolvers shipped for catalog systems, health-check configurations,
+    incidents, maintenances, SLO objectives, and automations.
+
+  Frontend:
+
+  - The resource-side editor is **"Who can change this"** (one Manage checkbox per
+    team; unticked = read-only), with an always-visible **Private** toggle
+    (disabled until a team that can Manage exists, so a resource can't be stranded).
+  - `TeamOwnershipPicker` explains _why_ there's nothing to pick (not a member of
+    any team, or none of your teams manage the selected parent) instead of a bare
+    "global resource" line.
+  - Read-only **"who can change this"** indicators on resource detail pages expand
+    to the actual people by name; bulk + per-row **Scope to team** actions in the
+    catalog systems list; and the team-access copy spells out that grants are
+    additive and that Read-only grants view (not change) even without the global
+    permission.
+
+  Security hardening:
+
+  - Child deletes in catalog (`removeSystemContact` / `removeSystemLink`) are scoped
+    to both the child id and its parent `systemId`, closing a cross-system IDOR for
+    team-scoped managers.
+  - `searchUsers` is restricted to team administrators, closing a directory/email
+    enumeration path opened by the default `auth.teams.read` rule.
+  - Grant setters reject unregistered resource types.
+
+  BREAKING CHANGES (beta; shipped as minor bumps):
+
+  - `access()` and `accessPair()` no longer accept `idParam` / `listKey` /
+    `recordKey`; move instance config to the procedure's `instanceAccess`.
+  - Boot fails if a procedure gated on a team-scopable resource type omits
+    `instanceAccess`. Declare a scoping mode or `instanceAccess: { global: true }`.
+  - The `AuthService` interface is reshaped: `check`, `listAccessibleObjectIds`,
+    `hasAnyTypeGrant`, `authorizeCreate` (returns `isPrivate`), `setOwner`
+    (`isPrivate`), and `deleteObjectRelations`. Custom `AuthService` implementations
+    and mocks must update.
+  - The auth RPC contract's per-concept resource-access endpoints are replaced by
+    the generic tuple API above; external callers of the old
+    `getResourceTeamAccess` / `setResourceTeamAccess` / `setResourceAccessSettings`
+    / `grantResourceCreate` / etc. must move to the new procedures.
+  - Several contract inputs changed from a bare `string` to an object so the
+    middleware can resolve the resource id: catalog `deleteSystem` (`{ id }`),
+    `removeSystemContact` / `removeSystemLink` (`{ id, systemId }`); health-check
+    `deleteConfiguration` / `pauseConfiguration` / `resumeConfiguration` (`{ id }`).
+    All in-tree callers are updated.
+  - List/record endpoints that relied on returning an empty `200` to signal "no
+    access" now return a `403` for categorically-unauthorized principals.
+  - The mis-keyed bulk endpoints `getBulkIncidentsForSystems`,
+    `getBulkMaintenancesForSystems`, and `getBulkObjectivesForSystems` no longer
+    post-filter their (systemId-keyed) result; access is already gated by
+    `catalog.system` upstream.
+  - Team membership/manager mutations (`addUserToTeam`, `removeUserFromTeam`,
+    `addTeamManager`, `removeTeamManager`) now require `auth.teams.read` instead of
+    `auth.teams.manage` at the contract level (broadened to per-team managers).
+  - The `resource_team_access`, `resource_access_settings`, and
+    `resource_create_grant` tables are dropped (data backfilled into
+    `relation_tuple` by migration `0008`). A previously inconsistent "team-only with
+    zero grants" resource is now correctly inaccessible to global-access holders.
+
+- 5c6393f: Add operator-built public Status Pages (phase 1: secure, extensible core).
+
+  Operators compose a public status page from widgets (status banner, system
+  health, group status, 90-day uptime, incidents, scheduled maintenance) plus
+  content blocks (text/Markdown, heading, links, image, divider), each bound to the
+  resources they choose, then publish it.
+
+  Security model — "only published widgets reveal data":
+
+  - A single public endpoint, `getPublishedStatusPage(slug)`, returns the layout
+    plus each widget's already-resolved, field-ALLOW-LISTED DTO. The public surface
+    has no generic data API, so it can only ever show what was placed on the page.
+  - Three gates: edit-time (you can only bind resources you can access), publish-time
+    (an audited, deliberate exposure that re-checks the editor can read every bound
+    resource via a user-scoped client), and render-time (resolvers run as a trusted
+    service but emit only DTO fields — never internal config, ids, or `createdBy`;
+    the service re-validates each DTO against its schema, so a resolver bug fails
+    closed).
+  - The overall banner rolls up only the bound systems; private resources are never
+    exposed beyond their public-safe status; per-binding label overrides avoid
+    internal-name leaks.
+
+  Coherence + extensibility:
+
+  - Status pages are team-scopable resources (RLAC): created via the standard
+    owning-team picker + create-capability flow, resolvable by name in the Teams
+    admin.
+  - Widget types come from an extension-point registry, so any plugin can contribute
+    a widget (config schema + public DTO + `resolvePublic`); the public renderers
+    are pure, prop-only components with no data access, so third-party widgets can
+    never leak.
+  - Draft vs published layouts; per-page visibility (public / authenticated-only)
+    and theming (brand color, logo).
+
+  Dependency direction: the status-page platform owns the widget-type registry and
+  the content widgets, but the DOMAIN widgets are contributed by their owning
+  plugins via the `statusWidgetTypeExtensionPoint` — system health / uptime /
+  banner / group status by `healthcheck-backend`, incidents by `incident-backend`,
+  scheduled maintenance by `maintenance-backend`. So `status-page-backend` depends
+  only on `backend-api` / `common` / `status-page-common`; the owning plugins
+  depend on the platform, never the reverse. `catalog-common` gains
+  `assertCatalogResourcesReadable` for the publish-time access check.
+
+  Phase 1 scope: the secure core, the admin builder, and the public page (served as
+  a no-access-rule route). A fully separate public bundle, custom domains + TLS,
+  drag-reorder, live-data preview, and distribution (embeds/badges/RSS/subscriptions)
+  are the next phases.
+
+### Patch Changes
+
+- Updated dependencies [551eaa9]
+- Updated dependencies [d2077bd]
+- Updated dependencies [9ab73c5]
+- Updated dependencies [5c6393f]
+  - @checkstack/ai-backend@0.7.0
+  - @checkstack/ai-common@0.5.0
+  - @checkstack/healthcheck-common@1.7.0
+  - @checkstack/backend-api@0.23.0
+  - @checkstack/common@0.16.0
+  - @checkstack/automation-backend@0.9.0
+  - @checkstack/catalog-backend@1.5.0
+  - @checkstack/catalog-common@2.4.0
+  - @checkstack/incident-backend@1.8.0
+  - @checkstack/incident-common@1.6.0
+  - @checkstack/maintenance-common@1.7.0
+  - @checkstack/status-page-common@0.1.0
+  - @checkstack/status-page-backend@0.1.0
+  - @checkstack/satellite-backend@0.6.13
+  - @checkstack/sdk@0.108.1
+  - @checkstack/script-packages-backend@0.3.12
+  - @checkstack/secrets-backend@0.2.9
+  - @checkstack/command-backend@0.2.9
+  - @checkstack/gitops-backend@0.5.9
+  - @checkstack/cache-api@0.3.13
+  - @checkstack/gitops-common@0.6.4
+  - @checkstack/notification-common@1.3.4
+  - @checkstack/queue-api@0.3.13
+  - @checkstack/secrets-common@0.2.4
+  - @checkstack/signal-common@0.2.10
+  - @checkstack/cache-utils@0.2.18
+
+## 1.8.1
+
+### Patch Changes
+
+- Updated dependencies [bb6f0fe]
+- Updated dependencies [bb6f0fe]
+  - @checkstack/maintenance-common@1.6.0
+  - @checkstack/ai-backend@0.6.1
+  - @checkstack/sdk@0.107.1
+  - @checkstack/automation-backend@0.8.1
+  - @checkstack/secrets-backend@0.2.8
+  - @checkstack/catalog-backend@1.4.12
+  - @checkstack/incident-backend@1.7.4
+  - @checkstack/satellite-backend@0.6.12
+  - @checkstack/script-packages-backend@0.3.11
+
 ## 1.8.0
 
 ### Minor Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/healthcheck-backend",
-  "version": "1.8.0",
+  "version": "1.9.0",
   "license": "Elastic-2.0",
   "type": "module",
   "main": "src/index.ts",
@@ -14,30 +14,32 @@
     "lint:code": "eslint . --max-warnings 0"
   },
   "dependencies": {
-    "@checkstack/backend-api": "0.22.0",
-    "@checkstack/ai-backend": "0.6.0",
-    "@checkstack/ai-common": "0.4.0",
-    "@checkstack/script-packages-backend": "0.3.10",
-    "@checkstack/cache-api": "0.3.12",
-    "@checkstack/cache-utils": "0.2.17",
-    "@checkstack/catalog-backend": "1.4.11",
-    "@checkstack/catalog-common": "2.3.6",
-    "@checkstack/command-backend": "0.2.8",
-    "@checkstack/common": "0.15.0",
-    "@checkstack/gitops-backend": "0.5.8",
-    "@checkstack/gitops-common": "0.6.3",
-    "@checkstack/healthcheck-common": "1.6.2",
-    "@checkstack/secrets-common": "0.2.3",
-    "@checkstack/secrets-backend": "0.2.8",
-    "@checkstack/incident-backend": "1.7.3",
-    "@checkstack/incident-common": "1.5.2",
-    "@checkstack/automation-backend": "0.8.0",
-    "@checkstack/maintenance-common": "1.5.2",
-    "@checkstack/notification-common": "1.3.3",
-    "@checkstack/queue-api": "0.3.12",
-    "@checkstack/satellite-backend": "0.6.11",
-    "@checkstack/sdk": "0.106.1",
-    "@checkstack/signal-common": "0.2.9",
+    "@checkstack/backend-api": "0.23.0",
+    "@checkstack/ai-backend": "0.7.0",
+    "@checkstack/ai-common": "0.5.0",
+    "@checkstack/script-packages-backend": "0.3.12",
+    "@checkstack/cache-api": "0.3.13",
+    "@checkstack/cache-utils": "0.2.18",
+    "@checkstack/catalog-backend": "1.5.0",
+    "@checkstack/catalog-common": "2.4.0",
+    "@checkstack/command-backend": "0.2.9",
+    "@checkstack/common": "0.16.0",
+    "@checkstack/gitops-backend": "0.5.9",
+    "@checkstack/gitops-common": "0.6.4",
+    "@checkstack/healthcheck-common": "1.7.0",
+    "@checkstack/secrets-common": "0.2.4",
+    "@checkstack/secrets-backend": "0.2.9",
+    "@checkstack/incident-backend": "1.8.0",
+    "@checkstack/incident-common": "1.6.0",
+    "@checkstack/automation-backend": "0.9.0",
+    "@checkstack/maintenance-common": "1.7.0",
+    "@checkstack/notification-common": "1.3.4",
+    "@checkstack/queue-api": "0.3.13",
+    "@checkstack/satellite-backend": "0.6.13",
+    "@checkstack/sdk": "0.108.1",
+    "@checkstack/signal-common": "0.2.10",
+    "@checkstack/status-page-backend": "0.1.0",
+    "@checkstack/status-page-common": "0.1.0",
     "@hono/zod-validator": "^0.7.6",
     "drizzle-orm": "^0.45.0",
     "hono": "^4.12.23",
@@ -49,8 +51,8 @@
   },
   "devDependencies": {
     "@checkstack/drizzle-helper": "0.0.5",
-    "@checkstack/scripts": "0.6.1",
-    "@checkstack/test-utils-backend": "0.1.42",
+    "@checkstack/scripts": "0.6.2",
+    "@checkstack/test-utils-backend": "0.1.43",
     "@checkstack/tsconfig": "0.0.7",
     "@types/bun": "^1.0.0",
     "@types/tdigest": "^0.1.5",

package/src/ai/healthcheck-delete.test.ts

@@ -75,7 +75,7 @@ describe("healthcheck.delete tool", () => {
     });
     const tool = createHealthcheckDeleteTool();
     const result = await tool.execute({ input: { id: "hc1" }, principal, rpcClient });
-    expect(deleteConfiguration).toHaveBeenCalledWith("hc1");
+    expect(deleteConfiguration).toHaveBeenCalledWith({ id: "hc1" });
     expect(result).toEqual({ id: "hc1", deleted: true });
   });
 });

package/src/ai/healthcheck-delete.ts

@@ -74,7 +74,7 @@ export function createHealthcheckDeleteTool(): RegisteredAiTool<
     dryRun,
     async execute({ input, rpcClient }) {
       const healthcheckClient = rpcClient.forPlugin(HealthCheckApi);
-      await healthcheckClient.deleteConfiguration(input.id);
+      await healthcheckClient.deleteConfiguration({ id: input.id });
       return { id: input.id, deleted: true };
     },
   };

package/src/ai-projections.test.ts

@@ -0,0 +1,59 @@
+import { describe, test, expect } from "bun:test";
+import { projectRunHistoryForModel } from "./ai-projections";
+
+describe("projectRunHistoryForModel", () => {
+  test("trims each run to time/status/latency/source and keeps total", () => {
+    const ts = new Date("2026-06-10T12:00:00.000Z");
+    const out = projectRunHistoryForModel({
+      runs: [
+        {
+          id: "run-1",
+          configurationId: "cfg-1",
+          systemId: "sys-1",
+          environmentId: "env-1",
+          sourceId: "src-1",
+          status: "unhealthy",
+          timestamp: ts,
+          latencyMs: 142,
+          sourceLabel: "EU West",
+        },
+      ],
+      total: 57,
+    }) as {
+      runs: Array<Record<string, unknown>>;
+      returned: number;
+      total: number;
+    };
+
+    expect(out.total).toBe(57);
+    expect(out.returned).toBe(1);
+    expect(out.runs).toHaveLength(1);
+    // Kept the useful fields...
+    expect(out.runs[0]).toEqual({
+      timestamp: "2026-06-10T12:00:00.000Z",
+      status: "unhealthy",
+      latencyMs: 142,
+      sourceLabel: "EU West",
+    });
+    // ...and dropped the opaque ids.
+    expect(out.runs[0]).not.toHaveProperty("id");
+    expect(out.runs[0]).not.toHaveProperty("configurationId");
+    expect(out.runs[0]).not.toHaveProperty("systemId");
+  });
+
+  test("omits absent optional fields", () => {
+    const out = projectRunHistoryForModel({
+      runs: [{ status: "healthy", timestamp: "2026-06-10T12:00:00.000Z" }],
+      total: 1,
+    }) as { runs: Array<Record<string, unknown>> };
+    expect(out.runs[0]).toEqual({
+      timestamp: "2026-06-10T12:00:00.000Z",
+      status: "healthy",
+    });
+  });
+
+  test("returns the input unchanged when the shape is unexpected", () => {
+    const weird = { foo: "bar" };
+    expect(projectRunHistoryForModel(weird)).toBe(weird);
+  });
+});

package/src/ai-projections.ts

@@ -0,0 +1,59 @@
+import { z } from "zod";
+import { HealthCheckStatusSchema } from "@checkstack/healthcheck-common";
+
+/**
+ * Model-facing lean shapes for the AI tool projections (see
+ * `aiToolProjectionExtensionPoint.expose({ projectResult })`). The chat/MCP
+ * read-loop still re-enters the real procedure as the principal and gets the
+ * FULL output (authz + audit unchanged); these mappers only trim the shape that
+ * enters the model's context window.
+ *
+ * `getHistory` returns ~9 fields per run. For the timeline/root-cause questions
+ * the assistant uses it for, the model only needs WHEN, WHAT status, how SLOW,
+ * and from WHERE — the opaque ids (`id`, `configurationId`, `systemId`,
+ * `environmentId`, `sourceId`) are echoed back to it from its own arguments and
+ * waste context, especially since history is replayed verbatim every turn.
+ */
+
+/** A run as the public `getHistory` returns it (only the fields we read). */
+const RunShape = z.object({
+  status: HealthCheckStatusSchema,
+  timestamp: z.union([z.date(), z.string()]),
+  latencyMs: z.number().optional(),
+  sourceLabel: z.string().optional(),
+});
+
+const HistoryShape = z.object({
+  runs: z.array(RunShape),
+  total: z.number(),
+});
+
+/** Compact run: time + status + latency + source label. */
+export interface LeanRun {
+  timestamp: string;
+  status: z.infer<typeof HealthCheckStatusSchema>;
+  latencyMs?: number;
+  sourceLabel?: string;
+}
+
+/**
+ * Project a `getHistory` result into the lean per-run shape. Defensive: if the
+ * output does not match the expected shape (a future schema change), it is
+ * returned unchanged — the generic clamp is the backstop, so a mismatch never
+ * crashes the read, it just sends the full shape.
+ */
+export function projectRunHistoryForModel(output: unknown): unknown {
+  const parsed = HistoryShape.safeParse(output);
+  if (!parsed.success) return output;
+  const { runs, total } = parsed.data;
+  const lean: LeanRun[] = runs.map((r) => ({
+    timestamp:
+      r.timestamp instanceof Date ? r.timestamp.toISOString() : r.timestamp,
+    status: r.status,
+    ...(r.latencyMs === undefined ? {} : { latencyMs: r.latencyMs }),
+    ...(r.sourceLabel === undefined ? {} : { sourceLabel: r.sourceLabel }),
+  }));
+  // `returned` makes the page size explicit next to `total`, so the model knows
+  // how much of the window it actually saw without counting the array.
+  return { runs: lean, returned: lean.length, total };
+}

package/src/index.ts

@@ -26,6 +26,9 @@ import {
 } from "@checkstack/ai-backend";
 import { buildHealthcheckAiTools } from "./ai/register-ai-tools";
 import { createHealthcheckSignalsContributor } from "./ai/system-signals-contributor";
+import { projectRunHistoryForModel } from "./ai-projections";
+import { statusWidgetTypeExtensionPoint } from "@checkstack/status-page-backend";
+import { registerHealthcheckStatusWidgets } from "./status-page/widgets";
 import {
   createBackendPlugin,
   coreServices,
@@ -69,6 +72,7 @@ import { GitOpsApi } from "@checkstack/gitops-common";
 import { registerSearchProvider } from "@checkstack/command-backend";
 import { resolveRoute } from "@checkstack/common";
 import { createHealthCheckCache } from "./cache";
+import { inArray, ilike } from "drizzle-orm";
 
 // Store emitHook reference for use during Phase 2 init
 let storedEmitHook: EmitHookFn | undefined;
@@ -97,6 +101,13 @@ export default createBackendPlugin({
       healthcheckGroupSubscription,
     ]);
 
+    // Status-page widgets owned by healthcheck (system health, uptime, banner,
+    // group status). Buffered behind the extension point until status-page-backend
+    // registers it — so the status-page platform never depends on healthcheck.
+    registerHealthcheckStatusWidgets(
+      env.getExtensionPoint(statusWidgetTypeExtensionPoint),
+    );
+
     // ─── Automation Platform: triggers + artifact type ─────────────────
     // Buffered behind the extension point until automation-backend's
     // register() runs. Actions are wired in afterPluginsReady where
@@ -208,6 +219,7 @@ export default createBackendPlugin({
         config: coreServices.config,
         secretResolver: secretResolverRef,
         advisoryLock: coreServices.advisoryLock,
+        resourceResolverRegistry: coreServices.resourceResolverRegistry,
       },
       // Phase 2: Register router and setup worker
       init: async ({
@@ -223,9 +235,41 @@ export default createBackendPlugin({
         config,
         secretResolver,
         advisoryLock,
+        resourceResolverRegistry,
       }) => {
         logger.debug("🏥 Initializing Health Check Backend...");
 
+        const typedDb = database as SafeDatabase<typeof schema>;
+
+        // Resolve/search health-check configurations by name for the Teams admin
+        // UI (team grants are stored as opaque healthcheck.configuration:<id>
+        // rows). Lets the auth backend render grants by name and power the grant
+        // picker without depending on healthcheck internals.
+        resourceResolverRegistry.register("healthcheck.configuration", {
+          resolveNames: async (ids) => {
+            if (ids.length === 0) return new Map();
+            const rows = await typedDb
+              .select({
+                id: schema.healthCheckConfigurations.id,
+                name: schema.healthCheckConfigurations.name,
+              })
+              .from(schema.healthCheckConfigurations)
+              .where(inArray(schema.healthCheckConfigurations.id, ids));
+            return new Map(rows.map((r) => [r.id, r.name]));
+          },
+          search: async (query, limit) => {
+            const rows = await typedDb
+              .select({
+                id: schema.healthCheckConfigurations.id,
+                name: schema.healthCheckConfigurations.name,
+              })
+              .from(schema.healthCheckConfigurations)
+              .where(ilike(schema.healthCheckConfigurations.name, `%${query}%`))
+              .limit(limit);
+            return rows;
+          },
+        });
+
         // Populate mutable refs for GitOps reconcile closures
         gitopsDb = database;
         gitopsHealthCheckRegistry = healthCheckRegistry;
@@ -285,13 +329,42 @@ export default createBackendPlugin({
           procedureKey: "getHistory",
           name: "healthcheck.runHistory",
           description:
-            "List historical health-check runs (individual timestamped results) " +
-            "for root-cause and timeline questions. Filter by `systemId`, a " +
-            "`startDate`/`endDate` window, and/or `statusFilter` (e.g. " +
-            "[\"unhealthy\",\"degraded\"]) to find when and how a system was " +
-            "failing over a period. Pass `sortOrder` (\"desc\" for most recent " +
-            "first) and use `limit`/`offset` to page. Use this for past/timespan " +
-            "questions; use healthcheck.status for the current state. Read-only.",
+            "List INDIVIDUAL historical health-check runs for a SMALL window or " +
+            "a few specific failures. Filter by `systemId`, a `startDate`/" +
+            "`endDate` window, and/or `statusFilter` (e.g. [\"unhealthy\"," +
+            "\"degraded\"]); keep `limit` small (each run is a row). For a WIDE " +
+            "window or 'how often / how much downtime / uptime over the last N " +
+            "days' questions, use healthcheck.runStats instead — it returns " +
+            "counts and latency stats without thousands of rows. Use " +
+            "healthcheck.status for the current state. Read-only.",
+          effect: "read",
+          execute: deferredProjectionExecute,
+          // Lean shape for the model: drop the opaque ids it merely echoes and
+          // keep time/status/latency/source, so a page of runs doesn't blow the
+          // context window (and keep doing so on every verbatim history replay).
+          projectResult: projectRunHistoryForModel,
+        });
+
+        // Aggregate run statistics over a window: counts by status, uptime %,
+        // and latency stats, plus a small capped time series — the COMPACT way
+        // to answer "how often / how much downtime / uptime over the last N
+        // days" without pulling thousands of raw rows into the model's context.
+        // Same public `healthcheck.status` gate as runHistory (no `result`
+        // payload). Output is already small and bounded, so no projectResult.
+        env.getExtensionPoint(aiToolProjectionExtensionPoint).expose({
+          procedure: healthCheckContract.getRunStats,
+          sourcePluginMetadata: pluginMetadata,
+          procedureKey: "getRunStats",
+          name: "healthcheck.runStats",
+          description:
+            "Summarize health-check runs over a window: total and per-bucket " +
+            "counts by status, uptime %, and latency stats (avg/min/max/p95). " +
+            "PREFER THIS over healthcheck.runHistory for any 'how often / how " +
+            "much downtime / uptime / latency trend over the last N hours or " +
+            "days' question — it returns compact aggregates, not raw rows. " +
+            "Filter by `systemId`, `configurationId`, `startDate`/`endDate`, " +
+            "`statusFilter`; set `maxBuckets` for the time-series resolution " +
+            "(default 24). Read-only.",
           effect: "read",
           execute: deferredProjectionExecute,
         });

package/src/router.test.ts

@@ -334,7 +334,7 @@ describe("HealthCheck Router", () => {
       const context = createMockRpcContext({ user: mockUser });
       
       try {
-        await call(router.deleteConfiguration, "config-1", { context });
+        await call(router.deleteConfiguration, { id: "config-1" }, { context });
       } catch (e: any) {
         // If it throws anything other than FORBIDDEN, it passed the lock check
         expect(e.code).not.toBe("FORBIDDEN");
@@ -357,7 +357,7 @@ describe("HealthCheck Router", () => {
       
       let error;
       try {
-        await call(router.deleteConfiguration, "config-1", { context });
+        await call(router.deleteConfiguration, { id: "config-1" }, { context });
       } catch (e) {
         error = e;
       }