Update README.md

README.md

@@ -1,99 +1,99 @@
 # LanguageStudy
 
 # Project Overview
-- **Architecture**: Multi-module Architecture
+Architecture**: Multi-module Architecture
 
 # Domain
 **LanguageStudy**: A language learning application.
 
 # Dependencies
 
-- **Kotlin**
-- **Compose**
-- **Hilt**
-- **Room**
-- **Coroutines**
+**Kotlin**
+**Compose**
+**Hilt**
+**Room**
+**Coroutines**
 
 # Current Status
 Preparing for MVP version development.
 
 # Design System Development
-- Establishing a comprehensive design system:
-    - Define design tokens
-    - Define color tokens
-    - Build minimal essential components (typography, buttons, etc.)
-    - Create a separate sample app to verify design system functionality
+Establishing a comprehensive design system:
+ - Define design tokens
+ - Define color tokens
+ - Build minimal essential components (typography, buttons, etc.)
+ - Create a separate sample app to verify design system functionality
 
 # Code Style & Conventions
 
 ## Kotlin Conventions
-- **Trailing Comma**: Always use trailing commas in multi-line declarations
-- **If Statements**: Always use braces with line breaks (no single-line if)
-- **When Statements**: Use braces for all branches, prefer `if` for 2 conditions, no `else` for enums/sealed
-- **Lambda**: Always use line breaks, specify field types explicitly
-- **Invoke Operator**: Use `obj()` not `obj.invoke()` for operator functions and lambdas
-- **Enum Classes**: Use `SCREAMING_SNAKE_CASE` for enum entries
-- **Declaration Order**: override → public → internal → protected → private (variables → functions → extensions)
-- **Object/Companion**: Always declare at bottom of class/interface
-- **Named Arguments**: Optional for 1 arg, required for 2+ args (Kotlin code only)
-- **Comments**: Use KDoc style, link TODO comments to JIRA tickets. Do not leave comments like `//` inside functions.
-- **Class Formatting**: The first line of a class should be written without a blank line.
+**Trailing Comma**: Always use trailing commas in multi-line declarations
+**If Statements**: Always use braces with line breaks (no single-line if)
+**When Statements**: Use braces for all branches, prefer `if` for 2 conditions, no `else` for enums/sealed
+**Lambda**: Always use line breaks, specify field types explicitly
+**Invoke Operator**: Use `obj()` not `obj.invoke()` for operator functions and lambdas
+**Enum Classes**: Use `SCREAMING_SNAKE_CASE` for enum entries
+**Declaration Order**: override → public → internal → protected → private (variables → functions → extensions)
+**Object/Companion**: Always declare at bottom of class/interface
+**Named Arguments**: Optional for 1 arg, required for 2+ args (Kotlin code only)
+**Comments**: Use KDoc style, link TODO comments to JIRA tickets. Do not leave comments like `//` inside functions.
+**Class Formatting**: The first line of a class should be written without a blank line.
 
 ## Compose Conventions
-- **Function Naming**: Unit-returning Composables start with uppercase, value-returning with lowercase
-- **Parameter Order**: Required → Modifier (first optional) → Optional → Composable slots/lambdas
-- **Modifier Default**: Always use `modifier: Modifier = Modifier` (not `Modifier.something()`)
-- **ViewModel Injection**: Pass ViewModels as parameters, not create inside Composables
-- **Preview Functions**: Mark internal composable previews as `internal` (not `public`)
-- **Event Parameters**: Use consistent naming for event handlers (`onX` pattern)
+**Function Naming**: Unit-returning Composables start with uppercase, value-returning with lowercase
+**Parameter Order**: Required → Modifier (first optional) → Optional → Composable slots/lambdas
+**Modifier Default**: Always use `modifier: Modifier = Modifier` (not `Modifier.something()`)
+**ViewModel Injection**: Pass ViewModels as parameters, not create inside Composables
+**Preview Functions**: Mark internal composable previews as `internal` (not `public`)
+**Event Parameters**: Use consistent naming for event handlers (`onX` pattern)
 
 # Architecture
 Following Android's official recommended app architecture with a layered approach:
-- **Presentation Layer** → **Domain Layer (Optional)** → **Data Layer**
+**Presentation Layer** → **Domain Layer (Optional)** → **Data Layer**
 
 ## Architectural Pattern
-- **UI Pattern**: MVVM (Model-View-ViewModel)
-    - Considering MVI as an alternative, but MVVM is likely to be adopted
+**UI Pattern**: MVVM (Model-View-ViewModel)
+ - Considering MVI as an alternative, but MVVM is likely to be adopted
 
 ## Layer Responsibilities
 
 ### Presentation Layer
-- **Pattern**: MVVM with Jetpack Compose
-- **Components**:
-    - ViewModels: Business logic and state management
-    - UI States: Immutable state representations
-    - Contracts: Events and side effects
-    - Composables: UI components
-- **Dependencies**: Domain API modules only (no direct data layer access)
+**Pattern**: MVVM with Jetpack Compose
+**Components**:
+- ViewModels: Business logic and state management
+- UI States: Immutable state representations
+- Contracts: Events and side effects
+- Composables: UI components
+**Dependencies**: Domain API modules only (no direct data layer access)
 
 ### Domain Layer (Optional)
-- **Pattern**: UseCase-based business logic
-- **When to use**:
-    - Complex repository logic that needs coordination
-    - Combining data from multiple repositories
-    - Reusable business logic across features
-- **Components**:
-    - UseCases: Single-responsibility business operations
-    - DomainModels: Business entities
-    - Domain Mappers: Data to domain transformations
-- **Dependencies**: Repository API modules only (no direct data source access)
+**Pattern**: UseCase-based business logic
+**When to use**:
+ - Complex repository logic that needs coordination
+ - Combining data from multiple repositories
+ - Reusable business logic across features
+**Components**:
+ - UseCases: Single-responsibility business operations
+ - DomainModels: Business entities
+ - Domain Mappers: Data to domain transformations
+**Dependencies**: Repository API modules only (no direct data source access)
 
 ### Data/Repository Layer
-- **Pattern**: Repository pattern with API/IMPL separation
-- **Components**:
-    - Repository interfaces (API): Contract definitions
-    - Repository implementations (IMPL): Data access logic
-    - DataModels: Data transfer objects
-    - Data Mappers: Network/DB to data model transformations
-- **Dependencies**: DataSource API modules, domain contracts
+**Pattern**: Repository pattern with API/IMPL separation
+**Components**:
+ - Repository interfaces (API): Contract definitions
+ - Repository implementations (IMPL): Data access logic
+ - DataModels: Data transfer objects
+ - Data Mappers: Network/DB to data model transformations
+**Dependencies**: DataSource API modules, domain contracts
 
 ### DataSource/Network Layer
-- **Pattern**: DataSource pattern with Request/Response DTOs
-- **Components**:
-    - RemoteDataSource: Firebase API interactions
-    - LocalDataSource: Local storage operations
-    - Response DTOs: API response models
-    - Request DTOs: API request parameters
-- **Dependencies**: Network clients (Firebase SDK), local storage APIs
+**Pattern**: DataSource pattern with Request/Response DTOs
+**Components**:
+ - RemoteDataSource: Firebase API interactions
+ - LocalDataSource: Local storage operations
+ - Response DTOs: API response models
+ - Request DTOs: API request parameters
+**Dependencies**: Network clients (Firebase SDK), local storage APIs