Lean by design

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.