PROMPT: Deep Research — Bổ sung chức năng Camera Quan sát Cử động, Phản biện, Chấm điểm & Nâng cấp Kiến trúc lên v6.0

Loại: Deep research + thiết kế phương án + phản biện đa vai + chấm điểm + kế hoạch nâng cấp tài liệu
Target: Agent có quyền đọc file, tìm kiếm web, tạo file mới (KHÔNG tự sửa tài liệu đã duyệt)
Phiên bản: 1.0
Ngày tạo: 25/09/2026
Tài liệu gốc cần nâng cấp: KIEN_TRUC_DU_AN.md (hiện tại v5.0)
Mục tiêu phiên bản mới: v6.0

---

Mục đích

Trả lời bằng bằng chứng cho một câu hỏi nghiên cứu chính và ba câu hỏi phụ:

Câu hỏi chính:

Có nên bổ sung chức năng kết nối hệ thống camera quan sát cử động (movement observation camera) vào Trợ lý AI CXK để hỗ trợ phân loại mức độ (triage) và phát hiện sớm cờ đỏ (red flag) hay không? Nếu nên thì làm ở phạm vi nào, bằng kiến trúc nào, với điều kiện an toàn và pháp lý nào?

Câu hỏi phụ:
1. Những dấu hiệu nào thực sự quan sát được qua camera, và những cờ đỏ nào camera không thể thấy?
2. Mọi chỉ số và ngưỡng đưa ra có truy vết nguồn (provenance) về kho tri thức y khoa của dự án được không? Nếu thiếu thì cần bổ sung thẻ bằng chứng nào?
3. Với nguồn lực thực tế (1 NCS lớp 10, ≤ 2h/ngày; CVYK part-time; 21 tuần), phương án nào khả thi mà không phá vỡ phạm vi MVP hiện tại?

Sau khi nghiên cứu, phải phản biện, chấm điểm bằng số, và lập phương án nâng cấp tài liệu kiến trúc từ v5.0 lên v6.0 cùng danh sách tài liệu liên quan phải sửa theo.

---

Cách sử dụng

Chạy prompt 20 để nghiên cứu bổ sung chức năng camera quan sát cử động,
phản biện, chấm điểm và lập phương án nâng cấp tài liệu 10 lên v6.0.

---

PHẦN A: Chuẩn bị & Đọc Input

A1. Tài liệu bắt buộc đọc (theo thứ tự)

A2. Tài liệu y khoa nội bộ cần tra cứu (để truy vết nguồn)

Đọc mục lục và phần liên quan (không cần đọc toàn văn) của:

A3. Ghi nhận trước khi nghiên cứu

Liệt kê rõ trong output:
- Đã đọc: danh sách file + phiên bản/ngày ghi trong file.
- Chưa có / chưa xác minh: ví dụ cấu hình phần cứng máy chủ (có GPU hay không), ngân sách thiết bị, số người tham gia pilot chấp nhận ghi hình. Dùng placeholder dạng [CHƯA CÓ DỮ LIỆU: ...]. Không suy đoán thành sự thật.

---

PHẦN B: Deep Research theo 8 Trục

B0. Quy tắc nguồn

• Tối thiểu 25 nguồn ngoài dự án, ưu tiên: hướng dẫn của cơ quan y tế > tổng quan hệ thống/phân tích gộp > nghiên cứu gốc có đối chứng > tài liệu kỹ thuật chính thức của thư viện/công cụ > blog.
• Mỗi nguồn ghi: tên, tổ chức hoặc người viết, năm hoặc ngày công bố, đường dẫn, ngày kiểm tra, mức bằng chứng (A→E theo evidence_pyramid của dự án).
• Mọi con số đều phải có nguồn. Không có nguồn thì ghi [CHƯA XÁC MINH], không được viết ra như dữ kiện.
• Không sao chép quá 30 từ liên tiếp từ một nguồn; diễn giải lại và dẫn link.
• Nếu môi trường không có công cụ tìm kiếm web: ghi rõ ở đầu báo cáo, chỉ dùng kho tri thức nội bộ, và đánh dấu toàn bộ phần cần nguồn ngoài là [CẦN TÌM NGUỒN NGOÀI]. Không được giả vờ đã nghiên cứu.

B1. Trục 1 — Y khoa: camera quan sát được gì, không quan sát được gì

Nghiên cứu và trả lời:

1. Các thử nghiệm chức năng vận động (functional test) đã được công nhận, có thể đo bằng camera: Timed Up and Go (TUG), 5 lần đứng lên ngồi xuống (5-times sit-to-stand), tốc độ đi bộ (gait speed), thăng bằng một chân, thang đo dáng đi/thăng bằng, tầm vận động khớp (range of motion), phát hiện té ngã (fall detection).
2. Với từng thử nghiệm: đo cái gì, ngưỡng bất thường theo nguồn nào, ý nghĩa lâm sàng (nguy cơ té ngã, suy giảm chức năng), và giới hạn khi đo tại nhà.
3. Độ tin cậy của camera so với chuẩn lâm sàng: sai số thời gian, sai số góc khớp, ảnh hưởng của quần áo rộng, ánh sáng yếu, dùng gậy/khung tập đi, góc và khoảng cách camera, che khuất (occlusion).
4. Bảng đối chiếu cờ đỏ — bắt buộc có:

Lấy danh mục cờ đỏ từ tap2/27-dinh-huong-chan-doan-dau-xuong-khop.md, tap2/28-dau-vung-that-lung.md và safety/W1_D05_SafetyPolicy_v0.1.md. Phải kết luận rõ tỷ lệ cờ đỏ mà camera không thấy được.

5. Sự khác biệt bắt buộc phải nêu: dấu hiệu quan sát (observation signal) ≠ chẩn đoán. Camera chỉ sinh dấu hiệu để đưa vào phân loại mức độ (triage), tuyệt đối không sinh kết luận bệnh.

B2. Trục 2 — Truy vết nguồn về kho tri thức dự án

• Ngưỡng/chỉ số nào đã có trong kho tri thức nội bộ (nêu file + mục)?
• Ngưỡng nào chưa có → cần tạo bao nhiêu thẻ bằng chứng (evidence card) mới, thuộc nhóm nào trong bảng phân loại?
• Schema knowledge_item_schema.yaml có đủ trường cho loại thẻ mới (thẻ đo chức năng vận động) chưa? Nếu thiếu, đề xuất trường mới: ví dụ measurement_method, device_requirement, threshold, threshold_source_id, false_negative_note, clinical_validation_status.
• Ai duyệt ngưỡng? Trả lời rõ: CVYK (Lương y Vũ Thế Sỹ) phải ký từng ngưỡng, không để AI tự chọn.

B3. Trục 3 — Công nghệ thị giác máy tính

• So sánh các hướng ước lượng dáng người (pose estimation) khả dụng: thư viện chạy trên trình duyệt (WASM/WebGL), thư viện chạy trên máy chủ, mô hình nhẹ vs mô hình lớn. Với mỗi hướng: giấy phép sử dụng, yêu cầu phần cứng, chạy được trên CPU không, độ trễ, mức chính xác công bố, ngày phiên bản.
• Loại camera: webcam RGB, camera điện thoại, camera IP (RTSP/ONVIF), camera có cảm biến độ sâu. So sánh chi phí, độ chính xác, độ phức tạp tích hợp.
• Đối chiếu hạ tầng thực tế của dự án: Windows Server 2022 + IIS 10 + MSSQL 2022, FastAPI. Nêu rõ điều kiện chưa biết: [CHƯA CÓ DỮ LIỆU: máy chủ có GPU hay không]. Nếu không có GPU thì phương án nào còn khả thi?
• Xử lý tại thiết bị (on-device) vs gửi lên máy chủ: so sánh về quyền riêng tư, băng thông, độ trễ, độ khó triển khai. Nêu khuyến nghị.

B4. Trục 4 — Kiến trúc & tích hợp

• Vị trí module mới trong cấu trúc 6 tầng hiện có: đề xuất movement-observation/ (Tầng 4 — Kỹ thuật), kèm cây thư mục con.
• Luồng dữ liệu đầy đủ, vẽ bằng Mermaid: người dùng/người chăm sóc → thu hình → ước lượng dáng người → tính chỉ số → đối chiếu ngưỡng (có truy vết nguồn) → bộ lọc an toàn → phân loại mức độ → câu trả lời có trích dẫn + lời khuyên an toàn.
• Chính sách lưu trữ: mặc định không lưu video; chỉ lưu toạ độ khung xương và chỉ số đã tính, hoặc chỉ lưu chỉ số. Nêu rõ cái gì lưu ở đâu, bao lâu, ai xoá được.
• Hợp đồng API (request/response) và cách chỉ số camera ghép với hội thoại text/voice hiện có; xử lý khi hai nguồn xung đột (người dùng nói "đi bình thường" nhưng chỉ số bất thường, và ngược lại).
• Ảnh hưởng tới sơ đồ hạ tầng Giai đoạn 1 và Giai đoạn 2 trong tài liệu v5.0 — vẽ lại sơ đồ đã bổ sung.
• Ai được bật phiên quan sát? Có bắt buộc người chăm sóc có mặt không?

B5. Trục 5 — Pháp lý & đạo đức

Phân tích cụ thể, có dẫn điều/khoản khi tìm được:

Kết luận phần này phải trả lời dứt khoát: có rào cản pháp lý nào khiến không thể làm trong phạm vi MVP nghiên cứu không?

B6. Trục 6 — An toàn & rủi ro mới

Phân tích ít nhất 8 rủi ro mới, mỗi rủi ro theo format của safety/risk_register.md (Risk ID RSK-CAM-00n, danh mục, severity, likelihood, impact, mitigation, owner):

1. Âm tính giả — chỉ số bình thường làm người dùng trì hoãn đi khám dù có cờ đỏ chủ quan.
2. Dương tính giả — gây lo lắng, đi khám không cần thiết ở NCT.
3. Rủi ro thân thể khi tự đo — thử nghiệm đứng lên/đi lại tại nhà ở người có nguy cơ té ngã mà không ai giám sát. Đây là rủi ro thể chất trực tiếp, không chỉ là rủi ro thông tin.
4. Thiên lệch tin máy (automation bias) — người dùng và người chăm sóc tin camera hơn cảm nhận cơ thể.
5. Trượt sang chẩn đoán — ngôn từ kết quả vô tình mang tính kết luận bệnh.
6. Rò rỉ hình ảnh trong nhà — video chứa người khác, không gian riêng tư.
7. Sai lệch mô hình theo nhóm người — mô hình huấn luyện trên dữ liệu không đại diện NCT Việt Nam, người dùng gậy, người mặc áo dài/quần rộng.
8. Phình phạm vi (đối chiếu RSK-014) — camera kéo theo phần cứng, ML, pháp lý, làm trượt tiến độ MVP.

Bổ sung: các ca kiểm thử mới cho SafetyTests (tối thiểu 15 ca, gồm ca đối kháng: người dùng hỏi "camera nói tôi bình thường nên khỏi đi khám đúng không?").

B7. Trục 7 — Trợ năng & UX cho người cao tuổi

• Người cao tuổi tự đặt camera được không? Cần hướng dẫn bằng giọng nói + hình minh hoạ cỡ lớn như thế nào?
• Mức chấp nhận camera trong nhà của NCT Việt Nam — tìm nguồn khảo sát; nếu không có, ghi [CẦN KHẢO SÁT] và đề xuất câu hỏi bổ sung vào bộ khảo sát hiện có tại user-research/.
• Yêu cầu trợ năng: đèn báo đang ghi, nút dừng lớn, nói rõ "không lưu video", bản ghi kết quả bằng chữ lớn.
• Phương án dự phòng khi camera không dùng được: người dùng tự trả lời bộ câu hỏi chức năng thay cho đo bằng camera.

B8. Trục 8 — Khả thi nguồn lực & 3 phương án phạm vi

Đối chiếu thực tế: 1 NCS lớp 10 (≤ 2h/ngày), CVYK ~9.6h/sprint, GVHD ~1h15/tuần, 21 tuần đã lấp gần kín, không có chuyên gia thị giác máy tính trong nhóm.

Xây 3 phương án và so sánh:

Điền số cụ thể, không để trống. Nêu khuyến nghị 1 phương án kèm lý do và điều kiện kèm theo.

---

PHẦN C: Thiết kế Phương án được chọn

Với phương án khuyến nghị, tạo đủ các hạng mục sau (mức chi tiết đủ để lập trình theo):

1. Sơ đồ kiến trúc (Mermaid) — bổ sung vào sơ đồ Giai đoạn 1 hiện có.
2. Cây thư mục module mới — theo quy ước kebab-case cho thư mục, snake_case.py cho file Python.
3. Đặc tả chỉ số — mỗi chỉ số: tên, cách tính, đơn vị, ngưỡng, source_id, trạng thái duyệt (DRAFT/CLINICAL_REVIEW/APPROVED).
4. Bổ sung schema — trường mới cho thẻ tri thức/thẻ bằng chứng loại đo chức năng; nêu rõ phải cập nhật tools/validate_schema.py kèm theo.
5. Hợp đồng API — endpoint, input, output, mã lỗi, hành vi khi độ tin cậy thấp (phải trả INSUFFICIENT_DATA, không đoán).
6. Sơ đồ luồng dữ liệu + bảng lưu trữ — cái gì lưu, ở đâu, bao lâu, ai xoá.
7. Ngôn ngữ trả kết quả — 5 mẫu câu an toàn (không dùng từ chẩn đoán) + 5 mẫu câu cấm dùng.
8. ADR mới — viết đầy đủ theo format 4 mục (Context / Decision / Consequences / Trigger) của tài liệu v5.0:
   - ADR-005: Camera là công cụ quan sát hỗ trợ, không phải công cụ chẩn đoán.
   - ADR-006: Xử lý tại thiết bị, chỉ giữ khung xương, không lưu video.
   - ADR-007: Chức năng camera đặt ở giai đoạn nào (MVP / hậu MVP / Giai đoạn 3) và điều kiện kích hoạt.
9. Bộ kiểm thử chuẩn bổ sung — số ca, phân bổ xanh/vàng/đỏ, cách gán nhãn vàng (gold label), ai gán.
10. Tiêu chí dừng — điều kiện nào thì huỷ chức năng camera (ví dụ: độ nhạy phát hiện bất thường < ngưỡng CVYK chấp nhận).

---

PHẦN D: Phản biện Đa vai

Phản biện trung thực, mỗi góc nhìn ≥ 3 phát hiện, mỗi phát hiện kèm bằng chứng (tên file + mục, hoặc nguồn ngoài).

D2. Danh sách lỗi mẫu phải kiểm

• [ ] Giải pháp đi tìm vấn đề — camera được thêm vì công nghệ hay vì nhu cầu người dùng có bằng chứng?
• [ ] Che phủ an toàn giả — bổ sung camera nhưng phần lớn cờ đỏ vẫn không thấy được.
• [ ] Ngưỡng không nguồn — dùng số liệu nghiên cứu nước ngoài cho NCT Việt Nam mà không nêu giới hạn.
• [ ] Bỏ qua rủi ro thể chất — đo vận động tại nhà không giám sát.
• [ ] Phình phạm vi — thêm phần cứng, ML, pháp lý vào MVP đã kín lịch.
• [ ] Nợ pháp lý — làm trước, xin phép sau.
• [ ] Thiếu phương án lùi — không có cách tắt chức năng nếu kết quả kiểm thử xấu.
• [ ] Kiểm thử muộn — chỉ kiểm thử ở cuối, không kiểm thử liên tục.

D3. Lập luận ngược

Viết một đoạn bảo vệ mạnh nhất có thể cho phương án đối lập với khuyến nghị của mình (nếu khuyến nghị "làm" thì bảo vệ "không làm", và ngược lại), rồi trả lời lại từng điểm. Mục đích: chống thiên lệch xác nhận.

---

PHẦN E: Chấm điểm

Chấm bằng số, mỗi điểm kèm một câu bằng chứng. Không dùng "tốt/khá/trung bình".

E1. Chấm đề xuất camera — 10 chiều, có trọng số (tổng /100)

Quy tắc phán quyết:

E2. Chấm tài liệu v5.0 hiện tại — mức sẵn sàng đón tính năng mới (/100)

E3. Chấm 3 phương án phạm vi

Mỗi phương án chấm 5 tiêu chí × 20 điểm: An toàn / Pháp lý / Khả thi / Giá trị khoa học / Tác động tiến độ → /100 mỗi phương án. Xếp hạng và chốt.

---

PHẦN F: Phương án Nâng cấp lên v6.0

Phần này là kế hoạch nâng cấp, không phải bản v6.0 hoàn chỉnh. Chỉ soạn v6.0 sau khi NCS + GVHD duyệt kế hoạch, và phần y khoa có ý kiến CVYK.

F1. Changelog dự kiến v5.0 → v6.0

F2. Bảng sửa theo từng mục của tài liệu 10

Với mỗi mục từ 1 đến 8 của tài liệu hiện tại, ghi: giữ nguyên / sửa / thêm mới, và nếu sửa thì nội dung chốt là gì. Phải nêu cụ thể tối thiểu:

• Mục 1 Executive Summary — có thêm tuyên bố về camera hay không, ở mức nào.
• Mục 2 Gap Analysis — thêm hạng mục camera vào bảng "CHƯA CÓ" với mức ưu tiên đúng (khuyến nghị không đặt P0/P1 nếu phán quyết là HOÃN).
• Mục 2.3 Rủi ro — thêm các rủi ro RSK-CAM-*.
• Mục 3 Cây thư mục — thêm module mới vào Tầng 4 (hoặc ghi rõ chưa thêm và vì sao).
• Mục 4 Tech stack + sơ đồ hạ tầng + sprint plan — cập nhật hoặc thêm bảng riêng cho giai đoạn có camera.
• Mục 5 Bài trình bày — có thêm slide về camera cho bảo vệ cuối không.
• Mục 7 ADR — thêm ADR-005/006/007.
• Mục 8 Trigger chuyển giai đoạn — thêm ngưỡng kích hoạt chức năng camera.
• Thêm mục mới: Changelog phiên bản + bảng người duyệt.

F3. Tài liệu liên quan phải cập nhật kèm theo

Liệt kê thuật ngữ mới đề xuất cho Glossary, tối thiểu: quan sát cử động (movement observation), ước lượng dáng người (pose estimation), khung xương số (skeleton keypoints), phân tích dáng đi (gait analysis), thử nghiệm chức năng (functional test), xử lý tại thiết bị (on-device processing), dữ liệu sinh trắc (biometric data), âm tính giả (false negative), dương tính giả (false positive).

F4. KPI bổ sung — đề xuất và tự đánh giá mức cần thiết (0–10)

F5. Điều kiện tiên quyết trước khi viết dòng code đầu tiên

Liệt kê dạng checklist có thể ký:
- [ ] CVYK ký danh mục chỉ số + ngưỡng + giới hạn.
- [ ] Bản đánh giá tác động quyền riêng tư được duyệt.
- [ ] Mẫu đồng ý riêng cho ghi hình được duyệt.
- [ ] GVHD và nhà trường đồng ý phạm vi thu thập hình ảnh trong đề tài.
- [ ] Xác nhận cấu hình máy chủ đủ chạy phương án đã chọn.
- [ ] Có phương án lùi (tắt chức năng) đã viết thành tài liệu.

F6. Tiêu chí nghiệm thu bản v6.0

• [ ] Có mục changelog và bảng người duyệt.
• [ ] Mọi phát biểu y khoa có source_id hoặc được đánh dấu [CẦN NGUỒN].
• [ ] Không có từ "chẩn đoán" gán cho hành vi của hệ thống.
• [ ] Cây thư mục trong tài liệu khớp thư mục thật, hoặc đánh dấu rõ 🆕 chưa tạo.
• [ ] python tools/check_glossary.py — 0 vi phạm HIGH.
• [ ] python tools/validate_schema.py — pass.
• [ ] Mọi liên kết nội bộ là đường dẫn tương đối và không hỏng.
• [ ] Bảng sprint không còn ô ghi chung "Deliverable/Pass" cho task mới thêm.

F7. Phương án lùi

Nêu rõ: nếu v6.0 bị phản đối ở cổng kiểm soát thì lùi thế nào (giữ v5.0 làm bản hiệu lực, v6.0 chuyển trạng thái DRAFT, ghi lý do vào nhật ký).

---

PHẦN G: Output & Thủ tục Kết thúc

G1. File kết quả

Mỗi file mở đầu bằng: phiên bản, ngày, trạng thái (DRAFT), người thực hiện, phạm vi, và bảng tóm tắt 1 trang cho GVHD đọc nhanh (phán quyết + 5 phát hiện quan trọng nhất + 3 việc cần quyết ngay).

G2. Giới hạn quyền

• KHÔNG tự sửa KIEN_TRUC_DU_AN.md, intended_use.md, project_charter.md, risk_register.md hay bất kỳ nội dung y khoa đã được CVYK phê duyệt trong lần chạy này.
• Chỉ tạo mới 2 file ở G1. Mọi thay đổi khác là đề xuất trong bảng.
• Nếu người dùng yêu cầu thực thi nâng cấp: chạy lại theo Phần F đã được duyệt, sửa theo đúng bảng, và tăng phiên bản kèm changelog.

G3. Thủ tục kết thúc phiên (theo AGENTS.md)

• [ ] Liệt kê file đã tạo/sửa.
• [ ] Xoá file trung gian; script dùng lại thì chuyển vào tools/ kèm docstring.
• [ ] python tools/check_glossary.py — sửa hết vi phạm HIGH.
• [ ] python tools/validate_schema.py nếu có chạm schema.
• [ ] Ghi nhật ký vào docs/diary/2026-MM-DD.md (append, không ghi đè); cập nhật docs/diary/README.md nếu tạo entry mới.
• [ ] Báo cáo tóm tắt cho NCS.

---

Ràng buộc

---

Checklist Hoàn thành

• [ ] Đã đọc 15 tài liệu ở A1 và ghi phiên bản từng file
• [ ] Đã tra cứu 6 nguồn y khoa nội bộ ở A2
• [ ] Đã ghi danh sách [CHƯA CÓ DỮ LIỆU]
• [ ] Đã nghiên cứu đủ 8 trục ở Phần B
• [ ] Có ≥ 25 nguồn ngoài, mỗi nguồn có ngày công bố + ngày kiểm + mức bằng chứng
• [ ] Có bảng đối chiếu cờ đỏ — camera thấy được / không thấy được
• [ ] Đã xác định ngưỡng nào có sẵn trong kho tri thức, ngưỡng nào cần thẻ bằng chứng mới
• [ ] Đã phân tích đủ 6 khung pháp lý ở B5, có kiểm tra hiệu lực văn bản
• [ ] Đã nêu ≥ 8 rủi ro mới theo format RSK-CAM-* + ≥ 15 ca kiểm thử
• [ ] Đã so sánh 3 phương án phạm vi bằng số và chốt 1 phương án
• [ ] Đã thiết kế đủ 10 hạng mục ở Phần C, gồm 3 ADR mới
• [ ] Đã phản biện 7 góc nhìn (≥ 21 phát hiện) + checklist lỗi mẫu + lập luận ngược
• [ ] Đã chấm E1 (/100 có trọng số) + E2 (/100) + E3 (3 × /100) và ra phán quyết
• [ ] Đã lập Phần F đầy đủ 7 mục, gồm bảng 15 tài liệu liên quan
• [ ] Đã tạo đúng 2 file ở G1, không sửa tài liệu đã duyệt
• [ ] Đã chạy check_glossary.py và ghi nhật ký

---

Ghi chú: Prompt này không thực thi nâng cấp tài liệu. Nó sinh ra hồ sơ nghiên cứu và phương án nâng cấp để NCS, GVHD và CVYK duyệt. Việc soạn bản v6.0 chỉ chạy sau khi có duyệt, theo đúng bảng ở Phần F.