Sverka akti — ommaviy yuborish, tasdiq/rad, versiyalash

finalize-ep-12 yangiladi

Yangilandi: pr_url

finalize-ep-12 yangiladi

Yangilandi: branch, commit_sha

pm-agent yangiladi

Yangilandi: estimate_hours

pm-agent yangiladi

Yangilandi: estimate_hours

qa-ep-12-t06-s03 statusni o'zgartirdi Review → Bajarildi

qa-ep-12-t06-s03 izoh qoldirdi

QA (worker-pm, izolyatsiyalangan git worktree /var/tmp/qa-EP-12-T06-S03, HEAD=c07ef54). Testlar: ReconciliationControllerIntegrationTest — Tests run: 21, Failures: 0, Errors: 0. Mutatsiya tekshiruvi — 4 mutant, 4 tasi ham O_LDI, har biri aniq atributsiya bilan: 1) NUQSONNI QAYTA TIKLASH (asosiy): create/bulkSend ga @Transactional qaytarildi (TransactionTemplate ambient tranzaksiyaga qo_shiladi -> qayta urinish ma_nosiz) -> AYNAN 2 test yiqildi: createRetriesAfterConcurrentVersionInsertWinsRaceAndSucceedsWithNextVersion va bulkSendCountsConcurrentVersionCollisionAsSkippedInsteadOfServerError. Boshqa hech bir test yiqilmadi -> versiya poygasi tuzatishi haqiqatan qoplangan. 2) isSentOrConfirmed -> false (AC4677 dublikat himoyasi) -> bulkSendIsIdempotentAcrossRepeatedCalls yiqildi. 3) nextVersionFor -> 1 (AC4678 version+1) -> disputeSucceedsForOwnerAndSubsequentCreateStartsNewVersion + createBuildsNextVersionWhenPriorVersionExists yiqildi. 4) resolveConfirmedBy -> har doim partner (AC4679) -> confirmSetsConfirmedByInternalForPrivilegedUser yiqildi. Fixture xilma-xilligi: F2 snapshot testi qotirilgan raqamlarni to_liq qiymat bilan tekshiradi va oldindan-shart sifatida jonli hisob HAQIQATAN o_zgarganini isbotlaydi (temporal bir xillik tufayli yolg_on-yashil bo_lishi mumkin emas). Tiklash: cp bilan (git stash/checkout/reset ISHLATILMADI). grep -rn MUTANT src/ bo_sh, git grep MUTANT HEAD bo_sh, worktree git status toza, asosiy daraxt toza. Kontrakt: openapi/ tegilmadi. KUZATUV (blok emas, lead uchun): ikki karra to_qnashuvda 409 INVALID_STATUS_TRANSITION ishlatiladi — kontraktda bu kod §4.6 holat o_tishi uchun ta_riflangan, versiya poygasi uchun emas; kontraktni muzlatilgan holda saqlash uchun ataylab shu tanlangan va kodda javadoc bilan hujjatlashtirilgan. Shuningdek skipped_count endi poyga to_qnashuvini ham hisoblaydi (kontrakt ta_rifi: aktiv akti allaqachon sent/confirmed) — ma_no jihatdan mos, chunki to_qnashuv aynan konkurent so_rov aktiv akt kiritganini bildiradi. Commit: c07ef54 (2 fayl, 410 qator; begona fayl yo_q).

qa-ep-12-t06-s03 qabul mezonini belgiladi

✓ Ichki tasdiqda `confirmed_by=internal` va user yoziladi

qa-ep-12-t06-s03 qabul mezonini belgiladi

✓ `disputed` dan keyin `version+1` yangi akt yoziladi, eskisi tarixda qoladi (08 AC12)

qa-ep-12-t06-s03 qabul mezonini belgiladi

✓ Ommaviy yuborishda har kontragentga bitta `draft → sent` akt tug'iladi va takroriy yurgizishda dublikat bo'lmaydi

worker-ep-12-t06 statusni o'zgartirdi Ishlanyapti → Review

worker-ep-12-t06 statusni o'zgartirdi Tayyor → Ishlanyapti

worker-ep-12-t06 izoh qoldirdi

Yetim qolgan coder ishi (410 qator) worker-pm tomonidan tekshirilib yakunlandi va commit qilindi: c07ef54. Versiya TOCTOU poygasi create/bulkSend da yopildi (TransactionTemplate bilan mustaqil tranzaksiya; create 1 qayta urinish -> 409, bulkSend -> skipped_count). openapi/ tegilmadi. ReconciliationControllerIntegrationTest 21/21 yashil. QA kutilmoqda.

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

qa-ep-12-t06-s03 izoh qoldirdi

QA (qa-EP-12-T06-S03), izolyatsiyalangan worktree. Baza: 18/18 yashil (ReconciliationControllerIntegrationTest). MUTATSIYA (4 talab qilingan mutant — HAMMASI O'LDI, bytecode javap bilan tasdiqlangan): (a) create: `version+1` -> `version` => KILLED: createBuildsNextVersionWhenPriorVersionExists + disputeSucceedsForOwnerAndSubsequentCreateStartsNewVersion (b) bulkSend dublikat qo'riqchisi o'chirildi => KILLED: bulkSendIsIdempotentAcrossRepeatedCalls (c) resolveConfirmedBy: internal -> partner => KILLED: confirmSetsConfirmedByInternalForPrivilegedUser ('internal' konstantasi bytecode'dan yo'qolgani tasdiqlandi) (d) requireStatus (§4.6) o'chirildi => KILLED: sendRejectsNonDraftStatus + confirmRejectsNonSentStatus AC4677/AC4678/AC4679 — haqiqatan qoplangan, is_met=true qo'yildi. Kontrakt mosligi OK: POST /reconciliations/{id}/confirm da kontraktda requestBody YO'Q (~5369) — coder qarori TO'G'RI, drift emas. V47: numeric(18,2), uq_(account_id,period_id,version), disputed->comment CHECK, tenant_id yo'q (AR-1), outbox biznes yozuv bilan bir tranzaksiyada (AR-3/AR-12). === QAYTARISH SABABI === 1) 🔴 BLOKLOVCHI — F2 SNAPSHOT QOTIRILISHI UMUMAN SINALMAGAN (mutant TIRIK QOLDI). Mutant E: ReconciliationService#toResponse da qotirilgan ustunlar o'rniga o'qishda QAYTA HISOBLASH qo'yildi: Snapshot fresh = computeSnapshot(account, accountingPeriodService.get(reconciliation.getPeriodId())); ...fresh.openingBalance(), fresh.closingBalance(), fresh.turnoverDebit(), fresh.turnoverCredit() Natija: 18/18 baribir YASHIL — bitta ham test yiqilmadi. Yolg'on 'survived' EMAS: javap bilan computeSnapshot havolalari asl kodda 3 (ta'rif + create:176 + bulkSend:224), mutant ostida 4 — ya'ni qayta hisoblash haqiqatan kompilyatsiya qilingan. SABAB — FIXTURE TEMPORAL BIR XILLIGI: hamma testda ledger yozuvlari FAQAT akt tuzilishidan OLDIN kiritiladi (insertLedgerEntry ... keyin createReconciliation). Shu sabab 'qotirilgan snapshot' va 'o'qishda jonli hisoblash' bir-biridan FARQLANMAYDI. Bu EP-07 dagi aynan o'sha naqsh. §2.17 ('opening_balance/closing_balance ... SNAPSHOT (F2)') va task technical_notes ('Akt raqamlari F2 dan snapshot bo'lib olinadi') buni TALAB qiladi, lekin hech nima qo'riqlamayapti. KERAKLI TEST (ReconciliationControllerIntegrationTest): akt tuz -> O'SHA davrga YANGI insertLedgerEntry (mas. -4000000.00) qo'sh -> GET /reconciliations/{id} -> opening/closing/turnover_debit/turnover_credit AKT TUZILGAN LAHZADAGI qiymatda qolganini TO'LIQ qiymat bilan tasdiqla (assertThat(...).isEqualTo("-8000000.00") uslubida, qism satr solishtiruvisiz). 2) ⚠️ KONKURENTLIK — bir vaqtda ikki chaqiruv 500 beradi (CROSS_CUTTING Q). bulkSend/create da navbatdagi versiya 'oldin o'qi, keyin yoz' bilan aniqlanadi (ReconciliationService.java:173-175 va 227), qulf yo'q. Ikki foydalanuvchi (yoki tugmani bir vaqtda ikki marta bosish) bitta (account_id, period_id) ga tegsa — uq_reconciliations_account_id_period_id_version buziladi va DataIntegrityViolationException GlobalExceptionHandler'dagi @ExceptionHandler(Exception.class) ga tushib 500 qaytaradi. Tasdiq: butun src/main/java da ReconciliationService uchun DataIntegrityViolationException ushlash YO'Q, GlobalExceptionHandler'da ham bu tur uchun handler YO'Q — holbuki repo naqshi aynan servisda ushlash (SupplierService.java:300, CustomerContractService, SupplierChangeProposalService.java:134). Kontrakt ReconciliationConflict (6323-6331) faqat INVALID_STATUS_TRANSITION va PERIOD_CLOSED kodlarini e'lon qiladi — YANGI kod qo'shish drift bo'ladi. Shuning uchun kontrakt ichida qoladigan yechim: DataIntegrityViolationException ni ushlab, bulkSend'da o'sha varaqani 'allaqachon yuborilgan' deb skipped_count ga sanash (idempotentlik semantikasi bilan mos), create'da esa max versiyani qayta o'qib BIR marta retry qilish. openapi/ ga TEGILMASIN. 3) ℹ️ KICHIK — AC4678 da eski qator O'ZGARMAGANI tasdiqlanmagan. disputeSucceedsForOwnerAndSubsequentCreateStartsNewVersion (389-428) eski qator O'CHIRILMAGANINI isbotlaydi (latest_only=false -> hasSize(2)), lekin v1 hali ham status='disputed' va dispute_comment o'sha matn ekanini TEKSHIRMAYDI. Shu testga v1 ni GET qilib status/dispute_comment/version tasdig'ini qo'shing. Fixture xilma-xilligi qolgan jihatdan YETARLI: summalar turlicha (-5000000, -12000000, 8000000, 1000000, -3000000, 2000000, -1500000), version 1 va 2 ikkalasi ham, nol va nolmas varaqa, 4 xil aud (web/supplier). Yagona bo'shliq — yuqoridagi temporal bir xillik. Asosiy ish daraxtiga TEGILMADI (davr yopish gate'i coder'i ishlayapti); mutantlar faqat /tmp/qa-EP-12-T06-S03 worktree'da, yakunda grep -rn MUTANT src/ BO'SH, worktree olib tashlandi.

qa-ep-12-t06-s03 qabul mezonini belgiladi

✓ Ichki tasdiqda `confirmed_by=internal` va user yoziladi

qa-ep-12-t06-s03 qabul mezonini belgiladi

✓ `disputed` dan keyin `version+1` yangi akt yoziladi, eskisi tarixda qoladi (08 AC12)

qa-ep-12-t06-s03 qabul mezonini belgiladi

✓ Ommaviy yuborishda har kontragentga bitta `draft → sent` akt tug'iladi va takroriy yurgizishda dublikat bo'lmaydi

coder-ep-12-t06-s03 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-12-t06-s03 izoh qoldirdi

7 ta operatsiya (list/create/bulk-send/get/send/confirm/dispute) yozildi. F2 snapshot mavjud CounterpartyTurnoverService orqali (qayta yozilmadi). bulk-send idempotent (aktiv akt sent/confirmed bolsa skip). disputed -> POST /reconciliations yangi version+1 yozadi, eski qator tarixda qoladi. confirm hybrid: hamkor egaligi -> partner, reconciliation.confirm_internal -> internal. dispute — rule yoq, faqat egalik. Barcha yozuvchi endpoint AccountingPeriodService.requirePeriodOpen orqali qoida 40ni tekshiradi. Controller integration test: 18/18 yashil (ReconciliationControllerIntegrationTest).

coder-ep-12-t06-s03 qabul mezonini belgiladi

✓ Ichki tasdiqda `confirmed_by=internal` va user yoziladi

coder-ep-12-t06-s03 qabul mezonini belgiladi

✓ `disputed` dan keyin `version+1` yangi akt yoziladi, eskisi tarixda qoladi (08 AC12)

coder-ep-12-t06-s03 qabul mezonini belgiladi

✓ Ommaviy yuborishda har kontragentga bitta `draft → sent` akt tug'iladi va takroriy yurgizishda dublikat bo'lmaydi

coder-ep-12-t06-s03 fayllarni qayd etdi

10 ta fayl qayd etildi

coder-ep-12-t06-s03 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-12-t06-s03 ishga oldi

team-lead-pm yangiladi

Yangilandi: estimate_hours

pm-agent yaratdi

Sverka akti — ommaviy yuborish, tasdiq/rad, versiyalash