feat: Enhance localization compliance by enforcing usage of localized keys for user-facing strings and updating related documentation

.claude/agents/architecture-reviewer.md

@@ -58,6 +58,7 @@ and load any additional skills as needed for specific review challenges.
 6. Missing tests for use cases or repositories
 7. Complex BLoC without bloc_test coverage
 8. Test coverage below 70% for business logic
+9. Hardcoded user-facing strings — must use `core_localization` (Slang) via `t.<section>.<key>`. All `Text('...')` with literal English/Spanish strings in presentation layer must be replaced with localized keys
 
 ### MODERATE (Request Fix, can be deferred with justification):
 1. Missing doc comments on public APIs
@@ -103,7 +104,7 @@ Verify:
 - Business logic resides exclusively in use cases
 - Entities are in domain, models in data, widgets in presentation
 
-### Step 3: Design System Compliance
+### Step 3: Design System & Localization Compliance
 
 ```bash
 # Hardcoded colors
@@ -117,9 +118,22 @@ grep -rn -E "EdgeInsets\.(all|symmetric|only)\(" apps/mobile/apps/*/lib/features
 
 # Direct icon imports
 grep -rn "^import.*icons" apps/mobile/apps/*/lib/features/
+
+# Hardcoded user-facing strings (look for Text('...') with literal strings)
+grep -rn "Text(['\"]" apps/mobile/packages/features/
+# Also check for hardcoded strings in SnackBar, AlertDialog, AppBar title, etc.
+grep -rn "title: ['\"]" apps/mobile/packages/features/
+grep -rn "label: ['\"]" apps/mobile/packages/features/
+grep -rn "hintText: ['\"]" apps/mobile/packages/features/
 ```
 
-All styling must come from the design system. No exceptions.
+All styling must come from the design system. All user-facing strings must come from `core_localization` via Slang (`t.<section>.<key>`). No exceptions.
+
+**Localization rules:**
+- Strings defined in `packages/core_localization/lib/src/l10n/en.i18n.json` and `es.i18n.json`
+- Accessed via `t.<section>.<key>` (e.g., `t.client_create_order.review.invalid_arguments`)
+- Both `en` and `es` JSON files must be updated together
+- Regenerate with `dart run slang` from `packages/core_localization/` directory
 
 ### Step 4: State Management Review
 For every BLoC in changed files, verify:

.claude/skills/krow-mobile-architecture/SKILL.md

@@ -266,11 +266,29 @@ design_system/
 - Export `TranslationProvider` for `context.strings` access
 - Map domain failures to localized error messages via `ErrorTranslator`
 
+**String Definition:**
+- Strings are defined in `packages/core_localization/lib/src/l10n/en.i18n.json` (English) and `es.i18n.json` (Spanish)
+- Both files MUST be updated together when adding/modifying strings
+- Generated output: `strings.g.dart`, `strings_en.g.dart`, `strings_es.g.dart`
+- Regenerate with: `cd packages/core_localization && dart run slang`
+
 **Feature Integration:**
 ```dart
-// Features access strings
-Text(context.strings.loginButton)
+// ✅ CORRECT: Access via Slang's global `t` accessor
+import 'package:core_localization/core_localization.dart';
 
+Text(t.client_create_order.review.invalid_arguments)
+Text(t.errors.order.creation_failed)
+
+// ❌ FORBIDDEN: Hardcoded user-facing strings
+Text('Invalid review arguments')  // Must use localized key
+Text('Order created!')            // Must use localized key
+```
+
+**RESTRICTION:** ALL user-facing strings in the presentation layer (Text widgets, SnackBars, AppBar titles, hints, labels, error messages, dialogs) MUST use localized keys via `t.<section>.<key>`. No hardcoded English or Spanish strings.
+
+**BLoC Error Flow:**
+```dart
 // BLoCs emit domain failures (not strings)
 emit(AuthError(InvalidCredentialsFailure()));
 
@@ -879,6 +897,11 @@ Navigator.push(context, MaterialPageRoute(...));  // ← Use Modular
 Modular.to.navigate('/profile');  // ← Use safe extensions
 ```
 
+❌ **Hardcoded user-facing strings**
+```dart
+Text('Order created successfully!');  // ← Use t.section.key from core_localization
+```
+
 ## Summary
 
 The architecture enforces: