php-feature-slicelisted

# PHP Feature Slice Architecture > "The best code is code that never has to be written." > -- Jeff Atwood > "Organize around business capabilities, not technical layers." > -- Sam Newman, *Building Microservices* ## Core Philosophy Feature slice architecture organizes code by business capability, not by technical layer. Laravel's default skeleton is layer-based — `app/Http/Controllers`, `app/Models`, `app/Services` spread one feature across many directories. This skill replaces that with self-contained vertical slices: `app/Features/Orders/`, `app/Features/Users/`, each owning its full stack — controller, Form Request, service, API Resource, and tests. In PHP with Laravel, the mediator pattern (FreeMediator in .NET) is replaced by Laravel's **service container**. Service classes are constructor-injected into controllers; the container resolves them automatically. CQRS separation is a structural and naming convention — `OrderReadService` vs `OrderWriteService` — not a library contract. **Non-Negotiable Constraints:** 1. **`declare(strict_types=1)`** at the top of every PHP file 2. **Feature isolation** — no cross-feature imports; features communicate through shared domain code only 3. **Service layer owns business logic** — controllers are thin; no business logic in controllers 4. **Form Requests for all input** — never trust raw `$request->input()`; validation lives in `FormRequest::rules()` 5. **API Resources for all output** — never return Eloquent models directly fro