Not sure "Inbox" makes sense for the user here. It might not even end up in the inbox if we added under a parent who has a project.

Kinda nitpicking, but I'd put this one last, although I see a need it's a bit of a corner case (or "last chance to find me") situation, I don't want it too prominently displayed.

Bonus point for reordering the member variable order, the initialization order and the conditions order (now that's my OCD speaking).

Since we really should get there I'm not sure the struct name is appropriate, I'd go for "TaskExtraData" or such.

Aligning with my comment, maybe it'd benefit from having a test verifying it does the right thing on promote? Obvious potential mistake would be the promoted task disappearing and its children as well (while the children should still appear with a new project as extra info).

It's not that simple.

In inbox, workday and all tasks, we need a projects query and a contexts query.
In projects, we need a contexts query.
In contexts, we need a projects query.
(+ childTask in all projects)

Either this means we have 3 structs, to use the right one in the right place, or we have one struct with everything and sometimes an unused member.

Now I'm thinking about all this and writing it down, I guess a single struct is simpler and the waste (one pointer per item) is acceptable?

I re-added the same test as in workday page.

But a test like the one you mention sounds more like a feature test, no?

IMHO there's too much mocking at this level for such a test to make sense here. It'll pass for sure even if something was broken, because the mocks would return the right thing anyway.

Done. A bit reluctantly because I found it convenient at the top, but I agree with the reasoning -- for more orderly people at least :-)

Yes, this is what I had in mind. One unused pointer is OK.

Right, it's time to "demock" some of the tests. But that's for later.