David Sutherland

> Having to remember the column number of each state is pretty dire! Well, there's only 4 columns, so it'd be fairly automatic if you were used to looking at...

Users shouldn't need to look at the `flow.cylc` or expand the graph window to know what a task is going to wait for or to know which condition (AND/OR conditions)...

> The comments above are now resolved Yes, I think we're in a good place. > From a CLI perspective it's not ideal to be restricted to the n-window, but...

> any ideas about how a task or family could end up with no `first_parent`? Perhaps with orphans? The only other way I can think of is..: If the node...

> Some families arriving with no `first_parent` elements. Well, `root` would always have no `first_parent`? I assume you mean others.. > I haven't found any pattern to the affected families...

Agreed this is needed .. And if it is to work using a broadcast style/approach, without reading context (which may address this), we should think about using a pop-up window...

Think it's probably the same thing we've been seeing, that Ronnie fixed (well half of it).. We should get this one in too: https://github.com/cylc/cylc-flow/pull/6589 (I've also seen this bug regularly...

Have run it twenty times locally and no failure... I will see if there's a more robust way to test the update.

I'd have to understand how the test harness works at a deeper level to know why it's inconsistent.. i.e. why does this: ``` @pytest.mark.asyncio @pytest.fixture(scope='module') async def harness(mod_flow, mod_scheduler, mod_run):...

I think the same harness yield gets shared amongst the tests.. Whenever I changes the order of the tests, it appears to effect what data the next tests are working...