refactor: prefixo no nome das branches — feature/ e chore/

.agents/rules/utf-rules.md

@@ -31,7 +31,8 @@ Ao estourar qualquer um dos dois, PARE IMEDIATAMENTE e diga qual estourou: "Esto
 
 ## 5. Regras de Git 
 - **Gitflow: `main` e `develop` são sagradas e bloqueadas.** Nunca faça commits diretos em nenhuma das duas. A `main` reflete produção; a `develop` integra o trabalho da equipe.
-- Toda implementação nasce em uma branch separada (Feature Branch), criada a partir da `develop`.
+- Toda implementação nasce em uma branch separada, criada a partir da `develop`, e **o nome carrega o tipo**: `feature/<numero-da-issue>-<slug>` para história, `chore/<slug>` para manutenção (bug, tarefa técnica, setup).
+- **A pasta da spec não leva prefixo:** `specs/<numero-da-issue>-<slug>/`. O prefixo é da branch, não do caminho no disco.
 - No fim da Issue, instrua o usuário a abrir um Pull Request para a `develop`.
 
 ## 6. Integração com GitHub (MCP)

.agents/workflows/utf-issue.md

@@ -14,7 +14,7 @@ Sempre que o usuário pedir para trabalhar em uma Issue (Feature), você atuará
 **Passo 1: Entendimento e Brainstorming**
 - Leia a Issue apontada e busque no `docs/prd.md` os critérios e o Glossário Ubíquo.
 - Faça perguntas ao usuário de forma proativa. Questione sobre casos de borda, caminhos tristes (ex: falhas de rede, dados inválidos) e como validar os critérios de aceite.
-- Após sanar as dúvidas, **crie a branch da história a partir da `develop`** (`git switch develop && git pull && git switch -c <numero-da-issue>-<slug>`). Ela nasce agora, antes da aprovação, porque no Gitflow `main` e `develop` são bloqueadas — e o commit de aprovação do usuário precisa de um lugar para viver.
+- Após sanar as dúvidas, **crie a branch da história a partir da `develop`** (`git switch develop && git pull && git switch -c feature/<numero-da-issue>-<slug>`). Ela nasce agora, antes da aprovação, porque no Gitflow `main` e `develop` são bloqueadas — e o commit de aprovação do usuário precisa de um lugar para viver.
 - Redija o documento e salve no caminho `specs/<numero-da-issue>-<slug>/spec.md`, commitando o rascunho na branch. **A estrutura é a de `docs/modelo-spec.md`** — copie-a e preencha; os comentários dela explicam cada seção e são apagados no caminho. Não invente seções novas nem pule as existentes. O frontmatter:
 
 ```yaml

.agents/workflows/utf-setup.md

@@ -38,7 +38,7 @@ que foi decidida. O que não estiver escrito lá, você pergunta; não escolhe.
 ## Passo 1 — Branch
 
 ```
-git switch -c setup-projeto
+git switch -c chore/setup-projeto
 ```
 
 Nenhum arquivo é criado antes da branch existir. No Gitflow, `main` e `develop` são bloqueadas — a branch do setup nasce da `develop` e volta para ela por PR.

CONTRIBUTING.md

@@ -22,9 +22,10 @@ Você é o Engenheiro e o Arquiteto; a IA é a sua equipe de execução.
 > ela. A `develop` do projeto de vocês é criada pelo `/utf-setup`, no repositório novo.
 
 - **Duas branches permanentes e bloqueadas:** a `main` reflete a produção; a `develop` integra o trabalho da equipe. Commit direto em qualquer uma das duas é proibido.
-- **Trabalho:** Crie uma feature branch curta **a partir da `develop`** para cada Issue.
+- **Trabalho:** Crie uma branch curta **a partir da `develop`** para cada Issue, nomeada `feature/<numero-da-issue>-<slug>`. Manutenção (bug, tarefa técnica, setup) usa `chore/<slug>`.
 - **Integração:** Ao finalizar, abra um Pull Request **para a `develop`** com `Closes #<n>`. O CI (testes + lint) precisa passar antes do merge.
 - **Release:** quando a `develop` está estável, um PR de `develop` → `main` publica a versão (é o que o deploy em produção acompanha).
+- **O que este projeto não usa:** o Gitflow original também prevê branches `release/*` e `hotfix/*`. Aqui não há trem de release nem correção de emergência em produção separada — a publicação é o próprio PR de `develop` → `main`. Se vocês encontrarem esses nomes em tutoriais, não é algo que ficou faltando.
 - **Em equipe (ID27):** todo PR precisa da aprovação de **um colega** antes do merge — quem abre a story não mergeia o próprio PR. Os portões da história (spec, triagem, commit) são do **dono da história**; a revisão do PR é do colega.
 
 ---

docs/guia-sdd.md

@@ -377,7 +377,7 @@ deste ciclo (inclusive o da sua aprovação, no Passo 3) precisa de um lugar par
 
 ```bash
 git switch develop && git pull
-git switch -c 27-solicitar-vaga
+git switch -c feature/27-solicitar-vaga
 ```
 
 Dessa conversa sai o `spec.md`, em `specs/<numero-da-issue>-<slug>/`, commitado como