Developer Workspace — Validation & Roadmap
OpenKubes is actively validating a contract-driven developer workspace with OpenCode as its first coding-agent profile.
Delivery status
| Public source / work area | Scope | Evidence and remaining work |
|---|---|---|
| Contract spike | Contract spike and OpenCode evaluation | Bounded proof recorded; ADR remains Proposed |
| Namespace reference profile | Namespace reference profile with OpenCode | Reconciler proven on disposable clusters; not production-ready |
| Live isolation and lifecycle proof | Live isolation / lifecycle validation | Bounded disposable-cluster proof of resource bounds, drift correction and UID-bound cleanup recorded; restart/reboot persistence evidence is separate; limits described below |
| Second coding-agent runtime proof | Second coding-agent runtime validation | OpenCode and Codex exercised under the same reviewed profile |
| Capacity-enforcing workspace storage | Reproducible capacity-enforcing workspace storage | Runtime capacity enforcement proven on disposable clusters with the ok-storage-local-quota XFS project-quota profile; cluster, storage and admission setup reproducible from repository entry points; not production-ready |
| User / operator guide | Operator guidance and OpenCode quickstart | Hands-on OpenCode quickstart (make live-up / live-down) available for disposable clusters; supported self-service installation remains future work |
Describes the public repository state as of 18 October 2026.
Follow the public sources above for the proof scope and implementation guidance. This is a reference implementation, not production-ready; the table describes demonstrated behavior and remaining work rather than ticket status.
For a guided first evaluation, see Your First AI Coding Workspace.
What has been proven
The current candidate verdict recommends GO for continued work and records a bounded live proof covering 18/18 required effects for OpenCode and Codex under a reviewed Namespace implementation profile.
The proof demonstrates declared command execution and independently checked fixture verification, selected network restrictions, ServiceAccount token controls, resource and storage behaviors, credential checks and UID-scoped cleanup. Negative controls were used to ensure failed preconditions produced failures.
The Crossplane reference implementation was then proven on disposable Talos clusters: reconciliation and drift correction, refusal of duplicate workspace identities, the operator/non-operator authority boundary (including a full enumeration of who can steer the privileged provider), CPU, memory and runtime storage-capacity enforcement under user namespaces, admission policies that must be in place before any workspace is created, and UID-bound cleanup for the hands-on mode. A deliberately false capacity declaration was refused certification.
What has not been proven
- Not production operation: the reconciler is proven on disposable clusters only; there is no requester role, upgrade path or production support yet.
- Not hostile multi-tenant isolation: the Namespace-based profile shares the underlying Kubernetes kernel and trusts its infrastructure.
- Not exhaustive credential security: scoped credential scans cannot disprove all data exfiltration.
- Not tool-level MCP authorization: tested reachability does not establish
approvedToolsenforcement inside the agent. - Not reproducible image build attestation: captured image digests are not end-to-end attestations.
- Not production authority: agent execution never implies approval to merge, release or deploy.
The governing ADR-Platform-039 remains Proposed. The live validation is meaningful engineering evidence, not a product GA announcement.
Next steps
Complete the current implementation and validation tasks, resolve the remaining contract and security boundaries, review/accept the ADR through the project's human architecture process, and only then document a supported self-service installation flow.