fix(flows): tighten builder input grounding — arg-name validation + input_context dry-run + boolean typing (B13, B7, B8)

[graycyrus]

The builder-grounding batch — three related fixes tightening how the builder grounds a workflow's inputs. Fires now that B3 (#4651) merged (they share builder_tools.rs/ops.rs/prompt.md).

B13 — validate arg NAMES against the input schema 🔴 HIGH

The builder wired SLACK_SEND_MESSAGE with a text arg, but that action wants markdown_text → runtime 400 "Unsupported Slack send message field(s)". validate_tool_contracts (#4605) checked required args were present but not that provided arg names are valid properties of the action's schema.

• New unsupported_arg_names(schema, args) (caps.rs) + wired into validate_tool_contracts (ops.rs): for each Composio tool_call, reject config.args keys not in input_schema.properties, naming the bad key + the valid names + get_tool_contract.
• Guards: skips when input_schema is None / has no properties / declares additionalProperties; never applies to native oh: or agent/http nodes. Input-side twin of B1.

B7 — dry-run flags a null input_context 🔴 LOW

#4590 made a null agent prompt dry-run-fatal but not a null input_context (the primary input channel). Added an agent_input_context_nulls pass (mirrors the prompt-nulls pass) into the ok:false condition + payloads.

B8 — type agent outputs used as booleans 🔴 LOW (prompt-only)

A condition mis-routed because an agent emitted the string "false" (truthy) not the boolean false. Engine is correct; prompt.md now tells the builder to declare type:"boolean" for any agent output feeding a condition/boolean use.

Verification

cargo check/fmt clean · flows:: 383 pass (+10 new: 6 unsupported_arg_names unit, 4 validate_tool_contracts arg-name, 1 input_context dry-run) · B14 on_error:route test green.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 11 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b91907a3-f52f-42ae-bbd7-cc87c4cbcf86

📥 Commits

Reviewing files that changed from the base of the PR and between 25ce5b7 and f891fd3.

📒 Files selected for processing (6)

• src/openhuman/flows/agents/workflow_builder/prompt.md
• src/openhuman/flows/builder_tools.rs
• src/openhuman/flows/builder_tools_tests.rs
• src/openhuman/flows/ops.rs
• src/openhuman/flows/ops_tests.rs
• src/openhuman/tinyflows/caps.rs

---

_{Comment @coderabbitai help to get the list of available commands.}