=== .ai/project-description rules ===
# Polaris Laravel service
Polaris is a debt-collection application with CRM synchronization, campaigns, SMS/email and telephony. This directory (`modulo_drpeso/laravel` inside the parent Git repository) is the Laravel application root; run the commands below here.
## Maintaining these instructions
This file is the shared project source for Laravel Boost. Edit `.ai/guidelines/project-description.md`, then run `docker exec -i polaris-service-new php artisan boost:update` to regenerate the Boost blocks in `CLAUDE.md` and `AGENTS.md`. Do not edit generated blocks directly. Selected agents are configured in `boost.json`; MCP connections are configured separately.
## Runtime and commands
- Use PHP 8.3: `app/Console/Kernel.php` has typed class constants, despite Composer's broader `^8.1` constraint.
- Stack: Laravel 10, Livewire 3, Sanctum 3, Scout 10, PHPUnit 10; PostgreSQL, Redis and Elasticsearch integrations.
- PHP runs in `polaris-service-new`, mounted at `/var/www`; run PHP, Composer, Artisan and Pint inside that container.
- Start local services: `docker compose -f polaris-local-infra/docker-compose.yml up -d`.
- Install PHP dependencies when needed: `docker exec -i polaris-service-new composer install`.
- Run tests: `docker exec -i polaris-service-new php artisan test --compact`.
- Run focused tests: `docker exec -i polaris-service-new php artisan test --compact --filter=ImportLoansCsvTest`.
- Format changed PHP before finalizing: `docker exec -i polaris-service-new vendor/bin/pint --dirty`.
- Inspect routes: `docker exec -i polaris-service-new php artisan route:list`.
- Vite scripts: `npm run dev` and `npm run build`. There is no `composer run dev` script.
- Most views use committed assets in `public/js` and `public/css`; check the actual Blade asset reference before assuming a Vite build affects the UI.
- Use Laravel Boost's version-aware documentation and inspection tools when available; verify command options before invoking unfamiliar Artisan generators.
## Architecture and navigation
- `app/Admin/routes.php` is loaded by `App\Providers\AdminPanelServiceProvider`; this is an application-owned admin panel, not an installed OpenAdmin package. UI components live in `app/Livewire` and `resources/views`.
- `app/Providers/AppServiceProvider.php` selects country-specific handlers and providers. `app/Services/Actualization` contains the runner, executors, and loan/payment import handlers.
- `app/Services/Company` implements campaigns (the domain calls them “company”); `app/Services/CommunicationIntegrations` contains channel orchestration and providers; `app/Integrations` contains telephony clients.
- `app/Models` groups models by database domain; `app/Repositories/Collection` provides reads through `collection_replica`. Jobs use queue names from `app/Jobs/JobsQueueEnum.php`.
- `app/Settings` contains DB-backed Spatie settings; their migrations belong in `database/settings`. Scheduling is in `app/Console/Kernel.php`.
## Country and data boundaries
- Four instances share this code: Peru, Colombia, Mexico and Kazakhstan, selected by `APP_INSTANCE` through `config('polaris.instance')`.
- Check the affected country branches before changing shared behavior; some bindings deliberately reject unsupported countries.
- Reuse `isPeru()`, `isColombia()`, `isMexico()`, `isKazakhstan()` and formatting helpers in `app/Helpers/Autoload/functions.php`. Constants and helpers are Composer-autoloaded.
- Register new country handler bindings in `AppServiceProvider`; preserve the distinction between Kazakhstan CRM1 and CRM2 sources.
- Extend `Kernel::LEAD_TIME` (`ALL` or the appropriate instance) and `COMMAND_SETTINGS` for scheduled work instead of bypassing the existing scheduling loop.
- Preserve model `$connection`, table names and legacy column mappings. `collection`, `users`, `sms`, `email` and `telephony` use different PostgreSQL schemas; changing connection can silently change the queried schema.
- Keep reads on the existing repository connection where applicable. `collection_replica` can share the primary host in local configurations; its name does not guarantee physical isolation.
- `colombia_prod` and `kz_prod` are enforced read-only in `AppServiceProvider`; do not bypass those guards.
- Preserve actualization concurrency guards, run history, bucket UUIDs, source selection, streaming and partial-run watermarks when changing imports.
## Code conventions
- Follow sibling classes and existing directory boundaries; reuse components and services before adding new abstractions.
- Use typed parameters/returns, constructor property promotion where appropriate, and braces for control structures. Prefer explanatory PHPDoc over redundant inline comments.
- For Laravel 10 models, use `protected $casts`, not the newer `casts()` method. Middleware belongs in `app/Http/Kernel.php`.
- Read environment settings through `config()`; keep new `env()` calls in configuration files.
- Prefer Eloquent relationships and eager loading. Where existing import/report queries need the query builder, preserve explicit connections and parameter binding.
- Use Form Requests for HTTP validation and validate/authorize Livewire actions on the server. Follow existing permission slugs (`PERMISSION_*`) and user access checks.
- Livewire uses `App\Livewire`, `$this->dispatch()` and `wire:model.live` for immediate updates. Do not add a second Alpine installation.
- Keep slow work on the established job/queue path; inspect existing locks and retry behavior before changing dispatch.
## Routes and contracts
- `routes/api.php` is mounted under both `/api` and `/laravel/api`; a route change affects both prefixes.
- `routes/webhooks.php` is mounted under `/webhooks`; admin routes use `config('admin.route.prefix')` and the `admin` session guard.
- Authentication differs by endpoint: Sanctum, the `access_token` header for incoming updates, admin sessions, and a separate MCP bearer token. Inspect the actual route and handler instead of assuming all API routes use Sanctum.
- Preserve existing response shapes/status codes and source parameters. Cover authentication and validation failures when changing endpoints.
## Verification and Git workflow
- The project has substantive Unit and Feature tests, including actualization, admin, telephony, MCP and imports. Start with the relevant tests; broaden when shared behavior changes.
- `phpunit.xml` does not configure an isolated test database. Inspect the target test setup and connection configuration before running DB-writing tests; reuse existing fakes/mocks and fixtures.
- Examples: `tests/Feature/IncomingUpdates/ImportLoansCsvTest.php`, `tests/Feature/Admin/AdminSmokeTest.php`, and `tests/Feature/ReadOnlyProdConnectionsTest.php`.
- Do not perform real campaign dispatch or CRM synchronization as a substitute for test verification.
- Preserve unrelated working-tree changes, including staged files elsewhere in the parent repository.
- Recent history includes `POL-...` issue references but no consistently enforced commit format; keep the task's issue key when supplied and describe the actual change.
- In a PR or handoff, state affected instances, behavior changes, checks performed and unresolved limitations. Do not claim tests ran if only commands were inspected.
## Deeper context
Read the relevant analysis on demand, then verify it against code:
- `.ai/docs/structure_analysis.md`: component map and extension points.
- `.ai/docs/dependency_analysis.md`: dependency wiring and runtime constraints.
- `.ai/docs/data_flow_analysis.md`: import stages, data lifecycle and state.
- `.ai/docs/request_flow_analysis.md`: routes, middleware and authorization.
- `.ai/docs/api_analysis.md`: API contracts and external integrations.
These documents are snapshots, not instructions to implement every finding. Do not copy credentials from source or analysis into generated documentation.
=== 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.3.33
- laravel/framework (LARAVEL) - v10
- laravel/prompts (PROMPTS) - v0
- laravel/pulse (PULSE) - v1
- laravel/sanctum (SANCTUM) - v3
- laravel/scout (SCOUT) - v10
- livewire/livewire (LIVEWIRE) - v3
- laravel/mcp (MCP) - v0
- laravel/pint (PINT) - v1
- laravel/sail (SAIL) - v1
- 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 `npm run build`, `npm run dev`, or `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`.
=== 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 `php artisan test --compact` with a specific filename or filter.
=== laravel/core rules ===
## Do Things the Laravel Way
- Use `php 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 `php 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 `php 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 `php 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 `npm run build` or ask the user to run `npm run dev` or `composer run dev`.
=== laravel/v10 rules ===
## Laravel 10
- Use the `search-docs` tool to get version-specific documentation.
- Middleware typically live in `app/Http/Middleware/` and service providers in `app/Providers/`.
- Laravel 10 has a `bootstrap/app.php` file that creates the application instance and binds kernel contracts, but does not use it for application configuration like Laravel 11:
- 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`
- When using Eloquent model casts, you must use `protected $casts = [];` and not the `casts()` method. The `casts()` method isn't available on models in Laravel 10.
=== livewire/core rules ===
## Livewire
- Use the `search-docs` tool to find exact version-specific documentation for how to write Livewire and Livewire tests.
- Use the `php artisan make:livewire [Posts\CreatePost]` Artisan command to create new components.
- State should live on the server, with the UI reflecting it.
- All Livewire requests hit the Laravel backend; they're like regular HTTP requests. Always validate form data and run authorization checks in Livewire actions.
## Livewire Best Practices
- Livewire components require a single root element.
- Use `wire:loading` and `wire:dirty` for delightful loading states.
- Add `wire:key` in loops:
```blade
@foreach ($items as $item)
{{ $item->name }}
@endforeach
```
- Prefer lifecycle hooks like `mount()`, `updatedFoo()` for initialization and reactive side effects:
public function mount(User $user) { $this->user = $user; }
public function updatedSearch() { $this->resetPage(); }
## Testing Livewire
Livewire::test(Counter::class)
->assertSet('count', 0)
->call('increment')
->assertSet('count', 1)
->assertSee(1)
->assertStatus(200);
$this->get('/posts/create')
->assertSeeLivewire(CreatePost::class);
=== livewire/v3 rules ===
## Livewire 3
### Key Changes From Livewire 2
- These things changed in Livewire 3, but may not have been updated in this application. Verify this application's setup to ensure you conform with application conventions.
- Use `wire:model.live` for real-time updates, `wire:model` is now deferred by default.
- Components now use the `App\Livewire` namespace (not `App\Http\Livewire`).
- Use `$this->dispatch()` to dispatch events (not `emit` or `dispatchBrowserEvent`).
- Use the `components.layouts.app` view as the typical layout path (not `layouts.app`).
### New Directives
- `wire:show`, `wire:transition`, `wire:cloak`, `wire:offline`, `wire:target` are available for use. Use the documentation to find usage examples.
### Alpine
- Alpine is now included with Livewire; don't manually include Alpine.js.
- Plugins included with Alpine: persist, intersect, collapse, and focus.
### Lifecycle Hooks
- You can listen for `livewire:init` to hook into Livewire initialization, and `fail.status === 419` for the page expiring:
document.addEventListener('livewire:init', function () {
Livewire.hook('request', ({ fail }) => {
if (fail && fail.status === 419) {
alert('Your session expired');
}
});
Livewire.hook('message.failed', (message, component) => {
console.error(message);
});
});
=== pint/core rules ===
## Laravel Pint Code Formatter
- You must run `vendor/bin/pint --dirty` before finalizing changes to ensure your code matches the project's expected style.
- Do not run `vendor/bin/pint --test`, simply run `vendor/bin/pint` to fix any formatting issues.
=== phpunit/core rules ===
## PHPUnit
- This application uses PHPUnit for testing. All tests must be written as PHPUnit classes. Use `php artisan make:test --phpunit {name}` to create a new test.
- If you see a test using "Pest", convert it to PHPUnit.
- Every time a test has been updated, run that singular test.
- When the tests relating to your feature are passing, ask the user if they would like to also run the entire test suite to make sure everything is still passing.
- Tests should test all of the happy paths, failure paths, and weird paths.
- 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.
### Running Tests
- Run the minimal number of tests, using an appropriate filter, before finalizing.
- To run all tests: `php artisan test --compact`.
- To run all tests in a file: `php artisan test --compact tests/Feature/ExampleTest.php`.
- To filter on a particular test name: `php artisan test --compact --filter=testName` (recommended after making a change to a related file).