Incomex AI Portal
KB-3F70

SR-SCAN-TEST — Master List Actual UI Scan (VERDICT FEASIBLE)

12 min read Revision 1
sua-renhap-uisr-scan-testmaster-listactual-ui-scanread-onlysource-recognition-ruleanchorfeasible2026-07-07

SR-SCAN-TEST — Master List Actual UI Scan

Gate: GO_SR_SCAN_TEST_MASTER_LIST received — yes (Owner phát nguyên văn trong phiên). Run date thật: 2026-07-08 (file gắn nhãn ca test 2026-07-07 theo yêu cầu mục 9). ui_id: master-list-quy-trinh-v1.

1. Verdict

FEASIBLE.

Đường chung (UI thật → nhận diện nguồn khái niệm → scan slot bằng anchor bền → so PG) chạy được end-to-end trên ca test đầu tiên. Khung chung tái dựng đúng 30/30 current slot của baseline PG bằng anchor bền: 28 exact_anchor_match + 2 anchor_conflict (granularity) + 0 missing. Lệch với PG đều giải thích được; không đếm dữ liệu thành slot; mảng gộp bằng [].

2. Scope

Read-only. Đọc UI source thật + JS render + SELECT read-only PG để đối chiếu. 0 ghi PG, 0 INSERT/UPDATE/DELETE/DDL, 0 dot-pg-atomic-apply, 0 sửa manifest/SQL/UI/quy trình, 0 hardening, 0 scan 4 bà mẹ, 0 ép scan khớp PG.

Nguồn đọc:

  • UI HTML: /opt/incomex/docs/mcp-writes/ui-preview/master-list-quy-trinh-v1.html
  • JS render: /opt/incomex/docs/mcp-writes/ui-preview/master-list.js
  • JS nav chrome: /opt/incomex/docs/mcp-writes/ui-preview/eco-nav.js
  • PG (DB directus, read-only role, READ ONLY tx): public.sua_re_ui_khai_niem_nhap, public.sua_re_khai_niem_nhap.

3. A0 — Source discovery

UI này thuộc dạng: structured config inline trong HTML (Layer 1) + code-rendered UI (Layer 4/JS).

Nguồn Loại Vai trò Đọc được
window.MASTER_CONFIG (inline <script> trong HTML) structured config inline PRIMARY Có
master-list.js (nạp qua fetch+eval) JS render → sinh bảng/drawer/ma trận, computed field, code_marker SECONDARY (bổ sung code_marker + computed) Có
eco-nav.js (nạp qua fetch+eval) JS navigation chrome ("4 Mẹ + Master") NON-SOURCE (không có khái niệm domain quy trình) Có
mot-theme-v1.css theme NON-SOURCE (bỏ, chỉ style)

Vì sao chọn MASTER_CONFIG là primary: là object JS có cấu trúc chứa luồng/field/bước/task/link/status → path bền config_key:MASTER_CONFIG.…, ưu tiên cao nhất (rule 4.2). master-list.js là secondary vì thêm slot không nằm trực tiếp trong config: code_marker (qv-grp, qv-tot) và computed field (tổng phút, đường dẫn 7 tầng tự suy). eco-nav.js đọc được nhưng loại khỏi phạm vi khái niệm vì chỉ là thanh điều hướng dùng chung mọi UI — không sinh slot của quy trình. Không có nguồn nào không đọc được → không BLOCKED, và lớp JS đã kiểm hết → verdict không bị trần PARTIAL.

3.1. SOURCE RECOGNITION RULE (tái dùng — bổ sung theo yêu cầu Owner)

Luật nhận diện nguồn, xếp theo độ ưu tiên; dừng ở lớp bền nhất tìm được:

# Dấu hiệu nhận ra Kết luận nguồn Anchor phát sinh
R1 Có object JS nhúng trong <script>/HTML chứa luồng/field/bước/task/link/status (vd MASTER_CONFIG, PAGE_CONFIG, FLOW_DEF) primary structured source config_key:<path> (strong)
R2 Có file rời JSON/YAML/JS-module/schema/contract primary structured source config_key: / contract_key: (strong)
R3 Không có structured source nhưng JS render sinh nhãn/tổng hợp/marker/computed field secondary source (bổ sung, không thay primary) code_marker:<class/fn/key ổn định> (strong)
R4 Không structured, nhưng DOM có data-* / id / class ổn định DOM/data marker data_key: / dom_marker: (medium)
R5 Chỉ còn text hiển thị text-only fallback text_marker:<text> (weak)

Kèm luật phân vai: (a) một UI có thể có nhiều nguồn cùng lúc — chọn 1 primary, các nguồn còn lại là secondary/non-source; (b) JS chỉ điều hướng/theme/chrome dùng chung ⇒ non-source, không sinh slot; (c) nếu 1 lớp JS đọc được thì phải đọc để không bị trần PARTIAL; nếu không đọc được thì scan phần còn lại, verdict trần PARTIAL, ghi rõ nhóm chưa kiểm.

4. General scan rules applied (luật chung đã dùng)

  • Source discovery theo R1–R5 ở trên (primary = MASTER_CONFIG).
  • Anchor priority: config_key > code_marker > text_marker. Header cột render ra thì anchor tốt nhất cho điểm-bề-mặt đó là text_marker:<th>…</th> (weak) — nhưng khái niệm gốc vẫn dedup về concept.
  • [] array grouping: mọi mảng gộp bằng []. 7 quy trình × 2 bước × 1–3 task (≈20+ instance dữ liệu) gộp về 1 path tổng quát mỗi loại → items[].steps[].items[].n/min/trig là 1 slot/loại, không phải 20.
  • Concept not data: đã kiểm — số slot KHÔNG nở theo số dòng dữ liệu.
  • No fake purpose: purpose lấy từ config/comment/code; slot chưa rõ concept (review/candidate) để purpose = known nhưng concept mapping = pending, không auto-match.

5. Master-list specific sources (dữ kiện riêng ca này)

Chỉ đúng cho master-list, KHÔNG phải luật chung:

  • Object cấu trúc tên riêng là MASTER_CONFIG, path gốc MASTER_CONFIG.items[].
  • Khuôn render dùng chung master-list.js (khuôn "danh sách đã đúc" của mọi Mẹ) — sinh:
    • bảng list (#mlTbl, thead <th>Mã/Tên/…),
    • drawer ma trận qv-matrix (thead STT/Tên task/Trigger/Số phút/Người thực hiện/Người được báo cáo/Ghi chú),
    • code_marker qv-grp (hàng gộp bước), qv-tot (dòng Tổng phút computed).
  • Khối APPEND trong master-list.js đổi header Tầng quản lý → Chuyên môn, ẩn cột Đường dẫn 7 tầng / Ngày lập / Người lập (vẫn còn trong DOM).
  • Cây 7 tầng TREE/resolvePath (window.MASTER_TREE) → computed it.path, it.anchorTier (đường dẫn tự suy T7→T2). Đây là dữ kiện riêng master-list, không phải luật chung.

6. Scan artifact summary (slot scan được)

Tổng scan: 41 slot bề mặt (View "usage/location" giống thiết kế 2 bảng của PG), gồm:

A. config_key · domain quy trình (strong) — 17 leaf / 14 nếu gộp object: items[].code, items[].name, items[].anchor, items[].date, items[].maker.t, items[].maker.n, items[].status, items[].links.mot, items[].links.moit, items[].links.mout, items[].steps[].name, items[].steps[].lam, items[].steps[].bao, items[].steps[].agent, items[].steps[].items[].n, items[].steps[].items[].min, items[].steps[].items[].trig.

B. config_key · page-frame (strong, ngoài phạm vi PG) — 8: title, mother, noun, itemBase, sub, principle, createUrl, createLabel.

C. code_marker · computed (strong) — 2: code_marker:qv-grp (hàng gộp bước), code_marker:qv-tot (Tổng phút = Σ min, computed).

D. text_marker · header list-table (weak) — 7: <th>Mã</th>, <th>Tên</th>, Chuyên môn, Đường dẫn 7 tầng, Ngày lập, Người lập, Trạng thái.

E. text_marker · header qv-matrix (weak) — 6: <th>Tên task</th>, <th>Trigger</th>, Số phút, <th>Người thực hiện</th>, <th>Người được báo cáo</th>, <th>Ghi chú</th>.

F. text_marker · drawer block (weak) — 1: Liên kết 4 Mẹ.

7. PG comparison by anchor

PG current (ui_id=master-list-quy-trinh-v1, is_current=true): 30 rows = 14 config_key + 2 code_marker + 14 text_marker.

Nhóm Số Chi tiết
exact_anchor_match 28 12 config_key leaf (code, name, anchor, date, status, steps[].name, steps[].lam, steps[].bao, steps[].agent, steps[].items[].n, steps[].items[].min, steps[].items[].trig) + 2 code_marker (qv-grp, qv-tot) + 14 text_marker (toàn bộ)
anchor_conflict (granularity) 2 items[].maker (PG=object, id22) vs scan maker.t+maker.n; items[].links (PG=object, id24) vs scan links.mot+moit+mout. UI render maker/links luôn đi liền ⇒ object-level của PG đúng hơn leaf-split.
missing_from_scan 0 Mọi anchor PG đều tái hiện được từ source thật.
new_in_scan 8 8 config page-frame (mục 6.B) — scan PG trước cố tình bỏ (chrome, không phải khái niệm quy trình).
label_or_purpose_changed 0 UI không đổi so với scan PG 2026-07-07; nhãn/purpose trùng khớp.

Ghi chú mapping concept (không sửa scan để khớp PG): 3 slot PG đang review/candidate, concept_id=null — steps[].agent (id30, review), links (id24, candidate), Liên kết 4 Mẹ (id25, candidate). Scan tái hiện đúng các anchor này; concept mapping là việc của Owner, không phải lỗi scan. Cặp G2 time-concept phân đôi đúng: Số phút/items[].min = concept 5 (số phút ranh giới) vs qv-tot = concept 14 (tổng phút cộng dồn, computed).

8. JS-only / computed slots

  • Đã slot trong PG: code_marker:qv-tot (Tổng phút = Σ min, concept 14 — computed thuần từ task); code_marker:qv-grp (hàng gộp bước, concept 2).
  • Computed hiện ở UI nhưng CHƯA slot riêng (gấp vào concept có sẵn, ứng viên nếu Owner muốn tách):
    • it.path / resolvePath (đường dẫn 7 tầng tự suy) → gấp vào concept 10 (Đường dẫn 7 tầng/Chuyên môn).
    • Tổng hợp Người làm / Người nhận báo cáo (dòng qd-sum gộp Object.keys(lam)/(bao)) → gấp vào concept 6 / 7.
    • Đếm đang chạy (act, subheader) — computed count, chưa slot.
    • mow_link_derived (path.T2 ? 1 : — trong khối "Liên kết 4 Mẹ") — computed, gấp vào slot Liên kết 4 Mẹ.

9. Weak anchors / unknown purpose

  • 14 text_marker đều weak (đúng bản chất header render). Không có purpose unknown — PG điền đủ; scan xác nhận từ thead/label.
  • 8 new_in_scan page-frame có purpose rõ từ config, nhưng phân loại nên là page_config/needs_review, không auto-import làm khái niệm quy trình.
  • 0 slot purpose=unknown thực sự. 3 slot review/candidate: purpose known, chỉ pending concept mapping.

10. What SR-LAP must learn (đề xuất vá — CHƯA sửa quy trình)

Chỉ ghi đề xuất; không sửa sua-re-lap-so-khai-niem-ui.md / sua-re-sua-so-khai-niem-ui.md trong bước này.

  1. Thêm A0 = "nhận diện nguồn" thành bước bắt buộc trước khi bóc slot, kèm bảng SOURCE RECOGNITION RULE R1–R5 ở §3.1 (luật chung).
  2. Luật độ hạt (granularity) — luật chung còn thiếu, PG đã áp ngầm: gộp các leaf scalar chỉ-cùng-nhau-xuất-hiện-trên-UI thành 1 slot (maker.t+maker.n → maker; links.mot/moit/mout → links). Chỉ tách leaf khi leaf tự nổi độc lập trên bề mặt.
  3. Luật scoping page-frame: config khung trang (title/mother/noun/itemBase/sub/principle/createUrl/createLabel) là page_config, không auto thành khái niệm domain; đánh needs_review, để Owner quyết.
  4. Làm rõ rule 4.2 cho thiết kế 2 bảng (concept vs usage): rule "không dùng text_marker nếu có nguồn bền hơn" áp cho chất lượng anchor của MỘT điểm bề mặt, không phải để bóp bỏ các điểm bề mặt khác. Một khái niệm hiện ở config + header cột + code_marker = nhiều usage row, cùng dedup về 1 concept. (Đây là điểm khung chung dễ hiểu sai nhất.)
  5. JS-render là secondary source bắt buộc đọc khi có: code_marker (qv-grp/qv-tot) và computed (Tổng phút) không nằm trong config — nếu chỉ scan config sẽ thiếu 2 code_marker + toàn bộ header.
  6. Không cần scan lại master-list sau khi vá SR-LAP: scan thật đã tái dựng đúng 30/30; các đề xuất trên là chuẩn-hoá luật, không thay đổi kết quả ca này.

11. What we stop

  • Không hardening.
  • Không scan 4 bà mẹ.
  • Không import PG / không ghi PG / không tạo SQL / không apply / không sửa manifest.
  • Không sửa quy trình (SR-LAP/SR-SUA) trong bước này.
  • Không ép scan khớp PG — mọi lệch đã ghi nguyên trạng.

Output: FEASIBLE

Back to Knowledge Hub knowledge/dev/laws-new/kestra/sua-re/nhap-ui/sr-scan-test-master-list-actual-ui-2026-07-07.md