Tracking issue for the chat-based management control plane ("formerly onboard"): one transport-independent ControlService as the sole management authority, reachable from any MCP-capable harness (Claude Code, Codex, …) and, later, native ZeroClaw agent tools.
State as of 2026-08-21
Built and verified (staged branches on this fork, no upstream PRs yet):
- Crate renamed
zeroclaw-onboarding → zeroclaw-control, propagated through the 5-layer Zerona stack (ordinary merges, full gate bar incl. strict workspace clippy).
feat/control-service-extraction — phase 1: ControlService with type-enforced preview→apply revision binding; terminal onboard drives it; 6 component tests unchanged.feat/control-mcp-readonly — phase 2: zeroclaw control --mcp read-only stdio server; unregistered surface is exactly ping/server_info/registration_help; fixture grants are test-only and provably absent from the release binary; 16 component tests, 3 mutation checks.docs/control-plane-phase-designs — phase 3–5 design docs + MCP protocol v1 spec; 26 open questions recorded against the parent architecture doc.- Live verification: scripted stdio client, headless Claude Code, and
codex exec all drove the server against an isolated config root; ZeroClaw's terminal flow creates agents through ControlService (PTY component test).
Governance
Maintainer decision 2026-08-21: no separate RFC. Acceptance path is the architecture doc + the four design docs + ordinary PR review. The parent doc's stricter wording will be amended when its PR opens.
Hard invariants that still hold regardless: no mutating MCP surface before phases 3–5 pass adversarial gates; a requester can never approve itself; approval authority stays on a separate operator backchannel.
Work map
Reference index: ~/worknotes/drafts/zerona-v2-prs/README.md (local). Parent doc: docs/book/src/architecture/chat-management-control-plane.md on docs/zerona-control-mcp-architecture.
Tracking issue for the chat-based management control plane ("formerly onboard"): one transport-independent ControlService as the sole management authority, reachable from any MCP-capable harness (Claude Code, Codex, …) and, later, native ZeroClaw agent tools.
State as of 2026-08-21
Built and verified (staged branches on this fork, no upstream PRs yet):
zeroclaw-onboarding→zeroclaw-control, propagated through the 5-layer Zerona stack (ordinary merges, full gate bar incl. strict workspace clippy).feat/control-service-extraction— phase 1: ControlService with type-enforced preview→apply revision binding; terminal onboard drives it; 6 component tests unchanged.feat/control-mcp-readonly— phase 2:zeroclaw control --mcpread-only stdio server; unregistered surface is exactly ping/server_info/registration_help; fixture grants are test-only and provably absent from the release binary; 16 component tests, 3 mutation checks.docs/control-plane-phase-designs— phase 3–5 design docs + MCP protocol v1 spec; 26 open questions recorded against the parent architecture doc.codex execall drove the server against an isolated config root; ZeroClaw's terminal flow creates agents through ControlService (PTY component test).Governance
Maintainer decision 2026-08-21: no separate RFC. Acceptance path is the architecture doc + the four design docs + ordinary PR review. The parent doc's stricter wording will be amended when its PR opens.
Hard invariants that still hold regardless: no mutating MCP surface before phases 3–5 pass adversarial gates; a requester can never approve itself; approval authority stays on a separate operator backchannel.
Work map
Reference index:
~/worknotes/drafts/zerona-v2-prs/README.md(local). Parent doc:docs/book/src/architecture/chat-management-control-plane.mdondocs/zerona-control-mcp-architecture.