RFC: Dev tooling approach — cargo-first vs pre-commit-first for docs/scripts checks

[niStee]

Context

In PR #1313, we explored adding docs/tooling configs (markdownlint, dprint, lychee, typos).
@GideonBear asked for a narrower scope—avoiding content churn (e.g., locales and OS-release)—and preferred pre-commit/pre-commit-ci over GitHub Actions for docs/lint.
The PR was closed with a request to realign. This RFC proposes two concrete approaches and asks maintainers to choose.

Goals and Constraints

• Keep Rust formatting via rustfmt as the single source of truth
• Avoid automated edits to sensitive content (locales, OS-release fingerprints)
• Keep contributor workflow simple and fast across platforms (Windows included)
• Minimize ecosystem sprawl and CI noise

---

🅰️ Option A — cargo-first (single entrypoint, fast, reproducible)

Orchestrate checks via cargo (xtask or cargo-make):

• Rust: fmt (rustfmt), clippy, cargo-deny
• Docs/Text: typos (spelling), lychee (links), dprint (Markdown)
• Scripts: ShellCheck

CI: One job calls the same cargo tasks; lychee also runs on a weekly schedule.
Conservative excludes for translations and OS-release files to prevent false positives.

Why: Single toolchain, Rust-native CLIs are fast, cross-platform, reproducible, and caching is straightforward.

---

🅱️ Option B — Align with @GideonBear (pre-commit-first, minimal scope)

• Keep rustfmt/clippy for Rust
• Use pre-commit/pre-commit-ci for typos and ShellCheck
• Omit markdownlint/dprint unless explicitly requested
• Maintain .typos.toml with excludes for locales/** and src/steps/os/os_release/**
• No changes to PR templates, CODEOWNERS, .editorconfig, .gitattributes, or workflows

---

🗳️ Decision Request

Please choose Option A or Option B (or share constraints to refine).
👉 Vote in the poll

If Option A: I’ll open a small PR adding xtask/cargo-make and one CI job calling those tasks.
If Option B: I’ll keep the minimal pre-commit setup (typos + ShellCheck) with conservative excludes and no CI/workflow/template changes.