llml — Cursor Rules

• Primary Data Type: The library's core data input is &serde_json::Value. This ensures compatibility with any data that can be serialized to JSON. • String Handling: • Use format! for constructing simple strings. • For building strings from multiple parts in a loop, collect parts into a Vec<String> and then use parts.join("") for efficiency. • Use &str as function arguments for string slices instead of String where possible. • Recursion: The core formatting logic is recursive. New formatting rules should be integrated into the existing recursive format_value and format_key_value functions.

These guidelines are designed to maintain the existing quality, style, and architectural patterns of the codebase.

• Public API (src/lib.rs): The src/lib.rs file is the public face of the library. It should only contain the public API (llml, llml_with_options, Options struct) and its associated documentation and unit tests. • Core Logic (src/formatters.rs): All internal formatting logic should reside in the src/formatters.rs module. Functions within this module should remain private to the crate (i.e., not marked with pub). • Tests: • Unit Tests: Place unit tests within the module they are testing, using a #[cfg(test)] mod tests { ... } block. • Integration Tests: Place integration tests in the tests/ directory. These tests should only call the public API from lib.rs. • Examples: Add new usage examples to the examples/ directory.

• Formatting: All code must be formatted with rustfmt using the default settings. • Naming Conventions: • Functions & Variables: Use snake_case (e.g., format_value, kebab_key). • Types (Structs, Enums): Use PascalCase (e.g., Options). • Constants & Statics: Use SCREAMING_SNAKE_CASE (e.g., MULTI_HYPHEN_RE). • Clarity: Prioritize clear, readable code. Use descriptive variable names.