Files
guara/CONTRIBUTING.pt-BR.md
Lucas RayanandClaude Sonnet 5 76e4466652 feat(update): unify the updater with Sabiá's Gitea-based mechanism
Replaces the signed tauri-plugin-updater (latest.json manifest, minisign
key pair) with the same simple mechanism Sabiá already uses: query the
Gitea Releases API directly, download the matching platform archive,
verify its SHA-256 checksum, and swap the binary in place. The CI job
that built the old latest.json manifest is removed in the next commit,
alongside an unrelated runner-routing change to the same workflow file.

- New guara-core::update module (check/apply), ported from
  sabia-core::update and adapted to Guará's own release asset naming
  (guara-<tag>-<platform>.tar.gz, matching scripts/package-cli.sh).
- New Engine::update_check / Engine::update_apply, wired into the RPC
  service for the browser UI.
- New CLI subcommand: "guara update" (check) and "guara update --apply"
  (download, verify, replace), mirroring "sabia update".
- GUI: replaced the Tauri plugin-updater flow (download_and_install,
  update-progress events, in-app restart) with a call to the new
  update_check/update_apply commands. The desktop app can no longer
  self-install in one click — it now points the user to the Releases
  page, same as Sabiá's desktop app already does.
- Removed tauri-plugin-updater, createUpdaterArtifacts and the
  updater.pubkey config, the signing-key loading in build-gui.sh, the
  CI step testing the old latest.json generator, and the now-unused
  make-latest-json.py/test_make_latest_json.py scripts.
- Documented the break for existing installs in CHANGELOG.md /
  CHANGELOG.pt-BR.md: versions up to 1.3.2 won't find this release
  automatically and need one manual download.

Trade-off accepted knowingly: SHA-256 verifies integrity against
Gitea's own API but, unlike the retired signed mechanism, does not
protect against a compromised Gitea server independently of it. This
is Lucas's own self-hosted instance, not a third-party mirror.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAyr8d7HuAdUGB6aA5xmDD
2026-10-30 22:03:28 -03:00

3.7 KiB

Contribuindo com o Guará

English · Português

Obrigado por ajudar! Regras de ouro:

  1. Nunca escreva na origem. Qualquer código que abra um dispositivo deve usar source::open_path (somente leitura). PRs que escrevem no disco de origem são recusados.
  2. Teste com dados reais. Novos detectores/leitores precisam de teste que recupera um arquivo conhecido bit a bit (veja crates/guara-core/tests/ e scripts/make-fixtures.sh).
  3. Seja honesto sobre confiança. Se o conteúdo não puder ser validado, a confiança é no máximo média.
  4. Código, comentários e commits 100% em inglês. Todo código-fonte, comentários, scripts, workflows de CI e mensagens de commit devem ser escritos em inglês, enquanto a interface gráfica/CLI permanece bilíngue (PT-BR e EN via i18n-en.js).

Fluxo

scripts/install-hooks.sh  # uma vez: ativa os hooks commit-msg e pre-push
scripts/check.sh          # rápido (segundos): fmt, clippy como no CI, tradução, scripts, workflows, semver
scripts/check.sh --full   # inclui cargo test --workspace e cargo audit

O CI leva de 5 a 30 minutos em Linux, então rode a verificação antes do push: quase tudo que faz o CI falhar aparece aqui em segundos. Mudanças só de documentação (*.md, docs/) pulam o CI.

No Linux os testes geram imagens com mtools, ntfs-3g, e2fsprogs, exfatprogs, imagemagick, zip e python3. Sem essas ferramentas os testes com imagem são ignorados (defina GUARA_REQUIRE_FIXTURES=1 para falhar).

Para as imagens de referência externas (BitLocker, FileVault 2, dfvfs, AFF4), rode scripts/fetch-testdata.sh; sem elas esses testes são pulados. O teste de BitLocker leva cerca de 75 s.

Releases e Versionamento

As versões seguem estritamente o Versionamento Semântico 2.0.0 (MAJOR.MINOR.PATCH), sincronizadas entre Cargo.toml, apps/gui/src-tauri/Cargo.toml e apps/gui/src-tauri/tauri.conf.json (validado por scripts/check.sh).

Enviar uma tag v* faz o CI do Gitea criar a release (as notas vêm do CHANGELOG.md, então atualize-o antes) e anexar o CLI para Linux (x86_64 e aarch64) e o app desktop para Linux (x86_64 e aarch64) e Windows.

Não há build para macOS: ele exige o SDK e a assinatura da Apple, que um runner Linux não tem.

Onde mexer

Mapa dos módulos em docs/pt-BR/arquitetura.md. O que falta e o que é bem-vindo está no ROADMAP.

Adicionando um formato de arquivo

Detectores simples ficam em crates/guara-core/src/signatures.rs; os mais novos, em formats.rs. Acrescente o detector em detect, o primeiro byte em might_start, a extensão em category_for_ext/matches_ext e um arquivo real ao scripts/make-fixtures.sh com teste de bit-exatidão.

Adicionando um sistema de arquivos

Crie o leitor em crates/guara-core/src/fs/, registre-o em fs/mod.rs e traga um teste com imagem real ou de referência. Não entregamos leitor sem validação: é por isso que ReFS e Storage Spaces ainda não existem. Imagens pequenas e sem dados pessoais são o melhor presente que se pode dar ao projeto.

Documentação

A versão principal é em inglês e cada arquivo tem uma tradução em português (*.pt-BR.md, docs/pt-BR/). Sem travessões. Ao mudar um recurso, atualize as duas versões (inglês e português) de docs/support.md, do CHANGELOG e, se for o caso, do ROADMAP.

Commits

Os commits devem seguir Conventional Commits 1.0.0 em inglês (feat:, fix:, chore:, ci:, docs:, refactor:, test:, perf:, build:), ex.: fix(ntfs): handle sparse data runs correctly. Uma mudança lógica por PR. Validado automaticamente por .githooks/commit-msg.