diff --git a/DbFirst.Application/Catalogs/CatalogService.cs b/DbFirst.Application/Catalogs/CatalogService.cs
index 98c3b49..65a4946 100644
--- a/DbFirst.Application/Catalogs/CatalogService.cs
+++ b/DbFirst.Application/Catalogs/CatalogService.cs
@@ -5,6 +5,22 @@ using DbFirst.Domain.Entities;
 namespace DbFirst.Application.Catalogs;
 
 //TODO: create generic service to reduce code duplication
+
+/* Copilot's Response:
+A generic CRUD base service adds little value in your case:
+
+Pros:
+• Less boilerplate for simple entities without special logic.
+• Uniform CRUD signatures.
+
+Cons/Practical here:
+• Domain logic differs per entity(unique title check, setting audit fields, forbidding title changes, stored procs with output GUID).
+• Generic services tend to be diluted by virtual methods/hooks for special cases—ending up with per-entity overrides and little real gain.
+• With stored procedures and output parameters, the pattern doesn’t fit cleanly because operations aren’t symmetric (separate procs for insert/update/delete).
+
+Conclusion: For this solution a generic service would be more overhead than benefit. If you later have multiple very similar entities without special logic,
+you could consider a lightweight generic interface/base; for now, the specialized service implementation is cleaner. */
+
 //TODO: implement CQRS pattern with MediatR
 public class CatalogService : ICatalogService
 {
diff --git a/DbFirst.Application/Catalogs/ICatalogService.cs b/DbFirst.Application/Catalogs/ICatalogService.cs
index d7fa862..d5e19c1 100644
--- a/DbFirst.Application/Catalogs/ICatalogService.cs
+++ b/DbFirst.Application/Catalogs/ICatalogService.cs
@@ -1,6 +1,22 @@
 namespace DbFirst.Application.Catalogs;
 
 //TODO: create generic service to reduce code duplication
+
+/* Copilot's Response:
+A generic CRUD base service adds little value in your case:
+
+Pros:
+• Less boilerplate for simple entities without special logic.
+• Uniform CRUD signatures.
+
+Cons/Practical here:
+• Domain logic differs per entity(unique title check, setting audit fields, forbidding title changes, stored procs with output GUID).
+• Generic services tend to be diluted by virtual methods/hooks for special cases—ending up with per-entity overrides and little real gain.
+• With stored procedures and output parameters, the pattern doesn’t fit cleanly because operations aren’t symmetric (separate procs for insert/update/delete).
+
+Conclusion: For this solution a generic service would be more overhead than benefit. If you later have multiple very similar entities without special logic,
+you could consider a lightweight generic interface/base; for now, the specialized service implementation is cleaner. */
+
 public interface ICatalogService
 {
     Task<List<CatalogReadDto>> GetAllAsync(CancellationToken cancellationToken = default);
diff --git a/DbFirst.Infrastructure/Repositories/CatalogRepository.cs b/DbFirst.Infrastructure/Repositories/CatalogRepository.cs
index 9dba532..ae2d299 100644
--- a/DbFirst.Infrastructure/Repositories/CatalogRepository.cs
+++ b/DbFirst.Infrastructure/Repositories/CatalogRepository.cs
@@ -15,21 +15,6 @@ namespace DbFirst.Infrastructure.Repositories;
 
 // TODO: instead of creating implementation of repository per entity, consider using generic repository pattern (eg. Repository<T>) to reduce code duplication.
 
-/* Copilot's Response:
-A generic CRUD base service adds little value in your case:
-
-Pros:
-• Less boilerplate for simple entities without special logic.
-• Uniform CRUD signatures.
-
-Cons/Practical here:
-• Domain logic differs per entity(unique title check, setting audit fields, forbidding title changes, stored procs with output GUID).
-• Generic services tend to be diluted by virtual methods/hooks for special cases—ending up with per-entity overrides and little real gain.
-• With stored procedures and output parameters, the pattern doesn’t fit cleanly because operations aren’t symmetric (separate procs for insert/update/delete).
-
-Conclusion: For this solution a generic service would be more overhead than benefit. If you later have multiple very similar entities without special logic,
-you could consider a lightweight generic interface/base; for now, the specialized service implementation is cleaner. */
-
 public class CatalogRepository : ICatalogRepository
 {
     private readonly ApplicationDbContext _db;