[kilianc]

send.rich and text parts in send.multipart now accept mentions arrays containing UTF-16 start, length, and participant handle values. The bridge preserves formatting and part boundaries while applying Messages' mention attribute.

Both RPC and helper validation reject invalid ranges, overlaps, malformed numbers, and unknown mention fields. Nonempty mentions require selectors.sendMentions, so an older helper cannot silently send ordinary text instead. File and URL sends retain their existing restrictions.

Validation: focused RPC mention fixtures, Objective-C message construction fixtures, make lint, and documentation tests. The helper regression first reproduced eight failed assertions for malformed direct requests, then passed after the fix. Independent P0–P2 review passed. Full macOS and Linux checks run in this PR's GitHub Actions.

No live run happened during this maintainer pass. No messages were sent; all proof used synthetic fixtures and no-send construction. Recipient notification behavior was not re-tested live.

Thanks @kilianc for the implementation and fixtures.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge.

What this changes

This PR adds UTF-16 mention ranges to RPC rich sends and multipart text parts.

Example: Send “hi Ann” with mentions [{"start":3,"length":3,"handle":"+15555550123"}].

• Before: RPC rejects the mentions parameter.
• After: A capable helper sends Ann as a native mention; an older helper rejects the request before sending.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The supplied live proof resolves the earlier proof request, and the low-value source assertion is absent; readiness remains capped by the unresolved public RPC direction.
Proof confidence	🦞 diamond lobster (5/6)	Sufficient (terminal): Branch-built imsg rpc and the injected helper exercised rich and multipart mention sends on macOS 27.0.1; terminal output, outgoing rows, and the inspected recipient screenshot establish native mention rendering in a real 1:1 chat, while the released helper rejected a mention before dispatch. This establishes the requested production paths without claiming a group notification was observed.
Patch quality	🦞 diamond lobster (5/6)	No actionable review findings were identified.

Product

Kind: Feature · Worth it: Needs a maintainer decision · Fix scope: Complete
User problem: RPC clients cannot mark message text as native mentions of chat participants.
Reason: The capability has demonstrated user value and a focused implementation, but the new public parameter needs owner direction.

Merge readiness

⛔ Blocked before merge - 1 item remains

This PR provides a distinct capability absent from main, with no actionable correctness findings; an owner decision remains on the RPC extension.

Priority: P2
Reviewed head: 2ccdb62371be4f8e6f3f098f8daefc51c2611422
Owner decision: Required. See Decision needed.

Decision needed

• Question: Should send.rich and send.multipart expose optional mention ranges while CLI mention flags remain outside this PR?
• Recommendation: Approve the scoped RPC extension: Accept optional UTF-16 ranges and capability-gated sends through the existing handlers.
• Why: This adds a public RPC capability to an owner-built contract, and no written owner approval of that direction appears in the discussion.

Before merge

• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

None.

Agent review details

How this fits together

JSON-RPC handlers validate text and mention ranges, probe the injected Messages helper, and pass attributed message bodies to the existing IMCore send path.

flowchart LR
  A[RPC client] --> B[Parameter validation]
  B --> C[Helper capability probe]
  C --> D[Attributed body builder]
  D --> E[IMCore send]
  E --> F[Recipient Messages]

Loading

Technical review

Best possible solution:

Approve the optional RPC mention contract and retain the existing send owners, strict validation, and older-helper rejection.

Do we have a high-confidence way to reproduce the issue?

Current-main parameter allowlists deterministically reject mentions, establishing the missing RPC capability without running target code.

Is this the best way to solve the issue?

The implementation fits the existing RPC and native-body owners, preserves ordinary sends, and avoids exposing arbitrary archived attributed bodies.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 41de9c8b58ff.

Provenance checked

• Multipart RPC accepted parameters changes intended behavior with a stated reason (b0165e4: feat(rpc): complete message contract parity #219 introduced text-only multipart sends with strict outgoing-row verification.)
• Native message construction and helper organization keeps the original intent (cb58dec: refactor: organize the injected helper into private feature modules #296 preserved one compiled translation unit and existing feature owners; this PR extends those owners directly.)
• URL-only rich-send modifier restrictions keeps the original intent (8e3964f: feat: add bridge rich links #165 required strict URL-only modifier validation; mentions remain excluded from that path.)

Testing

Proof path: shipped entry point.

Security

None.

Evidence

What I checked:

• Current main lacks RPC mentions: Main rejects mentions in multipart parts and does not accept mentions among send.rich parameters; repository searches found no equivalent RPC capability or canonical replacement. (Sources/imsg/RPCServer+MultipartHandler.swift:23, 41de9c8b58ff)
• Validated shared representation: Both RPC handlers use the existing strict parameter decoder and shared mention-range validator; the native builder applies mention attributes after formatting and rejects invalid ranges before dispatch. (Sources/imsg/RPCServer+BridgeMessageSupport.swift:100, 2ccdb62371be)
• Live proof supplied after the earlier review: The PR body records branch-built imsg rpc rich and multipart sends on macOS 27.0.1, matching outgoing database rows, and rejection with the released 0.19.1 helper without a new row; the downloaded body screenshot visibly shows both recipient-side mention ranges. Credit to kilianc's supplied runtime verification. (2ccdb62371be)
• Feature ownership and original contract: feat(rpc): complete message contract parity #219 introduced the text-only multipart RPC contract and strict outgoing-row verification; feature history also identifies steipete's RPC and helper refactors and omarshahine's original bridge contribution in feat: port BlueBubbles private-API surface as imsg bridge (fixes #60) #100. (Sources/imsg/RPCServer+MultipartHandler.swift:30, b0165e455f66)
• Repository policy applied: Read the complete root AGENTS.md; no nested AGENTS.md, maintainer notes directory, or pr-simplify skill was present. The change stays focused and adds deterministic parsing and native-body coverage. (AGENTS.md:1, 2ccdb62371be)
• Review limits: Missing historical blobs prevented content-based follow-history searches and the complete earlier-head diff; commit history, current-main blame, pinned introduced hunks, original base snippets, and current tests remained readable. No target code or tests were executed, and the checkout remained clean. (2ccdb62371be)

Likely related people:

• Peter Steinberger: Raw commit b0165e4 adds Sources/imsg/RPCServer+MultipartHandler.swift:29 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: b0165e455f66; files: Sources/imsg/RPCServer+MultipartHandler.swift)

Review metrics

Metric	Value	Why it matters
Production and regression coverage	Production +148/-5 lines; tests +261 lines	Coverage exercises separate Swift validation and native attributed-body boundaries without adding another send path.

Labels

Label changes:

• add proof: sufficient: Contributor real behavior proof is sufficient.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
• add status: ⏳ waiting on maintainer: Only explicit maintainer approvals or decisions remain; merge is still blocked.
• remove status: 📣 needs proof: Current PR status label is status: ⏳ waiting on maintainer.
• remove rating: 🧂 unranked krab: Current PR rating is rating: 🦐 gold shrimp, so this older rating label is no longer current.

Label justifications:

• P2: Useful, bounded RPC functionality with no established urgent regression.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
• status: ⏳ waiting on maintainer: Only explicit maintainer approvals or decisions remain; merge is still blocked.
• proof: sufficient: Contributor real behavior proof is sufficient.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

History

Review history (1 earlier review cycle)

• reviewed 2026-10-25T02:34:21.515Z sha cbbe9b5 :: needs real behavior proof before merge. :: none

Reviewed October 24, 2026, 11:42 PM ET / October 25, 2026, 03:42 UTC (Revision 2).

[kilianc]

e2e test:

[kilianc]

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/40159286808
• Updated: 2026-10-25T03:44:14.605Z