chore: promote staging to staging-promote/b6b3ffa1-23819569437 (2026-04-01 00:16 UTC)

[ironclaw-ci]

Auto-promotion from staging CI

Batch range: b6b3ffa1a42fa4d27b51edbe3e43ac1a78be430d..f441d788b3838dd17e650b288cc6c11a9c4c907d
Promotion branch: staging-promote/f441d788-23825523544
Base: staging-promote/b6b3ffa1-23819569437
Triggered by: Staging CI batch at 2026-04-01 00:16 UTC

Commits in this batch (2):

• bb9a760 chore: whats app lock file (chore: whats app lock file #1824)
• f441d78 fix(relay): route async Slack messages to correct channel instead of DMs (fix(relay): route async Slack messages to correct channel instead of DMs #1845)

Current commits in this promotion (0)

Current base: staging-promote/b6b3ffa1-23819569437
Current head: staging-promote/f441d788-23825523544
Current range: origin/staging-promote/b6b3ffa1-23819569437..origin/staging-promote/f441d788-23825523544

• (no non-merge commits in range)

Auto-updated by staging promotion metadata workflow

Waiting for gates:

• Tests: pending
• E2E: pending
• Claude Code review: pending (will post comments on this PR)

---

Auto-created by staging-ci workflow

[claude]

Code review

Found 5 issues:

1. [MEDIUM:70] Metadata field naming inconsistency between routine creation and execution

The PR correctly carries notify_channel from context in both routine_engine.rs (where it's set) and routine.rs (where it's read). However, this creates a subtle temporal ordering dependency: routines created via the tool read from the incoming context, while routines executed by the engine write the metadata. This works but obscures the data flow. Consider documenting the metadata propagation path more explicitly to clarify when/where notify_channel is available.

https://github.com/anthropics/ironclaw/blob/7113fba4fcd3356d90e499b8853a1ee52d0739b9/src/tools/builtin/routine.rs#L1184-L1189

2. [MEDIUM:50] Redundant .clone() in Option fallback chain

The code calls .clone() before .or_else() on an Option that will be moved into the struct. Since or_else consumes self, the clone is unnecessary. This works but wastes a string allocation.

https://github.com/anthropics/ironclaw/blob/7113fba4fcd3356d90e499b8853a1ee52d0739b9/src/tools/builtin/routine.rs#L1184

Consider:

channel: normalized.delivery.channel.or_else(|| {
    ctx.metadata
        .get("notify_channel")
        .and_then(|v| v.as_str())
        .map(ToOwned::to_owned)
}),

3. [LOW:75] Parameter descriptions in message.rs could be clearer about precedence

The schema descriptions mention "defaults to current channel" but don't clarify that this only applies when metadata is absent. The note: "Defaults to current conversation channel if no execution-local routing metadata exists." would be more accurate.

https://github.com/anthropics/ironclaw/blob/7113fba4fcd3356d90e499b8853a1ee52d0739b9/src/tools/builtin/message.rs#L207-L212

4. [LOW:65] Routine engine regression test could verify full data flow

The test test_build_lightweight_prompt_preserves_notify_config validates that notify metadata appears in the prompt string, but doesn't exercise the full routing path (whether the message tool actually uses it). Consider adding an integration-style test that mocks tool execution.

https://github.com/anthropics/ironclaw/blob/7113fba4fcd3356d90e499b8853a1ee52d0739b9/src/agent/routine_engine.rs#L2588-L2610

5. [LOW:60] RelayClient Slack error handling could be generalized

The ok=false error check is correctly added to proxy_provider(), but other Slack relay endpoints like initiate_oauth() and create_approval() may also return HTTP 200 with error semantics. Consider generalizing this pattern to all Slack API calls.

https://github.com/anthropics/ironclaw/blob/7113fba4fcd3356d90e499b8853a1ee52d0739b9/src/channels/relay/client.rs#L280-L301

Review summary: No security issues found. All changes follow CLAUDE.md patterns (no unwrap/expect in production, proper error handling, type-driven design). The PR correctly fixes message routing bugs with good test coverage. Issues flagged are minor code clarity and optimization opportunities.