create-yss-spec 1.0.0

package/template/docs/discovery/templates/discovery-template.md

@@ -0,0 +1,95 @@
+---
+pipeline: <feature-id>
+stage: discovery
+status: draft
+owner: ai
+---
+
+# <功能名称> Discovery 收敛文档
+
+> 适用场景：机会探索、竞品分析或用户材料已经有初步输入，需要收敛为 PRD 上游事实。
+> 本文回答“为谁、为什么、第一版做什么、不做什么、如何判断成功、产品能力往哪里建设、后续可能影响哪些设计资产”，不替代 PRD、业务架构、功能架构、OpenAPI 或系统 / 数据架构。
+
+## 1. 输入材料
+
+| 材料 | 路径 / 链接 | 状态 | 备注 |
+|------|-------------|------|------|
+| 机会想法 / 用户反馈 |  |  |  |
+| 竞品 / 市场分析 |  |  |  |
+| 现有系统 / 业务材料 |  |  |  |
+| 约束 / 决策 |  |  |  |
+
+## 2. 目标用户与场景
+
+| 用户 / 角色 | 核心场景 | 当前痛点 | 影响范围 |
+|-------------|----------|----------|----------|
+|  |  |  |  |
+
+## 3. 问题与机会
+
+- 问题陈述：
+- 为什么现在做：
+- 差异化机会：
+- 不做的机会：
+
+## 4. MVP 边界
+
+| 能力 | 是否进入 MVP | 理由 | 成功信号 |
+|------|---------------|------|----------|
+|  | 是 / 否 / 待定 |  |  |
+
+## 5. 非目标范围
+
+| 非目标 | 排除原因 | 后续观察条件 |
+|--------|----------|--------------|
+|  |  |  |
+
+## 6. 产品功能指引 / 能力候选
+
+> 本节用于给 PRD 和功能架构输入方向，不冻结最终功能架构或技术系统方案。
+
+| 能力候选 | 用户价值 | 优先级假设 | 是否进入 MVP | 证据 / 依据 | 下游影响 |
+|----------|----------|------------|---------------|-------------|----------|
+|  |  | P0 / P1 / P2 | 是 / 否 / 待定 |  | UI / API / 数据 / 权限 / 架构 |
+
+## 7. 下游影响清单
+
+> 只记录影响信号和待验证假设；具体方案在 PRD、产品设计、API、系统 / 数据架构和设计审查阶段收敛。
+
+| 影响域 | 是否可能影响 | 说明 | 需要进入的后续门禁 |
+|--------|--------------|------|--------------------|
+| 页面 / 交互 | 是 / 否 / 待定 |  | 产品设计 / Prototype Review |
+| OpenAPI / 契约 | 是 / 否 / 待定 |  | API 影响分析 / 契约草案 |
+| 数据模型 / 持久化 | 是 / 否 / 待定 |  | 数据架构 / Design Review |
+| 权限 / 审计 | 是 / 否 / 待定 |  | 系统架构 / 安全审查 |
+| 外部系统 / 集成 | 是 / 否 / 待定 |  | 系统架构 / ADR |
+| 发布 / 回滚 / 运维 | 是 / 否 / 待定 |  | 系统架构 / Release Review |
+| 安全红线 | 是 / 否 / 待定 |  | `TODO-HUMAN-REVIEW` |
+
+## 8. 成功标准
+
+| 指标 / 结果 | 目标 | 验证方式 |
+|-------------|------|----------|
+|  |  |  |
+
+## 9. 风险与待澄清
+
+| 风险 / 问题 | 影响 | 处理方式 | 截止点 |
+|-------------|------|----------|--------|
+|  |  |  | PRD 前 |
+
+## 10. 完成标准
+
+- [ ] 目标用户、痛点、为什么现在做已经明确。
+- [ ] MVP 和非目标范围可直接输入 PRD。
+- [ ] 产品功能指引已经形成能力候选和优先级假设，但未替代正式功能架构。
+- [ ] 下游 UI、API、数据、权限、架构、安全影响信号已列出。
+- [ ] 成功标准可验收。
+- [ ] 业务架构需要的用户旅程、价值流、角色 / 外部系统线索已列出。
+- [ ] 需要回写 `CONTEXT.md` 的术语已标注。
+
+## 11. 下一步门禁
+
+- 结论：Approved / Blocked
+- 下一步：业务架构 / PRD / 继续 Discovery
+- 阻断项：

package/template/docs/discovery/templates/market-analysis-template.md

@@ -0,0 +1,55 @@
+# 市场分析报告
+
+> 基于公开数据的市场分析（AI 辅助生成，人工审核后定稿）
+
+## 市场概览
+
+### 基本数据
+
+| 指标 | 数据 | 来源 | 年份 |
+|------|------|------|------|
+| | | | |
+
+### 增长趋势
+
+（描述市场规模变化趋势，附图表）
+
+## 细分赛道分析
+
+### 赛道一：[名称]
+
+- 市场规模：
+- 增长率：
+- 主要玩家：
+- 用户画像：
+- 机会点：
+
+## 用户行为趋势
+
+- 移动端 vs PC 端占比
+- 用户决策路径变化
+- 新消费习惯
+
+## 技术趋势
+
+- AI/ML 应用
+- AR/VR 购物体验
+- 新支付方式
+
+## 政策与监管
+
+- 相关法规
+- 合规要求
+- 政策风险
+
+## 关键结论
+
+1. 
+2. 
+3. 
+
+## 数据来源
+
+| 序号 | 来源 | 链接 | 可信度 |
+|------|------|------|--------|
+| | | | |

package/template/docs/discovery/templates/user-pain-points-template.md

@@ -0,0 +1,49 @@
+# 用户痛点分析
+
+> 数据来源：应用商店评论、社交媒体、客服社区、行业报告
+
+## 数据收集概览
+
+| 渠道 | 收集数量 | 有效样本 | 时间段 |
+|------|---------|---------|--------|
+| App Store 评论 | | | |
+| 微博讨论 | | | |
+| 小红书笔记 | | | |
+| 客服社区 | | | |
+
+## Top 10 用户痛点
+
+| 排名 | 痛点描述 | 严重程度 | 频率 | 影响面 | 用户原话 |
+|------|---------|---------|------|--------|---------|
+| 1 | | 🔴 高 | 日频 | 全部用户 | |
+| 2 | | 🔴 高 | | | |
+| 3 | | 🟡 中 | | | |
+| ... | | | | | |
+
+## 痛点分类
+
+### 功能痛点
+- 
+
+### 体验痛点
+- 
+
+### 信任痛点
+- 
+
+## 未被满足的需求
+
+（竞品都没有做好的点）
+
+| 需求 | 描述 | 证据 |
+|------|------|------|
+| | | |
+
+## 机会假设
+
+基于痛点推导的产品方向：
+
+1. **假设 1**：[方向] → 待验证
+2. **假设 2**：[方向] → 待验证
+
+## 附录：数据采集方法

package/template/docs/implementation/.gitkeep

@@ -0,0 +1 @@
+

package/template/docs/process/MATT-POCOCK-ENGINEERING-SKILLS.md

@@ -0,0 +1,197 @@
+# Matt Pocock Engineering Skills 集成与使用说明
+
+> 来源：<https://github.com/mattpocock/skills/tree/main/skills/engineering>
+> 项目内置快照：`272f99b22574f50e4266791c86b9302682970e23`
+
+本文说明本模板如何使用 Matt Pocock `skills/engineering` 作为默认轻量研发流程。它不是代码库依赖，而是 Agent 可读取和执行的操作规程，用来把模糊需求逐步转化为 PRD、OpenAPI 契约、垂直切片 Issue、TDD 实现、审查和验证证据。
+
+## 1. 总体定位
+
+Matt Pocock Engineering Skills 是一组小而可组合的工程工作流。本仓库用它替代重型流程编排，并保留 YSS 专项技能、OpenAPI 3.1 契约和轻量 OpenSpec-style Spec Delta。
+
+| 本模板层级 | 默认能力 | 说明 |
+|---|---|---|
+| 需求与任务 | `competitive-intelligence`、`grill-with-docs`、`to-prd`、`to-issues` | 收集竞品 / 市场事实、澄清需求、沉淀 PRD、拆端到端垂直切片 |
+| 契约层 | OpenAPI 3.1 Draft / Freeze、OpenSpec-style Spec Delta | 前后端契约、行为差异、验收场景和契约测试输入 |
+| 方法论层 | `implement`、`tdd`、`diagnosing-bugs`、`code-review` | 实现、红绿重构、Bug 诊断和独立审查 |
+| 架构与领域 | `domain-modeling`、`codebase-design`、`improve-codebase-architecture` | 领域语言、深模块设计、架构治理 |
+| 协作层 | `triage`、Issue tracker、Git checkpoint | 分诊、同步状态、记录验证证据 |
+
+## 2. 标准执行流程
+
+### 2.1 需求交付流程
+
+| 项 | 内容 |
+|---|---|
+| 触发语 | “做一个功能”、“把这个想法落成需求”、“生成 PRD/Issue”、“可以开始实现” |
+| 使用 skills | `competitive-intelligence`（需要竞品 / 市场事实时）、`grill-with-docs`、`domain-modeling`、`to-prd`、`to-issues`、`implement`、`tdd`、`code-review` |
+| 输入 | 业务想法、发现报告、用户故事草案、干系人讨论记录 |
+| 输出 | PRD、OpenAPI 3.1 Spec、垂直切片 Issue、实现与测试 |
+| 落点 | `docs/requirements/`、`docs/api/specs/`、GitLab / GitHub Issues、`CONTEXT.md`、`docs/adr/` |
+| 人工确认点 | PRD 范围、OpenAPI 契约、Issue 粒度、安全红线、最终 Review |
+
+执行顺序：
+
+```text
+competitive-intelligence (when market / competitor facts are needed)
+  -> grill-with-docs
+  -> domain-modeling
+  -> to-prd
+  -> OpenAPI 3.1 Draft
+  -> OpenSpec-style Spec Delta (medium/high-risk behavior changes)
+  -> Engineering Baseline / YSS DDD review
+  -> Architecture / Data Design Review
+  -> OpenAPI 3.1 Freeze
+  -> to-issues
+  -> implement with tdd
+  -> code-review / fresh verification
+```
+
+门禁：
+
+- PRD 进入开发前必须明确用户故事、验收条件、OpenAPI 影响和测试决策。
+- 任何 API 变更必须先在 `docs/api/specs/*.yaml` 形成 Draft，经工程基线、系统 / 数据架构和设计审查后 Freeze，再进入实现。
+- API、权限、状态机、数据模型、跨端、新模块或高风险行为变化，应在 Design Review / OpenAPI Freeze 前补 OpenSpec-style Spec Delta；它只描述行为差异、验收场景和测试映射，不恢复 OpenSpec 工具链。
+- OpenAPI Freeze 后进入 `to-issues` 或等价垂直切片拆分；Issue 必须可以独立 demo 或验证。
+- 后端新服务或新模块必须先确认 YSS DDD 工程基线；从零创建服务时优先使用 `yss-ddd-scaffold-generator`。
+- `to-issues` 只能产出可独立验证的垂直切片，不允许只按 Adapter / Application / Domain / Infrastructure 横向拆分。
+- 涉及安全红线时，Issue 必须标注 `ready-for-human` 或 `TODO-HUMAN-REVIEW`。
+
+### 2.2 Bug 修复流程
+
+| 项 | 内容 |
+|---|---|
+| 触发语 | “报错了”、“测试失败”、“性能变慢”、“偶现问题”、“帮我 debug” |
+| 使用 skills | `diagnosing-bugs`、`tdd`、必要时 `domain-modeling` |
+| 输入 | 报错信息、复现步骤、日志、失败测试、性能指标 |
+| 输出 | 可复现反馈命令、最小复现、假设列表、回归测试、修复说明 |
+| 落点 | 测试文件、Issue/PR 评论、审查报告、必要时 ADR |
+| 人工确认点 | 无法复现、缺少环境、触碰安全红线、需要生产插桩 |
+
+门禁：
+
+- 不得先猜原因再改代码；必须先建立能捕获原始症状的反馈命令。
+- 修复前必须把最小复现转成回归测试；如果没有合适 seam，必须记录为架构问题。
+- 临时 debug 日志必须带唯一前缀，完成后删除。
+
+### 2.3 架构治理流程
+
+| 项 | 内容 |
+|---|---|
+| 触发语 | “这个模块难改”、“帮我看架构”、“哪里可以重构”、“测试很难写” |
+| 使用 skills | `improve-codebase-architecture`、`codebase-design`、`domain-modeling`、必要时 `grill-with-docs` |
+| 输入 | 代码结构、测试痛点、维护痛点、ADR、领域词汇表 |
+| 输出 | 架构深度报告、deepening candidate、接口/seam 设计、ADR |
+| 落点 | `docs/architecture/`、`docs/adr/`、`CONTEXT.md`、后续 Issue |
+| 人工确认点 | 是否采纳候选重构、是否重开已有 ADR、是否投入 Sprint |
+
+门禁：
+
+- 架构建议必须使用 `module`、`interface`、`seam`、`adapter`、`depth`、`leverage`、`locality` 术语。
+- 只有难以回滚、非显而易见、存在真实取舍的决策才写 ADR。
+- 与既有 ADR 冲突时必须显式指出，并说明为什么值得重新讨论。
+
+### 2.4 Issue 分诊流程
+
+| 项 | 内容 |
+|---|---|
+| 触发语 | “看下 issue”、“分诊这些需求”、“哪些可以给 Agent 做”、“把 #42 准备好” |
+| 使用 skills | `triage`、必要时 `grill-with-docs`、`domain-modeling`、`diagnosing-bugs` |
+| 输入 | GitLab / GitHub Issue、评论、标签、复现步骤、需求背景 |
+| 输出 | 分类标签、状态标签、triage notes、agent brief、关闭说明 |
+| 落点 | GitLab / GitHub Issues、`.out-of-scope/`、`CONTEXT.md`、`docs/adr/` |
+| 人工确认点 | 状态跳转异常、信息不足、拒绝请求、必须人工实现 |
+
+状态模型：
+
+- `needs-triage`：等待维护者评估。
+- `needs-info`：等待报告者补充信息。
+- `ready-for-agent`：已具备 Agent 独立执行条件。
+- `ready-for-human`：需要人工判断、权限或安全审查。
+- `wontfix`：明确不处理。
+
+## 3. Skills 分类
+
+### 3.1 一次性初始化
+
+| Skill | 用途 | 产物 |
+|---|---|---|
+| `setup-matt-pocock-skills` | 为仓库配置 issue tracker、triage label、领域文档布局 | `docs/agents/issue-tracker.md`、`docs/agents/triage-labels.md`、`docs/agents/domain.md`，并在 `AGENTS.md` 增加 Agent skills 区块 |
+
+本仓库已完成项目内置安装。后续升级应按固定快照同步，并在 Git diff 中检查技能目录变化。
+
+### 3.2 需求到交付主流程
+
+| Skill | 触发场景 | 核心动作 | 推荐落点 |
+|---|---|---|---|
+| `ask-matt` | 不确定该走哪个流程 | 路由到合适 skill | 作为入口说明 |
+| `competitive-intelligence` | 需要竞品、替代方案、定价、定位、用户口碑或市场事实 | 基于公开来源形成竞品情报、证据表、竞品矩阵和 PRD 输入 | `docs/discovery/reports/` |
+| `grill-with-docs` | 想法还不清晰，需要追问 | 结合领域建模持续追问，沉淀 glossary / ADR | `CONTEXT.md`、`docs/adr/` |
+| `to-prd` | 已有对话，需要整理成 PRD | 不再访谈，直接合成 PRD 并发布到 issue tracker | `docs/requirements/` 或 Issue |
+| `to-issues` | PRD / 计划需要拆任务 | 拆成可独立领取的垂直切片 Issue | Issue tracker |
+| `implement` | 按 PRD 或 Issue 实现 | 业务行为默认按 TDD 推进；生成代码、配置或一次性原型说明例外和验证方式；最后 independent review + fresh verification + commit | 当前代码分支 |
+
+### 3.3 编码与验证
+
+| Skill | 用途 | 关键要求 |
+|---|---|---|
+| `tdd` | 红绿重构式开发 | 一次只写一个行为测试；测试公共接口，不测实现细节；使用垂直切片 |
+| `diagnosing-bugs` | Bug / 性能问题诊断 | 先建立红/绿反馈闭环，再复现、最小化、假设、插桩、修复和回归测试 |
+| `prototype` | 用一次性原型回答设计问题 | 逻辑原型用终端小程序，UI 原型用可切换多方案页面；结论沉淀后删除或吸收 |
+| `resolving-merge-conflicts` | 处理 merge / rebase 冲突 | 理解双方意图，保留两边真实目的，跑检查，完成 merge/rebase |
+| `code-review` | 审查实现是否符合标准和规格 | 从固定 diff 基准出发，分别审查 coding standards 和 spec fidelity |
+
+与本仓库测试要求的对应：
+
+- Domain / Application 层高覆盖要求可以用 `tdd` 的公共接口测试原则落实。
+- Bug 修复必须先产生能捕获原始症状的反馈命令。
+- OpenAPI 变更应优先补充契约测试，再实现前后端。
+- 原型代码必须明确标记为 throwaway，避免进入生产路径。
+
+### 3.4 架构和领域建模
+
+| Skill | 用途 | 核心概念 |
+|---|---|---|
+| `domain-modeling` | 建立和修正领域模型 | `CONTEXT.md` 只记录业务词汇，不记录实现细节；重大且不可逆决策才写 ADR |
+| `codebase-design` | 设计深模块和测试 seam | module、interface、implementation、depth、seam、adapter、leverage、locality |
+| `improve-codebase-architecture` | 扫描架构摩擦，输出 HTML 报告 | 找浅模块、坏 seam、难测区域，并提出 deepening opportunities |
+
+## 4. 模板资产与落点
+
+| Engineering Skills 产物 | 本模板建议位置 |
+|---|---|
+| PRD | `docs/requirements/`，必要时同步到 Issue |
+| OpenAPI 契约 | `docs/api/specs/` |
+| ADR | `docs/adr/` |
+| 架构方案 | `docs/architecture/` |
+| 测试策略 | `docs/testing/` |
+| Sprint / Standup / Retro | `docs/process/` |
+| Issue tracker 配置 | `docs/agents/` |
+| 领域词汇表 | 根目录 `CONTEXT.md` |
+
+## 5. 门禁与验收规则
+
+### 5.1 PRD Ready
+
+- [ ] 问题陈述与解决方案明确。
+- [ ] 用户故事覆盖主要用户路径。
+- [ ] 验收标准可验证。
+- [ ] OpenAPI 影响明确为“无”或列出 Draft spec 文件；进入开发前必须 Freeze。
+- [ ] 测试决策明确测试 seam。
+- [ ] AI / 人工审查点标注安全红线和人工确认点。
+
+### 5.2 Issue Ready
+
+- [ ] Issue 是一个端到端垂直切片。
+- [ ] 完成后可独立 demo 或验证。
+- [ ] Blocked by 清楚。
+- [ ] 测试命令和 fresh verification 方式清楚。
+- [ ] 涉及 OpenAPI 时引用 Freeze 记录。
+
+### 5.3 Implementation Ready
+
+- [ ] `yss-router` 已选择最小 YSS skill 集合。
+- [ ] Build Architecture Checklist 已绑定当前切片。
+- [ ] TDD 适用性已明确；若例外，说明验证方式。
+- [ ] 安全红线和人审点已标注。
+- [ ] 实现仓库、分支、测试命令和回滚点清楚。

package/template/docs/process/PDCA-SCRUM.md

@@ -0,0 +1,186 @@
+# PDCA × Scrum × AI — 研发流程管理框架
+
+> **PDCA 是持续改进的引擎。Scrum 是交付节奏的骨架。AI 是每个环节的加速器。**
+
+---
+
+## 一、整体架构
+
+```
+                          ┌──────────────────────────────────────┐
+                          │           产品愿景 (Vision)            │
+                          └────────────────┬─────────────────────┘
+                                           │
+          ┌────────────────────────────────┼────────────────────────────────┐
+          │                                ▼                                │
+          │   ┌────────────────────────────────────────────────────────┐   │
+          │   │                  Sprint 循环 (2周)                       │   │
+          │   │                                                        │   │
+          │   │   P (Plan)          D (Do)         C (Check)    A (Act) │   │
+          │   │   ─────────        ───────         ──────────   ─────── │   │
+          │   │   Sprint          TDD 编码         Sprint       Sprint  │   │
+          │   │   Planning         AI Review       Review       Retro   │   │
+          │   │   ─────────        ───────         ──────────   ─────── │   │
+          │   │   需求拆解         前后端并行        Demo 展示    改进计划  │   │
+          │   │   任务估算         AI 自测          质量检查    知识沉淀   │   │
+          │   │   容量规划         持续集成         反馈收集    流程优化   │   │
+          │   └────────────────────────────────────────────────────────┘   │
+          │                                │                                │
+          │                                ▼                                │
+          │                   可工作软件 + 改进措施                           │
+          └────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## 二、PDCA 在 AI 增强研发中的具体映射
+
+### P — Plan（计划）
+
+| Scrum 活动 | AI 增强 | Agent | 产出物 |
+|-----------|---------|-------|--------|
+| Product Backlog 梳理 | AI 从发现报告生成 Epics 和 User Stories | Plan Agent | 优先级排序的 Backlog |
+| Sprint Planning | AI 建议 Sprint 容量，拆分任务 | Plan Agent | Sprint Backlog |
+| 任务估算 | AI 基于历史数据预测 Velocity | Plan Agent | 估算 Story Points |
+| 风险识别 | AI 标注高风险任务 | Plan Agent | 风险清单 |
+
+**AI-Human Loop in Plan：**
+```
+PO 提出 Sprint Goal → AI 拆解 Backlog → 团队 Review → AI 生成 Sprint Backlog → PO 确认
+```
+
+### D — Do（执行）
+
+| 活动 | AI 增强 | Agent | 产出物 |
+|------|---------|-------|--------|
+| 每日编码 | TDD 循环 + 前后端并行 | Code Agent × 2 | 代码 + 测试 |
+| 每日站会 | AI 自动汇总昨日完成/今日计划/阻塞项 | Standup Agent | Daily Standup 摘要 |
+| 代码审查 | 独立审查 + 安全扫描 | Review Agent × 2 | 审查报告 |
+| 技术障碍 | AI 辅助调试 + 方案建议 | Debug Agent | 解决方案 |
+
+**AI-Human Loop in Do：**
+```
+开发者领取任务 → Code Agent 生成代码（TDD）→ Review Agent 独立审查
+→ 开发者 Review + 修复 → 合并
+```
+
+### C — Check（检查）
+
+| 活动 | AI 增强 | Agent | 产出物 |
+|------|---------|-------|--------|
+| Sprint Review | AI 生成 Demo 脚本 + 实际 vs 计划对比 | Review Agent | Sprint Review 报告 |
+| 质量检查 | CI 流水线 + 覆盖率报告 + AI 质量评分 | Test Agent | 质量仪表板 |
+| Bug 趋势 | AI 分析 Bug 趋势和热点模块 | Ops Agent | Bug 分析报告 |
+| 用户反馈 | AI 聚合用户反馈 + 情感分析 | Insight Agent | 反馈摘要 |
+
+**AI-Human Loop in Check：**
+```
+Sprint 结束 → AI 生成质量报告 → 团队 Demo → 干系人反馈
+→ AI 汇总反馈要点 → 输入下一 Sprint Planning
+```
+
+### A — Act（改进）
+
+| 活动 | AI 增强 | Agent | 产出物 |
+|------|---------|-------|--------|
+| Sprint Retro | AI 分析 Sprint 数据，建议改进项 | Retro Agent | Retro 报告 |
+| 知识沉淀 | AI 将教训写入 AGENTS.md + Skill | Knowledge Agent | 更新的规范和 Skill |
+| 流程优化 | AI 建议流程调整 | Retro Agent | 改进 Action Items |
+| 技术债管理 | AI 追踪技术债，建议偿还时机 | TechDebt Agent | 技术债看板 |
+
+**AI-Human Loop in Act：**
+```
+Sprint 数据 → AI 生成 Retro 报告 → 团队讨论 → AI 记录 Action Items
+→ AI 更新 AGENTS.md / Skills → 下次 Sprint 自动生效
+```
+
+---
+
+## 三、Scrum 节奏与 AI Agent 编排
+
+### Sprint 0：项目启动（1-2 周）
+
+```
+Week 1: 发现阶段
+  ├── Day 1-2: Market Agent     → 市场分析报告
+  ├── Day 3-4: Competitor Agent → 竞品功能矩阵
+  └── Day 5:   User Insight Agent → 用户痛点报告
+
+Week 2: 初始化
+  ├── Day 1: 商业论证（整合发现阶段产出）
+  ├── Day 2: 架构设计（Architecture Agent）
+  ├── Day 3: 技术选型、CI/CD 搭建
+  └── Day 4-5: Product Backlog 初始化（Plan Agent）
+```
+
+### Sprint 1-N：迭代交付（2 周一 Sprint）
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│                      Sprint N (2 周)                        │
+├──────────┬──────────┬──────────┬──────────┬────────────────┤
+│   Day 1  │ Day 2-8  │  Day 9   │  Day 10  │  持续活动       │
+│ Planning │ 开发+审查 │  Review  │  Retro   │                │
+├──────────┼──────────┼──────────┼──────────┼────────────────┤
+│ Plan     │ Review   │ Review   │ Retro    │ Daily Standup  │
+│ Agent    │ Agents   │ Agent    │ Agent    │ Agent (自动)    │
+│ 拆分任务  │ ×2 独立   │ 对比报告  │ 改进建议  │ 进度摘要        │
+│ 估算容量  │ 并行审查  │ 质量仪表  │ 知识沉淀  │ 阻塞标记        │
+└──────────┴──────────┴──────────┴──────────┴────────────────┘
+```
+
+### Sprint 各仪式中的 AI 角色
+
+| 仪式 | 频率 | AI 角色 | 人类角色 |
+|------|------|---------|---------|
+| **Sprint Planning** | Sprint 第 1 天 (4h) | AI 拆分 Backlog 项为任务，估算复杂度，建议 Sprint 容量 | PO 定义优先级，团队估算和承诺 |
+| **Daily Standup** | 每天 (15min) | AI 从 Git/Slack 自动汇总进度，生成 Standup 摘要 | 团队同步，解除阻塞 |
+| **Sprint Review** | Sprint 最后一天 (2h) | AI 生成 Demo 脚本，对比计划 vs 实际的差异 | 团队 Demo，干系人反馈 |
+| **Sprint Retro** | Sprint 最后一天 (1.5h) | AI 分析 Sprint 数据，建议改进项 | 团队讨论，确定 Action Items |
+| **Backlog Refinement** | Sprint 中期 (2h) | AI 为 Backlog 项补充验收条件、技术影响分析 | PO 和团队澄清需求 |
+
+---
+
+## 四、AI 驱动的 Sprint 度量
+
+### 自动采集指标
+
+| 指标 | 数据来源 | AI 分析 |
+|------|---------|---------|
+| Velocity | Sprint 完成的 Story Points | 趋势预测，容量建议 |
+| Cycle Time | Git commit 到 merge 的时间 | 瓶颈识别 |
+| Code Churn | 代码行数增删比 | 返工率分析 |
+| Bug Rate | Bug/Story Point | 质量趋势 |
+| AI 采纳率 | AI 生成代码被合并的比例 | Agent 效果评估 |
+| 测试覆盖率 | pytest --cov / vitest --coverage | 覆盖缺口警报 |
+
+### AI 每周自动产出（可通过 cronjob 定时生成）
+
+```python
+cronjob(
+    action="create",
+    schedule="0 9 * * 1",  # 每周一早上 9 点
+    prompt="分析上周 Sprint 数据，生成 Sprint 健康度报告：Velocity趋势/Bug率/覆盖率/AI采纳率/阻塞项",
+    deliver="telegram:..."
+)
+```
+
+---
+
+## 五、关键原则
+
+### 1. PDCA 不是一次性的，是每 Sprint 一次的
+每个 Sprint 都是一次完整的 P→D→C→A 循环。A 的产出（改进措施、知识沉淀）直接输入下一个 Sprint 的 P。
+
+### 2. AI 是加速器，人类是决策者
+- AI 负责：数据采集、分析建议、报告生成、任务拆分
+- 人类负责：优先级决策、架构审批、安全审核、最终承诺
+
+### 3. Scrum 仪式不能被 AI 取代
+Daily Standup 的价值在于团队同步和消除阻塞，AI 可以做摘要但**不能替代**人与人之间的沟通。同样，Retro 的核心是团队心理安全，AI 只提供数据支撑。
+
+### 4. 度量是为了改进，不是为了考核
+所有 Sprint 数据（Velocity、Bug Rate等）用于 PDCA 改进，**不用于个人绩效考核**。否则团队会 game the metrics。
+
+### 5. 知识沉淀是复利
+每次 Retro 的改进措施 → 写入 AGENTS.md / Skill → 下一个 Sprint 的 Agent 自动遵循 → 效率递增。

package/template/docs/process/harness-automation-candidates.md

@@ -0,0 +1,46 @@
+# Harness 门禁自动化候选清单
+
+本文记录 Harness 工程中适合自动化、半自动化或必须人工审查的门禁项。当前只形成 backlog，不实现脚本。
+
+## 分类原则
+
+- 可自动检查：输入、规则和失败条件明确，机器可以稳定判断。
+- 可半自动生成 checklist：机器能收集证据和生成问题，但放行需要人或 Agent 判断。
+- 必须人工审查：涉及安全红线、业务取舍、不可逆变更或责任确认。
+
+## 可自动检查
+
+| 编号 | 门禁 | 触发阶段 | 输入 | 输出 | 失败处理 | 人工接管点 |
+|---|---|---|---|---|---|---|
+| HAC-001 | active Issue change 完整性 | 6. 契约冻结与 Issue | `docs/requirements/issues/**`、`垂直切片 Issue 状态` | 缺失文件清单 | 阻止进入正式垂直切片 | change 命名或匹配关系不明确 |
+| HAC-002 | API 影响记录 / OpenAPI Draft / Freeze 文件存在性 | 5 / 6. API 相关阶段 | API 影响记录、`docs/api/specs/*.yaml`、Freeze 记录 | API 资产状态 | 要求补齐影响记录、契约草案、Draft / Freeze 或无 API 影响记录 | API 影响范围有争议 |
+| HAC-003 | Build Architecture Checklist 字段完整性 | 7. 垂直切片与 TDD 实现 | checklist 文档 | 缺失字段和未回勾项 | 阻止 build-ready 结论 | 架构约束是否适用需判断 |
+| HAC-004 | fresh verification 记录存在性 | 8. 验证发布与复盘 | verification 文档、Issue 评论、测试输出 | 验证证据摘要 | 阻止“完成 / 可合并 / 可发布”结论 | 验证范围是否足够需判断 |
+| HAC-005 | 阶段 checkpoint 字段完整性 | 每个主阶段结束 | checkpoint 记录 | 缺失字段清单 | 要求补齐后再推进 | Issue tracker 不可用或权限不足 |
+
+## 可半自动生成 checklist
+
+| 编号 | 门禁 | 触发阶段 | 输入 | 输出 | 失败处理 | 人工接管点 |
+|---|---|---|---|---|---|---|
+| HAC-101 | PRD Review 缺口 | 3. 业务 / PRD / 功能架构 | PRD、Discovery、CONTEXT | 用户、痛点、MVP、非目标、验收缺口 | 返回 PRD 补齐 | 业务优先级和非目标取舍 |
+| HAC-102 | Prototype Review 缺口 | 4. 产品设计与需求冻结 | 页面清单、状态矩阵、原型说明 | UI / 状态 / 权限 / API 反推缺口 | 返回产品设计 | 交互体验和视觉取舍 |
+| HAC-103 | Architecture Review 缺口 | 5. 系统 / 数据架构与工程契约设计审查 | 系统架构、数据架构、ADR、OpenAPI | 架构约束和风险清单 | 返回设计审查 | 服务边界、NFR、数据约束取舍 |
+| HAC-104 | 垂直切片拆分质量 | 7. 垂直切片与 TDD 实现 | Issue、tasks、实施计划 | 横向拆层风险、切片过大风险 | 返回计划修正 | MVP 范围和拆分优先级 |
+| HAC-105 | Skill 沉淀候选 | 8. 验证发布与复盘 | 复盘、重复动作、模板变更 | 模板 / 脚本 / Skill 候选 | 进入治理 backlog | 是否值得产品化 |
+
+## 必须人工审查
+
+| 编号 | 门禁 | 触发阶段 | 输入 | 输出 | 失败处理 | 人工接管点 |
+|---|---|---|---|---|---|---|
+| HAC-201 | 支付相关逻辑 | 任意阶段 | PRD、设计、代码草案 | `TODO-HUMAN-REVIEW` | Agent 只生成草案 | 产品 / 安全 / 研发负责人确认 |
+| HAC-202 | 数据库迁移 / DDL | 6 / 8. 架构与实现 | 数据架构、迁移模板 | 人审结论 | 不得自动执行迁移 | DBA / 架构负责人确认 |
+| HAC-203 | 认证 / 授权中间件 | 6 / 8. 架构与实现 | 权限模型、代码草案 | 人审结论 | fail-closed | 安全负责人确认 |
+| HAC-204 | 加密算法实现 | 任意阶段 | 需求或代码请求 | 禁止生成结论 | 停止实现 | 安全负责人确认替代方案 |
+| HAC-205 | SQL 原生查询 | 6 / 8. 架构与实现 | 查询草案、数据架构 | 人审结论 | Agent 只生成草案 | DBA / 安全负责人确认 |
+| HAC-206 | 公共基础库 API 变更 | 6 / 8. 架构与实现 | API 设计、影响面 | 人审结论 | Agent 只生成草案 | 架构负责人确认 |
+
+## 自动化 backlog 排序建议
+
+1. 先做存在性和字段完整性检查：HAC-001、HAC-003、HAC-004、HAC-005。
+2. 再做 checklist 生成：HAC-101 到 HAC-105。
+3. 安全红线只做识别和提醒，不做自动放行。