[mattdjenkinson]

Summary

Redesigns the compute plugin's workload Overview, following the "hairline sections" concept explored in Pencil.

• Summary card in the ALB overview's style: status, when the workload last changed, and the last hour's instances, CPU, memory, network and requests.
• Instances card: a table matching the ALB Backends card, with portal-style status badges (failure reasons appear in a tooltip), per-instance network traffic, and Logs, Shell and Metrics actions.
• Load balancers card: each load balancer that sends traffic to the workload, with its state, hostname and the routes that reach it, e.g. / → :8080 (http), plus the workload's share when a rule splits traffic. Route reading comes from @kevwilliams's feat/workload-overview-polish branch.
  • With no load balancer, Add to a load balancer creates the workload's NetworkService if it has none, then opens the portal's create dialog with the workload chosen. The service is the same object datumctl compute url creates.
  • The dialog side is in Open the create load balancer dialog with a workload chosen cloud-portal#1800.
• Hostnames stay with their load balancer. The URL and Visit button by the title, the endpoint line on the summary card and the Load balancer row in Configuration are gone. With two load balancers, showing the first one's hostname made it look like the workload's own URL.
• Loading states match what they stand in for:
  • Each stat in the summary card shows a placeholder until its own data arrives, instead of reading as zero.
  • The Instances and Load balancers cards load as their tables, headers included.
  • The page and workloads-list skeletons use the real tables' markup.
• datum-ui 3.8.0 in both plugins, the version cloud-portal runs.
• What changed and Configuration: recent activity replaces the recent-logs block, which was usually empty. Configuration gets its own card.
• Deploy states replace the step-by-step bar. A deploy takes about 10–15s on staging, faster than the page polls, so the bar never showed its steps. The card now shows:
  • deploying: elapsed time and a live instance count;
  • deployed: "Deployed in 13s" with a Created → Placed → Started → Ready timeline rebuilt from condition timestamps;
  • stalled: names the cause the API reports. A missing Secret or ConfigMap is read from the workload's deployments, the only place it's reported; quota waits come from the instances;
  • failed: the image can't be pulled, or the configuration was rejected.
• Polling stays at 3s until instances are ready, not just until the workload reports Available (which happens as soon as a placement exists).
• Instance page: a problem callout explains failures in plain words, with what to try.
• Metrics tab: network in and out per instance, replacing the "Not collected yet" stub.
• Workloads list: the sparklines drop their value text.

Screen.Recording.2026-11-06.at.16.51.43.mov

Data the design wants that the API doesn't expose yet (the asleep state and wake-ups, structured crash details, image digest and revision, image pull progress) is left out for now and tracked in #626.

Test plan

• pnpm typecheck, pnpm test (408 tests), pnpm build
• Rendered every state against cloud-portal's compiled CSS with sample data, at desktop and phone widths; checked the utility classes used compile in the host
• Network queries checked against the staging metrics API
• Locally against cloud-portal#1800: Add to a load balancer on cpu-mem-wave (which had no service) opens the dialog with it chosen
• Check in the portal against the compute-ui-state-test workloads on staging: state-missing-secret (stalled), state-bad-image (failed), state-crashloop (crash band), plus a fresh demo deploy (deploying, then deployed)

[ecv]

Approve.

Every new API and metrics path stays project-scoped and the project label is pinned and escaped; no tenant-isolation, query-bound or supply-chain problem found.

• Tenant isolation holds. New reads (WorkloadDeployments, NetworkService/HTTPProxy lists, the ensureWorkloadService POST) all go through getProjectScopedBase(projectId) in ui/consumer/src/lib/api.ts. The workload UID goes into labelSelector via URLSearchParams, so it is encoded.
• The new networkTrafficTotalQuery and networkThroughputQuery reuse networkTrafficLabels, which pins resourcemanager_datumapis_com_project_name and resource_namespace through escapePromQL, and escapes interface names with escapePromQLRegexp. The project comes from the route, the namespace and interface refs from the project's own Instance objects. A hostile project string cannot leave the quoted label.
• The __name__=~"rx|tx" regex in networkThroughputQuery is two constants, with the same label pin beside it, so it cannot widen the selection.
• Ranges and polling are bounded. Charts take useOverviewRange (default 1h) and the 5m rate window; the 3s fast poll is limited to settling workloads, and workloadSettling caps the "recently changed, short of replicas" case at 10 minutes.
• Dependencies: only @datum-cloud/datum-ui 3.6.0 to 3.8.0 (consumer, pinned; provider, ^3.8.0), plus its own bumps (isomorphic-dompurify 3.23.0, tailwind-merge 3.7.0). Every new lock entry carries an integrity hash from the npm registry. The provider lock gains ai@7.0.163, @ai-sdk/*, @vercel/oidc and @datum-cloud/datum-ui-assistant-core because datum-ui 3.8.0 now declares ai as a peer; consumer already had ai. Say so in the PR body so the provider bundle growth is expected.
• Tests are meaningful: exact-string query assertions, albRoutes and presenter tests, and api.test.ts covers the new helpers. No test feeds a hostile project or interface name through the new queries.
• Versus network-services-operator#877: both build on the same project-label-pinned PromQL helpers. This PR adds a write (ensureWorkloadService creates a NetworkService, treating 409 as success), which #877 does not.

Follow-ups:

• useWorkloadDeployments polls every 3s for as long as coming is true. A stalled deploy that stays Deploying polls indefinitely; give it the same 10-minute settle window as workloadSettling.
• ensureWorkloadService only checks whether a service selects the workload, then POSTs; a 403 surfaces as a generic Request failed. Show the permission cause in the load balancer UI.
• Add a hostile-value test (quotes, backslash, regex metacharacters in project and interface ref) for the two new query builders.