docs: define repository pattern boundary

examples/DECISIONS.example.md

@@ -148,3 +148,55 @@ Enforce authorization in backend policies for all sensitive actions.
 - Frontend checks remain usability hints only.
 - Authorization tests are required for each protected workflow.
 - Policy changes must be reviewed as security-sensitive changes.
+
+## ADR-004: Use Repository Pattern For Persistence Boundaries
+
+### Status
+
+Accepted
+
+### Date
+
+2026-06-28
+
+### Context
+
+Atlas Desk uses PostgreSQL and Entity Framework Core, but request workflow rules
+should not depend directly on ORM APIs or database-specific query details.
+
+### Problem
+
+Direct persistence access from application services would make workflow logic
+harder to test and increase coupling to storage implementation details.
+
+### Alternatives
+
+| Alternative | Summary |
+| --- | --- |
+| Direct database context access | Simple, but spreads persistence concerns through application logic. |
+| Generic repository | Hides the ORM, but exposes low-value CRUD abstractions. |
+| Domain-specific repositories | Keeps persistence behind workflow-focused interfaces. |
+
+### Pros
+
+- Keeps workflow services focused on use cases.
+- Makes request assignment and audit behavior easier to test.
+- Provides intention-revealing query methods.
+- Allows persistence implementation changes without rewriting domain logic.
+
+### Cons
+
+- Adds interface and implementation classes.
+- Requires discipline to avoid generic CRUD repositories.
+- Complex queries still need explicit performance review.
+
+### Decision
+
+Use domain-specific repositories for persistence boundaries.
+
+### Consequences
+
+- `RequestRepository` owns request persistence operations.
+- `UserRepository` owns user lookup persistence operations.
+- Reporting uses explicit read queries instead of mutating request data.
+- Transaction boundaries remain visible in application services.