v0.4.1 · disposable previews · mesh isolation · bucket websites Agents ship · humans inspect
← Engineering log

Workspaces are product names, namespaces are internal

Secondary workspaces are selected as -w prod, Kubernetes namespace names moved behind the API, and machine-readable output gained a structured workspace shape.

Until 0.3.20, selecting a secondary workspace meant typing its Kubernetes namespace: -w w-prod. That leaked an implementation detail into every command and forced users to remember a prefix rule instead of a name they chose. Mechanics 0.3.20 finished ADR-029: workspaces are selected by product name, and namespaces went back to being infrastructure.

product selectors

ssh -T mechanics.run -- workspace create prod
ssh -T mechanics.run -- app list -w prod
ssh -T mechanics.run -- route create web --app myapp -w prod
ssh -T mechanics.run -- user kubeconfig -w prod > kubeconfig-prod.yaml

Primary is implicit, aggregate is explicit

Omitting -w selects the primary workspace, the one backed by x-<github-login>, and namespace-shaped selectors such as -w w-prod are rejected with migration guidance rather than silently accepted. Account-wide listings became a deliberate choice too: secret list --all-workspaces instead of a list command that quietly ignored the workspace you passed.

A structured shape for machines

JSON output now reports workspace context as an object with name, namespace, and kind, with name: null for the primary workspace. Agents that need the Kubernetes namespace for tunnels or kubeconfig files read workspace.namespace. Everything user-facing uses workspace.name. Internally, GitOps paths, Argo CD application names, OpenBao materialization, and metrics queries all switched to a distinct WorkspaceNamespace type, with architecture tests keeping the old namespace-shaped APIs from creeping back.

Users name workspaces. Only the platform needs to know what the namespace is called.