# Rust Harness Profile

Use these snippets when the target project is a Rust crate or Cargo workspace.

These files are agent reference material, not automatic transformations. Merge
only the pieces that fit the target project's existing tools.

Apply this profile by priority: always preserve the target crate or workspace
layout, generated file boundaries, and exact local check commands; document
database, auth, or external API setup when present; consider decision records
only when changing crate or workspace boundaries, persistence approach, auth
flow, async runtime choice, or external integration policy; use a short
report/check note for narrow fixes.

## Recommended Checks

- `cargo build` to verify the crate compiles. Use `cargo build --workspace`
  only when the target is already a Cargo workspace.
- `cargo test` for unit and integration tests. Add `cargo test --workspace`
  only when the target is a workspace.
- `cargo clippy --all-targets` when the Clippy component is available. Do not
  add `-D warnings` unless the target project already treats lints as errors
  (for example, in CI or a `clippy.toml`/lint policy). Do not install Clippy if
  the target deliberately omits it.
- `cargo fmt --check` only when the target project already commits a
  `rustfmt.toml` or uses formatting in its existing checks.
- `scripts/check_docs_drift.py` for stale documentation references.
- `scripts/check_structure.py` for temporary or drift-prone files.

## Generated Files

Rust projects often include code generated by a `build.rs` script or by tools
such as `prost`/`tonic` (Protocol Buffers), `bindgen`, `cxx`, or `sqlx`
offline query data. Build-time output normally lands under `target/` or
`OUT_DIR` and should not be committed. When generated code is committed
intentionally, treat it as source: do not edit it directly, and record the
generated paths and the regeneration command in `AGENTS.md` so agents know not
to hand-edit them.

If the target project has a code generation step, document the command in
`AGENTS.md` so agents can regenerate when the schema or interface changes.

## Suggested Check Script

Copy or adapt `check_harness.py` into the target repository's `scripts/`
directory when the project has no existing task runner. It runs `cargo build`,
`cargo test`, `cargo clippy` when the Clippy component is available, and the
generic drift checks. It does not assume a workspace layout.

## Profile Absorption Notes

When Rust is introduced after generic adoption:

- Merge relevant ignores from `gitignore.harness.txt`, especially the `target/`
  build directory and the local `harness-starter-kit/` clone.
- Copy or adapt `check_harness.py` into `scripts/` only when the target has no
  equivalent local verification command.
- Update `AGENTS.md` with the crate or workspace layout, module conventions,
  generated file paths, and completion checks.
- Update `docs/conventions/coding.md` with module boundaries, error handling
  approach (`Result`, error enums, `anyhow`/`thiserror` if already used),
  feature flag conventions, testing approach, and any project-specific patterns
  agents should repeat.
- Consider a decision record when changing or selecting the crate or workspace
  structure, persistence layer, auth approach, async runtime, external
  integration policy, or code generation tooling. When the task only follows
  the existing architecture or makes a narrow fix, a final report or check note
  is enough, and no ADR guidance needed.
- In the final report, list which snippets were adopted, adapted, skipped, or
  deferred.

## Rust Notes

- Keep `Cargo.toml` as source. Run `cargo update` to refresh `Cargo.lock`
  rather than editing it by hand.
- Commit `Cargo.lock` for binaries and applications. Libraries may omit it;
  follow the target project's existing policy instead of changing it.
- Do not commit the `target/` build directory or the local
  `harness-starter-kit/` clone.
- Prefer adding tests next to the code with `#[cfg(test)]` modules, and add
  integration tests in the conventional top-level `tests` directory only when
  the target already uses that layout.
- Use `cargo clippy` findings as guidance; do not apply broad automatic lint
  rewrites across unrelated modules.
- Add integration or end-to-end tests only when the target project already has
  a test database, container, or fixture setup in place.
