Version Packages

[github-actions]

Checkstack v0.137.0 Changelog

Minor Changes

• Add the objectRef instanceAccess mode and move the relation-write authz onto it

  The relation-tuple writes (writeRelation / removeRelation / setObjectPublic)
  administer team access on ANY resource type, so their authorization could not be
  expressed by the existing instanceAccess modes (which all assume a fixed
  resource type) and was enforced by hand in the auth handlers with access: [] -
  leaving the contract unable to declare the rule and the API docs showing no
  restriction.

  A new objectRef mode reads the object's TYPE and id from the request body
  (typeParam / idParam) and authorizes via the same engine native scoping uses:
  the endpoint's own access rule (auth.teams.manage) is the global admin
  OR-override, otherwise the caller must be able to manage the referenced object
  (its own <type>.manage rule on a non-private object, or a team editor/owner
  grant on it). autoAuthMiddleware enforces it, the boot validator recognises it
  (input paths cross-checked), and the auth handlers drop their hand-rolled checks.
  Behaviour is unchanged; the authorization is now contract-declared and enforced
  by the middleware rather than the handler.

  Packages: @checkstack/auth-backend, @checkstack/auth-common, @checkstack/backend, @checkstack/backend-api, @checkstack/common

• Make endpoint authorization self-documenting in the generated API docs

  Every procedure's authorization is now derived from its contract metadata (its
  access rules + instanceAccess mode) via a shared mode-descriptor registry and
  emitted into the OpenAPI spec - both structurally (x-orpc-meta.authorization)
  and as a human **Authorization.** sentence folded into the operation
  description. Previously the docs surfaced only a flat list of global rule ids, so
  an integrator (an API-key/application principal that CAN hold team grants) never
  saw the team-grant / per-object dimension, and endpoints gated purely in the
  handler showed no restriction at all.

  For authorization that no declarative mode can express and is therefore enforced
  in the handler (a compound OR, a graded verdict, a DB-derived id set), a new
  optional accessNote on the procedure metadata surfaces the real rule in the
  docs as an explicitly handler-enforced addendum. The note is documentation, not a
  guarantee: per .claude/rules/rlac.md the drift guard for such authz is
  behavioral tests over an extracted pure decision function, and the note must
  state exactly what those tests pin.

  Every handler-enforced authorization endpoint now carries such a note so the docs
  are complete: the team read/scoping and team-management endpoints
  (@checkstack/auth-common), the health-check assignment/history reads
  (@checkstack/healthcheck-common), the audience-graded incident/maintenance
  reads (@checkstack/incident-common, @checkstack/maintenance-common), status
  -page publish's bound-resource check (@checkstack/status-page-common), the
  stream setSystemLinks readable-additions check
  (@checkstack/{metricstream,tracestream,logstream}-common), and the automation
  runAs escalation guard (@checkstack/automation-common). These are
  metadata-only additions - no runtime behavior changed. The notes describe the
  rule for API-doc readers only; the drift guard is behavioral tests over the
  check's decision function (per .claude/rules/rlac.md), so the notes name no
  internal test files.

  The API docs viewer (@checkstack/api-docs-frontend) now renders each
  operation's description as Markdown, so the **Authorization.** block (and any
  inline code) formats correctly instead of showing raw markdown.

  Packages: @checkstack/api-docs-frontend, @checkstack/auth-common, @checkstack/automation-common, @checkstack/backend, @checkstack/common, @checkstack/healthcheck-common, @checkstack/incident-common, @checkstack/logstream-common, @checkstack/maintenance-common, @checkstack/metricstream-common, @checkstack/status-page-common, @checkstack/tracestream-common

• Migrate the frontend from react-router-dom v7 to react-router v8

  Resolves GHSA-qwww-vcr4-c8h2 (HIGH): React Router before 8.3.0 has an RSC-mode
  CSRF bypass that lets an action execute before the 400 response. Checkstack runs
  a client-side SPA (<BrowserRouter>) and does not use RSC mode, so the platform
  was not exploitable through it - but the advisory kept the dependency-graph
  security gate red on every pull request, and the fix is only available in the 8.x
  line, which the auto-remediation deliberately will not reach (it refuses major
  bumps).

  react-router-dom has no v8: it was folded into react-router in v7 and v8
  ships as react-router only. So this is a package swap rather than a range bump:

  • 31 packages now depend on react-router@^8.3.0 instead of
    react-router-dom@^7.16.0, and 97 source files import from react-router.
  • The Module Federation host share, optimizeDeps and dedupe entries move to
    react-router (shared singleton requiredVersion ^8.0.0). Remotes never
    shared the router, so the remote contract is unchanged.
  • The syncpack unified-range group tracks react-router, keeping the enforced
    single-range guarantee that a past four-range regression motivated.

  The API surface Checkstack uses is unchanged between v7 and v8 - BrowserRouter,
  MemoryRouter, Routes, Route, Link, NavLink, useLocation,
  useNavigate, useParams and useSearchParams are all exported by v8 with the
  same signatures - so no routing code changed beyond the import specifier. v8
  requires React >= 19.2.7, which the workspace already pins.

  Packages: @checkstack/about-frontend, @checkstack/ai-backend, @checkstack/ai-frontend, @checkstack/announcement-frontend, @checkstack/anomaly-frontend, @checkstack/api-docs-frontend, @checkstack/auth-frontend, @checkstack/automation-frontend, @checkstack/catalog-frontend, @checkstack/command-frontend, @checkstack/dashboard-frontend, @checkstack/dependency-frontend, @checkstack/frontend, @checkstack/gitops-frontend, @checkstack/healthcheck-frontend, @checkstack/incident-frontend, @checkstack/infrastructure-frontend, @checkstack/integration-frontend, @checkstack/logstream-frontend, @checkstack/maintenance-frontend, @checkstack/metricstream-frontend, @checkstack/notification-frontend, @checkstack/pluginmanager-frontend, @checkstack/queue-frontend, @checkstack/release, @checkstack/satellite-frontend, @checkstack/script-packages-frontend, @checkstack/secrets-frontend, @checkstack/slo-frontend, @checkstack/status-page-frontend, @checkstack/telemetry-frontend, @checkstack/tracestream-frontend, @checkstack/ui

• Split telemetry "Test connection" so its authorization is contract-declared

  testSourceConfig used to accept an optional sourceId (to reuse an existing
  source's stored secrets) and verified MANAGE on that source with a hand-rolled
  check in the handler - the one telemetry endpoint whose authorization was not
  declared on the contract. It is now split into two procedures, each fully
  declared:

  • testSourceConfig - the fresh-editor dry run (no stored secrets), typeScoped
    at manage level, as before but with sourceId removed from its input.
  • testExistingSource - the secret-reuse dry run, sourceId required and
    authorized by the idParam instanceAccess mode (MANAGE on that source),
    enforced by the middleware. The hand-rolled assertCanManageSource handler
    check is deleted.

  The "Test connection" button calls whichever procedure fits (it has a sourceId
  or not), so the UI is unchanged.

  BREAKING CHANGE: testSourceConfig no longer accepts a sourceId - callers that
  reused stored secrets by passing one must call the new testExistingSource
  instead. Authorization behaviour is unchanged (still MANAGE on the referenced
  source), only the endpoint split.

  Packages: @checkstack/telemetry-backend, @checkstack/telemetry-common, @checkstack/telemetry-frontend

Patch Changes

• @checkstack/cache-api@0.3.21

  Packages: @checkstack/cache-utils, @checkstack/ingest-utils

• @checkstack/cache-utils@0.3.2

  Packages: @checkstack/ingest-utils

• @checkstack/otlp-wire@0.1.1

  Packages: @checkstack/ingest-utils

• @checkstack/scripts@0.7.7

  Packages: create-checkstack-plugin

• @checkstack/signal-common@0.3.2

  Packages: @checkstack/signal-frontend