automation-audit-ops

name	automation-audit-ops
description	基于证据的自动化清单和重叠审计工作流，适用于 ECC。在修复任何内容之前，当用户想要了解哪些作业、钩子、连接器、MCP 服务器或封装程序是活跃的、损坏的、冗余的或缺失时使用。
origin	ECC

自动化审计运维 (Automation Audit Ops)

当用户询问哪些自动化正在运行、哪些作业已损坏、哪里存在重叠，或者当前哪些工具和连接器实际上正在执行有用的工作时，请使用此技能。

这是一个证据优先的审计操作员技能。任务是在重写任何内容之前，生成一份有证据支持的清单以及一组“保留/合并/删除/下一步修复”的建议。

技能栈

在相关时将这些 ECC 原生技能引入工作流：

• workspace-surface-audit：用于连接器、MCP、钩子和应用清单
• knowledge-ops：当审计需要将实时仓库事实与持久上下文协调时
• github-ops：当答案取决于 CI、定时工作流、问题 (Issues) 或 PR 自动化时
• ecc-tools-cost-audit：当实际问题是同级应用仓库中的 Webhook 扇出、排队作业或计费支出时
• research-ops：当需要将本地清单与当前平台支持或公共文档进行比较时
• verification-loop：用于证明修复后的状态，而不是依赖假设的恢复

何时使用

• 用户询问“我有多少自动化”、“什么是活跃的”、“什么是损坏的”或“哪里有重叠”
• 任务跨越 cron 作业、GitHub Actions、本地钩子、MCP 服务器、连接器、封装程序或应用集成
• 用户想知道哪些是从另一个代理系统迁移过来的，以及哪些仍需在 ECC 内部重建
• 工作区积累了多种执行相同操作的方法，用户希望建立一个规范路径

护栏

• 除非用户明确要求修复，否则从只读开始
• 区分以下状态：
  • 已配置 (Configured)
  • 已认证 (Authenticated)
  • 最近已验证 (Recently verified)
  • 陈旧或损坏 (Stale or broken)
  • 完全缺失 (Missing entirely)
• 不要仅仅因为某个技能或配置引用了某个工具就声称它是活跃的
• 在证据表存在之前，不要合并或删除重叠的界面

工作流

1. 盘点真实表面

在理论化之前读取当前的实时表面：

• 仓库钩子和本地钩子脚本
• GitHub Actions 和定时工作流
• MCP 配置和已启用的服务器
• 由连接器或应用支持的集成
• 封装脚本和仓库特定的自动化入口点

按表面分组：

• 本地运行时 (Local runtime)
• 仓库 CI / 自动化
• 连接的外部系统
• 消息 / 通知
• 计费 / 客户运营
• 研究 / 监控

2. 按实时状态对每个项目进行分类

对于盘点出的每个自动化，标记：

• 已配置
• 已认证
• 最近已验证
• 陈旧或损坏
• 缺失

然后分类问题类型：

• 活跃损坏
• 认证中断
• 陈旧状态
• 重叠或冗余
• 功能缺失

3. 追踪证明路径

用具体的来源支持每一个重要断言：

• 文件路径
• 工作流运行
• 钩子日志
• 配置条目
• 最近的命令输出
• 确切的故障签名

如果当前状态不明确，请直接说明，而不是假装审计已完成。

4. 以“保留/合并/删除/下一步修复”结束

对于每个重叠或可疑的表面，给出一个结论：

• 保留 (Keep)
• 合并 (Merge)
• 删除 (Cut)
• 下一步修复 (Fix next)

其价值在于将嘈杂的自动化压缩到一个规范的 ECC 路径中，而不是保留每一个历史路径。

输出格式

当前表面 (CURRENT SURFACE)
- 自动化项
- 来源
- 实时状态
- 证明

发现 (FINDINGS)
- 活跃损坏
- 重叠
- 陈旧状态
- 功能缺失

建议 (RECOMMENDATION)
- 保留
- 合并
- 删除
- 下一步修复

下一步 ECC 行动 (NEXT ECC MOVE)
- 要强化的确切技能 / 钩子 / 工作流 / 应用路径

陷阱

• 当可以读取实时清单时，不要凭记忆回答
• 不要将“出现在配置中”视为“正在工作”
• 在指明高信号的损坏路径之前，不要修复低价值的冗余
• 如果用户首先要求清单，不要将任务扩大到仓库重写

验证

• 重要断言引用了实时证明路径
• 每个盘点出的自动化都贴有清晰的实时状态标签
• 最终建议明确区分了保留 / 合并 / 删除 / 下一步修复