Crates and change routing

Developer docs

Crate ownership is normative in the repository agent guide and decision P030. This map is a route into those sources, not permission to split or move ownership.

Active crates

Crate	Responsibility
platonic-core	Pure typed harness primitives: identifiers, events, run state, effect requests, and deterministic readback. Generated public API detail belongs on docs.rs.
platonic-protocol	Closed protocol v1 types, serialization, and validation. It has no transport or server policy.
platonic-client	Synchronous local connection, framing, deadlines, and typed request helpers. It does not own daemon run semantics.
platonic-server	Technical implementation crate for the Platonic server: registry, thread and run authority, policy, approvals, providers, tools, ledger, daemon, and gateways.
platonic	Thin crate for the Platonic product command, platonic, over platonic-server.
plato-agent	Plato Agent client distribution: plato, plato-tui, client orchestration, and offline replay. It never links platonic-server.
plato-tui	Client-side terminal UI components and protocol presentation.
plato-audio	Client-side voice capture, playback, and audio support.

Only platonic-core is the published implementation crate with a generated docs.rs surface at this head. The other workspace crates set publish = false; use their repository source and tests rather than treating reservation packages as API documentation. The publication rule is decision P029, reflected in the crate Cargo.toml files.

Dependency direction

The useful compile-time spine is:

plato-agent -> platonic-client -> platonic-protocol -> platonic-core

platonic -> platonic-server
                 -> platonic-client -> platonic-protocol -> platonic-core

The second client edge lets server-owned gateways behave as protocol peers; it does not transfer semantics into platonic-client. Compile-time direction and semantic ownership are different questions.

The prohibited directions are explicit:

• platonic-core cannot acquire I/O, provider, tool implementation, storage, daemon, connector, or UI code.
• platonic-protocol cannot acquire transport, policy, or server behavior.
• plato-* crates may depend on client, protocol, core, and client-side leaves, but never on platonic-server or the platonic command crate.
• platonic-server cannot depend on plato-*; gateways remain modules inside the server crate and use the client boundary.
• platonic stays a thin command over platonic-server.
• Provider, tool, store, and replay code stay in their current owning crates until a second consumer and an accepted design justify a split.

These directions are binding in AGENTS.md and partially compiler-checked by workspace_architecture_invariants_hold.

Selected boundary modules

Use this list to locate a crossing, then read callers and tests around it. It intentionally stops before becoming a module catalog.

Change	Start here
One-shot attachment and ordered consumption	plato-agent/src/run.rs
Local request mechanics	platonic-client/src/client.rs and transport.rs
Wire types and capability inventory	platonic-protocol/src/lib.rs
Host handshake and typed dispatch	daemon/server/host.rs and daemon/handlers/mod.rs
Thread authority, controller, and observer behavior	thread_authority.rs and daemon/runtime/thread.rs
Shared run driving and supervised effects	app/run_loop.rs and daemon/run_child/supervisor.rs
Pure event validation and effect requests	platonic-core/src/run.rs and the run API
Provider and tool host effects	provider/openai_compat/client.rs and app/tool_exec.rs
Ledger acknowledgement and recovery	ledger/recorder.rs, jsonl.rs, and sqlite.rs
Offline replay	plato-agent/src/offline.rs
Gateway as protocol peer	gateway/discord/daemon_bridge.rs

For item-level types and methods in the pure kernel, continue to docs.rs. For runtime behavior, follow the linked server source and executable tests instead of copying an internal API into this site.