🎯 CRITICAL PRINCIPLES (NON-NEGOTIABLE)

✅ STRICT TDD: Write failing test FIRST (RED), then implement (GREEN), then refactor
✅ NO MOCKS: Test real behavior, real code, real libs - NO MOCKS EVER
✅ NO LEGACY: Delete old code completely - NO backward compatibility, NO fallbacks
✅ NO HARDCODED VALUES: All config from YAML - NO magic numbers/strings in code
✅ 100% CONFIGURABLE: Every behavior must be configurable via YAML
✅ DRY: Zero code duplication - extract to shared utilities
✅ SOLID: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion
✅ KISS: Keep It Simple, Stupid - no over-engineering
✅ YAGNI: You Aren't Gonna Need It - remove speculative features
✅ LONG-TERM MAINTAINABLE
✅ UN-DUPLICATED & REUSABLE: DON'T REINVENT THE WHEEL. Before implementing any logic/lib/etc, analyse the current source code and look for potential already existing feature/implementation/function/class/lib that you could reuse/extend instead.
✅ STRICT COHERENCE AND UNITY: Our WHOLE code/lib/implementation/structure should be and stay coherent and unified. BEFORE implementing anything, look for similar patterns in our implementation/files/structure and understand EXACTLY how our current project/code/files/libs/scripts are structured and implemented, and implement it in a same/similar way, ensuring that anyone looking at our code/structure can easily understand everything and that our full implementation is looking like ONE coherent system
✅ ALWAYS FINDING AND FIXING ROOT ISSUES/ROOT CAUSES: We should NEVER apply dirty fixes or remove/simplify some logic/tests JUST to make some tests pass or bypass an issue. We must ALWAYS find the ROOT CAUSES of all issues and FIX THEM instead.
✅ REFACTORING ESSENTIALS: When refactoring, ALWAYS update ALL related code/callers, including CLIs/tests/e2e tests/unit tests/integration tests and ALL calls/usage sites. DO NOT KEEP or implement legacy fallbacks/backward-compatibility/deprecated code/logic, ALWAYS refactor and update EVERYTHING.
✅ SELF VALIDATION: When you think your task is done, do not mark it as done yet. You MUST self-validate and re-analyse EVERYTHING from a new fresh set of eyes, like if a colleague looked at the work you just had done to make sure you had not forgotten anything and that EVERYTHING has correctly been implemented and follows our CRITICAL PRINCIPLES.
✅ GIT: NEVER use
```
git reset
```
/
```
git checkout
```
or any similar commands, except if the user specifically asks you to. THIS IS CRITICAL!

Testing

When updating code, ALL related tests should be updated, including unit, integration, e2e, etc
When a test fails, we should ALWAYS analyse and fix the ROOT CAUSE of the failure. It could be that our code is wrong and we need to update/fix the logic, OR that the test is wrong or has issues, but we should NEVER simplify/skip/remove tests just to make them pass, or change tests just to work around an issue, and ALWAYS analyse deeply and fix the ROOT CAUSE of all issues.
The test suite can take long to execute and produce a lot of output. When running it (except if tightly scoped), always use a long timeout (eg. 30min) AND redirect all output/errors to a temporary file, to which you should then delegate a subagent to read completely and analyse deeply to extract all issues. Then, delegate multiple parallel subagents to analyse deeply the ROOT CAUSE of all issues and fix them in parallel.

🎯 CRITICAL PRINCIPLES (NON-NEGOTIABLE)

✅ STRICT TDD: Write failing test FIRST (RED), then implement (GREEN), then refactor

✅ NO MOCKS: Test real behavior, real code, real libs - NO MOCKS EVER

✅ NO LEGACY: Delete old code completely - NO backward compatibility, NO fallbacks

✅ NO HARDCODED VALUES: All config from YAML - NO magic numbers/strings in code

✅ 100% CONFIGURABLE: Every behavior must be configurable via YAML

✅ DRY: Zero code duplication - extract to shared utilities

✅ SOLID: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion

✅ KISS: Keep It Simple, Stupid - no over-engineering

✅ YAGNI: You Aren't Gonna Need It - remove speculative features

✅ LONG-TERM MAINTAINABLE

✅ UN-DUPLICATED & REUSABLE: DON'T REINVENT THE WHEEL. Before implementing any logic/lib/etc, analyse the current source code and look for potential already existing feature/implementation/function/class/lib that you could reuse/extend instead.

✅ STRICT COHERENCE AND UNITY: Our WHOLE code/lib/implementation/structure should be and stay coherent and unified. BEFORE implementing anything, look for similar patterns in our implementation/files/structure and understand EXACTLY how our current project/code/files/libs/scripts are structured and implemented, and implement it in a same/similar way, ensuring that anyone looking at our code/structure can easily understand everything and that our full implementation is looking like ONE coherent system

✅ ALWAYS FINDING AND FIXING ROOT ISSUES/ROOT CAUSES: We should NEVER apply dirty fixes or remove/simplify some logic/tests JUST to make some tests pass or bypass an issue. We must ALWAYS find the ROOT CAUSES of all issues and FIX THEM instead.

✅ REFACTORING ESSENTIALS: When refactoring, ALWAYS update ALL related code/callers, including CLIs/tests/e2e tests/unit tests/integration tests and ALL calls/usage sites. DO NOT KEEP or implement legacy fallbacks/backward-compatibility/deprecated code/logic, ALWAYS refactor and update EVERYTHING.

✅ SELF VALIDATION: When you think your task is done, do not mark it as done yet. You MUST self-validate and re-analyse EVERYTHING from a new fresh set of eyes, like if a colleague looked at the work you just had done to make sure you had not forgotten anything and that EVERYTHING has correctly been implemented and follows our CRITICAL PRINCIPLES.

✅ GIT: NEVER use

git reset

git checkout

or any similar commands, except if the user specifically asks you to. THIS IS CRITICAL!

Testing

When updating code, ALL related tests should be updated, including unit, integration, e2e, etc

When a test fails, we should ALWAYS analyse and fix the ROOT CAUSE of the failure. It could be that our code is wrong and we need to update/fix the logic, OR that the test is wrong or has issues, but we should NEVER simplify/skip/remove tests just to make them pass, or change tests just to work around an issue, and ALWAYS analyse deeply and fix the ROOT CAUSE of all issues.

The test suite can take long to execute and produce a lot of output. When running it (except if tightly scoped), always use a long timeout (eg. 30min) AND redirect all output/errors to a temporary file, to which you should then delegate a subagent to read completely and analyse deeply to extract all issues. Then, delegate multiple parallel subagents to analyse deeply the ROOT CAUSE of all issues and fix them in parallel.

🎯 CRITICAL PRINCIPLES (NON-NEGOTIABLE)