Template properties extraction

[jhorst11]

What does this PR do?

Templates can have custom template properties (agentforce agent id, etc) in addition to the standard mobilesdk properties (loginHost, connectedAppId, etc)

Upon selecting a template, the custom template properties are extracted and the graph goes through a custom template extraction process to ensure all necessary template properties are extracted prior to using the template.

This also moves the describe of the template into the node itself and presents the available templates to the LLM (rather than instruct the LLM to execute the describe command on its own)

[codecov-commenter]

Codecov Report

❌ Patch coverage is 42.30769% with 300 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.91%. Comparing base (ad97235) to head (8e04c8b).

Files with missing lines	Patch %	Lines
...mcp-server/src/workflow/nodes/templateSelection.ts	10.18%	97 Missing ⚠️
...p-server/src/workflow/nodes/templateDetailFetch.ts	20.58%	54 Missing ⚠️
...-server/src/workflow/nodes/templateOptionsFetch.ts	25.00%	39 Missing ⚠️
...src/workflow/nodes/templatePropertiesExtraction.ts	17.77%	37 Missing ⚠️
...ls/plan/sfmobile-native-template-selection/tool.ts	34.37%	21 Missing ⚠️
...ow/nodes/checkTemplatePropertiesFulfilledRouter.ts	32.25%	21 Missing ⚠️
.../src/workflow/nodes/templatePropertiesUserInput.ts	25.00%	21 Missing ⚠️
...ls/plan/sfmobile-native-project-generation/tool.ts	37.50%	5 Missing ⚠️
...r/src/workflow/nodes/templateCandidateSelection.ts	89.36%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #110      +/-   ##
==========================================
- Coverage   91.85%   87.91%   -3.95%     
==========================================
  Files         162      170       +8     
  Lines        6604     7056     +452     
  Branches      957      972      +15     
==========================================
+ Hits         6066     6203     +137     
- Misses        538      853     +315     

Flag	Coverage Δ
evaluation	80.14% <ø> (ø)
monorepo	87.91% <42.30%> (-3.95%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jhorst11]

I think @haifeng-li-at-salesforce has a PR that puts this behind a node tool (which is great!) but we'll need to reconcile with these changes

[jhorst11]

in a separate PR I want to address the similarities (and differences) between templateProperties and other app properties (i.e. connectedAppCallback, loginHost, etc) - I think ALL properties should be gathered in a similar fashion. Right now the system is very biased towards this being a mobilesdk app but in reality alot of B2C mobile sdk apps won't need loginHost, connectedAppClientId, etc and it should be the template metadata which describes if these properties should be collected at all

[haifeng-li-at-salesforce]

To expand on the comment, MobileNativeWorkflowState can be split into two sections: One for MSDK-essential state and another for app-specific state.

[jhorst11]

yeah I think we're going to have to think holistically about state as the workflow grows - we have a lot of state which is transient and just a means to carry data from one node to the next and then we're done with it so we should have a strategy where we clear state when we are done with that part of the workflow - @khawkins we've discussed this briefly, might be worth a targeted convo as we're going to continually hit it with our various workflows as they grow

[ben-zhang-at-salesforce]

Here we generate the shell command to run. Do we need to worry the command line to be valid in case value has special character for shell, like " here for the value?

[jhorst11]

@haifeng-li-at-salesforce is doing work to move this work into a node I wonder if that's a more appropriate place to do deterministic validation since we'll also have access to the shell result - what do you think @haifeng-li-at-salesforce ? seems like doing that work within the tool itself is not appropriate - can you add it to your pr when resolving to do some basic validation on the input?

[haifeng-li-at-salesforce]

Great job! There are a few comments from @ben-zhang-at-salesforce. Once those conversations are resolved, we can merge it.

[ben-zhang-at-salesforce]

good job!