fix(dashboard): label steward answers as the LoopX Manager - #4555
Conversation
The manager channel's answers were titled with whatever the agent picker held, so a steward turn served on a managed host rendered as "Codex" in the conversation tray. The executor and its model belong to the machine-capability chip; the transcript should name the speaker, not the CLI brand that happened to run the turn. Goal channels keep naming the Goal's own Agent: only the manager context is re-labelled, through one `answerIdentityLabel` helper applied to the return-receipt, history-hydration, recovery, streaming, interruption and failure message paths. Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Exact head reviewed: dc4a0d7b1cdc74f78bad4936f4998cbb015dcf16
动机
管家回答在前端/飞书上的标题显示为执行器品牌 Codex，业主读到的应该是"管家在回答"。这不是措辞偏好：管家通道的执行器是可配置的（本机是 dsh + V4.1 Flash high，其他机器可能是 codex），把 CLI 品牌写进回答署名，等于把"机器能力"泄漏成"回答者身份"，并且会随机器配置漂移。
改动思路
把"回答者身份"和"执行器身份"拆开：管家上下文固定署名 LoopX 管家 / LoopX Manager；执行器与模型继续只在机器能力 chips（）里呈现。Goal 通道不受影响，仍署名该 Goal 自己的 Agent。
具体改动
- 新增 ，管家上下文返回 ，其余返回原 label。
- 应用到 9 处管家回答路径：交接回执、历史水合 与"恢复的…会话" 、恢复流式占位与完成文案、发送流式占位（、）、完成兜底、中断、失败文案。
- 浏览器断言： 必须等于 。
对主干的风险
低。纯展示标识，无 API/状态/权限变更；未新增 i18n key（复用既有 ）。唯一共享面是管家会话的标题文本，Goal 通道 feature-off 行为逐字不变。
我的整体评价
正向且 proportional。一处 helper + 一处断言，覆盖了 9 条实际渲染路径，并且负向对照能精确复现业主报告的现象。
Evidence:
-
exact head
dc4a0d7b1cdc74f78bad4936f4998cbb015dcf16 -
→ passed
-
full browser suite → passed ()
-
negative control (hunk stashed) →
-
Pre-Merge Validation Gate
-
status:
passed -
ok:
true -
merge_gate_passed:
true -
self_merge_allowed:
true -
tier:
standard -
dry_run:
false -
changed_files:
3 -
surfaces:
public_boundary -
risk_profiles: ``
-
manual_holds:
0
Pre-merge validation is a risk-based gate: it runs diff hygiene, changed Python compile checks, catalog-selected canaries, risk-profile smokes, and public/private boundary checks. It reports manual holds for benchmark-sensitive or reviewer-gated surfaces instead of treating local smoke success as self-merge permission.
Direct Checks
diff_check_committed:passedgit diff --check origin/main...HEADdiff_check_staged:passedgit diff --cached --checkdiff_check_unstaged:passedgit diff --check
Catalog Canaries
- ok:
true - selected_checks:
4 - executed_checks:
4 - failures:
0 - advisory_failures:
1 - warnings:
0 advisory_inherited_failurepython3 examples/control_plane/control-plane-maintainability-ratchet-smoke.py
advisory_reason: known baseline smoke failure did not mention changed files; record it in the PR comment but do not block this diffpassedpython3 examples/semantic-vocabulary-drift-smoke.pypassedpython3 examples/frontstage-rollout-projections-fixture-smoke.pypassedpython3 examples/showcase-animation-prototype-smoke.py
Public Boundary
- ok:
true - selected_checks:
1 - executed_checks:
1 - failures:
0 - advisory_failures:
0 - warnings:
0 passedloopx check --scan-path apps/presentation/dashboard/src/views/dashboard-page.tsx --scan-path examples/personal-workspace-browser/chat-recovery.mjs --scan-path /Users/bytedance/goal-harness/apps/presentation/dashboard/node_modules → ; advisory known on clean
English verdict: APPROVE
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Correction notice: the previous review on this PR was posted with a body mangled by shell interpolation (backticked identifiers were substituted by command output). This review is the authoritative, complete version; the exact head OID below was produced by git rev-parse HEAD at review time.
Exact head reviewed: dc4a0d7
动机
管家回答在前端上的标题显示为执行器品牌 Codex，而业主读到的是"管家在回答"。这不是措辞偏好：管家通道的执行器是可配置的（本机显式配置为 dsh + V4.1 Flash high，其他机器可能是 codex），把 CLI 品牌写进回答署名，等于把"机器能力"泄漏成"回答者身份"，并且会随机器配置漂移。
复现路径：本地 dashboard 的管家上下文发送"我现在该做什么？"，回答署名渲染为 Codex，而不是 LoopX 管家。
改动思路
把"回答者身份"和"执行器身份"拆开：管家上下文固定署名 LoopX 管家 / LoopX Manager；执行器与模型继续只在机器能力 chips（header.managerRuntime / machine capabilities）里呈现。Goal 通道不受影响，仍署名该 Goal 自己的 Agent。
具体改动
- apps/presentation/dashboard/src/views/dashboard-page.tsx：新增 answerIdentityLabel(targetContextId, goalFallback)，管家上下文返回 t("header.manager")，其余返回原 label。
- 应用到 9 处管家回答路径：交接回执、历史水合 agentLabel 与"恢复的…会话" sourceLabel、恢复流式占位与完成文案、发送流式占位（"正在连接管家"、"LoopX 管家 · 跨 Goal"）、完成兜底文案、中断文案、失败文案。
- examples/personal-workspace-browser/chat-recovery.mjs：浏览器断言 .personal-manager-conversation-tray article.is-assistant strong 必须等于 LoopX 管家。
对主干的风险
低。纯展示标识，无 API、状态机、权限或投递语义变更；未新增 i18n key（复用既有 header.manager，EN/ZH 均已有）。唯一共享面是管家会话的标题文本；Goal 通道 feature-off 行为逐字不变。
我的整体评价
正向且 proportional。一处 helper + 一处浏览器断言，覆盖 9 条实际渲染路径，且负向对照能精确复现业主报告的现象。
Evidence:
- exact head dc4a0d7
- tsc --noEmit -p tsconfig.json: passed
- full personal-workspace-browser-smoke: passed (navigation-sorting, chat-recovery, typed-actions, team-plan, execution-chip)
- negative control (dashboard-page.tsx hunk stashed): fails exactly as reported with "Manager answer was labelled as its executor instead of the steward: Codex"
- loopx canary premerge --from-git-diff: merge_gate_passed true, surfaces public_boundary; one known baseline advisory control-plane-maintainability-ratchet-smoke.py, reproducible on clean origin/main
- First-screen review gate not applicable: conversation-tray label, not hero/nav/first viewport
English verdict: APPROVE
1 participant
动机
业主在飞书/前端读管家回答时，看到的标题是执行器品牌名 Codex，而不是"管家"。这条回答其实由托管宿主上的某个执行器跑出来，但读者关心的是"谁在回答我"，不是"哪个 CLI 恰好跑了这一回合"。
复现（本地 dashboard，管家会话发送"我现在该做什么？"）：
改动思路
回答身份和执行器身份是两个不同的东西：
LoopX 管家/LoopX Manager。header.managerRuntime/ machine capabilities 的职责，本次不改。只有管家上下文（
contextId === "manager"）重新命名；Goal 通道继续用该 Goal 自己的 Agent 名。具体改动
apps/presentation/dashboard/src/views/dashboard-page.tsx：新增answerIdentityLabel(targetContextId, goalFallback)，把 return-receipt、历史水合（agentLabel+ "恢复的…会话"）、恢复流式、发送流式占位（正在连接管家+LoopX 管家 · 跨 Goal）、完成兜底文案、中断、失败共 9 处收敛到同一个 helper。examples/personal-workspace-browser/chat-recovery.mjs：新增断言，管家回答的article.is-assistant strong必须是LoopX 管家。对主干的风险
低。纯展示层文案/标识，不触碰 API、状态机、权限或投递语义；Goal 通道行为不变，仅管家上下文标签改变。前端文案在
header.manager（EN/ZH 已有）上复用，未新增 i18n key。我的整体评价
正向且 proportional：一处 helper + 一处浏览器断言，修掉了"管家回答署名是 CLI 品牌"这个直接可见的体验问题。
Validation:
tsc --noEmit -p tsconfig.jsonpassed.personal-workspace-browser-smokefull run passed:navigation-sorting,chat-recovery,typed-actions,team-plan,execution-chip.dashboard-page.tsxhunk stashed the scenario fails exactly as reported (...instead of the steward: Codex); with it applied it passes.loopx canary premerge --from-git-diff:merge_gate_passed: true, surfacespublic_boundary; one known baseline advisorycontrol-plane-maintainability-ratchet-smoke.pyunrelated to this diff.Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
English verdict: APPROVE