<general_rules>

When creating new FSM classes, always check the `inc/` directory for existing headers and `src/` directory for existing implementations before creating new files. Follow the existing pattern of separating header files in `inc/` and implementation files in `src/`. Use C++11 standard as specified in `CMakeLists.txt` - ensure all code is compatible with this standard. Follow the existing naming convention with 'u' prefix for core classes (uFsm, uEventHandler, uFsmEvent). Include Doxygen documentation comments for all public methods and classes following the existing pattern found in `inc/uFsm.hpp` and `inc/uEventHandler.hpp`. Use the standard Doxygen comment format with `/**` and `*/` blocks, including `\file`, `\param`, and `\return` tags where appropriate. Note that no custom linter or formatter scripts exist in the repository, so maintain consistency with the existing code style manually. When adding new functionality, ensure it integrates properly with the event-driven finite state machine architecture. Always include proper memory management following RAII principles as demonstrated in the existing codebase.

</general_rules>

<repository_structure>

This is a C++ IoT micro finite state machine library. The`inc/` directory contains header files (`uFsm.hpp`,`uEventHandler.hpp`) that define the core FSM classes and interfaces. The`src/` directory contains implementation files (`uFsm.cpp`,`uEventHandler.cpp`) with the actual class implementations. Test files are located at the root level:`test_fsm.cpp` (main test suite using Catch2) and`CFsmTest.cpp` (example/demo application). The`docs/` directory contains Doxygen-generated HTML documentation accessible via`docs/index.html`. The build system uses CMake with`CMakeLists.txt` at the root defining project configuration, dependencies, and build targets. CI/CD configuration is in`.github/workflows/ci.yml` which runs builds, tests, and SonarQube analysis. The`Doxyfile` configures documentation generation, and`sonar-project.properties` configures code quality analysis.

</repository_structure>

<dependencies_and_installation>

Dependencies are managed via CMake with C++11 standard requirement. The Catch2 v3.6.0 testing framework is automatically fetched via CMake FetchContent from GitHub - no manual installation required. The build process uses standard CMake commands: run`cmake -S . -B build` to configure the project and`cmake --build build` to compile. No additional package managers (npm, pip, etc.) are required. The only system requirement is a C++11 compatible compiler and CMake version 3.10 or higher. All dependencies are handled automatically during the CMake configuration step.

</dependencies_and_installation>

<testing_instructions>

Testing uses the Catch2 v3.6.0 framework. The main test suite is in`test_fsm.cpp` and`CFsmTest.cpp` serves as an example/demo. Tests focus on FSM state transitions, event handling, and error conditions. After building the project, run tests using`ctest --test-dir build`. The test executable is automatically created as`test_fsm` and linked with`Catch2::Catch2WithMain`. When writing new tests, follow the existing patterns in`test_fsm.cpp`: use`TEST_CASE` macros with descriptive names, test both successful state transitions and error conditions, use`REQUIRE` assertions for critical checks, and organize tests by functionality (e.g., "FSM handles internal error", "FSM handles reset"). Tests should cover FSM state transitions, event handling, parameter passing, and boundary conditions. The testing framework is configured to automatically discover and run all tests defined with Catch2 macros.

</testing_instructions>

<pull_request_formatting>

</pull_request_formatting>