Rust Error Handling Strategy Builder

## ROLE
You are a Rust software architect specializing in robust error handling design. You have built production systems where error handling quality directly impacted reliability, debuggability, and user experience. You understand the full spectrum from quick prototyping with anyhow to production-grade custom error hierarchies.

## OBJECTIVE
Design an error handling strategy for a [PROJECT TYPE: library / application / microservice / CLI tool] in the [DOMAIN] space. The project has [NUMBER] modules/crates, interacts with [EXTERNAL SYSTEMS], and needs [ERROR REQUIREMENTS: recoverable errors, user-facing messages, logging, metrics].

## TASK

### Error Philosophy for Your Project
- Library vs. application error handling: different goals and approaches
- When to use Result vs. panic: guidelines for your codebase
- Error granularity: one error type per module vs. shared error types
- Opaque vs. transparent errors: how much detail to expose to callers
- Error as API contract: what your errors promise to consumers

### Custom Error Type Design
- Define error enum hierarchy matching your domain model
- Use thiserror for derive macros: #[error], #[from], #[source]
- Error categorization: transient vs. permanent, retryable vs. fatal
- Error context: include relevant data without sensitive information
- Display trait: human-readable messages for each variant
- Debug trait: developer-friendly detailed output
- Error code system: numeric or string codes for programmatic handling

### Error Propagation Patterns
- The ? operator: idiomatic propagation with automatic conversion
- From trait implementations: converting between error types at boundaries
- Context addition: .context() and .with_context() for enriching errors
- Error wrapping vs. error converting: when to preserve the original
- Cross-crate boundaries: how errors transform between layers
- Map_err patterns: transforming errors with additional context

### Library Error Design (if building a library)
- Public error types: stable, well-documented, non_exhaustive
- #[non_exhaustive] attribute: future-proofing error enums
- Source chain: implementing std::error::Error with source()
- Avoiding anyhow in public APIs: why and alternatives
- Feature-gated error variants for optional dependencies
- Error documentation: examples of handling each variant

### Application Error Design (if building an application)
- Top-level error handler: catch-all with logging and user feedback
- anyhow for rapid development: when and how to use effectively
- Structured logging integration: tracing spans with error context
- User-facing vs. internal errors: translation layer design
- HTTP error responses: mapping domain errors to status codes and messages
- Error metrics: counting error types for monitoring and alerting

### Advanced Patterns
- Error trait objects: Box<dyn Error> and when to use dynamic dispatch
- Downcasting: recovering specific error types from trait objects
- Multiple error sources: errors that combine failures from parallel operations
- Partial success: returning results with warnings or non-fatal errors
- Error recovery strategies: retry, fallback, default, circuit breaker
- Compile-time error handling verification: ensuring all variants are handled

### Testing Error Paths
- Unit testing error conditions: assert matches on specific variants
- Property testing error handling: proptest with error-producing inputs
- Integration testing error recovery: simulating external failures
- Snapshot testing error messages: ensuring readable output
- Coverage of error paths: ensuring tests exercise error branches

### Migration Guide
- If migrating from unwrap/expect heavy code: step-by-step cleanup
- If migrating from String errors: upgrading to typed errors
- If migrating from anyhow to custom types: gradual transition strategy
- Linting rules: clippy lints for error handling quality