Context types for visualizaton and further processing

[gavento]

Logged contexts have different semantics and usage, for example: root context, entire game/experiment, individual game moves&observations, main structure of agent deliberation, queries to LLMs, and auxiliary structures like repeat_on_failure.

It would be useful to have several broad categories for those, for better UI view customization and also post-processing. For example:

• hideable subtrees - where the observer is often not interested in the content (including the subtree), e.g.: all "observations" sent to individual agents when the game progress is obvious to a user from actions, or or explicitly user-declared "helper" queries or subroutines inside deliberation (that are most useful for debugging). This can be either hidden by default or vice versa.
• "wrapper/structural contexts" - contexts that somehow represent a function (repeat_on_failure) or an auxiliary structure of the entire process (e.g. splitting a game into "round 1", "round 2", ...), but where it makes sense to omit from the tree and insert their children (or some of them) visually or semantically directly into the super-context. This can be either hidden by default or vice versa.
• "default" - visible and relevant by default, most of user-created contexts, hidable only by more complex filtering (which may be a more advanced feature)
• maybe other categories (?)

Why: both for readability in the GUI (see just "a dialog" instead of "a dialog split into rounds", by default see only the last iteration of repeat_on_failure, etc.) and semantically when working with the data (so that e.g. only "agent messages" can be selected from a complex dialogue interaction split into phases/rounds etc., without e.g. having to scan into round subtrees manually and explicitely - or even deal with what the rounds are and if they are there) (edited)

How: Think about tags and their types, and filter based on them.

1. One option: tags could have their "class" directly in the name (e.g. tag H-foo is hidden by default, S-bar is a wrapper/structural tag, ... This is not very elegant, though may be convenient. Also needs good naming to be intuitive.
2. Other option: define standard tags (action, game, observation, repeated-on-failure ...) and define their classses. Having standard tags may be useful practice anyway.
3. Just add the type of the node to its tags explicitely, e.g. add T-wrapper, T-hidden or T-hidable to the node. Explicit, does allow the same tag to be hidden/not hidden dep. on the context. Better for the default setting, but not better for classifying the tags themselves.
4. Maybe others

[gavento]

How to implement filtering:

A. Either just swithching individual tags between visible/hidden-subtree/hidden-wrapper (the tag classes then hint which tags are by default hidden, or are easily toggleable (if there are many tags). B. Or just have full JSON-path-based filter, with the default settings hiding classes as in case 3 above.

[gavento]

My first impression is that we want to have some standard tags for games, queries, and utility wrappers anyway, and then we can do 2. (e.g. as default filter) or 3. (explicit hidabilty of nodes, though less sure about that) And then we can look into B. (JSON-path - is it good or is it whack?) while starting with just A. (The MVP could be just having toggles for known hidable classes (from 2.) and maybe 3 toggles for all of T-wrapper and T-hidden and T-hidable.

Not very high priority in the UI but making some decent early judgment calls about how we use tags may be good early.

@spirali , @klao What do you think?

[gavento]

Note that the functionality is mostly there thanks to @spirali 's recent work. The kind+tag semantics and more general filters are still to be decided and created, though.