architecturelisted

# Architecture Use Laravel conventions before adding custom architecture. A good default request path is: ```text Route -> Controller -> Form Request -> Action/Service -> Eloquent/Integration -> Response ``` Do not force every layer into every feature. Add a boundary only when it makes behavior easier to test, reuse, reason about, or change. For multi-menu dashboards, admin systems, or copied prototype apps, also use `module-per-menu`: default to one menu or page per module, small controllers, per-page views, shared layouts/components, and DB-backed dynamic data. ## Layer Decisions Use a controller for HTTP orchestration: - receive the request; - delegate validation and authorization; - call the application workflow; - return redirect, response, resource, view, or stream. Use a Form Request when validation or authorization is complex, reused, or important enough to test independently. Use an Action when a single use case needs a named command-style object. Use a Service when a workflow coordinates multiple models, integrations, files, jobs, events, generated documents, or transactional writes. Use a Policy or Gate for authorization rules. Keep authorization close to the boundary, but do not bury model-state rules in routes. ## Avoid Overengineering Do not add repositories, interfaces, DTOs, feature folders, or value objects by default. Duplication alone is not sufficient reason to create a service, action, or class. Prefer local reuse or a small extraction when