RFC: Would you use a graph-first Git TUI for repository maintenance?

[hrllk]

Graphkeeper is exploring a graph-first workflow for Git repository maintenance.

Instead of treating the commit graph as supporting information, the graph acts as the primary workspace for inspecting branches, remotes, tags, upstream state, and repository operations.

I’m currently trying to validate the core concept rather than collect general feature requests.

I’d appreciate feedback on the following questions:

1. When reading a Git graph, what information do you check first?
2. Can you determine whether to merge, rebase, fast-forward, or reset from the current Graphkeeper UI?
3. Which branch relationships or repository states are still difficult to understand?
4. Is a standalone TUI useful for this workflow, or would an editor integration be more valuable?
5. In what specific situation would you open Graphkeeper instead of running Git commands or using another Git client?

Current version: v0.1.0-alpha.4

Screenshots, workflow examples, and critical feedback are all welcome.