Start with v2

I want to move fast and I am okay with breaking stuff. As for now Thurbox has only few users. I am one of the main user. As for now I can add features for myself by improving thurbox and deploying new releases. Others needs to create issues and discuss with me for potential addition. For this project, usually, users will just change and move towards another solution they prefer.

I truly like how pi.dev agent is, and how it is working. Also a very interesting competitors bb is trying to provide such an experience.

Dropping Thurbox ?

For my usage what I could is to move towards a better solution that do provide fully customizable solution.

However (hopefully) there a still lot of caveats with competitors.

First I truly think that TUI is enough when it comes to agentic interface. Plus TUI is meant to be lightweight which is critical when it comes to running multiple consuming parallel agentic sessions!

Also, I am not fully aligned with how competitors do orchestrate agent sessions. There are two patterns.

First one is to directly use agent harness SDK, which requires custom adapters for each agents. This is on paper the best way to provide a fully integrated experience with your different agents. However, everything is moving fast, ensuring good integration and covering enough agents is tricky and most of existing solutions do have a lot of bugs.

Second option is to run agent sessions via dedicated PTY (thurbox choice). But even here we see 2 distinct approaches. Use tmux, or use a custom solution. Using a custom solution is a bad option because it will leads to complex bugs while using tmux for the hardwork is the clear winner.

Drafting v2 Design

I do not want to go head down and run a vibe coded implementation of thurbox v2.

Goal is to choose correct technologies and draft an architecture that will allow the fully customizable TUI.

Plugins should be the way to go, a small (or big) typescript code to add TUI features.

Keeping Rust for Thurbox core is also the way to go but hard part is what should be considered as plugin and what should not be considered as a plugin. Also I do have doubts around ratatui capabilities for integration with a typescript plugin.

Here is a PR with first design documents I could draft. Frontier is not clear yet, and more design work will be done.

More details in part 2...