Obrigado. Este arquivo existe porque o repo precisa ser reprodutível, fácil de revisar e fácil de estender.
Não envie uma mudança se você não conseguir rodar os comandos exatos de docs/HANDS_ON.md e não conseguir explicar como um novo contribuidor validaria sua alteração.
- Windows 10/11 com WSL 2 habilitado.
- Uma distribuição Linux instalada no WSL.
- Docker Desktop instalado no Windows com integração WSL ativada.
- Sua distro Linux precisa ter:
git,node,npm,curl. - Uma conta no GitHub.
Para melhor desempenho do Docker, evite usar caminhos sob /mnt/c/... diretamente.
wsl -d Ubuntu -e bash -lc "cd /mnt/d/milla/Documents/'Idea to MVP' && git clone <seu fork/worktree> . || true"Se você já clonou pelo Windows, tudo bem.
cp .env.example .envNunca adicione .env ao repo. Se vazar uma API key, assuma que está comprometida e rotacione antes de qualquer release pública.
bash scripts/setup_local_models.shEsse é o default recomendado. Ele instala o Ollama se faltar e puxa modelos locais baratos.
node scripts/validate_repo.js
node scripts/smoke_tools.jsSe qualquer comando falhar antes da sua mudança, pare e pergunte. Não some mudanças em cima de baseline quebrada.
Mantenha o patch pequeno. Prefira edições alvo a refactors amplos numa só PR.
- Ferramentas:
tools/flowise/ - Prompts:
flowise/prompts/ - Templates:
runtime/templates/ - Scripts:
scripts/ - Docs:
docs/
Escolha o comando que casa com sua alteração:
node scripts/validate_repo.js
node scripts/smoke_tools.js
node scripts/build_flowise_agentflow.jsUse Conventional Commits. Para este repo, os prefixos mais úteis são:
feat:novas funcionalidadesfix:correçõesdocs:mudanças apenas de documentaçãochore:manutenção
Depois, marque o release inicial v0.0.1.
git add README.md CONTRIBUTING.md docs/HANDS_ON.md
git commit -m "chore(v0.0.1): adiciona docs reprodutíveis para setup local e contribuição"
git tag v0.0.1git push origin master
git push origin v0.0.1Depois abra o PR e responda no texto:
- Qual problema?
- Quais comandos exatos você rodou?
- Quem consegue copiar suas anotações e reproduzir o mesmo resultado?
- Sem API keys, tokens ou senhas no código ou nos docs.
- Não exija APIs pagas para desenvolvimento local.
- Não mude comportamento externo sem atualizar docs, prompts ou exemplos na mesma mudança.
- Não misture documentação falsa com guia de código; cada arquivo tem um dono conceitual.
Bugs e perguntas de reprodução vão em Issues. PRs devem ser tão simples de reproduzir que um novo contribuidor copia,cola e passa de primeira.