Like many things, indeed. The other route is UI composition, keeping visualization close to the rest.

Here's a very simple heuristic: Different people working on it? Different context. Period!

Not data driven, but actual data, not code.

Wait until you realize the scenario is just data. You end up with one big data driven test.

Instead of coming up with static snapshots like this, store it in a graph db and use a Gremlin query visualizer.

Aggregates should be "invisible" in the code artifact (their roots not so much). So even if you claim it's not there, it's there. The fact many people read the word aggregate in a book and started embedding it literally in their code base is an accident in many OOP code bases.

This is already common practice for things that live at the "edges". Think OpenAPI, AsyncAPI, xRegistry, any sort of IDL, etc ...
Far less common for internals though.

One has to wonder what this sort of tech will do for people with imposter syndrome.

If nothing else, I think a lot of people would be interested to hear about "How I built VocalFold" or read about it :-)

I assume it's mostly - if not entirely - driven by the tasks you give Claude to implement. The workflow you use, where did you learn about that?

wiki.c2.com?CollectingPa...

Yeah, that’s akin to collecting parameter. I often use it when the logic is so complex understanding the why of a decision is as important as the decision itself.

What do you mean by debug object? Collecting parameter?