-
Notifications
You must be signed in to change notification settings - Fork 1
Description
MAP Commands — Phase 2.1 — Define Initial Command Contract and Sandwich Boundaries (v0)
1. Summary (Required)
What is the enhancement?
Define and implement the initial MAP Commands contract (v0) as a strongly-typed IPC model with explicit wire/domain separation ("sandwich model") between:
- TypeScript SDK
- Conductora Tauri host ingress
- IntegrationHub Runtime domain dispatch
This phase establishes:
- Canonical wire envelopes (
MapRequestWire,MapResponseWire) - Structural scoped command model (
MapCommandWireand scoped variants) - Post-bind domain command model (
MapCommand, scoped domain variants) - Explicit binding seam: Wire -> Domain inside
Runtime::dispatch - Clear separation of MAP domain ingress vs operational control-plane commands
The goal is:
Every TS-visible MAP domain operation maps to a single MapCommandWire variant, which binds to a single domain command shape and a stable Runtime dispatch target.
2. Problem Statement (Required)
Why is this needed?
Current command plumbing still reflects legacy assumptions:
- String-based command authority (
name: String) - Mixed or implicit scope
- Binding and lifecycle policy distributed across ingress/receptor paths
- Inconsistent distinction between domain commands and operational commands
Before dispatcher/cutover work, we must stabilize the contract so architecture is enforceable:
- Domain ingress accepts wire types only
- Domain execution uses domain types only
- Scope is structural and explicit
- Lifecycle/policy decisions can be centralized in Runtime in Phase 2.2
- Operational endpoints (
is_service_ready, etc.) remain explicitly out-of-band
3. Dependencies (Required)
Reference docs: MAP Commands Spec and MAP Commands Cheat Sheet define baseline vocabulary and command inventory for v0 alignment.
Does this depend on other issues or features?
- Transaction-bound reference model and lifecycle primitives already available in core
- Existing wire binding primitives (
*Wire.bind(context)) available for reuse - No requirement to remove legacy ingress in this phase
Must land before:
- Phase 2.2 Runtime dispatcher centralization
- Phase 3 single domain ingress cutover
- SDK contract stabilization for MAP domain commands
4. Proposed Solution (Required)
How would you solve it?
4.1 Define Canonical Wire Envelopes
Introduce/standardize:
pub struct MapRequestWire {
pub request_id: RequestId,
pub command: MapCommandWire,
}
pub struct MapResponseWire {
pub request_id: RequestId,
pub result: Result<MapResultWire, HolonErrorWire>,
}Rules:
- Wire types are transport-only and serializable
- Wire types carry identifiers and payload data, not runtime behavior
- Wire types must not appear below Runtime binding seam
4.2 Define Structural Command Scope at Wire Layer
Define MapCommandWire with explicit scope branches:
pub enum MapCommandWire {
Space(SpaceCommandWire),
Transaction(TransactionCommandWire),
Holon(HolonCommandWire),
}Define scoped payload enums/structs (v0 set) with no name: String authority.
Remove from target contract:
- string command routing as authority
- generic mixed-scope request body as authority
- implicit scope inference
4.3 Define Post-Bind Domain Command Surface
Define domain command shapes with no wire dependencies:
pub enum MapCommand {
Space(SpaceCommand),
Transaction(TransactionCommand),
Holon(HolonCommand),
}Transaction/Holon domain variants should carry bound runtime objects (e.g., TransactionContextHandle, HolonReference) rather than wire payloads or loose identifiers.
Rules:
- No
*Wiretypes in domain command structs/enums - No serialization requirements in domain command types
- No separate
tx_idstring fields once binding has completed
4.4 Define Binding Responsibilities (Contract Only)
This phase does not implement full dispatcher behavior (Phase 2.2), but defines normative responsibilities:
- Wire -> Domain binding occurs only in
Runtime::dispatch - Holon-scoped binding resolves tx provenance from reference where required
- Transaction-scoped binding resolves
tx_id -> context handle - Binding failures map to deterministic wire-safe errors
4.5 Define Domain vs Ops Interface Boundary
Codify two command planes:
-
MAP Domain Plane
- Uses
MapRequestWire/MapCommandWire - Will flow through
dispatch_map_command -> Runtime::dispatch(Phase 2.3)
- Uses
-
Operational Control Plane
- Readiness/health/diagnostics (e.g.,
is_service_ready) - Out of MAP command model scope
- Must not bypass Runtime if invoking domain execution
- Readiness/health/diagnostics (e.g.,
This ensures later addition/retention of status commands does not violate the single domain ingress invariant.
4.6 Initial v0 Command Set (Contract Scope)
Define and freeze v0 contract coverage (exact naming may follow existing domain naming conventions):
- Space:
BeginTransaction
- Transaction:
- Lifecycle:
Commit(and optionalRollbackplaceholder if retained) - Mutation: create/stage/update/relationship/load/delete variants
- Lookup: collection/read/count/space-anchor variants
- Dance invocation variants
- Graph query placeholder (optional, returns NotImplemented if included)
- Lifecycle:
- Holon:
- Read and write action families over bound
HolonReference
- Read and write action families over bound
5. Scope and Impact (Required)
What does this impact?
- MAP command contract types in host + TS boundary models
- Scoped command taxonomy and payload modeling
- Elimination plan for string-based command authority
- Prerequisite contract for Runtime centralization in Phase 2.2
Not in scope for this phase:
- Full runtime dispatch implementation
- Tauri cutover/removal of legacy ingress
- Receptor plumbing changes
- Descriptor enforcement implementation details (contract only in this phase)
6. Testing Considerations (Required)
How will this enhancement be tested?
- Wire model serde roundtrip tests for each command variant
- Domain model compile-time separation checks (no
*Wireleakage) - Mapping tests from TS request builders to structural wire variants
- Contract validation tests for required/invalid scoped payload shapes
Legacy tests should continue to run; this phase is contract-first and can coexist with legacy ingress paths.
7. Definition of Done (Required)
When is this enhancement complete?
- Canonical
MapRequestWireandMapResponseWireare defined and used for v0 contract surface -
MapCommandWirestructural scope model is defined (Space/Transaction/Holon) - Post-bind domain command model is defined with no wire dependencies
- String-based command authority is removed from the target contract model
- Binding seam responsibilities are documented as Runtime-owned
- Domain-vs-ops interface boundary is explicit in docs/types
- v0 command set is frozen at contract level
- Contract serde/shape tests pass
This phase stabilizes the MAP command contract so Phase 2.2 can implement centralized Runtime dispatch policy without ambiguity, and Phase 2.3 can cut over to a single domain ingress safely.