fix(workflows): refuse a filter mixed with a comparison operator instead of silently mis-binding it

[jawwad-ali]

Problem

In _evaluate_simple_expression the pipe is detected before the boolean and comparison operators:

pipe_idx = _find_top_level(expr, "|")
if pipe_idx != -1:
    segments = _split_top_level(expr, "|")
    value = _evaluate_simple_expression(segments[0].strip(), namespace)
    for segment in segments[1:]:
        value = _apply_filter(value, segment.strip(), namespace)
    return value

So a filter written on the right-hand operand of a comparison is applied to the comparison's boolean result, not to the operand.

Reproduction on current main (81bf741)

With inputs.count = 10 and inputs.limit missing:

{{ inputs.count > inputs.limit | default(5) }}   ->  False

count > limit is evaluated first, then default is applied to the resulting bool — which is a no-op, because a bool is never empty. The expression silently returns the comparison against the unfiltered operand. The author meant 10 > 5 → True.

This module already refuses the mirror case

A filter followed by a comparison is explicitly rejected rather than guessed at:

{{ inputs.missing | default('7') > '5' }}
  -> ValueError: filter 'default' used in an unsupported form

…and the test that pins it (test_filter_call_with_trailing_tokens_fails_loudly) states the reasoning:

A trailing operator/token after a filter's closing paren must not be silently discarded […] It must fall through to the "unsupported form" ValueError.

Same ambiguity, opposite handling — one raises, the other quietly returns a wrong answer. This PR applies the decision that was already made to the mirror case; it is not proposing a new precedence rule.

Fix

When the segment before the first top-level pipe contains a top-level comparison or boolean operator, report it:

ambiguous filter precedence in 'inputs.count > inputs.limit | default(5)':
  '| default(5)' would apply to the result of 'inputs.count > inputs.limit',
  not to an operand of '>'. Filter the operand in its own expression instead.

Why nothing legitimate breaks

There is no working use of a filter on a comparison result:

• default on a bool is a no-op (a bool is never None or empty)
• join / map / contains on a bool is an error

So every expression this now refuses was already producing either a wrong value or an error. Verified unaffected:

{{ inputs.missing | default(5) }}          -> 5
{{ inputs.items | join(", ") }}            -> 'a, b'
{{ inputs.items | map("x") | join(",") }}  -> 'a,b'
{{ inputs.items | contains("a") }}         -> True
{{ inputs.count > 5 }}                     -> True
{{ inputs.name == "x" }}                   -> True

The operator scan uses the same _find_top_level helper and the same token list as the operator parsing below it, so a > inside a quoted operand is not mistaken for one.

Verification

• Fail-before / pass-after: test_filter_on_a_comparison_operand_is_refused fails on unpatched src and passes with the fix. tests/test_workflows.py: 21 failed → 20 failed, 838 → 839 passed.
• The remaining 20 are identical to the clean-main baseline captured on 81bf741 (all Windows symlink-privilege).
• uvx ruff@0.15.0 check src tests → clean

Tests sit beside the existing filter-strictness tests, and a second test pins that plain filters, chains, and bare operators are untouched.

---

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

[Copilot]

Pull request overview

Rejects ambiguous filter/operator expressions instead of silently misapplying filters.

Changes:

• Detects comparison and boolean operators before filters.
• Adds regression and unaffected-behavior tests.
• Unary not remains unhandled.

Show a summary per file

File	Description
src/specify_cli/workflows/expressions.py	Adds ambiguous precedence validation.
tests/test_workflows.py	Adds filter precedence regression tests.

Review details

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Balanced

[mnriem]

Address Copilot feedback

[Copilot]

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[jawwad-ali]

@mnriem — I believe this one is ready; the CHANGES_REQUESTED looks stale rather than outstanding.

Timeline:

when	what
2026-08-07 17:50	Copilot flags the unary not gap
2026-08-07 17:54	CHANGES_REQUESTED — "Address Copilot feedback"
2026-08-15 11:52	c994960 fixes it, thread replied to and resolved
2026-08-17 13:22	Copilot re-reviews the fixed head and files nothing

So the review that requested changes predates the fix by 8 days, and Copilot's own re-review afterwards came back clean. Current state: 0 unresolved threads, no suppressed low-confidence comments, MERGEABLE.

For completeness on the substance — the gap was that the ambiguity scan matched infix tokens, so a leading unary not slipped through:

not inputs.value | default(1)

still bound the filter to the boolean rather than being rejected. Fixed by matching the prefix form the parser itself uses (expr.startswith("not ")) rather than scanning for an infix token.

No action needed from me that I can see, but happy to rebase or address anything else if you'd rather I did.

[mnriem]

Thank you!