roadmap

Roadmap

What devctl works on before v1.0, in order. Each item is a GitHub issue, so the issue is where the details and the discussion live. Platform bets are separate products that wait until Phases 1–3 are in daily use.

Sizes are relative: S is a contained change in one or two modules, M a new piece of a subsystem, L cross-cutting design work.

Phase 1: fix what the documented paths get wrong

Bugs on paths the docs promise, and the process that keeps them from coming back.

Item	Issue	Size	Status
Proxy isolation between checkouts	CHANGELOG 0.22.0	S	Done in 0.22.0
http / grpc health checks can't target ports: auto	#111	S	Done
Stock OpenTelemetry SDKs can't export to devctl (protobuf, gzip)	#112	M	Done
The log parser drops the text around embedded JSON	#113	S	Done
End-to-end tests of documented scenarios	#114	M	Done; new scenarios land with each fix
Users outside the original stack; experimental labels; this roadmap	#115	Ongoing	In progress
macOS in the unit-test CI job	#116	S	Done

Phase 2: work the way agents and CI work

Item	Issue	Size	Status
Parallel, isolated stacks per checkout or named instance	#117	L	Shipped (Parallel stacks), experimental
Test/CI harness: start --wait, devctl test, a failure bundle	#118	M	Shipped (Tests and CI), experimental
Proxy replay, mocks and fault injection	#119	M	Open

Phase 3: fill the gaps around the core

Item	Issue	Size	Status
Containers as full citizens: builds, networks, host access, OTLP env	#120	L	Open
Debug mode: run a service under a debugger, generate an attach config	#121	M	Open
OTLP metrics and per-route charts	#122	M	Open
Local HTTPS for proxy hostnames	#123	M	Open
Opt-in public tunnels for webhooks	#124	M	Open
Toolchain checks and setup	#125	M	Open
Crash notifications	#126	S	Open
<service>.local hosts setup	#127	S	Open

Unscheduled: if users need them

These depend on who ends up using devctl. They move into a phase when someone outside the original stack asks for them.

Item	Issue	Size
Cloud auth and secrets beyond Google (AWS SigV4, SSO, Azure Entra)	#128	L
Multi-repo workspaces	#129	L

Experimental features

A feature is experimental until a user outside the original stack relies on it. Until then its configuration and behavior may change in a minor release, without a deprecation period. Each one is marked in its docs with the same line:

Experimental. … may change without a deprecation period. See Experimental features.

Feature	Since	Docs
transform.request_body on proxy routes	0.20.0	Proxy
auth.suppress_authorization	0.17.0	Proxy, IAP
LLM capture.field_map and cost_per_token	0.16.0	LLM inspector
gRPC body decoding (inspect.grpc, trafficDecoders)	0.16.0	Proxy
environment.sops	0.19.0	Environment
environment.terraform	0.22.0	Environment
Parallel stacks: port slots, --instance, per-stack volumes, devctl mcp --write	0.22.0	Parallel stacks
devctl test, devctl bundle, start --wait	0.22.0	Tests and CI

When a feature graduates, its line comes out of the docs and the CHANGELOG says so under Changed, for example: "environment.sops is no longer experimental."

Feedback from other stacks

Most of devctl so far was shaped by one stack (Temporal, IAP, Workspace OAuth, LiteLLM, uvicorn, Vite). The missing input is teams on other stacks: AWS, Node-only, Go, a polyrepo org. If you try devctl on yours, onboard with the devctl-onboard skill and no other help. Wherever you get stuck, open a "Doesn't fit my stack" issue. Its blockers become issues here, and the reports are linked from #115.

Toward v1.0

v1.0 is the point where the codebase has been personally reviewed, tested and validated (see Project status). To keep that reachable while features land:

• New surface starts experimental, as above.
• Phase 1 comes before new Phase 2 and 3 features.
• A feature freeze before 1.0 is likely, so review can catch up with what has shipped.

Related

• Platform bets
• Architecture
• CHANGELOG