研究和运营常见的混乱，不是目录里没有资料，而是资料太多却不知道哪一项支持当前结论。以下两个脱敏案例展示启明怎样处理来源、故障接力，以及启明自身暴露出来的缺点。
原来乱在哪里
一个硬件研究项目有许多下载入口：论坛转述、相似文件名、镜像站和压缩包中的通用工具。目录里真的有程序，不代表它能解决目标设备的问题。若把“找到线索”写成“找到可执行方案”，下一位研究者可能跳过关键核查。
一个网络服务运营项目涉及多台服务和网络设备。故障发生时，不止一位 Agent 接手。档案写着“当时可用”，几个小时后现场可能变了；排障记录若散在聊天和临时 Markdown 中，新接手者也难判断哪份是当前事实。
启明做了什么
硬件研究先把问题写成任务，再将每份候选资料的取得状态区分为“已下载”“需要登录或积分”“404”“流量限制”“仅找到入口”。取得的原件保存 SHA-256，短入口指向当前任务、原件与汇总。报告分别写通用组件支持什么、目标设备还缺什么证据。
网络故障中，GLM-5.3 在 OpenCode 的一份现场报告指出：项目启动摘要、设备档案和凭据引用帮助它理解前任的操作限制；账户卡只存安全存储的引用，排障记录不用抄明文秘密。同时报告也指出旧 plan → apply 写入流程在紧急情况下太重，Agent 绕过工具直接写了两份 Markdown。启明因此增加向已有工作记录追加事件的短命令，同时保留内部事务和冲突检查。
留下了什么
研究项目留下来源状态表、已取得资料的哈希、当前可支持的结论和下一步要追的缺口。一个否定结论同样值得保存：发现通用接口和运行时方法，但尚未验证目标设备的完整永久写入路径。
网络项目留下项目入口、设备与服务关系、凭据引用、故障接力线索，以及对启明写入体验的产品反馈。动态状态应带观察时间；后来接手的 Agent 先复核当前设备，再决定是否沿用旧状态。档案是有时间的快照，不是实时监控面板。
验证到哪里
硬件研究这轮只做离线核查，没有在目标设备上执行。文件名、通用 API 或下载成功都不能替代目标专用证据。下一步应补齐来源和设备上的验证条件，不能把尚未证明的步骤写成操作说明。
OpenCode 的有效接续来自单份现场报告，不代表所有 Agent 或所有故障环境都通过。追加事件命令有本地测试和公开安装验证；真实 OpenCode 故障会话的完整复测仍待做。遇到用户报告绕过管理入口，启明应该先改自己的流程，再用真实现场确认是否改善。