终端运维操作 是做什么的？
当用户需要真实的仓库执行操作时使用：运行命令、检查Git状态、调试CI或构建、实施精确修复，并精确报告哪些内容已更改和哪些内容已验证。
本技能刻意比通用编码指导更为狭窄。它是一套面向证据优先终端执行的操作工作流。
技能栈
在相关场景下，将以下ECC原生技能引入工作流：
verification-loop用于变更后的精确验证步骤tdd-workflow当修复需要回归覆盖时security-review当涉及密钥、认证或外部输入时github-ops当任务依赖于CI运行、PR状态或发布状态时knowledge-ops当需要将验证的结果捕获到持久的项目上下文中时
使用时机
- 用户说“修复”、“调试”、“运行这个”、“检查仓库”或“推送它”
- 任务依赖于命令输出、Git状态、测试结果或经过验证的本地修复
- 答案必须区分“本地已更改”、“本地已验证”、“已提交”和“已推送”
护栏
- 先检查再编辑
- 如果用户仅要求审计/审查，则保持只读
- 优先使用仓库本地脚本和辅助工具，而非临时拼凑的包装器
- 在验证命令重新运行之前，不得声称已修复
- 除非分支实际已推送到上游，否则不得声称已推送
工作流
1. 解析工作表面
确定：
- 精确的仓库路径
- 分支
- 本地差异状态
- 请求的模式：
- 检查
- 修复
- 验证
- 推送
2. 先读取失败表面
在更改任何内容之前：
- 检查错误
- 检查文件或测试
- 检查Git状态
- 优先使用已提供的日志或上下文，避免盲目重新读取
3. 保持修复范围狭窄
一次解决一个主要失败：
- 首先使用最小且有效的验证命令
- 仅当本地失败得到解决后，才升级到更大的构建/测试流程
- 如果某个命令持续以相同特征失败，则停止广泛重试并缩小范围
4. 报告精确的执行状态
使用精确的状态词汇：
- 已检查
- 本地已更改
- 本地已验证
- 已提交
- 已推送
- 已阻塞
输出格式
工作表面
- 仓库
- 分支
- 请求的模式
证据
- 失败的命令 / 差异 / 测试
操作
- 更改的内容
状态
- 已检查 / 本地已更改 / 本地已验证 / 已提交 / 已推送 / 已阻塞
陷阱
- 当可以读取实时仓库状态时，不要依赖过时的记忆
- 不要将狭窄的修复扩大到仓库范围的更迭
- 不要使用破坏性的Git命令
- 不要忽略无关的本地工作
验证
- 响应中应指明验证命令或测试
- 与Git相关的工作应指明仓库路径和分支
- 任何声称推送的内容必须包含目标分支和确切结果