Holat mashinasi (§4) + 09_auth akkaunt sinxroni (bir tranzaksiyada)

finalize-ep-06 yangiladi

Yangilandi: pr_url

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

QA qayta tekshiruv (qa-EP-06-T03-S03) — commit c178872. Tuzatish FAQAT EmployeeStatusServiceTest.java ga tegdi; mahsulot kodi (EmployeeStatusService, UserService, JwtAuthenticationFilter) o'zgarmagan -> oldingi turda tasdiqlangan 2852/2854/2855/2857/2858 kuchda qoladi. AC2853 va AC2856 mustaqil qayta sinaldi. AC2853 = true. Mutatsiya: JwtAuthenticationFilter.java:93 dagi `.filter(profile -> isNotRevokedByTokenValidAfter(claims, profile))` olib tashlandi (javap: authenticate() da Optional.filter 1 marta qoldi — bytecode'da tasdiqlangan). Natija: oldAccessTokenIsRejectedByTokenValidAfterAloneEvenAfterUserStatusReturnsToActive:212 YIQILDI — expected: 401 UNAUTHORIZED but was: 200 OK. Aynan shu "200 OK" izolyatsiya haqiqiy ekanini isbotlaydi: suspend -> activate dan keyin users.status='active' (ALLOWED_STATUSES = {active, invited}), ya'ni status filtri RUXSAT BERADI va 401 ning YAGONA manbai token_valid_after (R27). Oldingi turda aynan shu mutatsiya testni yashil qoldirgan edi — endi o'ldiradi. Eslatma (bloklamaydi): e2e "fire -> eski token 401" endi bitta testda emas, ikkiga bo'lingan — fire() token_valid_after va barcha sessiyani yozishi AC2852 da DB darajasida, R27 ning rad etish oyog'i AC2853 da. Qamrov to'liq: fire holatida users.status='blocked' (ALLOWED_STATUSES da yo'q) qo'shimcha rad etuvchi filtr, ya'ni suspend/activate keysi qat'iyroq (zaifroq shart bilan) sinov. AC2856 = true, ikki bosqichda: (a) So'ralgan mutatsiya — EmployeeStatusService.java:107 `if (userId != null)` gate'i olib tashlandi (javap: transition() da getUserId dan keyin ifnull YO'Q). changingStatusOfEmployeeWithoutAccountDoesNotTouchUsersOrSessions:336 YIQILDI (NotFoundException: user topilmadi: id=null). (b) Kuchliroq sinov — "jim ravishda NOTO'G'RI qatorni yozish" (COUNT hech qachon o'zgarmaydigan regressiya): gate olib tashlangan holda UserService.blockAccountForEmployeeSync null'da birinchi faol userni oladigan qilib mutatsiya qilindi (javap: metodda UserRepository.findAll bor). Natija — assertBystanderAccountUntouched:356 YIQILDI: expected "active" but was "blocked". Ya'ni yangi assert'lar begona qatorning MAZMUNINI (status/revoked_at/ token_valid_after/revoked_reason) haqiqatan solishtiradi; eski "0 == 0" COUNT varianti bu regressiyani o'tkazib yuborardi. Barcha mutatsiyalar git checkout bilan tiklandi (`grep QA-MUT` bo'sh, git diff bo'sh). Yakuniy regressiya: EmployeeStatusServiceTest 10/10 yashil, BUILD SUCCESS. docs/ va openapi/ ga tegilmadi. Mezonlar 7/7 -> done.

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

✓ Akkauntsiz (`user_id IS NULL`) hodimning holati muammosiz o'zgaradi, `users`/`user_sessions` ga tegilmaydi

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

✓ Bo'shatilgandan keyin eski access token bilan so'rov ≤60 s ichida rad etiladi (09_auth R27 mexanizmi bilan juft test)

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

QA qaytargan 2 soxta test tuzatildi: AC2853 (R27 mexanizmi endi users.status filtridan izolyatsiya qilingan — suspend to activate ssenariysi orqali) va AC2856 (begona users/user_sessions qatorining mazmuni tekshiriladi, faqat COUNT emas). Ikkalasi ham qolda mutatsiya bilan tasdiqlandi: JwtAuthenticationFilter:93 R27 filtri va userId != null gate olib tashlanganda mos test yiqildi, keyin tiklandi. 10/10 test yashil. Boshqa 8 test va mahsulot kodi (JwtAuthenticationFilter, UserService, EmployeeStatusService) tegilmadi.

coder-ep-06-t03-s03 yangiladi

Yangilandi: commit_sha

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

✓ Akkauntsiz (`user_id IS NULL`) hodimning holati muammosiz o'zgaradi, `users`/`user_sessions` ga tegilmaydi

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

✓ Bo'shatilgandan keyin eski access token bilan so'rov ≤60 s ichida rad etiladi (09_auth R27 mexanizmi bilan juft test)

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

1 ta fayl qayd etildi

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

QA (qa-EP-06-T03-S03) — mustaqil tekshiruv, mutatsiya sinovlari bilan. Baza: 10/10 yashil. O'TDI (mutatsiya bilan tasdiqlangan, har biri javap orqali bytecode'da isbotlandi): - AC2855 ✅ HAQIQIY ROLLBACK. EmployeeStatusService.java:68/74/86 dan @Transactional olib tashlandi -> firingLastActiveOwnerEmployeeReturns409AndRollsBackEmployeeAndUserStatus:253 YIQILDI: expected "active" but was "fired". Sabab: transition() saveAndFlush ni (satr 104) R36 tekshiruvidan OLDIN bajaradi -> "status o'zgarmagan" da'vosi haqiqatan tranzaksiyani isbotlaydi. S01 dagi soxta naqsh bu yerda YO'Q. - AC2852 ✅ revokeAllSessions reason "suspended"->"blocked" mutatsiyasi ushlandi (:155). - AC2854 ✅ ALLOWED_TRANSITIONS ga fired->active qo'shilganda test yiqildi (:197). - AC2857 ✅ reactivateAccountForEmployeeSync setStatus("active")->"blocked" ushlandi (:315). - AC2858 ✅ actorType("system")->"user" ushlandi (:334). QAYTARILDI: 1) AC2853 = false — test R27 mexanizmini AJRATMAYDI. Dalil: JwtAuthenticationFilter.java:93 dagi `.filter(profile -> isNotRevokedByTokenValidAfter(claims, profile))` BUTUNLAY olib tashlandi (javap: authenticate() da Optional.filter faqat 1 marta qoldi) -> firedEmployeeOldAccessTokenIsRejectedWithinCacheWindow BARIBIR YASHIL (BUILD SUCCESS). Ya'ni 401 to'liq `users.status='blocked'` (ALLOWED_STATUSES) filtridan keladi; token_valid_after oyog'i o'lik bo'lsa ham test buni ko'rmaydi. Mezon matni esa aynan "R27 mexanizmi bilan juft test" deydi. Aniq tuzatish (EmployeeStatusServiceTest.java:162-181): fire() dan KEYIN JDBC bilan `UPDATE users SET status='active' WHERE id=?` qilib status oyog'ini ataylab NEYTRALLASHTIRING (token_valid_after o'z joyida qoladi), clearAllCaches(), so'ng /auth/me -> 401 kutilsin. Shunda 401 faqat token_valid_after (R27) tufayli bo'ladi. Qo'shimcha: fire() dan KEYIN chiqarilgan yangi token 200 berishi ham tekshirilsa, R27 ning "iat < token_valid_after" chegarasi to'liq qamraladi. 2) AC2856 = false — "users/user_sessions ga tegilmaydi" da'vosi isbotlanmagan. Test (EmployeeStatusServiceTest.java:280-294) faqat countAll("users") / countAll("user_sessions") ni solishtiradi, lekin @BeforeEach TRUNCATE tufayli bu testda ikkala jadval BO'SH (0 == 0) — ya'ni "tegilmadi" tekshiruvi bo'sh yuradi va mavjud qatorni O'ZGARTIRADIGAN (UPDATE) regressiyani prinsipial ravishda ushlay olmaydi (COUNT o'zgarmaydi). Kod tomoni to'g'ri: `if (userId != null)` guard bor va mutatsiya ushlanadi (guard olib tashlanganda test "NotFoundException: user topilmadi: id=null" bilan yiqildi), lekin bu faqat exception bor/yo'qligini isbotlaydi. Aniq tuzatish: testga ALOQASIZ bitta user + sessiya kiriting (insertUser/insertSession), suspend/fire dan OLDIN uning status · token_valid_after · revoked_at qiymatlarini o'qing va amaldan KEYIN AYNAN o'sha qiymatlar o'zgarmaganini assert qiling (haqiqiy oldingi/keyingi solishtiruv, count emas). Kontrakt (openapi/v1/employees.yaml, MUZLATILGAN) — moslik OK: INVALID_STATUS_TRANSITION / LAST_OWNER_REQUIRED yozilishi va 409 mapping'i (GlobalExceptionHandler.java:96) kontraktdagi EmployeeStatusConflict bilan mos; revoked_reason='suspended' suspend VA fire uchun bir xil (yaml 665, qoida 21c); fired manba sifatida jadvalda umuman yo'q -> fired->suspended ham 409. Kontrakt/docs O'ZGARTIRILMADI. Barcha mutatsiyalar git checkout bilan tiklandi (yakuniy tekshiruv: EmployeeStatusServiceTest 10/10 yashil, BUILD SUCCESS). Kichik kuzatuvlar (bloklamaydi): (a) fired->suspended uchun alohida test yo'q (mantiq jadval asosli, qamrov bilvosita); (b) blockAccountForEmployeeSync soft-delete qilingan users qatorida NotFoundException (404) beradi — kontraktda bu holat hujjatlanmagan.

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

✗ Akkauntsiz (`user_id IS NULL`) hodimning holati muammosiz o'zgaradi, `users`/`user_sessions` ga tegilmaydi

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

✗ Bo'shatilgandan keyin eski access token bilan so'rov ≤60 s ichida rad etiladi (09_auth R27 mexanizmi bilan juft test)

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

✓ Sinxron qadamlar `auth_logs` ga `actor_type='system'` bilan yoziladi (09_auth E16)

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

✓ `suspended → active` da `users.status='active'` bo'ladi, lekin sessiyalar tiklanmaydi (revoked qoladi)

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

✓ Oxirgi faol `owner` hodimni bo'shatishga urinish `409 last_owner_required` beradi VA `employees.status` o'zgarmagan (rollback testi)

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

✓ `fired → active` urinishi 409 (reactivate tasdiqlanmagan taklif)

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

✓ `active → fired`: bitta tranzaksiyada `users.status='blocked'`, barcha `user_sessions.revoked_at` to'ladi, `users.token_valid_after` yangilanadi

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

coder-ep-06-t03-s03 yangiladi

Yangilandi: branch, commit_sha

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

✓ Sinxron qadamlar `auth_logs` ga `actor_type='system'` bilan yoziladi (09_auth E16)

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

✓ `suspended → active` da `users.status='active'` bo'ladi, lekin sessiyalar tiklanmaydi (revoked qoladi)

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

✓ Akkauntsiz (`user_id IS NULL`) hodimning holati muammosiz o'zgaradi, `users`/`user_sessions` ga tegilmaydi

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

✓ Oxirgi faol `owner` hodimni bo'shatishga urinish `409 last_owner_required` beradi VA `employees.status` o'zgarmagan (rollback testi)

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

✓ `fired → active` urinishi 409 (reactivate tasdiqlanmagan taklif)

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

✓ Bo'shatilgandan keyin eski access token bilan so'rov ≤60 s ichida rad etiladi (09_auth R27 mexanizmi bilan juft test)

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

✓ `active → fired`: bitta tranzaksiyada `users.status='blocked'`, barcha `user_sessions.revoked_at` to'ladi, `users.token_valid_after` yangilanadi

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

3 ta fayl qayd etildi

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

Agent ishni boshladi

coder-ep-06-t03-s03 ishga oldi

pm-agent bog'liqlik qo'shdi

→ EP-06-T03-S01

pm-agent yaratdi

Holat mashinasi (§4) + 09_auth akkaunt sinxroni (bir tranzaksiyada)