既有 coding 场景草案，待按第二期活动设计适配。下列文档要求、审核角色与阶段门不自动成为新活动的统一要求。
V1 以人工运营为主。每个阶段都留下可审计产物，但不先建设复杂平台。
推荐 PR 序列
stage/01-prd-plan：澄清、PRD 与计划。stage/02-implementation：核心实现和基础测试。stage/03-evidence：运行证据、边界用例、文档收口。stage/04-rework：AI 预审返工（如需）。stage/05-live-change：临时新增需求（验收时创建）。stage/06-final：最终复盘与遗留问题。
基础自动检查在所有 PR 上检查目录、章节和常见敏感信息风险；只有 stage/06-final 分支触发严格检查，要求清理占位符并提供实际证据。各作业包可在此基础上增加自己的构建、测试和部署检查。
仓库权限与分支规则需在实际组织活动时确认；“自行合并”不等于通过。组织者只认私有验收台账中登记的仓库、PR 与 commit SHA。
澄清机制
- 业务歧义、范围冲突和外部依赖统一在“澄清 Issue”记录。
- 学员可以提出选项和推荐，但不能让 Codex 替代本人做最终取舍。
- 未及时回答的非阻塞问题，由学员记录可逆假设继续推进；会改变核心范围或造成外部风险的问题必须等待组织者确认。
- 口头澄清须在 Issue 或 PR 中补记，避免验收时争议。
技术讲解与追问
验收时学员需要在不依赖 Codex 代答的情况下说明：架构、关键数据流、测试策略、失败场景、取舍、AI 生成内容的核验方式，以及若再增加时间会如何改进。组织者可选择任一提交要求其解释或现场修改。