chore: 统一 DevOpsFlow 命名与工程环境语义

[TrueNine]

背景

本仓库最初主要是对 skills 的整理与总结，因此使用了 devflow-skills 这一名称。

当前仓库的实际边界已经明显扩大：除 skills 外，还包含 hooks、MCP、agent 等面向 Codex 的能力集合，并逐步形成了更完整、更流程化的 agent 规范与 harness（执行、编排和约束载体）。因此，原名称已经无法准确表达项目范围。

目前 GitHub 仓库、插件和包等主要外部标识已经使用 devopsflow；本 issue 用于明确该命名的推导依据，并继续收敛仓库内的范围说明与残留标识。

命名推导

命名判断分为两个概念阶段：

1. devflow-skills → devflow

   • 去除 skills 后缀，避免将项目错误限定为单一的 skills 集合。
   • 用 devflow 表达开发流程、agent 工作流及其配套能力的共同基础。

2. devflow → devopsflow

   • 项目已经不仅描述开发步骤，也开始对执行环境、工具接入、自动化约束、运行反馈和协作流程进行建模。
   • 相较于 devflow，devopsflow 更能表达这一整套工程环境。

这里的两步是命名语义的推导路径，不是要求仓库在 GitHub 上依次进行两次物理重命名；最终统一名称应为 devopsflow，展示名称应为 DevOpsFlow。

为什么是 DevOps

DevOps 虽然包含 Ops（Operations），但在现代工程语境中，它更多表示贯穿开发、验证、交付、运行和反馈的一整套工程文化与工程环境，而不只是传统意义上的运维工作。

采用 devopsflow：

• 没有削弱或移除 Dev 的范畴；
• 是将 Ops 所代表的环境、运行、反馈和自动化能力融入完整工作流；
• 能覆盖 skills、hooks、MCP、agent、harness 及其协作规范；
• 比单纯的 devflow 更符合当前项目已经形成的能力边界。

TDD 与环境不可割裂

TDD 不应只被理解为单元测试驱动。许多实际验证活动都依赖工程环境提供支撑，例如：

• 集成测试；
• 属性测试；
• 灰度测试；
• 针对线上问题排查而直接编写的测试；
• 依赖服务、数据、工具链、观测和运行反馈的验证。

这些能力必须在 skills 和相关 agent 工作流中得到建模。它们与单元测试、功能性测试属于同一条连续验证链路，不应因为需要环境支持就被从 TDD 或开发工作流中割裂出去。这也是从 devflow 扩展为 devopsflow 的重要原因。

目标

• 将仓库的统一名称确定为 devopsflow，展示名称确定为 DevOpsFlow。
• 用统一表述说明项目是面向 Codex 的 skills、hooks、MCP、agent、harness 与流程规范集合。
• 在项目文档中记录 devflow-skills → devflow → devopsflow 的命名推导及 DevOps 现代语义。
• 检查仓库内仍使用旧名称的活跃配置、文档和示例，并按语义完成收敛。
• 允许在来源归属、历史说明和必要兼容场景中保留 devflow-skills，但不得让它继续充当当前项目名称。
• 在 TDD 和验证工作流说明中体现环境支撑的集成测试、属性测试、灰度测试与线上问题排查测试，避免将其与单元测试、功能性测试割裂。

验收标准

• GitHub 仓库、插件、包、marketplace、文档标题和面向用户的安装示例统一使用 devopsflow / DevOpsFlow。
• 项目简介不再将仓库描述为单纯的 skills 汇总。
• 文档明确说明 skills、hooks、MCP、agent、harness 等能力边界。
• 文档明确说明 DevOps 在本项目中表示整套现代工程环境，并未损失 Dev 的范畴。
• 文档记录 devflow-skills → devflow → devopsflow 的命名推导路径。
• TDD/验证相关说明覆盖依赖环境的集成测试、属性测试、灰度测试和线上问题排查测试，并说明其与单元测试、功能性测试不可割裂。
• 仓库中仅在来源归属、历史记录或明确兼容用途下保留旧名称。

非目标

• 不将 Ops 狭义化为单独的运维模块。
• 不因为采用 devopsflow 而降低开发、编码、单元测试或功能性测试的重要性。
• 不要求先把当前仓库物理重命名回 devflow，再重命名为 devopsflow。