fix: resolve direct path expressions on Any-typed variable as Any

[barinali]

Related to #87

Proposed Changes

This pull request aims to mark unresolved FEEL path expression variables as any preserving their FEEL expression as info.

Checklist

Ensure you provide everything we need to review your contribution:

• Contribution meets our definition of done
• Pull request establishes context
  • Link to related issue(s), i.e. Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}
  • Brief textual description of the changes
  • Screenshots or short videos showing UI/UX changes
  • Steps to try out, i.e. using the @bpmn-io/sr tool

[Copilot]

Pull request overview

This PR adjusts Zeebe FEEL variable resolution so that unresolved path expressions (e.g. =agent.context) do not get typed as Null when their root variable is effectively unknown (Any), preserving the original FEEL expression in info for UI display.

Changes:

• Extend resolveReferences to convert certain null evaluation results into Any (atomicValue undefined) when the referenced root variable is Any-typed.
• Preserve the original FEEL expression as info for these “unknown” results (aligning with #87 expectations).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[barmac]

@copilot Provide a test case that proves the suggestion

[nikku]

Makes sense.

We could add an additional test to verify nested behavior =agent.foo.bar with agent.foo being defined vs. agent being defined vs. agent not being defined - I am not sure how the current roots detection will handle such scenarios.

Research question: If agent = { bar: 10 } exists, what is the value of agentFooBar = agent.foo.bar?

We can also leave that for another day. Overall, good stuff. Good to start from solid test coverage ⭐

[Copilot]

@barmac I've opened a new pull request, #99, to work on those changes. Once the pull request is ready, I'll request review from you.

[barinali]

Makes sense.

We could add an additional test to verify nested behavior =agent.foo.bar with agent.foo being defined vs. agent being defined vs. agent not being defined - I am not sure how the current roots detection will handle such scenarios.

Research question: If agent = { bar: 10 } exists, what is the value of agentFooBar = agent.foo.bar?

We can also leave that for another day. Overall, good stuff. Good to start from solid test coverage ⭐

expression	provided	actual	expected
=agent.foo.bar	agent={ bar: 10 }	null <Null>	=agent.foo.bar <Any> ❌
=agent.foo.bar	agent={ foo: {} }	null <Null>	=agent.foo.bar <Any> ❌
=agent.context	agent=agent	=agent.context	=agent.context <Any> ✅

The current root detection implementation is only providing top-level variables, not property accesses. So, when agent.foo.bar is in question, we only have agent as unresolvedRoot and cannot distinguish absence of unresolved intermediate properties (absence of agent.foo for agent.foo.bar).

I think this pull request introduces a pragmatical iteration for variables like the third sample in the table above without introducing an irrecoverable complexity. So I plan to go ahead with this pull request (as it's a partial improvement) and create an issue to follow up on the other scenarios especially after #74 lands.

[barinali]

@nikku created #100 🎉 as a follow-up item.