Categories:

Attempt 7

Back to durable goal · Attempt history

Why Attempt 6 was rejected

The user correctly identified that each package’s manifest.json, content-addressed versions/ directory, and active/latest pointers were a custom package manager rather than an MCP or Cordis standard. That mechanism made reusable source look temporary, duplicated Cordis loader responsibilities, and drove much of the worker-generation complexity. Green tests cannot justify shipping the wrong extension model.

Decision review

Verdict: revise and proceed. The published DeepSeek Cordis packages provide the missing standard mechanisms directly:

  • @deepseek-ai/cordis-plugin-loader owns runtime entries and lifecycle;
  • @deepseek-ai/cordis-plugin-include persists entries in cordis.yaml and transactionally refreshes them with rollback; and
  • @deepseek-ai/cordis-plugin-hmr watches normal modules, imports changed code before replacement, and restores the prior runtime when reload fails.

The strongest objection is that HMR is event-driven and failed source reloads are logged rather than returned to the file writer. MCP-driven updates must therefore retain prior bytes, wait for a correlated reload result, and restore the prior source on failure or timeout. Manual external edits retain Cordis HMR’s normal behavior and diagnostics.

Frozen plan

  1. Pin the exact released Loader, Include, HMR, Timer, and required peer dependencies through the project-owned npm lock.
  2. Replace package manifests and hash-named versions with normal ESM modules: reusable modules under projects/mcp_cordis/plugins/, disposable modules under out/mcp_cordis/plugins/.
  3. Make projects/mcp_cordis/cordis.yaml and out/mcp_cordis/cordis.yaml the authoritative standard entry lists.
  4. Mount the official Cordis Loader, two Include trees, Timer, and HMR in the stdio server. Keep the stable MCP gateway, workspace helpers, bounded process execution, and tool-registration effects as host services.
  5. Implement MCP define, update, start, stop, remove, and promotion as atomic source/config changes followed by Cordis lifecycle acknowledgement and rollback. Use Git for reusable history; do not create a second version database.
  6. Replace version-store tests with standard-config, restart, HMR rollback, manual-edit reload, and project/scratch promotion tests.
  7. Run the complete affected test/build/Buildifier packet, obtain a fresh independent review of the standard design, then rebase and deliver PR 32.

Boundaries

  • Do not add an MCP Registry server.json unless the server is actually being prepared for registry publication; it describes the whole server, not its internal Cordis entries.
  • Do not retain committed hash-named source snapshots or custom package manifests.
  • Keep reusable source and config in the project and all disposable modules, atomic-write scratch, state, and logs under out/mcp_cordis.
  • Keep one normal module per package and one stable entry id per scope.
  • Preserve PR 24’s scoped projects/agents import and the accepted process execution corrections that remain relevant to the in-process host.

Acceptance status

Implementation and working-tree validation are complete; exact post-rebase delivery gates remain open. The final architecture adds four narrow host guards around the official Cordis services: synchronous activation admission to prevent a never-settling apply(), source-token HMR correlation, a private stdio protocol stream, and Fiber/invocation-owned Linux process supervision. The real stdio regression covers define, inspect, run, invoke, update, failed update rollback, stop, remove, logging isolation, and restart recovery.

Bazel invocation 39711671-375a-413f-8a72-e6f9ff892bd3 passes all 11 affected tests on the rebased implementation after the import-boundary review corrections, including Buildifier and all three imported skill configurations. Invocation 153467fd-e62d-4eab-b260-6754d17fe8e2 builds all 26 affected targets. Those receipts bind implementation commit 0a93e487; the following amendments change only this durable goal record, with proportional diff and format validation required before publication. Fresh independent review accepted durable-record commit c05bd45a with no actionable findings. PR 32 was republished at the verified rebased head, its obsolete description was replaced, and all three prior review threads were resolved.