Skip to content

Latest commit

 

History

History
111 lines (74 loc) · 3.06 KB

File metadata and controls

111 lines (74 loc) · 3.06 KB

Contribuindo com o Code House

Obrigado. Este arquivo existe porque o repo precisa ser reprodutível, fácil de revisar e fácil de estender.

Regra central: só contribua se for reprodutível

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.

Pré-requisitos

  • 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.

1. Abra o repo no WSL

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.

2. Copie env e nunca comite segredos

cp .env.example .env

Nunca adicione .env ao repo. Se vazar uma API key, assuma que está comprometida e rotacione antes de qualquer release pública.

3. Configure modelos locais

bash scripts/setup_local_models.sh

Esse é o default recomendado. Ele instala o Ollama se faltar e puxa modelos locais baratos.

4. Valide antes de editar

node scripts/validate_repo.js
node scripts/smoke_tools.js

Se qualquer comando falhar antes da sua mudança, pare e pergunte. Não some mudanças em cima de baseline quebrada.

5. Faça uma mudança pequena

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/

6. Verifique sua mudança

Escolha o comando que casa com sua alteração:

node scripts/validate_repo.js
node scripts/smoke_tools.js
node scripts/build_flowise_agentflow.js

7. Commit e tag com significado

Use Conventional Commits. Para este repo, os prefixos mais úteis são:

  • feat: novas funcionalidades
  • fix: correções
  • docs: mudanças apenas de documentação
  • chore: 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.1

8. Push e abra PR

git push origin master
git push origin v0.0.1

Depois 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?

Regras duras

  • 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.

Dúvidas?

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.