Before submitting
Area
apps/desktop
Problem or use case
The work we do is grouped and managed within a single worktree. Threads should be too.
Consider 4 parallel worktrees where each is a unique branch. It should be easy to organize threads to be grouped by the overarching worktree. Grouping primarily by repo is the wrong organizing principle especially since most people are mot using multiple repos anyway.
Conductor does a good job of this and has the best capture on the mental model of how people actually work. T3 Code should adopt this approach.
Proposed solution
The primary grouping of threads is by worktree, like Conductor.
Why this matters
It's hard to keep track of multiple worktrees that have multiple threads each.
Smallest useful scope
See above
Alternatives considered
No response
Risks or tradeoffs
No response
Examples or references
Exactly how Conductor works.
Contribution
Before submitting
Area
apps/desktop
Problem or use case
The work we do is grouped and managed within a single worktree. Threads should be too.
Consider 4 parallel worktrees where each is a unique branch. It should be easy to organize threads to be grouped by the overarching worktree. Grouping primarily by repo is the wrong organizing principle especially since most people are mot using multiple repos anyway.
Conductor does a good job of this and has the best capture on the mental model of how people actually work. T3 Code should adopt this approach.
Proposed solution
The primary grouping of threads is by worktree, like Conductor.
Why this matters
It's hard to keep track of multiple worktrees that have multiple threads each.
Smallest useful scope
See above
Alternatives considered
No response
Risks or tradeoffs
No response
Examples or references
Exactly how Conductor works.
Contribution