generic-dev-sop

通用项目开发 SOP

把每项功能作为「计划、契约、UI、实现、测试、证据」同步交付的可追踪闭环；把整个项目作为「底座 → 纵向切片 → 阶段门禁」的迭代推进。除纯文案、无行为变化的单行修改外，不得跳过步骤；没有 UI 的后端/基础设施功能可跳过视觉设计稿，但必须在开发记录中说明原因。

适用场景与边界

该用：从零搭建并完整交付的新项目（前端 / 后端 / 跨端客户端 / 服务端）；需要规范化流程、多角色协作与质量门禁的中大型项目；希望每个功能「计划 → 实现 → 测试 → 证据」可追溯的团队。

已有项目迭代：不重新搭建，复用现有架构决策与质量底座；每个新需求仍按「分析需求 → 补充 UI 设计稿 → 划入任务计划（功能矩阵定 P0/P1/P2）→ 开发 → 审查验收」的第三部分闭环推进。计划缺失时先补最小计划（见第三部分第 1 步）。

不该用：纯文案或无行为变化的单行修改；已有仓库的快速小改动；一次性脚本、Demo、原型验证。这些场景直接改代码即可，不必走完整 SOP。

轻量用法：小型项目可只走「项目搭建 + 任务计划 + 单功能闭环」，跳过「完整交付」中的灰度、合规、回滚演练等门禁，并在 README 记录跳过原因。

快速上手

1. 说「用这个 SOP 从零搭一个 XX 项目」，并指定技术栈（或回车采用 default-stack.md 默认组合）。
2. 按 architecture-template.md 产出架构决策，按 task-plan-template.md 产出任务计划。
3. 每个功能按「第三部分」闭环交付，记录写入 references/features/<功能短名>.md。
4. P0 全绿后走「第四部分」发布候选、灰度回滚与交付检查。

状态仅使用：未开始、分析中、设计确认、开发中、审查测试中、已完成、阻塞。

生命周期总览

新项目按四步推进，功能闭环可循环执行，直到 P0 全部完成再进入交付：

一、项目搭建（架构决策 + 质量底座 + 记录机制）
  → 二、详细任务计划（阶段 / 任务 / 验收 / 门禁）
    → 三、单功能开发闭环 × N（确认计划→需求→方案→记录→设计稿→数据→开发→审查→回写）
      → 四、完整交付（发布候选 → 灰度回滚 → 文档同步 → 项目交付检查）

第一部分：项目搭建

新项目先搭底座，不直接堆业务页面。

1. 确认工程边界

• 新工程放独立目录、独立 package 边界；旧仓库只读，只作为功能与行为基线，禁止复制、import 或 workspace-link 旧实现。
• 固定包管理器与锁文件，全仓统一；开发与 CI 使用同一安装命令。
• 先确认新工程根目录，不要在旧仓库内覆盖创建。

2. 确认技术栈

启动开发前先与用户确认技术栈，避免中途返工：

• 按项目形态展示 references/default-stack.md 的默认组合作为推荐（Web/桌面、跨端移动、服务端各一套）。
• 用户指定技术栈（如「用 Vue」「用 Go」）→ 记录并以用户为准，写进 references/architecture.md 的「固定技术栈」节。
• 用户未指定或直接回车跳过 → 视为同意使用默认，采用 references/default-stack.md 的组合，并在架构决策中注明「默认技术栈，用户已确认跳过选型」。
• 确认结果与理由写入架构决策；后续所有实现按该栈执行，不重复争论选型。

3. 输出架构决策（按 references/architecture-template.md 创建 references/architecture.md）

• 产品边界：P0/P1/P2 与「明确不做」清单，冻结首版范围。
• 固定技术栈与理由；优先复用团队已验证的框架、分层与平台桥接模式，不重复发明。
• 技术栈选型：用户指定则以用户为准；未指定时默认采用 references/default-stack.md 的已验证组合，不重复争论选型。
• 目录结构与职责边界：技术职责先分层，业务再按模块归档；写入「允许/禁止」对照。
• 数据模型：主库选择、核心表/模型、稳定 ID 与时间约定、迁移与兼容策略。
• 接口契约：API 前缀、统一错误码格式、鉴权/RBAC、实时事件边界。
• 安全与隐私底线：密钥只存环境变量、日志脱敏、最小权限、审计留痕。
• 可行性风险与决策门：每项高风险能力列出 J0 必须验证的门槛。
• 决策结果写入 references/architecture.md，作为后续所有实现的依据；有改动同步更新。