Module services 

Canonical services::PostCortexService trait. Every transport (gRPC, MCP, REST) delegates to the same single implementation in post-cortex-memory. Canonical service trait for post-cortex.

PostCortexService is the single internal entrypoint that every transport layer (gRPC, MCP, REST, future SDKs) delegates to. Per TODO.md:106-117 we never want two transports re-implementing the same operation with subtly different validation; they each translate their wire payload, then call the same method on this trait. The canonical impl lives in post-cortex-memory as MemoryServiceImpl.

Scope

Phase 4 introduces the trait skeleton with the read/write/search/manage operations every transport exposes. Phases 6 + 7 (MCP and daemon extraction) migrate the existing handlers to delegate here; until then both transports still call into ConversationMemorySystem directly.

Trait methods intentionally take small, immediately-usable request types defined in types rather than huge proto structs — keeping the surface readable from non-gRPC consumers. gRPC handlers do the proto-to-domain translation in a single From/Into module at the transport boundary (Phase 7).

Object safety

The trait is intentionally object-safe (no generic methods, no Self return types) so consumers — post-cortex-mcp in particular — can hold an Arc<dyn PostCortexService> and let downstream Rust projects plug in their own implementation without touching the MCP layer.

Re-exports

pub use types::*;

Modules

types

Request / response types for super::PostCortexService.

Traits

PostCortexService

Canonical post-cortex service.

Type Aliases

DynPostCortexService

Convenience alias — most consumers carry the trait behind an Arc.