Qoida 5(c) — huquq qayta tekshiruvi (permission_code katalogda)

qa-ep-13-t03-s05 statusni o'zgartirdi Review → Bajarildi

qa-ep-13-t03-s05 izoh qoldirdi

QA (qa-EP-13-T03-S05) — mustaqil tekshiruv, commit 2d7579f. VERDIKT: done. 1) POYDEVOR (o'zim o'lchadim, surefire XML parser bilan, regex EMAS): rm -rf target/surefire-reports + flock ostida `mvn -Dtest='uz.erpbom.notifications.**' test` -> 26 klass / 212 test / 0 failure / 0 error / 0 skipped. Ikkala yangi test ham PASS. 2) MEZON 5650 — endi HALOL true, ikki yo'nalish ham mutatsiya bilan qotirildi. Izolyatsiyalangan worktree (git worktree add /tmp/qa-EP-13-T03-S05 2d7579f): * M1 — UserPermissionRepository.java:113 dagi `WHERE u.status = 'active'` -> `WHERE 1 = 1`. Bytecode tasdig'i: javap -v, @Query RuntimeVisibleAnnotation qiymati (constant #35) mutatsiyalangan matnni ko'rsatdi; qo'shni findActiveUserIdsByPermissionCodeInOrgNode (#40) tegilmagan. NATIJA: MUTANT O'LDI -> 212 test / 2 failure: blockedAdminWithRetainedPermissionStillMissesAdminCopyBecauseF5RequiresActiveStatus (aynan (a) yo'nalishi) + AdminSecurityNotificationServiceTest.inactiveOrDeletedRuleHoldersAreExcludedFromF5. Ya'ni 5650 ni 'qisman' qoldirgan bo'shliq YOPILDI: eski securityAdminCopyWithRevokedPermissionStillDiesDespiteRule6Exception (huquq umuman berilmagan -> mutant bilan ham bo'sh to'plam) endi yagona qoplama emas, yangi test huquqni HAQIQATAN beradi (grantPermission(adminUser,'user_session.revoke')) va status'ni 'blocked' qiladi. * M2 — NotificationOutboxWorker.java:271 `isRecipientEligible(row.userId(), security)` -> `(..., false)` (qoida 6 istisnosini o'chirish). Bytecode tasdig'i: javap -c, chaqiruv oldidagi `iload_3` -> `iconst_0` (toza daraxt bilan solishtirildi). NATIJA: MUTANT O'LDI -> 212 test / 2 failure: blockedRecipientStillReceivesOwnSecurityMessageIndependentlyOfF5PermissionCheck (aynan (b) yo'nalishi) + blockedUserWorkEventDiesButSecurityEventStillSends. Ikki mutant HAR BIRI BOSHQA yangi testni qizil qildi — bu ikki testning ortiqcha takror emasligining bevosita dalili. 3) FIXTURE XILMA-XILLIGI — haqiqiy farq bor: (a) user blocked + huquq BERILGAN (user_permissions qatori bor) + event_code auth.token_reuse_detected_admin + permissionCode='user_session.revoke' (not-null) -> kutilgan dead/recipient_ineligible, inbox qatori qoladi (countNotifications==1); (b) user blocked + huquq YO'Q + event_code auth.account_blocked + permissionCode=null -> kutilgan sent. Qo'shni testlarda severity ham xilma-xil (info/warning/security), status active/blocked/soft-deleted. 4) QOLGAN MEZONLAR qaytadan o'lchandi (board'dagi eski true'ga ishonmadim): * 5647 — NotificationEventDefinition.java:80 nullable permissionCode + :102 bo'sh satr validatsiyasi; katalogda 51 hodisadan 6 tasi to'ldirilgan (auth.account_locked_admin, auth.token_reuse_detected_admin, auth.ip_locked_admin -> user_session.revoke; supplier_proposal.submitted; payment.pending_approval; expense.pending), 45 tasi (ownership) null. * 5648 — NotificationOutboxWorkerTest.java:310 permissionRevokedActiveUserJobDiesWithRecipientIneligibleAndInboxRowSurvives: dead + recipient_ineligible + countNotifications==1 + FCM ga bormaydi; ijobiy juftligi :340 permissionGrantedActiveUserJobSendsSuccessfully. * 5649 — NotificationOutboxWorker.java:410-414 permissionCode==null da erta qaytish; test :361 permissionCodeNullSkipsPermissionCheckEntirely `verifyNoInteractions(mockEvaluator)` bilan 'ortiqcha so'rov yo'q'ni tom ma'noda isbotlaydi. * 5651 — yuqoridagi M1/M2 o'lchovi. 5) SPEC MUVOFIQLIGI: 10_notifications §5 qoida 6 (2026-09-11 aniqlashtirilgan doira: istisno faqat hodisa EGASIga, *_admin nusxalari F5 ga bo'ysunadi) va §6 F5 (qoida 37: u.status='active' AND deleted_at IS NULL AND has_rule AND u.id<>affected_user_id) kod bilan mos. Javadoc qotirish matni spec bilan zid emas. Funksional o'zgarish yo'q — tasdiqlayman. 6) CROSS-CUTTING: kontrakt tegilmagan (git show 2d7579f --stat: openapi/ yo'q, faqat 2 fayl / +119 qator, o'chirilgan qator 0); migratsiya yo'q; PermissionEvaluatorImpl.activeUserIdsWithPermission @Transactional(readOnly=true); soft-delete sharti (deleted_at IS NULL) saqlangan; log'ga parol/token yozilmagan. 7) TOZALIK: worktree mutantlari `cp <fayl>.orig <fayl>` bilan tiklandi (checkout/reset/stash ISHLATILMADI), worktree o'chirildi. Asosiy daraxtda `grep -rn MUTANT src/` BO'SH va `git grep -l MUTANT HEAD -- src/` BO'SH; git status toza, HEAD=2d7579f.

qa-ep-13-t03-s05 qabul mezonini belgiladi

✓ Mutatsiya: tekshiruvni olib tashlash kamida bitta testni qizil qiladi (o'lchangan)

qa-ep-13-t03-s05 qabul mezonini belgiladi

✓ `severity='security'` hodisada qoida 6 istisnosi buzilmaydi (bloklangan/huquqsiz user o'z xavfsizlik xabarini oladi)

qa-ep-13-t03-s05 qabul mezonini belgiladi

✓ `permissionCode = null` hodisada huquq tekshiruvi umuman bajarilmaydi (ortiqcha so'rov yo'q)

qa-ep-13-t03-s05 qabul mezonini belgiladi

✓ Huquqi olib qo'yilgan, akkaunti FAOL user uchun job `dead` + `last_error_code='recipient_ineligible'` bo'ladi va inbox qatori O'CHIRILMAYDI

qa-ep-13-t03-s05 qabul mezonini belgiladi

✓ `NotificationEventDefinition` da nullable `permissionCode` bor va huquqqa bog'langan hodisalarda to'ldirilgan (ownership bilan aniqlanadiganlarda `null`)

coder-ep-13-t03-s05 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-13-t03-s05 qabul mezonini belgiladi

✓ `severity='security'` hodisada qoida 6 istisnosi buzilmaydi (bloklangan/huquqsiz user o'z xavfsizlik xabarini oladi)

coder-ep-13-t03-s05 fayllarni qayd etdi

2 ta fayl qayd etildi

coder-ep-13-t03-s05 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-13-t03-s05 ishga oldi

team-lead-pm statusni o'zgartirdi Bloklangan → Backlog

Biznes qarori keldi (2026-09-11) — blok olindi, izohga qara.

team-lead-pm izoh qoldirdi

BIZNES QARORI KELDI (2026-09-11) — qoida 6 doirasi aniqlashtirildi. Istisno faqat qabul qiluvchi = hodisa egasi bolgan xabarga amal qiladi; admin nusxalari (qoida 37, *_admin) F5 ga boysunadi, F5 esa u.status=active ni TALAB qiladi. Yani hozirgi xatti-harakat TOGRI: bloklangan admin boshqa odam haqidagi security nusxasini olmaydi. KOD OZGARMAYDI. Qoladigan ish: (1) huquq rezolyutsiyasidagi status=active filtri ATAYLAB ekanini kod izohida F5 ga havola bilan qotirish; (2) shu xatti-harakatni qotiruvchi test (bloklangan, huquqi bor admin -> admin nusxasi ketmaydi; ozi haqidagi security xabari esa ketadi). Spec: 10_notifications.md qoida 6 + changelog 2026-09-11.

qa-ep-13-t03-s05 statusni o'zgartirdi Review → Bloklangan

Spec boshligi (10_notifications §5): huquqqa boglangan severity=security admin-nusxasida qoida 5(c) huquq rezolyutsiyasi users.status ni etiborga olsinmi? findActiveUserIdsByPermissionCode ozi status=active filtrini qoyadi -> qoida 6 istisnosi 2 hodisada (auth.token_reuse_detected_admin, auth.ip_locked_admin) orqa eshikdan bekor bolyapti: huquqi BOR bloklangan admin dead+recipient_ineligible oladi. Qoida 6 shartsiz yozilgan, F5 esa snapshot formulasi — spec bu holatni yopmaydi. Biznes qarori kerak, variantlar (A)/(B) QA izohida (activity 12333). Kod va testlar tayyor: 23 klass/192 test yashil, M4 mutanti oldi (javap bilan tasdiqlangan).

qa-ep-13-t03-s05 izoh qoldirdi

QA 2-tur (qa-EP-13-T03-S05) — cd6a216 · VERDIKT: BLOCKED (spec bo'shlig'i, kod nuqsoni emas) === (A) M4 mutanti O'LDI — mustaqil o'lchov === Izolyatsiyalangan worktree: /tmp/qa2-EP-13-T03-S05 @ cd6a216 (asosiy daraxtga tegilmadi). Mutatsiya: NotificationOutboxWorker.java:414 activeUserIdsWithPermission(permissionCode) -> activeUserIdsWithPermission("expense.approve") Bytecode tasdig'i (javap -p -c, isPermissionEligible): 6: aload_0 / 7: getfield permissionEvaluator / 10: ldc_w #332 // String expense.approve (ilgari shu joyda aload_2 = parametr edi) — mutatsiya HAQIQATAN kuchga kirgan. Natija: NotificationOutboxWorkerTest — Tests run: 20, Failures: 1, Errors: 0. Qizargan: securityAdminCopyWithGrantedNonExpensePermissionSendsSuccessfully:451 ("permissionCode = user_session.revoke huquqi haqiqatan bor" — expected "sent" but was "dead"). Xulosa: mutant tirik EMAS, mezon 5651 ✓. Coder o'lchovi tasdiqlandi. Tiklash: `cp <fayl>.orig <fayl>` (checkout/reset/stash ISHLATILMADI), worktree o'chirildi. Fixture xilma-xilligi ✓ — ijobiy yo'nalish endi IKKI xil kod bilan sinaladi: expense.approve (permissionGrantedActiveUserJobSendsSuccessfully) + user_session.revoke (yangi test). === Testlar (asosiy daraxt, cd6a216, flock ostida, bloklovchi) === Modulning HAMMA notification klassi birga: 23 klass / 192 test — 0 failure, 0 error, 0 skip (surefire XML rasmiy XML parser bilan yig'ildi, regex emas). Regressiya yo'q. === Gigiyena === `git diff 096df9c..cd6a216 -- openapi/` — BO'SH ✓ (kontrakt tegilmagan) `git grep -n MUTANT cd6a216 -- src/` — BO'SH ✓ `git log -1 --format=%B cd6a216` — AI atributi YO'Q ✓ === Mezonlar === 5647 ✓ NotificationEventDefinition.permissionCode (nullable, bo'sh satr rad etiladi); NotificationEventCatalogTest.permissionCode_faqat_huquqqa_boglangan_hodisalarda_tolgan ikki tomonlama qotiradi: 6 hodisada aniq rule kodi, qolgan 41 da null. 5648 ✓ permissionRevokedActiveUserJobDiesWithRecipientIneligibleAndInboxRowSurvives — FAOL user + huquq yo'q -> dead + recipient_ineligible, FCM ga urinish yo'q, inbox qatori qoladi (countNotifications == 1, spec qoida 5 "inbox qatori esa qoladi"). 5649 ✓ permissionCodeNullSkipsPermissionCheckEntirely — mock PermissionEvaluator + verifyNoInteractions: permissionCode=null da so'rov UMUMAN yurmaydi. 5650 ~ QISMAN: "o'z" xavfsizlik xabari yo'nalishi qoplangan (blockedUserWorkEventDiesButSecurityEventStillSends: bloklangan user auth.account_blocked ni `sent` oladi, task.available esa `dead`). Huquqqa bog'langan security admin-nusxasi yo'nalishi — quyidagi (B) bo'shlig'i. 5651 ✓ yuqoriga qara (mustaqil o'lchangan). === (B) 🔴 BLOK SABABI — spec javob bermaydi, TAXMIN QILINMADI === Kod (c) bandini PermissionEvaluator.activeUserIdsWithPermission orqali bajaradi. Uning SQL'i — UserPermissionRepository.findActiveUserIdsByPermissionCode (satr ~93-97): WHERE u.status = 'active' AND u.deleted_at IS NULL AND (...rule egaligi...) Ya'ni (c) bandi qoida 5(a) ni ORQA ESHIKDAN qaytaradi: qoida 6 istisnosiga qaramay, huquqi HALI ham bor, lekin bloklangan admin `dead` + `recipient_ineligible` oladi. isRecipientEligible(userId, security) da qoida 6 to'g'ri bajarilgan (security -> status tekshirilmaydi), lekin keyingi qadam — isPermissionEligible — uni bekor qiladi. AMALIY TA'SIR — katalogdagi 47 hodisadan AYNAN 2 tasi (severity=SECURITY + adminCopy=true + permissionCode!=null): * auth.token_reuse_detected_admin -> user_session.revoke * auth.ip_locked_admin -> user_session.revoke (auth.account_locked_admin = `warning` — unga qoida 6 umuman tegishli emas, kod to'g'ri.) Ssenariy: admin hodisa paytida faol edi (F5 snapshot'iga tushdi) -> yuborishgacha bloklandi/ishdan bo'shatildi (lease/retry oynasi) -> hozirgi kodda xabar o'ladi. NEGA SPEC YOPMAYDI (10_notifications.md §5 qayta o'qildi): - qoida 6 SHARTSIZ yozilgan: "severity='security' xabarlarga qoida 5 ning (a) bandi qo'llanmaydi" — "faqat foydalanuvchining o'ziga ketadigan xabar" deb cheklanmagan; - F5 admin nusxasi qabul qiluvchilarida u.status='active' ni talab qiladi, LEKIN F5 — qoida 4 (snapshot) formulasi, yuborish oldidagi qayta tekshiruv emas; - qoida 37(g) faqat "huquqi olingan admin xabarni olmaydi" deydi — "bloklangan, lekin huquqi bor admin" holati haqida hech narsa demaydi; - E17/E18, AC5, AC12 ham bu holatni qamramaydi; - (c) bandining huquq rezolyutsiyasi O'ZI status bo'yicha filtrlashi spec'da umuman ifodalanmagan. SAVOL (biznes qarori kerak — turi: biznes bo'shlig'i): Huquqqa bog'langan severity='security' admin-nusxasida (c) bandining huquq rezolyutsiyasi users.status ni e'tiborga olsinmi? (A) YO'Q — qoida 6 ning (a) istisnosi (c) ga ham o'tadi: user_session.revoke egaligi saqlanib qolgan bo'lsa bloklangan admin ham xabarni OLADI. (Qoida 6 harfma-harf bajariladi; KOD O'ZGARADI — huquq rezolyutsiyasi uchun status filtrsiz variant kerak.) (B) HA — hozirgi xatti-harakat to'g'ri: bloklangan admin `dead`/`recipient_ineligible` (qoida 5 ning "ishdan bo'shagan xodimga korxona ma'lumoti ketmasin" maqsadi ustun). KOD O'ZGARMAYDI, lekin spec'da qoida 6 ga aniq istisno yozilishi kerak: "(c) huquq rezolyutsiyasi baribir faol (status='active') foydalanuvchini talab qiladi". Javob qaysi bo'lsa ham §5 sikli orqali 10_notifications §5 (qoida 6 / F5 / 37g) aniqlashtirilsin — QA erp/docs ga YOZMAYDI. Qo'shimcha (javob kelgach): mavjud test securityAdminCopyWithRevokedPermissionStillDiesDespiteRule6Exception nomi va javadoci "qoida 6 (a) bloklanishni kechiradi, (c) esa kechirmaydi" talqinini DA'VO qiladi, lekin fixture'da user HAM bloklangan HAM huquqsiz — ya'ni u aynan shu ambiguitetni sinamaydi (ikkala talqinda ham natija `dead`). Qaror qabul qilingach shu test aniqlashtirilsin (bloklangan + huquqi BOR fixture bilan). === CROSS-LEAF QARZ (S05 doirasidan TASHQARI — T02/lead uchun, izohda qolib ketmasin) === Spec §10(v) 2026-09-10 da 43 -> 51 hodisaga kengaydi (finance.balance_mismatch, finance.orphan_account, task.norm_or_rate_missing, chain.reopened qo'shildi), kod katalogida esa 47 hodisa bor — bu 4 tasi YO'Q. Shu sababli bu bargning ta'rifida misol qilib keltirilgan `finance.balance_mismatch -> money_account.edit` va `task.norm_or_rate_missing -> profession_norm.set` uchun permissionCode to'ldirilmagan: HODISANING O'ZI katalogda mavjud emas. Bu S05 nuqsoni EMAS (T02 qarzi), lekin T05 da bu kodlar `unknown_event` bo'lib jimgina o'ladi — alohida barg sifatida rasmiylashtirilsin.

coder-ep-13-t03-s05 statusni o'zgartirdi Ishlanyapti → Review

QA 1-qaytish M4 mutant tuzatildi - yangi test qoshildi, mutant worktreeda qizil tasdiqlandi, modul toliq testi 192/192 yashil.

coder-ep-13-t03-s05 statusni o'zgartirdi Tayyor → Ishlanyapti

QA qaytargan bargni davom ettirish - M4 mutant tuzatish.

coder-ep-13-t03-s05 izoh qoldirdi

QA 1-qaytish tuzatildi (M4 mutant, fixture bir xilligi). Yangi test: securityAdminCopyWithGrantedNonExpensePermissionSendsSuccessfully - user_session.revoke huquqi berilgan FAOL foydalanuvchi auth.token_reuse_detected_admin xabarini sent oladi. permissionCode argumenti expense.approve ga qotirilganda (M4) bu test worktree /tmp/coder-mut-S05 da tasdiqlangan holda qiziradi, qolgan 19 test yashil qoladi. Modulning hammasi (23 klass / 192 test - plus 1 yangi) 0 xato bilan yashil. Ishlab chiqarish kodi ozgartirilmadi, faqat test fayli. Commit: cd6a216.

coder-ep-13-t03-s05 fayllarni qayd etdi

1 ta fayl qayd etildi

coder-ep-13-t03-s05 yangiladi

Yangilandi: commit_sha

system statusni o'zgartirdi Ishlanyapti → Tayyor

Avtomatik bo'shatildi: 60 daqiqa signal yo'q

system bo'shatdi

Avtomatik bo'shatildi: 60 daqiqa signal yo'q

qa-ep-13-t03-s05 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-13-t03-s05 izoh qoldirdi

QA (qa-EP-13-T03-S05, commit 2e4c2a2) — QAYTARILDI: 5/5 mezon KOD darajasida bajarilgan, lekin bitta MUTANT TIRIK QOLDI (fixture bir xilligi). Bitta test qo'shilsa yopiladi. (A) AC 5650 nizosi — KODA HAQ, spec bo'shligi YO'Q. Spec 10_notifications.md §5 qoida 6 AYNAN shunday yozilgan: "severity='security' xabarlarga qoida 5 ning (a) bandi qo'llanmaydi" — FAQAT (a). (b) va (c) istisno emas (buni §5 dagi mavjud test ham tasdiqlaydi: softDeletedUserSecurityEventStillDies...). Demak (c) ni severity'dan qat'i nazar qo'llash SPEC'GA MOS. AC 5650 matnining qavs ichidagi qismi ("o'z xavfsizlik xabarini oladi") ham buzilmagan: katalogda severity=SECURITY bo'lgan 7 hodisadan 5 tasi (auth.password_changed/account_blocked/account_locked/sessions_revoked/token_reuse_detected) adminCopy=false + permissionCode=null — ya'ni user O'Z xabarida (c) umuman yurmaydi; permissionCode to'lgan 2 tasi (auth.token_reuse_detected_admin, auth.ip_locked_admin) adminCopy=true, ular "o'z xabari" emas. Mavjud blockedUserWorkEventDiesButSecurityEventStillSends testi bu yo'nalishni yashil ushlab turibdi. Blok QILINMADI. (B) 152 vs 144 — TEST YO'QOLMAGAN. git diff 096df9c..2e4c2a2 -- src/test/ da bironta ham o'chirilgan/nomi o'zgargan/@Disabled test YO'Q, faqat +5 yangi test. Statik @Test sanog'i 184 -> 189 (aynan +5). Haqiqiy modul o'lchovi (asosiy daraxt, mvn -Dtest='uz.erpbom.notifications.**.*Test'): 23 klass / 191 test / Failures=0 Errors=0 SKIPPED=0, mvn exit=0. technical_notes'dagi "18 klass/152" ham, coder'ning "18/144" i ham tor/eskirgan filtr — poydevor raqami sifatida ishlatilmasin; to'g'ri raqam 23/191. O'LCHANGAN MUTATSIYALAR (izolyatsiyalangan worktree /tmp/qa-EP-13-T03-S05 @2e4c2a2, har biri javap bilan tasdiqlangan): M1 tekshiruvni butunlay olib tashlash (if(false)) -> O'LDI, 2 test qizil (permissionRevoked..., securityAdminCopy...). javap: processRow'da isPermissionEligible chaqiruvi yo'qolgan. => mezon 5651 o'lchandi. M2 `permissionCode==null` qo'riqchisini olib tashlash -> O'LDI, permissionCodeNullSkipsPermissionCheckEntirely qizil. => 5649. M3 markDeadImmediate('recipient_ineligible') da inbox qatorini o'chirish -> O'LDI, AYNAN kerakli assert: "[qoida 5 — inbox qatori (tarix) o'chirilmasligi kerak] expected: 1 but was: 0". => 5648. M4 (QUYIDA) -> TIRIK QOLDI. M5 qoida 6 istisnosini (c) ga yoyish (`if (!security && !isPermissionEligible(...))`) -> O'LDI, securityAdminCopy... qizil. => 5650 salbiy yo'nalishi. 🔴 DEFEKT — M4 TIRIK QOLDI (fixture xilma-xilligi): Fayl: src/main/java/uz/erpbom/notifications/service/NotificationOutboxWorker.java:413 (isPermissionEligible). Mutant: `permissionEvaluator.activeUserIdsWithPermission(permissionCode)` -> `activeUserIdsWithPermission("expense.approve")` (katalogdagi kod E'TIBORGA OLINMAYDI). Natija: NotificationOutboxWorkerTest (19) + NotificationEventCatalogTest (13) = 32 test HAMMASI YASHIL, mvn exit=0. javap tasdiqi: `ldc_w #332 // String expense.approve` + `invokeinterface activeUserIdsWithPermission` — mutatsiya bytecode'ga kirgan, yolg'on "survived" emas. Nega yashiringan: yangi 4 ta fixture'ning huquq qiymati bir xil qotib qolgan — 3 ta salbiy holatda user'da UMUMAN huquq yo'q (perm-revoked-user, admin-no-permission-user), yagona ijobiy holat esa aynan `expense.approve` (permissionGrantedActiveUserJobSendsSuccessfully). Shuning uchun "worker AYNAN katalogdagi kodni tekshiradimi" da'vosi hech qayerda qo'riqlanmagan. Ta'siri (real xato sinfi): kod noto'g'ri ulansa 6 ta huquqqa bog'langan hodisadan 5 tasi (auth.account_locked_admin, auth.token_reuse_detected_admin, auth.ip_locked_admin -> user_session.revoke; supplier_proposal.submitted -> supplier_contract.review_proposal; payment.pending_approval -> payment.approve_limit) huquqi BOR qabul qiluvchida ham JIM `dead`/`recipient_ineligible` bo'lib ketadi — uchala xavfsizlik admin-nusxasi hech qachon yetkazilmaydi va bitta ham test qizarmaydi. TALAB QILINADIGAN TUZATISH (bitta test, kod O'ZGARTIRILMAYDI — implementatsiya to'g'ri): NotificationOutboxWorkerTest ga `expense.approve` DAN BOSHQA huquqli IJOBIY test qo'shilsin, mas.: securityAdminCopyWithGrantedPermissionIsDelivered() — insertUser + updateUserStatus(...,"blocked") (qoida 6 (a) kechiradi) + grantPermission(userId, "user_session.revoke") + insertOutboxRow(..., "auth.token_reuse_detected_admin", "security", ...) -> kutilgan: fetchStatus == "sent" va pushSenderPort.requests() hasSize(1). Bu bitta test M4 ni o'ldiradi (user'da user_session.revoke bor, lekin expense.approve yo'q -> qotirilgan kodli mutant uni dead qiladi) VA mezon 5650 ning hozircha sinalmagan IJOBIY yo'nalishini (huquqi bor admin xavfsizlik nusxasini OLADI) yopadi. Qayta topshirishda M4 ni o'zingiz takrorlab, endi qizil bo'lishini hisobotda ko'rsating. Qolgan tekshiruvlar — HAMMASI TOZA: * Mezon 5647 to'liq: record'da nullable permissionCode + bo'sh satr rad etiladi (NotificationEventDefinition.java:102); katalogdagi 47 hodisadan 6 tasi to'ldirilgan, 41 tasi null; NotificationEventCatalogTest ikki tomonlama (kutilgan 6 ning AYNIQ qiymati + qolgan HAMMASI null) tekshiradi. Tavsifida huquq kodi nomlangan-u kodi null qolgan hodisa YO'Q: auth.account_locked / auth.token_reuse_detected tavsifida `user_session.revoke` uchraydi, lekin ular user'ning O'Z nusxasi — admin nusxasi qoida 10 (N4) bo'yicha alohida `_admin` kodda va u to'ldirilgan. * AR-10: 4 ta huquq kodi (user_session.revoke, supplier_contract.review_proposal, payment.approve_limit, expense.approve) R__permissions_and_currencies_seed.sql da mavjud. * Kontrakt: git diff 096df9c..2e4c2a2 -- openapi/ BO'SH (talab bo'yicha o'zgarmasligi kerak edi). * Migratsiya/DB ustuni qo'shilmagan (katalog kod artefakti, M2) — to'g'ri. * git grep -n MUTANT 2e4c2a2 -- src/ BO'SH; asosiy daraxt toza; QA worktree o'chirildi. * Commit xabarida AI atributi yo'q (CLAUDE.md §15) — Co-Authored-By/Generated with topilmadi. * Regressiya yo'q: modulning 23 klassi BIRGA yurgizildi — 191 test, 0 xato, 0 skip.

qa-ep-13-t03-s05 qabul mezonini belgiladi

✓ Mutatsiya: tekshiruvni olib tashlash kamida bitta testni qizil qiladi (o'lchangan)

qa-ep-13-t03-s05 qabul mezonini belgiladi

✓ `severity='security'` hodisada qoida 6 istisnosi buzilmaydi (bloklangan/huquqsiz user o'z xavfsizlik xabarini oladi)

qa-ep-13-t03-s05 qabul mezonini belgiladi

✓ `permissionCode = null` hodisada huquq tekshiruvi umuman bajarilmaydi (ortiqcha so'rov yo'q)

qa-ep-13-t03-s05 qabul mezonini belgiladi

✓ Huquqi olib qo'yilgan, akkaunti FAOL user uchun job `dead` + `last_error_code='recipient_ineligible'` bo'ladi va inbox qatori O'CHIRILMAYDI

qa-ep-13-t03-s05 qabul mezonini belgiladi

✓ `NotificationEventDefinition` da nullable `permissionCode` bor va huquqqa bog'langan hodisalarda to'ldirilgan (ownership bilan aniqlanadiganlarda `null`)

coder-ep-13-t03-s05 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-13-t03-s05 izoh qoldirdi

Bajarildi (variant a, LEAD QARORI bo'yicha). NotificationEventDefinition ga nullable permissionCode qo'shildi (13-chi maydon, recipientDescription dan keyin) — 6 ta huquqqa bog'langan hodisada to'ldirilgan: auth.account_locked_admin/token_reuse_detected_admin/ip_locked_admin -> user_session.revoke, supplier_proposal.submitted -> supplier_contract.review_proposal, payment.pending_approval -> payment.approve_limit, expense.pending -> expense.approve (hammasi recipientDescription matnida rule kodi allaqachon aniq nomlangan edi). Qolgan 41 hodisada null. NotificationOutboxWorker.isPermissionEligible() permissionCode != null bo'lsa PermissionEvaluator#activeUserIdsWithPermission orqali qayta tekshiradi (T02-S03 metodi, texnik izohda ko'rsatilganidek); null bo'lsa hech qanday so'rov yurmaydi. Yo'q bo'lsa dead + recipient_ineligible, inbox (notifications) qatori tegilmaydi. Qoida 6 (a) istisnosi o'zgarmadi — (c) severity'dan mustaqil (auth.token_reuse_detected_admin uchun blocked user token still qoida-6 (a) dan o'tadi, lekin huquqi yo'q bo'lsa (c) baribir dead qiladi — testda tekshirilgan). Testlar: NotificationEventCatalogTest (+1: permissionCode_faqat_huquqqa_boglangan_hodisalarda_tolgan), NotificationOutboxWorkerTest (+4: revoked/dies+inbox-survives, granted/sends, permissionCode-null/mock verifyNoInteractions, security-admin-copy-revoked/dies). Mutatsiya sinovi qo'lda o'tkazildi: isPermissionEligible() ni if(true) return true ga almashtirib NotificationOutboxWorkerTest yurgizildim — 2 ta test (permissionRevoked..., securityAdminCopy...) qizil bo'ldi, keyin fayl asl holatiga tiklandi (grep MUTANT bo'sh, commitga tushmagan). Barg yopishdan oldin modulning HAMMA 18 test klassi (144 test) birga yurgizildi — 0 failure, 0 error.

coder-ep-13-t03-s05 yangiladi

Yangilandi: branch, commit_sha

coder-ep-13-t03-s05 qabul mezonini belgiladi

✓ Mutatsiya: tekshiruvni olib tashlash kamida bitta testni qizil qiladi (o'lchangan)

coder-ep-13-t03-s05 qabul mezonini belgiladi

✓ `severity='security'` hodisada qoida 6 istisnosi buzilmaydi (bloklangan/huquqsiz user o'z xavfsizlik xabarini oladi)

coder-ep-13-t03-s05 qabul mezonini belgiladi

✓ `permissionCode = null` hodisada huquq tekshiruvi umuman bajarilmaydi (ortiqcha so'rov yo'q)

coder-ep-13-t03-s05 qabul mezonini belgiladi

✓ Huquqi olib qo'yilgan, akkaunti FAOL user uchun job `dead` + `last_error_code='recipient_ineligible'` bo'ladi va inbox qatori O'CHIRILMAYDI

coder-ep-13-t03-s05 qabul mezonini belgiladi

✓ `NotificationEventDefinition` da nullable `permissionCode` bor va huquqqa bog'langan hodisalarda to'ldirilgan (ownership bilan aniqlanadiganlarda `null`)

coder-ep-13-t03-s05 fayllarni qayd etdi

6 ta fayl qayd etildi

coder-ep-13-t03-s05 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-13-t03-s05 ishga oldi

team-lead-pm yaratdi

Qoida 5(c) — huquq qayta tekshiruvi (permission_code katalogda)