# Lean by design

KISS, YAGNI and DRY as working rules: simple parts, no speculative code, one place for each thing.

Keep implementations as small as the current requirement allows.

- Prefer the simplest solution that fully solves the actual task.
- Do not add speculative fields, statuses, workflow steps, or audit data "for later".
- Reuse built-in Nimbly metadata like `_created` and `_modified` before introducing parallel custom fields.
- Do not derive UUIDs from business fields unless the project explicitly requires it.
- Don't repeat logic - extract shared behaviour into a helper rather than duplicating it.
- Don't repeat substantial Tailwind class lists across links, buttons, or related UI elements. When the same long visual contract repeats, extract its canonical class list into a small `.tpl` class partial (for example `cls-action-link.tpl`) and reuse its rendered value. Place it at the narrowest useful scope: beside the route in `core/modules/<module>/uri/<route>/` or `ext/uri/<route>/` for page-scoped styles, in `core/tpl/` for framework-wide styles, or in `ext/tpl/` for reusable application-specific styles. Apply this only when the abstraction provides a real consistency or maintenance benefit. Keep one-off classes, single utilities, and short class lists inline; extracting those adds indirection without enough value.
- When duplicate prevention is needed, prefer an index on the business field before inventing a more complex identity scheme.

Production-ready does **not** mean speculative. It means clean, coherent, and sufficient for the current use case.

- If a project-specific solution exposes a reusable framework capability, explicitly mention the core/framework option before defaulting to a local workaround.