product-planning：补「宿主」这一环（③段加规范 ＋ ①段第4问 ＋ ②段页面关系）

起因：某项目把「往宿主已有页加一块」做成了「另起一页」，宿主原有板块功能整块丢掉。
根子在链上游 —— ①段不问「长在哪」→ ②段不写宿主 → ③段没规范。

本机改 4 文件 / 8 处（附件那份报告只列了 7 处，漏了②段同一句定义的复述点）：
- ③段 references/execution-runbook.md：新增 §3.2b「宿主已有页面」——
  锁外壳（⛔ 不自造；判据=出现供给中不存在的导航类名即视为未复刻）→ 宿主原有功能逐项回归 →
  写进 DESIGN.md 的「必要内容／页面职责」。外壳基线按本机供给实况写：有快照用快照，
  没有就用 design-capture 补采，都拿不到则记偏离单 + 3d 证据缺口。
- ①段 references/stage-discovery/references/grill-me.md：交付形态支补第 4 问「它长在哪」
  （分支表／三问表→四问表／反面清单／输出检查清单 4 处同步）。
- ②段 create-prd.md 与 stage-requirements/SKILL.md：页面关系字段补「新功能挂在宿主哪一页」，
  取值补「宿主页 ＋ 新增块」；create-prd 操作细节补第 3 条。两处字段行逐字一致（⛔ 不复述成两个版本）。

⛔ 未采用附件第 3.1 条的改法（把③段能力边界改成"自带资产已含 9 页整页快照与 345 族"）：
本机 design-system-tiaoyue 只有 tokens/brand/components.md/library.json/design-system.html（1.6 MB，
277 族、9 页提取结果），没有 component-library/、没有 snapshot/*.html、没有 tiaoyue-all.css，
app-sidebar 仅作族名出现 2 次、w-16 与 rounded-[100px] 命中 0 ⇒ 本机那句「几何与版式不在包内」
与事实相符，照搬会写出新的不实陈述。两台机器各留一份、不强行对齐（用户 2026-10-13 选 C）。

验证：命名闸门 2061｜0｜27；③段闸门自身对照 5/5 回归通过；
旧形态残留扫描 0（『至少要问清三件事』『页面关系｜有哪几页、门开在哪｜』『两条操作细节补充』均已归零）。

product-planning/references/stage-delivery/references/execution-runbook.md

@@ -224,6 +224,20 @@
 
 内联后必须自检三条：无 `unpkg` 残留、无 `src="v2/`（外部 jsx 引用）残留、根部挂载点仍在。任一不满足即构建失败。
 
+### 3.2b 宿主已有页面：往已有产品里加功能时
+
+适用：需求是「在某个已有页面里加一块」，而不是「新做一个工具」。三步在动手画之前做完。
+
+1. **锁定宿主外壳，⛔ 不自造** —— 外壳（导航／页头／页面框架）以宿主真实页面为基线。
+   供给里有整页快照（走 `§供给·定调与令牌` 那一行给的能力边界）⇒ 复制快照当原型页，加完新块其余不动；
+   没有快照 ⇒ 先用 `design-capture` 抓宿主那一页的整页快照，或按已采集的组件族与 class 名复刻；
+   都拿不到 ⇒ 在 `DESIGN.md` 偏离单写明「外壳无来源」，并在 3d 报告里记为证据缺口。
+   判据：**页面里出现供给中不存在的导航／外壳类名（例如自造 `nav-item`）即视为外壳未复刻。**
+2. **宿主原有功能逐项回归** —— 交付前把宿主该页原有的可交互项（导航项／入口卡／列表区／筛选／按钮）
+   逐条核对，写成一份逐项清单，作为 3d 终检的输入；新功能挤掉的原件要写明移到了哪、为什么。
+3. **写进 `DESIGN.md`** —— `必要内容` 字段显式写出宿主外壳与原有功能区；`页面职责` 字段写清
+   「本页是宿主哪一页 ＋ 新增了什么」。
+
 ### 3.3 输出红线（命中即返工）
 
 来源：数值判据取 `craft/`（`typography.md` ＋ `color.md` ＋ `accessibility-baseline.md`），反 AI 味取 `craft/anti-ai-slop.md`，版式自查取 `web-prototype/references/checklist.md`。下列判据不在 craft 里重复抄写，只写本项目追加的那几条。

product-planning/references/stage-discovery/references/grill-me.md

@@ -93,7 +93,7 @@ frontier 为空 = 决策树每个分支都走过、没有静默假设，且待
 | 目标 | 解决什么问题、成功怎么衡量、谁最痛 |
 | 用户 | 谁用、熟练度、在什么场景下用、现在怎么凑合 |
 | 范围 | 第一版做什么、**明确不做什么**、什么东西不在这个产品里 |
-| **交付形态** | **这套东西应该有几个界面 / 一页几件事 / 信息承载到哪一层**（2026-09-29 新增） |
+| **交付形态** | **这套东西应该有几个界面 / 一页几件事 / 信息承载到哪一层 / 它长在哪（独立成页 or 嵌进宿主已有页面）**（2026-09-29 新增；2026-10-13 补第 4 问） |
 | 素材与数据 | 手上已有什么（存量数据、素材、样例）、还缺什么才能验证 |
 | 约束 | 预算 / 人力 / 时间 / 合规底线 |
 | 依赖 | 依赖哪些外部系统、平台、第三方能力 |
@@ -102,12 +102,13 @@ frontier 为空 = 决策树每个分支都走过、没有静默假设，且待
 > ⭐ 为什么「交付形态」是必问支（实战教训）：
 > 原有 7 个必问分支覆盖了「做什么、为谁、边界」，唯独没问「交付成一个什么样的东西」。本项目①段问完了范围却漏掉形态，③段于是把六件事塞进一个页面，做成 2,884 行、约 190 个交互函数的「控制台」，被用户判定为「最多算一个产品框图」。
 >
-> 本支至少要问清三件事：
+> 本支至少要问清四件事：
 > | # | 问题 | 为什么在 ① 段问 |
 > |---|---|---|
 > | 1 | **价值主要在哪一层**——约定 / 文件结构，还是界面？ | 决定界面的**复杂度上限**。答"约定为主"则界面必须薄 |
 > | 2 | **应该有几个界面**，每个界面只办一件事时的"一件事"是什么 | 结构性决策；**漏掉它，后续所有界面文档都要重做** |
 > | 3 | **信息承载到哪一层**——哪些必须一进来就看到，哪些点一下能看到即可 | 决定"信息墙"是否发生（②段会据此出分档表） |
+> | 4 | **它长在哪**——独立成页，还是嵌进宿主已有页面的哪个位置；宿主原有的功能保留哪些 | 决定这是"新建一个界面"还是"往已有页加一块"。宿主是已有产品时，只答"一个界面"会被下游执行成**另起一页**，宿主那一页的原有功能整块丢掉（2026-10-13 实测：某项目照此做，宿主原有板块的功能在原型里出现次数全部为 0） |
 >
 > 不适用时：若产品确实没有界面（纯 CLI / 纯约定），在 `1a-需求文档.md` 写明「本产品无界面，交付形态=约定 + 脚本」，不留空、不跳过。
 
@@ -153,6 +154,7 @@ frontier 为空 = 决策树每个分支都走过、没有静默假设，且待
 - 把自动补全当默认动作，用户没说话就替他决定，还不标 `【假设】`
 - 标了 `【假设】` 却没进待复核清单，静默流进策略结论
 - 漏问「交付形态」这一支（2026-09-29 新增）：问完了「做什么、为谁、边界」，却没问「应该有几个界面、价值在哪一层」。后续 ②③ 段会在无形态依据的情况下自行发明结构，做出来的东西被判定为「产品框图」。该支为 A 节必问项
+- ⛔ 只问「应该有几个界面」不问「它长在哪」（2026-10-13 新增）：宿主是已有产品时，这两问**必须并列**答。只答"一个界面"⇒ 下游把它做成独立页，宿主原有功能整块丢掉（实测：某项目就是这么丢掉整个宿主板块的）
 - ⛔ 只做 A 节、跳过 B 节（2026-10-06 新增）：B 节是从②段合并来的，跳过它等于把功能压测整个删掉，接口会带着没压测过的需求直接进②段与原型
 - ⛔ 在 B 节把页面结构写死（2026-10-06 新增）：B 节只给粗粒度形态；精确板块清单与布局归②段
 - ⛔ 状态行只写「frontier 为空」，把未经确认的模型补全藏在正文（2026-10-02 新增）
@@ -162,7 +164,7 @@ frontier 为空 = 决策树每个分支都走过、没有静默假设，且待
 交付前逐条过。任一条为「否」，退回重跑。
 
 - [ ] 起点那句（做什么 / 为谁 / 不做什么）已摊开成决策表，写入 `docs/pm/<项目>/research/1a-需求文档.md`
-- [ ] A 节各分支都问过，其中「交付形态」支问清了「价值主要在哪一层 / 应该有几个界面 / 信息承载到哪一层」
+- [ ] A 节各分支都问过，其中「交付形态」支问清了「价值主要在哪一层 / 应该有几个界面 / 信息承载到哪一层 / 它长在哪（独立成页 or 嵌进宿主已有页面；宿主原有功能保留哪些）」
 - [ ] B 节各分支都问过，状态与不成立条件没有遗漏
 - [ ] 每轮问题都有编号与推荐答案，依赖未决答案的问题没塞进本轮
 - [ ] 所有 `【假设】` 都进了待复核清单；状态行同时给出「已确认 N 项 / 模型补全 M 项（M 项未经用户确认）」，没有单写「frontier 为空」

product-planning/references/stage-requirements/SKILL.md

@@ -102,7 +102,7 @@ description: 产品规划第②段，产品功能。只做一件事：把①段
 
 | 问 | 回答 | 内容 |
 |---|---|---|
-| 页面关系 | 有哪几页、门开在哪 | 页面清单、页面流转、导航 |
+| 页面关系 | 有哪几页、门开在哪、**新功能挂在宿主哪一页** | 页面清单、页面流转、导航、**宿主页 ＋ 新增块** |
 | 页面内布局 | 房间里家具怎么摆 | 每页的板块清单 ＋ 排列顺序（wireframe 灰块粒度） |
 
 > ⭐ 拆成两份是 2026-10-07 的用户定案。旧写法一份装两半，同一件事要写两遍（比如 `header / side / footer` 既像页面框架又像页内板块）；拆开后各自只写自己那一侧，正好逼着把边界写明确。

product-planning/references/stage-requirements/references/create-prd.md

@@ -66,17 +66,18 @@
 
 | 半 | 回答 | 内容 |
 |---|---|---|
-| 页面关系 | 有哪几页、门开在哪 | 页面清单、页面流转、导航 |
+| 页面关系 | 有哪几页、门开在哪、**新功能挂在宿主哪一页** | 页面清单、页面流转、导航、**宿主页 ＋ 新增块** |
 | 页面内布局 | 房间里家具怎么摆 | 每页的板块清单 + 排列顺序（wireframe 灰块粒度） |
 
 > 不拆两份的理由：参考图里的 `header / side / footer` 是页面框架，正好卡在「之间」与「之内」的交界。拆两份必然出现「页面 P1 有 header」写两遍，而同一件事写两遍就是打架的起点，本项目反复踩这个坑。
 
 ### 必须给全的五样（缺一样③段就没方向）
 
-「归②段」那一列就是这五样，逐条一一对应（定义见 `SKILL.md` §②—③ 交接口）。两条操作细节补充：
+「归②段」那一列就是这五样，逐条一一对应（定义见 `SKILL.md` §②—③ 交接口）。三条操作细节补充：
 
 1. 每页板块给到 wireframe 灰块粒度 —— 有几个块、从上到下什么顺序，⛔ 不含视觉。
 2. 页面流转要写清「谁跳到谁、什么条件下」，⛔ 不写「用户可自由导航」这类空话。
+3. 在已有产品上做加法时，「页面关系」要写出「**宿主页 ＋ 新增块**」，⛔ 不把「往已有页加一块」写成「新增一页」；宿主原有的功能要在骨架里**显式保留**（③段照它做逐项回归）。
 
 ### 信息承载分档（判据只有一条）