---
name: specdev-building
description: 在需要为某个已有 SpecDev 业务清单的项目生成或重建数字房蓝图时使用：读 docs/specdev 的项目与全部业务，按已有四种户型为每个业务安排房间，写出唯一的 docs/specdev/building.json，再用建筑诊断命令行逐项修正后交作者进房验收。也用于按作者要求调整项目级整栋 building.json 的房间数量、尺寸或户型；独立房间、家具及 room.json 用 specdev-room。写业务规格文档、workflow 图与节点详情用 specdev-business；业务关系（管道）、源码逆向推断业务、发明新房型、替作者决定业务取舍或面积分档都不在本技能范围。纯讨论、普通问答和只读审查不触发本技能。
---

# SpecDev Building（建筑布置）

把**项目清单**变成**一栋能走进去的房子**：产出唯一一个文件 `docs/specdev/building.json`（建筑蓝图）。本文件是入口，只管顺序、纪律和交付边界；字段、户型算术、诊断修法在各参考文件里，按需读取，不在此重复。

房子的内容（项目名、业务名、业务介绍、资料目录、门牌上的字）**不写在蓝图里**——由插件从项目清单注入。蓝图只安排空间：楼层、房间、门窗、楼梯、屋顶、入口。

## 适用范围

- **用本技能**：为已有 `docs/specdev/project.json` 与业务目录的项目建房，或按作者要求调整已有项目级整栋 building.json（加/减房间、改尺寸、换户型）；独立房间底座选择、家具布置和 room.json 交 specdev-room。
- **不做的**：业务关系与管道界面；读源码推断业务重要性；发明样板之外的新户型；替作者决定业务取舍（哪个业务该在清单里）与面积分档；补清单缺件（缺 `project.json`／`business.json` 指向 `specdev-business` 或作者）；改插件代码与生成器。
- **纯讨论交方案**：作者问"有没有办法／有什么建议"时交付方案，不动手。

## 唯一产物与边界

1. 只写 `docs/specdev/building.json` 一个文件，不新建、不改动清单里的任何其它文件。
2. **改已有蓝图按授权走**：作者已经明确要求加房、改尺寸或换户型时，按授权范围直接改，并在报告里写明改了哪几处；**没有**这类明确要求而要重建或覆盖别人的蓝图时，先给方案等作者裁决。
3. 蓝图里不写项目名、业务名、介绍、资料路径——那是清单的事，写进来只会与清单打架。
4. 不代作者声明实现状态：`implementation: present`、`tests: passed`、`acceptance: passed` 都要有真实出处，否则留默认（样板的 `construction` 块就是安全默认）。

## 主流程（按序执行）

1. **确认目标**：项目仓库根（必须是 Git 仓库顶层）与分支状态。工作区标识不是开工前置，也**不是本技能能自己查到的信息**（它只出现在作者从 DSH 侧栏进管理页的链接里），只在交付页面入口时用到，见"交付报告"第 5 条。
2. **勘察清单**：读 `docs/specdev/project.json` 和每个 `docs/specdev/<业务>/business.json`，列出「业务 id／名称／一句话职责／资料数（文档 × 图）」。
   - **资料数怎么数**（与插件清单同一口径，不要另立数法）：**文档数**＝该业务 `business.json` 的 `docs` 数组里非空字符串的条数；**图数**＝该业务目录下的**子目录个数**（目录名就是图编号，`chart.json` 缺失或坏也照样算一张，只是诊断会另报 `MATERIAL_UNREADABLE`）。全部业务的「文档＋图」之和＝诊断输出里的「资料入口 N 条」，拿它对数。
   - 清单缺件、`business.json` 坏、业务目录名含中文或其它写不进蓝图的字符（**业务 id 就是业务目录名**，而蓝图的 `businessId` 只接受 `^[A-Za-z0-9][A-Za-z0-9._-]*$`）→ **停下报告**，不自己补、不自造业务 id。
3. **定户型**：按下方选型规则挑一份样板，说明理由（作者可否决）。
4. **出设计表**：业务 → 房间 id → 面积档 → 所在层。房间 id 由业务 id **归一化**得到（转小写、`.`／`_` 换成 `-`、加 `room-` 前缀）；**不要直接拿 `businessId` 当房间 id**（业务 id 允许大写和点，蓝图 id 不允许）；归一化后若重名（如 `a.b` 与 `a-b`）就在后一个上加 `-2`／`-3`，保证全文件唯一。房间排列用**清单顺序**＝`docs/specdev/` 下业务目录名的字典序（`row` 一族从西到东、`tower` 按它分层），作者另有指定时从作者并在报告里写明。**面积档只写在报告里**——蓝图没有档位字段，档位不落盘。
5. **写蓝图**：以样板为骨架，照抄结构、按递推表改数量与坐标（见 [layouts.md](references/layouts.md)）。风格取下方选型表的"风格"列；`defaults`／`prototype`／`wallType`／`accent` 这些可选字段**默认不写**——省略就是取契约里的缺省值，**显式写出与缺省相同的值才是等价的**；**改值就会改几何**（墙厚、楼板厚参与构件尺寸与楼层净空，门高参与门洞与漫游落点），别凭空填（取值范围见 [blueprint-contract.md](references/blueprint-contract.md)）。字段与取值按契约核对一遍再落盘。
6. **跑诊断**，按码逐项修：
   ```
   node "<插件包根>/dist/check-building.js" <项目仓库根>
   ```
   退出码 `0` 通过（可含 warning）、`1` 有 error、`2` 读不了。每条 error 都带 `subject.path` 与「修复方向」；按 [diagnostics.md](references/diagnostics.md) 改，**一轮只修一类**，改完用同一条命令重跑。**同一问题两轮修不成**：停下，交证据与疑点给作者。
7. **交付报告**（固定格式，见下），交作者进房验收。

## 选型规则（区间不重叠；样板的业务 id 是演示值，必须逐个替换）

| 业务数 | 户型 | 风格 | 说明 |
|---|---|---|---|
| 0 | **不建房** | — | 清单里没有业务目录：停下报告并指向 `specdev-business`；确实要空院子由作者明确要求 |
| 1 | `single` 一间房＋前庭 | `warm-modern` | 不需要走廊——门直接开向前庭 |
| 2 | `row` 两间房＋走廊＋前庭 | `warm-modern` | 同一套递推，房间宽度可放宽 |
| 3–8 | `row` 一排房＋走廊＋前庭 | `warm-modern` | 默认 |
| 9–16 | `tower` 两层 | `warm-modern` | 每层 ≤8 间，按清单顺序前 ⌈N/2⌉ 间放一层 |
| >16 | **停下问作者** | — | 两层最多 16 间，超出 v1 户型能力 |
| 4–10 任意 | `court` 合院 | `chinese-timber` | 只在作者指定"要中庭/围合"时用，不参与自动选型 |

**风格只有两个取值**（`warm-modern`／`chinese-timber`），只影响配色与构件材质，**不影响布局、几何与诊断**；上表就是各户型样板的同款写法。作者另有指定时按作者指定，并在报告里写明。

要因场地或观感改选，在报告里说明理由，由作者确认或否决。

## 三条底线

1. **面积档由作者定**：默认全部基础档，交付报告逐间标"待作者定档"，**不宣称房间已有特色、不暗示已按价值排序**；不按代码量、文件数、文档长度推断业务价值。
2. **蓝图能生成 ≠ 房子能走通**：诊断通过只说明模型可生成。漫游手感、门牌点不点得开、观感如何，一律交作者在页面验收；不许把校验通过说成"已验收"。
3. **不越权**：业务取舍、面积分档、是否覆盖已有蓝图，都是作者的裁决——**未获修改授权时只提方案与理由；已获修改授权时按授权范围实施**（口径同"唯一产物与边界"第 2 条）。

## 按需读取

| 要做什么 | 先读 |
|---|---|
| 写蓝图前核对字段、取值、默认值 | [references/blueprint-contract.md](references/blueprint-contract.md) |
| 选定户型、算坐标、加房／改尺寸 | [references/layouts.md](references/layouts.md) ＋ `assets/layouts/*.json` |
| 看懂诊断、按码修 | [references/diagnostics.md](references/diagnostics.md) |

同一会话已读且未变化的内容直接复用；只展开当前步骤用到的文件。

## 交付报告（固定格式）

1. **文件路径**：`docs/specdev/building.json`（新建或修改；改了哪几处）。
2. **设计表**：业务 ↔ 房间 id ↔ 面积档（逐间标"待作者定档"；蓝图里没有档位字段，档位只出现在这张表里）↔ 所在层；资料数（文档 × 图，数法见主流程第 2 步）；户型与风格的选择理由。
3. **诊断结果**：命令原文、退出码、最终 error/warning 条数；保留的 warning 逐条写明理由；修了几轮、每轮改了什么。
4. **未决项**：需要作者裁决的（面积档、是否保留某业务、是否覆盖旧蓝图），无则写"无"。
5. **页面入口与检查点**：页面路径 `/specdev-workbench/building`。**工作区标识不在本技能能取到的信息里**——它只出现在作者从 DSH 侧栏进管理页时的链接 `?workspace=<id>` 中（命令行诊断 `--json` 里的 `repo.workspaceId` 恒为空串）。按拿没拿到分两种写法：
   - 拿到（作者贴过含 `?workspace=` 的链接）→ 原样写全：`/specdev-workbench/building?workspace=<实际标识>`；
   - 没拿到 → **只写不带参数的路径**，并写明"请从 DSH 侧栏打开本项目的工作区，标识由侧栏带出"；也可以请作者贴一次链接再补全。
   - **不许编造标识，也不许把 `<工作区标识>` 这类占位符当成可点的链接交出去**——占位符只能出现在"待作者补"的说明里。
   另附建议作者重点看什么（走进每间房、点门牌、切完整外观、上楼）。
6. **提交状态**：分支与提交号，或注明"未提交，待验收"。
7. **未验证项**：明确写"漫游与观感未由本技能验证，待作者页面验收"。