Backend: Domain-Modell + Interface (ExecutionFeed.cs, IExecutionFeedService.cs)

Implementation steps

• 1.Inspect src/agent_runtime/api/route/execution_feed.py to confirm how FeedFilter is currently instantiated and whether FastAPI/Pydantic validation is already used for related query constraints that return 422.
• 2.Inspect src/persistence/repository/task/execution_feed_repository.py to locate the FeedFilter definition and determine whether it is a dataclass, Pydantic model, or other typed container; use the smallest native validation mechanism available there.
• 3.Add an explicit conflict rule for amount filters: betrag_equal must not be combined with betrag_above or betrag_below. If repository-level FeedFilter supports model validation, encode the rule there so invalid combinations are rejected consistently wherever the filter is constructed.
• 4.Thread the validation through src/agent_runtime/service/execution_feed_service.py only as needed: if FeedFilter itself raises/validates, keep service changes minimal; otherwise add a lightweight guard in the service so the business rule is enforced beyond the HTTP layer.
• 5.Update src/agent_runtime/api/route/execution_feed.py so invalid amount-filter combinations surface as HTTP 422 for GET /execution-feed. Prefer framework-native validation/error mapping already used in this endpoint rather than custom response shaping.
• 6.Preserve existing valid combinations, especially betrag_above with betrag_below together if currently intended as a range; only reject combinations explicitly called out by the work packet unless repository semantics prove otherwise during inspection.
• 7.Extend tests/unit/agent_runtime/api/test_execution_feed.py with focused API tests that assert 422 when betrag_equal is combined with betrag_above, and 422 when betrag_equal is combined with betrag_below.
• 8.Add or update one passthrough test for a valid non-conflicting amount filter combination to confirm the service still receives expected FeedFilter values after the change.
• 9.If service-level validation is introduced because FeedFilter cannot validate itself, add a targeted unit test in the smallest existing test area available for the service or adjust the API test fixture expectations so the invalid request never reaches mock_service.get_feed.
• 10.Run only the narrow relevant test subset first, then the broader execution-feed unit tests, and inspect for any existing assumptions about FeedFilter construction or FastAPI validation formatting.