update_bot: an unknown colour is dropped in silence and the call still answers "Updated <name>." #2775

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 5a20be646e934d27b2a1efd231ed9959
Branch: dev/5-bot-color-invalid
Base: f2ef4df
At: 2026-11-10T03:56:37Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.
PR is opened within 24h; merge waits behind the current review queue.

Written-by: FlyBot Lead
Bot: FlyBot Product

updateBot validates the name, the model and the thinking level by throwing; the colour is
the one field it lets pass without storing anything.

• core/src/host/roster.js:211-213 — if (patch.color === null) delete bot.color; else if (isColor(currentColor(patch.color))) bot.color = currentColor(patch.color). No else.
• core/src/host/text.js:12 — isColor accepts 13 COLORS, 6 EXTRA_COLORS, #rrggbb, and 6 legacy names mapped through LEGACY_COLORS; anything else is not a colour.
• core/src/host/tools.js:394 — the tool answers Updated ${next.name}. whatever happened to the colour; its own parameter says One of ….

So update_bot { color: 'purple' } is reported as a successful update and the Bot keeps
the colour it had.

Reproduction (measured on f2ef4dfa)

Probe built on core/test/name-identity.test.js's createRuntime fixture; the temp test
was removed afterwards. Tool called as the Main Bot chief; state.json read back from
disk:

START color=undefined role="Engineer"
PURPLE reply="Updated Dev." stored=undefined
VIOLET reply="Updated Dev." stored="violet"
ROLE   reply="Updated Dev." stored="Testing and Quality Assu" len=24

The first line is the defect: the reply says updated, bots.dev.color did not move. The
last line is the same function's silent role cut (roster.js:208, cut(..., 24),
matching the client's maxLength: 24) — a separate acceptance, not part of this issue.

Why it matters

The caller cannot tell a stored colour from a discarded one, so a Bot retries the same
call, or reports a colour the user never gets. It is the same family as #2771 (the tool
says a thing happened that did not), in the one field updateBot treats differently from
every other field it owns.

Expected

An unknown colour is refused with a sentence naming the field and the accepted set (for
example Color must be one of deepseek, blue, violet, … or #rrggbb); update_bot
returns Could not update the Bot: … through its existing catch. null (clear) and
every accepted name stay byte-identical to today, including the legacy aliases.

Change scope

• core/src/host/roster.js:213: add else throw new Error(...), message built from
  COLORS/EXTRA_COLORS (and #rrggbb).
• core/test/update-bot.test.js: the four cases below, using its existing start() /
  tool() helpers.
• The usual generated companions for a src/host/ change (changelog fragment,
  arch-docs, and ds-bot-patches if the mirror needs it).
• No client change, no state-format change, no endpoint.

Acceptance (red first: 1 red / 2 green measured on the base)

1. update_bot { bot: 'Writer', color: 'purple' } → the answer does not start with
   Updated, names the colour rule, and state().bots.b2.color did not move (base:
   Updated Writer. — red).
2. color: 'violet' → Updated Writer. and the stored colour is violet (guard, green).
3. color: 'kimi' (legacy alias) → stored as charcoal (guard, green).
4. color: null → the colour is removed and the answer is Updated Writer. (guard,
   green today).

Fold-in file: ready/p662-red-first.test.js in the Lead workspace (imports ../index.js
and ./fake-ctx.js, so it sits in core/test/ to run; measured 1 red / 2 green on the
base, then removed from the tree).

Dedupe (two steps, 2026-11-10)

• Backlog: no update_bot/colour entry; P-660 and P-661 are in tools.js, this one is
  roster.js.
• GitHub open: update_bot color 0, bot color invalid 0, color silently 0. No open
  duplicate.