labrodev-infrastructurelisted

# Infrastructure: adapters between the Domain and the outside world Part of the Labrodev playbook. **The law for this component lives in the always-on `labrodev-infrastructure` guideline** (musts, must-nots); the per-file checklist is `rules/infrastructure.md`. This skill holds the craft: anatomy, canonical templates, and edge cases. Four pieces make up the pattern: a **contract** the Domain depends on, one **adapter** per vendor implementing it, a **resolver** for when the vendor is chosen at runtime, and a **boundary DTO** mapping vendor payloads into Domain-friendly shapes. Splitting it this way means adding or swapping a vendor never touches Domain code. ## The pattern: contract → adapters → resolver Worked example — one messaging capability, several vendors: ``` Core/Infrastructure/Messaging/ ├── Contracts/ │ └── MessageNotifier.php the capability contract ├── SlackNotifier.php per-vendor adapter ├── TelegramNotifier.php per-vendor adapter ├── MessageNotifierResolver.php picks the adapter by domain enum └── OutboundMessagePayload.php boundary DTO (final readonly) ``` ### Contract ```php <?php declare(strict_types=1); namespace Core\Infrastructure\Messaging\Contracts; use Core\Infrastructure\Messaging\OutboundMessagePayload; interface MessageNotifier { public function send(OutboundMessagePayload $outboundMessagePayload): void; } ``` ### Boundary DTO ```php <?php declare(strict_types=1); namespace Core\Inf