docs-doc-component

Standardize component documentation by enforcing a Usage → Examples → API Reference section order, with optional Composition, How it works, and Related sections. This structure helps readers find usage demos and API details quickly without scanning inconsistent layouts.

Group multiple examples by theme within the Examples section, keeping them strictly focused on usage. Avoid mixing deep mechanism explanations into demos, and place deep-dive content like namespaces or transforms in the How it works section instead.

Use the How it works section for deep-dive mechanisms such as namespaces, transforms, bbox/compile behavior, and edge-case conflicts. Keep the Examples section focused entirely on usage demonstrations to maintain a clear boundary between showing and explaining.

Yes, the Retikz docs system enforces a specific API Reference table format for component pages. Following this standardized table structure ensures API details are predictable and easy to scan across all component documentation within the system.

No, you should follow the enforced section ordering of Usage → Examples → API Reference, with optional Composition, How it works, and Related sections placed according to Retikz-specific rules. Deviating from this structure breaks documentation consistency and reader onboarding speed.

Documentation becomes hard to scan when section ordering is inconsistent or deep mechanisms are mixed into usage demos. Enforcing a predictable structure with clear boundaries between Examples and How it works ensures readers can navigate and reference components quickly.