# CLAUDE.md ## Projekt-Übersicht **mivita.care** - Laravel 11 CRM für Netzwerk-Marketing (MLM) mit E-Commerce, Provisionsberechnung, DHL-Versand und Multi-Tenancy. ## Tech Stack | Komponente | Technologie | | ----------- | -------------------------------------------- | | Framework | Laravel 11 (Classic MVC) | | Frontend | Bootstrap 4 (Appwork Theme), Blade Templates | | Auth | Laravel Passport (OAuth2/API) | | Database | MySQL 8 | | Data Tables | Yajra Datatables | | Testing | Pest PHP | | Queue | Laravel Horizon + Redis | | PDF | barryvdh/laravel-dompdf | | Slugs | Eloquent-Sluggable | | Forms | Spatie\Html | ## Wichtige Regeln (Constraints) 1. **Kein Livewire / Keine Vue-Komponenten** - Nutze reines Blade + Bootstrap 2. **Formulare** - Nutze `Spatie\Html` für Formular-Generierung (nicht reines HTML) 3. **Datentabellen** - Nutze ausschließlich `Yajra\Datatables` für Listenansichten im Admin 4. **PDF** - Rechnungen/Berichte via `barryvdh/laravel-dompdf` 5. **SEO/Slugs** - Nutze `Eloquent-Sluggable` für Berater-Profile/Produkte 6. **Code Style** - Immer `./vendor/bin/pint` nach Änderungen ausführen ## Custom Packages | Package | Pfad | Beschreibung | | --------------- | ------------------------------------ | --------------------------- | | DHL Integration | `packages/acme-laravel-dhl` | Versand-Labels und Tracking | | Shopping Cart | `packages/digital-bird/shoppingcart` | Warenkorb-System | ## Environment This project runs inside a **Dev Container**. Commands are executed directly with `php`, `composer`, and `npm` — **without** the `vendor/bin/sail` prefix. All `sail`-prefixed commands in docs or rules should be translated to their direct equivalents: | Sail | Dev Container | | ------------------------------ | ------------------- | | `vendor/bin/sail artisan ...` | `php artisan ...` | | `vendor/bin/sail composer ...` | `composer ...` | | `vendor/bin/sail npm ...` | `npm ...` | | `vendor/bin/sail php ...` | `php ...` | | `vendor/bin/sail bin pint` | `./vendor/bin/pint` | ## Projekt-Struktur ``` app/ ├── Console/Commands/ # Artisan Commands (Business*, User*) ├── Cron/ # Scheduled Task Logic ├── Http/Controllers/ # 40+ Controller ├── Models/ # Eloquent Models ├── Repositories/ # Data Access Layer ├── Services/ # Business Logic │ └── BusinessPlan/ # MLM-Berechnungen packages/ # Custom Packages dev/ # Dokumentation ``` ## Wichtige Dateien - **MLM-Berechnung**: `app/Services/BusinessPlan/TreeCalcBotOptimized.php` - **Cron Jobs**: `app/Console/Kernel.php` - **Domain Resolver**: Multi-Tenant Middleware - **Cart Systems**: AboOrderCart, HomepartyCart, ShopApiOrderCart ## Development Commands ### Laravel Basis ```bash php artisan serve # Dev Server php artisan migrate # Migrations php artisan cache:clear # Cache leeren php artisan config:clear php artisan route:clear php artisan view:clear ``` ### Code Quality ```bash ./vendor/bin/pint # Code formatieren ./vendor/bin/pest # Tests ausführen ./vendor/bin/pest --filter=TestName # Einzelner Test ``` ### IDE Helper ```bash php artisan ide-helper:generate php artisan ide-helper:models php artisan ide-helper:meta ``` ### Assets ```bash npm install && npm run dev # Development npm run production # Production Build ``` ### Business Commands ```bash # Provisionsberechnung (empfohlen: optimierte Version) php artisan business:store-optimized {month} {year} php artisan business:store-optimized {month} {year} --clear # Daten löschen php artisan business:clear-data {month} {year} [--force] # Level Reports php artisan business:level-reports {month} {year} # User Management php artisan user:cleanup php artisan user:make_abo_order # Zahlungen php artisan payments:check-accounts # Test Account php artisan business:test-account ``` ## Scheduled Tasks (Cron) | Zeit | Command | Beschreibung | | ----- | ------------------------------ | -------------------- | | 02:00 | `payments:check-accounts` | Zahlungsprüfung | | 03:00 | `business:store-optimized 0 0` | Provisionsberechnung | | 03:30 | `user:cleanup` | User-Bereinigung | | 04:00 | `user:make_abo_order` | Abo-Bestellungen | ## Docker Environment ```bash docker-compose up -d # Services starten ./vendor/bin/sail artisan [command] # Artisan im Container ./vendor/bin/sail shell # Shell im Container ``` ### Services - **laravel.test** - Hauptanwendung (Traefik + SSL) - **horizon** - Queue Worker - **mysql** - MySQL 8.0 - **redis** - Cache/Session - **mailpit** - Mail Testing (`mivita-mail.test`) ### Domains - Main: `mivita.test` - Wildcard: `*.mivita.test` - Mail: `mivita-mail.test` ## MLM-Architektur ### Kernkonzepte - **Consultants (Berater)**: Hierarchie mit Upline/Downline - **TreeCalcBotOptimized**: Provisionsberechnung für MLM-Strukturen - **BusinessPlan Services**: Sales Volumes, Ränge, Boni ### Performance - Memory Monitoring in optimierten Commands - Automatic Garbage Collection - Performance Logging ## Hinweise für Claude - Nutze immer `TreeCalcBotOptimized` für neue Business-Features - Prüfe Custom Packages in `packages/` vor Änderungen - Beachte Multi-Tenant Domain-Logik bei Routing-Änderungen - DHL-Integration unterstützt Sandbox/Production Mode === === foundation rules === # Laravel Boost Guidelines The Laravel Boost guidelines are specifically curated by Laravel maintainers for this application. These guidelines should be followed closely to enhance the user's satisfaction building Laravel applications. ## Foundational Context This application is a Laravel application and its main Laravel ecosystems package & versions are below. You are an expert with them all. Ensure you abide by these specific packages & versions. - php - 8.4.12 - laravel/framework (LARAVEL) - v11 - laravel/horizon (HORIZON) - v5 - laravel/passport (PASSPORT) - v12 - laravel/prompts (PROMPTS) - v0 - laravel/mcp (MCP) - v0 - laravel/pint (PINT) - v1 - laravel/sail (SAIL) - v1 - pestphp/pest (PEST) - v2 - phpunit/phpunit (PHPUNIT) - v10 ## Conventions - You must follow all existing code conventions used in this application. When creating or editing a file, check sibling files for the correct structure, approach, and naming. - Use descriptive names for variables and methods. For example, `isRegisteredForDiscounts`, not `discount()`. - Check for existing components to reuse before writing a new one. ## Verification Scripts - Do not create verification scripts or tinker when tests cover that functionality and prove it works. Unit and feature tests are more important. ## Application Structure & Architecture - Stick to existing directory structure; don't create new base folders without approval. - Do not change the application's dependencies without approval. ## Frontend Bundling - If the user doesn't see a frontend change reflected in the UI, it could mean they need to run `vendor/bin/sail npm run build`, `vendor/bin/sail npm run dev`, or `vendor/bin/sail composer run dev`. Ask them. ## Replies - Be concise in your explanations - focus on what's important rather than explaining obvious details. ## Documentation Files - You must only create documentation files if explicitly requested by the user. === boost rules === ## Laravel Boost - Laravel Boost is an MCP server that comes with powerful tools designed specifically for this application. Use them. ## Artisan - Use the `list-artisan-commands` tool when you need to call an Artisan command to double-check the available parameters. ## URLs - Whenever you share a project URL with the user, you should use the `get-absolute-url` tool to ensure you're using the correct scheme, domain/IP, and port. ## Tinker / Debugging - You should use the `tinker` tool when you need to execute PHP to debug code or query Eloquent models directly. - Use the `database-query` tool when you only need to read from the database. ## Reading Browser Logs With the `browser-logs` Tool - You can read browser logs, errors, and exceptions using the `browser-logs` tool from Boost. - Only recent browser logs will be useful - ignore old logs. ## Searching Documentation (Critically Important) - Boost comes with a powerful `search-docs` tool you should use before any other approaches when dealing with Laravel or Laravel ecosystem packages. This tool automatically passes a list of installed packages and their versions to the remote Boost API, so it returns only version-specific documentation for the user's circumstance. You should pass an array of packages to filter on if you know you need docs for particular packages. - The `search-docs` tool is perfect for all Laravel-related packages, including Laravel, Inertia, Livewire, Filament, Tailwind, Pest, Nova, Nightwatch, etc. - You must use this tool to search for Laravel ecosystem documentation before falling back to other approaches. - Search the documentation before making code changes to ensure we are taking the correct approach. - Use multiple, broad, simple, topic-based queries to start. For example: `['rate limiting', 'routing rate limiting', 'routing']`. - Do not add package names to queries; package information is already shared. For example, use `test resource table`, not `filament 4 test resource table`. ### Available Search Syntax - You can and should pass multiple queries at once. The most relevant results will be returned first. 1. Simple Word Searches with auto-stemming - query=authentication - finds 'authenticate' and 'auth'. 2. Multiple Words (AND Logic) - query=rate limit - finds knowledge containing both "rate" AND "limit". 3. Quoted Phrases (Exact Position) - query="infinite scroll" - words must be adjacent and in that order. 4. Mixed Queries - query=middleware "rate limit" - "middleware" AND exact phrase "rate limit". 5. Multiple Queries - queries=["authentication", "middleware"] - ANY of these terms. === php rules === ## PHP - Always use curly braces for control structures, even if it has one line. ### Constructors - Use PHP 8 constructor property promotion in `__construct()`. - public function __construct(public GitHub $github) { } - Do not allow empty `__construct()` methods with zero parameters unless the constructor is private. ### Type Declarations - Always use explicit return type declarations for methods and functions. - Use appropriate PHP type hints for method parameters. protected function isAccessible(User $user, ?string $path = null): bool { ... } ## Comments - Prefer PHPDoc blocks over inline comments. Never use comments within the code itself unless there is something very complex going on. ## PHPDoc Blocks - Add useful array shape type definitions for arrays when appropriate. ## Enums - Typically, keys in an Enum should be TitleCase. For example: `FavoritePerson`, `BestLake`, `Monthly`. === sail rules === ## Laravel Sail - This project runs inside Laravel Sail's Docker containers. You MUST execute all commands through Sail. - Start services using `vendor/bin/sail up -d` and stop them with `vendor/bin/sail stop`. - Open the application in the browser by running `vendor/bin/sail open`. - Always prefix PHP, Artisan, Composer, and Node commands with `vendor/bin/sail`. Examples: - Run Artisan Commands: `vendor/bin/sail artisan migrate` - Install Composer packages: `vendor/bin/sail composer install` - Execute Node commands: `vendor/bin/sail npm run dev` - Execute PHP scripts: `vendor/bin/sail php [script]` - View all available Sail commands by running `vendor/bin/sail` without arguments. === tests rules === ## Test Enforcement - Every change must be programmatically tested. Write a new test or update an existing test, then run the affected tests to make sure they pass. - Run the minimum number of tests needed to ensure code quality and speed. Use `vendor/bin/sail artisan test --compact` with a specific filename or filter. === laravel/core rules === ## Do Things the Laravel Way - Use `vendor/bin/sail artisan make:` commands to create new files (i.e. migrations, controllers, models, etc.). You can list available Artisan commands using the `list-artisan-commands` tool. - If you're creating a generic PHP class, use `vendor/bin/sail artisan make:class`. - Pass `--no-interaction` to all Artisan commands to ensure they work without user input. You should also pass the correct `--options` to ensure correct behavior. ### Database - Always use proper Eloquent relationship methods with return type hints. Prefer relationship methods over raw queries or manual joins. - Use Eloquent models and relationships before suggesting raw database queries. - Avoid `DB::`; prefer `Model::query()`. Generate code that leverages Laravel's ORM capabilities rather than bypassing them. - Generate code that prevents N+1 query problems by using eager loading. - Use Laravel's query builder for very complex database operations. ### Model Creation - When creating new models, create useful factories and seeders for them too. Ask the user if they need any other things, using `list-artisan-commands` to check the available options to `vendor/bin/sail artisan make:model`. ### APIs & Eloquent Resources - For APIs, default to using Eloquent API Resources and API versioning unless existing API routes do not, then you should follow existing application convention. ### Controllers & Validation - Always create Form Request classes for validation rather than inline validation in controllers. Include both validation rules and custom error messages. - Check sibling Form Requests to see if the application uses array or string based validation rules. ### Queues - Use queued jobs for time-consuming operations with the `ShouldQueue` interface. ### Authentication & Authorization - Use Laravel's built-in authentication and authorization features (gates, policies, Sanctum, etc.). ### URL Generation - When generating links to other pages, prefer named routes and the `route()` function. ### Configuration - Use environment variables only in configuration files - never use the `env()` function directly outside of config files. Always use `config('app.name')`, not `env('APP_NAME')`. ### Testing - When creating models for tests, use the factories for the models. Check if the factory has custom states that can be used before manually setting up the model. - Faker: Use methods such as `$this->faker->word()` or `fake()->randomDigit()`. Follow existing conventions whether to use `$this->faker` or `fake()`. - When creating tests, make use of `vendor/bin/sail artisan make:test [options] {name}` to create a feature test, and pass `--unit` to create a unit test. Most tests should be feature tests. ### Vite Error - If you receive an "Illuminate\Foundation\ViteException: Unable to locate file in Vite manifest" error, you can run `vendor/bin/sail npm run build` or ask the user to run `vendor/bin/sail npm run dev` or `vendor/bin/sail composer run dev`. === laravel/v11 rules === ## Laravel 11 - Use the `search-docs` tool to get version-specific documentation. - This project upgraded from Laravel 10 without migrating to the new streamlined Laravel 11 file structure. - This is **perfectly fine** and recommended by Laravel. Follow the existing structure from Laravel 10. We do not need to migrate to the Laravel 11 structure unless the user explicitly requests it. ### Laravel 10 Structure - Middleware typically lives in `app/Http/Middleware/` and service providers in `app/Providers/`. - There is no `bootstrap/app.php` application configuration in a Laravel 10 structure: - Middleware registration is in `app/Http/Kernel.php` - Exception handling is in `app/Exceptions/Handler.php` - Console commands and schedule registration is in `app/Console/Kernel.php` - Rate limits likely exist in `RouteServiceProvider` or `app/Http/Kernel.php` ### Database - When modifying a column, the migration must include all of the attributes that were previously defined on the column. Otherwise, they will be dropped and lost. - Laravel 11 allows limiting eagerly loaded records natively, without external packages: `$query->latest()->limit(10);`. ### Models - Casts can and likely should be set in a `casts()` method on a model rather than the `$casts` property. Follow existing conventions from other models. ### New Artisan Commands - List Artisan commands using Boost's MCP tool, if available. New commands available in Laravel 11: - `vendor/bin/sail artisan make:enum` - `vendor/bin/sail artisan make:class` - `vendor/bin/sail artisan make:interface` === pint/core rules === ## Laravel Pint Code Formatter - You must run `vendor/bin/sail bin pint --dirty --format agent` before finalizing changes to ensure your code matches the project's expected style. - Do not run `vendor/bin/sail bin pint --test --format agent`, simply run `vendor/bin/sail bin pint --format agent` to fix any formatting issues. === pest/core rules === ## Pest ### Testing - If you need to verify a feature is working, write or update a Unit / Feature test. ### Pest Tests - All tests must be written using Pest. Use `vendor/bin/sail artisan make:test --pest {name}`. - You must not remove any tests or test files from the tests directory without approval. These are not temporary or helper files - these are core to the application. - Tests should test all of the happy paths, failure paths, and weird paths. - Tests live in the `tests/Feature` and `tests/Unit` directories. - Pest tests look and behave like this: it('is true', function () { expect(true)->toBeTrue(); }); ### Running Tests - Run the minimal number of tests using an appropriate filter before finalizing code edits. - To run all tests: `vendor/bin/sail artisan test --compact`. - To run all tests in a file: `vendor/bin/sail artisan test --compact tests/Feature/ExampleTest.php`. - To filter on a particular test name: `vendor/bin/sail artisan test --compact --filter=testName` (recommended after making a change to a related file). - When the tests relating to your changes are passing, ask the user if they would like to run the entire test suite to ensure everything is still passing. ### Pest Assertions - When asserting status codes on a response, use the specific method like `assertForbidden` and `assertNotFound` instead of using `assertStatus(403)` or similar, e.g.: it('returns all', function () { $response = $this->postJson('/api/docs', []); $response->assertSuccessful(); }); ### Mocking - Mocking can be very helpful when appropriate. - When mocking, you can use the `Pest\Laravel\mock` Pest function, but always import it via `use function Pest\Laravel\mock;` before using it. Alternatively, you can use `$this->mock()` if existing tests do. - You can also create partial mocks using the same import or self method. ### Datasets - Use datasets in Pest to simplify tests that have a lot of duplicated data. This is often the case when testing validation rules, so consider this solution when writing tests for validation rules. it('has emails', function (string $email) { expect($email)->not->toBeEmpty(); })->with([ 'james' => 'james@laravel.com', 'taylor' => 'taylor@laravel.com', ]);