Refactor task management structure and update documentation

- Changed the directory structure for task specifications to include a dedicated `todo/` folder within `_docs/02_tasks/` for tasks ready for implementation.
- Updated references in various skills and documentation to reflect the new task lifecycle, including changes in the `implementer` and `decompose` skills.
- Enhanced the README and flow documentation to clarify the new task organization and its implications for the implementation process.

These updates improve task management clarity and streamline the implementation workflow.

_docs/02_tasks/done/AZ-144_test_negative.md

@@ -0,0 +1,82 @@
+# Negative Input Tests
+
+**Task**: AZ-144_test_negative
+**Name**: Negative Input Tests
+**Description**: Implement E2E tests verifying proper error responses for invalid inputs, unavailable engine, and missing configuration
+**Complexity**: 2 points
+**Dependencies**: AZ-138_test_infrastructure
+**Component**: Integration Tests
+**Jira**: AZ-144
+**Epic**: AZ-137
+
+## Problem
+
+The system must handle invalid and edge-case inputs gracefully, returning appropriate HTTP error codes without crashing. Tests must verify error responses for empty files, corrupt data, engine unavailability, and missing configuration.
+
+## Outcome
+
+- Empty image returns 400 Bad Request
+- Corrupt/non-image data returns 400 Bad Request
+- Detection when engine unavailable returns 503 or 422
+- Missing classes.json prevents normal operation
+- Service remains healthy after all negative inputs
+
+## Scope
+
+### Included
+- FT-N-01: Empty image returns 400
+- FT-N-02: Invalid image data returns 400
+- FT-N-03: Detection when engine unavailable returns 503
+- FT-N-05: Missing classes.json prevents startup
+
+### Excluded
+- Duplicate media_id (covered in async/SSE tests)
+- Service outage scenarios (covered in resilience tests)
+- Malformed multipart payloads (covered in security tests)
+
+## Acceptance Criteria
+
+**AC-1: Empty image**
+Given the detections service is running
+When POST /detect is called with a zero-byte file
+Then response is 400 Bad Request with error message
+
+**AC-2: Corrupt image**
+Given the detections service is running
+When POST /detect is called with random binary data
+Then response is 400 Bad Request (not 500)
+
+**AC-3: Engine unavailable**
+Given mock-loader is configured to fail model requests
+When POST /detect is called
+Then response is 503 or 422 with no crash or unhandled exception
+
+**AC-4: Missing classes.json**
+Given detections service started without classes.json volume mount
+When the service runs or a detection is attempted
+Then service either fails to start or returns empty/error results without crashing
+
+## Non-Functional Requirements
+
+**Reliability**
+- Service must remain operational after processing invalid inputs (AC-1, AC-2)
+
+## Integration Tests
+
+| AC Ref | Initial Data/Conditions | What to Test | Expected Behavior | NFR References |
+|--------|------------------------|-------------|-------------------|----------------|
+| AC-1 | Service running | POST /detect with empty file | 400 Bad Request | Max 5s |
+| AC-2 | Service running | POST /detect with corrupt binary | 400 Bad Request | Max 5s |
+| AC-3 | mock-loader returns 503 | POST /detect with valid image | 503 or 422 | Max 30s |
+| AC-4 | No classes.json mounted | Start service or detect | Fail gracefully | Max 30s |
+
+## Constraints
+
+- AC-4 requires a separate Docker Compose configuration without the classes.json volume
+- AC-3 requires mock-loader control API to simulate failure
+
+## Risks & Mitigation
+
+**Risk 1: AC-4 service start behavior**
+- *Risk*: Behavior when classes.json is missing may vary (fail at start vs. fail at detection)
+- *Mitigation*: Test both paths; accept either as valid graceful handling