Skip to content

MAP Commands -- Phase 2.1 -- Define initial command set (v0) #404

@evomimic

Description

@evomimic

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 (MapCommandWire and 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 *Wire types in domain command structs/enums
  • No serialization requirements in domain command types
  • No separate tx_id string 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:

  1. MAP Domain Plane

    • Uses MapRequestWire/MapCommandWire
    • Will flow through dispatch_map_command -> Runtime::dispatch (Phase 2.3)
  2. 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

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 optional Rollback placeholder 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)
  • Holon:
    • Read and write action families over bound HolonReference

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 *Wire leakage)
  • 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 MapRequestWire and MapResponseWire are defined and used for v0 contract surface
  • MapCommandWire structural 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.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions