收口design组展示名，改为设计实现Agent

分组字典、manifest默认名与分组头像字一并改掉

个体Agent名兜底跟进，玩法策划Agent与内部id不动

跟改16处由label派生的断言

第 18.2 节要求 design 组用户名称改为「设计实现组」，与新阶段「立项策划」区分。
bf2185fba 只改了 taskGroupLabels 一本字典，另两本同概念字典没动，于是同一个
design 组在开发者面板/文本汇总里叫「设计实现组」、在工作台状态栏里叫
「策划 Agent」——这个语义不一致是该提交引进来的。

先更正一条此前的判断：曾把这条的严重度建立在「新项目默认主路径上『立项策划』
与『策划 Agent』同屏共存」上。该说法未经验证且不成立——用 appSurface harness
实测策划路径，子 Agent 状态栏根本不渲染，策划 Agent 出现 0 次。结构上二者确在
launcherView === 'project-development' 分支的同一棵树里，但未能把用例驱动到该
分支，故不作为事实主张。若真会撞，也是批准后进入完整制作那一段，比原描述窄
得多。改这条的理由与撞不撞名无关，只是第 18.2 节的要求 + 上述不一致。

口径取最小方案：保持兄弟项的「X Agent」体系，design 取「设计实现 Agent」。
不把 taskGroupLabels 直接塞进 groupConfigs——两本字典命名体系不同（「X组」对
「X Agent」，且音乐组/音频 Agent、运营组/发布 Agent 连词都不一样），直接替换
会连带改掉另外五个分组名；消灭重复字典属视觉改版，单独立项。

改动：agentPresentation.ts 的 groupConfigs、view/project-development/index.tsx
的 summarizeAgent 默认名与同文件分组头像字（策→设）、model.ts 中
agentId.includes('design') 的个体名兜底（design-director 走这里）。
design-foundation 的「玩法策划 Agent」单列在前，不变；内部 agent id 与 design
分组键均未动。

测试量原估「3 处断言」严重低估，实跑发现 project-development.suite.ts 有 16 处
派生断言需跟改——「X 文本回执」由 App.tsx 的 `${candidate.label} 文本回执` 拼出、
「历史成果 · X」由 resourceProjectionModel.ts 拼出、dock 的 article accessible
name 亦然。替换用后行否定守住「玩法策划 Agent」（它含「策划 Agent」子串），
替换前后该串恒为 6 处。agentRuntimeModel.test.ts 与
projectResourceProjectionModel.test.ts 里剩余 4 处是测试自造的输入 fixture、
不由字典派生，保持不动。

验证：appSurface.test.ts 383 passed / 0 failed；agentRuntimeModel、
agentTraceSummary、projectResourceProjectionModel、projectResourceLiveUpdateModel
合计 39 passed；agc:typecheck、ESLint --max-warnings 0、check:encoding、
git diff --check 通过。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/project-memory/shared-memory/decision-log.md

@@ -1,5 +1,14 @@
 # 决策记录
 
+## 2026-08-18 M1D 收口：design 组展示名改完
+
+- **背景更正（先于结论）**：此前把这条的严重度建立在「新项目默认主路径上『立项策划』与『策划 Agent』同屏共存」上，**该说法未经验证且不成立**。用 appSurface harness 实测策划路径：`子 Agent 状态栏` 根本不渲染，`策划 Agent` 出现 0 次、`立项策划` 出现 2 次。结构上二者确在 `launcherView === 'project-development'` 分支的同一棵树里（`ProjectDevelopmentView` 的 dock + 作为 `supervisor` 传入的 `ProjectSupervisorView`），但未能把用例驱动到该分支，故不作为事实主张。若真会撞，也是**批准后进入完整制作**那一段（此时 `state=approved`，阶段进度卡守卫仍放行），比原描述窄得多。
+- **仍然要改的理由**：与撞不撞名无关。`bf2185fba` 只把 `taskGroupLabels.design` 改成「设计实现组」，另两本同概念字典没动，于是同一个 design 组在开发者面板/文本汇总里叫「设计实现组」、在工作台状态栏里叫「策划 Agent」——**这个语义不一致是该提交引进来的**。第 18.2 节要求本就是「design 组用户名称改为设计实现组」，与新阶段区分只是其动机之一。改完比回退便宜（回退还需挑拣 `c6a08ef98` 里混着的按钮改名与 prettier 重排，并反改第 18.2 节）。
+- **口径选择**：采最小方案，保持兄弟项的「X Agent」体系（美术 Agent / 程序 Agent / …），design 取「设计实现 Agent」。**不**把 `taskGroupLabels` 直接塞进 `groupConfigs`——两本字典命名体系不同（「X组」对「X Agent」，且音乐组/音频 Agent、运营组/发布 Agent 连词都不一样），直接替换会连带改掉另外五个分组名。消灭重复字典属视觉改版，单独立项。
+- **改动**：`agentPresentation.ts` 的 `groupConfigs`、`view/project-development/index.tsx` 的 `summarizeAgent` 默认名与同文件分组头像字（`策`→`设`）、`model.ts` 中 `agentId.includes('design')` 的个体名兜底（`design-director` 走这里；`design-foundation` 的「玩法策划 Agent」单列在前，不变）。内部 agent id 与 `design` 分组键均未动。
+- **测试**：原估「3 处断言」严重低估。实跑发现 `project-development.suite.ts` 有 16 处派生断言需跟改——「X 文本回执」由 `App.tsx` 的 `${candidate.label} 文本回执` 拼出、「历史成果 · X」由 `resourceProjectionModel.ts` 拼出、dock 的 article accessible name 亦然。替换时用后行否定守住 `玩法策划 Agent`（它含 `策划 Agent` 子串），替换前后该串恒为 6 处。`agentRuntimeModel.test.ts` 与 `projectResourceProjectionModel.test.ts` 里剩余 4 处是测试自造的输入 fixture、不由字典派生，保持不动。
+- **验证**：`appSurface.test.ts` **383 passed / 0 failed**；`agentRuntimeModel` / `agentTraceSummary` / `projectResourceProjectionModel` / `projectResourceLiveUpdateModel` 合计 39 passed；`agc:typecheck`、ESLint `--max-warnings 0`、`check:encoding`、`git diff --check` 通过。
+
 ## 2026-08-18 M1D 审查修复补充：锁错误脱敏与澄清轮次口径
 
 - **锁错误回传绝对路径**：`acquire_project_write_lock` 的 Err 内嵌 `.agent/project.lock` 真实绝对路径，违反第 18.3 节「返回值不包含绝对路径……或内部诊断」。补 `redact_agent_runtime_project_paths` 的三处是前端审批卡真正会显示的那条链：`reconcile_plan_gdd_approval_projections_at`（hydrate 在取自己的锁之前调它）、hydrate 自己的锁、`decide_plan_gdd_at`（其错误与 hydrate 的错误渲染在同一个错误区）。planning 另有 14 个取锁点沿用未脱敏写法，属 M1B/M1C 既有模式，本次不扩面。脱敏不破坏 `项目正在被其他写操作占用：` 前缀，`project_gates.rs` / `provider_recovery.rs` 两处按前缀分类的判据不受影响。