docs: define repository pattern boundary

examples/ARCHITECTURE.example.md

@@ -78,6 +78,19 @@ atlas-desk/
 - Domain rules do not depend on HTTP, Vue, or database APIs.
 - Infrastructure implementations depend inward on application contracts.
 
+## Persistence Boundary
+
+Atlas Desk uses the repository pattern for persistence boundaries.
+
+- Repository interfaces live in the owning backend module.
+- Repository implementations live in the module's infrastructure or persistence
+  folder.
+- Repositories are domain-specific, such as `RequestRepository` and
+  `UserRepository`.
+- Application services coordinate transactions for workflows that write multiple
+  records, such as assignment plus audit event creation.
+- Generic CRUD repositories are not used because they hide workflow intent.
+
 ## Request Flow
 
 ```mermaid

examples/CONVENTIONS.example.md

@@ -57,6 +57,10 @@
 
 ## Repository Rules
 
+- Use the repository pattern for persistence boundaries.
+- Keep repository interfaces in the owning backend module.
+- Keep repository implementations near persistence infrastructure.
+- Use specific repositories such as `RequestRepository` and `UserRepository`.
 - Keep queries explicit, such as `FindOpenRequestsForQueue`.
 - Do not add generic repository abstractions over the database context.
 - Write operations that can be retried must be idempotent or transactionally protected.

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.