What the agent does
The agent reads the crate layout and how tests are already organised. In sharkdp/fd it opens Cargo.toml for the fd-find package: binary fd at src/main.rs, dependencies such as clap 4.6 with derive features, ignore, regex, aho-corasick, jiff, and optional clap_complete / jemalloc features. Dev-dependencies include tempfile, filetime, diff and test-case. Integration coverage lives mainly in tests/tests.rs with a testenv helper; unit-style modules under src/ include filter/size.rs, filter/time.rs and filter/owner.rs (each already embedding #[cfg(test)] modules), plus regex_helper.rs, sanitize.rs, filesystem.rs, walk.rs, exec/, fmt/ and output.rs.
It runs the suite with coverage via cargo llvm-cov when that is available in the sandbox, or cargo tarpaulin / RUSTFLAGS instrumentation otherwise, and ranks src/**/*.rs by missed lines. Candidates with real branching include sanitize.rs (needs_escape, write_sanitized for control and bidi characters), regex_helper.rs (pattern_has_uppercase_char, leading-dot detection), filter/size.rs parse edge cases not already in its inline tests, exec/command.rs / exec/job.rs, and hyperlink formatting in hyperlink.rs. Pure main.rs wiring stays low priority when logic is already extracted.
New tests prefer #[cfg(test)] modules inside the same file when that matches fd's filter modules, or new files under tests/ when the behaviour is integration-shaped (temp directories with tempfile, mtime with filetime). Cases use test-case where neighbouring tests do. They assert observable behaviour: sanitized escape sequences, size constraint parsing errors, regex smart-case decisions, not private struct layouts.
After the new tests pass under cargo test --all (and the crate's default features), the agent writes coverage before/after into the pull request description. Production code changes only for a bug the tests exposed, called out explicitly. Feature flags such as completions are exercised only when the thin file sits behind them. Cross-compilation targets in Cross.toml and release stripping in [profile.release] stay out of the test loop; the sandbox runs host cargo test only.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Run the test suite with coverage, pick the five least-covered files that hold real logic, and write Rust tests for them that exercise behaviour, not implementation details. Do not change production code unless a test reveals a bug; if it does, say so in the description. Open a pull request with the coverage before and after.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is a pull request on a new branch. In an fd-shaped crate it extends #[cfg(test)] modules or tests/tests.rs helpers, leaves src/main.rs alone unless a bug fix is required, and does not churn Cargo.lock except when a dev-dependency for coverage tooling must be added.
The description names the five files, the coverage tool used, and the before/after figures. The trajectory keeps cargo test and coverage command output, including any feature-flag combinations that were required for a thin module.
Before merging, a reviewer checks that filesystem tests use temporary directories, that sanitizer tests include representative Unicode edge cases, and that default feature builds stay green. Once merged, the existing CICD workflow runs the new tests on the same host targets the project already uses.
Run it on every release cut preparation
Before tagging a release, have your server send this request so the thinnest modules gain tests while the crate is still soft. Point resources at the release branch.
Handle run.completed through the API key webhook and attach the coverage delta to the release checklist. Keep concurrency low; coverage builds are heavier than plain cargo test.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Rust coverage tooling and integration tests that touch the filesystem are messy beside daily editing. On Rush the agent installs the coverage helper in its sandbox, runs the suite, adds focused tests next to fd's existing style, and opens a pull request that already passes cargo test.
The coverage delta on the pull request is the proof. The same job can harden several crates overnight, each with its own reviewable diff.
Frequently asked questions
Inline #[cfg(test)] or tests/ integration tests?
Follow the file. Filters in fd keep unit tests inline; broad CLI behaviour stays under tests/tests.rs with testenv. The agent does not invent a third harness.
Which coverage tool?
Whatever the sandbox can run cleanly with the crate — typically cargo llvm-cov when llvm tools are present. The pull request states which command produced the numbers.
Will it enable every Cargo feature?
Default features first (use-jemalloc, completions on fd). It enables optional features only when the uncovered file needs them, and says so in the description.
Does it benchmark or only test?
Only tests and coverage for this job. Benchmarks and Cross.toml targets stay out of scope. Performance numbers from the README are never invented or restated as if the sandbox measured them.