@spunto/design-system 0.24.0 → 0.25.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@spunto/design-system",
-  "version": "0.24.0",
+  "version": "0.25.0",
   "description": "Spunto's shared design system — warm/flame tokens, color constants, and UI primitives.",
   "type": "module",
   "license": "MIT",

package/src/components/workers/types.ts

@@ -26,7 +26,7 @@ export interface WorkerCardWorker {
   name?: string | null
   /** Fallback identity when `name` is empty — renders as "Workspace #3". */
   index?: number | null
-  /** Lifecycle state: `provisioning` | `pulling` | `starting` | `setup` | `ready` | `stopping` | `stopped` | `deleting` | `error`. */
+  /** Lifecycle state: `provisioning` | `building` | `pulling` | `starting` | `setup` | `ready` | `stopping` | `stopped` | `deleting` | `error`. */
   state?: string | null
   /** Docker-level state: `running` | `stopped` | `exited` | `created` | `not_found` | `error`. */
   dockerState?: string | null

package/src/components/workers/worker-status.tsx

@@ -6,6 +6,14 @@
 // This module is the union of both, plus the transient states (`pulling`,
 // `stopping`, `deleting`) that only ever existed as ad-hoc `if`s above the table.
 //
+// `building` is the odd one out: it is the state a *control plane* reports, and
+// the only one here that Spunto Lite names and the dashboard does not. Both wait
+// for a project image before a container exists — Cloud does it inside
+// `provisioning` and rebuilds the fact client-side by joining the project's image
+// builds, Lite says it in the field. It is deliberately not folded into
+// `pulling`: building an image and pulling one are different waits, and only one
+// of them has a log worth opening.
+//
 // No "use client": pure functions and hookless components, so a React Server
 // Component can call them.
 
@@ -21,6 +29,7 @@ export type WorkerStatusKey =
   | "error"
   | "pending"
   | "setup"
+  | "building"
   | "pulling"
   | "stopping"
   | "deleting"
@@ -79,6 +88,7 @@ export const workerStatusConfig: Record<WorkerStatusKey, WorkerStatusConfig> = {
   },
   pending: BUSY,
   setup: { ...BUSY, label: "Setting up…" },
+  building: { ...BUSY, label: "Building image…" },
   pulling: { ...BUSY, label: "Pulling image…" },
   stopping: { ...BUSY, label: "Stopping…" },
   deleting: { ...BUSY, label: "Deleting…" },
@@ -99,7 +109,7 @@ const SETUP_STATES = new Set(["provisioning", "starting", "setup"])
  * Worker snapshot → one status, tolerant of shapes it has never seen.
  *
  * Order matters: the *lifecycle* state wins whenever it describes an action in
- * flight (deleting, stopping, pulling, setting up), because docker still reports
+ * flight (deleting, stopping, building, pulling, setting up), because docker still reports
  * the container as `running` throughout — showing "Running" while a worker is
  * being deleted is the bug this ordering exists to prevent. Past that, the
  * docker state is the truth. Apps with a single `state` field (Spunto Lite) fall
@@ -120,6 +130,7 @@ export function resolveWorkerStatus(worker: WorkerCardWorker): WorkerStatus {
 
   if (state === "deleting") return of("deleting")
   if (state === "stopping") return of("stopping")
+  if (state === "building") return of("building", { settingUp: true })
   if (state === "pulling") return of("pulling", { settingUp: true })
   if (state && SETUP_STATES.has(state)) return of("setup", { settingUp: true })