vietreport-admin/solution-erp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b1bae77c9c9863b846be418c7e8c1c695b11656a
solution-erp/.claude/workflows/runs/2026-07-27-S155-pe-delete-approver/reviewer-spec-review.md
pqhuy1987 8c5b3717df wal: flush 20260727T1030
2026-07-27 10:30:24 +07:00

28 KiB
Raw Blame History

reviewer-spec-review — chấm đối-kháng SPEC spec-pe-delete-approver.md

run 2026-07-27-S155-pe-delete-approver · S3 · vai reviewer (READ-only, verdict-only) Quy ước: mọi FLAG đều có file:line mở được. Mọi trục PASS đều kèm đã thử phá bằng cách nào. Ghi TRONG LÚC LÀM (chống #53).

VERDICT: PASS-WITH-FLAGS — 17 FLAG (4 HIGH / 8 MED / 5 LOW). Khung spec đứng vững: trích dẫn chịu lực đúng, mệnh đề trung tâm F.0 không bác được. Nhưng 4 lỗ HIGH sẽ cho ra bản cài đặt hỏng hoặc hở nếu giao thẳng cho hmw. H1/H2/H3 phải chốt trước khi bắt đầu code (H1 + H2 cần owner trả lời 1 câu; H3 là 2 dòng ràng buộc phải viết vào checklist).

🔴 HIGH

H1 — Nới authz mà không một ai có quyền: checklist 7 vừa phá chức năng đang chạy vừa giết luôn tính năng mới

Điều sai. Checklist 7 gắn [Authorize(Policy = "PurchaseEvaluations.Delete")] lên action Delete, và spec kết luận "0 key mới, 0 migration quyền" (§B3 dòng 66). Nhưng spec không kiểm ai đang có cờ CanDelete.

Bằng chứng đo được (Dev DB, SolutionErp_Dev, lệnh chạy thật):

SELECT r.Name, p.CanDelete FROM Permissions p JOIN Roles r ON r.Id=p.RoleId
WHERE p.MenuKey='PurchaseEvaluations'

→ Admin=1 · DeptManager=1 · Accounting/AuthorizedSigner/CatalogManager/CostControl/Director/Drafter/Equipment/Finance/HrAdmin/Procurement/ProjectManager = 0 (11/13 role = 0).

Nguồn của con số đó nằm trong mã: DbInitializer.cs:2515 — bool canDelete = roleName == AppRoles.DeptManager; // chỉ TPB xóa nháp. Và seeder thứ hai chỉ nâng CanRead/CanCreate, không bao giờ chạm CanDelete (DbInitializer.cs:2120-2126), lại skip-if-exists (:2118) ⇒ sửa seeder cũng không vá được prod.

Tầng policy không kế thừa: MenuPermissionHandler.cs:41-51 lọc p.MenuKey == req.MenuKey khớp chính xác rồi AnyAsync(p => p.CanDelete). Cơ chế kế thừa mà spec dẫn (GetMyMenuTreeQuery:66-72) chỉ là display-layer — đúng như spec nói, nhưng nó không cấp quyền API.

Hai hệ quả cụ thể:

  1. Regression trên chức năng đang chạy: nút "Xóa phiếu" bản Nháp (fe-user/src/components/pe/PeDetailTabs.tsx:445 + :460) hôm nay chạy được vì endpoint không có policy. Gắn policy vào ⇒ role Drafter (người soạn phiếu) mất quyền xoá nháp của chính mình.
  2. Tính năng mới chết ngay: approver trong ảnh UAT thuộc Phòng Cung ứng ⇒ role Procurement, CanDelete=0 ⇒ 403 dù đúng lượt và đúng cờ F6.

Test 25 chỉ kiểm chiều 403 nên nó sẽ xanh trong cả hai kịch bản hỏng trên. Không có test chiều thuận (đủ quyền ⇒ 204).

Đề xuất sửa. (a) Thêm mục checklist: cấp CanDelete cho tập role đích + ghi rõ đường cấp (tick tay /system/permissions trên prod hay seeder có upgrade-path như khối :2120-2126); (b) chốt với owner: quyền xoá-nháp (Drafter) và quyền xoá-khi-đang-duyệt (approver) dùng chung 1 cờ hay tách; (c) thêm test happy-path 204 cạnh test 25.

H2 — AllowApproverDelete per-ROW hay per-CẤP: spec chốt "per-Cấp" nhưng giấu hệ quả, và mã có sẵn cả hai cách đọc

Điều sai (2 lớp).

Lớp 1 — mơ hồ thi hành. Nhà của cờ là ApprovalWorkflowLevel, mà 1 row = 1 NGƯỜI (ApprovalWorkflow.cs:83-88, ApproverUserId là field của row). "Cấp" chỉ là tập row cùng Order. Vậy AllowApproverDelete của "Cấp" phải đọc bằng cách nào? Repo đang dùng cả hai cho cờ anh em F5:

  • per-ROW: PurchaseEvaluationWorkflowService.cs:859 — if (matchingLevel.AllowApproverFinalize && applyLevelFinalize)
  • per-CẤP: PurchaseEvaluationFeatures.cs:1182 — g.Any(l => l.AllowApproverFinalize)

⇒ hai người cài đặt sẽ ra hai kết quả khác nhau từ đúng câu chữ §B2 dòng 60 ("Cấp đó có AllowApproverDelete == true").

Lớp 2 — hệ quả chưa khai. Đọc theo per-Cấp (Any) ⇒ mọi người trong Cấp đều xoá được. Ảnh prod (run.md dòng 74) ghi rõ Cấp 2 Phòng Cung ứng có 3 người (Bùi Lê Thủy Trà, Trần Xuân Lưu, Lê Trần Đăng Trường). Owner chốt (1) là "Người đứng đầu phòng đc xóa khi đến lượt họ" = 1 người. Spec §2 có khai "đổi nghĩa" nhưng chỉ khai vế "thành cấp nào admin tick" — không khai vế "và như vậy N người cùng Cấp đều xoá được". Đó là hệ quả trực tiếp lên quyền huỷ chứng-từ tài chính, phải nằm trên bàn.

Đề xuất sửa. Chốt bằng chữ trong spec + checklist: dùng matchingLevel.AllowApproverDelete (per-row, 1 người — sát ý owner) hay pendingLevelGroup.Any(...) (per-Cấp, N người). Nếu chọn per-Cấp thì thêm 1 dòng khai hệ quả "N người" cho owner duyệt lại.

H3 — Endpoint "Đã xóa" thiếu 2 ràng buộc bắt buộc; D3 kín về rò-accumulator nhưng hở về rò-dữ-liệu

Điều sai. Checklist 8 chỉ ghi "handler RIÊNG list 'Đã xóa' với IgnoreQueryFilters() — tuân D3". Thiếu hai thứ:

  1. Thiếu .Where(x => x.IsDeleted). IgnoreQueryFilters() gỡ toàn bộ filter chứ không đảo nó ⇒ query trả cả phiếu sống lẫn phiếu xoá. Màn "Đã xóa" sẽ liệt kê mọi phiếu trong hệ thống. Không mục nào trong spec nói câu này; test 22 chỉ soi accumulator nên không bắt được.
  2. Thiếu tái lập IDOR-scope. Handler list hiện hành có rào chặt: PurchaseEvaluationFeatures.cs:596-617 — non-admin chỉ thấy phiếu khi (i) mình là Drafter, (ii) phase ∈ eligiblePhases theo role, hoặc (iii) mình là approver trong workflow đã pin. Handler MỚI dựng từ đầu mặc định không có gì. Kết quả: mọi user đăng nhập đọc được toàn bộ phiếu đã xoá của mọi dự án, kèm BudgetPeriodAmount + tên gói thầu + NCC (đúng bộ field của PurchaseEvaluationListItemDto).

Đây là 2 "đường rò thứ 4/thứ 5" mà 3 điều cấm của D3 không phủ — D3 chỉ chống rò sang accumulator, không chống rò ra người dùng.

Đề xuất sửa. Viết thẳng vào checklist 8: IgnoreQueryFilters().Where(x => x.IsDeleted) ∧ sao chép nguyên khối IDOR :596-617 (hoặc siết hơn: chỉ Drafter của phiếu + approver của workflow pin + Admin). Thêm 2 test: (a) list "Đã xóa" không chứa phiếu sống; (b) user ngoài phạm vi không thấy phiếu đã xoá của người khác.

H4 — Lệnh Update quy trình (F-1…F-11) không khai policy authz, trong khi chính nó là cổng cấp quyền

Điều sai. F-1 chỉ nói "UpdateAwDefinitionCommand mới". Không dòng nào nói endpoint mới phải mang policy. Mọi verb GHI hiện có của controller này đều có: ApprovalWorkflowsV2Controller.cs:29 (POST), :40 (PATCH user-selectable), :48 (DELETE) — cả ba đều [Authorize(Policy = "Workflows.Create")]; class chỉ [Authorize] trần (:18).

Vì sao nghiêm trọng hơn một endpoint thường: hai thao tác mà F-1 cho phép đều là hành vi cấp quyền:

  • op #1 "thêm người vào Cấp có sẵn" ⇒ tự thêm mình vào pendingLevelGroup ⇒ lọt guard PurchaseEvaluationWorkflowService.cs:702-708 ⇒ duyệt được phiếu người khác;
  • op #2 "bật/tắt cờ Allow*" ⇒ gồm chính F6 ⇒ tự cấp quyền xoá phiếu đang duyệt.

Thiếu 1 dòng attribute = leo thang đặc quyền cho mọi tài khoản đăng nhập.

Đề xuất sửa. Ghi rõ trong F-1: [Authorize(Policy = "Workflows.Create")] (hoặc key riêng nếu owner muốn tách), + 1 test 403 cho user thường, + cân nhắc ghi vết thay-đổi-quy-trình (spec đòi changelog cho xoá phiếu ở B4 nhưng không đòi vết cho việc sửa quyền — bất đối xứng).

🟠 MED

M1 — Quy tắc F.2 không đủ chặt: 3 phản ví dụ giữ nguyên cả 2 tập Order mà vẫn hỏng phiếu đang chạy

Phát biểu đang xét: "AN TOÀN ⟺ KHÔNG đổi tập {Step.Order} và tập {Level.Order}" (§F.2 dòng 208).

(a) Cờ AllowApproverFinalize (F5) bật/tắt giữa chừng — đổi ĐIỂM KẾT THÚC của phiếu đang chờ. PurchaseEvaluationWorkflowService.cs:859-878: khi matchingLevel.AllowApproverFinalize bật, người duyệt tại cấp đó kết thúc luôn (Phase = DaDuyet, :866, kèm ApplyBudgetSnapshotOnFinalizeAsync :865 = đóng băng số tiền). Bật cờ này cho một Cấp mà phiếu chưa đi tới ⇒ phiếu đang chờ nay không lên Ban Giám đốc nữa. Tắt ⇒ ngược lại. Spec xếp mọi cờ Allow* vào ✅ AN TOÀN (#2) "thuộc tính row, 0 đụng Order", trong khi xếp CeoApprovalThreshold vào ❓HỎI OWNER (#12) với lý do "đổi nghĩa quyết định đang chờ". Cùng một lý do, hai kết luận. F5 còn nặng hơn threshold: threshold vẫn cần CCM chủ động tích (:881-901), F5 thì đọc thẳng ở :859.

(b) matchingLevel fallback pendingLevelGroup.First() — thao tác #1 "thêm người" chạm đúng chỗ này. :733-734: var matchingLevel = pendingLevelGroup.FirstOrDefault(l => … l.ApproverUserId == actorUserId) ?? pendingLevelGroup.First();. Nhánh .First() chạy khi Admin duyệt thay. Thứ tự bên trong nhóm do OrderBy(l => l.Order) (:689) quyết — mà các row cùng Order thì không có tie-breaker ⇒ thứ tự do DB trả về. Thêm/bớt row cùng Cấp có thể đổi "row đầu tiên" ⇒ (i) chữ ký admin gắn sang Level row của người khác, (ii) UPSERT LevelOpinion khoá theo (PE, ApprovalWorkflowLevelId) (:736-738) ghi vào row khác. Spec có nhắc First() ở nguồn (sub-invest-wfver-4 F9) nhưng không đưa vào bảng 13 thao tác — đúng chỗ trục 3 nghi ngờ.

(c) Thêm người vào Cấp ĐÃ QUA ⇒ lịch sử duyệt hiển thị SAI. ComputeLevelStatus (PurchaseEvaluationFeatures.cs:1135-1148) thuần con-trỏ: stepIdx0 < currentIdx → "Done". Row mới thêm vào một Cấp đã qua sẽ render "Done" dù người đó chưa từng ký và không có LevelOpinion nào. Ở phiếu DaDuyet còn tuyệt đối hơn: :1137 if (isTerminalDone) return "Done". Bảng 13 thao tác chỉ soi đường duyệt (:689-702), không soi 4 read-site hiển thị cho ca thêm.

Đề xuất sửa. Tách #2 thành 2 dòng: cờ không đổi luồng (F1 4 mode, F3, F4) = ✅; cờ đổi luồng/quyền (F5 AllowApproverFinalize, F6 AllowApproverDelete) = ⚠️/❓ cùng hạng với CeoApprovalThreshold. Thêm 2 dòng vào bảng: "thêm người vào Cấp ĐANG CHỜ khi có khả năng Admin-duyệt-thay" và "thêm người vào Cấp ĐÃ QUA". Bổ sung câu: quy tắc F.2 chỉ bảo đảm con trỏ không dịch, KHÔNG bảo đảm ngữ nghĩa/hiển thị không đổi.

M2 — Bảng 13 thao tác bỏ sót 2 trường admin sửa được mà vẫn giữ nguyên 2 tập Order

ApprovalWorkflow.Code (ApprovalWorkflow.cs:23) và ApplicableType (:25).

  • Đổi Code ⇒ vỡ chuỗi version vì nextVersion = MAX(Version) WHERE Code = request.Code (ApprovalWorkflowV2AdminFeatures.cs:325-328) — bản kế tiếp có thể tụt về v1 hoặc đụng version cũ.
  • Đổi ApplicableType ⇒ (i) phiếu đang pin bỗng chạy workflow của module khác; kiểm tra khớp loại chỉ xảy ra lúc pin (PurchaseEvaluationFeatures.cs:258-265), không có re-validate; (ii) vỡ bất-biến "chỉ 1 active mỗi type" vì khối hạ-active lọc theo ApplicableType (:331-334).

Cả hai giữ nguyên {Step.Order} và {Level.Order} ⇒ theo chữ của F.2 chúng là "AN TOÀN". Nếu F-1 là allow-list đóng (chỉ #1#2#3) thì thực thi vẫn an toàn, nhưng bảng phân loại là tài liệu người sau dùng để mở rộng ⇒ phải khai tường minh 2 trường này thuộc NGOÀI-PHẠM-VI/PHÁ-VỠ.

M3 — Nợ N1 không trung tính lượt này: nó ăn thẳng vào F-5 của chính spec

Xoá mềm ⇒ cascade không chạy (AuditingInterceptor.cs:56-62 đổi Deleted → Modified) ⇒ PurchaseEvaluationLevelOpinions của phiếu đã xoá ở lại DB và vẫn Restrict FK về ApprovalWorkflowLevel (PurchaseEvaluationLevelOpinionConfiguration.cs:25-28). F-5 lại chốt: "chặn khi row đã có LevelOpinion". ⇒ Sau khi tính năng chạy, admin sẽ bị chặn bỏ người khỏi Cấp vì một phiếu đã bị xoá — chặn thật, không phải cảnh báo. Quan trọng: trước lượt này rác chỉ sinh từ phiếu Nháp (hiếm có LevelOpinion); sau lượt này mọi phiếu bị xoá đều ở ChoDuyet ⇒ chắc chắn đã có LevelOpinion + Approvals + Changelogs. Tức lượt này làm N1 tệ hơn theo đúng cái trục mà spec vừa dựng luật. Đề xuất sửa. F-5 phải nói rõ: đếm LevelOpinion loại trừ opinion thuộc PE đã IsDeleted (hoặc khai nhận hành vi chặn-do-phiếu-xoá là chấp nhận được, kèm thông điệp lỗi nói đúng lý do).

M4 — Test 21 phát biểu sai số học ⇒ không thi hành được như viết

Phiếu ChoDuyet chỉ nằm trong 2/4 phép cộng:

  • ✅ PrevSubmitted — PeBudgetAccumulator.cs:53-59 (ChoDuyet || DaDuyet);
  • ✅ PendingSelected — :114-117 (loại {DangSoanThao, DaDuyet, TuChoi} + có winner);
  • ❌ PrevSelected — :61-62 đòi Phase == DaDuyet;
  • ❌ PendingSubmitted — :107 loại tường minh ChoDuyet.

Test 21 viết "cả 4 phép cộng lũy kế giảm đúng". Với 2 phép sau, delta đúng = 0. Ai viết assert "giảm" cho cả 4 sẽ có test không thể xanh; ai viết assert "giảm" cho 2 và quên 2 kia sẽ mất chốt chặn hồi quy. Ngoài ra ComputePendingAsync còn output thứ 5: PriorPes (:128-133, gồm cả phiếu Nháp) cũng đổi sau khi xoá — spec không nhắc. Đề xuất sửa. Viết lại test 21 thành 4 assert có hướng: PrevSubmitted ↓, PendingSelected ↓, PrevSelected không đổi, PendingSubmitted không đổi, + PriorPes mất đúng 1 phần tử.

M5 — §E1 nói mạnh hơn bằng chứng, và checklist 14 ⟂ 15 mô tả hai nút khác nhau

  • Sự thật đo được: PeWorkflowPanel nhận đúng 3 prop {evaluation, readOnly, onApproved} — fe-user/src/components/pe/PeWorkflowPanel.tsx:31-43. Không có onDelete, không có mutation xoá trong file.
  • onDelete được truyền cho PeDetailTabs, không phải cho panel: PurchaseEvaluationsListPage.tsx:570-575 và :665-670 (đúng số dòng spec dẫn, sai component).
  • §E2 lại đặt nút mới vào PeWorkflowPanel.tsx:458-506.

⇒ Câu "Dây đã nối sẵn" (§E1) không đúng cho chỗ đặt nút. sub-invest-fe-2 đã khai đúng ở PH-14 mục 4 ("phải nâng mutation del lên rồi truyền prop mới cho PeWorkflowPanel, hoặc tạo mutation riêng") — spec bỏ mất caveat này. Kèm theo: checklist 14 đặt nút trong panel; checklist 15 bảo "bỏ chặn readOnly cho riêng nút Xóa" — nhưng nút bị chặn đó nằm trong PeDetailTabs với gate 3 điều kiện mode === 'workspace' && canEditPhase && !readOnly (PeDetailTabs.tsx:445) cộng phase === DangSoanThao (:460); màn Duyệt truyền mode mặc định 'detail' và canEditPhase=false ở ChoDuyet. ⇒ "bỏ chặn readOnly" không đủ, và hai mục sẽ đẻ ra 2 nút Xoá hoặc 1 nút không nối dây. Đề xuất sửa. Chốt 1 chỗ đặt nút duy nhất; ghi rõ prop/mutation phải thêm; xoá hoặc viết lại mục 15 cho khớp mục 14.

M6 — Checklist 27 bảo sửa row Policies + Menu keys trong STATUS.md — hai số đó KHÔNG được đổi

docs/STATUS.md:450 ghi rõ Policies = |MenuKeys.All| × |MenuKeys.Actions| = 54 × 4 = 216 (DERIVED, governance-detectors.ps1 resolve canonical từ đúng row này) và :451 Menu keys = 54 (đếm MenuKeys.All). Key mới "Đã duyệt"/"Đã xóa" là Pe_* sinh qua factory (MenuKeys.cs:134-141), không nằm trong All (:147-165 — đã đọc toàn bộ, Pe_* vắng mặt; đây cũng chính là điều spec dùng để loại [Authorize(Policy="Pe_….Delete")]). ⇒ Cả 2 số giữ nguyên 54 / 216. Làm theo mục 27 = ghi số sai vào chỗ canonical đang bị detector soi. Đề xuất sửa. Mục 27 chỉ giữ "Mig mới"; nếu muốn ghi số mục menu thì ghi ở chỗ khác và nói rõ đó là số row MenuItems, không phải MenuKeys.All.

M7 — Thứ tự thi công: văn xuôi và checklist đá nhau

§F.0 chốt "A-E KHÔNG CHẠY nếu thiếu F", nhưng §4 CHECKLIST xếp A-E (mục 1→28) trước, còn F (F-1→F-16) nằm ở PHẦN II cuối file, không có mốc thứ tự nào. Người làm top-down sẽ dựng đúng thứ tự mà spec vừa cảnh báo là hỏng. Migration F6 (mục 2) đứng trước lệnh Update (F-1) cũng đúng, nhưng phải nói ra. Đề xuất sửa. 1 dòng thứ-tự cứng đầu §4: mục 1-2 (schema F6) → F-1…F-4 (lệnh Update + validator) → 3-8 → 9-13 → 14-20 → test.

M8 — Mục 3 và F-11 là cùng một việc, hai độ sâu ⇒ mục 3 sẽ rơi đúng bẫy F-11 cảnh báo

Mục 3: "DTO + Designer admin: tick F6 per-Cấp (mirror chỗ tick F5)". F-11: liệt 5 dây FE :54 / :110 / :159 / :177 / :605 + cảnh báo 🔴 "thiếu :605 = tick xong KHÔNG gửi lên BE" + fe-user:282 + 4 neo BE :41 / :230 / :188 / :368. Ai làm theo mục 3 mà không lật xuống PHẦN II sẽ sót đúng cái :605. (Neo BE của F-11 kiểm chứng được: ApprovalWorkflowV2AdminFeatures.cs:230 AllowApproverFinalize trong CreateAwLevelInput, :368 map vào entity — khuôn đúng.) Đề xuất sửa. Gộp mục 3 vào F-11 hoặc trỏ chéo tường minh.

🟡 LOW

L1 — Tiêu đề F.0 mạnh hơn thân bài

"A-E KHÔNG CHẠY nếu thiếu F" → chính xác phải là "A-E không tới được phiếu đang treo". Phiếu tạo mới sau khi kích hoạt v(n+1) vẫn có cờ và vẫn xoá được. Thân bài (dòng 195-196) nói đúng điều này; chỉ tiêu đề quá rộng. Giữ nguyên kết luận thứ-tự-thi-công, chỉ sửa chữ để người sau không suy rộng sai.

L2 — §1 bỏ mất dữ kiện đối trọng cho vế "quay lại không được"

Vế lũy kế của spec đúng (đã kiểm, xem trục 2). Nhưng ở TraLai, người soạn được đổi hạng mục: UpdatePurchaseEvaluationDraftCommand.WorkItemId (PurchaseEvaluationFeatures.cs:221) + write :301-302, guard cho phép DangSoanThao ∥ TraLai (:248-250). Tức "bấm sai gói thầu" có đường tự sửa (dời lũy kế sang gói đúng), chỉ là vẫn ăn số trong lúc chờ sửa. Không đổi quyết định owner, nhưng nên khai để §1 không bị đọc thành "không còn cách nào khác".

L3 — 2 trích dẫn lệch biên 1 dòng (nội dung đúng)

  • DbInitializer.cs:1893-1903: nhánh if (existingItems.TryGetValue…) bắt đầu đúng :1893, nhưng continue; nằm ở :1904 (đóng nhánh :1905). Nội dung "chỉ update Order rồi continue, KHÔNG đụng Label" đúng 100% (comment :1897-1898 tự khai).
  • :1917-1923: var labelBackfill = … khai ở :1918, 4 entry :1920-1923, đóng :1924. Dòng :1917 là comment. Vô hại nhưng nên chỉnh cho khớp.

L4 — F-12 bị dán nhãn "bài kiểm chứng F.0" nhưng chỉ chứng chiều thuận

F-12 chứng "update tại chỗ ăn ngay vào phiếu đang chạy". Mệnh đề F.0 còn nửa kia: "POST version mới không tới phiếu đang treo". Không có test cho nửa đó, mà nó rẻ: tick F6 bằng POST ⇒ phiếu treo vẫn bị từ chối xoá. Thêm 1 test này thì F.0 mới có răng.

L5 — N4 ("TuChoi là nhánh chết") đúng về transition nhưng đừng dọn vội

Guard PurchaseEvaluationWorkflowService.cs:101-106 chặn đường đi tới TuChoi, nhưng chính comment :99 ghi "Phase TuChoi + phiếu TuChoi cũ GIỮ display/filter" ⇒ phiếu TuChoi cũ vẫn tồn tại, và nhánh allow-list xoá vẫn phục vụ chúng. Dọn nhánh = mất quyền xoá phiếu lịch sử. Nên ghi rõ trong N4.

✅ ĐIỂM SPEC LÀM ĐÚNG — đừng sửa hỏng

  1. Trích dẫn chịu lực: 16/16 mẫu ĐÚNG DÒNG + ĐÚNG NỘI DUNG. Gồm PeBudgetAccumulator.cs:53-59 · :104-126 · :114-126 · PurchaseEvaluationFeatures.cs:1404-1406 · :149 · :249-251 · :291 · ApprovalWorkflowV2AdminFeatures.cs:325-328 · :331-334 · :336 · PurchaseEvaluationWorkflowService.cs:674 · :683 · :686 · :694-695 · :705 · :101-106 · PurchaseEvaluationsController.cs:146-151 · MenuKeys.cs:147-165 · Program.cs:82-89 (khớp chính xác khối foreach menu → foreach action → AddPolicy) · DbInitializer.cs:2092-2096 + :2492-2496 (cả hai đúng từng dòng — 5 dòng Add(...) mỗi bên) · PurchaseEvaluationConfiguration.cs:84 · ApprovalWorkflow.cs:81-82.
  2. E3 md5 kiểm lại bằng lệnh thật: md5sum cho cùng 02671be6334110028c55fe82f5e70dee ở cả fe-user và fe-admin, 942 dòng — đúng y spec. Luật "mirror 2 app thay cho 4-place" là luật đúng cho việc này.
  3. B3 chọn policy root thay Pe_* là ĐÚNG và lý do đúng: Pe_* thật sự vắng khỏi MenuKeys.All (đọc trọn :147-165), mà Program.cs:82-89 chỉ đăng ký policy cho phần tử của All.
  4. Bẫy labelBackfill là THẬT và quan trọng: vòng upsert gặp key cũ chỉ sửa Order rồi continue, comment :1897-1898 tự khai "KHÔNG đụng Label / ParentKey / Icon". Sửa tree.Add mà không thêm labelBackfill sẽ không đổi được nhãn trên DB đã seed. Giữ nguyên cảnh báo 🔴 ở mục 11.
  5. D3 (3 điều cấm + "handler riêng, KHÔNG thêm cờ includeDeleted") là đúng và đáng giữ nguyên chữ — đã kiểm: IgnoreQueryFilters() là toán tử trên một IQueryable, 2 hàm accumulator đều dựng peers mới (:49-51, :100-102), nên không rò chéo. (Lỗ của D3 nằm ở chỗ khác — xem H3.)
  6. F-3 (CẤM delete-then-insert, diff theo Level.Id) và F-9 (usage-check trước khi xoá version) là hai điều đúng và bắt buộc: FK Restrict ở PurchaseEvaluationLevelOpinionConfiguration.cs:25-28 + PurchaseEvaluationConfiguration.cs:67-73, và handler xoá hiện tại (ApprovalWorkflowV2AdminFeatures.cs:406-418) thật sự Remove() thẳng, 0 usage-check, đúng như nợ tự khai :400-402.
  7. Khảo cổ S60 (6db195d) và mắt xích "guard tự trỏ sang Xóa phiếu" — kiểm lại trên đĩa: PurchaseEvaluationWorkflowService.cs:101-106 đúng nguyên văn. Đây là phần chẩn-đoán mạnh nhất của spec.

🎯 THÁCH-CLEAN: đã thử phá bằng cách nào

Trục 2 — mệnh đề F.0: KHÔNG bác được (6 đường tấn công, đều tắc)

# Đường thử bác Kết quả
1 Có write-site nào khác ghi PE.ApprovalWorkflowId (job/seeder/admin action)? grep -rn "ApprovalWorkflowId\s*=" --include=*.cs src/Backend | grep -v Migrations → PE đúng 2 write-site: :149 (create) + :291 (update). Các module Office (LeaveOtApprovalFeatures.cs:238/:509/:537/:702, ProposalFeatures.cs:277/:339, TravelVehicleApprovalFeatures.cs:189/:549/:774/:802) có re-pin — nhưng không phải PE. Mắt xích 4 đứng.
2 Có migration/Sql() nào backfill lại con trỏ workflow? grep -rniE "ApprovalWorkflowId" Migrations/*.cs | grep -iE "UPDATE|Sql\(" → 0 hit. grep "Sql(" Migrations/*.cs | grep -i purchaseeval → 0 hit. Đứng.
3 Có chỗ nào phiếu resolve workflow theo Code+IsActive thay vì Id? ApproveV2Async :671-675 chỉ w.Id == awId. Inbox :832-836 lấy wfIds từ chính phiếu. Badge list :672-685 join lv.Step!.ApprovalWorkflowId == x.e.ApprovalWorkflowId. Flow-tree dùng workflow đã pin. Không có đường Code/IsActive. Đứng.
4 Admin xoá bản cũ để ép phiếu rơi sang bản mới? FK Restrict (PurchaseEvaluationConfiguration.cs:67-73) ⇒ nổ FK, không "rơi sang". Đứng.
5 Drafter sửa phiếu lúc ChoDuyet để re-pin? Chặn :248-250. Đứng.
6 Trả lại → sửa → gửi lại có re-pin không? CÓ (:248-250 cho TraLai, write :291) — nhưng spec đã tự khai ở dòng 196 và đúng là không giải được ca gốc trong 1 bước. Chỉ làm yếu tiêu đề, không làm yếu kết luận (⇒ L1).

⇒ Kết luận F.0 ĐỨNG. Thứ tự thi công "F trước" là đúng.

Trục 1 — vì sao không cho FAIL: đã kiểm từng trích dẫn chịu lực bằng cách mở file, không đọc lại spec. Cách phá đã dùng: (a) so từng số dòng với sed -n/Read có đánh số; (b) đếm ngược thủ công 2 khối DbInitializer (2075→2096 và 2470→2496) để chắc 2 danh sách permission song song đúng dòng; (c) tính lại md5 thay vì tin con số spec chép. Lỗi duy nhất tìm được là diễn giải (M5), không phải số dòng.

Trục 5 — an toàn/số liệu: đã thử phá bằng 4 câu hỏi

(i) "3 điều cấm D3 có đủ không" → KHÔNG (H3, 2 đường rò khác trục); (ii) "nới allow-list rồi ai vẫn xoá được" → đo bảng Permissions thật (H1); (iii) "test có răng không" → test 21 sai số học (M4), test 25 xanh-giả (H1), test 22 có răng cho đúng thứ nó tuyên bố; (iv) "hoãn N1 có trung tính không" → KHÔNG (M3, đụng thẳng F-5).

Trục 6 — trung thực: 3 chỗ nói mạnh hơn bằng chứng đã tìm được là M5 (dây FE), L1 (tiêu đề F.0), H2-lớp-2 (hệ quả "N người cùng Cấp"). Ngoài ra spec giữ đúng nhãn nguồn: những chỗ sub gắn [SUY LUẬN] (vd F10 "chỉ cần nới guard là số tự đúng") được spec trình bày kèm cơ chế query filter chứ không đội lốt [CODE].

📌 Việc phải làm trước khi giao hmw (rút gọn)

  1. Owner trả lời 1 câu: F6 đọc per-ROW (1 người) hay per-CẤP (N người)? → H2.
  2. Chốt đường cấp quyền PurchaseEvaluations.Delete cho tập role đích + xác nhận không cắt quyền xoá-nháp của Drafter → H1.
  3. Thêm 2 ràng buộc vào checklist 8 (.Where(IsDeleted) + IDOR-scope) → H3.
  4. Thêm policy vào F-1 → H4.
  5. Sửa bảng F.2 (M1/M2), sửa test 21 (M4), gỡ mâu thuẫn 14/15 (M5), bỏ "Policies/Menu keys" khỏi mục 27 (M6), thêm dòng thứ tự (M7).