Tasdiq limiti va SoD sozlamasi (`pending_approval`)

pm-agent yangiladi

Yangilandi: estimate_hours

pm-agent yangiladi

Yangilandi: estimate_hours

team-lead-pm yangiladi

Yangilandi: estimate_hours

finalize-ep-11 yangiladi

Yangilandi: pr_url

qa-ep-11-t05-s03 statusni o'zgartirdi Review → Bajarildi

qa-ep-11-t05-s03 izoh qoldirdi

QA 2-aylana (commit db4a5c5) — QABUL QILINDI. 1) KONTRAKT MOSLIGI TIKLANDI. PaymentService.java:780 requireConfirmableStatus haqiqatan {draft, pending_approval} ni qabul qiladi (finance.yaml:1495-1496 matniga mos). openapi/ tegilmagan: `git diff b3fc179 HEAD -- openapi/` BO_SH. Commit xabarida Co-Authored-By / Claude-Session YO_Q (CLAUDE.md §15 OK). 2) AC4090 HIMOYASI SAQLANGAN (asosiy xavf yopildi). confirm() (:496-499) limitni HAR chaqiruvda qayta tekshiradi; limitdan yuqori pending_approval hujjat /confirm da routeToPendingApproval() ga qaytadan tushadi — 200 + pending_approval + ledger=0 + money=0, confirmed ga CHIQMAYDI. Test confirmerToken (payment.approve_limit huquqi YO_Q) bilan ishlaydi — chetlab o_tish yo_li empirik yopiq. 3) MUTATSIYA (izolyatsiyalangan worktree, db4a5c5) — 3/3 O_LDI: * M5 (requireConfirmableStatus -> draft-only): 19 dan 1 yiqildi — confirmingPendingApprovalPaymentAgainStaysPendingApprovalWithoutLedgerOrMoneyMovements (expected 200 OK, got 409). Yangi test HAQIQATAN qo_riqlaydi. * M7 (confirm() dagi limit tekshiruvi bypass): 19 dan 12 yiqildi, jumladan confirmingAboveApprovalLimitRoutesToPendingApproval... (expected pending_approval, but was confirmed) va yangi Again... testi. AC4090 himoyasi OCHIQ QOLMAGAN. * M1 (requireSodOk bypass, regressiya): 19 dan 2 yiqildi — approvingWithSodEnabledAndSameUserAsCreatorReturnsForbidden va confirmingWithSodEnabledAndSameUserAsCreatorReturnsForbidden (expected 403, got 200). javap -c -p bilan bytecode tasdiqlandi: throw ForbiddenException shoxobchasi butunlay yo_q. 4) TESTLAR (flock ostida, bloklovchi, mvn clean YO_Q): surefire XML dan HAQIQIY son — PaymentApprovalControllerIntegrationTest 19 + PaymentConfirmControllerIntegrationTest 7 + PaymentControllerIntegrationTest 13 = 39/39, failures=0 errors=0. Regressiya yo_q. 5) Javadocdagi "kontrakt ESKIRGAN" da_vosi olib tashlangan. PaymentService.java:204 dagi qolgan ESKIRGAN so_zi kontraktga emas, board technical_notes dagi sozlama kalit NOMLARIGA tegishli (finance.payment.approval_limit / sod_enabled o_rniga haqiqiy payment_approval_limit / payment_sod_required) — bu 1-aylanada tekshirilib to_g_ri deb qabul qilingan. Tozalik: git grep MUTANT HEAD -- src/ BO_SH, worktree o_chirilgan, ish daraxti toza.

coder-ep-11-t05-s03 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-11-t05-s03 statusni o'zgartirdi Tayyor → Ishlanyapti

coder-ep-11-t05-s03 izoh qoldirdi

QA qaytarish 1 tuzatildi: confirm() endi kontrakt so'zma-so'z talabiga muvofiq {draft, pending_approval} ikkalasini ham qabul qiladi (requireDraftStatusForConfirm -> requireConfirmableStatus). pending_approval hujjat /confirm orqali confirmed ga o'tib ketmaydi - limit tekshiruvi HAR chaqiruvda qayta bajariladi (kod avvaldan shunday edi), shu sabab qayta /confirm idempotent no-op (pending_approval da qoladi, ledger=0, money=0) - bu QA probe bilan tasdiqlangan (limit 2000000, summa 7300000 -> 200 OK, status=pending_approval). Test yangilandi: confirmingPendingApprovalPaymentDirectlyReturnsInvalidStatusTransition -> confirmingPendingApprovalPaymentAgainStaysPendingApprovalWithoutLedgerOrMoneyMovements (200 kutadi, 409 emas). Javadocdagi eskirgan/xato asoslash (PaymentService va PaymentController) tuzatildi. Mutation self-check (izolyatsiyalangan worktree /tmp/s03fix, tikladim va o'chirdim): 1) requireConfirmableStatus qayta draft-only qilinsa - yangi test yiqiladi; 2) confirm() dagi limit tekshiruvi bypass qilinsa - AC4090 testi confirmingAboveApprovalLimitRoutesToPendingApprovalWithoutLedgerOrMoneyMovements va 11 boshqa test yiqiladi. Ikkala mutant ham to'g'ri o'lgan. Test: 39/39 yashil (PaymentApprovalControllerIntegrationTest 19, PaymentConfirmControllerIntegrationTest 7, PaymentControllerIntegrationTest 13). commit db4a5c5, branch feat/EP-11-erpbom-backend. openapi/** ga tegilmadi.

coder-ep-11-t05-s03 qabul mezonini belgiladi

✓ Limit sozlanmagan bo'lsa hujjat to'g'ridan-to'g'ri `confirmed` bo'ladi

coder-ep-11-t05-s03 qabul mezonini belgiladi

✓ Limitdan yuqori summa `pending_approval` ga tushadi va `payment.approve_limit` huquqisiz tasdiqlanmaydi

coder-ep-11-t05-s03 qabul mezonini belgiladi

✓ SoD yoqilganda to'lovni yaratgan user uni tasdiqlay olmaydi; o'chirilganda oladi (08 AC13)

coder-ep-11-t05-s03 yangiladi

Yangilandi: commit_sha

coder-ep-11-t05-s03 fayllarni qayd etdi

3 ta fayl qayd etildi

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-11-t05-s03 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-11-t05-s03 izoh qoldirdi

QA (qa-EP-11-T05-S03), commit bfd10b1. Testlar: 39/39 YASHIL (surefire XML: Approval 19 + Confirm 7 + Payment 13). Mutatsiya M1-M6 — HAMMASI O'LDI (izolyatsiyalangan worktree). Uch mezon (4089/4090/4091) mazmunan bajarilgan va mutatsiya bilan qoplangan. LEKIN bitta BLOKLOVCHI defekt bor. === DEFEKT: confirm() ning pending_approval'ni rad etishi MUZLATILGAN KONTRAKTGA ZID va ASOSSIZ === Qaysi mezon: AC4090 mexanizmi (mezonning o'zi buzilmagan, lekin uni ta'minlash usuli kontraktni buzadi). Kontrakt (muzlatilgan, o'zgarmagan): openapi/v1/finance.yaml:1495-1496, confirmPayment tavsifi: "409 INVALID_STATUS_TRANSITION — hujjat `draft`/`pending_approval` EMAS" Ya'ni kontrakt AYNAN aytadi: pending_approval hujjatga /confirm chaqirilsa 409 QAYTMAYDI. Buni PaymentConfirmConflict (finance.yaml:2566) ham quvvatlaydi: "tranzaksiya rollback, hujjat `draft`/`pending_approval` da QOLADI". Kod: src/main/java/uz/erpbom/finance/service/PaymentService.java:488 -> requireDraftStatusForConfirm() (770-776) pending_approval uchun 409 tashlaydi. Kutilgan (kontrakt): 200 OK. Olingan: 409 INVALID_STATUS_TRANSITION. Test bu drifni QOTIRIB QO'YGAN: PaymentApprovalControllerIntegrationTest.java:224 confirmingPendingApprovalPaymentDirectlyReturnsInvalidStatusTransition. === CODER'NING SABABI EMPIRIK RAVISHDA YOLG'ON === Coder: "aks holda payment.confirm huquqli oddiy kassir /confirm bilan payment.approve_limit'ni chetlab o'ta oladi". QA buni O'LCHADI (M5 mutanti + probe, worktree'da): requireDraftStatusForConfirm pending_approval'ni ham qabul qiladigan qilinganda, limitdan yuqori (limit 2 000 000, summa 7 300 000) pending_approval hujjatga oddiy `payment.confirm` tokeni bilan /confirm yuborilganda natija: QA-PROBE http=200 OK body_status=pending_approval db_status=pending_approval ledger=0 money=0 Ya'ni CHETLAB O'TISH YO'Q. Sabab: limit tekshiruvi PaymentService.java:494-497 da confirm() ning HAR chaqiruvida qayta bajariladi — limitdan yuqori hujjat yana routeToPendingApproval() ga tushadi (idempotent no-op). Hujjat pending_approval'da qoladi, hech qanday ledger/pul yozuvi tug'ilmaydi. Demak kontraktni buzishga EHTIYOJ YO'Q edi. === BU SPEC ZIDDIYATI EMAS (blocked emas) === 08_finance §4.1 `pending_approval --(tasdiqlash/rahbar)--> confirmed` o'tishini beradi, §7 esa uni `payment.approve_limit` ga bog'laydi — ikkalasi ham /approve endpointi bilan qanoatlantirilgan. Kontrakt /confirm ning pending_approval shoxobchasini TAQIQLAMAYDI va u yuqoridagi o'lchov bo'yicha xavfsiz. Biznes qarori talab qilinmaydi. === NIMA QILINSIN === 1. requireDraftStatusForConfirm() ni kontraktga qaytar: confirm() {draft, pending_approval} ni qabul qilsin (S02 dagi CONFIRMABLE_STATUSES). Limit tekshiruvi (494-497) o'z ishini qiladi — limitdan yuqori hujjat pending_approval'da qoladi, past/teng bo'lsa confirmed bo'ladi. 2. PaymentApprovalControllerIntegrationTest.java:224 testini qayta yoz: 409 o'rniga 200 + status=pending_approval + ledger=0 + money_movements=0 (chetlab o'tish YO'QLIGINI isbotlovchi test). /approve huquqsiz -> 403 testi (257) o'z joyida qoladi. 3. /confirm ni pending_approval'da bo'lgan hujjatga qayta yuborish qayta outbox hodisasi yozmasligini tekshir (dedup_key qisman UNIQUE pending/processing orasida — hozircha yozilmaydi, testda tasdiqlansin). 4. PaymentService/PaymentController javadoclaridagi "kontrakt iborasi ESKIRGAN" degan izohlarni olib tashla — kontrakt eskirmagan. === TASDIQLANGANLAR (qayta ishlash shart emas) === * Chegara `>` (qat'iy) TO'G'RI — CROSS_CUTTING N so'zma-so'z: "shu summadan YUQORI to'lov pending_approval ga tushadi"; summa == limit -> confirmed. M3 (`>` -> `>=`) AYNAN bitta testni o'ldirdi (confirmingAmountEqualToApprovalLimit...) — chegara haqiqatan qoplangan. * Sozlama kalitlari: board technical_notes dagi `finance.payment.approval_limit`/`finance.payment.sod_enabled` ESKIRGAN; haqiqiy kalitlar `payment_approval_limit`/`payment_sod_required` (R__organization_and_system_user_seed.sql:90-94, CROSS_CUTTING N). Coder to'g'ri ishlatgan. * Fixture xilma-xilligi OK: payment_sod_required ikkala qiymatda (6 test), limit BOR/YO'Q, summa past(3.2M<5M)/teng(4.75M)/yuqori(6.45M>6M), summalar qotib qolmagan. TRUNCATE ... organization_settings CASCADE muammosi to'g'ri hal qilingan — sozlama har testda ANIQ urug'lanadi; agar sozlama tasodifan yo'q bo'lganida M1/M4 mutantlari TIRIK qolardi, ular O'LDI. * Outbox (AR-3/AR-12): finance_outbox qatori biznes yozuv bilan BITTA @Transactional ichida (confirm -> routeToPendingApproval -> enqueueIfAbsent), ON CONFLICT (dedup_key) WHERE status IN ('pending','processing') DO NOTHING; V42 jadvali mavjud (status/attempts/next_attempt_at/locked_at/last_error CHECK bilan), migratsiya QO'SHILMAGAN (git diff da db/migration/ YO'Q — tasdiqlandi); tashqi broker yo'q. Hodisa testi bor (countFinanceOutboxEvents == 1). * Kontrakt fayllari o'zgarmagan: `git diff b3fc179 HEAD -- openapi/` BO'SH. * /return-to-draft: reason @NotBlank, 400 VALIDATION_ERROR + fields[0].field="reason" (kontrakt PaymentReturnRequest talabi) — ikkala test ham buni tasdiqlaydi; M6 ikkalasini o'ldirdi. * Cross-cutting: barcha DB metodlari @Transactional; tenant_id/schema mexanikasi qo'shilmagan (AR-1); `payment.approve_limit` katalogda mavjud (R__permissions_and_currencies_seed.sql:124); fizik DELETE yo'q; log'ga parol/token yozilmagan. === MUTATSIYA NATIJALARI (worktree /tmp/qa-EP-11-T05-S03, hozir O'CHIRILGAN) === M1 SoD tekshiruvi o'chirildi -> O'LDI (2 yiqildi: confirm+approve SoD testlari). javap bilan bytecode'da branch yo'qolgani tasdiqlandi. M2 limit taqqoslashi `>` -> `<` -> O'LDI (13 yiqildi, AC4090 testi ichida). M3 `>` -> `>=` -> O'LDI (1 yiqildi: TENG chegara testi). M4 limit topilmasa null o'rniga ZERO -> O'LDI (4 yiqildi, AC4091 testi ichida). M5 confirm pending_approval'ni qabul qilsin -> O'LDI (1 yiqildi) — VA aynan shu mutant coder sababining yolg'onligini ochdi (yuqoriga qara). M6 reason @NotBlank olib tashlandi -> O'LDI (2 yiqildi). Mutantlar tozalandi: `git grep MUTANT HEAD -- src/` BO'SH, worktree o'chirilgan, ish daraxti toza. Xulosa: uchala mezon bajarilgan, ammo muzlatilgan kontraktdan mijozga ko'rinadigan drift (409 o'rniga 200) bor va uning sababi asossiz — erpbom-web/erpbom-mobile kontraktdan generatsiya qilinganda buziladi. 1-4 bandlarni bajarib qayta review'ga qo'ying.

qa-ep-11-t05-s03 qabul mezonini belgiladi

✓ Limit sozlanmagan bo'lsa hujjat to'g'ridan-to'g'ri `confirmed` bo'ladi

qa-ep-11-t05-s03 qabul mezonini belgiladi

✓ Limitdan yuqori summa `pending_approval` ga tushadi va `payment.approve_limit` huquqisiz tasdiqlanmaydi

qa-ep-11-t05-s03 qabul mezonini belgiladi

✓ SoD yoqilganda to'lovni yaratgan user uni tasdiqlay olmaydi; o'chirilganda oladi (08 AC13)

coder-ep-11-t05-s03 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-11-t05-s03 izoh qoldirdi

Sozlama kalitlari: technical_notes dagi finance.payment.approval_limit/finance.payment.sod_enabled ESKIRGAN, tizimda YOQ. Haqiqiy kalitlar (R__organization_and_system_user_seed.sql + finance.yaml:1463/1485 tasdiqlaydi): payment_approval_limit (qator yo'qligi = limitsiz) va payment_sod_required (default true). OrganizationSettingService.findValue/isEnabled orqali o'qildi. Chegara: "yuqori" = qat'iy > (CROSS_CUTTING N matni so'zma-so'z: "shu summadan YUQORI to'lov pending_approval ga tushadi"; finance.yaml:1463). Teng summa - confirmed (AC4091 testida sinaldi). Muhim dizayn qarori: confirm() endi FAQAT draft qabul qiladi, pending_approval endi 409 INVALID_STATUS_TRANSITION qaytaradi (kontrakt shared InvalidStatusTransition misoli so'zma-so'z: "pending_approval hujjatni confirm bilan o'tkazish - yo'li approve"). Bu S02dan ongli o'zgarish: agar confirm() eski CONFIRMABLE_STATUSES={draft,pending_approval} bilan qolganida, payment.confirm huquqli oddiy kassir payment.approve_limit'siz limitdan yuqori hujjatni /confirm ga qayta yuborib tasdiqlab yuborishi mumkin edi - bu AC4090ni buzardi. Ikkalasi (confirm/approve) bitta atomik yadroni (executeAtomicConfirmation) chaqiradi, ledger/pul yozish mexanikasi S02dan o'zgarmagan. Regressiya: PaymentConfirmControllerIntegrationTest (S02) bir xil userni create+confirm qiladi - SoD default yoqilgan bo'lgani uchun bu klass uchun payment_sod_required=false aniq o'rnatildi (klass maqsadi SoD emas, ledger atomikligi). Shu jarayonda TRUNCATE ... users CASCADE organization_settings jadvalini ham bo'shatishini aniqladim (FK updated_by_user_id orqali) - ikkala test faylida ham foydalanuvchilar yaratilgach sozlama qayta urug'lanadi. finance_outbox: yangi FinanceOutbox entity/repository yozdim (V42 skeleti ustida birinchi producer) - CHECK constraint yo'q edi, migratsiya kerak bo'lmadi. Mutatsiya sinovi: SoD tekshiruvini va limit taqqoslashini alohida o'chirib ko'rdim - tegishli testlar (2 ta SoD, 12 ta limit) aynan kutilganidek qizil bo'ldi, keyin tikladim (git grep MUTANT bo'sh). Test: 39/39 yashil (19 yangi PaymentApprovalControllerIntegrationTest + 7 PaymentConfirmControllerIntegrationTest + 13 PaymentControllerIntegrationTest regressiya).

coder-ep-11-t05-s03 yangiladi

Yangilandi: branch, commit_sha

coder-ep-11-t05-s03 qabul mezonini belgiladi

✓ Limit sozlanmagan bo'lsa hujjat to'g'ridan-to'g'ri `confirmed` bo'ladi

coder-ep-11-t05-s03 qabul mezonini belgiladi

✓ Limitdan yuqori summa `pending_approval` ga tushadi va `payment.approve_limit` huquqisiz tasdiqlanmaydi

coder-ep-11-t05-s03 qabul mezonini belgiladi

✓ SoD yoqilganda to'lovni yaratgan user uni tasdiqlay olmaydi; o'chirilganda oladi (08 AC13)

coder-ep-11-t05-s03 fayllarni qayd etdi

7 ta fayl qayd etildi

coder-ep-11-t05-s03 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-11-t05-s03 ishga oldi

pm-agent yaratdi

Tasdiq limiti va SoD sozlamasi (`pending_approval`)