230 lines
22 KiB
Markdown
230 lines
22 KiB
Markdown
REVIEW-F1: PASS-WITH-FLAGS 7 — 3 MAJOR (G-1 default ngược PE-live · G-2 sơ đồ nói CEO "đã duyệt" · G-6 cây phình 5→7 file, K4a bị commit ké) / 4 MINOR; 0 blocker kỹ-thuật trên 5 file F-1, 1 blocker quy-trình (G-6: tách commit trước khi push)
|
||
|
||
# Reviewer F-1 — ô-tích opt-out `applyLevelFinalize` panel duyệt KHKK
|
||
|
||
Ghi-đĩa TRONG LÚC SOI (chống #53). Đo từ ĐĨA, HEAD `24ea71e`, diff CHƯA commit.
|
||
Phạm vi: `git diff -- src fe-user fe-admin` = **5 file M, +137 / −14**.
|
||
|
||
## §0 Mirror 2 app — chứng bằng blob-SHA của git (KHÔNG tin lời khai)
|
||
|
||
`git diff` in ra index-line của cả 2 app:
|
||
|
||
| Cặp file | blob TRƯỚC | blob SAU |
|
||
|---|---|---|
|
||
| `fe-{admin,user}/src/pages/khkk/KhkkWorkflowPanel.tsx` | `e2fa3bc` (cả hai) | `6913182` (cả hai) |
|
||
| `fe-{admin,user}/src/types/khkk.ts` | `a99658c` (cả hai) | `1ffd79b` (cả hai) |
|
||
|
||
⇒ 2 cặp **byte-identical cả trước lẫn sau** (git blob = sha1 nội dung) — mirror §3.9 ĐẠT, và
|
||
không có nhánh "sửa 1 app quên app kia". ✅
|
||
|
||
## §1 Ranh giới BE — cờ có tới FE bằng ĐÚNG một đường
|
||
|
||
- `ContractSigningPlanWorkflowLevelDto` (`ContractSigningPlanFeatures.cs:116`) +1 positional
|
||
`bool AllowApproverFinalize`; **construction site = 1** (`:640`, grep toàn `src/Backend` cho
|
||
đúng 3 hit: `:116` def · `:132` kiểu List · `:640` new) ⇒ không có site thứ 2 lỡ truyền `false` cứng.
|
||
- `l.AllowApproverFinalize` đọc thẳng từ `ApprovalWorkflowLevel` của **đúng workflow đã pin**
|
||
(cùng bảng, cùng row mà `ResolveActingLevel` sẽ chấm lúc duyệt) ⇒ không có nguồn thứ hai.
|
||
- 0 đổi logic BE: `git diff` trên `src` chỉ 2 hunk, cả 2 nằm trong DTO + projection. ✅
|
||
|
||
## §2 (đề bài 1) `actingLevel` FE có mirror ĐÚNG `ResolveActingLevel` không
|
||
|
||
BE (`ContractSigningPlanWorkflowService.cs:463-468`):
|
||
`own = pendingLevelGroup.FirstOrDefault(l => l.ApproverUserId == actorId)` → `if (own is not null) return own;`
|
||
→ `if (isAdmin) return pendingLevelGroup.First();` → còn lại **ném Forbidden**.
|
||
FE (`KhkkWorkflowPanel.tsx:135-137`):
|
||
`currentLevels.find(l => l.approverUserId === user?.id) ?? (isAdmin ? currentLevels[0] : undefined)`.
|
||
|
||
| Ca | BE chấm level nào | FE chấm level nào | Khớp? |
|
||
|---|---|---|---|
|
||
| Actor ∈ Cấp, cấp CÓ cờ | own (có cờ) | own (có cờ) → hiện ô-tích | ✅ |
|
||
| Actor ∈ Cấp OR-of-N, **cờ ở NGƯỜI KHÁC cùng Cấp** | own (KHÔNG cờ) ⇒ không finalize | own (KHÔNG cờ) ⇒ ẩn ô-tích, gửi `true` = no-op | ✅ (ca đề bài hỏi kỹ — không rò) |
|
||
| Admin **có** slot riêng trong Cấp | own | own (vì `find` chạy TRƯỚC nhánh isAdmin) | ✅ |
|
||
| Admin **không** có slot | `pendingLevelGroup.First()` | `currentLevels[0]` | ⚠️ xem §6 (thứ tự 2 truy vấn) |
|
||
| Không phải approver, không Admin | **Forbidden 403** | `undefined` ⇒ ẩn ô-tích | ✅ (và nút Duyệt đã `disabled` bởi `blockedByLevel` `:130`) |
|
||
| `currentLevels` **RỖNG** (phase ≠ ChoDuyet, hoặc con-trỏ null, hoặc idx ngoài biên) | không tới `ApproveV2Async` (409 `:250-251`) | `find`→undefined, `currentLevels[0]`→`undefined` ⇒ eligible=false | ✅ **không nổ** (index-out-of-range trên mảng rỗng trong JS = `undefined`, không throw) |
|
||
| `user` chưa nạp (`user?.id` undefined) | — | `find` không khớp (`approverUserId` là `string` non-null) ⇒ undefined; `isAdmin`=false ⇒ nút Duyệt disabled | ✅ |
|
||
|
||
Vế **so-khớp GUID dạng chuỗi**: `user.id` sinh từ `res.data.user` (`AuthContext.tsx:53-56`, DTO login
|
||
serialize `Guid` → chữ thường có gạch), `approverUserId` cũng là `Guid` serialize cùng kiểu ⇒ `===`
|
||
hợp lệ; và đây là **cùng phép so đã sống từ W3** (`:127` `actorIsCurrentApprover`), không phải phép mới.
|
||
|
||
⇒ **Mirror ĐÚNG 6/7 ca**; ca thứ 7 (Admin duyệt-thay trên Cấp **trộn cờ**) là finding §6/G-4.
|
||
|
||
## §3 (đề bài 2) Body — rò field ở action khác? khớp hợp-đồng `bool?`?
|
||
|
||
`KhkkWorkflowPanel.tsx:151-157`:
|
||
`{ action, comment, ...(a === Approve ? { applyLevelFinalize: eligible ? state : true } : {}) }`
|
||
|
||
| Action | Key có trong JSON? | Giá trị | BE nhận | Ảnh hưởng |
|
||
|---|---|---|---|---|
|
||
| `submit` | **KHÔNG** | — | `ApplyLevelFinalize = null` → `?? true` (`Controller:213`) | `SubmitAsync` **không nhận tham số** (`Service:122`) ⇒ vô hại |
|
||
| `return` / `reject` | **KHÔNG** | — | như trên | `ReturnOrRejectAsync` **không nhận tham số** (`:130-136`) ⇒ vô hại |
|
||
| `approve`, cấp thường | CÓ | `true` | `true` | `actingLevel.AllowApproverFinalize && true` = **false** ⇒ no-op (§4) |
|
||
| `approve`, cấp có cờ, giữ tick | CÓ | `true` | `true` | finalize (đúng ý người bấm) |
|
||
| `approve`, cấp có cờ, bỏ tick | CÓ | `false` | `false` | rơi xuống advance thường ⇒ trình tiếp (đúng mục tiêu F-1) |
|
||
|
||
⇒ **0 rò field** sang action khác; và ngay cả khi rò cũng không có chỗ đọc ở BE (3 nhánh kia không có tham số).
|
||
|
||
**absent vs null vs true** — hợp-đồng `ContractSigningPlanTransitionBody(string Action, string? Comment = null, bool? ApplyLevelFinalize = null)`:
|
||
key vắng ⇒ System.Text.Json để `bool?` = `null` (bằng ĐÚNG giá trị mặc định khai báo, nên **không phụ thuộc**
|
||
vào chuyện STJ có tôn trọng default-parameter-value của positional record hay không — cả hai đường đều ra `null`)
|
||
⇒ `?? true`. FE **không bao giờ** gửi `null` tường minh (spread bỏ hẳn key, không set `undefined`).
|
||
⇒ 3 trạng thái absent/null/true hội tụ về CÙNG một hành vi. ✅ Khớp hợp-đồng.
|
||
|
||
## §4 (đề bài 3) Regression cấp thường + rò ô-tích ở phase khác
|
||
|
||
**Cấp thường (không cờ), trước ⟂ sau vá:**
|
||
- trước: body `{action, comment}` ⇒ BE `?? true` ⇒ `applyLevelFinalize=true`
|
||
- sau: body `{action, comment, applyLevelFinalize: true}` ⇒ BE `true`
|
||
⇒ **cùng một giá trị đi vào cùng một biểu thức** `if (actingLevel.AllowApproverFinalize && applyLevelFinalize)`
|
||
(`Service:276`), mà vế trái = `false` ⇒ nhánh không vào ở CẢ HAI thế giới. Hành vi **y hệt**, không phải
|
||
"giống về mặt cảm tính". ✅
|
||
(Điểm yếu còn lại là của thiết kế BE, không phải của diff: no-op này chỉ đúng vì BE **AND** với cờ cấp —
|
||
FE gửi `true` cho người không có quyền finalize là dữ liệu thừa, không phải quyền thừa.)
|
||
|
||
**Rò ô-tích ở phase khác — 3 lớp chặn ĐỘC LẬP, hỏng 1 lớp vẫn không rò:**
|
||
1. `currentLevels` chỉ khác `[]` khi `isWaiting` (`:118-121`) ⇒ DaDuyet/TraLai/TuChoi/Nháp ⇒ `actingLevel=undefined` ⇒ `approverFinalizeEligible=false`.
|
||
2. Nút "Duyệt" (đường DUY NHẤT đặt `action=Approve`) chỉ render trong `{isWaiting && (…)}` (`:312-335`).
|
||
3. Chính JSX ô-tích đòi `action === Approve` (`:443`).
|
||
⇒ **0 rò**. Kiểm chéo: `KhkkTransitionAction.Approve` được gán ở đúng 1 site (`:323`), grep 2 app cho thấy
|
||
không có site thứ hai. ✅
|
||
|
||
**Reset trạng thái:** `setApplyLevelFinalize(true)` đặt ở `onClick` mở dialog (`:322`) ⇒ bỏ tick rồi **Huỷ**
|
||
rồi mở lại vẫn về mặc định. (PE chỉ reset trong `onSuccess` `:288` ⇒ PE **giữ** tick sau khi Huỷ — chỗ này
|
||
KHKK **chặt hơn** khuôn.) ✅
|
||
|
||
## §5 (đề bài 4) Khuôn-PE fidelity — lệch CỐ Ý vs SÓT
|
||
|
||
| # | Trục | PE (live) | KHKK (diff) | Phán |
|
||
|---|---|---|---|---|
|
||
| a | JSX ô-tích | `:772-791` | `:443-462` — cùng khung, cùng nhãn "Cấp này KẾT THÚC quy trình" | ✅ trung thành |
|
||
| b | Câu "Nhớ chọn 1 giá chốt" | có (`:786`) | bỏ | ✅ **CỐ Ý** — KHKK 0 price-picker, BE tự chốt ở `ApplyApprovedValuesOnFinalize` |
|
||
| c | Gửi field | luôn gửi, `!isReject && (...)` (`:259`) | chỉ gửi khi approve | ✅ tương đương (3 nhánh kia BE không đọc) |
|
||
| d | Reset state | `onSuccess` | mở-dialog | ✅ KHKK chặt hơn |
|
||
| e | **Default ô-tích** | **`useState(false)` = OPT-IN** (`:61`) | **`useState(true)` = OPT-OUT** (`:85`) | 🔴 **G-1 — lệch NGƯỢC khuôn LIVE** |
|
||
| f | Nguồn eligibility | BE precompute `currentLevelOptions` chọn level theo actor (`PurchaseEvaluationFeatures.cs:1083-1085`) | FE **tự mirror** `ResolveActingLevel` | 🟡 **G-4 — nợ drift** |
|
||
| g | Badge cấp mang cờ trong sơ đồ | có (`:441` `lv.allowApproverFinalize &&`) + làm mờ Bước/Cấp SAU (`:161-170`) | **không có** | 🔴 **G-2 — SÓT** |
|
||
|
||
### 🔴 G-1 (MAJOR) — default TICK ngược chiều khuôn PE ĐANG SỐNG; nhãn "khuôn PE S96" trích bản ĐÃ BỊ ĐẢO
|
||
`fe-*/src/pages/khkk/KhkkWorkflowPanel.tsx:15-18` (header) + `:83-85` (`useState(true)`).
|
||
Đo tại chỗ: `fe-*/src/components/pe/PeWorkflowPanel.tsx:61` = `useState(false)`, chú thích ngay trên nó:
|
||
*"[S97 2026-07-01 — anh Kiệt FDC] … = ô-tick **OPT-IN**: default UNCHECKED → trình tiếp CEO/cấp sau; TÍCH mới KẾT THÚC tại cấp này. **Đảo opt-out S96**."*
|
||
⇒ PE **đã đi qua đúng ngã ba này** và owner ĐẢO sang opt-IN một phiên sau S96. KHKK vừa nhặt lại **đúng vế PE đã bỏ**.
|
||
Vì sao lọt: chú-thích PE `:769-771` (ngay trên khối JSX được trích) vẫn viết *"NAY là ô-tích BỎ được (opt-out): default tick"* — **tự nó STALE** so với `:61` cùng file ⇒ implementer trích đúng dòng nhưng trúng **chú-thích chết**. Đây là tái phát lớp *đối-chứng-khuôn-nguồn* (S165 F-1): đo khuôn ở tầng CHÚ-THÍCH thay vì tầng **giá trị khởi tạo**.
|
||
Hệ quả hành vi: Chương bấm "Duyệt" → "Xác nhận" mà không đọc ⇒ phiếu **DaDuyet + chốt giá**, CEO không bao giờ thấy. Hướng-sai-lệch nghiêng về **ÍT phê duyệt hơn** ở đúng cổng tiền; chiều ngược lại chỉ tốn thêm 1 trạm và cứu được.
|
||
Vế bào chữa PHẢI ghi cùng: default=`true` **giữ nguyên** hành vi BE `?? true` ⇒ **0 regression** so với trước diff, và acceptance F-1 của gate K3 chỉ đòi "mirror `PeWorkflowPanel.tsx:778`" (JSX) — implementer làm đúng chữ.
|
||
⇒ Đây là **quyết định của owner, không phải bug**. Nhưng KHÔNG được để nhãn *"khuôn PE S96"* nói rằng PE đang làm thế.
|
||
**Acceptance (1 trong 2):** (i) owner ratify default=tick + sửa nhãn thành *"ĐẢO NGƯỢC PE-live (PE S97 = opt-IN) — owner chốt @S166, lý do: …"*; HOẶC (ii) đổi `useState(true)`→`useState(false)` + đổi 2 câu mô tả cho khớp.
|
||
|
||
### 🔴 G-2 (MAJOR — carry-over, KHÔNG do diff này đẻ) — sơ đồ nói CEO "đã duyệt" trong khi CEO chưa đụng
|
||
`KhkkWorkflowPanel.tsx:100-106` `stepStatus`: `if (isApproved) return 'Done'` cho **MỌI** Bước; `:108-114` `levelStatus` trả thẳng `s` khi `s !== 'Current'` ⇒ mọi Cấp = `'Done'`; `:234` render `ls === 'Done' && "đã duyệt"`.
|
||
⇒ Phiếu kết thúc ở CCM Cấp 2 ⇒ Bước 3 «Ban Giám đốc» + cấp của `truong.nguyen` hiện ✓ emerald **"đã duyệt"**. Dấu vết phân biệt duy nhất = **vắng** dòng "✓ ký {giờ}" (`:238-242`) — bắt người đọc suy từ sự vắng mặt.
|
||
PE đã giải đúng bài này: badge `allowApproverFinalize` trên chính Cấp (`:441`) + làm mờ Bước/Cấp SAU (`:161-170`), **gate bằng runtime `endsBeforeCeo`** (chú thích tại chỗ: *"bug 'CEO duyệt mà mờ'"*).
|
||
KHKK làm được **nửa rẻ ngay bây giờ** (badge theo `allowApproverFinalize` — cờ vừa được chính diff này đưa vào DTO); nửa còn lại cần `EndedByLevelFinalize` ra DTO = **F-7 gate K3 vẫn treo**.
|
||
Ghi thật: lỗi có từ K3 (nhánh BE + seed cờ đã land ở `15349e8`), **diff này không đẻ ra nó** — nhưng diff này biến đường kết-thúc-sớm thành đường **mặc định có UI**, nên tần suất từ hiếm → thường.
|
||
|
||
## §6 (đề bài 5) Gotcha #44 — có ca nào CÓ quyền mà ô-tích KHÔNG hiện?
|
||
|
||
Quét đủ 3 đường có thể giấu control khỏi đúng người:
|
||
|
||
1. **Cấp trộn cờ + Admin duyệt thay** — 🟡 **G-4 (MINOR, điều-kiện)**.
|
||
BE lấy `pendingLevelGroup.First()` (IGrouping dựng trong `LoadStepsAsync`+`ResolvePointer`, `Service:410-442`);
|
||
FE lấy `currentLevels[0]` (mảng dựng trong query detail `ContractSigningPlanFeatures.cs:621-643`).
|
||
**Hai truy vấn khác nhau**, cả hai chỉ `OrderBy(l => l.Order)` — **không có khoá phụ** ⇒ thứ tự các row
|
||
cùng `Order` do DB quyết, không có gì bảo đảm 2 lượt trả giống nhau. Lệch ⇒ FE ẩn ô-tích trong khi BE
|
||
finalize = **mất opt-out im lặng** (đúng hình #44).
|
||
**Vô hại trên 8 workflow seed** — đo `DbInitializer.cs:626-660`: cờ gán theo **CẤP**
|
||
(`foreach (var (emails, finalize) in new[] { (r.Level1, false), (r.Level2, r.Level2Finalize) })` → mọi
|
||
approver trong cùng Cấp nhận CÙNG `finalize`) ⇒ trong 1 Cấp cờ **đồng nhất** ⇒ `First()` chọn ai cũng ra
|
||
cùng cờ; thêm nữa Cấp mang cờ chỉ có **1 người** (`chuong.phan`, `:576-580`).
|
||
**Có hại khi admin dựng Cấp trộn cờ qua Designer** — schema cho phép (cờ là per-slot), và chính PE đã ghi
|
||
thành chú thích cảnh báo: `PurchaseEvaluationFeatures.cs:1072-1075` *"OR-of-N approvers cùng Cấp = N rows
|
||
cùng Order, mỗi row có Allow* riêng. Lookup KHÔNG discriminate → luôn lấy row đầu DB"*.
|
||
Đối chiếu thiết kế: PE **không** mirror ở FE — BE trả `currentLevelOptions` đã chọn level theo actor. KHKK
|
||
chọn mirror FE ⇒ mỗi lần `ResolveActingLevel` đổi, FE **im lặng lệch**, không có test nào kêu.
|
||
|
||
2. **Cấp CÓ cờ mà actor là người khác trong Cấp** — KHÔNG phải lỗi: BE cũng chấm `own` (không cờ) ⇒ 2 bờ cùng nói "không finalize" (§2 hàng 2). ✅
|
||
|
||
3. **Sợi dây DTO đứt** — 🟡 **G-3 (MINOR)**: `ContractSigningPlanFeatures.cs:643` `l.AllowApproverFinalize`
|
||
là **điểm chết duy nhất** của tính năng, mà **0 test chạm nó**. Grep `tests/`: `AllowApproverFinalize` chỉ
|
||
xuất hiện ở `ContractSigningPlanApprovalTests.cs:877-904` (hành vi service) và `:1065-1138` (create-definition);
|
||
**0 hit** trên projection của `GetContractSigningPlanQuery`. Xoá đúng 1 argument đó ⇒ 614 test vẫn xanh,
|
||
`tsc` vẫn xanh (field vẫn đúng kiểu, chỉ luôn `false` lúc chạy) ⇒ ô-tích **biến mất im lặng** với đúng người
|
||
có quyền. Đúng lớp S161-W2 (*hợp-đồng FE↔BE vỡ mà build+test đều xanh*). Phase-9 test-after cho phép hoãn —
|
||
nhưng phải hoãn **có ý thức**, vì đây là sợi dây duy nhất.
|
||
|
||
4. 🟡 **G-5 (MINOR) — chữ "(CEO)" là suy đoán theo seed, không theo cấu hình.**
|
||
`:457` *"duyệt xong kế hoạch TRÌNH TIẾP lên cấp sau (CEO)"*. Đúng với 8 workflow seed (Bước 3 = Ban Giám đốc).
|
||
Nếu admin cắm cờ ở **Cấp cuối của Bước cuối**: bỏ tick ⇒ BE rơi xuống nhánh terminal `Service:320-329` ⇒
|
||
**vẫn `DaDuyet` ngay** (khác duy nhất: `EndedByLevelFinalize=false` + câu changelog) ⇒ ô-tích hứa "trình tiếp"
|
||
mà phiếu đóng luôn. Test T-a có sanity chặn "cấp mang cờ = cấp cuối" **trong test**, nhưng BE **không có
|
||
validator** cấm cấu hình đó ở Designer.
|
||
|
||
## §6b (đề bài 6) Header-comment — còn tự mâu thuẫn chỗ nào?
|
||
|
||
Quét toàn khối `:1-27` sau khi supersede:
|
||
- `:6-8` *"KHÔNG price-picker, KHÔNG ngân sách, KHÔNG file-khi-duyệt, KHÔNG 4 return-mode"* → vẫn ĐÚNG với diff (ô-tích không phải price-picker). ✅
|
||
- `:10-14` supersede-1 (BE đã port + Designer đã gỡ khoá) → kiểm chứng: `earlyFinalizeLocked` chỉ còn ở **2 chỗ bia-mộ** `ApprovalWorkflowsV2Page.tsx:153` + `:641` (đều là chú thích "ĐÃ BỎ HẲN"), 0 site dùng. ✅
|
||
- `:15-18` supersede-2 → nội dung mô tả ĐÚNG việc diff làm, nhưng **nhãn "khuôn PE S96"** sai với PE-live ⇒ G-1.
|
||
- `:20-27` *"KHÁC PE Ở CHỖ ĐẮT NHẤT: PE nhận `approvalFlow` đã có `status` … KHKK BE trả CÂY THÔ"* → vẫn đúng, và
|
||
giờ **thiếu một vế**: từ diff này KHKK còn phải tự suy **cả level-của-actor** (thứ PE cũng nhận sẵn từ BE) —
|
||
chính là G-4. Khối "KHÁC PE" nên nêu thêm vế đó, nếu không người sau đọc sẽ tưởng chỉ lệch ở `status`.
|
||
- Chú thích `:132-134` mô tả mirror đúng 2 vế BE, nhưng **không khai** rằng thứ tự nhóm đến từ 2 truy vấn khác nhau (G-4).
|
||
- Citation kiểm từng cái: `PeWorkflowPanel.tsx:259` = đúng dòng gửi `applyLevelFinalize` ✅; `:772-791` = đúng khối JSX ✅; `ContractSigningPlanWorkflowService.cs:455-469` = đúng `ResolveActingLevel` ✅. **Số dòng không bịa.**
|
||
⇒ 0 mâu thuẫn logic còn sót; 2 chỗ **thiếu-khai** (nhãn khuôn PE · vế mirror mới) đã tính vào G-1/G-4.
|
||
|
||
## §6c NGOÀI ĐỀ BÀI — cây làm việc PHÌNH GIỮA LƯỢT REVIEW (đo 2 lần, cách nhau ~40 tool-call)
|
||
|
||
| Mốc đo | `git status --porcelain -- src fe-user fe-admin tests` | `git diff --stat` |
|
||
|---|---|---|
|
||
| Lúc spawn (§0) | **5 file** | **+137 / −14** |
|
||
| Đo lại lúc viết §6c | **7 file** (+`Domain/Identity/MenuKeys.cs`, +`Infrastructure/Persistence/DbInitializer.cs`) | **+253 / −19** |
|
||
|
||
🔴 **G-6 (MAJOR — quy trình, chặn commit):** 2 file mới (+42 / +79 dòng) **KHÔNG thuộc spec F-1** và
|
||
**KHÔNG nằm trong phạm vi tôi soi**. Nội dung là **K4a** (khuôn (b) menu-key nhóm): `MenuKeys.cs:81-84`
|
||
thêm `KhkkGroupMenuKeys` rồi **spread `.. KhkkGroupMenuKeys` vào `All`** (`:244`).
|
||
Đo hệ quả canonical: `All` hiện gồm **64 định danh tĩnh + 1 spread**; spread = `KhkkGroupNumbers` (7 số
|
||
`[2..8]`) × (1 group + 6 `KhkkLeafActions`) = **49 key** — chính chú thích `MenuKeys.cs:79` cũng ghi *"49 key"*
|
||
⇒ `|MenuKeys.All|` = **113**, policies DERIVED = **452**.
|
||
⇒ Nếu commit "vá F-1" ngay bây giờ, nó **nuốt trọn** 121 dòng chưa qua cổng nào **và** đổi 2 con số canonical
|
||
(gấp ~1,8 lần). Đây đúng lớp đã ăn đòn ở gate K1 cùng chuỗi (*commit gộp = vượt quyền owner*).
|
||
**Acceptance:** tách 2 commit — (1) F-1 đúng 5 file; (2) K4a riêng, có gate riêng + cập nhật STATUS.
|
||
*(Ghi thật: tôi KHÔNG soi nội dung 2 file đó; con số 113/452 là DERIVE từ hình dạng mã + chú thích tại chỗ,
|
||
chưa chạy initializer — người ship phải tự đếm lại bằng máy trước khi ghi vào STATUS.)*
|
||
|
||
🟡 **G-7 (MINOR — carry-over K3 F-3, mới vá NỬA):** `docs/STATUS.md:6` (văn xuôi CURRENT) đã sửa
|
||
*"Policies **256** · Menu keys **64**"*, nhưng **2 row canonical** vẫn ở số S161: `:470` `| Policies | **220** |`
|
||
và `:471` `| Menu keys | **55** |`. Đó lại **đúng nơi máy đọc**: `scripts/governance-detectors.ps1:175-181`
|
||
`Get-StatusValue` khớp `^\|\s*<label>\s*\|\s*\*\*(\d+)`, `:202-208` map `'menu'→'Menu keys'`,
|
||
`'policy'→'Policies'` ⇒ detector đang resolve canonical **55 / 220** trong khi văn xuôi nói 64 / 256 và máy
|
||
(sau K4a) nói 113 / 452 — **ba nguồn, ba số**. Vá prose mà bỏ row = *fix áp NỬA spec* (bài S160).
|
||
|
||
## §7 VERDICT
|
||
|
||
**PASS-WITH-FLAGS — 7 finding (3 MAJOR / 4 MINOR), 0 blocker KỸ THUẬT trên 5 file F-1, 1 blocker QUY TRÌNH (G-6).**
|
||
|
||
Bản vá F-1 **làm đúng việc nó nhận**: sợi dây BE→FE nối bằng đúng 1 site (§1), mirror 2 app chứng bằng
|
||
blob-SHA (§0), `actingLevel` mirror `ResolveActingLevel` đúng 6/7 ca gồm cả OR-of-N cờ-ở-người-khác và
|
||
`currentLevels` rỗng (§2), body không rò field sang 3 action kia và hội tụ absent/null/true (§3), cấp
|
||
thường **bất biến từng bit đường đi** (§4), ô-tích không rò sang phase khác nhờ 3 lớp chặn độc lập (§4).
|
||
|
||
| # | Mức | Một dòng | Địa chỉ |
|
||
|---|---|---|---|
|
||
| G-1 | MAJOR | default TICK ngược chiều PE-**live** (PE S97 = opt-IN); nhãn "khuôn PE S96" trích bản đã bị owner ĐẢO — cần owner ratify hoặc lật default | `KhkkWorkflowPanel.tsx:85` + `:15-18` ⟂ `PeWorkflowPanel.tsx:61` |
|
||
| G-2 | MAJOR (carry-over K3) | phiếu kết-thúc-sớm ⇒ sơ đồ hiện Bước «Ban Giám đốc» ✓ "đã duyệt" dù CEO chưa đụng; PE đã giải bằng badge + làm mờ | `KhkkWorkflowPanel.tsx:100-114` + `:234` ⟂ `PeWorkflowPanel.tsx:441` `:161-170` |
|
||
| G-6 | MAJOR (quy trình) | cây phình 5→7 file giữa lượt review; K4a (+121 dòng, `All` 64→113, policies →452) sẽ bị commit ké | `MenuKeys.cs:81-84` `:244` · `DbInitializer.cs` |
|
||
| G-3 | MINOR | 0 test chạm `l.AllowApproverFinalize` trong projection — xoá 1 argument là ô-tích biến mất mà 614 test + tsc vẫn xanh | `ContractSigningPlanFeatures.cs:643` |
|
||
| G-4 | MINOR | FE tự mirror `ResolveActingLevel` (PE để BE precompute); Admin-fallback so `First()` giữa **2 truy vấn** không khoá phụ — vô hại trên seed (cờ đồng nhất trong Cấp), hại khi Designer trộn cờ | `KhkkWorkflowPanel.tsx:135-136` ⟂ `Service:463-465` |
|
||
| G-5 | MINOR | chữ "(CEO)" suy theo seed; cắm cờ ở Cấp cuối Bước cuối ⇒ bỏ tick vẫn `DaDuyet` ngay, ô-tích hứa sai; BE không có validator cấm | `KhkkWorkflowPanel.tsx:457` ⟂ `Service:320-329` |
|
||
| G-7 | MINOR (carry-over K3 F-3) | STATUS mới vá văn xuôi, 2 row canonical detector đọc vẫn 55/220 | `docs/STATUS.md:470-471` |
|
||
|
||
**Khuyến nghị thứ tự:** (1) tách commit theo G-6 → (2) hỏi owner G-1 (1 câu: *"Chương bấm Duyệt mà không
|
||
đọc thì mặc định KẾT THÚC hay LÊN CEO?"*) → (3) ship F-1 → (4) G-2/G-3 vào nhịp K4 → (5) G-7 kèm lần đụng STATUS kế.
|
||
|
||
END sub-reviewer-f1-checkbox — TOTAL: 7 finding (3 MAJOR / 4 MINOR) · 0 blocker kỹ-thuật · 1 blocker quy-trình (G-6) · verdict PASS-WITH-FLAGS
|
||
|
||
|
||
|
||
|
||
|