Charles YaoandClaude Opus 5 342cfc8545 fix(workflow): an ASCII comparison operator becomes the engine's own ...

An LLM writes `>=` where graphon's `SupportedComparisonOperator` (and the
list-operator's `FilterOperator`) spell `≥`; pydantic refuses it at
`Graph.init`, so F4's whole Edit batch was rejected and the session parked
at `edit.plan_approval` with nothing written.

`_normalize_condition_list` -- the walker that already visits all five
condition containers and already holds `comparison_operator` in hand --
now canonicalizes the two ordering forms (`>=`→`≥`, `<=`→`≤`) BEFORE the
value rule, which keys on that operator.

Only the ordering forms. Every equality-family ASCII form is ambiguous:
graphon's string equality is `is`/`is not` (`_assert_is` takes `str|bool`)
and its number equality is `=`/`≠` (`_assert_equal` takes only
numbers/bools), so `==`, `!=` and `<>` carry exactly the ambiguity that
keeps `equals`/`gte` rejected. Ordering carries none: graphon has no string
ordering operator at all, so `>=` can only mean `≥`.

`heal_nodes_for_preflight` is the one shared definition of the
deterministic heals a graph gets before it is preflighted, so the write
chokepoint and the dry run that decides applicability cannot drift apart.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-22 16:30:54 -07:00

..

prompts

feat(workflow-generator): the plan declares producer outputs, and an LLM node's are the engine's

2026-09-22 15:18:42 -07:00

__init__.py

perf(workflow-generator): parallelize node config generation (#38975)

2026-07-17 02:34:15 +00:00

runner.py

fix(workflow): an ASCII comparison operator becomes the engine's own

2026-09-22 16:30:54 -07:00

tool_catalogue.py

fix(dify-builder): wire resource readiness into recommender/gap prompts

2026-09-20 16:41:52 -07:00

types.py

feat(workflow-generator): the plan declares producer outputs, and an LLM node's are the engine's

2026-09-22 15:18:42 -07:00