Conditions: no inclusive numeric or date comparison operators (API-bound)

[adriannoes]

Problem

• Condition expressions offer strict numeric comparisons only, so contiguous numeric bands cannot be expressed. Two adjacent bands written as "greater than 20" and "less than 21" leave both boundary values in neither band.
• The workaround is to shift every boundary by one, which works only for integers and silently misclassifies decimals, so no threshold rule on a currency or decimal field can be written correctly.
• Reported from product testing on a real range rule where the boundary values fell outside every band.

Evidence

• Verified read-only by introspection on 2026-09-15. ConditionExpressionInput.operation documents nineteen operations: equals, not_equals, present, blank, string_contains, string_not_contains, number_greater_than, number_less_than, date_is_today, date_is_yesterday, date_in_current_week, date_in_last_week, date_in_current_month, date_in_last_month, date_in_current_year, date_in_last_year, date_is, date_is_after, date_is_before.
• No inclusive form on either side. Numeric: no number_greater_than_or_equal, no number_less_than_or_equal. Date: date_is_after and date_is_before have no inclusive equivalent either, so "on or after" needs an OR group pairing date_is_after with date_is.
• ConditionExpressionInput has exactly field_address, id, operation, structure_id, value, none deprecated when introspected with includeDeprecated: true. No inclusive operator is hidden behind a deprecated input.
• operation is typed String, not an enum, so introspection documents the set without enforcing it and the toolkit passes the value through as a soft enum.
• The operator list ships in five places and none of them states that the numeric and date comparisons are strict: skills/automations/pipefy-automations/SKILL.md:106, docs/mcp/tools/automations-and-ai.md:133, packages/mcp/src/pipefy_mcp/tools/automation_tools.py:463, packages/sdk/src/pipefy_sdk/models/ai_automation.py:32, packages/cli/src/pipefy_cli/commands/automation.py:106.

Scope

• Upstream ask: add number_greater_than_or_equal and number_less_than_or_equal, plus an inclusive form for the date comparisons. Contiguous bands are the common case, and without inclusive operators every boundary needs arithmetic that is wrong for non-integers.
• Local, in the meantime: state the strictness in each of the five places the operator list ships, and give the correct expression rather than only naming the limit. An integer field can shift the boundary by one; a decimal field cannot, and the correct form is an OR group pairing the strict operator with equals for numbers or date_is for dates.
• Do not add local validation that rejects an unknown operator. The field is a String soft enum on purpose so a server-side addition works without a release.

Acceptance

• The five operator lists say the numeric and date comparisons are strict and carry the OR-group expression as the correct workaround for non-integer fields.
• Upstream: create_automation accepts a condition using an inclusive numeric operator and get_automation reads it back.
• Upstream: two contiguous bands expressed with an inclusive boundary classify the boundary value into exactly one band.

Notes

• Related: Errors: business-validation failures return bare "is invalid" (API-bound) #624.
• Open probe: whether the server accepts an undocumented operator string such as number_greater_than_or_equal despite it not being in the documented set. Settling it needs a live create_automation carrying that operation, which is a write and was not run.
• Out of scope: rewriting a strict operator into an OR group on the client. That changes the rule the user asked for without saying so.