Study how an AI pair helped design a branching chat UI
Borrow the thread-versus-graph data model split for your own chat app
Reference the backend gap list when forking conversation threads
See a worked example of scoping FlowChat-style features against an existing schema
It is a documentation repo in Chinese with no code to run.
This repository is not software in the usual sense. It is a transcript, in Chinese, of the real conversations the author had with an AI assistant while planning a new feature for another project called Arkloop. Arkloop is described as an open-source AI agent client. The author wanted to fold ideas from a separate side project called FlowChat into Arkloop, and the chat logs here capture the back and forth that led to a design. The README explains that only the author's prompts and the AI's replies were kept. Tool calls and intermediate reasoning steps were stripped out. The discussion centres on how to replace Arkloop's existing Retry and Fork actions with something more visual, in the style of FlowChat, which lays a conversation out as a branching graph. A large part of the transcript is about where to draw the line between back-end and front-end work. The author and the AI agree that Arkloop's back end already has thread-level fork support, with fields like parent_thread_id and branched_from_message_id and a fork endpoint that copies messages up to a chosen point. So instead of rewriting the back end into a message-level graph, the plan is to add a new tab in the right panel that draws the branch graph, while keeping threads as the underlying execution unit. Later rounds refine that idea. Clicking a message in the main chat view should show history only up to that point, and continuing to send messages from there should automatically create a new forked thread rather than overwriting the old one. The transcript also lists the small back-end gaps that still need filling, such as exposing branched_from_message_id on thread responses, returning a thread family graph, and stabilising message ordering with a thread_seq field. The last section drives at a cleaner split. The back end keeps threads and messages as storage and execution. A new conversation_graph layer is added so the front end can render a true FlowChat-style message graph without the back end being rewritten. The repository serves as a record of how that decision was reached.
Generated 2026-05-22 · Model: sonnet-4-6 · Verify against the repo before relying on details.