| name | terminal-ops |
| description | ECC 的证据先行仓库执行工作流。当用户想要运行命令、检查仓库、调试 CI 失败或推送狭窄修复并附上执行和验证的确切证明时使用。 |
| origin | ECC |
终端运维
当用户想要真实的仓库执行时使用:运行命令、检查 git 状态、调试 CI 或构建、做狭窄修复,并准确报告更改了什么和验证了什么。
此技能有意比通用编码指导更窄。它是一个证据先行终端执行的操作工作流。
技能栈
在相关时将这些 ECC 原生技能拉入工作流:
verification-loop 用于变更后的精确证明步骤
tdd-workflow 当正确的修复需要回归覆盖时
security-review 当涉及密钥、认证或外部输入时
github-ops 当任务依赖 CI 运行、PR 状态或发布状态时
knowledge-ops 当验证结果需要被捕获到持久的项目上下文中时
何时使用
- 用户说"修复"、"调试"、"运行这个"、"检查仓库"或"推送它"
- 任务依赖命令输出、git 状态、测试结果或经过验证的本地修复
- 答案必须区分本地已更改、本地已验证、已提交和已推送
护栏
- 先检查再编辑
- 如果用户只要求审计/审查,保持只读
- 优先使用仓库本地脚本和辅助工具,而非临时即兴的包装器
- 在验证命令重新运行之前不要声称已修复
- 除非分支实际上已移动到上游,否则不要声称已推送
工作流
1. 确定工作面
确认:
2. 先读取失败面
在更改任何内容之前:
- 检查错误
- 检查文件或测试
- 检查 git 状态
- 使用任何已提供的日志或上下文,而非盲目重新读取
3. 保持修复狭窄
一次解决一个主要故障:
- 先使用最小的有用验证命令
- 仅在本地故障解决后才升级到更大的构建/测试通过
- 如果命令以相同特征持续失败,停止广泛重试并缩小范围
4. 报告确切的执行状态
使用精确的状态词:
- 已检查
- 本地已更改
- 本地已验证
- 已提交
- 已推送
- 已阻塞
输出格式
工作面
- 仓库
- 分支
- 请求模式
证据
- 失败的命令 / 差异 / 测试
行动
- 更改了什么
状态
- 已检查 / 本地已更改 / 本地已验证 / 已提交 / 已推送 / 已阻塞
注意事项
- 当可以读取实时仓库状态时不要从过时的记忆中工作
- 不要将狭窄的修复扩大为全仓库范围的变动
- 不要使用破坏性的 git 命令
- 不要忽略不相关的本地工作
验证
- 响应中命名了验证命令或测试
- git 相关的工作命名了仓库路径和分支
- 任何推送声明包括目标分支和确切结果