dokime-xtask

Responsibility: repository automation requiring Rust-aware workspace logic. This unpublished crate is build-time tooling and is not installed with Dokime.

Command Surface

Use the named mise tasks: they supply pinned tools, environment, and prerequisites.

xtask command	Responsibility	mise entrypoint
api-bench	Probe a running native gRPC runtime shell against latency budgets	cargo run --locked -p dokime-xtask -- api-bench directly
brand apply, brand check	Materialize or verify branding artifacts and icon hashes	brand:apply, brand:check
plugins build	Build the first-party plugin packages, built to validate the plugin build system, and every fixture bundle the test suites need	build:plugins:dev
tauri prepare-resources	Stage desktop branding and the companion dokime CLI	tauri:resources:release/tauri:resources:dev (hidden; invoked by Tauri’s own beforeBuildCommand, not run by hand)
tauri package	Verify collected desktop release artifacts	the Windows step of installer:release
tauri installer prepare, collect, check	Build or validate installer prerequisites	installer:release, installer:dev, installer:check
version print, dev	Print or stamp a development version	cargo run -p dokime-xtask -- version print/dev directly
version check, sync	Validate or refresh committed version metadata	version:check, version:sync
version release prepare, release finalize	Stamp and tag a release	node tools/node/release.mjs directly

Ownership

src/commands/ mirrors the command tree. Each leaf owns its arguments and execution; group modules compose their children. main.rs parses before setup, and error.rs owns the exit-code mapping, including native benchmark budget exit code 2.

The task runner does not link the application runtime. Native theme and binding exports run small entrypoints in their owning crates only when requested. Desktop binding exports and native checks omit installer resources through a scoped Tauri configuration; packaging still stages and validates its complete payload.

The root tools/ hierarchy separates Python environment and wheel handling, Node process supervision, and Rust automation. The xtask crate lives at tools/rust/dokime-xtask. GUI report assets and Vite helpers live in tools/node/gui/ and use the GUI package’s Node dependencies. Docs generation remains Node-only, so the docs pipeline does not acquire a Rust build prerequisite.

Installer and version-release workflows use Node process supervisors launched by mise. Each Rust preparation command exits before builds or validation begin, so Cargo can rebuild xtask without replacing a running Windows executable. Installer collection and release finalization run only after the preceding commands succeed. Tauri build hooks generate embedded frontend assets and stage branding and the dokime CLI host for direct Tauri builds. The installer places the CLI beside the GUI as a Tauri external binary and adds it to the Windows user PATH through an NSIS installer hook; it bundles no duplicate backend-hosted frontend. Plugin preparation uses a development packager executable without shipping it. Version release preparation records the selected version and checkout in a temporary plan; finalization checks that plan before committing and tagging. Version stamping keeps the tracked lockfile in step, so release validation does not rewrite tracked dependency versions. Validation runs the existing check and test aggregates once. Neither supervisor pushes changes.

mise run test covers process orchestration and xtask unit tests (part of the full workspace run) and Python script tests; mise run test:gui covers GUI and report-helper tests.