# 活动与 GitHub 阶段流程

> 既有 coding 场景草案，待按[第二期活动设计](../DESIGN.md)适配。下列文档要求、审核角色与阶段门不自动成为新活动的统一要求。

V1 以人工运营为主。每个阶段都留下可审计产物，但不先建设复杂平台。

| 阶段 | 学员动作 | 主要产物 | 阶段门 |
|---|---|---|---|
| 0. 领取作业 | 接收私有仓库，阅读边界 | 领取 Issue | 确认范围与禁用数据 |
| 1. Codex 澄清 / PRD | 用 Codex 辅助识别歧义，记录本人决策 | 澄清 Issue、`docs/PRD.md` | 关键假设可追溯 |
| 2. 实施计划 | 拆分里程碑、风险与验证方式 | `docs/PLAN.md` | 验收标准均有验证方法 |
| 3. 开发测试 | 分阶段实现、测试并留证 | 代码、测试、`docs/TEST_EVIDENCE.md` | 能按 README 复现 |
| 4. GitHub 阶段提交 | 每阶段从独立分支发 PR | PR、提交记录 | PR 描述完整，不直接提交 `main` |
| 5. AI 预审 | 回答问题、核验实现与证据 | 私有预审报告 | 问题按严重级别处理 |
| 6. 返工 | 修复同一 PR 或新返工 PR | 变更与复验证据 | 阻塞项清零或被明确接受 |
| 7. 安静领导验收 | 演示、技术讲解、现场追问 | 私有验收记录 | 安静给出阶段结论 |
| 8. 临时新增需求 | 现场接收组织者私有变更要求 | 新分支、PR、补充测试 | 新需求可运行、可解释、可回归 |
| 9. 最终评价 | 提交个人复盘 | `docs/RETROSPECTIVE.md`、私有结论 | 通过 / 返工 / 未达标 |

## 推荐 PR 序列

1. `stage/01-prd-plan`：澄清、PRD 与计划。
2. `stage/02-implementation`：核心实现和基础测试。
3. `stage/03-evidence`：运行证据、边界用例、文档收口。
4. `stage/04-rework`：AI 预审返工（如需）。
5. `stage/05-live-change`：临时新增需求（验收时创建）。
6. `stage/06-final`：最终复盘与遗留问题。

基础自动检查在所有 PR 上检查目录、章节和常见敏感信息风险；只有 `stage/06-final` 分支触发严格检查，要求清理占位符并提供实际证据。各作业包可在此基础上增加自己的构建、测试和部署检查。

仓库权限与分支规则需在实际组织活动时确认；“自行合并”不等于通过。组织者只认私有验收台账中登记的仓库、PR 与 commit SHA。

## 澄清机制

- 业务歧义、范围冲突和外部依赖统一在“澄清 Issue”记录。
- 学员可以提出选项和推荐，但不能让 Codex 替代本人做最终取舍。
- 未及时回答的非阻塞问题，由学员记录可逆假设继续推进；会改变核心范围或造成外部风险的问题必须等待组织者确认。
- 口头澄清须在 Issue 或 PR 中补记，避免验收时争议。

## 技术讲解与追问

验收时学员需要在不依赖 Codex 代答的情况下说明：架构、关键数据流、测试策略、失败场景、取舍、AI 生成内容的核验方式，以及若再增加时间会如何改进。组织者可选择任一提交要求其解释或现场修改。