Code rabbit config

Author: tatevikg1

.coderabbit.yaml

@@ -9,33 +9,40 @@ reviews:
   high_level_summary_in_walkthrough: false
   poem: false
   path_instructions:
-      - path: "src/Domain/**"
-        instructions: |
-          You are reviewing PHP domain-layer code. Enforce strict domain purity:
-          - ❌ Do not allow infrastructure persistence side effects here.
-          - Flag ANY usage of Doctrine persistence APIs, especially:
-          - $entityManager->flush(...), $this->entityManager->flush(...)
-          - $em->persist(...), $em->remove(...)
-          - direct transaction control ($em->beginTransaction(), commit(), rollback())
-          - If found, request moving these calls to application-layer Command handlers or background Jobs.
-          - Also flag repositories in Domain that invoke flush/transactional logic; Domain repositories should be abstractions without side effects.
-          - Encourage domain events/outbox or return-values to signal write-intent, leaving orchestration to Commands/Jobs.
-          - Only exception to this rule is when the service is orchestrating multiple domain services with complex use cases
+    - path: "src/Domain/**"
+      instructions: |
+        You are reviewing PHP domain-layer code. Enforce strict domain purity:
+        - ❌ Do not allow persistence or transaction side effects here.
+        - Flag ANY usage of Doctrine persistence APIs, especially:
+          - `$entityManager->flush(...)`, `$this->entityManager->flush(...)`
+          - `$em->persist(...)`, `$em->remove(...)`
+          - `$em->beginTransaction()`, `$em->commit()`, `$em->rollback()`
+        - ✅ Accessing Doctrine *metadata*, *schema manager*, or *read-only schema info* is acceptable
+          as long as it does not modify state or perform writes.
+        - ⚠️ If code is invoking actual table-creation, DDL execution, or schema synchronization,
+          then request moving that to the Infrastructure or Application layer (e.g. MessageHandler).
+        - Also flag repositories in Domain that invoke flush/transactional logic;
+          Domain repositories should be abstractions without side effects.
+        - Encourage using domain events or return-values to signal intent to write,
+          leaving persistence orchestration to Commands/Jobs.
 
-      - path: "src/**/Command/**"
-        instructions: |
-          Application layer (Commands/Handlers) is the right place to coordinate persistence.
-          - ✅ It is acceptable to call $entityManager->flush() here.
-          - Check that flush is used atomically (once per unit of work) after all domain operations.
-          - Ensure no domain entity or domain service is calling flush; only the handler orchestrates it.
-          - Prefer $em->transactional(...) or explicit try/catch with rollback on failure.
+    - path: "src/**/Command/**"
+      instructions: |
+        Application layer (Commands/Handlers) is the right place to coordinate persistence.
+        - ✅ It is acceptable to call $entityManager->flush() here.
+        - Check that flush is used atomically (once per unit of work) after all domain operations.
+        - Ensure no domain entity or domain service is calling flush; only the handler orchestrates it.
+        - Prefer $em->transactional(...) or explicit try/catch with rollback on failure.
 
-      - path: "src/**/MessageHandler/**"
-        instructions: |
-          Background jobs/workers may perform persistence.
-          - ✅ Allow $entityManager->flush() here when the job is the orchestration boundary.
-          - Verify idempotency and that flush frequency is appropriate (batching where practical).
-          - Ensure no domain-layer code invoked by the job performs flush/transaction control.
+    - path: "src/**/MessageHandler/**"
+      instructions: |
+        Background jobs/workers may perform persistence and schema management.
+        - ✅ Allow `$entityManager->flush()` when the job is the orchestration boundary.
+        - ✅ Allow table creation, migration, or schema synchronization (e.g. via Doctrine SchemaTool or SchemaManager),
+          as this is considered infrastructure-level orchestration.
+        - Verify idempotency for schema operations — e.g., check if a table exists before creating.
+        - Ensure domain-layer code invoked by the job remains free of persistence calls.
+        - Batch flush operations where practical.
 
   auto_review:
     enabled: true