how to contribute

How to contribute

Start with the project boundaries in Architecture and the local conventions in Patterns and conventions. CSV Anonymizer keeps anonymization behavior in crates/csv-anonymizer-core, desktop access in src-tauri, and interaction state in frontend/src.

Work pickup

1. Identify the owning layer before editing:
   • Product detection, preview, transformation, direct-input behavior, reports, and DTOs belong in crates/csv-anonymizer-core.
   • Tauri commands, settings persistence, path grants, file dialogs, job state, and Ollama integration belong in src-tauri.
   • UI state, workflow panels, command wrappers, frontend types, and styles belong in frontend/src.
   • Release, smoke, audit, package, and contract checks belong in scripts, package.json, frontend/package.json, and .github/workflows.
2. Read the closest tests or scripts before changing behavior.
3. Keep changes focused. Do not mix feature work, dependency upgrades, and release metadata unless the task explicitly asks for that combination.
4. Treat dist, build release outputs, target, frontend/dist, and model/runtime caches as generated or environment-specific unless a release task says otherwise.

Branch and code expectations

• Branch from main and use a focused branch name that matches the work area, for example fix/local-ai-status or docs/release-flow.
• Match existing Rust, TypeScript, CSS, shell, JavaScript, and Python style in nearby files.
• Keep Tauri commands thin. They should authorize desktop access, offload blocking work, and call the Rust core.
• Keep frontend calls routed through frontend/src/tauri.ts.
• When changing DTOs, update both crates/csv-anonymizer-core/src/types.rs and frontend/src/types.ts, then run the contract check.
• Do not commit secrets, local signing material, downloaded model files, Ollama caches, or llama-server binaries.

Definition of done

A change is done when:

• The intended behavior is implemented in the owning layer.
• Tests cover new detector behavior, command behavior, UI behavior, or release script behavior where practical.
• Manual DTO mirrors still pass npm run contracts:check.
• Scoped checks passed during iteration.
• The relevant full gates from Testing passed before opening or updating a PR.
• Privacy-sensitive changes preserve path grants, formula neutralization, Local AI validation, and report evidence.

PR expectations

PRs should include:

• A concise summary of the user-facing or maintenance reason for the change.
• The checks that were run, with command names.
• Notes about any intentionally skipped platform checks, for example Linux package validation on a macOS-only machine.
• Screenshots only when the UI changed.
• No unrelated formatting, version, or release artifact churn.

See Development workflow, Testing, Debugging, and Tooling for the day-to-day command set.