Tech Roadmap · Đề án 01-2026/DA-VF

Đảm bảo mọi cam kết có phương án kỹ thuật thật

Hợp nhất toàn bộ hạng mục kỹ thuật — từ pipeline dữ liệu đến định danh VNeID — thành một lộ trình có giai đoạn, có tiêu chí nghiệm thu đo được. Không lặp lại phân tích hiện trạng hay blueprint cấp task/file — tài liệu này đứng trên, dùng để lập sprint.

10Hạng mục kỹ thuật (H1–H10), mỗi hạng mục truy vết được về đúng một cam kết trong đề án/phụ lục

3Giai đoạn, khớp tinh thần lộ trình gốc của đề án — mỗi giai đoạn có exit criteria đo được

H1→H4→H7Đường găng (critical path) — mọi trượt tiến độ ở H1 đẩy lùi toàn bộ GĐ2/GĐ3

6Nguyên tắc điều hành — trong đó cốt lõi: cam kết chỉ vào hồ sơ khi code đã đúng

Nguyên tắc điều hành lộ trình

Mọi cam kết phải có chủ (traceability): mỗi câu cam kết trong đề án/phụ lục ánh xạ vào đúng một hạng mục roadmap. Không có cam kết "mồ côi".
Cam kết chỉ vào hồ sơ chính thức khi code đã đúng, hoặc có mốc hoàn thành rõ ràng: ví dụ "AES-256 at rest" hiện đúng cho SQLite nhưng chưa đúng cho buffer AsyncStorage — pentest phát hiện sai lệch sẽ thiệt hại uy tín hơn nhiều so với ghi trung thực "hoàn thành ở Giai đoạn 1".
Tích hợp qua nền tảng trung tâm, không nối điểm-điểm: app không bao giờ gọi thẳng API một hạ tầng cụ thể. Mọi đường ra ngoài qua một điểm nối duy nhất — Integration Gateway (H9) và IdentityProvider (H5).
Không xây trừu tượng cho yêu cầu chưa tồn tại: các lớp trung gian chỉ xây ở mức "một điểm nối duy nhất" — chưa dựng sẵn adapter cho đặc tả API chưa có (Viettel IDC, VNeID).
Dữ liệu thuộc quyền quản lý của Sở: mọi schema/pipeline giữ khả năng xuất toàn bộ dữ liệu theo định dạng chuẩn mở, không khoá vào schema nội bộ — kiểm tra ở H8.
Tuân thủ kiến trúc dự án hiện có (CLAUDE.md): Redux tự viết, hook/trigger tách bạch, pattern isSync — không du nhập kiến trúc mới giữa chừng.

Ma trận cam kết → hạng mục

Mỗi cam kết trong đề án gốc hoặc phụ lục kỹ thuật được ánh xạ vào đúng hạng mục sẽ hiện thực hoá nó — dùng để đối chiếu trước mỗi lần hồ sơ gửi Sở thay đổi.

Cam kết (nguồn)	Hạng mục	Giai đoạn
Theo dõi quá trình tập luyện + thành tích — dữ liệu theo người dùng, không kẹt 1 thiết bị	H1	GĐ1
GPS là nguồn dữ liệu chuyên ngành đổ về nền tảng (Data Platform)	H1, H9	GĐ1 → GĐ3
Dữ liệu thành tích "chính thức, minh bạch, công bằng" cho bảng xếp hạng	H2, H4	GĐ1 → GĐ2
Cấp độ 3 ATTT (NĐ 85/2016, TT 12/2022); AES-256/TLS 1.3 (NĐ 13/2023); SOC, DRP, pentest	H3	GĐ1 → GĐ2 → GĐ3
Kiến trúc AI Chống Gian lận Đa tầng + Trust Score	H4	GĐ1 → GĐ2
IAM chuẩn OAuth2/OIDC, Identity Provider Gateway sẵn sàng VNeID	H5	GĐ1 → GĐ3
GIS/bản đồ nền OSM; tuyến đường thi đấu; chủ quyền Hoàng Sa, Trường Sa	H6	GĐ1 → GĐ2
Gamification, Cộng đồng, Thông báo	H7	GĐ2
Sở quản lý dữ liệu; doanh nghiệp mở API, sẵn sàng bàn giao	H8	GĐ2 → GĐ3
Module hóa, tích hợp qua nền tảng trung tâm; hạ tầng mở → Viettel IDC giai đoạn sau	H9	GĐ3
Logging, Monitoring, audit trail	H10	GĐ1 → GĐ2

Tổng quan 3 giai đoạn

Khớp tinh thần 3 giai đoạn của đề án gốc, diễn giải cho phạm vi app.

GĐ1
Nền tảng dữ liệu & bảo mật cốt lõi

Dữ liệu GPS đi được từ thiết bị lên backend tập trung một cách đáng tin cậy, sạch, mã hoá toàn trình; dọn sạch nợ kỹ thuật chặn đường; đặt sẵn 2 "điểm nối duy nhất" (identity + data).

Exit: activity ghi trên thiết bị A xuất hiện trên Firestore, đọc được từ thiết bị B; không còn dữ liệu vị trí plain-text; không còn API key lộ; không còn dead code Mapbox; Sentry bật thật.

GĐ2
Mở rộng tính năng & hệ sinh thái

Hoàn thiện App Vietflow đúng danh mục năng lực đề án: Route/GIS thật, gamification, cộng đồng, notification; nâng anti-cheat lên server-side + Trust Score; hoàn tất hồ sơ ATTT Cấp độ 3 + pentest.

Exit: toàn bộ ô 🟡/🔴 thuộc phạm vi App Vietflow trong bảng đối chiếu chuyển 🟢; pentest độc lập đạt, không sai lệch hồ sơ ↔ triển khai.

GĐ3
Sẵn sàng tích hợp mở rộng

Đấu nối thật ra ngoài Firebase: Integration Gateway → backend VIVN/Viettel IDC; OIDC → VNeID/Trục định danh TP.HCM; quy trình bàn giao dữ liệu định kỳ; SOC/DRP vận hành.

Exit: đổi đích dữ liệu và đổi IdP không sửa code UI/hook; một đợt bàn giao dữ liệu chuẩn thành công; diễn tập DRP đạt RTO/RPO cam kết.

Quy tắc chuyển giai đoạn: không bắt đầu hạng mục GĐ2 phụ thuộc pipeline (H4 server-side, H7) khi H1 chưa đạt tiêu chí hoàn thành — mọi tính năng cộng đồng/xếp hạng/huy hiệu đều đứng trên dữ liệu đã tập trung và chống gian lận tối thiểu.

Chi tiết hạng mục H1–H10

doneđã có/đúng partialmột phần/chưa nhất quán missingchưa có

H1Pipeline đồng bộ dữ liệu GPS/Activity (SQLite → Firestore)missing▶

Mục tiêu

Activity/GPS thu trên thiết bị được đẩy lên backend tự động, idempotent, chịu mất mạng, hai nguồn đọc/ghi nhất quán.

Vì sao cần

Cam kết cốt lõi nhất với App Vietflow; điều kiện tiên quyết cho anti-cheat server-side (H4), gamification/xếp hạng (H7), bàn giao dữ liệu (H8), đường ra Viettel IDC (H9).

Hiện trạng

Thu GPS trên máy đã sản phẩm hoá; cờ isSync không có consumer; addFitnessActivity không được gọi; màn Activity đọc nhầm Firestore trong khi nơi ghi là SQLite.

Việc cần làm

Sửa lệch nguồn màn Activity — đọc SQLite (TASK 1, làm trước, độc lập)
Hàm sync lõi idempotent, dùng activity.id làm doc id Firestore + đánh dấu isSync=1 (TASK 2)
Hàng đợi đồng bộ theo NetInfo, batch 20, retry qua cờ isSync (TASK 3)
Điểm neo Integration Gateway (TASK 6) — chỉ ghi nhận kiến trúc, chưa triển khai ở GĐ1

Tiêu chí hoàn thành (GĐ1)

Ghi activity trên thiết bị A (có mạng) → xuất hiện Firestore ≤ 30s; thiết bị B cùng tài khoản thấy được
Chế độ máy bay → bật mạng lại → tự sync; chạy 2 lần liên tiếp không trùng bản ghi
User offline 30 ngày, 100+ activity tồn đọng: sync theo batch, không treo UI, không mất bản ghi
Màn Activity hiển thị đúng với user mới hoàn toàn

Phụ thuộc / rủi ro

Gốc của cây phụ thuộc — không phụ thuộc hạng mục nào. Rủi ro: chi phí Firestore khi user tăng (giảm bằng batch); rà schema với H8 trước khi có dữ liệu lớn.

H2Chất lượng dữ liệu tại nguồn & Hiệu năng/Pinmissing▶

Mục tiêu

Dữ liệu GPS sạch ngay từ nguồn (lọc accuracy); pipeline không phá pin/hiệu năng ở phiên dài (8.000+ điểm).

Vì sao cần

Dữ liệu bẩn đồng bộ lên rất khó gỡ; mã hoá at-rest (H3) chỉ đúng khi buffer không còn plain-text — một thay đổi (buffer → SQLite) giải quyết cả hiệu năng O(n²) lẫn lỗ hổng mã hoá.

Hiện trạng

insertLocalArray đọc–sửa–ghi toàn mảng mỗi 5m (O(n²)); buffer plain-text trong AsyncStorage; không lọc coords.accuracy; interval 1s chạy vĩnh viễn; watchPositions log-only; 5 file dead code Mapbox.

Việc cần làm

Chuyển buffer GPS sang bảng SQLite activity_point (SQLCipher sẵn có)
Lọc điểm theo coords.accuracy (ngưỡng đề xuất 30m — chốt với product); điểm kém vẫn lưu thô cờ lowAccuracy, không cộng odometer
Dọn tài nguyên nền: gỡ/điều kiện hoá interval root, xoá watchPositions log-only, đánh giá lại preventSuspend
Xoá dứt điểm dead code Mapbox + store/local/location + store/map_box + file 0 byte — danh sách cụ thể cần báo user phê duyệt trước khi xoá

Tiêu chí hoàn thành (GĐ1)

Phiên ≥3h/≥8.000 điểm: thời gian ghi mỗi điểm không tăng theo độ dài phiên
Không còn mảng tọa độ nào ghi AsyncStorage; vị trí chỉ nằm SQLite (SQLCipher)
GPS yếu (accuracy > ngưỡng): quãng đường không bị cộng dồn từ điểm nhiễu
Không còn interval/listener chạy khi không trong phiên tracking
Không còn tham chiếu @rnmapbox/maps; build sạch cả 2 nền tảng

Phụ thuộc / rủi ro

Lọc accuracy nên xong trước/cùng H1 go-live. Vùng nhạy nhất của app — cần test hồi quy cả 2 OS, cả background tracking.

H3Bảo mật & Mã hoá đạt Cấp độ 3 ATTTmissing▶

Mục tiêu

Mọi cam kết ATTT Cấp độ 3 (NĐ 85/2016, TT 12/2022), AES-256/TLS 1.3 (NĐ 13/2023), SOC, DRP, pentest — đúng 100% thực tế khi hồ sơ gửi Sở.

Vì sao cần

Cam kết pháp lý cụ thể nhất trong hồ sơ; dữ liệu GPS là dữ liệu cá nhân nhạy cảm; sai lệch hồ sơ ↔ thực tế sẽ bị pentest độc lập phơi ra.

Hiện trạng

SQLCipher đúng một phần; App Check đã bật. API key Google Maps/MapTiler hardcode; exportDatabase mở share sheet ở production; sqlGetAllActivity nội suy chuỗi thay vì binding; Sentry DSN rỗng; chưa hồ sơ Cấp độ 3, chưa pentest, chưa SOC/DRP.

Việc cần làm

GĐ1: hoàn tất H2 (buffer → SQLCipher); restrict + rotate API key; tắt exportDatabase ở prod; parameter binding; ghi nhận thực tế TLS (1.2+ hiện tại, 1.3 bắt buộc ở API Gateway khi H9)
GĐ2: hồ sơ Cấp độ 3 theo TT 12/2022 (4 nhóm: quản lý/kỹ thuật/con người/vận hành) + DPIA sơ bộ; pentest độc lập (app + Firestore/Storage rules + Cloud Functions); rà soát security rules
GĐ3: đấu nối log an ninh với SOC Thành phố; ban hành + diễn tập DRP

Tiêu chí hoàn thành

(GĐ1) Không còn secret/API key chưa restrict; thiết bị mất không lộ dữ liệu vị trí
(GĐ2) Hồ sơ Cấp độ 3 + DPIA rà chéo bởi người ngoài đội dev; pentest không còn finding High/Critical mở; 0 sai lệch hồ sơ ↔ code
(GĐ3) Diễn tập DRP đạt RTO/RPO; log an ninh xác nhận hai chiều với SOC

Phụ thuộc / rủi ro

Phụ thuộc H2; SOC/DRP phụ thuộc H9 và tiến độ Sở/Thành phố. Rủi ro lớn nhất: viết hồ sơ vượt thực tế — chốt bằng nguyên tắc điều hành số 2.

H4Chống gian lận GPS: Multi-Sensor Anti-Cheat + Trust Scoremissing▶

Mục tiêu

Hiện thực hoá 2 lớp: on-device (lọc/tương quan tại thiết bị) và server-side (kiểm tra chéo đa nguồn trên dữ liệu tập trung, tính Trust Score).

Vì sao cần

Khoảng cách giữa cam kết "minh bạch, công bằng tuyệt đối" và thực tế hiện là lớn nhất trong tất cả hạng mục — cần lộ trình riêng, không gộp vào lọc accuracy.

Hiện trạng

Chỉ kiểm tra mock === true phía client (dễ qua mặt); bộ lọc vận tốc cũ trong refine_data.function.js tồn tại nhưng không dùng; chưa có thành phần server-side nào.

Việc cần làm

GĐ1 — Lớp 1 (on-device): bộ lọc vận tốc–gia tốc trên đường lưu chính thức (phát hiện teleport, tốc độ vượt ngưỡng theo loại hoạt động); kết quả ghi thành metadata gắn cờ — không âm thầm loại bỏ; bổ sung tín hiệu activity type/is_moving từ background-geolocation
GĐ2 — Lớp 2 (server-side, sau khi H1 xong): Cloud Functions phân tích sau-đồng-bộ (polyline vs tốc độ vs độ cao, đối chiếu lịch sử cá nhân); tính Trust Score per-user (chỉ backend ghi); activity nghi vấn không vào bảng xếp hạng công khai tới khi duyệt
GĐ3: anomaly detection thay dần heuristic khi đủ khối lượng dữ liệu

Tiêu chí hoàn thành

(GĐ1) ≥90% kịch bản gian lận cơ bản bị gắn cờ; 0% false positive trên bộ mẫu chuẩn
(GĐ2) Mỗi activity có kết quả phân xử ≤5 phút; Trust Score đọc được qua API/Firestore; xếp hạng chỉ nhận activity đã phân xử
(GĐ2) Công thức Trust Score có tài liệu giải trình cho Sở

Phụ thuộc / rủi ro

Lớp 2 phụ thuộc cứng H1; chính sách xếp hạng phụ thuộc H7. Rủi ro: false positive mất lòng tin user thật (giảm bằng "gắn cờ, không xoá"); hồ sơ không được ngụ ý đã thu cảm biến chưa có (khí áp, sinh trắc, Pod).

H5Lớp định danh sẵn sàng OAuth2/OIDC/VNeIDpartial▶

Mục tiêu

Ngày đấu nối VNeID không phải sửa từng màn hình — cần một lớp trung gian định danh có trước khi codebase mọc thêm nơi gọi auth() trực tiếp.

Vì sao cần

Mối lo lớn nhất của cơ quan quản lý nhà nước là hệ thống không đấu nối được định danh quốc gia; càng để lâu chi phí trả nợ càng lớn.

Hiện trạng

Firebase Auth (Email/Google) + hồ sơ Firestore hoạt động thật; Apple Sign-In cấu hình native, chưa có UI. Hook/component gọi thẳng Firebase Auth SDK — chưa có lớp IdentityProvider.

Việc cần làm

GĐ1: module IdentityProvider bọc Firebase Auth — mọi thao tác đăng nhập/token đi qua module này (refactor khoanh vùng, báo user trước khi làm); rule/lint chặn import trực tiếp; hoàn thiện UI Apple Sign-In qua lớp mới
GĐ3 (khi có đặc tả VNeID): flow OIDC Authorization Code + PKCE trong IdentityProvider; liên kết định danh ngoài với tài khoản Firebase; mapping/merge tài khoản hiện hữu

Tiêu chí hoàn thành

(GĐ1) 0 import Firebase Auth SDK ngoài module IdentityProvider; regression pass; Apple Sign-In hoạt động iOS
(GĐ1) Tài liệu interface IdentityProvider — dẫn chiếu trong hồ sơ gửi Sở
(GĐ3) Demo đăng nhập qua OIDC provider ngoài mà không sửa file nào ngoài module + config

Phụ thuộc / rủi ro

GĐ3 phụ thuộc đặc tả VNeID (ngoài kiểm soát VIVN) — tiêu chí đo bằng demo OIDC chuẩn bất kỳ. Rủi ro trôi kiến trúc: mỗi màn mới dùng thẳng auth() là một khoản nợ.

H6GIS/Bản đồ nền OpenStreetMap + Màn Route + Chủ quyền lãnh thổpartial▶

Mục tiêu

Thống nhất base map OSM cả 2 nền tảng; triển khai màn Route thật; style bản đồ thể hiện đúng chủ quyền Hoàng Sa, Trường Sa — hạng mục kiểm thử bắt buộc trước phát hành.

Vì sao cần

Phụ lục đã chính thức chọn OSM (cam kết tối ưu chi phí với Sở) và đưa cam kết chủ quyền có tính pháp lý; màn Route là yêu cầu chức năng số 10 của đề án, hiện UI dummy.

Hiện trạng

Android: map_android.js đã chồng tile OSM/MapTiler — khớp hướng OSM, nhưng Route Android không có bản đồ (phụ thuộc Mapbox chưa cài); iOS: Apple Maps (lệch nguồn với Android); Route: 100% mock, blueprint sẵn (16 TASK); chưa cơ chế chủ quyền.

Việc cần làm

GĐ1: chuẩn hoá OSM tile cả 2 nền tảng (iOS chuyển UrlTile như Android); xoá 5 file dead code Mapbox (phối hợp H2, có phê duyệt); chốt nguồn tile production có SLA (tile công cộng OSM cấm dùng thương mại lưu lượng lớn); Layer Override/Custom Rendering cho khu vực Biển Đông; đưa rà soát chủ quyền vào checklist phát hành vĩnh viễn
GĐ2: triển khai đầy đủ theo upgrade_01_route.md (16 TASK: schema, Redux, CRUD offline-first + sync, search/filter, dialog, PULSE design)

Tiêu chí hoàn thành

(GĐ1) Cùng nguồn tile OSM trên iOS & Android ở Run và Route; không còn màn trắng bản đồ
(GĐ1) Biên bản rà soát chủ quyền (các mức zoom Biển Đông) duyệt trước phát hành đầu tiên dùng OSM
(GĐ1) Nguồn tile production có hợp đồng/hạ tầng rõ ràng
(GĐ2) 16 TASK Route hoàn thành: tạo route → realtime thiết bị khác → "Bắt đầu chạy" nối sang Run tracking

Phụ thuộc / rủi ro

Route sync dùng lại pattern isSync của H1. Rủi ro pháp lý chủ quyền là rủi ro phát hành — nằm ở GĐ1, không đợi GĐ2.

H7Gamification, Cộng đồng, Notificationmissing▶

Mục tiêu

Lấp 3 năng lực đề án yêu cầu rõ nhưng app chưa có: huy hiệu/điểm thưởng, feed cộng đồng, thông báo đẩy.

Hiện trạng

Gamification: không dấu vết. Cộng đồng: 100% dummy. Notification: chỉ alert "đang phát triển"; không FCM/expo-notifications trong deps.

Việc cần làm (GĐ2, đứng trên dữ liệu tập trung H1)

Notification trước: thêm @react-native-firebase/messaging (thư viện mới — cần phê duyệt); xin quyền, lưu token theo user, foreground/background/tap-to-open; gửi từ Cloud Functions theo sự kiện
Gamification: schema badge/user_badge; engine xét thưởng server-side sau khi đã qua anti-cheat (H4) — không xét client; xếp hạng chỉ tính activity sạch
Cộng đồng: feed dựa trên activity đã đồng bộ, tôn trọng riêng tư per-activity; like/comment; kiểm duyệt tối thiểu
Cập nhật Firestore security rules cho collection mới (phối hợp H3)

Tiêu chí hoàn thành

Push nhận đủ 3 trạng thái app trên cả 2 OS; tap mở đúng màn
Activity đạt điều kiện → huy hiệu tự xuất hiện; gian lận điểm từ client bị rules chặn
Feed hiển thị đúng theo cài đặt riêng tư; báo cáo vi phạm hoạt động
Không còn alert "đang phát triển" ở luồng chính

Phụ thuộc / rủi ro

Phụ thuộc cứng H1 và chính sách H4. Rủi ro riêng tư: lộ trình sống qua GPS công khai — mặc định private, opt-in chia sẻ, ghi vào DPIA (H3).

H8Xuất dữ liệu chuẩn & sẵn sàng bàn giao (dữ liệu thuộc Sở)missing▶

Mục tiêu

Toàn bộ dữ liệu nền tảng xuất được theo định dạng chuẩn mở, không khoá vào schema nội bộ.

Vì sao cần

Câu hỏi đầu tiên cơ quan quản lý đặt ra với mô hình xã hội hoá; phải map được vào mô hình 5 lớp dữ liệu của đề án.

Hiện trạng

Chưa có gì — dữ liệu nằm trong SQLite/Firestore theo schema nội bộ, toạ độ lưu chuỗi JSON; chưa định dạng xuất, chưa công cụ xuất.

Việc cần làm

GĐ1 (làm cùng H1): rà schema Firestore một lần — đơn vị đo, WGS84, ISO 8601/UTC, version schema
GĐ2: đặc tả xuất chuẩn GPX 1.1 / GeoJSON (RFC 7946) cho dữ liệu track; JSON/CSV + data dictionary cho dữ liệu phi không gian; công cụ xuất server-side có nhật ký
GĐ3: quy trình bàn giao định kỳ cho Sở; read-API qua Gateway (H9) khi được cấp phép

Tiêu chí hoàn thành

(GĐ2) Xuất activity mẫu ra GPX/GeoJSON, mở đúng trên ≥2 công cụ GIS độc lập
(GĐ2) Kỹ sư ngoài dự án tái tạo được cấu trúc dữ liệu chỉ từ tài liệu (test "bàn giao được")
(GĐ3) Một đợt bàn giao/diễn tập hoàn tất trọn quy trình, có biên bản

Phụ thuộc / rủi ro

Phụ thuộc H1. Mốc GĐ1 phải cài vào review schema của H1 ngay — bỏ qua sẽ dẫn tới migration đau về sau.

H9Tầng tích hợp trung tâm: Integration Gateway & hạ tầng ngoài (Viettel IDC)missing▶

Mục tiêu

Khi hạ tầng ngoài có đặc tả chính thức, app đổi đích đến dữ liệu chỉ bằng cấu hình + một module trung gian, không sửa UI/hook.

Vì sao cần

Chọn Viettel IDC nằm ngoài văn bản đề án — phải trình bày là lựa chọn hạ tầng giai đoạn; app gọi thẳng API một nhà cung cấp sẽ mâu thuẫn nguyên tắc đã cam kết.

Hiện trạng

0 dấu vết Viettel/IDC/endpoint riêng; không có lớp network client ngoài Firebase SDK; đề án chưa có đặc tả API hạ tầng ngoài.

Việc cần làm

GĐ1: chỉ ghi nhận điểm neo kiến trúc (syncOneActivity là điểm duy nhất sẽ đổi đích) — không viết code gateway trước khi có đặc tả
GĐ3 (khi có đặc tả): util/sync_gateway.function.js với interface duy nhất pushActivity(payload), đích quyết định bằng remote config; yêu cầu tối thiểu backend: TLS 1.3, token từ IdentityProvider (H5), idempotency key = activity id, hợp đồng lỗi/retry; chiến lược dual-write/chuyển dần theo cohort

Tiêu chí hoàn thành (GĐ3)

Đổi đích sync Firestore → API ngoài (staging) bằng remote config, 0 dòng thay đổi hook/UI; đối soát 100% khớp trong dual-write
Hồ sơ gửi Sở trình bày Viettel IDC theo khung "lựa chọn hạ tầng giai đoạn, kiến trúc cho phép thay thế"

Phụ thuộc / rủi ro

Phụ thuộc cứng H1 và đặc tả API từ đội hạ tầng (ngoài phạm vi repo). Rủi ro trình tự: ép tích hợp trước khi H1/H3 xong sẽ đồng bộ dữ liệu chưa sạch/chưa bảo mật lên bên thứ ba — GĐ1 → GĐ3 không nén.

H10Quan trắc, Logging & Audit trailpartial▶

Mục tiêu

Đáp ứng yêu cầu Logging/Monitoring/audit trail của đề án; cung cấp nền quan sát cho mọi hạng mục khác.

Hiện trạng

Sentry cài nhưng DSN rỗng; App Check có; chưa audit trail dữ liệu.

Việc cần làm

GĐ1: bật Sentry thật (DSN qua biến môi trường build); breadcrumb luồng sync; quy tắc cứng: không đưa toạ độ GPS/dữ liệu cá nhân vào log (scrub trước khi gửi)
GĐ2: audit trail append-only cho thao tác nhạy cảm (xuất dữ liệu, admin cộng đồng, duyệt activity nghi vấn); dashboard tỉ lệ sync lỗi/activity gắn cờ
GĐ3: đổ log an ninh về SOC (cùng mốc H3)

Tiêu chí hoàn thành

(GĐ1) Crash thật xuất hiện trên Sentry ≤5 phút, event không chứa toạ độ
(GĐ2) Mọi lần xuất dữ liệu/thao tác admin có bản ghi audit không sửa được từ client

Phụ thuộc / rủi ro

Không có phụ thuộc chặn — nên làm sớm nhất GĐ1 vì mọi hạng mục khác cần nó để nghiệm thu. Rủi ro duy nhất: log rò dữ liệu cá nhân.

Bảng lộ trình tổng hợp theo giai đoạn

Giai đoạn 1 — Nền tảng dữ liệu & bảo mật cốt lõi

#	Hạng mục	Trạng thái hiện tại	Việc cần làm	Tiêu chí hoàn thành
H10	Quan trắc (bật trước)	Sentry cài, DSN rỗng	Bật Sentry, breadcrumb sync, scrub PII/GPS	Crash lên dashboard ≤5 phút, event không chứa toạ độ
H1	Pipeline sync GPS/activity	Chưa tồn tại	TASK 1–3 blueprint sync	Activity A đọc được ở B; offline→online tự sync; không trùng
H2	Chất lượng dữ liệu & hiệu năng	Buffer O(n²) plain-text	TASK 4–5 blueprint sync; dọn dead code	Phiên 8.000+ điểm O(1)/insert; chỉ SQLCipher; build sạch
H3	Bảo mật client-side	Key lộ, export mở	Restrict+rotate key, tắt export prod, ghi nhận TLS thực tế	Không còn secret chưa restrict
H4	Anti-cheat lớp 1	Chỉ `mock===true`	Bộ lọc vận tốc/teleport, gắn cờ metadata	≥90% gian lận cơ bản bị gắn cờ, 0 false positive
H5	Lớp IdentityProvider	Gọi thẳng Firebase Auth	Module trung gian + chặn import + Apple Sign-In	0 import auth SDK ngoài module; regression pass
H6	Nền bản đồ OSM + chủ quyền	Android ok, Route trắng, iOS lệch nguồn	Thống nhất OSM, tile SLA, layer chủ quyền	Cùng nguồn 2 OS; biên bản chủ quyền duyệt trước phát hành
H8	(Ràng buộc) schema tự mô tả	Chưa có	Rà schema H1: đơn vị, WGS84, ISO 8601	Review schema H1 có mục kiểm, ký duyệt

Giai đoạn 2 — Mở rộng tính năng & hệ sinh thái

#	Hạng mục	Điều kiện vào GĐ2	Việc cần làm	Tiêu chí hoàn thành
H6	Màn Route đầy đủ	Nền OSM đã thống nhất	16 TASK `upgrade_01_route.md`	Tạo route → realtime thiết bị khác; nối sang Run tracking
H7	Notification→Gamification→Cộng đồng	Chưa có/dummy	FCM (thư viện mới); engine huy hiệu server-side; feed thật	Push đủ 3 trạng thái; gian lận điểm bị rules chặn
H4	Anti-cheat lớp 2 + Trust Score	Lớp 1 chạy, H1 xong	Phân tích sau-đồng-bộ; công thức Trust Score	Kết quả phân xử ≤5 phút; xếp hạng chỉ nhận activity sạch
H3	Hồ sơ Cấp độ 3 + pentest	Client-side sạch	Hồ sơ TT 12/2022 + DPIA; pentest độc lập	0 finding High/Critical mở; 0 sai lệch hồ sơ↔code
H8	Xuất dữ liệu chuẩn	Schema tự mô tả	GPX 1.1/GeoJSON + data dictionary	File mở đúng trên ≥2 công cụ GIS
H10	Audit trail	Sentry chạy	Log append-only cho thao tác nhạy cảm	Mọi thao tác nhạy cảm có bản ghi không sửa được

Giai đoạn 3 — Sẵn sàng tích hợp mở rộng

#	Hạng mục	Điều kiện kích hoạt	Việc cần làm	Tiêu chí hoàn thành
H9	Integration Gateway → Viettel IDC	Có đặc tả API chính thức	`sync_gateway` interface duy nhất, remote config	Đổi đích bằng config, 0 thay đổi hook/UI
H5	Đấu nối OIDC/VNeID	Có đặc tả VNeID	OIDC Authorization Code + PKCE	Demo OIDC ngoài không sửa file ngoài module
H3	SOC + DRP vận hành	Backend riêng chạy	Đổ log SOC; diễn tập DRP	Biên bản đạt RTO/RPO
H8	Bàn giao dữ liệu cho Sở	Công cụ xuất đã có	Quy trình giao nhận, biên bản	Một đợt bàn giao/diễn tập hoàn tất
H4	Anti-cheat "AI" đúng nghĩa	Đủ dữ liệu GĐ1–2	Anomaly detection thay heuristic	Mô hình đánh bại heuristic trên tập kiểm định

Sơ đồ phụ thuộc giữa các hạng mục

H10 (quan trắc) ──── nền đo lường cho tất cả, làm đầu tiên
H2 (lọc accuracy) ──┐
                    ├──► H1 (sync pipeline) ──┬──► H4 lớp 2 + Trust Score ──► H7 (xếp hạng/thưởng)
H8 (schema chuẩn) ──┘                         ├──► H7 (feed/gamification/notification)
                                              ├──► H8 (công cụ xuất → bàn giao GĐ3)
                                              └──► H9 (gateway → Viettel IDC)
H5 (IdentityProvider GĐ1) ──► H9 (token cho API ngoài) ──► H5 (VNeID GĐ3)
H6 (nền OSM + chủ quyền GĐ1) ──► H6 (Route đầy đủ GĐ2, dùng lại pattern isSync của H1)
H2 (buffer → SQLCipher) ──► H3 (cam kết AES-256 đúng 100%) ──► H3 (pentest GĐ2) ──► H3 (SOC/DRP GĐ3)

Đường găng (critical path): H1 → H4 lớp 2 → H7 và H1 → H9. Mọi trượt tiến độ ở H1 đẩy lùi toàn bộ GĐ2/GĐ3 — H1 là hạng mục duy nhất không được chạy song song với việc khác của cùng người phụ trách.

Rủi ro cấp lộ trình & giảm thiểu

Rủi ro	Ảnh hưởng	Giảm thiểu
Hồ sơ gửi Sở cam kết vượt thực tế code	Pentest/thẩm định phát hiện sai lệch → mất uy tín toàn đề án	Nguyên tắc điều hành số 2; checklist đối chiếu ma trận mục 2 trước mỗi lần phát hành
Phát hành bản đồ OSM chưa qua rà soát chủ quyền	Rủi ro pháp lý theo Luật Đo đạc và Bản đồ, có thể bị xử lý/gỡ app	Rà soát chủ quyền vào checklist phát hành bắt buộc từ GĐ1
Ép tiến độ Viettel IDC trước khi H1/H3 xong	Đồng bộ dữ liệu chưa sạch/chưa bảo mật lên bên thứ ba	Quy tắc chuyển giai đoạn; trình tự GĐ1→GĐ3 không nén
Đặc tả ngoài (VNeID, API Viettel IDC) trễ	Hạng mục GĐ3 treo	Tiêu chí GĐ3 đo bằng demo chuẩn mở, độc lập tiến độ nhà nước
Trôi kiến trúc khi phát triển song song	Nợ tích luỹ phá 2 điểm nối duy nhất (H5, H9)	Rule review/lint chặn import trực tiếp; PR chạm auth/sync qua tech lead
Chi phí Firestore & tile server tăng theo user	Ngân sách vận hành (doanh nghiệp tự đầu tư)	Batch sync tuần tự; chốt tile provider có SLA sớm; theo dõi qua H10
False positive anti-cheat làm mất user thật	Uy tín cộng đồng, khiếu nại lên Sở	"Gắn cờ, không xoá" + quy trình khiếu nại; Trust Score có tài liệu giải trình
Xoá dead code/refactor auth chạm chỉ thị CLAUDE.md	Vi phạm quy trình nội bộ	Mọi đợt xoá/refactor lập danh sách cụ thể, báo user phê duyệt trước

Cách dùng tài liệu này để lập sprint

Chọn hạng mục theo giai đoạn và đường găng: sprint đầu tiên của GĐ1 nên là H10 (bật Sentry — nửa ngày) + H1 TASK 1 (bug lệch nguồn, độc lập, giá trị ngay) + khởi động H1 TASK 2–3.
Hạng mục đã có blueprint (H1, H6-Route): lấy TASK trong blueprint làm ticket trực tiếp.
Hạng mục chưa có blueprint (H4 lớp 2, H5, H7, H8): viết blueprint chi tiết theo format upgrade_0x_*.md trước khi code — tài liệu này cung cấp mục tiêu và acceptance criteria làm đầu bài.
Nghiệm thu: một hạng mục chỉ "xong" khi toàn bộ checkbox tiêu chí hoàn thành được tick kèm bằng chứng — và ma trận mục 2 cập nhật trạng thái tương ứng.
Khi hồ sơ gửi Sở thay đổi: đối chiếu câu cam kết mới với ma trận mục 2; nếu chưa có hạng mục đỡ, bổ sung hạng mục trước, phát hành hồ sơ sau.