Genarrative

Files

T

lhk229 d44f930d1f 收口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>

2026-08-18 12:20:01 +00:00

【SEO】官网SEO地基实施约定-2026-07-10.md

调整首页品牌文案层级

2026-07-12 19:32:11 +08:00

【前端架构】BarkBattleWorkCache草稿状态收口计划-2026-06-04.md

refactor: 收口 Bark Battle 草稿恢复映射

2026-06-04 05:14:23 +08:00

【前端架构】CreationUrlStateModel收口计划-2026-06-03.md

refactor: 收口创作恢复身份匹配

2026-06-04 02:04:53 +08:00

【前端架构】CreationWorkDeleteFlow收口计划-2026-06-04.md

refactor: 收口作品架删除确认模型