14 Wireframes Screen Behavior And Ui Rules

Artifact Governance Metadata

Trường kiểm soát	Giá trị
Tên tệp được kiểm soát	/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md
Tiêu đề tài liệu	14 Wireframes Screen Behavior And Ui Rules
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale	vi-VN
Tiền tệ mô phỏng	VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp
Phân loại	Handbook chapter; tài liệu học liệu có kiểm soát
Nguồn quản trị thượng nguồn	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/01_CURRICULUM_ARCHITECTURE.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md
Baseline reference	Chưa có baseline reference tại v0.9.0
Approval reference	Chưa có approval reference tại v0.9.0
Giới hạn thẩm quyền	Nội dung không xác nhận yêu cầu Nova Foods thực tế, không phê duyệt thiết kế, không cho phép production, không thay thế quyết định Business Owner, Architect, Security, QA, Legal hoặc Accounting Owner.

Lịch sử thay đổi

Ngày	Tác giả	Version	Tóm tắt thay đổi
2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	v0.9.0	Thiết lập artifact handbook ở trạng thái IN_REVIEW; ghi nhận metadata quản trị, phạm vi học liệu, nguồn quản trị thượng nguồn, giới hạn thẩm quyền, và lịch sử thay đổi để hỗ trợ kiểm tra chất lượng trước downstream review.

1. Concept l? g??

Core

Wireframe là bản mô tả cấu trúc màn hình ở mức đủ để người đọc hiểu: người dùng thấy gì, thao tác ở đâu, hệ thống phản hồi thế nào, và giới hạn nào áp dụng. Nó ưu tiên bố cục, thông tin, hành vi và trạng thái hơn màu sắc, thương hiệu, ảnh minh họa hay chi tiết đồ họa cuối cùng.

“Screen behavior” là hành vi màn hình. Hành vi không dừng ở việc nút có tồn tại. Nó xác định điều kiện để nút dùng được, dữ liệu nào xuất hiện sau thao tác, lỗi hiển thị ở đâu, màn hình chuyển trạng thái nào, và dữ liệu có bị thay đổi hay không. Nếu wireframe chỉ vẽ ô nhập và nút lưu nhưng không nêu phản hồi khi dữ liệu sai, đội phát triển phải tự suy đoán; suy đoán tạo khác biệt giữa ý định nghiệp vụ, thiết kế và phần mềm.

“UI rules” là quy tắc giao diện người dùng. Quy tắc này làm các màn hình nhất quán: nhãn trường dữ liệu, trường bắt buộc, định dạng ngày giờ theo vi-VN, định dạng tiền tệ mô phỏng VND, vị trí thông báo lỗi, điều kiện hiển thị và quyền thao tác. Một quy tắc UI không tự tạo ra quy tắc nghiệp vụ. Bằng chứng là UI chỉ quyết định cách hệ thống trình bày hoặc chặn thao tác; ý nghĩa nghiệp vụ, điều kiện phê duyệt, hạch toán, pháp lý và vận hành phải truy về artifact canonical có thẩm quyền.

Mục tiêu chapter là biến nhu cầu đã được xác định thành mô tả màn hình có thể kiểm tra. “Có thể kiểm tra” nghĩa là QA hoặc người review đọc được cùng một kết quả mong đợi từ artifact: dữ liệu đầu vào, thao tác, phản hồi, trạng thái và giới hạn hiển thị. Wireframe vì vậy là cầu nối giữa requirement và thiết kế UI, không phải ảnh trang trí, không phải prototype chạy được, không phải đặc tả API, và không phải bằng chứng phê duyệt.

Phạm vi chapter bao gồm mô tả màn hình ERP, vùng thông tin, điều khiển tương tác, trạng thái hiển thị, thông báo, điều hướng và quy tắc UI liên quan trực tiếp. Phạm vi không gồm quyết định kiến trúc, schema cơ sở dữ liệu, hợp đồng API, mã nguồn, cấu hình production, diễn giải pháp luật, quyết định kế toán hoặc xác nhận tuân thủ. Khi một chi tiết màn hình phụ thuộc các nội dung đó, BA phải giữ liên kết truy vết đến nguồn canonical và nêu rõ thẩm quyền cần xác minh; không biến giả định giao diện thành quyết định chuyên môn.

Core

Wireframe là bản phác cấu trúc màn hình. Nó cho thấy người dùng thấy gì, làm gì, với dữ liệu nào, và hệ thống phản hồi ra sao. Wireframe không phải giao diện hoàn chỉnh: không chốt màu sắc, mã nguồn, cấu hình ERP, hay quyết định triển khai.

Thuật ngữ	Nghĩa tiếng Việt	Vai trò trong wireframe
UI — User Interface	Giao diện người dùng	Thành phần người dùng nhìn và thao tác: nút, ô nhập, bảng, thông báo.
Screen	Màn hình	Một vùng giao diện phục vụ mục tiêu cụ thể, ví dụ màn hình tạo đơn bán hàng.
Wireframe	Khung sườn màn hình	Biểu diễn vị trí, thứ tự, nhóm thông tin và hành vi dự kiến của UI.
Actor	Tác nhân, thường là vai trò người dùng hoặc hệ thống	Trả lời: ai khởi tạo hoặc nhận hành vi? Ví dụ: Nhân viên Bán hàng.
Action	Hành động	Thao tác actor thực hiện. Ví dụ: chọn Lưu nháp, nhập số lượng, xác nhận gửi.
Object	Đối tượng nghiệp vụ hoặc dữ liệu bị tác động	Trả lời: hành động tác động lên cái gì? Ví dụ: đơn bán hàng, dòng hàng, khách hàng.
Outcome	Kết quả quan sát được sau hành động	Trả lời: hệ thống phải tạo, đổi, hiển thị hoặc chặn điều gì? Ví dụ: đơn chuyển sang trạng thái nháp và hiện mã đơn.
Behavior	Hành vi màn hình	Quy tắc phản ứng của UI trước action, dữ liệu nhập, quyền truy cập hoặc trạng thái đối tượng.
Field	Trường dữ liệu	Một ô hiển thị hoặc nhập một giá trị, như Mã khách hàng hoặc Số lượng.
Validation	Kiểm tra hợp lệ	Điều kiện UI hoặc hệ thống dùng để chặn dữ liệu sai trước khi tạo outcome.
State	Trạng thái	Tình trạng nghiệp vụ hiện thời của object, như Nháp, Đã gửi, Đã hủy.
Error message	Thông báo lỗi	Nội dung chỉ rõ dữ liệu hoặc hành động không hợp lệ và cách người dùng sửa.

Công thức đọc một hành vi màn hình: actor thực hiện action lên object để đạt outcome. Ví dụ cấu trúc: “Nhân viên Bán hàng chọn Lưu nháp cho Đơn bán hàng; hệ thống lưu dữ liệu đã nhập và hiển thị trạng thái Nháp.” Suy luận này có bằng chứng rõ: actor là người bấm nút, action là Lưu nháp, object là Đơn bán hàng, outcome là bản ghi được lưu với trạng thái quan sát được.

BA không dừng ở câu “có nút Lưu”. Câu đó chỉ nêu UI, thiếu lý do và kết quả kiểm chứng. Wireframe đủ dùng phải nối được bốn phần trên, vì QA cần outcome để kiểm thử, developer cần behavior để xây dựng, còn business cần biết object nào bị thay đổi. Nếu thiếu actor, không xác định được quyền dùng màn hình; nếu thiếu action, không xác định được thao tác; nếu thiếu object, không biết dữ liệu bị tác động; nếu thiếu outcome, không thể xác nhận hành vi đúng hay sai.

Các thuật ngữ này mô tả yêu cầu giao diện trong corpus Nova Foods Trading & Manufacturing mô phỏng, chỉ dùng dữ liệu tổng hợp. Chúng không tự tạo business rule, quyền truy cập thực tế, cấu hình ERP, hay phê duyệt cho production.

Applied

Ví dụ tối thiểu — Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Màn hình Goods Receipt Note dùng để nhân viên kho ghi nhận lô hàng đã nhận từ nhà cung cấp cho một đơn mua. Wireframe không quyết định Nova Foods phải nhận hàng theo quy trình này. Nó biểu diễn hành vi màn hình để các vai trò cùng kiểm tra cách người dùng thao tác và hệ thống phản hồi.

Thành phần	Nội dung mô phỏng
Actor	Nhân viên kho, người có quyền tạo phiếu nhận hàng
Action	Chọn đơn mua PO-NF-2026-0018, nhập số lượng nhận 120 kg, nhấn Ghi nhận
Object	Phiếu nhận hàng GRN-NF-2026-0042, dòng hàng RM-TOMATO-PASTE
Outcome	Hệ thống hiển thị phiếu ở trạng thái Draft hoặc thông báo lỗi tại trường số lượng nếu dữ liệu không hợp lệ
Dữ liệu minh họa	120 kg, đơn giá không hiển thị, tiền tệ bối cảnh VND
Bằng chứng thiết kế	Người kho cần nhập sự kiện nhận thực tế; vì vậy wireframe phải chỉ rõ trường nhập, nút thao tác, kiểm tra dữ liệu và phản hồi thấy được

Ranh giới concept. Wireframe là bản mô tả trực quan và có quy tắc của giao diện: vùng hiển thị, trường dữ liệu, nút, trạng thái, điều kiện hiển thị, kiểm tra nhập liệu và phản hồi sau thao tác. Nó trả lời: actor nhìn gì, làm gì trên màn hình, với object nào, rồi nhận outcome nào. Wireframe không tự chứng minh business rule là đúng, không tự tạo quyền truy cập, không thay thế đặc tả API, thiết kế cơ sở dữ liệu, BPMN, UML, test case, cấu hình ERP hay quyết định vận hành.

Bao gồm trong wireframe	Loại trừ khỏi wireframe	Lý do
Nhãn trường Số lượng nhận, kiểu nhập số, đơn vị kg, nút Ghi nhận	Công thức hạch toán tồn kho	Hạch toán thuộc quyết định kế toán và thiết kế nghiệp vụ chuyên sâu
Lỗi hiển thị khi số lượng không phải số dương	Quy tắc pháp lý về chứng từ hoặc an toàn thực phẩm	Cần Legal Owner hoặc domain owner xác minh từ nguồn chính thức
Trạng thái hiển thị Draft sau khi lưu thành công	API endpoint, schema JSON, mã HTTP	Đây là phạm vi đặc tả tích hợp; wireframe chỉ nêu hành vi UI cần thấy
Điều kiện nút bị vô hiệu khi thiếu số lượng	Ma trận phân quyền chi tiết	Wireframe có thể nêu actor giả định, nhưng quyền chuẩn cần artifact bảo mật và quyết định có thẩm quyền

Không suy diễn rằng PO-NF-2026-0018, GRN-NF-2026-0042, hàng hóa, số lượng hay luồng xử lý tồn tại trong ERP thật. Không suy diễn tính tuân thủ pháp lý, kế toán, thuế, truy xuất nguồn gốc hoặc phê duyệt. Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07 chỉ là trạng thái quản trị corpus; không phải baseline hay approval.

2. T?i sao concept n?y t?n t?i?

Core

Wireframe ngăn lỗi “cùng đọc một requirement, mỗi người hình dung một màn hình khác”. Requirement chữ có thể nói “người dùng ghi nhận số lượng nhận hàng”, nhưng chưa đủ để quyết định trường nào bắt buộc, lỗi xuất hiện lúc nào, nút nào khả dụng, trạng thái nào thấy sau khi lưu, hay dữ liệu nào được phép sửa. Khoảng trống này gây mơ hồ giữa Business Owner, BA, UX/UI, developer và QA.

Không có wireframe, developer có thể tạo màn hình đúng tên trường nhưng sai hành vi; QA thiếu test basis trực quan; business review muộn khi phần mềm đã viết. Khi đó rework không chỉ là sửa giao diện: có thể phải đổi validation, API contract, trạng thái workflow, quyền thao tác và test case liên quan.

Rủi ro được ngăn	Cơ chế ngăn của wireframe	Hậu quả nếu không kiểm soát
Mơ hồ hành vi UI	Ghi rõ actor, trường, điều kiện, nút, lỗi và phản hồi	Các bên dùng diễn giải riêng
Rework sau phát triển	Review hành vi trước khi code	Sửa UI kéo theo sửa logic và kiểm thử
Lệch giữa requirement và test	Wireframe thành test basis cho hành vi thấy được	QA chỉ kiểm tra chức năng kỹ thuật, bỏ sót trải nghiệm
Governance yếu	Gắn nguồn input, assumption, decision và authority	Ý kiến trao đổi bị hiểu nhầm thành rule đã quyết định
Scope creep	Nêu ranh giới UI với API, quyền, hạch toán và pháp lý	Wireframe bị dùng sai như đặc tả toàn hệ thống

Wireframe không làm requirement tự đúng. Nó biến requirement thành đối tượng có thể review: người review thấy đúng trường, đúng điều kiện và đúng outcome hay không. Đây là bằng chứng thiết kế cần truy vết, không phải phê duyệt, baseline hay cấu hình production.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi ID và dữ liệu là tổng hợp. Xét màn hình ghi nhận nhận hàng cho PO-NF-2026-0018 và chứng từ nhận hàng GRN-NF-2026-0042.

Thành phần	Trước khi có wireframe	Sau khi có wireframe
Mô tả requirement	“Ghi nhận số lượng nhận hàng.”	Màn hình nêu trường Số lượng nhận, đơn vị kg, nút Ghi nhận, điều kiện số dương và phản hồi lưu thành công
Developer hiểu	Có thể tạo trường text tự do và luôn bật nút lưu	Có đầu vào UI cụ thể để xây validation và trạng thái nút
QA kiểm tra	Có thể chỉ kiểm tra thao tác lưu	Có thể kiểm tra lỗi khi để trống, nhập 0, nhập chữ và outcome sau lưu
Business review	Chỉ thấy kết quả khi build xong	Thấy hành vi trước khi code
Hậu quả thấy được	Người dùng có thể nhập giá trị không hợp lệ rồi nhận lỗi không nhất quán	Người dùng thấy điều kiện nhập trước hoặc tại thời điểm thao tác theo wireframe đã review

Source mermaid — có thể chỉnh sửa

flowchart TB
    R[Requirement: ghi nhận số lượng nhận] --> W["Wireframe: Số lượng nhận, đơn vị kg,<br/>nút Ghi nhận, lỗi dữ liệu không hợp lệ,<br/>phản hồi lưu thành công"]

    W --> B[Business review hành vi trước khi code]
    W --> D[Developer xây UI]
    W --> Q[QA thiết kế kiểm tra hành vi]

    D --> UI[UI đã xây theo wireframe]
    UI --> I[Người dùng nhập Số lượng nhận]
    I --> V{Giá trị nhập}

    V -->|Để trống, 0 hoặc nhập chữ| E[Hiển thị lỗi dữ liệu không hợp lệ]
    V -->|Số dương| G[Nút Ghi nhận được bật]
    G -->|Người dùng chọn Ghi nhận| O[Hiển thị phản hồi lưu thành công]

    Q --> QT[QA thực thi kiểm tra trên UI]
    UI --> QT
    QT -. kiểm tra nhánh .-> E
    QT -. kiểm tra nhánh .-> O

Wireframe giảm rủi ro bằng cách làm rõ điểm giao giữa người dùng và hệ thống. Nó không xác nhận PO-NF-2026-0018 hay GRN-NF-2026-0042 tồn tại trong ERP thật, không quyết định hạch toán tồn kho, không xác lập quyền và không chứng minh tuân thủ pháp lý.

Senior Lens

Sai lầm governance phổ biến: biến ghi chú wireframe thành business rule hoặc approval. BA phải tách nguồn gốc từng nội dung trước khi đưa vào artifact.

Loại nội dung	Ý nghĩa	Cách xử lý trong wireframe
Fact đã xác minh	Điều được chứng minh bởi artifact nguồn kiểm soát	Tham chiếu đúng artifact nguồn; không suy rộng
Stakeholder input	Nhu cầu hoặc ý kiến từ stakeholder	Gắn nguồn và vai trò cung cấp; chưa gọi là quyết định
Project assumption	Giả định dùng để tiếp tục phân tích khi thiếu bằng chứng	Gắn nhãn Project assumption; nêu điều kiện cần xác minh
Decision	Lựa chọn giữa các phương án bởi vai trò có thẩm quyền	Ghi authority và artifact quyết định; không tự gán cho BA
Verification required	Claim cần xác minh trước khi dùng làm requirement bắt buộc	Giữ nhãn này; không code như nghĩa vụ đã xác nhận

Nếu wireframe cho thấy nút Ghi nhận bị vô hiệu khi Số lượng nhận trống, đó là hành vi UI đề xuất. Nó chưa tự chứng minh quy tắc nghiệp vụ, quyền thao tác hoặc điều kiện pháp lý. Nếu hành vi ảnh hưởng tồn kho, kế toán, truy xuất nguồn gốc, dữ liệu cá nhân hoặc bảo mật, BA phải giữ traceability đến artifact canonical và escalation đến owner có thẩm quyền.

Quick Reference

Quy tắc	Áp dụng
Một requirement chữ không đủ cho hành vi màn hình	Bổ sung trường, trạng thái, validation, lỗi và outcome
UI rule không tự là business rule	Truy vết đến CANONICAL_BUSINESS_RULES khi có rule canonical
Wireframe không thay API spec	API cần artifact tích hợp riêng, dùng OpenAPI khi phù hợp
Wireframe không thay quyền truy cập	Phân quyền cần quyết định security/architecture có thẩm quyền
IN_REVIEW không là approval	Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07 không tạo baseline hay phê duyệt

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. So sánh dưới đây cho thấy wireframe, tức bản phác màn hình có hành vi và quy tắc UI, ngăn chặn rework bằng cách biến cách hiểu ngầm thành phần tử quan sát được trước khi build.

Thành phần	Trước khi có wireframe hành vi	Sau khi có wireframe hành vi	Hệ quả quan sát được
Màn hình NF-ERP-SO-01 tạo đơn bán hàng	BA ghi “người dùng chọn khách hàng, nhập mặt hàng, lưu đơn”. Không chỉ rõ lúc nào hiện hạn mức tín dụng, ai thấy cảnh báo, hay nút nào bị khóa.	Wireframe chỉ vùng Khách hàng, Dòng hàng, Tổng tiền, Trạng thái tín dụng; quy định sau khi chọn khách hàng, hệ thống gọi kiểm tra tín dụng và hiển thị kết quả trong cùng màn hình.	Developer có vị trí hiển thị và trigger rõ. QA có thể kiểm tra chọn khách hàng, nhận kết quả, rồi kiểm tra nút Xác nhận đơn.
Khách hàng vượt hạn mức mô phỏng	Developer có thể cho phép lưu; designer có thể chỉ tô đỏ tổng tiền; QA không có kết quả mong đợi chung.	Quy tắc UI: hiện banner cảnh báo; giữ dữ liệu đã nhập; khóa Xác nhận đơn; vẫn cho Lưu nháp; hiển thị lý do trả về.	Người dùng không mất dòng hàng đã nhập. Các vai trò cùng quan sát một trạng thái, không tranh luận từ câu chữ ngắn.
Quyền của Nhân viên Kinh doanh và Quản lý Kinh doanh	Câu “quản lý được duyệt” không xác định có thấy nút duyệt trên màn hình tạo đơn hay màn hình riêng.	Wireframe tách hành động: Nhân viên Kinh doanh thấy Lưu nháp, Gửi duyệt; Quản lý Kinh doanh thấy Phê duyệt, Từ chối tại NF-ERP-SO-02.	Không đặt nhầm quyền duyệt vào màn hình tạo đơn. Kiểm thử phân quyền có màn hình, vai trò, hành động cụ thể.

Source mermaid — có thể chỉnh sửa

flowchart TB
    subgraph SO01["Nhân viên Kinh doanh — NF-ERP-SO-01"]
        Nhap_don["Nhập hoặc chỉnh sửa đơn"]
        Kiem_tra_tin_dung{"Chọn khách hàng<br/>Kiểm tra tín dụng"}
        Co_the_xac_nhan["Trong hạn mức<br/>Bật Xác nhận đơn"]
        Canh_bao_vuot_han_muc["Vượt hạn mức<br/>Hiện banner và lý do<br/>Giữ dữ liệu đã nhập<br/>Khóa Xác nhận đơn<br/>Bật Lưu nháp<br/>Bật Gửi duyệt"]
        Luu_nhap["Lưu nháp"]
        Xac_nhan_don["Xác nhận đơn"]
        Gui_duyet["Gửi duyệt"]

        Nhap_don --> Kiem_tra_tin_dung
        Kiem_tra_tin_dung -->|Trong hạn mức| Co_the_xac_nhan
        Kiem_tra_tin_dung -->|Vượt hạn mức| Canh_bao_vuot_han_muc
        Canh_bao_vuot_han_muc -->|Chọn Lưu nháp| Luu_nhap
        Canh_bao_vuot_han_muc -->|Chọn Gửi duyệt| Gui_duyet
        Luu_nhap -->|Tiếp tục chỉnh sửa| Nhap_don
        Co_the_xac_nhan -->|Chọn Xác nhận đơn| Xac_nhan_don
        Co_the_xac_nhan -->|Chọn Gửi duyệt| Gui_duyet
    end

    subgraph SO02["Quản lý Kinh doanh — NF-ERP-SO-02"]
        Cho_xu_ly["Đơn chờ xử lý"]
        Phe_duyet["Phê duyệt"]
        Tu_choi["Từ chối"]

        Cho_xu_ly -->|Chọn Phê duyệt| Phe_duyet
        Cho_xu_ly -->|Chọn Từ chối| Tu_choi
    end

    Gui_duyet --> Cho_xu_ly

Trước trạng thái này, cùng một requirement ngắn có thể sinh ba bản build khác nhau: cho lưu và xác nhận, chỉ cảnh báo, hoặc chặn toàn bộ thao tác. Sau wireframe, hành vi sai nhìn thấy ngay trong review: nút còn bật khi trạng thái là Canh_bao_vuot_han_muc, dữ liệu bị xóa sau cảnh báo, hoặc vai trò sai thấy hành động Phê duyệt. Đây là hậu quả thực tế quan sát được, không dùng số liệu bịa đặt.

Ranh giới cần giữ: sơ đồ và ví dụ không xác nhận hạn mức tín dụng, phân quyền, hay cấu hình ERP thật của Nova Foods. Chúng chỉ mô tả phương án màn hình cho dữ liệu mô phỏng. Mọi quy tắc nghiệp vụ canonical phải được truy vết về CANONICAL_BUSINESS_RULES; mọi trường dữ liệu phải khớp CANONICAL_DATA_DICTIONARY; ID mới không được tự tạo ngoài TRACEABILITY_ID_REGISTRY.

Core

Trong wireframe, cùng một câu có năm trạng thái bằng chứng khác nhau. Không tách chúng, đội dự án dễ biến ý kiến thành yêu cầu, giả định thành quy tắc ERP, hoặc bản nháp thành quyết định đã được phê duyệt. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp.

Loại	Nghĩa từ gốc	Bằng chứng tối thiểu	Cách ghi trong artifact
Fact đã xác minh	Thông tin đã đối chiếu nguồn kiểm soát được	URL chính thức, artifact canonical, hoặc bằng chứng hệ thống được định danh	Nêu nguồn, ngày 2026-08-07, phạm vi xác minh
Stakeholder input	Ý kiến, nhu cầu, mô tả vấn đề từ người liên quan	Người nói, thời điểm, ngữ cảnh; chưa đủ để thành rule	Ghi nguyên ý nghĩa, không đổi thành “hệ thống phải”
Project assumption	Điều nhóm tạm coi đúng để tiếp tục phân tích	Lý do cần giả định, rủi ro nếu sai, người cần xác minh	Gắn nhãn Project assumption và điểm kiểm tra
Decision	Lựa chọn giữa các phương án theo tiêu chí	Phương án, tiêu chí, thẩm quyền, tham chiếu quyết định	Chỉ ghi “Decision” khi có authority và record rõ
Verification-required claim	Khẳng định có thể ảnh hưởng pháp lý, kế toán, bảo mật, vận hành hoặc cấu hình	Nguồn hiện có chưa đủ, hoặc cần vai trò chuyên môn xác nhận	Gắn Verification required; không biến thành UI rule bắt buộc

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Phát biểu về màn hình] --> B{Có nguồn kiểm soát<br/>đã đối chiếu?}

    B -->|Có| C{Có nguồn, ngày 2026-08-07<br/>và phạm vi xác minh rõ?}
    C -->|Có| D[Fact đã xác minh]
    C -->|Không| V[Giữ provenance gốc;<br/>Verification required<br/>Định danh vai trò xác minh]

    B -->|Không| E{Là ý kiến từ<br/>stakeholder?}
    E -->|Có| F{Có người nói, thời điểm<br/>và ngữ cảnh?}
    F -->|Có| G[Stakeholder input]
    F -->|Không| V

    E -->|Không| H{Nhóm cần tạm dùng<br/>để phân tích?}
    H -->|Có| I{Có lý do cần giả định,<br/>rủi ro nếu sai, điểm kiểm tra<br/>và người cần xác minh?}
    I -->|Có| J[Project assumption]
    I -->|Không| V
    H -->|Không| V

    G --> Q{Claim ảnh hưởng pháp lý,<br/>kế toán, bảo mật, vận hành<br/>hoặc cấu hình?}
    J --> Q
    Q -->|Có| V
    Q -->|Không| L[Đầu vào phân tích;<br/>không tự thành Decision]

    D --> L

    V --> M{Xác minh chuyên môn<br/>đạt?}
    M -->|Không| N[Giữ Verification-required claim;<br/>không thành UI rule bắt buộc<br/>hoặc Decision]
    M -->|Có| O{Đủ nguồn, ngày 2026-08-07<br/>và phạm vi xác minh rõ?}
    O -->|Có| D
    O -->|Không| P[Giữ provenance gốc;<br/>ghi trạng thái xác minh;<br/>không phải Fact]
    P --> L

    L --> R{Có lựa chọn giữa phương án<br/>theo tiêu chí?}
    R -->|Không| S[Không ghi là Decision]
    R -->|Có| T{Authority, record và<br/>decision reference rõ?}
    T -->|Có| U[Decision]
    T -->|Không| S

Applied

Ví dụ artifact-ready cho wireframe màn hình tạo phiếu xuất kho mô phỏng:

Trường	Nội dung ghi nhận
Facts	/01-curriculum/CHAPTER_MANIFEST.md có trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07; metadata này không là baseline hoặc approval. Đây là fact vì artifact canonical nêu trực tiếp.
Current Behavior	Wireframe nháp hiển thị nút Lưu và Gửi duyệt. Đây là mô tả thiết kế hiện tại, không chứng minh ERP thực có hành vi này.
Underlying Need	Cần phân biệt lưu nháp với gửi xử lý để người dùng không hiểu nhầm trạng thái chứng từ. Đây là nhu cầu phân tích, chưa là business rule.
Options	(1) Một nút Lưu; (2) hai nút Lưu nháp và Gửi duyệt; (3) tự gửi duyệt khi lưu.
Decision Criteria	Rõ trạng thái cho người dùng; phù hợp quy trình được Business Owner xác nhận; có thể kiểm thử; không tự suy diễn kiểm soát kế toán.
Decision	Chưa có decision. Không được ghi wireframe là “đã chọn hai nút” khi chưa có record thẩm quyền.
Authority	Business Owner quyết định luồng nghiệp vụ; Product/UX Owner quyết định biểu đạt UI; Accounting Owner hoặc Legal Owner phải xác minh nếu thao tác ảnh hưởng chứng từ hoặc nghĩa vụ pháp lý.
Artifact	Ghi trong /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md với nhãn nguồn từng dòng; tham chiếu CANONICAL_BUSINESS_RULES chỉ khi catalog có rule được kiểm soát.
Consequence if Wrong	Stakeholder input “cần gửi nhanh” bị viết thành rule tự động gửi duyệt. QA sẽ kiểm thử hành vi chưa được quyết định; đội phát triển có thể phải sửa UI, quyền và trạng thái sau review.

Senior Lens

Câu “phải lưu lịch sử người sửa để tuân thủ pháp luật” không là fact nếu chưa đối chiếu văn bản hiện hành và chưa có Legal Owner xác nhận áp dụng. Nguồn pháp lý trong /00-research/00_SOURCE_MAP.md xác nhận tồn tại nguồn chính thức, không tự xác nhận requirement cụ thể cho Nova Foods mô phỏng. Vì cầu nối bằng chứng chưa đủ, câu này là Verification required.

Câu “thủ kho muốn thấy mã lô trước ngày hết hạn” là Stakeholder input. Nó có giá trị thiết kế vì chỉ ra nhu cầu thao tác, nhưng không tự chứng minh thứ tự cột, dữ liệu sẵn có, hay quy tắc chặn xuất kho. Nếu wireframe cần tiếp tục trước khi xác minh, ghi Project assumption: dữ liệu mã lô và ngày hết hạn có thể được cung cấp cho màn hình; nêu Architect hoặc Data Owner cần kiểm tra.

Quick Reference

Không được viết	Viết đúng
“Nova Foods đã phê duyệt nút Gửi duyệt.”	“Decision chưa được ghi nhận; wireframe giữ phương án để review.”
“Luật yêu cầu màn hình này khóa sửa.”	“Verification required: Legal Owner xác minh nghĩa vụ và phạm vi áp dụng.”
“Người dùng nói nên hiện mã lô, nên đó là rule.”	“Stakeholder input: hiển thị mã lô được đề xuất; cần xác minh data availability và quyết định.”
“ERP có trạng thái nháp.”	“Project assumption: cần trạng thái nháp để phân tích hành vi; cần Business Owner xác nhận.”

3. V? tr? trong Lifecycle

Core

Wireframe là bản mô tả trực quan về bố cục màn hình, hành vi, trạng thái và quy tắc giao diện người dùng. Trong Lifecycle, wireframe không bắt đầu từ ý tưởng giao diện rồi ép nghiệp vụ theo giao diện. Nó đi sau nhu cầu đã được làm rõ và đi trước cấu hình, lập trình, kiểm thử. Lý do: Delivery cần biết phải tạo gì; Testing cần biết hành vi quan sát được nào cần kiểm tra.

Giai đoạn	Entry gate: điều kiện vào	Wireframe làm gì	Exit gate: điều kiện ra
Discovery	Có vấn đề hoặc cơ hội nghiệp vụ được ghi nhận, nhưng chưa coi là requirement	Phác thảo luồng thao tác để khám phá người dùng cần xem, nhập, chọn hoặc xác nhận gì	Có danh sách câu hỏi mở, giả định và phạm vi màn hình dự kiến; không biến giả định thành rule
Analysis	Có stakeholder input, phạm vi nghiệp vụ và dữ liệu sơ bộ	Chuyển nhu cầu thành màn hình, trường dữ liệu, hành động, trạng thái, thông báo lỗi và acceptance criteria dự kiến	Mỗi thành phần wireframe liên kết được tới nhu cầu, rule, data hoặc Verification required
Delivery	Có wireframe đủ rõ để đội Delivery hiểu hành vi cần tạo	Là test basis trực quan cho cấu hình ERP, phát triển và mô tả API khi có tích hợp	Delivery xác nhận được phạm vi hiển thị, thao tác và trạng thái; điểm chưa xác minh vẫn giữ nhãn
Testing	Có bản build hoặc cấu hình có thể chạy và test basis từ Analysis	So sánh hành vi thực tế với wireframe, rule và acceptance criteria	Lỗi giao diện, luồng, quyền hiển thị, kiểm tra dữ liệu và thông báo được ghi nhận theo traceability
Release	Có kết quả kiểm thử, danh sách lỗi và quyết định phát hành được ghi nhận bởi vai trò có thẩm quyền	Làm tài liệu tham chiếu để kiểm tra màn hình phát hành không lệch phạm vi đã phân tích	Phiên bản wireframe khớp phạm vi phát hành hoặc chênh lệch được ghi nhận rõ
Operations	Màn hình đã được đưa vào vận hành theo quyết định có thẩm quyền	Hỗ trợ phân tích phản hồi, lỗi thao tác và yêu cầu thay đổi	Mọi thay đổi quay lại Discovery hoặc Analysis; không sửa wireframe để hợp thức hóa hành vi chưa được quyết định

Source mermaid — có thể chỉnh sửa

flowchart TB
    D[Discovery<br/>Nhu cầu và câu hỏi mở]
    A[Analysis<br/>Wireframe và hành vi]
    DV[Delivery<br/>Cấu hình hoặc phát triển]
    T[Testing<br/>Đối chiếu test basis]
    R[Release<br/>Kiểm tra phạm vi phát hành]
    G{Phạm vi phát hành khớp wireframe<br/>hoặc chênh lệch đã ghi nhận rõ?}
    X[Quay lại Analysis hoặc Delivery<br/>xử lý chênh lệch]
    O[Operations<br/>Phản hồi và lỗi]

    D -->|"Exit Discovery: câu hỏi mở, giả định, phạm vi màn hình dự kiến;<br/>giả định chưa thành rule<br/>Entry Analysis: stakeholder input, phạm vi nghiệp vụ, dữ liệu sơ bộ"| A
    A -->|"Mỗi thành phần liên kết tới nhu cầu, rule, data<br/>hoặc `Verification required`;<br/>wireframe đủ rõ để Delivery hiểu hành vi cần tạo"| DV
    DV -->|"Build hoặc cấu hình chạy được;<br/>test basis từ Analysis"| T
    T -->|"Ghi nhận lỗi giao diện, luồng, quyền hiển thị,<br/>kiểm tra dữ liệu, thông báo và traceability;<br/>có danh sách lỗi và quyết định phát hành<br/>do vai trò có thẩm quyền xác nhận"| R
    R --> G
    G -->|Có| O
    G -->|Chưa| X
    X -->|Cần phân tích lại| A
    X -->|Cần điều chỉnh Delivery| DV
    O -->|Nhu cầu hoặc câu hỏi thay đổi mới| D
    O -->|Thay đổi đã đủ đầu vào phân tích| A

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; dữ liệu đều tổng hợp. Stakeholder input nêu thủ kho cần nhận biết lô hàng khi chuẩn bị xuất kho. Chưa có bằng chứng rằng dữ liệu mã lô, ngày hết hạn và quyền xem lô đã sẵn sàng trong ERP.

Current Behavior: Wireframe màn hình xuất kho dự kiến có bảng dòng hàng, nhưng chưa xác định cột nào hiển thị cho từng dòng. Nếu Delivery bắt đầu ngay, đội phát triển phải tự chọn giữa hiển thị mã lô, ngày hết hạn, cả hai, hoặc không hiển thị.

Underlying Need: Người thao tác cần đủ thông tin để nhận biết lô đang được chọn trước khi xác nhận xuất kho. Nhu cầu này khác với quy tắc chặn xuất lô hết hạn; quy tắc chặn cần nguồn nghiệp vụ và xác minh riêng.

Mục	Nội dung
Options	1. Hiển thị Mã lô; 2. Hiển thị Mã lô và Ngày hết hạn; 3. Chỉ mở chi tiết lô khi người dùng chọn dòng hàng
Decision Criteria	Dữ liệu có sẵn; tốc độ nhận biết lô; không làm bảng quá rộng; quyền xem dữ liệu; quy tắc nghiệp vụ đã được xác minh
Decision	Trong Analysis, wireframe dùng phương án 2 với nhãn Project assumption; không mô tả chặn xuất kho
Authority	Business Owner quyết định mức thông tin cần thấy; Data Owner hoặc Architect xác minh dữ liệu và khả năng cung cấp; BA không tự xác nhận rule hay khả năng kỹ thuật
Artifact	Wireframe ghi cột Mã lô, Ngày hết hạn; mỗi cột liên kết tới /01-curriculum/CANONICAL_DATA_DICTIONARY.md; điểm chưa xác minh ghi Verification required
Consequence if Wrong	Delivery có thể làm màn hình thiếu dữ liệu thao tác hoặc truy cập dữ liệu không được phép; Testing thiếu test basis để phát hiện sai khác

Cầu nối suy luận là: stakeholder input chứng minh nhu cầu nhận biết lô; nó không chứng minh dữ liệu tồn tại, thứ tự cột đúng, hoặc nghĩa vụ chặn xuất. Vì hai bằng chứng sau chưa có, wireframe chỉ được qua exit gate Analysis khi giữ rõ Project assumption và Verification required.

Senior Lens

Exit gate không phải nghi thức ký tên. Exit gate là điều kiện kiểm soát để giai đoạn sau không phải suy đoán. Ví dụ, wireframe có nút Xác nhận xuất kho nhưng không nêu khi nào nút bị khóa thì Testing không thể tạo kiểm thử nhất quán. Ngược lại, nếu chưa có rule được xác minh, không được bịa điều kiện khóa nút để làm wireframe có vẻ hoàn chỉnh.

IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và VND là metadata corpus Nova Foods mô phỏng. Chúng không là exit gate nghiệp vụ, không là baseline và không chứng minh phê duyệt. Chỉ artifact kiểm soát có tham chiếu quyết định phù hợp mới được mô tả trạng thái quyết định tương ứng.

Quick Reference

Giai đoạn	Câu kiểm tra exit gate
Discovery	Đã tách nhu cầu, câu hỏi mở và giả định chưa?
Analysis	Mỗi trường, nút, trạng thái và thông báo có nguồn hoặc nhãn xác minh chưa?
Delivery	Đội thực hiện có thể tạo hành vi mà không tự đặt rule mới chưa?
Testing	Tester có thể quan sát và đối chiếu hành vi với test basis chưa?
Release	Khác biệt giữa phạm vi phát hành và wireframe đã được ghi nhận chưa?
Operations	Phản hồi mới đã quay về phân tích thay vì sửa ngầm tài liệu chưa?

Core

Handoff là chuyển giao có kiểm soát giữa vai trò: người giao nêu artifact, phạm vi và điểm chưa quyết; người nhận xác nhận đủ đầu vào để thực hiện phần việc thuộc thẩm quyền. Không phải chuyển trách nhiệm phê duyệt. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu là tổng hợp; corpus ở IN_REVIEW, v0.9.0, ngày 2026-08-07.

Quan hệ	Owner giao	Owner nhận	Artifact/handoff	Giới hạn thẩm quyền	Escalation
Upstream nguồn	Principal IT Business Analyst / Technical Curriculum Author	BA soạn wireframe	00_SOURCE_MAP, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY	BA giữ ID, nguồn, trạng thái; không xác nhận luật, kế toán, bảo mật	Nguồn mâu thuẫn hoặc ID chưa đăng ký: escalation theo TRACEABILITY_ID_REGISTRY
Upstream nghiệp vụ	Business Owner	BA soạn wireframe	Nhu cầu, luồng, ngoại lệ nghiệp vụ mô phỏng	Business Owner quyết mục tiêu nghiệp vụ; không tự quyết kiến trúc hay test pass	Mục tiêu xung đột quy tắc canonical: escalation Principal IT Business Analyst / Technical Curriculum Author
Upstream quy tắc/dữ liệu	Owner có thẩm quyền của CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY	BA soạn wireframe	Rule ID, data field, trạng thái dữ liệu	BA không sửa nghĩa rule hay định nghĩa dữ liệu qua màn hình	Rule tác động pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm: Legal, Accounting, Compliance hoặc domain owner xác minh
Downstream delivery	BA	UX/UI Designer, Solution Architect, Developer	Wireframe, hành vi màn hình, UI rule, traceability	BA mô tả yêu cầu; Architect quyết kiến trúc; Developer không tự đổi rule nghiệp vụ	UI không khả thi kỹ thuật hoặc làm lộ dữ liệu: Architect và Security review
Downstream testing	BA	QA/Test Analyst	Acceptance criteria, trạng thái, validation, error behavior	QA quyết bằng chứng test; BA không tự tuyên bố pass	Tiêu chí mơ hồ hoặc không kiểm thử được: trả BA làm rõ
Downstream vận hành	BA và Business Owner	Operations Owner, Support	Hành vi dự kiến, quyền thao tác, thông báo lỗi	Operations Owner quyết cách vận hành mô phỏng; không thay đổi requirement im lặng	Lỗi gây sai chứng từ, truy vết hoặc dữ liệu cá nhân: dừng quyết định tại owner chuyên môn phù hợp

Applied

Mục	Nội dung
Facts	Wireframe màn hình “Xác nhận xuất kho” mô phỏng hiển thị số phiếu, lô hàng, số lượng và nút Xác nhận.
Current Behavior	BA nhận yêu cầu thêm nút từ Business Owner, nhưng chưa có rule canonical xác định ai được xác nhận khi số lượng thực xuất khác số lượng đề nghị.
Underlying Need	Cần phân định quyền quyết chênh lệch và người chịu trách nhiệm trước khi UI tạo thao tác không thể giải thích.
Options	1. Hiển thị nút cho mọi người dùng. 2. Khóa nút khi có chênh lệch. 3. Hiển thị nút theo quyền, bắt buộc lý do chênh lệch và chuyển ngoại lệ cho owner nghiệp vụ.
Decision Criteria	Phải giữ traceability, không tự tạo rule, cho QA kiểm thử được, không vượt thẩm quyền Business Owner, Architect, Security hoặc Accounting Owner.
Decision	Chọn phương án 3 ở mức wireframe: ghi rõ “quyền và rule chênh lệch: Verification required”; không gán role hoặc ngưỡng VND tổng hợp thành rule canonical.
Authority	Business Owner quyết quy trình nghiệp vụ; Accounting Owner xác minh ảnh hưởng chứng từ; Architect quyết cơ chế phân quyền; Security review dữ liệu và quyền; BA ghi nhận hành vi và handoff.
Artifact	Wireframe liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; trạng thái vẫn IN_REVIEW, không phải approval.
Consequence if Wrong	Nút xác nhận có thể cho người không đúng quyền hoàn tất giao dịch mô phỏng; QA thiếu test basis; delivery tự suy diễn rule; traceability đứt.

Senior Lens

BA phải escalation khi UI buộc chọn giữa hai cách hiểu nghiệp vụ mà artifact upstream chưa quyết. Bằng chứng: wireframe biến rule thành thao tác người dùng; thao tác đã hiển thị thường bị delivery hiểu là yêu cầu. Vì vậy BA được làm rõ, ghi giả định và giữ liên kết; không được tự cấp quyền, đặt ngưỡng, diễn giải luật, hay xác nhận compliance.

Source mermaid — có thể chỉnh sửa

flowchart TB
    UP[Artifact upstream<br/>ID, rule, data boundary] --> DRAFT[Wireframe và UI rules<br/>trạng thái chưa chốt]
    DRAFT --> RISK[Rủi ro: thao tác đã hiển thị<br/>có thể bị delivery hiểu là yêu cầu]
    RISK --> COND{UI buộc chọn giữa hai cách hiểu nghiệp vụ<br/>mà artifact upstream chưa quyết?}

    COND -->|Không| READY[Tiếp tục bàn giao wireframe/UI rules<br/>với traceability tới artifact nguồn]
    COND -->|Có| BA[BA làm rõ<br/>ghi giả định<br/>giữ liên kết artifact nguồn]
    BA --> ESC[Escalation vấn đề vượt quyền]
    ESC --> OWNER[Owner có thẩm quyền<br/>với rule hoặc compliance tranh chấp]
    OWNER --> DECISION[Quyết định được xác nhận]
    DECISION --> UPDATE[Cập nhật wireframe, UI rules<br/>và liên kết quyết định]
    UPDATE --> READY

    BA -. Không được .-> LIMIT[Không tự cấp quyền<br/>không đặt ngưỡng<br/>không diễn giải luật<br/>không xác nhận compliance]

Quick Reference

• BA giao artifact, không giao thẩm quyền.
• Người nhận chỉ triển khai hoặc kiểm thử phần đã rõ và truy vết được.
• Mâu thuẫn rule, data, quyền, pháp lý, kế toán, bảo mật: escalation; không vá bằng UI.
• IN_REVIEW và v0.9.0 chỉ là trạng thái quản trị; không là baseline, approval hay quyền production.

Core

Sơ đồ vòng đời giúp thấy wireframe (bản phác thảo bố cục và hành vi màn hình) đi qua các pha mà không biến thành yêu cầu, thiết kế kỹ thuật hay bằng chứng kiểm thử. Nova Foods Trading & Manufacturing là case mô phỏng; mọi tên và dữ liệu dưới đây là tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Source mermaid — có thể chỉnh sửa

flowchart TB
    D[Discovery<br/>Nêu vấn đề người dùng] --> A[Analysis<br/>Làm rõ luồng, dữ liệu, quy tắc]
    A --> W[Wireframe & UI rules<br/>Mô tả màn hình, trạng thái, phản hồi]
    W --> L[Delivery<br/>Thiết kế và xây dựng]
    L --> T[Testing<br/>Kiểm tra theo yêu cầu hoặc<br/>tiêu chí chấp nhận đã phê duyệt]
    T --> R[Release<br/>Đưa bản đã đủ điều kiện phát hành]
    R --> O[Operations<br/>Theo dõi sử dụng và lỗi vận hành]

    A -.tham chiếu.-> C[CANONICAL_BUSINESS_RULES]
    A -.tham chiếu.-> DD[CANONICAL_DATA_DICTIONARY]
    W -.truy vết.-> TR[TRACEABILITY_ID_REGISTRY]

    AC[Yêu cầu hoặc tiêu chí chấp nhận<br/>đã phê duyệt] -.căn cứ kiểm thử.-> T
    W -.tham chiếu giao diện,<br/>không xác nhận hành vi.-> T

    O -->|Phản hồi thay đổi màn hình| Q{Có cần xem lại<br/>vấn đề người dùng?}
    Q -->|Có| D
    Q -->|Không| M[Tiếp tục theo dõi vận hành]

Sơ đồ dùng Mermaid, không phải BPMN. Bằng chứng chọn Mermaid: mục tiêu là quét nhanh quan hệ pha và điểm phản hồi; sơ đồ không mô tả ký hiệu BPMN chuẩn hay quy trình vận hành thực tế.

Applied

Trường	Nội dung mô phỏng Nova Foods
Facts	Nhân viên kho cần xem màn hình xác nhận nhập lô hàng nguyên liệu; màn hình có mã lô, số lượng, đơn vị tính và trạng thái kiểm tra chất lượng.
Current Behavior	Chưa có wireframe kiểm soát; người học chỉ biết luồng nhập kho ở mức mô tả.
Underlying Need	Cần đặt wireframe sau Analysis vì bố cục phải phản ánh dữ liệu, quy tắc và trạng thái đã được làm rõ, trước khi Delivery diễn giải thành giao diện chạy được.
Options	1. Vẽ wireframe ngay từ Discovery. 2. Vẽ sau Analysis. 3. Chỉ vẽ khi Testing phát hiện lỗi giao diện.
Decision Criteria	Wireframe phải có đầu vào đủ rõ, còn đủ sớm để sửa rẻ, và tạo test basis cho Testing.
Decision	Chọn phương án 2: đặt wireframe giữa Analysis và Delivery. Lý do: Analysis cung cấp ngữ cảnh màn hình; Delivery và Testing dùng cùng mô tả để giảm suy diễn khác nhau.
Authority	BA duy trì nội dung wireframe và traceability. Business Owner quyết định ưu tiên nghiệp vụ. Architect quyết định giới hạn kỹ thuật. QA quyết định đủ bằng chứng kiểm thử. Không vai trò nào được suy diễn phê duyệt từ artifact IN_REVIEW.
Artifact	/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md, tham chiếu kiểm soát CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Nếu vẽ trước khi làm rõ Analysis, Delivery có thể xây trường dữ liệu hoặc nút thao tác không có căn cứ. Nếu vẽ sau Testing, lỗi hành vi màn hình chỉ lộ khi chi phí sửa cao hơn.

Senior Lens

Không dùng sơ đồ vòng đời để hợp thức hóa quyết định ngoài thẩm quyền. Ví dụ, màn hình hiện cảnh báo dữ liệu cá nhân hay truy xuất lô không chứng minh tuân thủ pháp lý, an toàn thực phẩm hoặc bảo mật. Khi wireframe đụng dữ liệu cá nhân, hạch toán, hóa đơn, truy xuất hoặc quyền truy cập, giữ nhãn Verification required và chuyển vấn đề tới Legal Owner, Accounting Owner, Security Owner hoặc domain owner phù hợp.

Điểm quay lại từ Operations sang Discovery là phản hồi cần phân tích mới, không phải quyền sửa im lặng wireframe. Bằng chứng: phản hồi vận hành chỉ cho biết có dấu hiệu vấn đề; nguyên nhân, phạm vi ảnh hưởng và quyết định thay đổi còn cần được xác minh trong pha Discovery và Analysis.

Quick Reference

Mục đích	Vị trí trên vòng đời	Không có nghĩa là
Hiểu nhu cầu màn hình	Discovery, Analysis	Đã có thiết kế giao diện cuối
Mô tả bố cục và phản hồi UI	Sau Analysis, trước Delivery	Đã phê duyệt hoặc đã baseline
Hướng dẫn xây dựng	Delivery	Được phép tự đổi quy tắc nghiệp vụ
Làm test basis	Testing	Thay thế test case hoặc bằng chứng QA
Ghi nhận vấn đề sử dụng	Operations	Xác nhận lỗi gốc hoặc quyết định sửa

4. Input c?n thi?t

Core

Wireframe cần đầu vào trước khi vẽ. Người mới không cần biết phần mềm: wireframe là bản phác bố cục và hành vi màn hình, không phải màn hình chạy được. BA không tự đoán trường, nút, trạng thái hay dữ liệu. Mỗi thành phần phải truy ngược được về bằng chứng hoặc artifact nguồn.

Đầu vào gồm kiến thức nghiệp vụ tối thiểu, bằng chứng và artifact nguồn. Kiến thức nghiệp vụ tối thiểu là hiểu người dùng làm việc gì, đối tượng nào được xem hoặc sửa, và kết quả nào cần đạt. Ví dụ, trước khi phác màn hình quản lý lô hàng, BA phải hiểu “lô” là đối tượng nghiệp vụ cần nhận diện; không được tự suy ra mã lô, ngày hết hạn hay nút khóa lô.

Bằng chứng là nội dung cho phép kiểm tra lý do tồn tại của một thành phần UI. Bằng chứng có thể là quy tắc nghiệp vụ, định nghĩa dữ liệu, luồng nghiệp vụ, yêu cầu đã ghi nhận, hoặc nguồn chuẩn. Artifact nguồn là tệp kiểm soát chứa bằng chứng đó. Với corpus Nova Foods mô phỏng, mọi dữ liệu là tổng hợp; artifact chỉ là nguồn học liệu, không chứng minh cấu hình ERP thật hay quyết định vận hành thật.

Định danh canonical là ID ổn định, dùng nguyên dạng để nối các artifact. ID tránh việc một khái niệm bị gọi nhiều tên rồi mất truy vết. Ví dụ, CANONICAL_DATA_DICTIONARY luôn chỉ kế hoạch từ điển dữ liệu logic canonical; không đổi thành “Data Dictionary Nova” trong liên kết kiểm soát. Tương tự, phải giữ nguyên CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Kiến thức nghiệp vụ tối thiểu] --> D[Wireframe: bố cục và hành vi màn hình]
    C[Artifact nguồn] -->|chứa| B[Bằng chứng]
    B --> D
    C --> D
    E[Canonical ID] -->|nối các artifact| C
    D --> F[Thành phần UI]
    F -->|truy ngược| C

Applied

Facts: Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Tài liệu đang ở IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Current Behavior: Người học dễ bắt đầu từ ô nhập liệu, bảng dữ liệu và nút thao tác vì các thành phần này quen thuộc. Cách làm này tạo UI trước căn cứ nghiệp vụ.

Underlying Need: Wireframe cần cho thấy màn hình hỗ trợ công việc nào và từng thành phần có nguồn từ đâu.

Options:
1. Vẽ từ giả định cá nhân.
2. Dùng artifact canonical đã có làm đầu vào.
3. Chờ tự tạo quy tắc và dữ liệu mới rồi mới vẽ.

Decision Criteria: Giữ được traceability; không tạo rule mới; không đổi ID; không diễn giải artifact kế hoạch thành phê duyệt hoặc baseline.

Decision: Dùng artifact canonical hiện có làm nguồn đầu vào; chỉ mô tả thành phần UI khi nối được với nhu cầu hoặc evidence đã ghi nhận.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và liên kết artifact. Vai trò này không có quyền xác nhận rule Nova Foods, baseline, approval, pháp lý, kế toán, bảo mật hay production.

Artifact:
- /01-curriculum/CANONICAL_BUSINESS_RULES.md — CANONICAL_BUSINESS_RULES
- /01-curriculum/CANONICAL_DATA_DICTIONARY.md — CANONICAL_DATA_DICTIONARY
- /01-curriculum/TRACEABILITY_ID_REGISTRY.md — TRACEABILITY_ID_REGISTRY
- /00-research/00_SOURCE_MAP.md — 00_SOURCE_MAP

Consequence if Wrong: Nếu BA đổi tên ID, vẽ theo suy đoán, hoặc dùng nguồn kế hoạch như quyết định đã phê duyệt, Delivery và QA không xác định được căn cứ của trường UI. Lỗi có thể lan sang quy tắc, dữ liệu và test basis.

Senior Lens

Phân loại nguồn trước khi dùng, nhưng không nâng cấp thẩm quyền nguồn. CANONICAL_BUSINESS_RULES là nguồn catalog quy tắc dự kiến; nó không tự biến nội dung thành quy tắc vận hành. CANONICAL_DATA_DICTIONARY là nguồn định nghĩa dữ liệu logic dự kiến; nó không tự là schema triển khai. TRACEABILITY_ID_REGISTRY giữ định danh và liên kết; nó không quyết định nghiệp vụ. 00_SOURCE_MAP chỉ giới hạn cách dùng nguồn chuẩn và pháp lý; nó không thay thế kết luận của Legal Owner, Accounting Owner, Security Owner hoặc domain owner.

Cầu nối suy luận phải viết rõ: “Màn hình cần hiển thị X vì artifact Y định nghĩa hoặc yêu cầu X.” Không đủ căn cứ thì giữ thành phần ngoài wireframe. Đây là kiểm soát phạm vi, không phải thiếu sót.

Quick Reference

Loại đầu vào	Dùng để trả lời	Nguồn canonical
Kiến thức nghiệp vụ	Người dùng đang làm công việc gì?	Evidence nghiệp vụ đã ghi nhận
Quy tắc nghiệp vụ	UI cần hạn chế hoặc cho phép hành vi nào?	CANONICAL_BUSINESS_RULES
Định nghĩa dữ liệu	UI cần gọi đúng đối tượng, thuộc tính nào?	CANONICAL_DATA_DICTIONARY
ID truy vết	Thành phần UI nối với artifact nào?	TRACEABILITY_ID_REGISTRY
Ranh giới nguồn	Nguồn chuẩn hoặc pháp lý được dùng tới đâu?	00_SOURCE_MAP

Core

Kiểm tra chất lượng đầu vào là xác nhận nguồn đủ dùng trước khi BA vẽ wireframe hoặc viết quy tắc màn hình. Đầu vào không phải “đúng vì có tệp”; phải truy được nguồn, còn mới, có Owner chịu trách nhiệm, không vượt thẩm quyền.

Kiểm tra	Tiêu chí đạt	Không đạt
Nhận diện	Có Artifact ID, đường dẫn canonical, Status, Version	Không dùng làm căn cứ thiết kế
Nguồn gốc	Phân loại nguồn rõ: PRIMARY_OFFICIAL, CONTROLLED_INTERNAL, PROJECT_ASSUMPTION, VERIFICATION_REQUIRED	Không suy diễn thành fact
Tính mới	Ngày cập nhật hoặc ngày truy cập xác định; dùng Asia/Ho_Chi_Minh	Gắn nhãn cũ, xin xác minh
Thẩm quyền	Owner nguồn có quyền duy trì; quyết định nghiệp vụ thuộc đúng vai trò	Escalate, không tự quyết
Nhất quán	ID, trạng thái, phạm vi không mâu thuẫn artifact canonical	Dừng phần bị ảnh hưởng
An toàn diễn giải	Luật, kế toán, thuế, an toàn thực phẩm chỉ nêu phạm vi đã xác minh	Gắn Verification required

PRIMARY_OFFICIAL là nguồn do tổ chức ban hành chính thức, như URL ISO, W3C, OMG, OWASP hoặc văn bản Chính phủ. CONTROLLED_INTERNAL là artifact corpus có ID, đường dẫn, Status và Version kiểm soát. PROJECT_ASSUMPTION là giả định học liệu, không phải quy tắc Nova Foods. VERIFICATION_REQUIRED là thông tin chưa đủ bằng chứng hoặc cần vai trò có thẩm quyền xác nhận.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Nhận đầu vào] --> B{Có Artifact ID, đường dẫn canonical,<br/>Status, Version?}
    B -- Không --> S1[STOP: không dùng làm căn cứ thiết kế]
    B -- Có --> C{Đã phân loại nguồn<br/>và xác định Owner?}
    C -- Không --> S2[STOP: nguồn hoặc thẩm quyền chưa rõ]
    C -- Có --> D{Owner có quyền duy trì?}
    D -- Không --> X[Escalate: chưa đúng thẩm quyền]
    D -- Có --> C1{Loại nguồn}

    C1 -- PROJECT_ASSUMPTION --> P[Chỉ dùng làm giả định học liệu<br/>gắn nhãn PROJECT_ASSUMPTION]
    C1 -- VERIFICATION_REQUIRED --> V0[Không dùng phần chưa xác minh<br/>làm evidence]
    C1 -- PRIMARY_OFFICIAL --> E{Quyết định nghiệp vụ<br/>thuộc đúng vai trò?}
    C1 -- CONTROLLED_INTERNAL --> E

    E -- Không --> X
    E -- Có --> F{Có ngày cập nhật hoặc ngày truy cập<br/>theo Asia/Ho_Chi_Minh và còn mới?}
    F -- Không --> V1[Gắn nhãn cũ và xin xác minh]
    F -- Có --> G{Có mâu thuẫn với<br/>artifact canonical?}
    G -- Có --> S3[STOP: dừng phần bị ảnh hưởng]
    G -- Không --> I{Thuộc luật, kế toán, thuế<br/>hoặc an toàn thực phẩm?}
    I -- Không --> K[Dùng làm evidence cho wireframe]
    I -- Có --> J{Đã xác minh đúng phạm vi?}
    J -- Không --> V3[Gắn VERIFICATION_REQUIRED<br/>không dùng phần chưa xác minh làm evidence]
    J -- Có --> K

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp. Ngày kiểm soát 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Các artifact dưới đây đều IN_REVIEW, v0.9.0; không artifact nào tự chứng minh baseline hoặc approval.

Current Behavior: BA nhận thông tin từ nhiều tệp và URL. Nếu không kiểm tra nguồn, một nhãn IN_REVIEW có thể bị hiểu sai thành yêu cầu đã chốt.

Underlying Need: Wireframe cần evidence đủ tin cậy để quyết định trường hiển thị, trạng thái, lỗi và quyền thao tác; không được biến kế hoạch curriculum thành cấu hình ERP thật.

Đầu vào	Phân loại	Freshness	Owner	Kiểm tra dùng cho wireframe	Trạng thái
00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md	CONTROLLED_INTERNAL	Cập nhật 2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Chỉ dùng ranh giới nguồn và nguồn tham khảo	Dùng được có điều kiện
CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md	CONTROLLED_INTERNAL	Cập nhật 2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Giữ tên chapter, phạm vi và trạng thái	Dùng được có điều kiện
TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	CONTROLLED_INTERNAL	Cập nhật 2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Kiểm tra ID canonical trước khi liên kết	Dùng được có điều kiện
CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	CONTROLLED_INTERNAL	Cập nhật 2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Không gọi rule là approved hoặc baseline	Dùng được có điều kiện
CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	CONTROLLED_INTERNAL	Cập nhật 2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Chỉ dùng định nghĩa logic đã ghi nhận	Dùng được có điều kiện
WCAG 2.2 tại https://www.w3.org/TR/WCAG22/	PRIMARY_OFFICIAL	Edition 2024-12-12; truy cập 2026-08-07	W3C	Đối chiếu yêu cầu accessibility khi có tiêu chí cụ thể	Dùng được trong boundary
Luật 91/2025/QH15 tại https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	PRIMARY_OFFICIAL	Hiệu lực 2026-01-01; truy cập 2026-08-07	Quốc hội Việt Nam	Không suy diễn nghĩa vụ UI; cần Legal Owner xác minh	VERIFICATION_REQUIRED
Quy tắc lưu số điện thoại khách hàng trên màn hình	PROJECT_ASSUMPTION	Ghi nhận 2026-08-07	Chưa có Business Owner xác nhận	Không thiết kế bắt buộc, che dữ liệu, hoặc retention rule từ giả định	VERIFICATION_REQUIRED

Options: Dùng mọi đầu vào như fact; chỉ dùng nguồn official; hoặc dùng nguồn theo phân loại và chặn phần thiếu thẩm quyền.

Decision Criteria: Traceability phải giữ được; nguồn phải còn mới; Owner phải phù hợp; không diễn giải pháp lý, kế toán, thuế hoặc an toàn thực phẩm vượt evidence.

Decision: Dùng nguồn PRIMARY_OFFICIAL và CONTROLLED_INTERNAL trong ranh giới ghi rõ. Giữ PROJECT_ASSUMPTION và VERIFICATION_REQUIRED ngoài quyết định UI bắt buộc.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và traceability. Business Owner quyết định nhu cầu nghiệp vụ. Legal Owner xác minh diễn giải pháp luật. Accounting Owner xác minh nội dung kế toán. Không vai trò nào được suy ra approval từ IN_REVIEW.

Artifact: Ghi nguồn, phân loại, freshness, Owner, kết quả kiểm tra và nhãn unresolved trong wireframe evidence log của /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md.

Consequence if Wrong: Wireframe có thể hiển thị sai dữ liệu, áp quy tắc chưa được xác minh, che hoặc lộ thông tin sai cách, hoặc tạo test case dựa trên requirement không có thẩm quyền.

Senior Lens

Dừng thiết kế khi gặp một trong các điều kiện sau:

1. Không xác định được Artifact ID hoặc đường dẫn canonical.
2. Hai nguồn canonical mâu thuẫn về cùng một trạng thái, trường dữ liệu hoặc quy tắc.
3. Source mới hơn thiếu Owner, hoặc source cũ hơn đang bị dùng thay source mới.
4. Quyết định cần Legal Owner, Accounting Owner, Security, Architect hoặc Business Owner nhưng chưa có xác minh từ vai trò đó.
5. Nội dung IN_REVIEW bị yêu cầu diễn đạt như baseline, approved, compliant hoặc production-ready.
6. Dữ liệu có khả năng là dữ liệu cá nhân, tài chính hoặc truy xuất thực phẩm nhưng phân loại bảo vệ chưa rõ.

Dừng không phải thất bại. Dừng giữ wireframe không biến khoảng trống bằng chứng thành quyết định giả.

Quick Reference

Nhãn	BA được làm	BA không được làm
PRIMARY_OFFICIAL	Trích phạm vi đã xác minh, ghi URL và ngày truy cập	Bịa điều khoản hoặc diễn giải vượt nguồn
CONTROLLED_INTERNAL	Giữ nguyên ID, tên tệp, Status, Version	Đổi ID, coi IN_REVIEW là approval
PROJECT_ASSUMPTION	Dùng để nêu câu hỏi thiết kế	Biến thành business rule bắt buộc
VERIFICATION_REQUIRED	Gắn rõ điểm chưa xác minh, chỉ định Owner cần xác minh	Hoàn tất quyết định thay Owner

Core

Bảng dưới là inventory đầu vào cho wireframe của Nova Foods Trading & Manufacturing, case study mô phỏng giáo dục; mọi giá trị Nova Foods là dữ liệu tổng hợp. Không có dòng nào xác nhận cấu hình ERP, quy tắc vận hành, baseline, approval hoặc quyền production.

Nhóm input	Giá trị dùng trong ví dụ	Artifact/ID canonical	Tên tệp hoặc URL nguồn	Phân loại nguồn	Trạng thái xác minh
Bối cảnh hệ thống	ERP Nova Foods mô phỏng; locale vi-VN; múi giờ Asia/Ho_Chi_Minh; tiền tệ VND	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Đã ghi nhận metadata; không phải cấu hình production
Trạng thái tài liệu	IN_REVIEW, v0.9.0, ngày 2026-08-07	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Đã ghi nhận metadata; không phải baseline hay approval
Mục tiêu màn hình	Wireframe phải mô tả bố cục, thao tác, trạng thái và UI rule trước khi phát triển	01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	Đủ cho mục tiêu học liệu; thiếu phạm vi màn hình nghiệp vụ cụ thể
Định danh cần giữ nguyên	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical identifier registry plan	Đang xem xét; chưa có danh sách ID màn hình hoặc trường dữ liệu được trích trong input này
Quy tắc nghiệp vụ tham chiếu	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical rule catalog plan	Đang xem xét; chưa có rule Nova Foods cụ thể để biến thành hành vi UI
Dữ liệu logic tham chiếu	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Canonical logical data dictionary plan	Đang xem xét; chưa có entity, field, format, mandatory flag cụ thể
Nguồn BA	BABOK Guide Version 3	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Primary professional source	Dùng thuật ngữ BA; không suy diễn trang, clause hoặc yêu cầu Nova Foods
Nguồn yêu cầu	ISO/IEC/IEEE 29148:2018 Edition 2	https://www.iso.org/standard/72089.html	Primary standards source	Chỉ dùng abstract và trạng thái thư mục; clause cần licensed-text verification
Nguồn accessibility	WCAG 2.2 Recommendation, edition 2024-12-12	https://www.w3.org/TR/WCAG22/	Normative accessibility source	Có thể kiểm tra claim theo success criterion; chưa có yêu cầu accessibility Nova Foods
Mẫu dữ liệu hiển thị	“Phiếu nhập kho mô phỏng”, ngày 2026-08-07, tổng tiền 1250000 VND	Không có ID canonical được cung cấp	Dữ liệu tổng hợp trong handbook	Synthetic example	Cần xác minh: tên chứng từ, field, trạng thái và giá trị không phải dữ liệu canonical
Vai trò người dùng	“Nhân viên kho mô phỏng”, “Kế toán mô phỏng”	Không có ID canonical được cung cấp	Dữ liệu tổng hợp trong handbook	Synthetic example	Cần xác minh: role catalog, quyền xem/sửa/xóa, segregation of duties
Luồng thao tác	Mở danh sách, xem chi tiết, nhập dữ liệu, lưu, báo lỗi	Không có artifact nguồn đủ chi tiết được cung cấp	Chưa có BPMN, user journey hoặc use case canonical	Missing required source artifact	Cần xác minh trước khi vẽ wireframe hành vi
Tích hợp/API	Không có endpoint, payload, lỗi API hoặc OpenAPI Nova Foods	OpenAPI Specification 3.1.1 chỉ là nguồn chuẩn	https://spec.openapis.org/oas/v3.1.1.html	Normative specification source	Cần xác minh: interface contract; không được tự tạo API từ wireframe
Pháp lý, kế toán, ATTP	Có nguồn luật và nghị định trong source seed	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Verified source map	Cần xác minh bởi Legal, Accounting, Compliance hoặc domain owner trước khi biến thành UI rule

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Artifact governance metadata đã ghi nhận] --> D[Inventory đầu vào wireframe]
    B[Catalog ID, rule, data đang xem xét; chưa có nội dung cụ thể đã xác minh] --> D
    C[Ví dụ Nova Foods tổng hợp; cần xác minh] --> D

    D --> E{Nguồn đủ cho phạm vi wireframe dự kiến?}
    L[Tiêu chí: screen, role và segregation of duties, data, rule, luồng thao tác, interface contract, yêu cầu accessibility Nova Foods<br/>WCAG 2.2 chỉ dùng để kiểm tra claim khi có yêu cầu] -. đánh giá .-> E

    E -- Đủ --> K[Soạn wireframe có traceability]
    E -- Đủ một phần --> J[Chỉ soạn phần đã đủ nguồn; đánh dấu phần còn lại cần xác minh]
    E -- Thiếu hoặc chưa xác minh --> F[Đánh dấu cần xác minh]

    J --> P[Phân loại mọi khoảng trống còn thiếu]
    F --> P
    P --> Q[Phân công các owner phù hợp song song]

    Q --> R[Screen, role, quyền hoặc segregation of duties, data, rule, luồng thao tác<br/>Giao domain/process owner xác minh]
    Q --> S[Interface contract, endpoint, payload hoặc lỗi API<br/>Giao system/interface owner xác minh]
    Q --> T[Claim pháp lý, kế toán, ATTP hoặc chuyên ngành<br/>Giao Legal, Accounting, Compliance hoặc domain owner xác minh]
    Q --> U[Yêu cầu accessibility Nova Foods<br/>Giao owner phù hợp xác minh; kiểm tra claim theo WCAG 2.2]

    R --> H[Tổng hợp kết quả xác minh]
    S --> H
    T --> H
    U --> H

    H --> V{Đánh giá lại toàn bộ phần còn thiếu}
    V -- Tất cả nguồn cần thiết đã hợp lệ và đủ --> K
    V -- Một phần đã hợp lệ và đủ --> J
    V -- Vẫn thiếu hoặc không xác minh được --> M[Không suy diễn hành vi UI]
    M --> N[Không tự tạo endpoint, payload hoặc lỗi API khi thiếu interface contract]

Applied

Facts: Nova Foods chỉ có metadata corpus, source map, registry plan, rule catalog plan và data dictionary plan. Ví dụ “Phiếu nhập kho mô phỏng” có giá trị tổng hợp 1250000 VND, không có ID chứng từ canonical.

Current Behavior: Chưa có BPMN, use case, role-permission matrix, field catalog hoặc interface contract Nova Foods được cung cấp cho màn hình nhập kho.

Underlying Need: Wireframe cần biết người dùng nào thao tác, dữ liệu nào hiển thị, quy tắc nào kiểm tra và trạng thái nào đổi sau thao tác. Không có các input này, hình màn hình chỉ là minh họa, không phải đặc tả có thể build.

Options: (1) Tự giả định field, role và rule; (2) vẽ wireframe minh họa, gắn nhãn synthetic và unresolved; (3) dừng toàn bộ nội dung.

Decision Criteria: Giữ traceability, không biến giả định thành requirement, vẫn giúp người mới thấy input còn thiếu.

Decision: Chọn phương án (2). Dùng giá trị tổng hợp rõ nhãn; giữ nguyên TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY; không tạo ID mới.

Authority: Principal IT Business Analyst / Technical Curriculum Author quản trị artifact. Business Owner, Architect, Security, Accounting, Legal, Compliance và domain owner giữ thẩm quyền xác minh phần thuộc chuyên môn.

Artifact: /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md, section 04-inputs, trạng thái IN_REVIEW, version v0.9.0.

Consequence if Wrong: Wireframe có thể gán nhầm quyền sửa dữ liệu, hiển thị field không tồn tại, bỏ rule bắt buộc, hoặc khiến learner nhầm dữ liệu mô phỏng với quyết định ERP thật.

Senior Lens

Một input không có ID canonical không được “sửa” bằng cách BA tự đặt mã. ID mới tạo ra quan hệ truy vết giả. Trong bảng này, khoảng trống được giữ dưới nhãn Cần xác minh vì bằng chứng hiện có chỉ chứng minh artifact plan tồn tại, không chứng minh nội dung nghiệp vụ bên trong đã sẵn sàng.

“Complete” nghĩa là đủ mọi loại input cần kiểm tra cho phạm vi wireframe hiện tại, gồm cả input chưa có. Không nghĩa là mọi input đã được xác minh. Dòng missing source artifact là bằng chứng quản trị: nó cho biết chính xác phần nào chưa thể chuyển thành hành vi UI.

Quick Reference

Nhìn thấy trong input table	Cách hiểu đúng
IN_REVIEW	Đang xem xét có kiểm soát; không phải approved hoặc baselined
Synthetic example	Chỉ minh họa học liệu; không phải dữ liệu Nova Foods thật
Cần xác minh	Chưa đủ bằng chứng để biến thành rule, field, role hoặc screen behavior
ID canonical	Phải giữ nguyên chuỗi và đường dẫn nguồn
Không có ID được cung cấp	Không tự tạo mã thay thế

5. Step-by-step BA Activities

Applied

Quy trình này biến input đã kiểm soát thành wireframe và quy tắc hành vi màn hình có thể review. Wireframe là bản phác bố cục và tương tác; không phải giao diện đã xây. Mọi ví dụ Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dùng dữ liệu tổng hợp, trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.

1. BA chuẩn bị phạm vi màn hình.
   Actor: BA. Action: Xác định mục tiêu người dùng, trigger, vai trò dự kiến, màn hình trước/sau và ranh giới không xử lý. Object: Screen scope note. Evidence produced: Bảng phạm vi liên kết /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md với CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY. Decision rule: Chỉ mô tả hành vi có nguồn canonical hoặc gắn nhãn Cần xác minh. Quality gate: Không có field, rule, quyền hay integration tự suy diễn. Escalation route: Thiếu rule sang Business Owner; thiếu data definition sang data owner; thiếu quyền sang Security; thiếu integration sang Architect.

2. BA phân tích hành trình thao tác.
   Actor: BA. Action: Mô tả người dùng bắt đầu ở đâu, nhập gì, hệ thống kiểm tra gì, thấy kết quả gì và kết thúc ở đâu. Object: User flow, tức luồng thao tác người dùng. Evidence produced: Sơ đồ Mermaid và danh sách trạng thái màn hình. Decision rule: Mỗi nhánh lỗi phải có điều kiện kích hoạt, thông báo, dữ liệu được giữ hoặc bị xóa, và hành động tiếp theo. Quality gate: Luồng có đường thành công, lỗi xác thực, lỗi phân quyền và hủy thao tác khi các điều kiện này thuộc phạm vi. Escalation route: Mâu thuẫn trạng thái sang Business Owner và Architect; tác động dữ liệu nhạy cảm sang Security hoặc Legal/Compliance owner.

3. BA dựng wireframe mức đủ review.
   Actor: BA. Action: Đặt vùng thông tin, field, nút, bảng kết quả, thông báo lỗi và trạng thái disabled. Object: Wireframe. Evidence produced: Bố cục màn hình có nhãn field, loại control và hành vi dự kiến. Decision rule: Field chỉ xuất hiện khi có bằng chứng data hoặc business need; field chưa xác minh ghi rõ Cần xác minh, không giả định kiểu dữ liệu. Quality gate: Mỗi control có mục đích, điều kiện hiển thị, điều kiện sửa và điều kiện lưu. Escalation route: Field không có định nghĩa sang data owner; hành vi thao tác bất thường sang Business Owner; rủi ro accessibility sang UX/UI reviewer.

4. BA ghi quy tắc hành vi và kiểm tra.
   Actor: BA. Action: Chuyển từng tương tác thành điều kiện trước, hành động, kết quả, lỗi và tiêu chí chấp nhận. Object: Screen behavior rule. Evidence produced: Bảng hành vi có liên kết nguồn. Decision rule: Quy tắc UI không thay đổi business rule; UI chỉ thể hiện hoặc ngăn thao tác theo rule đã có. Quality gate: Không dùng wireframe để quyết định ngầm giá trị mặc định, quyền phê duyệt, logic kế toán, thuế, pháp lý hoặc truy xuất thực phẩm. Escalation route: Logic nghiệp vụ sang Business Owner; accounting sang Accounting Owner; legal/privacy sang Legal/Compliance owner; security sang Security.

5. BA tự review truy vết và tính kiểm thử.
   Actor: BA. Action: Kiểm tra hai chiều từ mục tiêu màn hình đến field, rule, trạng thái và evidence nguồn. Object: Wireframe review checklist. Evidence produced: Danh sách pass, issue và điểm Cần xác minh. Decision rule: Một hành vi không có nguồn hoặc không thể kiểm thử phải bị loại khỏi bản sẵn sàng review. Quality gate: Mỗi button có outcome; mỗi validation có điều kiện; mỗi lỗi có cách phục hồi; mọi giả định được phân biệt với fact. Escalation route: Thiếu test basis sang QA reviewer; thiếu canonical source sang Principal IT Business Analyst / Technical Curriculum Author để ghi nhận gap, không tạo ID mới.

6. BA tổ chức review và handoff có kiểm soát.
   Actor: BA. Action: Gửi gói review, ghi nhận nhận xét theo nguồn và vai trò, cập nhật artifact được kiểm soát, rồi handoff cho consumer phù hợp. Object: Review package và controlled handoff, tức bàn giao chỉ dùng artifact có trạng thái, version và gap rõ ràng. Evidence produced: Bảng comment disposition, version reference và danh sách unresolved items. Decision rule: IN_REVIEW được handoff để review hoặc học tập; không được diễn giải là approval, baseline hay cho phép triển khai production. Quality gate: Handoff nêu rõ tệp, section, version, trạng thái, nguồn, giả định và escalation còn mở. Escalation route: Bất đồng không giải được gửi đúng authority; BA giữ traceability, không tự kết luận thay authority.

Applied

Core

Mỗi bước thiết kế wireframe phải tạo bằng chứng kiểm tra được. Actor là vai trò thực hiện; action là thao tác; object là màn hình, trường dữ liệu hoặc quy tắc UI chịu tác động; evidence produced là tệp, bảng hoặc ghi nhận chứng minh thao tác đã xảy ra. Decision rule là điều kiện chọn phương án. Quality gate là điểm chặn: không đạt thì không chuyển bước. Escalation route là tuyến chuyển vấn đề tới đúng thẩm quyền; BA không tự quyết thay Business Owner, Architect, Security, Legal, Accounting hoặc QA.

Applied

1. Actor: BA. Action: Thu thập và đối chiếu đầu vào. Object: requirement, business rule, data field, role và luồng liên quan màn hình. Evidence produced: danh sách tham chiếu trong /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md, liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY. Decision rule: chỉ dùng ID, tên trường và quy tắc đã có trong nguồn canonical; thiếu hoặc mâu thuẫn thì ghi là Verification required. Quality gate: từng thành phần UI có nguồn truy vết hoặc nhãn xác minh. Escalation route: mâu thuẫn rule tới Business Owner; mâu thuẫn dữ liệu tới Data Owner/Architect; dữ liệu cá nhân tới Legal Owner và Security.

2. Actor: BA. Action: Xác định mục tiêu màn hình và trạng thái người dùng. Object: mục tiêu tác vụ, vai trò truy cập, điểm vào và kết quả mong đợi. Evidence produced: bảng screen purpose gồm người dùng, hành động chính, dữ liệu cần xem/nhập và kết quả. Decision rule: một màn hình ưu tiên một tác vụ nghiệp vụ chính; tác vụ phụ chỉ giữ lại nếu trực tiếp hỗ trợ tác vụ chính. Quality gate: không có nút, trường hoặc vùng hiển thị không gắn với nhu cầu hay quy tắc nguồn. Escalation route: phạm vi tác vụ tăng ngoài requirement tới Business Owner và Principal IT Business Analyst / Technical Curriculum Author để ghi nhận tác động.

3. Actor: BA. Action: Phác cấu trúc wireframe. Object: vùng header, bộ lọc, bảng dữ liệu, biểu mẫu, nút hành động, thông báo lỗi và trạng thái rỗng. Evidence produced: wireframe gắn nhãn thành phần và hành vi dự kiến. Decision rule: dùng kiểm soát giao diện native trước; chỉ đề xuất thành phần tùy biến khi native không đáp ứng nhu cầu đã chứng minh. Quality gate: luồng bàn phím, nhãn trường, lỗi nhập và trạng thái không có dữ liệu được mô tả; không coi wireframe là xác nhận thiết kế production. Escalation route: rủi ro khả dụng hoặc khả năng tiếp cận tới UX/UI Designer và QA; yêu cầu WCAG cần đối chiếu nguồn W3C trước khi nêu tiêu chí cụ thể.

4. Actor: BA. Action: Gắn hành vi cho từng thành phần. Object: điều kiện hiển thị, bắt buộc nhập, định dạng, xác thực, quyền thao tác và phản hồi hệ thống. Evidence produced: bảng UI rule theo từng trường hoặc nút. Decision rule: hành vi nghiệp vụ phải tham chiếu rule canonical; kiểm tra định dạng thuộc UI, kiểm tra toàn vẹn phải còn ở backend hoặc DB nếu rủi ro dữ liệu tồn tại. Quality gate: mỗi lỗi có điều kiện kích hoạt, thông điệp, vị trí hiển thị và hành động phục hồi. Escalation route: quyền truy cập tới Security/Architect; quy tắc kế toán tới Accounting Owner; quy tắc pháp lý tới Legal Owner.

5. Actor: BA. Action: Rà soát với nhóm liên quan. Object: wireframe, UI rule, traceability và giả định. Evidence produced: review log ghi người xem, nhận xét, quyết định, nguồn chứng minh và mục còn Verification required. Decision rule: nhận xét chỉ đổi artifact khi có nguồn, owner có thẩm quyền hoặc tác động kỹ thuật được xác nhận; ý kiến không có bằng chứng giữ là câu hỏi mở. Quality gate: không có xung đột chưa định tuyến giữa wireframe, business rule và data dictionary. Escalation route: tranh chấp nghiệp vụ tới Business Owner; khả thi kỹ thuật tới Architect; khả năng kiểm thử tới QA.

6. Actor: BA. Action: Handoff có kiểm soát. Object: wireframe và bảng UI rule ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Evidence produced: gói tham chiếu tới tệp nguồn, review log và danh sách điểm cần xác minh. Decision rule: chỉ bàn giao nội dung có traceability; không gọi là baseline, approved, compliant hoặc production-ready. Quality gate: tên tệp, ID canonical, phân loại nguồn và trạng thái IN_REVIEW còn nguyên. Escalation route: thiếu đầu vào hoặc thay đổi ID tới Principal IT Business Analyst / Technical Curriculum Author; quyết định vận hành tới owner thẩm quyền tương ứng.

Thành phần Applied của Nova Foods mô phỏng	Nội dung kiểm soát
Facts	Nhân viên kho cần xem danh sách lô hàng tổng hợp; dữ liệu chỉ dùng cho Nova Foods Trading & Manufacturing mô phỏng.
Current Behavior	Chưa có bằng chứng nguồn xác nhận ERP thực tế, màn hình thực tế hoặc quy trình vận hành thực tế.
Underlying Need	Cần mô tả màn hình tra cứu để learner hiểu quan hệ giữa trường dữ liệu, quyền xem và hành vi UI.
Options	Hiển thị toàn bộ trường; hiển thị trường theo vai trò; dùng dữ liệu mẫu tối thiểu.
Decision Criteria	Traceability, tối thiểu hóa dữ liệu hiển thị, khả năng kiểm thử, không suy diễn quyền production.
Decision	Dùng dữ liệu tổng hợp tối thiểu, gắn từng trường với CANONICAL_DATA_DICTIONARY; quyền chi tiết giữ Verification required.
Authority	Business Owner quyết nhu cầu; Architect/Security xác nhận mô hình quyền; BA duy trì truy vết.
Artifact	Wireframe và UI rule trong /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md.
Consequence if Wrong	Hiển thị sai trường hoặc quyền có thể gây sai yêu cầu, sai test basis và rủi ro lộ dữ liệu khi triển khai thực tế.

Senior Lens

Bằng chứng không phải biên bản để “đủ hồ sơ”. Nó là cầu nối từ quyết định UI tới nguồn gốc: không có cầu nối, developer phải đoán; QA không có test basis; owner không biết ai quyết. Escalation đúng tuyến giữ BA ở vai trò phân tích, không biến giả định học liệu thành quyết định Nova Foods.

Quick Reference

Trường bắt buộc mỗi bước	Câu hỏi kiểm tra
Actor	Ai chịu trách nhiệm làm hoặc quyết?
Action và object	Làm gì với màn hình, trường hoặc rule nào?
Evidence produced	Tệp hay ghi nhận nào chứng minh kết quả?
Decision rule	Điều kiện nào chọn phương án?
Quality gate	Điều gì phải đúng trước khi chuyển bước?
Escalation route	Vướng nghiệp vụ, kỹ thuật, pháp lý hay bảo mật thì chuyển ai?

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Bảng thực thi nối hành vi màn hình với bằng chứng review. Wireframe không tự tạo quy tắc nghiệp vụ; nó biểu diễn nhu cầu đã truy vết về màn hình, dữ liệu, trạng thái và phản hồi người dùng.

Mục	Nội dung thực thi Nova Foods
Facts	Nhân viên Kho cần ghi nhận nhận hàng cho phiếu mua mô phỏng PO-NF-2026-0042; lô hàng có 12.500 kg nguyên liệu, giá trị tổng hợp 187.500.000 VND.
Current Behavior	Màn hình nhận hàng cho nhập số lượng bất kỳ, không báo khi số lượng vượt số lượng còn mở của đơn mua. Người dùng chỉ phát hiện sai sau khi lưu.
Underlying Need	Chặn dữ liệu không hợp lệ tại điểm nhập. Hiển thị rõ số lượng đơn mua, số lượng đã nhận, số lượng còn mở và lỗi theo từng dòng hàng.
Options	Phương án 1: chỉ kiểm tra sau khi lưu. Phương án 2: kiểm tra ngay khi người dùng rời trường số lượng và kiểm tra lại khi lưu.
Decision Criteria	Phải giảm lỗi nhập, không che giấu dữ liệu nguồn, có thông báo bằng tiếng Việt, hỗ trợ bàn phím, và không thay quy tắc trong CANONICAL_BUSINESS_RULES.
Decision	Chọn phương án 2. Wireframe hiển thị lỗi nội tuyến khi số lượng nhận lớn hơn số lượng còn mở; nút lưu vẫn kiểm tra lại phía máy chủ để tránh bỏ qua kiểm tra giao diện.
Authority	Business Owner xác nhận luồng kho; Architect xác nhận kiểm tra phía máy chủ; QA xác nhận test basis; Legal/Compliance Owner xác minh nếu dữ liệu lô hàng chứa dữ liệu cá nhân hoặc yêu cầu pháp lý. Không có xác nhận nào được ghi nhận trong batch này.
Artifact	Bản chú thích wireframe trong /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md, liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY. Status IN_REVIEW, Version v0.9.0, date 2026-08-07.
Consequence if Wrong	Nhập vượt số lượng mở có thể làm sai tồn kho mô phỏng, sai dữ liệu đối soát đơn mua, và tạo test case không phản ánh nhu cầu kho.

Bước thực thi	Vai trò	Đối tượng màn hình	Bằng chứng review	Quy tắc quyết định
1. Đọc ngữ cảnh	BA	Dòng đơn mua, số lượng còn mở, đơn vị tính	Ghi chú dữ liệu nguồn và trường hiển thị	Không vẽ trường mới nếu chưa xác định nguồn dữ liệu trong CANONICAL_DATA_DICTIONARY.
2. Đặt hành vi nhập	BA	Trường Số lượng nhận	Chú thích: kiểm tra khi rời trường	Giá trị phải lớn hơn 0; giá trị vượt số lượng còn mở tạo lỗi nội tuyến.
3. Đặt trạng thái nút	BA và UX Designer	Nút Lưu phiếu nhận	Ma trận trạng thái mặc định, lỗi, hợp lệ	Nút chỉ gửi khi mọi dòng bắt buộc hợp lệ; kiểm tra phía máy chủ vẫn bắt buộc.
4. Đặt phản hồi lỗi	BA và QA	Thông báo lỗi dòng hàng	Nội dung lỗi và điều kiện kích hoạt	Lỗi phải chỉ rõ dòng sai, giá trị cho phép, không chỉ dùng màu để truyền đạt trạng thái.
5. Review liên vai trò	BA, Business Owner, Architect, QA	Wireframe có chú thích	Comment có nguồn, quyết định, vai trò xử lý	Mâu thuẫn quy tắc chuyển tới Business Owner; mâu thuẫn dữ liệu/API chuyển Architect; thiếu testability chuyển QA.

Source mermaid — có thể chỉnh sửa

flowchart TB
    PO[Hiển thị dữ liệu đơn mua<br/>Số lượng đơn mua<br/>Số lượng đã nhận<br/>Số lượng còn mở] --> A[Người dùng nhập hoặc sửa<br/>Số lượng nhận]
    A --> B[Người dùng rời trường<br/>Số lượng nhận]
    B --> C{Giao diện kiểm tra:<br/>Số lượng nhận lớn hơn 0?}
    C -- Không --> D[Giao diện hiện lỗi nội tuyến:<br/>Số lượng phải lớn hơn 0]
    D --> A
    C -- Có --> E{Giao diện kiểm tra:<br/>Số lượng nhận không vượt<br/>số lượng còn mở?}
    PO --> E
    E -- Không --> F[Giao diện hiện lỗi nội tuyến:<br/>Vượt số lượng còn mở]
    F --> A
    E -- Có --> G[Giao diện đánh dấu dòng hợp lệ]
    G --> H{Giao diện kiểm tra:<br/>Mọi dòng bắt buộc hợp lệ?}
    H -- Không --> I[Giao diện vô hiệu hóa<br/>nút Lưu phiếu nhận]
    I --> A
    H -- Có --> J[Giao diện cho phép<br/>Lưu phiếu nhận]
    J --> K[Người dùng kích hoạt Lưu phiếu nhận<br/>bằng chuột hoặc bàn phím]
    K --> L[Giao diện gửi yêu cầu lưu]
    L --> M{Máy chủ kiểm tra lại:<br/>Dữ liệu hợp lệ?}
    M -- Không --> N[Giao diện hiện lỗi từ máy chủ<br/>theo dòng]
    N --> A
    M -- Có --> O[Máy chủ lưu phiếu nhận]
    O --> P[Giao diện hiển thị lưu thành công]

Core

Sơ đồ Mermaid mô tả luồng hành vi giao diện, không phải BPMN. Nó làm rõ điểm quyết định, lỗi và kiểm tra lại phía máy chủ. Bảng là bằng chứng để reviewer kiểm tra wireframe có phản ánh đúng nhu cầu, không phải bằng chứng phê duyệt hay baseline.

Senior Lens

Kiểm tra ở giao diện giảm lỗi sớm; kiểm tra phía máy chủ bảo vệ dữ liệu khi giao diện bị bỏ qua hoặc dữ liệu thay đổi đồng thời. Nếu số lượng còn mở được tính từ nhiều nguồn ERP, BA không tự chọn công thức; ghi nhận mâu thuẫn và chuyển Architect cùng Business Owner xử lý.

Quick Reference

Kiểm tra	Đạt khi
Truy vết	Mỗi hành vi có nguồn dữ liệu hoặc quy tắc canonical.
Testability	Mỗi nhánh sơ đồ có kết quả quan sát được.
Accessibility	Lỗi có văn bản, vị trí rõ, không chỉ biểu đạt bằng màu.
Governance	Artifact vẫn IN_REVIEW; không diễn giải thành approval hoặc baseline.

6. Output thu ???c

Core

Output của hoạt động wireframe gồm artifact mới hoặc artifact được cập nhật. Artifact là tài liệu có định danh, owner, trạng thái và lịch sử thay đổi để người review biết nội dung nào đang được xem xét. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp.

Artifact tạo/cập nhật	Canonical ID	Tệp kiểm soát	Owner	Status	Nội dung tối thiểu
Wireframe, hành vi màn hình, quy tắc UI	Chưa có ID artifact riêng được đăng ký trong nguồn đầu vào; dùng đường dẫn canonical làm định danh kiểm soát	/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Mục tiêu màn hình, thành phần giao diện, trạng thái hiển thị, hành vi nhập/lưu/lỗi, quy tắc UI, liên kết requirement hoặc rule nguồn
Registry định danh tham chiếu	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Quy tắc cấp và bảo toàn ID; không tự tạo ID có vẻ canonical khi registry chưa đăng ký
Catalog quy tắc tham chiếu	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Nguồn quy tắc nghiệp vụ; wireframe chỉ diễn đạt quy tắc, không thay thế catalog
Từ điển dữ liệu tham chiếu	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Định nghĩa dữ liệu logic; nhãn trường trên UI không tự tạo nghĩa dữ liệu mới

Không có standalone canonical ID cho artifact wireframe trong nguồn được cung cấp. Vì vậy, không được bịa ID như WF-001 rồi gọi là canonical. Bằng chứng là TRACEABILITY_ID_REGISTRY là nguồn quản trị ID, còn đầu vào chỉ xác nhận đường dẫn /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md. Khi registry đăng ký ID riêng, cập nhật metadata và lịch sử thay đổi cùng lần.

Mỗi thay đổi phải ghi lịch sử tối thiểu: version, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh, người ghi nhận, phần thay đổi, lý do, artifact nguồn bị ảnh hưởng và trạng thái sau thay đổi. Không sửa im lặng nội dung đã được review. IN_REVIEW chỉ nói artifact đang được xem xét; không có nghĩa approved, baselined, production-ready hoặc được người dùng chấp thuận.

Source mermaid — có thể chỉnh sửa

flowchart TB
    R["Artifact<br/>Trạng thái: IN_REVIEW"]
    C["Cập nhật nội dung đã được review"]
    O["Principal IT Business Analyst / Technical Curriculum Author<br/>Ghi nhận thay đổi; không sửa im lặng"]
    H["Lịch sử thay đổi bắt buộc<br/>version; ngày 2026-08-07; múi giờ Asia/Ho_Chi_Minh;<br/>người ghi nhận; phần thay đổi; lý do;<br/>artifact nguồn bị ảnh hưởng; trạng thái sau thay đổi"]
    B["Ranh giới trạng thái<br/>IN_REVIEW không đồng nghĩa approved, baselined,<br/>production-ready hoặc user-accepted"]

    R --> C
    C --> O
    O --> H
    H -->|"Giữ trạng thái sau cập nhật: IN_REVIEW"| R
    R -.->|"Giới hạn diễn giải"| B

Applied

Mục	Nova Foods mô phỏng
Facts	Màn hình ghi nhận nhận hàng cần mô tả ô số lượng nhận, lỗi theo dòng và hành vi gửi lưu.
Current Behavior	Nội dung hiện có mô tả luồng kiểm tra số lượng lớn hơn 0 và không vượt số lượng còn mở.
Underlying Need	QA, Developer và Business Reviewer cần cùng đọc một nguồn về hành vi giao diện thay vì suy đoán từ hình màn hình.
Options	Ghi hành vi trong wireframe; ghi rời trong email; chỉ dùng ảnh giao diện.
Decision Criteria	Có định danh kiểm soát, truy vết được thay đổi, giữ liên kết với quy tắc và không tạo nguồn chân lý thứ hai.
Decision	Cập nhật /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md; tham chiếu CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi có quy tắc hoặc trường dữ liệu liên quan.
Authority	Principal IT Business Analyst / Technical Curriculum Author quản trị artifact. Mâu thuẫn nghiệp vụ chuyển Business Owner; mâu thuẫn dữ liệu hoặc kỹ thuật chuyển Architect; thiếu khả năng kiểm thử chuyển QA.
Artifact	Wireframe, screen behavior và UI rules trong /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md, IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Developer có thể xây sai phản hồi lỗi; QA thiếu test basis; thay đổi không truy được nguồn; một giả định mô phỏng có thể bị hiểu nhầm thành quy tắc ERP thực.

Senior Lens

Owner chịu trách nhiệm giữ artifact nhất quán, không sở hữu quyền quyết định nghiệp vụ, pháp lý, kế toán, bảo mật hoặc production. Lý do: wireframe chuyển nhu cầu thành hành vi nhìn thấy được, nhưng không xác nhận quy tắc nguồn đúng cho vận hành thực. Nếu UI cần hiển thị dữ liệu cá nhân, hóa đơn, truy xuất thực phẩm hoặc giá trị VND, ghi nhãn Verification required khi chưa có kết luận từ owner chuyên môn phù hợp.

Quick Reference

Quy tắc	Cách áp dụng
Một nguồn kiểm soát	Dùng đúng đường dẫn canonical; bản xuất hoặc ảnh không thay artifact.
Không bịa canonical ID	Chờ đăng ký trong TRACEABILITY_ID_REGISTRY.
Giữ lịch sử thay đổi	Ghi version, ngày, người ghi nhận, lý do và ảnh hưởng.
Không nâng trạng thái	Giữ IN_REVIEW; không suy diễn approval hay baseline.

Core

Output anatomy là cấu trúc đầy đủ để người đọc biết artifact nào được tạo, artifact nào được cập nhật, nội dung nào thuộc mỗi artifact, và liên kết nào giữ được truy vết. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; artifact không mô tả cấu hình ERP thực hay quyết định vận hành thực.

Artifact ID	Tệp canonical	Loại output	Mục đích	Nội dung tối thiểu
14_WIREFRAMES_SCREEN_BEHAVIOR_UI_RULES	/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md	Handbook chapter	Giải thích wireframe, hành vi màn hình, UI rule	Metadata; màn hình; trường dữ liệu; trạng thái; hành vi; rule; liên kết traceability
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Rule catalog	Nguồn tham chiếu cho rule nghiệp vụ	Rule ID; điều kiện; kết quả; owner thẩm quyền; trạng thái xác minh
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Logical data dictionary	Nguồn tham chiếu cho field logic	Data element ID; tên; kiểu; bắt buộc; mô tả; phân loại dữ liệu
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID registry	Kiểm soát ID và liên kết	ID; loại; artifact nguồn; artifact dùng; trạng thái

Một wireframe không phải ảnh trang trí. Wireframe cho biết bố cục và thành phần giao diện. Screen behavior, tức hành vi màn hình, cho biết hệ thống phản ứng khi người dùng xem, nhập, lưu, lỗi hoặc đổi trạng thái. UI rule, tức quy tắc giao diện, ràng buộc cách hiển thị và thao tác để UI không tự tạo logic khác business rule.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Business rule<br/>CANONICAL_BUSINESS_RULES] --> B[Screen behavior]
    A --> E[UI rule]
    C[Data element<br/>CANONICAL_DATA_DICTIONARY] --> D[Field specification]
    B --> F[Wireframe]
    D --> F
    E --> F

    A --> G[Traceability record<br/>TRACEABILITY_ID_REGISTRY]
    C --> G
    B --> G
    D --> G
    E --> G
    F --> G

Applied

Nova Foods mô phỏng: màn hình tạo phiếu yêu cầu mua hàng.

Thành phần	Nội dung đã điền
Facts	Nhân viên mua hàng cần nhập yêu cầu mua nguyên liệu tổng hợp cho kho WH-HCM-01. Giá trị yêu cầu là 12.500.000 VND.
Current Behavior	Chưa có mô tả thống nhất về trường bắt buộc, nút thao tác, lỗi nhập liệu và trạng thái sau khi lưu.
Underlying Need	Người dùng cần tạo yêu cầu đủ dữ liệu để bước review sau đó hiểu mặt hàng, số lượng, kho nhận và lý do mua.
Options	1. Một form tự do chỉ có ghi chú. 2. Form có trường cấu trúc, kiểm tra bắt buộc và trạng thái draft.
Decision Criteria	Giữ dữ liệu có cấu trúc; hỗ trợ kiểm tra lỗi sớm; không suy diễn rule kế toán, thuế hoặc phê duyệt.
Decision	Dùng form cấu trúc với trạng thái Draft; nút Submit for Review chỉ hiển thị hành vi dự kiến trong học liệu.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact. Business Owner, Accounting Owner và các owner chuyên môn chưa xác nhận quy tắc vận hành.
Artifact	Bản ghi wireframe nằm trong 14_WIREFRAMES_SCREEN_BEHAVIOR_UI_RULES; tham chiếu catalog CANONICAL_BUSINESS_RULES, dictionary CANONICAL_DATA_DICTIONARY, registry TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Thiếu trường kho nhận hoặc số lượng làm downstream reviewer phải suy đoán; suy đoán phá traceability và có thể tạo yêu cầu mua sai trong mô hình học tập.

Screen ID	Vùng UI	Thành phần	Nhãn vi-VN	Data element tham chiếu	Bắt buộc	Hành vi đầy đủ
SCR-PR-001	Header	Text input	Mã yêu cầu mua	PurchaseRequestCode	Có	Hệ thống hiển thị mã mô phỏng PR-HCM-20260807-001; người dùng không sửa mã.
SCR-PR-001	Header	Date picker	Ngày yêu cầu	RequestDate	Có	Giá trị khởi tạo 2026-08-07; người dùng chọn ngày hợp lệ.
SCR-PR-001	Thông tin nhận hàng	Select	Kho nhận	ReceivingWarehouseCode	Có	Danh sách mô phỏng có WH-HCM-01; chưa chọn thì hiển thị lỗi khi gửi review.
SCR-PR-001	Dòng hàng	Text input	Mã nguyên liệu	MaterialCode	Có	Nhập RM-SUGAR-001; giá trị là dữ liệu tổng hợp.
SCR-PR-001	Dòng hàng	Number input	Số lượng	RequestedQuantity	Có	Chấp nhận số lớn hơn 0; nhập 0, số âm hoặc rỗng thì báo lỗi tại trường.
SCR-PR-001	Dòng hàng	Select	Đơn vị tính	RequestedUoM	Có	Chọn KG; không tự quy đổi đơn vị.
SCR-PR-001	Dòng hàng	Currency input	Giá trị dự kiến	EstimatedAmountVND	Có	Hiển thị 12.500.000 VND; chỉ dùng locale vi-VN và tiền tệ mô phỏng VND.
SCR-PR-001	Lý do	Text area	Lý do mua	PurchaseRequestReason	Có	Nhập Bổ sung nguyên liệu cho kế hoạch sản xuất mô phỏng; giới hạn giao diện 500 ký tự.
SCR-PR-001	Footer	Button	Lưu nháp	Không áp dụng	Không	Lưu trạng thái Draft; không gửi review.
SCR-PR-001	Footer	Button	Gửi xem xét	Không áp dụng	Không	Kiểm tra mọi trường bắt buộc; nếu hợp lệ, chuyển trạng thái mô phỏng từ Draft sang IN_REVIEW.
SCR-PR-001	Footer	Inline error	Vui lòng nhập số lượng lớn hơn 0	Không áp dụng	Không	Hiển thị cạnh RequestedQuantity; focus quay về trường lỗi.

Senior Lens

Cầu nối suy luận: ReceivingWarehouseCode và RequestedQuantity cần bắt buộc vì reviewer không thể xác định nơi nhận hoặc quy mô nhu cầu nếu hai giá trị rỗng. Đây là suy luận từ chức năng của phiếu yêu cầu mua, không phải khẳng định rule Nova Foods đã được phê duyệt. EstimatedAmountVND chỉ là giá trị dự kiến tổng hợp; không được gọi là giá, thuế, bút toán hoặc chứng từ kế toán.

Không ghi rule vào wireframe nếu rule chưa có nguồn canonical. Wireframe chỉ tham chiếu CANONICAL_BUSINESS_RULES; data field chỉ tham chiếu CANONICAL_DATA_DICTIONARY; liên kết ID được ghi vào TRACEABILITY_ID_REGISTRY. Cách tách này ngăn một ảnh màn hình trở thành nguồn chân lý sai.

Quick Reference

Kiểm tra anatomy	Đạt khi
Màn hình có ID	Mỗi màn hình dùng một Screen ID ổn định trong artifact.
Field có nghĩa rõ	Có nhãn, data element, kiểu control, bắt buộc và hành vi lỗi.
Nút không mơ hồ	Mỗi nút nêu kết quả thao tác và trạng thái tác động.
Dữ liệu mô phỏng rõ	Mã, tiền, kho, nguyên liệu được ghi là dữ liệu tổng hợp Nova Foods.
Traceability rõ	Rule, data và ID registry được tham chiếu bằng đúng canonical ID và filename.

Core

Quality gate là cổng kiểm tra chất lượng trước downstream review, tức review bởi vai trò nhận đầu ra ở bước kế tiếp. Gate không phê duyệt nội dung, không tạo baseline, không xác nhận sẵn sàng production. Với /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md, mọi đầu ra chỉ được gắn nhãn Ready for downstream review khi đủ toàn bộ điều kiện dưới đây.

Điều kiện gate	Bằng chứng bắt buộc	Lý do
Nhận diện kiểm soát đủ	Giữ đúng đường dẫn, Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND	Reviewer phải biết đúng artifact và ngữ cảnh đang xem xét.
Traceability đầy đủ	Mỗi màn hình, hành vi, quy tắc UI liên kết đến nguồn đầu vào canonical hoặc ghi rõ Verification required	Wireframe không được tự biến giả định thành yêu cầu.
Hành vi kiểm tra được	Trigger, điều kiện, phản hồi UI, lỗi, trạng thái rỗng, quyền truy cập và dữ liệu hiển thị mô tả rõ	QA, UX và kỹ thuật cần diễn giải cùng một hành vi.
Không mâu thuẫn	Không mâu thuẫn CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY khi các artifact này được tham chiếu	Một màn hình đúng hình thức nhưng trái rule hoặc data definition vẫn không đủ cho review.
Boundary được giữ	Nova Foods là mô phỏng giáo dục; dữ liệu tổng hợp; nội dung pháp lý, kế toán, thuế, an toàn thực phẩm chưa xác minh ghi Verification required hoặc project assumption	BA không thay Legal Owner, Accounting Owner, Security hoặc Business Owner kết luận chuyên môn.
Lịch sử thay đổi đủ	Có dòng change history: ngày, người ghi nhận, phần đổi, lý do, artifact/nguồn bị ảnh hưởng	Reviewer phải phân biệt nội dung mới với nội dung bị thay đổi im lặng.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Draft output] --> B{Control metadata đủ?<br/>/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md<br/>Status: IN_REVIEW; Version: v0.9.0<br/>2026-08-07; Asia/Ho_Chi_Minh; vi-VN; VND}
    B -- Không --> H[Không gắn nhãn<br/>Ready for downstream review]
    B -- Có --> C{Mỗi màn hình, hành vi, quy tắc UI<br/>liên kết nguồn canonical hoặc ghi<br/>Verification required?}
    C -- Không --> H
    C -- Có --> D{Behavior mô tả đủ?<br/>Trigger; điều kiện; phản hồi UI; lỗi<br/>trạng thái rỗng; quyền truy cập;<br/>dữ liệu hiển thị}
    D -- Không --> H
    D -- Có --> E{Không mâu thuẫn<br/>CANONICAL_BUSINESS_RULES;<br/>CANONICAL_DATA_DICTIONARY;<br/>TRACEABILITY_ID_REGISTRY?}
    E -- Không --> H
    E -- Có --> F{Boundary được giữ?<br/>Nova Foods là mô phỏng giáo dục;<br/>dữ liệu tổng hợp; nội dung chuyên môn<br/>chưa xác minh ghi Verification required<br/>hoặc project assumption}
    F -- Không --> H
    F -- Có --> G{Change history đủ?<br/>Ngày; người ghi nhận; phần đổi;<br/>lý do; artifact/nguồn bị ảnh hưởng}
    G -- Không --> H
    G -- Có --> I[Ready for downstream review]
    I --> J[Chỉ cho downstream review<br/>Không phê duyệt nội dung;<br/>không tạo baseline;<br/>không xác nhận sẵn sàng production]
    J --> K[IN_REVIEW giữ nguyên]
    H --> L[Return for correction]
    L --> A

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng; chỉ dùng dữ liệu tổng hợp. Artifact đang xét là /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md, IN_REVIEW, v0.9.0, ngày 2026-08-07.

Current Behavior: bản nháp mô tả nút “Lưu” nhưng không nêu dữ liệu nào bắt buộc, lỗi hiển thị ở đâu, hoặc liên kết đến nguồn rule/data. Downstream reviewer không thể quyết định hành vi có kiểm tra được hay không.

Underlying Need: biến mô tả UI thành đầu vào review có thể đối chiếu, không biến review thành phê duyệt.

Options: (1) chuyển ngay vì có wireframe; (2) đợi đủ toàn bộ quyết định vận hành; (3) áp quality gate dựa trên bằng chứng hiện có và gắn nhãn điểm chưa xác minh.

Decision Criteria: reviewer phải xác định được phạm vi, nguồn của từng quyết định, hành vi dự kiến, điểm chưa xác minh và thay đổi kể từ lần ghi nhận trước.

Decision: chọn phương án 3. Màn hình chỉ sẵn sàng review khi trường bắt buộc, phản hồi lỗi, trạng thái lưu và nguồn tham chiếu được ghi; nội dung chưa có nguồn canonical phải là Verification required.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và quality gate. Business Owner, Architect, QA, Legal Owner, Accounting Owner hoặc Security giữ thẩm quyền kết luận thuộc phạm vi của họ.

Artifact: /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md tham chiếu TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi áp dụng.

Consequence if Wrong: nếu gắn Ready for downstream review khi thiếu hành vi lỗi hoặc traceability, QA có thể tạo test basis sai; kỹ thuật có thể suy diễn rule; reviewer có thể nhầm nội dung mô phỏng là quyết định ERP thực tế.

Senior Lens

Gate tốt kiểm tra khả năng review, không kiểm tra đúng tuyệt đối. Hai khái niệm khác nhau: “đủ để reviewer đặt câu hỏi đúng” không đồng nghĩa “đã được người có thẩm quyền chấp thuận”. Vì corpus ở IN_REVIEW, không dùng các nhãn APPROVED, BASELINED, compliant, production-ready hoặc user-approved.

Nếu nguồn canonical mâu thuẫn, thiếu ID, hoặc yêu cầu UI đụng quyết định pháp lý, kế toán, bảo mật hay kiến trúc, gate phải trả về correction hoặc escalation. Không được lấp khoảng trống bằng rule Nova Foods tự tạo.

Quick Reference

Kết quả gate	Điều kiện	Nhãn được dùng
Pass	Đủ metadata, traceability, behavior, boundary, change history	Ready for downstream review
Return	Thiếu bất kỳ bằng chứng gate nào	IN_REVIEW
Escalate	Mâu thuẫn nguồn hoặc vượt thẩm quyền BA	IN_REVIEW và ghi Verification required
Không được suy diễn	Pass gate	Không phải approval, baseline hoặc production readiness

7. Who consumes those outputs?

Core

Output của wireframe gồm: bố cục màn hình, hành vi người dùng, trạng thái lỗi, quy tắc hiển thị, quyền truy cập dự kiến, liên kết TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi áp dụng. Người nhận không dùng cùng một output theo cùng mục đích. Developer biến hành vi thành phần mềm; QA biến hành vi thành test basis; Architect kiểm tra ranh giới kỹ thuật; PM/Product Owner điều phối phạm vi; Business Owner kiểm tra ý nghĩa nghiệp vụ; Operations kiểm tra khả năng vận hành; specialist owner kiểm tra phần thuộc thẩm quyền chuyên môn.

Source mermaid — có thể chỉnh sửa

flowchart TB
    W[Wireframe và UI rules<br/>IN_REVIEW]

    W --> L[Bố cục màn hình]
    W --> H[Hành vi người dùng]
    W --> E[Trạng thái lỗi]
    W --> R[Quy tắc hiển thị]
    W --> A[Quyền truy cập dự kiến]

    W --> D[Developer<br/>Biến hành vi thành phần mềm]
    W --> Q[QA<br/>Biến hành vi thành test basis]
    W --> AR[Architect<br/>Kiểm tra ranh giới kỹ thuật]
    W --> P[PM/Product Owner<br/>Điều phối phạm vi]
    W --> B[Business Owner<br/>Kiểm tra ý nghĩa nghiệp vụ]
    W --> O[Operations<br/>Kiểm tra khả năng vận hành]
    W --> S[Specialist owners<br/>Kiểm tra phần thuộc thẩm quyền]

    W -. khi áp dụng .-> T[TRACEABILITY_ID_REGISTRY]
    W -. khi áp dụng .-> BR[CANONICAL_BUSINESS_RULES]
    W -. khi áp dụng .-> C[CANONICAL_DATA_DICTIONARY]

Applied

Facts: Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp. Artifact /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md ở IN_REVIEW, version v0.9.0, ngày 2026-08-07.

Current Behavior: Wireframe mô tả người dùng nhập dữ liệu, hệ thống kiểm tra dữ liệu đầu vào, hiển thị lỗi và chặn thao tác không hợp lệ. Wireframe không tự xác nhận rule nghiệp vụ, quyền production, nghĩa vụ pháp lý hoặc cấu hình ERP thực tế.

Underlying Need: Mỗi vai trò cần đọc cùng artifact nhưng phải biết phần nào là đầu vào hành động của mình. Bằng chứng là một lỗi UI có thể là lỗi hiển thị cho Developer, test condition cho QA, rủi ro tích hợp cho Architect hoặc câu hỏi nghiệp vụ cho Business Owner.

Consumer	Output họ tiêu thụ	Cách dùng trong phạm vi vai trò
Developers	Bố cục, field, trạng thái, validation, thông báo lỗi, traceability	Chuyển hành vi màn hình thành UI và xử lý client/server; liên kết implementation với rule hoặc data element đã được tham chiếu.
QA	Luồng thao tác, điều kiện hiển thị, lỗi, trạng thái disabled, message	Lập test basis, test condition và expected result; kiểm tra hành vi quan sát được thay vì suy diễn logic ẩn.
Architect	Luồng màn hình, dữ liệu vào/ra, điểm tích hợp, ranh giới quyền	Kiểm tra UI có đòi hỏi API, đồng bộ dữ liệu, xác thực, phân quyền hoặc kiến trúc không được mô tả hay không.
PM/Product Owner	Phạm vi màn hình, ưu tiên, dependency, điểm chưa rõ	Điều phối thứ tự review và phạm vi delivery; không thay Business Owner xác nhận rule nghiệp vụ.
Business Owner	Nhãn nghiệp vụ, hành vi người dùng, ngoại lệ vận hành, kết quả mong đợi	Đối chiếu wireframe với mục tiêu nghiệp vụ mô phỏng; xác định chỗ BA không được tự suy diễn.
Operations	Hành vi khi lỗi, thông tin hỗ trợ người dùng, khả năng tra cứu, tác động vận hành	Đánh giá thao tác có thể vận hành, hỗ trợ và xử lý sự cố; không tự xác nhận cấu hình production.
Specialist owners	Phần chuyên môn: pháp lý, kế toán, bảo mật, accessibility, an toàn thực phẩm khi áp dụng	Kiểm tra claim thuộc thẩm quyền chuyên môn. Ví dụ, Security xem quyền và dữ liệu nhạy cảm; Accounting xem cách hiểu nghiệp vụ kế toán.

Options: Có thể giao một wireframe cho một vai trò duy nhất, hoặc phân phối cùng artifact theo ma trận consumer. Phương án một vai trò làm mất góc nhìn test, kiến trúc và vận hành. Phương án ma trận giữ một nguồn đọc chung, nhưng không chuyển thẩm quyền chuyên môn sang BA.

Decision Criteria: Chọn consumer theo loại câu hỏi mà output trả lời: “xây thế nào” thuộc Developer; “test gì” thuộc QA; “có phù hợp ranh giới kỹ thuật không” thuộc Architect; “có đúng mục tiêu nghiệp vụ không” thuộc Business Owner; “có vận hành được không” thuộc Operations; “có thuộc phạm vi chuyên môn được kiểm soát không” thuộc specialist owner.

Decision: Dùng cùng wireframe như input review đa vai trò; mỗi vai trò chỉ kết luận trong thẩm quyền của mình. Mọi nội dung còn IN_REVIEW.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì artifact, traceability và gói câu hỏi. Vai trò chuyên môn giữ thẩm quyền kết luận chuyên môn. Không có approval hoặc baseline được suy ra từ việc nhận artifact.

Artifact: /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md; tham chiếu TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi wireframe dùng ID, rule hoặc data element tương ứng.

Consequence if Wrong: Nếu Developer đọc wireframe như quyết định kiến trúc, có thể tạo API hoặc quyền truy cập chưa được xem xét. Nếu QA đọc nhãn màn hình như rule hoàn chỉnh, test có thể bỏ sót ngoại lệ. Nếu Business Owner bị bỏ khỏi luồng đọc, UI có thể đúng kỹ thuật nhưng sai mục tiêu nghiệp vụ mô phỏng.

Senior Lens

Handoff tốt không phải “gửi file”. Handoff tốt là chỉ rõ consumer nào dùng phần nào của output và giới hạn kết luận của họ. Wireframe là bằng chứng hành vi dự kiến tại giao diện; không phải hợp đồng API, không phải catalog rule đầy đủ, không phải quyết định pháp lý hay kế toán.

Specialist owner chỉ được đưa vào khi wireframe chạm phạm vi chuyên môn. Ví dụ: màn hình hiển thị dữ liệu cá nhân cần Security và Legal Owner; màn hình tác động ghi nhận kế toán cần Accounting Owner; màn hình truy xuất lô hàng cần domain owner về an toàn thực phẩm và truy xuất. Các nội dung này vẫn là mô phỏng và cần Verification required nếu chưa đối chiếu nguồn hoặc thẩm quyền phù hợp.

Quick Reference

Output	Consumer chính	Consumer phụ	Mục đích dùng
Layout, field, control	Developers	QA, accessibility specialist	Build và kiểm tra khả năng thao tác
User flow, state, error message	QA	Developers, Operations	Test basis và hỗ trợ vận hành
Data hiển thị, nhập, xuất	Architect	Developers, Security, specialist owners	Kiểm tra boundary dữ liệu và tích hợp
Business label, outcome, exception	Business Owner	PM/Product Owner, Operations	Kiểm tra ý nghĩa nghiệp vụ
Scope, dependency, review state	PM/Product Owner	Tất cả consumer	Điều phối review, không tạo approval
Quyền, dữ liệu nhạy cảm, claim chuyên môn	Specialist owners	Architect, QA	Review thuộc thẩm quyền chuyên môn

Core

Đầu ra wireframe, hành vi màn hình, quy tắc UI là bằng chứng để từng vai trò quyết định trong phạm vi thẩm quyền, không phải lệnh tự động cho build hay production. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu là tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Người nhận	Có thể quyết định	Bằng chứng phải có	Phải escalation khi
Developer	Cách hiện thực UI, kiểm tra client/server, xử lý lỗi kỹ thuật	Wireframe có trạng thái, rule ID, trường dữ liệu, acceptance criteria, tham chiếu CANONICAL_DATA_DICTIONARY	Rule mơ hồ; UI xung đột API, quyền hoặc dữ liệu canonical
QA	Test basis, ca kiểm thử black-box, dữ liệu test tổng hợp, tiêu chí pass/fail	Hành vi kỳ vọng, trạng thái lỗi, validation, traceability requirement-rule-test	Không xác định được expected result; rule không kiểm thử được; lỗi có nguy cơ mất dữ liệu
Architect	Ranh giới client/server, tích hợp, phân quyền, hiệu năng, security pattern	Luồng dữ liệu, dependency API, vai trò, loại dữ liệu, rủi ro	Thay đổi ảnh hưởng kiến trúc, API contract, dữ liệu nhạy cảm hoặc quyền truy cập
PM/Product Owner	Thứ tự ưu tiên, phạm vi release, trade-off thời gian và giá trị	Mục tiêu nghiệp vụ, tác động người dùng, dependency, effort estimate	Quyết định làm đổi business rule, KPI, deadline cam kết hoặc phạm vi đã kiểm soát
Business Owner	Ý nghĩa nghiệp vụ, ngoại lệ vận hành, mức chấp nhận kết quả	Rule diễn đạt nghiệp vụ, ví dụ dữ liệu tổng hợp, hậu quả sai	Rule chạm giá, chiết khấu, phê duyệt, doanh thu, tồn kho hoặc chính sách doanh nghiệp
Operations owner	Tính khả dụng thao tác, bàn giao, xử lý sự cố, quyền vận hành	Luồng thao tác, trạng thái lỗi, audit trail dự kiến, vai trò người dùng	Quy trình gây chặn vận hành, không có bước khôi phục hoặc thay đổi trách nhiệm ca trực
Specialist owner: Accounting, Legal, Security, Food Safety	Diễn giải chuyên môn thuộc lĩnh vực	Nguồn chính thức, dữ liệu bị ảnh hưởng, giả định dự án, traceability	Có hàm ý pháp lý, kế toán, bảo vệ dữ liệu, truy xuất hoặc thu hồi thực phẩm

Quy tắc bằng chứng: wireframe chỉ chứng minh bố cục và tương tác dự kiến; không chứng minh API tồn tại, quyền hợp lệ, tính tuân thủ hay phê duyệt. Khi một quyết định thuộc từ hai vai trò trở lên, BA lập gói escalation gồm ID yêu cầu, rule liên quan, ảnh màn hình, dữ liệu tổng hợp, phương án và tác động; không tự chọn thay người có thẩm quyền.

Source mermaid — có thể chỉnh sửa

flowchart TB
    W[Wireframe, hành vi màn hình và quy tắc UI<br/>IN_REVIEW v0.9.0]

    L[Giới hạn bằng chứng<br/>Không chứng minh API tồn tại, quyền hợp lệ,<br/>tuân thủ hoặc phê duyệt]
    W -.-> L

    W --> T{Quyết định thuộc<br/>từ 2 vai trò trở lên?}
    T -- Có --> X[BA lập escalation package<br/>ID yêu cầu, rule, ảnh màn hình, dữ liệu tổng hợp,<br/>phương án và tác động<br/>BA không tự quyết thay owner có thẩm quyền]
    X --> E[Escalation tới owner có thẩm quyền]

    T -- Không --> G{Vai trò có thẩm quyền}

    G --> D[Developer<br/>Cách hiện thực UI]
    G --> Q[QA<br/>Test basis và pass/fail]
    G --> A[Architect<br/>Ranh giới, tích hợp và security pattern]
    G --> P[PM/Product Owner<br/>Priority, scope và trade-off]
    G --> B[Business Owner<br/>Ý nghĩa và ngoại lệ nghiệp vụ]
    G --> O[Operations owner<br/>Khả dụng và vận hành]
    G --> S[Specialist owner<br/>Accounting, Legal, Security, Food Safety]

    D --> CD{Rule mơ hồ;<br/>UI xung đột API, quyền<br/>hoặc dữ liệu canonical?}
    Q --> CQ{Không xác định expected result;<br/>rule không kiểm thử được;<br/>nguy cơ mất dữ liệu?}
    A --> CA{Đổi kiến trúc hoặc API contract;<br/>ảnh hưởng dữ liệu nhạy cảm<br/>hoặc quyền truy cập?}
    P --> CP{Đổi business rule, KPI,<br/>deadline cam kết<br/>hoặc phạm vi đã kiểm soát?}
    B --> CB{Chạm giá, chiết khấu, phê duyệt,<br/>doanh thu, tồn kho<br/>hoặc chính sách doanh nghiệp?}
    O --> CO{Chặn vận hành;<br/>thiếu bước khôi phục;<br/>đổi trách nhiệm ca trực?}
    S --> CS{Có hàm ý pháp lý, kế toán,<br/>bảo vệ dữ liệu, truy xuất<br/>hoặc thu hồi thực phẩm?}

    CD -- Có --> E
    CQ -- Có --> E
    CA -- Có --> E
    CP -- Có --> E
    CB -- Có --> E
    CO -- Có --> E
    CS -- Có --> E

    CD -- Không --> R[Quyết định trong phạm vi vai trò]
    CQ -- Không --> R
    CA -- Không --> R
    CP -- Không --> R
    CB -- Không --> R
    CO -- Không --> R
    CS -- Không --> R

Applied

Facts: Màn hình mô phỏng “Tạo phiếu xuất kho” hiển thị nút Xác nhận xuất. Wireframe quy định nút bị khóa khi chưa nhập Kho xuất và Lý do xuất. Dữ liệu ví dụ là tổng hợp, giá trị hàng hóa hiển thị bằng VND.

Current Behavior: Wireframe mô tả nút khóa ở trình duyệt. Chưa có bằng chứng rằng API từ chối yêu cầu thiếu trường, chưa xác định quyền xác nhận xuất kho.

Underlying Need: Ngăn người dùng tạo giao dịch thiếu dữ liệu bắt buộc, đồng thời không cho UI trở thành điểm kiểm soát duy nhất.

Options:
1. Chỉ kiểm tra trên UI.
2. Kiểm tra trên UI và API.
3. Để API tự suy luận Kho xuất mặc định.

Decision Criteria: Phải ngăn dữ liệu thiếu tại trust boundary, giữ kết quả nhất quán khi gọi API ngoài UI, và không tự tạo quy tắc kho mặc định chưa được xác nhận.

Decision: Developer và QA được quyết định kiểm tra bắt buộc tại UI và API nếu API contract đã có trường tương ứng. Không được chọn kho mặc định.

Authority: Business Owner quyết định Lý do xuất có bắt buộc theo nghiệp vụ. Architect quyết định API validation và authorization. Operations owner xác nhận thao tác kho thực tế. Nếu lý do xuất liên quan hạch toán, Accounting Owner phải xác nhận; nếu liên quan truy xuất thực phẩm, Food Safety owner và Legal Owner phải xác nhận.

Artifact: Ghi liên kết wireframe tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; giữ nhãn Verification required cho quyền xác nhận và tác động chuyên môn chưa có nguồn xác nhận.

Consequence if Wrong: Chỉ khóa UI cho phép API tạo phiếu thiếu dữ liệu. Tự suy luận kho có thể làm sai tồn kho mô phỏng, sai luồng vận hành và làm QA test nhầm expected result.

Senior Lens

Escalation không phải chuyển mọi câu hỏi lên cấp cao. Escalate khi câu trả lời làm đổi rule, ownership, dữ liệu canonical, API contract, quyền, rủi ro bảo mật, nghĩa vụ pháp lý hoặc vận hành. Developer không quyết định ý nghĩa nghiệp vụ; Business Owner không quyết định cơ chế authorization; QA không tự viết expected result thay rule còn thiếu. Bằng chứng thiếu phải được ghi là thiếu, không được lấp bằng suy đoán.

Quick Reference

Tình huống	Câu hỏi làm rõ chính xác	Nơi escalation
Nút UI bị khóa nhưng API chưa rõ validation	API có từ chối yêu cầu khi thiếu Kho xuất hoặc Lý do xuất không? Mã lỗi và HTTP status nào được trả về?	Architect, Developer, QA
Rule nói “người có quyền”	Vai trò nào được xác nhận xuất kho, và nguồn canonical nào định nghĩa quyền này?	Business Owner, Architect, Operations owner
Trường có ảnh hưởng hạch toán	Lý do xuất có quyết định tài khoản, chứng từ hoặc thời điểm ghi nhận không?	Accounting Owner
Dữ liệu có thể phục vụ truy xuất	Phiếu xuất kho có phải giữ liên kết lô hàng cho mục đích truy xuất hay thu hồi không?	Food Safety owner, Legal Owner
Wireframe khác data dictionary	Tên trường, kiểu dữ liệu và bắt buộc nhập nào là canonical: wireframe hay CANONICAL_DATA_DICTIONARY?	Principal IT Business Analyst / Technical Curriculum Author, owner dữ liệu

Core

Bàn giao wireframe thất bại khi người nhận biến hình vẽ thành quyết định chưa được ghi rõ. Wireframe mô tả bố cục, trạng thái màn hình và hành vi dự kiến; không tự xác nhận quy tắc nghiệp vụ, quyền truy cập, dữ liệu nguồn hay điều kiện tích hợp. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp.

Source mermaid — có thể chỉnh sửa

flowchart TB
    W[Wireframe] --> Q{Có điểm chưa rõ?}
    Q -->|Không| C[Tiếp nhận đúng phạm vi wireframe]
    Q -->|Có| R[Đặt câu hỏi làm rõ]
    R --> E[Đối chiếu nguồn đã được phê duyệt hoặc ghi nhận]
    E --> X{Xung đột hoặc vượt thẩm quyền?}
    X -->|Không| C
    X -->|Có| S[Chuyển cấp kèm bằng chứng]
    S --> D[Chờ người có thẩm quyền quyết định]
    C --> B[Không suy diễn thành quy tắc nghiệp vụ, quyền truy cập, dữ liệu nguồn hoặc điều kiện tích hợp]

Applied

Mục	Nội dung
Facts	Wireframe màn hình tạo phiếu xuất kho mô phỏng hiển thị nút Xác nhận, tổng tiền VND và trạng thái Đã tạo. Không có chú thích về quyền, thời điểm khóa số lượng hay nguồn tính giá.
Current Behavior	Developer có thể hiểu nút Xác nhận là ghi phiếu ngay. QA có thể kiểm thử chỉ việc đổi trạng thái. Đây là suy luận từ giao diện, không phải bằng chứng quy tắc.
Underlying Need	Phân biệt hành vi UI với quyết định nghiệp vụ: nút bấm gọi hành động nào, dữ liệu nào bị thay đổi, ai được thực hiện, lỗi nào phải hiển thị.
Options	(1) Tự suy diễn từ nhãn nút. (2) Đối chiếu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và artifact nguồn liên quan. (3) Escalate nếu nguồn không tồn tại, mâu thuẫn hoặc đòi hỏi quyết định nghiệp vụ.
Decision Criteria	Chỉ chấp nhận diễn giải có ID nguồn canonical, điều kiện trước/sau rõ, owner có thẩm quyền và traceability giữ nguyên.
Decision	Không coi Xác nhận là lệnh xuất kho hay ghi sổ. Ghi điểm mở và yêu cầu làm rõ trước khi dùng wireframe làm test basis hoặc đặc tả triển khai.
Authority	Business Owner quyết định ý nghĩa nghiệp vụ; Architect quyết định ranh giới xử lý; QA xác nhận khả năng kiểm thử. BA giữ câu hỏi, bằng chứng và liên kết truy vết; không tự chốt.
Artifact	/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md; nguồn đối chiếu canonical: CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY. Tất cả đang IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Hệ thống có thể xuất kho sai thời điểm, QA kiểm thử sai trạng thái, hoặc màn hình hiển thị tổng tiền không nhất quán với dữ liệu nguồn. Đây là rủi ro mô phỏng, không phải kết luận về ERP thực tế.

Senior Lens

Hiểu nhầm bàn giao	Vì sao sai	Câu hỏi làm rõ chính xác
“Trường có dấu * nghĩa là bắt buộc ở mọi trạng thái.”	Dấu hiển thị không nói điều kiện áp dụng, nguồn rule hay thông điệp lỗi.	“Trường này bắt buộc tại trạng thái nào, theo ID quy tắc canonical nào, và khi thiếu dữ liệu hệ thống chặn lưu hay chỉ cảnh báo?”
“Nút bị mờ nghĩa là người dùng không có quyền.”	Disabled có thể do thiếu dữ liệu, trạng thái chứng từ hoặc quyền.	“Điều kiện nào làm nút bị mờ: quyền, trạng thái, dữ liệu chưa hợp lệ hay lỗi tích hợp; mỗi điều kiện hiển thị thông điệp nào?”
“Cột tổng tiền là giá trị đã tính xong.”	Wireframe không xác định công thức, thời điểm tính, làm tròn hay nguồn giá.	“Tổng tiền lấy từ trường nào trong CANONICAL_DATA_DICTIONARY, công thức và quy tắc làm tròn nằm ở artifact nào, giá trị có đổi khi người dùng sửa số lượng không?”
“Thông báo thành công nghĩa là giao dịch hoàn tất.”	Thành công UI có thể chỉ xác nhận tiếp nhận yêu cầu; xử lý nền hoặc tích hợp có thể chưa xong.	“Thông báo này xác nhận lưu nháp, gửi yêu cầu hay hoàn tất nghiệp vụ; trạng thái nào chứng minh hoàn tất; lỗi xử lý nền được hiển thị ở đâu?”
“Danh sách hiển thị toàn bộ dữ liệu người dùng được phép xem.”	Wireframe không tự xác định lọc mặc định, phân trang, dữ liệu bị ẩn hay phạm vi tổ chức.	“Bộ lọc mặc định là gì, người dùng có thấy dữ liệu của đơn vị nào, phân trang và thứ tự sắp xếp dùng trường nào?”
“Ghi chú trên wireframe là yêu cầu bảo mật đã xác nhận.”	Ghi chú có thể là đề xuất UI; kiểm soát bảo mật cần nguồn và thẩm quyền riêng.	“Yêu cầu che dữ liệu hoặc giới hạn truy cập này có nguồn canonical nào; Security Owner hoặc Architect cần xác nhận điểm nào?”

Escalate ngay khi câu trả lời làm thay đổi quyền, trạng thái nghiệp vụ, dữ liệu ghi nhận, công thức tiền VND, tích hợp, lưu vết, hoặc yêu cầu pháp lý. Bằng chứng escalation gồm ảnh wireframe, vị trí chú thích, ID artifact nguồn đã kiểm tra, diễn giải đang xung đột và câu hỏi chưa có owner trả lời.

Quick Reference

Quy tắc	Cách áp dụng
Không suy diễn từ hình	Mỗi hành vi quan trọng cần nguồn canonical hoặc điểm mở được ghi rõ.
Hỏi về điều kiện và kết quả	Luôn hỏi: điều kiện trước, hành động, dữ liệu đổi, trạng thái sau, lỗi và owner.
Phân biệt UI với nghiệp vụ	Nhãn, màu, vị trí nút là bằng chứng thiết kế UI; không đủ chứng minh business rule.
Giữ trạng thái quản trị	IN_REVIEW không phải baseline, approval hay quyền triển khai production.

8. Detailed Worked Example

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp. Bối cảnh: nhân viên kho nhận lô hàng nguyên liệu “Đường tinh luyện” tại kho nguyên liệu WH-NL-HCM. Màn hình nhận hàng ERP dùng để ghi số lượng thực nhận, số lô nhà cung cấp và trạng thái kiểm tra chất lượng. Đây là ví dụ wireframe nhằm làm rõ hành vi màn hình, không phải cấu hình ERP thực tế hay quy định vận hành đã được phê duyệt.

Nhóm fact	Giá trị mô phỏng
Chứng từ mua hàng	PO-NF-2026-0817
Nhà cung cấp	NCC-THUANPHAT-001 — Công ty TNHH Thuận Phát
Mặt hàng	RM-SUGAR-001 — Đường tinh luyện, đơn vị KG
Kho nhận	WH-NL-HCM — Kho nguyên liệu TP. Hồ Chí Minh
Số lượng đặt	10.000 KG
Số lượng giao thực tế	9.800 KG
Số lô nhà cung cấp	TP-SUGAR-260807-A
Ngày sản xuất	2026-07-28
Hạn dùng	2028-07-27
Người thao tác mô phỏng	USR-WH-014 — Nhân viên kho
Thời điểm mô phỏng	2026-08-07 09:15, Asia/Ho_Chi_Minh
Tiền tệ ngữ cảnh	VND; màn hình này không ghi nhận giá trị tiền
Phân loại dữ liệu	Dữ liệu kho và truy xuất lô; không chứa dữ liệu cá nhân khách hàng

Facts (sự kiện đã quan sát trong kịch bản): Phiếu mua hàng yêu cầu 10.000 KG, nhưng chứng từ giao hàng và cân thực tế cùng ghi 9.800 KG. Lô giao có mã TP-SUGAR-260807-A, ngày sản xuất và hạn dùng đầy đủ. Nhân viên kho cần lưu nhận hàng trước khi bộ phận chất lượng đánh giá lô. Evidence: có chênh lệch 200 KG giữa số lượng đặt và số lượng thực nhận; vì vậy màn hình không thể chỉ hiển thị một trường “Số lượng” mà không nêu rõ ý nghĩa.

Current Behavior (hành vi hiện tại của wireframe mô phỏng): Wireframe hiện có một dòng mặt hàng, trường nhập Số lượng nhận, trường Số lô, nút Lưu và thông báo “Lưu thành công”. Trường Số lượng nhận tự điền 10.000, lấy từ chứng từ mua hàng. Người dùng có thể sửa thành 9.800, nhưng màn hình không hiển thị chênh lệch, không yêu cầu lý do, không hiển thị trạng thái lô sau khi lưu và không nói rõ “Lưu thành công” nghĩa là lưu nháp hay hoàn tất nhận kho.

Thành phần wireframe hiện có	Hành vi hiện tại	Evidence	Giới hạn diễn giải
Số lượng nhận	Tự điền 10.000; cho phép sửa	Giá trị ban đầu bằng số lượng đặt	Chưa xác định có kiểm tra số âm, số thập phân hay vượt số lượng đặt
Số lô	Người dùng nhập tự do TP-SUGAR-260807-A	Không có danh sách chọn hoặc kiểm tra định dạng	Chưa xác định mã lô có cần duy nhất toàn hệ thống
Lưu	Gửi dữ liệu biểu mẫu	Thông báo “Lưu thành công” xuất hiện	Chưa xác định trạng thái chứng từ, tồn kho hay lô thay đổi thế nào
Chênh lệch	Không hiển thị	Không có trường hoặc thông báo liên quan	Không thể biết người dùng đã nhận ra thiếu 200 KG
Kiểm tra chất lượng	Không hiển thị	Không có trạng thái Chờ kiểm tra hoặc tương đương	Không thể suy ra lô được phép xuất dùng

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Nhân viên kho mở PO-NF-2026-0817] --> B[Màn hình tự điền 10.000 KG]
    B --> C[Nhập thực nhận 9.800 KG]
    C --> D[Nhập lô TP-SUGAR-260807-A]
    D --> E[Chọn Lưu]
    E --> F[Hiện thông báo Lưu thành công]
    F --> G[Không hiện chênh lệch 200 KG]
    F --> H[Không yêu cầu lý do chênh lệch]
    F --> I[Không hiện trạng thái lô]
    F --> J[Không hiện trạng thái kiểm tra chất lượng]
    F --> K[Không xác định lưu nháp hay hoàn tất nhận kho]

Kịch bản này chỉ ghi nhận facts và current behavior để làm test basis, tức cơ sở thông tin cho phân tích và kiểm thử sau này. Nó chưa kết luận underlying need, chưa chọn phương án thiết kế, chưa tạo business rule, chưa xác nhận authority và không xác nhận Nova Foods đã phê duyệt hay đang dùng hành vi nào.

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Tình huống: nhân viên kho ghi nhận nhận hàng mua nguyên liệu, nhưng màn hình chưa chặn số lượng nhận vượt số lượng còn mở của đơn mua.

Thành phần	Giá trị mô phỏng
Scenario ID	SCN-GRN-001
Màn hình	GRN-ENTRY — Goods Receipt Note Entry
Chứng từ mua	PO-NF-2026-000184
Nhà cung cấp	SUP-NF-0031 — Công ty Nguyên liệu Minh An
Kho nhận	WH-HCM-RM-01 — Kho nguyên liệu TP.HCM
Mặt hàng	RM-SUGAR-001 — Đường tinh luyện
Đơn vị tính	KG
Số lượng đặt	10,000 KG
Đã nhận trước đó	8,000 KG
Số lượng còn mở	2,000 KG
Giá trị hiển thị	24,500 VND/KG
Người dùng mô phỏng	USR-WH-014 — Nhân viên kho
Nguồn phân loại	Dữ liệu tình huống tổng hợp; không phải cấu hình ERP thực tế

Facts

Fact là dữ kiện có thể kiểm tra, chưa phải kết luận. Người dùng USR-WH-014 mở GRN-ENTRY, chọn PO-NF-2026-000184, nhập 2,500 KG cho RM-SUGAR-001. Hệ thống hiện tại cho phép lưu chứng từ nhận hàng GRN-NF-2026-000771.

Fact ID	Dữ kiện quan sát	Bằng chứng mô phỏng
FACT-GRN-001	Đơn mua đặt 10,000 KG	Header và dòng hàng của PO-NF-2026-000184
FACT-GRN-002	Đã nhận 8,000 KG	Tổng số lượng chứng từ nhận hàng trước đó
FACT-GRN-003	Còn có thể nhận 2,000 KG	10,000 - 8,000 = 2,000
FACT-GRN-004	Người dùng nhập 2,500 KG	Trường receivedQuantity trên GRN-ENTRY
FACT-GRN-005	Hệ thống lưu chứng từ	GRN-NF-2026-000771 có trạng thái mô phỏng POSTED

Current Behavior

Current Behavior là cách màn hình đang phản hồi. Màn hình chỉ kiểm tra số lượng nhập lớn hơn 0. Màn hình không so sánh receivedQuantity với số lượng còn mở của dòng đơn mua. Vì 2,500 > 0, hệ thống lưu giao dịch dù tổng nhận thành 10,500 KG.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Người dùng chọn PO-NF-2026-000184] --> B[Hệ thống tải dòng RM-SUGAR-001]
    B --> C[Hiển thị còn mở 2,000 KG]
    C --> D[Người dùng nhập 2,500 KG]
    D --> E{receivedQuantity > 0?}
    E -->|Có| F[Lưu GRN-NF-2026-000771]
    E -->|Không| G[Hiển thị lỗi]
    F --> H[Tổng nhận thành 10,500 KG]

Underlying Need

Underlying Need là nhu cầu gốc, không phải giải pháp giao diện. Kho cần ngăn ghi nhận số lượng vượt phần còn mở của đơn mua, vì số lượng nhận là dữ liệu đầu vào cho tồn kho và đối chiếu mua hàng. Bằng chứng suy luận: FACT-GRN-001 và FACT-GRN-002 cho số lượng còn mở 2,000 KG; FACT-GRN-004 nhập 2,500 KG; chênh lệch 500 KG không có chứng từ đơn mua hỗ trợ trong tình huống mô phỏng.

Need ID	Nhu cầu	Cầu nối bằng chứng
NEED-GRN-001	Chặn lưu khi số lượng nhận vượt số lượng còn mở	2,500 KG > 2,000 KG
NEED-GRN-002	Hiển thị lỗi để người dùng sửa ngay tại dòng hàng	Người dùng cần biết dòng nào, giới hạn nào, số nào đã nhập
NEED-GRN-003	Tính lại số lượng còn mở lúc lưu	Dữ liệu có thể đổi nếu chứng từ khác được ghi nhận trước lúc người dùng lưu

Options

Option ID	Phương án	Ưu điểm	Hạn chế
OPT-GRN-001	Chỉ cảnh báo, vẫn cho lưu	Ít cản trở thao tác	Không ngăn dữ liệu vượt đơn mua
OPT-GRN-002	Chặn tại trình duyệt khi nhập vượt số lượng đang hiển thị	Phản hồi nhanh	Không bảo vệ khi dữ liệu thay đổi trước lúc lưu hoặc bị gọi ngoài giao diện
OPT-GRN-003	Chặn tại giao diện và kiểm tra lại tại API khi lưu	Phản hồi nhanh; bảo vệ quy tắc tại điểm ghi dữ liệu	Cần hai điểm kiểm tra cùng một quy tắc

Decision Criteria

Criterion ID	Tiêu chí	OPT-GRN-001	OPT-GRN-002	OPT-GRN-003
CRIT-GRN-001	Không cho lưu vượt số lượng còn mở	Không đạt	Không đảm bảo	Đạt
CRIT-GRN-002	Người dùng nhận phản hồi trước khi gửi	Đạt	Đạt	Đạt
CRIT-GRN-003	Bảo vệ khi nhiều người dùng cùng thao tác	Không đạt	Không đạt	Đạt
CRIT-GRN-004	Áp dụng cho API, không chỉ màn hình	Không đạt	Không đạt	Đạt

Decision

Khuyến nghị BA, chưa phải quyết định được ủy quyền: chọn OPT-GRN-003. Giao diện kiểm tra ngay sau khi người dùng nhập số lượng. API kiểm tra lại bằng số lượng còn mở mới nhất trước khi tạo chứng từ. Khuyến nghị này đạt toàn bộ CRIT-GRN-001 đến CRIT-GRN-004. Nó không xác nhận quy tắc là cấu hình Nova Foods thực tế.

Rule ID	Quy tắc đề xuất
BR-GRN-001	Với mỗi dòng nhận hàng tham chiếu đơn mua, receivedQuantity phải lớn hơn 0 và không lớn hơn openQuantity tại thời điểm lưu.
BR-GRN-002	openQuantity = orderedQuantity - postedReceivedQuantity.
BR-GRN-003	Khi vi phạm BR-GRN-001, API không tạo chứng từ; giao diện giữ dữ liệu người dùng đã nhập và hiển thị lỗi tại dòng vi phạm.

Payload kiểm tra mô phỏng:

{
  "purchaseOrderId": "PO-NF-2026-000184",
  "warehouseId": "WH-HCM-RM-01",
  "lines": [
    {
      "purchaseOrderLineNo": 1,
      "itemId": "RM-SUGAR-001",
      "receivedQuantity": 2500,
      "uom": "KG"
    }
  ]
}

Phản hồi lỗi mô phỏng:

{
  "code": "GRN_QTY_EXCEEDS_OPEN_QTY",
  "message": "Số lượng nhận 2,500 KG vượt số lượng còn mở 2,000 KG của dòng 1 đơn mua PO-NF-2026-000184.",
  "field": "lines[0].receivedQuantity"
}

Authority

Không có quyết định được ủy quyền, baseline, hay phê duyệt được ghi nhận. BR-GRN-001 đến BR-GRN-003 là đề xuất phân tích trong artifact IN_REVIEW. Business Owner xác nhận chính sách nhận vượt; Solution Architect xác nhận điểm kiểm tra API; QA xác nhận test basis. Nếu chính sách liên quan kế toán, tồn kho chính thức, truy xuất nguồn gốc hoặc pháp lý, cần xác minh bởi owner chuyên môn phù hợp.

Artifact

Artifact ID	Tệp kiểm soát	Nội dung tạo từ tình huống
WF-GRN-001	/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md	Hành vi màn hình GRN-ENTRY, lỗi và trạng thái nút lưu
BR-GRN-001	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Quy tắc kiểm soát số lượng nhận
DATA-GRN-001	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	orderedQuantity, postedReceivedQuantity, openQuantity, receivedQuantity
TC-GRN-001	Test basis dự kiến, chưa tạo tệp canonical	Ca kiểm tra nhập 2,500 KG khi còn mở 2,000 KG

Consequence if Wrong

Nếu chọn OPT-GRN-001 hoặc OPT-GRN-002, chứng từ có thể ghi nhận vượt 500 KG. Tồn kho mô phỏng tăng vượt số lượng đơn mua hỗ trợ; đối chiếu đơn mua và nhận hàng sai; người dùng phải truy tìm và xử lý chênh lệch sau khi dữ liệu đã được ghi. Nếu BR-GRN-001 bị diễn đạt như quy định đã phê duyệt, corpus sẽ sai thẩm quyền vì trạng thái hiện hành là IN_REVIEW.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Màn hình minh họa: duyệt yêu cầu điều chỉnh số lượng giao hàng cho đơn bán SO-NF-2026-000184. Mục tiêu wireframe: người duyệt thấy đủ dữ liệu, lý do, tác động và hành động hợp lệ trước khi quyết định.

Nhóm	ID / giá trị đầy đủ	Nguồn phân loại	Ý nghĩa hiển thị
Yêu cầu điều chỉnh	DAR-NF-2026-000071	Dữ liệu giao dịch mô phỏng	Đối tượng màn hình chính
Đơn bán	SO-NF-2026-000184	Dữ liệu giao dịch mô phỏng	Chứng từ gốc bị ảnh hưởng
Khách hàng	CUS-NF-000248 — Siêu thị An Phú	Master data mô phỏng	Bên nhận hàng
Kho xuất	WH-HCM-01 — Kho Thành phẩm TP.HCM	Master data mô phỏng	Nguồn tồn kho
Mặt hàng	FG-NF-CHILI-500G — Tương ớt Nova 500g	Master data mô phỏng	Hàng cần điều chỉnh
Số lượng cũ	1.200 chai	Dữ liệu giao dịch mô phỏng	Cam kết đã ghi nhận
Số lượng đề nghị	1.500 chai	Dữ liệu giao dịch mô phỏng	Tăng 300 chai
Giá đơn vị	28.000 VND/chai	Dữ liệu giao dịch mô phỏng	Giá chỉ đọc
Tác động trước thuế	8.400.000 VND	Phép tính UI	300 × 28.000; không phải bút toán
Lý do	Khách hàng bổ sung nhu cầu cho chương trình cuối tuần.	Người tạo mô phỏng	Bằng chứng nghiệp vụ nhập tay
Người tạo	USR-NF-0142 — Nguyễn Minh Khoa	Danh tính mô phỏng	Sales Executive
Người duyệt	USR-NF-0027 — Trần Thu Hà	Danh tính mô phỏng	Sales Manager
Trạng thái	IN_REVIEW	Trạng thái workflow mô phỏng	Chờ người có quyền quyết định
Ngày tạo	2026-08-07 09:15:00+07:00	Audit data mô phỏng	Chỉ đọc
Phiên bản artifact	v0.9.0	Metadata corpus	Không phải phiên bản đơn bán

Mọi trường nguồn lấy từ dịch vụ ERP mô phỏng phải giữ định danh gốc; wireframe không đổi DAR-NF-2026-000071 thành nhãn tự do. Điều này giữ traceability, nghĩa là khả năng lần ngược từ màn hình về dữ liệu, quy tắc và quyết định.

ID quy tắc	Quy tắc UI đầy đủ	Bằng chứng và cầu nối suy luận	Trạng thái thẩm quyền
BR-UI-DAR-001	Chỉ hiển thị nút Phê duyệt và Từ chối khi status = IN_REVIEW và người dùng có quyền DAR_APPROVE.	Trạng thái xác định điểm workflow; quyền xác định ai được chuyển trạng thái. Không kiểm tra cả hai sẽ cho hành động sai.	Đề xuất thiết kế; chưa được phê duyệt
BR-UI-DAR-002	Nút Phê duyệt bị vô hiệu khi availableQty < requestedIncreaseQty; hiển thị số tồn khả dụng và lý do.	Yêu cầu tăng 300 chai; tồn khả dụng quyết định khả năng đáp ứng. UI phải chặn lỗi sớm, nhưng backend vẫn phải kiểm tra lại.	Đề xuất thiết kế; chưa được phê duyệt
BR-UI-DAR-003	Từ chối bắt buộc nhập rejectionReason từ 10 đến 500 ký tự.	Từ chối làm thay đổi kỳ vọng người tạo; cần lý do truy vết.	Đề xuất thiết kế; chưa được phê duyệt
BR-UI-DAR-004	Giá, đơn bán, khách hàng, kho, mặt hàng và số lượng cũ là chỉ đọc.	Người duyệt quyết định yêu cầu, không sửa chứng từ nguồn trên màn hình duyệt.	Đề xuất thiết kế; chưa được phê duyệt
BR-UI-DAR-005	Sau thao tác thành công, màn hình tải lại trạng thái và nhật ký audit từ server.	Trạng thái có thể đổi đồng thời; dữ liệu client cũ không đủ tin cậy.	Đề xuất thiết kế; chưa được phê duyệt

Payload đọc màn hình, dùng cho wireframe và test basis, không phải hợp đồng API được phê duyệt:

{
  "adjustmentRequestId": "DAR-NF-2026-000071",
  "status": "IN_REVIEW",
  "salesOrderId": "SO-NF-2026-000184",
  "customer": {
    "customerId": "CUS-NF-000248",
    "customerName": "Siêu thị An Phú"
  },
  "warehouse": {
    "warehouseId": "WH-HCM-01",
    "warehouseName": "Kho Thành phẩm TP.HCM"
  },
  "line": {
    "itemId": "FG-NF-CHILI-500G",
    "itemName": "Tương ớt Nova 500g",
    "originalQty": 1200,
    "requestedQty": 1500,
    "requestedIncreaseQty": 300,
    "uom": "chai",
    "unitPriceVnd": 28000,
    "impactBeforeTaxVnd": 8400000,
    "availableQty": 425
  },
  "reason": "Khách hàng bổ sung nhu cầu cho chương trình cuối tuần.",
  "createdBy": {
    "userId": "USR-NF-0142",
    "displayName": "Nguyễn Minh Khoa"
  },
  "createdAt": "2026-08-07T09:15:00+07:00",
  "reviewer": {
    "userId": "USR-NF-0027",
    "displayName": "Trần Thu Hà",
    "permissions": ["DAR_APPROVE"]
  }
}

Source mermaid — có thể chỉnh sửa

flowchart TB
    ENTRY["Mở màn hình duyệt<br/>DAR-NF-2026-000071"]

    subgraph UI["UI — đề xuất thiết kế; chưa được phê duyệt"]
        STATUS{"status = IN_REVIEW?"}
        PERMISSION{"Có quyền DAR_APPROVE?"}

        NOT_IN_REVIEW["Ẩn Phê duyệt và Từ chối<br/>Hiển thị trạng thái hiện tại"]
        NO_PERMISSION["Ẩn Phê duyệt và Từ chối<br/>Hiển thị: Bạn không có quyền duyệt yêu cầu này."]
        ACTIONS["Hiển thị Phê duyệt và Từ chối"]

        STOCK{"availableQty >=<br/>requestedIncreaseQty?"}
        APPROVE_DISABLED["Vô hiệu Phê duyệt<br/>Hiển thị tồn khả dụng và mức tăng yêu cầu"]
        APPROVE_ENABLED["Cho phép Phê duyệt"]
        SEND_APPROVAL["Gửi lệnh phê duyệt"]

        REJECT_INPUT["Chọn Từ chối<br/>Nhập rejectionReason"]
        REJECTION_VALID{"Độ dài từ 10 đến 500 ký tự?"}
        REJECTION_INVALID["Hiển thị lỗi độ dài<br/>Không gửi payload"]
        SEND_REJECTION["Gửi lệnh từ chối"]

        APPROVAL_REJECTED["Hiển thị: Không thể phê duyệt vì quyền, trạng thái<br/>hoặc tồn kho không còn hợp lệ.<br/>Không ghi đè dữ liệu."]
        CONFLICT["Hiển thị: Yêu cầu đã được xử lý bởi người dùng khác.<br/>Không ghi đè quyết định. Tải lại dữ liệu."]
        RELOAD["Yêu cầu tải lại trạng thái<br/>và nhật ký audit"]
        UPDATED{"Trạng thái hiện tại"}
        SHOW_APPROVED["Hiển thị APPROVED<br/>và nhật ký audit"]
        SHOW_REJECTED["Hiển thị REJECTED<br/>và nhật ký audit"]
        SHOW_OTHER["Hiển thị trạng thái hiện tại<br/>và nhật ký audit"]
    end

    subgraph SERVER["Dịch vụ ERP mô phỏng"]
        CHECK_APPROVAL["Khuyến nghị chưa được phê duyệt:<br/>kiểm tra lại quyền, trạng thái và tồn kho"]
        APPROVAL_RESULT{"Kết quả lệnh phê duyệt"}
        REJECTION_RESULT{"Kết quả lệnh từ chối"}
        LOAD_CURRENT["Đọc trạng thái<br/>và nhật ký audit hiện tại"]
    end

    ENTRY --> STATUS
    STATUS -- "Không" --> NOT_IN_REVIEW
    STATUS -- "Có" --> PERMISSION
    PERMISSION -- "Không" --> NO_PERMISSION
    PERMISSION -- "Có" --> ACTIONS

    ACTIONS --> STOCK
    STOCK -- "Không" --> APPROVE_DISABLED
    STOCK -- "Có" --> APPROVE_ENABLED
    APPROVE_ENABLED --> SEND_APPROVAL
    APPROVE_DISABLED -- "Chọn Từ chối" --> REJECT_INPUT

    ACTIONS --> REJECT_INPUT
    REJECT_INPUT --> REJECTION_VALID
    REJECTION_VALID -- "Không" --> REJECTION_INVALID
    REJECTION_INVALID -- "Sửa lý do" --> REJECT_INPUT
    REJECTION_VALID -- "Có" --> SEND_REJECTION

    SEND_APPROVAL --> CHECK_APPROVAL
    CHECK_APPROVAL --> APPROVAL_RESULT
    APPROVAL_RESULT -- "Thành công" --> RELOAD
    APPROVAL_RESULT -- "Không đạt kiểm tra lại" --> APPROVAL_REJECTED
    APPROVAL_RESULT -- "409 Conflict" --> CONFLICT
    APPROVAL_REJECTED --> RELOAD

    SEND_REJECTION --> REJECTION_RESULT
    REJECTION_RESULT -- "Thành công" --> RELOAD
    REJECTION_RESULT -- "409 Conflict" --> CONFLICT

    CONFLICT --> RELOAD
    RELOAD --> LOAD_CURRENT
    LOAD_CURRENT --> UPDATED
    UPDATED -- "APPROVED" --> SHOW_APPROVED
    UPDATED -- "REJECTED" --> SHOW_REJECTED
    UPDATED -- "IN_REVIEW" --> STATUS
    UPDATED -- "Trạng thái khác" --> SHOW_OTHER

    NOT_IN_REVIEW --> DONE([Kết thúc])
    NO_PERMISSION --> DONE
    SHOW_APPROVED --> DONE
    SHOW_REJECTED --> DONE
    SHOW_OTHER --> DONE

Kịch bản	Dữ liệu đầu vào	Hành vi màn hình cần có	Kết quả mong đợi
SCN-DAR-001	status = IN_REVIEW; quyền DAR_APPROVE; availableQty = 425	Hiện nút Phê duyệt, Từ chối; hiện tác động 8.400.000 VND	Người duyệt có thể chọn một hành động
SCN-DAR-002	status = IN_REVIEW; không có DAR_APPROVE	Ẩn cả hai nút; hiện “Bạn không có quyền duyệt yêu cầu này.”	Không gửi payload thay đổi trạng thái
SCN-DAR-003	availableQty = 250; tăng yêu cầu 300	Vô hiệu Phê duyệt; hiện “Tồn khả dụng 250 chai, thấp hơn mức tăng 300 chai.”	Không cho duyệt từ UI
SCN-DAR-004	Chọn Từ chối; lý do Hết hàng	Hiện lỗi “Lý do từ chối phải từ 10 đến 500 ký tự.”	Không gửi payload
SCN-DAR-005	Server trả 409 Conflict vì trạng thái đã đổi	Hiện “Yêu cầu đã được xử lý bởi người dùng khác. Tải lại dữ liệu.”	Không ghi đè quyết định khác

Loại kết luận	Nội dung	Thẩm quyền cần có
Khuyến nghị BA	Dùng một màn hình chi tiết với hành động đặt cuối trang, sau vùng tác động tồn kho và giá trị.	Business Owner, UX Owner, Architect xem xét
Khuyến nghị BA	Backend kiểm tra lại quyền, trạng thái, tồn kho khi nhận lệnh duyệt.	Architect, Security Owner xác nhận
Quyết định được ủy quyền	Chưa có. IN_REVIEW, v0.9.0, ngày 2026-08-07 không cấu thành phê duyệt.	Business Owner và vai trò chuyên môn phù hợp
Artifact liên kết	/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md; TRACEABILITY_ID_REGISTRY; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Artifact đều IN_REVIEW
Hậu quả nếu sai	Người không có quyền có thể thấy hành động; người duyệt có thể duyệt vượt tồn; lý do từ chối thiếu truy vết; UI có thể hiển thị trạng thái cũ.	Rủi ro vận hành mô phỏng; không phải kết luận tuân thủ hay production

9. Related Concepts & Dependencies

Core

Wireframe không phải nguồn chân lý độc lập. Wireframe chỉ diễn tả cách người dùng thấy dữ liệu, nhập dữ liệu và kích hoạt hành động. Quy tắc nghiệp vụ, định nghĩa dữ liệu, định danh truy vết và danh mục template phải nằm tại artifact canonical riêng. Lý do: cùng một quy tắc được chép vào nhiều màn hình sẽ tạo nhiều bản có thể lệch nhau khi thay đổi.

Nova Foods Trading & Manufacturing là case study mô phỏng; mọi tên, dữ liệu và hành vi dưới đây là dữ liệu tổng hợp. Trạng thái corpus hiện là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Các trạng thái này không là baseline, approval, xác nhận vận hành hay cho phép production.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A["/01-curriculum/CHAPTER_MANIFEST.md"]
    B["/01-curriculum/TRACEABILITY_ID_REGISTRY.md"]
    C["/01-curriculum/CANONICAL_BUSINESS_RULES.md"]
    D["/01-curriculum/CANONICAL_DATA_DICTIONARY.md"]
    E["/01-curriculum/TEMPLATE_MANIFEST.md"]
    P["API artifact<br/>(khi tồn tại)"]
    S["Scenario"]

    W["Wireframe behavior"]
    U["Thiết kế UX/UI"]
    R["Thiết kế kiến trúc và API"]
    Q["Thiết kế kiểm thử QA"]

    A -->|"Giữ nguyên chapter identity và filename"| W
    B -->|"Dùng persistent ID đã đăng ký"| W
    C -->|"Dẫn chiếu rule ID; không chép thành bản thay thế"| W
    D -->|"Dùng field name và định nghĩa canonical"| W
    E -->|"Chỉ dùng template đã catalog; không đồng nghĩa approved"| W

    W -->|"Chuyển hành vi thành artifact trực quan"| U

    W -->|"Kiểm tra dữ liệu, quyền và xung đột;<br/>không suy ra API contract từ nút bấm"| R
    C -->|"Rule catalog"| R
    D -->|"Định nghĩa dữ liệu"| R
    P --> R

    W -->|"Hành vi UI đã liên kết nguồn"| Q
    S -->|"Cơ sở scenario"| Q
    B -->|"Persistent ID"| Q
    C -->|"Business rule"| Q
    D -->|"Định nghĩa dữ liệu"| Q

Hướng	Khái niệm hoặc artifact	Vai trò với wireframe	Nguồn chân lý giữ ở đâu	Quy tắc tham chiếu
Upstream	Chapter manifest	Xác định chapter, filename và phạm vi section	/01-curriculum/CHAPTER_MANIFEST.md	Giữ nguyên filename và chapter identity; không tự đổi tên file trong wireframe
Upstream	Traceability ID registry	Cấp và kiểm soát persistent ID, tức định danh bền vững qua phiên bản	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Dùng ID đã đăng ký; không tạo biến thể ID theo tên màn hình
Upstream	Canonical business rules	Xác định điều kiện được duyệt, từ chối, quyền và kiểm tra tồn	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Wireframe dẫn chiếu rule ID và mô tả tác động UI; không chép lại rule như bản thay thế
Upstream	Canonical data dictionary	Xác định nghĩa, kiểu, nguồn và giới hạn trường dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Ghi field name theo dictionary; không đổi nghĩa trường vì nhãn UI
Upstream	Template manifest	Xác định template dự kiến dùng cho artifact	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ tham chiếu template đã catalog; không tuyên bố template là approved
Downstream	UX/UI design	Chuyển hành vi đã truy vết thành thiết kế trực quan	Wireframe và nguồn upstream liên quan	UX không tự sửa business rule qua mockup
Downstream	Architect và API design	Kiểm tra UI có đủ dữ liệu, quyền và xử lý xung đột	Data dictionary, rule catalog, API artifact khi tồn tại	Không suy ra API contract chỉ từ nút bấm
Downstream	QA và test design	Xây test basis từ hành vi UI đã liên kết nguồn	Scenario, rule, data definition và registry	QA giữ test case ở artifact test canonical, không biến wireframe thành test case canonical

Applied

Facts: Màn hình chi tiết yêu cầu điều chỉnh tồn kho mô phỏng dùng các scenario SCN-DAR-002 đến SCN-DAR-005. Màn hình hiển thị trạng thái IN_REVIEW, quyền DAR_APPROVE, số lượng khả dụng availableQty, lý do từ chối và lỗi 409 Conflict.

Current Behavior: UI ẩn hoặc vô hiệu hành động duyệt khi người dùng không có quyền, trạng thái không còn phù hợp, hoặc mức tăng vượt availableQty. UI yêu cầu lý do từ chối từ 10 đến 500 ký tự và yêu cầu tải lại khi server trả 409 Conflict.

Underlying Need: Người học cần biết mỗi chi tiết UI lấy nghĩa từ đâu. Bằng chứng: quyền không thuộc wireframe; availableQty là dữ liệu; điều kiện duyệt là business rule; 409 Conflict là phản hồi tích hợp. Nếu wireframe tự định nghĩa toàn bộ, cùng hành vi sẽ có nhiều nguồn mâu thuẫn.

Options: (1) Chép toàn văn rule và định nghĩa dữ liệu vào từng màn hình. (2) Chỉ ghi tên màn hình, không có liên kết nguồn. (3) Ghi hành vi UI ngắn gọn, kèm tham chiếu đến artifact canonical và persistent ID đã đăng ký.

Decision Criteria: Chọn phương án giữ một nguồn chân lý, truy được thay đổi, không làm wireframe thành catalog quy tắc hoặc từ điển dữ liệu thứ hai, và cho phép QA cùng Architect xác định đúng đầu vào.

Decision: Dùng phương án (3). Wireframe giữ nhãn, trạng thái hiển thị, điều kiện tương tác và thông báo lỗi. Rule, data definition, ID registry và API contract giữ tại artifact canonical tương ứng.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner, Architect, Security Owner, QA Owner hoặc owner chuyên môn phù hợp xác nhận nội dung thuộc thẩm quyền của họ. Chưa có approval được ghi nhận.

Artifact: /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md tham chiếu TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, /01-curriculum/CHAPTER_MANIFEST.md và /01-curriculum/TEMPLATE_MANIFEST.md.

Consequence if Wrong: Nếu availableQty bị định nghĩa khác giữa UI và data dictionary, người dùng có thể thấy số tồn khác backend. Nếu quyền DAR_APPROVE bị chép sai, UI có thể hiện hành động không phù hợp. Nếu scenario ID bị đổi tự phát, review sau này không nối được bằng chứng hành vi với artifact gốc.

Senior Lens

Một liên kết tốt trả lời ba câu: “đối tượng này là gì”, “nguồn nào sở hữu nghĩa của nó”, và “ai bị ảnh hưởng nếu nó đổi”. Ví dụ, wireframe có thể ghi availableQty cạnh nhãn “Tồn khả dụng”; nhưng nghĩa tính toán, đơn vị và nguồn dữ liệu phải dẫn về CANONICAL_DATA_DICTIONARY. Wireframe không được tự đổi availableQty thành “Tồn thực tế” nếu dictionary chưa đổi, vì đây là đổi nghĩa nghiệp vụ chứ không phải đổi nhãn.

Persistent ID không được tái sử dụng cho nội dung mới. Khi nội dung cũ bị thay đổi đáng kể, registry quyết định giữ ID với lịch sử phiên bản hay cấp ID khác. Lý do: ID là khóa nối giữa chapter, rule, dữ liệu, scenario, test artifact và review evidence; đổi hoặc tái dùng im lặng làm đứt chuỗi truy vết.

Quick Reference

Thành phần trên wireframe	Ghi tại wireframe	Không ghi lại như canonical
Nhãn trường	Tên hiển thị, vị trí, trạng thái read-only hoặc editable	Định nghĩa logic đầy đủ của trường
Nút hành động	Điều kiện hiện, ẩn, vô hiệu; phản hồi người dùng thấy	Quyết định quyền hoặc rule nghiệp vụ gốc
Thông báo lỗi	Nội dung hiển thị và thời điểm hiển thị	API contract hoặc error catalog đầy đủ
Scenario	SCN-DAR-002 đến SCN-DAR-005 và hành vi minh họa	Registry cấp phát hoặc test case canonical
Liên kết artifact	ID và đường dẫn canonical nguyên dạng	Bản sao local thay thế artifact gốc

Core

Ma trận truy vết liên kết một nhu cầu với requirement, business rule, acceptance criteria, dữ liệu/API và test case. Mục đích: người đọc kiểm tra được màn hình Nova Foods mô phỏng đang hiển thị hoặc chặn hành vi vì nguồn nào. Ma trận chỉ tham chiếu ID đã đăng ký; không chép lại nội dung canonical vào wireframe.

Loại liên kết	Ý nghĩa	Nguồn canonical	Cách ghi trong wireframe	Không được làm
NEED	Nhu cầu nghiệp vụ giải thích giá trị cần đạt	TRACEABILITY_ID_REGISTRY	Ghi ID NEED đã đăng ký cạnh hành vi màn hình	Tự diễn giải nhu cầu thành quy tắc mới
REQ	Yêu cầu mô tả khả năng hệ thống phải có	Registry requirement theo TRACEABILITY_ID_REGISTRY	Liên kết control, trạng thái, thông báo lỗi với ID REQ	Dùng mô tả wireframe thay requirement
BR	Business Rule, quy tắc nghiệp vụ quyết định điều kiện hoặc kết quả	CANONICAL_BUSINESS_RULES	Ghi ID BR tại validation, tính toán, quyền hiển thị	Sao chép hoặc sửa câu chữ quy tắc trong màn hình
AC	Acceptance Criteria, điều kiện kiểm nhận xác định kết quả chấp nhận được	Artifact requirement canonical	Ghi ID AC cho trạng thái thành công, lỗi, biên dữ liệu	Xem mockup đẹp là bằng chứng đạt AC
DATA/API	Trường dữ liệu hoặc hợp đồng giao tiếp xác định dữ liệu màn hình đọc, ghi	CANONICAL_DATA_DICTIONARY; OpenAPI nếu đã được đăng ký	Ghi tên trường hoặc operation cùng ID đăng ký	Suy ra kiểu dữ liệu, quyền, endpoint từ nhãn UI
TC	Test Case, ca kiểm thử kiểm tra liên kết có thể quan sát	Registry test theo TRACEABILITY_ID_REGISTRY	Ghi ID TC cho luồng và lỗi có rủi ro	Dùng TC để tạo requirement mới

Source mermaid — có thể chỉnh sửa

flowchart TB
    WF[Wireframe và UI rule]

    WF -->|tham chiếu| NEED[NEED đã đăng ký]
    WF -->|tham chiếu| REQ[REQ trong registry requirement theo TRACEABILITY_ID_REGISTRY]
    WF -->|tham chiếu| BR[BR trong CANONICAL_BUSINESS_RULES]
    WF -->|tham chiếu| DATA[Trường DATA trong CANONICAL_DATA_DICTIONARY]
    WF -->|tham chiếu| API[Operation API trong OpenAPI đã đăng ký]
    WF -->|tham chiếu| AC[AC trong artifact requirement canonical]
    WF -->|tham chiếu| TC[TC đã đăng ký cho luồng và lỗi có rủi ro]

    REQ -->|tham chiếu| NEED
    TC -->|kiểm tra| AC

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; dữ liệu tổng hợp; toàn corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07. Current Behavior: wireframe Phiếu xuất kho cần chứng minh nút “Xác nhận xuất” dựa trên requirement, quy tắc, dữ liệu và kiểm thử nào. Underlying Need: reviewer phải lần ngược từ control UI đến nguồn canonical mà không coi wireframe là nguồn quyết định nghiệp vụ.

Thành phần wireframe	NEED	REQ	BR	AC	DATA/API	TC	Trạng thái liên kết
Nút “Xác nhận xuất”	ID phải tra từ TRACEABILITY_ID_REGISTRY	ID phải tra từ registry	ID phải tra từ CANONICAL_BUSINESS_RULES	ID phải tra từ artifact requirement	Operation và trường phải tra từ CANONICAL_DATA_DICTIONARY hoặc OpenAPI đã đăng ký	ID phải tra từ registry test	Chưa được xác nhận vì nguồn seed không cung cấp ID dòng cụ thể
Thông báo thiếu số lượng khả dụng	ID phải tra từ TRACEABILITY_ID_REGISTRY	ID phải tra từ registry	ID phải tra từ CANONICAL_BUSINESS_RULES	ID phải tra từ artifact requirement	Trường tồn khả dụng phải tra từ CANONICAL_DATA_DICTIONARY	ID phải tra từ registry test	Chưa được xác nhận vì nguồn seed không cung cấp ID dòng cụ thể
Hiển thị mã lô hàng	Khi có nhu cầu truy xuất đã đăng ký	Requirement liên quan phải được đăng ký	Rule hiển thị phải tra catalog	Điều kiện hiển thị phải tra artifact requirement	Định nghĩa mã lô phải tra CANONICAL_DATA_DICTIONARY	Ca kiểm thử phải được đăng ký	Verification required

Options: (1) ghi ID giả để hoàn chỉnh bảng; (2) để trống liên kết; (3) ghi rõ nguồn canonical và trạng thái chưa có ID. Decision Criteria: bảo toàn ID; không tạo nguồn chân lý thứ hai; không ngụ ý approval; cho phép reviewer tìm đúng artifact. Decision: chọn phương án 3. Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết; Business Owner, Architect, QA và owner chuyên môn xác nhận nội dung thuộc thẩm quyền của họ. Artifact: /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md tham chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Consequence if Wrong: ID giả làm QA kiểm thử sai hành vi; rule bị sao chép có thể lệch catalog; UI có thể gọi dữ liệu không đúng định nghĩa.

Senior Lens

Liên kết REQ không thay BR: requirement nói hệ thống cần làm gì, còn business rule nói điều kiện nghiệp vụ nào chi phối kết quả. Liên kết DATA/API không chứng minh API đã tồn tại hoặc được phê duyệt; nó chỉ chỉ đúng nơi kiểm tra hợp đồng dữ liệu. TC truy vết từ AC và hành vi quan sát được, không được tự suy ra nghĩa vụ pháp lý, kế toán, an toàn thực phẩm hoặc bảo mật.

Nếu registry chưa cấp ID, ghi trạng thái “chưa được xác nhận” và nêu đúng artifact cần tra. Không dùng chuỗi ID tự tạo, không đổi tiền tố ID, không thay đường dẫn canonical bằng bản sao. IN_REVIEW không phải baseline, approval, production-ready hoặc xác nhận Nova Foods vận hành theo nội dung mô phỏng.

Quick Reference

Kiểm tra trước khi giữ liên kết	Đạt khi
ID	Chuỗi ID khớp nguyên dạng registry
Nguồn	BR chỉ trỏ CANONICAL_BUSINESS_RULES; dữ liệu chỉ trỏ CANONICAL_DATA_DICTIONARY hoặc OpenAPI đã đăng ký
UI	Control, trạng thái hoặc lỗi có liên kết REQ hoặc AC phù hợp
Test	TC kiểm tra kết quả quan sát được từ AC
Governance	Không có ID giả, approval ngầm định, hay nội dung canonical bị sao chép

Thay đổi dependency và tác động lan truyền

Core

Dependency là quan hệ phụ thuộc: wireframe chỉ đúng khi dữ liệu, quy tắc, yêu cầu và API mà màn hình dùng vẫn giữ ý nghĩa đã công bố. Khi dependency đổi, thay đổi phải lan từ nguồn canonical đến mọi artifact tiêu thụ nó. Không sửa riêng wireframe để “khớp giao diện”, vì tạo hai nguồn sự thật.

Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, mọi thay đổi còn cần review; không có baseline hay approval ngầm định.

Source mermaid — có thể chỉnh sửa

flowchart TB
    C["Nguồn canonical thay đổi"] --> I["Ghi nhận version, lý do, phạm vi tác động và artifact cần kiểm tra"]
    I --> W["Cập nhật wireframe và UI rules"]
    I --> R["Cập nhật requirement và business rules"]
    I --> D["Cập nhật data model và API contract"]
    I --> T["Cập nhật test artifacts"]
    W --> V{"Review tính nhất quán"}
    R --> V
    D --> V
    T --> V
    V -->|Nhất quán| H["Cập nhật liên kết traceability"]
    V -->|Chưa nhất quán| F["Sửa artifact bị ảnh hưởng"]
    F --> I

Thay đổi im lặng là sửa nội dung, cấu trúc dữ liệu, quy tắc hoặc hợp đồng API nhưng không ghi nhận version, lý do, phạm vi tác động và artifact cần kiểm tra. Hậu quả không phải chỉ là lỗi tài liệu. Người dùng có thể thấy trường sai, hệ thống gửi dữ liệu sai, QA kiểm thử theo kỳ vọng cũ, hoặc đội phát triển dựng giao diện mâu thuẫn với logic nghiệp vụ.

Applied

Facts: Wireframe màn hình nhập thông tin lô hàng hiển thị trường Hạn dùng. CANONICAL_DATA_DICTIONARY đổi định nghĩa trường này từ “ngày tùy chọn” thành “ngày bắt buộc khi loại hàng yêu cầu truy xuất”. Đây là thay đổi giả lập trong corpus Nova Foods, không phải quy định vận hành thật.

Current Behavior: UI rule cũ cho phép lưu khi Hạn dùng trống. API và test case liên quan chưa được kiểm tra tác động.

Underlying Need: Giữ cùng một ý nghĩa dữ liệu giữa màn hình, validation, API và kiểm thử. Bằng chứng: nếu UI cho lưu dữ liệu trống nhưng tầng nhận dữ liệu yêu cầu giá trị, người dùng gặp lỗi muộn; nếu API vẫn nhận trống, dữ liệu truy xuất có thể thiếu.

Options:
1. Chỉ sửa nhãn trường trên wireframe.
2. Sửa UI rule, kiểm tra hợp đồng API, requirement liên quan và test artifact.
3. Tạo quy tắc mới ngay trong wireframe.

Decision Criteria: Nguồn nào sở hữu định nghĩa dữ liệu; thay đổi có ảnh hưởng validation hay không; có consumer nào dùng giá trị cũ; thay đổi có vượt thẩm quyền BA hay không.

Decision: Chọn phương án 2. CANONICAL_DATA_DICTIONARY giữ định nghĩa dữ liệu; wireframe chỉ tham chiếu và phản ánh hành vi. Không tạo quy tắc nghiệp vụ mới trong tài liệu UI.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và lịch sử thay đổi. Business Owner xác nhận ý nghĩa nghiệp vụ. Architect xác nhận API hoặc tích hợp. QA xác nhận test basis. Nếu thay đổi liên quan truy xuất thực phẩm hoặc dữ liệu cá nhân, cần Legal/Compliance Owner xác minh; tài liệu học liệu không tự kết luận nghĩa vụ pháp lý.

Artifact: Cập nhật ghi nhận tác động tại /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md; đối chiếu nguồn tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; giữ ID và đường dẫn canonical nguyên dạng.

Consequence if Wrong: Sửa im lặng làm wireframe nói “bắt buộc”, API vẫn nhận rỗng, test vẫn chấp nhận rỗng. Ba artifact cùng tồn tại nhưng cho ba hành vi khác nhau. Lỗi chỉ lộ khi tích hợp hoặc vận hành thử, lúc chi phí sửa cao hơn.

Senior Lens

Kiểm tra lan truyền theo ý nghĩa, không chỉ theo tên trường. Đổi kiểu dữ liệu, điều kiện bắt buộc, quyền xem, định dạng VND, timezone Asia/Ho_Chi_Minh, mã trạng thái, hoặc xử lý lỗi đều có thể đổi hành vi màn hình dù tên trường không đổi. Không suy luận rằng thay đổi “nhỏ” chỉ tác động UI.

Dependency đổi im lặng	Wireframe có thể hỏng	Rủi ro tiếp theo	Hành động tối thiểu
Định nghĩa dữ liệu	Nhãn, format, bắt buộc/số lần nhập sai	Dữ liệu thiếu hoặc sai kiểu	So khớp với CANONICAL_DATA_DICTIONARY
Quy tắc nghiệp vụ	Điều kiện hiện nút, cảnh báo, khóa sửa	Người dùng thực hiện sai luồng	So khớp với CANONICAL_BUSINESS_RULES
Hợp đồng API	Trạng thái tải, lỗi, dữ liệu trả về	UI lỗi khi tích hợp	Architect kiểm tra contract
ID traceability	Liên kết trỏ sai đối tượng	Không chứng minh được nguồn thay đổi	Kiểm tra TRACEABILITY_ID_REGISTRY
Trạng thái/version artifact	Người đọc dùng bản không còn đúng	Review sai phạm vi	Ghi rõ IN_REVIEW, v0.9.0, ngày thay đổi

Quick Reference

• Canonical source đổi: ghi nhận tác động trước khi sửa artifact tiêu thụ.
• Wireframe mô tả hành vi UI; không thay thế data dictionary, business-rule catalog hay API contract.
• Không có log thay đổi và kiểm tra consumer: coi là thay đổi im lặng.
• Dependency đụng pháp lý, kế toán, bảo mật, API hoặc test: chuyển đúng owner xác minh.

10. Common Mistakes & Anti-patterns

Core

Người mới thường xem wireframe là ảnh minh họa tĩnh. Wireframe là bản mô tả cấu trúc màn hình và hành vi dự kiến: ai thấy gì, nhập gì, bấm gì, hệ thống phản hồi gì. Dấu hiệu quan sát được là ảnh có nút nhưng thiếu điều kiện hiện nút, thiếu trạng thái lỗi, tải dữ liệu hoặc khóa thao tác. Nguyên nhân là chỉ ghi nhận cuộc họp theo giao diện, chưa chuyển nhu cầu thành hành vi kiểm tra được. Cách sửa: với mỗi thành phần có thể thao tác, ghi điều kiện vào, hành động, phản hồi thành công, phản hồi lỗi và liên kết nguồn.

Sai lầm cụ thể	Dấu hiệu đỏ quan sát được	Nguyên nhân gốc	Hành động sửa
Vẽ trường nhập nhưng không ghi quy tắc kiểm tra	Trường Số lượng có nhãn nhưng không có kiểu số, giới hạn hoặc lỗi	Nhầm wireframe với thiết kế hình ảnh	Ghi kiểu nhập, bắt buộc hay không, điều kiện hợp lệ và thông báo lỗi dự kiến
Chỉ mô tả đường thành công	Có nút Lưu nhưng không có trạng thái đang lưu, thất bại hoặc mất kết nối	Nhóm giả định backend luôn trả thành công	Bổ sung hành vi tải, lỗi hệ thống, lỗi nghiệp vụ và cách giữ dữ liệu đã nhập
Dùng dữ liệu ví dụ như quy tắc	Một con số 100.000 VND bị diễn giải thành hạn mức	Không tách dữ liệu tổng hợp khỏi business rule	Gắn nhãn dữ liệu mô phỏng; chỉ liên kết quy tắc từ CANONICAL_BUSINESS_RULES khi đã tồn tại
Gộp nhiều vai trò vào một màn hình	Người tạo phiếu, người duyệt và quản trị viên cùng thấy mọi nút	Không phân tích quyền theo tác vụ	Lập ma trận vai trò, hành động và điều kiện hiển thị; Security hoặc Business Owner xác minh quyền
Sửa wireframe nhưng không kiểm tra consumer	QA, UI và API dùng ba cách hiểu khác nhau	Không rà tác động xuống acceptance criteria và test basis	Ghi thay đổi, rà các artifact liên kết, cập nhật cùng một phạm vi review

[!WARNING] Rủi ro thật: nút hành động không có trạng thái lỗi có thể làm người dùng Nova Foods mô phỏng bấm lưu lại nhiều lần. Hậu quả là tạo trùng chứng từ mô phỏng hoặc hiểu sai kết quả xử lý. Ranh giới phục hồi an toàn: không tự xóa dữ liệu; dừng thao tác lặp, đối chiếu mã tham chiếu do hệ thống trả về, rồi chuyển owner nghiệp vụ và kỹ thuật xác minh.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Phát hiện hành vi thiếu trong wireframe] --> B[Xác định thành phần và màn hình]
    B --> C{Nguồn quy tắc canonical đã tồn tại?}

    C -- Chưa --> C1[Không dùng dữ liệu mô phỏng làm business rule]
    C1 --> C2[Chuyển làm rõ; xác định hoặc xác nhận owner nguồn canonical]
    C2 --> C

    C -- Rồi --> C3[Ghi tham chiếu nguồn canonical]
    C3 --> D[Ghi điều kiện vào, hành động, phản hồi thành công, lỗi, tải và quyền]
    D --> E[Security hoặc Business Owner xác minh quyền hiển thị và thao tác]

    E --> S[Hiển thị trạng thái đang xử lý; khóa thao tác lặp]
    S --> X{Người dùng thử lưu lặp?}

    X -- Có --> Y[Nguy cơ tạo trùng chứng từ mô phỏng hoặc hiểu sai kết quả xử lý]
    Y --> Y0[Dừng thao tác lặp]
    Y0 --> Y1[Không tự xóa dữ liệu]
    Y1 --> Y2[Đối chiếu mã tham chiếu do hệ thống trả về]
    Y2 --> Y3[Owner nghiệp vụ cùng kỹ thuật xác minh]
    Y3 --> Q{Đã có kết quả cuối?}

    X -- Không --> Q
    Q -- Chưa --> W[Chờ hoặc đối chiếu trạng thái xử lý; tiếp tục khóa thao tác lặp]
    W --> Q
    Q -- Rồi --> F{Kết quả cuối}

    F -- Thành công --> G[Rà tác động; cập nhật acceptance criteria, UI và test basis liên kết]
    F -- Lỗi hệ thống --> H[Hiển thị lỗi; giữ dữ liệu đã nhập]
    F -- Lỗi nghiệp vụ --> H
    F -- Mất kết nối --> H

    H --> G
    G --> R[Ghi nhận thay đổi và kết quả trong phạm vi IN_REVIEW]

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp.

Mục	Nội dung
Facts	Wireframe màn hình tạo Phiếu yêu cầu mua hàng có nút Lưu nháp và Gửi duyệt. Trường Số lượng hiển thị ví dụ 25.
Current Behavior	Tài liệu chỉ ghi “nhập số lượng và gửi duyệt”; không mô tả nhập 0, ký tự chữ, mất kết nối hoặc bấm Gửi duyệt hai lần.
Underlying Need	Người dùng cần biết dữ liệu nào được nhận và hệ thống phản hồi thế nào để không hiểu nhầm phiếu đã được gửi.
Options	1. Giữ wireframe ảnh tĩnh. 2. Thêm ghi chú hành vi cạnh từng thành phần. 3. Tạo đặc tả hành vi ngắn liên kết wireframe.
Decision Criteria	Phải kiểm tra được bởi QA, không tự tạo business rule, ít lặp nội dung và truy được nguồn.
Decision	Chọn phương án 3: mỗi nút và trường có hành vi ngắn, liên kết wireframe; quy tắc nghiệp vụ chỉ tham chiếu CANONICAL_BUSINESS_RULES khi catalog cung cấp ID phù hợp.
Authority	BA duy trì mô tả và traceability. Business Owner xác nhận ý nghĩa nghiệp vụ. Architect xác nhận lỗi tích hợp. QA xác nhận khả năng kiểm thử.
Artifact	/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu chỉ viết “Gửi duyệt thành công”, UI có thể báo thành công khi API thất bại. Người dùng tưởng phiếu mô phỏng đã vào hàng chờ duyệt; QA không có test âm để phát hiện.

Senior Lens

Đừng sửa bằng cách thêm nhiều chữ mơ hồ. Sửa tốt làm giảm số cách diễn giải. Ví dụ, “hiển thị lỗi phù hợp” không kiểm tra được; “khi API trả lỗi, giữ giá trị người dùng đã nhập, hiển thị trạng thái thất bại, không chuyển màn hình” kiểm tra được. Bằng chứng là QA có thể tạo phản hồi lỗi và quan sát ba kết quả riêng.

Sai lầm cấp delivery-team thường nằm ở handoff. Designer giao ảnh, BA giao mô tả rời, developer tự chọn hành vi, QA chỉ kiểm tra happy path. Dấu hiệu đỏ là cùng một màn hình có nhiều nguồn mô tả mà không chỉ rõ nguồn nào kiểm soát hành vi. Cách sửa ít nhất: chọn một artifact mô tả hành vi, còn wireframe chỉ tham chiếu đến artifact đó; không sao chép rule sang nhiều nơi.

Quick Reference

Kiểm tra trước khi đưa wireframe vào review	Đạt khi
Trường nhập	Có kiểu dữ liệu, điều kiện bắt buộc, kiểm tra và phản hồi lỗi
Nút thao tác	Có điều kiện hiển thị, điều kiện kích hoạt, kết quả thành công và thất bại
Trạng thái hệ thống	Có tải dữ liệu, dữ liệu rỗng, lỗi và ngăn bấm lặp khi cần
Quyền	Vai trò và hành động được tách rõ, không suy đoán quyền từ giao diện
Handoff	BA, UI, API và QA cùng tham chiếu hành vi kiểm tra được

Core

[!WARNING] Cảnh báo chỉ dùng khi lỗi có thể gây mất dữ liệu, sai quyền truy cập, sai trạng thái giao dịch, hoặc khiến đội triển khai hiểu màn hình mô phỏng là quyết định vận hành. Cảnh báo không dùng để nhấn mạnh sở thích giao diện.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Wireframe chỉ mô tả hành vi màn hình dự kiến; không xác nhận cấu hình ERP, tuân thủ pháp lý, quyền phê duyệt hay sẵn sàng production.

Tình huống có rủi ro thật	Dấu hiệu trên wireframe	Hậu quả có thể quan sát	Ranh giới khôi phục an toàn
Nút Xác nhận xuất kho không nêu trạng thái sau khi bấm	Không có trạng thái Đã ghi nhận, Chờ duyệt, Thất bại	Người dùng bấm lại; phát sinh hai yêu cầu xuất kho mô phỏng	Dừng thao tác gửi lại; tra cứu mã giao dịch mô phỏng trước; chỉ sửa wireframe, không suy diễn dữ liệu ERP thật
Màn hình hiển thị giá vốn cho vai trò không xác định	Trường Giá vốn luôn hiện, không có ghi chú quyền	Lộ dữ liệu nhạy cảm trong thiết kế hoặc test demo	Che dữ liệu tổng hợp; ghi Verification required cho ma trận quyền; Security Owner quyết định quyền thật
Nút xóa không có xác nhận và hậu quả	Nút Xóa đặt cạnh Lưu, không nêu dữ liệu bị ảnh hưởng	Mất dòng chi tiết đơn hàng hoặc mất bằng chứng thao tác mô phỏng	Đổi thành hành vi hủy có xác nhận; nêu rõ đối tượng bị tác động; không gọi đây là cơ chế xóa thật của ERP
Ghi “tuân thủ hóa đơn” trên màn hình	Wireframe gắn nhãn compliant nhưng không có nguồn, owner, phiên bản	Đội delivery coi ghi chú UI là kết luận pháp lý	Gỡ khẳng định; gắn Verification required; Legal Owner và Accounting Owner xác minh theo nguồn chính thức

Applied

Facts: Wireframe WF-NF-INV-01 mô tả màn hình tạo phiếu xuất kho mô phỏng cho đơn hàng SO-SYN-00017. Nút Xác nhận xuất kho đổi ngay sang thông báo Thành công; không mô tả kiểm tra tồn kho, lỗi mạng, hay thao tác bấm lặp.

Current Behavior: Người học thấy một kết quả thành công duy nhất. Evidence: wireframe không có trạng thái chờ xử lý, mã giao dịch, hay quy tắc chống gửi lặp. Reasoning: nếu hệ thống nhận hai yêu cầu nhưng UI chỉ hiển thị một kết quả, đội test không có cơ sở phân biệt một lần xuất hay hai lần xuất.

Underlying Need: Màn hình phải cho người dùng biết yêu cầu đã được nhận, bị từ chối, hay cần xử lý lại, nhưng không được tự tạo quy tắc tồn kho hoặc quy trình kho Nova Foods.

Options:

Phương án	Lợi ích	Rủi ro
Giữ thông báo Thành công tức thì	Wireframe ngắn	Che lỗi gửi lặp và lỗi xử lý
Hiển thị trạng thái Đang gửi rồi Đã ghi nhận yêu cầu	Phân biệt thao tác UI và kết quả xử lý	Cần mô tả trạng thái tối thiểu
Ghi “đã xuất kho” ngay khi bấm	Dễ hiểu bề mặt	Khẳng định trạng thái nghiệp vụ chưa có bằng chứng

Decision Criteria: Chọn phương án không khẳng định kết quả nghiệp vụ vượt dữ liệu wireframe; hỗ trợ test trạng thái; không thay thẩm quyền Warehouse Owner.

Decision: Dùng Đang gửi trong lúc gửi yêu cầu. Khi nhận phản hồi hợp lệ, hiển thị Đã ghi nhận yêu cầu xuất kho cùng mã giao dịch tổng hợp. Khi lỗi, hiển thị lỗi và cho phép gửi lại sau khi người dùng kiểm tra mã giao dịch.

Authority: Business Owner hoặc Warehouse Owner xác nhận ý nghĩa trạng thái nghiệp vụ. Architect xác nhận cơ chế chống gửi lặp. QA xác nhận test case. BA chỉ ghi nhận hành vi và điểm cần xác minh.

Artifact: Cập nhật WF-NF-INV-01 trong /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md; giữ Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Nếu gọi Đã ghi nhận yêu cầu là Đã xuất kho, người dùng và đội delivery có thể hiểu sai thời điểm giảm tồn kho. Không được dùng wireframe này làm bằng chứng xuất kho, chứng từ, hoặc tuân thủ.

Source mermaid — có thể chỉnh sửa

stateDiagram-v2
    direction TB

    [*] --> NhapThongTin
    NhapThongTin --> DangGui: Người dùng chọn Xác nhận xuất kho
    DangGui --> DaGhiNhan: Nhận phản hồi hợp lệ
    DangGui --> LoiGui: Nhận lỗi hoặc hết thời gian chờ
    LoiGui --> KiemTraMaGiaoDich: Người dùng kiểm tra mã giao dịch
    KiemTraMaGiaoDich --> DangGui: Gửi lại [Architect xác minh chống gửi lặp]
    DaGhiNhan --> [*]

    state "Nhập thông tin phiếu xuất kho" as NhapThongTin
    state "Đang gửi" as DangGui
    state "Đã ghi nhận yêu cầu xuất kho\nMã giao dịch tổng hợp\nKhông phải bằng chứng đã xuất kho" as DaGhiNhan
    state "Hiển thị lỗi" as LoiGui
    state "Kiểm tra mã giao dịch" as KiemTraMaGiaoDich

Senior Lens

[!WARNING] Không ghi “đã được phê duyệt”, “đúng quy định”, “đã tuân thủ”, hoặc “hệ thống sẽ tự động” nếu artifact không có bằng chứng, nguồn canonical, vai trò có thẩm quyền và tham chiếu approval. IN_REVIEW tại v0.9.0 không phải approval hay baseline.

Khôi phục an toàn bắt đầu bằng việc hạ cấp tuyên bố sai thành mô tả trung tính. Ví dụ, thay “Nova Foods bắt buộc khóa sửa phiếu sau xuất kho” bằng “Wireframe giả định khóa sửa sau khi trạng thái xuất kho được xác nhận; Verification required bởi Warehouse Owner và Accounting Owner.” Giữ nguyên ID, filename và lịch sử thay đổi; không sửa im lặng để tạo cảm giác nội dung từng được xác nhận.

Quick Reference

Khi nào dùng warning	Nội dung tối thiểu	Không được làm
Có thể mất dữ liệu hoặc gửi lặp	Hành vi nguy hiểm, hậu quả, bước dừng an toàn	Gọi hành vi mô phỏng là cấu hình ERP thật
Có thể lộ dữ liệu hoặc sai quyền	Loại dữ liệu, điểm hiển thị, owner cần xác minh	Tự quyết ma trận quyền
Có thể tạo hiểu lầm pháp lý, kế toán, hóa đơn, an toàn thực phẩm	Nhãn Verification required, nguồn cần kiểm tra, owner có thẩm quyền	Suy diễn nghĩa vụ từ wireframe
Lỗi chỉ là căn chỉnh, màu sắc, câu chữ	Ghi chú UI thường	Dùng warning để tăng sức nặng cá nhân

Core

Năm lỗi khác nhau, không được gộp thành “chưa rõ yêu cầu”. Mơ hồ là câu có nhiều cách hiểu; không đầy đủ là thiếu thông tin cần để xây, kiểm thử hoặc vận hành; khẳng định thẩm quyền không có bằng chứng là gọi nội dung đã phê duyệt, tuân thủ hoặc bắt buộc khi artifact không ghi nhận; dùng sai ký pháp là nhãn sơ đồ không đúng chuẩn; đứt truy vết là không nối được màn hình với nguồn rule, dữ liệu và kiểm thử.

Loại lỗi	Dấu hiệu quan sát	Nguyên nhân gốc	Sửa an toàn
Mơ hồ	Wireframe ghi “hiển thị cảnh báo phù hợp”	Không xác định điều kiện, nội dung, vị trí, thời điểm	Viết điều kiện kích hoạt, thông điệp, hành vi người dùng và trạng thái sau xử lý
Không đầy đủ	Có nút Lưu nhưng không nêu dữ liệu bắt buộc, lỗi, quyền	Nhóm chỉ mô tả giao diện bình thường	Bổ sung trạng thái hợp lệ, không hợp lệ, không có quyền, lỗi hệ thống và dữ liệu rỗng
Thẩm quyền không có bằng chứng	Ghi “đã được Finance phê duyệt”	Nhầm ý kiến workshop với approval được kiểm soát	Đổi thành “Verification required”; ghi owner cần xác nhận và artifact cần lưu bằng chứng
Sai ký pháp	Gọi sơ đồ PlantUML activity là BPMN	Dùng công cụ thay cho chuẩn ký pháp	Gọi đúng tên sơ đồ; chỉ gọi BPMN khi dùng phần tử BPMN 2.0.2 đúng nghĩa
Đứt truy vết	Trường UI không có ID rule hoặc data element	Copy wireframe giữa màn hình, không kiểm ID canonical	Liên kết đúng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY

Cảnh báo: Sai thẩm quyền hoặc đứt truy vết có thể biến giả định học liệu thành quyết định ERP. Trong corpus Nova Foods mô phỏng, IN_REVIEW và v0.9.0 không phải approval, baseline, compliance hay quyền dùng production.

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp. Wireframe màn hình xác nhận xuất kho ghi: “Nếu tồn kho thấp, hiển thị cảnh báo và chặn xuất.” Không có ngưỡng, nguồn tồn kho, vai trò được chặn, rule ID hoặc test basis.

Current Behavior: Developer có thể hiểu “thấp” là dưới 10 đơn vị; QA có thể kiểm dưới 0; vận hành có thể hiểu chặn mọi người dùng. Ba cách hiểu cùng phù hợp câu gốc, nên câu gốc mơ hồ.

Underlying Need: Màn hình cần cho người dùng biết khi nào thao tác bị chặn và cần dữ liệu nào để quyết định. Nhưng rule tồn kho chưa được xác nhận trong CANONICAL_BUSINESS_RULES; BA không có thẩm quyền tự đặt ngưỡng.

Options: (1) Tự ghi ngưỡng 10; (2) bỏ cảnh báo; (3) giữ hành vi dưới nhãn Verification required, liên kết owner và artifact nguồn.

Decision Criteria: Chọn phương án giữ được tính kiểm thử, không tạo rule mới, không tuyên bố approval, và cho phép thay rule sau review.

Decision: Chọn (3). Wireframe ghi: “Khi dịch vụ tồn kho trả về trạng thái không đủ theo rule được xác nhận, hệ thống chặn Xác nhận xuất kho, hiển thị lý do trả về và không tạo chứng từ xuất.” Ngưỡng, nguồn số lượng khả dụng và ngoại lệ quyền phải có rule canonical trước khi build.

Authority: Business Owner xác nhận chính sách xuất kho; Accounting Owner xác nhận ảnh hưởng chứng từ; Architect xác nhận nguồn dữ liệu và tích hợp. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì truy vết.

Artifact: Liên kết wireframe tới /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, và /01-curriculum/TRACEABILITY_ID_REGISTRY.md; trạng thái liên kết: Verification required.

Consequence if Wrong: Tự đặt ngưỡng có thể chặn đơn hợp lệ hoặc cho xuất vượt chính sách mô phỏng. Phục hồi an toàn: không phát hành rule suy diễn; trả màn hình về trạng thái IN_REVIEW; ghi khoảng trống nguồn và chuyển đúng owner xác nhận.

Source mermaid — có thể chỉnh sửa

flowchart TB
    W["Wireframe: Xác nhận xuất kho"] --> V["Trạng thái liên kết:<br/>Verification required"]

    V --> CR["CANONICAL_BUSINESS_RULES.md<br/>Thiếu rule ID, ngưỡng và ngoại lệ quyền"]
    V --> DD["CANONICAL_DATA_DICTIONARY.md<br/>Thiếu nguồn số lượng khả dụng"]
    V --> TR["TRACEABILITY_ID_REGISTRY.md"]

    BA["Principal IT Business Analyst /<br/>Technical Curriculum Author"] -->|"Chỉ duy trì truy vết"| TR

    CR --> DEP["Dependency bắt buộc trước build"]
    DD --> DEP
    TR --> DEP

    BO["Business Owner<br/>Xác nhận chính sách xuất kho"] --> G
    AO["Accounting Owner<br/>Xác nhận ảnh hưởng chứng từ"] --> G
    AR["Architect<br/>Xác nhận nguồn dữ liệu và tích hợp"] --> G
    DEP --> G{"Đủ xác nhận của cả 3 owner?"}

    G -->|"Chưa"| NOAPP["Không có approval<br/>Không build<br/>Giữ Verification required"]
    NOAPP -->|"Ghi khoảng trống nguồn"| TR

    G -->|"Đủ"| UPDATE["Ghi rule và nguồn dữ liệu đã xác nhận<br/>vào canonical artifacts"]
    UPDATE --> REG["Cập nhật registry<br/>Chuyển khỏi Verification required"]
    REG --> READY["Đủ điều kiện build<br/>Test basis được hình thành"]

    READY --> LOW["Dịch vụ tồn kho trả trạng thái không đủ<br/>theo rule đã xác nhận"]
    LOW --> BLOCK["Chặn Xác nhận xuất kho"]
    LOW --> REASON["Hiển thị lý do dịch vụ trả về"]
    LOW --> NODOC["Không tạo chứng từ xuất"]

    READY -->|"Phát hiện rule suy diễn<br/>hoặc phát hành sai"| WRONG["Rule không có nguồn xác nhận"]
    WRONG --> CONSEQUENCE["Có thể chặn đơn hợp lệ<br/>hoặc cho xuất vượt chính sách mô phỏng"]
    CONSEQUENCE --> RECOVERY["Phục hồi an toàn:<br/>Đưa màn hình về IN_REVIEW<br/>Ghi khoảng trống nguồn<br/>Chuyển đúng owner xác nhận"]
    RECOVERY --> TR

Senior Lens

Không dùng từ “bắt buộc”, “tuân thủ”, “đã phê duyệt”, “đã baseline” nếu artifact nguồn không có bằng chứng kiểm soát tương ứng. Nguồn pháp lý trong corpus chỉ định hướng nghiên cứu; diễn giải áp dụng cho hệ thống cần Legal Owner hoặc owner chuyên môn xác nhận. Đây là ranh giới giữa BA ghi nhận yêu cầu và người có thẩm quyền quyết định.

PlantUML activity diagram mô tả luồng hoạt động, không tự trở thành BPMN. BPMN 2.0.2 là chuẩn ký pháp riêng của OMG. Tương tự, bảng wireframe không phải data dictionary: bảng chỉ hiển thị trường; data dictionary mới định nghĩa ý nghĩa, kiểu dữ liệu, miền giá trị và nguồn dữ liệu.

Quick Reference

Kiểm tra trước khi giữ nội dung wireframe	Kết quả đạt
Một câu chỉ có một cách hiểu kiểm thử được?	Có điều kiện, dữ liệu vào, hành vi, kết quả
Màn hình có đủ trạng thái lỗi và quyền?	Có trạng thái rỗng, lỗi, không quyền, thành công
Rule có ID và nguồn canonical?	Giữ đúng ID, không tự tạo biến thể
Câu có tuyên bố approval hoặc compliance?	Có bằng chứng artifact, nếu không ghi Verification required
Sơ đồ có tên đúng ký pháp?	BPMN chỉ dùng cho BPMN; PlantUML gọi PlantUML
Trường UI nối được tới rule, data và test?	Không có liên kết mồ côi

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không chọn UI chỉ vì “dễ dùng” cho một nhóm. Wireframe là giả thuyết về hành vi màn hình; quyết định chỉ đứng vững khi nối được nhu cầu, bằng chứng, rủi ro và người có thẩm quyền. Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không có baseline hoặc approval được ghi nhận.

Tình huống trade-off	Lợi ích	Đổi giá phải kiểm soát	Bằng chứng cần có	Quyền quyết định
Hiển thị nút “Xác nhận xuất kho” ngay trên danh sách	Thao tác nhanh hơn	Có thể xác nhận nhầm nhiều dòng hoặc vượt quyền	Luồng nghiệp vụ, quyền vai trò, tiêu chí chấp nhận, kịch bản lỗi	Business Owner quyết định nghiệp vụ; Security Owner xác nhận quyền; QA xác nhận kiểm thử
Ẩn giá vốn khỏi màn hình kho	Giảm lộ dữ liệu nhạy cảm	Kế toán có thể thiếu thông tin đối chiếu	Phân loại dữ liệu, ma trận quyền, nhu cầu đối chiếu	Accounting Owner và Security Owner
Bắt buộc nhập lý do hủy phiếu	Tăng truy vết	Làm chậm xử lý ngoại lệ khẩn cấp	Rule canonical hoặc quyết định nghiệp vụ có nguồn	Business Owner; Legal/Compliance Owner nếu liên quan nghĩa vụ pháp lý
Dùng một màn hình cho kho và kế toán	Ít màn hình, ít đào tạo	Quá tải trường, tăng lỗi thao tác, khó kiểm soát quyền	Mục tiêu tác vụ từng vai trò, quan sát quy trình, dữ liệu cần xem	Business Owner và Architect

Ngoại lệ không phá quy tắc; ngoại lệ phải có điều kiện kích hoạt, thời hạn, dấu vết và owner. Ví dụ, quy tắc thường là không cho sửa số lượng sau khi xác nhận xuất kho. Nếu vận hành mô phỏng nêu tình huống hàng hỏng cần điều chỉnh, Senior BA không tự thêm nút “Sửa”. Cần tách câu hỏi: có được điều chỉnh không, ai được điều chỉnh, điều chỉnh tạo chứng từ nào, dữ liệu cũ được giữ thế nào, và ai chịu trách nhiệm quyết định. Nếu thiếu rule canonical trong /01-curriculum/CANONICAL_BUSINESS_RULES.md, ghi Verification required; không biến giả định thành hành vi màn hình.

Xung đột stakeholder thường lộ ra dưới dạng yêu cầu UI. Kho có thể muốn một chạm để nhanh; kế toán muốn khóa để bảo toàn số liệu; Security muốn phân quyền chặt; QA muốn trạng thái xác định để kiểm thử. Senior BA chuyển tranh luận từ sở thích sang tiêu chí: tần suất tác vụ, hậu quả khi sai, khả năng hoàn tác, dữ liệu bị ảnh hưởng, quyền truy cập và bằng chứng nguồn. BA tổng hợp phương án, tác động và điểm chưa rõ; không thay Business Owner, Accounting Owner, Security Owner, Architect, Legal Owner hoặc QA quyết định phần thuộc thẩm quyền họ.

Chất lượng bằng chứng	Cách dùng trong wireframe	Giới hạn
Rule hoặc data element canonical có ID, nguồn và trạng thái kiểm soát	Liên kết trường, điều kiện hiển thị, kiểm tra hợp lệ	IN_REVIEW không chứng minh rule đã được phê duyệt
Nguồn chuẩn hoặc pháp lý chính thức	Xác định điểm cần xác minh chuyên môn	Không tự diễn giải thành nghĩa vụ cấu hình ERP
Ý kiến stakeholder chưa được ghi nhận thành quyết định có thẩm quyền	Ghi là input hoặc giả định dự án	Không ghi “bắt buộc”, “tuân thủ” hoặc “đã phê duyệt”
Suy luận từ layout hoặc màn hình cũ	Dùng để đặt câu hỏi	Không phải nguồn chân lý cho business rule

Dấu hiệu đỏ: một trường UI không nối tới data dictionary; nút hành động không có trạng thái lỗi, không quyền hoặc thành công; cùng một trường đổi nhãn giữa màn hình; yêu cầu “ẩn cho an toàn” nhưng không có phân loại dữ liệu; yêu cầu liên quan thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc nhưng thiếu owner chuyên môn. Escalate khi lựa chọn UI làm thay đổi quyền phê duyệt, tạo hoặc sửa dữ liệu kế toán, quyết định lưu dữ liệu cá nhân, thay đổi traceability, hoặc có hai owner đưa chỉ dẫn mâu thuẫn.

Khuyến nghị phòng thủ phải ghi rõ mức chắc chắn. Mẫu ghi nhận: “Khuyến nghị giữ nút xác nhận ở trang chi tiết, không cho xác nhận hàng loạt. Lý do: giảm rủi ro chọn nhầm khi tác vụ ảnh hưởng tồn kho; bằng chứng hiện có là wireframe và nhu cầu thao tác mô phỏng. Verification required: Business Owner xác nhận luồng, Security Owner xác nhận quyền, QA xác nhận tiêu chí kiểm thử.” Câu này phân biệt fact, suy luận và việc chưa xác minh; không bịa certainty hoặc approval.

Senior Lens

Senior BA rà wireframe bằng câu hỏi: “Màn hình này có giúp đúng vai trò ra quyết định đúng lúc, với dữ liệu đủ tin cậy, mà không tạo quy tắc mới không?” Wireframe là mô tả giao diện dự kiến, không phải bằng chứng rằng quy trình, quyền, luật hay tích hợp đã được chấp thuận. Với Nova Foods là case mô phỏng, dữ liệu tổng hợp, mọi nhận định chỉ giữ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Heuristic rà soát	Bằng chứng cần thấy	Red flag	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Một màn hình phục vụ một quyết định chính	Tên màn hình, vai trò, hành động chính, trạng thái trước và sau	Có nhiều nút “Duyệt”, “Lưu”, “Xuất”, nhưng không rõ hành động nào đổi trạng thái	Một thao tác có thể tạo cam kết tài chính, điều chỉnh tồn kho, phát hành chứng từ hoặc khóa dữ liệu	Dashboard chỉ đọc có thể hiển thị nhiều chỉ số nếu không cho phép thay đổi dữ liệu
Hiển thị dữ liệu theo nhu cầu quyết định	Trường dữ liệu liên kết CANONICAL_DATA_DICTIONARY hoặc có nhãn Verification required	Thêm trường vì “có thể cần”, không có nguồn hay người dùng tiêu thụ	Trường mới tác động dữ liệu cá nhân, kế toán, truy xuất thực phẩm, API hoặc phân quyền	Trường kỹ thuật bắt buộc cho vận hành hệ thống được Architect xác nhận trong artifact phù hợp
Hành động nguy hiểm phải có kiểm soát	Điều kiện kích hoạt, cảnh báo, quyền, kết quả thành công và thất bại	Nút xóa, hủy, duyệt hoặc gửi không nêu hậu quả và khả năng khôi phục	Hành động không thể đảo ngược, thay đổi sổ sách, tồn kho, giá, quyền truy cập hoặc dữ liệu cá nhân	Không dùng hộp xác nhận làm thay thế cho phân quyền hay business rule
Trạng thái giao diện khớp trạng thái nghiệp vụ	State source, quy tắc chuyển trạng thái, thông báo lỗi	Nhãn “Đã duyệt” trên màn hình nhưng không có nguồn trạng thái canonical	Mâu thuẫn với CANONICAL_BUSINESS_RULES, tích hợp hoặc traceability ID	Bản nháp wireframe được phép dùng trạng thái giả định, nhưng phải ghi rõ Project assumption
Lỗi giúp người dùng sửa đúng dữ liệu	Điều kiện lỗi, trường lỗi, cách sửa, dữ liệu được giữ lại	Thông báo chung như “Có lỗi xảy ra”; xóa dữ liệu người dùng đã nhập	Lỗi có thể làm mất dữ liệu, gửi trùng giao dịch hoặc che giấu lỗi tích hợp	Không hiển thị chi tiết kỹ thuật nhạy cảm cho người dùng cuối; ghi mã tham chiếu an toàn thay thế
Khả năng tiếp cận được xét từ luồng chính	Nhãn trường, thứ tự bàn phím, trạng thái không chỉ dựa màu, thông báo lỗi	Chỉ dùng đỏ/xanh để nói đúng sai; icon không có nhãn	Luồng bắt buộc không thao tác được bằng bàn phím hoặc lỗi không được nhận biết	Wireframe thấp độ trung thực chưa cần chứng minh mã HTML, nhưng phải nêu hành vi cần kiểm tra theo WCAG 2.2

Escalate khi tranh chấp không còn là câu hỏi bố cục. Business Owner quyết định ưu tiên nghiệp vụ; Architect quyết định giới hạn kỹ thuật và tích hợp; Security quyết định kiểm soát truy cập, dữ liệu nhạy cảm; Accounting Owner hoặc Legal Owner xác nhận diễn giải thuộc kế toán hoặc pháp luật; QA xác nhận testability. Senior BA không chọn thay các vai trò này. Senior BA ghi vấn đề, phương án, tác động, bằng chứng và owner quyết định trong artifact truy vết phù hợp.

Không áp dụng quy tắc “giảm số trường đến tối thiểu” khi việc ẩn trường làm người dùng không thể kiểm tra định danh giao dịch, đơn vị tính, trạng thái hoặc nguồn dữ liệu trước khi thực hiện hành động có hậu quả. Không áp dụng quy tắc “gộp thao tác vào một màn hình” khi tách bước giảm nguy cơ duyệt nhầm, lộ dữ liệu hoặc bỏ qua kiểm soát. Không áp dụng quy tắc “dùng modal xác nhận” cho hành động cần phê duyệt theo vai trò; modal chỉ xác nhận ý định, không chứng minh thẩm quyền.

Senior Lens

Senior BA không biến thiếu bằng chứng thành kết luận. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, khuyến nghị phải tách rõ: sự kiện quan sát được, suy luận, giả định dự án, điểm cần xác minh, người có thẩm quyền quyết định. Cầu nối suy luận phải đọc được: bằng chứng nào dẫn đến rủi ro nào, rủi ro nào làm cần quyết định nào.

Thành phần ghi nhận	Nội dung bắt buộc	Cách viết không ngụy tạo chắc chắn
Fact	Dữ liệu hoặc hành vi màn hình đã quan sát, kèm nguồn artifact	“Wireframe WF-INV-014 cho thấy nút Hủy phiếu xuất hiện khi trạng thái Đã ghi sổ.”
Inference	Diễn giải BA từ Fact, không gọi là quy tắc đã xác nhận	“Nếu người dùng hủy sau ghi sổ, số tồn và chứng từ liên quan có thể mất nhất quán.”
Assumption	Điều tạm dùng để thiết kế tiếp, có phạm vi	“Giả định dự án: trạng thái Đã ghi sổ không cho hủy trực tiếp.”
Verification required	Câu hỏi, bằng chứng cần lấy, vai trò phải xác minh	“Cần Accounting Owner xác minh cách đảo chứng từ; không suy diễn từ wireframe.”
Recommendation	Phương án đề xuất, tiêu chí và giới hạn	“Đề xuất khóa nút Hủy phiếu tại Đã ghi sổ, hiển thị hướng dẫn tạo chứng từ đảo, chờ xác nhận nghiệp vụ và kế toán.”
Decision status	Trạng thái thật của quyết định	“IN_REVIEW tại v0.9.0, không phải baseline, không phải approval.”

Mẫu ghi trong phần ghi chú của wireframe:

Khuyến nghị BA: Khóa thao tác Hủy phiếu khi phiếu đạt trạng thái Đã ghi sổ.
Bằng chứng: Wireframe WF-INV-014 có thao tác hủy nhưng chưa định nghĩa hành vi theo trạng thái; /01-curriculum/CANONICAL_BUSINESS_RULES.md đang IN_REVIEW, không xác nhận quy tắc hủy.
Lý do: Hủy trực tiếp sau ghi sổ có thể ảnh hưởng số liệu tồn kho và chứng từ; mức ảnh hưởng này là suy luận thiết kế, chưa là kết luận kế toán.
Điều kiện: Accounting Owner và Business Owner xác minh quy trình đảo hoặc điều chỉnh. Legal hoặc Accounting Owner phải xác minh mọi diễn giải nghĩa vụ kế toán.
Trạng thái: Verification required; không mô tả là đã được phê duyệt.

Không viết “hệ thống phải tuân thủ luật” khi chưa có yêu cầu được Legal Owner xác minh. Viết: “Yêu cầu pháp lý có thể liên quan; cần Legal Owner xác minh đối chiếu Luật Kế toán và nguồn hiện hành trước khi dùng làm yêu cầu triển khai.” Nguồn pháp lý định hướng kiểm tra, không trao thẩm quyền kết luận cho BA.

Khuyến nghị có thể bị bác bỏ vẫn là khuyến nghị tốt nếu lưu đủ bằng chứng, tiêu chí, phương án bị loại và thẩm quyền cần quyết định. Mục tiêu không phải đoán đúng thay người quyết định. Mục tiêu là làm rõ quyết định nào còn mở, vì sao còn mở, và hậu quả nào cần được người có thẩm quyền chấp nhận.

12. Associated Template Reference & Completed Artifact

Core

Template là khuôn tệp lặp lại để BA ghi wireframe, hành vi màn hình và quy tắc UI nhất quán. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Tại v0.9.0, IN_REVIEW, chỉ được dùng template đã có ID và đường dẫn canonical. Không tự đặt ID template mới vì làm đứt truy vết với TEMPLATE_MANIFEST.

Applied

Thành phần	Nội dung
Facts	Chapter mô tả wireframe, screen behavior và UI rules. Nguồn dependency xác nhận TEMPLATE_MANIFEST là danh mục template dự kiến, nhưng không cung cấp ID và tên tệp template wireframe riêng trong phạm vi đầu vào này.
Current Behavior	BA có thể tham chiếu artifact quản trị và các catalog canonical; chưa được gọi một tệp chưa đăng ký là template chính thức.
Underlying Need	Người viết cần biết đúng nơi lấy khuôn, ai duy trì, ai dùng và tiêu chí nào chặn việc dùng sai tệp.
Options	Dùng template chưa đăng ký; tự tạo ID; chỉ tham chiếu TEMPLATE_MANIFEST và artifact canonical đã xác minh.
Decision Criteria	Giữ ID, filename, trạng thái và source boundary; không tạo approval ngầm định; không biến nội dung mô phỏng thành cấu hình ERP.
Decision	Dùng TEMPLATE_MANIFEST làm điểm vào template. Chỉ dùng template wireframe khi manifest công bố ID và filename canonical.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì manifest. Business Owner, Architect, QA Reviewer xác nhận nội dung thuộc thẩm quyền họ.
Artifact	/01-curriculum/TEMPLATE_MANIFEST.md; các artifact canonical trong bảng Quick Reference.
Consequence if Wrong	Dùng tệp không đăng ký tạo bản sao nguồn chân lý, mất traceability, hoặc bị hiểu sai là requirement đã được phê duyệt.

Source mermaid — có thể chỉnh sửa

flowchart TB
  A[BA cần wireframe hoặc UI rule] --> B[TEMPLATE_MANIFEST]
  B --> C{Manifest có ID và filename canonical?}

  C -- Có --> D[Dùng template đã đăng ký]
  D --> E[Business Owner, Architect, QA Reviewer xác nhận nội dung thuộc thẩm quyền]
  E --> F[QA kiểm tra traceability]

  C -- Không --> G[Chỉ tham chiếu /01-curriculum/TEMPLATE_MANIFEST.md và artifact canonical đã xác minh]
  G --> H[Chặn dùng tệp chưa đăng ký]
  H --> I[Tránh bản sao nguồn chân lý, mất traceability, hiểu sai requirement đã phê duyệt]

  J[Principal IT Business Analyst / Technical Curriculum Author duy trì manifest] -. governance .-> B

Senior Lens

Bằng chứng quyết định là dependency /01-curriculum/TEMPLATE_MANIFEST.md xác nhận artifact này quản lý danh mục template dự kiến và đang IN_REVIEW; đầu vào không công bố template ID riêng cho wireframe. Vì thiếu bằng chứng đăng ký, việc tự suy ra tên như WF_TEMPLATE sẽ là fabricated identifier. BA senior giữ khoảng trống này rõ ràng: không dùng tệp cá nhân làm canonical, không đổi filename để “đồng bộ”, không diễn giải IN_REVIEW thành baseline hoặc approval.

Quick Reference

ID / filename canonical	Dùng khi	Không dùng khi	Owner	Consumers	Quality gate
TEMPLATE_MANIFEST /01-curriculum/TEMPLATE_MANIFEST.md	Cần xác định template nào được quy hoạch, ID nào đã đăng ký, dependency và boundary sử dụng	Không dùng thay wireframe đã điền hoặc thay quyết định nghiệp vụ	Principal IT Business Analyst / Technical Curriculum Author	BA author, curriculum author, QA reviewer	ID, filename, status IN_REVIEW, version v0.9.0 phải khớp manifest; không suy ra template riêng khi manifest chưa công bố
TRACEABILITY_ID_REGISTRY /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Cần kiểm tra định danh liên kết giữa wireframe, rule, requirement, test basis	Không dùng để tạo ID mới ngoài quy tắc registry	Principal IT Business Analyst / Technical Curriculum Author	BA, QA reviewer, technical architect	Giữ nguyên canonical ID; phát hiện xung đột ID phải escalation
CANONICAL_BUSINESS_RULES /01-curriculum/CANONICAL_BUSINESS_RULES.md	UI behavior phụ thuộc trạng thái, quyền, validation hoặc business rule	Không dùng làm bằng chứng rule đã được Business Owner phê duyệt	Principal IT Business Analyst / Technical Curriculum Author	BA, Business Owner, QA reviewer, developer	Rule reference đúng ID; IN_REVIEW không bị ghi thành approved hoặc baselined
CANONICAL_DATA_DICTIONARY /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Màn hình hiển thị, nhập, lọc hoặc kiểm tra trường dữ liệu	Không dùng thay data model vật lý, schema DB hoặc API contract	Principal IT Business Analyst / Technical Curriculum Author	BA, data analyst, developer, QA reviewer	Tên trường và ý nghĩa logic khớp dictionary; không tự suy ra kiểu dữ liệu kỹ thuật
CHAPTER_MANIFEST /01-curriculum/CHAPTER_MANIFEST.md	Cần xác nhận chapter, filename handbook và dependency cấp curriculum	Không dùng làm template nội dung wireframe	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, QA reviewer	Đúng chapter và controlled path; không đổi cấu trúc chapter ngoài manifest

Quick Reference

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Artifact đã điền của chapter nằm tại /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md, mục 8. Detailed Worked Example. Lý do: blueprint chapter chỉ định mục 8 là nơi trình bày ví dụ hoàn chỉnh; mục 12 chỉ cung cấp đường dẫn tra cứu, không tạo bản sao artifact.

Mục tra cứu	Vị trí canonical	Kiểm tra phải đạt
Định danh chapter và đường dẫn	/01-curriculum/CHAPTER_MANIFEST.md	Filename khớp /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md; không đổi ID hoặc tên file
Cấu trúc 12 mục	/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md	Có đủ 12 H2 blueprint, đúng thứ tự; không thêm H2 ngoài blueprint
Ví dụ Nova Foods đã điền	/02-handbook/14-wireframes-screen-behavior-and-ui-rules.md, mục 8. Detailed Worked Example	Có Facts, Current Behavior, Underlying Need, Options, Decision Criteria, Decision, Authority, Artifact, Consequence if Wrong; dữ liệu tổng hợp
Template được phép liên kết	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ dùng template ID và filename đã đăng ký; không suy ra template chưa được manifest ghi nhận
ID truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Giữ nguyên canonical ID; không tự tạo biến thể ID cho screen, rule, requirement hoặc test
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Không biến giả định học liệu thành quy tắc vận hành Nova Foods
Thuật ngữ dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Field, entity, trạng thái, mã và định nghĩa dùng đúng nguồn canonical
Nguồn và ranh giới dùng nguồn	/00-research/00_SOURCE_MAP.md	Không gán điều khoản, nghĩa vụ pháp lý, chuẩn tuân thủ khi chưa xác minh nguồn chính thức
Kiến trúc curriculum	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Wireframe phục vụ chuỗi requirement, acceptance criteria, traceability và test basis; không thành thiết kế production
Trạng thái quản trị	Metadata các artifact trên	Đồng nhất IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND

Source mermaid — có thể chỉnh sửa

flowchart TB
  A[Người sửa artifact mở handbook, mục 8] --> B{Chapter manifest: ID và filename khớp?}
  B -- Không đạt --> X[Xác định nguồn kiểm soát của mục lệch]
  B -- Đạt --> C{Handbook: đủ 12 H2 blueprint, đúng thứ tự?}

  C -- Không đạt --> X
  C -- Đạt --> D{Mục 8: đủ Facts, Current Behavior, Underlying Need, Options, Decision Criteria, Decision, Authority, Artifact, Consequence if Wrong?}

  D -- Không đạt --> X
  D -- Đạt --> E{TEMPLATE_MANIFEST: chỉ dùng template ID và filename đã đăng ký?}

  E -- Không đạt --> X
  E -- Đạt --> F{ID registry: dùng canonical ID, không tạo biến thể?}

  F -- Không đạt --> X
  F -- Đạt --> G{Business rules: không biến giả định học liệu thành quy tắc vận hành?}

  G -- Không đạt --> X
  G -- Đạt --> H{Data dictionary: field, entity, trạng thái, mã, định nghĩa đúng canonical?}

  H -- Không đạt --> X
  H -- Đạt --> I{Source map: nguồn chính thức xác minh trước khi gán nghĩa vụ hoặc chuẩn tuân thủ?}

  I -- Không đạt --> X
  I -- Đạt --> J{Curriculum architecture: wireframe hỗ trợ requirement, acceptance criteria, traceability, test basis; không thành thiết kế production?}

  J -- Không đạt --> X
  J -- Đạt --> K{Metadata: IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND khớp?}

  K -- Không đạt --> X
  K -- Đạt --> L[Artifact Nova Foods mô phỏng đạt kiểm tra và giữ IN_REVIEW]

  X --> Y[Cập nhật nguồn kiểm soát phù hợp]
  Y --> Z[Liên kết lại từ chapter]
  Z --> A

Không sao chép toàn bộ registry vào chapter. Lý do: registry là nguồn canonical; bản sao dễ lệch ID, version hoặc trạng thái. Khi artifact cần sửa, cập nhật đúng nguồn kiểm soát rồi liên kết lại từ chapter.

Core

Rà soát liên tệp kiểm tra cùng một thông tin có giữ nguyên ID, tên tệp, trạng thái, phiên bản, phạm vi nguồn và ranh giới thẩm quyền trong các artifact liên quan hay không. Bằng chứng: CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY cùng ghi IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND, Nova Foods là mô phỏng và dữ liệu tổng hợp. Suy ra chapter không được gọi nội dung là baseline, approved, compliant hoặc production-ready.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Soát chapter hiện hành] --> B[Đối chiếu CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY]
    B --> C[Kiểm tra ID, tên tệp, trạng thái, phiên bản, ngày, locale, múi giờ, tiền tệ, phạm vi nguồn, ranh giới thẩm quyền]
    C --> D{Có mâu thuẫn?}
    D -- Không --> E[Ghi kết quả: nhất quán nhưng vẫn IN_REVIEW]
    D -- Có --> F[Ghi open issue kèm bằng chứng]
    F --> G[Chuyển open issue cho owner có thẩm quyền theo manifest]
    G --> H[Giữ trạng thái IN_REVIEW]
    E --> I[Không gắn nhãn baseline, approved, compliant hoặc production-ready]
    H --> I

Applied

Facts: /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md mô tả wireframe và hành vi màn hình cho Nova Foods mô phỏng. TRACEABILITY_ID_REGISTRY là nguồn canonical cho ID; CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY là nguồn canonical cho quy tắc và dữ liệu logic.

Current Behavior: chapter tham chiếu artifact upstream, nhưng không có quyền tự chốt quy tắc nghiệp vụ, nghĩa vụ pháp lý, hạch toán, bảo mật hay cấu hình ERP.

Underlying Need: người đọc cần biết phần nào nhất quán, phần nào còn mở, ai phải xác minh trước handoff.

Options: (1) tự sửa chapter để khép khoảng trống; (2) ghi rõ vấn đề, giữ nhãn Verification required, escalation đúng owner.

Decision Criteria: chọn phương án không đổi ID canonical, không biến giả định thành yêu cầu bắt buộc, không vượt thẩm quyền.

Decision: chọn phương án (2). Bằng chứng: mọi artifact nguồn đang IN_REVIEW; không có baseline reference hoặc approval reference.

Authority: Principal IT Business Analyst / Technical Curriculum Author điều phối review và traceability. Business Owner xác nhận ý nghĩa nghiệp vụ. Solution Architect xác nhận khả thi kỹ thuật. QA Reviewer xác nhận testability. Legal Owner, Accounting Owner, Security Owner xác nhận nội dung thuộc chuyên môn tương ứng.

Artifact: ghi review trước handoff trong /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md; không tạo artifact thay thế nguồn canonical.

Consequence if Wrong: ID lệch làm đứt traceability; quy tắc màn hình sai có thể tạo sai quyền truy cập, dữ liệu hiển thị hoặc luồng phê duyệt trong bài học.

Senior Lens

Hạng mục soát	Bằng chứng phải thấy	Kết quả hiện tại	Owner escalation
Định danh	ID và đường dẫn khớp nguồn canonical	Không được đổi ID hoặc tên tệp	Principal IT Business Analyst / Technical Curriculum Author
Trạng thái	IN_REVIEW, v0.9.0, 2026-08-07 xuất hiện nhất quán	Không được diễn giải thành approval	Principal IT Business Analyst / Technical Curriculum Author
Quy tắc màn hình	Rule tham chiếu CANONICAL_BUSINESS_RULES, không tự tạo rule	Verification required nếu rule ảnh hưởng vận hành	Business Owner
Dữ liệu hiển thị	Field tham chiếu CANONICAL_DATA_DICTIONARY	Verification required nếu thiếu định nghĩa, phân loại hoặc quyền xem	Data Owner và Security Owner
Tích hợp/API	Không suy diễn endpoint, lỗi HTTP hoặc mapping dữ liệu	Verification required nếu wireframe phụ thuộc dịch vụ ngoài	Solution Architect
Kiểm thử	Hành vi có điều kiện quan sát được và kết quả mong đợi	Verification required nếu không thể viết test basis	QA Reviewer
Pháp lý, kế toán, thực phẩm	Không gọi giả định là nghĩa vụ pháp lý	Verification required trước khi dùng làm requirement	Legal Owner, Accounting Owner hoặc Food Safety Owner

Open issues trước handoff:

ID vấn đề	Nội dung	Trạng thái	Escalation owner
UIR-OPEN-001	Chưa có bằng chứng canonical cho quyền xem dữ liệu theo vai trò trên màn hình Nova Foods mô phỏng.	Verification required	Security Owner và Business Owner
UIR-OPEN-002	Chưa có xác nhận field nào là bắt buộc nhập hay chỉ hiển thị.	Verification required	Business Owner và Data Owner
UIR-OPEN-003	Chưa có test basis xác nhận thông báo lỗi, trạng thái trống và điều kiện chặn thao tác.	Verification required	QA Reviewer
UIR-OPEN-004	Nếu màn hình hiển thị dữ liệu hóa đơn, kế toán hoặc truy xuất thực phẩm, diễn giải hiện hành chưa phải kết luận pháp lý hay nghiệp vụ thật.	Verification required	Legal Owner, Accounting Owner và Food Safety Owner

Quick Reference

Checklist handoff hoàn tất khi: tên chapter giữ đúng /02-handbook/14-wireframes-screen-behavior-and-ui-rules.md; mọi tham chiếu ID giữ nguyên chuỗi canonical; metadata không mâu thuẫn IN_REVIEW và v0.9.0; Nova Foods luôn ghi mô phỏng, dữ liệu tổng hợp; mọi khoảng trống có Verification required, bằng chứng và escalation owner; không có câu nào ngụ ý user approval, baseline hoặc production authorization. Nếu một kiểm tra thất bại, dừng handoff, ghi vấn đề vào review record và chuyển đúng owner; không tự lấp khoảng trống bằng quy tắc mới.