Execution Plane

Execution Plane is the lower runtime workspace in the Brain / Spine / Execution Plane split:

• Brain: jido_os
• Spine: jido_integration
• Execution Plane: this repo

Waves 2, 3, 6, and 7 turn the Wave 1 shell into the executable lower substrate used across the stack: the contract packet stays frozen, the kernel, placement, HTTP, process, and minimal JSON-RPC packages execute on the final contracts, and the repo now exposes frozen helper surfaces for unary HTTP, one-shot process execution, long-lived process transport, and truthful local, SSH, and guest placement breadth.

Documentation Menu

Start Here

• Guide Index
• North-Star Architecture
• Repo Topology And Package Map
• Shared Contracts And Lineage
• HTTP, GraphQL, And Realtime Family Design
• Process And Agent Session Family Design
• Brain, Spine, And Harness Alignment
• Subset-Complete Big-Bang Execution Model
• Surface Exposure And Contract Carriage Matrix
• Repo Quality Gate Command Matrix

Brain Contract Context

• Brain Contract Context
• AuthorityDecision.v1 Packet Baseline

Wave 1

• Master Orchestrator Prompt
• Wave 1 Checklist
• Wave 1 Implementation Prompt

Wave 2

• Wave 2 Checklist
• Wave 2 Implementation Prompt

Wave 3

• Wave 3 Checklist
• Wave 3 Implementation Prompt

Required ADRs

• ADR-001
• ADR-002
• ADR-003
• ADR-004
• ADR-006
• ADR-007
• ADR-008
• ADR-009
• ADR-011
• ADR-012
• ADR-014
• ADR-015
• ADR-016

Workspace Status

Waves 2, 3, 6, and 7 now own:

• the versioned contract packet
• route validation and dispatch planning
• timeout coordination and raw-fact emission in execution_plane_kernel
• unary HTTP execution in execution_plane_http
• basic local process execution in execution_plane_process
• long-lived process transport and attachable process sessions in execution_plane_process
• minimal unary JSON-RPC over the process runtime in execution_plane_jsonrpc
• frozen helper surfaces in ExecutionPlane.HTTP, ExecutionPlane.Process, and ExecutionPlane.JsonRpc
• prove-out corrections to the minimal-lane intent contracts exposed by downstream adoption
• the narrow placement seam in execution_plane_local
• SSH-backed placement helpers in execution_plane_ssh
• guest-backed placement helpers in execution_plane_guest
• conformance fixtures and lower-substrate execution coverage in execution_plane_testkit
• honest documentation that container and microVM package homes are not active sandbox guarantees yet

The minimum executable package homes for the substrate slice are:

• core/execution_plane_contracts
• core/execution_plane_kernel
• protocols/execution_plane_http
• protocols/execution_plane_jsonrpc
• placements/execution_plane_local
• placements/execution_plane_ssh
• placements/execution_plane_guest
• runtimes/execution_plane_process
• conformance/execution_plane_testkit

Reserved package homes for later waves are still tracked so topology and ownership stop drifting:

• streaming/execution_plane_sse
• streaming/execution_plane_websocket
• sandboxes/execution_plane_container
• sandboxes/execution_plane_microvm

Development

mix deps.get
mix format
mix compile --warnings-as-errors
mix test
mix docs

The repo gate for execution_plane is ROOT_NO_STATIC_ANALYSIS from technical/12_repo_quality_gate_command_matrix.md.

Wave 3 proves the covered minimal-lane adoption used by pristine, cli_subprocess_core, codex_sdk, and reqllm_next, and freezes the helper surfaces those repos consume instead of re-owning transport.

Wave 7 closes the remaining active-owner gap from /home/home/p/g/n/external_runtime_transport. That repo now remains only as an archival compatibility shell over the Execution Plane transport surface; it is no longer an active owner for service-runtime placement or long-lived transport mechanics.

License

MIT