fix(workflows): stop offering a condition correction that inverts it

[ntdatt812]

Follow-up to #4182. That PR merged while this last fix was in flight — by about a minute — so the defect below is still live on main.

Problem

format_condition_correction wraps whatever it is handed. That is right for a formatter, but the three step validators advertise its output as a paste-ready correction, and for two inputs it cannot repair the suggestion is actively harmful.

I measured what pasting each suggestion does rather than reasoning about it:

condition	validator reports	correction it suggests	pasting that gives
" "	always true	"{{ }}"	False
{{ inputs.name == 'abc	always true	"{{ inputs.name == 'abc }}"	False

Both invert the condition rather than repair it:

• the blank core interpolates to the empty string;
• the open quote survives wrapping, so the raw-close fallback evaluates a truncated comparison whose result is the string "False", which evaluate_condition reads as the false keyword before bool() is ever reached.

So an author who follows the advice trades an always-true condition for an always-false one, having been told it was the fix.

Change

format_condition_remediation builds the advice, and the three validators call it instead of assembling the sentence themselves. It offers a correction only when wrapping would genuinely repair the input, and otherwise names the fault — the same call already made for condition_has_malformed_expression_block, which deliberately offers no suggestion.

'   '                    -> ... There is no expression here to wrap: use the literal
                             true or false, since an empty '{{ }}' block evaluates to
                             the empty string and would silently invert the condition.

{{ inputs.name == 'abc   -> ... Close the unbalanced quote first: wrapping it as
                             written leaves the quote open, so the raw-close fallback
                             evaluates a truncated comparison rather than the one
                             written, and its result can silently invert the condition.

inputs.count > 100       -> ... Wrap the expression: "{{ inputs.count > 100 }}".

_has_unbalanced_quote uses the same left-to-right scan as _find_block_close and _strip_stray_delimiters, so "inside a string" means one thing throughout the module.

Note on one of my own claims

My first draft of the unbalanced-quote message said the wrapped form "stays always true". The new test failed and showed it returns False — evaluate_condition recognises the residual "False" as the keyword before coercion. The message and docstring say inverted, which is what the measurement shows. Flagging it because the distinction is the whole point of the change.

Verification — Python 3.11, on this branch off main

tests/unit + tests/test_workflows.py   1233 passed  (main: 1216)

The 22 failures in that run are identical with and without this commit — all TestWorkflowCliAlignment symlink tests, which need elevation on Windows. I ran the suite against unmodified main to confirm that rather than assume it.

Mutation-checked: removing either gate fails exactly the 9 new parametrised cases and nothing else, so the fixtures pin this defect rather than passing incidentally.

Credit to the Copilot reviewer on #4182 — it raised this as a suppressed comment there and was right.

[Copilot]

Pull request overview

Centralizes condition-remediation advice to avoid suggesting known condition inversions.

Changes:

• Adds guarded remediation for blank and unbalanced-quote conditions.
• Updates all conditional step validators.
• Adds regression tests for unsafe corrections.

Show a summary per file

File	Description
src/specify_cli/workflows/expressions.py	Adds remediation logic and quote scanning.
src/specify_cli/workflows/steps/if_then/__init__.py	Uses centralized remediation.
src/specify_cli/workflows/steps/while_loop/__init__.py	Uses centralized remediation.
src/specify_cli/workflows/steps/do_while/__init__.py	Uses centralized remediation.
tests/unit/test_condition_expression_block.py	Covers correction inversions and quote detection.

Review details

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Suppressed comments (2)

src/specify_cli/workflows/expressions.py:930

• The quote-balance check is not enough to establish that wrapping repairs the condition. For example, inputs.name == has a nonempty, quote-balanced core, so this still advertises "{{ inputs.name == }}"; the original is truthy text, but the suggested form resolves the missing RHS to None and evaluates the comparison as False. The paste-ready correction therefore still silently inverts malformed inputs. Validate the core for incomplete operators/brackets before offering a correction, or withhold the correction when its syntax cannot be established.

    if _has_unbalanced_quote(core):

src/specify_cli/workflows/expressions.py:935

• The wrapped form does not use the raw-close fallback: because it starts and ends with {{ }}, _is_single_expression routes it through the typed fast path despite the open quote. The message gives users an incorrect diagnosis; it should state that wrapping leaves a malformed expression whose result can invert the condition.

            "Close the unbalanced quote first: wrapping it as written leaves the "
            "quote open, so the raw-close fallback evaluates a truncated comparison "
            "rather than the one written, and its result can silently invert the "
            "condition instead of repairing it."

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

[mnriem]

Please address Copilot feedback. Thanks for all the great work!

[ntdatt812]

Both suppressed findings were correct. Fixed in 6944920.

1. The quote-balance gate was not sufficient. inputs.name == has a non-empty, quote-balanced core, so a correction was still advertised:

inputs.name ==   ->   "{{ inputs.name == }}"      True -> False

Same harm as the two cases this PR already covered — the author is told the condition is always true and hands back an always-false one.

2. The message named the wrong mechanism. I said the wrapped form goes through the raw-close fallback. Measured:

_is_single_expression("{{ inputs.name == 'abc }}")  ->  True

So it takes the typed fast path instead. The diagnosis was wrong even though the conclusion — that the result can invert the condition — was right.

What changed

Enumerating broken shapes was the mistake; it is why this needed three rounds. _wrapping_would_not_repair now reports the first reason wrapping cannot yield the intended expression — empty core, unclosed quote, unbalanced bracket, or an operator missing an operand — and the advice names that instead of offering a suggestion.

_has_incomplete_operand reads _COMPARISON_OPERATORS, extracted from _evaluate_simple_expression, so the check cannot drift from what the evaluator actually splits on.

The messages now describe the text itself rather than the interpolator path it will take. Asserting an internal route is exactly what made my previous two versions wrong, twice, so they no longer do it.

The test that matters

test_every_offered_correction_is_a_complete_expression states the property rather than the shapes: whatever is advertised as paste-ready must survive both validators. A new malformed shape is caught by the invariant now, not by adding another fixture row.

Verification — Python 3.11

tests/unit/test_condition_expression_block.py      182 passed  (was 133)
tests/unit + tests/test_workflows.py              1282 passed  (was 1233)

22 failures identical before and after — the TestWorkflowCliAlignment symlink tests that need elevation on Windows, confirmed by running against the stashed tree.

One mutation initially escaped, and that is worth reporting

Removing "<" from _COMPARISON_OPERATORS left all tests green. The operator test parametrised over the constant it was checking, so shrinking the constant shrank the test — the same can't-fail-when-it-matters shape this whole PR exists to reject, in my own test. It is hard-coded now and that mutation fails.

Final mutation results, each gate against its own cases: operand gate → 12 failures, bracket gate → 3, dropped operator → 1.

[Copilot]

Review details

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

[mnriem]

Please address Copilot feedback

[ntdatt812]

@mnriem — done, in 24c71a6. Both live Copilot findings were correct.

1. _has_incomplete_operand inspected only the first occurrence of each operator, and its end-of-string check covered only trailing boolean keywords:

inputs.a == inputs.b ==   ->  correction offered   True -> False
and inputs.ready          ->  correction offered   True -> False

Worth naming plainly: that is the same defect this PR's parent commit fixed one level up — stopping at the first match — reintroduced inside the gate written to prevent it. It now splits on every top-level occurrence and requires every operand to be non-empty.

A stripped core also loses the space that delimits a word operator, so inputs.a not in matched nothing at all. _WORD_OPERATORS is derived from _COMPARISON_OPERATORS and matched against both ends without that space.

2. _has_unbalanced_bracket counted depth, so mismatched types cancelled out:

inputs.f(]   ->  correction offered   True -> False

It now tracks opener types on a stack and rejects a non-matching closer.

On the third thread

The docstring one is marked outdated and refers to the text before 6944920. The line it points at now reads:

Each branch names something observable about the text itself, deliberately not the interpolator path it will take: two earlier versions of this message asserted an internal route — the raw-close fallback — and were wrong, because _is_single_expression accepts the wrapped form and sends it down the typed fast path instead.

So it does not attribute the inversion to the raw-close fallback; it records that earlier versions did and states the actual path, which matches what the reviewer described. I left it as the explanation for why the messages avoid naming internal routes. Happy to reword if you would rather it not mention the fallback at all.

Verification — Python 3.11

tests/unit/test_condition_expression_block.py      207 passed  (was 182)
tests/unit + tests/test_workflows.py              1307 passed  (was 1282)

22 failures identical before and after — the TestWorkflowCliAlignment symlink tests needing elevation on Windows, confirmed against the stashed tree.

Mutation-checked: depth-only brackets → 9 failures, first-occurrence-only → 3, dropping the end-of-core word scan → 16.

[Copilot]

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/specify_cli/workflows/expressions.py:1017

• reason is None does not establish that wrapping repairs the condition; it only excludes four structural shapes. For example, inputs.items | length passes these gates and is advertised as paste-ready, but the evaluator raises ValueError("unknown filter 'length'") for the wrapped form. The existing he said "hi"\nthen left fixture is also classified as correctable even though wrapping makes it resolve to None, changing the original truthy string to false. Please validate the core against the evaluator's actual expression grammar/registered filters (or conservatively withhold a correction when that cannot be established) before returning Wrap the expression.

    reason = _wrapping_would_not_repair(core)
    if reason is None:
        return "Wrap the expression: " + format_condition_correction(condition) + "."

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

[ntdatt812]

That was the strongest point raised on this PR, and it was right. Addressed in 6c8ca2c.

reason is None only excluded four structural shapes, and structural shapes cannot establish that wrapping yields a working expression. Both examples reproduce:

inputs.items | length     ->  offered;  wrapped form raises
                              ValueError("unknown filter 'length'")
he said "hi"\nthen left   ->  offered;  wrapped form resolves to None,  True -> False

The first replaces an always-true condition with a crash; the second inverts it.

Two checks, both reading the evaluator rather than guessing

• _unregistered_filter walks the top-level | segments and reports the first name missing from _REGISTERED_FILTERS — the same tuple _apply_filter raises on, so the validator cannot bless a filter the evaluator will reject.
• _reads_as_prose reports a core that is several bare terms with nothing joining them. Quoted spans and bracketed groups are skipped, so inputs.f('a b') and inputs.name == 'two words' are unaffected, and a not prefix is allowed.

The fixture was mine, and it was wrong in two ways

he said "hi"\nthen left was only in the offered-correction set because I built that fixture as TRICKY_CONDITIONS + [...]. TRICKY_CONDITIONS exists to exercise the formatter's quoting and deliberately contains prose — reusing it asserted something it was never meant to claim. The list is explicit now, with the tricky-quoting entries that really are expressions carried over by hand, so adding prose to that fixture can no longer widen this invariant.

inputs.tags | length > 0 was also mine, and length is not a registered filter. It is join(',') now. My own fixture was asserting a correction the evaluator would have crashed on.

Verification — Python 3.11

tests/unit/test_condition_expression_block.py      212 passed  (was 207)
tests/unit + tests/test_workflows.py              1312 passed  (was 1307)

22 failures identical before and after — the TestWorkflowCliAlignment symlink tests needing elevation on Windows, confirmed against the stashed tree.

Mutation-checked: dropping either new gate fails 3 cases and nothing else.

One thing worth your call, @mnriem

This is the fourth round in which the suggested correction — not the validation itself — was wrong in a new way. The rejection of never-evaluated conditions has been solid since #4182; it is the paste-ready suggestion that keeps needing another gate.

I think the gates are now in the right place, because the last two read the evaluator's own tables rather than restating structure. But if you would rather not carry that surface at all, dropping the suggestion and keeping only the diagnosis would delete four helpers and remove this whole class of defect permanently. Happy to cut it down if that is the call — it is your maintenance burden, not mine.

[Copilot]

Review details

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

[ntdatt812]

Thanks for the approval @mnriem — one more push after it, because the Copilot comment that arrived two minutes later was correct and I would rather not leave it. a61ff6c.

Two more shapes got through:

inputs.tags | join   ->  offered;  `join` is registered, but with no argument
                         _apply_filter raises ValueError
inputs.count+1       ->  offered;  the evaluator has no arithmetic, reads it as a
                         key named "count+1", wrapped form resolves to None,
                         True -> False

That is the fifth shape in four rounds, which is the argument against enumerating shapes. So this commit stops:

• _evaluator_rejects runs the core through _evaluate_simple_expression against a probe namespace and returns the evaluator's own error. Any filter under an unknown name or in an unsupported form is now reported by the code that will actually run. _unregistered_filter, which restated the filter table, is deleted.
• _is_not_a_bare_path covers the part a probe cannot: a single-term core is resolved as a path lookup, so every dotted segment must be an identifier. count+1 is not, and neither is prose — so _reads_as_prose is deleted too.

The probe namespace resolves roots but not leaves on purpose. I tried the permissive version first, and a namespace that answers every lookup also answers inputs.count+1 — it hides the exact shape the probe exists to expose.

Net: two helpers fewer, and no restatement of the evaluator's tables anywhere in the gate.

Verification — Python 3.11

tests/unit/test_condition_expression_block.py      230 passed  (was 212)
tests/unit + tests/test_workflows.py              1330 passed  (was 1312)

22 failures identical before and after — the TestWorkflowCliAlignment symlink tests needing elevation on Windows, confirmed against the stashed tree.

Mutation-checked: dropping either check fails 6 cases and nothing else.

Since this landed after your approval, please re-approve or tell me to revert to 6c8ca2c — I did not want to sit on a reproducible defect, but I also do not want to slip a change past a review you had already given.

[Copilot]

Review details

Suppressed comments (1)

src/specify_cli/workflows/expressions.py:1046

• Add the second blank line before this top-level function; otherwise the repository's Ruff CI check reports E305.

def _wrapping_would_not_repair(core: str) -> str | None:

• Files reviewed: 5/5 changed files
• Comments generated: 3
• Review effort level: Balanced

[mnriem]

Please address Copilot feedback

[mnriem]

Lets get this one through the review and then if you can describe what specifically would make it easier / cleaner / faster then lets address that by describing it in an issue so we can asses it? Hope that is OK? Thanks!

[Copilot]

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 3
• Review effort level: Balanced

[mnriem]

Please address Copilot feedback

[ntdatt812]

@mnriem — two of the three are fixed in 967fa66. The third I could not fix without doing the thing this PR has spent seven rounds backing away from, so I want to put a direct question to you rather than keep going.

Fixed: my checks approximated the evaluator instead of matching it

1e3        ->  offered;  no "." so the evaluator calls int(), which fails, and it
                         falls through to a path lookup. float() alone accepted it.
'a' 'b'    ->  offered;  the evaluator requires the opening quote's match to be the
                         final character; first/last-character equality is not that.
inputs[0]  ->  offered;  _build_namespace hands back mappings, so an indexed root
                         resolves to None however the index is written.

All three are truthy before wrapping and False after. _looks_numeric and _is_literal now use the evaluator's own tests verbatim, and the root segment is matched without stripping an index off it first.

Not fixed: inputs.tags | join(5)

join always raises for a non-string separator, so this is a real hole. But it is a type rule, and _evaluator_rejects deliberately ignores value errors because under a probe they usually describe the placeholder rather than the author's text — that is the fix from two rounds ago, which stopped steps.emit.output.stdout | from_json being wrongly rejected.

The two cannot be separated from the message:

join: expected a string separator, got int        <- the author's literal
join: expected a string separator, got NoneType   <- my probe's placeholder

They differ only in a type name the probe may have supplied. I tried keying on whether the filter segments reference a namespace root, but that misclassifies steps.emit.output.stdout | from_json, where the probe-caused error is about the filter input rather than its argument. Catching join(5) means encoding each filter's argument types in the validator.

The question

Eight rounds now, every one of them about the suggested correction. The validation itself has been correct since #4182 merged; what keeps breaking is the paste-ready string offered alongside it, because getting it right means reimplementing the evaluator's grammar and now its type rules inside a validator.

So, plainly — which do you want?

1. Keep the suggestion. I encode the filter argument types next, and we accept that this surface tracks the evaluator by hand and will drift again.
2. Drop the suggestion. The error keeps naming the fault and stops handing back a string to paste. That deletes five helpers and the whole class of defect, permanently. format_condition_correction stays exported and tested for anyone who wants it.

I have offered (2) three times without wanting to remove a shipped behaviour unilaterally, so I would rather you decide. Either way I will do it in one pass.

Verification — Python 3.11

tests/unit/test_condition_expression_block.py      267 passed  (was 253)
tests/unit + tests/test_workflows.py              1367 passed  (was 1353)
ruff check src/specify_cli/workflows/expressions.py   5 errors — the ones already on main

22 failures identical before and after — the TestWorkflowCliAlignment symlink tests needing elevation on Windows.

Mutation-checked: restoring the bare float() fails 2 cases; restoring the first/last-character quote test fails 3.

[Copilot]

Review details

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

src/specify_cli/workflows/expressions.py:1100

• This leaf check omits the evaluator's supported list-literal grammar (expressions.py:582-595, covered by tests/test_workflows.py:392-419). Consequently a valid bare condition such as inputs.tag in ['x', 'y'] is classified as an unresolvable name and denied the correction even though wrapping it is a complete, evaluable expression. Recurse through list elements just as the evaluator does.

    if _is_literal(stripped):
        return None

    segments = _split_top_level(stripped, ".")
    if not _PATH_SEGMENT.match(segments[0].strip()):

src/specify_cli/workflows/expressions.py:1080

• Filter arguments are skipped here, so malformed inputs can still receive a paste-ready correction. For example, inputs.tags | join(bogus) passes this check; the probe then ignores join's NoneType argument error, but the suggested wrapped condition always raises because bogus is not a namespace root. Inspect each parsed filter argument with the same operand validation before offering a correction.

    if _find_top_level(stripped, "|") != -1:
        segments = _split_top_level(stripped, "|")
        return _unresolvable_term(segments[0])

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

[ntdatt812]

@mnriem Understood on both counts — through review first, and the broader design point as a separate issue. I will write that one up once this lands.

Both suppressed Copilot findings are addressed in a5970cf. I checked each against the evaluator before changing anything, because they point in opposite directions and one of them was described at the wrong entry point.

List literals — the correction was withheld from a valid condition.

_unresolvable_term resolved ['x', 'y'] as a path, so:

inputs.tag in ['x', 'y']
  -> No correction is offered because "['x', 'y']" is not a name the evaluator can resolve
  but {{ inputs.tag in ['x', 'y'] }} evaluates to True

_evaluate_simple_expression treats [...] as a term and recurses into the elements, so the leaf check now does the same, including the empty-segment skip that makes [1, 2,] be [1, 2] rather than [1, 2, None].

The finding named format_condition_correction, which always wraps whatever it is handed; the gate is _wrapping_would_not_repair, reached through format_condition_remediation. Same defect, different entry point.

Filter arguments — a correction was offered for something that raises.

inputs.tags | join(bogus)
  -> Wrap the expression: "{{ inputs.tags | join(bogus) }}"
  but that raises ValueError: join: expected a string separator, got NoneType

_apply_filter evaluates the argument with _evaluate_simple_expression like any other operand. The check now parses it with the same (\w+)\((.+)\) pattern _apply_filter uses, and a form that pattern does not match is left to the evaluator probe rather than guessed at here.

One correction to the finding's reasoning, since it affects the fix: not every unresolvable argument raises. default tolerates the None, so inputs.count | default(bogus) evaluates fine and is withheld on the same policy that already withholds bogus == 'x' — which also evaluates fine. I split the tests accordingly rather than asserting a crash that does not happen; my first version of that test asserted it and failed.

Verification

Windows, Python 3.13. Every case is asserted against what the evaluator does with the wrapped form, not against a restatement of the check, so a check that drifts from the evaluator fails the test rather than agreeing with itself.

tests/unit/test_condition_expression_block.py          280 passed
tests/test_extensions.py + test_workflows.py
  + test_condition_expression_block.py                 1718 passed, 22 failed

Those 22 are pre-existing and platform-bound. Measured on both sides — reverting this PR's two files to their parent revision gives the identical 22 failures, diff clean, with 1705 passed against 1718 here. The +13 is exactly the cases added. They are the same symlink and bash-parity classes that account for all 168 failures in the full local run (7005 passed): unelevated Windows cannot create symlinks, and the *_python_parity files shell out to the bash scripts.

Mutation-checked, after confirming each edit actually applied:

skip every filter argument      -> 3 failed  (join(bogus), map(bogus), default(bogus))
list literals fall through      -> 5 failed  (all five list-literal cases)

Nothing else moves in either case, so the new cases pin these two behaviours rather than passing incidentally.

[Copilot]

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/specify_cli/workflows/expressions.py:1146

• Not every root is a mapping: StepContext.item is Any, and fan-out assigns each item value directly, so an item may itself be a list. The evaluator therefore supports item[0], but this root-membership check reports it as unknown and withholds a valid correction such as "{{ item[0] == 'x' }}". Strip the numeric index before checking the root, while retaining the index rejection for the roots that are always mappings.

    # The root itself is never indexed: `_build_namespace` hands back mappings, so
    # `_resolve_dot_path` returns None for `inputs[0]` however the index is written.
    if segments[0].strip() not in _NAMESPACE_ROOTS:

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

[mnriem]

Please address Copilot feedback

[ntdatt812]

Addressed in b0c7704. This one is a correction to something I got wrong earlier in this branch, not just a gap.

Two rounds ago I replaced an index-stripping root check with a plain membership test, on the reasoning that _build_namespace hands back mappings so an indexed root always resolves to None. That is true of four roots and false of the fifth. StepContext.item is Any, and a fan-out assigns the item value itself, so when the item is a list _resolve_dot_path takes its index branch and resolves:

item[0] == 'x'   item = ["x", "y"]   ->  evaluates True    correction offered: False   <- wrong
inputs[0]        always a mapping    ->  evaluates False   correction offered: False   <- right
steps[1]         always a mapping    ->  evaluates False   correction offered: False   <- right
fan_in[0]        always a mapping    ->  evaluates False   correction offered: False   <- right

So the index is stripped for item alone rather than for roots in general, and there is a paired test for the other four so the narrowing cannot later widen into "any indexed root". Both directions are asserted against what the evaluator returns, not against the check.

I should have caught this when I wrote that line — the comment I put above it asserted a property of all five roots that I had only verified for inputs.

Verification

tests/unit/test_condition_expression_block.py           286 passed
tests/test_extensions.py + test_workflows.py
  + test_condition_expression_block.py                  1724 passed, 22 failed

Same 22 as the unpatched tree, diff clean against the baseline I measured for the previous push — the pre-existing symlink and bash-parity classes on unelevated Windows. 1705 -> 1724 passed is exactly the 19 cases added across both pushes.

Mutation-checked, after confirming the edit applied:

never strip the index   ->  2 failed  (item[0], item[1])

The always-mapping cases stay green under that mutation, which is the point — they do not depend on the strip, so they still guard the other side.

[Copilot]

Review details

Suppressed comments (1)

src/specify_cli/workflows/expressions.py:1025

• This suppresses deterministic evaluator failures as well as probe-placeholder failures. For example, format_condition_remediation("inputs.tags | join(5)") offers "{{ inputs.tags | join(5) }}", but the numeric separator makes the wrapped expression always raise ValueError (the evaluator contract is pinned at tests/test_workflows.py:615-624). The same occurs for map(5) and invalid literal from_json inputs, so these are still advertised as paste-ready corrections even though wrapping cannot repair them. Please distinguish errors caused by unresolved probe values from errors caused by literal operands/arguments and withhold the correction for the latter.

    except ValueError as exc:
        message = str(exc)
        # Every error _apply_filter raises about the filter *expression* quotes the
        # segment back as `got '| ...'`. Its value errors instead name the type they
        # received, which under a probe is the placeholder, not anything the author
        # wrote -- treating those as rejections withheld corrections from valid
        # conditions such as `steps.emit.output.stdout | from_json`.
        if "got '| " in message:
            return message.split(":", 1)[0]
    except Exception:  # noqa: BLE001 - probe values, not the author's text

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

[mnriem]

Thank you!