picking_rates CRUD + tarix (picking_rate.edit)

finalize-ep-10 yangiladi

Yangilandi: commit_sha, pr_url

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

Mezon matni kontrakt+doc bilan moslashtirildi (PM qarori A); ikkala mezon bajarildi, lead olchovi 14/14 yashil.

team-lead-pm izoh qoldirdi

PM QARORI (2026-09-02, variant A — QA tavsiyasi): mezon 3727 matni MUZLATILGAN KONTRAKTGA HAM, SPEC DOCGA HAM zid edi, kod emas. 06_orders §2.3 modeli: node da bitta qator (UNIQUE(organization_id) WHERE active), stavka ozgarganda eskisi picking_rate_logs ga effective_to bilan yoziladi. Yani yangi qator + eskisini active=false qilish modeli spetsifikatsiyada YOQ; kontrakt (orders.yaml:1388-1391, :1865-1871) POST uchun 409 DUPLICATE_PICKING_RATE talab qiladi va kod aynan shunday. Mezon matni kontrakt+doc bilan moslashtirildi (yangi id 3757). LEAD OLCHOVI: PickingRateControllerTest 14/14 yashil (0 failure, 0 error, 0 skipped), 409 DUPLICATE_PICKING_RATE ikkala yolda (POST va PUT) test bilan qoplangan. Kontrakt OZGARTIRILMADI.

team-lead-pm qabul mezonini belgiladi

✓ Stavka o'zgartirilganda (PUT) eski qiymatlar `picking_rate_logs` ga `effective_to` bilan yoziladi; node'da ikkinchi FAOL stavka yaratishga urinilsa `409 DUPLICATE_PICKING_RATE` (06_orders §2.3: `UNIQUE(organization_id) WHERE active`, kontrakt orders.yaml:1388-1391)

qa-ep-10-t06-s03 statusni o'zgartirdi Review → Bloklangan

Mezon 3727 matni (POST da avto-deaktivatsiya) muzlatilgan kontraktga zid — openapi/v1/orders.yaml:1388-1391 va :1865-1871 POST uchun 409 DUPLICATE_PICKING_RATE talab qiladi. Kod TO'G'RI yozilgan; kontrakt doirasida qoplanishi mumkin bo'lgan hamma narsa (PUT -> picking_rate_logs ga eski qiymatlar + effective_to, active=false boshqaruvi) qoplangan va mutatsiya tekshiruvi bilan tasdiqlangan (M1/M2/M3/M6 o'ldi). PM qarori kerak: (A) mezon matnini kontraktga moslash [QA tavsiyasi], (B) kontraktni o'zgartirish, (C) mezonni ikkiga bo'lish. Batafsil — oldingi QA izohida.

qa-ep-10-t06-s03 izoh qoldirdi

QA (qa-EP-10-T06-S03) — commit 7bbda49, izolyatsiyalangan worktree'da tekshirildi. ## Test PickingRateControllerTest — 14 test, 0 failure, 0 error (real PostgreSQL 16, Testcontainers, 56.4 s). Surefire oldindan tozalangan. ## Mutatsiya tekshiruvi — 10 mutant, 8 O'LDI, 2 tirik O'LDI: (M1) PUT'da picking_rate_logs yozuvini olib tashlash -> 3 test; (M2) effective_to = eski effective_from -> 2 test; (M3) logga ESKI o'rniga YANGI qiymatlar -> 2 test; (M5) @RequirePermission PUT'dan -> updatePickingRateWithoutPermissionReturnsForbidden; (M6) existing.setActive(request.active()) olib tashlandi -> updatePickingRateWithActiveFalseDeactivates...; (M7) default sort DESC->ASC -> listPickingRates...; (M8) active filtri e'tiborsiz -> listPickingRates...; (M9) @RequirePermission POST'dan -> createPickingRateWithoutPermissionReturnsForbidden. Fixture xilma-xilligi TEKSHIRILDI va YAXSHI: updatePickingRateWritesOldValuesToLog... da eski (5000.00 / 100.00 / 2000.00 / 40.0000 / 2026-01-01) va yangi (6500.00 / 150.00 / 2500.00 / 55.0000 / 2026-09-01) qiymatlar HAR BIRI farqli, logdagi har ustun alohida raqam bilan tasdiqlangan -> M3 tirik qolmadi. rate_per_unit va bonus_rate_per_line default 0 da QOTIB QOLMAGAN. TIRIK #1 (EKVIVALENT, defekt EMAS): POST'dagi findActiveByOrganizationId pre-check'ini olib tashlash 14 testni ham yashil qoldirdi. Sabab — DB qisman unikal indeksi uq_picking_rates_organization_id_active saveOrThrowDuplicate orqali AYNAN o'sha 409 DUPLICATE_PICKING_RATE ni qaytaradi (defense-in-depth). javap bilan tasdiqlandi: mutant bytecode'da kuchga kirgan (baseline'dagi lambda$create$0 yo'qolgan). Ya'ni test DB darajasidagi kafolatni ham isbotlaydi. TIRIK #2 (HAQIQIY QAMROV BO'SHLIG'I): PickingRateLogRepository.search dagi organization_id filtrini e'tiborsiz qoldirish (l.organizationId = l.organizationId) — 14 test ham yashil. javap bilan tasdiqlandi (@Query konstantasi bytecode'da o'zgargan). Sabab: listPickingRateLogsReturnsHistoryFilteredByOrganization testida BITTA org va BITTA log qatori bor, shuning uchun filtr aslida sinalmaydi. Kerak: ikkinchi org-node uchun ham log yaratib (PUT), filtr FAQAT o'z org'ining logini qaytarishini tasdiqlash; ayni testda logs endpoint'ining default sort'i (effective_from,desc) ham qamralmagan — ikki xil effective_from bilan ikki log kerak. ## Mezonlar 3728 — TASDIQLANDI (is_met=true). @RequirePermission("picking_rate.edit") annotatsiyasi kodda KO'Z BILAN ko'rildi (grep emas): PickingRateController.java:62 (POST), :76 (PUT). GET yo'llarida (:51 list, :69 get, :84 listLogs) annotatsiya ATAYLAB YO'Q — orders.yaml:1345-1347 ("O'qish uchun alohida rule YO'Q") bilan mos, va bu uchta GET testda noPermToken bilan 200 qaytarishi tekshirilgan. 403 testi MOCK EMAS: DB'ga haqiqiy user INSERT qilinadi, user_permissions qatori berilmaydi, jwtService.issueAccessToken bilan haqiqiy JWT olinadi. M5/M9 mutantlari o'ldi. 3727 — is_met=false QOLDIRILDI. Bu KOD DEFEKTI EMAS — MEZON MATNI va MUZLATILGAN KONTRAKT o'rtasidagi ziddiyat. ## PM uchun: mezon 3727 <-> kontrakt ziddiyati Mezon: "Yangi faol stavka qo'yilganda eskisi active=false bo'ladi va picking_rate_logs ga effective_to bilan yoziladi" — ya'ni POST oqimida AVTO-DEAKTIVATSIYA. Kontrakt buni TAQIQLAYDI: openapi/v1/orders.yaml:1388-1391 (POST createPickingRate tavsifi) — "node'da faol stavka allaqachon bo'lsa 409 DUPLICATE_PICKING_RATE (o'zgartirish uchun PUT ... ishlating)"; va :1865-1871 (DuplicatePickingRate javobi) — "Mavjudini PUT bilan o'zgartiring yoki avval active=false qiling". Spec 06_orders.md §2.3 ham faqat "UNIQUE(organization_id) WHERE active" va "o'zgarganda eskisi picking_rate_logs ga" deydi — avto-deaktivatsiyani talab qilmaydi. Coder kontraktga TO'G'RI amal qilgan (PickingRateService.create:130-133 -> 409; test createPickingRateWhenActiveOneAlreadyExistsIsRejectedWithDuplicateCode mavjud faol qator o'zgarmasligini ham tekshiradi). Mezonning KONTRAKT DOIRASIDA qoplanishi mumkin bo'lgan qismi TO'LIQ ishlaydi va o'lchandi: PUT'da eski qiymatlar picking_rate_logs ga effective_to = yangi effective_from bilan yoziladi (kontrakt PickingRateLogResponse.effective_to izohi: "yangi qiymat kuchga kirgan sana" — 04_employees'dagi "bir kun oldin" naqshidan farqli, coder buni javadoc'da asoslagan), active=false bilan deaktivatsiya ishlaydi, so'ng POST yangi faol qator ochadi. M1/M2/M3/M6 mutantlari bu qismni qo'riqlashini isbotladi. QOPLANMAGAN: "POST'da eskisi avtomatik active=false bo'ladi" — kontrakt tufayli BAJARILMAYDI. Variantlar: (A) mezon 3727 matnini kontraktga moslab qayta yozish (PUT active=false -> log -> POST oqimi) va bargni yopish — kod o'zgarmaydi; (B) kontraktni o'zgartirish (POST'da avto-deaktivatsiya, 409 olib tashlanadi) — muzlatilgan kontraktga tegadi, alohida qaror + T00 kontrakt taski kerak; (C) mezonni ikkiga bo'lish: PUT tarix qismi = bajarildi, avto-deaktivatsiya = alohida barg/rad etilgan. QA tavsiyasi: (A) — kontrakt va spec §2.3 ikkalasi ham PUT oqimini qo'llab-quvvatlaydi, mezon matni yagona chetga chiquvchi. ## Cross-cutting (o'tdi) @Transactional: list/get/listLogs readOnly=true, create/update yozuvchi (PickingRateService). Single-tenant: V33 da tenant_id YO'Q, bitta public schema. Nomlash: snake_case, jadval ko'plikda, FK to'liq nomdan (fk_picking_rates_organization, fk_picking_rate_logs_changed_by_user). Precision: rate_per_line/rate_per_unit/bonus_rate_per_line numeric(18,2), norm_lines_per_day numeric(18,4). Fizik DELETE yo'q (deaktivatsiya active=false orqali; logs insert-only). Log'ga parol/token yozilmaydi (bu kodda umuman logging yo'q). permission_code 'picking_rate.edit' R__permissions_and_currencies_seed.sql:118 da katalogda bor. Kontrakt tiplari: BigDecimal JacksonConfig'dagi ToStringSerializer orqali JSON string bo'lib chiqadi -> kontrakt type: string bajarildi. Javob kodlari: POST 201 (@ResponseStatus(CREATED)), PUT/GET 200. Sort ruxsat etilgan qiymatlar (effective_from, created_at) va default effective_from,desc — mos. PickingRateLogMapper.pickingRateId ignore — oldingi bargning ongli qarori, defekt deb hisoblanmadi. ## Qo'shimcha kichik topilma (bloklovchi emas, qayta ochilganda yopilsin) PickingRateControllerTest klass javadoc'i (56-qator) "validatsiya (400)" ni qamrov sifatida sanaydi, lekin testda 400 kutadigan birorta holat YO'Q — PickingRateService.resolveSort:278-286 dagi ValidationException shoxobchasi (yaroqsiz sort qiymati) va DTO @DecimalMin/@NotNull validatsiyalari umuman sinalmagan. Javadoc'dagi da'vo yo tuzatilsin, yo test qo'shilsin.

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

✗ Yangi faol stavka qo'yilganda eskisi `active=false` bo'ladi va `picking_rate_logs` ga `effective_to` bilan yoziladi

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

✓ `picking_rate.edit` huquqisiz user 403 oladi

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

coder-ep-10-t06-s03 izoh qoldirdi

AC3727 ziddiyati (is_met=false, TAXMIN QILMADIM): mezon matni "yangi faol stavka qoyilganda eskisi active=false boladi" — bu avto-deaktivatsiyani nazarda tutadi. Lekin muzlatilgan openapi/v1/orders.yaml POST javobi #/components/responses/DuplicatePickingRate (~1421-qator, izoh ~1865-1870) sozma-soz: node da faol stavka bolsa 409 DUPLICATE_PICKING_RATE, avto-deaktivatsiya YOQ — "Mavjudini PUT bilan ozgartiring yoki avval active=false qiling". Ikkalasi bir vaqtda togri bolishi mumkin emas: yoki POST eskisini avto-deaktivatsiya qiladi (mezonga mos, kontraktga zid), yoki 409 qaytaradi (kontraktga mos, mezon sozma-soz bajarilmaydi). Kontraktga amal qildim (u ustun, ADR/coding-process qoidasi). PickingRateService PUT oqimi mezonning ikkala qismini ALOHIDA qamraydi: (1) eski qiymatlar har PUT da picking_rate_logs ga effective_to bilan yoziladi (effective_to = yangi effective_from — kontrakt PickingRateLogResponse izohiga sozma-soz mos: "yangi qiymat kuchga kirgan sana", 04_employees dagi "bir kun oldin" naqshidan ATAYLAB farqli, chunki employees.yaml va orders.yaml matni ikki xil yozilgan); (2) active maydoni PUT orqali boshqariladi (false — ochirish, true — qayta faollashtirish, boshqa faol qator bolsa 409 DUPLICATE_PICKING_RATE). Ikki qadamli oqim (PUT active=false eskisini yopadi+logga yozadi, keyin POST yangi faol ochadi) mezonni amalda qoplaydi, lekin bu AVTOMATIK emas — shuning uchun is_met=false qoldirdim, PM/QA hal qilsin: mezon matnini PUT+POST oqimiga moslab qayta yozish kerakmi, yoki kontrakt boshqacha (auto-deaktivatsiya) bolishi kerakmi — bu ikkinchisi openapi/v1/orders.yaml ni ochishni talab qiladi (men tegmadim, muzlatilgan). Test qamrovi: PickingRateControllerTest.updatePickingRateWritesOldValuesToLogWithEffectiveToEqualToNewEffectiveFrom + updatePickingRateWithActiveFalseDeactivatesRowAndStillLogsOldValues + updatePickingRateReactivatingWhileAnotherRowIsAlreadyActiveIsRejectedWithDuplicateCode — 14/14 test yashil. AC3728 (is_met=true): POST/PUT picking_rate.edit siz 403 — createPickingRateWithoutPermissionReturnsForbidden / updatePickingRateWithoutPermissionReturnsForbidden testlarida tasdiqlangan. GET uchlari (list/get/logs) kontrakt boyicha rule talab qilmaydi (faqat autentifikatsiya) — tasks.yaml/TaskController naqshi.

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

✗ Yangi faol stavka qo'yilganda eskisi `active=false` bo'ladi va `picking_rate_logs` ga `effective_to` bilan yoziladi

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

✓ `picking_rate.edit` huquqisiz user 403 oladi

coder-ep-10-t06-s03 yangiladi

Yangilandi: branch, commit_sha

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

7 ta fayl qayd etildi

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

Agent ishni boshladi

coder-ep-10-t06-s03 ishga oldi

pm-agent yaratdi

picking_rates CRUD + tarix (picking_rate.edit)