/salvar

Versiona e envia o trabalho ao GitHub, criando o repositório privado na primeira vez. Use com “salvar”, “salva no github”, “commit”, “push”, pedido de backup ou /salvar.

Como funciona

O que lê

• Estado do repositório git local (git status, git remote -v)
• Identidade global do git (nome/email)
• Ferramenta gh (opcional, para criar o repositório remoto)

Passos

1. Verificar se a pasta já é um repositório git (git rev-parse --is-inside-work-tree); se não for, rodar git init.
2. Verificar se a identidade git (nome/email) está configurada; se não, perguntar UMA vez e configurar.
3. Verificar se existe remoto origin.
4. Sem remoto: perguntar se já existe um repositório remoto (pedir a URL) ou se deve ser criado agora.
5. Se for para criar: com gh disponível, rodar gh repo create <nome> --private --source=. --remote=origin e garantir que o remoto fica em HTTPS (git remote set-url origin https://github.com/<owner>/<nome>.git se necessário).
6. Sem gh disponível: instruir o usuário a instalar a ferramenta ou criar o repositório manualmente no GitHub e colar a URL.
7. Confirmar que .env, .env.dev e .env.local estão no .gitignore; se não estiverem, adicionar antes de qualquer commit.
8. Verificar mudanças pendentes (git status -sb); se não houver nenhuma, informar que está tudo sincronizado e encerrar.
9. Mostrar o status resumido e perguntar se o usuário quer descrever a mudança numa frase ou usar mensagem gerada automaticamente.
10. git add só dos arquivos de trabalho alterados (nunca .env/.env.*, nunca git add -A/git add . cego).
11. Gerar mensagem de commit conventional (feat|fix|chore|docs|refactor: <resumo>) a partir dos arquivos alterados, quando o usuário não fornecer uma.
12. Commitar e enviar ao remoto (git push -u origin <branch> na primeira vez, git push depois).
13. Se o push falhar por divergência com o remoto, avisar e oferecer git pull --ff-only antes de tentar de novo — nunca sobrescrever.
14. Confirmar a sincronização com git status -sb e mostrar o link do repositório.

O que grava e onde

• Não gera arquivos de conteúdo — atua sobre o próprio repositório git (init, commits, push, .gitignore quando necessário).

Pontos de aprovação

• Force push ou reescrita de histórico: só com pedido explícito do usuário.
• Mensagem de commit: usuário escolhe descrever ou aceitar a gerada automaticamente.

Falha cedo

• Identidade git ausente: perguntar UMA vez nome/email e configurar antes de qualquer commit.
• gh ausente e usuário quer criar repositório novo: parar e instruir instalação (gh desbloquearia criação automática do remoto) ou criação manual com URL colada.
• .env/.env.* fora do .gitignore: corrigir o .gitignore antes de prosseguir, nunca commitar segredo.
• Divergência com o remoto no push: nunca forçar — avisar e propor pull --ff-only.

Verificação final

git status -sb mostra a branch local sincronizada com origin (sem ahead/behind) e o commit aparece em git log -1 --oneline — confirmar antes de anunciar sucesso ao usuário.