Project Blueprint

Project Blueprint

工程蓝图规划阶段:在设计阶段把"业务愿景"拆成两层——工程基线(恒常,必须全绿)与业务拼图地图(可变,按 L1/L2/L3 渐进展开),经用户确认冻结为 BP-1,之后的 project-dev 按冻结版本执行。

定位与边界

• 承接:已有代码库先完成 project-intake(docs/ + AGENTS.md 就位);全新项目直接进入。
• 输出:工程基线清单(常驻闸门) + 业务拼图地图(需求池) + BP 版本管理。
• 不做:不实现代码(那是 project-dev);不做现有代码盘点(那是 project-intake)。

核心原则

1. 工程与业务分离。工程完整度(骨架)恒常在场,业务(图案)可变;两者用不同机制管理,不进同一个池子。
2. 工程基线是闸门,不是待办。核对后写进 AGENTS.md 项目规则节,每轮开发强制过,不排队、不勾销。
3. 豁免走流程。基线条目改"不需要"必须三分类(不适用/推迟/替代) + 反方解释 + 用户确认,记录可审计,巡检复查。
4. 业务地图只规划近期。L1 方向层 / L2 近期层(带验收) / L3 远期层(只占位),禁止为 L3 写验收标准。
5. 验收分三级。V1 机器闸门 + V2 人工闸门 = 完成依据;V3 AI 自验只作补充,不作完成依据。
6. 计划有版本。冻结版本不可变,变更须记录 + 用户确认 + 发布新版本(BP-N+1)。
7. 认知沉淀回写。项目中学到的新工程块回写 references 模板库,所有项目自动继承。
8. 需求统一入池。蓝图核对、开发发现、AI 自发、用户提出的需求,一律登记 notes/backlog.md(唯一需求池);蓝图文档只做视图与引用,不重复维护需求明细。

阶段流程

1. 定类型:识别项目类型(工业/互联网/其他),加载 通用基线 + 对应类型变体。
2. 基线核对:逐条核对 已有/缺/豁免;缺块必须补,豁免走三分类流程。
3. 业务展开:愿景 → L1 方向层(成功标准) → L2 近期块(每块带验收) → L3 远期占位。
4. 用户确认:基线清单 + 业务地图 + MVP 范围(拼图框),逐块确认。
5. 冻结发布:写版本号 BP-1,历史归档,工程闸门写入 AGENTS.md 项目规则节。
6. 变更管理(持续):任何计划改动 → 变更记录 → 用户确认 → 发布 BP-N+1,禁止直接改冻结版本。

产物

notes/blueprint/
  baseline.md           # 工程基线清单(当前版本, 冻结后只读)
  puzzle-map.md         # 业务拼图地图(L1/L2/L3, 需求明细引用 notes/backlog.md)
  versions/             # 冻结历史版本 + 变更台账
  versions/CHANGELOG.md # 变更台账(内容/理由/影响/触发者/版本)

验收标准(结束闸门)

1. 基线核对完:逐条核对,豁免均三分类 + 反方解释 + 用户确认。
2. 地图分层齐:L1/L2/L3 齐备;L2 每块有 V1/V2 验收;L3 只有一句话方向。
3. MVP 明确:拼图框确定,第一版做哪些块、哪些推迟。
4. BP-1 冻结:版本号 + 日期 + 变更台账建立,冻结版本归档。
5. 闸门入册:工程基线写进 AGENTS.md 项目规则节,dev 每轮强制验收。

闸门过 → 进入 project-dev;开发中任何计划变更走 BP 版本流程。

后续

流程细节见 references/workflow.md;产物模板见 references/templates.md;通用工程基线见 references/engineering-baseline.md;行业变体见 references/industry-iot.md 与 references/industry-web.md。