Add tests for Jinja expression reference validation

[zhongkaifu]

Motivation

• Add automated coverage for validation of Jinja expressions embedded in workflow params to prevent regressions.
• Ensure template references inside params are checked against action output schemas instead of treating whole Jinja strings as opaque.
• Verify that missing fields referenced inside Jinja expressions produce SCHEMA_MISMATCH errors.
• Provide a positive test asserting valid referenced fields do not produce validation errors.

Description

• Added tests/test_jinja_template_reference_validation.py which constructs small workflows exercising Jinja expressions in action params.
• Includes two tests: one asserting a missing field inside a Jinja expression yields a SCHEMA_MISMATCH on the target param, and one asserting a valid field passes with no errors.
• Tests call validate_completed_workflow and use BUSINESS_ACTIONS fixtures to validate against real action schemas.
• The tests exercise the Jinja reference extraction and schema-checking codepaths implemented in velvetflow/jinja_utils.py and velvetflow/verification/node_rules.py.

Testing

• Ran pytest -q tests/test_jinja_template_reference_validation.py and both tests passed.
• The test run produced 2 passed in 0.17s.
• No other automated test suites were run as part of this change.
• The new test file was added and committed.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 70b0d5baf7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve bracket string keys when extracting paths

This conversion treats any string index (e.g. foo['a.b'] or foo['0']) as dotted access, which loses the original bracket semantics. When a schema has property names with dots or numeric strings, extract_jinja_reference_paths will emit foo.a.b or foo.0, and parse_field_path will split or coerce those into nested fields/array indices. That can raise SCHEMA_MISMATCH for templates that are actually valid in Jinja. This regression shows up only when bracket string keys are used in expressions, but in that case the new validation will flag false errors.

Useful? React with 👍 / 👎.