aarif khatri

PROMPT PHÁT TRIỂN PHẦN MỀM AI TỔNG THỂ
Cơ Quan Hành Chính Cấp Huyện — Nền Tảng Quản Lý Chiến Dịch Đa Năng, Vận Hành Thực Địa, Khảo Sát, Xác Minh, Báo Cáo & Thanh Toán
Hãy xây dựng một ứng dụng web toàn diện (full-stack), cấp doanh nghiệp, sẵn sàng cho môi trường thực tế (production-grade) dành cho Cơ quan Hành chính Cấp Huyện để tạo lập và vận hành các chiến dịch thực địa quy mô lớn của chính quyền.
Nền tảng phải hỗ trợ các chiến dịch có sự tham gia của:
•	Một phòng ban.
•	Nhiều phòng ban.
•	Các đội liên ngành phối hợp nhiều phòng ban.
•	Cán bộ cấp cao.
•	Giám sát viên.
•	Cán bộ thực địa.
•	Nhân sự dự bị/dự phòng.
•	Các cơ sở/tổ chức.
•	Làng/Xã.
•	Phường.
•	Khu dân cư/Tổ dân phố (Mohallas).
•	Hộ gia đình.
•	Các thực thể mục tiêu có thể cấu hình khác.
Hệ thống phải cho phép Cơ quan Hành chính Cấp Huyện tạo một chiến dịch, chia chiến dịch thành nhiều giai đoạn, tạo các biểu mẫu khác nhau cho từng giai đoạn, phân công nhân sự và đội nhóm vào các khu vực địa lý cũng như các thực thể mục tiêu, thu thập dữ liệu thực địa thông qua thiết bị di động, xác minh dữ liệu gửi lên thông qua hệ thống phân cấp có thể cấu hình, yêu cầu chỉnh sửa, theo dõi kết quả cuối cùng, tính toán tiền công tác phí/thù lao được phê duyệt theo hướng dẫn có thể cấu hình của chính quyền, và tạo bảng điều khiển cũng như báo cáo.
Hệ thống phải mang tính tổng quát (generic).
Không được gắn cứng (hard-code) ứng dụng chỉ dành riêng cho Tổng điều tra dân số.
Tổng điều tra dân số 2027 (Census 2027) nên được triển khai như một ví dụ về loại chiến dịch.
Các loại chiến dịch khác phải có thể được tạo lập mà không cần thay đổi phần mềm cốt lõi.
Ví dụ:
•	Tổng điều tra dân số 2027 (Census 2027).
•	Thanh tra Trường học.
•	Thanh tra Bệnh viện.
•	Khảo sát Đường bộ.
•	Khảo sát Thiệt hại Lũ lụt.
•	Khảo sát Làng/Xã.
•	Thanh tra Hệ thống Phân phối Công cộng (PDS).
•	Thanh tra Trung tâm Chăm sóc Bà mẹ và Trẻ em (Anganwadi).
•	Khảo sát Cơ sở Hạ tầng.
•	Xác minh Chương trình Trợ cấp Chính phủ.
•	Đánh giá Thiên tai.
•	Xác minh Thực địa Khiếu nại Công dân.
•	Bất kỳ chiến dịch cấp huyện nào trong tương lai.
________________________________________
1. MÔ HÌNH NGHIỆP VỤ CỐT LÕI
Toàn bộ hệ thống phải tuân theo cấu trúc sau:
Huyện (District)
→ Chiến dịch (Campaign)
→ Giai đoạn Chiến dịch (Campaign Phase)
→ Phạm vi Địa lý (Geographic Scope)
→ Các Phòng ban (Departments)
→ Lực lượng Nhân sự (Workforce)
→ Các Đội nhóm (Teams)
→ Các Thực thể Mục tiêu (Target Entities)
→ Các Nhiệm vụ (Tasks)
→ Các Biểu mẫu Động (Dynamic Forms)
→ Đệ trình Dữ liệu Thực địa (Field Submission)
→ Xác minh (Verification)
→ Chỉnh sửa/Đệ trình lại (Correction/Re-submission)
→ Phê duyệt Cuối cùng (Final Approval)
→ Kết quả Giai đoạn (Phase Result)
→ Thanh toán/Thù lao (Payment/Honorarium)
→ Báo cáo (Reports)
Mọi thành phần đều phải có thể cấu hình được.
________________________________________
2. MỤC TIÊU CHÍNH
Ứng dụng phải giải quyết được bài toán thực tế sau:
"Một Cơ quan Hành chính Cấp Huyện có hàng nghìn nhân sự thuộc các phòng ban khác nhau và muốn tiến hành đồng thời nhiều chiến dịch thực địa trên khắp các khu vực địa lý khác nhau, với các đội nhóm, biểu mẫu, khối lượng công việc, quy trình xác minh, thời hạn, quy tắc thanh toán và yêu cầu báo cáo khác nhau."
Nền tảng phải giảm thiểu việc điều phối thủ công dựa trên Excel/WhatsApp/giấy tờ.
Nó phải cung cấp một hệ thống chỉ huy trung tâm duy nhất cho Cơ quan Hành chính Cấp Huyện.
________________________________________
3. ĐA CHIẾN DỊCH
Cơ quan Hành chính Cấp Huyện phải có khả năng vận hành đồng thời nhiều chiến dịch.
Ví dụ:
•	Tổng điều tra dân số 2027.
•	Thanh tra Trường học.
•	Khảo sát Đường bộ.
•	Đánh giá Lũ lụt.
•	Khảo sát Nước sinh hoạt.
Mỗi chiến dịch hoạt động độc lập.
Mỗi chiến dịch có thể có:
•	Các phòng ban khác nhau.
•	Nhân sự khác nhau.
•	Khu vực địa lý khác nhau.
•	Biểu mẫu khác nhau.
•	Quy trình làm việc (workflow) khác nhau.
•	Thời hạn hoàn thành khác nhau.
•	Quy tắc thanh toán khác nhau.
•	Thực thể mục tiêu khác nhau.
•	Cấu trúc báo cáo khác nhau.
________________________________________
4. CHIẾN DỊCH ĐA GIAI ĐOẠN
Mỗi chiến dịch có thể có nhiều giai đoạn.
Ví dụ:
Tổng điều tra dân số 2027
Giai đoạn 1
Lập danh sách Nhà ở
Giai đoạn 2
Điều tra Nhân khẩu Hộ gia đình
Giai đoạn 3
Xác minh
Giai đoạn 4
Chỉnh sửa/Điều tra lại
Mỗi giai đoạn phải có khả năng thiết lập:
•	Thời gian diễn ra khác nhau.
•	Biểu mẫu khác nhau.
•	Lực lượng nhân sự khác nhau.
•	Đội nhóm khác nhau.
•	Phân công địa bàn khác nhau.
•	Hướng dẫn thực hiện khác nhau.
•	Khối lượng công việc khác nhau.
•	Quy trình xác minh khác nhau.
•	Quy tắc thanh toán khác nhau.
•	Kết quả đầu ra khác nhau.
Không được mặc định rằng tất cả các giai đoạn đều sử dụng cùng một nhóm nhân sự hoặc cùng một biểu mẫu.
________________________________________
5. CÁC LOẠI CHIẾN DỊCH
Tạo các loại chiến dịch có thể cấu hình được.
Ví dụ:
•	Tổng điều tra dân số (Census).
•	Thanh tra (Inspection).
•	Khảo sát (Survey).
•	Xác minh (Verification).
•	Kiểm đếm/Thống kê (Enumeration).
•	Giám sát (Monitoring).
•	Đánh giá (Assessment).
•	Ứng phó thiên tai (Disaster response).
•	Khảo sát cơ sở hạ tầng (Infrastructure survey).
•	Tùy chỉnh (Custom).
Quản trị viên có thể tạo mới một loại chiến dịch.
________________________________________
6. PHÂN CẤP TỔ CHỨC
Cơ cấu tổ chức phải có thể cấu hình được.
Ví dụ:
Quản trị viên Cấp Huyện (District Admin)
→ Trưởng Phòng ban (Department Head)
→ Cán bộ Phân khu (Subdivision Officer)
→ Cán bộ Hạt/Phân huyện (Tehsil Officer)
→ Cán bộ Khối/Cụm xã (Block Officer)
→ Giám sát viên (Supervisor)
→ Đội Thực địa (Field Team)
→ Cán bộ Thực địa (Field Officer)
Nhưng một phòng ban khác có thể có cơ cấu tổ chức khác.
Do đó không được gắn cứng (hard-code) các cấp bậc phân cấp.
Hãy sử dụng:
OrganizationNode
với mối quan hệ cha/con (parent/child) có thể cấu hình được.
________________________________________
7. PHÂN CẤP ĐỊA LÝ
Hỗ trợ hệ thống phân cấp địa lý linh hoạt.
Ví dụ khu vực nông thôn:
Bang/Tỉnh (State)
→ Huyện (District)
→ Phân khu (Subdivision)
→ Hạt/Phân huyện (Tehsil)
→ Khối/Cụm xã (Block)
→ Làng/Xã (Village)
→ Xóm/Thôn (Mohalla/Hamlet)
→ Hộ gia đình (Household)
Ví dụ khu vực đô thị:
Bang/Tỉnh (State)
→ Huyện (District)
→ Đô thị/Thành phố trực thuộc (Municipality/Nagar Palika)
→ Khu vực (Zone)
→ Phường (Ward)
→ Khu dân cư/Tổ dân phố (Mohalla)
→ Hộ gia đình (Household)
Hệ thống phải hỗ trợ cả hai mô hình.
Không được mặc định rằng mọi khu vực đều có cùng một cấu trúc địa lý.
________________________________________
8. DỮ LIỆU DANH MỤC ĐỊA LÝ GỐC (GEOGRAPHIC MASTER DATA)
Tạo chức năng quản lý dữ liệu danh mục địa lý gốc.
Quản trị viên có thể quản lý:
•	Huyện (District).
•	Phân khu (Subdivision).
•	Hạt/Phân huyện (Tehsil).
•	Khối/Cụm xã (Block).
•	Đô thị (Municipality).
•	Phường (Ward).
•	Làng/Xã (Village).
•	Khu dân cư/Thôn xóm (Mohalla).
•	Tọa độ GPS.
•	Ranh giới/đa giác bản đồ (polygon) ở những nơi có dữ liệu.
Hỗ trợ nhập dữ liệu hàng loạt thông qua:
•	CSV.
•	Excel.
•	API dữ liệu danh mục gốc của chính phủ ở những nơi có sẵn.
Kiểm tra phát hiện các bản ghi địa lý trùng lặp.
________________________________________
9. BỘ MÁY QUẢN LÝ THỰC THỂ MỤC TIÊU (TARGET ENTITY ENGINE)
Không được biến "hộ gia đình" thành thực thể mục tiêu duy nhất.
Hãy tạo một hệ thống thực thể mục tiêu tổng quát.
Các thực thể có thể có:
•	Hộ gia đình (Household).
•	Cá nhân (Person).
•	Trường học (School).
•	Bệnh viện (Hospital).
•	Tuyến đường (Road).
•	Làng/Xã (Village).
•	Cửa hàng (Shop).
•	Trung tâm Anganwadi.
•	Tòa nhà công sở chính quyền (Government building).
•	Nguồn nước (Water source).
•	Thực thể tùy chỉnh (Custom entity).
Ví dụ:
Chiến dịch:
Thanh tra Trường học
Mục tiêu:
Trường học
Chiến dịch:
Tổng điều tra dân số
Mục tiêu:
Hộ gia đình
Chiến dịch:
Khảo sát Đường bộ
Mục tiêu:
Đoạn đường.
________________________________________
10. BẢN GHI THỰC THỂ GỐC (ENTITY MASTER RECORD)
Mỗi thực thể mục tiêu phải có một bản ghi gốc cố định lâu dài.
Ví dụ:
Mã Hộ gia đình (Household ID):
HH-000001
Mã Trường học (School ID):
SCH-000001
Mã Tuyến đường (Road ID):
ROAD-000001
Thực thể gốc có thể gắn với nhiều bản đệ trình dữ liệu qua nhiều chiến dịch/giai đoạn khác nhau.
Điều này giúp ngăn chặn tình trạng trùng lặp dữ liệu.
________________________________________
11. MÔ HÌNH HỘ GIA ĐÌNH
Đối với các chiến dịch dạng Tổng điều tra dân số, cần hỗ trợ cấu trúc:
Hộ gia đình (Household)
→ Các thành viên trong hộ gia đình (Household members)
→ Các bản ghi cá nhân từng người (Individual person records)
Hộ gia đình có thể bao gồm các thông tin:
•	Mã Hộ gia đình (Household ID).
•	Địa chỉ.
•	Phân cấp địa lý.
•	Số nhà.
•	Tọa độ GPS.
•	Trạng thái.
•	Nguồn dữ liệu.
•	Lịch sử qua các giai đoạn.
Cấu trúc cá nhân/nhân khẩu phải hỗ trợ số lượng người linh hoạt trong mỗi hộ.
________________________________________
12. DANH MỤC NHÂN SỰ GỐC (EMPLOYEE MASTER)
Tạo cơ sở dữ liệu nhân sự tập trung.
Các trường thông tin:
•	Mã Nhân viên (Employee ID).
•	Họ và tên.
•	Số điện thoại di động.
•	Chức danh (Designation).
•	Phòng ban (Department).
•	Cơ quan/Đơn vị (Office).
•	Địa điểm công tác (Posting location).
•	Huyện (District).
•	Phân khu (Subdivision).
•	Hạt/Phân huyện (Tehsil).
•	Khối/Cụm xã (Block).
•	Vai trò (Role).
•	Trạng thái làm việc (Employment status).
•	Tình trạng sẵn sàng (Availability).
•	Trạng thái dự bị (Reserve status).
•	Trạng thái tập huấn (Training status).
Mã Nhân viên phải là duy nhất.
Số điện thoại di động phải là duy nhất trong phạm vi áp dụng.
________________________________________
13. NHẬP DỮ LIỆU NHÂN SỰ HÀNG LOẠT
Hỗ trợ nhập hàng nghìn hồ sơ nhân sự cùng lúc.
Định dạng hỗ trợ:
•	Excel.
•	CSV.
Trước khi nhập:
•	Kiểm tra tính hợp lệ (Validate).
•	Phát hiện Mã Nhân viên bị trùng lặp.
•	Phát hiện số điện thoại di động bị trùng lặp.
•	Phát hiện các trường bị thiếu thông tin.
•	Phát hiện tên phòng ban không hợp lệ.
•	Hiển thị lỗi chi tiết tới từng dòng (row-level errors).
Cho phép tùy chọn:
Nhập Các Bản Ghi Hợp Lệ (Import Valid Records)
mà không làm mất các bản ghi hợp lệ chỉ vì một số dòng bị lỗi.
________________________________________
14. TÌNH TRẠNG SẴN SÀNG CỦA NHÂN SỰ
Trạng thái nhân sự:
•	Sẵn sàng (Available).
•	Đã phân công (Assigned).
•	Đang làm nhiệm vụ (On Duty).
•	Đang nghỉ phép (On Leave).
•	Không sẵn sàng (Unavailable).
•	Dự bị (Reserve).
•	Dự bị đã kích hoạt (Activated Reserve).
•	Đã giải phóng nhiệm vụ (Released).
•	Đình chỉ (Suspended).
Việc phân công vào chiến dịch phải kiểm tra tình trạng sẵn sàng của nhân sự.
Ngăn chặn việc phân công trùng lặp gây xung đột nhiệm vụ.
________________________________________
15. CHIẾN DỊCH LIÊN PHÒNG BAN
Một chiến dịch có thể bao gồm nhiều phòng ban.
Ví dụ:
Thanh tra Trường học:
•	Giáo dục (Education).
•	Sở Công chính (PWD).
•	Lương thực - Thực phẩm (Food).
•	Thuế/Doanh thu (Revenue).
Mỗi phòng ban có thể đảm nhận các trách nhiệm khác nhau.
________________________________________
16. ĐỘI LIÊN NGÀNH (JOINT TEAMS)
Tạo bộ máy quản lý đội nhóm.
Một đội có thể bao gồm các nhân sự đến từ nhiều phòng ban khác nhau.
Ví dụ:
Đội 001:
•	Nhân sự phòng Thuế/Doanh thu.
•	Nhân sự phòng Giáo dục.
•	Nhân sự Sở Công chính (PWD).
Mỗi đội có:
•	Mã Đội (Team ID).
•	Đội trưởng (Team leader).
•	Các thành viên (Members).
•	Phòng ban (Department).
•	Địa bàn phụ trách (Geographic responsibility).
•	Chiến dịch (Campaign).
•	Giai đoạn (Phase).
•	Trạng thái (Status).
________________________________________
17. THÀNH LẬP ĐỘI NHÓM
Cho phép hai phương thức:
Thủ công (Manual)
Quản trị viên trực tiếp chọn từng nhân sự.
Tự động (Automatic)
Hệ thống tự động tạo các đội dựa trên các quy tắc đã cấu hình.
Các quy tắc có thể bao gồm:
•	Quy mô đội.
•	Cơ cấu kết hợp các phòng ban.
•	Khu vực địa lý.
•	Chức danh.
•	Kỹ năng.
•	Tình trạng sẵn sàng.
•	Khối lượng công việc.
________________________________________
18. ĐỘI TRƯỞNG
Đội trưởng có thể:
•	Xem danh sách thành viên trong đội.
•	Xem các nhiệm vụ được phân công.
•	Theo dõi tiến độ thực hiện.
•	Rà soát công việc ở cấp độ đội nhóm khi được ủy quyền.
•	Báo cáo nhân sự vắng mặt.
•	Yêu cầu nhân sự thay thế.
•	Gửi báo cáo của đội.
Không tự động cấp quyền truy cập vào toàn bộ dữ liệu chỉ vì một người là đội trưởng.
Hệ thống phân quyền vẫn phải được áp dụng chặt chẽ.
________________________________________
19. HỆ THỐNG NHÂN SỰ DỰ BỊ
Mọi chiến dịch quy mô lớn đều phải hỗ trợ lực lượng nhân sự dự bị.
Nhân sự dự bị có thể thay thế nhân sự chính thức khi cần thiết.
Các lý do thay thế:
•	Nghỉ phép.
•	Ốm đau.
•	Thuyên chuyển công tác.
•	Trường hợp khẩn cấp.
•	Yêu cầu hành chính.
•	Các lý do được phê duyệt khác.
Quy trình xử lý (Workflow):
Nhân sự Chính thức (Active Employee)
→ Không sẵn sàng làm việc (Unavailable)
→ Giám sát viên báo cáo (Supervisor reports)
→ Cán bộ có thẩm quyền phê duyệt (Authorized officer approves)
→ Chọn nhân sự dự bị (Reserve employee selected)
→ Kích hoạt nhân sự dự bị (Reserve activated)
→ Chuyển giao nhiệm vụ được phân công (Assignment transferred)
→ Tạo bản ghi nhật ký kiểm toán (Audit record created).
________________________________________
20. ĐỘI DỰ BỊ
Hỗ trợ cả các đội dự bị bên cạnh các cá nhân dự bị.
Ví dụ:
Đội Chính thức:
Đội 001
Đội Dự bị:
Đội R001
Nếu toàn bộ một đội không thể thực hiện nhiệm vụ, đội dự bị có thể được kích hoạt để thay thế.
________________________________________
21. QUẢN LÝ KHỐI LƯỢNG CÔNG VIỆC
Trước khi phát động một giai đoạn chiến dịch, hệ thống phải hiển thị:
Tổng số thực thể mục tiêu.
Lực lượng nhân sự cần thiết.
Lực lượng nhân sự hiện có.
Lực lượng nhân sự dự bị.
Khối lượng công việc dự kiến trên mỗi nhân sự.
Khối lượng công việc dự kiến trên mỗi đội.
Ví dụ:
Mục tiêu:
1,000,000
Số đội:
10,000
Trung bình:
100 mục tiêu/đội.
Cho phép các quản trị viên có thẩm quyền điều chỉnh cách phân bổ.
________________________________________
22. CÂN BẰNG KHỐI LƯỢNG CÔNG VIỆC
Hỗ trợ các phương thức:
•	Phân bổ đồng đều (Equal distribution).
•	Phân bổ theo địa lý (Geographic distribution).
•	Phân bổ ngẫu nhiên (Random distribution).
•	Phân bổ thủ công (Manual distribution).
•	Phân bổ theo kỹ năng (Skill-based distribution).
•	Cân bằng tải công việc (Workload balancing).
Hệ thống phải phát hiện được các nhân sự/đội nhóm bị quá tải.
Ví dụ:
Nhân sự A:
300 nhiệm vụ
Nhân sự B:
80 nhiệm vụ
Hiển thị cảnh báo.
________________________________________
23. PHÂN CÔNG NGẪU NHIÊN
Hỗ trợ phân công ngẫu nhiên ở những nơi có yêu cầu.
Ví dụ:
10,000 trường học
1,000 cán bộ
Hệ thống phân công ngẫu nhiên các trường học cho các cán bộ.
Ngăn chặn việc phân công trùng lặp.
Cho phép quản trị viên xem trước kết quả phân công trước khi kích hoạt chính thức.
Lưu giữ lịch sử phân công.
________________________________________
24. PHÂN CÔNG THEO ĐỊA LÝ
Các nhiệm vụ có thể được phân công dựa trên:
•	Huyện (District).
•	Phân khu (Subdivision).
•	Hạt/Phân huyện (Tehsil).
•	Khối/Cụm xã (Block).
•	Làng/Xã (Village).
•	Phường (Ward).
•	Khu dân cư/Thôn xóm (Mohalla).
•	Ranh giới tọa độ GPS.
Hỗ trợ phân công địa lý dựa trên đa giác bản đồ (polygon) ở những nơi khả thi.
________________________________________
25. TRÌNH HƯỚNG DẪN TẠO CHIẾN DỊCH (CAMPAIGN CREATION WIZARD)
Tạo một trình hướng dẫn từng bước (multi-step wizard) chuyên nghiệp.
Bước 1
Thông tin chi tiết chiến dịch.
Bước 2
Loại chiến dịch.
Bước 3
Phạm vi địa lý.
Bước 4
Các phòng ban tham gia.
Bước 5
Lực lượng nhân sự.
Bước 6
Các đội nhóm.
Bước 7
Các thực thể mục tiêu.
Bước 8
Biểu mẫu thu thập dữ liệu.
Bước 9
Phân công nhiệm vụ.
Bước 10
Quy trình xác minh.
Bước 11
Quy tắc thanh toán.
Bước 12
Tài liệu hướng dẫn/văn bản.
Bước 13
Xem trước toàn bộ cấu hình.
Bước 14
Phát động chiến dịch (Launch).
________________________________________
26. KIỂM TRA TÍNH HỢP LỆ CỦA CHIẾN DỊCH TRƯỚC KHI PHÁT ĐỘNG
Trước khi phát động, hệ thống phải kiểm tra các lỗi:
•	Chưa có thực thể mục tiêu.
•	Chưa có đội nhóm.
•	Chưa có cán bộ thực hiện.
•	Thiếu biểu mẫu.
•	Thiếu các câu hỏi bắt buộc.
•	Thiếu phân công địa bàn.
•	Thiếu quy trình xác minh.
•	Thiếu cấu hình thanh toán ở những nơi bắt buộc.
•	Xung đột lịch trình nhân sự.
•	Phân công trùng lặp.
•	Không đủ lực lượng nhân sự.
•	Ngày tháng không hợp lệ.
Hiển thị rõ các cảnh báo (warnings) và lỗi (errors).
Không cho phép phát động chiến dịch khi còn thiếu các yêu cầu quan trọng.
________________________________________
27. TRÌNH TẠO BIỂU MẪU ĐỘNG (DYNAMIC FORM BUILDER)
Quản trị viên Cấp Huyện phải tạo được các biểu mẫu mà không cần viết mã (no-code).
Các loại câu hỏi hỗ trợ:
•	Văn bản ngắn (Short text).
•	Văn bản dài (Long text).
•	Số nguyên (Integer).
•	Số thập phân (Decimal).
•	Tỷ lệ phần trăm (Percentage).
•	Tiền tệ/số tiền (Currency/amount).
•	Ngày tháng (Date).
•	Ngày/giờ (Date/time).
•	Có/Không (Yes/No).
•	Nút chọn một (Radio).
•	Ô đánh dấu nhiều lựa chọn (Checkbox).
•	Danh sách thả xuống (Dropdown).
•	Chọn nhiều mục (Multi-select).
•	Hình ảnh (Image).
•	Nhiều hình ảnh (Multiple image).
•	Video.
•	Tệp đính kèm (File).
•	Tọa độ GPS.
•	Chữ ký điện tử (Signature).
•	Đánh giá mức điểm (Rating).
•	Bảng dữ liệu (Table).
•	Nhóm trường lặp lại (Repeating group).
•	Trường tự động tính toán (Calculated field).
________________________________________
28. CÁC PHẦN TRONG BIỂU MẪU (FORM SECTIONS)
Biểu mẫu có thể chứa nhiều phần (sections).
Ví dụ:
Thanh tra Trường học:
1.	Thông tin Trường học.
2.	Cơ sở Hạ tầng.
3.	Hạng mục Công chính (PWD).
4.	An toàn Thực phẩm & Bữa ăn.
5.	Chất lượng Giáo dục.
6.	Nhận xét Cuối cùng.
________________________________________
29. CÂU HỎI CÓ ĐIỀU KIỆN (CONDITIONAL QUESTIONS)
Hỗ trợ các quy tắc hiển thị theo điều kiện.
Ví dụ:
NẾU (IF):
Tòa nhà bị hư hại = CÓ (YES)
THÌ (THEN):
Hiển thị các trường:
•	Loại hư hại.
•	Mức độ nghiêm trọng của hư hại.
•	Ảnh chụp hiện trạng hư hại.
•	Ước tính chi phí sửa chữa.
Ngược lại thì ẩn các trường này đi.
Tạo một trình xây dựng điều kiện trực quan (visual condition builder).
________________________________________
30. NHÓM TRƯỜNG LẶP LẠI (REPEATING GROUPS)
Đối với Tổng điều tra dân số:
Hộ gia đình:
Số lượng thành viên = 6
Tự động tạo ra các mục nhập cho:
Người 1
Người 2
Người 3
Người 4
Người 5
Người 6.
Hỗ trợ dữ liệu lặp lại lồng nhau (nested repeating data) ở những nơi có yêu cầu.
________________________________________
31. KIỂM TRA TÍNH HỢP LỆ CỦA BIỂU MẪU (FORM VALIDATION)
Mỗi câu hỏi có thể thiết lập các ràng buộc:
•	Bắt buộc nhập (Required).
•	Giá trị tối thiểu (Minimum).
•	Giá trị tối đa (Maximum).
•	Độ dài ký tự (Length).
•	Biểu thức chính quy (Regex).
•	Các tùy chọn được phép chọn (Allowed options).
•	Sự phụ thuộc vào trường khác (Dependency).
•	Yêu cầu bằng chứng xác thực (Evidence requirement).
•	Yêu cầu tọa độ GPS (GPS requirement).
Quá trình kiểm tra tính hợp lệ phải diễn ra ở cả:
Giao diện người dùng (Frontend) + Máy chủ (Backend)
Không bao giờ chỉ tin tưởng vào bước kiểm tra ở phía giao diện người dùng (frontend).
________________________________________
32. QUẢN LÝ PHIÊN BẢN BIỂU MẪU (FORM VERSIONING)
Các biểu mẫu phải được quản lý theo phiên bản.
Ví dụ:
Biểu mẫu v1
Biểu mẫu v2
Các bản đệ trình dữ liệu trong lịch sử vẫn phải gắn liền với phiên bản biểu mẫu gốc tại thời điểm gửi.
Việc sửa đổi biểu mẫu không được làm biến đổi các bản đệ trình dữ liệu cũ.
________________________________________
33. BIỂU MẪU THEO GIAI ĐOẠN CHIẾN DỊCH
Mỗi giai đoạn có thể có biểu mẫu riêng của mình.
Ví dụ:
Chiến dịch:
Tổng điều tra dân số 2027
Giai đoạn 1:
Biểu mẫu A
Giai đoạn 2:
Biểu mẫu B
Giai đoạn 3:
Biểu mẫu C
________________________________________
34. ỨNG DỤNG DI ĐỘNG DÀNH CHO CÁN BỘ THỰC ĐỊA
Xây dựng ứng dụng web tiến bộ ưu tiên thiết bị di động (mobile-first PWA).
Bảng điều khiển của nhân sự thực địa:
Các Chiến dịch (Campaigns)
→ Giai đoạn Đang Hoạt động (Active Phase)
→ Địa bàn Được Phân công (Assigned Area)
→ Nhiệm vụ Được Phân công (Assigned Tasks)
→ Đã Hoàn thành (Completed)
→ Đang Chờ Xử lý (Pending)
→ Cần Chỉnh sửa (Corrections)
→ Bản Nháp (Drafts)
→ Đồng bộ Dữ liệu (Sync)
→ Thông báo (Notifications)
________________________________________
35. NHIỆM VỤ THỰC ĐỊA (FIELD TASK)
Mỗi nhiệm vụ bao gồm:
•	Mã Nhiệm vụ (Task ID).
•	Chiến dịch.
•	Giai đoạn.
•	Thực thể mục tiêu.
•	Vị trí địa lý.
•	Đội được phân công.
•	Nhân sự được phân công.
•	Thời hạn hoàn thành (Deadline).
•	Mức độ ưu tiên (Priority).
•	Trạng thái (Status).
•	Hướng dẫn thực hiện (Instructions).
________________________________________
36. TRẠNG THÁI NHIỆM VỤ
Sử dụng các trạng thái sau:
•	Chưa Bắt đầu (Not Started).
•	Đã Phân công (Assigned).
•	Đã Tiếp nhận (Accepted).
•	Đang Thực hiện (In Progress).
•	Bản Nháp (Draft).
•	Đã Gửi (Submitted).
•	Đang Xác minh (Under Verification).
•	Yêu cầu Chỉnh sửa (Correction Required).
•	Đã Gửi lại (Resubmitted).
•	Đã Phê duyệt (Approved).
•	Đã Từ chối (Rejected).
•	Đã Phân công lại (Reassigned).
•	Quá hạn (Overdue).
•	Đã Hoàn tất (Completed).
________________________________________
37. THU THẬP DỮ LIỆU THỰC ĐỊA
Cán bộ thực địa phải có thể:
•	Mở nhiệm vụ.
•	Bắt đầu làm nhiệm vụ.
•	Điền biểu mẫu.
•	Lưu bản nháp.
•	Tiếp tục làm sau.
•	Thu thập tọa độ GPS.
•	Chụp ảnh.
•	Tải lên video.
•	Thêm ghi chú/nhận xét.
•	Gửi dữ liệu (Submit).
________________________________________
38. ĐỊNH VỊ GPS
Khi được cấu hình yêu cầu GPS:
Thu thập:
•	Vĩ độ (Latitude).
•	Kinh độ (Longitude).
•	Độ chính xác (Accuracy).
•	Dấu thời gian (Timestamp).
Tùy chọn tính toán khoảng cách từ vị trí đứng thực tế đến vị trí của thực thể mục tiêu.
Có thể cấu hình hành vi xử lý khi lệch khoảng cách:
•	Hiển thị cảnh báo (Warning).
•	Chuyển cho giám sát viên xem xét (Supervisor review).
•	Chặn không cho gửi dữ liệu (Block submission).
________________________________________
39. HÌNH ẢNH
Hỗ trợ:
•	Chụp trực tiếp từ máy ảnh (Camera).
•	Chọn từ thư viện ảnh (Gallery).
•	Tải lên nhiều ảnh (Multiple images).
•	Nén dung lượng ảnh (Compression).
•	Xem trước ảnh (Preview).
•	Chụp lại (Retake).
Gắn kết hình ảnh với:
•	Chiến dịch.
•	Giai đoạn.
•	Nhiệm vụ.
•	Câu hỏi tương ứng.
•	Nhân sự thực hiện.
________________________________________
40. VIDEO
Hỗ trợ:
•	Quay video trực tiếp (Record).
•	Chọn tệp video có sẵn (Select).
•	Xem trước (Preview).
•	Tải lên (Upload).
•	Thanh tiến trình tải lên (Progress).
•	Thử tải lại khi lỗi (Retry).
•	Giới hạn dung lượng tối đa (Maximum size).
•	Giới hạn thời lượng tối đa (Maximum duration).
Sử dụng dịch vụ lưu trữ đối tượng (object storage).
Không lưu trữ các tệp video dung lượng lớn trực tiếp bên trong cơ sở dữ liệu PostgreSQL.
________________________________________
41. CHẾ ĐỘ NGOẠI TUYẾN (OFFLINE MODE)
Ứng dụng di động phải hoạt động tốt ngay cả trong điều kiện kết nối mạng kém.
Sử dụng:
•	PWA (Progressive Web App).
•	IndexedDB.
•	Lưu bản nháp cục bộ trên thiết bị (Local draft).
•	Danh sách nhiệm vụ ngoại tuyến (Offline task list).
•	Hàng đợi đồng bộ hóa (Sync queue).
Trạng thái kết nối và đồng bộ:
Trực tuyến (Online)
Ngoại tuyến (Offline)
Đang đồng bộ (Syncing)
Đã đồng bộ (Synced)
Đồng bộ thất bại (Failed).
________________________________________
42. QUẢN LÝ XUNG ĐỘT DỮ LIỆU NGOẠI TUYẾN
Nếu cùng một bản ghi bị thay đổi từ nhiều nguồn khác nhau:
Không được âm thầm ghi đè dữ liệu.
Hãy tạo bản ghi xung đột:
Xung đột cần được xem xét xử lý (Conflict requires review).
Lưu giữ toàn bộ lịch sử phiên bản.
________________________________________
43. GỬI DỮ LIỆU (SUBMISSION)
Trước khi gửi dữ liệu lần cuối:
Hiển thị trang rà soát lại thông tin.
Ví dụ:
Các trường bắt buộc:
✓
Tọa độ GPS:
✓
Hình ảnh bắt buộc:
✓
Kiểm tra tính hợp lệ:
✓
Sau đó nhấn:
Gửi (Submit)
Máy chủ trả về:
Mã Đệ trình (Submission ID).
Không bao giờ hiển thị thông báo gửi thành công trước khi nhận được xác nhận từ máy chủ.
________________________________________
44. BỘ MÁY XÁC MINH (VERIFICATION ENGINE)
Tạo quy trình xác minh có thể cấu hình linh hoạt.
Ví dụ:
Cán bộ Thực địa (Field Officer)
→ Giám sát viên (Supervisor)
→ Cán bộ Hạt/Phân huyện (Tehsil Officer)
→ Cán bộ Phân khu (Subdivision Officer)
→ Trưởng Phòng ban (Department Head)
→ Quản trị viên Cấp Huyện (District Admin)
Tuy nhiên các quản trị viên có thể cấu hình các cấp duyệt khác nhau tùy theo chiến dịch.
________________________________________
45. CÁC HÀNH ĐỘNG XÁC MINH
Người kiểm duyệt (Reviewer) có thể:
•	Phê duyệt (Approve).
•	Từ chối (Reject).
•	Yêu cầu chỉnh sửa (Request correction).
•	Thêm bình luận/nhận xét (Add comment).
•	Chuyển vượt cấp lên cấp trên (Escalate).
•	Phân công lại cho người khác (Reassign).
•	Xem lịch sử thay đổi (View history).
________________________________________
46. QUY TRÌNH YÊU CẦU CHỈNH SỬA
Ví dụ:
Người kiểm duyệt ghi:
"Vui lòng tải lên hình ảnh chụp rõ nét hơn."
Trạng thái chuyển thành:
Yêu cầu Chỉnh sửa (Correction Required).
Nhân sự thực địa nhận được thông báo.
Nhân sự chỉ được phép chỉnh sửa các trường được cho phép.
Gửi lại dữ liệu (Resubmits).
Người kiểm duyệt nhận được thông báo đã gửi lại.
________________________________________
47. QUẢN LÝ PHIÊN BẢN DỮ LIỆU (DATA VERSIONING)
Mọi lần đệ trình dữ liệu đều phải bảo toàn:
•	Phiên bản (Version).
•	Các câu trả lời (Answers).
•	Các tệp đính kèm (Files).
•	Tọa độ GPS.
•	Người thực hiện (User).
•	Dấu thời gian (Timestamp).
•	Chi tiết các thay đổi (Changes).
•	Lý do thay đổi (Reason).
Không bao giờ xóa bỏ hoặc làm mất các phiên bản lịch sử.
________________________________________
48. PHÊ DUYỆT CUỐI CÙNG (FINAL APPROVAL)
Chỉ những bản ghi đã được phê duyệt mới được đưa vào kết quả cuối cùng khi chiến dịch có yêu cầu bước phê duyệt cuối cùng.
Cho phép các báo cáo phân biệt rõ giữa các mức dữ liệu:
•	Sơ bộ (Preliminary).
•	Đã gửi (Submitted).
•	Đã xác minh (Verified).
•	Đã phê duyệt cuối cùng (Final Approved).
________________________________________
49. BỘ MÁY KIỂM SOÁT CHẤT LƯỢNG DỮ LIỆU (DATA QUALITY ENGINE)
Tạo các bài kiểm tra chất lượng dữ liệu tự động.
Ví dụ:
•	Trùng lặp hộ gia đình.
•	Trùng lặp nhiệm vụ.
•	Thiếu tọa độ GPS.
•	Giá trị phi thực tế/không thể xảy ra.
•	Tổng số liệu không khớp nhau.
•	Thiếu bằng chứng bắt buộc.
•	Dữ liệu giữa các giai đoạn mâu thuẫn nhau.
•	Tốc độ hoàn thành biểu mẫu nhanh bất thường.
•	Tọa độ GPS trùng hệt nhau lặp đi lặp lại một cách đáng ngờ.
•	Số lượng bản gửi lên quá nhiều trong một khoảng thời gian ngắn.
Gắn cờ các điểm bất thường để cán bộ quản lý xem xét.
Không tự động quy chụp nhân sự có hành vi sai phạm.
Đánh dấu là:
Ngoại lệ Chất lượng Dữ liệu (Data Quality Exception)
________________________________________
50. QUẢN LÝ NGOẠI LỆ (EXCEPTION MANAGEMENT)
Tạo một Trung tâm Quản lý Ngoại lệ (Exception Center) tập trung.
Ví dụ các ngoại lệ:
•	Thiếu hộ gia đình.
•	Trùng lặp hộ gia đình.
•	Sự cố tọa độ GPS.
•	Biểu mẫu chưa hoàn chỉnh.
•	Dữ liệu mâu thuẫn.
•	Nhiệm vụ quá hạn.
•	Nhân sự không thể làm việc.
•	Đội nhóm không thể làm việc.
•	Lỗi thanh toán.
•	Lỗi đồng bộ hóa dữ liệu.
Quản trị viên có thể phân công người xử lý từng ngoại lệ.
________________________________________
51. VÍ DỤ CHIẾN DỊCH TỔNG ĐIỀU TRA DÂN SỐ 2027 (CENSUS 2027)
Tạo chiến dịch Tổng điều tra dân số 2027 làm một chiến dịch mẫu.
Không tự bịa ra các câu hỏi Tổng điều tra dân số chính thức.
Hãy sử dụng các biểu mẫu giữ chỗ (placeholder)/có thể cấu hình hoặc các biểu mẫu được cung cấp chính thức.
Cấu trúc ví dụ:
Tổng điều tra dân số 2027 (Census 2027)
→ Giai đoạn 1: Lập danh sách Nhà ở (House Listing)
→ Giai đoạn 2: Điều tra Nhân khẩu (Enumeration)
→ Giai đoạn 3: Xác minh (Verification)
→ Giai đoạn 4: Chỉnh sửa (Correction)
Mỗi giai đoạn có các biểu mẫu khác nhau và có thể sử dụng lực lượng nhân sự khác nhau.
________________________________________
52. CẤU TRÚC ĐỊA LÝ TRONG TỔNG ĐIỀU TRA DÂN SỐ
Hỗ trợ cấu trúc:
Huyện (District)
→ Phân khu (Subdivision)
→ Hạt/Phân huyện (Tehsil)
→ Đô thị / Thành phố trực thuộc (Municipality / Nagar Palika)
→ Phường (Ward)
→ Làng/Xã (Village)
→ Khu dân cư/Thôn xóm (Mohalla)
→ Hộ gia đình (Household)
Hệ thống phân cấp thực tế phải có thể cấu hình được.
________________________________________
53. ĐỘI LIÊN NGÀNH TRONG TỔNG ĐIỀU TRA DÂN SỐ
Ví dụ:
Đội 001
Địa bàn:
Phường 10 / Khu dân cư A (Mohalla A)
Thành viên:
•	Nhân sự Phòng Giáo dục.
•	Nhân sự Phòng Thuế/Doanh thu.
•	Nhân sự Đô thị/Thành phố.
Đội sẽ đến thăm từng hộ gia đình nằm trong phạm vi địa bàn được phân công.
________________________________________
54. LUỒNG ĐIỀU TRA HỘ GIA ĐÌNH
Đội mở hồ sơ:
Hộ gia đình HH-000123
Hệ thống hiển thị:
•	Vị trí định vị.
•	Địa chỉ.
•	Thông tin từ giai đoạn trước nếu được cấp quyền xem.
•	Biểu mẫu của giai đoạn hiện tại.
Đội thu thập các thông tin bắt buộc.
Gửi dữ liệu lên hệ thống.
Kết quả sẽ đi qua quy trình xác minh đã được cấu hình.
________________________________________
55. KHỐI LƯỢNG CÔNG VIỆC ĐA GIAI ĐOẠN TRONG TỔNG ĐIỀU TRA DÂN SỐ
Hỗ trợ phân bổ công việc qua nhiều giai đoạn để giảm tải khối lượng công việc cho nhân sự.
Ví dụ:
Giai đoạn 1:
Nhóm Nhân sự A
Giai đoạn 2:
Nhóm Nhân sự B
Giai đoạn 3:
Nhóm Nhân sự C
Hoặc cùng một nhóm nhân sự có thể tham gia vào nhiều giai đoạn khác nhau.
Hệ thống phải hỗ trợ cả hai phương án.
________________________________________
56. BỘ MÁY TÍNH TOÁN THANH TOÁN / THÙ LAO (PAYMENT/HONORARIUM ENGINE)
Tạo một phân hệ thanh toán chuyên biệt.
QUAN TRỌNG:
Không bao giờ gắn cứng (hard-code) mức tiền thanh toán của chính quyền vào mã nguồn.
Số tiền thanh toán phải được lấy từ các quy tắc cấu hình được phê duyệt dựa trên quyết định/hướng dẫn hiện hành của chính quyền.
________________________________________
57. QUY TẮC THANH TOÁN
Các trường thông tin của quy tắc thanh toán:
•	Chiến dịch.
•	Giai đoạn.
•	Vai trò đảm nhận.
•	Phòng ban (nếu áp dụng).
•	Loại nhiệm vụ công tác (Duty type).
•	Phương thức tính toán.
•	Số tiền/đơn giá (Amount/rate).
•	Ngày có hiệu lực.
•	Số hiệu văn bản/quyết định của chính quyền (Government order reference).
•	Phiên bản quy tắc.
•	Trạng thái phê duyệt.
________________________________________
58. TÍNH TOÁN KHOẢN THANH TOÁN
Các mô hình tính toán có thể hỗ trợ:
•	Số tiền cố định trọn gói (Fixed amount).
•	Tính theo ngày công (Per day).
•	Tính theo từng nhiệm vụ (Per task).
•	Tính theo mỗi hộ gia đình được phê duyệt (Per approved household).
•	Tính theo vai trò (Role-based).
•	Tính theo giai đoạn (Phase-based).
•	Tính theo thành phần công việc (Component-based).
Không tự mặc định rằng các mô hình này đều được áp dụng về mặt pháp lý.
Quản trị viên sẽ là người cấu hình phương thức tính toán được phép sử dụng theo đúng quy định chính thức.
________________________________________
59. ĐIỀU KIỆN ĐỦ ĐỂ ĐƯỢC THANH TOÁN (PAYMENT ELIGIBILITY)
Ví dụ quy trình xét duyệt:
Được phân công nhiệm vụ (Assignment)
↓
Hoàn thành đợt công tác (Duty completed)
↓
Hoàn thành khối lượng công việc bắt buộc (Required work completed)
↓
Dữ liệu gửi lên được chấp nhận/phê duyệt (Submission accepted/approved)
↓
Phát sinh trạng thái đủ điều kiện thanh toán (Eligibility generated)
↓
Phê duyệt khoản thanh toán (Payment approval)
↓
Xử lý giải ngân thanh toán (Payment processing)
↓
Đã thanh toán (Paid)
Các quy tắc xét duyệt chính xác phải có thể cấu hình được.
________________________________________
60. BẢNG ĐIỀU KHIỂN THANH TOÁN CỦA NHÂN SỰ
Nhân sự nhìn thấy các thông tin:
Chiến dịch:
Tổng điều tra dân số 2027
Giai đoạn:
Giai đoạn 1
Nhiệm vụ công tác:
Đã hoàn thành
Điều kiện nhận thù lao:
Đủ điều kiện (Eligible)
Khoản thanh toán:
₹XXXX
Trạng thái:
Đang chờ duyệt / Đã phê duyệt / Đang xử lý / Đã thanh toán.
Thông tin tài chính nhạy cảm phải được bảo mật chặt chẽ.
________________________________________
61. TRẠNG THÁI THANH TOÁN
Các trạng thái bao gồm:
•	Chưa Đủ Điều kiện (Not Eligible).
•	Đang Chờ Xét Điều kiện (Pending Eligibility).
•	Đủ Điều kiện (Eligible).
•	Đang Chờ Phê duyệt (Pending Approval).
•	Đã Phê duyệt (Approved).
•	Đang Xử lý (Processing).
•	Đã Thanh toán (Paid).
•	Thanh toán Thất bại (Failed).
•	Bị Hoàn trả (Returned).
•	Tạm Giữ (On Hold).
•	Đang Khiếu nại/Tranh chấp (Disputed).
________________________________________
62. NHẮC NHỞ THANH TOÁN
Nếu khoản thanh toán vẫn đang chờ xử lý:
Gửi thông báo qua:
•	Thông báo trong ứng dụng (In-app notification).
•	Tin nhắn SMS (nếu được cấu hình).
•	Email (nếu được cấu hình).
Ví dụ nội dung:
Khoản thanh toán thù lao công tác chiến dịch đã được phê duyệt của bạn hiện vẫn đang chờ xử lý giải ngân.
Không được đưa ra các tuyên bố chưa được xác minh về thời điểm tiền về tài khoản.
________________________________________
63. XỬ LÝ NGOẠI LỆ THANH TOÁN
Hỗ trợ quản lý:
•	Các giao dịch thanh toán thất bại.
•	Hồ sơ thông tin không chính xác.
•	Thiếu phê duyệt.
•	Ngăn chặn thanh toán trùng lặp.
•	Tạm dừng thanh toán (Hold).
•	Thử thanh toán lại (Retry).
•	Giải quyết dứt điểm ngoại lệ (Resolution).
Lưu giữ đầy đủ nhật ký kiểm toán (audit trail).
________________________________________
64. NGĂN CHẶN THANH TOÁN TRÙNG LẶP
Ngăn chặn việc chi trả trùng lặp cho cùng tổ hợp:
Nhân sự + Chiến dịch + Giai đoạn + Nhiệm vụ công tác (Employee + Campaign + Phase + Duty)
trừ khi được cho phép rõ ràng bởi một quy trình điều chỉnh bổ sung có thẩm quyền phê duyệt.
________________________________________
65. CHẤM CÔNG / BẰNG CHỨNG THỰC HIỆN NHIỆM VỤ
Ở những nơi quy định chiến dịch có yêu cầu, hãy hỗ trợ chức năng chấm công thực hiện nhiệm vụ.
Các phương thức có thể áp dụng:
•	Báo cáo bắt đầu ca công tác (Start duty).
•	Báo cáo kết thúc ca công tác (End duty).
•	Định vị GPS.
•	Đội trưởng xác nhận.
•	Giám sát viên phê duyệt.
•	Hoàn thành số lượng nhiệm vụ.
Không mặc định rằng việc có chấm công đồng nghĩa với việc đủ điều kiện nhận thanh toán.
Hãy thiết kế để quy tắc này có thể cấu hình được.
________________________________________
66. TẬP HUẤN NGHIỆP VỤ (TRAINING)
Theo dõi:
•	Lớp tập huấn được phân công.
•	Trạng thái hoàn thành tập huấn.
•	Ngày tham gia tập huấn.
•	Tài liệu tập huấn.
•	Bài kiểm tra đánh giá (Assessment).
•	Chứng nhận hoàn thành (Certification).
Một giai đoạn chiến dịch có thể tùy chọn yêu cầu nhân sự phải hoàn thành tập huấn trước khi được phân công nhiệm vụ.
________________________________________
67. TÀI LIỆU HƯỚNG DẪN / VĂN BẢN CHỈ ĐẠO
Quản trị viên chiến dịch có thể tải lên:
•	Các quyết định/chỉ thị của chính quyền (Government orders).
•	Tài liệu hướng dẫn (Guidelines).
•	Quy trình vận hành tiêu chuẩn (SOPs).
•	Tài liệu đào tạo, tập huấn.
•	Thông tư/Công văn (Circulars).
•	Các biểu mẫu mẫu.
•	Quyết định chi trả thù lao (Payment orders).
Các tài liệu phải được quản lý theo phiên bản (versioned).
________________________________________
68. BỘ MÁY THÔNG BÁO (NOTIFICATION ENGINE)
Hỗ trợ gửi thông báo qua:
•	Trong ứng dụng (In-app).
•	Tin nhắn SMS.
•	Thư điện tử (Email).
•	Thông báo đẩy (Push notifications).
Các loại thông báo:
•	Nhiệm vụ mới.
•	Chiến dịch mới.
•	Giai đoạn bắt đầu.
•	Hạn chót (Deadline).
•	Quá hạn.
•	Yêu cầu chỉnh sửa.
•	Phê duyệt.
•	Phân công lại.
•	Kích hoạt nhân sự dự bị.
•	Cập nhật thanh toán.
________________________________________
69. CÔNG CỤ CHUYỂN CẤP XỬ LÝ (ESCALATION ENGINE)
Tạo cơ chế chuyển cấp xử lý có thể cấu hình.
Ví dụ:
Nhiệm vụ quá hạn 2 ngày:
→ Thông báo cho Giám sát viên (Supervisor).
Quá hạn 4 ngày:
→ Cán bộ Tehsil (Tehsil Officer).
Quá hạn 7 ngày:
→ Quản trị viên Cấp huyện (District Admin).
Lịch trình chuyển cấp xử lý phải có thể cấu hình được.
________________________________________
70. CÔNG CỤ NHẮC NHỞ (REMINDER ENGINE)
Hỗ trợ các lời nhắc theo lịch trình.
Ví dụ:
7 ngày trước hạn chót.
3 ngày trước hạn.
1 ngày trước hạn.
Ngày đến hạn.
Quá hạn.
Thanh toán đang chờ xử lý trong X ngày.
________________________________________
71. BẢNG ĐIỀU KHIỂN CHỈ HUY CẤP HUYỆN (DISTRICT COMMAND DASHBOARD)
Tạo một trung tâm chỉ huy chuyên nghiệp.
Hiển thị:
Chiến dịch (Campaigns)
Tổng số.
Đang hoạt động.
Đã hoàn thành.
Bị trễ tiến độ.
Lực lượng lao động (Workforce)
Tổng số.
Đã phân công.
Sẵn sàng.
Dự bị.
Không sẵn sàng.
Nhiệm vụ (Tasks)
Tổng số.
Đã hoàn thành.
Đang chờ xử lý.
Quá hạn.
Cần chỉnh sửa.
Xác minh (Verification)
Đã gửi.
Đang xem xét.
Đã phê duyệt.
Bị từ chối.
Thanh toán (Payment)
Đủ điều kiện.
Đã phê duyệt.
Đã thanh toán.
Đang chờ xử lý.
Thất bại.
________________________________________
72. KHOAN SÂU THEO ĐỊA LÝ (GEOGRAPHIC DRILL-DOWN)
Bảng điều khiển:
Huyện (District)
↓
Phân khu (Subdivision)
↓
Tehsil
↓
Làng/Phường (Village/Ward)
↓
Khu phố (Mohalla)
↓
Hộ gia đình (Household)
Ở mọi cấp độ:
•	Tổng số.
•	Đã phân công.
•	Đã hoàn thành.
•	Đang chờ xử lý.
•	Đã xác minh.
•	Ngoại lệ.
________________________________________
73. BẢN ĐỒ (MAP)
Cung cấp bản đồ tương tác.
Hiển thị:
•	Các khu vực được phân công.
•	Các mục tiêu đã hoàn thành.
•	Các mục tiêu đang chờ xử lý.
•	Các trường hợp ngoại lệ.
•	Các bản gửi có tọa độ GPS ở những nơi được cấp phép.
Sử dụng kỹ thuật gom cụm (clustering) cho các tập dữ liệu lớn.
Không cố gắng kết xuất (render) hàng triệu điểm cùng một lúc.
________________________________________
74. BẢNG ĐIỀU KHIỂN PHÒNG BAN (DEPARTMENT DASHBOARD)
Trưởng Phòng ban (Department Head) nhìn thấy:
•	Sự tham gia vào chiến dịch.
•	Nhân viên.
•	Các nhóm (Teams).
•	Khối lượng công việc.
•	Mức độ hoàn thành.
•	Xác minh.
•	Ngoại lệ.
•	Thanh toán.
Chỉ hiển thị dữ liệu phòng ban được cấp phép.
________________________________________
75. BẢNG ĐIỀU KHIỂN PHÂN KHU / TEHSIL (SUBDIVISION / TEHSIL DASHBOARD)
Hiển thị tiến độ tại địa phương.
Ví dụ:
Tehsil A:
Mục tiêu: 100,000
Đã hoàn thành: 92,000
Đang chờ xử lý: 8,000
Tỷ lệ hoàn thành:
92%
________________________________________
76. BẢNG ĐIỀU KHIỂN NHÓM (TEAM DASHBOARD)
Trưởng nhóm (Team Leader) nhìn thấy:
•	Các thành viên.
•	Các mục tiêu được phân công.
•	Đã hoàn thành.
•	Đang chờ xử lý.
•	Các yêu cầu chỉnh sửa.
•	Quá hạn.
•	Trạng thái đồng bộ hóa.
________________________________________
77. BẢNG ĐIỀU KHIỂN NHÂN VIÊN (EMPLOYEE DASHBOARD)
Nhân viên nhìn thấy:
•	Chiến dịch của tôi.
•	Giai đoạn của tôi.
•	Nhiệm vụ của tôi.
•	Tiến độ của tôi.
•	Các yêu cầu chỉnh sửa.
•	Thông báo.
•	Thanh toán.
•	Tài liệu hướng dẫn.
________________________________________
78. CÔNG CỤ BÁO CÁO (REPORTING ENGINE)
Tạo các báo cáo có thể cấu hình.
Các loại báo cáo:
•	Chiến dịch.
•	Giai đoạn.
•	Phòng ban.
•	Nhân viên.
•	Nhóm.
•	Địa lý.
•	Thực thể mục tiêu.
•	Xác minh.
•	Ngoại lệ.
•	Thanh toán.
•	Lực lượng lao động.
•	Năng suất.
________________________________________
79. BỘ LỌC BÁO CÁO (REPORT FILTERS)
Các bộ lọc:
•	Chiến dịch.
•	Giai đoạn.
•	Ngày tháng.
•	Phòng ban.
•	Nhân viên.
•	Nhóm.
•	Huyện (District).
•	Phân khu (Subdivision).
•	Tehsil.
•	Làng (Village).
•	Phường (Ward).
•	Khu phố (Mohalla).
•	Trạng thái.
________________________________________
80. XUẤT DỮ LIỆU (EXPORT)
Hỗ trợ:
•	Excel.
•	CSV.
•	PDF.
Các báo cáo dung lượng lớn phải được tạo bất đồng bộ (asynchronously).
________________________________________
81. LẬP LỊCH BÁO CÁO (REPORT SCHEDULING)
Cho phép người dùng được cấp phép lập lịch xuất báo cáo.
Ví dụ:
Mỗi ngày vào lúc 6 giờ chiều:
Báo cáo Tiến độ Chiến dịch Cấp huyện
Gửi đến những người dùng được cấp phép.
________________________________________
82. KIỂM SOÁT TRUY CẬP DỮ LIỆU (DATA ACCESS CONTROL)
Sử dụng:
RBAC + Phạm vi Địa lý + Phạm vi Phòng ban + Phạm vi Chiến dịch
Ví dụ:
Cán bộ Thực địa (Field Officer):
Chỉ các nhiệm vụ được phân công.
Cán bộ Tehsil (Tehsil Officer):
Tehsil được cấp phép.
Trưởng Phòng ban (Department Head):
Phòng ban được cấp phép.
Quản trị viên Cấp huyện (District Admin):
Toàn huyện.
Không bao giờ chỉ dựa vào các giới hạn ở phía giao diện người dùng (frontend).
________________________________________
83. QUẢN TRỊ VIÊN CẤP CAO (SUPER ADMIN)
Super Admin quản lý:
•	Các huyện.
•	Các phòng ban.
•	Người dùng.
•	Vai trò.
•	Quyền hạn.
•	Cài đặt hệ thống.
•	Dữ liệu gốc (Master data).
•	Các tích hợp hệ thống.
________________________________________
84. QUẢN TRỊ VIÊN CẤP HUYỆN (DISTRICT ADMIN)
District Admin có thể:
•	Tạo chiến dịch.
•	Tạo giai đoạn.
•	Tạo biểu mẫu.
•	Chọn phòng ban.
•	Quản lý lực lượng lao động.
•	Tạo nhóm.
•	Phân công khu vực.
•	Phân công nhiệm vụ.
•	Cấu hình quy trình xác minh.
•	Cấu hình quy tắc thanh toán ở những nơi được cấp phép.
•	Giám sát tiến độ.
•	Phê duyệt/xem xét dữ liệu.
•	Tạo báo cáo.
________________________________________
85. TRƯỞNG PHÒNG BAN (DEPARTMENT HEAD)
Có thể:
•	Xem các chiến dịch của phòng ban.
•	Quản lý lực lượng lao động của phòng ban.
•	Xem xét các bản gửi.
•	Xác minh dữ liệu.
•	Giám sát hiệu suất của phòng ban.
•	Tạo các báo cáo được cấp phép.
________________________________________
86. CÁN BỘ THỰC ĐỊA (FIELD OFFICER)
Có thể:
•	Đăng nhập.
•	Xem nhiệm vụ được giao.
•	Thu thập dữ liệu thực địa.
•	Thu thập tọa độ GPS.
•	Chụp ảnh/quay video (media).
•	Lưu bản nháp.
•	Gửi dữ liệu.
•	Chỉnh sửa.
•	Gửi lại.
•	Xem trạng thái thanh toán.
•	Xem tài liệu hướng dẫn.
________________________________________
87. CÁN BỘ THANH TOÁN (PAYMENT OFFICER)
Có thể:
•	Xem xét tính đủ điều kiện.
•	Phê duyệt thanh toán.
•	Xử lý thanh toán.
•	Xem các giao dịch thất bại.
•	Thử lại các khoản thanh toán được cấp phép.
•	Tạo báo cáo thanh toán.
Không cấp cho cán bộ thanh toán quyền truy cập không cần thiết vào dữ liệu hộ gia đình.
________________________________________
88. BẢO MẬT HỆ THỐNG (SYSTEM SECURITY)
Triển khai:
•	Băm mật khẩu (Password hashing).
•	Xác thực an toàn.
•	OTP.
•	Bảo mật phiên đăng nhập (Session security).
•	Kiến trúc JWT hoặc phiên bảo mật.
•	Xoay vòng refresh token (Refresh token rotation) khi có áp dụng.
•	Giới hạn tần suất (Rate limiting).
•	Phân quyền API.
•	Xác thực dữ liệu đầu vào (Input validation).
•	Xác thực tệp tải lên (File validation).
•	Các header bảo mật (Secure headers).
•	CORS.
•	Chống tấn công CSRF khi có áp dụng.
•	Chống tấn công SQL injection.
•	Chống tấn công XSS.
•	Nhật ký kiểm toán (Audit logs).
________________________________________
89. QUYỀN RIÊNG TƯ DỮ LIỆU (DATA PRIVACY)
Chỉ thu thập những thông tin được yêu cầu chính thức.
Thông tin nhạy cảm phải có:
•	Kiểm soát truy cập nghiêm ngặt.
•	Mã hóa khi phù hợp.
•	Nhật ký kiểm toán (Audit logs).
•	Quy tắc lưu giữ dữ liệu (Retention rules).
•	Hạn chế xuất dữ liệu.
Không hiển thị thông tin nhạy cảm của hộ gia đình/cá nhân trên các bảng điều khiển công khai.
________________________________________
90. NHẬT KÝ KIỂM TOÁN (AUDIT LOG)
Ghi lại mọi thao tác quan trọng.
Ví dụ:
•	Đăng nhập.
•	OTP.
•	Tạo chiến dịch.
•	Tạo giai đoạn.
•	Thay đổi biểu mẫu.
•	Phân công nhân viên.
•	Tạo nhóm.
•	Phân công hộ gia đình.
•	Gửi dữ liệu (Submission).
•	Chỉnh sửa.
•	Phê duyệt.
•	Phân công lại.
•	Kích hoạt nhân sự dự bị.
•	Tính toán thanh toán.
•	Phê duyệt thanh toán.
•	Xử lý thanh toán.
•	Xuất dữ liệu.
Nhật ký kiểm toán phải là bất biến (immutable) đối với người dùng thông thường.
________________________________________
91. GHI NHẬT KÝ HỆ THỐNG (SYSTEM LOGGING)
Sử dụng nhật ký ứng dụng có cấu trúc (structured application logs).
Tách biệt:
•	Nhật ký ứng dụng (Application logs).
•	Nhật ký bảo mật (Security logs).
•	Nhật ký kiểm toán (Audit logs).
•	Nhật ký lỗi (Error logs).
Không làm lộ các lỗi nội bộ cho người dùng thấy.
________________________________________
92. CƠ SỞ DỮ LIỆU (DATABASE)
Sử dụng:
PostgreSQL
ORM:
Prisma
Thiết kế lược đồ chuẩn hóa (normalized schema).
Các thực thể (entities) quan trọng:
•	State.
•	District.
•	Department.
•	OrganizationNode.
•	GeographicNode.
•	User.
•	Employee.
•	Role.
•	Permission.
•	Campaign.
•	CampaignPhase.
•	CampaignDepartment.
•	CampaignGeography.
•	TargetEntity.
•	Household.
•	Person.
•	Team.
•	TeamMember.
•	ReserveEmployee.
•	Task.
•	TaskAssignment.
•	Form.
•	FormVersion.
•	FormSection.
•	FormQuestion.
•	FormOption.
•	FormCondition.
•	Submission.
•	SubmissionVersion.
•	SubmissionAnswer.
•	SubmissionFile.
•	GPSRecord.
•	Verification.
•	CorrectionRequest.
•	Exception.
•	PaymentRule.
•	PaymentRuleVersion.
•	EmployeePayment.
•	PaymentComponent.
•	PaymentTransaction.
•	Notification.
•	GuidelineDocument.
•	Training.
•	AuditLog.
•	Report.
•	ReportJob.
Sử dụng hợp lý:
•	Khóa ngoại (Foreign keys).
•	Ràng buộc duy nhất (Unique constraints).
•	Chỉ mục (Indexes).
•	Xóa mềm (Soft deletion) khi phù hợp.
•	Dấu thời gian (Timestamps).
________________________________________
93. LƯU GIỮ DỮ LIỆU (DATA RETENTION)
Xây dựng các chính sách lưu giữ dữ liệu có thể cấu hình.
Các bản ghi khác nhau có thể có yêu cầu thời hạn lưu giữ khác nhau.
Không tự động xóa các hồ sơ chính thức nếu không có chính sách lưu giữ được phê duyệt.
________________________________________
94. SAO LƯU (BACKUP)
Thiết kế:
•	Sao lưu cơ sở dữ liệu tự động.
•	Khôi phục tại một thời điểm (Point-in-time recovery) ở nơi được hỗ trợ.
•	Sao lưu kho lưu trữ đối tượng (Object storage backup).
•	Giám sát sao lưu.
•	Kiểm thử phục hồi (Restore testing).
________________________________________
95. KHÔI PHỤC SAU THẢM HỌA (DISASTER RECOVERY)
Lập tài liệu:
•	Quy trình khôi phục.
•	Phục hồi bản sao lưu.
•	Khôi phục cơ sở dữ liệu.
•	Khôi phục tệp tin.
•	Khôi phục hàng đợi (Queue recovery).
•	Các kịch bản thảm họa.
________________________________________
96. KHẢ NĂNG MỞ RỘNG (SCALABILITY)
Thiết kế để đáp ứng:
•	Hơn 50,000 nhân viên.
•	Hàng triệu mục tiêu.
•	Hàng triệu bản gửi (submissions).
•	Tải lên các tệp dung lượng lớn.
•	Hàng ngàn người dùng di động đồng thời.
Sử dụng:
•	Phân trang (Pagination).
•	Phân trang theo con trỏ (Cursor pagination) ở những nơi phù hợp.
•	Chỉ mục cơ sở dữ liệu (Database indexes).
•	Redis.
•	Các tiến trình xử lý hàng đợi (Queue workers).
•	Kho lưu trữ đối tượng (Object storage).
•	Tác vụ chạy nền (Background jobs).
•	Mở rộng theo chiều ngang (Horizontal scaling).
•	Gom nhóm kết nối cơ sở dữ liệu (Database connection pooling).
________________________________________
97. HỆ THỐNG TÁC VỤ CHẠY NỀN (BACKGROUND JOB SYSTEM)
Sử dụng:
Redis + BullMQ hoặc tương đương.
Các tác vụ:
•	Tạo báo cáo.
•	Xuất tệp Excel.
•	Tạo tệp PDF.
•	Thông báo.
•	SMS.
•	Email.
•	Xử lý hình ảnh.
•	Xử lý video.
•	Tích hợp xử lý thanh toán.
•	Các tác vụ nhắc nhở.
•	Chuyển cấp xử lý (Escalation).
•	Tổng hợp dữ liệu.
________________________________________
98. LƯU TRỮ TỆP TIN (FILE STORAGE)
Sử dụng:
•	Kho lưu trữ tương thích S3 (S3-compatible storage).
Chỉ lưu trữ siêu dữ liệu (metadata) trong PostgreSQL.
Siêu dữ liệu bao gồm:
•	ID tệp (File ID).
•	Tên.
•	Loại.
•	Kích thước.
•	Đường dẫn lưu trữ.
•	Người dùng tải lên.
•	Chiến dịch.
•	Giai đoạn.
•	Nhiệm vụ.
•	Câu hỏi.
•	Dấu thời gian (Timestamp).
Sử dụng các URL có chữ ký (signed URLs) cho các tệp riêng tư.
________________________________________
99. HIỆU NĂNG TRÊN DI ĐỘNG (MOBILE PERFORMANCE)
Tối ưu hóa cho:
•	Các thiết bị Android cấu hình thấp.
•	Mạng chậm.
•	Dung lượng lưu trữ hạn chế.
•	Kết nối mạng chập chờn.
Tránh các hiệu ứng chuyển động (animations) không cần thiết.
Giữ cho các biểu mẫu gọn nhẹ.
Nén hình ảnh.
Sử dụng cơ chế tải lên có thể tiếp tục lại (resumable uploads) ở những nơi khả thi.
________________________________________
100. KHẢ NĂNG TIẾP CẬN (ACCESSIBILITY)
Hỗ trợ:
•	Độ tương phản cao.
•	Vùng chạm (touch targets) lớn.
•	Điều hướng bằng bàn phím.
•	Trình đọc màn hình (Screen readers).
•	Nhãn (labels) đầy đủ, đúng chuẩn.
•	Thông báo xác thực dữ liệu dễ tiếp cận.
________________________________________
101. GIAO DIỆN NGƯỜI DÙNG (USER INTERFACE)
Máy tính để bàn cho Quản trị viên (Admin desktop):
Thanh bên (Sidebar)
→ Bảng điều khiển (Dashboard)
→ Chiến dịch (Campaigns)
→ Giai đoạn (Phases)
→ Lực lượng lao động (Workforce)
→ Nhóm (Teams)
→ Địa lý (Geography)
→ Mục tiêu (Targets)
→ Biểu mẫu (Forms)
→ Nhiệm vụ (Tasks)
→ Xác minh (Verification)
→ Thanh toán (Payments)
→ Báo cáo (Reports)
→ Bản đồ (Maps)
→ Thông báo (Notifications)
→ Nhật ký kiểm toán (Audit Logs)
→ Cài đặt (Settings)
Thiết bị di động cho Cán bộ thực địa (Field mobile):
Trang chủ (Home)
Chiến dịch của tôi (My Campaigns)
Nhiệm vụ của tôi (My Tasks)
Yêu cầu chỉnh sửa (Corrections)
Thông báo (Notifications)
Thanh toán (Payment)
Tài liệu hướng dẫn (Guidelines)
Hồ sơ (Profile)
________________________________________
102. PHONG CÁCH THIẾT KẾ (DESIGN STYLE)
Sử dụng thiết kế hành chính nhà nước chuyên nghiệp.
Màu chính:
Xanh hải quân / xanh dương (Navy/blue).
Màu phụ:
Trắng / xám (White/gray).
Sử dụng:
•	Bảng dữ liệu (Tables).
•	Thẻ thông tin (Cards).
•	Huy hiệu trạng thái (Status badges).
•	Biểu đồ (Charts).
•	Bản đồ (Maps).
•	Thanh tiến độ (Progress bars).
Tránh giao diện trang trí rườm rà quá mức.
Ưu tiên tính dễ sử dụng (usability).
________________________________________
103. THAO TÁC HÀNG LOẠT (BULK OPERATIONS)
Quản trị viên phải có thể:
•	Nhập (Import) danh sách nhân viên.
•	Nhập dữ liệu địa lý.
•	Nhập các thực thể mục tiêu.
•	Phân công nhóm hàng loạt.
•	Phân công lại nhiệm vụ hàng loạt.
•	Kích hoạt nhân sự dự bị hàng loạt.
•	Tạo báo cáo hàng loạt.
Luôn hiển thị bước xác nhận trước khi thực hiện các thao tác quy mô lớn.
________________________________________
104. AN TOÀN THAO TÁC HÀNG LOẠT (BULK OPERATION SAFETY)
Đối với mọi thao tác hàng loạt:
1.	Xem trước (Preview).
2.	Xác thực dữ liệu (Validate).
3.	Hiển thị số lượng bản ghi bị ảnh hưởng.
4.	Xác nhận (Confirm).
5.	Thực thi (Execute).
6.	Hiển thị kết quả.
7.	Cung cấp báo cáo lỗi.
8.	Ghi lại sự kiện kiểm toán (audit event).
________________________________________
105. TÌM KIẾM (SEARCH)
Tìm kiếm toàn cục trên dữ liệu được cấp phép:
•	Chiến dịch.
•	Nhân viên.
•	Nhóm.
•	Hộ gia đình.
•	Cơ sở/Tổ chức (Institution).
•	Nhiệm vụ.
•	Bản gửi (Submission).
•	Khu vực địa lý.
________________________________________
106. PHÁT HIỆN TRÙNG LẶP (DUPLICATE DETECTION)
Phát hiện:
•	Nhân viên trùng lặp.
•	Mục tiêu trùng lặp.
•	Hộ gia đình trùng lặp.
•	Nhiệm vụ trùng lặp.
•	Phân công trùng lặp.
•	Thanh toán trùng lặp.
Không tự động xóa các bản ghi.
Gắn cờ chúng để xem xét.
________________________________________
107. TÙY CHỌN THÔNG BÁO (NOTIFICATION PREFERENCES)
Cho phép người dùng cấu hình các tùy chọn nhận thông báo được phép thay đổi.
Tuy nhiên, các cảnh báo bắt buộc của cơ quan nhà nước không thể bị tắt nếu đã được cấu hình là bắt buộc.
________________________________________
108. KIẾN TRÚC API (API ARCHITECTURE)
Sử dụng REST API sạch hoặc tương đương.
Tổ chức các API theo mô-đun:
/auth
/users
/employees
/departments
/geography
/campaigns
/phases
/teams
/targets
/tasks
/forms
/submissions
/verifications
/exceptions
/payments
/notifications
/reports
/audit
/files
________________________________________
109. TÀI LIỆU API (API DOCUMENTATION)
Tạo:
OpenAPI / Swagger
Lập tài liệu cho:
•	Xác thực (Authentication).
•	Yêu cầu (Request).
•	Phản hồi (Response).
•	Lỗi (Errors).
•	Quyền hạn (Permissions).
________________________________________
110. XỬ LÝ LỖI (ERROR HANDLING)
Sử dụng cấu trúc phản hồi API nhất quán.
Ví dụ:
{
"success": false,
"error": {
"code": "VALIDATION_ERROR",
"message": "Các trường bắt buộc đang bị thiếu."
}
}
Không bao giờ làm lộ:
•	Lỗi cơ sở dữ liệu.
•	Dấu vết ngăn xếp (Stack traces).
•	Thông tin bí mật (Secrets).
•	Chi tiết hạ tầng nội bộ.
________________________________________
111. TRẠNG THÁI GIAO DIỆN (FRONTEND STATE)
Sử dụng chiến lược quản lý trạng thái / tải dữ liệu phù hợp.
Sử dụng:
•	Tải dữ liệu phía máy chủ (Server-side fetching) ở những nơi phù hợp.
•	Lưu bộ nhớ đệm truy vấn (Query caching).
•	Cập nhật lạc quan (Optimistic updates) chỉ khi thực sự an toàn.
•	Trạng thái ngoại tuyến (Offline state).
________________________________________
112. BẢO MẬT DỮ LIỆU NGOẠI TUYẾN (OFFLINE DATA SECURITY)
Không lưu trữ vĩnh viễn dữ liệu cá nhân nhạy cảm không cần thiết trên thiết bị.
Mã hóa / bảo vệ cục bộ kho lưu trữ ngoại tuyến nhạy cảm ở những nơi khả thi.
Cung cấp cơ chế hết hạn thiết bị / phiên làm việc.
________________________________________
113. BẢO MẬT PHIÊN LÀM VIỆC (SESSION SECURITY)
Hỗ trợ:
•	Hết thời gian chờ phiên (Session timeout).
•	Quản lý thiết bị / phiên đăng nhập.
•	Đăng xuất khỏi tất cả các thiết bị khi được cấp phép.
•	Thu hồi token (Token revocation).
•	Phát hiện đăng nhập đáng ngờ.
________________________________________
114. BẢO MẬT OTP (OTP SECURITY)
OTP:
•	Thời gian hết hạn.
•	Giới hạn tần suất (Rate limiting).
•	Giới hạn số lần thử.
•	Thời gian chờ gửi lại (Resend cooldown).
•	Lưu trữ an toàn.
•	Ghi nhật ký kiểm toán.
Không bao giờ lưu trữ OTP ở dạng văn bản thuần (plain text) lâu hơn mức cần thiết.
________________________________________
115. ĐĂNG NHẬP (LOGIN)
Hỗ trợ:
Số điện thoại di động
→ OTP để xác minh lần đầu
→ Tạo mật khẩu
Sau đó:
Số điện thoại di động
→ Mật khẩu
→ Bảng điều khiển (Dashboard)
Quên mật khẩu:
Số điện thoại di động
→ OTP
→ Mật khẩu mới
________________________________________
116. TÍCH HỢP HỆ THỐNG CHÍNH PHỦ (GOVERNMENT INTEGRATIONS)
Xây dựng các giao diện tích hợp (integration interfaces) thay vì viết cứng (hard-code) các hệ thống bên ngoài.
Các tích hợp có thể có trong tương lai:
•	Cổng SMS (SMS gateway).
•	Cơ sở dữ liệu gốc về cán bộ nhân viên nhà nước.
•	Hệ thống GIS chính thức.
•	Hệ thống thanh toán / kho bạc.
•	Hệ thống định danh / xác thực.
•	Email.
•	Cổng thông báo (Notification gateway).
Sử dụng các bộ chuyển đổi (adapters) / giao diện (interfaces) để có thể thay đổi nhà cung cấp dễ dàng.
________________________________________
117. KHÔNG GIẢ MẠO TÍCH HỢP (NO FAKE INTEGRATIONS)
Nếu một API chính phủ thực tế chưa sẵn có:
Hãy sử dụng một bộ chuyển đổi phát triển / giả lập (development/mock adapter) được đánh dấu rõ ràng.
Không giả vờ một tích hợp giả lập là hệ thống thật.
________________________________________
118. TÍCH HỢP THANH TOÁN (PAYMENT INTEGRATION)
Quá trình xử lý thanh toán ban đầu cần hỗ trợ:
Trạng thái thủ công / hành chính
và được thiết kế kiến trúc sẵn sàng để tích hợp trong tương lai với hệ thống thanh toán / kho bạc nhà nước được cấp phép.
Không tự bịa ra một API thanh toán của chính phủ.
________________________________________
119. BẢO MẬT NHẬP/XUẤT DỮ LIỆU (IMPORT/EXPORT SECURITY)
Việc xuất dữ liệu phải tuân thủ phân quyền.
Không cho phép cán bộ thực địa xuất toàn bộ dữ liệu của huyện.
Việc xuất các dữ liệu nhạy cảm phải yêu cầu quyền phê duyệt bổ sung khi phù hợp.
Ghi nhật ký mọi thao tác xuất dữ liệu.
________________________________________
120. BẢNG ĐIỀU KHIỂN CHẤT LƯỢNG DỮ LIỆU (DATA QUALITY DASHBOARD)
Hiển thị:
•	Dữ liệu bị thiếu.
•	Dữ liệu không hợp lệ.
•	Dữ liệu trùng lặp.
•	Các ngoại lệ về GPS.
•	Tỷ lệ yêu cầu chỉnh sửa.
•	Tỷ lệ từ chối.
•	Hoạt động bất thường.
________________________________________
121. CHỈ SỐ NĂNG SUẤT (PRODUCTIVITY METRICS)
Hiển thị:
•	Số nhiệm vụ hoàn thành mỗi ngày.
•	Thời lượng thực hiện nhiệm vụ trung bình.
•	Tỷ lệ hoàn thành.
•	Tỷ lệ phải chỉnh sửa.
•	Tỷ lệ được phê duyệt.
•	Tỷ lệ quá hạn.
Không sử dụng các chỉ số năng suất làm kết luận kỷ luật tự động.
________________________________________
122. MẪU CHIẾN DỊCH (CAMPAIGN TEMPLATES)
Cho phép quản trị viên lưu:
Mẫu Chiến dịch (Campaign Template)
Ví dụ:
Mẫu Thanh tra Trường học.
Khi tạo một chiến dịch mới:
Sử dụng Mẫu (Use Template)
Sau đó chỉnh sửa:
•	Biểu mẫu.
•	Các phòng ban.
•	Địa lý.
•	Lực lượng lao động.
•	Ngày tháng.
•	Thanh toán.
________________________________________
123. THƯ VIỆN MẪU BIỂU MẪU (FORM TEMPLATE LIBRARY)
Cho phép tái sử dụng các biểu mẫu.
Ví dụ:
•	Biểu mẫu thanh tra.
•	Biểu mẫu khảo sát.
•	Biểu mẫu hộ gia đình.
•	Biểu mẫu xác minh.
Các biểu mẫu vẫn phải được quản lý theo phiên bản (versioned).
________________________________________
124. MẪU QUY TRÌNH LÀM VIỆC (WORKFLOW TEMPLATE)
Cho phép tái sử dụng các quy trình làm việc.
Ví dụ:
Cán bộ Thực địa (Field Officer)
→ Giám sát viên (Supervisor)
→ Trưởng Phòng ban (Department Head)
→ Quản trị viên Cấp huyện (District Admin).
Lưu dưới tên:
Quy trình Thanh tra Tiêu chuẩn (Standard Inspection Workflow).
________________________________________
125. MẪU THANH TOÁN (PAYMENT TEMPLATE)
Cho phép người dùng được cấp phép tái sử dụng các cấu trúc thanh toán.
Ví dụ:
Mẫu Thanh toán Nhiệm vụ Thực địa.
Tuy nhiên, mỗi chiến dịch / giai đoạn phải tham chiếu đến đúng quy tắc / phiên bản được áp dụng.
________________________________________
126. TẠM DỪNG CHIẾN DỊCH (CAMPAIGN PAUSE)
Quản trị viên có thể tạm dừng một chiến dịch.
Khi bị tạm dừng:
•	Không nhiệm vụ mới nào có thể bắt đầu.
•	Các bản nháp hiện có vẫn được giữ an toàn.
•	Quản trị viên có thể tiếp tục lại (resume) sau đó.
Hiển thị rõ ràng:
Chiến dịch Đang Tạm dừng (Campaign Paused).
________________________________________
127. GIA HẠN CHIẾN DỊCH (CAMPAIGN EXTENSION)
Quản trị viên được cấp phép có thể gia hạn thời hạn hoàn thành (deadline).
Yêu cầu:
•	Ngày mới.
•	Lý do.
•	Phê duyệt nếu được cấu hình.
Ghi lại lịch sử kiểm toán.
________________________________________
128. PHÂN CÔNG LẠI NHIỆM VỤ (TASK REASSIGNMENT)
Cho phép:
Nhân viên A
→ Nhân viên B
Lý do:
Nhân viên không thể làm việc.
Duy trì toàn bộ lịch sử phân công.
________________________________________
129. THAY ĐỔI NHÓM (TEAM CHANGE)
Cho phép thêm/bớt thành viên trong nhóm trong suốt chiến dịch khi có sự cấp phép.
Không ghi đè lại các bản ghi phân công lịch sử trước đó.
________________________________________
130. PHÂN CÔNG LẠI MỤC TIÊU (TARGET REASSIGNMENT)
Nếu một hộ gia đình / cơ sở được phân công lại:
Duy trì:
Nhóm cũ (Old Team)
→ Nhóm mới (New Team)
Lý do
Ngày tháng
Người cấp phép
________________________________________
131. CHỐT DỮ LIỆU GIAI ĐOẠN (FINALIZATION)
Khi một giai đoạn được chốt hoàn tất:
•	Ngăn chặn việc chỉnh sửa thông thường.
•	Chỉ cho phép quy trình chỉnh sửa được cấp phép đặc biệt.
•	Khóa kết quả chính thức.
•	Lưu giữ các phiên bản lịch sử.
________________________________________
132. ĐÓNG CHIẾN DỊCH (CAMPAIGN CLOSURE)
Khi chiến dịch hoàn thành:
•	Khóa các thay đổi vận hành.
•	Chốt các báo cáo cuối cùng.
•	Chốt danh sách đủ điều kiện thanh toán.
•	Lưu giữ nhật ký kiểm toán.
•	Lưu trữ (Archive) theo chính sách lưu giữ dữ liệu.
________________________________________
133. BẢN DEMO THỰC TẾ ĐIỀU TRA DÂN SỐ 2027 (REAL-LIFE CENSUS 2027 DEMO)
Tạo bản demo phát triển:
Chiến dịch:
Điều tra Dân số 2027 (Census 2027)
Huyện:
Huyện Demo (Demo District)
Các phòng ban:
•	Thuế vụ / Doanh thu (Revenue).
•	Giáo dục (Education).
•	Hành chính Đô thị (Municipal Administration).
•	Hội đồng Làng xã (Panchayat).
Tạo dữ liệu mẫu:
•	2 phân khu (subdivisions).
•	4 tehsil.
•	3 đô thị (municipalities).
•	10 làng (villages).
•	20 phường (wards).
•	50 khu phố (mohallas).
•	500 hộ gia đình.
•	100 nhân viên.
•	20 nhóm chính thức.
•	5 nhóm dự bị.
Tạo:
Giai đoạn 1:
Lập danh sách Nhà ở (House Listing)
Giai đoạn 2:
Thống kê Dân số (Enumeration)
Giai đoạn 3:
Xác minh (Verification)
Sử dụng các câu hỏi giữ chỗ (placeholder) mẫu.
Gắn nhãn rõ ràng:
DỮ LIỆU DEMO — KHÔNG PHẢI DỮ LIỆU ĐIỀU TRA DÂN SỐ CHÍNH THỨC (DEMO DATA — NOT OFFICIAL CENSUS DATA)
________________________________________
134. DEMO ĐẦU-CUỐI TOÀN TRÌNH (END-TO-END DEMO)
Trình diễn luồng hoạt động:
Quản trị viên Cấp huyện (District Admin)
→ Tạo chiến dịch Điều tra Dân số
→ Tạo Giai đoạn 1
→ Chọn các phòng ban
→ Nhập (Import) danh sách nhân viên
→ Tạo các nhóm liên ngành (joint teams)
→ Phân công khu vực địa lý
→ Tải danh sách các hộ gia đình mục tiêu
→ Tạo biểu mẫu Giai đoạn 1
→ Cấu hình quy trình xác minh
→ Cấu hình quy tắc thanh toán
→ Khởi chạy giai đoạn
Nhóm Thực địa (Field Team)
→ Đăng nhập
→ Xem danh sách hộ gia đình
→ Mở thông tin hộ gia đình
→ Điền hoàn chỉnh biểu mẫu
→ Thu thập tọa độ GPS
→ Lưu bản nháp
→ Gửi biểu mẫu (Submits)
Người kiểm duyệt (Reviewer)
→ Xem xét
→ Yêu cầu chỉnh sửa
Nhóm Thực địa (Field Team)
→ Chỉnh sửa
→ Gửi lại
Người kiểm duyệt (Reviewer)
→ Phê duyệt
Hệ thống (System)
→ Tạo kết quả cuối cùng
→ Tạo trạng thái đủ điều kiện thanh toán
→ Hiển thị trạng thái thanh toán
Quản trị viên Cấp huyện (District Admin)
→ Xem bảng điều khiển
→ Khoan sâu (Drills down) xuống tận cấp hộ gia đình
→ Xem bản đồ
→ Tạo tệp Excel/PDF
→ Xem lịch sử kiểm toán.
________________________________________
135. KIỂM THỬ (TESTING)
Tạo:
Kiểm thử Đơn vị (Unit Tests)
Cho:
•	Phân công nhiệm vụ.
•	Quyền hạn.
•	Xác thực biểu mẫu.
•	GPS.
•	Tính toán thanh toán.
•	Quy trình làm việc (Workflow).
Kiểm thử Tích hợp (Integration Tests)
Cho:
•	Xác thực đăng nhập.
•	Chiến dịch.
•	Nhóm.
•	Biểu mẫu.
•	Gửi dữ liệu (Submission).
•	Xác minh.
•	Thanh toán.
Kiểm thử Đầu-Cuối (E2E Tests)
Kiểm thử toàn bộ vòng đời của chiến dịch.
________________________________________
136. KIỂM THỬ TẢI (LOAD TESTING)
Kiểm thử với mức tải thực tế.
Tối thiểu phải kiểm thử:
•	50,000 nhân viên.
•	Khối lượng nhiệm vụ lớn.
•	Khối lượng bản gửi lớn.
•	Người dùng di động truy cập đồng thời.
•	Tạo báo cáo dung lượng lớn.
•	Tải lên tệp dung lượng lớn.
Xác định các điểm nghẽn cổ chai (bottlenecks).
________________________________________
137. ĐÁNH CHỈ MỤC CƠ SỞ DỮ LIỆU (DATABASE INDEXING)
Tạo chỉ mục (indexes) cho các trường thường xuyên được truy vấn:
•	ID Nhân viên (Employee ID).
•	Số điện thoại di động (Mobile).
•	ID Chiến dịch (Campaign ID).
•	ID Giai đoạn (Phase ID).
•	ID Nhóm (Team ID).
•	ID Địa lý (Geographic ID).
•	ID Mục tiêu (Target ID).
•	Trạng thái nhiệm vụ (Task status).
•	Trạng thái bản gửi (Submission status).
•	Trạng thái thanh toán (Payment status).
•	Ngày tạo (Created date).
Xem xét kế hoạch thực thi truy vấn (query plans) đối với các bảng dữ liệu lớn.
________________________________________
138. KIẾN TRÚC CÔNG NGHỆ (ARCHITECTURE)
Ngăn xếp công nghệ (stack) ưu tiên:
Frontend
Next.js
React
TypeScript
Tailwind CSS
shadcn/ui
PWA
IndexedDB
Backend
NestJS
TypeScript
Database
PostgreSQL
Prisma
Cache / Queue
Redis
BullMQ
Storage
Kho lưu trữ tương thích S3 (S3-compatible storage)
Maps
Lớp trừu tượng hóa nhà cung cấp (Provider abstraction) hỗ trợ:
OpenStreetMap / Mapbox / Google Maps
________________________________________
139. CẤU TRÚC DỰ ÁN (PROJECT STRUCTURE)
Sử dụng kiến trúc phân tách mô-đun sạch sẽ.
Ví dụ:
/apps
/web
/api
/packages
/ui
/types
/config
/validation
/infrastructure
/docs
/tests
Giữ cho logic nghiệp vụ (business logic) tách biệt khỏi giao diện người dùng (UI).
________________________________________
140. BIẾN MÔI TRƯỜNG (ENVIRONMENT VARIABLES)
Tạo tệp:
.env.example
Bao gồm:
DATABASE_URL
REDIS_URL
JWT_SECRET
S3_ENDPOINT
S3_ACCESS_KEY
S3_SECRET_KEY
S3_BUCKET
SMS_PROVIDER
SMS_API_KEY
SMS_SENDER_ID
EMAIL_PROVIDER
EMAIL_API_KEY
MAP_PROVIDER
MAP_API_KEY
Không bao giờ commit các thông tin bí mật (secrets) thật.
________________________________________
141. DOCKER
Cung cấp:
Dockerfile
docker-compose.yml
Các dịch vụ (Services):
•	Web.
•	API.
•	PostgreSQL.
•	Redis.
•	Kho lưu trữ đối tượng (Object storage) phục vụ phát triển cục bộ.
________________________________________
142. TÀI LIỆU HƯỚNG DẪN PHÁT TRIỂN (DEVELOPMENT README)
Cung cấp hướng dẫn đầy đủ:
1.	Cài đặt các gói phụ thuộc (dependencies).
2.	Cấu hình tệp .env.
3.	Khởi động PostgreSQL.
4.	Khởi động Redis.
5.	Chạy di trú cơ sở dữ liệu (migrations).
6.	Tạo dữ liệu mầm (Seed database).
7.	Khởi động backend.
8.	Khởi động frontend.
9.	Đăng nhập bằng thông tin tài khoản demo.
10.	Chạy kiểm thử (tests).
________________________________________
143. DỮ LIỆU MẦM (SEED DATA)
Tạo dữ liệu phát triển sát thực tế nhưng thể hiện rõ là dữ liệu giả lập.
Bao gồm:
•	Quản trị viên (Admin).
•	Trưởng Phòng ban (Department Heads).
•	Giám sát viên (Supervisors).
•	Cán bộ Thực địa (Field Officers).
•	Nhân viên dự bị (Reserve employees).
•	Các phòng ban.
•	Phân cấp địa lý.
•	Các nhóm.
•	Các hộ gia đình.
•	Các chiến dịch.
•	Các giai đoạn.
•	Các biểu mẫu.
•	Các nhiệm vụ.
Không bao giờ sử dụng thông tin cá nhân thật.
________________________________________
144. THÔNG TIN ĐĂNG NHẬP DEMO (DEMO CREDENTIALS)
Cung cấp các tài khoản demo chỉ dành cho môi trường phát triển.
Ví dụ:
District Admin
Department Head
Supervisor
Field Officer
Payment Officer
Đánh dấu rõ ràng:
CHỈ DÀNH CHO PHÁT TRIỂN (DEVELOPMENT ONLY)
Không sử dụng các thông tin đăng nhập này trong môi trường thực tế (production).
________________________________________
145. QUY TẮC QUAN TRỌNG VỀ DỮ LIỆU CHÍNH PHỦ
Không tự bịa ra:
•	Các câu hỏi Điều tra Dân số chính thức.
•	Mức tiền chi trả của chính phủ.
•	Các văn bản / mệnh lệnh hành chính của chính phủ.
•	Hồ sơ cán bộ công chức nhà nước.
•	Các tập dữ liệu địa lý chính thức.
•	Các API của chính phủ.
•	Quy trình nghiệp vụ Điều tra Dân số chính thức.
Ở những nơi chưa có thông tin chính thức, hãy tạo:
CÁC GIÁ TRỊ GIỮ CHỖ CÓ THỂ CẤU HÌNH (CONFIGURABLE PLACEHOLDERS)
và gắn nhãn rõ ràng cho chúng.
________________________________________
146. QUY TẮC THIẾT KẾ QUAN TRỌNG
Không tạo các ứng dụng riêng lẻ cho từng mục đích:
•	Điều tra dân số.
•	Thanh tra trường học.
•	Khảo sát đường bộ.
•	Khảo sát lũ lụt.
Thay vào đó hãy tạo một nền tảng chung:
Nền tảng Chiến dịch Cấp huyện (District Campaign Platform)
Sau đó cấu hình:
Loại Chiến dịch (Campaign Type):
Điều tra dân số (Census)
Chiến dịch (Campaign):
Điều tra dân số 2027 (Census 2027)
Giai đoạn (Phase):
Lập danh sách Nhà ở (House Listing)
Cách tiếp cận này giúp nền tảng có thể tái sử dụng nhiều lần.
________________________________________
147. CÁC MÔ-ĐUN KIẾN TRÚC QUAN TRỌNG NHẤT
Ứng dụng phải được xây dựng xoay quanh các công cụ (engines) sau:
1. Campaign Engine (Công cụ Chiến dịch)
Các chiến dịch và giai đoạn.
2. Organization Engine (Công cụ Tổ chức)
Các phòng ban và sơ đồ phân cấp.
3. Geography Engine (Công cụ Địa lý)
Huyện / tehsil / làng / phường / khu phố (mohalla).
4. Workforce Engine (Công cụ Lực lượng lao động)
Nhân viên và trạng thái sẵn sàng làm việc.
5. Team Engine (Công cụ Nhóm)
Nhóm liên ngành và nhóm dự bị.
6. Target Entity Engine (Công cụ Thực thể Mục tiêu)
Hộ gia đình, trường học, đường sá, v.v.
7. Assignment Engine (Công cụ Phân công)
Phân công mục tiêu cho các nhóm / nhân viên.
8. Form Engine (Công cụ Biểu mẫu)
Biểu mẫu động và quản lý phiên bản.
9. Field Data Engine (Công cụ Dữ liệu Thực địa)
Thu thập dữ liệu trên thiết bị di động.
10. Offline Sync Engine (Công cụ Đồng bộ Ngoại tuyến)
Hoạt động ngoại tuyến trên thiết bị di động.
11. Verification Engine (Công cụ Xác minh)
Xem xét và phê duyệt.
12. Exception Engine (Công cụ Ngoại lệ)
Các ngoại lệ về chất lượng dữ liệu và vận hành.
13. Payment Engine (Công cụ Thanh toán)
Thanh toán có thể cấu hình dựa trên hướng dẫn của chính phủ.
14. Notification Engine (Công cụ Thông báo)
SMS / email / thông báo đẩy (push) / trong ứng dụng (in-app).
15. Reporting Engine (Công cụ Báo cáo)
Bảng điều khiển và các báo cáo.
16. Audit Engine (Công cụ Kiểm toán)
Lịch sử hoạt động đầy đủ.
________________________________________
148. THỨ TỰ PHÁT TRIỂN (DEVELOPMENT ORDER)
Đừng cố gắng tạo toàn bộ ứng dụng dưới dạng các trang rời rạc thiếu kết nối.
Hãy xây dựng theo thứ tự sau:
Giai đoạn A — Nền tảng (Foundation)
•	Kiến trúc.
•	Cơ sở dữ liệu.
•	Xác thực (Authentication).
•	Phân quyền dựa trên vai trò (RBAC).
•	Tổ chức.
•	Địa lý.
Giai đoạn B — Chiến dịch (Campaign)
•	Chiến dịch.
•	Giai đoạn.
•	Phòng ban.
•	Lực lượng lao động.
•	Nhóm.
Giai đoạn C — Mục tiêu & Phân công (Target & Assignment)
•	Thực thể mục tiêu.
•	Hộ gia đình.
•	Phân công theo địa lý.
•	Công cụ nhiệm vụ (Task engine).
•	Khối lượng công việc.
Giai đoạn D — Biểu mẫu (Forms)
•	Trình tạo biểu mẫu (Form builder).
•	Câu hỏi động.
•	Điều kiện rẽ nhánh.
•	Nhóm lặp lại (Repeating groups).
•	Xác thực dữ liệu (Validation).
•	Quản lý phiên bản (Versioning).
Giai đoạn E — Di động (Mobile)
•	Giao diện cán bộ thực địa.
•	Ngoại tuyến (Offline).
•	GPS.
•	Hình ảnh.
•	Video.
•	Đồng bộ hóa (Sync).
Giai đoạn F — Quy trình làm việc (Workflow)
•	Xác minh.
•	Chỉnh sửa.
•	Gửi lại.
•	Phê duyệt.
•	Ngoại lệ.
Giai đoạn G — Thanh toán (Payment)
•	Quy tắc thanh toán.
•	Tính đủ điều kiện.
•	Phê duyệt.
•	Trạng thái.
•	Nhắc nhở.
•	Ngoại lệ.
Giai đoạn H — Thông tin Quản trị (Intelligence)
•	Bảng điều khiển (Dashboards).
•	Bản đồ.
•	Phân tích dữ liệu (Analytics).
•	Báo cáo.
•	Xuất dữ liệu.
Giai đoạn I — Đưa vào Vận hành Thực tế (Production)
•	Bảo mật.
•	Kiểm thử.
•	Kiểm thử tải (Load testing).
•	Giám sát.
•	Sao lưu.
•	Khôi phục sau thảm họa.
•	Docker.
•	Tài liệu hướng dẫn.
________________________________________
149. TIÊU CHÍ NGHIỆM THU CUỐI CÙNG (FINAL ACCEPTANCE CRITERIA)
Dự án chỉ được coi là hoàn thành khi luồng hoạt động đầu-cuối (end-to-end) thực tế vận hành trơn tru:
Quản trị viên Cấp huyện (District Admin)
→ tạo chiến dịch
→ tạo nhiều giai đoạn
→ chọn các phòng ban
→ nhập danh sách lực lượng lao động
→ tạo các nhóm liên ngành
→ tạo các nhóm dự bị
→ phân công địa lý
→ tải danh sách các thực thể mục tiêu
→ tạo biểu mẫu động theo từng giai đoạn cụ thể
→ tạo quy trình xác minh
→ cấu hình quy tắc thanh toán được cấp phép
→ khởi chạy chiến dịch
↓
Nhóm Thực địa (Field Team)
→ đăng nhập trên thiết bị di động
→ nhận khu vực được phân công
→ xem các mục tiêu được giao
→ đến thăm thực tế mục tiêu
→ điền biểu mẫu
→ thu thập tọa độ GPS ở những nơi bắt buộc
→ chụp ảnh/quay video ở những nơi bắt buộc
→ làm việc ngoại tuyến nếu cần thiết
→ đồng bộ hóa dữ liệu
→ gửi biểu mẫu
↓
Người kiểm duyệt (Reviewer)
→ nhận bản gửi
→ xác minh
→ yêu cầu chỉnh sửa
↓
Nhóm Thực địa (Field Team)
→ chỉnh sửa
→ gửi lại
↓
Người kiểm duyệt (Reviewer)
→ phê duyệt
↓
Hệ thống (System)
→ chốt kết quả cuối cùng
→ tính toán điều kiện hưởng thanh toán theo quy định được cấp phép
→ theo dõi thanh toán
→ gửi thông báo
↓
Quản trị viên Cấp huyện (District Admin)
→ xem tiến độ theo thời gian thực
→ khoan sâu dữ liệu theo phân cấp địa lý
→ xem bản đồ
→ xem hiệu suất của phòng ban / nhóm / nhân viên
→ xem các trường hợp ngoại lệ
→ xem trạng thái thanh toán
→ tạo báo cáo
→ xuất dữ liệu được cấp phép
→ xem lại lịch sử kiểm toán.
________________________________________
150. HƯỚNG DẪN CUỐI CÙNG DÀNH CHO LẬP TRÌNH VIÊN AI
Đừng xây dựng một dự án đồ chơi (toy project).
Đừng chỉ xây dựng các màn hình giao diện frontend.
Đừng sử dụng các mảng dữ liệu gắn cứng (hard-coded arrays) cho dữ liệu nghiệp vụ cốt lõi.
Đừng tạo các nút bấm giả không có chức năng.
Đừng tạo các trang demo rời rạc không kết nối với nhau.
Hãy xây dựng một hệ thống full-stack thực thụ với:
Frontend
↕
Backend API
↕
Logic Nghiệp vụ (Business Logic)
↕
PostgreSQL
↕
Kho Lưu trữ Đối tượng (Object Storage)
↕
Redis / Tác vụ Chạy nền (Background Jobs)
↕
Dịch vụ Thông báo (Notification Services)
Mọi nút bấm quan trọng phải thực hiện một thao tác thực sự.
Mọi bản ghi quan trọng phải được lưu trữ bền vững vào cơ sở dữ liệu.
Mọi quyền hạn phải được kiểm soát và thực thi ở phía backend.
Mọi bản gửi chính thức phải được quản lý phiên bản.
Mọi thay đổi quan trọng phải được ghi nhật ký kiểm toán.
Mọi thao tác dữ liệu lớn phải được thiết kế để đảm bảo khả năng mở rộng quy mô.
Mọi quy trình làm việc trên di động phải tính đến điều kiện kết nối mạng kém.
Mọi khoản tiền thanh toán phải có thể cấu hình và được liên kết với một quy tắc / văn bản tham chiếu được cấp phép.
Mọi chiến dịch phải có thể cấu hình.
Mọi giai đoạn phải có thể cấu hình độc lập.
Mọi biểu mẫu phải có thể cấu hình động.
Mọi sơ đồ phân cấp tổ chức / địa lý phải có thể cấu hình.
Sản phẩm cuối cùng phải là một Nền tảng Vận hành Thực địa & Chiến dịch Số cấp Huyện (District Administration Digital Campaign & Field Operations Platform) có khả năng tái sử dụng, trong đó Điều tra Dân số 2027 (Census 2027) là một kịch bản triển khai thực tế, chứ không phải là một ứng dụng chỉ dùng riêng cho Điều tra Dân số.
Một điều tôi đặc biệt khuyến nghị:
Đối với một dự án có quy mô lớn như thế này, đừng yêu cầu AI tạo toàn bộ ứng dụng chỉ trong một lần chạy duy nhất. Hãy cung cấp cho AI bản prompt tổng thể ở trên, sau đó yêu cầu nó thực hiện từng mô-đun một, bắt đầu từ cơ sở dữ liệu và kiến trúc hệ thống.
Nền tảng quan trọng nhất là:
Organization → Geography → Workforce → Campaign → Phase → Team → Target → Task → Form → Submission → Verification → Result → Payment
Nếu mô hình dữ liệu đó được thiết kế chuẩn xác, phần còn lại của ứng dụng có thể phát triển mở rộng dần mà không cần phải đập đi xây lại về sau.