Repository navigation
Local Chief turns pink after a friend named Chief is added #963
Description
Written-by: Dev
Environment
FlyBot home, after adding a friend whose Bot is also named Chief. The local Chief is the Main Bot (blue whale, stored color deepseek). The friend's Chief is drawn in pink.
Steps to reproduce
- Keep the local Chief on its stored look (whale, deepseek).
- Add a friend whose Bot display name is also Chief and whose look is pink.
- Open a group the local Chief is in, and look at the local Chief's 1:1 row, the group icon, and an in-chat Chief mark (the
@Chiefchip DSH draws, and the Chief seat in the group).
Actual
The local Chief's 1:1 sidebar row stays the blue whale. The group icon and the in-chat Chief mark turn pink — the color used for the friend's Chief. Owner: 「加完好友之后，我自己的Chief的颜色不对了，变成粉色了」.
Expected
The owner's own Chief keeps its stored local look (blue whale / deepseek) on every surface that is that local Bot. A friend's Bot may keep a different look. Adding a friend does not repaint a local Bot.
Where it sits
core/src/client/index.jsinstallMentions: the file-chip rule is[title="@${bot.name}"], so a later Bot with the same name overwrites the chip color and silhouette. Remotes are created after locals, so the friend's Chief paints every@Chiefchip. The id-specific mention anchor is unaffected, which is why the 1:1 row (the bot object itself) stays blue.core/src/client/sources.jsindexRoster: each bot is indexed by its parts, current session, and id, and a later bot replaces an earlier key. A friend's chat that shares a key paints the friend's look onto the local Bot's group seat and bubbles (roster.byId), while the sidebar still walks the local object.core/src/client/mark.jsRoomAvatar: local members are seated first and remote participants after them. The later seat is drawn on top, so a pink friend seat covers the local whale and the group icon reads as pink.
Suggested direction
Local identity wins. A shared display name is not a shared look: the @Name chip uses the local Bot when one exists, a Bot's own id and session keys are not replaced by a friend's chat, and a local member stays in front of a friend's seat in the group icon. The friend's own row keeps the friend's look.
Activity
Birfy commentedon Oct 24, 2026
Triage on
1dd057df— the reported location is right and the mechanism is one selector, not the roster.core/src/client/index.js:289installMentions(), rule at:295:The rule is keyed on the display name, and it is applied in roster order. Remotes are created after locals, so a friend's Bot also called
Chiefmatches every@Chiefchip and installs its own colour and silhouette over the local one. The 1:1 sidebar row stays correct because it draws the bot object itself; the group icon and the in-chat mark go through the chip path, which is why only they turn pink.core/src/client/sources.jsindexRosterhas the same shape: bots are indexed by parts, current session and id, and a later record replaces an earlier key.Expected
A chip that names a local Bot must be keyed by that Bot's id, not by its display name. Adding a friend must never repaint a local Bot, and two Bots that share a display name must each keep their own look wherever the identity is known (1:1 row, group icon,
@Namechip, seat in the room).Acceptance
Chief(stored colourdeepseek, whale) + a friend's Bot also namedChief(pink): the local Bot's 1:1 row, group icon,@Chiefchip and room seat all keepdeepseek.Dedupe
#389 and #502 are about naming and wording in the sidebar and cards; this is a look bleed through a name-keyed CSS rule, a different mechanism. Not filed before.
Notes
A pull request exists: #965 (
Fixes #963), bodyOwner: Birfy/Reviewer: Reviewer— different names, so the#951rule is satisfied. This issue carries the type and area for the record;agent-readyis not applied because the pull request already exists.Keep a local Bot's color when a friend shares its name (ThinkFlowLab#965