Attempt 9

Back to durable goal · Attempt history

Trigger

The user rejected the growing HMR race-handling layer and explicitly requested the simplest robust way for an MCP server to load DeepSeek/Cordis plugins. The published parent is bc4e5ae97ef9ea968c01b1b2a55403ae032a6a8d. An unpublished polling experiment is rejected rather than promoted.

Hypothesis

Atomic persistence plus the official Cordis Include and HMR services is the smallest reliable boundary. If MCP source mutations stop claiming synchronous activation or transactional on-disk rollback, the runtime can delete its source-marker protocol and every dependency on Loader internals while still loading, invoking, and eventually hot-reloading normal Cordis plugins without restarting the MCP connection.

Frozen plan

  1. Keep standard cordis.yaml, ordinary plugins/*.mjs, and the two project and out/mcp_cordis scopes.
  2. Keep the fixed MCP list/invoke gateway and the existing package context API.
  3. Validate module syntax before an MCP write and use atomic file replacement.
  4. For an existing running module, return after persistence with persisted: true, sourceChanged: true, and activation: "pending"; official Cordis HMR owns eventual activation. Do not claim that every evaluation or apply() failure restores the prior live entry.
  5. Keep public Include refresh for entry-list changes, because it is the official transactional API for starting, stopping, adding, and removing entries.
  6. Delete injected source markers, HMR acknowledgement waiters, polling, Loader loadCache inspection, and MCP-owned source rollback.
  7. Update documentation and tests so success means persisted/configured, while live update is verified by bounded eventual observation.
  8. Retain and validate the two pending repo_context review corrections for ordered context events and empty-line endpoints.
  9. Register the server in the trusted workspace’s .codex/config.toml. Use a worktree-resolving launcher and Bazel’s run --script_path handoff so the long-lived MCP does not retain the Bazel output-base lock.
  10. Rebase onto d29f9d471ea467e8dfc75db4eedeedbbae43dc2d, preserve its projects/goal redesign, and discard the superseded in-place goal-skill edits rather than replaying them.

Planned review packet

  • Focused runtime, stdio, and repo_context tests.
  • Complete //projects/mcp_cordis:all tests and build.
  • repo-delivery skill tests and root Buildifier.
  • Fresh diff-focused scrutiny of update failure, disabled-entry, promotion, restart, shutdown, and watcher timing paths.
  • Independent review and exact PR 32 thread reconciliation before delivery.

Current verdict

Refine. Removing wrapper-side acknowledgement machinery was correct, but an independent reproduction proved that unmodified HMR 1.0.16 can lose a source change arriving during an in-flight reload. Attempt 10 keeps the thin wrapper and moves serialization into a focused, reproducibly pinned dependency patch. The separate delivery-adapter refusal still prevents the history rewrite.