🔴 P0 feat(templates): 项目蓝本闭环 —— 34 契约操作 + 32 用例，零表零路由零前端；含四项待裁（已推理，请 coord-main 定）

## 人类下达（2026-08-12）

> 后台的项目蓝本，目前还是测试数据……把项目蓝本的前端后台都实现了。最终这个项目蓝本的数据应该是人类创建的数据，然后可以给予项目蓝本来建立项目，**这个闭环必须要走通**。

人类同时授权：四项待裁由我（dev-project）推理出答案，走 coord-main 而不是打断人类。本 issue 即该推理 + backlog，**请 coord-main 裁定下方四项**，裁完我按 BP-01 开工。

## 与 #470 的边界（不是重复）

#470 正文逐字写着人类已裁：**「可视化模板」＝ canvas 白板模板（非 blueprint 蓝本）**。蓝本当时被明确划出该 epic。本 issue 是**新增范围**，与 #470 互补，形状与 #572（MCP：有契约有用例、中间那层没接）完全一致。

## 实测现状（origin/main = `54d9e340`）

会话中 main 从 89093f20 前进到 54d9e340，已复核蓝本面无新增实现（`c3b3e87d` 只动后台左栏去重，蓝本屏仍 mock）。

| 层 | 状态 | 依据 |
|---|---|---|
| 契约 | ✅ 34 个 operation，束已人类签核 | `packages/contracts/src/templates.ts`；`design-signoff.md` confirmed（yanbin shen, 2026-07-30） |
| 领域 | ✅ 15 项设计环节单源 + 生成器门控 | `apps/api/src/domain/templates/design-facet-table.ts:117-131` |
| 应用 | ✅ 32 个纯用例 | `apps/api/src/application/templates/` |
| **基础设施** | ❌ **零** | `infrastructure/` 下无 templates 目录 |
| **表/迁移** | ❌ **零** | migrations 只有 interview_templates / canvas_template_registry |
| **HTTP 路由** | ❌ **零** | 44 个 controller 里无 templates.controller.ts |
| 前端 ~2800 行 | ⚠️ 全壳 | 后台屏 mock `AG_BLUEPRINTS` + `NoBackendNotice`；`tpl/*` 12 屏 mock；`/project/new` 九宫格禁用 |

**32 个用例、34 个契约操作，一个都接不上电**——端口定义齐全，零实现类。

## ⚠️ 七条 passing 名不副实（请一并裁处理方式）

`F17/F18/F22/F23/F28/F29/F30` 全标 `passing`，但 verification 全是纯用例单测 + mock UI 单测，没有一条碰 HTTP 或 DB。最刺眼的 F23：

- **behavior**：「点新建项目选一个已发布蓝本 → 一次性把六类默认值写进新项目」
- **verify**：3 条纯函数 vitest + 1 条 mock UI 测

该行为**今天在产品里走不到**（无蓝本表、无已发布蓝本可选）。按 AGENTS.md 完成定义第 1 条（行为真实可见、端到端可复现），这七条是**层内通过、闭环不成立**。

**我的建议**：不撤销（单测确实真、有价值），但承认其 evidence 只覆盖领域层，闭环由本 backlog 的 BP-10 补 e2e 承担。我不碰 status（agent 不得手改）。

---

# 四项待裁（含我的推理与判据）

## ① T9 两扇门 → **推荐：createProject 单门，本版不实现 applyBlueprint**

契约里 `project.createProject(blueprintVersionId)` 与 `templates.applyBlueprint`（POST /blueprints/:id/apply）都能建项目；契约自己标了 T9 隐患（两处都要维护「projects 一行 + 子类型表一行」原子性）。

判据：
1. 契约注释**已声明意图**：「容器创建的唯一入口在 project 束」，并给了理由。
2. `createProject.in` 已经有 `blueprintVersionId` 这个参数——若蓝本走 applyBlueprint，该参数就是死重。
3. **幂等已白拿**：`creationFingerprint` 已把 `blueprintVersionId` 纳入指纹（`create-project.ts:103-109`），所以不需要 applyBlueprint 的 `idempotencyKey`。
4. 唯一差额是 `tier`（applyBlueprint 允许套用时覆盖档位，createProject 无此参数）。**本版不做覆盖，项目继承蓝本版本快照里的档位** ⇒ **契约零 delta**。

将来真需要「套用时改档位」，再开 applyBlueprint 或给 createProject 补 tier，届时才付这个成本。

## ② D-2 必填清单 + T3 冲突 → **推荐：required = { flow-agenda } 一项**

15 个环节今天 `required` 全 false ⇒ 空白蓝本也能发布。而 T3 指出原型里 9/16、12/16 的蓝本也是「已发布」，与「必填未完成不能发布」冲突。

我去读了原型数据（`apps/web/lib/mock/tpl.ts:515-526`），**冲突是假的**：

| 蓝本 | 完成度 | 状态 | 卡在哪 |
|---|---|---|---|
| bp-hmw | 16/16 | published | — |
| bp-diag | 15/16 | published | — |
| bp-strat | 15/16 | published | — |
| bp-bmc | 14/16 | published | — |
| **bp-sprint** | **13/16** | **published** | — |
| bp-hypo | 12/16 | **draft** | `draftHint: "试跑一场后才能发布"` |
| bp-review | 9/16 | **draft** | `draftHint: "试跑一场后才能发布 · …"` |

两条草稿的 hint 逐字说卡在**试跑**，不是完成度；而 13/16 的 bp-sprint 已发布，证明**未完成项不阻断发布**。⇒ 原型里真正咬合的门是 **AC3a「已试跑」**，完成度只显示不设门。

那 required 该放几项？判据是「哪一项缺了会让产出的项目成为空壳」：
- **flow-agenda（流程 Agenda）**：缺了，套用出来的项目**零议程环节**，直接违反 F23 的行为承诺「打开即有完整议程环节（数量=所选档位）」。
- 原型 7 条蓝本（含两条草稿）**全部有议程**（4–19 环节），所以把它设为必填**不会误伤任何一条原型数据**——可反证。
- 其余 14 项缺了只是内容少，不产生空壳。

⇒ `required = { flow-agenda }`，恰好一项。既让 I-6 的机制真实可触发（`required-column-drives-gate.test.ts` 不再空转），又与原型零冲突。

## ③ T2 维护者谓词 → **推荐：复用 `canMutateCapabilities`（org admin），不新造角色**

判据：蓝本是后台「AI 能力」六类 AssetKind 之一（F132 已把它纳入双向相等门控）。姊妹资产的既有谓词：
- 画布模板：`requireTemplateAdmin` → `canMutateCapabilities`（`bind-template-to-segment.ts:23-24` 逐字）
- Skill 版本编辑：`membership.orgRole !== "admin"` 即拒（`edit-skill-version-content.ts:88-91`）
- `canMutateCapabilities` 定义：`orgRole === "admin"`（`capability-listing.ts:114-116`）

六类资产里五类已是 org admin，蓝本另造一套维护者角色＝**同一事实第二处声明**，本仓已因此漂移五次。

## ④ 16 vs 15 环节 → **裁：15 项是对的，第 16 项 `basic-overview` 不是配置项**

人类截图原型是 16 环节，领域定义表 15 项。差额已定位：mock 里第 16 行是
`{ key: "basic-overview", label: "基本配置", count: "" }`（`tpl.ts:94`）——它 `count` 为空，其余 15 项都有计数（"7 环节"/"4 组"/"18 页"）。⇒ 它是**设计器的概览落地页**，不是可填可完成的配置槽位。领域表砍掉它是对的。

（PJ-11「重新推理 16 环节哪些第一版必要」仍按原计划走设计+签核，本裁决只解决口径差异。）

---

# Backlog：BP-01 → BP-10

估时标尺：已完成的 project 束（F116–F128）＝ 773 行 pg 仓储 + 676 行 controller + 9 迁移。当量 ＝ 一个 feature 从开工到 PR 合入。

| id | 内容 | 依赖 | 当量 |
|---|---|---|---|
| BP-01 | 蓝本表 + 迁移 + pg 仓储 + `POST/GET /blueprints` | 裁③ | 2 |
| BP-02 | 设计环节读写 `PUT design-facets/:key` + `getDesignerShell` | BP-01 | 1.5 |
| BP-03 | 时长档位 / 形式语言 / 模型策略三个写端点 | BP-01 | 1 |
| BP-04 | 发布版本 `POST /versions` + 快照不可变 + 门槛（试跑 ∧ required） | BP-02, 裁② | 2 |
| BP-05 | 后台「项目蓝本」列表接真（撤 mock + 撤 NoBackendNotice） | BP-01 | 1 |
| BP-06 | 蓝本设计器接真（15 环节保存 + 完成度真实派生）＝ PJ-11 实现段 | BP-02 + PJ-11 签核 | 2 |
| BP-07 | `initialization-preview` 接真（AC2 逐项对得上） | BP-02 | 1 |
| BP-08 | createProject 带 blueprintVersionId 真执行六类初始化（事务 + 幂等 + 快照绑定） | BP-04, 裁① | 2.5 |
| BP-09 | `/project/new` 九宫格接真、撤禁用态 ＝ PJ-12 | BP-08 | 1 |
| BP-10 | **闭环 e2e**：人类建蓝本 → 发布 → 建项目选它 → 项目真有议程环节 | BP-09 | 1 |

合计 **≈ 15 当量**。

**时间**：单 agent 串行 ≈ 15–20 个工作时段；BP-01 落地后 BP-02/03/05 可并行到 3 条线 ⇒ ≈ 8–11 个时段。硬约束：`apps/web/lib/mock/project.ts` 是六 tab 共用热点，前端接真栈必须串行。

**风险**：① 裁①若改判「双入口都实现」，BP-08 当量 2.5 → 4+；② 裁②若改判必填多项，BP-04 要连带补门槛反证套件；③ 七条假 passing 若定为「撤销重验」，额外 +3~4 当量。

## 与 PJ 线的关系

本 backlog 的 BP-09 ＝ 原 PJ-12，BP-06 ⊃ 原 PJ-11。P0 前端接线（PJ-02~PJ-05）不受影响，可继续串行推进。

/cc @coord-main —— 请裁 ①②③④ 与七条 passing 的处理方式；裁完我从 BP-01 开工。

Start with packages/contracts/src/templates.ts, apps/api/src/domain/templates/design-facet-table.ts, and the use cases under apps/api/src/application/templates/. Review the existing mock surfaces in apps/web/lib/mock/tpl.ts and apps/web/lib/mock/project.ts, then run required-column-drives-gate.test.ts. Done requires the four pending decisions and the seven passing items to be resolved before the BP-01–BP-10 implementation can be completed and verified end to end.

Written by the indexing model from the issue text.