Đặc tả bộ tài liệu đích — 20 gói nâng cấp tổng thể

TƯ VẤN NỘI BỘ CHO GVHD — CHƯA PHÊ DUYỆT.
Ngày lập: 26/09/2026. Phạm vi: nghiên cứu và thiết kế tài liệu, không triển khai.
Đây không phải đề cương, báo cáo NCKH hoặc sản phẩm thay NCS tự thực hiện.

1. Ranh giới sử dụng và căn cứ

• PL8 nội bộ cấm AI viết bản đầu kế hoạch nghiên cứu, báo cáo, tóm tắt và poster.
• Kết luận, định hướng nghiên cứu và danh mục tham khảo khởi đầu phải do NCS xây dựng.
• Nhãn tư vấn nội bộ không tạo ngoại lệ. GVHD cần xác nhận cách dùng trước khi chuyển thành nhiệm vụ.
• Không sao chép tài liệu này thành đề cương hoặc báo cáo của NCS.
• D03, D16 và D17 chỉ mô tả yêu cầu quản lý hồ sơ, không cung cấp lập luận hoặc kết luận thay NCS.
• Các vai trò duyệt dưới đây là đề xuất. Không xác nhận người nào đã nhận việc hoặc đã phê duyệt.
• Không viết nội dung y khoa, thuốc hoặc tự chuyển thẻ sang APPROVED.
• 20 gói không đồng nghĩa 20 file mới. Ưu tiên giữ và sửa tài liệu hiện có.
• Chỉ tạo tài liệu khi có người phụ trách, nội dung thực và tiêu chí kiểm tra; không tạo file trống.
• Đường dẫn trong dấu mã đều tính từ gốc dự án. Đường dẫn đề xuất không chứng minh file đã tồn tại.
• Các liên kết điều hướng bên dưới trỏ tới bộ nghiên cứu đang được agent chính tích hợp.

Điều hướng cùng đợt nghiên cứu:

• Tổng quan.
• Phát hiện và rủi ro.
• Nguồn và giới hạn.
• Kế hoạch thực hiện.
• Cổng kiểm soát và truy vết.

1.1 Mức bằng chứng hiện trạng

Đã đọc README.md, docs/GLOSSARY.md, docs/INDEX.md và PL8; quy tắc AGENTS.md được cung cấp trong phiên.
Các mục “Hiện có” được đối chiếu danh sách file thực tế ngày 26/09/2026.
Việc file tồn tại không chứng minh nội dung đúng, được duyệt hoặc chức năng đã chạy.
Danh sách đường dẫn ở README và INDEX chỉ là chỉ dẫn, không được dùng thay kiểm kê.

Thông tin sau được kế thừa từ ba nhánh kiểm kê do agent chính cung cấp:

• Phần ứng dụng backend/frontend chưa có triển khai thực tế.
• Kho tri thức có 19 thẻ YAML DRAFT, cùng một file khung trùng ID.
• Có 48 FAQ DRAFT và 6 thẻ bằng chứng DRAFT.
• Hai bộ kiểm thử an toàn có 55 và 50 trường hợp, nhưng không cùng hệ nhãn.
• Công cụ kiểm tra trả PASS trong phạm vi hẹp; không chứng minh an toàn hoặc sẵn sàng thử nghiệm.

Các số trên không phải phép đo độc lập của nhánh soạn đặc tả; bằng chứng kiểm kê được dẫn ngay bên dưới.
Không tự chấm điểm chất lượng, không suy ra tỷ lệ hoàn thành từ số file.

Bằng chứng đã được tích hợp tại hiện trạng.
Những phụ thuộc D03–D05 là quan hệ phối hợp theo phiên bản, không yêu cầu hoàn tất lẫn nhau trước khi mở hồ sơ.
T01 mở hồ sơ và chốt phạm vi sơ bộ; G0 chỉ được xét sau đầu ra bắt buộc của T01–T06.

1.2 Quy ước quản lý chung

Mỗi tài liệu đích cần có phiên bản, trạng thái, chủ trì, người review, ngày kiểm tra và phạm vi sử dụng.
Mỗi yêu cầu cần nối tới nguồn, quyết định, bằng chứng kiểm tra và cổng kiểm soát liên quan.
Thay đổi nội dung đã duyệt phải mở lại review; không ghi đè lịch sử phê duyệt.
Lưu trữ bản cũ chỉ sau khi có bản thay thế và kiểm tra liên kết; không xóa nguồn gốc.
Gộp tài liệu không đồng nghĩa gộp quyền truy cập hoặc công khai dữ liệu.

Ưu tiên đề xuất: P0 giải quyết trước khi làm tiếp; P1 trước thử nghiệm; P2 trước bàn giao hoặc công bố.
Đây là thứ tự phụ thuộc, không phải điểm số hay cam kết thời hạn.

Cổng kiểm soát đề xuất: G0 chốt phạm vi và tính hợp lệ; GA chốt tri thức và thiết kế an toàn.
GB kiểm tra kỹ thuật; GC cho phép thử nghiệm giới hạn; GD bàn giao hồ sơ và công bố.
GCA xét điều kiện camera; GCB xét bằng chứng camera trước tích hợp hoặc sử dụng.
Định nghĩa và thẩm quyền cuối cùng phải thống nhất với file cổng kiểm soát cùng đợt.
Không dùng mã cổng như bằng chứng đã đạt; cổng camera không thay thế các cổng của hệ thống chung.

2. Tổng danh mục 20 gói

3. Đặc tả chi tiết

D01 — Điều lệ, phạm vi và mục đích sử dụng

• Hiện có: docs/project/project_charter.md, docs/project/intended_use.md, README.md, docs/research/requirements/YEU_CAU_GOC.md.
• Xử lý: giữ điều lệ và mục đích sử dụng; sửa điểm mâu thuẫn; README chỉ tóm tắt và dẫn nguồn chuẩn.
• Đích: hai file trong docs/project/ tiếp tục làm bản chuẩn. Không tạo điều lệ thứ hai.
• Vai trò đề xuất: đọc: cả nhóm; soạn: NCS1 cùng NCS2; review: CVYK và GVHD; duyệt phạm vi: GVHD.
• Đầu vào/phụ thuộc: yêu cầu gốc, PL8; D02 cung cấp quản lý phiên bản, không chặn bản nháp đầu.
• Ưu tiên/cổng: P0; G0, mở lại khi thay đổi đối tượng hoặc tính năng.
• Nội dung 1: Ai sử dụng, trong hoàn cảnh nào, và ai không thuộc phạm vi? Nêu giới hạn của bản thử nghiệm.
• Nội dung 2: Chức năng nào làm trước, hoãn hoặc loại bỏ? Tách phần cốt lõi, giọng nói, Telegram và camera.
• Nội dung 3: Điều kiện nào khiến hệ thống dừng trả lời hoặc chuyển sang hướng dẫn an toàn đã duyệt?
• Nội dung 4: Ai quyết định phạm vi, chấp nhận rủi ro và cho phép thử nghiệm? Không giao quyền duyệt cho AI.
• Bảng/sơ đồ: bảng trong/ngoài phạm vi; ma trận vai trò; sơ đồ người dùng–hệ thống–bên ngoài.
• DoD: mỗi chức năng có giới hạn, người chịu trách nhiệm và liên kết yêu cầu; không tuyên bố ứng dụng đã hoạt động.
• Cách verify: đối chiếu từng mục với yêu cầu gốc, D07, D09 và D14; ghi quyết định cho mọi khác biệt.
• Kích hoạt cập nhật: thay người dùng, kênh giao tiếp, dữ liệu thu thập, cách dùng hoặc quy định cuộc thi.

D02 — Danh mục tài liệu chuẩn, phiên bản và quyết định thay đổi

• Hiện có: docs/INDEX.md, README.md, docs/research/plans/KIEN_TRUC_DU_AN.md, docs/research/plans/ROADMAP.md.
• Xử lý: giữ chỉ mục; sửa liên kết và trạng thái; gộp mô tả trùng bằng dẫn chiếu, không sao chép toàn văn.
• Đích đề xuất: bổ sung danh mục tại docs/INDEX.md; sổ quyết định docs/project/SO_QUYET_DINH_THAY_DOI.md khi có quyết định thực.
• Vai trò đề xuất: đọc: cả nhóm; soạn: NCS1; review: NCS2 và chủ từng gói; duyệt quy ước: GVHD.
• Đầu vào/phụ thuộc: D01; danh sách file và kết quả kiểm tra liên kết; nhận thay đổi từ D03–D20.
• Ưu tiên/cổng: P0; G0 và duy trì tại mỗi cổng.
• Nội dung 1: Tài liệu nào là bản chuẩn cho từng chủ đề? Khi hai bản trái nhau, ai xử lý?
• Nội dung 2: Phân biệt hiện có, đề xuất, đã thay thế, lưu trữ và không được công bố như thế nào?
• Nội dung 3: Mỗi quyết định ghi phương án, lý do, bằng chứng, người quyết và các file bị tác động.
• Nội dung 4: Khi đổi đường dẫn, giữ truy vết phiên bản và liên kết cũ bằng cách nào?
• Bảng/sơ đồ: bảng ID gói–file–phiên bản–trạng thái–chủ trì; sơ đồ yêu cầu đổi → review → phát hành.
• DoD: không còn hai bản cùng được gọi là chuẩn; mọi bản lưu trữ có lý do và bản thay thế.
• Cách verify: so danh mục với cây file thực; kiểm tra liên kết; lấy mẫu quyết định và lần theo file chịu tác động.
• Kích hoạt cập nhật: tạo, đổi tên, di chuyển, gộp, lưu trữ hoặc thay đổi hiệu lực tài liệu.

D03 — Hồ sơ đề cương do NCS tự viết

• Hiện có: docs/research/reports/DE_CUONG_NGHIEN_CUU.md, docs/presentations/kickoff/02_KE_HOACH_NGHIEN_CUU.md, PL8 trong docs/research/requirements/.
• Xử lý: giữ nguyên để kiểm tra nguồn gốc; không coi bản hiện có là bản NCS tự viết nếu chưa có bằng chứng.
• Đích: NCS và GVHD quyết định file chuẩn sau kiểm tra. Không tạo bản đề cương thay thế trong đợt tư vấn này.
• Vai trò đề xuất: đọc: NCS và GVHD; soạn bản đầu: NCS; review phương pháp: GVHD; duyệt tính hợp lệ: GVHD theo quy định áp dụng.
• Đầu vào/phụ thuộc: D01, D04, D05; yêu cầu chính thức do NCS/GVHD xác minh.
• Ưu tiên/cổng: P0; G0 trước khi dùng đề cương làm căn cứ nghiên cứu.
• Nội dung quản lý 1: Có bản đầu do NCS tự viết, ngày lập và lịch sử thay đổi hay chưa?
• Nội dung quản lý 2: NCS đã tự xác định vấn đề, câu hỏi và phương pháp bằng quá trình nào?
• Nội dung quản lý 3: Phần nào đã có AI hỗ trợ? Việc hỗ trợ có vượt ranh giới PL8 không?
• Nội dung quản lý 4: Những nội dung chưa hợp lệ phải xử lý và lưu bằng chứng thế nào, thay vì đổi nhãn cho hợp lệ?
• Bảng/sơ đồ: bảng nguồn gốc từng phiên bản; bảng nhận xét của GVHD và phản hồi của NCS.
• DoD: có bằng chứng NCS tự thực hiện bản đầu; mọi chỉnh sửa AI được giới hạn và ghi nhận theo PL8.
• Cách verify: GVHD đối chiếu bản gốc, lịch sử và nhật ký; yêu cầu NCS giải thích lựa chọn bằng lời của mình.
• Kích hoạt cập nhật: NCS đổi câu hỏi, phương pháp, phạm vi; phát hiện nguồn gốc không rõ hoặc quy định mới.

D04 — Hồ sơ sử dụng AI và nhật ký PL3

• Hiện có: docs/diary/_template.md, docs/diary/README.md, docs/research/requirements/PHU_LUC_3_HUONG_DAN_GHI_NHAT_KY.md, PL8.
• Xử lý: giữ nhật ký lịch sử; sửa hướng dẫn ghi; không ghi bù sự kiện hoặc thời điểm không có bằng chứng.
• Đích đề xuất: bổ sung hướng dẫn tại docs/diary/README.md; hồ sơ tổng hợp docs/project/HO_SO_SU_DUNG_AI.md khi có dữ liệu.
• Vai trò đề xuất: đọc: NCS/GVHD; ghi: người thực hiện; review: NCS đối chiếu và GVHD kiểm tra; duyệt hồ sơ nộp: GVHD.
• Đầu vào/phụ thuộc: D01, D02, D03; nhận dấu vết AI từ mọi gói.
• Ưu tiên/cổng: P0; G0–GD, ghi theo sự kiện chứ không đợi cuối dự án.
• Nội dung 1: Công cụ, thời điểm, yêu cầu, phản hồi liên quan và cách NCS kiểm tra được lưu ở đâu?
• Nội dung 2: Tách việc đã làm khỏi kế hoạch; phân biệt AI đề xuất với NCS tự quyết định.
• Nội dung 3: Bản viết tay PL3 được NCS đối chiếu thế nào? Không tự xác nhận đã chép hoặc đã ký.
• Nội dung 4: Loại bỏ bí mật và dữ liệu người tham gia khỏi bản chia sẻ bằng quy trình nào?
• Bảng/sơ đồ: bảng sự kiện–file–phần AI hỗ trợ–kiểm tra của NCS; quy trình ghi và đối chiếu sáu mục PL3.
• DoD: mỗi phần AI được sử dụng có dấu vết và kiểm tra; thiếu bằng chứng được ghi rõ, không suy diễn.
• Cách verify: lấy mẫu sản phẩm đối chiếu nhật ký và phiên bản; kiểm tra quyền truy cập hồ sơ gốc.
• Kích hoạt cập nhật: mỗi phiên làm việc, lần dùng AI, sửa sản phẩm hoặc phát hiện sai lệch nhật ký.

D05 — Nguồn và quyền sử dụng theo thao tác

• Hiện có: docs/research/references/NGUON_THAM_KHAO.md, knowledge-base/evidence-matrix/W1_D03_GuidelineConflictMatrix.md, knowledge-base/README.md.
• Sổ hiện hành: docs/legal/W1_D02_RightsRegister.csv và knowledge-base/evidence-matrix/source_registry.csv phải được đối soát trước.
• Xử lý: giữ nguồn gốc; sửa danh mục theo kiểm chứng của NCS; không sinh danh mục tham khảo khởi đầu thay NCS.
• Đích đề xuất: bổ sung ma trận trong danh mục hiện có; tách docs/legal/QUYEN_SU_DUNG_NGUON.md nếu cần quản lý quyền riêng.
• Nguồn chuẩn: D02 chọn nơi quản lý từng trường. Tài liệu mới chỉ hướng dẫn, không tạo trạng thái quyền song song.
• Vai trò đề xuất: đọc: NCS/CVYK/GVHD; soạn: NCS; review: CVYK về nguồn, người được giao về quyền; duyệt sử dụng: GVHD sau xác minh.
• Đầu vào/phụ thuộc: D01, D02, D04; tài liệu gốc và bằng chứng cho phép sử dụng.
• Ưu tiên/cổng: P0; GA cho nạp tri thức, GD cho công bố.
• Nội dung 1: NCS đã trực tiếp đọc phần nào, phiên bản nào? Định vị trang hoặc mục và ngày truy cập ra sao?
• Nội dung 2: Quyền đọc, tải, OCR, trích đoạn, nạp mô hình, lưu đệm và công bố có khác nhau không?
• Nội dung 3: Bằng chứng quyền áp dụng cho tài liệu và thao tác cụ thể nào? Chưa rõ quyền thì chặn thao tác đó.
• Nội dung 4: Nguồn bị rút, thay phiên bản hoặc mâu thuẫn sẽ tác động đến thẻ và câu trả lời nào?
• Bảng/sơ đồ: nguồn–phiên bản–vị trí–thao tác–quyền–bằng chứng; sơ đồ nguồn → thẻ → ngữ cảnh → xuất bản.
• DoD: mọi nguồn dùng có truy vết; mỗi thao tác có trạng thái quyền rõ; không coi truy cập công khai là quyền tái sử dụng.
• Cách verify: NCS mở nguồn gốc và chứng cứ quyền; đối chiếu mẫu trích dẫn với vị trí nguồn.
• Kích hoạt cập nhật: đổi nguồn, giấy phép, nhà cung cấp mô hình, cách lưu hoặc phạm vi công bố.

D06 — Schema, thẻ tri thức, thẻ bằng chứng, FAQ và tình huống

• Hiện có: knowledge-base/schemas/knowledge_item_schema.yaml, knowledge-base/knowledge-cards/_schema.json, knowledge-base/faq/_schema.json.
• Hiện có bổ sung: knowledge-base/_templates/, file tổng hợp KC/FAQ v0.1 và knowledge-base/knowledge-cards/knee-oa/KC-OA-001.md.
• Xử lý: đối chiếu schema trước khi chọn chuẩn; giữ nguồn gốc; xử lý ID trùng bằng quyết định, không xóa tùy tiện.
• Đích đề xuất: đặc tả chung knowledge-base/schemas/QUY_UOC_DU_LIEU_VA_DUYET.md; tái sử dụng các schema và mẫu phù hợp.
• Vai trò đề xuất: đọc: NCS/CVYK; soạn: NCS1; review kỹ thuật: NCS2; review/duyệt y khoa: CVYK; GVHD theo dõi quy trình.
• Đầu vào/phụ thuộc: D01, D02, D05; phối hợp D07 và D10 khi xác định trường an toàn và nhãn.
• Ưu tiên/cổng: P0; GA, kiểm tra lại trước mọi lần nạp tri thức.
• Nội dung 1: KC, EC, FAQ và tình huống cần trường nào, kiểu dữ liệu nào, ID nào và liên kết nào?
• Nội dung 2: Phân biệt bản khung, bản DRAFT và bản được duyệt bằng dữ liệu máy đọc như thế nào?
• Nội dung 3: Ai được chuyển trạng thái? Ghi người review, thời điểm, phiên bản nguồn và lý do chặn ra sao?
• Nội dung 4: Thẻ đổi nguồn hoặc nội dung có mất hiệu lực duyệt không? Phải có cơ chế thu hồi bản đang sử dụng.
• Bảng/sơ đồ: từ điển trường; sơ đồ liên kết bốn loại dữ liệu; vòng DRAFT → NCS review → CVYK review → APPROVED.
• DoD: ID duy nhất, liên kết hợp lệ, trạng thái có bằng chứng; cập nhật tools/validate_schema.py cùng thay đổi schema.
• Cách verify: kiểm thử dữ liệu hợp lệ và cố tình sai; kiểm tra chéo cả file tổng hợp lẫn file lẻ; chặn DRAFT khỏi ngữ cảnh thật.
• Kích hoạt cập nhật: thêm loại thẻ, trường dữ liệu, nguồn, trạng thái; phát hiện ID trùng hoặc lỗi bỏ lọt.

D07 — Quy tắc an toàn

• Hiện có: safety/README.md, safety/W1_D05_SafetyPolicy_v0.1.md, safety/risk_register.md.
• Xử lý: giữ chính sách; sửa ranh giới và điều kiện dừng; chỉ tách quy tắc máy đọc sau khi nội dung được review.
• Đích đề xuất: chính sách hiện có là điểm vào; đặc tả thực thi safety/DAC_TA_BO_LOC_AN_TOAN.md khi đủ nội dung.
• Vai trò đề xuất: đọc: NCS/CVYK/GVHD; soạn quy trình: NCS1; review/duyệt y khoa: CVYK; duyệt cổng: GVHD.
• Đầu vào/phụ thuộc: D01, D05, D06, D09; nhãn và bằng chứng kiểm tra từ D10.
• Ưu tiên/cổng: P0; GA thiết kế, GB thực thi, GC trước tiếp xúc người dùng.
• Nội dung 1: Kiểm tra trước và sau câu trả lời áp dụng tại đâu? Lỗi thành phần có buộc dừng không?
• Nội dung 2: Thiếu nguồn, mâu thuẫn, câu hỏi ngoài phạm vi hoặc yêu cầu bị cấm được xử lý theo nhóm nào?
• Nội dung 3: Hệ thống phát hiện cờ đỏ phải chuyển sang hướng dẫn đi khám đã duyệt bằng cách nào?
• Nội dung 4: Ai tiếp nhận sự cố, vô hiệu hóa quy tắc sai và cho phép mở lại? Không viết quy tắc y khoa tại đây.
• Bảng/sơ đồ: nhóm tình huống–hành vi–nguồn duyệt–test; sơ đồ các nhánh dừng và chuyển xử lý.
• DoD: mỗi quy tắc có người duyệt và test; lời khuyên an toàn không được dùng thay kiểm soát kỹ thuật.
• Cách verify: nối quy tắc tới D10; thử lỗi nguồn, lỗi mô hình và vượt phạm vi trong môi trường không có người dùng thật.
• Kích hoạt cập nhật: sự cố, nhãn mới, thay mô hình, thay chính sách hoặc phát hiện quy tắc không được thực thi.

D08 — Kiến trúc, API, ngữ cảnh và trích dẫn

• Hiện có: docs/research/plans/KIEN_TRUC_DU_AN.md, docs/research/reports/DEEP_RESEARCH_OBSIDIAN_VS_RAG.md, backend/README.md, data-pipeline/README.md.
• Xử lý: sửa kiến trúc; đưa lựa chọn chưa kiểm chứng về trạng thái đề xuất; không gọi thư mục trống là hệ thống đang chạy.
• Đích đề xuất: kiến trúc hiện có làm bản chuẩn; đặc tả backend/DAC_TA_API_VA_NGU_CANH.md cho phần giao tiếp.
• Vai trò đề xuất: đọc: NCS và người review kỹ thuật; soạn: NCS1; review: NCS2/CVYK theo phạm vi; duyệt thiết kế: GVHD.
• Đầu vào/phụ thuộc: D01, D05, D06, D07, D09, D20.
• Ưu tiên/cổng: P1; GA chốt ranh giới, GB kiểm tra thực thi.
• Nội dung 1: API nhận và trả trường nào, trạng thái lỗi nào? Quyền truy cập và giới hạn yêu cầu được đặt ở đâu?
• Nội dung 2: Chọn thẻ nào vào ngữ cảnh, theo phiên bản nào? Loại DRAFT, nguồn hết quyền và nội dung bị thu hồi thế nào?
• Nội dung 3: Giới hạn ngữ cảnh, chi phí, thời gian chờ và bộ nhớ hội thoại được quản lý ra sao?
• Nội dung 4: Trích dẫn có định vị nguồn thật không? Dữ liệu đầu vào không được biến thành chỉ thị hệ thống như thế nào?
• Bảng/sơ đồ: sơ đồ thành phần; trình tự yêu cầu; bảng giao tiếp API; bản kê ngữ cảnh và quy tắc kiểm tra trích dẫn.
• DoD: mỗi luồng thành công/lỗi có đầu vào, đầu ra và test dự kiến; quyết định kiến trúc có lý do và giới hạn.
• Cách verify: review giao tiếp với D11/D14; kiểm tra mẫu tổng hợp không chứa thông tin người dùng; nối test D10.
• Kích hoạt cập nhật: đổi mô hình, cách nạp nguồn, dung lượng, kênh giao tiếp hoặc định dạng trích dẫn.

D09 — Dữ liệu, quyền riêng tư, bảo mật và nhà cung cấp

• Hiện có: docs/legal/W1_D04_DataMinimizationMap.md, docs/legal/W1_D04_ConsentForm_DRAFT.md, deployment/database/init_schema.sql.
• Xử lý: sửa bản đồ dữ liệu và đồng ý; không coi đồng ý tham gia là căn cứ đủ cho mọi thao tác.
• Đích đề xuất: tái sử dụng hai file pháp lý; bổ sung docs/legal/HO_SO_DU_LIEU_VA_NHA_CUNG_CAP.md nếu cần.
• Vai trò đề xuất: đọc: NCS/GVHD và người vận hành; soạn: NCS1; review: người có chuyên môn được chỉ định; duyệt: người có thẩm quyền được xác định.
• Đầu vào/phụ thuộc: D01, D05; phối hợp D08, D12, D14, D15 để chốt mọi luồng dữ liệu.
• Ưu tiên/cổng: P0; G0 xác định trách nhiệm, GB kiểm soát, GC trước thu thập dữ liệu thật.
• Nội dung 1: Thu trường nào, nhằm mục đích gì, lưu bao lâu, ở đâu, ai truy cập và xóa bằng cách nào?
• Nội dung 2: Dữ liệu nào rời thiết bị hoặc đi tới nhà cung cấp? Có dùng huấn luyện, lưu log hoặc chuyển tiếp không?
• Nội dung 3: Quản lý khóa truy cập, mã hóa, phân quyền, sao lưu và thông báo sự cố như thế nào?
• Nội dung 4: Quy định nào áp dụng tại ngày thử nghiệm? Ai xác minh văn bản, hiệu lực và trách nhiệm thực tế?
• Bảng/sơ đồ: sơ đồ luồng dữ liệu; bảng dữ liệu–mục đích–thời hạn–người giữ; bảng điều khoản nhà cung cấp–bằng chứng–điểm chưa rõ.
• DoD: không còn luồng không có chủ trách nhiệm; điều khoản chưa rõ được ghi là chặn, không mặc nhiên chấp thuận.
• Cách verify: đối chiếu bản đồ với API, SQL, log và cấu hình; kiểm tra xóa/phân quyền bằng dữ liệu giả khi triển khai.
• Kích hoạt cập nhật: đổi nhà cung cấp, nơi lưu, mục đích, trường dữ liệu, điều khoản hoặc yêu cầu của người tham gia.

D10 — Bộ kiểm thử, nhãn chuẩn, tiêu chí chấm và chỉ số

• Hiện có: safety/W1_D05_SafetyTests_v0.1.yaml, testing/safety/W1_D05_SafetyTests_v0.1.yaml, testing/README.md, docs/guides/TEST_REPORT_TEMPLATE.md.
• Xử lý: giữ cả hai bộ để đối chiếu; không cộng 55 và 50 thành số ca độc lập hoặc đổi nhãn tự động.
• Đích đề xuất: quy ước testing/QUY_UOC_NHAN_VA_DANH_GIA.md; chọn vị trí bộ chuẩn sau quyết định D02.
• Vai trò đề xuất: đọc: NCS/CVYK/GVHD; soạn khung: NCS1; gán/duyệt nhãn y khoa: CVYK; review phương pháp: GVHD.
• Đầu vào/phụ thuộc: D01, D06, D07; giao tiếp D08 và môi trường D20.
• Ưu tiên/cổng: P0; T04 chốt hệ nhãn và tiêu chí an toàn trước GA. T08 khóa bộ đánh giá độc lập trước GB/T17.
• Nội dung 1: Nhãn nào tương đương, không tương đương hoặc cần phân xử? Ai giải quyết bất đồng và giữ lịch sử?
• Nội dung 2: Mỗi ca có đầu vào, kỳ vọng, nguồn, mức rủi ro, nhóm chức năng và phiên bản nào?
• Nội dung 3: Đo bỏ sót, báo sai, trích dẫn, từ chối, thời gian đáp ứng bằng mẫu số nào? Ca thiếu kết quả tính ra sao?
• Nội dung 4: Tách bộ phát triển và đánh giá thế nào? Ai chốt ngưỡng trước khi xem kết quả, tránh chọn số thuận lợi?
• Bảng/sơ đồ: ma trận ánh xạ nhãn; bảng tiêu chí chấm; công thức và mẫu số; bảng yêu cầu–ca–kết quả–lỗi.
• DoD: không còn ánh xạ ngầm; ngưỡng có người duyệt; báo rõ phạm vi công cụ kiểm tra và phần chưa được kiểm tra.
• Cách verify: kiểm tra ID trùng, tính nhãn từ mẫu độc lập; lưu bản kê phiên bản; thử ca hỏng để chứng minh phát hiện lỗi.
• Kích hoạt cập nhật: đổi nhãn, quy tắc, nguồn, mô hình, giao tiếp hoặc phát hiện ca bị rò sang bộ phát triển.

D11 — Giao diện, giọng nói và trợ năng

• Hiện có: frontend/README.md, frontend/package.json, voice/README.md, docs/research/plans/W1/W1_D06_VoiceUX_Notes.md.
• Xử lý: giữ ghi chú; sửa thành yêu cầu kiểm tra được; không coi cấu hình dự án là giao diện hoàn chỉnh.
• Đích đề xuất: frontend/DAC_TA_GIAO_DIEN_VA_TRO_NANG.md; giọng nói dẫn chiếu từ voice/README.md.
• Vai trò đề xuất: đọc: NCS và người thử nghiệm; soạn: NCS1; review: NCS2/CVYK theo nội dung; duyệt thử nghiệm: GVHD.
• Đầu vào/phụ thuộc: D01, D07, D08, D09, D10; nhu cầu đã kiểm chứng từ D15.
• Ưu tiên/cổng: P1; GB kiểm tra giao diện, GC kiểm tra cùng đối tượng sử dụng được phép.
• Nội dung 1: Người dùng bắt đầu, đọc nguồn, sửa câu hỏi, dừng và nhận hỗ trợ bằng bao nhiêu thao tác?
• Nội dung 2: Chữ, tương phản, bàn phím, phóng to và đọc màn hình được kiểm tra theo tiêu chí nào?
• Nội dung 3: STT sai được xác nhận và sửa thế nào? TTS có bỏ sót lời khuyên an toàn hoặc trích dẫn không?
• Nội dung 4: Quyền micro bị từ chối, mất mạng hoặc quá thời gian chờ phải hiện gì? Luôn có cách nhập chữ thay thế.
• Bảng/sơ đồ: sơ đồ màn hình; bảng trạng thái thành công/lỗi; tiêu chí trợ năng–cách thử–bằng chứng.
• DoD: mỗi yêu cầu có cách kiểm tra; thông tin an toàn không phụ thuộc riêng màu sắc hoặc âm thanh.
• Cách verify: kiểm tra thủ công và tự động; ghi thiết bị/trình duyệt; phân biệt lỗi thao tác với lỗi STT.
• Kích hoạt cập nhật: đổi màn hình, nhà cung cấp giọng nói, trình duyệt hỗ trợ hoặc phản hồi người dùng.

D12 — SQL, IIS, sao lưu và vận hành

• Hiện có: deployment/database/init_schema.sql, deployment/iis/W1_D06_IIS_Config_Guide.md, backend/README.md.
• Xử lý: giữ hướng dẫn; rà cấu hình theo môi trường thực; bổ sung phục hồi, không chạy triển khai trong đợt nghiên cứu.
• Đích đề xuất: deployment/HUONG_DAN_VAN_HANH_VA_PHUC_HOI.md; giữ SQL và hướng dẫn IIS làm tài liệu chuyên biệt.
• Vai trò đề xuất: đọc: NCS/người vận hành; soạn: NCS1 cùng người vận hành được giao; review kỹ thuật: người độc lập; duyệt phát hành: GVHD.
• Đầu vào/phụ thuộc: D08, D09, D10, D20; quyền truy cập hạ tầng phải được xác nhận.
• Ưu tiên/cổng: P1; GB môi trường thử, GC sẵn sàng phục hồi, GD bàn giao.
• Nội dung 1: Môi trường phát triển, thử và sử dụng thật được tách thế nào? Ai giữ quyền quản trị?
• Nội dung 2: Thay schema SQL, quay lại phiên bản cũ và kiểm tra mất dữ liệu bằng quy trình nào?
• Nội dung 3: Sao lưu gì, mã hóa thế nào, lưu ở đâu? Thời gian phục hồi và mức mất dữ liệu chấp nhận do ai quyết?
• Nội dung 4: Theo dõi lỗi, chi phí, tài nguyên, chứng chỉ và dịch vụ phụ thuộc ra sao? Ai nhận cảnh báo và dừng dịch vụ?
• Bảng/sơ đồ: sơ đồ triển khai; bảng quyền; trình tự phát hành/quay lại; bảng sao lưu–phục hồi–bằng chứng thử.
• DoD: có quy trình phục hồi kiểm chứng, chủ vận hành và thông tin bàn giao không chứa bí mật.
• Cách verify: thử phục hồi ở môi trường riêng khi được phép; ghi phiên bản, thời gian và kiểm tra dữ liệu sau phục hồi.
• Kích hoạt cập nhật: đổi máy chủ, SQL, IIS, quyền, chính sách lưu hoặc sau sự cố.

D13 — Sổ rủi ro và cổng kiểm soát

• Hiện có: safety/risk_register.md, docs/project/LICH_GVHD.md, docs/project/kpi_dashboard.yaml, docs/research/plans/ROADMAP.md.
• Xử lý: sửa sổ rủi ro; giữ lịch họp nhưng tách khỏi bằng chứng đạt cổng; không dùng tiến độ thay an toàn.
• Đích: sổ hiện có và docs/research/plans/20260926_NANG_CAP_TONG_THE/03_CONG_KIEM_SOAT_VA_TRUY_VET.md do agent chính tích hợp.
• Vai trò đề xuất: đọc: cả nhóm; soạn: NCS1, NCS2 phụ trách camera; review: CVYK/người kỹ thuật; quyết định cổng: GVHD theo thẩm quyền.
• Đầu vào/phụ thuộc: D01, D02; tổng hợp bằng chứng từ tất cả gói, không chờ hoàn tất mọi gói để mở sổ.
• Ưu tiên/cổng: P0; G0, GA, GB, GC, GD, GCA, GCB.
• Nội dung 1: Mỗi rủi ro có nguyên nhân, tác hại, kiểm soát, chủ trách nhiệm và bằng chứng hiệu lực nào?
• Nội dung 2: Tiêu chí nào bắt buộc dừng? Ai có quyền mở lại và cần bằng chứng gì?
• Nội dung 3: Cổng đạt, chưa đạt, hoãn hoặc đạt có điều kiện được ghi thế nào? Điều kiện không được che lỗi chặn an toàn.
• Nội dung 4: Khi bản phát hành thay đổi, bằng chứng nào hết hiệu lực? Tách ký chuyên môn khỏi quyết định quản lý.
• Bảng/sơ đồ: rủi ro–kiểm soát–test–cổng; bảng quyết định; sơ đồ mở lại cổng khi phát hiện sự cố.
• DoD: mỗi tiêu chí có người chịu trách nhiệm và bằng chứng; không có trạng thái đạt chỉ từ văn bản AI.
• Cách verify: thử truy ngược một quyết định tới phiên bản và kết quả gốc; đánh dấu thiếu chứng cứ là chưa xác minh.
• Kích hoạt cập nhật: sự cố, thay phạm vi, kết quả kiểm thử mới, thay nhân sự hoặc bằng chứng hết hiệu lực.

D14 — Camera quan sát cử động, quản lý riêng

Bổ sung tích hợp 26/09: D14 phụ thuộc D05/D06 về nguồn, thẻ và quy trình được duyệt theo phiên bản.
Ma trận y khoa camera nối CYK-01–13 với CAM-Y01–04 và T14/T19.
NCS1 chuẩn bị nguồn và nội dung; NCS2 chuyển thành đặc tả đo; CVYK xét chuyên môn.
Nghiệm thu thêm: nguồn→thẻ/quy trình→cấu hình→ca kiểm truy vết được; thu hồi nguồn phải chặn phần phụ thuộc.
Không coi kết quả số học là thẻ tri thức hoặc dùng thẻ vận động chung thay quy trình đo cụ thể.

• Hiện có: docs/research/plans/CAMERA_MODULE_TASK_BOARD.md, docs/research/reports/DEEP_RESEARCH_CAMERA.md, docs/research/plans/_PHUONG_AN_NANG_CAP_V6_CAMERA.md.
• Xử lý: giữ nghiên cứu; sửa bảng công việc theo bằng chứng; gộp quyết định kiến trúc trùng qua D02.
• Đích đề xuất: tiếp tục dùng bảng công việc và phần camera trong kiến trúc; tách docs/research/plans/DAC_TA_CAMERA.md khi cần.
• Vai trò đề xuất: đọc: NCS1/NCS2/CVYK/GVHD; soạn: NCS2; review kỹ thuật: NCS1, an toàn: CVYK; duyệt cổng: GVHD.
• Đầu vào/phụ thuộc: D01, D07, D09, D10, D11, D20; không bắt phần cốt lõi phụ thuộc camera nếu chưa được quyết định.
• Ưu tiên/cổng: P1; GCA điều kiện nghiên cứu, GCB kiểm chứng riêng, GC nếu đưa vào thử nghiệm người dùng.
• Nội dung 1: Chỉ quan sát cử động nào trong phạm vi được duyệt? Không chuyển chỉ số thành chẩn đoán.
• Nội dung 2: Xử lý tại thiết bị và không lưu video được chứng minh bằng kiểm tra mạng, log và lưu trữ ra sao?
• Nội dung 3: Ánh sáng, che khuất, khoảng cách và thiết bị làm kết quả không đủ tin cậy thì dừng thế nào?
• Nội dung 4: Chỉ số nào được lưu, với quyền nào? Hiển thị bắt buộc: “Camera chỉ thấy cử động bên ngoài”.
• Bảng/sơ đồ: luồng dữ liệu riêng; ma trận điều kiện thiết bị; bảng sai số–cách đo–giới hạn; bảng kiểm dừng an toàn.
• DoD: có bằng chứng riêng cho xử lý tại thiết bị, giới hạn và an toàn; không suy từ thử nghiệm kỹ thuật sang hiệu lực y khoa.
• Cách verify: kiểm tra luồng mạng và nơi lưu; thử điều kiện không đạt; CVYK review quy trình trước thử với người.
• Kích hoạt cập nhật: đổi mô hình ước lượng dáng người, thiết bị, chỉ số, bài quan sát hoặc nơi xử lý dữ liệu.

D15 — Công cụ khảo sát và thử nghiệm giới hạn

• Hiện có: docs/research/instruments/W1_D04_OlderAdultSurvey_v0.1.md, docs/research/instruments/W1_D04_ExpertInterviewGuide_v0.1.md, user-research/README.md, mẫu đồng ý D09.
• Xử lý: giữ công cụ nháp; NCS/GVHD sửa theo mục tiêu nghiên cứu; không mặc nhiên dùng với người tham gia.
• Đích: dùng thư mục công cụ hiện có; quy trình đề xuất user-research/QUY_TRINH_THU_NGHIEM_GIOI_HAN.md do NCS xây dựng.
• Vai trò đề xuất: đọc: người tổ chức/người tham gia theo phần; soạn: NCS; review: GVHD/CVYK; cho phép thực hiện: bên có thẩm quyền.
• Đầu vào/phụ thuộc: D01, D03, D07, D09, D11, D13; D14 nếu có camera.
• Ưu tiên/cổng: P1; G0 xem tính hợp lệ nghiên cứu, GC trước tuyển và thu dữ liệu.
• Nội dung quản lý 1: Công cụ đo đúng câu hỏi do NCS lựa chọn chưa? Có câu dẫn dắt hoặc thu dữ liệu không cần thiết không?
• Nội dung quản lý 2: Ai đủ điều kiện tham gia, ai được mời, ai giải thích đồng ý và quyền rút lui?
• Nội dung quản lý 3: Dừng hoạt động, hỗ trợ người tham gia và báo sự cố bằng quy trình nào?
• Nội dung quản lý 4: Thử công cụ trước, ghi thay đổi và tránh ép buộc tham gia như thế nào?
• Bảng/sơ đồ: câu hỏi–mục đích–dữ liệu; bảng phiên bản công cụ; luồng mời → đồng ý → hoạt động → kết thúc/rút lui.
• DoD: công cụ, quyền dữ liệu, người phụ trách và quyết định cho phép khớp cùng phiên bản; chưa được phép thì không tuyển.
• Cách verify: GVHD review phương pháp; kiểm tra tình huống rút lui và dừng bằng diễn tập không thu dữ liệu thật.
• Kích hoạt cập nhật: đổi mục tiêu, nhóm người tham gia, câu hỏi, thao tác, mức rủi ro hoặc công cụ sử dụng.

D16 — Dữ liệu kết quả, khả năng tái lập và phân tích do NCS quyết định

• Hiện có: testing/README.md, docs/guides/TEST_REPORT_TEMPLATE.md, docs/research/plans/W20/D134_T2_phan_tich_log.md, docs/research/plans/W20/D135_T3_insight_report.md.
• Xử lý: giữ kế hoạch như kế hoạch, không gọi là kết quả; tạo hồ sơ kết quả chỉ khi có dữ liệu thực và quyền xử lý.
• Đích đề xuất: quy ước testing/QUY_UOC_DU_LIEU_KET_QUA.md; kết quả trong testing/results/, dữ liệu hạn chế không công khai.
• Vai trò đề xuất: đọc: NCS/GVHD, người kiểm tra được phép; quyết phương pháp và diễn giải: NCS; review: GVHD; xác nhận hồ sơ: người chịu trách nhiệm.
• Đầu vào/phụ thuộc: D03, D09, D10, D15, D20; dấu vết nghiên cứu D04.
• Ưu tiên/cổng: P1; GC chốt cách ghi trước thu thập; GD đối chiếu hồ sơ tái lập.
• Nội dung quản lý 1: Dữ liệu gốc, dữ liệu làm sạch, dữ liệu loại và lý do loại được giữ riêng thế nào?
• Nội dung quản lý 2: NCS lựa chọn phép phân tích và xử lý thiếu dữ liệu trước khi nhìn kết quả bằng hồ sơ nào?
• Nội dung quản lý 3: Phiên bản mô hình, nguồn, mã, cấu hình và dữ liệu được nối tới mỗi lần chạy ra sao?
• Nội dung quản lý 4: Ai được tái lập, với dữ liệu nào? Tách dao động mô hình khỏi sai khác mã hoặc dữ liệu.
• Bảng/sơ đồ: từ điển dữ liệu; bản kê lần chạy; bảng loại dữ liệu; sơ đồ dữ liệu gốc → xử lý → bảng kết quả.
• DoD: không có số liệu tự sinh thay quan sát; NCS tự chọn và giải thích phân tích; mọi kết quả truy được lần chạy.
• Cách verify: người được phép tái chạy một phần và đối chiếu; ghi khác biệt và giới hạn, không đòi kết quả mô hình luôn giống hệt.
• Kích hoạt cập nhật: dữ liệu mới, sửa lỗi xử lý, đổi phương pháp có giải trình hoặc thay bản phát hành được đánh giá.

D17 — Báo cáo, tài liệu bảo vệ và sản phẩm do NCS thực hiện

• Hiện có: docs/research/requirements/PHU_LUC_6_MAU_BAO_CAO_KET_QUA.md, docs/research/reports/OUTLINE_BAO_CAO_15_TRANG.md, docs/presentations/kickoff/.
• Xử lý: kiểm tra nguồn gốc từng bản; giữ lịch sử; không dùng tài liệu AI làm bản đầu báo cáo, tóm tắt hoặc poster.
• Đích: NCS chọn file báo cáo trong docs/reports/ và tài liệu bảo vệ trong docs/presentations/final/ khi tự viết.
• Vai trò đề xuất: đọc: NCS/GVHD và hội đồng theo quyền; soạn bản đầu/kết luận: NCS; review: GVHD/CVYK; duyệt nộp: người có thẩm quyền.
• Đầu vào/phụ thuộc: D03, D04, D05, D13, D16; quy định hình thức và nội dung hiện hành đã xác minh.
• Ưu tiên/cổng: P2; GD, không chờ GD mới kiểm tra nguồn gốc bản đầu.
• Nội dung quản lý 1: Bản đầu, sửa đổi và phần hỗ trợ AI có được nhận diện và lưu riêng không?
• Nội dung quản lý 2: Mỗi bảng, hình và nhận định có nối tới dữ liệu hoặc nguồn NCS đã tự đọc không?
• Nội dung quản lý 3: NCS có tự trình bày giới hạn, kết luận và giải thích phương pháp không? AI không bổ sung lập luận thay NCS.
• Nội dung quản lý 4: Thông tin riêng tư, quyền hình ảnh và quyền nguồn được kiểm tra trước nộp hoặc trình chiếu thế nào?
• Bảng/sơ đồ: bảng kiểm hồ sơ nộp; bảng nguồn gốc phiên bản; bảng hình/bảng–nguồn–quyền–bằng chứng kiểm tra.
• DoD: đáp ứng PL8 và mẫu nộp; có dấu vết bản đầu của NCS; không dùng nhãn “đã review” để che việc viết thay.
• Cách verify: GVHD kiểm tra lịch sử, đối chiếu kết quả và tổ chức NCS giải trình; không tự đánh giá điểm bảo vệ.
• Kích hoạt cập nhật: NCS sửa nội dung, có kết quả mới, thay yêu cầu nộp hoặc phát hiện vấn đề nguồn gốc.

D18 — Hướng dẫn người dùng và hỗ trợ cộng đồng

• Hiện có: community/README.md, telegram-bot/README.md, frontend/README.md.
• Xử lý: sửa README thành điểm vào; chỉ viết hướng dẫn thao tác dựa trên chức năng đã được kiểm tra.
• Đích đề xuất: community/HUONG_DAN_NGUOI_DUNG.md, community/QUY_TRINH_HO_TRO.md khi đã có luồng dùng thực.
• Vai trò đề xuất: đọc: người dùng/người hỗ trợ; soạn: NCS1; review: CVYK và người thử trợ năng; duyệt phát hành: GVHD.
• Đầu vào/phụ thuộc: D01, D07, D09, D11, D12, D15; D14 nếu hướng dẫn camera.
• Ưu tiên/cổng: P1; GC trước thử nghiệm, GD trước phát hành rộng hơn.
• Nội dung 1: Bắt đầu, hỏi, đọc nguồn, sửa dữ liệu, tắt micro và rút khỏi thử nghiệm bằng cách nào?
• Nội dung 2: Phạm vi hỗ trợ và giới hạn hệ thống được giải thích đơn giản ra sao, không quảng bá quá mức?
• Nội dung 3: Người hỗ trợ tiếp nhận lỗi, phản hồi và sự cố nhưng không biến thành kênh tư vấn y khoa như thế nào?
• Nội dung 4: Ai trực hỗ trợ, trong thời gian nào? Kênh không hoạt động phải thông báo ra sao?
• Bảng/sơ đồ: bảng thao tác và ảnh đã ẩn dữ liệu; sơ đồ tiếp nhận → phân loại → chuyển người phụ trách → đóng phản hồi.
• DoD: hướng dẫn khớp phiên bản; thông tin hỗ trợ được xác nhận; không chứa dữ liệu thật hoặc lời hứa chưa kiểm chứng.
• Cách verify: thử hoàn thành thao tác chỉ bằng hướng dẫn; CVYK review thông điệp an toàn; ghi lỗi hiểu nhầm.
• Kích hoạt cập nhật: đổi giao diện, đầu mối hỗ trợ, điều kiện sử dụng hoặc phát hiện người dùng hiểu sai.

D19 — Sinh HTML và xuất bản nội bộ/công khai

• Hiện có: tools/build_docs_site.py, tools/build_html_site.py, tools/build_hub_pages.py, tools/link_audit.py; thư mục html/ có bản xuất.
• Xử lý: giữ công cụ; xác định công cụ chuẩn qua D02; không chạy sinh hoặc đăng trang trong phạm vi tư vấn này.
• Đích đề xuất: docs/guides/QUY_TRINH_XUAT_BAN_HTML.md; danh sách được phép xuất phải quản lý cùng phiên bản nguồn.
• Vai trò đề xuất: đọc: NCS/người xuất bản; soạn: NCS1; review: chủ nội dung và người kiểm tra quyền; duyệt công bố: GVHD theo thẩm quyền.
• Đầu vào/phụ thuộc: D02, D04, D05, D06, D09, D17, D18, D20.
• Ưu tiên/cổng: P1; GB kiểm tra công cụ, GD quyết định phát hành và phạm vi người đọc.
• Nội dung 1: File nào chỉ nội bộ, file nào được công khai? Không xuất toàn cây tài liệu theo mặc định.
• Nội dung 2: Bản DRAFT, nhật ký, dữ liệu cá nhân và tài liệu chưa rõ quyền bị chặn ở bước nào?
• Nội dung 3: Chỉ mục tìm kiếm, sitemap, tài nguyên phụ và bản xuất cũ có làm lộ nội dung đã loại không?
• Nội dung 4: Đồng bộ nguồn–HTML, thu hồi trang và xóa bản lưu đệm thế nào? Trang tĩnh nội bộ cần kiểm soát truy cập thực.
• Bảng/sơ đồ: nguồn–trạng thái–quyền–đối tượng đọc–đầu ra; sơ đồ kiểm tra → sinh thử → review → cho phép → phát hành.
• DoD: có danh sách cho phép rõ; không có nội dung hạn chế trong bản công khai, kể cả dữ liệu tìm kiếm và tài nguyên phụ.
• Cách verify: kiểm tra toàn bộ đầu ra, liên kết và trợ năng; thử file bị cấm; đối chiếu bản kê nguồn với bản xuất.
• Kích hoạt cập nhật: đổi nội dung, trạng thái duyệt, quyền nguồn, công cụ sinh hoặc phạm vi truy cập.

D20 — Môi trường phát triển, phụ thuộc, kiểm thử và đóng góp

• Hiện có: pyproject.toml, Makefile, backend/requirements.txt, data-pipeline/requirements.txt, frontend/package.json, AGENTS.md, tools/.
• Xử lý: giữ cấu hình; thống nhất hướng dẫn; không cài gói, tạo ứng dụng hoặc sửa kiểm thử trong đợt tư vấn này.
• Đích đề xuất: docs/guides/MOI_TRUONG_VA_DONG_GOP.md; README thành phần dẫn tới quy ước chung và ghi phần khác biệt.
• Vai trò đề xuất: đọc: người đóng góp; soạn: NCS1; review: NCS2/người kỹ thuật được giao; duyệt quy ước: GVHD.
• Đầu vào/phụ thuộc: D01, D02, D04, D09; nhận yêu cầu môi trường từ D08, D12 và D14.
• Ưu tiên/cổng: P0; G0 xác định nền tảng, GB kiểm tra tái lập, GD bàn giao.
• Nội dung 1: Phiên bản Python, Node, hệ điều hành và công cụ nào đã kiểm tra? Không coi yêu cầu khai báo là bằng chứng chạy được.
• Nội dung 2: Phụ thuộc được khóa phiên bản, rà quyền, kiểm tra lỗ hổng và cập nhật bằng quy trình nào?
• Nội dung 3: Lệnh kiểm tra nào kiểm tra cấu trúc, schema, thuật ngữ, liên kết và mã? Công cụ nào bỏ qua loại file nào?
• Nội dung 4: Quy tắc đóng góp, review, UTF-8 không BOM, bí mật và ghi nhận mã AI được thực hiện ra sao?
• Bảng/sơ đồ: môi trường–phiên bản–bằng chứng; công cụ–phạm vi–ngoại lệ; quy trình thay đổi → review → kiểm thử → tích hợp.
• DoD: hướng dẫn tái lập được kiểm tra; có test chứng minh phát hiện lỗi; PASS luôn kèm phạm vi và giới hạn.
• Cách verify: cài thử ở môi trường tách biệt khi được phép; chạy test dương/âm; đối chiếu phụ thuộc khai báo với thực tế.
• Kích hoạt cập nhật: đổi phiên bản, thêm gói, sửa công cụ kiểm tra, thay môi trường hoặc phát hiện lỗi chuỗi phụ thuộc.

4. Quy tắc tích hợp và việc cần GVHD/agent chính xác nhận

1. Thống nhất định nghĩa G0, GA, GB, GC, GD, GCA, GCB với tài liệu cổng kiểm soát cùng đợt.
2. Nối các số kiểm kê kế thừa tới bằng chứng trong báo cáo phát hiện; không dùng tài liệu này làm nguồn đo độc lập.
3. Kiểm tra năm liên kết điều hướng sau khi các file do agent chính phụ trách đã được tạo.
4. Xác nhận PL8 đang áp dụng và ranh giới sử dụng tư vấn; không suy ra đã có ngoại lệ cho AI.
5. Quyết định người nhận việc và người có thẩm quyền; phân vai trong đặc tả chưa phải sự đồng ý của họ.
6. Xem lại nội dung từng file trước khi quyết định giữ, sửa, gộp hoặc lưu trữ; kiểm kê chỉ xác nhận tồn tại.
7. D03, D16, D17 phải giữ quyền tự quyết của NCS và bằng chứng thực hiện; không giao AI viết thay bản đầu.
8. Đích đề xuất chỉ là phương án; D02 chốt vị trí cuối cùng trước khi tạo tài liệu có nội dung.

Ranh giới nhánh soạn đặc tả: chỉ tạo file đặc tả này; không sửa INDEX, nhật ký, schema, công cụ hoặc nội dung khác.
Agent chính đã tích hợp chỉ mục, nhật ký và kiểm tra bộ tư vấn; kết quả nằm trong biên bản của bộ báo cáo.
Không có cổng nào được tự xác nhận đạt và không có tài liệu đích nào được triển khai bởi đặc tả này.