Prefer behavior-true names

Use naming that clearly communicates the real behavior/intent of the API and avoids misleading abbreviations or borrowed terms whose common meaning differs.

Apply this when adding/renaming methods:

• Match semantics to behavior: if the method “checks and returns input as-is,” don’t name it after an operation that “returns an array without duplicates.”
• Prefer full, intention-revealing names over short/ambiguous ones when they reduce clarity.
• If a common ecosystem term may imply different semantics, choose a name that reflects the actual operation (or explicitly document the difference).
• For domain terms that overlap with other systems (e.g., “forms”), ensure the wording/dox strings align with the library’s/TypeScript’s meaning to prevent confusion.

Example rule in practice:

• ❌ Confusing due to semantic mismatch: a method named like lodash uniq when it does not dedupe/transform.
• ✅ Clearer alternative: choose a name that reflects what happens (e.g., “unique/ distinct” only if the operation truly enforces/derives uniqueness as that name implies), or pick another verb that matches intent (as in the naming exploration for .check).