feat: centralize Laravel architecture policy

plugins/engineering-playbook/skills/code-review/SKILL.md

@@ -26,21 +26,13 @@ Use those standards as hard review criteria, not background suggestions.
 3. Read surrounding code until the intent, call paths, data flow, side effects,
    and failure behavior are clear. Do not review a line in isolation when nearby
    code changes its meaning.
-4. When `laravel-standards` applies, perform an explicit Laravel boundary audit
-   for every changed Laravel delivery file. Review the final file contents line
-   by line, not only the diff hunks. Check controllers, commands, jobs,
-   listeners, middleware, requests, policies, resources, providers, and other
-   framework classes for business rules, workflow branching, use-case
-   orchestration, domain decisions, transaction boundaries, Eloquent/query
-   builder/`DB`/repository calls, and framework-side persistence decisions. If
-   any are present, report a `Blocker` finding with the exact file and line. Do
-   not conclude the review until this audit is complete.
+4. When `laravel-standards` applies, audit the final contents of every changed
+   Laravel delivery file against it, not only the diff hunks. Report every
+   violation as a `Blocker` finding with the exact file and line. Do not
+   conclude the review until this audit is complete.
 5. Check the implementation against:
    - coding standards and hexagonal architecture rules
    - Laravel delivery-layer boundaries and framework conventions
-   - any business logic, application orchestration, or direct persistence calls
-     in Laravel controllers, commands, jobs, listeners, middleware, requests,
-     policies, resources, or providers
    - functional correctness against the requested behavior
    - security, authorization, validation, escaping, secrets, and data exposure
    - edge cases, null/empty states, invalid input, missing records, partial failures, and retries
@@ -69,12 +61,6 @@ Before finalizing, re-read each finding and confirm:
 - every Laravel boundary violation is reported as `Blocker`
 - the output follows the required format below
 
-Any new or expanded business rule, use-case orchestration, workflow branching,
-domain decision, transaction boundary, or direct database/query/repository call
-inside Laravel delivery code is a `Blocker` finding. The fix is to move that
-behavior into `src` under the application or domain layer and call one explicit
-application use case from Laravel.
-
 ## Output Format
 
 Lead with numbered findings ordered by severity. Each finding must include:

plugins/engineering-playbook/skills/coding-standards/SKILL.md

@@ -57,9 +57,9 @@ Follow hexagonal architecture as the baseline.
   authorization handoff, domain calls, ports, and input/output mapping.
 - Use `Infrastructure` only for adapters such as persistence, queues, HTTP
   clients, framework integration, and serialization.
-- Treat framework applications, including Laravel apps, as infrastructure
-  adapters only; do not create or hide `Domain`, `Application`, business rules,
-  or use-case orchestration there.
+- Treat framework applications as infrastructure adapters only; do not create
+  or hide `Domain`, `Application`, business rules, or use-case orchestration
+  there.
 - Use cases live under `<Module>/Application/UseCase`, start with a verb, end
   with `UseCase`, do one user-intent only, and expose exactly one public method:
   `__invoke`. For example, use `CreateUserUseCase`, not

plugins/engineering-playbook/skills/development/SKILL.md

@@ -29,13 +29,12 @@ source of truth.
    implementation.
 3. Ask only blocking questions. If the request is clear enough to implement,
    start without waiting.
-4. Before touching Laravel delivery code, name the `src` application use case
-   that owns the behavior. If the use case does not exist, create or update it
-   first; keep controllers, commands, jobs, listeners, and middleware limited to
-   delivery wiring and response mapping.
-5. Make the smallest maintainable change that satisfies the request. Follow
-   existing patterns, coding standards, and Laravel delivery-layer boundaries.
-6. Add or update focused tests when behavior changes or regression risk justifies
+4. Choose an implementation that supports long-term maintainability and
+   satisfies the request. If a broader refactor would materially improve the
+   result, outline the option and ask the user whether to include it before
+   expanding scope. Follow existing patterns and the standards loaded for the
+   affected code.
+5. Add or update focused tests when behavior changes or regression risk justifies
    it.
 
 ## Review Gate