feat(cli): add --notify (PR #619 BCC-light) + --mode parity to messages send + --notify to message-to#49
Merged
Conversation
…es send + --notify to message-to Closes the cli-side coverage gap that was blocking action ports for --mode and --notify on `messages send`. ## --notify (hosted PR #619, §17 BCC-light) Both `messages send` and `message-to` now accept `--notify <agent_ref>` (repeatable, max 10). Each ref gets a stripped notification copy alongside the main delivery, sharing thread_id. Server contract: MessageCreate.notify (List[str], max-10, app/schemas/message.py). CLI enforces the max-10 cap client-side via UsageError so the failure surfaces at parse time instead of as a server 422. ## --mode parity for messages send cueapi-cli #41 added `--mode` to `message-to` (Surface 6 v2 delivery_mode) but `messages send` was left without it — a cross-product gap surfaced when porting cueapi-action #12 (action couldn't wire --mode through messages-send). Mirroring the existing shape from `message-to`: - click.Choice(["live","bg","inbox","webhook","auto"]), default "auto" - Default-omit: only emit `delivery_mode` on the wire when caller opts away from `auto`. Server treats absent === auto, so the wire format stays identical to pre-Surface-6 senders for the common path. Pinned in regression-guard tests so explicit `--mode auto` is also omitted (not just default omission). ## Wire format Both fields are body fields on POST /v1/messages: - `notify`: List[str], default omit when empty - `delivery_mode`: enum, default omit when "auto" Different from `idempotency_key` (header) and `from_agent` (X-Cueapi-From-Agent header). Verify-server-transport-per-endpoint discipline applied. ## Tests 8 new tests: - messages_send_notify_passed_as_body_list - messages_send_notify_omitted_when_unset - messages_send_notify_max_10_enforced_client_side - messages_send_mode_default_omitted - messages_send_mode_explicit_passed_through (live/bg/inbox/webhook) - messages_send_mode_auto_explicitly_omitted - message_to_notify_passed_as_body_list - message_to_notify_omitted_when_unset 179/179 pass total. ## Why now This unblocks 2 follow-on cueapi-action ports: - action `messages-send` --notify wire-through - action `messages-send` --mode wire-through (reusing existing `mode` input from PR #13 which already wires it for `message-to`) Will chain a small action follow-up PR after this lands.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two co-shipped flag ports that close cli-side gaps blocking cueapi-action follow-ups:
--notify(hosted PR #619 §17 BCC-light) on bothmessages sendandmessage-to--modeparity onmessages send(cueapi-cli feat(message-to): --mode <live|bg|inbox|webhook|auto> Surface 6 delivery_mode #41 added it tomessage-toonly — leaving a cross-product gap)--notify (PR #619 §17 BCC-light)
Each ref in
--notifygets a stripped notification copy alongside the main delivery, sharing thread_id so notify recipients can reply into the conversation. Repeatable; max 10 enforced client-side via UsageError to surface the cap at parse time instead of as a server 422.Server contract:
MessageCreate.notify: List[str](max-10),app/schemas/message.py. Body field, default omit when empty.--mode parity on messages send
cueapi-cli #41 shipped
--modeonmessage-to(Surface 6 v2 delivery_mode) butmessages sendwas left without it. Surfaced as a real gap when porting cueapi-action #12 — action couldn't wire--modethroughmessages-sendbecause the underlying CLI flag didn't exist.Mirroring exact shape from
message-to:click.Choice(["live","bg","inbox","webhook","auto"]), defaultautodelivery_modeon the wire when caller opts away fromauto--mode autois also omitted (not just default omission)Wire format
Both fields are BODY fields on
POST /v1/messages:notify:List[str], default omit when emptydelivery_mode: enum, default omit whenautoDifferent transport from
idempotency_key(header) andfrom_agent(X-Cueapi-From-Agent header). Verify-server-transport-per-endpoint discipline applied.Tests
8 new tests across both commands:
messages_send_notify_passed_as_body_listmessages_send_notify_omitted_when_unsetmessages_send_notify_max_10_enforced_client_sidemessages_send_mode_default_omittedmessages_send_mode_explicit_passed_through(live/bg/inbox/webhook)messages_send_mode_auto_explicitly_omittedmessage_to_notify_passed_as_body_listmessage_to_notify_omitted_when_unset(171 → 179, +8 new.)
Why now
PM identified the cli upstream gap during today's CTO-call after action #12 was unable to wire
--mode+--notifythrough messages-send. This PR closes the gap; will chain a small cueapi-action follow-up after merge to wire through.Test plan
app/schemas/message.pyMessageCreate.notify🤖 Generated with Claude Code