Skip With-template resolution and WithSchema validation for condition-skipped steps during plan building

[blindzero]

Problem Statement

During plan building, a workflow step can already be determined as not applicable because its Condition evaluates to false against the current request and context.

However, the current planning flow still continues with later plan-time processing for that same step, including With template resolution and WithSchema validation. This can produce false-positive planning failures for steps that would never be executed.

Typical examples are steps guarded by a condition such as checking whether a required identity attribute exists. If the attribute is missing, the condition correctly makes the step not applicable. But plan-time With processing may still fail afterwards because the same missing data is referenced in With, even though the step should already have been skipped.

This is especially relevant now that WithSchema validation is enforced more strictly during planning.

Proposed Solution

Adjust the plan-building flow so that once a step is determined to be NotApplicable due to its Condition, all later plan-time processing that assumes the step is still eligible is skipped for that step.

Expected behavior:

• Evaluate Condition before any plan-time With validation that depends on the step being applicable.
• If the condition evaluates to false:
  • mark the step as NotApplicable
  • retain the condition evaluation result in the plan output as today
  • skip subsequent With template substitution for that step
  • skip WithSchema validation for that step
  • skip any further plan-time checks that only make sense for executable steps
• Ensure this behavior is consistent for all steps, regardless of provider or step type.
• Cover the behavior with focused unit tests.
• Document the planning behavior clearly so users understand that conditions can guard steps from downstream plan-time validation.

Alternatives Considered

Alternative A: Keep current behavior and require all condition-guarded steps to still pass full plan-time validation

This was rejected because it creates false-positive failures for steps that are intentionally skipped by design. It also makes conditions less useful as guardrails.

Alternative B: Add a special opt-out switch for specific validations

This was rejected because it pushes engine behavior complexity into workflow authoring and makes the planning model harder to understand.

Alternative C: Evaluate conditions only after all With validation

This was rejected because it defeats the purpose of using conditions as an early applicability guard.

Impact

• Does this affect existing workflows?

  • Yes, but in a positive way. Workflows that currently fail planning for steps that are already condition-skipped would start planning successfully.
  • Workflows with applicable steps should continue to fail fast exactly as today when With data is invalid.

• Any backward compatibility concerns?

  • This changes plan-time behavior and could therefore be considered behaviorally breaking for anyone relying on current false-positive failures.
  • The new behavior is still the more correct and deterministic model because non-applicable steps should not block plan creation.

Additional Context

Suggested acceptance criteria:

1. A step whose condition evaluates to false is represented in the plan as NotApplicable.
2. With template resolution is not executed for that step after the condition result is known.
3. WithSchema validation is not executed for that step after the condition result is known.
4. Applicable steps still undergo full template resolution and schema validation.
5. Unit tests cover both branches:
   • condition false => no false-positive validation failure
   • condition true => current strict validation behavior remains
6. User-facing documentation explains the interaction between conditions and planning.

Suggested examples to cover in tests/docs:

• Guarding a step with an existence check for IdentityKey
• Guarding a step whose With block references optional context data
• Confirming that skipped steps do not fail planning when the referenced data is absent