What the agent does
The agent picks pure entry points with round-trip potential. In rust-lang/mdBook the workspace (edition = "2024", rust-version = "1.88.0") splits crates under crates/; mdbook-summary exposes parse_summary in crates/mdbook-summary/src/lib.rs building a Summary with prefix, numbered and suffix chapters; mdbook-core holds Config parsing from TOML in crates/mdbook-core/src/config.rs and path helpers such as path_to_root in utils/fs.rs. There is no proptest dependency in the workspace Cargo.toml today.
It adds proptest as a dev-dependency on the crate under test (for example mdbook-summary) and writes #[proptest] tests beside unit tests or under tests/. Strategies generate SUMMARY.md-like markdown (headings, linked chapters, separators, nested lists) and assert: successful parses produce structures that respect prefix-before-numbered ordering; clearly invalid nesting returns Err; lossless properties hold only where the parser documents them (the module comments describe ignored titles and unsupported elements). For config, round-trip TOML through Config where serde allows.
Runs use a raised ProptestConfig::cases (or PROPTEST_CASES) so thousands of inputs exercise the parser in the sandbox. On failure the agent keeps the shrunk INPUT in the test output / pull request and does not edit parse_summary or other production functions to silence the property.
It runs cargo test -p mdbook-summary (and any other package it extended) with the workspace's pinned Rust version, fixes strategy bugs only, and opens a pull request adding proptest tests and Cargo.dev-dependencies. When generating SUMMARY.md-like input it mirrors the grammar in the mdbook-summary module docs: optional # Summary title, prefix links, # Part titles, nested - [name](path.md) lists, horizontal rules as separators, and suffix links after numbered chapters. Strategies shrink toward the smallest markdown that still violates an invariant, which is what maintainers need when parse_summary returns Ok for a structure the docs call unsupported.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Write property-based tests with proptest for the core parsing and transformation functions of this library: round trips, idempotence and invariants. Run them with a high example count. Open a pull request; if a property fails, include the shrunk counterexample and do not change the library.",
"resources": [
{
"url": "https://github.com/your-org/your-rust-lib"
}
]
}- 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 that adds proptest cases to the chosen crate(s) and pins proptest in that crate's Cargo.toml. Production parsers stay unchanged when a counterexample appears; the shrunk markdown or TOML is quoted for maintainers.
The pull request description names the cargo test -p … command, the case count, and pass/fail per property. The trajectory includes proptest's shrinking log when a failure is intentional evidence.
Before merging, a reviewer checks that strategies match the SUMMARY.md grammar described in mdbook-summary's module docs, that flaky over-broad strategies were not papered over with filter that hides bugs, and that CI's Rust version matches rust-version = "1.88.0".
Run it on every summary or config parser changed
When pulls touch crates/mdbook-summary/** or crates/mdbook-core/src/config.rs, POST this session body so proptest re-runs at high case counts before merge, in a sandbox with the workspace MSRV toolchain.
Notify via the API key webhook on run.completed / run.failed with the session URL. Treat a new counterexample as a bug report against the parser, not an automatic production patch.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
proptest at thousands of cases compiles and runs heavier than ordinary unit tests, especially across a workspace. Rush builds with the repo's Rust 1.88 toolchain in an isolated sandbox so your machine is free for other crates. Workspace members listed in the root Cargo.toml (crates/*) keep sharing workspace.dependencies, so the proptest pin stays local to the crate under test instead of forcing every member to compile it.
Failing closed on library changes when a property fails gives you a minimal SUMMARY.md counterexample in the pull request and the full cargo test log in the trajectory—the evidence maintainers need without noise from drive-by parser rewrites.
Frequently asked questions
Will it modify parse_summary if a property fails?
No. The job records the shrunk input and leaves production code alone. Fixing the parser is a separate, deliberate change.
Which crate gets the tests?
The ones with clear pure parsers—primarily mdbook-summary for parse_summary, optionally mdbook-core for Config. The agent does not spray proptest across GUI or CLI crates without invariants.
Does this replace the existing testsuite?
No. Integration coverage under tests/ and crate unit tests remain. proptest adds randomised exploration on top.
What Rust edition and MSRV?
mdBook's workspace uses edition 2024 and rust-version = "1.88.0". The sandbox installs that toolchain (or newer compatible) before cargo test.