| 1 | # 模板架构：Brand / Style / Layout / Deck 四分类 |
| 2 | |
| 3 | [English](../templates-architecture.md) | [Chinese](./templates-architecture.md) |
| 4 | |
| 5 | --- |
| 6 | |
| 7 | > 本文是**架构对齐文档**，定义“模板”在数据模型层面的四种身份、各自的 `design_spec.md` 字段集、以及多路径安装与片段所有权规则。面向贡献者与 AI 工作流，回答“一个模板目录里应该写什么、不写什么；多个模板同时给时怎么协同”。 |
| 8 | > |
| 9 | > 用户视角的用法（怎么选、怎么提供精确路径）见 [`templates-guide.md`](./templates-guide.md)；本文不重复。 |
| 10 | |
| 11 | --- |
| 12 | |
| 13 | ## 一、四分类 |
| 14 | |
| 15 | | 分类 | 全局库工作区根目录 | 写什么 | 不写什么 | 出处工作流 | |
| 16 | |---|---|---|---|---| |
| 17 | | **Brand** | `templates/brands/<id>/` | 仅身份段：color / typography / logo / voice / icon style | 不写 canvas、page structure、SVG roster | `workflows/create-template/create-brand.md` | |
| 18 | | **Style** | `templates/styles/<id>/` | 可移植方向/方法段：沟通方法、页面角色词汇、证据/数据表达、视觉默认值、图片/图标方向、审阅关注点 | 不写身份真值、应用契约、canvas、页面结构或 SVG roster | `workflows/create-template/create-style.md` | |
| 19 | | **Layout** | `templates/layouts/<id>/` | 仅品牌中立的结构段：canvas / page structure / 语义文字角色 / page types / SVG roster | 不写品牌身份，也不拥有可重复沟通场景 | `workflows/create-template/create-layout.md` | |
| 20 | | **Deck** | `templates/decks/<id>/` | 一类可重复演示：描述性应用语境 + 一体化身份与结构 | —— | `workflows/create-template/create-deck.md` | |
| 21 | |
| 22 | 每张新建的 Layout/Deck SVG 都是完整预览，并在根节点声明 Master/Layout key 与选择器名称；固定 Master/Layout 视觉是直接原子元素；语义槽位是顶层 group。普通槽位必须有正数设计区域 bounds 和恰好一个兼容 carrier；复合 `object` 区域走显式 proxy 绑定，零槽 Layout 也合法。这些专用标记具有最高优先级；最小 `data-pptx-role` 只补充它们无法表达的页面框架行为。Create Template 根据自然语言意图与来源证据在内部推导 `standard` / `fidelity` / `mirror`；Strategist 再根据真实原型与当前内容推导 strict/adaptive 导出行为。这些实现值都不是用户必选项。仅 Brand/Layout/Deck 的旧式平铺目录可在满足当前 kind 合同时继续读取；Style 没有平铺兼容形态。带旧结构语义的包必须替换为新建模板工作区，不能原地升级。 |
| 23 | |
| 24 | 四者是**四种并列的可复用规则包**，不是 PowerPoint 包对象类型。在全局库范围内，物理目录与前置元数据中的 `kind` 字段双向对齐： |
| 25 | |
| 26 | 每份已装 spec 各自保留自己的 `kind` 与 id；不存在合并后的项目 spec，也没有组合出来的能力标签。路由结果在读取时推导：结构优先来自 Layout，没有 Layout 时才来自 Deck；身份来自 Brand 或 Deck，方向来自 Style。项目内临时组合的 Brand + Layout 因此只是“两种能力都已安装”，不会被自动提升为可注册的 Deck，也不会凭空生成应用语境；当前项目的 Stage 1 沟通契约负责提供场景。Strategist 在内部生成模板应用计划，确认页不显示模板模式控件。 |
| 27 | |
| 28 | ```yaml |
| 29 | # templates/brands/anthropic/templates/design_spec.md |
| 30 | --- |
| 31 | kind: brand |
| 32 | ... |
| 33 | --- |
| 34 | |
| 35 | # templates/styles/consulting-decision/templates/design_spec.md |
| 36 | --- |
| 37 | kind: style |
| 38 | ... |
| 39 | --- |
| 40 | |
| 41 | # templates/layouts/presentation_core/templates/design_spec.md |
| 42 | --- |
| 43 | kind: layout |
| 44 | native_structure_mode: structured |
| 45 | ... |
| 46 | --- |
| 47 | |
| 48 | # templates/decks/中国电信/templates/design_spec.md |
| 49 | --- |
| 50 | kind: deck |
| 51 | native_structure_mode: structured |
| 52 | ... |
| 53 | --- |
| 54 | ``` |
| 55 | |
| 56 | ### PowerPoint 原生对象是编译目标 |
| 57 | |
| 58 | 项目模板 kind 与 PresentationML 对象不是一一对应关系： |
| 59 | |
| 60 | | 项目合同 | 原生投影 | |
| 61 | |---|---| |
| 62 | | **Brand** | Theme 的颜色、字体与效果，以及 Logo 等固定身份资产规则 | |
| 63 | | **Style** | 不提供可复用包结构；已确认的方法和视觉默认值指导 flat Slide-local 创作 | |
| 64 | | **Layout** | Master/Layout/Placeholder 拓扑、可复用几何、语义文字角色与槽位空间行为 | |
| 65 | | **Deck** | Brand 与 Layout 的投影，再加描述性重复应用语境和真实原型 | |
| 66 | |
| 67 | 一个 Slide Master 可以同时包含结构几何和品牌视觉。来源规则仍分开归属：Layout 决定拓扑、位置、语义文字角色与空间行为，Brand 决定身份值与资产。下游选择 `layout` 时，导出结合已确认的阅读模式和字号体系解析最终 placeholder 格式；选择 `mirror` 时则保留来源的字面格式与文字拓扑。最后再把适用规则编译进同一套 Master/Layout 图谱。因此 Theme 是已解析身份的实现投影——身份可以来自 Brand、Deck 或当前项目——而不是另一种模板 kind；Style 的色彩/字体 fallback 也不是 Theme 身份真值。 |
| 68 | |
| 69 | ### 输出范围与 kind 相互独立 |
| 70 | |
| 71 | `create-template` 会确认工作区放在哪里。这个执行选择不会增加另一种 kind，也不会增加新的 PPTX 结构模式： |
| 72 | |
| 73 | | 范围 | 工作区根目录 | 核心结构 | 发现行为 | |
| 74 | |---|---|---|---| |
| 75 | | `library`（默认） | `skills/ppt-master/templates/<kind>/<id>/` | 必需 `templates/`；可选 `images/`、`icons/` 与按需 `exports/` | 写入对应全局索引 | |
| 76 | | `project` | `projects/<name>/` | 完全相同的路由合同 | 不更新全局索引 | |
| 77 | |
| 78 | 两种根目录都保持相同的核心形态： |
| 79 | |
| 80 | ```text |
| 81 | <template_workspace>/ |
| 82 | ├── templates/ |
| 83 | │ ├── design_spec.md |
| 84 | │ └── *.svg |
| 85 | ├── images/ # 可选；SVG 统一引用 ../images/<name> |
| 86 | ├── icons/ |
| 87 | │ └── imported/ # 可选；导入向量素材的唯一规范副本 |
| 88 | └── exports/ # 可选；用户要求审阅或多 Master 包需要证据时创建 |
| 89 | └── <id>_template_preview.pptx |
| 90 | ``` |
| 91 | |
| 92 | 空的可选目录直接省略，不添加占位文件。预览 PPTX 是派生审阅证据，不是模板 |
| 93 | 源资产；单 Master 按需生成，多 Master 必须通过该 package gate。Step 3 只把 |
| 94 | 工作区 root 记录为候选输入，不读取其内容；Stage 1 选中后，apply 阶段才消费 |
| 95 | `templates/` 及实际存在的 `images/`、`icons/`，不会复制或使用 `exports/`； |
| 96 | 全局库下的 `exports/` 统一由 Git 忽略。 |
| 97 | |
| 98 | 导入向量统一使用 `data-icon="imported/<name>"`，唯一规范文件位于 `icons/imported/<name>.svg`。具备工作区感知的校验与导出会直接解析这个根目录路径；`templates/icons/` 不属于模板包结构。 |
| 99 | |
| 100 | 原生形状 metadata 采用两级模型。完整导入 SVG 保存 native metadata、隐藏 carrier 和预览证据，并作为不可变原生载荷后备；`svg_authoring_view.py` 生成可编辑 authoring IR，其中轻量 SVG 使用文档内 source ref 标识对象，manifest 只保存路径和初始 hash。创作模式使用项目规范化 SVG，只有精确匹配已登记 preset 时才使用 compact authored-preset 组。Mirror 从 IR 物化模板，仅为未改且 hash 匹配的 Slide-local/slot ref 重新接入转换器已支持的载荷；固定结构层保持直接原子，不支持或已修改的对象保留 SVG fallback，最终模板不包含 IR 专用 ref。导出只编译声明的结构，不推断归属。 |
| 101 | |
| 102 | 两种范围都在可移植前置元数据中保留所选 `kind`。`output_scope` 与 `target_project` 只属于工作流简报，不写入 `design_spec.md`。 |
| 103 | |
| 104 | 任何范围第一次写最终文件前，都必须解析 Design Spec 和全部真实目标。Library 范围要求 `templates/` 为空。Project 范围要求目标项目已初始化，并拒绝裸名、同 kind spec 或无效的限定名集合；不同 kind 可以共存。Layout 与 Deck 同时存在时，Layout 拥有有效 roster：新增 Deck 不改变已有 Layout roster，新增 Layout 则先隔离校验，再原子替换已有 Deck 结构载荷。两种范围都会检查计划素材和预览目标冲突。任一失败都在写入前停止，不覆盖、不留下半套输出。 |
| 105 | |
| 106 | ### 四段的字段切分 |
| 107 | |
| 108 | 为了让多路径所有权干净解析，所有字段按段归属，**片段整段应用是默认粒度**： |
| 109 | |
| 110 | | 段 | 包含的章节 | 归属（覆盖优先级）| |
| 111 | |---|---|---| |
| 112 | | **身份段** | Color Scheme / Typography / Logo / Voice & Tone / Icon Style | brand 覆盖 | |
| 113 | | **方向/方法段** | Communication Method / Page Role Vocabulary / Evidence & Data Expression / Visual System Defaults / Image & Icon Direction / Review Focus | style；默认值低于用户确认及身份/结构所有者 | |
| 114 | | **结构段** | 可移植 canvas/page-type 元数据、结构归属的 Signature 规则、SVG Page Roster，以及 SVG Master/Layout/slot 合同 | layout 覆盖 | |
| 115 | | **应用段** | Template Overview：重复场景、受众与结果、交付假设及代表性叙事/页面角色 | deck 独有；brand / layout 不写 | |
| 116 | |
| 117 | ### 为什么需要 Deck 这一类 |
| 118 | |
| 119 | Deck 编码的是**一类可重复演示**，而不只是预先组合好的 Brand 和 Layout。它描述模板服务哪些沟通场景、支持哪些受众结果，以及常见的叙事或页面角色。身份与结构围绕这份语境形成一个整体；具体选哪些原型、如何处理内容，由当前 Strategist 决定。 |
| 120 | |
| 121 | `standard` / `fidelity` 根据已确认的证据创作新完整系统；mirror 把已验证的来源身份与父子关系一对一映射进新工作区。Mirror 能保留来源事实，但不能单独证明来源就是可复用 Deck：创建时仍要识别稳定的应用规则。只得到身份时创建 Brand；方法与视觉方向需要脱离原型复用时创建 Style；得到品牌中立的可复用结构时创建 Layout；结构带品牌身份，或者包含场景叙事与内容语法时创建 Deck。 |
| 122 | |
| 123 | 这也约束创建模式：只有来源合同本身已经品牌中立且应用中立时，Layout mirror 才成立。删除品牌色、字体、Logo、固定身份对象或可复用应用规则都属于重新创作；越过这条边界的来源要么使用 `standard` / `fidelity` 创作新的 Layout，要么保留这些事实并创建 Deck mirror。 |
| 124 | |
| 125 | --- |
| 126 | |
| 127 | ## 二、各分类的 `design_spec.md` 结构定义 |
| 128 | |
| 129 | 字段集只规定**必须写**的部分。「非必要不表明」——当前结构定义没列出的字段，不写。 |
| 130 | |
| 131 | ### Brand 结构定义 |
| 132 | |
| 133 | **前置元数据** |
| 134 | |
| 135 | ```yaml |
| 136 | --- |
| 137 | brand_id: <slug> |
| 138 | kind: brand |
| 139 | summary: <一句话描述用途，含主色> |
| 140 | primary_color: "<HEX>" |
| 141 | --- |
| 142 | ``` |
| 143 | |
| 144 | **正文章节**（身份段全集） |
| 145 | |
| 146 | | 节 | 标题 | 必写字段 | |
| 147 | |---|---|---| |
| 148 | | I | Brand Overview | Brand Name / Use Cases / Tone | |
| 149 | | II | Color Scheme | role / HEX / provenance（`fact` 官方真值 \| `approx` 推导）/ notes | |
| 150 | | III | Typography | role / family / weight | |
| 151 | | IV | Logo | file / form / usage + clearspace 与组合规则 | |
| 152 | | V | Voice & Tone | formality / person / emoji / abbreviation 策略 | |
| 153 | | VI | Icon Style | preference（stroke / filled / duotone …）+ 推荐字库 | |
| 154 | |
| 155 | **不允许出现**：canvas viewBox、page types、SVG roster——这些是 layout 的职责。 |
| 156 | |
| 157 | ### Style 结构定义 |
| 158 | |
| 159 | **前置元数据** |
| 160 | |
| 161 | ```yaml |
| 162 | --- |
| 163 | style_id: <slug> |
| 164 | kind: style |
| 165 | summary: <一句话描述可移植方法与视觉方向> |
| 166 | keywords: [tag1, tag2, tag3] |
| 167 | --- |
| 168 | ``` |
| 169 | |
| 170 | **正文章节**（方向/方法段） |
| 171 | |
| 172 | | 节 | 标题 | 必写内容 | |
| 173 | |---|---|---| |
| 174 | | I | Style Overview | 名称、宽泛适用语境、复用意图与来源；不绑定受众/结果 | |
| 175 | | II | Communication Method | mode 候选、论证流、页面信息纪律与证据纪律 | |
| 176 | | III | Page Role Vocabulary | 开放角色及其沟通任务、证据义务和构图倾向；不规定顺序/页数 | |
| 177 | | IV | Evidence & Data Expression | 主张/证据、事实/假设/含义/建议区分，以及图表/表格/来源规则 | |
| 178 | | V | Visual System Defaults | visual-style 候选、构图、密度、装饰、节奏及可选色彩/字体 fallback | |
| 179 | | VI | Image & Icon Direction | 渲染、使用与处理方向；不写 inventory 或逐页映射 | |
| 180 | | VII | Review Focus | 仅在用户另行开启 visual review 后追加的检查点 | |
| 181 | |
| 182 | Style 不写 SVG，也不拥有 Brand 官方身份、Deck 应用契约、canvas、页数/ |
| 183 | 顺序、Master/Layout/placeholder 结构或逐页资源。其色彩与字体只是可覆盖 |
| 184 | fallback：用户最终确认及 Brand/Deck 身份优先。Review Focus 不能启动 |
| 185 | visual review。`kind: style` 表示可复用包类型，区别于最终 Stage 2 的 |
| 186 | `visual_style` 选择和内部 flat 导出值 `template_reuse_scope: style`。 |
| 187 | |
| 188 | ### Layout 结构定义 |
| 189 | |
| 190 | **前置元数据** |
| 191 | |
| 192 | ```yaml |
| 193 | --- |
| 194 | layout_id: <slug> |
| 195 | kind: layout |
| 196 | category: general | scenario | government | special |
| 197 | native_structure_mode: structured |
| 198 | summary: <一句话描述用途> |
| 199 | keywords: [tag1, tag2, tag3] |
| 200 | canvas_format: <ppt169 | ppt43 | a4 | ...> |
| 201 | canvas_width: <像素> |
| 202 | canvas_height: <像素> |
| 203 | canvas_viewbox: "0 0 <width> <height>" |
| 204 | source_canvas_width: <像素> # 已知 PPTX/SVG 来源画布时填写 |
| 205 | source_canvas_height: <像素> |
| 206 | source_viewbox: "0 0 <width> <height>" |
| 207 | replication_mode: standard | fidelity | mirror |
| 208 | page_count: <N> |
| 209 | page_types: [<cover, toc, chapter, content, ending, ...>] |
| 210 | --- |
| 211 | ``` |
| 212 | |
| 213 | **正文章节**（该包特有的结构段） |
| 214 | |
| 215 | | 节 | 标题 | 必写字段 | |
| 216 | |---|---|---| |
| 217 | | IV | Signature Design Elements | 该 Layout 特有的网格、区域、图片行为、密度节奏、中性框架、语义文字角色、对齐/换行/容量行为和 slot 约定 | |
| 218 | | V | Page Roster | 每个 SVG 文件、Layout key、picker name、适用内容与 slot 行为 | |
| 219 | |
| 220 | 只有 Layout 改写规范占位词汇时才增加 `Placeholder Overrides`。前置元数据 |
| 221 | `summary` 承担简短的选型语境；Layout 不写 deck 独有的 Template Overview。 |
| 222 | |
| 223 | `category: scenario` 只表示发现时的适配标签。Layout 可以针对某种内容形态或交付环境优化几何，但不能规定沟通目的、受众结果、必需叙事顺序、固定措辞或示例内容；如果这些规则也要重复使用，应创建 Deck。 |
| 224 | |
| 225 | **不允许出现**：Color Scheme、品牌字体家族/字重身份、最终字号体系、品牌 logo、品牌 voice & tone、Icon Style 或官方真值色（`provenance: fact`）。Layout 可以保留语义文字角色、对齐、换行与容量规则，因为它们属于结构；SVG 中性 paint、字体和字号只用于审阅。最终色彩与字体由策略师确认阶段或其他模板 kind 解析。 |
| 226 | |
| 227 | ### Deck 结构定义 |
| 228 | |
| 229 | **前置元数据** |
| 230 | |
| 231 | ```yaml |
| 232 | --- |
| 233 | deck_id: <slug> |
| 234 | kind: deck |
| 235 | category: brand | general | scenario | government | special |
| 236 | native_structure_mode: structured |
| 237 | summary: <一句话描述可重复演示类型与预期结果> |
| 238 | keywords: [tag1, tag2, tag3] |
| 239 | canvas_format: <ppt169 | ...> |
| 240 | canvas_width: <像素> |
| 241 | canvas_height: <像素> |
| 242 | canvas_viewbox: "0 0 <width> <height>" |
| 243 | source_canvas_width: <像素> # 已知 PPTX/SVG 来源画布时填写 |
| 244 | source_canvas_height: <像素> |
| 245 | source_viewbox: "0 0 <width> <height>" |
| 246 | replication_mode: standard | fidelity | mirror |
| 247 | page_count: <N> |
| 248 | primary_color: "<HEX>" |
| 249 | --- |
| 250 | ``` |
| 251 | |
| 252 | **正文章节**（应用契约 + 一体化身份/结构） |
| 253 | |
| 254 | | 节 | 标题 | 归属段 | |
| 255 | |---|---|---| |
| 256 | | I | Template Overview | 应用段 | |
| 257 | | II | Color Scheme | 身份段 | |
| 258 | | III | Typography | 身份段；只有使用共享默认字体栈时才省略 | |
| 259 | | IV | Signature Design Elements | 模板特有的身份图形与可复用结构语法 | |
| 260 | | V | Page Roster | 结构段 | |
| 261 | | VI | Assets | 身份/支撑资产；无资产时省略 | |
| 262 | | VII | Placeholder Overrides | 结构词汇；无覆盖时省略 | |
| 263 | |
| 264 | Template Overview 写明可重复演示类型、目标受众与结果、交付/阅读假设及代表性叙事或页面角色。Page Roster 只需如实描述每个原型的 Master/Layout/slot 合同、视觉特征、用途和容量，不得添加必需/可选/可重复或固定/可替换/仅示例政策；当前 Strategist 会按实际内容推导这些决定。 |
| 265 | |
| 266 | 可移植 canvas 字段、`page_count` 和显式 SVG roster 承载其余结构合同。通用间距、字号比例、SVG 和 placeholder 规则保持集中管理，不复制进每个 deck spec。省略条件章节只表示“采用共享默认值或没有资产”，不表示该段改由其他 kind 所有。 |
| 267 | |
| 268 | --- |
| 269 | |
| 270 | ## 三、四套 index 文件 |
| 271 | |
| 272 | 这四份 index 都与各自物理目录一一对应，字段只保留 Strategist 选择可复用 workspace 所需的信息。Visualization 采用另一条边界：规划读取客观的 [`chart-vocabulary.md`](../../skills/ppt-master/templates/charts/chart-vocabulary.md) 与 [`table-vocabulary.md`](../../skills/ppt-master/templates/tables/table-vocabulary.md)，[`charts_index.json`](../../skills/ppt-master/templates/charts/charts_index.json) 和 [`tables_index.json`](../../skills/ppt-master/templates/tables/tables_index.json) 只保留为机器 registry。定性 Structure 没有 index，因为 Executor 会根据当前页关系现场生成。 |
| 273 | |
| 274 | 四套索引只覆盖全局库范围。项目根工作区有意不进入任何索引，仍可通过显式 `projects/<name>/` 路径使用。因为两种范围采用相同工作区形态，完整核心工作区可在两者之间移动或复制，不需要重写素材路径；只有全局库注册不同。 |
| 275 | |
| 276 | ### `templates/brands/brands_index.json` |
| 277 | |
| 278 | ```json |
| 279 | { |
| 280 | "<brand_id>": { |
| 281 | "summary": "Anthropic brand identity — AI/LLM tech talks, developer conferences", |
| 282 | "primary_color": "#D97757" |
| 283 | } |
| 284 | } |
| 285 | ``` |
| 286 | |
| 287 | - 保留 `primary_color` —— Strategist 选 brand 时第一眼就要知道主色 |
| 288 | - 去掉 keywords —— summary 自带英文等价词，AI 用自然语言匹配（沿用 charts 经验） |
| 289 | |
| 290 | ### `templates/styles/styles_index.json` |
| 291 | |
| 292 | ```json |
| 293 | { |
| 294 | "<style_id>": { |
| 295 | "summary": "Answer-first、证据驱动的决策文档默认值，不含页面原型或品牌身份", |
| 296 | "keywords": ["consulting", "decision-support", "evidence"] |
| 297 | } |
| 298 | } |
| 299 | ``` |
| 300 | |
| 301 | - 保留 `keywords`：方法/方向没有结构 roster，发现主要依赖语义 |
| 302 | - 不写 canvas、page count 或 primary color；Style 不拥有结构或身份真值 |
| 303 | |
| 304 | ### `templates/layouts/layouts_index.json` |
| 305 | |
| 306 | ```json |
| 307 | { |
| 308 | "<layout_id>": { |
| 309 | "summary": "Standard academic defense layout — cover/toc/chapter/content/ending", |
| 310 | "canvas_format": "ppt169", |
| 311 | "page_count": 5, |
| 312 | "page_types": ["cover", "toc", "chapter", "content", "ending"] |
| 313 | } |
| 314 | } |
| 315 | ``` |
| 316 | |
| 317 | - 加 `canvas_format` / `page_count` / `page_types` —— Strategist 选 layout 时要快速判断"页面骨架能不能装下我的 deck" |
| 318 | - 无 `primary_color` —— layout 无身份 |
| 319 | |
| 320 | ### `templates/decks/decks_index.json` |
| 321 | |
| 322 | ```json |
| 323 | { |
| 324 | "<deck_id>": { |
| 325 | "summary": "中国电信政企方案说明与下一步对齐汇报", |
| 326 | "canvas_format": "ppt169", |
| 327 | "page_count": 5, |
| 328 | "primary_color": "#XXXXXX" |
| 329 | } |
| 330 | } |
| 331 | ``` |
| 332 | |
| 333 | - 含 `primary_color`（deck 自带身份）+ 结构元数据 |
| 334 | - `summary` 优先描述可重复演示类型与预期结果，而不只是视觉气质 |
| 335 | - 详细应用契约留在 Template Overview；紧凑索引不重复整份契约 |
| 336 | |
| 337 | --- |
| 338 | |
| 339 | ## 四、多路径安装与片段所有权 |
| 340 | |
| 341 | ### 安装只复制，不合并 |
| 342 | |
| 343 | Step 3 确认已注册和/或指定工作区根目录后，会解析每个 root 的真实 `kind`， |
| 344 | 并把每个选中的工作区安装为**各自独立**的一份项目内文件： |
| 345 | |
| 346 | ``` |
| 347 | <project>/templates/design_spec.brand.mckinsey.md |
| 348 | <project>/templates/design_spec.style.consulting-decision.md |
| 349 | <project>/templates/design_spec.layout.presentation_core.md |
| 350 | ``` |
| 351 | |
| 352 | 正文原样复制，只在 H1 下补一行来源标注： |
| 353 | |
| 354 | ```markdown |
| 355 | > **Installed from**: `skills/ppt-master/templates/brands/mckinsey/` (library) |
| 356 | ``` |
| 357 | |
| 358 | 不存在合并后的项目 spec，也没有组合出来的能力标签。裸的 |
| 359 | `<project>/templates/design_spec.md` 含义完全不同：那表示该项目**自身就是** |
| 360 | project scope 的 Create Template 产物，永远不会被当作已安装模板消费。 |
| 361 | |
| 362 | `library` / `explicit` 只记录发现来源，不改变所有权。 |
| 363 | |
| 364 | ### 片段所有权在读取时解析 |
| 365 | |
| 366 | 消费方——Default 的最终 Stage 2，或 Quick 在创作前的当前 agent——读取全部已装 |
| 367 | spec，并在上下文中解析下列片段： |
| 368 | |
| 369 | | 片段 | 起始所有者 | |
| 370 | |---|---| |
| 371 | | Identity | Brand，其次 Deck；都没有则留到最终 Stage 2；Style 只提供候选回退值 | |
| 372 | | 方向／方法 | Style；没有则留到最终 Stage 2；Deck 的实际原型与 Signature 事实只用于兼容性判断 | |
| 373 | | Structure | 有 Layout 时由 Layout 提供，否则由 Deck 提供；都没有则留到最终 Stage 2 或自由设计 | |
| 374 | | 可复用应用语境 | 仅 Deck 拥有；保留供最终 Stage 2 比对，绝不作为当前项目的应用契约 | |
| 375 | |
| 376 | 当前用户指令与最终确认覆盖任何起始所有者。Brand 身份对 Style 的色彩／字体回退值 |
| 377 | 始终具有权威性。Style 单独、或 Style 加 Brand，走扁平页面创作；Style 与 Layout |
| 378 | 或 Deck 同装时follow所选结构来源。Style 自身不会升级或降级结构。 |
| 379 | |
| 380 | **被拥有的片段管的是视觉权重，不只是取值。** 当片段所有者声明某个值应当主导、 |
| 381 | 退居次要或保持稀有时，该指令与取值本身具有同等权威——Style 的留白或构图倾向 |
| 382 | 绝不能把 Brand 声明的主导色降格为偶然点缀。 |
| 383 | |
| 384 | 把 Style 与 Layout／Deck 组合前，先确认其沟通方法与构图预期 |
| 385 | 能够被该可复用语境与结构兑现。不兼容时显式报告模板片段冲突，不能静默混合字段 |
| 386 | 或保留一份当前结构无法兑现的承诺。当前项目的适配只在 Stage 1 确认后的最终 |
| 387 | Stage 2 开始。 |
| 388 | |
| 389 | ### 段级整段应用（默认粒度） |
| 390 | |
| 391 | 解析出的片段**整段应用**——例如 deck + brand 时，整个 Color Scheme / Typography / |
| 392 | Logo / Voice / Icon Style 五段从 brand 拿，**不做字段级混搭**（即不会发生 |
| 393 | "primary 从 brand 拿、secondary 从 deck 拿"这类隐式混合）。 |
| 394 | |
| 395 | 字段级微调走策略师确认阶段这条已有路径——用户在 chat 里说"用 anthropic brand， |
| 396 | 但 primary 改成 #FF0000"，由 Strategist 在 e/g 现场调整；安装层不加字段级语法。 |
| 397 | |
| 398 | ### 选择冲突 |
| 399 | |
| 400 | 完整选择中每个 kind 最多一份；Layout 与 Deck 可以同时存在，结构由 Layout |
| 401 | 优先提供。指定的多 kind root 必须原子选择，只能与 kind 不重叠的已注册 root 共存。Default 在 Stage-1 |
| 402 | 选择器和服务端回执中拒绝冲突；Quick 要求先在 chat 中缩小精确 root 集合。 |
| 403 | 安装阶段不会平均同 kind spec，也不会按路径顺序替用户选择。 |
| 404 | |
| 405 | ### 可追溯性 |
| 406 | |
| 407 | 因为不做任何合并，已装集合本身即自描述：文件名带 kind 与 id，来源行带源 root， |
| 408 | 其余正文保持不变。追溯哪一段来自哪里，看目录列表即可，不需要重建合并过程。 |
| 409 | |
| 410 | 让 AI 和人类都能回溯每段来自哪。 |
| 411 | |
| 412 | --- |
| 413 | |
| 414 | ## 五、与 Generate PPTX Stage 1 的关系 |
| 415 | |
| 416 | Default Generate 的 [Step 3](../../skills/ppt-master/workflows/generate-pptx.md#step-3-template-candidate-preparation) |
| 417 | 只准备候选输入。Stage 1 把沟通契约与可切换的自由设计/使用模板选择同屏呈现。 |
| 418 | 普通请求默认自由设计并收起详细控件；明确要求使用模板或提供任意精确 root 时 |
| 419 | 默认展开模板模式。只提供一个 root 时会预选，多 root 仍只作为未选候选。裸 |
| 420 | 模板/品牌名称或风格词不会解析或预选工作区。对于每个已选 root，确认后的 |
| 421 | apply 阶段解析一份 library 裸 spec 或全部 project 限定名 spec；为兼容目录形态，也接受根目录直接包含 `<workspace>/design_spec.md`、且满足当前 kind 合同的旧式平铺 Brand/Layout/Deck 工作区。Layout/Deck 还必须带有当前 structured SVG；Style 没有平铺形态。若包仍使用 `native_structure_mode: template`、缺 Master 身份、原子 placeholder 或蒸馏时代标记等旧语义，apply 阶段必须拒绝；先由 `create-template` 产出新工作区，再继续生成。`kind` 字段决定**AI 如何处理已选路径**： |
| 422 | |
| 423 | | 用户路径指向 | Stage-1 确认后的 apply 行为（按 kind 分支）| |
| 424 | |---|---| |
| 425 | | `kind: brand` | 安装限定名身份 spec 与 root 自有素材；除非同时选择 Layout/Deck，否则结构自由 | |
| 426 | | `kind: style` | 安装限定名方向/方法 spec；Style 自身不得带 roster 或素材，无 Layout/Deck 时页面保持 flat | |
| 427 | | `kind: layout` | 安装限定名结构 spec、SVG roster 与素材；结构优先于 Deck | |
| 428 | | `kind: deck` | 安装限定名应用/身份/结构 spec 与素材；仅在没有 Layout 时安装其 SVG roster | |
| 429 | | 多 kind root | 保留全部限定名 spec，共享素材只映射一次，并只保留有效 Layout-or-Deck roster | |
| 430 | | 选择冲突 | 安装前拒绝同 kind 重复 | |
| 431 | |
| 432 | 位图统一进入工作区 `images/`，模板 SVG 通过 `../images/` 引用。如果显式输入根目录本来就是目标项目根目录，apply 阶段原地消费：不得复制到自身，也不得再次移动素材。项目 root 可以被其他项目直接复用；把其中一项移入全局库时，spec 正文保持不变，但要从项目限定名路径放到单 kind 库工作区的裸 spec 路径，并完成注册。 |
| 433 | |
| 434 | ### 策略师确认阶段在不同 kind 下的行为 |
| 435 | |
| 436 | 安装模板不会让沟通问题消失。Stage 1 把同一份开放式沟通契约与模板选择同时确认，但两者相互独立：沟通推荐只使用当前请求、源材料事实、对话约束和项目初始化状态，连模板画布也不能参与。Stage 1 完成且所选模板安装后，最终 Stage 2 才读取该状态，并确认完整方案与制作计划。Brand 提供身份约束、结构仍然自由；Style 提供方法和视觉默认值候选并保持 flat；Layout 提供结构能力；Deck 提供描述性的可复用应用语境供对照，但不充当当前项目契约。Style-only 时 Strategist 不读取原型，固定写入 `template_reuse_scope: style` 与 flat 结构；其他情况只读取有效原型（有 Layout 时用 Layout，否则用 Deck）和当前内容，生成页面/原型计划，并把 `mirror`、`layout` 或 `style` 记录为内部导出值。按 mirror 创建的工作区因此只提供原样复用能力，不会强制使用；Confirm UI 会显示自由设计/使用模板和候选控件，但不显示内部复用/遵循字段。规划语义由 `references/strategist.md` 与 `references/strategist-template.md` 负责，机器结构由 `templates/schemas/spec_lock.schema.json` 负责。 |
| 437 | |
| 438 | --- |
| 439 | |
| 440 | ## 六、与路线和子工作流的关系 |
| 441 | |
| 442 | | 路线或子工作流 | 产出 | |
| 443 | |---|---| |
| 444 | | `workflows/create-template.md` | 固定 Create Template 入口，以及范围、确认、预检、结构创作、注册、完成和交接的共享合同；只分派一个子工作流 | |
| 445 | | `workflows/create-template/create-brand.md` | 仅身份的 Brand 工作区；无 SVG roster，空的可选目录省略 | |
| 446 | | `workflows/create-template/create-style.md` | 仅方向/方法的 Style 工作区；无 SVG roster、身份真值、应用契约、原生结构或预览 PPTX | |
| 447 | | `workflows/create-template/create-layout.md` | 品牌中立、带结构化 SVG roster 的 Layout 工作区 | |
| 448 | | `workflows/create-template/create-deck.md` | 应用契约与身份/结构一体化、带结构化 SVG roster 的 Deck 工作区；可复用成果带品牌身份或场景语义时选择，不能只因来源是一份完整 PPTX 就默认选择 | |
| 449 | |
| 450 | **一套结构定义，两个落点。** 模板是同一份合同落在两个层面，唯一的差别是 Design Spec 叫什么： |
| 451 | |
| 452 | | 层 | 容器 | Design Spec | |
| 453 | |---|---|---| |
| 454 | | skill 库 | `templates/<kind_dir>/<template_id>/` 已经说明了 kind 和 id | `templates/design_spec.md` | |
| 455 | | 项目 | 一个平铺、多 kind 共用的 `templates/` | `templates/design_spec.<kind>.<id>.md` | |
| 456 | |
| 457 | 消歧责任归容器，容器给不了的才写进文件名。因此一个项目根同一 kind 至多一份 spec，四种 kind 可以共存，且文件名里的 kind/id 必须分别与前置元数据中的 `kind` 及对应 `<kind>_id` 一致；裸名与限定名不得在同一目录混用。一个 `templates/` 只保留一份有效 SVG roster：有 Layout 时用 Layout，否则用 Deck；Deck 的其他片段不会因结构被覆盖而丢失。由于结构定义不随层面变化，项目里的 spec 进库不需要补字段、出库也不需要删字段，安装进来的与就地创作的在形态上不可区分。 |
| 458 | |
| 459 | 选择遵循同一条原则：单位是工作区 **root**，不是 kind。一个 root 会贡献它暴露的全部 kind，所以指向一个同时装了 Brand 和 Style 的项目，两者都会生效。按 kind 浏览全局库只是找到 root 的一种方式——`library` 与 `explicit` 记录的是 root 如何被发现，而不是它拥有什么。 |
| 460 | |
| 461 | 在全局库范围，前置元数据中的 `kind` 字段决定工作区父目录位于 `templates/brands/` / `templates/styles/` / `templates/layouts/` / `templates/decks/`。项目范围在项目工作区根目录保留同一 kind 语义。项目到项目复用保持完整 root；单项进出全局库时保留 spec 的结构定义与素材，但会改变 spec 文件名落点及索引注册。 |
| 462 | |
| 463 | --- |
| 464 | |
| 465 | ## 七、不做（与本文叙述框架配套的拒绝列表） |
| 466 | |
| 467 | - **不在安装层支持字段级覆盖语法** —— 字段级微调走 策略师确认阶段这条已有路径 |
| 468 | - **不接受同 kind 重复** —— 安装前先缩小 root 集合；Layout + Deck 按结构优先级解析 |
| 469 | - **不引入双名映射表** —— 模板命名按其品牌/场景母语（中文模板用中文名，英文模板用 snake_case），不强制统一 |
| 470 | - **不为输出范围新增结构分支或 CLI flag** —— 输出范围是 `create-template` 简报里的执行选择；两种范围的 Layout/Deck 都声明 `native_structure_mode: structured`，Brand/Style 均无 roster |
| 471 | - **不增加 Theme kind** —— Theme 投影 Brand、Deck 或当前项目解析后的身份；Style fallback 不是身份真值 |
| 472 | - **不让 Style 自动触发 visual review** —— Review Focus 只补充已启用的审阅阶段 |
| 473 | - **不把 Brand + Layout 自动提升成可注册的 Deck** —— 项目内组合可以按同时具备身份/结构能力来路由，但可复用 Deck 仍必须包含应用契约 |
| 474 |