Files
orion/scripts
Samir Boulahtit adc36246b8
Some checks failed
CI / ruff (push) Successful in 14s
CI / pytest (push) Failing after 2h32m45s
CI / validate (push) Successful in 30s
CI / dependency-scanning (push) Successful in 31s
CI / docs (push) Has been skipped
CI / deploy (push) Has been skipped
feat(storefront): homepage, module gating, widget protocol, i18n fixes
Storefront homepage & module gating:
- CMS owns storefront GET / (slug="home" with 3-tier resolution)
- Catalog loses GET / (keeps /products only)
- Store root redirect (GET / → /store/dashboard or /store/login)
- Route gating: non-core modules return 404 when disabled for platform
- Seed store default homepages per platform

Widget protocol for customer dashboard:
- StorefrontDashboardCard contract in widgets.py
- Widget aggregator get_storefront_dashboard_cards()
- Orders and Loyalty module widget providers
- Dashboard template renders contributed cards (no module names)

Landing template module-agnostic:
- CTAs driven by storefront_nav (not hardcoded module names)
- Header actions check nav item IDs (not enabled_modules)
- Remove hardcoded "Add Product" sidebar button
- Remove all enabled_modules checks from storefront templates

i18n fixes:
- Title placeholder resolution ({{store_name}}) for store default pages
- Storefront nav label_keys prefixed with module code
- Add storefront.account.* keys to 6 modules (en/fr/de/lb)
- Header/footer CMS pages use get_translated_title(current_language)
- Footer labels use i18n keys instead of hardcoded English

Icon cleanup:
- Standardize on map-pin (remove location-marker alias)
- Replace all location-marker references across templates and docs

Docs:
- Storefront builder vision proposal (6 phases)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-13 22:53:17 +02:00
..

Architecture Validation Scripts

This directory contains scripts for validating and enforcing architectural patterns across the codebase.

Architecture Validator

Overview

validate_architecture.py is an automated tool that checks the codebase against architectural rules defined in .architecture-rules.yaml.

Key Features

  • API Endpoint Validation: Ensures proper separation of concerns, Pydantic usage, exception handling
  • Service Layer Validation: Enforces domain exceptions, database session patterns
  • Model Validation: Checks proper separation of SQLAlchemy and Pydantic models
  • Exception Handling: Validates proper exception patterns
  • JavaScript Patterns: Enforces coding standards for frontend code
  • Template Validation: Ensures templates follow required patterns

Usage

# Validate entire codebase
python scripts/validate/validate_architecture.py

# Validate specific directory
python scripts/validate/validate_architecture.py app/api/

# Verbose output with code context
python scripts/validate/validate_architecture.py --verbose

# Show only errors (suppress warnings)
python scripts/validate/validate_architecture.py --errors-only

# Use custom config file
python scripts/validate/validate_architecture.py --config custom-rules.yaml

Exit Codes

  • 0: Validation passed (warnings allowed)
  • 1: Validation failed (errors found)

Integration with Pre-commit

Install pre-commit hooks to run validation automatically:

# Install pre-commit
pip install pre-commit

# Setup hooks
pre-commit install

# Run manually on all files
pre-commit run --all-files

# Run on staged files only
pre-commit run

Configuration

The validation rules are defined in .architecture-rules.yaml at the project root. This file contains:

  • Core Principles: Separation of concerns, type safety, exception handling
  • API Endpoint Rules: (API-001 through API-004)
  • Service Layer Rules: (SVC-001 through SVC-004)
  • Model Rules: (MDL-001 through MDL-002)
  • Exception Rules: (EXC-001 through EXC-002)
  • JavaScript Rules: (JS-001 through JS-003)
  • Template Rules: (TPL-001)

Rule Categories

API Endpoint Rules

  • API-001: Use Pydantic models for request/response
  • API-002: No business logic in endpoints
  • API-003: Proper exception handling (catch and convert to HTTPException)
  • API-004: Authentication on protected endpoints

Service Layer Rules

  • SVC-001: No HTTPException in services (use domain exceptions)
  • SVC-002: Create custom exception classes (avoid generic Exception)
  • SVC-003: Database session as parameter (not created internally)
  • SVC-004: Use Pydantic for input validation

Model Rules

  • MDL-001: Use SQLAlchemy Base for database models
  • MDL-002: Separate Pydantic from SQLAlchemy models

Exception Rules

  • EXC-001: Define custom exceptions in exceptions module
  • EXC-002: Never use bare except

JavaScript Rules

  • JS-001: Use apiClient directly (not window.apiClient)
  • JS-002: Use centralized logger (not console)
  • JS-003: Alpine components must spread ...data()

Example Output

🔍 Starting architecture validation...

📡 Validating API endpoints...
🔧 Validating service layer...
📦 Validating models...
⚠️  Validating exception handling...
🟨 Validating JavaScript...
📄 Validating templates...

================================================================================
📊 ARCHITECTURE VALIDATION REPORT
================================================================================

Files checked: 145
Total violations: 3

❌ ERRORS (2):
--------------------------------------------------------------------------------

  [API-002] Endpoint must NOT contain business logic
  File: app/api/v1/admin/stores.py:45
  Issue: Database operations should be in service layer
  💡 Suggestion: Move database operations to service layer

  [SVC-001] Service must NOT raise HTTPException
  File: app/services/store_service.py:78
  Issue: Service raises HTTPException - use domain exceptions instead
  💡 Suggestion: Create custom exception class (e.g., StoreNotFoundError) and raise that

⚠️  WARNINGS (1):
--------------------------------------------------------------------------------

  [JS-001] Use apiClient directly
  File: static/admin/js/stores.js:23
  Issue: Use apiClient directly instead of window.apiClient
  💡 Suggestion: Replace window.apiClient with apiClient

================================================================================
❌ VALIDATION FAILED - Fix errors before committing
================================================================================

CI/CD Integration

Add to your CI pipeline (GitHub Actions example):

# .github/workflows/ci.yml
name: CI

on: [push, pull_request]

jobs:
  validate-architecture:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install dependencies
        run: |
          pip install pyyaml

      - name: Validate Architecture
        run: |
          python scripts/validate/validate_architecture.py

Documentation

For detailed architectural patterns and examples, see:

Extending the Validator

To add new rules:

  1. Add rule definition to .architecture-rules.yaml
  2. Implement validation logic in validate_architecture.py
  3. Add examples to docs/architecture/architecture-patterns.md
  4. Test with python scripts/validate/validate_architecture.py --verbose

Troubleshooting

Issue: Validator reports false positives

Solution: Add exception patterns to .architecture-rules.yaml under ignore section

Issue: Validator doesn't catch a specific violation

Solution: The rule might not be implemented yet. Check .architecture-rules.yaml and validate_architecture.py to add the rule.

Issue: Pre-commit hook fails but manual run passes

Solution: Ensure pre-commit is using the same Python environment:

pre-commit clean
pre-commit install

Contributing

When adding new architectural patterns:

  1. Document the pattern in docs/architecture/architecture-patterns.md
  2. Add validation rule to .architecture-rules.yaml
  3. Implement validation in validate_architecture.py
  4. Test thoroughly with existing codebase
  5. Update this README with the new rule

Questions? See the Architecture Patterns Documentation