Đây là kickoff pack của P-002. Tài liệu được chuẩn bị ngày 16/09/2026 để buổi kickoff ngày 17/09/2026 chỉ còn xác nhận người thực hiện cụ thể, xác nhận nhận việc và bắt đầu delivery.

1. Mục tiêu kickoff

Khóa cách làm việc cho V1 để team có thể triển khai liên tục mà không phải quay lại hỏi các nguyên tắc đã được freeze trong biz-docs.

Kết thúc kickoff cần đạt 5 kết quả:

1. mọi người dùng cùng một P0 baseline và hiểu ranh giới phạm vi;
2. mỗi nhánh công việc có một người phụ trách chịu trách nhiệm kết quả;
3. hạn chót V1 09/10/2026 và Định nghĩa hoàn tất (Definition of Done) được xác nhận;
4. reporting, communication và báo chặn dùng cùng một quy ước;
5. mọi điểm chặn hoặc thay đổi phạm vi có nơi ghi nhận và chủ thể rõ ràng.

2. Phạm vi baseline dùng để triển khai

• Customer app P0: iOS + Android. Admin/backoffice Web là bảng điều khiển vận hành P0. Public/customer Web storefront thuộc P0, không delay — cập nhật 17/09/2026 (xem Biên bản họp 17/09/2026).
• Catalog hỗ trợ cả standard ecommerce và print/customizable product bằng Admin configuration.
• Standard ecommerce item có thể chỉ cần variant/phân loại + quantity + fixed-unit price + direct fulfilment.
• Print/customizable item có thể bật public design URL, print pricing engine và production/QC workflow.
• Một cart/order có thể mix hai loại; gate design/production chỉ áp dụng cho item cần gate đó.
• Payment P0: bank transfer + SePay. Invoice và shipping vận hành manual theo spec.
• Notification transactional: email + push.
• Không đưa feature ngoài implementation freeze vào V1 nếu chưa có change request được chấp nhận.

Source of truth: Decision Register + FR/NFR/BR/AC hiện hành trong biz-docs. Khi wording khác nhau, clarification/decision mới hơn thắng.

3. Phân công vai trò

Tên người cụ thể được gán vào từng vai trò/nhánh công việc trong kickoff. Cho tới khi được điền, người phụ trách trong kế hoạch dự án là chủ thể chịu trách nhiệm mặc định, không được để task vô chủ.

4. Reporting cadence

Bảng điều hành dự án tại Quản lý dự án là nơi khách hàng nhìn tiến độ/trạng thái. Kế hoạch chuẩn cơ sở nằm ở data/project.yaml; cập nhật thực thi thực tế nằm ở data/project-progress.yaml.

5. Truyền thông và lưu trữ có tính bền vững

Không phụ thuộc một công cụ chat cụ thể để lưu quyết định.

• Biz-docs / Decision Register: quyết định nghiệp vụ và baseline nghiệm thu.
• Trang quản lý dự án: người phụ trách, hạn chót, trạng thái, tiến độ, rủi ro và tình hình hiển thị cho khách hàng.
• GitHub PR/commit: bằng chứng thay đổi code/docs và review kỹ thuật.
• Kênh chat của team (realtime): dùng để phối hợp nhanh và báo điểm chặn; mọi thay đổi phạm vi/hạn chót/decision quan trọng phải được ghi lại vào GitHub/biz-docs trong cùng ngày làm việc.

6. Quy tắc báo cáo chặn (báo chặn)

• Điểm chặn > 1 ngày làm việc: người phụ trách báo cho Tech Lead + Product người phụ trách, ghi rõ ảnh hưởng và phương án gỡ chặn.
• Lỗi mức nghiêm trọng nhất (Severity-1) / mất dữ liệu / an ninh / toàn vẹn thanh toán: báo ngay, dừng nhánh release liên quan tới khi đã kiểm soát và có quyết định.
• Nguy cơ trễ mốc: không âm thầm đổi hạn chót. Ghi nguyên nhân gốc, đường tới hạn, phương án phục hồi và ảnh hưởng tới khách hàng.
• Phạm vi mới: tạo change request/version mới. Không biến feature request thành defect và không nhét vào sprint P0 nếu chưa qua đánh giá tác động.
• Requirement chưa rõ: trước tiên kiểm Decision Register/FR/BR/AC. Chỉ chuyển lên Product người phụ trách khi cần khi tài liệu thực sự không quyết định được behavior.

7. Định nghĩa hoàn tất (Definition of Done) cho task

Một task chỉ chuyển Hoàn tất khi:

• output đã merge/available ở môi trường phù hợp;
• happy path và negative path quan trọng đã test;
• không phá RBAC/data integrity/idempotency liên quan;
• có bằng chứng đủ để người review khác kiểm tra lại;
• nếu thay đổi behavior thì FR/BR/AC/project docs đã được đồng bộ.

Release V1 còn yêu cầu demo tối thiểu 1 standard ecommerce SKU + 1 print/customizable SKU + 1 mixed cart/order.

8. Điểm xuất phát kỹ thuật

Repo đã có đủ bốn application boundary chính: storefront/, admin/, mobile/ và backend/, cùng production Compose/deploy docs. Root CI hiện kiểm repository contracts, Admin/storefront build và Docker image build.

Chuẩn cơ sở gần nhất được ghi trong repo là audit ngày 08/09/2026, nên các con số dưới đây phải được P-003 chạy lại trước khi coi là hiện trạng mới:

• Storefront build từng pass nhưng còn lint debt được audit ghi nhận.
• Admin production build pass; audit ghi nhận local lint từng vướng dependency ESLint globals.
• Mobile audit ghi nhận TypeScript compile còn 42 errors trong 27 files; một Jest suite fail ở native-module setup, trong khi 21 test đã chạy pass.
• Backend database tests cần disposable PostgreSQL; root CI hiện chưa chứng minh migrations/database test path.
• Public DNS/TLS/runtime health, upload persistence và backup restore vẫn cần operator/runtime bằng chứng riêng.

Điểm này là bằng chứng xuất phát, không phải phán quyết hiện tại. P-003 phải chạy lại/đo lại và cập nhật bằng chứng mới thay vì copy kết luận audit cũ.

9. Kickoff checklist

• P0 phạm vi / non-goals đã freeze.
• V1 mục tiêu 09/10/2026 và lộ trình V2/V3/M5 đã có baseline.
• Phân công vai trò theo chức năng đã định nghĩa.
• Quy chế báo cáo + truyền thông + báo chặn đã định nghĩa.
• Định nghĩa hoàn tất (Definition of Done) và quy tắc bằng chứng đã định nghĩa.
• Bằng chứng xuất phát kỹ thuật đã được gom để P-003 kiểm chứng lại.
• Xác nhận tên người thực hiện thực tế cho các nhánh công việc trong kickoff 17/09.
• Mỗi người thực hiện xác nhận nhận việc task đầu tiên và dependency của mình.

10. Trạng thái P-002

Đang thực hiện · 80% tại ngày 16/09/2026.

Phần chuẩn bị có thể hoàn tất trước kickoff đã xong. P-002 chỉ được chuyển Hoàn tất sau khi người thực hiện thực tế và xác nhận nhận việc được xác nhận ngày 17/09. Sau đó task kế tiếp trên đường tới hạn là P-003: môi trường staging/dev, cổng CI, dữ liệu kiểm thử và quy ước bằng chứng phát hành.

Cập nhật lần cuối 17/09/2026 bởi j · 5675f04e · Lịch sử thay đổi