MAP Commands -- Phase 2.2 — Implement IntegrationHub MAP Command dispatcher

[evomimic]

MAP Commands — Phase 2.2 — Implement IntegrationHub Runtime Dispatcher as the Authoritative Domain Boundary

1. Summary (Required)

What is the enhancement?
Implement the authoritative MAP domain execution boundary in IntegrationHub:

• Runtime::dispatch(request: MapRequestWire) -> Result<MapResponseWire, HolonErrorWire>

This dispatcher is the single domain choke point that:

• binds Wire -> Domain
• resolves transaction context
• enforces lifecycle/descriptor policy
• routes to scope-specific domain dispatchers
• converts domain results/errors back to wire form

This phase builds the new domain path in parallel with legacy paths (no cutover removal yet).

---

2. Problem Statement (Required)

Why is this needed?
Even with a structural command contract, correctness remains fragile unless enforcement is centralized. Today, binding/policy/routing concerns are distributed across ingress/receptor-era paths.

We need one auditable place where:

• wire binding happens
• tx selection and reference binding are enforced consistently
• lifecycle and commit guard policy are applied deterministically
• domain execution routing is structural (not string authority)
• error/result shaping is standardized

Without this, policy leaks and architectural drift continue.

---

3. Dependencies (Required)

Does this depend on other issues or features?

Reference docs: MAP Commands Spec and MAP Commands Cheat Sheet define baseline vocabulary and command inventory for v0 alignment.

• Phase 2.1 contract types and boundaries are defined via Issue MAP Commands -- Phase 2.1 -- Define initial command set (v0) #404 .
• Core lifecycle primitives and tx-bound reference binders are available
• Legacy paths remain active during this phase for parity/testing

---

4. Proposed Solution (Required)

How would you solve it?

4.1 Add Runtime Dispatch Boundary

Implement:

impl Runtime {
    async fn dispatch(
        &self,
        request: MapRequestWire,
    ) -> Result<MapResponseWire, HolonErrorWire>;
}

Responsibilities inside this method:

1. capture request_id
2. bind command Wire -> Domain
3. resolve descriptor policy
4. enforce lifecycle/commit guard invariants
5. route to scope-specific domain dispatch
6. return MapResponseWire with deterministic result/error mapping

---

4.2 Centralize Binding in Runtime

Move binding ownership to Runtime only:

• MapCommandWire -> MapCommand
• tx-scoped: tx_id -> TransactionContextHandle (or equivalent bound context carrier)
• holon-scoped: bind reference wire and validate tx provenance
• ensure no *Wire.bind(...) domain-entry calls exist outside Runtime seams for new path

---

4.3 Implement Scope-Specific Domain Dispatchers

Inside Runtime, route structurally by scope:

• dispatch_space
• dispatch_transaction
• dispatch_holon

These methods operate on domain types only (no wire types).

Scope branching is structural routing only; policy decisions remain descriptor-driven.

---

4.4 Centralize Policy Enforcement

Implement unified enforcement in Runtime:

• resolve CommandDescriptor for each bound command
• enforce:
  • open-transaction requirements
  • commit ingress guard requirements
  • commit allowed semantics
  • snapshot-after behavior where applicable

No duplicated lifecycle/policy logic should remain in ingress-level command handlers for the new path.

---

4.5 Reposition Receptors as Internal Adapters

For the new path:

• ingress does not select receptor type
• Runtime owns delegation decisions
• receptor-like components (e.g., holochain path) are internal adapters/channels, not ingress routers

Legacy path can remain temporarily unchanged in this phase.

---

4.6 Keep Legacy Path Operational (Interim)

Do not remove legacy ingress in this phase.

• allow side-by-side execution for parity
• add compatibility adapters if needed
• preserve existing tests while new path is validated

---

5. Scope and Impact (Required)

What does this impact?

• IntegrationHub runtime execution architecture
• binding and policy location (centralized in Runtime)
• scope routing implementation
• internal adapter invocation ownership (Runtime-owned)

Not in scope for this phase:

• final Tauri cutover/removal of legacy domain commands
• client-only cutover requirements
• removal of operational control-plane commands

---

6. Testing Considerations (Required)

How will this enhancement be tested?

• Unit tests:
  • Wire -> Domain binding by scope
  • descriptor/lifecycle enforcement behavior
  • error mapping determinism
• Integration tests:
  • representative command flows through Runtime::dispatch
  • parity checks against legacy path for overlapping commands
• Negative tests:
  • invalid tx binding/cross-transaction reference failures
  • mutation denied in invalid lifecycle states
  • commit guard violations

Legacy suite should remain green while new-path tests are added.

---

7. Definition of Done (Required)

When is this enhancement complete?

• Runtime::dispatch(MapRequestWire) -> MapResponseWire exists and is functional
• Runtime owns Wire->Domain binding for new path
• Scope-specific domain dispatchers operate on domain types only
• Descriptor/lifecycle enforcement is centralized in Runtime
• New domain path does not rely on ingress receptor selection
• Legacy path remains operational for interim parity
• New-path routing/binding/policy/error tests pass
• Parity tests for overlapping commands are in place

---

Optional Details (Expand if needed)

8. Alternatives Considered

• Keep distributed enforcement across ingress handlers and adapters
  Rejected: hard to audit, easy to regress.
• Immediate cutover/removal in same phase
  Rejected: higher migration risk; deferred to Phase 2.3.

9. Risks or Concerns

• Dual-path behavioral drift during interim
• Temporary complexity from compatibility adapters
• Incomplete descriptor coverage causing routing/policy gaps

10. Additional Context

This phase implements architecture correctness without forcing immediate endpoint cutover. It sets up Phase 2.3 to be a controlled switch + cleanup step.