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?
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.
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) -> MapIpcResponseThen 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:
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:
Rules:
4.2 Cut Over Domain Callers
Migrate TypeScript and host-side domain callers to use
dispatch_map_commandexclusively for MAP domain commands.4.3 Remove Legacy Domain Ingress Paths
After cutover gates are met:
map_requestdomain ingress route(s)4.4 Preserve Separate Operational Control Plane
Keep control-plane commands (status/readiness/health/diagnostics) separate from MAP domain ingress.
Normative rule:
4.5 Enforce Conformance Invariants in CI
Add/enable invariant tests/gates that assert:
5. Scope and Impact (Required)
What does this impact?
Does not change:
6. Testing Considerations (Required)
How will this enhancement be tested?
dispatch_map_commandrequest/response payloads7. Definition of Done (Required)
When is this enhancement complete?
dispatch_map_commanddispatch_map_commandOptional Details (Expand if needed)
8. Alternatives Considered
Rejected: preserves architectural drift and bypass risk.
Rejected: broadens IPC surface and weakens boundary discipline.
9. Risks or Concerns
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.