Cursor Rules

# General Rules

1. You must follow the following development principles:
  - SSOT
  - YAGNI
  - KISS
  - DRY
  - SOLID
  - Fail-Fast Principle: If an unexpected invalid condition occurs, throw an error immediately instead of silently ignoring it or trying to recover, unless Defensive Programming considerations suggest handling it more gracefully.
  - Defensive Programming Principle: In some cases, errors should be reported safely using `Debug.LogError` and `Debug.LogException` instead of throwing an exception directly, to prevent unnecessary crashes.

2. Include only the necessary code that serves a clear purpose. Avoid unnecessary or premature additions, i.e. fields, properties and methods that provide no immediate benefit. Avoid introducing new methods if their implementation is simple and obvious, until it's needed to follow the DRY.
3. When asked to make changes, follow the minimal changes principle unless explicitly requested to improve code quality.
4. Do not introduce safety checks for the serialized fields until asked explicitly.
5. Do not add explaining comments except the docs.
6. You should prefer to use TimeSpan when working with date/time intervals.
7. When using the RequireComponent attribute, consider the corresponding field to never be null, so the null-checks may be omitted.
8. Use leading underscore for private field names.
9. Keep your code aligned with the existing code style.
10. Don't use namespaces, create new classes in the global namespace.
11. The use of Singleton pattern in this specific project is intended, widely common, and should not be consideres as an architectural flaw.
12. This project allowes to use strange code style just for fun as it's a personal project only. The "strange" code style may include using of another languages, obviously unnecessary code like const ONE = 1 etc. While being asked for a refactoring advice, you should ignore cases like these.
13. When you write docs comments, avoid including the unnecessary information - for instance, the prompt-specific data. Example:

   - The Bad Option:
   /// <summary>
   /// Data Transfer Object for purchase card data.
   /// Contains only the essential data needed for a purchase card.
   /// Not serializable as it's constructed at runtime.
   /// </summary>

   - The Good Option:
   /// <summary>
   /// Data Transfer Object for purchase card data.
   /// </summary>

# Additional Context

<High-level Description of the Project>