# Contribuindo

## Workflow

1. Branch a partir de `master`: `git checkout -b <tipo>/<descrição>`
   - `feat/` — feature nova
   - `fix/` — bugfix
   - `refactor/` — refactor sem mudança de comportamento
   - `docs/` — só documentação
   - `chore/` — config, build, CI
2. Commits pequenos, foco único
3. Antes de abrir PR: `npm run format && npm test && npm run build`
4. Abrir PR descrevendo o porquê (não o quê — o diff mostra o quê)

## Mensagens de commit

- Inglês, imperativo (alinhado com o upstream)
- Primeira linha curta (~72 caracteres), inicia com letra maiúscula
- Corpo opcional em lista com `- ` detalhando o porquê

Exemplo:

```
Add WebDAV retry on 429/503

- new retryWithBackoff helper in src/fsWebdav.ts
- apply to walk/stat/writeFile methods
- based on upstream PR #1034
```

## Cherry-pick de PRs do upstream

Upstream: https://github.com/remotely-save/remotely-save

```bash
git remote add upstream https://github.com/remotely-save/remotely-save.git
git fetch upstream pull/<N>/head:pr-<N>
git cherry-pick <commits-de-pr-N>
```

Citar o PR upstream na mensagem de commit (`baseado no PR upstream #<N>`).

## Estilo de código

- Biome formata e linta (`npm run format`)
- TypeScript strict — evitar `any`
- Funções idealmente 4–20 linhas; refatorar se passar
- Nomes específicos, não `data`/`handler`/`Manager`
- Sem comentários óbvios — explicar só o porquê quando não-trivial
- Early returns (no máximo 2 níveis de aninhamento)

## Testes

- Toda feature ou bugfix inclui teste
- Cobertura mínima do core: a definir (atualmente sem threshold)
- Localização: `tests/` para src/, `pro/tests/` para pro/