@checkstack/frontend-api 0.4.2 → 0.5.0

package/CHANGELOG.md

@@ -1,5 +1,157 @@
 # @checkstack/frontend-api
 
+## 0.5.0
+
+### Minor Changes
+
+- aa89bc5: Replace the bespoke `registerInfrastructureTab()` registry with a standard
+  slot-extension contract (`InfrastructureTabsSlot` from
+  `@checkstack/infrastructure-common`). Plugins now contribute infrastructure
+  tabs via `createSlotExtension`, depending only on the slot owner.
+
+  The slot system in `@checkstack/frontend-api` gains a second type parameter
+  on `createSlot<TContext, TMetadata>` so extensions can declare typed static
+  metadata at registration time (label, icon, access rules, ordering for the
+  infrastructure tab bar). A new `useSlotExtensions(slot)` hook returns typed
+  extensions and subscribes to plugin lifecycle changes.
+
+  Each tab body now stacks a **Runtime** sub-section (live state, read-only)
+  on top of a **Configuration** sub-section (settings, gated by `canUpdate`).
+
+  **Queue runtime panel.** Surfaces aggregated counts (pending / processing /
+  completed / failed) plus three sub-tabs of recent jobs: **Active**, **Recent
+  failed** (with the failure message), and **Recent completed** (with
+  duration). Job payloads are deliberately not surfaced — they may carry
+  secrets and need a separate manage-access gate to be shown.
+
+  To support this, `Queue<T>` gains a required `listJobs(opts)` method
+  returning `JobSummary[]` (no payloads), and `QueueStats` gains a
+  `scope: "instance" | "cluster"` field. The in-memory queue keeps rolling
+  ring buffers (200 entries) for completed/failed history and tracks active
+  jobs by id; BullMQ uses native `getJobs`. `QueueManager.listJobs` aggregates
+  across queues and sorts (most-recent-first for terminal states, FIFO for
+  active/waiting/delayed).
+
+  **Cache runtime panel.** Lists the top N entries by size (or by recency) so
+  operators can debug a cache filling up. Values are deliberately omitted —
+  PII / secret risk. Backends opt in via an optional `listEntries?` method on
+  `CacheProvider`; non-supporting backends return `{ supported: false }` and
+  the UI renders a "not supported by this backend" hint. The in-memory cache
+  implements it using its existing per-entry byte tracking.
+
+  `CacheStats` also gains `scope: "instance" | "cluster"`.
+
+  **Multi-instance scope warning.** A new `<InstanceScopeBanner>` component in
+  `@checkstack/ui` renders a yellow banner above any runtime panel whose
+  backend reports `scope: "instance"` — i.e. in-memory queue or cache running
+  in a horizontally scaled deployment. The banner explains the metrics are
+  local to the responding replica and recommends switching to a clustered
+  backend (Redis-backed queue / cache) for cluster-wide visibility.
+
+  **Bug fix — stable cache provider proxy.** `CacheManagerImpl.getProvider()`
+  now returns a single stable proxy that delegates to whatever provider is
+  currently active. Previously, consumers of `createCachedScope` (and any
+  direct `cacheManager.getProvider()` caller) captured the active provider
+  reference at plugin-init time. After any `setActiveBackend` call — including
+  saving the same memory config in the new Cache tab, which reconstructs the
+  in-memory cache — those scopes wrote to an orphaned old provider while the
+  runtime panel read stats from the new (empty) one, making the runtime panel
+  appear to report 0 keys. With the proxy, all consumers share a single stable
+  identity and writes always land in the active provider.
+
+  **Bytes tracking on the in-memory cache.** `InMemoryCache.getStats().sizeBytes`
+  now returns a running approximation (UTF-8 bytes of the key plus
+  `v8.serialize(value).byteLength`, with a JSON fallback) that's kept in sync
+  across all eviction paths. Treat the number as a sanity gauge; it doesn't
+  include `Map` per-entry overhead.
+
+  **Pagination.** Both `Queue<T>.listJobs` and `CacheProvider.listEntries?`
+  are offset-paginated. Inputs gain an `offset: number`; outputs change to
+  `{ items, total: number | null, hasMore: boolean }`. `total` is nullable
+  so backends that can't compute it cheaply still paginate via `hasMore`.
+  The UI uses the existing `<Pagination>` component with a 25-row default
+  page size. `QueueManager.listJobs` aggregates by over-fetching
+  `[0, offset+limit)` per queue, merge-sorting, then slicing the window —
+  optimal for the single-queue case, acceptable for the multi-queue case
+  within the UI's reasonable page-depth bounds. BullMQ uses native offset
+  ranges via `getJobs(types, start, end)` plus `getJobCounts` for `total`.
+
+  **Pending tab.** The Queue runtime panel exposes a virtual `"pending"`
+  state (waiting ∪ delayed, FIFO). It's now the default sub-tab, since
+  "what's queued up?" is the most common question. Per-row state is shown
+  when viewing the combined list.
+
+  **Recurring schedules visible under Pending.** Cron- and interval-based
+  recurring jobs (e.g. healthchecks) are surfaced under Pending/Delayed
+  between fires, with a `nextRunAt` countdown column and a "(recurring)"
+  label. `JobSummary` gains optional `nextRunAt: Date` and `recurring:
+boolean` fields. The in-memory queue synthesises these rows from its
+  `recurringJobs` registry; BullMQ already materialises the next fire of
+  each scheduler as a delayed job and we now surface its trigger time and
+  the `repeatJobKey`-derived `recurring` flag.
+
+  **Bug fix — drop hook emits with no listeners.** `EventBus.emit` no
+  longer enqueues a job when zero listeners (distributed or instance-local)
+  are registered for the hook. Previously, hooks like
+  `core.plugin.initialized` — emitted on every plugin init but subscribed
+  to by nothing in the core repo — accumulated one waiting job per emit
+  forever. The in-memory queue's `processNext` short-circuits when there
+  are zero consumer groups, so its post-loop cleanup never ran for these
+  orphaned jobs. The fix drops the emit at the source and logs a debug
+  line. Note: in distributed deployments using a Redis-backed queue, this
+  means a subscriber on another replica won't receive an event if no
+  replica that emits it has a local listener. Plugins needing cross-process
+  delivery must register their listener on every replica that should
+  receive the hook.
+
+  **Breaking notes (treated as minor under beta semantics)**:
+
+  - `@checkstack/infrastructure-common` removes `registerInfrastructureTab`
+    and `getInfrastructureTabs`; former callers must register an extension
+    into `InfrastructureTabsSlot`.
+  - `@checkstack/queue-api`'s `Queue<T>` interface requires the new
+    `listJobs(opts)` method returning `ListJobsResult` (paginated). Both
+    bundled queue backends (memory, BullMQ) are updated; out-of-tree
+    implementations will need to add it.
+  - `QueueStats` and `CacheStats` add a required `scope` field.
+  - `CacheProvider.listEntries?` (when implemented) now returns
+    `ListEntriesResult` instead of `CacheEntrySummary[]`.
+  - `JobState` adds a `"pending"` variant.
+
+- 950d6ec: Fix mobile UserMenu items rendering at zero height, group menu items by
+  section, and unstack cramped card headers on small viewports.
+
+  - **UserMenu mobile bug**: On mobile, the user-menu Sheet rendered every
+    menu item as a grid row, which combined with `flex-shrink: 1` on each
+    item collapsed the buttons whose internal layout uses `display: flex`
+    (the items registered with `useNavigate` rather than `<Link>`) to zero
+    content height. Switched the mobile container to a flex column with
+    `[&>*]:shrink-0` and added `min-h-0` so the sheet scrolls correctly
+    when the list overflows.
+
+  - **UserMenu grouping**: Slot extensions now accept an optional `group`
+    field. The user menu buckets `UserMenuItemsSlot` extensions by `group`
+    and renders each group under a labeled header (`Workspace`,
+    `Reliability`, `Configuration`, `Documentation`, `Account`). Existing
+    core plugins are tagged with the appropriate group; third-party plugins
+    can pick any of these or supply their own label. Untagged extensions
+    render last with no header. `UserMenuItemsBottomSlot` is unaffected.
+
+  - **Card header responsiveness**: `CardHeaderRow` (the primitive shared by
+    Incident, Maintenance, Auth, Catalog, GitOps and other config cards) now
+    stacks vertically on narrow viewports and only switches to a single row
+    at the `sm` breakpoint, so titles and adjacent filter controls (e.g.
+    status `Select`, "Show resolved" checkbox) no longer cram together on
+    mobile. Refactored the Incident and Maintenance config pages to use the
+    primitive instead of a hand-rolled `flex items-center justify-between`
+    row, and made their `Select` triggers full-width on mobile.
+
+### Patch Changes
+
+- Updated dependencies [42abfff]
+  - @checkstack/common@0.9.0
+  - @checkstack/signal-common@0.2.2
+
 ## 0.4.2
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/frontend-api",
-  "version": "0.4.2",
+  "version": "0.5.0",
   "license": "Elastic-2.0",
   "type": "module",
   "main": "./src/index.ts",
@@ -13,8 +13,8 @@
     "react": "^18.0.0"
   },
   "dependencies": {
-    "@checkstack/common": "0.7.0",
-    "@checkstack/signal-common": "0.2.0",
+    "@checkstack/common": "0.8.0",
+    "@checkstack/signal-common": "0.2.1",
     "@orpc/client": "^1.13.14",
     "@orpc/contract": "^1.13.14",
     "@orpc/react-query": "1.13.4",
@@ -25,8 +25,8 @@
     "@types/bun": "^1.3.5",
     "@types/react": "^18.0.0",
     "typescript": "^5.0.0",
-    "@checkstack/tsconfig": "0.0.6",
-    "@checkstack/scripts": "0.1.2"
+    "@checkstack/tsconfig": "0.0.7",
+    "@checkstack/scripts": "0.3.0"
   },
   "checkstack": {
     "type": "tooling"

package/src/components/ExtensionSlot.tsx

@@ -7,7 +7,7 @@ import type { SlotDefinition } from "../slots";
  * Extracts the context type from the slot definition itself,
  * ensuring the context matches what the slot expects.
  */
-type ExtensionSlotProps<TSlot extends SlotDefinition<unknown>> =
+type ExtensionSlotProps<TSlot extends SlotDefinition<unknown, unknown>> =
   SlotContext<TSlot> extends undefined
     ? { slot: TSlot; context?: undefined }
     : { slot: TSlot; context: SlotContext<TSlot> };
@@ -24,7 +24,7 @@ type ExtensionSlotProps<TSlot extends SlotDefinition<unknown>> =
  * <ExtensionSlot slot={NavbarRightSlot} />
  * ```
  */
-export function ExtensionSlot<TSlot extends SlotDefinition<unknown>>({
+export function ExtensionSlot<TSlot extends SlotDefinition<unknown, unknown>>({
   slot,
   context,
 }: ExtensionSlotProps<TSlot>) {

package/src/index.ts

@@ -4,6 +4,7 @@ export * from "./core-apis";
 export * from "./plugin";
 export * from "./plugin-registry";
 export * from "./components/ExtensionSlot";
+export * from "./use-slot-extensions";
 export * from "./utils";
 export * from "./slots";
 export * from "./use-plugin-route";

package/src/plugin.ts

@@ -9,33 +9,72 @@ import type {
 import type { Signal } from "@checkstack/signal-common";
 
 /**
- * Extract the context type from a SlotDefinition
+ * Extract the context type from a SlotDefinition.
  */
-export type SlotContext<T> = T extends SlotDefinition<infer C> ? C : never;
+export type SlotContext<T> = T extends SlotDefinition<infer C, unknown>
+  ? C
+  : never;
 
 /**
- * Type-safe extension that infers component props from the slot definition.
+ * Extract the metadata type from a SlotDefinition.
+ */
+export type SlotMetadata<T> = T extends SlotDefinition<unknown, infer M>
+  ? M
+  : never;
+
+/**
+ * Type-safe extension that infers component props and metadata from the
+ * slot definition.
+ *
+ * The `metadata` field is always declared as optional on the base interface
+ * so that aggregate types like `Extension[]` (used in
+ * {@link FrontendPlugin.extensions}) accept extensions for slots that don't
+ * declare metadata. The required-vs-optional distinction is enforced at
+ * registration time by {@link createSlotExtension}, which narrows the input
+ * shape based on the slot's metadata parameter.
  */
 export interface Extension<
-  TSlot extends SlotDefinition<unknown> = SlotDefinition<unknown>
+  TSlot extends SlotDefinition<unknown, unknown> = SlotDefinition<
+    unknown,
+    unknown
+  >
 > {
   id: string;
   slot: TSlot;
   component: React.ComponentType<SlotContext<TSlot>>;
+  metadata?: SlotMetadata<TSlot>;
 }
 
+/**
+ * Input shape for `createSlotExtension`. Requires `metadata` when the slot
+ * declares a non-`undefined` metadata type, forbids it otherwise.
+ */
+type SlotExtensionInput<TSlot extends SlotDefinition<unknown, unknown>> =
+  SlotMetadata<TSlot> extends undefined
+    ? {
+        id: string;
+        component: React.ComponentType<SlotContext<TSlot>>;
+        metadata?: undefined;
+      }
+    : {
+        id: string;
+        component: React.ComponentType<SlotContext<TSlot>>;
+        metadata: SlotMetadata<TSlot>;
+      };
+
 /**
  * Helper to create a type-safe extension from a slot definition.
- * This ensures the component props match the slot's expected context.
+ * Ensures the component props match the slot's expected context and that
+ * `metadata` matches the slot's metadata contract (required when the slot
+ * declares typed metadata, forbidden otherwise).
  */
-export function createSlotExtension<TSlot extends SlotDefinition<unknown>>(
-  slot: TSlot,
-  extension: Omit<Extension<TSlot>, "slot">
-): Extension<TSlot> {
+export function createSlotExtension<
+  TSlot extends SlotDefinition<unknown, unknown>
+>(slot: TSlot, extension: SlotExtensionInput<TSlot>): Extension<TSlot> {
   return {
     ...extension,
     slot,
-  };
+  } as Extension<TSlot>;
 }
 
 /**

package/src/slots.ts

@@ -1,37 +1,48 @@
 /**
  * A type-safe slot definition that can be exported from plugin common packages.
- * The context type parameter defines what props extensions will receive.
+ *
+ * @typeParam TContext  - Props passed to every extension component at render time.
+ * @typeParam TMetadata - Static descriptor each extension declares at registration time
+ *                        (e.g. label, icon, ordering, access rules). Use `undefined`
+ *                        (the default) when the slot just renders components without
+ *                        per-extension metadata.
  */
-export interface SlotDefinition<TContext = undefined> {
+export interface SlotDefinition<TContext = undefined, TMetadata = undefined> {
   /** Unique slot identifier, recommended format: "plugin-name.area.purpose" */
   readonly id: string;
   /** Phantom type for context type inference - do not use directly */
   readonly _contextType?: TContext;
+  /** Phantom type for metadata type inference - do not use directly */
+  readonly _metadataType?: TMetadata;
 }
 
 /**
  * Creates a type-safe slot definition that can be exported from any package.
  *
  * @example
- * // In @checkstack/catalog-common
+ * // Render-only slot (no metadata)
  * export const SystemDetailsSlot = createSlot<{ systemId: string }>(
  *   "catalog.system.details"
  * );
  *
- * // In your frontend plugin
- * extensions: [{
- *   id: "my-plugin.system-details",
- *   slot: SystemDetailsSlot,
- *   component: MySystemDetailsExtension, // Receives { systemId: string }
- * }]
- *
- * @param id - Unique slot identifier
- * @returns A slot definition that can be used for type-safe extension registration
+ * @example
+ * // Slot whose extensions declare metadata at registration time
+ * interface InfrastructureTabMetadata {
+ *   label: string;
+ *   icon: React.ComponentType<{ className?: string }>;
+ *   readAccess: AccessRule;
+ *   manageAccess: AccessRule;
+ *   order?: number;
+ * }
+ * export const InfrastructureTabsSlot = createSlot<
+ *   { canUpdate: boolean },
+ *   InfrastructureTabMetadata
+ * >("infrastructure.tabs");
  */
-export function createSlot<TContext = undefined>(
+export function createSlot<TContext = undefined, TMetadata = undefined>(
   id: string
-): SlotDefinition<TContext> {
-  return { id } as SlotDefinition<TContext>;
+): SlotDefinition<TContext, TMetadata> {
+  return { id } as SlotDefinition<TContext, TMetadata>;
 }
 
 /**
@@ -51,9 +62,21 @@ export interface UserMenuItemsContext {
   hasCredentialAccount: boolean;
 }
 
-export const UserMenuItemsSlot = createSlot<UserMenuItemsContext>(
-  "core.layout.navbar.user-menu.items"
-);
+/**
+ * Metadata for user-menu top-section extensions. The optional `group` key
+ * lets the menu render extensions under labeled headers (Workspace,
+ * Reliability, Configuration, Documentation, Account, or any custom label
+ * supplied by a third-party plugin). Extensions without a group render in
+ * an unlabeled bucket at the bottom of the top section.
+ */
+export interface UserMenuItemsMetadata {
+  group?: string;
+}
+
+export const UserMenuItemsSlot = createSlot<
+  UserMenuItemsContext,
+  UserMenuItemsMetadata
+>("core.layout.navbar.user-menu.items");
 export const UserMenuItemsBottomSlot = createSlot<UserMenuItemsContext>(
   "core.layout.navbar.user-menu.items.bottom"
 );

package/src/use-slot-extensions.ts

@@ -0,0 +1,38 @@
+import { useEffect, useReducer } from "react";
+import { pluginRegistry } from "./plugin-registry";
+import type { Extension, SlotMetadata } from "./plugin";
+import type { SlotDefinition } from "./slots";
+
+/**
+ * Strongly-typed extension entry returned by `useSlotExtensions`.
+ *
+ * `metadata` is typed by the slot's metadata parameter, falling back to
+ * `undefined` for slots that declare no metadata.
+ */
+export type SlotExtensionEntry<TSlot extends SlotDefinition<unknown, unknown>> =
+  Extension<TSlot> & {
+    metadata: SlotMetadata<TSlot>;
+  };
+
+/**
+ * Subscribe to all extensions registered for a slot.
+ *
+ * Re-renders when plugins are registered/unregistered. Use this hook when
+ * the consumer needs to do more than just render extensions inline (e.g.
+ * read metadata to build a tab bar). For pure render-and-pass-context use,
+ * `<ExtensionSlot slot={...} />` remains simpler.
+ */
+export function useSlotExtensions<TSlot extends SlotDefinition<unknown, unknown>>(
+  slot: TSlot
+): readonly SlotExtensionEntry<TSlot>[] {
+  const [, forceUpdate] = useReducer((x: number) => x + 1, 0);
+
+  useEffect(() => {
+    return pluginRegistry.subscribe(forceUpdate);
+  }, []);
+
+  return pluginRegistry.getExtensions(slot.id) as SlotExtensionEntry<TSlot>[];
+}
+
+// Re-export helper types alongside the hook.
+export type { SlotMetadata, SlotContext } from "./plugin";