feat(message-to): --mode <live|bg|inbox|webhook|auto> Surface 6 delivery_mode#41
Merged
Merged
Conversation
2 tasks
3 tasks
…ery_mode Adds CLI surface for the PRD Surface 6 v2 delivery_mode field (token: CTO-AGENT-DIR-SURFACE-6-SECONDARY). - New --mode option on `cueapi message-to`, Click.Choice over the 5 documented values, default `auto` - Default-omit discipline: only sends `delivery_mode` in the POST body when the user opts away from `auto`, since absent == auto on the server. Keeps wire-format identical for pre-Surface-6 senders and avoids payload noise on the common path. - Surfaces `effective_delivery_mode` from the response as a `Sent via:` line. When the server downgrades (e.g. requested `live` but recipient has no live session, server delivered via `inbox`), the line reads `Sent via: inbox (requested live, recipient does not support it)`. Flag-passing only — works against current server (field ignored), works correctly once the server-side bridge ships. 8 new tests (160 total), covering: default-auto omits the field, explicit `--mode auto` also omits, each non-auto value passes through and surfaces in output, invalid value rejected by Click, downgrade is surfaced with the requested-vs-effective hint, missing field on legacy server doesn't print a stray "Sent via" line, --help lists the flag and all 5 choices. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
govindkavaturi-art
force-pushed
the
feat/message-to-mode-flag
branch
from
cd731b1 to
a433e6c
Compare
govindkavaturi-art
approved these changes
May 7, 2026
Member
govindkavaturi-art
left a comment
govindkavaturi-art
left a comment
There was a problem hiding this comment.
Surface 6 delivery_mode flag on cueapi message-to — extends #40's command with --mode <live|bg|inbox|webhook|auto>. Approve.
6 tasks
mikemolinet
added a commit
that referenced
this pull request
May 10, 2026
…es send + --notify to message-to (#49) 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.
6 tasks
mikemolinet
added a commit
that referenced
this pull request
May 12, 2026
…y, Mike body-verify directive 2026-05-11) (#55) Parity port of cueapi-python #41 — body-verify Phase 2 on cues.fire, but **OPT-IN** (not default-on) because the substrate's /v1/cues/{id}/fire endpoint echoes a pydantic-after-parse body that may include server-side default-population, causing spurious diff vs the CLI's canonical-JSON serialization. Mirrors primary's #41 design rationale: default OFF; caller opts in with --verify when they know substrate echo semantics match their serialization (typical for the sha256 constant-cost path). Diverges from messages-send body-verify which is default-on (--no-verify opt-out) because that endpoint echoes the raw STRING body field per the spec-lock — no parsed-defaulted shape concern. Implementation: - New --verify click flag (is_flag, default False). Help text documents the OPT-IN rationale + the substrate-echo-shape concern. - When --verify: send X-CueAPI-Verify-Echo: true header; pre-compute sha256(canonical-JSON(body)) hexdigest client-side. - On 2xx response: compare sha256 first (constant-cost). If sha mismatch, fall back to string compare of body_received vs canonical body JSON. Spurious sha mismatch (e.g. canonical-JSON serialization diff) is rescued by the string compare. - Defensive isinstance: body_received as string (post-#798 spec-lock) OR dict (pre-#798 wire shape). Matches the same pattern in cueapi-cli messages-send (#53) and cueapi-python messages.send (#40). - On confirmed mismatch: exit 7 with byte-divergence diagnostic. Uses click.echo + raise SystemExit(7) directly (NOT echo_error which would raise SystemExit(1) and shadow the verify-specific exit code). Tests (4 new): - test_fire_verify_off_by_default_omits_header — no --verify ⇒ no X-CueAPI-Verify-Echo header (preserves pre-#791 wire format) - test_fire_verify_on_sends_header — --verify ⇒ header set + sha match path passes silently - test_fire_verify_help_lists_flag — --help mentions --verify + the opt-in rationale so users discover the design context - test_fire_verify_mismatch_exits_7 — substrate echoes corrupted body ⇒ exit 7 with "body-verify mismatch" diagnostic Full file: 219/219 passing (was 215 + 4 new = 219). Backlog row: cmp1wj0q3. Out of scope: - cueapi-mcp parity (Backlog cmp1wj2a6) — separate PR.
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
2 participants
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
CLI half of PRD Surface 6 v2 (token
CTO-AGENT-DIR-SURFACE-6-SECONDARY). Extends `cueapi message-to` with a `--mode` flag that maps to the new server-side `delivery_mode` field on `POST /v1/messages`.Flag-passing only — works against current server (field ignored), works correctly once the server-side bridge ships. Stacked on top of #40 (`feat: cueapi message-to `); GitHub will tighten the diff to just this change once #40 merges.
Sequencing
cueapi (main) is on the server-side bridge (~1-3d). This PR doesn't depend on his merge — flag-passing logic ships immediately; once his PR lands, the full chain works.
cueapi-mcp parity (`mode` parameter on `cueapi_messages_send`) ships in a sibling PR right after this one.
Test plan
🤖 Generated with Claude Code