Defining the core and plugin boundaries

What should we keep in core thurbox and what should be implemented as plugins ?

I am suggesting an aggressive approach where almost everything existing should be plugins. What remains in core should be essential components: tmux management, git worktrees and session lifecycle...

Then most features will be redeveloped as plugins. Allowing more flexibility than just feature flags to enable or disable what end users wants or not.

Defining plugins capabilities

What capabilities should be provided to plugins ? The more capabilities they have, the better. Design and architecture goals is to find potential limitations related to what plugins can do.

Thurbox core (everything that is not a plugin) is defined as the kernel.

Kernel responsabilities are:

• Session lifecycle

• Terminal grid (most important UI for agents)

• Storage and migrations

• Git and worktrees

• Event loop, critical for UI

• Plugins host

• Themes, keep global UI consistent with one theme only

Then everything else is a plugin, including session list, code reviews, automations or tasks.

In other words, plugins should be capable to impact entire TUI and also fetch and send datas and metadatas to/from sessions.

Then question is how the hell can we provide full control to TUI, keeping everything stable. One solution is to provide primitives for the plugin to use and compose with. However this approach seems to restrictive... Animations are not feasible and direct terminal access are not feasible.

Goal is to be able to be able to have a plugin like thurbox-doom working (same as pi-doom)!

No good approach have been decided yet, I am open to any suggestions and will continue to do some research. More in part 3...