Skip to content

MAP Commands -- Phase 3 — Expose a single Tauri command surface #406

@evomimic

Description

@evomimic

MAP Commands — Phase 3 — Expose and Cut Over to a Single Tauri Domain Command Surface

1. Summary (Required)

What is the enhancement?
Expose and finalize exactly one Tauri IPC ingress for MAP domain execution:

  • dispatch_map_command(request: MapIpcRequest) -> MapIpcResponse

Then cut over clients/tests to this path and remove legacy MAP domain ingress routes.

Operational control-plane commands (e.g., readiness/health) remain separate and out of MAP domain scope.


2. Problem Statement (Required)

Why is this needed?
After Phase 2.2, the Runtime domain boundary exists but legacy ingress paths still allow drift and bypass risk.

We need one stable domain pipe so that:

  • all MAP domain execution flows through Runtime policy/binding
  • no alternate domain ingress exists
  • telemetry/debugging/auditing are centralized
  • IPC contract is predictable for TS SDK and future integrations

At the same time, status/ops commands should remain available as a distinct control-plane surface.


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.


4. Proposed Solution (Required)

How would you solve it?

4.1 Expose Single Domain Tauri Command

Implement/retain one domain ingress command:

#[tauri::command]
async fn dispatch_map_command(
    state: State<'_, Runtime>,
    request: MapIpcRequest,
) -> Result<MapIpcResponse, HolonError> {
    state.dispatch(request).await
}

Rules:

  • This is the only Tauri entrypoint for MAP domain execution.
  • It accepts wire types only.
  • It delegates immediately to Runtime.
  • It performs no domain binding/policy/routing itself.

4.2 Cut Over Domain Callers

Migrate TypeScript and host-side domain callers to use dispatch_map_command exclusively for MAP domain commands.

  • remove legacy command usage for domain operations
  • preserve behavior through parity-validated mapping

4.3 Remove Legacy Domain Ingress Paths

After cutover gates are met:

  • remove legacy map_request domain ingress route(s)
  • remove temporary compatibility adapters introduced during parallel migration
  • remove leftover string-authority dispatch plumbing from ingress surfaces

4.4 Preserve Separate Operational Control Plane

Keep control-plane commands (status/readiness/health/diagnostics) separate from MAP domain ingress.

Normative rule:

  • operational endpoints must not perform MAP domain execution except via Runtime domain dispatch path

4.5 Enforce Conformance Invariants in CI

Add/enable invariant tests/gates that assert:

  • single Tauri domain ingress exists
  • all domain execution goes through Runtime dispatcher
  • no wire leakage below binding seam
  • no ingress receptor selection for domain routing
  • ops endpoints do not bypass domain boundary

5. Scope and Impact (Required)

What does this impact?

  • Conductora Tauri command surface for MAP domain execution
  • TS integration surface (single domain invoke path)
  • removal of legacy MAP domain ingress and adapters
  • stabilization of long-term command architecture

Does not change:

  • core transaction semantics
  • domain behavior semantics
  • operational control-plane concept (kept separate)

6. Testing Considerations (Required)

How will this enhancement be tested?

  • IPC shape tests for dispatch_map_command request/response payloads
  • smoke/integration tests covering representative command families through single ingress
  • regression tests with legacy domain ingress disabled/removed
  • invariant tests:
    • no alternate MAP domain ingress
    • no domain bypass from ops endpoints
  • full suite pass post-cutover

7. Definition of Done (Required)

When is this enhancement complete?

  • Exactly one Tauri MAP domain command exists: dispatch_map_command
  • All MAP domain callers use dispatch_map_command
  • Legacy MAP domain ingress paths are removed
  • Temporary compatibility adapters are removed
  • Ops/status commands remain available as separate control plane
  • Conformance invariant tests are active and passing
  • Full test suite passes with legacy domain ingress removed

Optional Details (Expand if needed)

8. Alternatives Considered

  • Keep legacy domain ingress as permanent fallback
    Rejected: preserves architectural drift and bypass risk.
  • Multi-command Tauri domain surface mirroring internal APIs
    Rejected: broadens IPC surface and weakens boundary discipline.

9. Risks or Concerns

  • Hidden dependencies on legacy request shapes during cutover
  • Late parity gaps
  • CI instability if invariants are not explicit

Mitigation: parity gates from Phase 2.2 and staged rollout before final removal.

10. Additional Context

This is the final cutover/cleanup phase that converts the parallel architecture into the canonical architecture.

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