What
packages/workspace/src/types.ts currently accepts legacy \"running\" and \"stopped\" workspace status values and transforms them to \"inactive\" on read:
```ts
export const WorkspaceStatusSchema = z
.enum(["inactive", "running", "stopped"])
.transform(() => "inactive" as const);
```
This shim exists to absorb the schema shrink in #338 — workspaces persisted before that PR have `status: "running"` or `status: "stopped"` in their KV entries, and would otherwise fail Zod validation in `listWorkspaces` and disappear from the UI. Each entry rewrites itself with the canonical `"inactive"` value the next time `updateWorkspaceStatus` fires, so the legacy values fade out over time.
At 1.0
Drop the transform and the legacy enum entries:
```ts
export const WorkspaceStatusSchema = z.enum(["inactive"]);
```
By 1.0 every persisted entry will have been rewritten to `"inactive"` (or the user accepts that pre-1.0 entries get dropped from the workspace list, since 1.0 is the breaking-change cut).
Why future-breaking
Anything still persisting a non-"inactive" status by 1.0 — whether from a stale KV mirror, an external integration writing to the registry, or a test fixture — will hard-fail on read. This is intentional: at 1.0 we want the schema to enforce the post-per-dispatch model directly without a coercion layer.
What
packages/workspace/src/types.tscurrently accepts legacy\"running\"and\"stopped\"workspace status values and transforms them to\"inactive\"on read:```ts
export const WorkspaceStatusSchema = z
.enum(["inactive", "running", "stopped"])
.transform(() => "inactive" as const);
```
This shim exists to absorb the schema shrink in #338 — workspaces persisted before that PR have `status: "running"` or `status: "stopped"` in their KV entries, and would otherwise fail Zod validation in `listWorkspaces` and disappear from the UI. Each entry rewrites itself with the canonical `"inactive"` value the next time `updateWorkspaceStatus` fires, so the legacy values fade out over time.
At 1.0
Drop the transform and the legacy enum entries:
```ts
export const WorkspaceStatusSchema = z.enum(["inactive"]);
```
By 1.0 every persisted entry will have been rewritten to `"inactive"` (or the user accepts that pre-1.0 entries get dropped from the workspace list, since 1.0 is the breaking-change cut).
Why future-breaking
Anything still persisting a non-"inactive" status by 1.0 — whether from a stale KV mirror, an external integration writing to the registry, or a test fixture — will hard-fail on read. This is intentional: at 1.0 we want the schema to enforce the post-per-dispatch model directly without a coercion layer.