setup

.eslintrc.json

@@ -32,6 +32,18 @@
     ]
   },
   "overrides": [
+    {
+      "files": ["**/index.ts", "**/index.tsx"],
+      "rules": {
+        "no-restricted-syntax": [
+          "error",
+          {
+            "selector": "Program",
+            "message": "index.ts files are forbidden. Use explicit file names instead (e.g., UserService.ts, not index.ts)."
+          }
+        ]
+      }
+    },
     {
       "files": ["**/*.ts", "**/*.tsx"],
       "parser": "@typescript-eslint/parser",
@@ -95,7 +107,14 @@
           }
         ],
         "import/no-default-export": "error",
-        "import/no-useless-path-segments": "error"
+        "import/no-useless-path-segments": "error",
+        "no-restricted-syntax": [
+          "error",
+          {
+            "selector": "ExportDefaultDeclaration",
+            "message": "Default exports are forbidden. Use named exports instead."
+          }
+        ]
       }
     }
   ]

docs/architecture/DISPLAY_OBJECTS.md

@@ -0,0 +1,82 @@
+# Display Objects
+
+## Definition
+
+A **Display Object** encapsulates **reusable, UI-only display logic**.
+
+It answers the question:
+
+> “How should this specific piece of information be shown?”
+
+Display Objects are **not screen-specific**.
+They exist to avoid duplicating presentation logic across View Models.
+
+---
+
+## Responsibilities
+
+A Display Object MAY:
+
+- format values (money, dates, durations)
+- handle localization and language-specific rules
+- map codes to labels
+- encapsulate UI display conventions
+- be reused across multiple View Models
+
+A Display Object MUST:
+
+- be deterministic
+- be side-effect free
+- operate only on presentation data
+
+---
+
+## Restrictions
+
+A Display Object MUST NOT:
+
+- contain business logic
+- enforce domain invariants
+- perform validation
+- influence system behavior
+- be sent back to the server
+- depend on backend or infrastructure concerns
+
+If a rule affects system correctness or persistence,
+it does not belong in a Display Object.
+
+---
+
+## Ownership & Placement
+
+- Display Objects belong to the **presentation layer**
+- They are frontend-only
+- They are not shared with the backend or core
+
+---
+
+## Relationship to View Models
+
+- View Models MAY use Display Objects
+- Display Objects MUST NOT depend on View Models
+- Display Objects represent **parts**
+- View Models represent **screens**
+
+---
+
+## Testing
+
+Display Objects SHOULD be tested because they often contain:
+
+- locale-specific behavior
+- formatting rules
+- edge cases visible to users
+
+---
+
+## Summary
+
+- Display Objects encapsulate **how something looks**
+- View Models encapsulate **what a screen needs**
+- Both are presentation concerns
+- Neither contains business truth

docs/architecture/VIEW_MODELS.md

@@ -0,0 +1,85 @@
++# View Models
+
+## Definition
+
+A **View Model** represents a **fully prepared UI state**.
+
+It answers the question:
+
+> “What does the UI need in order to render this screen without thinking?”
+
+View Models are **UI-owned** classes.
+They do not represent business truth and do not enforce domain rules.
+
+---
+
+## Responsibilities
+
+A View Model MAY:
+
+- accept an API DTO as input
+- derive UI-specific fields
+- combine or reshape data for rendering
+- perform formatting (dates, numbers, labels)
+- handle localization and presentation logic
+- use Display Objects for reusable UI concerns
+
+A View Model MUST:
+
+- be fully usable by the UI without further computation
+- expose only data and UI-oriented helpers
+- be created in a consistent, explicit way
+
+---
+
+## Restrictions
+
+A View Model MUST NOT:
+
+- contain business logic
+- validate domain rules
+- enforce permissions or authorization
+- contain domain entities or value objects
+- perform side effects
+- be sent back to the server
+
+If a View Model decides whether something is *allowed* or *correct*,
+that logic belongs in the Core, not here.
+
+---
+
+## Ownership & Placement
+
+- View Models belong to the **frontend**
+- They live close to the UI, not in shared or core layers
+- They are not shared with the backend
+
+---
+
+## Creation Rules
+
+- View Models are created from API DTOs
+- UI components must never construct View Models themselves
+- Construction happens in services or presentation layers
+- The UI only consumes View Models, never DTOs
+
+---
+
+## Testing
+
+View Models SHOULD be tested when they contain:
+
+- formatting logic
+- localization behavior
+- non-trivial derived fields
+
+View Models do NOT need tests if they only expose data without logic.
+
+---
+
+## Summary
+
+- View Models describe **UI state**
+- They are **presentation-focused**, not business-focused
+- They reduce complexity in components
+- They form a stable contract for the UI