rent doctor

Use rent doctor after adding Rent to a crate, changing project paths, or diagnosing generation and migration setup. It checks configuration, Cargo metadata, schema parsing, generated-client currency, whether the crate declares that client, which crate owns it, and migration checksums.

Check the local project

rent doctor

Rent Doctor

Ready    Configuration  ./rent.toml
Ready    Cargo project
Ready    Schema         1 entity
Ready    Client         generated and current
Ready    Module         declared in the crate root
Ready    Layout         generated client in its own crate, social-app-db
Ready    Migrations     no migration history yet
Ready    Database       sqlite connection verified

Healthy: Rent project is healthy.

What each row proves

Configuration names the file in force. A project without rent.toml runs on built-in defaults, and the row says so rather than naming a file that does not exist:

Absent   Configuration  built-in defaults; no ./rent.toml

Client compares the schema fingerprint recorded at generation against the schema on disk, so a client generated from an older schema is reported instead of being taken on trust:

Stale    Client         generated from a different schema

Module checks that the crate root declares the generated client. It resolves the declaration's #[path] relative to the crate source file, including a module alias and parent-relative crate configuration. A path or formatting attribute on a different module does not satisfy this check. A client the crate never declares cannot be used, and no other check observes that:

Absent   Module         not declared in the crate root

It also checks that the declaration carries #[rustfmt::skip]. Without it, cargo fmt rewrites the generated client into your style and cargo fmt --check reports it:

Absent   Module         declared, but without #[rustfmt::skip]

Layout names the crate that owns the generated client. A client inside the application crate is fine for a small schema. Once the schema has twenty or more models the row comes with an action, because every edit to the application then recompiles the client:

Ready    Layout         generated client inside the application crate

Action move the generated client to its own crate with `rent init --crate` so an edit to the application
       never recompiles it; at 200 models an incremental build takes about 10s inline and under 1s in its
       own crate

Permission fixtures appears only when the schema opts into access. Doctor looks for *.permissions.toml next to the configured schema file, or inside the configured schema directory:

Absent   Permission fixtures  none next to ./rent/schema.rsl

Action add permission fixtures matching `./rent/*.permissions.toml` and run them in your test suite

With fixtures present, it reports their count:

Found    Permission fixtures  2 file(s); presence checked, tests not run

This checks file presence only. It does not parse fixtures, execute permission checks, or certify tenant isolation. Run your permission tests separately. Ordinary schemas without access need no permission fixtures and receive no warning.

Database is verified only when the project actually configures a URL, through --database-url, the variable named by url_env, or the project-root .env. With none of those set the check is skipped rather than connecting to an invented local database:

Skipped  Database       set DATABASE_URL in .env to verify the connection

Include the database

For server projects, keep the live database URL in the project-root .env:

rent doctor

Rent Doctor

Ready    Configuration  ./rent.toml
Ready    Cargo project
Ready    Schema         3 entities
Ready    Client         generated and current
Ready    Module         declared in the crate root
Ready    Layout         generated client in its own crate, social-app-db
Ready    Migrations     2 verified
Ready    Database       postgres connection verified

Healthy: Rent project is healthy.

Exit behavior

The command exits unsuccessfully at the first invalid boundary and includes the failing file or operation in its error.

Findings that leave a project usable but incomplete, such as an absent configuration, a stale client, or an undeclared module, are reported as actions rather than failures. The closing line then lists what to do instead of declaring the project healthy, so a green summary always means every check passed.

The command never writes to the database and never creates one.