Resource.systemData is required and typed Record<string, never>, which forces every test fixture to be cast #365

What happens

plugins/plugin-radius/src/resources/resource.ts declares the shared resource envelope as:

export interface Resource<T = { [key: string]: unknown }> {
  id: string;
  type: string;
  name: string;
  tags?: Record<string, string>;
  systemData: Record<string, never>;
  properties: T;
}

systemData is required and typed Record<string, never> — "an object whose every property has type never". The only value that satisfies it is {}. So the model can express exactly one thing about systemData: that it is present and empty.

That is not what the control plane returns. UCP responses carry a populated systemData (createdAt, createdBy, lastModifiedAt, and so on), and several resources the dashboard reads omit the field entirely.

Why it matters beyond tidiness

The field is required and unfillable at the same time, so no accurate fixture can be written as a plain typed literal. Every test that needs a Resource therefore casts:

const app = {
  id: '/planes/radius/local/.../applications/demo-app',
  name,
  type: 'Applications.Core/applications',
  properties: { environment: '/environment/default' },
} as Resource<ApplicationProperties>;

The cast silences the systemData error, but it also switches off checking of id, type, name, and properties in the same expression. A modelling choice intended to tighten the type is the reason the fixtures across the plugin's component suites are effectively untyped — so a genuine drift in properties would not be caught either.

Expected

systemData?: Record<string, unknown>;

Optional, because not every response carries it, and open-valued, because the values are real. Fixtures can then be written as checked literals and the casts removed.

Pinned by

RS-14 in plugins/plugin-radius/src/resources/resource.test.ts, added by the Phase 1 work of the dashboard test plan (docs/design/2026-09-dashboard-plugin-test-plan.md). It is tagged KNOWN-DEFECT and uses @ts-expect-error to record both halves of the current behaviour — that a populated systemData is rejected and that the field cannot be omitted. Both @ts-expect-error comments become unused compile errors when this is fixed, which is the signal the fix landed.