mirror of
https://github.com/multica-ai/multica.git
synced 2026-08-03 19:20:07 +02:00
* feat(agents): pick an emoji as the agent avatar (MUL-5534) The server has always seeded a new agent with a random `emoji:<char>` avatar and every renderer already parsed the marker, but the only way a user could change one was to upload an image. Clicking an agent avatar now opens a picker offering both: the image upload it always had, plus the emoji set the product hands out, with the full searchable picker one click behind it. Emoji stays opt-in per call site (`onEmojiSelected`), so user, workspace, and squad avatars keep their click-straight-to-upload behavior. Co-authored-by: multica-agent <github@multica.ai> * fix(agents): lock the avatar while a pick saves, single-owner failures Two problems from review of the emoji picker: An edit caller PATCHes on every pick, and the emoji path never entered `busy`, so a second pick could be started while the first was still in flight. The two writes are last-one-to-arrive-wins on the server, which means the user's newer choice can lose to the older one and stick — the invalidate that follows only converges on whatever the server kept. The callback now runs inside `busy`, so the trigger is disabled until the save settles. Persistence failures were reported twice on the agent detail page: `handleUpdate` toasts and then rethrows so autosave can render a failed state, and the control toasted the same error again. `persistedByCaller` makes the ownership explicit — a caller's rejection is theirs to report, and the upload this control runs itself stays the one failure it owns. That double toast predated the emoji path on the image flow too, and is fixed for both. Regression tests cover the pending lock (deferred promise), and that neither a rejected emoji save nor a rejected image save toasts here while an upload failure still does. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>