From 0681d1e6eedd68fe4a78703ec6accab50392bdca Mon Sep 17 00:00:00 2001 From: Bryan Helmkamp Date: Tue, 28 Jul 2026 14:52:02 -0400 Subject: [PATCH] docs: clarify run-create undefined variable handling --- .../fabro-workflow/src/transforms/variable_expansion.rs | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/lib/components/fabro-workflow/src/transforms/variable_expansion.rs b/lib/components/fabro-workflow/src/transforms/variable_expansion.rs index 311c47189..e739c21a4 100644 --- a/lib/components/fabro-workflow/src/transforms/variable_expansion.rs +++ b/lib/components/fabro-workflow/src/transforms/variable_expansion.rs @@ -19,11 +19,10 @@ use crate::static_reference::{ /// How the template-expansion pass should treat undefined input variables. /// -/// Neither validate nor run-create should fail just because the user has not -/// bound `{{ inputs.* }}` yet, so both render structurally. Run-create then -/// promotes the resulting warnings to errors itself, which keeps its hard-fail -/// behavior while still reporting every undefined variable in one pass rather -/// than aborting on the first. +/// Both validate and run-create render structurally so they can report every +/// unbound `{{ inputs.* }}` variable in one pass rather than aborting on the +/// first. Run-create then promotes the resulting warnings to errors, which +/// keeps its hard-fail behavior. #[derive(Clone, Copy, Debug)] pub enum RenderMode { /// Undefined inputs abort the pass with a hard error. No production caller