jarvis-ai-framework 1.0.0

package/workflows/engineering/eng.plan.md

@@ -0,0 +1,213 @@
+---
+description: Planejamento de execução faseada para a feature
+auto_execution_mode: 3
+agent: "$IDE/agents/engineering/eng.agent.md"
+rules_file: "$IDE/rules/engineering/eng.plan-rules.md"
+template_file: "$IDE/templates/engineering/plan-template.md"
+recommended_model: claude-sonnet-4-20250514
+model_tier: high
+model_justification: Planejamento detalhado requer decomposição de tarefas complexas, análise de dependências e estimativas precisas
+---
+
+# Engineer Plan
+
+Este workflow cria um **plano de execução detalhado e faseado** para implementar a feature de forma incremental.
+
+---
+
+## Argumentos
+
+<arguments>
+#$ARGUMENTS
+</arguments>
+
+Ler `TASK_MANAGER` do `$IDE/ENV.md`. Se o `TASK_MANAGER_KEY` não vier nos argumentos: **perguntar e aguardar** (`eng.integrations-rules.md`). Freelance → número de controle próprio.
+
+---
+
+## Pré-requisitos
+
+Antes de executar este workflow:
+
+1. O arquivo `architecture.md` **DEVE existir** em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/`
+2. Se não existir, peça ao usuário para executar o workflow `start` primeiro
+
+> 📁 **Padrão de pasta**: `{TASK_MANAGER_KEY}` é o ID do card em **lowercase** (ex: `TASK-123` → `task-123`)
+
+---
+
+## Fase 0.5: Comentário no card — Início
+
+Pular se `TASK_MANAGER` estiver vazio (freelance).
+
+Após confirmar que o `architecture.md` existe, registrar início do planejamento:
+
+```
+/eng-task-comment {TASK_MANAGER_KEY} 📋 [Jarvis] Iniciando criação do plano de execução
+```
+
+> Usa o skill `/eng-task-comment`. Não bloquear se falhar.
+
+---
+
+## Fluxo de Execução
+
+### Fase 0: Análise de Contexto (CDD)
+
+> 🎯 **Objetivo**: Adaptar a granularidade e rigor do plano com base no contexto.
+> ⚙️ **Configurável**: Esta fase é opcional e controlada pela variável `ENABLE_CDD` no ENV.md
+
+**Verificação de Ativação:**
+
+Antes de herdar o contexto, verifique se o CDD está habilitado:
+
+```bash
+grep "^ENABLE_CDD=" $IDE/ENV.md
+```
+
+- Se `ENABLE_CDD=false` ou não definida → **Pular esta fase** e usar comportamento padrão (Fase 1)
+- Se `ENABLE_CDD=true` → Herdar contexto normalmente
+
+Antes de criar o plano, herde o contexto da sessão (se CDD estiver habilitado):
+
+#### 0.1 Herdar Contexto da Sessão
+
+Leia o `CONTEXT_PROFILE` do arquivo `context.md` (gerado pelo `/context-detect`):
+
+```bash
+# Localização: $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/context.md
+```
+
+```
+CONTEXT_PROFILE:
+  tipo: [hotfix|bugfix|feature|refactor]
+  urgencia: [normal|alta|baixa]
+  rigor: [mínimo|padrão|alto]
+  comunicacao: [didático|direto|estratégico]
+  autonomia: [baixa|média|alta]
+```
+
+> Se `context.md` não existir, verifique o `architecture.md` ou execute `/context-detect {TASK_MANAGER_KEY}`
+
+#### 0.2 Calibração do Plano por Tipo
+
+| Tipo | Ajuste no Plano |
+|------|-----------------|
+| `hotfix` | 1-2 fases máximo, foco cirúrgico, skip de testes extensivos |
+| `bugfix` | 2-3 fases, incluir fase de teste que reproduz o bug |
+| `feature` | Fases completas (~1h cada), todas as validações |
+| `refactor` | Fase 0 obrigatória de testes antes de qualquer mudança |
+
+#### 0.3 Granularidade por POSITION
+
+| POSITION | Granularidade do Plano |
+|----------|------------------------|
+| `junior`, `pleno` | Mais detalhado, passos menores, mais checkpoints |
+| `senior`, `staff` | Fases maiores, menos micro-gerenciamento |
+| `tech-lead` | Visão estratégica, delegar detalhes |
+
+#### 0.4 Autonomia por MAX_AI_EXECUTION_PERCENTAGE
+
+| Valor | Comportamento no Planejamento |
+|-------|-------------------------------|
+| `>= 80%` | Criar plano completo, validar apenas no final |
+| `70-79%` | Apresentar outline, detalhar após aprovação |
+| `60-69%` | Apresentar cada fase para aprovação antes de detalhar |
+
+---
+
+### Fase 1: Leitura do Architecture
+
+1. **Ler** o arquivo `architecture.md` da sessão
+2. **Extrair** informações essenciais:
+   - Objetivo da feature
+   - Requisitos funcionais e não-funcionais
+   - Decisões arquiteturais
+   - Restrições técnicas
+
+### Fase 2: Pesquisa no Codebase
+
+1. **Buscar** arquivos relevantes usando:
+   - `repoprompt:search` para encontrar arquivos específicos
+   - `repoprompt:read_selected_files` para ler código em batch
+2. **Analisar**:
+   - Padrões existentes no projeto
+   - Arquivos que serão modificados
+   - Dependências técnicas
+
+3. **Pesquisar** (se necessário):
+   - WebSearch para melhores práticas
+   - context7 para documentação de bibliotecas
+
+### Fase 3: Criação do Plano
+
+1. **Dividir** o trabalho em **fases incrementais**:
+   - Cada fase deve levar ~1 hora (máximo)
+   - Cada fase deve ser testável independentemente
+   - Fases devem ser ordenadas por dependências
+
+2. **Detalhar** cada tarefa com:
+   - **O que fazer**: Descrição clara
+   - **Onde fazer**: Arquivo(s) envolvido(s)
+   - **Como fazer**: Abordagem técnica
+   - **Como verificar**: Critério de conclusão
+
+3. **Incluir tarefa de testes em CADA fase** (obrigatório):
+   - Cada fase DEVE ter uma tarefa `X.T Testes da Fase X`
+   - Basear nos requisitos definidos em `architecture.md` seção 6.5
+   - Especificar tipos de teste: unitário, integração, e2e
+   - Definir cobertura mínima esperada
+   - Listar o que será testado (funcionalidades da fase)
+
+4. **Usar** o template em `$IDE/templates/engineering/plan-template.md`
+
+### Fase 4: Validação
+
+1. **Apresentar** o plano ao humano
+2. **Discutir** ajustes necessários
+3. **Atualizar** `architecture.md` se houver mudanças arquiteturais
+4. **Confirmar** antes de prosseguir
+
+---
+
+## Saída Esperada
+
+Arquivo criado:
+
+```
+$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/plan.md
+```
+
+Com:
+
+- Fases numeradas e detalhadas
+- Tarefas específicas com critérios de conclusão
+- Dependências claras (sequencial/paralelo)
+- Status iniciais definidos (⏳)
+
+---
+
+## Comentário no card — Conclusão
+
+Pular se `TASK_MANAGER` estiver vazio (freelance).
+
+Após validação do plano com o usuário, registrar conclusão:
+
+```
+/eng-task-comment {TASK_MANAGER_KEY} ✅ [Jarvis] Plano de execução criado e validado - {N} fases definidas. Pronto para implementação.
+```
+
+## Próximo Passo
+
+Após a validação do plano com o humano, informar:
+
+> ✅ Plano criado e validado! Pronto para executar o workflow `work` e iniciar a implementação.
+
+---
+
+## Regras Importantes
+
+- ⚠️ **Consulte** as regras completas em `$IDE/rules/engineering/eng.plan-rules.md`
+- ⏱️ **Fases de ~1 hora** - Não criar fases maiores
+- 🔄 **Incremental** - Cada fase deve entregar valor testável
+- 🗣️ **Validar** - Sempre confirmar o plano com o humano antes de prosseguir

package/workflows/engineering/eng.pr.md

@@ -0,0 +1,466 @@
+---
+description: Criação de branch, commit e merge request (MR)
+auto_execution_mode: 3
+agent: "$IDE/agents/engineering/eng.agent.md"
+rules_file: "$IDE/rules/engineering/eng.pr-rules.md"
+template_file: "$IDE/templates/engineering/PR-template.md"
+recommended_model: claude-sonnet-4-20250514
+model_tier: medium
+model_justification: Operações Git e preenchimento de templates são tarefas estruturadas que não requerem raciocínio extremamente complexo
+---
+
+# Pull Request / Merge Request
+
+Este comando cria a **branch, commita as alterações e abre um Merge Request**.
+
+> 📋 **Rules**: `$IDE/rules/engineering/eng.pr-rules.md`
+> 📤 **Template**: `$IDE/templates/engineering/PR-template.md`
+
+## Skills recomendados
+
+- **pr**: siga o playbook do skill para padronizar branch, commits e MR.
+  - Arquivo: `$IDE/skills/eng-pr/SKILL.md`
+- **eng-qa-test-plan**: se precisar validar lacunas de testes antes de abrir o MR.
+  - Arquivo: `$IDE/skills/eng-qa-test-plan/SKILL.md`
+- **eng-qa-testsprite**: para executar testes automatizados E2E/API antes de abrir o MR.
+  - Arquivo: `$IDE/skills/eng-qa-testsprite/SKILL.md`
+- **eng-qa-e2e**: para validar fluxos de usuário críticos com testes E2E em linguagem natural antes de abrir o MR.
+  - Arquivo: `$IDE/skills/eng-qa-e2e/SKILL.md`
+- **eng-docs-write**: se houver necessidade de atualizar documentação junto do PR.
+  - Arquivo: `$IDE/skills/eng-docs-write/SKILL.md`
+- **eng-cybersecurity**: se o PR toca em auth, inputs, APIs públicas ou permissões — adicionar label `security` ao MR.
+  - Arquivo: `$IDE/skills/eng-cybersecurity/SKILL.md`
+
+## Agentes recomendados (opcional)
+
+- **eng.qa.test-planner**: para análise detalhada de cobertura antes do MR.
+  - Arquivo: `$IDE/agents/engineering/qa/eng.qa.test-planner.md`
+  - Quando usar: Se houver dúvidas sobre cobertura de testes ou mudanças significativas.
+
+---
+
+## Entrada
+
+<task_manager_key>
+#$ARGUMENTS
+</task_manager_key>
+
+Ler `TASK_MANAGER` do `$IDE/ENV.md`. Seguir `$IDE/rules/engineering/eng.integrations-rules.md`.
+
+**Se não receber argumentos**, perguntar e **aguardar**:
+
+- `TASK_MANAGER` vazio → *Qual o seu número de controle para esta tarefa? (ex: F-042)*
+- `TASK_MANAGER` preenchido → *Qual o id do card no {TASK_MANAGER}?*
+
+> A branch de destino **padrão é `dev`** (GitFlow). Só perguntar se o usuário indicar outra branch (ex: hotfix direto para `main`).
+> 💡 A branch de feature já foi criada no `eng.start`. Este workflow apenas faz push e abre o MR.
+
+---
+
+## Fase 0.5: Comentário no card — Início
+
+Pular se `TASK_MANAGER` estiver vazio (freelance).
+
+Registrar início da criação do MR:
+
+```
+/eng-task-comment {TASK_MANAGER_KEY} 🔀 [Jarvis] Iniciando criação do Merge Request para {TARGET_BRANCH}
+```
+
+> Usa o skill `/eng-task-comment`. Não bloquear se falhar.
+
+---
+
+## Fase 1: Validação Pré-PR
+
+### 1.1 Executar Testes Unitários
+
+```bash
+npm test  # ou comando do projeto
+```
+
+### 1.2 Verificar Lint
+
+```bash
+npm run lint  # ou comando do projeto
+```
+
+### 1.3 Verificar Build
+
+```bash
+npm run build  # ou comando do projeto
+```
+
+### 1.4 Executar Testes Automatizados (Opcional)
+
+Se o projeto estiver rodando localmente, execute o skill **eng-qa-testsprite** para validação completa:
+
+```
+/eng-qa-testsprite diff
+```
+
+Isso irá:
+
+- Gerar plano de testes para as mudanças recentes (diff)
+- Executar testes E2E (frontend) ou API (backend)
+- Gerar relatório em `testsprite_tests/`
+
+> **Observação**: o comportamento exato de "diff" pode variar (staged vs uncommitted). Se necessário, valide com o usuário qual estado do Git deve ser considerado antes de executar.
+
+> **Nota**: Este passo é opcional mas recomendado para mudanças significativas.
+
+**Se qualquer validação falhar:**
+→ Corrigir os problemas antes de prosseguir
+→ Informar o usuário sobre os erros
+
+---
+
+## Fase 2: Verificar Branch
+
+> 🌿 **GitFlow**: a branch foi criada no `eng.start` e os commits foram feitos pelo `eng.work`.
+> Esta fase apenas verifica que estamos na branch correta antes do push.
+
+### 2.1 Verificar Branch Ativa
+
+A branch de feature foi criada no `eng.start`. Verificar:
+
+```bash
+git branch --show-current
+```
+
+A branch deve seguir o padrão `{TASK_MANAGER_KEY}-{titulo-em-kebab-case}`.
+
+**Cenários:**
+
+| Situação | Ação |
+|----------|------|
+| Branch com `{TASK_MANAGER_KEY}` | ✅ Prosseguir |
+| Branch errada / `main` / `develop` | Fazer checkout na branch correta: `git checkout {TASK_MANAGER_KEY}-{titulo-kebab}` |
+
+### 2.2 Confirmar Branch de Destino
+
+Branch de destino padrão: **`dev`** (GitFlow).
+
+> ⚠️ **Nunca fazer push direto para `main` ou `master`** sem confirmação explícita do usuário.
+
+---
+
+**Se não estiver na branch correta:**
+
+```bash
+git checkout {TASK_MANAGER_KEY}-{titulo-em-kebab-case}
+```
+
+### 2.2 Verificar Commits da Branch
+
+```bash
+git log dev..HEAD --oneline
+```
+
+Deve listar os commits das fases implementadas no `eng.work`.
+
+**Se houver mudanças não commitadas** (ex: ajuste manual fora do `eng.work`):
+
+```bash
+# Adicionar arquivos individualmente (NUNCA git add .)
+git add {arquivo1} {arquivo2}
+git commit -m "{TASK_MANAGER_KEY} chore: ajustes pré-PR
+
+Refs: {TASK_MANAGER_KEY}"
+```
+
+---
+
+## Fase 3: Push
+
+### 3.1 Enviar para Remote
+
+```bash
+git push -u origin {NOME_DA_BRANCH}
+```
+
+**Verificar push:**
+
+```bash
+git log --oneline -3
+```
+
+---
+
+## Fase 4: Criar Merge Request / Pull Request
+
+Ler `VERSION_CONTROL` do `$IDE/ENV.md` (`gitlab` | `github` | `bitbucket`).
+Use **MR** se GitLab, **PR** se GitHub/Bitbucket.
+
+### 4.1 Preparar descrição
+
+Template, nesta ordem (o primeiro que existir):
+
+```bash
+cat $IDE/.gitlab/merge_request_templates/default.md 2>/dev/null \
+  || cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null \
+  || cat pull_request_template.md 2>/dev/null \
+  || cat $IDE/templates/engineering/PR-template.md
+```
+
+Preencher com a tarefa. Link do card:
+
+| TASK_MANAGER | URL |
+|--------------|-----|
+| jira | `{TASK_MANAGER_URL_BASE}/browse/{TASK_MANAGER_KEY}` |
+| linear | `{TASK_MANAGER_URL_BASE}/issue/{TASK_MANAGER_KEY}` |
+| github | `{TASK_MANAGER_URL_BASE}/issues/{TASK_MANAGER_KEY}` |
+| asana | `{TASK_MANAGER_URL_BASE}/0/0/{TASK_MANAGER_KEY}` |
+
+`{TASK_MANAGER_KEY}` = `{TASK_MANAGER_KEY}`.
+
+> ⚠️ Não mencione AI, Claude ou assistentes no MR/PR.
+
+### 4.2 Criar MR/PR via adapter
+
+- **Título**: `{TASK_MANAGER_KEY}: {Título da tarefa}`
+- **Branch origem**: `{NOME_DA_BRANCH}`
+- **Branch destino**: a informada pelo usuário (`dev` / `main` / hotfix)
+- **Descrição**: template preenchido, gravado em arquivo temporário
+
+```bash
+BODY_FILE=$(mktemp)
+# gravar a descrição preenchida em $BODY_FILE
+
+node bin/lib/vcs/create-merge.js \
+  --source "${NOME_DA_BRANCH}" \
+  --target "${TARGET_BRANCH}" \
+  --title "${TASK_MANAGER_KEY}: ${TITULO_DA_TAREFA}" \
+  --body-file "$BODY_FILE"
+
+rm -f "$BODY_FILE"
+```
+
+O adapter lê `git remote get-url origin` e `VERSION_CONTROL` / hostname (GitLab, GitHub, Bitbucket). Token: `.npmrc` (GitLab), `gh auth` / `GITHUB_TOKEN` (GitHub), `BITBUCKET_TOKEN` (Bitbucket).
+
+Se o script não estiver no repo alvo, usar o path do clone do framework Jarvis.
+
+**Erros comuns:**
+
+| Código | Causa | Solução |
+|--------|-------|---------|
+| `401 Unauthorized` | PAT ausente ou sem scope `api` | Gerar novo PAT com scope `api` em `~/.npmrc` |
+| `404 Not Found` | Namespace desatualizado no remote | `git remote set-url origin <nova-url>` |
+| `422` | Branch origem não existe no remote | Verificar se o push (Fase 3) foi executado |
+
+---
+
+## Fase 5: Comentário no card — Conclusão
+
+Pular se `TASK_MANAGER` estiver vazio (freelance).
+
+Após MR criado com sucesso, registrar:
+
+```
+/eng-task-comment {TASK_MANAGER_KEY} ✅ [Jarvis] MR criado: {TITULO_DO_MR} → {TARGET_BRANCH} | Link: {LINK_DO_MR}
+```
+
+---
+
+## Fase 6: Atualizar Board
+
+Pular se `TASK_MANAGER` estiver vazio (freelance).
+
+> Consultar `$IDE/rules/engineering/eng.downstream-flow-rules.md` para regras completas de transição.
+
+### 6.1 Mover Card
+
+De acordo com o fluxo downstream, após abertura do MR o **DEV** (`JUNIOR` / `PLENO` / `SENIOR` / `SPECIALIST`) move o card para **"Review de código"**.
+
+> O próximo passo (**Pronto para QA**) é responsabilidade do **TECH LEAD**, após merge ou revisão do MR.
+
+### 6.2 Adicionar Comentário
+
+Adicione um comentário no card com o link do MR:
+
+```
+MR aberto: {LINK_DO_MR}
+Branch: {NOME_DA_BRANCH}
+```
+
+---
+
+## Fase 6: Processar Code Review
+
+### 7.1 Aguardar Comentários
+
+Aguarde 3-5 minutos para a ferramenta de code review processar.
+
+### 7.2 Analisar Comentários
+
+Para cada comentário:
+
+1. Avaliar se requer correção
+2. Avaliar se pode ser explicado/ignorado
+3. Apresentar ao usuário
+
+### 7.3 Aplicar Correções
+
+Se necessário:
+
+```bash
+# Fazer mudanças
+git add {arquivos_alterados}
+git commit -m "fix: corrigir {problema} conforme code review"
+git push
+```
+
+---
+
+## Fase 7: Conclusão
+
+### 8.1 Registrar Métricas de Lead Time
+
+Calcule e registre o lead time (tempo desde eng.start até PR criado):
+
+```bash
+# Calcular lead time se .timestamp_start existir
+if [ -f $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/.timestamp_start ]; then
+  START_TIME=$(cat $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/.timestamp_start)
+  END_TIME=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
+
+  # Calcular diferença em minutos (macOS/Linux compatível)
+  if [[ "$OSTYPE" == "darwin"* ]]; then
+    # macOS
+    START_EPOCH=$(date -j -f "%Y-%m-%dT%H:%M:%SZ" "$START_TIME" +%s 2>/dev/null || echo 0)
+    END_EPOCH=$(date +%s)
+  else
+    # Linux
+    START_EPOCH=$(date -d "$START_TIME" +%s 2>/dev/null || echo 0)
+    END_EPOCH=$(date +%s)
+  fi
+
+  LEAD_TIME_MINUTOS=$(( (END_EPOCH - START_EPOCH) / 60 ))
+  LEAD_TIME_HORAS=$(awk "BEGIN {printf \"%.1f\", $LEAD_TIME_MINUTOS/60}")
+
+  echo "$LEAD_TIME_MINUTOS" > $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/.lead_time_minutes
+
+  LEAD_TIME_MSG="⏱️ Lead time: $LEAD_TIME_HORAS horas ($LEAD_TIME_MINUTOS minutos)"
+else
+  LEAD_TIME_MSG="⏱️ Lead time: não calculado (timestamp inicial ausente)"
+fi
+```
+
+### 8.2 Mensagem Final
+
+```
+✅ MERGE REQUEST CRIADO COM SUCESSO!
+
+📋 Resumo:
+- Branch: {NOME_DA_BRANCH}
+- MR: {LINK_DO_MR}
+- Jira: {TASK_MANAGER_KEY} → "In Review"
+
+📊 Validações:
+- Testes: ✅ Passando
+- Lint: ✅ OK
+- Build: ✅ OK
+
+{LEAD_TIME_MSG}
+
+📌 Próximos passos:
+1. Aguardar revisão do time
+2. Processar comentários do code review
+3. Merge após aprovação
+
+🔗 Links:
+- MR: {LINK_DO_MR}
+- Jira: {TASK_MANAGER_URL_BASE}/browse/{TASK_MANAGER_KEY}
+```
+
+## Fase 8: Limpeza da Sessão
+
+### 9.1 Solicitar Confirmação
+
+Após o MR ser criado com sucesso, **solicitar confirmação do usuário**:
+
+```
+🧹 Deseja limpar a sessão?
+
+A pasta $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/ será removida.
+A documentação permanece no Jira e no MR.
+
+Confirmar? (s/n)
+```
+
+> ⚠️ **IMPORTANTE**: Sempre pedir confirmação antes de executar comandos destrutivos.
+
+### 9.2 Remover Pasta da Sessão
+
+Se confirmado:
+
+```bash
+rm -rf $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
+```
+
+**Exemplo:**
+
+```bash
+rm -rf $SESSIONS_DIR/eng/task-123/
+```
+
+### 9.3 Confirmar Limpeza
+
+```
+🧹 SESSÃO LIMPA!
+
+📁 Removido: $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
+   - architecture.md ✅
+   - plan.md ✅
+   - context.md ✅ (se existia)
+
+ℹ️ A documentação permanece no:
+   - Card do Jira: {TASK_MANAGER_KEY}
+   - Merge Request: {LINK_DO_MR}
+```
+
+> ⚠️ **NOTA**: A documentação não é perdida! Ela está anexada no Jira e registrada no MR.
+
+---
+
+## Regras Importantes
+
+### ⛔ NÃO FAÇA
+
+- ❌ `git add .` (adiciona arquivos indesejados)
+- ❌ Push direto para `main`/`master`
+- ❌ Commit sem referenciar TASK_MANAGER_KEY
+- ❌ Branch sem padrão de nomenclatura
+- ❌ Mencionar AI/Claude no MR
+
+### ✅ FAÇA SEMPRE
+
+- ✅ Validar testes antes do commit
+- ✅ Adicionar arquivos específicos
+- ✅ Usar mensagem de commit padronizada
+- ✅ Criar branch no padrão `{TASK_MANAGER_KEY}-{titulo}`
+- ✅ Preencher template do MR completamente
+- ✅ Mover card para "In Review"
+- ✅ **Limpar sessão após criar MR** (`rm -rf $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/`)
+
+---
+
+## Tratamento de Erros
+
+### Se os testes falharem:
+
+→ Listar testes que falharam
+→ Sugerir correções
+→ NÃO prosseguir com o PR
+
+### Se já existir uma branch com o mesmo nome:
+
+→ Verificar se é a branch correta
+→ Se sim, fazer checkout nela
+→ Se não, perguntar ao usuário
+
+### Se o push falhar:
+
+→ Verificar se há conflitos
+→ Resolver conflitos se necessário
+→ Tentar push novamente