fix: clarify Laravel infrastructure boundary

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

@@ -28,10 +28,18 @@ description: >-
   `does...` only for methods that return `bool` and do not throw.
 
 ## Rule: Hexagonal Architecture
-Follow hexagonal architecture as the baseline. Apply these project conventions on top of it:
+Follow hexagonal architecture as the baseline.
 
-- Organize each module as `Domain`, `Application`, and `Infrastructure`;
+- Organize each business module in `src` as `Domain`, `Application`, and `Infrastructure`;
   dependencies point inward only.
+- Put all business rules and decisions in `Domain`.
+- Use `Application` only for use-case orchestration, transaction boundaries,
+  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.
 - 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/laravel-standards/SKILL.md

@@ -8,9 +8,14 @@ description: >-
 
 # Laravel Standards
 
-Laravel is only the delivery and composition layer: collect input, run
-delivery/form/frontend validation for shape and UX only, invoke a
-`src/.../Application/UseCase`, and map the result back to the framework
-response. Do not put business rules, use-case orchestration, domain decisions,
-persistence logic, or infrastructure adapter behavior in Laravel delivery code;
-those belong in `src` according to the hexagonal architecture rule.
+- Treat Laravel as infrastructure only.
+- Use Laravel only for HTTP/UI, console commands, scheduled tasks, queue
+  workers, events, service providers, and runtime integrations.
+- Do not create `Domain` or `Application` layers inside Laravel.
+- Do not put business rules, domain decisions, use-case orchestration, workflow
+  branching, pricing, eligibility, state transitions, persistence decisions, or
+  policy decisions in Laravel.
+- Keep Laravel controllers, requests, commands, jobs, listeners, middleware,
+  providers, models, and other framework code limited to input collection,
+  delivery validation, `src` entrypoint calls, and framework output mapping.
+- Put business and application behavior in `src`.