命令成功，不等于任务完成
假设有一项虚构任务：验证成员邀请页面。它可能需要读源码、启动预览、使用测试账号、查看浏览器并报告结果。终端退出码只能回答其中的一小部分。
Onevium 把对话和工具活动放在桌面工作区中。有用的原则不是让所有任务都自动执行，而是让操作者能看清请求、所选工具和完成证据之间的关系。
把四类上下文放在一起
运行命令前确认项目与代码版本，浏览器操作前明确预览地址，写清哪些动作需要审批，最后定义接收者需要的产物：复现说明、经过测试的改动，还是一份简短报告。
本地优先描述的是工作区状态的存放方式，不代表连接的模型、网站和外部工具不会收到数据。需要检查已配置的服务商与连接器，只发送任务真正需要的信息。
- 项目上下文：目录、分支、相关文件，以及需要保留的已有工作。
- 执行上下文：实际命令、进程、预览地址和就绪检查结果。
- 决定上下文：允许的范围和仍待确认的审批。
- 证据上下文：观察到的行为、测试结果和未确认事项。
把开发预览当作实际运行依赖
任务需要预览时，先检查是否已有合适的服务在运行。不能因为端口被占用就停止别人的进程。进程存在也不代表提供了正确应用，应先验证服务就绪和目标页面。
Onevium 的托管服务工作流可以让长期运行的开发服务更容易检查，但仍需核对服务记录对应什么。只在不再需要时停止自己拥有的服务，可见状态不能替代对预览的实际访问。
把完成线拆成独立关口
对于成员邀请示例，可以定义三个关口：要求的改动存在，预期行为经过测试，结果可以交给他人审查。除非任务明确包含部署，否则部署是另一个关口。这样，长任务中的“完成”就不会悄悄改变含义。
完成条件示例
验证所选演示项目的成员邀请页面。
保留无关工作，已有预览健康时直接复用。
检查正常流程、无效输入和窄屏布局。
返回改动文件、实际运行的测试和浏览器观察。
列出因缺少账号或服务而无法检查的部分。
本次不要提交代码、部署，也不要发送渠道消息。决定哪些内容值得保留
保留另一人能够核对的最小交接：相关路径、实际命令与结果、脱敏证据，以及仍待决定的事项。只有任务需要时才写入项目文档，不要把整段对话或无关终端输出复制进报告。
重复工作也需要同样的纪律。计划任务要有负责人、来源、完成条件和目的地；渠道机器人要有确定接收人和实测的投递路径。增加这些功能，应该是为了让实际工作更容易核对和控制。