By transcript, I mean every command and every response in the debug session. Usually, in the beginning, I do not know yet what I'm looking for, and set breakpoints at points that may be interesting, and when I reach the breakpoints, I look at variables. Later, when I reach the point where things have gone wrong, I can look at variable values now, but also at the result of every previous query. This helps me answer questions like: was this object here already in that queue over there when the previous request came in?
I can also attach the debug session to an issue in order for others or future me to understand what was happening then. In a purely GUI-driven debugger, I can copy&paste a stack trace of the final point, but the history is lost.
I can really recommend debugging with command-line gdb (inside a text editor, of course; we're not barbarians). The transcript that lets you look back at the past of your debug session really adds a new dimension to the debug experience that a plain IDE integration just does not offer.
Just learn a tool at a time. Ftrace, for example, is a nice tool to trace kernel events. It is not the coolest kid on the block, but simple enough for basic things.
Mermaid has explicit support for diagrams that look UML-ish (never mind the filled triangle arrowheads for inheritance): class, state and sequence diagrams. Graphviz doesn't do that easily.
Remember when Blackberry succeeded in the market by calling their text-messaging device a "two-way pager" even though, technically, it was a mobile computer with modem and not at all a pager?
Chances are you'll fare best by hiding your earth-shattering new paradigm behind a veneer of familiarity. Then nobody has to know you have deep insights no one else has.
If you're at least a bit into home-lab tinkering, you could run NextCloud from a Docker container on your NAS or home server or RPi. For external access limited to your family's devices, you could use Tailscale.
But yes, you could just have Hetzner host it for you for a handful of Euros a month.
"Is my partner having a good time": Make your partners look good. That is usually a good idea in any team.
"Find the earliest end". That would mean don't ever maintain an old product because there's nothing interesting in it...
"Yes and" principle: you accept the ideas that your fellow players introduced and build on top of them. For example, "Backend moved their data store to a novel distributed document store they read about on Twitter -- Yes, And we'll let the frontend run in a JS-emulated Browser-in-a-Browser!". I see that being applied, but I'm not sure it's good advice.