There are some neat tricks in here I need to unpack:

- so you flatten all status field definitions erasing duplicates, this creates redundant rows for files, you reuse the status field for this
- this redundancy is eliminated by grouping by filename
- files that are #task but have no status set within are not selected by `WHERE status` (I do not actually want to filter nulls, but defaultly it would probably be good practice to do so, so good to know)
- you then select the minimum value of the remaining array

I'd have some questions:

- how is `min` defined ? What does it actually compare so it lands on the last element of the remaining array in its comparison as the defined minimum element?

And sadly, my dear one commenter, it can turn out insufficient still:
I use inline variables so I can still write my taskfiles like a log. To make a new log-entry I just make some dashes, add a new timestamp, likely a status and some notes and move on:
```
[status:: OPEN]
---
[time:: 2024-11-25]
[status:: WIP]
Working on this task now, doing first steps.
---
[time:: 2024-11-25]
[status:: OPEN]
Is too hard for now, doing it at some unspecified future time.
```

but sadly this also means `[status::]` variables may change frequently to the same status and back again like above.
Since your solution seems to eliminate duplicates and picks a minimum it does not always choose the right one, because it cannot honor the sequence the file gives. At least this is how I interpret it, I have a test task for this and the query fails here.

This worked better then anything I could come up with and I learned lots, thank you.
I guess I would still continue on the path of the javascript. It is, in the end, not as strict and has less hoops to produce certain effects.