把 MCP 工程，做到真实路径上。
源码已经改好。运行的却还是旧版本。
src/server.ts
处理逻辑已更新为版本 B
dist/server.js
仍然包含版本 A
node dist/server.js
仍然返回修改前的结果
调用方根本没有进入改过的源码。 先追踪它实际选择的入口，再决定是否继续修改处理逻辑。
使用修复工作流这次，
你要交付什么？
同一个入口，根据任务选择所需深度。选一项工作，把对应的起始提示词带进编码智能体。
让调用方真正用上这个能力。
把目标能力做成可运行的 MCP 实现，在真正拥有该行为的层次放置控制。
使用 $mcp-boundary 构建我需要的 MCP 能力。先明确调用方、入口、传输方式与协议版本，再沿实际使用路径完成实现，把控制放在拥有该行为的层次，并验证目标行为。工作深度与任务规模匹配。
修到真正运行的那条路径上。
沿出错调用追踪实际选中的入口，修复拥有该行为的层次，再对齐构建产物与运行进程。
使用 $mcp-boundary 修复这个 MCP 集成。追踪实际调用方、入口、传输、处理逻辑、安装产物与运行进程；在这条路径上完成修复，运行能够否定原始故障的最小有效检查，并说明还有什么没有验证。
迁移实现，也收好旧路径。
协议、SDK 或运行方式变更时，调用方与产物也需要迁移。先找到仍在使用的依赖，再明确退役被取代的行为。
使用 $mcp-boundary 将这个 MCP 实现迁移到选定版本。识别有证据支持的调用方与活跃入口，完成迁移，明确退役被取代的路径，并对齐源码、产物与运行进程。区分本地检查和具体宿主上的结果。
先看清行为究竟由谁负责。
不改仓库，先查看当前实现。区分协议要求、传输层控制、部署策略与宿主行为。
使用 $mcp-boundary 检查这个 MCP 实现，不要修改仓库。追踪实际调用方、入口、传输、协议与 SDK 分派、能力效果、安装产物及运行进程。定位控制归属，报告有证据支持的发现，并指出最小且有用的下一项检查。
在对应的边界，验证具体结论。
选择与结论对应的产物和观察者。本地渲染测试有它的价值，另一个宿主仍需要独立的实际观察。
使用 $mcp-boundary 验证这个 MCP 行为。明确待验证结论、具体产物、实际运行进程与合格观察者，在对应边界运行获授权的检查，区分源码、进程、产物和具体宿主上的观察。没有观察到的宿主结果，不能判为成功或失败。
小而明确的改动就保持小：读相关参考、完成修改、运行检查，到此为止。
安装一个技能。
需要时，继续深入。
在编码智能体里使用技能，读懂决策背后的工程方法，再去 Lab 复现具体边界上的行为。 v0.3.0 增加按日期标注的扩展与宿主 recipes、九个本地评估 fixture，并恢复 Lab 的打包与运行验证路线。
进入工程资料库把它带进你的
下一次 MCP 工作。
安装 MCP Boundary，重启 Codex，再描述这次要做的事。需要明确调用时，直接写上 $mcp-boundary。
从仓库安装
codex plugin marketplace add IndelibleVivi/mcp-boundary --ref v0.3.0 codex plugin add mcp-boundary@mcp-boundary
这些命令固定安装源码发布版 v0.3.0。只有需要跟随开发时才使用 --ref main。安装后重启 Codex；需要支持 Agent Plugin 的当前 Codex CLI。
到底会安装什么？
一个纯技能包，包含所需参考与资源。不启动服务器，不新增 App connector 或认证流程，也不发送分析数据或遥测。Guide 与可执行 Lab 留在仓库里，不随插件运行。
会不会把小改动变成大审计？
工作深度应当匹配任务。小的措辞修改或本地辅助能力不需要一整套复杂审计；技能明确要求在小而清楚的 MCP 任务上及时停止。
一项检查通过，意味着什么？
意味着在那次检查对应的边界上观察到了预期行为。源码、本地进程、构建产物、激活后的运行时和具体宿主上的观察仍各自成立。资料库提供方法与可运行检查的入口，这个官网本身不执行它们。