From 08db683120d0a59071651426b3cddbce74574b16 Mon Sep 17 00:00:00 2001 From: Roni Fabio Banaszewski Date: Thu, 10 Sep 2026 17:06:53 -0300 Subject: [PATCH] =?UTF-8?q?refactor:=20prefixo=20no=20nome=20das=20branche?= =?UTF-8?q?s=20=E2=80=94=20feature/=20e=20chore/?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit O template criava branches sem prefixo: `27-reserva-de-carona` para historia e `setup-projeto` para o scaffold. Funciona, mas nao e o que o aluno encontra no mercado — o CLI do git-flow e praticamente todo material da area usam `feature/`, e a listagem de branches sem prefixo nao diz o tipo de nada. O modelo original do Gitflow nao exige prefixo (so `release-*` e `hotfix-*` tem nome obrigatorio); o `feature/` e convencao da ferramenta. Adotamos por ser o que se reconhece, mantendo o numero da Issue no nome, que e o que liga branch, Issue, PR e pasta da spec. Duas coisas ficam ditas para o agente nao errar: - **A pasta da spec nao leva prefixo** — continua `specs/-/`. O prefixo e da branch, nao do caminho no disco. Sem essa frase o agente cria `specs/feature/27-.../` na primeira tentativa. - **`chore/` para manutencao** (bug, tarefa tecnica, setup), casando com o vocabulario de Conventional Commits que as mensagens ja usam. O CONTRIBUTING do Angular ganha tambem a nota de que `release/*` e `hotfix/*` existem no Gitflow e nao sao usados aqui — o aluno vai encontra-los em tutorial e precisa saber que nao esqueceu nada. Co-Authored-By: Claude Opus 5 (1M context) --- .agents/rules/utf-rules.md | 3 ++- .agents/workflows/utf-issue.md | 2 +- .agents/workflows/utf-setup.md | 2 +- CONTRIBUTING.md | 3 ++- docs/guia-sdd.md | 2 +- 5 files changed, 7 insertions(+), 5 deletions(-) diff --git a/.agents/rules/utf-rules.md b/.agents/rules/utf-rules.md index 4485304..f6bd298 100644 --- a/.agents/rules/utf-rules.md +++ b/.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/-` para história, `chore/` para manutenção (bug, tarefa técnica, setup). +- **A pasta da spec não leva prefixo:** `specs/-/`. 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) diff --git a/.agents/workflows/utf-issue.md b/.agents/workflows/utf-issue.md index d00a381..e893b34 100644 --- a/.agents/workflows/utf-issue.md +++ b/.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 -`). 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/-`). 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/-/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 diff --git a/.agents/workflows/utf-setup.md b/.agents/workflows/utf-setup.md index ad07e79..9983d8b 100644 --- a/.agents/workflows/utf-setup.md +++ b/.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. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c6b8ddb..084dcdf 100644 --- a/CONTRIBUTING.md +++ b/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/-`. Manutenção (bug, tarefa técnica, setup) usa `chore/`. - **Integração:** Ao finalizar, abra um Pull Request **para a `develop`** com `Closes #`. 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. --- diff --git a/docs/guia-sdd.md b/docs/guia-sdd.md index 35ff9eb..8de4c0f 100644 --- a/docs/guia-sdd.md +++ b/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/-/`, commitado como