Post-PR440 Hardening: Complete Recovery Wiring and Receptor Runtime Finalization

[evomimic]

1. Summary (Required)

What is the enhancement?
Complete post-PR440 hardening for recovery/session integration and receptor runtime behavior so recovery is fully wired, command-triggered, and production-safe (no placeholder panic paths).

---

2. Problem Statement (Required)

Why is this needed?
PR 418/440 landed key scaffolding and refactors, but several runtime integration items were explicitly deferred to unblock merge sequencing. Those deferred items are currently spread across PR discussion context and are at risk of being lost after PR closure.

Without closing these gaps:

• recovery may remain partially wired (or silently disabled in some paths)
• command-driven snapshot/undo/redo behavior may be incomplete
• runtime edge behavior may remain transitional
• placeholder command panic paths may persist

This issue captures the deferred work as a single authoritative follow-up.

---

3. Dependencies (Required)

Does this depend on other issues or features?

• Depends on merged state of PR 418 and PR 440.
• Depends on current MAP Runtime / command-dispatch architecture being the authoritative execution boundary.
• Should be coordinated with any ongoing TS SDK command-path enablement work to ensure trigger wiring is aligned with actual ingress usage.

---

4. Proposed Solution (Required)

How would you solve it?

1. Recovery receptor/runtime wiring

• Ensure recovery receptor lookup returns the actual resolved receptor (no dropped result paths).
• Ensure runtime/session lifecycle consumes the recovery receptor path consistently.

2. Command-path trigger integration

• Wire snapshot persistence to command policy execution (snapshot_after) in runtime dispatch flow.
• Wire undo/redo command actions to recovery/session operations.
• Wire lifecycle cleanup (commit/rollback) to persisted recovery cleanup.

3. Local provider behavior finalization

• Define explicit behavior for enabled local providers without "recovery" feature:
  • either register a non-recovery local receptor path, or
  • fail fast with typed configuration error.

4. Remove placeholder panic path

• Replace root_space unimplemented!() with typed error behavior or real implementation.

5. Receptor runtime edge-hardening

• Finalize transitional factory/runtime edge behavior introduced during receptor restructuring.
• Ensure typed-error behavior at runtime boundaries (no avoidable panic paths).

---

5. Scope and Impact (Required)

What does this impact?
Impacts:

• Host runtime initialization and receptor resolution
• MAP command dispatch lifecycle behavior
• Recovery persistence/undo/redo user experience
• Local provider configuration semantics
• Runtime stability and operational safety

Does not directly impact:

• New feature surface area in TS UI (except where command behavior becomes fully available)
• Underlying persistence vendor choice (SQLite remains current backend unless separately changed)

---

6. Testing Considerations (Required)

How will this enhancement be tested?

• Can it be validated with existing test cases?

  • Partially. Existing build/test/smoke coverage validates non-regression but not full recovery trigger semantics.

• Do new test cases need to be created?

  • Yes:
    • recovery receptor lookup and session wiring tests
    • snapshot_after trigger behavior tests
    • undo/redo command-path integration tests
    • commit/rollback cleanup tests for persisted recovery rows
    • non-recovery local provider behavior tests
    • root_space command no-panic behavior tests

• Are there specific areas in the test ecosystem impacted by this enhancement?

  • Host runtime unit tests
  • MAP command dispatch integration tests
  • Start-up smoke tests for both HC_DEV_MODE=1 and HC_DEV_MODE=0
  • Any end-to-end tests that exercise command ingress and lifecycle transitions

---

7. Definition of Done (Required)

When is this enhancement complete?

• Recovery receptor lookup/runtime wiring is fully connected (no dropped-result paths).
• Runtime command flow executes snapshot persistence via policy hook (snapshot_after).
• Undo/redo command path is wired to recovery/session operations.
• Commit/rollback reliably triggers persisted recovery cleanup.
• Enabled local provider behavior is explicit and enforced for both recovery and non-recovery modes.
• root_space no longer uses unimplemented!() in invoke-exposed command path.
• Runtime/receptor transitional edge behavior is finalized with typed error handling.
• Targeted unit/integration tests added and passing.
• Existing build/test/start smoke flows remain green.

---

Optional Details (Expand if needed)

8. Alternatives Considered

What other solutions did you think about?

• Leave deferred items distributed across PR comments only.
  Rejected: poor discoverability and high risk of follow-up loss.
• Split each deferred item into separate micro-issues now.
  Deferred: can be done later; a single tracking issue is preferred first for coherence and accountability.

---

9. Risks or Concerns

What could go wrong?

• Behavioral drift between intended command policy semantics and actual runtime wiring.
• Regressions during receptor/factory edge-hardening.
• Hidden panic paths if typed-error cleanup is incomplete.
• Merge/conflict churn if done concurrently with other runtime refactors.

Mitigations:

• Sequence work through clear checklist items
• Add focused integration tests before finalization
• Keep changes scoped to deferred items in this issue

---

10. Additional Context

Any supporting material?
This issue tracks items explicitly deferred during review/merge of PR 418 and PR 440 to unblock PR convoy sequencing while preserving follow-through on integration hardening.

---