OpenClaw OA Operator

使用此 skill 作为 OpenClaw 的可观测性（Observability）与自愈（self-heal）层来操作 OA。重点关注稳定的工作流，清晰解释数据含义，并将面向公众发布的打包逻辑与机器特定的本地配置严格分离。

快速入门

• 检查工作区中是否存在 config.yaml、self_heal_rules.yaml、scripts/、patches/、pipelines/，以及任意仪表板覆盖目录（如 dashboard-zh/）。
• 明确用户需求属于本地运维、仪表板优化，还是可发布打包。一旦用户选定偏好布局，未经明确批准不得更改 UI 结构。
• 优先选择最简且稳定的路径：除非工作区已包含合理依据的覆写项，否则应沿用上游 OA 行为。
• 每次完成有意义的变更后，执行最小但有效的验证：API 健康检查、脚本冒烟测试（smoke check）或仪表板截图。
• 当 OA 已完成配置时，可运行 scripts/oa_workspace_smoke_test.sh 进行最小化的端到端工作区检查。

本地操作 OA

1. 确认当前 OA 的作用面（surface）。 若工作区中已存在相关脚本，优先使用，尤其是封装类脚本，例如 scripts/start_oa_server.sh、scripts/stop_oa_server.sh 和 scripts/manage_oa_launchd.sh。
2. 在编辑 UI 前，先验证运行时状态。 确保 oa collect 能成功采集数据，且 oa serve 已暴露预期端点，再开始排查仪表板问题。
3. 将配置文件视为策略声明。 通过 config.yaml 理解目标（goals）、阈值（thresholds）、OpenClaw 路径及 agent 范围；修改自愈行为前，务必先阅读 self_heal_rules.yaml。
4. 保持验证具体可测。 验证 /api/health、/api/goals、/api/team-health、/api/traces，以及当前仪表板所依赖的全部自愈相关端点。

解读指标与自愈状态

• 优先解释 G1 和 G2，因其通常是稳定性最高的内置目标：分别是定时任务（cron）可靠性与团队健康度（team health）。
• 仅在确认其对应 pipeline 及指标数据源已在工作区中存在后，再解释自定义目标（custom goals）。
• 清晰区分以下四类问题：
  • 信号质量（signal quality）问题
  • Pipeline 执行失败
  • 仪表板渲染问题
  • 自愈策略违规（self-heal policy breaches）
• 开展自愈工作时，须维持闭环流程：
  • 检测（detect）
  • 修复（fix）
  • 验证（verify）
  • 学习（learn）
• 执行命令模式（command-mode）修复器前，须审阅具体命令模板、占位符（placeholders）及目标路径。优先选用非破坏性修复器，并在可用时保持后备工单（fallback ticketing）机制启用。

安全优化仪表板

• 一旦用户确认某版本布局更清晰，即应固定该布局。优化应优先聚焦于文案（copy）、信息密度（density）和数据映射（data mapping），而非结构变动。
• 当用户重视清晰性与对原始仓库的一致性对比时，优先采用上游 OA 默认布局。
• 仅在确有本地化（localization）、新增标签页（extra tabs）或增强诊断能力等明确需求时，才使用项目级（project-level）覆盖。
• 完成 UI 修改后，须使用真实截图分别验证桌面端与移动端视图，不可假设布局适配有效。

为 ClawHub 打包

• 若核心价值在于工作流知识（如：安装 OA、操作 OA、解读指标、指导自愈决策），则优先打包为 skill。
• 若核心价值在于长期运行的服务、HTTP 路由、后台 worker 或产品化仪表板体验，则优先打包为 plugin。
• 面向公开发布前，须移除所有机器特定的默认配置：
  • 绝对路径
  • 本地端口与 launchd 标签
  • 本地 agent 名单（rosters）
  • 用户专属工单目录
  • 本地备份与产物（artifact）路径
• 打包内容应包含可复用的操作说明、核对清单（checklists）与安全默认值。禁止将私有工作区快照作为公开示例打包。
• 准备公开发布前，请通读 references/release-readiness.md。
• 声明打包成果已达到可发布状态前，请通读 references/smoke-test.md。

交付物

• 针对本地运维任务，需报告：  • 发生了哪些变更；  • 如何完成验证；  • 当前仍存在的风险点。
• 针对发布准备工作，需产出：
  • 公有内容与私有内容的差异对比（public versus private diff）
  • 可发布性核对清单（publish-readiness checklist）
  • 拟提交的上架文案（proposed listing copy）
  • skill 或 plugin 的选型建议