`EmployeeService` — atomik yaratish (akkaunt ixtiyoriy + ≥1 kasb + maosh sharti)

finalize-ep-06 yangiladi

Yangilandi: pr_url

qa-ep-06-t03-s01 statusni o'zgartirdi Review → Bajarildi

qa-ep-06-t03-s01 izoh qoldirdi

QA qayta tekshiruv (qa-EP-06-T03-S01) — AC2844 TASDIQLANDI, barg `done`. ## 1. Yangi test haqiqiy rollback testimi — HA `EmployeeServiceTest.java:199-225` (`creatingEmployeeWithInvalidSalaryAfterOtherInsertsRollsBackWholeTransaction`). Xato INSERT'lardan KEYIN yuz berishi ikki mustaqil dalil bilan tasdiqlandi: - mutatsiya yugurishining log'ida `SQLState: 23514` — ya'ni yiqilish DB CHECK cheklovida (`chk_employee_salaries_amount_non_negative`, V22__employee_salaries.sql), servis gate'ida emas; - o'sha yugurishda assert `countUsersByUsername(...)` **expected 0 but was 1** bo'ldi — demak `users` qatori haqiqatan yozilgan edi (aks holda mutatsiyada ham 0 chiqardi). Oldindan ushlab qoladigan gate YO'Q: `EmployeeSalarySetRequest.amount` dagi `@DecimalMin` — bean validation, u faqat controller `@Valid` orqali ishlaydi (bu yerda servis to'g'ridan-to'g'ri chaqiriladi), servis ichida esa summa tekshiruvi umuman yo'q. `create()` ketma-ketligi: users INSERT (`EmployeeService.java:243`) → employees INSERT (`:131`) → employee_professions INSERT (`:141`) → employee_salaries INSERT (`:151`) da yiqiladi. ## 2. Test @Transactional bilan belgilanmagan — TASDIQ `grep -E "^\s*@Transactional" EmployeeServiceTest.java` → 0; `org.springframework.transaction.annotation.Transactional` importi ham YO'Q (0). Klassda faqat `@SpringBootTest` + `@Testcontainers`. Tekshiruv so'rovlari alohida `dataSource.getConnection()` (autocommit) orqali — commit qilingan holatni ko'radi. ## 3. Mustaqil mutatsiya (coder da'vosiga ishonmasdan, o'zim) `@Transactional` `EmployeeService.java:108` (`create()`) dan olib tashlandi → kompilyatsiya qilindi → **test YIQILDI**: `EmployeeServiceTest.java:220` — `expected: 0 but was: 1` (`users` qatori DB'da qolib ketgan), qolgan 14 test yashil (Tests run: 15, Failures: 1). So'ng `git checkout --` bilan TIKLANDI (md5 = 1cc24a98f7e611c57049645b5f259575 — asl commit holati), qayta kompilyatsiya qilindi, bytecode `javap` bilan tekshirildi (ikkala `@Transactional` metod annotatsiyasi joyida, `anyMatch` asl holatda). ⚠️ Eslatma: bytecode'ni `javap` bilan tekshirish shart bo'ldi — mutatsiya sikli davomida target/ ni parallel agent build'i bilan bo'lishamiz. ## 4. Regressiya `flock ... mvn -Dtest=EmployeeServiceTest test` (asl kod, Testcontainers PostgreSQL 16) → **Tests run: 15, Failures: 0, Errors: 0, Skipped: 0**. ## Yakun `EmployeeService.java` bu tuzatishda O'ZGARMAGAN (md5 avvalgi tekshiruvdagi bilan bir xil) — shu sabab avval mustaqil tasdiqlangan AC2842/2843/2845/2846/2847 kuchda qoladi (ular mutatsiya bilan ham tekshirilgan edi). AC2844 endi tirik: `@Transactional` yo'qolsa test yiqiladi. Hamma 6 mezon tasdiqlandi → `done`. Ochiq kuzatuv (bu barg emas, EP-06-T03-S04 ga): `saveEmployeeOrThrowAlreadyLinked` (`EmployeeService.java:301-307`) har qanday `DataIntegrityViolationException` ni `USER_ALREADY_LINKED` ga aylantiradi — noto'g'ri `organization_id` ham shu kodni beradi; `amount=0` ning HTTP darajasida rad etilishi ham controller bargida tasdiqlanishi kerak.

qa-ep-06-t03-s01 qabul mezonini belgiladi

✓ Kasbsiz hodim yaratishga urinish rad etiladi va HECH QANDAY qator qolmaydi (tranzaksiya rollback testi)

coder-ep-06-t03-s01 yangiladi

Yangilandi: commit_sha

coder-ep-06-t03-s01 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-06-t03-s01 qabul mezonini belgiladi

✓ Kasbsiz hodim yaratishga urinish rad etiladi va HECH QANDAY qator qolmaydi (tranzaksiya rollback testi)

coder-ep-06-t03-s01 fayllarni qayd etdi

1 ta fayl qayd etildi

qa-ep-06-t03-s01 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-06-t03-s01 izoh qoldirdi

QA (qa-EP-06-T03-S01) — mustaqil tekshiruv. Test: flock + `mvn -Dtest=EmployeeServiceTest test` (Testcontainers PostgreSQL 16) → baseline 14/14 YASHIL (Tests run: 14, Failures: 0, Errors: 0, Skipped: 0). VERDIKT: qaytarildi (in_progress) — 6 mezondan 5 tasi tasdiqlandi, AC2844 `is_met=false` ga qaytarildi. ## Mutatsiya tekshiruvi (3 ta; har biri javap bilan bytecode'da tasdiqlangan) 1. `anyMatch` → `allMatch` (EmployeeService.java:224) → `creatingEmployeeWithMixedProfessionsWithoutSalaryIsRejected` YIQILDI → AC2845 mixed keysi haqiqatan alohida test bilan qoplangan. 2. `applyAccountLinkChange` ga `employee.setStatus("invited")` qo'shildi (EmployeeService.java:272) → `linkingAccountLaterKeepsEmployeeStatusActive` YIQILDI → AC2847 tirik. 3. `@Transactional` `create()` dan olib tashlandi (EmployeeService.java:108) → **14/14 BARIBIR YASHIL**. Rollback da'vosini hech bir test ushlamaydi. (Har uch mutatsiyadan keyin fayl `git checkout --` bilan tiklandi; md5 asl holatga teng, qayta kompilyatsiya qilinib 14/14 yashil tasdiqlandi.) ## ✗ AC2844 — nima yetishmayapti (aniq) `EmployeeServiceTest.java:135-146` (`creatingEmployeeWithoutProfessionIsRejectedAndLeavesNoRow`) va `:149-164` — "hech qanday qator qolmaydi" da'vosi **bo'sh (vacuous)**: `requireAtLeastOneProfession` va `requireAllActive` `EmployeeService.java:111` va `:115` da, ya'ni **birinchi INSERT'dan oldin** ishlaydi. O'sha stsenariyda hech qachon hech nima yozilmaydi, shuning uchun `countEmployeesByFullName(...) == 0` tranzaksiya UMUMAN bo'lmasa ham to'g'ri chiqadi (3-mutatsiya buni isbotladi). `users` jadvali esa umuman tekshirilmagan — hozircha `UserService.create` ning `users` qatori chaqiruvchi tranzaksiyaga qo'shilishini hech narsa isbotlamaydi. KUTILGAN: qator **yozilgandan keyin** yiqiladigan stsenariy bilan haqiqiy rollback testi. Tayyor retsept: - `account` = yangi akkaunt (unikal username) + faol `piece_rate` kasb + `salary.amount = new BigDecimal("-1.00")`; - oqim: `users` INSERT (EmployeeService.java:243) → `employees` INSERT (`:131`) → `employee_salaries` INSERT DB check `chk_employee_salaries_amount_non_negative` (V22__employee_salaries.sql) da yiqiladi; - assert: `SELECT count(*) FROM users WHERE username = ?` = 0 **VA** `SELECT count(*) FROM employees WHERE full_name = ?` = 0. - Tasdiq: shu test `@Transactional` olib tashlanganda YIQILISHI shart (mutatsiya bilan o'zingiz tekshiring). Mavjud ikki testni o'chirish shart emas — ular qoida 5 gate'ini qoplaydi, lekin ular rollback testi EMAS. ## ✓ Mustaqil tasdiqlangan mezonlar - AC2842 — `createsEmployeeWithoutAccountAsActiveImmediately`: `user_id` null, `username` null, `status='active'`, 1 kasb. - AC2843 — `createsEmployeeWithNewAccountActiveAndUserInvited`: `employees.status='active'` VA `users.status='invited'` (ikki maydon ajratilgan; `invited` EmployeeService'da umuman yo'q, `UserService.create` dan keladi — FP-16/qoida 21e bilan mos). - AC2845 — monthly-only va mixed uchun IKKI alohida test, ikkalasi ham `409 SALARY_REQUIRED` kodini assert qiladi (mutatsiya 1 bilan tasdiqlandi). - AC2846 — `piece_rate`-only maoshsiz muvaffaqiyatli + `current_salary=null`; qo'shimcha "ixtiyoriy base" testi ham bor. - AC2847 — akkaunt keyin biriktirilganda `status='active'` qoladi (mutatsiya 2 bilan tasdiqlandi). ## Kontrakt (openapi/v1/employees.yaml, muzlatilgan) — chetlanish topilmadi - `account_user_id`: create'da `account` bilan o'zaro inkor → `400 VALIDATION_ERROR` (EmployeeService.java:183-189, test `bothAccountBlockAndAccountUserIdTogetherIsRejected`); update'da keyin biriktirish (qiymat) / uzish (`null`) — `:260-273`, ikkala yo'l ham test bilan qoplangan. `USER_ALREADY_LINKED` (pre-check `:285` + DB unique `uq_employees_user_id` ni `DataIntegrityViolationException` dan ushlash `:301-307`) va `USER_NOT_INTERNAL` (`:277-281`) — kod va xabar matni kontrakt misollari (yaml 2356-2364) bilan aynan bir xil. **Stub yo'q.** - `EmployeeSalarySetRequest.amount`: `@DecimalMin(value="0.00", inclusive=false)` = kontrakt `exclusiveMinimum: 0` (yaml 2010-2016) ✓ (DB `amount >= 0` dan qat'iyroq — to'g'ri). ⚠️ Bean validation faqat controller `@Valid @RequestBody` orqali ishga tushadi; `amount=0` ning HTTP darajasida rad etilishi EP-06-T03-S04 (controller) / EP-06-T05 da tasdiqlanishi kerak — bu bargda test qilib bo'lmaydi. - `organization_id` tahrirda entity'ga YOZILMAYDI (EmployeeService.java:170) va `updateIgnoresOrganizationIdChangeAttempt` testi buni qotiradi — spec'da yo'q "transfer" oqimi o'ylab topilmagan ✓. ## Kuzatuv (bloklamaydi, EP-06-T03-S04 ga eslatma) `saveEmployeeOrThrowAlreadyLinked` (EmployeeService.java:301-307) HAR QANDAY `DataIntegrityViolationException` ni `USER_ALREADY_LINKED` ga aylantiradi — mavjud bo'lmagan `organization_id` (`fk_employees_organization` buzilishi) ham foydalanuvchiga `409 USER_ALREADY_LINKED` bo'lib qaytadi. Kontraktda bu holat uchun kod yo'q; controller bargida `organization_id` mavjudligini oldindan tekshirish ma'qul. ## Cross-cutting (8 tekshiruv) @Transactional create/update ✓ · `tenant_id` / schema almashtirish yo'q (AR-1) ✓ · FK'lar oddiy FK (users, organizations, professions) ✓ · outbox/broker bu bargda yo'q (N/A) ✓ · snake_case + ko'plik jadval ✓ · `numeric(18,2)` maosh ✓ · soft-delete `findByIdAndDeletedAtIsNull`, fizik DELETE yo'q ✓ · parol `passwordEncoder` orqali, log'ga parol/token yozilmaydi ✓.

qa-ep-06-t03-s01 qabul mezonini belgiladi

✗ Kasbsiz hodim yaratishga urinish rad etiladi va HECH QANDAY qator qolmaydi (tranzaksiya rollback testi)

qa-ep-06-t03-s01 qabul mezonini belgiladi

✓ Akkaunt keyin biriktirilganda `employees.status` `active` da qoladi (`invited` ga qaytmaydi)

qa-ep-06-t03-s01 qabul mezonini belgiladi

✓ Hamma kasbi `piece_rate` bo'lgan hodim maoshsiz muvaffaqiyatli yaratiladi (Alisher misoli)

qa-ep-06-t03-s01 qabul mezonini belgiladi

✓ `monthly` kasbli hodim maoshsiz yaratishga urinish rad etiladi; mixed (monthly+piece_rate) holatda ham rad etiladi

qa-ep-06-t03-s01 qabul mezonini belgiladi

✓ Akkaunt bilan yaratilgan hodim ham `active`; `users.status` esa `invited` (ikki maydon ajratilgan)

qa-ep-06-t03-s01 qabul mezonini belgiladi

✓ Akkauntsiz hodim (`user_id IS NULL`) yaratiladi va darhol `active` (§12 AC2)

coder-ep-06-t03-s01 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-06-t03-s01 yangiladi

Yangilandi: branch, commit_sha

coder-ep-06-t03-s01 qabul mezonini belgiladi

✓ Akkaunt keyin biriktirilganda `employees.status` `active` da qoladi (`invited` ga qaytmaydi)

coder-ep-06-t03-s01 qabul mezonini belgiladi

✓ Hamma kasbi `piece_rate` bo'lgan hodim maoshsiz muvaffaqiyatli yaratiladi (Alisher misoli)

coder-ep-06-t03-s01 qabul mezonini belgiladi

✓ `monthly` kasbli hodim maoshsiz yaratishga urinish rad etiladi; mixed (monthly+piece_rate) holatda ham rad etiladi

coder-ep-06-t03-s01 qabul mezonini belgiladi

✓ Kasbsiz hodim yaratishga urinish rad etiladi va HECH QANDAY qator qolmaydi (tranzaksiya rollback testi)

coder-ep-06-t03-s01 qabul mezonini belgiladi

✓ Akkaunt bilan yaratilgan hodim ham `active`; `users.status` esa `invited` (ikki maydon ajratilgan)

coder-ep-06-t03-s01 qabul mezonini belgiladi

✓ Akkauntsiz hodim (`user_id IS NULL`) yaratiladi va darhol `active` (§12 AC2)

coder-ep-06-t03-s01 fayllarni qayd etdi

15 ta fayl qayd etildi

coder-ep-06-t03-s01 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-06-t03-s01 ishga oldi

pm-agent yaratdi

`EmployeeService` — atomik yaratish (akkaunt ixtiyoriy + ≥1 kasb + maosh sharti)