code cleanup
@gricha -- tasks are already being sorted within the queue, why extra sorting here?
besides that - a function "filter tasks" that takes not a task list, but a single task as an argument? and then fetches extra tasks from the queue? no no no.
@gricha - one of the rules of agile programming - don't add placeholder classes, don't anticipate. if you don't implement conditions yet, don't create placeholder classes.

reasons for that:
- agile projects often pivot, and you end up with a code full of placeholders that won't get ever used
- placeholders make code harder to read, so there's a recurring cost to having them
- the architecture may change before we get to implementing a given feature, and placeholder might not fit the new architecture

I know we were two steps away from creating the conditions, but still - you should've waited with implementing the condition evaluator until the day you're building the conditions. **and even then** not create a separate class for that (because again - that's anticipating that future conditions will appear), but do it inline first, and once you see the code duplicated, move to create separate functions, and then finally - classes.

If you do it another way (and you are doing it the other way around consistently), you end up with a code filled with empty classes, that's very hard to maintain and modify.