[FEAT] Introducing a State Machine Algorithm

[Coopyrightdmin]

Problem Statement

The current code, while functional, follows a linear and fixed structure to process various transformation, analysis, and generation steps. This makes it challenging to add, remove, or modify steps without revisiting a significant portion of the code.

Benefits

1. Plugin System Preparedness: Integrating a state machine is a preparatory step for the introduction of a plugin system. The plugins would be incorporated as steps within the state machine, allowing for a dynamic and extendable process flow.
2. Maintainability: In case of bugs or required enhancements in a specific step, it wouldn't affect the other steps, making debugging and updates simpler.

Additional context

The implementation of this state machine will follow the standard structure of state machines, with a class for each state and a main class handling transitions between states. While this will require a major overhaul of the current code structure, the core functions currently used for each step will be largely reused.

Priority/Severity

• [x] High (This integration will make the code more robust, scalable, and easier to maintain for future iterations and paves the way for an extendable plugin system)
• [ ] Medium
• [ ] Low

---

Vous pouvez apporter des modifications en fonction de vos besoins spécifiques et ajouter des détails supplémentaires si nécessaire.

[Coopyrightdmin]

I'm pleased to announce that we have addressed the concerns raised in this ticket.

In order to provide a more scalable and maintainable structure, we've restructured our project. The existing modules have been relocated to a modules directory. Moreover, we have introduced a new extensions directory, where we have added three new classes: AutomationEngine, Step, and Context.

The Context class is especially central to this enhancement, serving as a memory exchange block. Here's a brief overview of its attributes:

• self._config: Represents the configuration model.
• self._logs: A list that captures logs.
• self._data: Holds any form of data required during processing.
• self._result: A dictionary that captures the results.
• self._input_path: Specifies the path for input data or files.
• self._output_dir: Designates the directory for output data or files.
• self._lang: Used to specify the language if necessary.
• self._prompt: A flag to indicate if prompting is required.
• self._status: Indicates the status of the context, leveraging the ContextStatusenumeration.

This restructuring makes our codebase more robust, scalable, and easier to maintain. It also lays a strong foundation for introducing an extendable plugin system in the future. Thank you for your patience and understanding during this overhaul. As always, we welcome any feedback or suggestions.