refactor: split architecture rules into domain-specific files

Split the monolithic .architecture-rules.yaml (1700+ lines) into focused
domain-specific files in .architecture-rules/ directory:

- _main.yaml: Core config, principles, ignore patterns, severity levels
- api.yaml: API endpoint rules (API-001 to API-005)
- service.yaml: Service layer rules (SVC-001 to SVC-007)
- model.yaml: Model rules (MDL-001 to MDL-004)
- exception.yaml: Exception handling rules (EXC-001 to EXC-005)
- naming.yaml: Naming convention rules (NAM-001 to NAM-005)
- auth.yaml: Auth and multi-tenancy rules (AUTH-*, MT-*)
- middleware.yaml: Middleware rules (MDW-001 to MDW-002)
- frontend.yaml: Frontend rules (JS-*, TPL-*, FE-*, CSS-*)
- language.yaml: Language/i18n rules (LANG-001 to LANG-010)
- quality.yaml: Code quality rules (QUAL-001 to QUAL-003)

Also creates scripts/validators/ module with base classes for future
modular validator extraction.

The validate_architecture.py loader now auto-detects and merges split
YAML files while maintaining backward compatibility with single file mode.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

.architecture-rules/service.yaml

@@ -0,0 +1,117 @@
+# Architecture Rules - Service Layer Rules
+# Rules for app/services/**/*.py files
+
+service_layer_rules:
+
+  - id: "SVC-001"
+    name: "Service must NOT raise HTTPException"
+    severity: "error"
+    description: |
+      Services are business logic layer - they should NOT know about HTTP.
+      Raise domain-specific exceptions instead (ValueError, custom exceptions).
+    pattern:
+      file_pattern: "app/services/**/*.py"
+      anti_patterns:
+        - "raise HTTPException"
+        - "from fastapi import HTTPException"
+
+  - id: "SVC-002"
+    name: "Service must use proper exception handling"
+    severity: "error"
+    description: |
+      Services should raise meaningful domain exceptions, not generic Exception.
+      Create custom exception classes for business rule violations.
+    pattern:
+      file_pattern: "app/services/**/*.py"
+      discouraged_patterns:
+        - "raise Exception\\("
+
+  - id: "SVC-003"
+    name: "Service methods must accept db session as parameter"
+    severity: "error"
+    description: |
+      Service methods should receive database session as a parameter for testability
+      and transaction control. Never create session inside service.
+    pattern:
+      file_pattern: "app/services/**/*.py"
+      required_in_method_signature:
+        - "db: Session"
+      anti_patterns:
+        - "SessionLocal()"
+        - "get_db()"
+
+  - id: "SVC-004"
+    name: "Service must use Pydantic models for input validation"
+    severity: "warning"
+    description: |
+      Service methods should accept Pydantic models for complex inputs
+      to ensure type safety and validation.
+    pattern:
+      file_pattern: "app/services/**/*.py"
+      encouraged_patterns:
+        - "BaseModel"
+
+  - id: "SVC-005"
+    name: "Service must scope queries to vendor_id in multi-tenant contexts"
+    severity: "error"
+    description: |
+      All database queries must be scoped to vendor_id to prevent cross-tenant data access.
+    pattern:
+      file_pattern: "app/services/**/*.py"
+      check: "vendor_scoping"
+
+  - id: "SVC-006"
+    name: "Service must NOT call db.commit()"
+    severity: "warning"
+    description: |
+      Services should NOT commit transactions. Transaction control belongs at the
+      API endpoint level where one request = one transaction.
+
+      This allows:
+      - Composing multiple service calls in a single transaction
+      - Clean rollback on any failure
+      - Easier testing of services in isolation
+
+      The endpoint should call db.commit() after all service operations succeed.
+    pattern:
+      file_pattern: "app/services/**/*.py"
+      anti_patterns:
+        - "db.commit()"
+      exceptions:
+        - "log_service.py"
+
+  - id: "SVC-007"
+    name: "Service return types must match API response schemas"
+    severity: "error"
+    description: |
+      When a service method's return value will be used as an API response,
+      the returned dict keys MUST match the corresponding Pydantic schema fields.
+
+      This prevents the common bug where:
+      - Service returns {"total_imports": 5, "completed_imports": 3}
+      - Schema expects {"total": 5, "completed": 3}
+      - Frontend receives wrong/empty values
+
+      RECOMMENDED PATTERNS:
+
+      1. Return Pydantic model directly from service:
+         def get_stats(self, db: Session) -> StatsResponse:
+             return StatsResponse(total=count, completed=done)
+
+      2. Return dict with schema-matching keys:
+         def get_stats(self, db: Session) -> dict:
+             return {"total": count, "completed": done}  # Matches StatsResponse
+
+      3. Document the expected schema in service docstring:
+         def get_stats(self, db: Session) -> dict:
+             """
+             Returns dict compatible with StatsResponse schema.
+             Keys: total, pending, completed, failed
+             """
+
+      TESTING: Write tests that validate service output against schema:
+         result = service.get_stats(db)
+         StatsResponse(**result)  # Raises if keys don't match
+    pattern:
+      file_pattern: "app/services/**/*.py"
+      check: "schema_compatibility"