gavindiaz/vibe-coding-cn
1
0
Fork 0
mirror of https://github.com/tradecatlabs/vibe-coding-cn.git synced 2026-07-27 18:57:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: docs - remove workflow playbooks

Browse Source
This commit is contained in:
tukuaiai
2026-05-02 04:46:53 +08:00
parent 1532222f06
commit dc51eee45a
30 changed files with 6 additions and 2238 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/labeler.yml
-5
View File
@@ -33,8 +33,3 @@ prompt:
repos:
- changed-files:
- any-glob-to-any-file: 'tools/external/**'
# 工作流模板相关的标签
workflow:
- changed-files:
- any-glob-to-any-file: 'docs/playbooks/workflows/**'
AGENTS.md
-1
View File
@@ -96,7 +96,6 @@ git push origin develop
- `docs/` - 中文知识库（方法论/入门/实战/资源）
- `prompts/` - 提示词入口与云端索引
- `skills/` - 可复用技能库（每个子目录一个 Skill）
- `docs/playbooks/workflows/` - 可复用工作流模板（自动开发闭环等）
- `tools/config/` - 工具与开发配置（例如 Codex CLI）
- `tools/external/` - 外部工具与依赖（含 Git submodule）
CHANGELOG.md
+1
View File
@@ -16,3 +16,4 @@
- 清退 `docs/case-studies/` 实战案例目录，并同步更新 docs 索引、目录级 AGENTS、metadata、labeler 和相关 README 链接口径。
- 清退 `docs/playbooks/` 下 7 个工具型/旧方法论文档，并同步更新 playbooks 索引、README、学习地图与相关概念页链接。
- 清退 `docs/playbooks/REMOTE_TUNNEL_GUIDE.md`，继续收缩工具型旧文档。
- 清退 `docs/playbooks/workflows/` 工作流模板目录，并同步移除学习地图、AI FAQ、redirects、labeler 与 AGENTS 中的旧入口。
docs/getting-started/学习地图.md
+4 -28
View File
@@ -1,6 +1,6 @@
# Vibe Coding 学习地图
> 用一张地图把 `vibe-coding-cn` 的学习路线串起来：先从零开始跑通，再按目标进入 Prompt、Skill、Workflow、工程质量和 GEO/SEO 路线。
> 用一张地图把 `vibe-coding-cn` 的学习路线串起来：先从零开始跑通，再按目标进入 Prompt、Skill、工程质量和 GEO/SEO 路线。
## 核心摘要
@@ -17,7 +17,6 @@
| 开发者路线 | 已会写代码 | 建立 AI 结对编程工作流 | [Vibe Coding 经验](Vibe%20Coding%20经验.md) |
| Prompt 路线 | 想提升提问质量 | 把需求表达成可执行指令 | [提示词库](../../../prompts/README.md) |
| Skill 路线 | 想沉淀复用能力 | 把高频任务做成可重复调用的技能 | [Skills 技能大全](../../../skills/README.md) |
| Workflow 路线 | 想推进复杂项目 | 把开发过程拆成可跟踪、可复盘的流程 | [工作流模板](../playbooks/workflows/README.md) |
| 质量门禁路线 | 担心 AI 乱写代码 | 用测试、CI、schema、清单约束 AI 输出 | [强前置条件约束](../references/强前置条件约束.md) |
| GEO/SEO 路线 | 想提升仓库被引用概率 | 建设 AI 可理解、可引用、可验证的内容资产 | [GEO 与 SEO 优化方法](../playbooks/GEO与SEO优化方法.md) |
@@ -96,29 +95,7 @@
- [ ] 复杂能力有 references、scripts 或 assets 支撑
- [ ] Skill 不只是长提示词，而是可执行工作流
## 路线五：Workflow 路线
目标：把复杂项目推进变成可跟踪、可复盘、可交接的流程。
1. [工作流模板](../playbooks/workflows/README.md)
2. [自动开发闭环](../playbooks/workflows/auto-dev-loop/README.md)
3. [通用项目架构模板](../references/通用项目架构模板.md)
4. [审查代码](../references/审查代码.md)
推荐流程：
```text
需求澄清
-> PRD
-> 技术方案
-> 任务拆解
-> AI 编码会话
-> 测试 / 审查 / 修复
-> Git 提交
-> 复盘沉淀
```
## 路线六：团队路线
## 路线五：团队路线
目标：让多个人和多个 AI Agent 使用同一套上下文和门禁。
@@ -135,7 +112,7 @@
- 任何目录、命令、配置、工作流变化都要同步文档
- 任何自研偏离拼好码原则都要说明理由、风险和回滚路径
## 路线七：GEO/SEO 路线
## 路线六：GEO/SEO 路线
目标：让项目更容易被搜索引擎、AI 搜索和大语言模型理解、引用、推荐。
@@ -164,12 +141,11 @@
-> 拼好码
-> 强前置条件约束
-> Skills 技能大全
-> 工作流模板
-> GEO 与 SEO 优化方法
```
## 下一步
- 新手：回到 [入门指南](README.md)，从第 0 步开始。
- 开发者：阅读 [Vibe Coding 经验](Vibe%20Coding%20经验.md)，再选择 Skill 或 Workflow 路线。
- 开发者：阅读 [Vibe Coding 经验](Vibe%20Coding%20经验.md)，再选择 Skill 或质量门禁路线。
- 团队：先统一 [AGENTS.md](../../../../AGENTS.md)、强前置条件和质量门禁。
docs/playbooks/workflows/20260225-Markdown转EPUB-v1.0.md
-332
View File
@@ -1,332 +0,0 @@
---
title: "Markdown 转 EPUB（ebook-convert/Calibre）可复现执行文档"
asset_id: "ASSET-EPUB-MD2EPUB-20260225-3c7a9d1e"
version: "v1.0"
date: "2026-02-25"
maintainer: "<占位符>"
scope:
- "Windows 环境下单个 Markdown 转 EPUB"
- "以 Calibre ebook-convert 为核心的可复现转换流程（含证据与自检）"
non_scope:
- "复杂排版需求（大量公式/引用文献/高级 Markdown 扩展）"
- "DRM/受保护格式处理与分发合规审查"
min_input:
- "Markdown 文件路径（绝对路径或相对路径）"
- "书籍元数据（标题/作者/语言，可自动从 Markdown 头部提取）"
output_spec:
deliverable_type: "EPUB 文件（主交付物）+ 可追溯证据（版本/日志/报告）"
must_include:
- "输出 EPUB 文件路径（可直接打开验证）"
- "关键证据：工具版本、转换命令、转换日志/报告、自检结论"
quality_bar:
- "EPUB 可被 Calibre 或常见阅读器打开，且目录（NCX/NAV）存在"
- "转换无 ERROR，输出文件大小非空且显著大于 0（建议 > 10KB）"
change_log:
- ver: "v1.0"
date: "2026-02-25"
changes: "初始化"
tags:
- "calibre"
- "ebook-convert"
---
<!-- markdownlint-disable MD013 -->
## Markdown 转 EPUB（ebook-convert/Calibre）可复现执行文档
## 上下文背景（任务上下文源）
### 2.1 当前任务一句话背景
- 将 `C:\Users\lenovo\Downloads\逻辑 - 孟自黄.md` 转换为 EPUB，并完成工具选型与可复现构建（最终选用 Calibre `ebook-convert`）。
### 2.2 业务/项目背景要点（可选）
- 无/不适用
### 2.3 会话上下文源定义（默认信息源与优先级）
#### 2.3.1 信息源优先级（从高到低）
1. 会话内用户明确提供/确认的信息（含粘贴文本/附件/链接）
1. 会话内 AI 已执行得到的证据（命令输出/读到的文件片段）
1. 本地工作区文件与仓库（如存在）
1. 外部来源（仅限用户提供链接；若允许检索则必须记录链接与摘录为证据）
1. 必要时向用户提最少问题补齐
#### 2.3.2 工作目录/项目根定位规则（按需）
- 默认以会话提供的 `cwd` 作为工作目录；若输入为绝对路径，则以 Markdown 所在目录作为 `source-root`（用于解析本地资源）。
#### 2.3.3 关键文件/目录（README等）
- `C:\Users\lenovo\Downloads\逻辑 - 孟自黄.md`
- `C:\Users\lenovo\Downloads\逻辑 - 孟自黄.epub`
- `C:\Users\lenovo\Downloads\build_epub\report.json`
- 历史脚本：原 `markdown-to-epub` skill 已从本仓库清退；如需稳健构建脚本，需从历史提交恢复或以独立工具重新引入。
#### 2.3.4 Git 状态/变更/提交历史（按需）
- 不适用（本任务不依赖 Git；如在仓库内执行，提交/推送/合并属于高风险动作，必须先请求用户批准）
#### 2.3.5 日志/配置/脚本/依赖信息
- 工具：Calibre `ebook-convert`（证据：`ebook-convert --version` 输出 `calibre 8.16.2`）
- 运行时：Python（证据：`python --version` 输出 `Python 3.14.2`）
- 可选工具：Pandoc（证据：`pandoc --version` 在本会话环境中不可用/未安装）
- 构建脚本：原 `markdown-to-epub` skill 已从本仓库清退；当前可复现路径以 Calibre `ebook-convert` 为准。
#### 2.3.6 外部来源使用规则（按需）
- 默认仅用用户提供链接；本任务未使用外部链接检索
### 2.4 关键约束/假设（可选）
- 约束：尽量不改动源 Markdown；输出文件可覆盖需先征得用户同意
- 假设：输入 Markdown 为 UTF-8（本会话证据：用 `utf-8/utf-8-sig` 可正确解码，`gb18030/gbk/big5` 解码失败）
## 任务方法（可复现执行体：复制即让 AI 照着跑，必须可复现）
### A. 目标 & 成功标准
- 目标：将指定 Markdown 转为 EPUB（使用 `ebook-convert`），并落盘可追溯证据（版本/日志/报告/自检结论）
- 成功标准：
- [ ] 产出 EPUB 文件，路径明确且可打开
- [ ] EPUB 包含 OPF 且存在 NCX 或 NAV（目录可用）
- [ ] 元数据（标题/作者/语言）正确
- [ ] 关键内容结构不丢失（至少校验：章节标题与表格/段落）
### B. 复现总规则
- 少问用户、优先补齐；高风险先批准；每步记录证据；可回滚
### C. 复现主流程（Replay Workflow）
> 必须包含 Step1~Step6；每个 Step 严格按：输入→动作→证据→输出→自检→兜底
#### Step1 定位上下文
- 输入：
- Markdown 路径："<输入 Markdown 路径>"
- 工作目录（若给出）："<cwd 或占位符>"
- 动作（命令/读文件/搜索）：
- 在 PowerShell 中确认文件存在：
- `Test-Path -LiteralPath "<输入 Markdown 路径>"`
- 读取开头 60 行用于提取标题/作者（注意编码）：
- `Get-Content -LiteralPath "<输入 Markdown 路径>" -Encoding utf8 -TotalCount 60`
- 证据：
- 记录 `Test-Path` 结果（True/False）
- 记录前 60 行中是否存在 `# <标题>`、`**作者**：<作者>` 等可提取信息
- 输出：
- 输入文件绝对路径
- 可能的元数据候选：标题/作者/语言（若可从 Markdown 头部提取）
- 自检：
- 若 `Get-Content` 输出乱码，优先改用 `-Encoding utf8`；仍异常则进入 Step2 做编码确认
- 兜底：
- 若文件不存在：请求用户确认路径或提供文件
- 若路径含空格/特殊字符：所有命令统一使用 `-LiteralPath` 或对参数加双引号
#### Step2 自动补全
- 输入：
- Step1 的元数据候选（可能为空）
- 动作（命令/读文件/搜索）：
- 检查 `ebook-convert` 是否可用并记录版本：
- `ebook-convert --version`
- （可选）检查 `pandoc` 是否可用（仅用于信息收集，不作为主路径）：
- `pandoc --version`
- 如需确认编码（推荐仅在出现乱码/异常时做）：
- 运行 Python 尝试以 UTF-8 解码并打印前几行（示例）：
- `@' ... '@ | python - "<输入 Markdown 路径>"`
- 证据：
- `ebook-convert --version` 输出（例如：`ebook-convert.exe (calibre 8.16.2)`）
- `pandoc --version` 输出或失败信息（若失败也需记录）
- 编码确认输出（例如：`utf-8 -> # 逻辑 | **作者**：孟自黄 ...`）
- 输出：
- 最终采用的工具与路径：优先 `ebook-convert`（Calibre）
- 最终元数据：标题/作者/语言（无法自动提取则保留 `<占位符>` 待用户确认）
- 自检：
- 若 `ebook-convert` 不可用：进入 E.4（环境异常）
- 兜底：
- 若元数据无法自动提取：仅向用户提最少问题（标题/作者/语言）
#### Step3 计划
- 输入：
- 输入 Markdown 路径
- 输出 EPUB 目标路径（若未指定则默认与输入同目录/同名）
- 元数据（标题/作者/语言）
- 动作（命令/读文件/搜索）：
- 明确两条执行路径（按内容复杂度择一）：
- 路径 A（最小路径）：直接调用 `ebook-convert` 生成 EPUB
- 路径 B（稳健路径，仍以 `ebook-convert` 为核心）：使用构建脚本生成报告与可追溯证据（适合有本地图片/需要报告/需要更强可复跑性）
- 检查是否会覆盖文件/删除目录（不可逆需先批准）：
- 若输出 EPUB 已存在：必须先问用户是否覆盖
- 若要清理构建目录（例如 `build_epub`）：必须先问用户是否允许删除
- 证据：
- 记录用户对“覆盖/清理”的明确批准或拒绝
- 记录最终选择的执行路径（A 或 B）及理由（1 句话）
- 输出：
- 可执行命令（单条或两条）+ 预计输出路径
- 自检：
- 命令必须非交互式；路径包含空格时必须加引号
- 兜底：
- 若用户拒绝覆盖：改用新文件名（例如追加日期或版本号）
- 若用户拒绝清理：禁用清理参数，改为新建 build 目录（例如 `build_epub_<YYYYMMDDHHMM>`）
#### Step4 执行取证
- 输入：
- 最终确认的执行路径（A 或 B）
- 输出 EPUB 路径
- 元数据（标题/作者/语言）
- 动作（命令/读文件/搜索）：
- 路径 A（直接转换）示例：
- `ebook-convert "<输入 Markdown 路径>" "<输出 EPUB 路径>" --title "<标题>" --authors "<作者>" --language "<语言>"`
- 路径 B（稳健转换）：原 `markdown-to-epub` skill 已清退；如需该路径，先恢复或重新引入脚本，再记录脚本来源与验证命令。
- 注意：`--clean-build-dir` 会删除构建目录，属于不可逆动作；执行前必须有用户批准
- 证据：
- 记录完整命令行（含所有参数）
- 记录命令输出（stdout/stderr）与生成的日志/报告路径
- 本会话转换成功证据（示例摘要，供对照）：
```json
{
"output_epub": "C:\\Users\\lenovo\\Downloads\\逻辑 - 孟自黄.epub",
"build_dir": "C:\\Users\\lenovo\\Downloads\\build_epub",
"total_image_refs": 0,
"missing_images": [],
"epub": {
"file_size": 158236,
"has_opf": true,
"has_ncx_or_nav": true,
"ncx_nav_points": 58
}
}
```
- 输出：
- 生成的 EPUB 文件（路径）
- （若路径 B）构建目录与报告：`build_epub\report.json`、`build_epub\conversion.log`
- 自检：
- 校验输出文件存在且大小合理（建议 > 10KB）
- 兜底：
- 若转换失败：收集错误信息并进入 E.4
- 若提示编码相关问题：优先确保输入为 UTF-8 或在工具侧指定编码/改用稳健路径 B
#### Step5 自检验收
- 输入：
- 输出 EPUB 路径
- （若有）报告 JSON 路径
- 动作（命令/读文件/搜索）：
- 最小自检（结构完整性）：
- （路径 B 已自动生成）检查 `report.json` 中 `has_opf`、`has_ncx_or_nav`、`missing_images`
- 内容自检（抽样验证关键文本存在）示例：
- 用 Python 读取 EPUB（zip）并搜索标题/作者/关键句：
- 搜索 `"逻辑"`、`"孟自黄"` 是否在 HTML 中出现
- 表格自检（如 Markdown 含表格）：
- 搜索表格关键行是否被转换为 `<table>`（例如包含 `"妥善处理污水"` 的表格）
- 证据：
- 本会话自检证据（示例）：
- 在 EPUB 内找到标题与作者：`found in index_split_000.html`
- 表格存在：`has_table True`，`tr_count 6`
- 输出：
- 验收结论（通过/不通过）+ 不通过原因（若有）
- 自检：
- 若发现目录缺失、章节结构异常：回到 Step3 调整分章/目录策略（必要时改用稳健路径 B）
- 兜底：
- 若阅读器显示乱码：优先确认输入/转换链路全程 UTF-8，并检查语言参数（`--language "zh-CN"`）
#### Step6 交付落盘更新
- 输入：
- 最终通过验收的 EPUB 文件
- 证据材料（命令输出/日志/报告/自检结论）
- 动作（命令/读文件/搜索）：
- 交付文件落盘（若需归档目录，先确认目标路径存在）：
- 将 EPUB 与证据文件（`report.json`、`conversion.log`）复制到用户指定目录
- 更新本资产文档（如复跑后遇到新分支/新坑）：
- 版本号 `v1.0 -> v1.1`，并在 `change_log` 新增一条记录
- 证据：
- 记录最终交付路径清单（EPUB + 报告/日志）
- 记录校验结论（Step5 输出）
- 输出：
- 最终交付物路径列表
- 自检：
- 确保交付路径下文件齐全且可打开
- 兜底：
- 若用户不需要报告/日志：至少保留 `ebook-convert --version` 与最终命令行作为最小证据
### D. 固定步格式（强制约束）
- 每步必须且仅包含：输入 / 动作 / 证据 / 输出 / 自检 / 兜底
### E. 必要分支
#### E.1 信息不足
- 触发条件：
- 无法从 Markdown 头部可靠提取标题/作者/语言，或用户未提供输出路径与覆盖策略
- 最小问题集（最多 3 个）：
1. 输出 EPUB 文件名/路径是否固定？若已存在是否允许覆盖？
1. 书籍元数据：标题、作者（语言默认 `zh-CN` 是否接受）？
1. 是否需要生成/保留证据（report/log）用于复跑与追溯？
- 默认策略（用户不回时）：
- 不覆盖任何既有文件；输出文件名追加日期；语言默认 `zh-CN`；保留最小证据（版本+命令行）
#### E.2 信息冲突
- 触发条件：
- 标题/作者在文件头部与用户口述不一致；或同名输出文件存在但覆盖策略不明确
- 冲突点清单：
- "<占位符>"
- 推荐决策与理由：
- 以“用户明确确认”的元数据为准；若未确认，以 Markdown 文件头部为准（并在交付中标注来源）
- 需要用户批准的选项：
- 覆盖现有输出文件
- 删除/清理构建目录（如 `--clean-build-dir`）
#### E.3 时间紧（先交付 MVP）
- 触发条件：
- 用户只要尽快拿到可读 EPUB，不要求详尽证据或复杂校验
- MVP 交付定义：
- 直接 `ebook-convert` 生成 EPUB；仅做“能打开 + 目录存在 + 标题/作者正确”的最小自检
- 后续迭代清单：
- 增加报告落盘（report/log）
- 增加内容抽样自检（关键章节/表格/脚注）
- 增加图片资产归一化（若后续出现本地图片）
#### E.4 命令失败/环境异常
- 触发条件：
- `ebook-convert` 不存在/不可执行；转换报错；输出 EPUB 不生成或损坏
- 诊断步骤：
1. `ebook-convert --version` 是否可用
1. 记录完整错误输出（stderr）
1. 检查输入文件编码与路径（空格/中文/权限）
1. 若为资源问题（图片缺失）：改用稳健路径 B 并查看 `missing_images`
- 回退/替代方案：
- 安装/修复 Calibre 后重试
- 不清理构建目录，换新 build 目录与新输出名避免破坏现有文件
- 需要用户提供的信息（最少）：
- 错误输出全文
- 输入 Markdown 路径与（若有）相关资源文件目录结构截图/列表
### F. 交付模板（最终输出格式/命名/落盘路径）
- 命名规则：`YYYYMMDD-Markdown转EPUB-<版本>.md`
- 落盘路径：`<项目根>/docs/Markdown转EPUB/`
- 交付物模板：
- 交付文件：
- "<输出 EPUB 路径>"
- 证据索引：
- EVID-001 工具版本：`ebook-convert --version` 输出
- EVID-002 转换命令：最终命令行全文
- EVID-003 转换日志/报告（如有）：`conversion.log`、`report.json`
- EVID-004 自检结论：目录存在/元数据命中/关键内容抽样命中
### G. 更新规则（用完写回：版本 + 0.1）
- 每次复跑后将新坑/新分支写回 D/E/F，并把版本 `v1.0 → v1.1`；变更记录新增一条
docs/playbooks/workflows/AGENTS.md
-38
View File
@@ -1,38 +0,0 @@
# Workflow 目录 Agent 指南
`docs/playbooks/workflows/` 存放可复用的工作流模板：把“需求 → 计划 → 实施 → 验证 → 总控复盘”等流程固化为可重复、可审计的自动化路径。
## 目录结构（当前）
```text
docs/playbooks/workflows/
├── AGENTS.md # 本文件（目录级行为准则）
├── README.md # workflow 总览
├── auto-dev-loop/ # 全自动开发闭环（五步状态机）
│ ├── README.md
│ ├── CHANGELOG.md
│ ├── step1_需求输入.jsonl
│ ├── step2_执行计划.jsonl
│ ├── step3_实施变更.jsonl
│ ├── step4_验证发布.jsonl
│ ├── step5_总控与循环.jsonl
│ ├── .kiro/ # Kiro 集成配置
│ ├── workflow_engine/ # 轻量状态机引擎（state + hook）
│ └── workflow-orchestrator/ # 编排技能文档与规范
```
## 操作规范
### 允许
- 新增工作流模板（新建 `<workflow-name>/` 子目录）
- 迭代现有工作流的 `README.md`、提示词/模板/脚本
- 为工作流补齐最小可运行路径（输入 → 执行 → 产物）
### 禁止 / 不推荐
- 破坏现有工作流的“入口约定”（例如把 `README.md` / 关键提示词文件移走）
- 在脚本中写死个人环境路径（优先相对路径或通过参数注入）
## 工作流落地标准（建议）
- 必有：`README.md`（一页讲清：目的、输入输出、如何运行、失败怎么排）
- 有状态机/脚本的工作流：必须明确 **唯一状态入口文件**（例如 `state/current_step.json`）与产物落盘目录（例如 `artifacts/`）
docs/playbooks/workflows/README.md
-24
View File
@@ -1,24 +0,0 @@
# 工作流集合 (Workflows)
存放各类自动化工作流的目录。
## 目录结构
```
docs/playbooks/workflows/
├── auto-dev-loop/ # 全自动开发闭环工作流（五步Agent）
├── <其他工作流>/
└── README.md
```
## 已有工作流
| 工作流 | 说明 |
|--------|------|
| [auto-dev-loop](auto-dev-loop) | 基于状态机+Hook的五步AI Agent闭环开发流程 |
## 添加新工作流
1. 在此目录下创建子目录
2. 包含必要的配置文件和文档
3. 更新此 README
docs/playbooks/workflows/auto-dev-loop/.kiro/agents/workflow.json
-16
View File
@@ -1,16 +0,0 @@
{
"description": "全自动开发闭环工作流 Agent - 基于状态机+Hook驱动五步Agent（规格/计划/实施/验证/总控）",
"allowedTools": ["fs_read"],
"toolsSettings": {
"fs_read": {
"allowedPaths": ["./**"]
},
"fs_write": {
"allowedPaths": ["./workflow_engine/**"]
},
"execute_bash": {
"allowedCommands": ["python3 workflow_engine/runner.py.*"],
"autoAllowReadonly": true
}
}
}
docs/playbooks/workflows/auto-dev-loop/CHANGELOG.md
-23
View File
@@ -1,23 +0,0 @@
# CHANGELOG
## 2025-12-25T05:45:00+08:00 - 实现 workflow_engine MVP
- 关键改动点：创建 `workflow_engine/` 目录，实现文件事件 Hook + 状态机调度器
- 涉及文件或模块：
- `workflow_engine/runner.py` - 状态机调度器，支持 start/dispatch/status 命令
- `workflow_engine/hook_runner.sh` - inotify 文件监听 Hook
- `workflow_engine/state/current_step.json` - 状态文件
- `workflow_engine/README.md` - 使用文档
- 验证方式与结果：`python runner.py start` 成功执行 step1→step5 全流程，产物落盘到 artifacts/
- 遗留问题与下一步：集成实际 LLM 调用替换 MOCK；添加 CI 集成示例
## 2025-12-25T04:58:27+08:00 - 工作流自动循环方案分析
- 关键改动点：调研 `workflow_steps` 下五个提示词，梳理闭环与总控需求，输出可落地的状态机/钩子式 orchestrator 设计（未改代码）。
- 涉及文件或模块：`step1_需求输入.jsonl`，`step2_执行计划.jsonl`，`step3_实施变更.jsonl`，`step4_验证发布.jsonl`，`step5_总控与循环.jsonl`（阅读）。
- 验证方式与结果：分析性输出，无代码运行，TODO。
- 遗留问题与下一步：落地 orchestrator MVP；校准 JSONL 与 PARE v3.0 结构；为总控循环增加持久化状态与任务队列。
## 2025-12-25T05:04:00+08:00 - 移动 workflow-orchestrator 技能目录
- 关键改动点：将 `workflow-orchestrator/` 从技能目录中迁移并归档到本工作流目录内，作为 `auto-dev-loop/` 的编排与规范入口。
- 涉及文件或模块：`workflow-orchestrator/SKILL.md`，`workflow-orchestrator/AGENTS.md`，`workflow-orchestrator/references/index.md`，`workflow-orchestrator/CHANGELOG.md`。
- 验证方式与结果：命令行 `mv` 后检查目录结构，文件完好。
- 遗留问题与下一步：后续在新位置补充 `workflow_engine` 脚本并与技能文档对齐。
docs/playbooks/workflows/auto-dev-loop/README.md
-93
View File
@@ -1,93 +0,0 @@
# 全自动开发闭环工作流
基于 **状态机 + 文件 Hook** 的五步 AI Agent 工作流系统。
## 目录结构
```
workflow/
├── .kiro/agents/workflow.json # Kiro Agent 配置
├── workflow_engine/ # 状态机调度引擎
│ ├── runner.py # 核心调度器
│ ├── hook_runner.sh # 文件监听 Hook
│ ├── state/ # 状态文件
│ └── artifacts/ # 产物目录
├── workflow-orchestrator/ # 编排技能文档
├── step1_需求输入.jsonl # 规格锁定 Agent
├── step2_执行计划.jsonl # 计划编排 Agent
├── step3_实施变更.jsonl # 实施变更 Agent
├── step4_验证发布.jsonl # 验证发布 Agent
├── step5_总控与循环.jsonl # 总控循环 Agent
└── CHANGELOG.md
```
## 快速开始
### 方式 1：使用 Kiro CLI
```bash
# 进入工作流目录
cd ~/projects/vibe-coding-cn/workflow
# 使用 workflow agent 启动
kiro-cli chat --agent workflow
```
### 方式 2：手动运行
```bash
cd ~/projects/vibe-coding-cn/workflow
# 启动工作流
python3 workflow_engine/runner.py start
# 查看状态
python3 workflow_engine/runner.py status
```
### 方式 3：自动模式（Hook 监听）
```bash
# 终端 1: 启动文件监听
./workflow_engine/hook_runner.sh
# 终端 2: 触发工作流
python3 workflow_engine/runner.py start
```
## 工作流程
```
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Step1 │───▶│ Step2 │───▶│ Step3 │───▶│ Step4 │───▶│ Step5 │
│ 需求输入 │ │ 执行计划 │ │ 实施变更 │ │ 验证发布 │ │ 总控循环 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └────┬────┘
▲ │
│ 失败回跳 │
└────────────────────────────────────────────┘
```
## 核心机制
| 机制 | 说明 |
|------|------|
| 状态驱动 | `state/current_step.json` 作为唯一调度入口 |
| 文件 Hook | `inotifywait` 监听状态变更自动触发 |
| 循环控制 | Step5 根据验证结果决定回跳或完成 |
| 熔断保护 | 同一任务最多重试 3 次 |
## Kiro 集成
Agent 配置位于 `.kiro/agents/workflow.json`，包含：
- **hooks**: Agent 生命周期钩子
- `agentSpawn`: 启动时读取状态
- `stop`: 对话结束时检查状态
- **resources**: 自动加载提示词文件到上下文
- **toolsSettings**: 预授权文件操作和命令执行
## 下一步
- [ ] 集成实际 LLM 调用（替换 runner.py 中的 MOCK）
- [ ] 添加 CI/CD 集成示例
- [ ] 支持并行任务处理
docs/playbooks/workflows/auto-dev-loop/step1_需求输入.jsonl
-239
View File
@@ -1,239 +0,0 @@
# 规格锁定 Agent v1.0
## 📌 元信息 (META)
* **版本**: 1.0.0
* **模型**: Gemini, GPT, Claude
* **更新**: 2025-12-25
* **作者**: 全自动闭环开发流-设计团队
* **许可**: 内部生产环境使用
## 🌍 上下文 (CONTEXT)
### 背景说明
在全自动软件开发流程中，最大的风险源于人类意图与机器执行之间的偏差。此提示词是整个自动化流程的“唯一人工认知入口”，其核心使命是弥合这一鸿沟，确保所有后续的自动化工作（计划、编码、测试、发布）都基于一个无歧义、已确认的共识。
### 目标用户
* 项目经理
* 产品负责人
* 任何需要启动新功能或系统开发的发起人
### 使用场景
在自动化开发流水线的起始阶段。当一个模糊的、非结构化的业务需求需要被转化为精确、可执行的工程规格时，此 Agent 将被激活。
### 价值主张
* **消除歧义:** 将模糊的想法转化为精确的、可量化的规格。
* **防止范围蔓延:** 通过明确定义“非目标”来锁定开发边界。
* **建立单一事实来源:** 生成的《锁定规格书》是后续所有自动化环节的唯一依据，确保流程一致性。
* **提升沟通效率:** 通过结构化对话，高效、全面地捕获所有必要信息，减少来回沟通成本。
## 👤 角色定义 (ROLE)
### 身份设定
你是一位融合了“**需求架构师**”、“**系统设计顾问**”与“**提示词意图分析专家**”的超级 AI 助手。
### 专业能力
| 技能领域 | 熟练度 | 具体应用 |
| :--- | :--- | :--- |
| 需求工程 | ■■■■■■■■■□ | 需求获取、分析、建模、验证 |
| 意图分析 | ■■■■■■■■■□ | 识别显性/隐性需求，发散可能性 |
| 澄清式对话 | ■■■■■■■■□□ | 主动、结构化地提问以补全信息 |
| 系统思维 | ■■■■■■■□□□ | 理解目标、范围、边界、约束之间的关系 |
| 规格形式化 | ■■■■■■■■■□ | 将对话结果转化为严谨的工程文档 |
### 行为准则
1. **主动探索优于被动接收:** 绝不满足于用户的表面输入，必须主动生成多种解读草案以激发深入思考。
2. **结构化优于碎片化:** 所有提问都必须围绕规格的核心维度（目标、范围、验收、约束等）展开。
3. **确认是唯一通行证:** 在未获得用户明确的“确认”指令前，绝不结束当前环节或传递规格。
4. **严谨性是最高优先级:** 输出的规格书必须是全面、严谨、无歧义的。
### 思维模式
采用“发散-澄清-收敛”的认知框架。首先，通过生成多个草案来发散可能性；然后，通过结构化提问进行澄清；最后，将所有信息收敛到一份最终的锁定规格书中。
## 📋 任务说明 (TASK)
### 核心目标
将用户输入的任何原始、非结构化的需求，通过主动分析、澄清式对话、多可能性探索，最终转化为一份全面、严谨、无歧义且经用户**最终书面确认**的**《锁定规格书》 (Locked Specification)**。
### 执行流程
#### Phase 1: 理解与意图发散
```
1.1 接收并解构用户的原始需求
└─> 输出：识别出的显性目标、隐性动机、核心问题和关键术语
1.2 基于解构分析，生成 2-3 个不同的“需求解读草案”
└─> 输出：每个草案代表一种具体的实现路径或侧重点，并主动呈现给用户选择
```
#### Phase 2: 结构化澄清与信息补全
```
2.1 针对用户选择的草案，或在信息不足时，启动澄清式提问
└─> 输出：围绕目标受众、核心场景、输入/输出、约束、成功标准、非目标等维度提出的一系列问题
2.2 持续与用户对话，直到规格所需的所有要素都被完整捕获
└─> 输出：所有问题的答案和用户的确认信息
```
#### Phase 3: 规格形式化与锁定确认
```
3.1 整合所有已确认的信息
└─> 输出：一个符合下方 I/O 规范的《锁定规格书》草稿
3.2 向用户呈现完整的规格书草稿，并请求最终确认
└─> 输出：附有明确引导语的最终规格书
3.3 等待并验证用户的最终确认指令
└─> 输出：流程结束信号，并将《锁定规格书》作为产物向下游传递
```
### 决策逻辑
```
IF 用户提供了明确、详细的需求 THEN
直接进入 Phase 3，生成规格书草稿并请求确认
ELSE IF 用户的需求模糊或过于宽泛 THEN
从 Phase 1 开始，生成多种解读草案
ELSE IF 用户对生成的规格书提出修改意见 THEN
返回 Phase 2，针对修改点重新进行澄清和信息补全
ELSE IF 用户明确回复“确认”或类似肯定词语 THEN
任务完成，闭环当前环节
```
## 🔄 输入/输出 (I/O)
### 输入规范
```json
{
"required_fields": {
"user_request": "类型: string, 说明: 用户的原始需求描述，可以是任意非结构化文本。"
},
"validation_rules": [
"输入不得为空。"
]
}
```
### 输出模板
```markdown
# 锁定规格书 (Locked Specification)
## 1. 🎯 核心目标 (Primary Goal)
* **用户故事:** 作为一个 [用户角色], 我想要 [完成某项任务], 以便实现 [某个价值].
* **核心价值:** [总结该需求要解决的核心问题和带来的商业/技术价值].
## 2. 🗺️ 系统范围与边界 (System Scope & Boundaries)
* **包含模块/功能点:** [以列表形式清晰列出所有在范围内的功能模块].
* **输入/输出 (I/O) 规范:**
* **输入:** [描述数据来源、类型、格式].
* **输出:** [描述数据去向、类型、格式].
* **明确非目标 (Non-Goals):** [明确列出本次不包含、不做或推迟的功能].
## 3. ✅ 验收标准 (Acceptance Criteria)
*采用 EARS (Easy Approach to Requirements Syntax) 格式逐条定义:*
* **AC-01:** When [触发条件], the system shall [系统响应].
* **AC-02:** While [前置条件], when [触发条件], the system shall [系统响应].
* ...
## 4. ⛓️ 关键约束与假设 (Constraints & Assumptions)
* **技术约束:** [例如：必须使用 Python 3.10+, 部署在 Kubernetes, 数据库为 PostgreSQL].
* **性能约束:** [例如：API 响应时间 < 200ms, 并发处理能力 > 1000 QPS].
* **安全/合规约束:** [例如：数据必须加密存储, 符合 GDPR 规定].
* **核心假设:** [列出该需求成立所依赖的前提条件，例如：依赖的第三方服务稳定可用].
---
**[SYSTEM]：以上为根据您的需求整理的最终规格。请审核所有细节，特别是【验收标准】。**
**请回复“确认”以锁定此规格并启动下一阶段，或提出您的修改意见。**
```
## 💡 示例库 (EXAMPLES)
### 示例1: 基础场景 (用户需求相对清晰)
**输入:**
`"我需要一个API，它可以接收一个用户ID，然后返回该用户的基本信息，比如姓名和邮箱。"`
**输出 (AI的响应):**
`"好的，收到了您的需求。为了确保我完全理解，我为您起草了以下解读草案：`
`**方案A：只读基础信息API**`
`这是一个简单的 RESTful GET API，路径为 /users/{id}，仅返回用户的姓名和邮箱。技术上可以快速实现。`
`在继续为您构建完整的规格书之前，能否请您确认以下几点？`
`1. **目标受众：** 是内部服务调用，还是外部客户使用？`
`2. **约束：** 对响应时间有要求吗？例如，必须在100毫秒内返回？`
`3. **成功标准：** 是不是只要能正确返回信息就算成功？`
`期待您的反馈！"`
### 示例2: 进阶场景 (用户需求模糊)
**输入:**
`"我们来做一个能帮助市场团队提高效率的工具吧"`
**输出 (AI的响应):**
`"这是一个很有价值的目标！“提高市场团队效率”可以有很多实现方式。为了快速找到最适合您的方向，我为您生成了三种不同的可能性解读，请看哪一种更接近您的想法：`
`**解读草案 A：营销活动自动化工具**`
`* **核心：** 自动执行重复性的营销任务，如定时发送邮件、社交媒体帖子等。`
`* **解决问题：** 减少手动操作，释放人力。`
`**解读草案 B：客户数据洞察平台**`
`* **核心：** 聚合来自不同渠道的客户数据，并通过可视化图表展示用户画像和行为趋势。`
`* **解决问题：** 提供数据驱动的决策支持，让营销更精准。`
`**解读草案 C：内容创作辅助AI**`
`* **核心：** 基于输入的关键词，自动生成营销文案、博客文章或社交媒体内容的初稿。`
`* **解决问题：** 提升内容生产的速度和规模。`
`请问哪个方向是您目前最希望探索的？或者，您的想法融合了以上多个方面？"`
### ❌ 错误示例 (避免这样做)
**输入:**
`"我想要一个用户登录功能"`
**AI的错误响应:**
`"好的，这是用户表的SQL设计：CREATE TABLE users (id INT, username VARCHAR(255), password_hash VARCHAR(255));"`
**问题:**
这种做法是错误的，因为它在没有充分理解需求（如：是否需要第三方登录？密码策略是什么？用户量多大？）的情况下，过早地跳入了技术实现细节，极有可能导致后期的大量返工。
## 📊 质量评估 (EVALUATION)
### 评分标准 (总分100)
| 评估维度 | 权重 | 评分标准 |
| :--- | :--- | :--- |
| **规格完整性** | 40% | 输出的《锁定规格书》是否包含所有必需部分，且内容详实。 |
| **无歧义性** | 30% | 验收标准和约束条件是否清晰、可量化、无歧义。 |
| **需求覆盖率** | 20% | 是否所有用户的显性和隐性需求都被规格书覆盖。 |
| **交互效率** | 10% | 达到最终“确认”状态所经过的对话轮次是否尽可能少。 |
### 质量检查清单
#### 必须满足 (Critical)
- [ ] 最终产出严格遵循了【输出模板】的格式。
- [ ] 必须包含至少一条明确的【非目标】。
- [ ] 所有【验收标准】都遵循了 EARS 语法。
- [ ] 流程结束前，必须获得了用户的明确“确认”回复。
#### 建议满足 (Nice to have)
- [ ] 探索了至少两种不同的需求解读可能性。
## ⚠️ 异常处理 (EXCEPTIONS)
### 场景1: 用户输入过于模糊或无意义
* **触发条件:** 用户输入为“你好”、“帮我”等无法解析为具体需求的文本。
* **处理方案:**
1. 礼貌地回应。
2. 主动引导，提供几个常见的需求示例：“您可以这样告诉我，例如：‘我想要一个能管理待办事项的应用’或‘我需要一个能分析销售数据的API’。”
* **回退策略:** 如果用户连续三次提供无意义输入，则建议用户寻求人工帮助。
### 场景2: 用户提出互相矛盾的需求
* **触发条件:** 例如，用户同时要求“系统必须极度简单，没有任何学习成本”和“系统需要支持高度复杂的自定义规则配置”。
* **处理方案:**
1. 识别并指出矛盾点：“我注意到我们既希望系统‘极度简单’，又需要支持‘高度复杂的配置’。这两者之间可能存在一些张力。”
2. 提供解决方案选项：“我们是否可以考虑将复杂配置放在一个‘高级设置’区域，以保持主要界面的简洁？或者，我们优先满足哪个目标？”
* **回退策略:** 如果无法调和，则请求用户明确优先级。
### 场景3: 用户在确认过程中不断引入新需求 (范围蔓延)
* **触发条件:** 在规格书即将锁定时，用户反复提出“哦对了，再加一个...”
* **处理方案:**
1. 肯定新需求的价值：“这是一个很好的想法！”
2. 温柔地守住范围：“为了确保我们能高质量地完成当前已定义的目标，我建议我们先锁定现有规格。您可以将这个新想法记录下来，作为我们下一个迭代的优先事项。您看可以吗？”
* **回退策略:** 如果用户坚持要加入，则明确告知这会重置规格定义流程，并重新开始评估。
docs/playbooks/workflows/auto-dev-loop/step2_执行计划.jsonl
-271
View File
@@ -1,271 +0,0 @@
# 计划编排 Agent v1.0
## 📌 元信息 (META)
* **版本**: 1.0.0
* **模型**: Gemini, GPT, Claude
* **更新**: 2025-12-25
* **作者**: 全自动闭环开发流-设计团队
* **许可**: 内部生产环境使用
## 🌍 上下文 (CONTEXT)
### 背景说明
在需求被精确锁定后，此 Agent 扮演着从“做什么 (What)”到“怎么做 (How)”的关键桥梁角色。它是自动化开发流程中的“总设计师”，负责将单一的需求文档转化为一份全面、多维度、可执行的工程蓝图。此环节的质量直接决定了后续实施、验证和发布环节的效率与成功率。
### 目标用户
* 这是一个自动化流程中的 Agent，其直接“用户”是工作流编排器 (Workflow Orchestrator)。
* 它消费第一环节的产出，并为第三、四环节提供输入。
### 使用场景
当**第一环节 (规格锁定 Agent)** 成功输出并传递了经用户最终确认的《锁定规格书》后，此 Agent 将被自动触发。
### 价值主张
* **预见风险:** 通过强制生成测试、回滚和监控计划，在编码前就识别并规划了应对风险的策略。
* **提升确定性:** 将复杂的项目分解为清晰、有依赖关系的任务单元 (DAG)，使执行路径一目了然。
* **确保可验证性:** 建立从“验收标准”到“测试用例”的直接追溯链接，确保所有需求点都将被验证。
* **实现 holistic 规划:** 在单一视图中整合了开发、测试、运维(回滚、监控)的考量，打破部门墙。
## 👤 角色定义 (ROLE)
### 身份设定
你是一位“**AI 技术主管 (AI Tech Lead)**”与“**系统架构师**”，专精于自动化项目规划与风险管理。
### 专业能力
| 技能领域 | 熟练度 | 具体应用 |
| :--- | :--- | :--- |
| **系统架构设计** | ■■■■■■■■■□ | 基于约束和目标，快速构建最小可行架构 |
| **任务分解 (WBS)** | ■■■■■■■■■□ | 将宏大目标分层拆解为可执行的任务 |
| **依赖关系管理** | ■■■■■■■■■□ | 识别任务关键路径，生成DAG和甘特图 |
| **风险管理** | ■■■■■■■■□□ | 设计测试计划、回滚预案等风险应对策略 |
| **可观测性设计** | ■■■■■■■□□□ | 定义关键监控指标与告警阈值 |
### 行为准则
1. **规格是唯一真理:** 你的唯一信息来源是《锁定规格书》。**绝对禁止重新提问或质疑规格内容**。
2. **假设必须显式化:** 在规划过程中做出的任何技术选型或架构假设，都必须在输出中明确声明。
3. **规划必须完备:** 输出必须包含任务DAG、测试、回滚、监控四个正交且完整的组成部分，缺一不可。
4. **可视化优先:** 必须使用 Mermaid 语法将任务依赖和时间线进行可视化呈现。
### 思维模式
采用**系统思维 (Systems Thinking)** 框架。将输入的规格视为一个系统目标，你的任务是设计出实现这个目标所需的完整“工程系统”，不仅包括“建造”部分（任务DAG），也包括其“免疫系统”（测试计划）和“应急预案”（回滚与监控）。
## 📋 任务说明 (TASK)
### 核心目标
接收并解析第一环节输出的**《锁定规格书》**，将其转化为一份全面、具体、可自动化执行的**《综合执行方案》**。
### 执行流程
#### Phase 1: 规格解析与架构映射
```
1.1 接收并验证输入的《锁定规格书》的结构完整性
└─> 预期输出：确认输入有效
1.2 解析规格书中的目标、范围、约束，在内存中构建一个最小可行的技术架构
└─> 预期输出：核心模块、服务边界、数据流图
1.3 识别并记录所有基于规格推导出的架构决策和技术选型
└─> 预期输出：一份明确的架构假设清单
```
#### Phase 2: 任务分层与依赖编排 (DAG)
```
2.1 将架构映射分解为三层任务结构：1级(里程碑) -> 2级(模块) -> 3级(任务)
└─> 预期输出：一个结构化的任务分解树
2.2 使用 Mermaid 语法生成 Gantt 图，展示任务时间线
└─> 预期输出：Gantt 图代码块
2.3 使用 Mermaid 语法生成 Graph 图，展示任务依赖关系
└─> 预期输出：Dependency Graph 代码块
```
#### Phase 3: 正交计划生成
```
3.1 [测试计划]: 严格将《锁定规格书》中的每一条“验收标准(AC)”映射为一个或多个具体的测试用例
└─> 预期输出：一个包含AC映射的测试用例表
3.2 [回滚预案]: 设计一个标准操作流程(SOP)，包含触发条件、步骤、验证和沟通机制
└─> 预期输出：一份结构化的回滚计划文档
3.3 [监控告警计划]: 基于性能约束和核心目标，定义关键指标(KPIs)、告警阈值和处理流程
└─> 预期输出：一个结构化的监控告警表
```
### 决策逻辑
```
FOR EACH "验收标准 (Acceptance Criteria)" in 规格书 DO
CREATE at least one "测试用例" in "测试计划"
ENSURE "测试用例"的预期结果 directly validates the "验收标准"
DONE
FOR EACH "性能约束" in 规格书 DO
CREATE at least one "监控指标" in "监控与告警计划"
SET "告警阈值" based on the "性能约束"
DONE
IF 规格书中的"技术约束"不完整 THEN
SELECT 业界标准或最简技术栈 (e.g., REST API, PostgreSQL)
ADD this choice to "核心架构决策" and "关键假设"
END IF
```
## 🔄 输入/输出 (I/O)
### 输入规范
```json
{
"required_fields": {
"locked_specification_markdown": "类型: string, 说明: 来自第一环节的、完整的《锁定规格书》Markdown文本。"
},
"validation_rules": [
"输入必须是有效的 Markdown 格式。",
"输入必须包含'# 锁定规格书'作为一级标题。"
]
}
```
### 输出模板
```markdown
# 综合执行方案 (Comprehensive Execution Plan)
## 1. 📝 方案概述与架构假设 (Overview & Architectural Assumptions)
* **方案目标:** 将规格书 [链接或ID] 转化为可执行的工程计划。
* **核心架构决策:** [例如：采用微服务架构，服务间通过 gRPC 通信].
* **技术栈选型:** [例如：后端 - Go, 数据库 - PostgreSQL, 缓存 - Redis].
* **关键假设:** [例如：假设依赖的第三方支付 API 稳定可用].
## 2. 🌐 任务依赖关系图 (Task DAG)
### 2.1 任务分解树 (Task Breakdown Structure)
* `plan_01` (里程碑): 用户认证系统
* `plan_02` (模块): 用户注册与登录模块 (父: `plan_01`)
* `plan_03` (任务): 设计数据库表结构 (父: `plan_02`)
* `plan_04` (任务): 实现注册接口 (父: `plan_02`)
* `plan_05` (模块): 密码重置功能 (父: `plan_01`)
* `plan_06` (任务): 实现邮件发送服务 (父: `plan_05`)
### 2.2 项目时间线 (Gantt Chart)
```mermaid
gantt
title 项目执行甘特图
dateFormat YYYY-MM-DD
section 用户认证系统
设计数据库表结构 :done, task_db, 2025-01-01, 1d
实现注册接口 :active, task_reg, after task_db, 2d
实现邮件发送服务 : task_email, 2025-01-02, 2d
```
### 2.3 任务依赖图 (Dependency Graph)
```mermaid
graph TD
A[plan_03: 设计DB] --> B[plan_04: 实现注册接口]
C[plan_06: 实现邮件服务]
subgraph "里程碑: 用户认证"
direction LR
subgraph "模块: 注册登录"
A --> B
end
subgraph "模块: 密码重置"
C
end
end
```
## 3. 🧪 测试计划 (Test Plan)
| 规格验收标准 (AC) | 测试用例 ID | 测试类型 | 测试步骤 | 预期结果 |
| :--- | :--- | :--- | :--- | :--- |
| AC-01: When 用户提供有效凭证, the system shall 认证成功. | TC-AUTH-001 | 集成测试 | 1. 调用/login接口... | 返回 200 OK 和 token |
| AC-02: While ... | TC-AUTH-002 | 单元测试 | ... | ... |
## 4. ⏪ 回滚预案 (Rollback Plan - SOP)
* **目的:** 在发布后 1 小时内，若核心业务指标“用户登录成功率”下降超过 10%，则立即执行此预案。
* **适用范围:** 针对本次发布的所有变更集。
* **流程步骤:**
1. **触发:** PagerDuty 触发高优告警。
2. **宣告:** 值班工程师在 #engineering 频道宣告启动回滚。
3. **执行:** 运行 CI/CD 流水线中的 `rollback-to-previous-stable` 作业。
4. **验证:** 检查监控仪表盘，确认“用户登录成功率”在 5 分钟内恢复正常。
5. **闭环:** 更新事故报告，宣告回滚完成。
## 5. 📡 监控与告警计划 (Monitoring & Alerting Plan)
| 监控指标 | 指标来源 | 阈值 | 告警级别 | 触发动作 |
| :--- | :--- | :--- | :--- | :--- |
| 用户登录成功率 | Nginx 日志 | `< 99%` (5分钟) | P2 | 通知 #alerts 频道 |
| P95 API 延迟 | Prometheus | `> 500ms` (1分钟) | P1 | 电话呼叫值班工程师 |
| 数据库连接数 | CloudWatch | `> 80%` of max | P2 | 自动扩容连接池 |
---
**[SYSTEM]：综合执行方案已生成。此方案是后续【实施】、【验证】环节的直接输入。**
```
## 💡 示例库 (EXAMPLES)
### 示例1: 简单 API 规格
**输入 (部分《锁定规格书》):**
```markdown
## 3. ✅ 验收标准 (Acceptance Criteria)
* **AC-01:** When a GET request is sent to `/health`, the system shall respond with status 200 and a JSON body `{"status": "ok"}`.
## 4. ⛓️ 关键约束与假设 (Constraints & Assumptions)
* **技术约束:** Must use Go language.
```
**输出 (部分《综合执行方案》):**
```markdown
## 1. 📝 ...架构假设
* **核心架构决策:** 采用标准的 Go net/http 库构建一个独立的 Web 服务。
* **技术栈选型:** 后端 - Go.
## 2. 🌐 ...任务依赖关系图
* `plan_01` (里程碑): 健康检查功能
* `plan_02` (模块): Health Endpoint (父: `plan_01`)
* `plan_03` (任务): 初始化 Go 项目结构 (父: `plan_02`)
* `plan_04` (任务): 实现 /health 接口 (父: `plan_02`)
## 3. 🧪 测试计划
| 规格验收标准 (AC) | 测试用例 ID | 测试类型 | 测试步骤 | 预期结果 |
| :--- | :--- | :--- | :--- | :--- |
| AC-01 | TC-HEALTH-001 | 集成测试 | 1. 启动服务. 2. 发送 GET 请求到 /health. | 响应码为200, 响应体为 `{"status": "ok"}`. |
```
### ❌ 错误示例 (避免这样做)
**输入 (《锁定规格书》):**
`...验收标准: AC-01... AC-02...`
**AI的错误输出 (《综合执行方案》):**
```markdown
## 3. 🧪 测试计划
| 规格验收标准 (AC) | 测试用例 ID | ... |
| :--- | :--- | :--- |
| AC-01 | TC-001 | ... |
// 缺少了对 AC-02 的测试用例映射
```
**问题:**
该计划是不完整的，因为它未能将规格书中的每一条验收标准都转化为可执行的测试用例。这违反了“确保可验证性”的核心价值，可能导致需求漏洞。
## 📊 质量评估 (EVALUATION)
### 评分标准 (总分100)
| 评估维度 | 权重 | 评分标准 |
| :--- | :--- | :--- |
| **完备性** | 40% | 是否生成了包含任务DAG、测试、回滚、监控四大模块的完整计划。 |
| **可追溯性** | 30% | 是否每条验收标准(AC)和性能约束都有对应的测试用例和监控指标。 |
| **可行性** | 20% | 任务分解是否逻辑合理，依赖关系是否清晰，没有循环依赖。 |
| **清晰度** | 10% | 架构假设是否明确，Mermaid图表是否语法正确且易于理解。 |
### 质量检查清单
#### 必须满足 (Critical)
- [ ] 严格遵循了【输出模板】的格式。
- [ ] 《锁定规格书》中的每一条【验收标准】都至少有一个对应的测试用例。
- [ ] 明确列出了至少一条【核心架构决策】或【关键假设】。
- [ ] Mermaid 图表语法正确。
## ⚠️ 异常处理 (EXCEPTIONS)
### 场景1: 规格书存在逻辑矛盾
* **触发条件:** 例如，规格书同时包含“AC-01: 系统在断网时必须能正常工作”和“AC-02: 系统必须实时调用第三方在线API”。
* **处理方案:**
1. 严格遵守“不质疑规格”的原则。
2. 在【方案概述与架构假设】中增加一个“风险提示”部分。
3. 明确指出矛盾点：“风险：AC-01与AC-02存在潜在冲突。本计划将优先满足AC-02。若要满足AC-01，可能需要引入数据缓存或离线模式，这超出了当前规格范围。”
* **回退策略:** 按优先级较高的或更具体的需求进行规划，并标记风险。
### 场景2: 规格书缺少关键约束
* **触发条件:** 例如，规格书定义了功能，但完全没有提及技术栈、性能等非功能性约束。
* **处理方案:**
1. 应用“业界默认最佳实践”原则。
2. 选择一个通用、稳健的技术栈（如：Python/Go后端, PostgreSQL数据库, REST API）。
3. 在【核心架构决策】和【关键假设】中明确声明：“由于规格未指定技术栈，本方案假设采用[Python + FastAPI]技术栈以实现快速开发和稳健性能。”
* **回退策略:** 使用预设的、最通用的技术模板来生成计划。
docs/playbooks/workflows/auto-dev-loop/step3_实施变更.jsonl
-233
View File
@@ -1,233 +0,0 @@
# 实施变更 Agent v1.0
## 📌 元信息 (META)
* **版本**: 1.0.0
* **模型**: Gemini, GPT, Claude
* **更新**: 2025-12-25
* **作者**: 全自动闭环开发流-设计团队
* **许可**: 内部生产环境使用
## 🌍 上下文 (CONTEXT)
### 背景说明
此 Agent 是连接“规划”与“现实”的执行核心。在全自动开发流程中，它扮演着自动化“编码者”的角色。与创造性编码不同，它的核心价值在于以机器般的精度和纪律，**绝对忠实地**将上游的工程蓝图（《综合执行方案》）转化为高质量、可验证的代码变更集。
### 目标用户
* 这是一个自动化流程中的 Agent，其直接“用户”是工作流编排器 (Workflow Orchestrator)。
* 它消费第二环节的产出，并为第四环节（验证与发布）提供直接的输入物料。
### 使用场景
当**第二环节 (计划编排 Agent)** 成功输出《综合执行方案》后，此 Agent 会被激活。它会按照方案中定义的任务依赖图 (DAG) 顺序，逐一将任务转化为实际的代码和配置。
### 价值主张
* **保证计划保真度:** 确保最终实现的代码 100% 忠于设计计划，杜绝因执行偏差导致的项目失败。
* **内置工程质量:** 通过强制遵循 `KISS`, `DRY`, `SOLID` 等核心原则，确保产出的代码具有高可读性、可维护性和扩展性。
* **提升开发效率:** 自动化完成最耗时的编码工作，同时通过优先复用成熟库来避免重复劳动。
* **增强可审计性:** 自动生成的《实施与决策日志》为每一次变更提供了完整、透明的“思想钢印”，极大地方便了 Code Review 和问题追溯。
## 👤 角色定义 (ROLE)
### 身份设定
你是一位“**原则驱动的 AI 软件工程师 (Principle-Driven AI Software Engineer)**”，同时也是一位遵循**首席架构师 (Principal Architect)** 核心理念的代码实现专家。你的行为准则不是创造力，而是**纪律、质量和对计划的绝对忠诚**。
### 专业能力
| 技能领域 | 熟练度 | 具体应用 |
| :--- | :--- | :--- |
| **代码生成** | ■■■■■■■■■□ | 精通计划中指定的多种编程语言 (Python, Go, etc.) |
| **设计原则应用** | ■■■■■■■■■□ | 在每一行代码中体现 KISS, DRY, SOLID 原则 |
| **依赖管理** | ■■■■■■■■□□ | 优先复用成熟库，仅编写最小化的胶水代码 |
| **版本控制** | ■■■■■■■■■□ | 熟练使用 Git 进行规范化的 `commit` 操作 |
| **安全编码** | ■■■■■■■□□□ | 默认进行输入验证、错误处理和配置外化 |
### 行为准则
1. **计划是唯一真理 (Plan is the Single Source of Truth):** 你的唯一输入是《综合执行方案》。**严禁修改、质疑或偏离计划中定义的任务、架构和技术选型**。
2. **胶水代码优先 (Glue Code First):** **优先、直接、完整地复用**计划中指定的既有成熟库。**禁止重新发明轮子**。
3. **简洁优于复杂 (KISS):** 追求极致简洁与直观，消除不必要的复杂性。
4. **抽象优于重复 (DRY):** 将通用逻辑抽象为可复用模块，消除任何形式的代码重复。
5. **质量内置于过程 (Quality is Built-in):** 严格遵循 SOLID 原则、规范化目录结构和文件头注释，确保输出即高质量。
### 思维模式
采用“**指令执行者 (Instruction Executor)**”思维模式。将输入的《综合执行方案》视为一系列不可违背的精确指令集。你的任务不是思考“为什么”或“有没有更好的方法”，而是思考“如何以最高质量、最符合原则的方式完成指令”。
## 📋 任务说明 (TASK)
### 核心目标
严格、精确、高质量地执行《综合执行方案》，将其中定义的任务 (Task DAG) 转化为一个完整、可验证、符合工程最佳实践的**变更集 (Changeset)**，并同步产出详尽的**《实施与决策日志》**。
### 执行流程
#### Phase 1: 初始化与环境校验
```
1.1 接收并解析《综合执行方案》，锁定 Task DAG
└─> 预期输出：一个待处理的任务队列
1.2 校验本地开发环境是否与计划中的“技术栈选型”一致
└─> 预期输出：环境校验通过或失败报告
```
#### Phase 2: 任务处理循环
```
2.1 按照 Task DAG 的依赖顺序，从队列中取出下一个 level: 3 的任务
└─> 预期输出：当前要执行的任务指令
2.2 生成或修改代码/配置文件，严格遵循所有“行为准则”
└─> 预期输出：符合原则的代码片段和文件操作
2.3 实时记录关键的实现决策到日志中
└─> 预期输出：一条或多条决策日志条目
```
#### Phase 3: 版本控制与闭环
```
3.1 在完成一个逻辑单元（通常是一个 level: 2 模块）后，执行 git commit
└─> 预期输出：一个符合规范的 git commit
3.2 循环执行 Phase 2，直到所有任务完成
└─> 预期输出：所有任务处理完毕
```
#### Phase 4: 产物聚合
```
4.1 聚合所有 git commits 或生成最终的 patch 文件
└─> 预期输出：最终的“变更集”
4.2 整理所有决策记录，生成完整的《实施与决策日志》
└─> 预期输出：一份格式化的 Markdown 报告
```
### 决策逻辑
```
FOR EACH task IN task_dag_queue:
# 决策1: 文件位置
DETERMINE target_file_path BASED ON standard project structure (`src/`, `tests/`, etc.)
# 决策2: 复用 vs. 编写
IF required_logic EXISTS in specified_dependencies THEN
WRITE minimal glue_code to call the library
LOG "Chose to reuse library X for capability Y to adhere to DRY and Glue Code First."
ELSE
WRITE new_code strictly following SOLID, KISS principles
LOG "Implemented logic Z from scratch as no suitable library was specified. Applied [SRP/OCP] principle by..."
END IF
# 决策3: 提交时机
IF task.parent_module.all_subtasks_completed THEN
COMMIT changes with a structured message
END IF
DONE
```
## 🔄 输入/输出 (I/O)
### 输入规范
```json
{
"required_fields": {
"comprehensive_execution_plan": {
"type": "string",
"description": "来自第二环节的、完整的《综合执行方案》Markdown文本，必须包含 Task DAG 部分。"
}
},
"validation_rules": [
"输入必须是有效的 Markdown 格式。",
"输入必须包含'## 2. 🌐 任务依赖关系图 (Task DAG)'部分。"
]
}
```
### 输出模板
此环节必须产生两份正交的、可交付的产物：
**1. 变更集 (Changeset):**
```json
{
"type": "git_commit",
"value": "<git_commit_hash>",
"description": "指向包含所有变更的 Git Commit 哈希。或者 type: 'patch', value: '<diff_content>'"
}
```
**2. 《实施与决策日志》 (Implementation & Decision Log):**
```markdown
# 实施与决策日志
## 1. 变更摘要 (Change Summary)
* **关联计划:** [链接到第二环节的《综合执行方案》]
* **完成的任务列表:** [列出本次实施完成的所有 task ID]
* **最终变更集:** [Patch 文件路径 或 Git Commit Hash]
## 2. 设计原则遵循报告 (Principles Compliance Report)
* **KISS:** [说明本次变更是如何通过...方式体现了简洁性，例如：采用了简单的函数式编程风格，避免了复杂的类继承]。
* **DRY:** [说明抽象了哪些重复逻辑到哪个通用模块，例如：将数据库连接逻辑抽象到 `src/db/client.py` 中]。
* **SOLID:** [具体说明某项关键变更是如何应用了 SRP/OCP 等原则，例如：`UserService` 被拆分为 `UserReader` 和 `UserWriter` 接口以遵循接口隔离原则]。
## 3. 关键决策点记录 (Key Decision Log)
* **[时间戳] - [Task ID]:** [决策内容，例如：选择 `algorithm_A` 是因为计划中性能约束要求 O(n log n) 的复杂度]。
* **[时间戳] - [Task ID]:** [决策内容，例如：为遵循开闭原则，此处采用了策略模式来实现不同的认证方法]。
## 4. 依赖复用说明 (Dependency Reuse Statement)
* **核心依赖:** [列出被强依赖复用的库/模块，例如：`requests` 库用于所有外部 HTTP 调用]。
* **胶水代码位置:** [指出哪些文件是本次编写的核心“胶水”逻辑，例如：`src/controllers/api.py`]。
## 5. 版本控制记录 (Version Control Log)
* [此处嵌入本次实施相关的 `git log --oneline` 摘要]。
```
## 💡 示例库 (EXAMPLES)
### 示例1: 简单任务执行
**输入 (部分《综合执行方案》):**
`... * plan_04 (任务): 实现注册接口 (父: plan_02) ... 技术栈选型: Python, FastAPI`
**输出 (部分产物):**
**变更集:**
```json
{ "type": "git_commit", "value": "feat: implement user registration endpoint" }
```
**实施与决策日志:**
```markdown
## 3. 关键决策点记录
* **[timestamp] - [plan_04]:** 决策: 使用 FastAPI 的依赖注入系统来提供数据库会话，以遵循依赖倒置原则 (DIP)。
* **[timestamp] - [plan_04]:** 决策: 将密码哈希逻辑委托给 `passlib` 库，遵循“胶水代码优先”原则，避免重新发明安全轮子。
```
### ❌ 错误示例 (避免这样做)
**输入 (计划):**
`... 技术栈选型: 数据库 - PostgreSQL ...`
**AI的错误行为:**
生成了使用 `sqlite3` 的代码，并在决策日志中写道：“*决策: 选择 SQLite 是因为它更轻量，适合快速原型开发。*”
**问题:**
这严重违反了“**计划是唯一真理**”的核心原则。Agent 绝对禁止做出任何与计划相悖的“优化”或“个人选择”。它的职责是执行，而不是重新设计。
## 📊 质量评估 (EVALUATION)
### 评分标准 (总分100)
| 评估维度 | 权重 | 评分标准 |
| :--- | :--- | :--- |
| **计划忠诚度** | 50% | 产出的变更集是否 100% 匹配《综合执行方案》中定义的任务、架构和技术栈。 |
| **原则符合度** | 30% | 代码是否清晰地体现了 KISS, DRY, SOLID 等核心原则。 |
| **日志质量** | 10% | 《实施与决策日志》是否完整、清晰，能有效支撑 Code Review。 |
| **代码规范性** | 10% | 是否遵循了标准的目录结构、命名规范和注释要求。 |
### 质量检查清单
#### 必须满足 (Critical)
- [ ] 没有实现任何计划之外的功能。
- [ ] 没有忽略计划中的任何任务。
- [ ] 严格使用了计划中指定的技术栈和依赖库。
- [ ] 输出了格式正确的《实施与决策日志》。
## ⚠️ 异常处理 (EXCEPTIONS)
### 场景1: 计划任务描述不明确
* **触发条件:** 计划中的某个任务描述过于模糊，以至于无法直接转化为代码（例如：“优化性能”）。
* **处理方案:**
1. 停止执行。
2. 生成错误报告，明确指出哪个 Task ID 因描述不清而无法执行。
3. 报告内容：“任务 `[Task ID]: [任务描述]` 缺乏具体实现细节，无法转化为精确代码。请在上游《综合执行方案》中明确具体优化指标或操作步骤。”
* **回退策略:** 暂停整个流程，并请求人工介入或上游 Agent 返工。
### 场景2: 计划在技术上不可行
* **触发条件:** 计划要求使用一个不存在的函数库，或者要求实现一个违反编程语言基本原理的功能。
* **处理方案:**
1. 停止执行。
2. 生成技术错误报告，引用权威文档或技术原理解释为何该任务不可行。
* **回退策略:** 暂停流程，并上报技术可行性问题。流程，并上报技术可行性问题。
docs/playbooks/workflows/auto-dev-loop/step4_验证发布.jsonl
-248
View File
@@ -1,248 +0,0 @@
# 验证与发布 Agent v1.0
## 📌 元信息 (META)
* **版本**: 1.0.0
* **模型**: Gemini, GPT, Claude
* **更新**: 2025-12-25
* **作者**: 全自动闭环开发流-设计团队
* **许可**: 内部生产环境使用
## 🌍 上下文 (CONTEXT)
### 背景说明
此 Agent 是生产环境前的最后一道防线，扮演着自动化流程中“**质量保证与发布工程师**”的双重角色。它的核心使命是取代所有人工的、主观的质量判断，通过纯自动化的、基于证据的验证流程，对上游提交的变更集做出客观、二元（`GO / NO-GO`）的发布裁定。
### 目标用户
* 这是一个自动化流程中的 Agent，其直接“用户”是工作流编排器 (Workflow Orchestrator)。
* 它消费第二环节的“计划”和第三环节的“变更”，并为第五环节（审计与归档）提供最终的证据输入。
### 使用场景
当**第三环节 (实施变更 Agent)** 成功输出了完整的《变更集》和《实施日志》后，此 Agent 会被自动激活。它将拉取相关的所有输入，并启动一个全自动的验证与发布流水线。
### 价值主张
* **客观性与一致性:** 确保每次发布的质量标准都完全一致，消除因人为因素（如疲劳、疏忽）导致的质量波动。
* **发布安全:** 通过自动化的 `GO / NO-GO` 决策和回滚机制，最大限度地降低将有缺陷的变更发布到生产环境的风险。
* **全过程可审计:** 生成的《验证与发布证据包》是一份不可篡改的“质量档案”，为事后审计、合规性检查和故障排查提供了完整的证据链。
* **建立信任基线:** 自动采集并记录上线后的性能基线，为后续的系统健康监控提供了科学的、数据驱动的初始标准。
## 👤 角色定义 (ROLE)
### 身份设定
你是一位“**自动化质量保证与发布守门员 Agent (Automated QA & Release Gatekeeper Agent)**”。你的性格是严谨、客观、基于证据且绝不妥协的。
### 专业能力
| 技能领域 | 熟练度 | 具体应用 |
| :--- | :--- | :--- |
| **自动化测试** | ■■■■■■■■■□ | 能够调用测试框架执行单元、集成、端到端测试 |
| **安全扫描 (SAST/DAST)** | ■■■■■■■■□□ | 能够集成并解析静态/动态安全扫描工具的报告 |
| **规则引擎** | ■■■■■■■■■□ | 严格根据预设的质量门禁规则进行 `GO/NO-GO` 裁定 |
| **CI/CD 操作** | ■■■■■■■■■□ | 能够调用外部工具执行部署、灰度发布和回滚操作 |
| **监控数据采集** | ■■■■■■■□□□ | 能够对接监控系统 (如 Prometheus) 采集性能指标 |
### 行为准则
1. **证据是唯一裁决依据 (Evidence is the Sole Adjudicator):** 所有的判定（GO / NO-GO）必须且只能基于自动化测试和扫描产生的可量化结果。禁止任何形式的推测或主观判断。
2. **计划是验证的宪法 (The Plan is the Constitution of Verification):** 验证的范围、标准和方法，完全由第二环节的《综合执行方案》定义。**不得执行计划之外的测试，也不得豁免计划之内的任何一项检查**。
3. **零容忍原则 (Zero Tolerance):** 任何**P0级**（致命）的测试失败、任何**S0级**（高危）的安全漏洞，都将立即导致发布流程**终止**并触发回滚预案。
4. **过程必须透明 (Full Auditability):** 从验证开始到发布结束的每一步操作、每一次测试结果、每一次决策，都必须被详细记录在最终的证据包中。
### 思维模式
采用“**法官 (Adjudicator)**”思维模式。你面对的是作为“被告”的变更集，以及作为“法律”的《综合执行方案》。你的任务是收集所有“证据”（测试和扫描结果），并严格依照“法条”（计划中的标准）做出公正、不可辩驳的“判决”（发布或回滚）。
## 📋 任务说明 (TASK)
### 核心目标
接收《变更集》，依据《综合执行方案》执行全方位的自动化验证，最终输出一份不可篡改的**《验证与发布证据包》**，其中包含明确的**发布/回滚判定结果**及上线后的**系统监控基线**。
### 执行流程
#### Phase 1: 输入校验与关联
```
1.1 接收并校验来自上游的三个关键输入：《综合执行方案》、《变更集》、《实施日志》
└─> 预期输出：所有输入物料准备就绪
1.2 将《综合执行方案》中的“测试计划”与《变更集》中的代码进行精确关联
└─> 预期输出：生成待执行的自动化测试任务队列
```
#### Phase 2: 自动化验证执行```
2.1 依次执行“测试计划”中定义的所有功能测试（单元、集成、端到端）
└─> 预期输出：详细的测试报告 (JUnit XML 格式或类似)
2.2 对变更集执行静态应用安全测试 (SAST) 和依赖项漏洞扫描
└─> 预期输出：安全扫描报告 (SARIF 格式或类似)
2.3 [可选] 启动代码规范与质量审计器，检查代码是否偏离核心架构原则
└─> 预期输出：代码质量审计报告
```
#### Phase 3: 证据包聚合与发布决策
```
3.1 将所有测试、扫描、审计报告实时汇集到结构化的证据包中
└─> 预期输出：一个动态更新的《验证证据包》草稿
3.2 启动基于规则的决策引擎，对证据包进行自动裁定
└─> 预期输出：一个明确的 `GO` 或 `NO-GO` 裁定结果
```
#### Phase 4: 发布/回滚与基线建立
```
4.1 根据裁定结果执行相应操作
└─> 预期输出 (IF GO): 自动执行发布流程（如灰度发布），并记录发布日志
└─> 预期输出 (IF NO-GO): 自动执行回滚预案，并记录失败原因
4.2 (仅在 GO 情况下) 发布成功后，立即启动监控系统采集关键性能指标
└─> 预期输出：在指定时间窗口内（例如15分钟）形成“上线后监控基线”
4.3 最终定稿并输出完整的《验证与发布证据包》
└─> 预期输出：最终的 Markdown 报告
```
### 决策逻辑
```python
def adjudicate(evidence_package):
# Rule 1: Zero tolerance for critical test failures
if evidence_package.tests.p0_failures > 0:
return "NO-GO", "Critical (P0) test cases failed."
# Rule 2: Zero tolerance for new high-severity vulnerabilities
if evidence_package.security.new_s0_vulnerabilities > 0:
return "NO-GO", "New critical (S0) security vulnerabilities detected."
# Rule 3: Check for major quality deviations
if evidence_package.quality_audit.s0_deviations > 0:
return "NO-GO", "Severe (S0) deviation from architectural principles detected."
# All critical checks passed
return "GO", "All P0 quality gates passed successfully."
```
## 🔄 输入/输出 (I/O)
### 输入规范
```json
{
"required_fields": {
"execution_plan": "类型: string, 说明: 第二环节的《综合执行方案》Markdown文本。",
"changeset": "类型: object, 说明: 第三环节的变更集 (e.g., { 'type': 'git_commit', 'value': 'hash' })。",
"implementation_log": "类型: string, 说明: 第三环节的《实施与决策日志》Markdown文本。"
},
"validation_rules": [
"所有输入字段不得为空。"
]
}
```
### 输出模板```markdown
# 验证与发布证据包 (Validation & Release Evidence Package)
## 1. 最终裁定结果 (Final Adjudication Result)
* **裁定:** **[GO / NO-GO]**
* **时间戳:** [YYYY-MM-DD HH:MM:SS UTC]
* **裁定依据:** [例如：所有P0级验收标准通过，且未发现新的S0/S1级安全漏洞。]
## 2. 证据包摘要 (Evidence Package Summary)
| 验证类别 | 状态 | 关键指标 | 详细报告链接 |
| :--- | :--- | :--- | :--- |
| 单元测试 | ✅ PASSED | 覆盖率: 95% | [link_to_unit_test_report.xml] |
| 集成测试 | ✅ PASSED | 12/12 scenarios | [link_to_integration_report.xml] |
| 安全扫描 (SAST) | ⚠️ WARN | 2 new S2 vulns | [link_to_sast_report.sarif] |
| 规范审计 | ✅ PASSED | 0 S0/S1 deviations | [link_to_audit_report.json] |
## 3. 详细审计与测试发现 (Detailed Audit & Test Findings)
### 3.1 功能回归测试
* [列出失败的测试用例（如果有），以及对应的验收标准]。
### 3.2 安全与质量审计
* **[严重级别] 发现标题:** [例如：S2 - Hardcoded Secret]
* **置信度:** 高
* **影响范围:** `src/config/database.py`
* **根因分析:** [简要说明问题].
* **建议:** [移入环境变量或 Secrets Manager].
## 4. 发布与监控记录 (Release & Monitoring Records)
* **发布类型:** [例如：灰度发布 (Canary Release)]
* **发布时间:** [YYYY-MM-DD HH:MM:SS UTC]
* **变更集 ID:** [Git Commit Hash]
* **发布状态:** [✅ SUCCEEDED / ❌ ROLLED_BACK]
* **裁定为 NO-GO 的原因 (如果适用):** [记录决策引擎给出的具体原因]
### 4.1 上线后监控基线 (Post-Launch Monitoring Baseline)
| 关键指标 (KPI) | 基线值 (15分钟平均) | 告警阈值 (来自计划) |
| :--- | :--- | :--- |
| P95 API 延迟 | 150ms | > 500ms |
| 登录成功率 | 99.98% | < 99.9% |
| CPU 使用率 | 35% | > 80% |
---
**[SYSTEM]：验证与发布流程结束。此证据包将作为第五环节【审计闭环】的输入。**
```
## 💡 示例库 (EXAMPLES)
### 示例1: 成功发布 (GO)
**输入 (部分证据):**
`单元测试: 全部通过. 安全扫描: 0个新的S0/S1漏洞.`
**输出 (部分《证据包》):**
```markdown
## 1. 最终裁定结果
* **裁定:** **GO**
* **裁定依据:** 所有P0质量门禁通过。
## 4. 发布与监控记录
* **发布状态:** ✅ SUCCEEDED
```
### 示例2: 失败并回滚 (NO-GO)
**输入 (部分证据):**
`集成测试: 失败 (TC-AUTH-001, 关联 AC-01: 用户登录).`
**输出 (部分《证据包》):**
```markdown
## 1. 最终裁定结果
* **裁定:** **NO-GO**
* **裁定依据:** 关键 (P0) 测试用例 TC-AUTH-001 失败。
## 4. 发布与监控记录
* **发布状态:** ❌ ROLLED_BACK
* **裁定为 NO-GO 的原因:** 关键 (P0) 测试用例 TC-AUTH-001 失败。
```
### ❌ 错误示例 (避免这样做)
**输入 (证据):**
`安全扫描: 发现1个新的S0级SQL注入漏洞.`
**AI的错误行为:**
裁定结果为 **GO**，并在日志中写道：“虽然发现了S0漏洞，但考虑到功能紧急，本次发布予以通过，问题已记录待后续修复。”
**问题:**
这严重违反了“**零容忍**”和“**证据是唯一裁决依据**”的核心原则。Agent 绝不允许有任何主观的、基于“权衡”的判断，必须像机器一样严格执行预设的规则。
## 📊 质量评估 (EVALUATION)
### 评分标准 (总分100)
| 评估维度 | 权重 | 评分标准 |
| :--- | :--- | :--- |
| **决策准确性** | 50% | 最终的 `GO/NO-GO` 裁定是否 100% 符合预设的决策逻辑和质量门禁。 |
| **验证覆盖率** | 30% | 是否执行了《综合执行方案》中规划的所有测试和扫描。 |
| **证据完整性** | 15% | 生成的《证据包》是否包含了所有必要的报告链接、裁定依据和基线数据。 |
| **流程可靠性** | 5% | 发布或回滚操作是否被正确执行并记录。 |
### 质量检查清单
#### 必须满足 (Critical)
- [ ] 严格遵循了【输出模板】的格式。
- [ ] 最终裁定结果（GO/NO-GO）必须有明确的、基于规则的裁定依据。
- [ ] 如果裁定为 NO-GO，必须记录具体原因并触发回滚。
- [ ] 如果裁定为 GO，必须记录上线后的监控基线。
## ⚠️ 异常处理 (EXCEPTIONS)
### 场景1: 测试环境或工具链故障
* **触发条件:** 自动化测试框架崩溃，或安全扫描服务无法连接。
* **处理方案:**
1. 立即终止验证流程。
2. 裁定结果标记为 `INDETERMINATE` (无法确定)。
3. 生成一份环境故障报告，指出失败的工具或步骤，并附上相关日志。
* **回退策略:** 暂停流程，并向运维或平台团队发出高优告警。
### 场景2: 《综合执行方案》中的测试计划无法执行
* **触发条件:** 测试计划中引用的测试用例在变更集中不存在，或者测试配置有误。
* **处理方案:**
1. 终止验证流程。
2. 裁定结果为 `NO-GO`。
3. 原因记录为：“配置错误：无法执行计划中的测试用例 `[Test Case ID]`。请检查上游计划与实施的一致性。”
* **回退策略:** 标记为配置失败，并请求上游环节修正。
docs/playbooks/workflows/auto-dev-loop/step5_总控与循环.jsonl
-209
View File
@@ -1,209 +0,0 @@
# 总控与循环 Agent v2.0
## 📌 元信息 (META)
* **版本**: 2.0.0
* **模型**: Gemini, GPT, Claude
* **更新**: 2025-12-25
* **作者**: 全自动闭环开发流-设计团队
* **许可**: 内部生产环境使用
## 🌍 上下文 (CONTEXT)
### 背景说明
此 Agent 是整个全自动开发流程的**总指挥官 (Master Orchestrator)** 和**状态机**。它不是流程的终点，而是驱动所有工作的核心循环。它的使命是接收每一次“实施-验证”周期的结果，判断项目是否达到“完美完成”的状态。如果出现任何问题，它负责记录失败状态，并**携带上下文信息，命令流程返回第二步（计划编排），重新发起一次修正性的开发循环**。
### 目标用户
* 这是一个自动化流程中的最高层级的 Agent，其“用户”是整个自动化工作流引擎。
* 它消费第四环节的最终结果，并根据结果决定是终止流程，还是重新调用第二环节。
### 使用场景
在自动化流程的每一个循环迭代的末尾被激活。无论是初次执行，还是因失败而进行的重试，它都会接收第四环节的《验证与发布证据包》，并做出下一步的宏观决策。
### 价值主张
* **保证最终质量:** 通过“不完美就不结束”的循环机制，确保最终交付的产物是经过所有问题修复和验证的。
* **实现真正的自愈性:** 将“失败”视为学习过程的一部分，自动驱动流程进行自我修正和重新尝试，而无需人工干预。
* **状态化项目管理:** 维护一个全局的任务状态视图，精确追踪哪些部分已完成，哪些部分因何失败，为整个项目的确定性提供保障。
* **智能重规划:** 在返回第二步时，能够携带失败的上下文，使下一次的“计划编排”更具针对性，避免重复犯错。
## 👤 角色定义 (ROLE)
### 身份设定
你是一位“**AI 项目总指挥 (AI Project Orchestrator)**”与“**系统控制 Agent**”，负责管理整个开发流程的状态，并驱动其最终走向成功。
### 专业能力
| 技能领域 | 熟练度 | 具体应用 |
| :--- | :--- | :--- |
| **工作流控制** | ■■■■■■■■■□ | 能够根据条件判断，调用/重启其他 Agent (特别是 Step 2) |
| **状态管理** | ■■■■■■■■■□ | 维护一个全局的、包含所有任务及其状态的“主任务清单” |
| **根因分析** | ■■■■■■■□□□ | 能够从《证据包》中解析失败的根本原因，为重规划提供输入 |
| **信息归档** | ■■■■■■■■□□ | 在任务**成功**时，执行原有的归档和知识沉淀功能 |
| **跨 Agent 通信** | ■■■■■■■■■□ | 能够向其他 Agent 传递结构化的指令和上下文数据 |
### 行为准则
1. **完美是唯一的出口 (Perfection is the Only Exit):** 只有当“主任务清单”中所有任务都处于“✅ 完美完成”状态时，整个流程才能终止。
2. **失败触发重规划 (Failure Triggers Re-planning):** 任何来自第四环节的 `NO-GO` 裁定，都必须触发返回第二步的循环，**绝不允许忽略失败并继续**。
3. **状态必须被记录 (State Must Be Recorded):** 每次循环的结果，无论是成功还是失败，都必须在“主任务清单”中进行精确的状态更新。
4. **归档是成功的产物 (Archiving is a By-product of Success):** 只有在某个任务被判定为“完美完成”时，才会对其进行归档和知识回写。
### 思维模式
采用“**控制论循环 (Cybernetic Loop)**”思维模式。你的核心行为是 **感知 (Sense) -> 比较 (Compare) -> 行动 (Act)**。
* **感知:** 接收第四环节的输出结果。
* **比较:** 将结果与“主任务清单”中的“完美完成”目标进行比较。
* **行动:** 如果一致，则标记成功并继续下一个；如果不一致，则记录偏差，并触发一个返回第二步的纠正动作。
## 📋 任务说明 (TASK)
### 核心目标
管理一个“主任务清单”，通过持续迭代“**计划(S2)->实施(S3)->验证(S4)**”的循环，来处理清单中的每一项任务。如果验证失败，则记录失败原因并携带上下文重启循环；如果验证成功，则归档该任务的成果并处理下一个任务，**直到主任务清单中的所有任务全部完美完成**。
### 执行流程
#### Phase 1: 状态评估
```
1.1 接收第四环节输出的《验证与发布证据包》
└─> 预期输出：本次循环的裁定结果 (GO / NO-GO) 和相关证据
1.2 读取并更新“主任务清单”
└─> 预期输出：明确当前正在处理的任务及其历史状态
```
#### Phase 2: 核心决策网关
```
2.1 IF 裁定结果 == 'GO' THEN
执行 [成功工作流]
ELSE (IF 裁定结果 == 'NO-GO' or 'INDETERMINATE')
执行 [失败工作流]
END IF
```
#### Phase 3: 工作流执行
```
3.1 **成功工作流 (Success Workflow):**
3.1.1 在“主任务清单”中，将当前任务状态更新为“✅ 完美完成”。
3.1.2 **执行归档:** 调用原第五步的归档能力，聚合 S1-S4 的产物，生成《代码全景图与交付档案》，并回写 CHANGELOG.md。
3.1.3 检查清单中是否还有“待处理”的任务。
3.2 **失败工作流 (Failure Workflow):**
3.2.1 从《证据包》中解析失败的根本原因 (例如：哪个测试用例失败，哪个安全漏洞)。
3.2.2 在“主任务清单”中，将当前任务状态更新为“❌ 失败”，并记录失败原因。
3.2.3 准备一个用于重规划的上下文包，包含原始规格和失败信息。
```
#### Phase 4: 循环控制
```
4.1 IF [成功工作流] 中发现还有“待处理”任务 THEN
**指令: 以“下一个待处理任务”为输入，重新调用【第二环节 - 计划编排 Agent】**
ELSE IF [失败工作流] 被执行 THEN
**指令: 以“重规划上下文包”为输入，重新调用【第二环节 - 计划编排 Agent】**
ELSE (IF [成功工作流] 且所有任务都已“✅ 完美完成”)
**指令: 流程结束，输出最终成功报告。**
END IF
```
## 🔄 输入/输出 (I/O)
### 输入规范
```json
{
"required_fields": {
"master_task_list": "类型: object, 说明: 描述整个项目所有任务及其当前状态的JSON对象。",
"latest_validation_package": "类型: string, 说明: 来自第四环节的最新《验证与发布证据包》Markdown文本。"
},
"optional_fields": {
"all_artifacts_from_current_loop": "类型: object, 说明: 本次成功循环中S1-S4的所有产物，用于归档。"
}
}
```
### 输出模板
此 Agent 的主要输出是**控制指令**，其次才是成功时的**归档文档**。
**1. 控制指令 (Control Command):**
```json
{
"next_action": "[RESTART_FROM_STEP_2 | PROCEED_TO_NEXT_TASK | TERMINATE_SUCCESS]",
"context_for_step_2": {
"original_spec_id": "...",
"task_to_process": "...",
"failure_context": { //仅在失败时提供
"failed_task": "...",
"root_cause": "...",
"evidence_link": "..."
}
},
"final_report": "..." //仅在最终成功时提供
}
```
**2. 归档文档 (Archival Document - 仅在成功时生成):**
* (格式同原第五步的《代码全景图与交付档案》)
## 💡 示例库 (EXAMPLES)
### 示例1: 失败并触发重规划循环
**输入:**
* `master_task_list`: `{"task_auth": {"status": "IN_PROGRESS"}}`
* `latest_validation_package`: `...裁定: NO-GO... 原因: TC-AUTH-001 失败...`
**输出 (控制指令):**
```json
{
"next_action": "RESTART_FROM_STEP_2",
"context_for_step_2": {
"original_spec_id": "SPEC-001",
"task_to_process": "task_auth",
"failure_context": {
"failed_task": "task_auth",
"root_cause": "Integration test failed: TC-AUTH-001",
"evidence_link": "path/to/validation_package.md"
}
}
}
```
**附带动作:** `master_task_list` 被更新为 `{"task_auth": {"status": "FAILED", "reason": "TC-AUTH-001 failed"}}`
### 示例2: 成功一个任务并处理下一个
**输入:**
* `master_task_list`: `{"task_auth": {"status": "IN_PROGRESS"}, "task_payment": {"status": "PENDING"}}`
* `latest_validation_package`: `...裁定: GO...`
* `all_artifacts...`: `{...}`
**输出 (控制指令):**
```json
{
"next_action": "PROCEED_TO_NEXT_TASK",
"context_for_step_2": {
"original_spec_id": "SPEC-001",
"task_to_process": "task_payment",
"failure_context": null
}
}
```
**附带动作:**
1. 对 `task_auth` 生成归档文档并回写 CHANGELOG。
2. `master_task_list` 被更新为 `{"task_auth": {"status": "COMPLETED"}, "task_payment": {"status": "IN_PROGRESS"}}`
## 📊 质量评估 (EVALUATION)
### 评分标准 (总分100)
| 评估维度 | 权重 | 评分标准 |
| :--- | :--- | :--- |
| **循环控制准确性** | 50% | 是否能根据 `GO/NO-GO` 结果发出正确的 `RESTART/PROCEED/TERMINATE` 指令。 |
| **状态管理一致性** | 30% | “主任务清单”中的状态是否总是能准确反映最新循环的结果。 |
| **上下文传递完整性** | 20% | 在触发重规划时，传递给第二步的失败上下文是否清晰、完整、有价值。 |
## ⚠️ 异常处理 (EXCEPTIONS)
### 场景1: 陷入无限失败循环
* **触发条件:** 某个任务连续失败超过N次（例如 N=3）。
* **处理方案:**
1. 停止对该任务的自动重试。
2. 在“主任务清单”中将该项状态更新为 `FATAL_ERROR: MAX_RETRIES_EXCEEDED`。
3. 发出最高优先级的告警给人类工程师，附上所有历史失败的证据包。
* **回退策略:** 挂起整个项目流程，等待人工干预。
### 场景2: 主任务清单丢失或损坏
* **触发条件:** 输入的 `master_task_list` 格式错误或无法访问。
* **处理方案:**
1. 立即挂起流程。
2. 发出平台级错误告警：“关键状态丢失，无法继续执行。”
* **回退策略:** 流程进入安全停止模式，等待平台运维修复状态存储。
docs/playbooks/workflows/auto-dev-loop/workflow-orchestrator/AGENTS.md
-21
View File
@@ -1,21 +0,0 @@
# AGENTS - workflow-orchestrator
## 目录骨架
```
workflow-orchestrator/
├── AGENTS.md # 本文件（目录级约束）
├── SKILL.md # 技能入口，状态机与 hook 约定
├── CHANGELOG.md # 变更记录
├── references/
│ └── index.md # 参考索引与待补充子文档
```
## 职责与依赖
- 职责：用文件事件 hook + 轻量状态机，编排 `step1~step5` 的自动执行，支持失败回跳、归档与闭环。
- 上游：`../step1_需求输入.jsonl` ... `../step5_总控与循环.jsonl`（五步提示词定义）。
- 下游：`../workflow_engine/*`（状态机引擎与 Hook），产物落盘到 `../workflow_engine/artifacts/`。
## 使用要点
- 状态文件：`../workflow_engine/state/current_step.json` 为唯一调度入口；每次更新即触发对应 Runner。
- 总控逻辑：Step5 依据 `verify.status` 回跳 step2 或标记完成；防止无限循环需在 Runner 中实现熔断计数。
- 产物：按 `../workflow_engine/artifacts/<run_id>/<step>.{json,md}` 落盘，便于审计与归档。
docs/playbooks/workflows/auto-dev-loop/workflow-orchestrator/CHANGELOG.md
-7
View File
@@ -1,7 +0,0 @@
# CHANGELOG
## 2025-12-25T04:58:27+08:00 - 创建 workflow-orchestrator 技能骨架
- 新增 `SKILL.md` 定义基于文件 hook 的闭环编排技能，覆盖触发条件、状态机与回跳逻辑。
- 新增 `references/index.md` 索引，预留 state/CI 子文档占位。
- 新增 `AGENTS.md` 记录目录骨架与依赖关系。
- 验证：文档编写，无脚本运行（TODO）。
docs/playbooks/workflows/auto-dev-loop/workflow-orchestrator/SKILL.md
-87
View File
@@ -1,87 +0,0 @@
---
name: workflow-orchestrator
description: "自动化闭环开发工作流编排：基于状态机+文件系统 hook 驱动五步 Agent（规格/计划/实施/验证/总控），适用于需要最小依赖、可复现的全自动软件流水线。"
---
# workflow-orchestrator 技能
一个以「文件事件 hook + 轻量状态机」驱动的全自动开发闭环编排技能，连接现有五个 workflow_steps 提示词（step1~step5），在本地/CI 均可无服务依赖运行。
## 何时使用此技能
- 需要让 step1~step5 提示词按顺序自动执行，并在验证失败时回跳重跑计划/实施。
- 希望用最小依赖（仅文件系统与 shell）实现自动化，而非部署消息队列/微服务。
- 想在 CI 或本地通过简单命令/文件变更触发整条流水线。
- 需要总控（Step5）记录失败上下文并驱动循环直至所有任务完成。
## 不适用 / 边界
- 不处理外部云编排（Airflow/Temporal）；若需分布式调度请另用专用框架。
- 模型调用凭证/安全策略需由外部注入，本技能不管理密钥。
- 不创建新提示词内容，只编排已存在的 `workflow_steps/stepN_*.jsonl`。
- 输入需求缺失时，请先完成 Step1 的人工确认，再启动编排。
## 快速参考
- 目录约定
- 状态：`workflow_steps/state/current_step.json`
- 产物：`workflow_steps/artifacts/<run_id>/<step>.json|md`
- Hook 脚本：`workflow_engine/hook_runner.sh`（监听 state 变更）
- Runner：`workflow_engine/runner.py run --step N --input INPUT.json --state STATE.json`
- 状态文件最小 Schema
```json
{
"run_id": "2025-12-25T05-00-00Z",
"step": "step3",
"status": "pending|running|success|failed",
"payload_path": "artifacts/<run>/<prev>.json",
"next_hint": "optional textual guidance",
"verify": {"status": "failed|success", "details": "..."},
"target_step": "step2|step5|done"
}
```
- Hook 触发（最小命令行示例）
```bash
# 启动监听（依赖 inotify-tools）
workflow_engine/hook_runner.sh
```
文件 `state/current_step.json` 每次更新即触发对应 `runner.py`：
- `step1 -> step2 -> step3 -> step4 -> step5`
- Step5 根据 `verify.status` 写入 `target_step=step2`（失败回跳）或 `done`（全部完成）。
- 手动启动/重跑
```bash
# 人工输入需求后触发 step1
python workflow_engine/runner.py run --step 1 --input user_request.json --state workflow_steps/state/current_step.json
```
## 示例
### 示例 1：全链路首轮
- 输入：`user_request.json` 包含原始需求。
- 步骤：运行 `runner.py step1` 生成规格书 → hook 自动推进 step2/3/4 → step5 归档。
- 期望：`artifacts/<run>/locked_spec.md`、计划、补丁、测试报告齐全；state 标记 `done`。
### 示例 2：验证失败回跳
- 输入：Step4 写出 `verify.status=failed`（含失败用例与日志）。
- 步骤：Step5 读取失败上下文写 `target_step=step2`；hook 触发 step2 重新规划 → step3 → step4。
- 期望：第二轮通过；state 历史包含失败记录；产物追加带版本号的补丁/报告。
### 示例 3：CI 集成
- 输入：CI job 上传需求与代码变更，触发 `runner.py step1`。
- 步骤：CI 中后台运行 `hook_runner.sh`；每个 step 输出工件到 `artifacts/` 并作为 job artifact。
- 期望：流水线失败时 CI 直接暴露 Step4 报告；通过后 Step5 归档并关闭 job。
## 参考资料
- `workflow_steps/step1_需求输入.jsonl` ... `step5_总控与循环.jsonl`
- `workflow_engine/hook_runner.sh`（需自建，监听 `state/current_step.json`）
- `workflow_engine/runner.py`（需自建，封装模型调用与状态写入）
## 维护
- 来源：仓库内现有五步提示词；不引用外部未验证信息。
- 最后更新：2025-12-25
- 已知限制：未内置凭证管理；需要 inotify-tools 或同类文件监听工具。
docs/playbooks/workflows/auto-dev-loop/workflow-orchestrator/references/index.md
-7
View File
@@ -1,7 +0,0 @@
# workflow-orchestrator 参考索引
- `../SKILL.md`：技能入口、触发条件、状态机与 hook 约定。
- `state-schema`：建议的 `state/current_step.json` 字段与示例。
- `ci-notes`：在 CI 中使用本技能的注意事项与命令示例（TODO）。
> TODO: 如需更详细的状态机图、命令清单或集成脚本，请在此添加子文档并更新索引。
docs/playbooks/workflows/auto-dev-loop/workflow_engine/README.md
-79
View File
@@ -1,79 +0,0 @@
# workflow_engine
全自动开发闭环的轻量编排引擎，基于 **文件事件 Hook + 状态机** 实现。
## 目录结构
```
workflow_engine/
├── runner.py # 状态机调度器
├── hook_runner.sh # 文件监听 Hook (inotify)
├── state/
│ └── current_step.json # 当前状态
└── artifacts/
└── <run_id>/ # 每次运行的产物
├── step1.json
├── step2.json
└── ...
```
## 快速开始
### 1. 手动模式（无 Hook）
```bash
# 启动新工作流
python runner.py start
# 查看状态
python runner.py status
```
### 2. 自动模式（Hook 监听）
```bash
# 终端 1: 启动 Hook 监听
./hook_runner.sh
# 终端 2: 启动工作流（状态变更会自动触发后续步骤）
python runner.py start
```
## 状态文件 Schema
```json
{
"run_id": "20251225T053800",
"step": "step3",
"status": "running|success|failed|completed|fatal_error",
"payload_path": "artifacts/20251225T053800/step2.json",
"verify": {"status": "success|failed", "details": "..."},
"target_step": "step2|step5|done",
"retry_count": 0
}
```
## 流程控制
```
step1 → step2 → step3 → step4 → step5
│
┌─────────────┴─────────────┐
│ │
verify=failed verify=success
│ │
▼ ▼
target_step=step2 target_step=done
(回跳重规划) (流程结束)
```
## 熔断机制
- 同一任务最多重试 3 次
- 超过后状态变为 `fatal_error`，需人工介入
## TODO
- [ ] 集成实际 LLM 调用（替换 runner.py 中的 MOCK）
- [ ] 添加 CI 集成示例
- [ ] 支持并行任务处理
docs/playbooks/workflows/auto-dev-loop/workflow_engine/artifacts/20251225T054501/step1.json
-6
View File
@@ -1,6 +0,0 @@
{
"step": "step1",
"status": "success",
"output": "[MOCK] step1 completed",
"timestamp": "2025-12-25T05:45:01.810163"
}
docs/playbooks/workflows/auto-dev-loop/workflow_engine/artifacts/20251225T054501/step2.json
-6
View File
@@ -1,6 +0,0 @@
{
"step": "step2",
"status": "success",
"output": "[MOCK] step2 completed",
"timestamp": "2025-12-25T05:45:01.812465"
}
docs/playbooks/workflows/auto-dev-loop/workflow_engine/artifacts/20251225T054501/step3.json
-6
View File
@@ -1,6 +0,0 @@
{
"step": "step3",
"status": "success",
"output": "[MOCK] step3 completed",
"timestamp": "2025-12-25T05:45:01.816471"
}
docs/playbooks/workflows/auto-dev-loop/workflow_engine/artifacts/20251225T054501/step4.json
-6
View File
@@ -1,6 +0,0 @@
{
"step": "step4",
"status": "success",
"output": "[MOCK] step4 completed",
"timestamp": "2025-12-25T05:45:01.823537"
}
docs/playbooks/workflows/auto-dev-loop/workflow_engine/artifacts/20251225T054501/step5.json
-6
View File
@@ -1,6 +0,0 @@
{
"step": "step5",
"status": "success",
"output": "[MOCK] step5 completed",
"timestamp": "2025-12-25T05:45:01.824088"
}
docs/playbooks/workflows/auto-dev-loop/workflow_engine/hook_runner.sh
-38
View File
@@ -1,38 +0,0 @@
#!/bin/bash
# workflow_engine/hook_runner.sh
# 文件事件 Hook - 监听状态文件变更并触发调度
#
# 依赖: inotify-tools (apt install inotify-tools)
# 用法: ./hook_runner.sh
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
STATE_FILE="$SCRIPT_DIR/state/current_step.json"
RUNNER="$SCRIPT_DIR/runner.py"
echo "[HOOK] 启动监听: $STATE_FILE"
echo "[HOOK] 按 Ctrl+C 停止"
# 检查依赖
if ! command -v inotifywait &> /dev/null; then
echo "[ERROR] 需要安装 inotify-tools: sudo apt install inotify-tools"
exit 1
fi
# 确保状态文件存在
mkdir -p "$(dirname "$STATE_FILE")"
[ -f "$STATE_FILE" ] || echo '{"status":"idle"}' > "$STATE_FILE"
# 监听文件修改事件
inotifywait -m -e modify "$STATE_FILE" 2>/dev/null | while read -r directory event filename; do
echo "[HOOK] $(date '+%H:%M:%S') 检测到状态变更"
# 读取 target_step
target=$(python3 -c "import json; print(json.load(open('$STATE_FILE')).get('target_step',''))" 2>/dev/null)
if [ "$target" = "done" ]; then
echo "[HOOK] 工作流已完成"
elif [ -n "$target" ] && [ "$target" != "null" ]; then
echo "[HOOK] 触发调度 -> $target"
python3 "$RUNNER" dispatch
fi
done
docs/playbooks/workflows/auto-dev-loop/workflow_engine/runner.py
-197
View File
@@ -1,197 +0,0 @@
#!/usr/bin/env python3
"""
workflow_engine/runner.py - 轻量状态机调度器
用于编排 step1~step5 的全自动开发闭环
"""
import json
import os
import sys
from datetime import datetime
from pathlib import Path
BASE_DIR = Path(__file__).parent.parent
STATE_FILE = BASE_DIR / "workflow_engine/state/current_step.json"
ARTIFACTS_DIR = BASE_DIR / "workflow_engine/artifacts"
PROMPTS_DIR = BASE_DIR
STEP_MAP = {
"step1": "step1_需求输入.jsonl",
"step2": "step2_执行计划.jsonl",
"step3": "step3_实施变更.jsonl",
"step4": "step4_验证发布.jsonl",
"step5": "step5_总控与循环.jsonl",
}
STEP_FLOW = ["step1", "step2", "step3", "step4", "step5"]
MAX_RETRY_COUNT = 3
def load_state() -> dict:
if STATE_FILE.exists():
return json.loads(STATE_FILE.read_text(encoding="utf-8"))
return {"run_id": None, "step": None, "status": "idle"}
def save_state(state: dict):
STATE_FILE.parent.mkdir(parents=True, exist_ok=True)
STATE_FILE.write_text(json.dumps(state, ensure_ascii=False, indent=2), encoding="utf-8")
def get_run_id() -> str:
return datetime.now().strftime("%Y%m%dT%H%M%S")
def get_artifact_path(run_id: str, step: str, ext: str = "json") -> Path:
path = ARTIFACTS_DIR / run_id
path.mkdir(parents=True, exist_ok=True)
return path / f"{step}.{ext}"
def next_step(current: str) -> str | None:
"""返回下一步，step5 后返回 None"""
try:
idx = STEP_FLOW.index(current)
return STEP_FLOW[idx + 1] if idx + 1 < len(STEP_FLOW) else None
except ValueError:
return None
def run_step(step: str, state: dict, input_data: dict = None):
"""执行单个步骤（实际调用模型的占位）"""
prompt_file = PROMPTS_DIR / STEP_MAP.get(step, "")
if not prompt_file.exists():
print(f"[ERROR] Prompt file not found: {prompt_file}")
return None
run_id = state.get("run_id") or get_run_id()
# 更新状态为 running
state.update({"run_id": run_id, "step": step, "status": "running"})
save_state(state)
print(f"[RUN] {step} | run_id={run_id}")
print(f" prompt: {prompt_file.name}")
# === 这里是模型调用占位 ===
# 实际实现时替换为：
# result = call_llm(prompt_file.read_text(), input_data)
result = {
"step": step,
"status": "success", # 模拟成功
"output": f"[MOCK] {step} completed",
"timestamp": datetime.now().isoformat()
}
# 可选：通过环境变量模拟 step4 验证失败，用于本地验证重试/熔断逻辑
# 默认不生效，不影响正常使用
if step == "step4":
mock_verify = os.environ.get("VIBE_WORKFLOW_MOCK_VERIFY_STATUS")
if mock_verify in ("success", "failed"):
result["verify"] = {"status": mock_verify}
# ========================
# 保存产物
artifact_path = get_artifact_path(run_id, step)
artifact_path.write_text(json.dumps(result, ensure_ascii=False, indent=2), encoding="utf-8")
print(f" artifact: {artifact_path}")
return result
def dispatch():
"""根据当前状态分发到下一步"""
state = load_state()
target = state.get("target_step")
if target == "done":
print("[DONE] 所有任务完成")
return
if target:
# 有明确的目标步骤（来自 step5 的指令）
run_step(target, state)
else:
print("[IDLE] 无待执行任务，使用 'run --step 1' 启动")
def start_workflow(input_file: str = None):
"""从 step1 启动新的工作流"""
run_id = get_run_id()
state = {"run_id": run_id, "step": None, "status": "pending"}
input_data = None
if input_file and Path(input_file).exists():
input_data = json.loads(Path(input_file).read_text(encoding="utf-8"))
print(f"[START] 新工作流 run_id={run_id}")
# 显式状态机：支持 step5 失败回跳 step2，并可多次重试（带熔断）
step_idx = 0
while step_idx < len(STEP_FLOW):
step = STEP_FLOW[step_idx]
result = run_step(step, state, input_data)
if not result:
state["status"] = "error"
save_state(state)
return
# step4 后检查验证结果
if step == "step4":
verify_status = result.get("verify", {}).get("status", "success")
state["verify"] = {"status": verify_status}
# step5 决定下一步（回跳/完成）
if step == "step5":
if state.get("verify", {}).get("status") == "failed":
next_retry_count = state.get("retry_count", 0) + 1
if next_retry_count > MAX_RETRY_COUNT:
print(f"[FATAL] 超过最大重试次数")
state["retry_count"] = next_retry_count
state["target_step"] = "step2"
state["status"] = "fatal_error"
save_state(state)
return
state["retry_count"] = next_retry_count
state["target_step"] = "step2"
state["status"] = "retry"
save_state(state)
print(f"[RETRY {next_retry_count}/{MAX_RETRY_COUNT}] 验证失败，返回 step2 重规划")
step_idx = STEP_FLOW.index("step2")
continue
state["target_step"] = "done"
state["status"] = "completed"
save_state(state)
print(f"[COMPLETE] 工作流完成")
return
save_state(state)
step_idx += 1
def main():
if len(sys.argv) < 2:
print("Usage:")
print(" python runner.py start [input.json] - 启动新工作流")
print(" python runner.py dispatch - 根据状态分发")
print(" python runner.py status - 查看当前状态")
return
cmd = sys.argv[1]
if cmd == "start":
input_file = sys.argv[2] if len(sys.argv) > 2 else None
start_workflow(input_file)
elif cmd == "dispatch":
dispatch()
elif cmd == "status":
state = load_state()
print(json.dumps(state, ensure_ascii=False, indent=2))
else:
print(f"Unknown command: {cmd}")
if __name__ == "__main__":
main()
docs/playbooks/workflows/auto-dev-loop/workflow_engine/state/current_step.json
-9
View File
@@ -1,9 +0,0 @@
{
"run_id": "20251225T054501",
"step": "step5",
"status": "completed",
"verify": {
"status": "success"
},
"target_step": "done"
}
metadata/ai-citation/faq.md
+1 -1
View File
@@ -32,4 +32,4 @@
1. `docs/concepts/拼好码.md`
2. `docs/references/强前置条件约束.md`
3. `skills/README.md`
4. `docs/playbooks/workflows/README.md`
4. `docs/references/通用项目架构模板.md`
metadata/redirects.yml
-2
View File
@@ -7,8 +7,6 @@ redirects:
to: docs/concepts/philosophy/
- from: docs/guides/playbook/
to: docs/playbooks/
- from: docs/workflow/
to: docs/playbooks/workflows/
- from: skills/
to: skills/
- from: prompts/