docs: refresh the CLAUDE.md crate list and conventions #45

Merged

longjacksonle merged 1 commit from docs/DUNITE-crate-list-refresh into main

2026-08-12 04:11:22 +02:00

longjacksonle commented

2026-08-12 04:07:51 +02:00

Owner

The crate list in CLAUDE.md had drifted five crates behind the workspace. dunite-stripe, dunite-stripe-core, dunite-user-core, dunite-feedback and dunite-image-upload were all missing, so the file described a ten-crate workspace that actually holds fifteen.

Changes

Adds the five missing crates with their scope and dependency edge.
Rewrites the dependency-direction paragraph to state the rule - everything is a leaf except dunite-download / dunite-oci / dunite-oidc on dunite-core, and dunite-stripe on dunite-stripe-core - instead of enumerating leaves by name, which is the sentence that went stale. Records the corollary the newer crates already follow: a leaf owns its error type rather than returning dunite_core::AppError, since returning it would pull every consumer onto one dunite-core revision (ImageValidationError, StripeServiceError).
Two conventions learned from DUNITE-10 through DUNITE-12: a crate that talks to a fixed upstream takes the host as a constructor argument so tests can point it at wiremock (StripeService::with_api_base, not a StripeConfig field, because consumers build those by struct literal); and a third-party error's free-text message is never logged or returned when the upstream embeds customer data in it (redacted_stripe_error + StripeErrorDetails, matched exhaustively so a new upstream variant is a compile error rather than a silent leak).

Verified every directory under crates/ now appears in the file, and nothing appears that is not a directory.

Docs only; no code touched.

The crate list in `CLAUDE.md` had drifted five crates behind the workspace. `dunite-stripe`, `dunite-stripe-core`, `dunite-user-core`, `dunite-feedback` and `dunite-image-upload` were all missing, so the file described a ten-crate workspace that actually holds fifteen. ## Changes - Adds the five missing crates with their scope and dependency edge. - Rewrites the dependency-direction paragraph to state the rule - everything is a leaf except `dunite-download` / `dunite-oci` / `dunite-oidc` on `dunite-core`, and `dunite-stripe` on `dunite-stripe-core` - instead of enumerating leaves by name, which is the sentence that went stale. Records the corollary the newer crates already follow: a leaf owns its error type rather than returning `dunite_core::AppError`, since returning it would pull every consumer onto one `dunite-core` revision (`ImageValidationError`, `StripeServiceError`). - Two conventions learned from DUNITE-10 through DUNITE-12: a crate that talks to a fixed upstream takes the host as a constructor argument so tests can point it at wiremock (`StripeService::with_api_base`, not a `StripeConfig` field, because consumers build those by struct literal); and a third-party error's free-text message is never logged or returned when the upstream embeds customer data in it (`redacted_stripe_error` + `StripeErrorDetails`, matched exhaustively so a new upstream variant is a compile error rather than a silent leak). Verified every directory under `crates/` now appears in the file, and nothing appears that is not a directory. Docs only; no code touched.

longjacksonle added 1 commit

2026-08-12 04:07:51 +02:00

docs: refresh the CLAUDE.md crate list and conventions

Check / fmt + clippy + test (pull_request) Successful in 48s

Details

create-release / create-release (pull_request) Has been skipped

Details

6e629697e9

The crate list had drifted five crates behind the workspace: `dunite-stripe`, `dunite-stripe-core`, `dunite-user-core`, `dunite-feedback` and `dunite-image-upload` were all missing, so the file described a workspace of ten crates that actually holds fifteen.

Adds each with its one-line scope and its dependency edge, and rewrites the dependency-direction paragraph to state the rule (everything is a leaf except `dunite-download` / `dunite-oci` / `dunite-oidc` on `dunite-core` and `dunite-stripe` on `dunite-stripe-core`) instead of enumerating leaves by name, which is what went stale. Records the corollary the newer crates already follow: a leaf owns its error type rather than returning `dunite_core::AppError`, because returning it would pull every consumer onto one `dunite-core` revision.

Two conventions added under Conventions, both learned from DUNITE-10 through DUNITE-12: a crate that talks to a fixed upstream takes the host as a constructor argument so tests can point it at wiremock (`StripeService::with_api_base`, not a `StripeConfig` field, since consumers build those by struct literal), and a third-party error's free-text message is never logged or returned when the upstream embeds customer data in it (`redacted_stripe_error` + `StripeErrorDetails`, matched exhaustively so a new variant is a compile error rather than a silent leak).

Docs only; no code touched.