Files
guara/CONTRIBUTING.md
T
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.6 KiB

Contributing to Guará

English · Português

Thanks for helping! Golden rules:

  1. Never write to the source. Any code that opens a device must use source::open_path (read-only). PRs that write to the source disk are rejected.
  2. Test with real data. New detectors/readers need a test that recovers a known file bit for bit (see crates/guara-core/tests/ and scripts/make-fixtures.sh).
  3. Be honest about confidence. If the content cannot be validated, confidence is at most medium.
  4. 100% English codebase and comments. All source code, comments, scripts, CI workflows, and commit messages must be written in English, while the GUI/CLI remains bilingual (PT-BR and EN via i18n-en.js).

Workflow

scripts/install-hooks.sh  # once: enables commit-msg and pre-push Git hooks
scripts/check.sh          # fast (seconds): fmt, clippy as in CI, i18n, scripts, workflows, semver
scripts/check.sh --full   # includes cargo test --workspace and cargo audit

The CI takes 5 to 30 minutes on Linux, so run the check before pushing: almost everything that makes the CI fail shows up locally in seconds. Documentation-only changes (*.md, docs/) skip the CI.

On Linux the tests build images with mtools, ntfs-3g, e2fsprogs, exfatprogs, imagemagick, zip and python3. Without these tools the image tests are skipped (set GUARA_REQUIRE_FIXTURES=1 to make them fail).

For the external reference images (BitLocker, FileVault 2, dfvfs, AFF4), run scripts/fetch-testdata.sh; without them those tests are skipped. The BitLocker test takes about 75 s.

Releases and Versioning

Versions strictly follow Semantic Versioning 2.0.0 (MAJOR.MINOR.PATCH), synchronized across Cargo.toml, apps/gui/src-tauri/Cargo.toml, and apps/gui/src-tauri/tauri.conf.json (enforced by scripts/check.sh).

Pushing a v* tag makes the Gitea CI create the release (notes come from CHANGELOG.md, so update it first) and attach the Linux CLI (x86_64 and aarch64) and the desktop app for Linux (x86_64 and aarch64) and Windows.

There is no macOS build: it needs Apple's SDK and code signing, which a Linux runner cannot provide.

Where to make changes

A map of the modules is in docs/architecture.md. What is missing and what is welcome is in the ROADMAP.

Adding a file format

Simple detectors live in crates/guara-core/src/signatures.rs; the newer ones in formats.rs. Add the detector to detect, the first byte to might_start, the extension to category_for_ext/matches_ext and a real file to scripts/make-fixtures.sh with a bit-exactness test.

Adding a file system

Create the reader in crates/guara-core/src/fs/, register it in fs/mod.rs and bring a test with a real or reference image. We do not ship a reader without validation: that is why ReFS and Storage Spaces do not exist yet. Small images without personal data are the best gift you can give the project.

Documentation

The main version is in English and every file has a Portuguese translation (*.pt-BR.md, docs/pt-BR/). No em dashes or en dashes. When you change a feature, update both versions (English and Portuguese) of docs/support.md, the CHANGELOG and, if applicable, the ROADMAP.

Commits

Commits must follow Conventional Commits 1.0.0 in English (feat:, fix:, chore:, ci:, docs:, refactor:, test:, perf:, build:), e.g. fix(ntfs): handle sparse data runs correctly. One logical change per PR. Enforced automatically by .githooks/commit-msg.