Update test results directory structure and enhance Docker configurations

- Modified `.gitignore` to reflect the new path for test results.
- Updated `docker-compose.test.yml` to mount the correct test results directory.
- Adjusted `Dockerfile.test` to set the `PYTHONPATH` and ensure test results are saved in the updated location.
- Added `boto3` and `netron` to `requirements-test.txt` to support new functionalities.
- Updated `pytest.ini` to include the new `pythonpath` for test discovery.

These changes streamline the testing process and ensure compatibility with the updated directory structure.

.cursor/rules/coderule.mdc

@@ -5,18 +5,22 @@ alwaysApply: true
 # Coding preferences
 - Always prefer simple solution
 - Generate concise code
-- Do not put comments in the code
+- Do not put comments in the code, except in tests: every test must use the Arrange / Act / Assert pattern with `# Arrange`, `# Act`, `# Assert` section comments. Omit any section that is not needed (e.g. if there is no setup, skip `# Arrange`; if act and assert are the same line, keep only `# Assert`)
 - Do not put logs unless it is an exception, or was asked specifically
 - Do not put code annotations unless it was asked specifically 
 - Write code that takes into account the different environments: development, production
 - You are careful to make changes that are requested or you are confident the changes are well understood and related to the change being requested
 - Mocking data is needed only for tests, never mock data for dev or prod env
 - When you add new libraries or dependencies make sure you are using the same version of it as other parts of the code
+- When a test fails due to a missing dependency, install it — do not fake or stub the module system. For normal packages, add them to the project's dependency file (requirements-test.txt, package.json devDependencies, test csproj, etc.) and install. Only consider stubbing if the dependency is heavy (e.g. hardware-specific SDK, large native toolchain) — and even then, ask the user first before choosing to stub.
 
 - Focus on the areas of code relevant to the task
 - Do not touch code that is unrelated to the task
 - Always think about what other methods and areas of code might be affected by the code changes
-- When you think you are done with changes, run tests and make sure they are not broken
+- When you think you are done with changes, run the full test suite. Every failure — including pre-existing ones, collection errors, and import errors — is a **blocking gate**. Never silently ignore, skip, or proceed past a failing test. On any failure, stop and ask the user to choose one of:
+  - **Investigate and fix** the failing test or source code
+  - **Remove the test** if it is obsolete or no longer relevant
+  - **Leave as-is for now** (acknowledged tech debt — not recommended)
 - Do not rename any databases or tables or table columns without confirmation. Avoid such renaming if possible.
 
 - Make sure we don't commit binaries, create and keep .gitignore up to date and delete binaries after you are done with the task

.cursor/rules/cursor-meta.mdc

@@ -17,5 +17,11 @@ globs: [".cursor/**"]
 ## Agent Files (.cursor/agents/)
 - Must have `name` and `description` in frontmatter
 
+## User Interaction
+- Use the AskQuestion tool for structured choices (A/B/C/D) when available — it provides an interactive UI. Fall back to plain-text questions if the tool is unavailable.
+
+## Execution Safety
+- Never run test suites, builds, Docker commands, or other long-running/resource-heavy/security-risky operations without asking the user first - unlsess it is explicilty stated in skill or agent, or user already asked to do so.
+
 ## Security
 - All `.cursor/` files must be scanned for hidden Unicode before committing (see cursor-security.mdc)