Hiểu hệ thống SSA

Xây Mini App bằng React + TypeScript + ZaUI + zmp-sdk, phát hành bundle qua nền tảng Zalo. Luồng được chọn: Zalo Mini App → VPS reverse proxy tại Việt Nam → Cloudflare API Worker → D1/R2. Admin, import API, tác vụ giao dịch, lưu trữ và các lớp bảo vệ ứng dụng dùng Cloudflare; Airflow điều phối đồng bộ trên môi trường VPS tại Việt Nam, tách khỏi tiến trình proxy. Không dùng Apps Script trong hệ thống đích. Cloudflare không thay quy trình kiểm duyệt/phát hành Mini App của Zalo.

Có hai điều kiện phải giải quyết trước khi đưa dữ liệu thật lên production:

1. Địa điểm dữ liệu. Feedback yêu cầu Việt Nam và điều khoản Zalo vẫn có yêu cầu đó. D1, R2, Queues và Workers cấu hình thông thường chưa cung cấp bằng chứng bảo đảm toàn bộ xử lý/lưu trữ tại Việt Nam. Thiết kế Cloudflare đầy đủ bên dưới là phương án A có điều kiện; chưa đủ cơ sở gọi là production compliant. [Z10, C01-C05, C13]
2. Cửa hàng và thanh toán. Yêu cầu ngày 12/11 chọn hướng merchandise có giá/đơn và Checkout SDK. G1 nay cần chốt provider/merchant, cách nhận hàng, hủy/hoàn, settlement và điều kiện duyệt Zalo; không còn là câu hỏi có bổ sung module thanh toán hay không. Chi tiết FEATURES §7.

Đây là các điểm chưa chốt của triển khai, không ngăn việc hoàn thành kế hoạch. Không yêu cầu SSA đăng ký tài khoản lại. Dùng tài khoản đã có và kiểm tra đúng App ID, OA, quyền, chủ thể sở hữu khi bắt đầu thực hiện.

1.1 Phương án kiến trúc

Trong B, hostname API dùng DNS-only trỏ trực tiếp origin Việt Nam; không mặc nhiên đặt Cloudflare proxy/Tunnel/Worker trước PII. TLS termination, logs, IP metadata và nhà cung cấp email cũng phải nằm trong hồ sơ xử lý. Nếu muốn bật proxy/Access cho luồng nhạy cảm, cần rà soát điều kiện địa điểm riêng. Một DB tại Việt Nam phía sau Worker toàn cầu không giải quyết toàn bộ yêu cầu.

1.2 Các quyết định thiết kế đề xuất

Phát hiện cụ thể trong HTML: Qv trả session mau, Jv trả bản sao dữ liệu mẫu, zc là hàm rỗng; w0 tự mở demo. Nhãn “Dữ liệu mẫu · chưa nối máy chủ” xác nhận mục đích. CSS ban đầu có repeat(3,1fr) nhưng có override repeat(4,1fr) phía sau; render mobile xác nhận 4 tab cùng hàng. Giữ layout cuối và loại bỏ CSS dư khi tái cấu trúc. Không lấy các tên/số mẫu làm hồ sơ thật, không đẩy HTML nguyên trạng lên production.

2.1 Những thứ cần nhận trong giai đoạn discovery

Source ZIP/frontend; package/lockfile; app-config; cấu hình Airflow/VPS và tên biến môi trường không chứa giá trị secret; tài liệu hoặc 10 file Apps Script cũ chỉ nếu cần hiểu mapping nguồn, không phải phụ thuộc triển khai; mapping sheet có kiểu dữ liệu; Excel đã ẩn danh của từng loại và trường hợp lỗi; PDF mẫu; quy tắc 6 kỹ năng/5 mức; quyền chỉnh sửa hiện tại; danh sách quan hệ phụ huynh đã xác minh; quy tắc gia hạn/bảo lưu/học bù; trạng thái App ID/OA/quyền phone; domain sở hữu SSA; mẫu chính sách/consent; giờ trực và đầu mối vận hành.

Không gửi key thật qua chat hoặc commit. Khi nhận source: hash archive, scan secrets/dependencies, inventory từng endpoint/trigger, review cùng fixture ẩn danh. Nếu source không nhận được, dự toán lại phần rebuild; không hứa “reuse toàn bộ”.

MVP baseline bao gồm khảo sát và admin tối thiểu. Phạm vi bổ sung ngày 12/11/2026 bao gồm FR-13…FR-18; phải tính lại kế hoạch và nghiệm thu, chưa phải tính năng đang chạy. Kênh ZBS chỉ bật khi quyền/template và chi phí được duyệt. AI rewrite vẫn tùy chọn; chat riêng, mạng xã hội, LMS, MISA API, đa học viện SaaS và push tự do không thuộc phạm vi.

Đặc tả màn hình, trạng thái, schema/API bổ sung và T17–T21 nằm trong FEATURES §7, được nhúng trong chương này của bản HTML. Đây là mở rộng được yêu cầu, không phải xác nhận triển khai.

Sơ đồ: context

4.1 Ranh giới và thành phần phương án A

DNS/domain minh họa: api.<domain-SSA>, admin.<domain-SSA>, docs.<domain-SSA>; không phải tên đã đăng ký. Frontend Mini App vẫn được upload Zalo, không trỏ người dùng sang website Cloudflare để đăng nhập. Admin và tài liệu có thể dùng Workers Static Assets; Pages là lựa chọn tương đương cho static nếu đội đã có quy chuẩn. Không cần vận hành cả Pages lẫn Static Assets cho cùng một UI.

D1 chỉ là lựa chọn kỹ thuật có điều kiện G0. Giới hạn Paid 10 GB/DB, thực thi từng DB single-threaded: dùng index, pagination, batch; không suy từ 650 phụ huynh ra khả năng chịu tải. Không bật read replicas ngay; nếu bật, phải kiểm chứng read-after-write và tuyệt đối không dùng dữ liệu quyền cũ. [C07]

Không dùng KV cho session revocation, guardian relation, order status hoặc idempotency do cần nhất quán. Durable Objects chỉ bổ sung nếu cần điều phối singleton/token-refresh theo App/OA; không biến thành nguồn dữ liệu thứ hai. Workers AI không thay thế Claude mặc định: cả hai đều phải qua đánh giá nội dung, nơi xử lý và consent.

4.2 Cấu trúc code dự kiến

apps/miniapp/       React, ZaUI, routes, Zalo SDK adapter
apps/admin/         nhân sự SSA, review/import/support
workers/api/        HTTP và auth middleware
workers/import/     validation, staging, publish
workers/jobs/       outbox, notification, scheduled tasks
packages/domain/    quyền, rule nghiệp vụ, state transitions
packages/contracts/ schema request/response, errors, generated clients
packages/storage/   repository ports + D1 adapter (A), PostgreSQL adapter (B)
packages/importers/ mapping MISA/Coach versioned, fixture ẩn danh
migrations/         schema versioned, forward-compatible
infra/              cấu hình từng environment, secret names
runbooks/           sự cố, restore, phát hành, thu hồi quyền
tests/              integration, security, migration, E2E, load

TypeScript dùng chung ở client/Worker; tách domain khỏi env.DB để phương án B có thể chạy Node LTS + PostgreSQL tại Việt Nam mà không viết lại nghiệp vụ. D1/SQLite và PostgreSQL không dùng nguyên một SQL migration; adapter phải có integration contract tests. Không khóa version SDK/Vite theo DOCX cũ: thử build source nhận được, chọn tổ hợp được Zalo hỗ trợ, commit lockfile, lưu version toolchain và compatibility date.

4.3 Phương án B nếu gate A không đóng (chưa được chọn)

Sơ đồ: hybrid

API Node/TypeScript và job worker chạy tại nhà cung cấp Việt Nam; PostgreSQL giữ dữ liệu/quyền/outbox; object storage có cam kết Việt Nam; job runner dùng outbox PostgreSQL và lease, chưa cần Redis. TLS terminate tại VN, origin WAF/rate limits, admin OIDC/identity có đánh giá nơi xử lý. Backup sang tài khoản/điểm lưu độc lập tại Việt Nam. Cloudflare DNS/public site vẫn được dùng; không đưa thông tin định danh vào public assets, analytics hay URL. Đây là thay đổi hạ tầng có thật, phải dự toán vận hành/patching; không gọi nó là “all Cloudflare”.

4.4 VPS proxy, Airflow và ranh giới triển khai được chọn

Luồng phụ huynh: Mini App → HTTPS api.<domain-SSA> tại VPS Việt Nam → HTTPS origin Cloudflare → API Worker → D1/R2. Domain API cho Zalo trỏ DNS-only tới VPS; hostname origin Cloudflare được bảo vệ riêng. Đây là sơ đồ logic đề xuất, chưa phải domain/console đã kiểm chứng. Admin có identity riêng và đường vào được hạn chế; không dùng một session chung với phụ huynh.

Cloudflare WAF/rate limiting bảo vệ origin Cloudflare; request đã tới VPS trước khi tới Cloudflare, nên không được tuyên bố Cloudflare bảo vệ mọi cuộc tấn công vào ingress VPS. VPS cần firewall/provider DDoS phù hợp, OS patching, TLS rotation, giới hạn body/timeouts/concurrency, egress allowlist khi khả thi, health checks, monitoring và phương án thay thế/khôi phục cấu hình. Một VPS là single point of failure; trước live phải chốt standby hoặc chấp nhận rủi ro kèm RTO đã đo. Không tự retry POST sau timeout nếu chưa tra idempotency key.

Bảo vệ origin fail-closed: cấu hình service identity hoặc chữ ký request proxy→origin (timestamp, nonce, method, path và body digest; cửa sổ replay có giới hạn); Worker xác minh trước khi xử lý. Không chỉ dựa vào header tĩnh dễ sao chép, CORS hoặc giấu URL. Nếu dùng Cloudflare Access service token, phải thử tương thích với route Worker và tiếp tục kiểm role/phạm vi tại ứng dụng. Vô hiệu hóa đường public bypass như route workers.dev không được bảo vệ. VPS xóa header giả từ client trước khi đặt forwarding metadata; tin forwarded IP chỉ từ proxy đã xác minh. TLS được kiểm chứng ở cả hai chặng; không dùng chế độ bỏ kiểm certificate. Không log query/token/body chứa dữ liệu trẻ.

Airflow là control plane đồng bộ, không là API public cho Zalo. Scheduler, UI, metadata DB và executor nằm trong mạng quản trị riêng tại Việt Nam; tách service account, tài nguyên và secrets khỏi proxy (hai VPS hoặc isolation tương đương cần benchmark). Metadata DB của Airflow phục vụ scheduler, không thay D1 là database nghiệp vụ. Không đặt hồ sơ trẻ/raw Excel trong XCom hoặc log task: truyền object reference, hash và batch ID. Chốt phiên bản Airflow/provider tương thích qua lockfile/container digest khi triển khai, không khóa bản chưa thử build.

DAG đề xuất: detect_source → register_file → trigger_import → wait_validation → reconcile → wait_approval → request_publish → verify_generation → notify_ops. MISA vẫn xuất Excel theo lịch của SSA; connector chỉ dùng nguồn đã được cấp quyền, chưa có bằng chứng MISA API. Có thể upload vào private object storage qua admin rồi Airflow nhận manifest; không đưa lại Apps Script/Sheets thành dependency. Trigger import bằng service principal scope theo dataset/sân, qua endpoint nội bộ có auth; response trả batch ID để sensor theo dõi. API server giữ rule validation, CAS và publish; DAG không được ghi trực tiếp D1 hoặc tự mở gate duyệt.

DAG run gắn dag_id/run_id, source hash, mapping version, scope, source date, batch ID và generation. File trùng/sensor chạy lại phải dùng cùng idempotency key; retry không đổi business key. Chặn hai publish cùng scope bằng lease/fencing và CAS trong backend, không chỉ bằng max_active_runs. Catchup/backfill có cửa sổ và phê duyệt, giữ delta history; DAG lỗi phải giữ snapshot đang active, cảnh báo và replay đúng task. Không dùng lịch Airflow để gửi từng đơn hay email giao dịch: outbox + Queues/Cron tiếp tục đảm nhận các side effect đó.

Điểm kiểm chứng trước live: trace Zalo→VPS→Worker thành công; truy cập origin trực tiếp bị chặn; giả forwarding header và replay chữ ký bị từ chối; proxy chết có cảnh báo/failover; Airflow retry/backfill không trùng batch; task logs/XCom không PII; scheduler metadata backup/restore và patching có owner. Tham chiếu thiết kế Airflow: A01, A02. Origin routing và service credentials: [C15, C16]. Toàn bộ Cloudflare data services vẫn thuộc G0: VPS tại Việt Nam không làm dữ liệu D1/R2/Queues tự có residency Việt Nam.

Nguồn sự thật nghiệp vụ được phân theo field, không tuyên bố một hệ thống sở hữu mọi thứ. MISA sở hữu số liệu gói/lớp và điểm danh nhập; SSA xác minh liên kết giám hộ; hệ thống mới sở hữu đơn/lead, survey, read receipts, consent và audit. Cập nhật MISA không được ghi đè consent/quyền/order.

Sơ đồ: data-core

5.1 Mô hình quan hệ chính

guardian_student_links không tự được upsert thành verified chỉ vì Excel có cùng số. Import mới tạo candidate, đối chiếu hồ sơ ghi danh, người có thẩm quyền duyệt. Quan hệ đã revoked không tự hồi sinh sau import. Đổi số phải kiểm chứng lại và thu hồi sessions liên quan; không tự chuyển quyền sang người đang sở hữu số tái cấp.

5.2 Nghiệp vụ phụ huynh và thông báo

Sơ đồ: commerce-data

Index tối thiểu: links(guardian_id,status,student_id), attendance(student_id,session_date DESC), reports(student_id,status,period), recipients(guardian_id,published_at), orders(guardian_id,created_at), outbox(status,due_at), import_rows(batch_id,row_no). Foreign key checks phải bật/kiểm chứng trong migration tests. Tiền là integer VND; timestamp UTC, ngày học và lịch gửi dùng Asia/Ho_Chi_Minh. SĐT chuẩn hóa +84 theo số hợp lệ, không cắt/ghép tùy tiện hoặc làm mất số 0 từ Excel.

ERD đơn và thanh toán / ERD settlement: mô hình logic mở rộng, chưa phải migration triển khai.

5.3 Ma trận trao đổi dữ liệu giữa ứng dụng

5.4 Công thức cần chốt bằng fixture

Chuyên cần đề xuất = số buổi Có mặt / số buổi theo lịch đủ điều kiện trong kỳ; Có phép không tự bằng Có mặt. Phải chốt có loại trừ buổi hủy và cách tính học bù. Số buổi còn lại lấy snapshot MISA được duyệt, không tự tính từ bảng attendance khi quy tắc bảo lưu/gia hạn chưa rõ. So sánh 6 kỹ năng chỉ giữa cùng rubric version; thiếu điểm hiển thị “Chưa đánh giá”, không đổi thành 0. Hai bản nhận xét cùng tháng cần revision và bản published duy nhất.

Sơ đồ: auth

1. Người dùng xem onboarding giải thích mục đích và chính sách. Chỉ sau hành động chủ động mới xin phone permission. Từ chối: màn hình hướng dẫn/hỗ trợ, không tự đóng app.
2. Client lấy access token từ SDK, gửi server; server gọi profile API với appsecret_proof = HMAC-SHA256(access_token, AppSecret) theo tài liệu chính thức. Chỉ yêu cầu trường cần thiết như ID. Không tin UID/name do client tự khai. [Z07]
3. Khi cần liên kết hồ sơ: getPhoneNumber() trả token; backend gọi GET https://graph.zalo.me/v2.0/me/info với headers access_token, code (phone token), secret_key của cùng app. Token dùng một lần, hết hạn sau 2 phút; nếu timeout không biết đã đổi thành công hay chưa, xác minh kết quả login theo nonce hoặc yêu cầu token mới, không retry token cũ vô hạn. Không gửi App Secret về client. Token sai/hết hạn/mismatch phải fail closed; không fallback sang nhập số để tự mở dữ liệu. [Z08]
4. Chuẩn hóa số đã xác thực; tra candidate contact; cần link verified hiện hành. Không trả tên trẻ để “gợi ý chọn” khi chưa đủ quyền. Hồ sơ chưa khớp tạo support case với thông tin tối thiểu.
5. Tạo guardian identity theo (app_id, zalo_user_id), cấp session ứng dụng. Backend trả danh sách trẻ được phép và phiên bản quyền, không trả toàn bộ data Sheet.
6. Mọi request/file/deeplink kiểm tra session còn hiệu lực và link chưa revoked. Xóa cache riêng khi đổi con/logout/revoke. Thu hồi không phụ thuộc thời hạn token 30 ngày.

Session đề xuất: access token ứng dụng 15 phút; rotating refresh/opaque session tối đa 7 ngày, idle 24 giờ; đây là policy khởi điểm phải thử UX Zalo. Khi hết phiên ưu tiên tái xác thực nền bằng SDK nếu quyền còn hợp lệ, tránh bắt người dùng đăng nhập lại thủ công trái trải nghiệm liên kết. Refresh token hash lưu server; rotation single-use, replay thu hồi chain. Không lưu PII trong JWT. Mini App storage adapter dùng khả năng SDK được hỗ trợ; không giữ hồ sơ trẻ offline lâu dài. Với trình duyệt demo chỉ fixture; không fallback sang session production giả.

6.1 Ma trận quyền

Admin authentication tách parent flow, MFA/SSO và deny-by-default backend. Cloudflare Access ở A chỉ là lớp cửa vào: Worker vẫn kiểm chứng JWT audience/issuer và role nghiệp vụ. Không tin header tự đặt hoặc UI ẩn nút. Với B chọn giải pháp identity phù hợp địa điểm, không tự đẩy tên/email nhân sự sang dịch vụ chưa duyệt.

6.1a Quyền merchandise và tài chính bổ sung

Backend kiểm role, scope, người lập/người duyệt và version ở mỗi lệnh; điều chỉnh bằng bản ghi liên kết. Quyền giao diện không thay quyền server. Hoàn tiền / Đối soát.

Sơ đồ: import

MISA vẫn do SSA xuất Excel hằng ngày; không hứa realtime hoặc tự động truy cập MISA. Phương án đích: Airflow điều phối nhận manifest/file từ nguồn đã duyệt, gọi Import Worker qua API có quyền và theo dõi batch đến publish. Nhân sự upload qua admin khi chưa có connector phù hợp. Không dùng Apps Script, không đồng bộ qua Sheet production; Drive chỉ là nguồn file nếu SSA chủ động chọn và gate dữ liệu cho phép. Chi tiết orchestration tại §4.4.

7.1 Pipeline

Quy tắc duyệt khởi đầu đề xuất cho MVP: mỗi batch/generation đều cần người có quyền của SSA duyệt bản đối soát trước publish, kể cả batch không vượt ngưỡng cảnh báo. Bất thường phải được giải thích/xử lý trước khi duyệt. Airflow dừng chờ approval; service principal không được tự tạo approval hoặc bypass. SSA phải bố trí người duyệt theo lịch nhập; thời điểm công bố phụ thuộc file và approval. Sau pilot có thể đề xuất tự động hóa batch bình thường nhưng cần quyết định mới, test và policy version riêng; chưa nằm trong phạm vi tự động publish hiện tại.

1. Upload: role đúng, giới hạn kích thước/số dòng đề xuất 10 MB/50.000 dòng sau khi benchmark; chỉ .xlsx/CSV mapping đã cho phép, kiểm tra nội dung thực. Lưu private object key và hash, không lấy filename người dùng làm path.
2. Quarantine: kiểm tra ZIP bomb, archive expansion, macro/embedded links, formula cells; không thực thi formula và không fetch URL từ workbook. Parser được pin version, scan dependency. File quá lớn chuyển luồng batch, không vượt memory/CPU Worker.
3. Classify: loại HocVien/LienHePH/DiemDanh/Coach; required headers, mapping version, source effective date, timezone, campus scope. Giữ row_no để truy ngược.
4. Validate: duplicate business key, phone invalid, missing FK, unknown campus, negative sessions, total<used, future dates, kỳ sai. Tách warnings khỏi hard errors; không nuốt lỗi để import “thành công”.
5. Stage: ghi generation mới theo chunks idempotent, chưa chuyển active pointer. Giữ count/read hash từng chunk. Job chết giữa chừng resume cùng batch.
6. Reconcile: source count = accepted + rejected; distinct students; attendance by status; diff remaining per student; records removed; contacts changed; tổng theo sân; review mọi delta bất thường. Ngưỡng đề xuất: giảm >20% số trẻ hoặc thay remaining >5 buổi hàng loạt phải duyệt, không coi ngưỡng là đúng nghiệp vụ mặc định.
7. Publish: trong transaction/batch atomic chỉ chuyển manifest active từ expected old generation sang new, ghi audit và outbox import-published. Không tạo side effect email trước commit.
8. Derived notifications: chỉ sau publish và nguồn đủ mới. Event key gồm loại+student+session/package/report revision để dedupe; import lại không gửi lần hai. Source sửa “Vắng” thành “Có mặt” tạo correction, không xóa dấu vết.
9. Archive: giữ raw và normalized reference theo retention; hiển thị source_as_of và imported_at riêng. Import mới không biến timestamp file cũ thành dữ liệu mới.

Snapshot atomic áp dụng dữ liệu MISA; orders/consent/links/read receipts không bị đảo về generation cũ. Mỗi API request giữ cùng dataset generation khi đọc nhiều bảng. Không dùng “batch từng chunk đã commit” như bằng chứng atomic của toàn file. Hai import chạy cùng scope dùng lease + fencing/version; publish CAS ngăn worker cũ overwrite worker mới. Reject file cũ hơn source date trừ thao tác backfill có lý do.

7.2 Full snapshot và delta theo dataset

Generation là ảnh đọc hoàn chỉnh sau hợp nhất, không mặc định đồng nghĩa với một file upload. Batch bắt buộc ghi dataset, input_mode, scope sân/lớp, kỳ hiệu lực, base generation và mapping version; không đoán full/delta từ tên file.

Full replacement của attendance chỉ được phép với scope/window được đánh dấu complete và được SSA duyệt; giữ mọi dòng ngoài window. Xóa/cancel là tombstone hoặc correction có lý do, actor, audit và review, không suy ra từ dòng thiếu. Backfill lịch sử không làm mất các ngày mới hơn. Khi base generation thay đổi trước publish, CAS thất bại; phải hợp nhất/reconcile lại trên base mới, không chỉ đổi expected version rồi publish staging cũ. G2/G3 xác nhận grain và mode thực tế trước triển khai.

Acceptance fixture bắt buộc cho T04: import ngày 1 có học viên A/lớp X; import delta ngày 2 của A/X phải trả cả ngày 1 và ngày 2. Gửi lại delta không nhân đôi; sửa trạng thái ngày 1 chỉ cập nhật đúng business key, giữ ngày 2 và audit correction. Thêm fixture scope sân khác, tombstone được duyệt và CAS conflict để chứng minh không mất lịch sử.

7.3 Xử lý lỗi điển hình

Giữ nhận diện vàng #FFC20E, đen #111113, nền sáng, cách trình bày học viên và 4 tab của template. Không coi font online sẵn có: self-host font có license hoặc system fallback; không tải font bên ngoài vào Mini App chưa được kiểm tra. ZaUI dùng cho Page/Header/BottomNavigation/Sheet/Modal/Toast/Form; nội dung báo cáo giữ thiết kế SSA. Không bắt buộc thay mọi component chỉ để “thuần ZaUI”. [Z02]

Khảo sát mở từ home và thông báo, không cần tab thứ năm. Chọn trẻ phải reset query key theo guardian+student; không giữ phiếu con trước trong lúc con mới đang loading. Back button native, safe areas, bàn phím, text scaling, bottom nav 4 cột và tap target khoảng 44 px phải kiểm tra trong Zalo iOS/Android. Loading không chỉ spinner vô hạn: có timeout thông điệp/retry. Mutation retry cùng idempotency key; không hiện “thành công” trước response server.

PDF: backend authorize và trả file/proxy hoặc URL ngắn hạn phù hợp SDK openDocument; kiểm chứng headers/redirects/thời hạn trong thiết bị thật. URL ký vẫn là bearer link có cửa sổ chia sẻ; ưu tiên URL hạn ngắn và không ghi analytics, có đánh giá rủi ro thu hồi. Không dùng link Drive public, không cho phép arbitrary external URL trong thông báo.

8.1 Quyết định cửa hàng (G1)

Merchandise / Checkout sequence / Hoàn tiền

C1 là hướng được chọn theo yêu cầu 12/11/2026: chỉ triển khai production sau khi Zalo xác nhận mô hình hoặc tích hợp Checkout được duyệt. Giữ schema orders/price snapshots. Trong phạm vi thanh toán mới phải bổ sung provider order ID, callback chữ ký, pending/paid/failed/refunded, reconciliation, refund support và dự toán riêng; client callback không xác nhận đã trả tiền.

C2 chỉ còn là dự phòng khi SSA quyết định đổi phạm vi: catalog không giá, CTA “Đăng ký tư vấn”; lưu consultation_request với size/màu/số lượng/trẻ, Sale liên hệ báo giá và thu tiền theo quy trình ngoài app. Không dùng total/đã thanh toán trong UI. Đây là thay đổi so với L01/L03, phải SSA chốt; không âm thầm bỏ giá trong scope.

Prototype hiện là C1 mock, có nhãn dữ liệu mẫu; không gọi là checkout đã hoạt động. G1 chỉ đóng sau khi chốt cấu hình/provider và kiểm duyệt phù hợp. Không dùng feature flag bí mật để bật lại giá sau kiểm duyệt.

API version /v1; response {data, meta:{requestId,sourceAsOf,importedAt,generation}}; lỗi {error:{code,message,retryable},requestId}. Dùng HTTPS JSON đúng MIME, CORS allowlist origin thực quan sát trong Zalo; không dùng wildcard với credentials. CORS không phải authorization. Rate limit theo session/identity và IP với ngưỡng theo test, tránh khóa cả phụ huynh chung NAT. Không trả stack trace.

Errors: UNAUTHENTICATED 401, FORBIDDEN/NOT_FOUND không lộ tài nguyên, LINK_PENDING 409, VALIDATION_FAILED 422, VERSION_CONFLICT 409, RATE_LIMITED 429 + Retry-After, SOURCE_STALE metadata/read warning, SERVICE_UNAVAILABLE 503. Write timeout có thể đã commit: client query theo key, không tạo key mới tự động.

Các action Apps Script trong proposal (dangNhap, duLieu, daDoc, datHang, guiKhaoSat) chỉ dùng đối chiếu nghiệp vụ; không xây adapter GAS runtime hoặc transition test bắt buộc phụ thuộc GAS. Endpoint duLieu trả mọi thứ cần tách pagination. Các action dangNhapThu, timHocVien, xemNhu, gopY phải bị loại khỏi production routing, không chỉ ẩn nút. Nếu giữ support impersonation sau này phải riêng role/timebound/audit và thông báo rõ.

Sơ đồ: order

Khi tạo order/consultation: kiểm quyền và validate → transaction ghi header + lines + idempotency response + outbox → commit → trả ID. Email/ZBS thất bại không rollback đơn đã tồn tại. Cùng key/cùng payload trả lại kết quả cũ; cùng key/khác payload trả 409. Chốt thời gian giữ key đề xuất 30 ngày; không reuse sau timeout.

D1 dùng batch transactional phù hợp API đã chọn [C14]; không giả định có transaction dài qua nhiều await. Sinh ID trước, insert có constraint, kiểm tra affected rows/version trong cùng cơ chế atomic; test hai request cạnh tranh. Nếu logic bắt buộc read-modify-write phức tạp, dùng conditional SQL/state version hoặc thiết kế lại, không giữ lock tưởng tượng ở Worker. Trong B dùng PostgreSQL transaction ngắn.

Outbox poller chọn pending/due, claim bằng lease/version rồi enqueue event ID. Nếu chết sau enqueue nhưng trước marked sent, có thể gửi queue lần nữa; consumer dedupe theo delivery key. Queue chứa reference và loại event, không raw phone/nhận xét. Gửi thành công rồi crash trước lưu provider result vẫn có nguy cơ duplicate external delivery: dùng provider idempotency/query status nếu có; nếu không, chuyển ambiguous/manual review, không hứa exactly-once. [C06]

Retry đề xuất exponential backoff + jitter cho timeout/429/5xx; respect Retry-After, tối đa 5 lần/24 giờ trước DLQ; lỗi quyền/template/recipient invalid dừng ngay và báo owner. Scheduled notification giữ due_at trong DB, Cron enqueue khi đến hạn; không dựa vào delay queue dài tùy ý. Recheck cancelled/revoked/source freshness trước gửi. Quiet hours đề xuất 20:00-07:00, trừ tin khẩn được SSA duyệt. Lưu provider message ID, attempt, trạng thái accepted/delivered/failed tách read trong app.

Sơ đồ: delivery

Sơ đồ: report

Coach file → validate 6 skill IDs và 1-5 → draft có original text → rewrite tùy chọn → người duyệt so sánh → published revision → PDF và notification. Không sửa điểm bằng AI. Mỗi lần rewrite lưu prompt/model/version, input hash, output và reviewer; input chứa nội dung đã giảm định danh, không gửi tên/phone/campus nếu không cần. Văn bản tự do vẫn có thể nhận dạng trẻ; pseudonym không đồng nghĩa anonymized.

Mặc định khi chưa có cơ sở chuyển dữ liệu/consent: tắt outbound AI, người thật duyệt thủ công. Timeout AI không chặn import điểm; output lỗi giữ draft. Prompt injection trong file là dữ liệu, không được cấp tool/network quyền từ nội dung Coach. Kiểm tra hallucination, đổi nghĩa, đánh giá tiêu cực/quá mức, lộ dữ liệu giữa học viên bằng fixture. Mục tiêu đề xuất 0 thay đổi điểm và không thêm sự kiện không có trong input; người duyệt chịu trách nhiệm cuối.

Khảo sát: khóa question version lúc nộp; 8 điểm bắt buộc trong 1-5, 2 câu mở theo mức bắt buộc SSA chốt, giới hạn độ dài và sanitize rendering. Điểm thấp đề xuất bất kỳ câu ≤2 → care task; threshold phải owner duyệt. Email chỉ chứa task ID/link admin, không copy câu trả lời nhạy cảm. Tổng hợp theo campus enrollment tại thời điểm submission; suppress nhóm quá nhỏ theo policy được duyệt để tránh nhận dạng. Không show câu trả lời của bố cho mẹ mặc định. Thay đổi câu trả lời sau nộp nếu cho phép phải revision và audit, không nhân đôi care event.

Sơ đồ: survey

Mini App SDK identity phục vụ login; OA là kênh liên hệ và nhắn tin; Social OAuth dành use case ngoài Mini App, không cần triển khai một login Social riêng. App ID, OA ID, ZBS account ID và UID theo app/OA không được trộn. Ghi rõ loại ID trong schema, config và test. [Z12-Z14]

Kênh trong app luôn là chức năng cơ sở. ZBS cho vắng học, nhắc gia hạn và phiếu mới chỉ kích hoạt sau khi template và use case được duyệt, quyền OA cấp, số dư/quota kiểm tra, consent/audience phù hợp. Không dùng OA messaging như push miễn phí cho mọi user. Follow OA là lựa chọn có ngữ cảnh, không ép follow để xem hồ sơ.

Token OA lưu encrypted server-side, refresh có single flight/lease, version CAS để token cũ không ghi đè token mới. Không ghi token vào logs; revoke/re-auth có runbook. Webhook phải kiểm tra theo đúng signature contract của API đã chọn (chưa có payload tài khoản để kiểm chứng); reject replay/forged requests, persist trước ACK rồi xử lý bất đồng bộ. Theo dõi hết quota/số dư, template rejected, refresh failure và delivery ambiguous.

Không gửi thông báo vắng theo event chưa đối soát. Không đưa điểm chi tiết/tên đầy đủ của trẻ lên preview màn hình khóa; tin tối thiểu + deeplink resource. Deeplink luôn xác thực lại; không chứa phone/access token.

Điều khoản nền tảng là một đầu vào thiết kế, không thay đánh giá pháp lý đầy đủ. Cần người phụ trách pháp lý/dữ liệu SSA phê duyệt mục đích, consent trẻ/người giám hộ, retention, bên xử lý và cách thực hiện quyền dữ liệu trước live. Không suy rằng một checkbox chung hoặc mã hóa là đủ để đáp ứng địa điểm. [Z10]

13.1 Danh mục dữ liệu và lưu giữ đề xuất

Những con số này là đầu vào thương lượng, không được ghi thành “pháp luật bắt buộc”. Yêu cầu xóa phải phân biệt dữ liệu cần giữ theo nghĩa vụ với dữ liệu có thể xóa; theo dõi consent withdrawal và tombstone để restore không hồi sinh quyền/dữ liệu đã xóa. Không xóa backup bất chấp tính toàn vẹn: hạn chế truy cập, expiry theo policy, tái áp deletion ledger khi restore.

13.2 Rút quyền, xóa dữ liệu và ngừng dịch vụ

Mini App cần màn hình Quyền dữ liệu: xem mục đích/consent đã cấp, yêu cầu xuất/chỉnh sửa, rút consent và chủ động khởi tạo xóa dữ liệu. Đề xuất POST /v1/privacy/requests (type, scope, consent version, idempotency key) và GET /v1/privacy/requests/:id chỉ cho chủ thể. Server xác minh phiên, thu hồi quyền bị tác động ngay, tạo task có hạn xử lý và audit; không yêu cầu nhập lại toàn bộ PII qua email. Xóa tài khoản phụ huynh không tự xóa hồ sơ học viên thuộc quyền người giám hộ khác hoặc hồ sơ SSA có cơ sở giữ độc lập; phải tách scope và giải thích rõ.

Điều khoản Zalo còn có yêu cầu xử lý khi ngừng Mini App, gồm hoàn trả/xóa dữ liệu trong 24 giờ trừ trường hợp có cơ sở ngoại lệ được nêu trong điều khoản. Vì vậy retention 35 ngày của backup ở bảng trên không mặc nhiên được áp dụng cho decommission hoặc yêu cầu xóa đặc biệt. Trước live phải chốt với SSA/Zalo quy trình hoàn trả, phạm vi xóa, ngoại lệ hợp lệ, và khả năng xóa trong DB, file, logs, queue, replicas, exports, bên thứ ba và bản sao provider. D1 Time Travel/immutable backup có thể không hỗ trợ xóa chọn lọc từng chủ thể: ghi thành gap cần đánh giá, không tuyên bố tombstone đã đáp ứng xóa không khôi phục. Gate G0/G4 bao gồm cả vấn đề này. [Z10, mục con 6.16.5]

Runbook decommission: freeze login/writes/sends → xác định nghĩa vụ và người nhận hợp lệ → export mã hóa tại nơi được duyệt → xác nhận bàn giao → revoke access/token/connector → xóa theo phạm vi/timeline hợp lệ kể cả các bản sao → thu chứng nhận/biên bản nhà cung cấp → kiểm tra không còn truy cập. Chỉ giữ evidence tối thiểu có căn cứ, không giữ lại nội dung đã cam kết xóa. Đây là quy trình phải diễn tập trên dữ liệu tổng hợp trước khi nhận dữ liệu thật.

13.3 Threat model và kiểm soát

Public static cache chỉ cho assets/catalog đã được chấp thuận. Parent API và file trả Cache-Control: private, no-store; không cache CDN theo URL chứa child ID. Backup keys khác credential app; app chỉ đọc object được phép; CI token không có quyền xóa backup. Chỉ dùng WAF/challenge phù hợp Zalo WebView; không đặt captcha khiến SDK flow không thể dùng.

Mỗi request có request_id; mỗi import có batch_id, hash, mapping_version, source_as_of, counts, generation; mutation có actor/resource/action và event_id. UI hiển thị mã hỗ trợ không chứa PII. Khi phụ huynh báo “8 buổi thành 2”, support truy từ student → active snapshot → source row → batch → audit diff, không dò raw logs chứa toàn bộ hồ sơ.

Ngưỡng chưa phải kết quả đo. Email cảnh báo phải có kênh dự phòng nếu email provider hỏng; cần dashboard có import cuối, outbox tồn, DLQ, backup status. Trace không thay đối soát nghiệp vụ. Tách báo động sai dữ liệu khỏi availability: HTTP 200 với số buổi sai vẫn là lỗi quan trọng.

Incident đề xuất: P1 lộ dữ liệu/mất toàn hệ thống → trực nhận 30 phút trong khung đã ký, cô lập, giữ bằng chứng, thông báo SSA; P2 chức năng chính lỗi → 4 giờ làm việc; P3 vấn đề nhỏ → ngày làm việc tiếp theo. Đây là mức để định giá, không hứa 24/7 khi chưa có người trực/hợp đồng.

14.1 Kế hoạch audit triển khai và bằng chứng bàn giao

Audit trail nghiệp vụ khác operational logs: audit lưu tối thiểu actor, action, resource, thời gian, request/batch/event/run ID, lý do, version trước/sau hoặc diff đã giảm định danh và approval reference. Role ứng dụng không có quyền sửa/xóa audit; export tách quyền để giảm rủi ro tài khoản hạ tầng. Người được xem audit không mặc nhiên có quyền xem nội dung trẻ. Báo cáo audit phải phân biệt “đã thiết kế”, “đã chạy test” và “đã ký nghiệm thu”; tài liệu này chỉ chứng minh phần thiết kế.

15.1 Di chuyển nguồn cũ sang Airflow + Cloudflare

1. Inventory từng tab L01, Drive objects, ownership, public sharing và lịch trigger. Export snapshot bất biến có hash và schema version; dữ liệu thật chỉ qua kênh/nơi đã được duyệt.
2. Dry-run mapping với dữ liệu ẩn danh; giữ external IDs. Chuyển HocVien/LienHePH riêng, không mất liên hệ khi file học viên không phone. Dedup student/attendance/order với ledger các dòng hợp nhất.
3. Nhập nguồn thật vào môi trường đủ điều kiện; so row counts, sums và mẫu từng sân, từng case nhiều con/học bù/gia hạn. SSA ký reconciliation report.
4. Shadow read trên cohort cho phép; không dual-write tự do giữa hai nguồn. Nguồn cũ chỉ tiếp tục ghi nếu đã được xác minh đang chạy; không giả định proposal là hệ thống live. Airflow chạy dry-run trước cutover, chưa publish tự động.
5. Chốt cửa sổ freeze writes ngắn; nếu có GAS/trigger/email cũ thực sự chạy thì tắt và thu hồi quyền. Chụp export cuối, chạy DAG Airflow với import delta, chuyển writer mới. Giữ archive cũ read-only có hạn, đóng endpoint thử nghiệm và thu hồi keys không cần.
6. Verify canary, mutation/idempotency, report scope, source dates; mở cohort dần 10→50→toàn bộ theo danh sách đã cho phép và cơ chế phân phối Zalo thực có. Con số là kế hoạch pilot, không cam kết nền tảng có rollout %.
7. Hypercare 2 tuần đề xuất; giải quyết sai lệch rồi hủy connector và quyền nguồn cũ theo retention, không để hai hệ thống gửi tin.

15.2 Rollback phân loại

A có D1 Time Travel theo gói; cần export độc lập định kỳ vì cùng account không chống mọi compromise. RPO đề xuất ≤24 giờ với export độc lập, mục tiêu cải thiện ≤1 giờ khi đã có cơ chế/đo thử; RTO đề xuất ≤4 giờ. Không ghi “RPO 0” nhờ có PITR. Backup của files và DB cần cùng manifest; test PDF references sau restore. Với B chốt PostgreSQL WAL/PITR và backup object tại VN theo nhà cung cấp, không giả định sẵn có.

Phân lớp: domain tests cho rule và state transitions; integration thật với D1 hoặc PostgreSQL, private file auth và queue emulator; staging E2E; device test thật; fault injection; load và restore. Mock SDK không thay thiết bị thật. 650 học viên không đồng nghĩa 650 phụ huynh, không đồng nghĩa concurrency; đo DAU/phiên và kích thước Excel rồi chỉnh test profile.

16.1 Nghiệm thu phạm vi thương mại mới

T17–T21 bắt buộc khi phát hành module mới cùng T01–T16. Chi tiết fixture/evidence ở FEATURES §7.6; QA, SSA nghiệp vụ và tài chính ký, không dùng mock SDK thay kết quả sandbox/thiết bị thật.

Sơ đồ: deployment

17.1 Môi trường và CI

Dev dùng fixture, local Worker/DB; staging tài khoản/quyền riêng và dữ liệu tổng hợp; production chỉ sau G0. Tách DB/bucket/queue/secret/bindings theo môi trường, không suy chỉ env là đã cách ly. Nếu chỉ có một Mini App ID, lập rõ Testing và live cùng ID, đảm bảo từng build trỏ backend đúng; không dùng quyền admin như bằng chứng user thường.

PR: lint/typecheck/domain+integration tests, schema drift, dependency/secret scan, build frontend/API, contract compatibility. Artifact lưu git SHA, lockfile hash, build time, SDK/tool versions, migration ID, target App ID, backend version. Preview không có credentials production. Review changes đặc biệt auth/import/payment bởi người thứ hai.

Promote backend: backup/bookmark → expand migration → deploy tương thích → smoke test → enable cohort. Sau khi phiên bản frontend mới đủ phổ biến mới contract/drop fields. Rollback artifact kèm config, không chỉ source code. Khi chưa có source package, lệnh npm ci, build và Wrangler phải được khóa trong runbook dự án thực nhận; không trình bày lệnh chưa chạy là đã kiểm chứng.

17.2 Checklist phát hành thực hiện khi build sẵn sàng

1. Đối chiếu tài khoản đã có: App ID, owner verified, OA association, vai trò Admin/Developer; giữ bằng chứng console, không tạo app khác tùy ý.
2. Kiểm tra domain API/file, HTTPS certificate, CORS/preflight, redirect, allowlist theo console hiện hành. A dùng domain SSA; B dùng origin VN. Không giữ whitelist script.google.com chỉ vì proposal cũ nói vậy.
3. Cấu hình public App/OA IDs và API base URL; secret chỉ server. Chọn version SDK/ZaUI/plugin tương thích sau spike; kiểm tra bundle size/constraints theo tooling hiện hành.
4. Cài Extension chính thức, đăng nhập bằng QR với tài khoản có quyền, liên kết đúng App ID; deploy Development kiểm tra nhanh, sau đó Testing có mô tả version. Lưu QR/deeplink và artifact SHA. [Z03, Z04]
5. Nộp getPhoneNumber với video/screenshot use case thật; khai mục đích và privacy URL; quyền người dùng và quyền App đều phải đạt. Test thêm phụ huynh không thuộc Admin/Developer sau khi nền tảng cho phép. [Z06, Z09]
6. Hồ sơ review: tên/logo sở hữu SSA, mô tả đúng chức năng, category, privacy/terms, contact support, demo workflow an toàn, dữ liệu tổng hợp cho reviewer, evidence consent/residency, lựa chọn store G1. Không mở xemNhu hoặc mật khẩu dùng chung trên production để reviewer vào.
7. Gửi Testing xét duyệt; theo dõi lý do reject, sửa và nộp lại. Chính sách nêu vòng kiểm duyệt trong 3 ngày làm việc, không phải SLA hoàn thành toàn dự án. [Z05, Z11 §9.1]
8. Sau approved, SSA/owner phát hành Publish, gắn menu OA/QR/deeplink, kiểm tra từ thiết bị/tài khoản thường. Backend deployment thành công không chứng minh Mini App đã live.
9. Kiểm tra privacy/support links, source freshness, order/lead vào admin, receipt, disable thử nghiệm, rollback candidate; lưu release record và bàn giao.

17.3 Bộ hồ sơ bàn giao

Source/lockfile/license, architecture/ADR/contracts/schema, mapping importer, fixture ẩn danh, test evidence, infra config không secret, account ownership matrix, secret rotation process, release artifact/QR/version, migration reconciliation, backup/restore report, monitoring/dashboard/alert routes, runbooks, training SSA, scope hỗ trợ và chi phí.

Lưu ý dự toán: các con số dưới đây là baseline trước khi bổ sung Airflow/VPS, chưa phải ước tính hiện hành để ký hợp đồng. P0 phải tính lại effort, lịch và chi phí cho stack đã chọn.

18.1 Work breakdown đề xuất

Ước tính tổng 6-10 tuần trước live nếu 1 frontend + 1 backend/lead + QA bán thời gian, source usable và G0/G1 được giải quyết sớm; các giai đoạn có overlap, không cộng máy móc tất cả dòng. Đây không phải báo giá hoặc cam kết deadline. Scope Checkout/Notification/đối soát mới chưa nằm trong ước tính baseline; thiếu source, chọn hạ tầng B hoặc chờ thỏa thuận Cloudflare/Zalo sẽ thay critical path. Không tính thời gian chờ pháp lý/provider là effort lập trình nhưng vẫn tác động ngày live.

Ước lượng effort để lập ngân sách: discovery 4-6, nền tảng/auth 8-12, importer/migration 10-15, frontend/admin 12-18, nghiệp vụ/outbox 8-12, QA/security/restore 8-12, release/training 3-5 person-days; tổng baseline 53-80 person-days chưa gồm Checkout, Notification/ZBS mở rộng và đối soát tài chính mới, tránh cộng phần overlap vai trò hai lần khi chốt SOW. Báo giá = effort chốt × đơn giá từng vai trò + dự phòng 15-20% được thống nhất; chưa có đơn giá nên không bịa số tiền triển khai.

18.2 Chi phí sử dụng

Mô hình tải minh họa để điền calculator: 650 tài khoản giả định × 30 ngày × 2 phiên/ngày × 12 API = 468.000 API/tháng; 650 × 12 buổi = 7.800 attendance rows/tháng. Đây là giả định sizing, không phải số đo SSA và không dùng làm proof capacity. Nếu PDF 650 × 12 × 0.5 MB ≈3.9 GB/năm, thêm revision/raw/backup; phải đo file thật. Cảnh báo ngân sách ở 50/80/100% ngân sách tháng; giới hạn CPU, import và sending để tránh chi phí bất thường.

18.3 Trách nhiệm và vận hành

SSA chịu trách nhiệm xuất MISA đúng lịch, xác minh quan hệ phụ huynh, duyệt điểm/nhận xét/tin, consent/chính sách, sở hữu tài khoản và ngân sách, xử lý Sale/care. Đối tác chịu triển khai kỹ thuật, review/QA, bảo mật app, monitoring, backup/restore, cập nhật và hỗ trợ theo hợp đồng. Provider cung cấp dịch vụ theo điều khoản riêng; không chuyển trách nhiệm dữ liệu của SSA cho provider chỉ vì “serverless”.

Mỗi gate phải có một người accountable có tên trong kickoff; không để “team” chung chung. Bàn giao quyền owner cho SSA và least privilege cho đối tác, tránh tài khoản cá nhân duy nhất giữ quyền deploy/backup.

Không cần các câu trả lời này để đọc/đánh giá bản kế hoạch. Chúng là backlog quyết định ở kickoff, không bị dùng để trì hoãn nghiên cứu. Những bằng chứng còn thiếu không được gắn nhãn “đã đạt”.

19.1 Hồ sơ quyết định bổ sung theo xác nhận chủ dự án

Đã xác nhận ngày 11/11/2026: không dùng Apps Script; Airflow cho sync; VPS proxy tại Việt Nam; Cloudflare cho deployment, security và database. Chưa xác nhận: nhà cung cấp/region VPS, số lượng VPS/standby, nguồn file/connector, lịch sync, domain/origin auth, phiên bản Airflow/executor và cam kết nơi dữ liệu Cloudflare. Không coi việc chọn stack là evidence đã deploy. Ước tính effort/timeline ở §18 là baseline trước bổ sung VPS/Airflow; cần re-estimate tại P0, chưa phải ngân sách đã cập nhật.

19.2 Engineer, Vibecode và tiêu chí bàn giao

“Vibecode” trong tài liệu này là cách dùng AI để tạo/chỉnh ứng dụng nhanh theo phản hồi. Đây không phải phân loại năng lực hoặc bằng chứng chất lượng của một cá nhân/nhà thầu. Kỹ sư có thể dùng cùng công cụ AI. Cần so sánh mức hoàn thiện, trách nhiệm và evidence, không so “gõ code tay” với “dùng AI”. Bản demo hữu ích để chốt giao diện/luồng; chỉ đủ điều kiện production khi vượt cùng tiêu chí nghiệm thu.

Không có cơ sở để khẳng định cách nào nhanh/rẻ hơn theo một tỷ lệ cố định. Dự toán phụ thuộc scope, chất lượng source, số người, G0/G1, UAT và vận hành. Nếu đội Vibecode bàn giao đủ bằng chứng trên thì đánh giá theo cùng chuẩn; nếu Engineer không cung cấp được thì chưa đạt. Dùng AI không chuyển trách nhiệm bảo mật, số liệu hoặc hỗ trợ khỏi bên đã cam kết triển khai.

19.3 Giới hạn phương án Apps Script và Sheets ban đầu

Phạm vi nhận xét là proposal L01 và HTML demo L03, chưa phải audit source/runtime GAS. Việc chưa có bằng chứng một kiểm soát không đồng nghĩa đã phát hiện lỗ hổng hoặc sự cố. Apps Script có thể phù hợp automation nội bộ/prototype; SSA đã chọn không dùng trong hệ thống đích. Đánh giá dưới đây giải thích điều cần chứng minh, không quy kết bên đề xuất.

Consumer là tài khoản Google cá nhân; Workspace là tài khoản theo gói tổ chức.

Hạn mức Google đối chiếu ngày 11/11/2026, có thể thay đổi; tài khoản trial còn có điều kiện riêng. G01

Hạn mức không chứng minh 650 học viên vượt khả năng Apps Script. Cần tài khoản, danh tính thực thi, số request, thời gian xử lý và kích thước file thật mới đánh giá được. Vượt quota có thể dừng thực thi; không suy thành mất dữ liệu chắc chắn. Google cho phép web app chạy theo chủ triển khai hoặc người truy cập; phải xác minh cấu hình và auth ứng dụng, không coi mọi lượt gọi tự có quyền đúng trẻ. G02

Trigger chạy theo tài khoản người tạo và thời gian có thể lệch trong cửa sổ lịch; không cam kết cập nhật đúng từng phút. Import mỗi giờ vẫn chỉ cập nhật tới thời điểm file MISA được xuất: file xuất hôm qua không thành dữ liệu hôm nay nhờ chạy lại. G03

Apps Script có LockService hỗ trợ phối hợp vùng mã truy cập tài nguyên dùng chung; không được viết “Apps Script không có khóa”. Khóa ứng dụng không tự tạo transaction nhiều bảng hoặc kiểm soát mọi chỉnh sửa thủ công trong Sheet. Cần test toàn bộ writer và fault cases thực tế. G04

19.4 Giới hạn của hướng mới và cách Director nghiệm thu

Airflow không tạo tích hợp MISA API; lịch, retry và lịch sử chạy chỉ hữu ích khi nguồn file/quy tắc nghiệp vụ được chốt. VPS Việt Nam là ingress proxy, không phải bằng chứng dữ liệu Cloudflare ở Việt Nam. Cloudflare có quota, single-DB execution và phí usage như §§4/18; không dùng “serverless” để hứa vô hạn hoặc không cần bảo trì. Một VPS hoặc scheduler đơn lẻ có thể gây gián đoạn, phải có owner và recovery plan. Apps Script bị loại nhưng chi phí patching, metadata DB, secrets, backup và giám sát Airflow/VPS được bổ sung; phải tính lại dự toán.

Director duyệt theo module và luồng trong PRESENTATION.md; engineering sign-off theo FR/T/decision gates. Nghiệm thu không chỉ là “màn hình chạy được”: dữ liệu đối soát, quyền người dùng thường, gửi lại an toàn, báo lỗi, phục hồi, Zalo approved+published, tài khoản/source và người vận hành đều phải được chứng minh. Chưa có kết quả test runtime nào được tạo ra chỉ bằng việc xuất tài liệu.

Hoàn thành gói kế hoạch: có nguồn đầu vào và nghiên cứu hiện hành, kiến trúc Cloudflare đầy đủ cùng điều kiện, mô hình dữ liệu/flow/API/UI/security/import/migration/testing/release/ops/cost/ownership, sơ đồ đọc được, HTML đồng bộ Markdown và báo cáo kiểm tra. Không yêu cầu đã có tài khoản production để hoàn thành việc lập kế hoạch.

Hoàn thành dự án triển khai sau này: toàn bộ FR/T gates được chứng minh, G0/G1/G4 đóng, dữ liệu đối soát đúng, quyền user thường chạy thật, phiên bản Zalo approved+published, OA entry hoạt động, restore thực hiện được và người vận hành nhận bàn giao. Bộ kế hoạch này không tự chứng minh các điều kiện triển khai đó đã xảy ra.