Use repository-derived worktree branch names instead of the hardcoded t3code prefix

[TaylorMerritt]

Summary

New worktree branches are currently created under a hardcoded t3code/... namespace, even when the active repository is not named t3code.

Problem

This makes branch names and derived worktree paths misleading in multi-repo usage. For example, creating a new worktree in another repository can still produce a branch like t3code/1a2b3c4d, which looks like it belongs to this app rather than the actual repository the user is working in.

Current behavior

• The initial temporary worktree branch is created with a hardcoded t3code/<8-hex> prefix.
• After the first turn, generated human-readable branch names are also forced back under the t3code/... namespace.
• This leaks the app name into repository-specific git state and worktree folder names.

Expected behavior

• New worktree branch names should be based on the actual repository name, or use no prefix at all.
• Temporary branch detection should continue to work reliably for the first-turn rename flow.
• Generated branch names should stay consistent with whatever namespace rule we choose.

Why this matters

• Reduces confusing branch names across different repositories.
• Keeps git state aligned with the repo the user is actually editing.
• Avoids app-specific naming leaking into worktree management and downstream tooling.

Likely code areas

• apps/web/src/components/ChatView.tsx
• apps/server/src/orchestration/Layers/ProviderCommandReactor.ts
• packages/shared/src/git.ts

Acceptance criteria

• No hardcoded t3code worktree branch prefix remains in the worktree creation / rename flow.
• The temporary branch created for a new worktree uses a repository-derived namespace, or no namespace if that is the chosen design.
• The server-side first-turn rename flow uses the same naming rule as the initial branch creation flow.
• Temporary-branch detection still works for the rename path.
• Relevant tests cover the naming and detection behavior.

Prompt to solve

Refactor worktree branch naming so it is derived from the active repository instead of a hardcoded t3code prefix. Centralize the naming logic in shared git utilities, update the web-side worktree creation flow and the server-side first-turn branch rename flow to use the same helper, preserve reliable temporary branch detection, and add focused tests for namespace derivation, temporary branch generation, and generated branch renaming.

[nathanscain]

would ideally like a way to specify branch naming conventions. My org requires us to prefix branches by type feat/*, fix/*, et al.

similar request for commit messages to stick with conventional commits (also enforced by my org)

[TaylorMerritt]

would ideally like a way to specify branch naming conventions. My org requires us to prefix branches by type feat/*, fix/*, et al.

similar request for commit messages to stick with conventional commits (also enforced by my org)

Yeah I just had the gut initial take of “I don’t want my branches prefixed with t3code.” I think the minimum change I need is to just be able to configure the branch prefix (allowing null too for no prefix). Maybe a more polished solution looks like a prompt where you can give instructions for which type of branch prefix you’d like to use like in your example you need to have feat and fix prefixes. Maybe an in-between solution is to be able to define multiple prefixes and then on creation of the branch the model will attempt to make a choice and the user gets the final say via a UI element/prompt.

[juliusmarminge]

t3code/ is cause t3code is the one making the branch, not cause it's the repo you're in.

we'll eventually have configurable branch names (probalby both deterministic prefix but also letting you configure the prompts sent to the agent when generating the name).

[nathanscain]

cool - I figured it was that just to keep t3code branches from colliding with something else preexisting.

I know you have a thousand things coming at you, but can you give a rough priority on at what point polish like this will be added?