Context
Live operator use of the compose surface (2026-08-17, first real send): "i noticed i can select multiple agents, but never deselect. i would certainly use a chip field here (unless it is already one, and the 2 used neo themes have no styling for this widget yet). a2a priority => 3 radios or a radio group wins here. combo for 3 items is bad UX."
The Problem (verified in source)
- Recipients (
OperatorComposeForm.mjs:95-103): a Neo.list.Base with selectionModel: {ntype: 'selection-listmodel', singleSelect: false} — NOT an unstyled chip field. Click-to-deselect does not work on the shipped list (operator-observed): a selected recipient cannot be removed short of… nothing. A multi-select whose selections are irrevocable is half a control.
- The in-code comment answers the chip question honestly: the engine's
ComboBox/Chip primitive is single-select ("collapses its value to one scalar") — which is WHY the list was chosen. So "use a chip field" is currently an engine gap, not a styling gap.
- Priority (
OperatorComposeForm.mjs:134): a ComboBoxField over exactly three fixed values (low/normal/high). A dropdown hides three always-relevant options behind a click; a radio group shows the whole decision space at zero cost.
The Fix
- Deselect first (the bug half): clicking a selected recipient row toggles it off — whether that is a
selection-listmodel toggle config, a fix in it, or explicit handling. A removable selection is the floor.
- Chip presentation (the design half): render the CURRENT selection as removable chips (chip row above/inside the field, × affordance per chip) over the existing multi-select list — presentation over the working selection model, sidestepping the single-select Chip primitive. If instead the engine's Chip field gains true multi-select, that is a
src/form/field engine ticket to file separately at implementation time — this ticket takes whichever path is honest about effort, and SAYS which it took.
- Priority → radio group (three options,
high preselected — amended 2026-08-21: this ticket predates the shipped combo's documented AC-7 default, "operator steering ranks first at the recipient's turn-start drain", and today's wake-priority incident is that rationale's living proof; the radio group keeps the shipped product decision). If the themes lack radio-group styling for the agentos surfaces, the gap lands in the theme layer work (#17242/#17244 family) rather than being painted over locally.
- Token-governed styling under the §04 bar; zero bespoke CSS values.
Acceptance Criteria
Out of Scope
Sender attribution (#17310) · a general-purpose multi-select Chip engine primitive (file in src/ if chosen at implementation) · operator pane information design beyond these two controls (#17268 family).
Related
#17310 (same surface, attribution) · #17268 (pane design feedback thread) · #17242 / #17244 (theme layers) · #17263 / PR #17279 (§04 bar) · Epic #14560 (parent)
Live latest-open sweep: REST created-descending, latest 12 checked 2026-08-17T18:17Z, no equivalent; A2A window clean.
Origin Session ID: 7ee47ccf-d1c7-469d-a75e-15cebf3b5ea5
Retrieval Hint: query_raw_memories("operator compose recipients deselect chips priority radio group combo")
Context
Live operator use of the compose surface (2026-08-17, first real send): "i noticed i can select multiple agents, but never deselect. i would certainly use a chip field here (unless it is already one, and the 2 used neo themes have no styling for this widget yet). a2a priority => 3 radios or a radio group wins here. combo for 3 items is bad UX."
The Problem (verified in source)
OperatorComposeForm.mjs:95-103): aNeo.list.BasewithselectionModel: {ntype: 'selection-listmodel', singleSelect: false}— NOT an unstyled chip field. Click-to-deselect does not work on the shipped list (operator-observed): a selected recipient cannot be removed short of… nothing. A multi-select whose selections are irrevocable is half a control.ComboBox/Chipprimitive is single-select ("collapses its value to one scalar") — which is WHY the list was chosen. So "use a chip field" is currently an engine gap, not a styling gap.OperatorComposeForm.mjs:134): aComboBoxFieldover exactly three fixed values (low/normal/high). A dropdown hides three always-relevant options behind a click; a radio group shows the whole decision space at zero cost.The Fix
selection-listmodeltoggle config, a fix in it, or explicit handling. A removable selection is the floor.src/form/fieldengine ticket to file separately at implementation time — this ticket takes whichever path is honest about effort, and SAYS which it took.highpreselected — amended 2026-08-21: this ticket predates the shipped combo's documented AC-7 default, "operator steering ranks first at the recipient's turn-start drain", and today's wake-priority incident is that rationale's living proof; the radio group keeps the shipped product decision). If the themes lack radio-group styling for the agentos surfaces, the gap lands in the theme layer work (#17242/#17244 family) rather than being painted over locally.Acceptance Criteria
highdefault (the shipped AC-7 steering rationale, amended from the originalnormal— see The Fix §3); combo gone.AGENT:*broadcast row — the broadcast sentinel keeps its existing exclusive behavior if it has one; if it does not, its interaction with individual selections is defined and tested).toas array; sender stays transport-fact (#17310 owns attribution).Out of Scope
Sender attribution (#17310) · a general-purpose multi-select Chip engine primitive (file in
src/if chosen at implementation) · operator pane information design beyond these two controls (#17268 family).Related
#17310 (same surface, attribution) · #17268 (pane design feedback thread) · #17242 / #17244 (theme layers) · #17263 / PR #17279 (§04 bar) · Epic #14560 (parent)
Live latest-open sweep: REST created-descending, latest 12 checked 2026-08-17T18:17Z, no equivalent; A2A window clean.
Origin Session ID: 7ee47ccf-d1c7-469d-a75e-15cebf3b5ea5
Retrieval Hint:
query_raw_memories("operator compose recipients deselect chips priority radio group combo")