feat(daemon): a Slack elicitation offers a multi-select and a Confirm

[spacedragon]

Implements the Slack-column item on #1794: multi-select on Slack, with no modal.

Multi-select landed for webchat in #1801 and declined on Slack, because a row of buttons cannot express "pick several, then confirm". multi_static_select can, inside a message — which is why this is separate from the form work that does need a modal.

The interaction, and where the in-progress selection lives

A multi_static_select does not submit itself: Slack delivers an interaction on every selection change, and the reader needs a separate Confirm. So the card is select + Confirm + Dismiss.

Checked rather than assumed: Slack re-sends the whole selection on each change (actions[0].selected_options), so nothing accumulates — only the last one has to be remembered. It lives on the card's own pending record and is freed by every settle path, so there is no new cleanup hook. Nothing else could hold it: the relay persists no message content, and Confirm's button value is frozen at render time.

It is seeded from the schema's default, matching the select's initial_options, so an untouched Confirm submits exactly what the card was posted showing. It is relayed, never trusted — Confirm delegates to the same path as every other answer, so #1815's re-derivation against the card is still the only thing that makes it valid.

Message-level state.values was deliberately not used: it is documented for views, and I could not confirm Slack populates it for elements in a message's actions block. The selected_options route needs no such guarantee.

Per-kind option limits, because Slack's two caps differ

#1813 made the option limit a property of the surface. It has to become a property of the surface and the kind, because Slack's caps are not the same thing:

• enum → 24 options (the 25-element actions block minus Dismiss) — unchanged
• multi-enum → 100 options (the select's own cap) and 75 characters per option value

That 75-char value cap is exactly why #1813 rejected static_select for single-select. A multi-select has no button fallback, so an over-long option value declines instead. Keeping the limits per kind is what stops the select's 100 quietly widening the button row's 24 — pinned by a test where 25 buttons still decline while 25 select options do not.

One design consequence worth naming: the request id rides the select's own action_id, not its option values, because a card identified only by its selected options cannot report an empty selection. Option values therefore stay bare, so the 75-char cap applies exactly.

Both interaction edges needed changing, and that was not avoidable

The existing ac_elicit:* / elicitation-choice path could not be reused: a select payload has no value field at all, and Confirm is a third verb with no room in one nullable string. Both edges — the relay's HTTP ingest and the daemon's Bolt handlers — decode two new verbs, carried as two new RdSlackAction members rather than by widening value.

Skew: forward (new relay → old daemon) fails closed — zod rejects the action, the forward is refused, the card stays live. Backward (old relay → new daemon) simply never sends them, so Confirm submits what the card was posted showing, which is why seeding from default rather than leaving it empty matters.

The relay also folds the selection into its dedup id, so two changes on one card are two interactions rather than one swallowed.

The approval DM would have been widened silently

sendApprovalDm reuses buildElicitationCard, so adding multi-enum to the Slack surface widened the DM card too — and a DM tap settles through the editor path, which holds no per-card selection. That would have been a Confirm that could never work.

SLACK_DM_ELICIT_SURFACE (enum + boolean) now bounds it, and the DM's own re-derivation sites use it. This is the same shape as the ?? [] empty-DM-card hole already tracked on #1794.

Known gaps, recorded on #1794 rather than left in this body

• A refused Confirm is silent. The re-derivation convention is "drop it, leave the card live", so a below-minItems Confirm tells the reader nothing. Mitigated by putting the bounds on the card as a context line; the proper fix is an ephemeral response_url reply.
• The 75-char option-value cap bites in practice. Enum values that are paths, URLs or ids are common, and such a multi-select declines on Slack while rendering on webchat. Same fix as feat(daemon): a URL elicitation posts a consent card on Slack #1821's long-URL gap: a per-request nonce with a server-side lookup.
• minItems: 0 with a seeded default makes an untouched Confirm accept [], indistinguishable from a deliberate empty choice. Webchat reads it the same way (feat(console): webchat answers multi-select elicitations #1801), so consistency was kept rather than inventing a second rule.

Verification

• protocol 488, relay 646, web 2404 — green.
• pnpm typecheck: error TS count 0. eslint + prettier clean on the 15 changed files.
• Affected daemon suites (render, daemon-permission-autoallow, elicit-decline-notice, approval-dm, daemon-commands, slack-status-actor, turn-chrome): 388 passing, independently re-run.
• Full daemon suite: 11 files failing, all confirmed as the known-unrelated set — acp-matrix dialling live runtimes, the five skills-CLI files (skills CLI exited with status 1), bwrap sandbox, the memoed evaluation-runner baseline, and daemon-smoke's gitcred/workspace pair, which reproduced exactly at HEAD with the source reverted. Two more (daemon-duty-drain, daemon-hook) pass alone and were a different pair in an earlier run — full-suite load flakes.

One real failure this caused, fixed here: elicit-decline-notice.test.ts used a multi-select as its "Slack cannot render this" exemplar. It now uses a free-text field, plus a case asserting a multi-select gets a card and no notice.

Every new test was confirmed red with only the source reverted — 12 daemon cases across four files and 2 relay cases, with failures like Target cannot be null or undefined (no card) and Cannot read properties of undefined (reading 'kinds') (no DM surface).

[agentconnect-md-test]

One correctness issue needs fixing: the new Confirm flow submits the last selection cached for the card, which can differ from the clicking user's current selection. I reproduced both a delayed selection handler causing an older list to be accepted and one reader confirming another reader's draft.

Use the Confirm interaction's own state.values for this select, then apply the existing validation. Slack explicitly documents full state for message block_actions in its full-state changelog.

Validation: 388 focused daemon tests and 43 relay tests passed; the reproductions above exercised the changed code without adding repository tests.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}

[agentconnect-md-test]

[P2] Confirm must submit the clicking user's current selection

rec.selected is shared by every reader of this card and reflects processing order, not the state being confirmed. Reproduced: A selects lint, B selects test, then A confirms and the runtime receives ['test']. Even with one reader, delaying the selection handler's store.getSession() lets a later Confirm overtake it and accept the previous list; both interactions are acknowledged successfully. The whitelist cannot detect this because the stale values are valid options.

Read and forward this select's state.values[block_id][action_id].selected_options from the Confirm payload on both Slack ingress paths, and validate that snapshot. Slack explicitly includes message state in block_actions, so confirmation need not depend on earlier change events.

[spacedragon]

Fixed in d708c35, and thank you for the two-reader reproduction — that is what makes it a correctness bug rather than a race. rec.selected was a second copy of the truth, shared by every reader of one card and ordered by processing, and the re-derivation structurally cannot catch it: a stale selection is made of options the card really did offer, so the accept asserts a reader chose something they did not.

You were also right about the changelog; my reason for avoiding state.values was that I could not confirm Slack populates it for elements in a message's actions block, and it has since 2020-09-01.

What changed:

• selectedOptionsFromState(state, actionId) — a pure codec in relay-cp.ts, beside decodePermValue for the same reason: both Slack ingress paths must read one card identically. It searches state.values by action id across every block, so it does not depend on how Slack grouped the card's elements, nor on the card naming that block — the direct socket path posts no block_id when there is no session target.
• Both edges forward the snapshot on Confirm, and it goes through the same multiSelectAccepts gate as before.
• The shared state is gone, not supplemented: PendingElicit.selected and noteElicitSelection are deleted. A self-contained Confirm was the point, so leaving the copy beside a snapshot would have kept the bug reachable.
• elicitation-select is dropped too — it existed only to feed that record. The relay now returns null for it (Slack still gets its 200 via the fall-through), and the daemon keeps app.action(/^ac_elicit_select:/) as a bare ack() only because Bolt logs an unhandled-request warning otherwise. The select's action_id survives as the key the snapshot is found under.

Two things the fix turned up: null vs [] is now load-bearing — no state for that select forwards nothing and leaves the card live, rather than confirming a selection it cannot see, while an emptied select is still a real answer. And the dedup id now hashes the values, or two Confirms carrying different selections would have collapsed into one redelivery.

Tests: your literal sequence at the relay edge (A selects, B selects — both forward nothing now — A confirms with ['lint'], B with ['test']), plus a coordinator test asserting each reader's Confirm resolves the runtime with their own list. Against the old sources that test times out, which is the bug's own signature: the submitted list is not the one the reader tapped, so the re-derivation refuses it and the request is never answered.

[agentconnect-md-test]

Confirmed in d708c35b: both Slack paths submit Confirm’s own selection, the shared cache is gone, and missing state stays distinct from an empty selection. Existing validation still applies.

This resolves my P2 finding.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}

[agentconnect-md-test]

Approved at d708c35b. The previous P2 finding is resolved: both Slack paths submit the Confirm interaction's own selection, the shared selection cache is removed, and missing state remains distinct from an empty selection. Existing option and bounds validation still applies.

No remaining blocking findings. Validation: 390 focused daemon tests and 44 relay tests passed; daemon and relay typechecks passed.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}