404 map commands phase 21 define initial command set v0

[owleyeview]

MAP Commands — Phase 2.1 — Command Contract and Runtime Binding Seam (v0)

Closes #404.

Summary

Establishes the structural command contract and Runtime binding seam defined by the MAP Commands Specification. Introduces a new map_commands crate implementing the full wire/domain separation, a Runtime dispatch boundary, and Tauri integration — all without touching legacy receptor paths.

What was built

map_commands crate — new crate housing the full command type hierarchy:

• Wire types (MapCommandWire, SpaceCommandWire, TransactionCommandWire, HolonCommandWire) with serde and bind() implementations
• Domain types (MapCommand, TransactionCommand, HolonCommand, LookupAction, MutationAction, ReadableHolonAction, WritableHolonAction) — no wire dependencies, no serialization
• MapIpcRequest / MapIpcResponse IPC envelope types
• MapResult / MapResultWire with From<MapResult> conversion

Runtime dispatch sandwich — Runtime::dispatch(MapIpcRequest) -> MapIpcResponse:

• Binding (wire → domain) centralized inside Runtime only
• RuntimeSession owns transaction lifecycle (begin_transaction, get_transaction, remove_transaction) via an Arc<HolonSpaceManager>
• Scope-specific dispatchers (dispatch_space, dispatch_transaction, dispatch_holon) operate on domain types only; non-implemented commands return NotImplemented
• BeginTransaction and Commit execute end-to-end

Tauri integration — dispatch_map_command Tauri command:

• RuntimeState = RwLock<Option<Runtime>> managed state, initialized during run_complete_setup
• ConductorClientState shares the Arc<HolochainConductorClient> between the receptor and initialize_runtime()
• TrustChannel constructed from the conductor client and passed to init_client_runtime() as the DanceInitiator

holons_client — added init_client_runtime() returning Arc<HolonSpaceManager> without opening an implicit transaction (transaction lifecycle owned by RuntimeSession)

Tests

• 4 dispatch tests exercising Runtime::dispatch end-to-end: transaction creation, uniqueness, unimplemented command shape, invalid tx_id binding failure
• 14 wire serde roundtrip tests covering all command and result variants
• All 22 host unit tests pass; WASM compiles; cargo check -p conductora clean

Not in scope

• CommandDescriptor policy enforcement — Phase 2.2
• Full command coverage (stubs remain) — Phase 2.2
• ClientSession / undo-recovery integration (pending PR 412 recovery and transactional snapshots #418) — Phase 2.2
• Receptor de-primary — Phase 3

[evomimic]

Overall this looks great. I confirmed everything builds (happ and host), unit and sweetests all pass, and app runs correctly (via npm start).

I do have two suggested changes:

MutationAction Makes False Promise

The TransactionAction shape in this PR diverges from the current MAP Commands spec by introducing a second level of action nesting (LookupAction / MutationAction) instead of keeping the transaction action surface flat. See transaction_command.rs, transaction_wire.rs, and the tests that lock this shape in place: wire_serde_tests.rs and dispatch_tests.rs.

I agree the grouped shape has some local organizational appeal, but I don’t think this is a good place to vary from the spec.

Reasons:

• MutationAction introduces a semantic signal the model cannot actually guarantee. Some Dance operations may be mutating, and Dance is intentionally extensible, so nesting some actions under MutationAction implies a CQRS boundary that is not structurally true.
• That makes enum structure look like a policy/classification mechanism, when the spec says policy should be enforced by runtime descriptors and lifecycle rules, not inferred from command naming or ingress-visible shape.
• My recommendation is to keep TransactionAction aligned with the flat spec for this phase, and revisit sub-grouping later only if we can justify it without introducing misleading semantic guarantees.

Setup Failures Masked

Runtime initialization currently proceeds even after provider setup failure or when no conductor client was captured, which leaves the app with a partially functional MAP runtime instead of clearly unavailable runtime state. run_complete_setup() logs setup failure and continues into initialize_runtime(), and initialize_runtime() unconditionally builds Runtime from init_client_runtime(initiator) even when initiator is None. That contradicts the comment saying the runtime should remain None without a conductor client and will produce confusing behavior for commands that depend on conductor-backed capabilities. See app_builder.rs and app_builder.rs

[evomimic]

Looks good! Approved.