What problem does it solve? Backend developers need a consistent pattern for writing read-only query use cases in Go that respect the polyglot ownership boundary, avoid unnecessary transactions, and never leak domain entities into API responses. ## Core Features & Use Cases - Query Handler Pattern: Implements the same types.Handler[I,O] interface as write use cases, but reads from repositories with plain ctx and no UnitOfWork or DomainEventRepository. - Ownership Boundary Enforcement: Ensures UI-shaped BFF queries (cross-context joins for frontend screens) stay in api-typescript, while Go handles only ctx-local reads like GetTranscodingJobStatus or ListPendingJobs. - Output Mapping & Pagination: Maps entities to primitive DTO fields with json/example/format tags, RFC3339 timestamps, and default page sizes for list queries. - Use Case: A worker needs to check whether a transcoding job finished before re-queuing it — implement a GetTranscodingJobStatus query handler that reads via the repository and returns a flat DTO. ## Quick Start Ask the AI to scaffold a Go query use case such as ListChannels with input validation, repository reads, paginated output DTOs, and fx wiring following this pattern.