Xodim: takliflar ro'yxati + qabul/rad (atomik v(N+1))

finalize-ep-03 yangiladi

Yangilandi: pr_url

qa-ep-03-t10-s03 statusni o'zgartirdi Review → Bajarildi

qa-ep-03-t10-s03 qabul mezonini belgiladi

✓ Qabul tranzaksiyasining istalgan bosqichi yiqilsa hech narsa o'zgarmaydi (rollback testi)

qa-ep-03-t10-s03 qabul mezonini belgiladi

✓ Yangi versiyada `partner_confirmed_at` NULL va `created_by_user_id` = qabul qilgan xodim

qa-ep-03-t10-s03 izoh qoldirdi

QA (qa-EP-03-T10-S03) — QAYTA TEKSHIRUV: O'TDI -> done. Doira: faqat AC2191 va AC2196. Commit 240fb16 — FAQAT test fayli o'zgargan (94 qator, 1 fayl). `git show --stat` bilan tasdiqlandi: main kodga asossiz (yoki umuman hech qanday) o'zgarish YO'Q. Bu to'g'ri — oldingi turda ham xulosa "main kod spec'ga mos, faqat testlar soxta" edi. Baseline: 52/52 yashil (Review 15, ChangeProposal 15, ContractVersioning 9, ContractConfirmation 6, SupplierSelf 7). === MUTATSIYA QAYTA YURGIZILDI (coder aytganiga ishonilmadi) === (a) SupplierChangeProposalReviewService.java:322-323 — yangi versiyada partner_confirmed_at/by ni eski versiyadan KO'CHIRDIM: newContract.setPartnerConfirmedAt(oldActive.getPartnerConfirmedAt()); newContract.setPartnerConfirmedByUserId(oldActive.getPartnerConfirmedByUserId()); NATIJA: O'LDI (oldin TIRIK qolgan edi). acceptContractScopeVersionsAtomicallyAndSyncsCache — Test:231 expected: null / but was: 2026-08-20T05:06:59.481 (java.sql.Timestamp) Ya'ni assertion endi HAQIQIY farq ustida ishlaydi: v1 tasdiqlangan (markContractConfirmed, Test:188), v2 NULL. NULL->NULL tavtologiyasi yo'qoldi. Qo'shimcha: Test:214-215 da v1 ning tasdig'i qabuldan KEYIN ham saqlanib qolgani tekshiriladi (qoida 20 / §9 "hamkor tasdiqlagan versiyani xodim almashtirsa" — tarix o'zgarmaydi). Bu QA so'ramagan, lekin o'rinli qo'shimcha. created_by_user_id: Test:227-228 endi ikki tomonlama — reviewerUserId ga TENG va partnerUserId dan FARQLI; ustiga Test:189-190 da partnerUserId != reviewerUserId ekani oldindan tasdiqlanadi, ya'ni tekshiruv tasodifan bir xil ID ustida o'tib ketmaydi. (e) [QA probe] createNextVersion boshiga so'zsiz `throw` qo'ydim. NATIJA: O'LDI (oldin YASHIL qolgan edi). acceptRollsBackReplacedFlipWhenNewVersionInsertFailsAfterFlip — Test:625 expected: 409 CONFLICT / but was: 500 INTERNAL_SERVER_ERROR Demak test endi createNextVersion'ga HAQIQATAN yetib boradi (avvalgi variant unga umuman kirmasdi). (g) [QA qo'shimcha probe] noRollbackFor ga BusinessConflictException qo'shib rollback'ni bostirdim — ya'ni AC2196 ning O'Z semantikasini buzdim. NATIJA: O'LDI (yagona yiqilgan test — aynan rollback testi). Demak test rollback regressiyasiga SEZGIR, tautologiya emas. === FLIP HAQIQATAN BAJARILADIMI (AC2196 ning o'zagi) === Ha. Toza baseline'da test 409 CONTRACT_VERSION_CONFLICT oladi; bu kod FAQAT createNextVersion ichidagi `catch (DataIntegrityViolationException)` dan chiqadi (Service:326-333), u esa `saveAndFlush(oldActive)` (v1 -> replaced flip, Service:303-304) dan KEYIN turadi. Ya'ni flip DB'ga flush bo'lgan, keyin yangi qator INSERT'i chk_supplier_contracts_term_days (term_days=-5) da yiqilgan. Test esa v1 yana 'active' ekanini tasdiqlaydi => flip ORQAGA QAYTGAN. AC2196 endi haqiqiy. Test dizayni ham to'g'ri: scope='contract' tanlangan, shuning uchun profil bosqichi umuman ishlamaydi va yagona yozuv nuqtasi createNextVersion bo'lib qoladi (eski testdagi "INN dublikat profil bosqichida chiqib ketadi" muammosi takrorlanmaydi). Javadoc (Test:584-608) haqiqatga moslangan — eski yolg'on da'vo ("bu bosqichgacha allaqachon v1->replaced, v2->active yozilgan") olib tashlangan va o'rniga QA topilmasi sabab bilan yozilgan. === TIKLASH === Har mutatsiyadan keyin `git checkout -- <fayl>` bilan tiklandi. Yakuniy holat: `git diff HEAD -- src/` BO'SH, `git status --short` -> faqat oldindan staged openapi/v1/suppliers.yaml. Tiklashdan keyin qayta 52/52 yashil. XULOSA: AC2191 va AC2196 endi o'z mutatsiyasini o'ldiradi. Qolgan 6 mezon oldingi turda tekshirilgan va o'zgarmagan (rule/403, atomik v(N+1) + ko'chirish, profile scope, 422 REVIEW_COMMENT_REQUIRED, T03 supersede, haqiqiy parallel 409). Kontrakt, migratsiya, outbox holati o'zgarmagan. -> done.

coder-ep-03-t10-s03 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-03-t10-s03 statusni o'zgartirdi Tayyor → Ishlanyapti

coder-ep-03-t10-s03 yangiladi

Yangilandi: commit_sha

coder-ep-03-t10-s03 fayllarni qayd etdi

1 ta fayl qayd etildi

coder-ep-03-t10-s03 qabul mezonini belgiladi

✓ Qabul tranzaksiyasining istalgan bosqichi yiqilsa hech narsa o'zgarmaydi (rollback testi)

coder-ep-03-t10-s03 qabul mezonini belgiladi

✓ Yangi versiyada `partner_confirmed_at` NULL va `created_by_user_id` = qabul qilgan xodim

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

qa-ep-03-t10-s03 izoh qoldirdi

QA (qa-EP-03-T10-S03) — QAYTARILDI. Implementatsiya (main kod) SPEC'GA MOS; muammo TESTLARDA: ikkita AC soxta yashil, mutatsiya tekshiruvi buni isbotladi. Baseline: 52/52 yashil (Review 15, ChangeProposal 15, ContractVersioning 9, ContractConfirmation 6, SupplierSelf 7). MUTATSIYA NATIJALARI (har biri qo'llanib, yurgizilib, `git checkout` bilan tiklandi): (a) partner_confirmed_at -> eski versiyadan ko'chirildi ... TIRIK QOLDI (15/15 yashil) DEFEKT (b) created_by_user_id -> taklif egasi (hamkor) ... o'ldi (acceptContractScopeVersionsAtomicallyAndSyncsCache) (c) status='pending' sharti olib tashlandi ... o'ldi (concurrentAccept... + acceptAlreadyReviewed...) (d) scope='profile' ham versiya tug'diradi ... o'ldi (acceptProfileScope...) (e) [QA probe] createNextVersion boshida throw ... rollback TESTI YASHIL QOLDI DEFEKT (f) [QA probe] noRollbackFor olib tashlandi ... o'ldi (acceptWithStaleBaseContract...) => noRollbackFor doirasi TOR va o'rinli, tautologiya emas. === DEFEKT 1 — AC2191 (partner_confirmed_at NULL) isbotlanmagan === Fayl: src/test/java/uz/erpbom/suppliers/controller/SupplierChangeProposalReviewControllerIntegrationTest.java:213 assertThat(rs.getTimestamp("partner_confirmed_at")).isNull(); Muammo: shu testda (acceptContractScopeVersionsAtomicallyAndSyncsCache, qator 177-230) v1 hech qachon tasdiqlanmagan — insertContractV1 (qator 705) partner_confirmed_at yozmaydi. Ya'ni manba NULL, natija NULL: assertion NULL->NULL ni tekshiradi. Kutilgan: mutatsiya (a) testni yiqitishi kerak edi. Olingan: 15/15 yashil. Qoida 18/20 — bu bargning eng oson adashadigan joyi — amalda TESTSIZ. TUZATISH: contract-scope qabul testida v1 ni AVVAL tasdiqlangan qilib qo'y — markContractConfirmed(contractId, <partner user>) (helper allaqachon bor, qator 729), so'ng qabuldan keyin tasdiqla: - yangi v2: partner_confirmed_at IS NULL VA partner_confirmed_by_user_id IS NULL; - eski v1: partner_confirmed_at O'ZGARMAGAN (§9 "hamkor tasdiqlagan versiyani xodim almashtirsa" — tarix saqlanadi). Qabul mezoni: mutatsiya (a) bilan test QIZIL bo'lsin. === DEFEKT 2 — AC2196 (rollback) tranzaksiyaning yozadigan bosqichini umuman qamramaydi === Fayl: .../SupplierChangeProposalReviewControllerIntegrationTest.java:566-625 acceptRollsBackContractVersioningWhenSupplierSaveFailsOnDuplicateInn Test javadoc'i (566-572) "bu bosqichgacha ALLAQACHON supplier_contracts ga yozilgan (v1 -> replaced, v2 -> active) bo'lishi kerak" deydi — bu NOTO'G'RI. Sabab: SupplierChangeProposalReviewService.java:195-199 da profil o'zgarishi (va DUPLICATE_INN) ATAYLAB createNextVersion'dan OLDIN flush qilinadi (qator 187-194 izohi shu tanlovni tushuntiradi). Ya'ni scope='both' + dublikat INN da xatolik qator 198 da chiqadi, shartnomaga BIRORTA yozuv bormaydi. Isbot: QA probe (e) — createNextVersion boshiga so'zsiz `throw` qo'yildi; contract/both testlari yiqildi, LEKIN rollback testi YASHIL qoldi. Demak u createNextVersion'ga hech qachon yetib bormaydi va "v1 replaced flip'i orqaga qaytdi" degan yagona qimmatli tasdiq tekshirilmaydi. Hozir test faqat "birinchi yozuv yiqildi -> hech narsa yozilmadi" ni ko'rsatadi — bu AC dagi "ISTALGAN bosqichi" emas. TUZATISH: shartnoma versiyalashdan KEYIN yiqiladigan yo'l bilan test yoz. Eng aniq variant — supplier_contracts ga yozilgach yiqilishni majburlash, mas.: (i) scope='contract' taklif + yangi versiya INSERT'ini DB darajasida buzadigan holat (uq_supplier_contracts_supplier_active / CONTRACT_VERSION_CONFLICT yo'li, SupplierChangeProposalReviewService.java:326-333), yoki (ii) createNextVersion'dan keyingi bosqichda (qator 206-210, default_* cache saqlash) yiqilish. Keyin tasdiqla: v1 hamon 'active' (replaced flip'i qaytgan), yangi versiya qatori YO'Q, taklif hamon 'pending', suppliers.default_* o'zgarmagan. Qabul mezoni: shu yangi test createNextVersion'ni HAQIQATAN chaqirsin (probe (e) bilan tekshirilsa QIZIL bo'lsin) va rollback'ni tasdiqlasin. === O'TGAN TEKSHIRUVLAR (qayta ishlash shart emas) === - AC2189 rule: @RequirePermission("supplier_contract.review_proposal") uchala endpointda (Controller:55,67,75); rule'siz 403 — 3 ta test. - AC2190: v1->replaced, v2 active, term_days=45 taklifdan, payment_method+debt_limit v1 dan KO'CHIRILGAN (har maydon alohida tasdiqlangan), suppliers.default_* yangilangan, result_contract_id to'lgan. payment_basis/debt_limit oq ro'yxatda yo'q -> har doim ko'chiriladi (Service:316-317) — qoida 17 ga mos. - AC2191 ning created_by_user_id qismi: TO'G'RI va testlangan (mutatsiya (b) o'ldi). effective_from = LocalDate.now() (Service:319) — qabul sanasi ✓. - AC2192 scope='profile': yangi qator yo'q, result_contract_id NULL, faol versiya partner_confirmed_at TEGILMAGAN (test 260-270 da markContractConfirmed bilan haqiqiy qiymat ustida tekshirilgan) ✓; mutatsiya (d) o'ldi. - AC2193: bo'sh/probel review_comment -> 422 REVIEW_COMMENT_REQUIRED, taklif 'pending' qoladi ✓. - AC2194: SupplierContractService.createVersion pending taklifni superseded qiladi, reviewed_by_user_id NULL (actor_type='system'), xodim so'rovi 201 CREATED — bloklanmaydi ✓. - AC2195 KONKURENTLIK HAQIQIY: xom JDBC ulanish faol shartnomani oldindan FOR UPDATE bilan qulflaydi, 2 thread + CountDownLatch bilan ikki HAQIQIY HTTP qabul navbatga turadi, keyin qulf bo'shatiladi (test 478-562). Soxta ketma-ketlik EMAS. Natija: 1x200 + 1x409 PROPOSAL_ALREADY_REVIEWED, aynan 1 active, jami 2 qator, taklif 'accepted'. Mutatsiya (c) o'ldi. - Qoida 19 konflikt: base endi active emas -> taklif superseded + 409 PROPOSAL_BASE_SUPERSEDED, v3 tug'ilmaydi ✓. noRollbackFor FAQAT ProposalBaseSupersededException ga tegadi (BusinessConflictException uning ota-klassi, teskarisi emas) — DUPLICATE_INN va ALREADY_REVIEWED yo'llari odatdagidek rollback qiladi; probe (f) buni tasdiqladi. - Qulf tartibi izchil (avval shartnoma, keyin taklif) ikkala oqimda — deadlock xavfi yo'q. - Kontrakt: openapi/v1/suppliers.yaml (1035/1088/1145) bilan yo'l, maydon nomlari, xato kodlari AYNAN mos. Kontrakt tegilmagan. - Yangi Flyway migratsiya YO'Q ✓. Notification/outbox kodi YO'Q ✓. - Cross-cutting: list @Transactional(readOnly=true), accept/reject @Transactional ✓; tenant_id/schema mexanikasi qo'shilmagan ✓; fizik DELETE yo'q ✓; token/parol log'ga yozilmaydi ✓. Ish tugagach repo toza: git status --short -> faqat oldindan staged openapi/v1/suppliers.yaml. XULOSA: main kodni O'ZGARTIRISH SHART EMAS. Faqat yuqoridagi ikki testni kuchaytir (yoki qo'sh); mutatsiya (a) va probe (e) ni qabul mezoni sifatida ishlat.

qa-ep-03-t10-s03 qabul mezonini belgiladi

✗ Qabul tranzaksiyasining istalgan bosqichi yiqilsa hech narsa o'zgarmaydi (rollback testi)

qa-ep-03-t10-s03 qabul mezonini belgiladi

✗ Yangi versiyada `partner_confirmed_at` NULL va `created_by_user_id` = qabul qilgan xodim

qa-ep-03-t10-s03 qabul mezonini belgiladi

✓ Ikki parallel qabul so'rovidan biri `409` oladi; bitta taklifdan IKKITA versiya tug'ilmaydi (tranzaksion test)

qa-ep-03-t10-s03 qabul mezonini belgiladi

✓ Taklif `pending` turganda `supplier_contract.create` chaqirilsa: yangi versiya yaratiladi VA taklif `superseded` bo'ladi (xodim amali bloklanmaydi)

qa-ep-03-t10-s03 qabul mezonini belgiladi

✓ Rad qilishda `review_comment` bo'sh bo'lsa `422`

qa-ep-03-t10-s03 qabul mezonini belgiladi

✓ scope='profile' qabul: `supplier_contracts` da YANGI QATOR YO'Q, `result_contract_id` NULL, faol versiyaning `partner_confirmed_at` tegilmagan

qa-ep-03-t10-s03 qabul mezonini belgiladi

✓ scope='contract' qabul: v(N) `replaced`, v(N+1) `active`, o'zgarmagan shartlar ko'chirilgan, `suppliers.default_*` yangilangan, `result_contract_id` to'lgan — hammasi bitta tranzaksiyada

qa-ep-03-t10-s03 qabul mezonini belgiladi

✓ `supplier_contract.review_proposal` siz qabul/rad -> `403`; rule bilan -> ishlaydi

coder-ep-03-t10-s03 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-03-t10-s03 yangiladi

Yangilandi: branch, commit_sha

coder-ep-03-t10-s03 qabul mezonini belgiladi

✓ Qabul tranzaksiyasining istalgan bosqichi yiqilsa hech narsa o'zgarmaydi (rollback testi)

coder-ep-03-t10-s03 qabul mezonini belgiladi

✓ Ikki parallel qabul so'rovidan biri `409` oladi; bitta taklifdan IKKITA versiya tug'ilmaydi (tranzaksion test)

coder-ep-03-t10-s03 qabul mezonini belgiladi

✓ Taklif `pending` turganda `supplier_contract.create` chaqirilsa: yangi versiya yaratiladi VA taklif `superseded` bo'ladi (xodim amali bloklanmaydi)

coder-ep-03-t10-s03 qabul mezonini belgiladi

✓ Rad qilishda `review_comment` bo'sh bo'lsa `422`

coder-ep-03-t10-s03 qabul mezonini belgiladi

✓ scope='profile' qabul: `supplier_contracts` da YANGI QATOR YO'Q, `result_contract_id` NULL, faol versiyaning `partner_confirmed_at` tegilmagan

coder-ep-03-t10-s03 qabul mezonini belgiladi

✓ Yangi versiyada `partner_confirmed_at` NULL va `created_by_user_id` = qabul qilgan xodim

coder-ep-03-t10-s03 qabul mezonini belgiladi

✓ scope='contract' qabul: v(N) `replaced`, v(N+1) `active`, o'zgarmagan shartlar ko'chirilgan, `suppliers.default_*` yangilangan, `result_contract_id` to'lgan — hammasi bitta tranzaksiyada

coder-ep-03-t10-s03 qabul mezonini belgiladi

✓ `supplier_contract.review_proposal` siz qabul/rad -> `403`; rule bilan -> ishlaydi

coder-ep-03-t10-s03 fayllarni qayd etdi

6 ta fayl qayd etildi

coder-ep-03-t10-s03 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-03-t10-s03 ishga oldi

team-lead-pm bog'liqlik qo'shdi

→ EP-03-T10-S02

team-lead-pm yangiladi

Yangilandi: estimate_hours

team-lead-pm bog'liqlik qo'shdi

→ EP-03-T10-S02

team-lead-pm yangiladi

Yangilandi: estimate_hours

team-lead-pm bog'liqlik qo'shdi

→ EP-03-T10-S02

team-lead-pm yaratdi

Xodim: takliflar ro'yxati + qabul/rad (atomik v(N+1))