added test for init and trigger functions and resolve errors

[devanshi00]

Summary

• Fixes Errors while executing request using TemplateLogicExecutor #516
• Added explicit accordproject.stateful: true metadata to the affected templates so the runtime and tests can distinguish stateful contracts from stateless ones.
• Expanded test/render.test.mjs to:
  • skip archived templates entirely,
  • precompute template metadata once,
  • add dedicated init coverage for stateful templates,
  • add trigger coverage for both stateful and stateless execution paths.
• Updated sample request payloads for stateful templates such as payment-upon-iot and payment-upon-signature so they start from the correct ContractSigned flow and use the right model version.
• Hardened several logic files by replacing generated runtime value imports with import type usage and local enum/interface constants where needed, reducing runtime/type-generation issues during execution.

Impact

• Improves stateful template support across metadata, sample requests, and test coverage.
• Makes the render test suite better aligned with the current template lifecycle expectations.
• Reduces failures caused by missing generated runtime symbols in template logic.

Author Checklist

• Ensure you provide a DCO sign-off for your commits using the --signoff option of git commit.
• Vital features and changes captured in unit and/or integration tests
• Commits messages follow AP format
• Extend the documentation, if necessary
• Merging to master from fork:branchname

@DianaLease @dselman @mttrbrts

[mttrbrts]

Can we do the same as the money namespace here?

[devanshi00]

Yes, we can align this more closely with the money-namespace approach, but only for type usage. These templates already vendor org.accordproject.time@0.3.0 locally; the reason some logic files still inline TemporalUnit/IDuration is that runtime imports from ./generated/... can break render execution. The safe cleanup is to switch to import type { IDuration } and keep runtime unit checks as string literals/local constants.

[mttrbrts]

Is there a more idiomatic way to do this?

[devanshi00]

You can see the implementation now.

[mttrbrts]

@devanshi00 can you see a way to statically determine from the logic if a template is stateful?

This solution is good as a first step, but it would be more robust if the library could tell you the statefulness

[devanshi00]

@devanshi00 can you see a way to statically determine from the logic if a template is stateful?

This solution is good as a first step, but it would be more robust if the library could tell you the statefulness

@devanshi00 can you see a way to statically determine from the logic if a template is stateful?

This solution is good as a first step, but it would be more robust if the library could tell you the statefulness

https://github.com/accordproject/template-archive/blob/7acd408eb46881072e55b082d3676fd85a922a94/packages/cicero-core/src/template.ts#L495
SO we could use this method but as discussed with @dselman and @DianaLease we will have to extend the state and obligation for the respective templates for this method to work and even the LLM executor to work.
If you want I can modify it in this pr or open another pr for it.
You can see the discussion and linked issue also here
accordproject/template-archive#937

Let me know how you want me to approach it.

[mttrbrts]

Thanks for sharing those links, I'm glad to see that we're all thinking along the same lines.

I would have expected this to throw at build time

concept HelloWorldState identified {
  o Double counter
}

Instead I expected the definitions to look like:

concept HelloWorldState extends State {
  o Double counter
}

If the existing isStateful API in template-archive will detect the latter, let's switch to that here (given that we're already editing the templates).

I'll start a separate thread to investigate why this isn't caught on template compilation. Thanks!

[mttrbrts]

@devanshi00, it looks like this change will fix the issue and force us to patch the templates.
accordproject/template-engine#164