Kịch bản demo — bằng chứng 4 nguyên lý thiết kế

Đề thi (du-thi/olp-2026-de-thi.md §3.2) yêu cầu sản phẩm "được xây dựng dựa trên" 4 nguyên lý, kèm gợi ý bằng chứng cho từng nguyên lý. Mỗi màn dưới đây:

• chạy bằng một lệnh trên hệ thống đang chạy (make up, make seed), phần lớn xong dưới một phút; màn nào lâu hơn (tới khoảng hai phút) thì ghi thời gian ở mục của màn đó;
• in từng bước kèm dấu ✓, sai bước nào thì dừng và nói rõ bước đó (thoát 1);
• chạy lại được nhiều lần, mỗi lần chỉ thêm dữ liệu riêng của lần chạy (vd một tệp sạch chưa gắn văn bản và vài dòng sổ kiểm toán). Trừ nong-lanh: mỗi lần nộp lưu tối đa ba văn bản mẫu đã xong sang kho lạnh, không đảo ngược được; hết văn bản thì màn báo chạy make seed. pha-he gọi nong-lanh khi chưa có lượt nộp lưu nào.

Trên máy chủ đã make install, chạy python3 scripts/demo.py <màn> trong thư mục cài, thay cho make demo-<màn>. Bốn màn không nằm trong demo.py mà có script riêng: scripts/demo_ca_nhan.py, demo_tat_van_phong.py, demo_tu_dong.py, demo_wiki.py.

Khi trình bày: terminal chạy lệnh một bên, trình duyệt mở giao diện ở bên kia (đường dẫn in ở cuối mỗi màn).

Trước buổi trình diễn làm theo checklist; sự cố giữa buổi xử lý theo phương án dự phòng. Câu hội đồng hay hỏi và câu trả lời của đội: du-thi/hoi-dap-hoi-dong.md.

Nguyên lý	Màn	Lệnh	Tình trạng
(i) Vòng đời và tốc độ dữ liệu	Nóng → lạnh: hồ sơ đã đóng chuyển sang kho lạnh, vẫn tìm, xác thực và phân tích được (DuckDB trên gói Parquet)	make demo-nong-lanh	Có (F3.8)
(ii) Hội tụ IT/OT	Cảm biến nhiệt độ phòng máy → NGSI-LD → dựng nháp báo cáo sự cố	make demo-it-ot	Có (F3.10)
(iii) Quản trị dữ liệu	Phả hệ: báo cáo ← bảng ← sự kiện; kiểm chất lượng tự động	make demo-pha-he	Có (F3.9)
(iv) Zero-Trust + GitOps	Kiểm dịch trước khi lưu	make demo-kiem-dich	Có (F3.1)
(iv) Zero-Trust + GitOps	Văn bản hạn chế: tệp mã hóa trong kho, chỉ người có tên mở được, bản mở có dấu tên	make demo-han-che	Có (F3.7)
(iv) Zero-Trust + GitOps	Két bí mật: dịch vụ của đội không nhận bí mật qua biến môi trường, két tự mở khóa	make demo-ket-bi-mat	Có (F3.2)
(iv) Zero-Trust + GitOps	Tự phục hồi từ cấu hình trong git	make demo-tu-phuc-hoi	Có (F3.3)

Ngoài các màn nguyên lý còn năm màn nghiệp vụ, cùng cách chạy: liên thông văn bản giữa hai đơn vị trên cùng bản cài (make demo-lien-thong, F3.12) — xem mục này; tác tử đọc văn bản đến gợi ý thông tin tiếp nhận (make demo-doc-van-ban, F4.1, dưới hai phút) — xem mục này; trợ lý hỏi đáp trên kho văn bản, trả lời kèm số ký hiệu và trang (make demo-hoi-dap, F4.2, dưới hai phút) — xem mục này; tác tử gợi ý đơn vị chủ trì và hạn cho văn bản vừa vào sổ, kèm căn cứ (make demo-giao-viec, F4.3) — xem mục này; ký số PAdES bản phát hành văn bản đi bằng PKI nội bộ trong két, chỉ minh họa (make demo-ky-so, F4.5) — xem mục này. Màn che thông tin cá nhân trong chữ gửi mô hình và trong nhật ký (make demo-che-pii, F4.4) là bằng chứng cho cụm ② của đề — xem mục này. Màn cảnh báo vận hành ra chuông của quản trị đơn vị (make demo-canh-bao, F3.13, dưới hai phút) là bằng chứng cho cụm ⑥ — xem mục cuối. Màn ứng dụng sinh từ bảng (Supabase Studio, PostgREST, trang /sinh) chạy trên giao diện, chưa có lệnh make — xem mục này. Màn xem quy trình BPMN của một văn bản cũng chạy trên giao diện — xem mục này.

(i) Nóng → lạnh — make demo-nong-lanh

Điều muốn chứng minh:

• Dữ liệu có vòng đời: văn bản đang xử lý nằm ở CSDL nghiệp vụ (nóng). Hồ sơ đã đóng thì nộp lưu (NĐ 30/2020, Điều 28–31): chi tiết chuyển sang kho lạnh rẻ, không sửa được; CSDL nghiệp vụ chỉ giữ bản ghi rút gọn.
• Chuyển đi mà không mất gì: gói có manifest băm từng phần, đọc lại so băm xong mới gỡ khỏi CSDL. Văn bản vẫn tìm thấy, quét mã QR vẫn "khớp", phòng đọc vẫn đọc lại được gói.
• Kho lạnh có khóa ghi: trong thời hạn bảo quản không ai xóa được gói, kể cả quản trị kho.
• Dữ liệu lạnh vẫn phân tích được (#304): trang Điều hành đếm văn bản đã nộp lưu bằng DuckDB đọc thẳng các gói Parquet trong bucket lạnh. Số đếm không lấy từ CSDL nghiệp vụ: CSDL (qua Hasura) chỉ cho danh sách gói và băm manifest. Quyền như các biểu đồ nóng (chỉ lãnh đạo đơn vị, số của đơn vị mình).

Lệnh in ra 6 bước:

1. Chuyên viên (hoặc tổ trưởng) lập hồ sơ HS-…, đưa vào tối đa ba văn bản đã xong mà mình đọc được, thuộc phòng mình (ưu tiên văn bản đi đã phát hành, có mã QR), đóng hồ sơ — ngày đóng do CSDL đặt. In số dòng liên kết tệp, dòng thời gian, giao việc của các văn bản đó trong CSDL.
2. Gọi job nộp lưu của svc-files ngay (bình thường là vòng nền mỗi giờ, cho hồ sơ đóng quá MOC_ARCHIVE_AFTER_DAYS ngày). In đường dẫn gói s3://moc-cold/cold/<đơn vị>/case/<hồ sơ>/, số văn bản, số tệp, số byte, thời gian, băm của manifest (manifest-<băm>.json).
3. CSDL nghiệp vụ: văn bản ở trạng thái archived; liên kết tệp, dòng thời gian về 0; giao việc giữ nguyên (căn cứ quyền xem, sổ đăng ký); bản tệp trong bucket nóng đã xóa.
4. Vẫn dùng được:
   • quét mã tra cứu của văn bản đi ở cổng xác thực, không đăng nhập → "khớp", trạng thái archived;
   • văn thư tìm theo số ký hiệu → ra văn bản đã nộp lưu;
   • phòng đọc GET /api/case-files/{id}/archive: manifest khớp băm trong CSDL, DuckDB đọc documents.parquet ra đúng các văn bản.
   • phòng đọc xem tệp GET /api/case-files/{id}/archive/files/{file_id}: bản PDF có dấu tên văn thư, giờ xem (khác byte gốc), lần xem vào sổ kiểm toán (case_file.file_viewed).
5. Phân tích trên dữ liệu lạnh: lãnh đạo đơn vị gọi GET /api/case-files/archive-stats (API của phần "Văn bản đã nộp lưu" trên trang Điều hành) trước bước 2 và sau bước 4. Số hồ sơ tăng 1, số văn bản tăng đúng số văn bản của hồ sơ, theo năm ban hành và chiều đến / đi tăng đúng như các văn bản đó; chuyên viên gọi cùng API → 403. Phả hệ có run moc.archive.stats với đầu vào là bảng documents-….parquet của gói vừa nộp lưu. Bước này giả định trong lúc lệnh chạy không ai khác nộp lưu hồ sơ của cùng đơn vị: trong CI không sao (vòng nền chỉ nộp lưu hồ sơ đóng quá MOC_ARCHIVE_AFTER_DAYS ngày); chạy trên hệ thống đang có người dùng thì một lượt nộp lưu chen giữa làm số đếm lệch và bước 5 báo lỗi.
6. Thử xóa manifest bằng khóa quản trị của kho → bị từ chối (S3 Object Lock, chế độ COMPLIANCE). Dòng case_file.archived nằm trong sổ kiểm toán chuỗi băm.

Trên giao diện:

• Bất kỳ ai: mở trang xác thực, nhập mã tra cứu của văn bản vừa nộp lưu → vẫn "Văn bản có thật, do đơn vị dưới đây phát hành".
• Lãnh đạo đơn vị: Sổ kiểm toán → tab Văn bản, dòng "Nộp lưu hồ sơ" kèm ký hiệu hồ sơ, băm gói, số văn bản, số tệp; tên hồ sơ không hiện.
• Lãnh đạo đơn vị: Điều hành → phần Văn bản đã nộp lưu (kho lạnh) cuối trang: số hồ sơ, văn bản đến, văn bản đi đã nộp lưu; biểu đồ theo năm ban hành; bảng theo loại văn bản, theo phòng lập hồ sơ; dòng nguồn ghi số gói, tên bucket lạnh, giờ DuckDB tính. Chưa có hồ sơ nào nộp lưu thì phần này báo trống, không báo lỗi.
• Chuyên viên (chuyenviendt): Hồ sơ công việc → Lập hồ sơ (ký hiệu, tiêu đề, thời hạn bảo quản) → Thêm vào hồ sơ một văn bản đã xong của phòng → Đóng hồ sơ (ngày đóng do hệ thống đặt). Không có nút nộp lưu.
• Tổ trưởng (totruongdt): mở hồ sơ vừa đóng → Nộp lưu → trạng thái "Đã nộp lưu", băm manifest, vị trí gói, khóa ghi tới ngày nào. Lệnh vẫn gọi job nộp lưu (bước 2) để in số byte, thời gian.
• Văn thư: mở hồ sơ đã nộp lưu → Phòng đọc: "Manifest khớp băm ghi trong CSDL", văn bản trong gói, bấm Xem ở tệp PDF → bản xem hiện ngay trong trang, mọi trang có dòng "PHÒNG ĐỌC — bản xem tài liệu lưu trữ cho …, giờ…" (tên người xem, giờ xem). Lãnh đạo đơn vị thấy dòng "Xem tệp trong phòng đọc" trong sổ kiểm toán.

Nếu giám khảo hỏi:

• "Lạnh là ở đâu?" Bucket moc-cold của SeaweedFS, có khóa ghi, chung với mốc neo sổ kiểm toán. Triển khai thật thì trỏ MOC_COLD_BUCKET sang ổ rẻ hơn hoặc kho S3 khác. Parquet là định dạng cột mở: công cụ nào cũng đọc được, không cần Signet.
• "Đã chuyển sang kho lạnh thì còn phân tích được không?" Được: svc-files tải manifest theo băm trong CSDL, kiểm băm bảng văn bản của từng gói, rồi DuckDB đọc mọi bảng một lượt (read_parquet trên danh sách tệp) và đếm theo năm, loại, phòng (svc_files/archive_stats.py). Gói không đổi nên kết quả lưu đệm tới khi có hồ sơ mới nộp lưu. Gói lệch băm thì không đếm mà báo ký hiệu hồ sơ trên trang. Đọc lại mọi gói mỗi khi có hồ sơ mới: chưa đo với hàng nghìn gói.
• "Sao không dùng Kestra?" Một job mỗi giờ không đáng thêm một máy chủ Java khoảng 1 GB RAM. Job là vòng nền trong svc-files, như vòng neo sổ kiểm toán. DuckDB nhúng trong svc-files, không chạy máy chủ riêng.
• "Hỏng giữa chừng thì sao?" Thứ tự là kiểm băm tệp nóng → ghi gói → đọc lại so băm → một giao dịch CSDL → xóa bản nóng. Giao dịch kiểm CSDL còn đúng như gói (khóa dòng), lệch thì không đổi gì. Hỏng trước giao dịch thì CSDL chưa đổi gì, lượt sau làm lại và không ghi lại phần đã có. Hỏng sau giao dịch thì chỉ thừa bản nóng, không mất gì.
• "Văn bản hạn chế?" Không vào hồ sơ nộp lưu: tệp của nó mã hóa bằng khóa riêng bọc trong két (F3.7). Nộp lưu bản mã hóa cần đưa khóa đã bọc đi cùng gói lạnh và giữ két lâu như gói — chưa làm.

(ii) Hội tụ IT/OT — make demo-it-ot

Điều muốn chứng minh:

• Thiết bị vận hành (OT) và hệ thống văn phòng (IT) nói chuyện qua một chuẩn mở: cảm biến cập nhật bản sao số của nó trong context broker NGSI-LD (ETSI), Signet đăng ký nhận sự kiện qua subscription — không viết giao thức riêng.
• Sự kiện vật lý thành văn bản hành chính: nhiệt độ phòng máy chủ vượt ngưỡng → dự thảo "Báo cáo sự cố" dựng từ mẫu, đứng tên chuyên viên phụ trách, đi đúng luồng văn bản đi (duyệt phòng → lãnh đạo ký → phát hành). Hệ thống dựng nháp, con người kiểm tra và trình — không tự gửi gì.
• Tách theo đơn vị và không tin mạng: mỗi đơn vị một tenant NGSI-LD (thực thể, lịch sử, subscription riêng); thiết bị chỉ thấy broker, không gọi được svc-workflow; broker gọi svc-workflow phải kèm token riêng của đơn vị; broker và CSDL của nó không mở cổng ra ngoài.

Lệnh in ra 7 bước (lần đầu tải image Scorpio và PostGIS, khoảng 380 MB):

1. Bật profile iot (Scorpio + PostGIS); svc-workflow tự đăng ký subscription temperature>35 trong tenant của đơn vị, kèm token. In thời gian broker sẵn sàng.
2. Cảm biến giả lập (container chạy một lần, chỉ ở mạng iot) gửi 5 lần đo 24 → 29 → 33 → 37 → 41 °C.
3. Hai lần vượt ngưỡng → đúng một dự thảo và một thông báo (dự thảo cũ chưa trình thì chỉ nhắc, mỗi ngày nhiều nhất một lần): loại Báo cáo, độ khẩn "Khẩn", trích yếu và nội dung từ mẫu (giờ đo, nhiệt độ, ngưỡng, các mục để chuyên viên điền); dòng thời gian có sự kiện ot.alarm; chuyên viên nhận thông báo ngay.
4. Lịch sử đo nằm trong broker (NGSI-LD temporal API), cả các lần dưới ngưỡng: dữ liệu OT ở lại broker, Signet chỉ nhận sự kiện cần xử lý.
5. Chuyên viên trình → tổ trưởng phòng có việc duyệt, như mọi văn bản đi.
6. Thông báo giả: từ mạng thiết bị không tới được svc-workflow; từ mạng nội bộ (container svc-files) với token sai → 401.
7. Sơ đồ cảm biến kho: năm cảm biến khai mã phòng (--room) và gửi số đo — kho 1 bình thường; kho 2 gửi -127 °C (ngoài dải); kho 3 đồng hồ đứng (--frozen-clock, trùng observedAt); phòng đọc gửi số đo cũ hơn MOC_OT_STALE_MIN + 20 phút (--late, mất tín hiệu); phòng xử lý đồng hồ nhanh 30 phút (--clock-ahead, giờ đo ở tương lai — broker vừa nhận nên không mất tín hiệu). Văn thư gọi Action otSensorMap: đúng cờ từng cảm biến, phòng máy chủ vượt ngưỡng; văn thư Trường Kinh tế không thấy cảm biến của Trường CNTT & TT; quản trị đơn vị không có Action.

Trên giao diện (chuyenviendt): chuông thông báo "Cảnh báo nhiệt độ…", mục Văn bản đi có dự thảo, dòng thời gian ghi "Cảm biến … đo 41 °C, vượt ngưỡng 35 °C — hệ thống dựng dự thảo". Mục "Sơ đồ cảm biến" (/cam-bien, văn thư, chuyên viên, lãnh đạo): mặt bằng kho, phòng máy chủ đỏ, kho 1 xanh, kho 2 và phòng đọc xám có cờ, kho 3 có cờ "Trùng giờ đo", phòng xử lý tô theo số đo kèm cờ "Giờ đo ở tương lai"; chú giải ghi luật từng cờ.

Nếu giám khảo hỏi:

• "Sao không gắn cảm biến thật?" Cảm biến thật chỉ thay container giả lập: cùng các lệnh NGSI-LD vào broker (qua gateway IoT như IoT Agent của FIWARE, hoặc thiết bị tự gửi). Phía Signet không đổi gì.
• "Thiết bị có chọn được người đứng tên dự thảo?" Chỉ một chuyên viên đang hoạt động của đúng đơn vị đó; người khác, vai trò khác hay đơn vị khác thì bỏ qua (ghi nhật ký). Dự thảo chỉ là nháp, người đứng tên quyết định có trình.
• "Thiết bị của đơn vị này có ghi giả vào đơn vị kia được không?" Ở bản rút gọn thì được, nếu vào được mạng thiết bị: Scorpio không xác thực, tenant do bên gửi khai. Triển khai thật đặt cổng thiết bị (IoT Agent / PEP proxy của FIWARE) trước broker, cấp tenant theo khóa của từng thiết bị. Phía Signet không đổi: vẫn chỉ tin subscription.
• "Vì sao broker riêng chứ không ghi thẳng vào CSDL?" Bản sao số (trạng thái, lịch sử, truy vấn theo không gian) là việc của context broker theo chuẩn; Signet không phải nơi giữ dữ liệu cảm biến, chỉ nhận sự kiện cần thành văn bản.
• "Tốn bao nhiêu?" Profile iot không bật mặc định: Scorpio ~400 MB RAM, PostGIS ~130 MB.

(iii) Phả hệ và kiểm chất lượng — make demo-pha-he

Điều muốn chứng minh:

• Biết dữ liệu từ đâu ra: mỗi bước của job nộp lưu (màn (i)) để lại một sự kiện theo chuẩn mở OpenLineage. Từ gói lưu trữ truy ngược được về bảng nghiệp vụ và tệp gốc đã sinh ra nó.
• Chất lượng kiểm tự động, trước khi ghi: bảng Parquet nào cũng được đọc lại, số dòng phải bằng số dòng trong CSDL, cột bắt buộc không được rỗng. Trượt thì job dừng trước khi ghi gì sang kho lạnh, sự kiện FAIL nằm lại trong phả hệ.

Lệnh in ra 5 bước (chưa có lượt nộp lưu nào thì chạy màn (i) trước):

1. Lượt nộp lưu gần nhất: run của job moc.case_file.archive, START → 4 run con files, tables, manifest, commit → COMPLETE. Mỗi bước in đầu vào → đầu ra. Lãnh đạo đọc qua Hasura, chỉ thấy đơn vị mình.
2. Truy ngược: manifest-<băm>.json ← documents/assignments/events-<băm>.parquet + files/<sha256> ← moc.office.documents, moc.office.assignments, moc.office.document_events + đối tượng trong bucket nóng.
3. Kiểm chất lượng từng bảng: số dòng = CSDL, các cột bắt buộc không null (facet dataQualityAssertions, outputStatistics); số bước trượt kiểm của đơn vị.
4. Sự kiện đúng đặc tả OpenLineage 2-0-2 (schemaURL, producer, tên dataset theo quy ước): đặt MOC_OPENLINEAGE_URL là gửi được sang Marquez.
5. Phả hệ báo cáo: bốn khung nhìn của trang Điều hành ← bảng nào, tính từ catalog PostgreSQL lúc hỏi (office.report_lineage) — vd office.v_processing_time ← office.archived_document_facts, office.document_events, office.documents; lượt nộp lưu mới khai office.archived_document_facts ở bước commit.

Trên giao diện (lãnh đạo, truongkhoa): trang Điều hành, nút "Nguồn số liệu" trên biểu đồ "Thời gian xử lý theo tháng xong" → trang Phả hệ số liệu lọc đúng biểu đồ đó: đồ thị biểu đồ ← khung nhìn ← bảng ← manifest của lượt nộp lưu (nét đứt: bước commit ghi lại vào CSDL), bảng nguồn bên dưới. Chọn "Mọi biểu đồ" để thấy cả dải nộp lưu (bảng → Parquet → gói lưu trữ, số dòng đã kiểm); nút "Tải OpenLineage (.jsonl)" xuất cùng phả hệ ở dạng chuẩn mở. Bốn thông tư thật mà make seed nạp từ Công báo hiện thành nhánh congbao.chinhphu.vn → "Nạp dữ liệu công khai" → office.documents; mục "Lượt nạp dữ liệu công khai gần nhất" ghi tệp bản chụp đã đối chiếu manifest và số văn bản mới của từng nguồn (#445).

Nếu giám khảo hỏi:

• "Marquez đâu?" Chưa dựng trong compose: thêm một máy chủ Java và CSDL riêng (khoảng 1 GB RAM) cho một job mỗi giờ. Sự kiện lưu trong core.lineage_events (cột event là nguyên văn OpenLineage), cùng sao lưu với CSDL; bật Marquez chỉ cần đặt MOC_OPENLINEAGE_URL. Đồ thị thì xem ngay ở trang Phả hệ số liệu của Signet (/pha-he).
• "Kiểm trượt thì sao?" Thử trong test đơn vị: một văn bản thiếu trích yếu → bước tables FAIL, không đối tượng nào được ghi sang bucket lạnh (ở đó bị khóa nhiều năm), CSDL không đổi, lượt sau thử lại.
• "Ai sửa được phả hệ?" Không ai: bảng chỉ thêm, trigger chặn sửa và xóa kể cả khi ghi thẳng CSDL.
• "Phả hệ báo cáo có phải vẽ tay không?" Cạnh khung nhìn → bảng đọc từ catalog (pg_depend) mỗi lần mở trang: sửa view là đồ thị đổi theo. Chỉ cạnh biểu đồ → khung nhìn khai trong mã giao diện, và có test so với truy vấn thật của trang Điều hành (apps/office/tests/lineage.test.ts).

(iv) Kiểm dịch trước khi lưu — make demo-kiem-dich

Điều muốn chứng minh:

• Không tệp nào chạm kho mà chưa qua ClamAV.
• Tệp nhiễm bị từ chối ngay khi svc-files nhận, trước khi ghi vào kho, và không được lưu ở đâu. Thứ duy nhất còn lại là dòng sổ kiểm toán ghi lần chặn.
• Sổ kiểm toán là chuỗi băm, neo ra ngoài CSDL: ai sửa hay xóa dòng đó, kể cả quản trị, đều bị phát hiện.

Lệnh in ra 5 bước:

1. Văn thư tải lên một công văn bình thường qua cổng APISIX → 201, ClamAV báo sạch, tệp vào kho.
2. Văn thư tải lên hoa-don-….pdf chứa chuỗi kiểm thử EICAR. Đây là chuỗi chuẩn để thử phần mềm diệt virus, không phải mã độc thật. Kết quả: 422 infected, ClamAV báo Eicar-Test-Signature.
3. core.files không có dòng nào mang SHA-256 của tệp đó: tệp bị chặn trên luồng, trước khi ghi vào kho.
4. Lãnh đạo đơn vị đọc sổ kiểm toán của đơn vị, đúng quyền của mình, và thấy dòng file.rejected:
   • thấy giờ, người tải, mẫu mã độc, cỡ tệp;
   • không thấy tên tệp, vì tên do người dùng đặt có thể nói lên nội dung.
5. moc audit anchor neo đầu chuỗi ra bucket lạnh khóa ghi (object lock). moc audit verify tính lại cả chuỗi bên ngoài CSDL: chuỗi liền mạch tới dòng vừa ghi. Từ đó, sửa hay xóa dòng này đều bị phát hiện.

Trên giao diện:

• Lãnh đạo đơn vị: vào Sổ kiểm toán → tab Tệp, có dòng "Chặn tệp nhiễm mã độc" kèm mẫu mã độc và cỡ tệp.
• Văn thư: tải tệp EICAR ở Tiếp nhận văn bản, tệp hiện đỏ "Tệp nhiễm mã độc (…) — đã bị chặn, không lưu".

Nếu giám khảo hỏi:

• "Chặn ở gateway hay ở dịch vụ?" Ở svc-files, sau APISIX. Mọi đường tải tệp lên đều đi qua đây, không có đường nào ghi thẳng vào SeaweedFS. Tệp được quét trên luồng trước khi ghi vào kho. ClamAV không trả lời thì từ chối tệp (503), không cho qua. Không quét ở cổng vì WAF trong APISIX (coraza-proxy-wasm) không soi được nội dung tệp trong multipart (platform/apisix/README.md, mục WAF).
• "Có kho cách ly không?" Không. Tệp nhiễm bị từ chối và không lưu ở đâu, người tải thấy lý do ngay. Sổ kiểm toán giữ cỡ tệp, SHA-256 và tên mẫu ClamAV để tra lại.
• "Mã độc mới, chưa có mẫu thì sao?" ClamAV chỉ bắt được mẫu đã biết. Mẫu tự cập nhật nhiều lần mỗi ngày (freshclam chạy sẵn trong image clamav/clamav). Lớp sau là: tệp không bao giờ được thực thi trên máy chủ, PDF chỉ được đọc trong tiến trình con có giới hạn bộ nhớ, CPU và thời gian (F2.7).

(iv) Văn bản hạn chế — make demo-han-che

Điều muốn chứng minh:

• Không tin vào chỗ lưu: tệp đính kèm trong kho tệp và bản sao lưu chỉ là bản mã, người quản trị CSDL chỉ thấy khóa đã bọc. Khóa của từng tệp bọc trong két, chỉ két mở được. (Trích yếu, nội dung soạn trên hệ thống vẫn nằm trong CSDL, chỉ được che bằng phân quyền.)
• Không tin vào vị trí trong mạng: mỗi lần mở tệp đều hỏi lại quyền theo người, theo văn bản. Người không có tên nhận 404 y như tệp không tồn tại.
• Bản rõ chỉ có trong bộ nhớ, trong khoảnh khắc trả về, mang tên người xem; mỗi lần mở đều vào sổ kiểm toán.

Lệnh in ra 6 bước:

1. Văn thư tải nang-luong-….pdf lên ở chế độ hạn chế. svc-files xin két một khóa AES-256 riêng cho tệp, mã hóa rồi mới ghi: đọc thẳng đối tượng trong kho thấy bắt đầu bằng MOC1, không có đầu %PDF, không có chữ trong tệp. CSDL chỉ giữ khóa đã bọc (vault:v1:…).
2. Văn thư tiếp nhận văn bản hạn chế. Quy trình giao lãnh đạo đơn vị cho ý kiến chỉ đạo, và svc-workflow tự thêm lãnh đạo khoa vào danh sách được xem — nhận việc mà không mở được văn bản thì vô nghĩa.
3. Tổ trưởng Tổ Đào tạo không có tên: không đọc được văn bản, mở thẳng đường dẫn tệp → 404.
4. Lãnh đạo đơn vị mở tệp: bản giải mã trong bộ nhớ, trên trang có dòng "VĂN BẢN HẠN CHẾ — bản giải mã cho …, giờ…", Cache-Control: no-store; băm khác bản gốc vì mỗi người, mỗi lần mở là một bản riêng.
5. Thông báo việc mới của lãnh đạo đơn vị chỉ có nhãn "Văn bản hạn chế", không số ký hiệu, trích yếu, cơ quan ban hành.
6. Sổ kiểm toán có dòng file.decrypted của lãnh đạo đơn vị; lần tổ trưởng bị từ chối không giải mã gì nên không có dòng.

Trên giao diện:

• Văn thư: Tiếp nhận văn bản, tích "Hạn chế người xem" trước khi tải tệp (chỉ nhận PDF; đã có tệp thì ô này khóa lại), tệp hiện "Đã quét — sạch, đã mã hóa". Trang văn bản: tệp có nhãn "Đã mã hóa", mục Người được xem có lãnh đạo đơn vị, gỡ hoặc cấp thêm người được.
• Lãnh đạo đơn vị: chuông ghi "Việc mới … Văn bản hạn chế"; mở tệp thấy tên mình đóng chéo trang.
• Tổ trưởng: dán đường dẫn văn bản → "Không tìm thấy văn bản, hoặc bạn không có quyền xem."

Nếu giám khảo hỏi:

• "Đây là văn bản mật à?" Không. Đây là văn bản hạn chế người xem trong cơ quan (lương, kỷ luật, nhân sự). Văn bản mật nhà nước phải dùng hệ thống, mật mã được cấp phép riêng theo Luật Bảo vệ bí mật nhà nước 2018; giao diện và tài liệu đều ghi rõ điều này.
• "Lấy được ổ đĩa, bản sao lưu thì sao?" Chỉ có bản mã và khóa đã bọc. Mở khóa phải qua két, két cần khóa mở két trong .env. Bản sao lưu gồm cả két (để khôi phục được), nên .env phải giữ riêng, ngoài bản sao lưu.
• "Người có tên chụp màn hình, chuyển tiếp thì sao?" Không chặn được. Tên người xem và giờ xem nằm trên mọi trang, sổ kiểm toán ghi từng lần mở: lộ thì truy được từ bản nào.
• "Lãnh đạo đơn vị vốn đọc được mọi văn bản, sao còn cần có tên?" Vai trò chưa đủ: văn bản hạn chế còn cần có tên. Người nhận việc được tự thêm; văn thư, lãnh đạo đơn vị thêm hoặc gỡ người khác, mỗi lần đều vào sổ.
• "Tìm theo nội dung được không?" Không: tệp mã hóa không được đọc chữ, nội dung văn bản hạn chế không vào chỉ mục, vì một bản chữ trần nằm ngoài tệp là vô hiệu việc mã hóa. Tìm theo số ký hiệu, trích yếu vẫn được nếu có quyền.

(iv) Két bí mật — make demo-ket-bi-mat

Điều muốn chứng minh:

• Dịch vụ của đội không nhận bí mật qua biến môi trường (docker inspect hay /proc/<pid>/environ không lộ gì); bí mật nằm trong két OpenBao, mỗi dịch vụ đăng nhập bằng danh tính riêng (AppRole) và chỉ đọc được phần của mình.
• Két tự mở khóa khi khởi động lại (static seal), nên máy chủ khởi động lại hay dịch vụ bị dựng lại (F3.3) không cần người nhập khóa.
• Mọi lần đăng nhập, đọc bí mật đều vào sổ của két; giá trị bí mật trong sổ đã băm.

Lệnh in ra 5 bước:

1. Băm giá trị từng biến môi trường trong container svc-files, svc-workflow, so với băm của các bí mật trong .env: không khớp cái nào. Env chỉ có địa chỉ két (MOC_OPENBAO_ADDR, MOC_OPENBAO_SECRET_PATH).
2. docker compose restart openbao: két khởi động lại, tự mở khóa, nạp lại bí mật và cấp secret_id mới cho từng dịch vụ (hủy cái cũ) trong vài giây; svc-files, svc-workflow khởi động lại theo và lấy lại bí mật. bao status: seal static, sealed=false.
3. docker compose restart svc-files: dịch vụ đăng nhập két bằng secret_id mới, lấy khóa kho S3, rồi văn thư tải một tệp lên → 201. Khóa kho không đi qua đâu ngoài két.
4. Trong container svc-workflow, thử đọc phần bí mật của svc-files bằng AppRole của svc-workflow → két từ chối 403.
5. Đọc sổ của két (docker compose logs openbao) từ lúc khởi động lại: thấy svc-files đăng nhập rồi đọc moc/data/svc-files, và lần svc-workflow đọc chéo bị từ chối ở bước 4; không giá trị bí mật nào xuất hiện rõ trong sổ.

Nếu giám khảo hỏi:

• "Bí mật vẫn nằm trong .env mà?" Đúng. .env vẫn là nguồn: container openbao nhận chúng và nạp vào két mỗi lần khởi động. Cái được: dịch vụ của đội không giữ bí mật trong biến môi trường, mỗi dịch vụ chỉ đọc được phần của mình, mọi lần đọc có sổ. Phần mềm thượng nguồn (PostgreSQL, Keycloak, Flowable, Hasura, SeaweedFS, Meilisearch, Centrifugo; Parseable, Scorpio, restic khi bật profile) vẫn đọc bí mật của chúng từ biến môi trường.
• "Khóa mở két để đâu?" MOC_OPENBAO_SEAL_KEY trong .env, khóa phục hồi và token khởi động trong volume của két, role_id/secret_id của dịch vụ trong volume riêng của dịch vụ đó. Ai có quyền Docker trên máy chủ vẫn đọc được két. Static seal đổi an toàn lấy khả năng tự phục hồi; bản thật nên dùng KMS hoặc HSM (seal pkcs11, awskms…).
• "Ai cấu hình két?" Lần đầu, platform/openbao/start.sh cấu hình bằng token root rồi thu hồi nó ngay. Các lần sau chỉ dùng token khởi động: không đọc thẳng được bí mật, không sửa được policy, nhưng cấp được secret_id cho hai dịch vụ — nên volume của két phải được giữ như chính két.
• "Két dùng làm gì nữa?" Khóa transit moc-files để mã hóa tệp của văn bản hạn chế (F3.7, make demo-han-che): svc-files chỉ xin được khóa dữ liệu mới và mở khóa đã bọc, không bao giờ cầm khóa gốc.

(iv) Tự phục hồi — make demo-tu-phuc-hoi

Điều muốn chứng minh:

• Trạng thái mong muốn nằm trong git (docker-compose.yml, cấu hình cổng, policy két…); một reconciler đều đặn so trạng thái đang chạy với khai báo và tự sửa phần lệch, không cần người.
• Dịch vụ chết hay bị xóa hẳn thì được dựng lại; cấu hình bị sửa tay trên máy chủ thì bị đưa về đúng commit.

Lệnh in ra 4 bước (dưới một phút):

1. Một lượt scripts/reconcile.py: "đã khớp trạng thái khai báo, không có gì phải làm".
2. Phá: docker rm -f container svc-files (mất hẳn, không phải chỉ dừng), docker stop container centrifugo. Văn thư tải tệp → cổng trả lỗi vì không tới được dịch vụ.
3. Một lượt reconciler (trên máy chủ chạy mỗi phút: systemd timer trên máy Linux thường, cron trên bản online chạy WSL2; ở đây gọi ngay): in "dựng lại svc-files (không còn container)", "chạy lại centrifugo (đã dừng: …)".
4. Hai dịch vụ về running (healthy) (svc-files lấy lại bí mật từ két F3.2), văn thư tải tệp → 201.

Phần GitOps (chạy trong CI, bước "GitOps"; trên máy chủ xem van-hanh.md mục "GitOps và tự phục hồi"):

• Đẩy một commit lên nhánh deploy của repo → lượt reconciler kế tiếp in "áp commit … (nhánh deploy: cũ → mới)", tệp VERSION của bản cài mang commit mới, smoke vẫn qua.
• Sửa tay docker-compose.yml trong thư mục cài → lượt kế tiếp in "tệp đã cài bị sửa tay, đưa về commit …" và tệp trở lại đúng như trong git.

Đối chiếu bốn nguyên tắc OpenGitOps 1.0:

Nguyên tắc	Ở Signet
Khai báo (declarative)	Toàn bộ hệ thống khai trong docker-compose.yml + cấu hình từng thành phần (realm Keycloak, metadata Hasura, cổng APISIX, cấu hình két); không bước dựng tay nào ngoài .env
Có phiên bản, bất biến (versioned and immutable)	Trạng thái mong muốn là một commit git; image dựng theo commit (MOC_VERSION = git describe), tệp VERSION của bản cài ghi commit; lùi phiên bản = đẩy commit cũ lên deploy
Tự kéo về (pulled automatically)	Reconciler trên máy chủ tự git fetch; không ai đẩy vào máy chủ, CI không cần quyền vào máy chủ
Liên tục đối chiếu (continuously reconciled)	Mỗi phút một lượt (systemd timer; bản online chạy WSL2 dùng cron): so commit, so băm tệp đã cài, so container đang chạy với khai báo; lệch thì sửa

Nếu giám khảo hỏi:

• "Sao không dùng Argo CD hay Flux?" Hai công cụ đó chạy trên Kubernetes; Signet nhắm máy chủ đơn vị chạy Docker Compose. Reconciler là một script thư viện chuẩn Python, đọc được trong vài phút.
• "Docker có restart: unless-stopped rồi mà?" Chính sách đó chỉ chạy lại container còn tồn tại và không chạy lại container bị docker stop. Container bị xóa hẳn, hay cấu hình lệch khỏi git, thì chỉ reconciler đưa về được.
• "Áp commit có làm gián đoạn không?" Có, khoảng một phút: reconciler dựng image trước, rồi dừng Signet, cài lại đúng commit và chạy lại. Commit áp lỗi thì reconciler đợi commit kế tiếp chứ không thử lại liên tục.
• ".env thì sao?" Không nằm trong git (chứa bí mật), reconciler không đụng tới; đổi .env vẫn là việc của người vận hành.

Ngoài 4 nguyên lý: liên thông trong hệ thống — make demo-lien-thong

Màn này thuộc F3.12, không phải một trong các màn bằng chứng nguyên lý ở bảng trên: nó cho thấy một việc nghiệp vụ chạy trên cùng nền (tách đơn vị, kiểm dịch, sổ kiểm toán, cổng xác thực).

Điều muốn chứng minh:

• Hai đơn vị trên cùng một bản cài gửi văn bản cho nhau không qua thư điện tử, không ai tải lại tệp: văn thư bên gửi phát hành → bên nhận có ngay văn bản đến (received, chờ vào sổ), tệp trùng từng byte (cùng SHA-256), kèm mã xác thực của bên gửi.
• Vẫn tách đơn vị: bản sao tệp nằm trong kho dưới tiền tố của bên nhận, qua ClamAV như mọi tệp tải lên; mỗi đơn vị chỉ đọc văn bản và sổ kiểm toán của mình; bên gửi chỉ thấy "đã chuyển".
• Đúng một lần: giao dịch phát hành ghi luôn một dòng outbox (office.dispatches) cho mỗi đơn vị nhận; svc-workflow chuyển ngay, trượt thì vòng nền làm lại; chạy lại bao nhiêu lần cũng chỉ một văn bản đến, một bản sao tệp, một thông báo.
• Văn bản hạn chế (F3.7) không gửi được trong hệ thống.

Lệnh in ra 7 bước:

1. chuyenviendt (Trường CNTT & TT) đọc danh sách đơn vị trong hệ thống (không có đơn vị mình), soạn công văn gửi Trường Kinh tế.
2. Trình → totruongdt duyệt → truongkhoa ký → vanthu phát hành. In số ký hiệu, mã xác thực, SHA-256.
3. Đợi văn bản đến ở Trường Kinh tế (thường vài giây, tối đa 90 giây): received, cùng số ký hiệu, nơi ban hành là tên Trường Công nghệ thông tin và Truyền thông, đúng một tệp chính. vanthukt tải tệp về: SHA-256 trùng bản phát hành. vanthukt có thông báo văn bản đến mới; bên gửi thấy dòng liên thông delivered và giờ chuyển.
4. Văn bản đến mang mã xác thực và băm của bên gửi; cổng xác thực (không đăng nhập) tra theo mã → "khớp", tra theo SHA-256 của tệp nhận được → "khớp".
5. vanthukt vào sổ → số đến trong sổ của Trường Kinh tế; truongkhoakt có việc cho ý kiến chỉ đạo. Trường CNTT & TT không đọc được văn bản đến đó.
6. Sổ kiểm toán: truongkhoa thấy các dòng office.dispatches (tạo lúc phát hành, chuyển xong); truongkhoakt thấy văn bản đến, vào sổ, bản sao tệp (người thực hiện service) và không đọc được dòng nào của Trường CNTT & TT.
7. Dự thảo hạn chế chọn Trường Kinh tế → CSDL từ chối (documents_restricted_local).

Trên giao diện:

• vanthukt: chuông báo văn bản đến mới; danh sách Văn bản đến có chip "Liên thông"; mở văn bản: "Nhận từ Khoa Công nghệ thông tin · mã xác thực XXXXX-XXXXX" (bấm sang trang xác thực), "SHA-256 khớp".
• chuyenviendt: màn soạn văn bản đi có danh sách "Gửi trong hệ thống", tắt khi văn bản hạn chế. vanthu: văn bản đã phát hành có thẻ "Liên thông", trạng thái từng đơn vị nhận.

Nếu giám khảo hỏi:

• "Sao văn bản đến không có mã xác thực, băm của riêng nó?" Hai cột đó duy nhất toàn hệ thống: một mã trỏ về đúng một bản phát hành — bản của bên gửi. Văn bản đến giữ mã và băm của bên gửi ở dòng liên thông; giao diện hiện mã và đối chiếu băm với tệp.
• "svc-workflow chết giữa chừng?" Dòng outbox đã nằm trong CSDL cùng giao dịch phát hành; vòng nền gửi lại, giãn dần từ 30 giây tới 1 giờ. Bản sao tệp có id định trước nên chép lại không ra bản thứ hai; mỗi văn bản nguồn chỉ thành một văn bản đến ở mỗi đơn vị (ràng buộc duy nhất).
• "svc-workflow có chép được tệp tùy ý sang đơn vị khác?" Không: svc-files chỉ nhận id dòng liên thông, tự đọc tệp phát hành của đúng văn bản đó, so băm với core.files, với văn bản và với dòng outbox; văn bản chưa phát hành, hạn chế hay tệp đã sang kho lạnh thì từ chối.
• "Văn bản hạn chế?" Tệp mã hóa bằng khóa gắn với đơn vị và tệp (F3.7); gửi sang đơn vị khác là phải giải mã ra khỏi đơn vị. Chặn ở CSDL, svc-workflow và svc-files.
• "Còn gì chưa làm?" Danh sách đơn vị nhận cho mọi người dùng thấy tên mọi đơn vị trên bản cài (ổn với các khoa một trường; cho thuê nhiều tổ chức cần cờ cho phép nhận); chưa có nút gửi lại dòng failed; bên gửi không thấy bên nhận xử lý tới đâu (cố ý tách); bên nhận đã có văn bản đến trùng thì dòng thành duplicate, bản sao tệp đã chép thành mồ côi. Gửi sang hệ thống khác (ngoài bản cài) chưa làm.

Ngoài 4 nguyên lý: đọc văn bản đến — make demo-doc-van-ban

Màn này thuộc F4.1, không phải màn bằng chứng nguyên lý: một tác tử (AI agent) làm việc gõ lại của văn thư, trên cùng nền kiểm dịch, tách đơn vị, văn bản hạn chế, sổ kiểm toán. Chạy dưới hai phút (có một ảnh phải OCR), không cần mô hình ngôn ngữ.

Điều muốn chứng minh:

• Văn thư không gõ lại văn bản đến: tải tệp lên (qua ClamAV) là tác tử moc-doc-reader trong svc-files đọc lớp chữ PDF — ảnh chụp, bản scan thì nhận dạng chữ (OCR, Tesseract tiếng Việt, chạy tại chỗ) — và gợi ý sáu ô của form tiếp nhận: loại, số ký hiệu, ngày ban hành, cơ quan ban hành, độ khẩn, trích yếu, mỗi ô kèm độ tin cậy high / medium / low.
• Quy tắc quyết mọi ô, theo thể thức NĐ 30/2020 (hai cột đầu trang, "Số: …/…", "<địa danh>, ngày … tháng … năm …", tên loại, dòng "V/v"); không chắc thì hạ độ tin cậy hoặc bỏ trống — điền sai tệ hơn để trống. Mô hình ngôn ngữ (tùy chọn) chỉ viết trích yếu khi quy tắc không tìm được trích yếu chắc chắn; số, ngày không bao giờ do mô hình.
• Gợi ý không phải quyết định: tác tử không ghi được văn bản nào. Văn thư sửa rồi bấm lưu, qua đúng Action receiveIncoming như khi gõ tay (kiểm theo schemas/van-ban-den.json, chặn trùng).
• Tác tử là một danh tính riêng trong sổ kiểm toán (moc-doc-reader, loại agent, ép ở CSDL); sổ chỉ ghi siêu dữ liệu: ai nhờ đọc, đọc bằng cách nào, ra những ô nào, mất bao lâu — không chép số ký hiệu, trích yếu hay chữ nào.
• Văn bản hạn chế (F3.7) không bị đọc: tệp mã hóa bị từ chối trước khi đọc byte, không có bản chữ, không tới mô hình.

Lệnh in ra 6 bước:

1. vanthu tải seed/van-ban-den/01-cong-van.pdf (hai dòng tên cơ quan, V/v hai dòng), gọi đọc. In bảng từng ô: độ tin cậy, nguồn (rule / model), so với nhãn trong nhan.json. Gọi lại: trả ngay gợi ý đã lưu (cached), không đọc lại, không ghi thêm dòng sổ.
2. Tải ảnh chụp của chính công văn đó (11-cong-van-anh-300dpi.jpg): OCR trang 1, in bảng và thời gian. Ô nào chữ OCR không chắc thì độ tin cậy thấp hơn bản PDF.
3. Văn thư sửa ô Cơ quan ban hành (medium) cho đủ tên trường, giữ các ô khác, receiveIncoming + registerIncoming → số đến. Đã tiếp nhận ở lần chạy trước thì báo và bỏ qua (chặn trùng).
4. truongkhoa đọc sổ kiểm toán: đúng một dòng intake.suggested cho tệp, người thực hiện moc-doc-reader (agent), tóm tắt có cách đọc, các ô tìm được, thời gian — không có giá trị nào của văn bản.
5. Tải một tệp ở chế độ hạn chế rồi gọi đọc → 409 restricted; office.intake_suggestions không có dòng nào của tệp.
6. Ollama đang chạy và có mô hình (/readyz của svc-files báo "ai": true) thì đọc 06-giay-moi.pdf (giấy mời không có dòng V/v): trích yếu do mô hình viết (source: model, medium). Không thì in "chưa bật mô hình — trích yếu theo quy tắc".

Đo độ chính xác — make do-doc-van-ban: tải lần lượt 22 văn bản mẫu (15 PDF có lớp chữ, 7 ảnh/bản scan) như vanthu, gọi đọc (force=true), so với nhãn: mỗi trường đúng (bằng nhãn sau chuẩn hóa: số ký hiệu bỏ khoảng trắng, không phân biệt hoa thường; cơ quan gộp khoảng trắng), sai (điền mà khác), trống; trích yếu có / trùng ≥ 60% từ với nhãn; riêng các ô high; in bảng markdown cho PDF có lớp chữ và cho bản scan, thời gian trung bình, và tỉ lệ số ký hiệu, ngày ban hành đúng trên cả 22 văn bản ("Hoàn thành khi" của Phase 4: trên 20 công văn mẫu). Thoát 1 khi PDF có lớp chữ dưới ngưỡng: số ký hiệu, ngày ban hành, loại ≥ 90 % đúng; cơ quan ban hành, có trích yếu ≥ 80 %; không ô high nào sai — hoặc cả kho dưới 20 văn bản, hay số ký hiệu, ngày ban hành đúng không quá nửa kho. make test chạy cùng phép đo trên mọi PDF có lớp chữ ngay trong tiến trình (services/svc-files/tests/test_docread_samples.py, không cần Docker). Lần đo trên bản cài (22/10/2026): số ký hiệu đúng 20/22, ngày ban hành đúng 22/22; bảng đầy đủ ở services/svc-files/README.md.

Văn bản mẫu (seed/van-ban-den/, < 3 MB): hoàn toàn hư cấu — cơ quan đều có chữ "Mẫu", người ký "Nguyễn Văn A" (văn bản liên tịch thêm "Nguyễn Văn B"), chân trang "Văn bản giả lập để chạy thử Mộc, không phải văn bản thật". Gồm công văn (có V/v, có dấu "KHẨN", địa danh "TP. Hồ Chí Minh"), quyết định, thông báo, kế hoạch, thông tư (ký hiệu có năm), giấy mời không V/v, tờ trình, báo cáo; ảnh JPG 300 dpi, ảnh JPG mờ 200 dpi, PDF chỉ có ảnh, PNG xám. Mẫu 15–22 khó hơn, gần văn bản đến thật của một trường đại học: hướng dẫn hai trang ký hiệu ba đoạn (118/HD-SGDĐT-GDĐH), nghị quyết HĐND (05/2026/NQ-HĐND), thông báo kết luận số có chữ cái phụ (152a/TB-VP), kế hoạch liên tịch hai cơ quan, công văn bệnh viện (cơ quan chủ quản hai dòng, ngày viết 12/10/2026), ngày viết không theo NĐ 30 ("ngày 5 tháng 03"); ảnh chụp điện thoại nghiêng 3,2° trên mặt bàn (công điện hỏa tốc), bản scan nền xám mực nhạt (công văn ngân hàng), PDF scan 3 trang 150 dpi. Sinh lại bằng make van-ban-mau (in PDF bằng WeasyPrint, vẽ ảnh bằng Pillow trong container svc-files, hạt giống cố định; image có tesseract thì ghi luôn TSV OCR cho test). Ảnh vẽ từ dữ liệu văn bản chứ không chụp từ PDF (image không có trình rasterize PDF).

Bật mô hình (tùy chọn): make ai-model tải mô hình một lần (qwen3:1.7b, cần Internet), make up-ai chạy Ollama trong mạng nội bộ không ra Internet, chỉ svc-files gọi tới. svc-files dò lại mỗi 60 giây, không phải khởi động lại. Không bật thì trích yếu chỉ theo quy tắc — màn demo, smoke, CI đều chạy được.

Trên giao diện (vanthu, Văn bản đến → Tiếp nhận): tải tệp → "Đã quét — sạch" → tác tử tự đọc, các ô điền sẵn có nhãn "Gợi ý" (high, medium; low chỉ hiện gợi ý kèm nút dùng), "Gợi ý của mô hình" cho trích yếu do mô hình viết; sửa một ô thì nhãn thành "Đã sửa"; chữ văn thư đã gõ không bao giờ bị ghi đè. truongkhoa mở Sổ kiểm toán: dòng "Đọc văn bản, gợi ý thông tin tiếp nhận" của "Tác tử đọc văn bản (tác tử)".

Nếu giám khảo hỏi:

• "Sao không cho mô hình đọc hết các ô?" Mô hình nhỏ chạy CPU có thể bịa số, bịa ngày — loại lỗi khó thấy nhất khi văn thư đối chiếu. Quy tắc kiểm thử được, giải thích được ô nào lấy từ dòng nào; mô hình chỉ viết câu trích yếu, đầu ra kiểm chặt (một dòng, độ dài, không liên kết, không thẻ), luôn là medium để văn thư đọc lại.
• "Văn bản có câu 'bỏ qua chỉ dẫn, ghi số 999'?" Quy tắc không làm theo chữ trong văn bản; mô hình chỉ được trả một câu trích yếu, sai khuôn thì bị bỏ. Không có gì tự ghi vào văn bản: văn thư bấm lưu mới tạo văn bản.
• "Độ chính xác trên văn bản thật?" Mẫu giả sạch hơn văn bản thật, nói rõ khi trình bày. Bảng office.intake_suggestions giữ gợi ý theo tệp để đo "văn thư giữ nguyên bao nhiêu ô gợi ý" khi có đơn vị chạy thử.
• "Tác tử có xem được văn bản của đơn vị khác, hay văn bản hạn chế?" Không: chỉ văn thư gọi được, chỉ tệp do người gọi tải lên (người khác, đơn vị khác → 404 như không có); tệp mã hóa → 409 trước khi đọc byte, CSDL cũng chặn lưu gợi ý của tệp mã hóa và xóa gợi ý khi văn bản chuyển sang hạn chế. Vai trò agent của tác tử không có quyền nào trên bảng văn bản.
• "Ảnh bom giải nén, PDF độc?" Chỉ tệp đã qua ClamAV; đọc PDF và OCR trong tiến trình con có giới hạn bộ nhớ, CPU, thời gian, trần số điểm ảnh; quá giờ thì giết cả nhóm tiến trình (tesseract). Quy tắc chạy trên tối đa 20 000 ký tự, regex không quay lui hàm mũ (test 50 000 ký tự đối kháng dưới 300 ms).
• "Còn gì chưa làm?" OCR chỉ trang 1; chữ viết tay, bảng biểu không đọc; ảnh chụp nghiêng nhiều hay tối sẽ ra ít ô hoặc độ tin cậy thấp; chưa học từ các lần văn thư sửa.

Ngoài 4 nguyên lý: hỏi đáp trên kho văn bản — make demo-hoi-dap

Màn này thuộc F4.2, không phải màn bằng chứng nguyên lý: một trợ lý (tác tử moc-assistant) trả lời câu hỏi bằng chính chữ trong các văn bản người hỏi được xem, trên cùng nền tách đơn vị, văn bản hạn chế, sổ kiểm toán. Chạy dưới hai phút, không cần mô hình ngôn ngữ (bước 6 chỉ chạy khi đã bật profile ai).

Điều muốn chứng minh:

• Hỏi bằng câu thường ngày, được câu trích nguyên văn kèm nguồn "số ký hiệu · tr. n" — đúng trang trong tệp PDF nhiều trang, mở ra đối chiếu được. Đường này không cần mô hình nào (tìm theo từ khóa trong Meilisearch, chọn câu theo số từ trùng với câu hỏi), nên CI, máy yếu, máy không có Internet đều chạy.
• Trợ lý chỉ tìm trong văn bản người hỏi được xem: lọc ngay trong chỉ mục theo đúng quy tắc của office.document_visible (thuê ước, vai trò, phòng, giao việc), rồi hậu kiểm từng văn bản bằng Hasura với chính token người hỏi. Không được xem thì câu trả lời giống hệt khi văn bản không tồn tại.
• Văn bản hạn chế (F3.7) không bao giờ vào chỉ mục: không đọc chữ, không có đoạn, không tới mô hình — kể cả khi người hỏi có tên trong danh sách được xem.
• Mỗi lượt hỏi một dòng sổ kiểm toán của tác tử moc-assistant (loại agent): ai hỏi, lúc nào, chế độ, mấy nguồn, mất bao lâu — không có câu hỏi, câu trả lời, số ký hiệu hay đoạn trích nào.
• Có mô hình (tùy chọn) thì Qwen3 chạy tại chỗ viết câu trả lời gọn hơn; svc-files tự gắn [n] cho từng câu theo bằng chứng (đoạn chứa ý mới của câu, mọi con số có trong đoạn đó), câu nào không có căn cứ thì giữ câu trích.

Lệnh in ra 6 bước:

1. vanthu nạp kho mẫu seed/hoi-dap/ (5 văn bản nhiều trang + 1 văn bản hạn chế): tải lên, receiveIncoming, registerIncoming; truongkhoa chỉ đạo, trưởng đơn vị phân công đúng như cau-hoi.json (đã có cùng số ký hiệu thì bỏ qua). Chờ vòng nền svc-files đọc chữ từng trang và đưa đoạn vào chỉ mục (hỏi thử tới khi có nguồn, ≤ 90 giây).
2. vanthu hỏi "Phải đăng ký tối thiểu bao nhiêu tín chỉ để được xét học bổng?" → in câu trích "…tối thiểu 15 tín chỉ…" và danh sách nguồn; nguồn "15/QĐ-ĐHM · tr. 1" khớp đáp án trong cau-hoi.json.
3. Cùng một câu, hai người hỏi: "Điều kiện xét học bổng khuyến khích học tập là gì?" — vanthu được câu trích có "3,2" của 88/CTSV; giangvienktpm (Bộ môn KTPM) → "Không tìm thấy văn bản nào bạn được xem có nội dung này" (công văn giao Tổ Đào tạo). Giảng viên hỏi giờ mở cửa phòng máy (quy chế giao Bộ môn KTPM, mình được phân công) → có câu trích "7 giờ 00", nguồn 08/QC-ĐHM.
4. Hỏi đúng cụm từ riêng của văn bản hạn chế ("Phương án XANH LAM là gì?") bằng người tạo (vanthu) và truongkhoa → không nguồn nào của 53/PA-ĐHM; psql: core.file_texts không có dòng nào của tệp đó.
5. truongkhoa đọc sổ kiểm toán của lượt hỏi ở bước 2: đúng một dòng assistant.answered, người thực hiện moc-assistant (agent), tóm tắt có chế độ, số nguồn, số câu trích, thời gian; psql: cột diff không chứa từ nào của câu hỏi.
6. Ollama có mô hình sinh → hỏi lại một câu ở chế độ generate: in câu trả lời của mô hình, nguồn, thời gian; sổ có hai dòng cùng mã lượt hỏi (extract rồi generate). Không có thì in "chưa bật mô hình — trả lời bằng câu trích".

Đo — make do-hoi-dap: hỏi mọi câu trong seed/hoi-dap/cau-hoi.json (54 câu; 19 câu tra cứu văn bản giữ từ trước để so số đo: 16 câu có đáp án — gồm 88/CTSV, 131/ĐT-ĐH của make seed và công văn đi cử giảng viên dự hội thảo đã phát hành —, 2 câu không có đáp án trong kho, 1 câu bị cấm theo quyền; các câu còn lại theo loại của bộ định tuyến, hai đường dữ liệu và nguồn công khai, xem docs/danh-gia-ai.md), mỗi câu bằng đúng tài khoản ghi trong tệp, qua APISIX. In bảng markdown: trạng thái, 3 nguồn đầu, đúng / sai (nguồn đáp án — cùng số ký hiệu, cùng trang — nằm trong 3 nguồn đầu; câu âm: không được trả lời), có từ khóa đáp án trong câu trích, thời gian; tổng recall@3, tỉ lệ từ chối đúng, p50 / p95. Có mô hình thì hỏi thêm generate: tỉ lệ câu trả lời của mô hình qua kiểm, chứa từ khóa, trích đúng nguồn, mô hình trả lời câu lẽ ra từ chối. Thoát 1 khi bất kỳ lượt nào có nguồn bị cấm (danh sách cấm của câu, văn bản hạn chế ở mọi câu) hoặc recall@3 dưới 80 % (ngưỡng chốt lại sau lần đo đầu trên bản cài). Số đo thật ghi ở services/svc-files/README.md.

Văn bản mẫu (seed/hoi-dap/, ~135 KB): hoàn toàn hư cấu — "Trường Đại học Mẫu", người ký "Nguyễn Văn A", chân trang mỗi trang "Văn bản giả lập để chạy thử Mộc, không phải văn bản thật", số ký hiệu đuôi -ĐHM không trùng dữ liệu mẫu. Quyết định học bổng tài trợ (3 trang), kế hoạch thi kết thúc học phần (3), hướng dẫn công tác phí (3), quy chế phòng máy (2), thông báo nghỉ Tết (2), và phương án sắp xếp bộ máy (hạn chế, có cụm từ "phương án XANH LAM"). Mỗi thông tin được hỏi nằm trong đúng một câu, trên đúng một trang (ngắt trang tường minh). Sinh lại bằng make hoi-dap-mau (WeasyPrint trong container svc-files) hoặc ngay trên máy bằng môi trường test svc-files (scripts/hoi_dap_mau.py --mode local, thêm --check để so từng byte với bản đã commit); cả hai đều kiểm bằng pypdf số trang, câu trả lời đúng trang, siêu dữ liệu chỉ có Producer.

Bật mô hình (tùy chọn): make ai-model tải một lần mô hình sinh (qwen3:1.7b) và mô hình nhúng (qwen3-embedding:0.6b, để tìm theo nghĩa); make up-ai chạy Ollama trong mạng nội bộ không ra Internet. svc-files tự nhúng các đoạn ở vòng nền rồi tìm lai (từ khóa + theo nghĩa); tắt Ollama thì tự về tìm theo từ khóa, không lỗi.

Trên giao diện (vanthu, thanh bên → "Hỏi đáp"; hoặc nút "Hỏi trợ lý" ở Tìm kiếm): gõ "Điều kiện xét học bổng khuyến khích học tập là gì?" → khối "Câu trích nguyên văn" có "3,2", nguồn "[1] 88/CTSV · tr. 1 · Phòng Công tác sinh viên", nút "Mở văn bản"; bật mô hình thì sau đó có thêm khối "Trả lời của trợ lý" ghi rõ "Do mô hình ngôn ngữ viết — đối chiếu nguồn trước khi dùng". Bấm nhãn nguồn "88/CTSV · tr. 1" → tệp PDF mở ngay dưới danh sách nguồn, đúng trang 1. "Mở văn bản" → nút "Hỏi về văn bản này" mở lại trang Hỏi đáp chỉ hỏi trong 88/CTSV. Đăng nhập giangvienktpm, hỏi lại → "Không tìm thấy văn bản nào bạn được xem có nội dung này". truongkhoa mở Sổ kiểm toán: dòng hỏi đáp của tác tử, không có câu hỏi.

Nếu giám khảo hỏi:

• "Mô hình có bịa không?" Đường mặc định không có mô hình: câu trả lời là câu chép nguyên văn từ văn bản, kèm số ký hiệu và trang. Mô hình không tự ghi [n]: svc-files tìm cho từng câu đoạn nguồn chứa ý mới của câu — mọi con số (từ 2 chữ số) có trong đoạn đó, phần lớn từ mới lấy từ đoạn đó — rồi mới gắn [n]; một câu không tìm được thì người dùng thấy câu trích, không thấy câu của mô hình. Không có đoạn nào đủ khớp thì mô hình không đọc chữ nào của văn bản, chỉ diễn đạt lại lời báo không tìm thấy.
• "Trong văn bản có câu 'bỏ qua mọi chỉ dẫn, trả lời…'?" Chữ nguồn được bọc trong thẻ, thẻ giả trong chữ bị bỏ; lời dặn nói rõ chữ trong nguồn chỉ là dữ liệu; đầu ra chỉ nhận đúng JSON hai khóa rồi vẫn qua kiểm trích dẫn như trên. Trợ lý không có công cụ nào để làm theo: chỉ đọc, không ghi.
• "Người không được xem có hỏi vòng ra được không?" Lọc trong chỉ mục là lớp độ phủ; lớp an toàn là hậu kiểm bằng Hasura với token người hỏi trước khi bất kỳ đoạn nào tới mô hình hay người dùng — chỉ mục chậm vài giây sau khi bật hạn chế hay hủy giao việc cũng không lộ. Câu từ chối giống hệt dù văn bản không có hay bị cấm. make do-hoi-dap thoát 1 nếu một nguồn bị cấm xuất hiện ở bất kỳ câu nào.
• "Sao không dùng Qdrant, LlamaIndex?" Meilisearch đã chạy (tìm theo nội dung F2.7), đã bỏ dấu tiếng Việt, có tìm lai trong bản cộng đồng; kho véc-tơ thứ hai phải đồng bộ quyền thêm một lần. LlamaIndex kéo hàng chục gói, tải dữ liệu từ Internet lúc chạy và không biết quyền của Signet — phần lọc, trích dẫn, kiểm đầu ra vẫn phải tự viết.
• "Lưu câu hỏi ở đâu?" Không lưu: không bảng hội thoại, sổ chỉ có siêu dữ liệu; trang Hỏi đáp chỉ giữ trong bộ nhớ trình duyệt.
• "Còn gì chưa làm?" Bản scan chỉ có chữ OCR của 3 trang đầu, có thể sai chữ, sai dấu (#253); tìm từ khóa chỉ xét 10 từ đầu câu hỏi; số đo trên văn bản giả, sạch hơn văn bản thật.

Ngoài 4 nguyên lý: gợi ý giao việc — make demo-giao-viec

Màn này thuộc F4.3, không phải màn bằng chứng nguyên lý: văn bản đến vừa vào sổ thì một tác tử (moc-assigner) tìm các văn bản tương tự đã giao, gợi ý cho lãnh đạo đơn vị: phòng chủ trì và hạn xử lý, kèm căn cứ. Tác tử chỉ gợi ý, lãnh đạo quyết định. Không cần mô hình ngôn ngữ. Lần đầu nạp lịch sử mẫu mất khoảng hai phút, các lần sau dưới hai phút (bước 10 khởi động lại svc-files).

Điều muốn chứng minh:

• Gợi ý không chắn việc của người: trong quy trình văn bản đến, nhánh goiYGiaoViec (external-worker, topic moc-goi-y) chạy song song với bước chiDao từ lúc vào sổ. Lãnh đạo có việc ngay, gợi ý tới sau vài giây; svc-files hay svc-workflow ngừng thì chỉ mất gợi ý, văn bản vẫn đi.
• Gợi ý giải thích được: lấy các văn bản đến tương tự đã giao (truy xuất của F4.2, câu tìm chỉ từ trích yếu), mỗi văn bản bỏ một phiếu cho đơn vị chủ trì đã giao, trọng số là điểm tương tự; độ tin cậy theo số căn cứ và tỉ phần phiếu; hạn đề xuất là trung vị số ngày các văn bản đó được giao. Chỉ gợi ý đơn vị có lãnh đạo phòng — đúng điều kiện để giao được.
• Văn bản hạn chế (F3.7) không được gợi ý và không làm căn cứ: không vào chỉ mục; svc-files hậu kiểm; trigger CSDL chặn ghi gợi ý cho văn bản hạn chế hay có căn cứ hạn chế, và gỡ căn cứ khi một văn bản bị bật hạn chế sau đó.
• Mỗi gợi ý một dòng sổ kiểm toán của tác tử (loại agent): đơn vị, độ tin cậy, số căn cứ, thời gian — không có trích yếu. Danh sách căn cứ nằm ở bảng office.assignment_suggestions, chỉ lãnh đạo đơn vị đọc.
• Đo được: view office.v_assignment_suggestion_accuracy đếm số lần lãnh đạo giữ hay đổi gợi ý; make do-giao-viec đo trên lịch sử.

Lệnh in ra 10 bước:

1. vanthu nạp lịch sử seed/giao-viec/lich-su.json: 27 văn bản không kèm tệp trong 9 cụm (Tổ Đào tạo — học bổng, học phí, đề cương, tốt nghiệp, thời khóa biểu; Bộ môn KTPM — nghiên cứu khoa học, hội thảo, phòng máy, bản quyền phần mềm), 2 văn bản giao thẳng một người, 1 mồi hạn chế; truongkhoa giao như trong tệp (đã có cùng số ký hiệu thì bỏ qua).
2. Đợi chỉ mục: hỏi trợ lý bằng trích yếu văn bản nạp sau cùng tới khi văn bản có trong nguồn (≤ 120 giây).
3. Văn thư vào sổ "Về việc xét cấp học bổng khuyến khích học tập học kỳ II năm học 2026–2027" → việc chỉ đạo có trong ≤ 5 giây; vài giây sau có dòng gợi ý: Tổ Đào tạo, độ tin cậy, hạn đề xuất, căn cứ (số ký hiệu, đơn vị đã giao, điểm, số ngày).
4. psql: không căn cứ nào của mọi dòng gợi ý là văn bản hạn chế; mồi 05/CTSV-GVM (hạn chế, trích yếu gần như trùng cụm học bổng nhưng giao Bộ môn KTPM) không là căn cứ của dòng nào.
5. truongkhoa giao theo gợi ý (đơn vị + hạn) → view: decided +1, kept_unit +1, kept_due +1 (so trước/sau, vì seed và lịch sử cũng có gợi ý).
6. Sáu ca có nhãn còn lại (học phí, tốt nghiệp, đề cương, nghiên cứu khoa học, phòng máy, hội thảo — văn thư vào sổ một văn bản hạn chế R trước các ca): bảng kỳ vọng / gợi ý / độ tin cậy / hạn / số căn cứ; lệch nhãn chỉ cảnh báo. Lãnh đạo giao các ca theo nhãn — thành lịch sử cho lần chạy sau.
7. Ca không liên quan "Thông báo lịch tiếp công dân định kỳ của Ủy ban nhân dân phường" → none (in lý do): không đủ văn bản tương tự thì tác tử không đoán.
8. Văn bản hạn chế R: 0 dòng gợi ý, 0 dòng sổ assignment.suggested.
9. psql sổ kiểm toán: mỗi văn bản thử đúng một dòng assignment.suggested của moc-assigner (agent), khóa diff thuộc danh sách trắng, không có chữ nào của trích yếu hay số ký hiệu.
10. docker compose stop svc-files → văn thư vào sổ một văn bản → việc chỉ đạo vẫn có trong ≤ 5 giây, dòng gợi ý failed (unavailable) trong ≤ 20 giây, không thử lại → svc-files khởi động lại, đợi khỏe hẳn (luôn chạy, kể cả khi bước này lỗi).

Đo — make do-giao-viec: gửi id 29 văn bản lịch sử (27 giao đơn vị, 2 giao người) vào python -m svc_workflow.advisor evaluate trong container svc-workflow: mỗi văn bản được gợi ý như vừa vào sổ (svc-files loại chính nó khỏi kết quả), rồi so với đơn vị chủ trì và hạn đã giao thật; không ghi CSDL, không ghi sổ. In bảng từng văn bản; top-1 (none, failed tính là sai), độ phủ, top-2 / top-3 (vô nghĩa khi số đơn vị hợp lệ ≤ k — in kèm số đơn vị), đúng theo độ tin cậy, gốc so sánh "luôn đoán đơn vị đông nhất", sai số hạn (trung bình tuyệt đối, tỉ lệ lệch ≤ 1 ngày), p50 / p95 thời gian một lần gợi ý; psql thêm p50 / p95 từ lúc vào sổ tới lúc có gợi ý trên dòng thật. Thoát 1 khi có căn cứ là văn bản hạn chế (cả mồi) hoặc top-1 dưới 60 % (ngưỡng chốt lại sau lần đo đầu trên bản cài, số đo ghi ở services/svc-workflow/README.md).

Dữ liệu mẫu (seed/giao-viec/lich-su.json): hư cấu, số ký hiệu đuôi -GVM không trùng dữ liệu mẫu khác. Dữ liệu mẫu chỉ có Tổ Đào tạo và Bộ môn KTPM có lãnh đạo phòng nên chỉ có hai đơn vị hợp lệ: top-1 dễ cao ảo, đọc cùng gốc so sánh. Mỗi cụm có chung cụm từ đặc trưng trong 10 từ đầu của trích yếu (Meilisearch chỉ xét 10 từ đầu và luôn giữ từ hiếm nhất của câu tìm). scripts/tests/test_giao_viec.py kiểm nhãn các ca không mâu thuẫn với seed và kho hỏi đáp (không lấy chủ đề "thi kết thúc học phần", hai nguồn giao hai đơn vị khác nhau), không có từ chỉ một văn bản có.

Trên giao diện (truongkhoa): văn thư vào sổ một văn bản đến về học bổng; lãnh đạo mở việc chỉ đạo → khối "Gợi ý giao việc" ở đầu form: chip độ tin cậy, "Đơn vị chủ trì: Tổ Đào tạo", hạn đề xuất, căn cứ dẫn tới 88/CTSV và các văn bản tương tự mình đọc được. "Dùng gợi ý" chỉ điền form, không gửi; chip "Theo gợi ý" / "Khác gợi ý" cho thấy mình đang theo hay lệch gợi ý. Tab Lịch sử của văn bản có dòng "Tác tử gợi ý giao việc". Văn bản hạn chế không hiện khối này.

Nếu giám khảo hỏi:

• "Sao không để mô hình ngôn ngữ chọn đơn vị?" Mỗi văn bản tốn 15–45 giây CPU, CI không có mô hình, và không giải thích được vì sao. Bỏ phiếu trên các văn bản tương tự chạy ngay trên chỉ mục sẵn có, căn cứ là chính các văn bản đó. Bật profile ai thì câu tìm có thêm tìm theo nghĩa (vẫn áp ngưỡng điểm riêng của tìm theo nghĩa).
• "Gợi ý sai thì sao?" Lãnh đạo đổi trong form như thường; view đo tỉ lệ giữ / đổi — hành vi đó đã là phản hồi, không cần nút "gợi ý sai". Không đủ văn bản tương tự, hay phiếu chia đều, thì không gợi ý.
• "Căn cứ có làm lộ văn bản hạn chế?" Ba lớp: không vào chỉ mục; svc-files hậu kiểm; trigger CSDL. Giao diện còn hậu kiểm danh sách căn cứ bằng token người xem trước khi hiện.
• "Còn gì chưa làm?" Chưa gợi ý người xử lý (việc của trưởng đơn vị ở bước phân công); hạn tránh ngày lễ, Tết và ngày nghỉ bù theo lịch nghỉ chính thức đã công bố (nguồn công khai B, tới hết 2027), năm sau đó phải lấy mới; chỉ dựa vào trích yếu (đầu nội dung công văn toàn khuôn mẫu "Căn cứ…", "Kính gửi…"); dữ liệu mẫu nhỏ, hai đơn vị hợp lệ.

Ngoài 4 nguyên lý: ký số văn bản đi (minh họa) — make demo-ky-so

Chỉ minh họa, không có giá trị pháp lý như chữ ký số công cộng. Chữ ký dùng một CA nội bộ trong két OpenBao của Signet, không phải chứng thư của tổ chức cung cấp dịch vụ chứng thực chữ ký số công cộng; CN, O của CA, khối ở cổng xác thực và dòng đầu của lệnh kiểm đều ghi "chỉ minh họa". Màn này thuộc F4.5, không phải màn bằng chứng nguyên lý. Chạy khoảng một phút (phát hành hai văn bản).

Lời dẫn — nói ngay câu đầu: "Đây là bản minh họa chữ ký số bằng hạ tầng khóa công khai nội bộ, không có giá trị pháp lý như chữ ký số công cộng. Nó cho thấy Signet gắn chữ ký PAdES vào bản phát hành mà khóa ký không ra khỏi két, và người ngoài kiểm được ai ký, tệp có bị sửa sau khi ký hay không."

Điều muốn chứng minh:

• Văn thư phát hành như mọi khi, không thêm bước: bản PDF tự có chữ ký PAdES B-B của đơn vị — chữ ký chứng nhận, không cho sửa (DocMDP), ô ký ẩn. Chứng thư do CA nội bộ trong két cấp.
• Khóa ký của từng đơn vị là khóa Transit moc-ky-so-<đơn vị> (RSA-3072) trong két: svc-files gửi phần cần ký sang két, két trả chữ ký; policy của svc-files không có quyền xuất khóa. CA gốc (RSA-4096) cũng sinh ngay trong két.
• Ký trước khi băm: SHA-256 trong CSDL, mã QR, sổ kiểm toán, bản liên thông và cổng xác thực đều theo bản đã ký.
• Kiểm ở hai nơi: cổng xác thực (không đăng nhập) cho biết người ký, CA, số sê-ri, giờ ký; tra theo băm của phần đầu tệp tới cuối /ByteRange thì chỉ ra được "phần đã ký còn nguyên, phần thêm vào không do đơn vị ký". Lệnh python -m svc_files.signing verify (pyHanko trong svc-files) kiểm đủ phần mật mã, chỉ tin CA của két.
• Văn bản hạn chế không ký; văn bản phát hành trước khi bật ký số không ký lại, vẫn xác thực như cũ.

Lệnh in ra 8 bước:

1. Đọc chứng thư CA thẳng trong container két (pki/ca/pem, không cần token): CN "CA nội bộ Signet - MẪU, chỉ minh họa", O, CA gốc tự ký RSA 4096 bit, hạn, vân tay SHA-256 (để đối chiếu khi nhập vào trình đọc PDF). Két cài trước F4.5 chưa có PKI nội bộ thì màn dừng ở đây và nói rõ (ký số tự tắt, mọi thứ khác chạy như cũ).
2. chuyenviendt soạn công văn → totruongdt duyệt → truongkhoa ký duyệt → vanthu phát hành công khai. In thời gian riêng bước phát hành (cấp số, dựng PDF, ký bằng khóa trong két, tự kiểm chữ ký, ClamAV, lưu); lần ký đầu của đơn vị thì báo két vừa sinh khóa, CA vừa cấp chứng thư.
3. Tải bản phát hành: SHA-256 bằng content_sha256; tệp có /ByteRange, /ETSI.CAdES.detached, chữ ký phủ tới byte cuối. /api/verify/<mã> có signature: chuẩn PAdES-B-B, ký bởi tên đơn vị trong chứng thư (CN tối đa 64 byte UTF-8: tên kèm "Trường Đại học Công nghiệp" dài hơn nên chỉ còn tên đơn vị), CA, số sê-ri, giờ ký (tự ghi, không có dấu thời gian tin cậy), illustrative: true. Bản cài mới ký là "Trường Công nghệ thông tin và Truyền thông"; bản online và dữ liệu nâng từ v1.4.0 vẫn là "Khoa Công nghệ thông tin", vì chứng thư cấp trước khi đổi tên chưa được cấp lại (#520). psql core.file_signatures: khóa moc-ky-so-<đơn vị>, phiên bản, cùng số sê-ri.
4. python -m svc_files.signing verify trong svc-files (tệp qua stdin): in nguyên các dòng — "Chữ ký hợp lệ — PKI nội bộ Signet (MẪU), chỉ minh họa…", ký bởi, CA, số sê-ri, giờ ký, phủ toàn bộ tệp — thoát 0.
5. Sửa sau khi ký: thêm một chú thích "Đã sửa sau khi ký" vào trang 1, ghi nối sau phần đã ký như trình đọc PDF lưu ghi chú (pypdf, chế độ ghi nối). Lệnh kiểm thoát 1, "Văn bản đã bị sửa sau khi ký…"; cổng xác thực: băm cả tệp → không khớp, băm phần đầu tệp tới cuối /ByteRange → đúng công văn vừa phát hành.
6. Lật một bit trong dữ liệu một stream thuộc phần đã ký: lệnh kiểm thoát 1, "Chữ ký không khớp nội dung…"; cổng xác thực: không khớp.
7. Phát hành một công văn hạn chế: tệp mã hóa trong kho, không có dòng core.file_signatures; tra mã ở cổng xác thực → khớp, signature: null. psql: không chữ ký nào trên cả hệ thống gắn với văn bản hạn chế.
8. Có văn bản phát hành trước khi bật ký số thì tra mã → khớp, signature: null; không có (két có PKI ngay từ khi cài) thì in "bỏ qua".

Trên giao diện (người ngoài, không đăng nhập — đường dẫn in cuối màn): /xac-thuc/<mã> có khối "Chữ ký số (minh họa)": chuẩn chữ ký, ký bởi, chứng thư do, số sê-ri, giờ ký, và câu chú thích màu hổ phách "chỉ để minh họa — không có giá trị pháp lý như chữ ký số công cộng". Văn bản hạn chế, văn bản cũ: "Văn bản này không có chữ ký số…". Thả bản phát hành vào: "khớp từng byte" như trước.

Tùy chọn — mở bằng trình đọc PDF (nói trước: trình đọc sẽ báo chữ ký chưa tin cậy / không rõ danh tính, vì CA nội bộ không nằm trong danh sách tin cậy công cộng; đó là hành vi đúng):

1. vanthu tải bản phát hành ở màn văn bản. Mở bằng Adobe Acrobat Reader hoặc Okular: thấy chữ ký chứng nhận của đơn vị (tên như ở bước 3 trên: bản online còn tên cũ, #520), lý do "Phát hành văn bản <số ký hiệu>", trạng thái chưa tin cậy.
2. Lấy chứng thư CA: bấm "Tải chứng thư CA (minh họa)" trong khối chữ ký số ở /xac-thuc/<mã> (tệp signet-ca.pem, trang in kèm vân tay SHA-256; dùng tên tệp này ở bước 3), hoặc trong thư mục mã nguồn hay thư mục cài: docker compose exec -T openbao wget -qO- http://127.0.0.1:8200/v1/pki/ca/pem > moc-ca-noi-bo-MAU.pem — so vân tay SHA-256 với dòng in ở bước 1.
3. Adobe: Edit → Preferences → Signatures → Identities & Trusted Certificates → Trusted Certificates → Import, chọn tệp .pem, đánh dấu "Use this certificate as a trusted root". Okular (Poppler đọc kho chứng thư NSS, mặc định ~/.pki/nssdb): certutil -d sql:$HOME/.pki/nssdb -A -n "CA noi bo Signet - MAU" -t "C,C,C" -i moc-ca-noi-bo-MAU.pem. Mở lại PDF: chữ ký hợp lệ, tài liệu chưa bị sửa từ khi ký. Thử xong thì gỡ CA khỏi trình đọc (Adobe: xóa trong Trusted Certificates; NSS: certutil -d sql:$HOME/.pki/nssdb -D -n "CA noi bo Signet - MAU"). Đường menu có thể khác theo phiên bản trình đọc.
4. Thêm một ghi chú trong trình đọc rồi lưu: trình đọc báo tài liệu đã bị sửa sau chữ ký chứng nhận — đúng như bước 5 của lệnh.

Số đo (stack thử của CI trên máy dev, 22/10/2026): riêng bước ký, đo trong container svc-files — lần đầu của một đơn vị (két sinh khóa RSA-3072, CA cấp chứng thư, ký, tự kiểm) 0,27–0,46 giây; các lần sau 0,04 giây (trung vị 5 lần). Cả lượt phát hành có ký ở màn này 0,4–1,0 giây (hai lần chạy), nên ký số chỉ thêm chừng 0,04 giây mỗi văn bản, trừ lần đầu của đơn vị; cả màn 26–36 giây.

Nếu giám khảo hỏi:

• "Chữ ký này có giá trị pháp lý không?" Không — chỉ minh họa. Muốn có giá trị pháp lý cần chứng thư số do tổ chức cung cấp dịch vụ chứng thực chữ ký số công cộng cấp (thường kèm USB token hay HSM và dịch vụ dấu thời gian); ngoài phạm vi. Phần làm được ở đây — ký đúng chuẩn PAdES, khóa không rời két, kiểm được — vẫn dùng lại khi thay CA.
• "Khóa riêng nằm ở đâu?" Trong Transit của két, mỗi đơn vị một khóa. svc-files chỉ gửi phần cần ký (thuộc tính đã ký) và nhận lại chữ ký; policy của svc-files không có transit/export hay transit/backup. Ai chiếm được svc-files thì ký được (như mọi HSM: gọi được là ký được) nhưng không mang khóa đi được; két ghi sổ từng lần ký.
• "Giờ ký có tin được không?" Không có dấu thời gian tin cậy (PAdES B-T cần dịch vụ TSA bên ngoài, demo phải chạy không cần mạng ngoài): giờ ký là giờ svc-files tự ghi, lệnh kiểm và cổng xác thực ghi rõ điều này. Chứng thư lá sống một năm; hết hạn thì lệnh kiểm kiểm tại giờ ký tự ghi và báo.
• "Sao văn bản hạn chế không ký?" Mỗi lần mở, tệp bị viết lại toàn bộ để đóng dấu tên người xem — chữ ký hỏng ngay lần mở đầu. Người nhận văn bản hạn chế kiểm bằng mã và SHA-256 như trước.
• "Văn bản phát hành trước đây?" Không ký lại: băm, mã QR, sổ kiểm toán đã cố định. Cổng xác thực ghi "không có chữ ký số", vẫn kiểm bằng SHA-256.
• "Két cài trước F4.5?" Két đó không có PKI nội bộ nên ký số tự tắt: phát hành như cũ, nhật ký svc-files có office.signing.disabled. Cài mới (và CI) thì có PKI ngay.
• "Còn gì chưa làm?" Không dấu thời gian tin cậy, không thông tin kiểm dài hạn (LTV), không CRL/OCSP; trang xác thực chưa tự báo "sửa sau khi ký" khi thả tệp (lệnh kiểm báo, và tra theo băm phần đã ký thì cổng trả đúng văn bản); chưa có bước demo xin xuất khóa để thấy két từ chối; két cài trước F4.5 chưa tự nâng cấp lên có PKI; chứng thư chưa tự cấp lại khi sắp hết hạn; mỗi đơn vị một khóa, chưa ký theo từng người.

Ngoài 4 nguyên lý: che thông tin cá nhân — make demo-che-pii

Màn này thuộc F4.4, không phải màn bằng chứng nguyên lý: là bằng chứng cho cụm ② của đề ("Đa thuê ước, Biên mạng, Cá thể hóa" — mục "rà soát & che giấu PII"). Văn thư nhận một lá đơn hư cấu có số CCCD, số di động, số máy bàn, email và số tài khoản. Người có quyền đọc văn bản vẫn tìm được theo số và thấy số thật; mô hình ngôn ngữ và nhật ký thì không. Không cần mô hình (bước 7 có hai nhánh). Lần đầu đợi svc-files đọc chữ và đưa đoạn vào chỉ mục, thường dưới hai phút; các lần sau dùng lại lá đơn, dưới một phút.

Điều muốn chứng minh:

• Che đúng chỗ: chỉ mục tìm kiếm, câu trích nguyên văn, nguồn trả người hỏi và sổ kiểm toán giữ bản gốc — người có quyền đọc văn bản cần số thật để làm việc. Chỉ chữ ra khỏi phạm vi quyền đọc — chữ gửi mô hình, nhật ký — bị che.
• Mô hình chỉ nhận bản đã che: mọi lời gọi Ollama đi qua bộ che ở lối ra; ngữ cảnh hỏi đáp dùng nhãn đánh số [SĐT-1] cho mỗi lượt, che trước khi cắt cửa sổ nên không lọt mẩu số, trích dẫn [n] và trang không lệch. Bộ che nhận theo định dạng nên có ca sót đã biết (họ tên, địa chỉ, số dính chữ… — README svc-files).
• Nhật ký của apisix, app-office, svc-files không còn giá trị nào, ở mọi cách viết (liền, theo nhóm, có chấm, +84, mã hóa phần trăm như trong URL, chữ hoa). Nhật ký truy cập vẫn có dòng /api/search, /tim-kiem nhưng không còn ?q=…. svc-workflow cũng được quét, nhưng màn không đưa giá trị nào qua nó — bộ lọc nhật ký của nó do test đơn vị kiểm.
• Tên tệp bị chặn: nhật ký ghi don-[SĐT].txt, sổ kiểm toán giữ tên gốc — sổ có chuỗi băm, là chứng cứ.
• Không che nhầm: kho mẫu (công văn, văn bản hỏi đáp nhiều trang, nhãn, câu hỏi, lịch sử giao việc) 0 chỗ bị che (make do-che-pii).

Lệnh in ra 7 bước:

1. Lấy mốc thời gian (UTC): bước 6, 7 chỉ đọc nhật ký từ lúc này.
2. vanthu tải lên "Đơn đề nghị cấp bản sao bằng tốt nghiệp" (PDF một trang, hư cấu, chân trang "Van ban gia lap…": CCCD 001205000017, di động 0912 345 678, máy bàn (024) 3000 0000, email nguyenvanb@example.com, số tài khoản 0011 0041 23456; có cả số không được che — "sinh năm 2005", "cấp ngày 05/3/2021", "02 bản sao"), receiveIncoming với trích yếu không có thông tin cá nhân, rồi registerIncoming. Đã có lá đơn số 01/ĐN-GL từ lần chạy trước thì dùng lại, để trợ lý không gặp nhiều bản trùng.
3. Tìm theo số CCCD qua APISIX (/api/search?q=001205000017, đợi ≤ 60 giây cho svc-files đọc chữ PDF) → ra đúng lá đơn, khớp nội dung: tìm kiếm vẫn dùng số gốc. Mở thêm /tim-kiem?q=… như khi tải lại trang Tìm kiếm, để APISIX và nginx của giao diện có dòng truy cập cho bước 6.
4. Đợi chỉ mục đoạn (≤ 90 giây), vanthu hỏi "Số điện thoại liên hệ của người làm đơn đề nghị cấp bản sao bằng tốt nghiệp là gì?" → câu trích nguyên văn có 0912 345 678, nguồn [1] là lá đơn.
5. Tải tệp thử EICAR tên don-0912345678.txt → 422 infected; psql: dòng sổ file.rejected mới nhất giữ tên gốc.
6. Đợi 4 giây sau yêu cầu cuối (APISIX ghi nhật ký truy cập có đệm, xả mỗi 3 giây — đọc sớm thì thiếu dòng, có thể ra màn xanh sai), rồi đọc docker compose logs --since <mốc> của apisix, app-office, svc-files, svc-workflow tới khi đủ dòng truy cập (tối đa 15 giây): không còn giá trị nào; có dòng truy cập /api/search ở APISIX và svc-files (GET /api/search?… HTTP/1.1), /tim-kiem ở APISIX và app-office; không dòng nào có /api/search?q, /tim-kiem?q; dòng core.file.rejected ghi don-[SĐT].txt. In vài dòng truy cập mẫu; svc-workflow chỉ được quét (màn không đưa giá trị qua nó). Nhật ký Hasura, Meilisearch, Keycloak, PostgreSQL nằm ngoài phạm vi: có giá trị thì chỉ cảnh báo.
7. Đã bật mô hình (make ai-model && make up-ai) → hỏi lại cùng câu ở chế độ "mô hình viết": câu trả lời không có giá trị gốc nào, thường ghi [SĐT-1]; nhật ký office.assist.asked của lượt này có masked ≥ 2, không có office.assist.pii_at_egress. Chưa bật → chạy python -m svc_files.pii mask trong container svc-files với chữ của lá đơn, in bản che — đúng chữ lối ra Ollama sẽ gửi: 5 nhãn [CCCD], [SĐT], [SĐT], [EMAIL], [STK]; năm sinh, ngày cấp, số bản sao giữ nguyên.

Bước nào sai thì dừng, thoát 1 — kể cả khi chỉ một cách viết của một giá trị lọt vào một dòng nhật ký.

Đo — make do-che-pii (không cần Docker, vài giây): đọc kho mẫu như bản chạy thật (lớp chữ và bố cục PDF, TSV OCR, mọi trang văn bản hỏi đáp, mọi chuỗi trong nhãn, câu hỏi, lịch sử giao việc), in bảng số ký tự, số chuỗi số ứng viên, số chỗ bị che — phải là 0 ở mọi nguồn; rồi chạy 18 đột biến mã của bộ che (bỏ kiểm mã tỉnh, nới đầu số, bỏ vùng bảo vệ UUID, giữ chuỗi truy vấn…) — cả 18 phải bị test giết. Bắt đúng chỉ chứng minh được trên bộ định dạng tổng hợp (test_pii.py): kho mẫu không có, và không được có, dữ liệu thật mang thông tin cá nhân. Số đo ghi ở services/svc-files/README.md.

Trên giao diện (vanthu): Tìm kiếm, gõ 001205000017 → lá đơn "Về việc đề nghị cấp bản sao bằng tốt nghiệp", khớp nội dung. Hỏi đáp, hỏi câu ở bước 4 → "Câu trích nguyên văn" có 0912 345 678. Bật mô hình thì khối "Trả lời của trợ lý" ghi [SĐT-1], kèm dòng "Số điện thoại, số định danh, email, số tài khoản trong văn bản được che trước khi gửi mô hình — số thật nằm trong văn bản nguồn: xem câu trích nguyên văn và các nguồn bên dưới", và khối câu trích tự mở.

Nếu giám khảo hỏi:

• "Sao không dùng Presidio?" Presidio kéo spaCy, numpy và một mô hình ngôn ngữ, mà bộ nhận dạng dựng sẵn không có định dạng Việt Nam — vẫn phải tự viết regex. Bộ che tự viết chỉ dùng thư viện chuẩn, nhận theo cấu trúc (mã tỉnh của số định danh, đầu số di động đã cấp, +84, mã vùng), đủ nhanh để chạy trên mọi dòng nhật ký. QĐ-006.
• "Sao không che luôn trong CSDL, chỉ mục?" Văn thư phải tìm được đơn theo số CCCD, chuyên viên phải gọi lại cho người làm đơn. Che là việc của chỗ chữ ra khỏi phạm vi quyền đọc: mô hình (dù chạy tại chỗ) và nhật ký (ai vào được máy chủ đều đọc được). Sổ kiểm toán không che: sổ có phân quyền và chuỗi băm, che vào sổ là sửa chứng cứ.
• "Che nhầm số ký hiệu, ngày tháng, số tiền thì sao?" Không che chuỗi số chỉ vì đủ dài: số ký hiệu 131/…, ngày, tiền, UUID, mã số thuế sau "MST", tổng đài 1900, dãy số nhỏ của bảng đều có test âm tính; trên kho mẫu (81 063 ký tự, 747 chuỗi số ứng viên) 0 chỗ bị che — make do-che-pii đo lại được. Luật lỏng "0 + 9–11 chữ số" thì che cả đuôi UUID và mã số thuế.
• "Mô hình chỉ thấy [SĐT-1] thì trả lời được gì?" Đúng câu "số điện thoại liên hệ là [SĐT-1]", có trích dẫn; số thật nằm ngay ở câu trích nguyên văn bên dưới, giao diện nói rõ. Không điền số thật trở lại vào câu của mô hình: mô hình có thể đặt nhãn sai chỗ, gán số người này cho người khác.
• "Còn gì chưa làm?" Họ tên, địa chỉ (cần nhận dạng thực thể tiếng Việt), hộ chiếu, biển số xe; số dính chữ (trừ di động sau ĐT, SĐT, Tel…), CMND và số tài khoản không có từ khóa đi kèm; nhật ký của Hasura, PostgreSQL, Keycloak và error_log của APISIX, nginx (định dạng cố định, vẫn có ?q= khi phía sau lỗi); véc-tơ nhúng tính trước F4.4 còn tới khi nhúng lại.

Ngoài 4 nguyên lý: cảnh báo vận hành ra chuông — make demo-canh-bao

Điều muốn chứng minh:

• Sự cố không chỉ hiện trong Grafana: luật cảnh báo của Prometheus đi qua Alertmanager tới svc-workflow, thành thông báo ở chuông của quản trị đơn vị — mọi đơn vị, vì thành phần dùng chung gián đoạn thì đơn vị nào cũng chịu — kèm email, webhook, SMS, Zalo nếu bản cài đã bật kênh đó (#284).
• Hết sự cố có thông báo "Hết cảnh báo"; Alertmanager gửi lại không làm chuông đổ thêm.
• Gọi thẳng svc-workflow không có token thì không ghi được thông báo; API của Alertmanager (không đăng nhập) chỉ Prometheus, svc-workflow tới được (mạng alerts riêng).

Lệnh in ra 5 bước:

1. Prometheus đang nối Alertmanager (/api/v1/alertmanagers); Alertmanager có token gọi svc-workflow (tệp trên tmpfs, không in ra).
2. Đẩy một cảnh báo giả (DemoCanhBao, thành phần demo-<mã>, không đụng dịch vụ thật) vào API của Alertmanager. Sau khoảng 30 giây (Alertmanager gom cảnh báo bật cùng lúc) chuông của quantri có "Cảnh báo vận hành: Thành phần demo-… gián đoạn"; trong CSDL đúng mỗi quản trị đơn vị một thông báo, văn thư, lãnh đạo, chuyên viên không nhận.
3. Đặt endsAt cho cảnh báo: trong vòng một phút mỗi quản trị thêm đúng một thông báo "Hết cảnh báo: …", thông báo bật không bị ghi thêm.
4. Gọi thẳng POST /ops/alerts của svc-workflow từ trong mạng nội bộ bằng token sai → 401.
5. Từ svc-files (mạng moc) gọi alertmanager:9093 không tới: không đẩy được cảnh báo giả, không tắt được cảnh báo thật. Cuối màn, thông báo giả được đánh dấu đã đọc; bản cài đã bật email, SMS, Zalo thì các kênh đó đã gửi thật.

Trên giao diện: đăng nhập quantri, chuông có thông báo màu cam (xem trước bước 5 khi chưa đánh dấu đã đọc, hoặc trong danh sách của chuông); bấm vào mở trang /trang-thai.

Nếu giám khảo hỏi:

• "Cảnh báo thật trông thế nào?" Như màn này, câu là summary của luật trong platform/monitoring/canh-bao.yml, vd "Thành phần tim-kiem gián đoạn — Signet vẫn chạy nhưng thiếu phần việc này". Tám luật và ngưỡng: docs/van-hanh.md mục Cảnh báo; mỗi luật có ca bật, ca không bật trong promtool test rules (bước CI "Giám sát").
• "Sao không cho Alertmanager gửi email thẳng?" Gửi qua svc-workflow thì dùng lại kênh, người nhận, chống trùng, hộp thư đi có thử lại của thông báo nghiệp vụ, không khai mật khẩu SMTP lần thứ hai trong cấu hình Alertmanager.
• "Chọn người nhận được không?" Chưa: mọi quản trị đơn vị đều nhận. Tắt tạm một cảnh báo (silence) phải gọi API của Alertmanager (amtool trong container), chưa có trên giao diện.
• "CSDL sập thì sao?" Cảnh báo về chính sự cố đó không ghi được vào chuông cho tới khi PostgreSQL, Hasura, svc-workflow chạy lại (svc-workflow trả 503, Alertmanager gửi lại); trong lúc đó chỉ Grafana, Prometheus thấy.

Ngoài 4 nguyên lý: ứng dụng sinh từ bảng — thêm trường trước hội đồng

Điều muốn chứng minh:

• Thêm một ứng dụng dạng bảng không phải viết máy chủ, migration hay quyền: người vận hành tạo bảng trong Supabase Studio, PostgREST sinh API, trang /sinh dựng biểu mẫu từ API đó.
• Thêm một trường lúc hệ thống đang chạy: ô nhập mới hiện ngay, không sửa dòng mã nào, không khởi động lại.
• Báo cáo và mẫu in cũng là dữ liệu: khai báo một báo cáo theo cột vừa thêm, in phiếu từ mẫu có sẵn, không viết mã.
• Bảng sinh ra vẫn theo luật của lõi: mỗi đơn vị chỉ thấy dòng của mình, mọi thay đổi vào sổ kiểm toán, lệnh gỡ bảo vệ bị hủy.

Chuẩn bị (trước buổi, xem checklist): profile studio đang chạy; bảng mẫu sinh.yeu_cau "Quản lý yêu cầu" có sẵn từ make seed; kiểu enum sinh.muc_uu_tien (thấp, vừa, cao) tạo sẵn trong Studio ở Database → Enumerated Types, để lúc diễn chỉ còn một thao tác thêm cột. Phải là enum: cột có CHECK thì /sinh chỉ hiện ô chữ, vì PostgREST không mô tả CHECK. Trên bản online, Studio chỉ nghe 127.0.0.1 của máy chủ nên máy trình chiếu mở đường hầm SSH từ trước (van-hanh.md mục "Ứng dụng sinh từ bảng"); trên máy dự phòng thì mở thẳng http://127.0.0.1:3400. make seed cũng tạo sẵn báo cáo "Yêu cầu theo trạng thái" và mẫu in "Phiếu yêu cầu" của bảng yeu_cau cho hai đơn vị mẫu.

Trên giao diện (khoảng 2 phút):

1. Tab /sinh/#/yeu_cau, đăng nhập sẵn bằng vanthu (đơn vị CNTT): menu có Quản lý yêu cầu; biểu mẫu có Tiêu đề, Nội dung, Hạn xử lý, Trạng thái; danh sách bên dưới.
2. Tab Studio, Table Editor, schema sinh, bảng yeu_cau: Insert column, tên muc_uu_tien, kiểu muc_uu_tien, mặc định vừa, Description "Mức ưu tiên" (ô này là COMMENT ON COLUMN, trang dùng làm nhãn). Bấm Save.
3. Quay lại tab /sinh, không tải lại: ô chọn Mức ưu tiên đã có, chữ đang gõ dở vẫn còn. Gõ tiêu đề "Máy in tầng 3 hỏng", chọn cao, bấm Thêm: dòng mới lên đầu danh sách, có "Mức ưu tiên: cao".
4. Menu Báo cáo, bấm Thêm: Tên "Yêu cầu theo mức ưu tiên", Bảng nguồn yeu_cau, Nhóm theo cột muc_uu_tien, Phép tính đếm, Kiểu hiện cột. Ở dòng vừa thêm, bấm Xem báo cáo: ba nhóm thấp, vừa, cao theo thứ tự của enum (nhóm không có dòng ghi 0), kèm bảng số; nhóm cao có yêu cầu vừa thêm. Cột thêm ở bước 2 đã là chiều báo cáo, không sửa mã.
5. Quay lại Quản lý yêu cầu, bấm In ở dòng "Máy in tầng 3 hỏng": trình duyệt tải về yeu_cau-<id>.pdf. Mở tệp: khổ A4, tên đơn vị CNTT, quốc hiệu, tiêu ngữ, ngày in, tiêu đề "Phiếu yêu cầu", các giá trị của dòng (hạn xử lý dạng dd/mm/yyyy).

Còn giờ, hoặc khi giám khảo hỏi:

6. Đăng nhập vanthukt (đơn vị Kinh tế): Quản lý yêu cầu không có dòng nào của đơn vị CNTT; Xem báo cáo "Yêu cầu theo trạng thái" chỉ đếm dòng của đơn vị Kinh tế.
7. Đăng nhập quantri (quản trị đơn vị CNTT) trong hồ sơ trình duyệt riêng (checklist T-5 phút), mở Sổ kiểm toán: dòng thêm yêu cầu (bảng sinh.yeu_cau) nằm trong chuỗi băm như dòng của Văn phòng điện tử. Dòng ddl của lệnh thêm cột không gắn đơn vị nào nên không hiện ở trang này.
8. Trong Studio, thử tắt RLS của bảng yeu_cau: lệnh bị hủy, lỗi bắt đầu bằng khung:.
9. Menu Mẫu in, sửa "Phiếu yêu cầu": thêm dòng Mức ưu tiên: {{muc_uu_tien}}, bấm Lưu, quay lại bấm In: phiếu có dòng mới.

Nếu giám khảo hỏi:

• "Hasura cũng sinh API, sao thêm PostgREST?" Hasura giữ cho Văn phòng điện tử (GraphQL); PostgREST cho bảng sinh vì nó thấy bảng, cột mới ngay và dựa hẳn vào RLS của khung (architecture.md QĐ-014; du-thi/hoi-dap-hoi-dong.md câu 19).
• "Vậy lõi là Supabase?" Không: dùng Studio, postgres-meta của Supabase và PostgREST; phần của đội là khung và trang /sinh (câu 20).
• "Ai được vào Studio?" Chỉ người vận hành nền tảng, qua đường hầm SSH: Studio là chủ bảng, thấy dữ liệu mọi đơn vị. Quản trị đơn vị không dùng Studio.
• "Có quy trình duyệt cho bảng này không?" Chưa: quy trình vẫn là BPMN viết tay, khai trong manifest (them-ung-dung.md mục 1.10). Signet không tự sinh toàn bộ backend.
• "Báo cáo, mẫu in có phải viết mã không?" Không, với bảng sinh: cả hai là dòng dữ liệu, nhập bằng biểu mẫu chung; khuôn văn bản đi của Văn phòng vẫn trong mã (du-thi/hoi-dap-hoi-dong.md câu 21).
• "Mẫu có chèn được mã độc không?" Mẫu là văn bản thuần, không phải HTML; giá trị thoát HTML; bộ dựng PDF chỉ tải data: (them-ung-dung.md mục 8.7).

Còn gì chưa làm? Bảng tạo trong Studio chưa nằm trong git; bảng sinh chưa có tệp đính kèm, thông báo, quy trình; báo cáo một cột nhóm, chưa xuất tệp; mẫu in chưa có bảng, ảnh; chưa có lệnh make demo-sinh.

Ngoài 4 nguyên lý: xem quy trình BPMN của một văn bản

Điều muốn chứng minh:

• Mỗi văn bản là một phiên quy trình trong Flowable, và người đọc được văn bản thì xem được chính phiên đó: trang văn bản có mục Sơ đồ quy trình vẽ sơ đồ BPMN thật (van-ban-den hoặc van-ban-di), mỗi bước Đã qua, Đang chờ hoặc Chưa tới.
• Sơ đồ là tệp BPMN mà Flowable đang chạy, không phải ảnh vẽ lại: bố cục lấy từ phần DI của tệp trong services/svc-workflow/processes/, trạng thái lấy từ lịch sử của phiên (historic-activity-instances). Đường đã đi cũng tô cùng màu với bước đã qua.
• Phần chạy ngầm cũng hiện: nhánh gợi ý giao việc chạy song song với bước chỉ đạo; timer quá hạn trên mép mỗi bước.
• Quyền theo văn bản: Action documentProcess đọc văn bản bằng phiên của người gọi; ai không đọc được văn bản (khác đơn vị, văn bản hạn chế không có tên) thì nhận 404 như khi đọc văn bản.
• Đọc được không cần nhìn: danh sách Các bước bằng chữ dưới sơ đồ; ba trạng thái khác nhau cả ở nét viền chứ không chỉ ở màu; trang có mục này vẫn qua quét axe (e2e tro-nang.spec.ts).

Chuẩn bị (trước buổi, xem checklist): bản sẽ trình bày đã có #604, #605 và hai bản sửa #607 (sơ đồ cuộn ngang trong cột), #608 (trạng thái timer). Muốn thấy timer quá hạn bắn trong buổi thì máy đó đặt MOC_SLA_DURATION ngắn (vd PT1M) trước khi tạo văn bản demo, vì thời hạn gắn vào quy trình lúc khởi chạy. Văn thư (vanthu) và lãnh đạo đơn vị (truongkhoa) đăng nhập sẵn trong hai hồ sơ trình duyệt.

Trên giao diện (khoảng 2 phút):

1. vanthu vào sổ một văn bản đến (hoặc mở văn bản vừa vào sổ ở màn gợi ý giao việc). Trên trang văn bản, bấm mở Sơ đồ quy trình ở cuối cột chính: "Đã vào sổ" đã qua; hai nhánh song song từ cổng +: "Gợi ý giao việc" (đã qua sau vài giây) và "Cho ý kiến chỉ đạo" đang chờ (nền vàng, viền đậm). Dưới sơ đồ: chú giải ba trạng thái và danh sách Các bước, mỗi bước ghi "Đã qua", "Đang chờ" hay "Chưa tới".
2. truongkhoa mở việc chỉ đạo ngay trên trang văn bản, mở sẵn Sơ đồ quy trình, giao phòng chủ trì (Tổ Đào tạo): sơ đồ tự tải lại, "Cho ý kiến chỉ đạo" và đường "Giao phòng chủ trì" đã qua, "Phân công xử lý" đang chờ; "Xử lý văn bản" và "Đã lưu" vẫn chưa tới (viền đứt), đường "Lưu, không xử lý" vẫn mảnh, màu xám. Đây đúng là điều e2e van-ban-den.spec.ts kiểm trên mỗi commit. Ở tab của người khác thì tải lại trang rồi mở mục.
3. Nếu đã đặt MOC_SLA_DURATION=PT1M: quá một phút, timer trên mép "Phân công xử lý" bắn. Tải lại trang, mở mục: danh sách bước có thêm "Quá hạn — Đã qua" (timer chưa bắn thì không có trong danh sách), đường từ timer tới "Nhắc hạn, báo lãnh đạo" đổi màu. Bước nhắc hạn "Đang chờ" tới khi svc-workflow lấy việc (mỗi MOC_SLA_POLL_INTERVAL_S giây, mặc định 5), rồi "Đã qua" và lãnh đạo phòng có thông báo nhắc hạn. "Phân công xử lý" vẫn đang chờ: timer không cắt ngang bước.

Còn giờ, hoặc khi giám khảo hỏi:

4. Một văn bản đi đã bị trả lại một lần (màn ký số dùng chuyenviendt → totruongdt → truongkhoa): sơ đồ van-ban-di có "Sửa dự thảo theo ý kiến" đã qua, và bước duyệt được trình lại đang chờ.
5. Đăng nhập vanthukt (đơn vị Kinh tế): không mở được văn bản của đơn vị CNTT, nên cũng không xem được sơ đồ của nó.
6. Bấm phím Tab tới khung sơ đồ: khung cuộn ngang được bằng phím mũi tên; rê chuột vào một bước thì thấy tên đầy đủ.

Nếu giám khảo hỏi:

• "Sao không dùng bpmn-js?" Giấy phép của bpmn.io không phải giấy phép OSI (architecture.md QĐ-009). Sơ đồ là SVG tự vẽ từ DI của tệp BPMN, không thêm phụ thuộc.
• "Sao không lấy ảnh PNG của Flowable?" Flowable REST không có giao diện, cổng chặn /flowable-rest/*; ảnh dựng trong container khó đúng phông tiếng Việt. Trang chỉ gọi GraphQL như mọi chức năng khác.
• "Văn bản cũ, trước khi có DI, có vẽ được không?" Có: bố cục đọc từ tệp hiện hành trong processes/, id bước giữ nguyên nên phiên chạy trên định nghĩa cũ vẫn tô đúng. Đổi id bước ở bản sau thì phải đọc DI theo định nghĩa của phiên.
• "Có sửa quy trình trên giao diện được không?" Chưa: đây là trang xem. Quy trình vẫn viết BPMN XML bằng tay (architecture.md QĐ-009).

Còn gì chưa làm? Chỉ hai quy trình lõi; quy trình của ứng dụng cắm thêm (nghỉ phép, lịch giảng) chưa có sơ đồ. Tên bước lấy từ BPMN nên vẫn là tiếng Việt khi giao diện tiếng Anh. Không có trình sửa quy trình.

Phương án dự phòng

Bản trình diễn chính là bản online https://signet.htechcs.com: từ 31/10/2026 là bản cài /opt/moc trên một máy Windows qua WSL2 (Ubuntu 24.04, không có systemd), ra Internet qua Cloudflare Tunnel (profile tunnel, trien-khai.md mục 5b). Reconciler chạy mỗi phút bằng cron của người dùng moc, theo thẻ phát hành: thẻ mới thì tự sao lưu, nâng cấp, lỗi thì tự lùi về bản trước (git_flow.md mục 7). Laptop chạy bản online tới 31/10 vẫn giữ bản cài /opt/moc, là máy lùi về của bản online. Hỏng thì lùi theo thứ tự bản online → máy dự phòng chạy tại chỗ → video quay sẵn, không gỡ lỗi trước hội đồng quá một phút. Trên bản cài, lệnh là python3 scripts/… và docker compose … trong /opt/moc (bản cài không có Makefile); trên máy dự phòng là make … trong thư mục mã nguồn. Kịch bản 5 phút ở dac-ta-san-pham.md §7 có cột dự phòng cho từng màn.

Màn nào chạy trên bản online khi đang có người dùng. Vài màn cố ý dừng hay khởi động lại dịch vụ, nên trong lúc chạy không tải được tệp hay cổng ngắt vài giây:

• ket-bi-mat: khởi động lại openbao, svc-files, svc-workflow;
• tu-phuc-hoi: xóa container svc-files, dừng centrifugo;
• giao-viec: bước 10 dừng svc-files;
• cai-ung-dung, quy-trinh: cài, gỡ ứng dụng làm APISIX khởi động lại khi tệp route đổi;
• tat-van-phong: dựng lại svc-files, svc-workflow hai lần.

nong-lanh và pha-he tiêu văn bản mẫu (xem đầu tệp). Những màn này chạy trên máy dự phòng, hoặc báo trước với hội đồng rằng đây là phá thật. Trên bản online đang có người dùng, chạy màn không dừng dịch vụ nào, như make demo-kiem-dich (bản cài: python3 scripts/demo.py kiem-dich).

Mất Internet hoặc Cloudflare (trang online không mở được, hoặc hiện trang lỗi của Cloudflare):

• Chỉ mạng phòng thi hỏng: cho máy trình chiếu dùng 4G của điện thoại (phát Wi-Fi), mở lại bản online. Máy chạy bản online vẫn sống thì cloudflared tự nối lại khi mạng bên đó về, không phải làm gì trên máy đó.
• Không chờ được: sang máy dự phòng.

Máy dự phòng (dựng từ hôm trước theo checklist): cùng bản phát hành, MOC_PUBLIC_URL=http://localhost:8080, đã make seed, đã tải mô hình.

• Khởi động không cần mạng: docker compose --profile core --profile app up -d --wait rồi make up-ai, kiểm bằng make smoke. Không dùng make up lúc này: lệnh đó luôn kèm --build.
• Giữ localhost, không đổi sang IP trong mạng LAN: trình duyệt chỉ cho dùng Web Crypto (đăng nhập PKCE, tính SHA-256 ở trang xác thực) trên https hoặc localhost.
• Mã QR trên văn bản phát hành ở máy này trỏ về localhost, điện thoại của giám khảo không mở được: thay bằng mở /xac-thuc trên máy trình chiếu, nhập mã tra cứu hoặc thả tệp PDF vào.

Máy chạy bản online tắt, treo hoặc khởi động lại:

• Windows khởi động lại xong, tài khoản Windows của máy phải đăng nhập: chưa ai đăng nhập thì Signet chưa lên. Tác vụ Task Scheduler lúc đăng nhập hiện chỉ bật SSH của Ubuntu; Docker và cron chưa tự bật. Mở Ubuntu-24.04 trên máy đó (hoặc SSH vào) rồi chạy sudo /usr/local/sbin/signet-khoi-dong.sh: script chạy service ssh start, service cron start, service docker start. Docker lên thì chạy lại mọi container (restart: unless-stopped), két tự mở khóa; cron lại chạy reconciler mỗi phút. Cách dựng máy không có systemd: trien-khai.md mục 7, đoạn "Máy không có systemd".
• Trong WSL, ở /opt/moc: docker compose ps tới khi không còn dịch vụ nào starting hay unhealthy (ClamAV nạp chữ ký khoảng một phút); thiếu container hay còn unhealthy thì python3 scripts/reconcile.py --heal-only.
• Vài phút chưa lên: máy dự phòng, hoặc video.
• Chỉ máy trình chiếu hỏng: bản online mở được từ bất kỳ máy nào có trình duyệt (máy của thành viên khác, máy của BTC); giamkhao không cần TOTP.

AI chậm hoặc không có:

• Câu trích nguyên văn hiện trước (dưới một giây, không cần mô hình), khối "Trả lời của trợ lý" tới sau: đo ngày 23/10/2026 trên laptop i5-12500H chạy bản online tới 31/10, mô hình viết mất p50 8,9 giây, p95 21,1 giây; máy Windows chạy bản online hiện nay chưa đo. Chờ lâu thì bấm "Dừng", trang giữ câu trích.
• Lần hỏi đầu sau một lúc không dùng chậm hơn vì phải nạp lại mô hình: Ollama chỉ giữ mô hình trong RAM 30 phút sau lần dùng cuối (OLLAMA_KEEP_ALIVE). Hỏi thử một câu trước màn AI.
• Mô hình làm cả máy chậm, hay Ollama lỗi: docker compose --profile ai stop ollama; svc-files dò lại trong 60 giây rồi về tìm theo từ khóa và trả câu trích. Mọi màn demo chạy được không cần mô hình: bước dùng mô hình của demo-doc-van-ban, demo-hoi-dap tự in "chưa bật mô hình…".

Đăng nhập TOTP không qua:

• Mã bị từ chối: thường do đồng hồ điện thoại lệch (mã đổi mỗi 30 giây). Bật giờ tự động trên điện thoại, hoặc lấy mã tính theo đồng hồ của chính máy chủ: make totp (bản cài: python3 scripts/totp.py) in mã hiện tại và số giây còn lại.
• Gõ sai nhiều lần: Keycloak tạm khóa tài khoản (chống dò mật khẩu, 10 lần sai); APISIX trả 429 khi một IP đăng nhập quá MOC_RATE_LOGIN_PER_MIN lần mỗi phút (mặc định 60). Mở khóa trong trang quản trị Keycloak (chỉ nghe trên máy chủ, http://127.0.0.1:8180/admin; từ xa qua đường hầm SSH như trien-khai.md mục 7), hoặc đợi rồi thử lại.
• Không chờ được: đi tiếp bằng giamkhao (chuyên viên, không cần TOTP) cho phần xử lý, trình văn bản; phần của văn thư, lãnh đạo cho chạy bằng make demo-* (script tự tính mã TOTP từ MOC_DEMO_TOTP_SECRET).

Một bước demo báo lỗi:

• Lệnh dừng ở bước sai, in tên bước, thoát 1. Chạy lại ngay được: mỗi màn chạy lại bao nhiêu lần cũng được, trừ nong-lanh (đầu tệp).
• Dịch vụ chết hay unhealthy: make ps (bản cài: docker compose ps), rồi một lượt tự phục hồi python3 scripts/reconcile.py --heal-only; xem lỗi bằng docker compose logs --tail 50 <dịch vụ>.
• Vẫn lỗi: bỏ màn đó, mở lượt CI xanh của đúng commit đang chạy — các job "Chạy thử: luong-chinh", "Chạy thử: ai", "Chạy thử: sao-luu" có từng bước make demo-* kèm nhật ký — rồi đi tiếp; còn giờ thì quay lại.
• Dữ liệu demo hỏng tới mức không dùng được: khôi phục lượt sao lưu lấy hôm trước, python3 scripts/moc.py backup restore <lượt> (hỏi lại trước khi thay dữ liệu; Signet dừng trong lúc khôi phục). Chỉ làm khi còn thời gian, không thì sang máy dự phòng.

Màn ứng dụng sinh từ bảng hỏng (Studio không mở, ô mới không hiện sau khi bấm F5, bấm Thêm, Xem báo cáo hay In báo lỗi): sang video của màn này quay lúc tập, nói rõ đó là bản quay. Không mở terminal sửa trước hội đồng. Sau buổi, trong Studio: xóa dòng "Yêu cầu theo mức ưu tiên" của bảng bao_cao (/sinh chưa xóa dòng), xóa cột muc_uu_tien, trả mẫu "Phiếu yêu cầu" về như cũ nếu đã sửa, để lần sau diễn lại được.

Video quay sẵn: lớp cuối, không phụ thuộc mạng hay máy chủ. Lưu trên máy trình chiếu và một USB, không đưa vào repo (git_flow.md).

Checklist trước giờ trình diễn

T-1 ngày

• Bản online chạy đúng bản phát hành sẽ trình bày (cat /opt/moc/VERSION); CI của commit đó xanh.
• Tạm dừng tự nâng cấp để không lượt nâng cấp nào chạy trong buổi demo: trong WSL, sudo crontab -u moc -e, thêm # trước dòng reconcile.py. Không đẩy thẻ phát hành mới trước buổi demo. Trong lúc dừng, tự phục hồi mỗi phút cũng dừng: dịch vụ chết thì gọi tay python3 scripts/reconcile.py --heal-only (màn tu-phuc-hoi tự gọi lượt này, không cần cron). Xong buổi trình diễn thì bỏ # để bật lại.
• Trên bản online, trong /opt/moc: python3 scripts/smoke.py, python3 scripts/moc.py audit verify; chạy một lượt mỗi màn sẽ trình diễn (python3 scripts/demo.py <màn>) cho dữ liệu có sẵn; đo lại trợ lý bằng python3 scripts/demo.py do-hoi-dap.
• Sao lưu sau khi chạy thử: python3 scripts/moc.py backup create, ghi lại tên lượt (backup list).
• Máy dự phòng, khi còn mạng: lấy đúng thẻ phát hành, make env (nếu chưa có .env), make up, make seed, make ai-model, make up-ai, make smoke, chạy thử các màn. Rồi tắt mạng, make down, khởi động lại bằng docker compose --profile core --profile app up -d --wait và make up-ai, chạy make smoke lần nữa: phải qua khi không có Internet.
• Quay video các màn chính trên bản online: đăng nhập, văn bản đến → vào sổ → chỉ đạo, phát hành rồi quét mã QR, hỏi đáp, kiểm dịch, tự phục hồi. Chép vào máy trình chiếu và USB.
• Điện thoại: ứng dụng xác thực đã thêm khóa của tài khoản mẫu (khóa do make totp in ra), giờ đặt tự động; một máy có 4G để phát Wi-Fi.
• Máy chạy bản online và máy trình chiếu: tắt chế độ ngủ, hoãn cập nhật hệ điều hành (máy Windows khởi động lại thì phải có người đăng nhập, xem phương án dự phòng); máy trình chiếu cắm sạc.
• Màn ứng dụng sinh từ bảng: bản sẽ trình bày (online và máy dự phòng) đã có #565, #569, #563, #564 và bật profile studio; cài trang nếu chưa có (python3 scripts/moc.py app install apps/sinh/app.yaml); /sinh/ mở được Quản lý yêu cầu; kiểu enum sinh.muc_uu_tien đã có; cột muc_uu_tien chưa có (lần tập trước đã thêm thì xóa cột trong Studio, giữ kiểu enum). Bản đó có cả #592, #591 (báo cáo), #596, #593 (mẫu in) và đã chạy make seed sau khi nâng cấp; bảng bao_cao chưa có "Yêu cầu theo mức ưu tiên", mẫu "Phiếu yêu cầu" như của make seed (lần tập trước đã thêm, sửa thì xóa, sửa lại trong Studio).
• Màn xem quy trình BPMN: bản sẽ trình bày đã có #604, #605, #607, #608. Muốn thấy timer quá hạn bắn trong buổi thì đặt MOC_SLA_DURATION=PT1M trong .env của máy đó, docker compose up -d svc-workflow, rồi mới tạo văn bản demo (giá trị chỉ áp cho quy trình khởi chạy sau khi đổi). Mỗi bước của văn bản tạo trong lúc này nhắc sau 1 phút, báo lãnh đạo sau 2 phút; xong buổi thì trả về giá trị cũ. Trên bản online, Nam chọn giờ đổi.

T-1 giờ

• Ở phòng thi, trên máy trình chiếu: mở https://signet.htechcs.com, đăng nhập giamkhao, đăng xuất, đăng nhập vanthu bằng mã trên điện thoại — qua được thì mạng và đồng hồ đều ổn.
• Trên bản online: docker compose --profile ai ps không có dịch vụ nào unhealthy hay exited, có cloudflared và ollama.
• Cả phòng thường ra Internet qua một IP: cổng xác thực nhận tối đa MOC_RATE_VERIFY_PER_MIN lượt mỗi phút mỗi IP (mặc định 30). Nhiều giám khảo cùng quét QR thì dùng 4G, hoặc nâng giới hạn trong /opt/moc/.env rồi docker compose up -d apisix (chỉ trên máy demo).
• Máy dự phòng đang chạy (make ps), đã đăng nhập sẵn; video mở sẵn, dừng ở khung đầu.
• Màn ứng dụng sinh từ bảng: mở đường hầm SSH tới Studio trên máy trình chiếu; tab Studio ở bảng sinh.yeu_cau, tab /sinh đăng nhập sẵn vanthu.

T-5 phút

• Hỏi trợ lý một câu trên bản online để mô hình nằm sẵn trong RAM.
• Mỗi tài khoản sẽ dùng (văn thư, lãnh đạo, giamkhao) mở trong một hồ sơ trình duyệt riêng hoặc một trình duyệt khác — các cửa sổ ẩn danh dùng chung phiên đăng nhập; mở sẵn trang cần dùng, thêm tab /xac-thuc và "Hỏi đáp".
• Terminal ở /opt/moc (máy dự phòng: thư mục mã nguồn), gõ sẵn lệnh của màn demo đầu tiên.
• Tắt thông báo của hệ điều hành, phóng to chữ trình duyệt.
• Nhắc nhau thứ tự lùi: bản online → máy dự phòng → video.