mivita/CLAUDE.md

# 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

===

<laravel-boost-guidelines>
=== 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()`.
    - <code-snippet>public function __construct(public GitHub $github) { }</code-snippet>
- 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.

<code-snippet name="Explicit Return Types and Method Params" lang="php">
protected function isAccessible(User $user, ?string $path = null): bool
{
    ...
}
</code-snippet>

## 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:
<code-snippet name="Basic Pest Test Example" lang="php">
it('is true', function () {
    expect(true)->toBeTrue();
});
</code-snippet>

### 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.:
<code-snippet name="Pest Example Asserting postJson Response" lang="php">
it('returns all', function () {
    $response = $this->postJson('/api/docs', []);

    $response->assertSuccessful();
});
</code-snippet>

### 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.

<code-snippet name="Pest Dataset Example" lang="php">
it('has emails', function (string $email) {
    expect($email)->not->toBeEmpty();
})->with([
    'james' => 'james@laravel.com',
    'taylor' => 'taylor@laravel.com',
]);
</code-snippet>
</laravel-boost-guidelines>