@@ -630,8 +630,8 @@ later node reads `{subject}`, not `{screen_1.subject}`.
 }
 ```
 
-`visibleWhen` is **bare CEL over the screen's own field names** — not the `{var}`
-template dialect the rest of a node's `config` uses. The client re-evaluates it
+`visibleWhen` is **bare CEL over the screen's own field names** — never a
+`{{ }}` template like the screen's `title` / `description`. The client re-evaluates it
 as the user types, against the values collected so far, which is why it cannot
 be a server-interpolated template. Omit it for a field that is always visible.
 
@@ -650,7 +650,7 @@ Two things worth knowing:
   the name is never bound and a downstream condition reading it aborts the run.
 - **A broken predicate fails open** (the field stays visible) rather than hiding
   an input the flow may be waiting on. `registerFlow()` does check the predicate
-  as bare CEL — a `{var}` template or a syntax error is a loud registration
+  as bare CEL — a `{…}` brace or a syntax error is a loud registration
   failure that quotes the source and locates it as
   `config.fields[N].visibleWhen` — but a predicate that *parses* and simply
   names the wrong field still shows up as a field that never hides.
@@ -2202,19 +2202,14 @@ a field access on an object variable is not one. Both reported `success`. They
 are bare CEL now, so the spellings in the table above are the correct ones and
 `lead_record.status == 'converted'` resolves the field.
 
-The `{var}` form still works where a condition is a plain authored string — a
-start node's `config.condition`: `{amount} > 100`, `{status} == 'active'`. The
-two ways it used to answer `false` without saying so are now **loud errors**
-naming the reference: a `{…}` hole that matches no flow variable, and a
-substituted value that is neither a boolean, a number, nor part of a comparison
-(#4336).
-
-**A decision's `conditions[].expression` is the exception — it is always CEL.**
-The slot is declared bare CEL and is on the expression ledger as a predicate
-(#4439), so a braced spelling there is not the `{var}` dialect but a build
-failure: `os build` and `registerFlow` reject it, naming
-`config.conditions[N].expression`. That is deliberate — the alternative is a
-build that refuses what run time would happily execute.
+**There is no `{var}` form of a condition.** Every condition is bare CEL — a
+start node's `config.condition`, an edge's `condition`, a decision's
+`conditions[].expression`, a screen field's `visibleWhen` — so a braced
+spelling (`{amount} > 100`) is a build failure: `os build` and `registerFlow`
+reject it, naming the slot (`config.conditions[N].expression`, …). Write
+`amount > 100`, `status == 'active'`. The template path the evaluator kept for a
+braced string is deleted (#19939), so a direct `evaluateCondition` call refuses
+the same spelling as a CEL fault, and a `template` or `flow` envelope with it.
 </Callout>
 
 CEL conditions that fail to evaluate raise an error and stop the run — they