fix(workflows): strip a resolved condition before the true/false check

[jawwad-ali]

Problem

evaluate_condition() special-cases the strings "false"/"true" so that a condition resolving to text behaves as a boolean — its own comment says so:

# Treat plain "false"/"true" strings as booleans so that
# condition: "false" (without {{ }}) behaves as expected.
if isinstance(result, str):
    lower = result.lower()

It matches with result.lower() and never strips. But the most common way a string reaches a condition is captured command output, and the shell step stores stdout verbatim (steps/shell/__init__.py:67):

"stdout": proc.stdout,

So run: echo false resolves to "false\n" — which matches neither branch and falls through to bool("false\n") → True.

Reproduction on current main (81bf741)

shell stored stdout      : 'false\n'
evaluate_condition       : True     <-- expected False

  'false'      -> False
  'false\n'    -> True     <-- bug
  'false\r\n'  -> True     <-- bug
  ' false'     -> True     <-- bug
  'FALSE\n'    -> True     <-- bug

An if step takes its then branch on a step that printed false, and while/do-while keep dispatching their body — engine.py uses this same function as the loop-continuation predicate.

There is no workaround

_REGISTERED_FILTERS is ("default", "join", "map", "contains", "from_json") — there is no trim filter, and docs/reference/workflows.md:510 lists the same five. A workflow author has no way to strip stdout before a condition, so this cannot be worked around in YAML.

Fix

One line — result.strip().lower().

Existing precedent for stripping before matching boolean text:

Site	Code
steps/init/__init__.py:241	resolved.strip().lower() in ("true", "1", "yes")
workflows/catalog.py:410	raw_install.strip().lower() in (...)
workflows/catalog.py:1099	same

To be precise about the precedent: those return False for anything unmatched, whereas evaluate_condition falls through to bool(result). They justify the strip, not the surrounding semantics.

Breaking risk

Only strings whose stripped form is exactly false/true but whose raw form is not. Whitespace-padded false/FALSE now evaluate to False instead of True — that is the bug being fixed. Padded true was already True via bool() and stays True.

bool(result) below still sees the raw string, so nothing else changes: a whitespace-only string is still truthy, and "falsey" is still truthy. Both are pinned by a new test.

Verification

• Fail-before / pass-after: reverting only the changed line makes test_condition_strips_captured_command_output fail (True = evaluate_condition('{{ steps.check.output.stdout }}', ...)); restoring it gives 2 passed.
• tests/test_workflows.py → 839 passed, 20 failed; the failure set is byte-identical to the clean-main baseline I captured on 81bf741 (20 in this file, all Windows symlink-privilege).
• uvx ruff@0.15.0 check src tests → clean

Tests go into the existing TestExpressions, beside test_condition_evaluation.

---

Written with assistance from Claude Code. Bug found, reproduced, and verified by me on current main.