feat(auto-reply): implement flow engine for handling interactive auto…

[mrinal002]

…-replies

• Added FlowEngine class to process incoming messages and manage user interaction flows.
• Introduced FlowConfig and SessionFlow interfaces to define session configurations.
• Implemented state management for user interactions, including timeout handling and state reset on trigger word.
• Created unit tests for FlowEngine to ensure correct behavior across various scenarios, including greeting triggers, option selections, and invalid inputs.

Description

Brief description of changes

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Checklist

• Tests added/updated
• Documentation updated
• Lint passes
• Self-reviewed

Screenshots (if applicable)

Related Issues

Closes #

[rmyndharis]

Thank you for the substantial work here, @mrinal002 — a full flow engine with an interactive config UI is a genuinely useful feature, and I'd like to see it land. Unfortunately I can't merge this PR as it stands, and I want to be transparent about why and point you at the path that will get it in.

1) It's built on a base that no longer exists. This PR extends the bundled src/plugins/extensions/auto-reply directory. In v0.7.0 we removed that whole tree (auto-reply + translation) as a deliberate breaking change (#442) — bundled reference extensions are gone, and that logic now lives in standalone marketplace plugins built against the new v0.7 plugin contract. Merging this would resurrect a directory main intentionally deleted and revert the contract, so it conflicts at the architectural level, not just in the lockfiles.

2) The route-registration approach bypasses authentication. The plugin registers its HTTP routes by reaching for the raw Express app and prepending them ahead of NestJS's pipeline. Because those routes never enter the Nest pipeline, the global API-key guard never runs on them — so GET /plugins/auto-reply/sessions (which lists session ids/names/status) and POST /plugins/auto-reply/config end up reachable without an API key. That's a security regression we can't ship regardless of the architecture question. (Relatedly, it also monkey-patches the plugin loader and writes to dashboard/index.html on disk at runtime, which we'd want to avoid.)

The good news — there's a first-class path for exactly this. The v0.7 contract gives plugins everything this feature needs, the safe way:

• a dashboard config UI via the manifest (configSchema for a rendered form, or a sandboxed iframe UI) — no DOM injection or index.html rewriting needed;
• per-session activation + per-session config out of the box;
• ctx.net.fetch (SSRF-guarded), ctx.messages, and the message:received / message:sent hooks — no raw Express, no loader patching;
• routes that automatically sit behind the API-key guard.

So I'd love to see this re-targeted as a standalone marketplace plugin (the chat-flow id is reserved for exactly this interactive-flow use case) rather than a core extension. It'd be cleaner to review, wouldn't carry the auth/monkey-patch issues, and you'd own its release cadence independently. The plugin contract + SDK and the existing group-translate plugin are good references for the shape.

I'm going to close this PR since it can't be salvaged by a rebase, but I'm very happy to help you scope the plugin version — point you at the contract docs, the manifest schema, and the catalog (OpenWA-plugins plugins.json). Thanks again for the effort, and sorry the timing collided with the v0.7 extraction.