Bản dịch và giải thích toàn bộ ticket, kèm những gì Game Design Document ràng buộc, những gì file zip đính kèm đã làm sẵn, và bảng ước lượng để bạn chốt EST.
Ticket dài vì phần Acceptance Criteria được viết theo kiểu liệt kê đầy đủ mọi trạng thái camera — 14 gạch đầu dòng nghe như một dự án. Nhưng file zip đính kèm không phải "code mẫu": nó là một prototype gần hoàn chỉnh, tôi đã giải nén và chạy thử, 16/16 test pass, và nó đã đáp ứng sẵn khoảng 11 trên 14 AC.
Phần việc thật nằm ở ba gạch đầu dòng trong mục Technical Implementation, và gạch quan trọng nhất là: thay nhận diện giả bằng model nhận diện vật thể thật (MobileNet hoặc YOLO) chạy trên camera điện thoại. Đây là thứ duy nhất đắt tiền trong ticket, và cũng là thứ duy nhất chưa có trong zip.
Vì vậy EST của bạn sẽ rẽ làm đôi tuỳ theo cách hiểu một câu chữ trong ticket — xem mục 07.
Đây là thuật ngữ riêng của sản phẩm Egg Rescue. Ticket dùng chúng như đã biết, nên đọc mục này trước.
person.Tạo một proof of concept chạy được cho Egg Rescue MVP, nhằm kiểm chứng phần code gameplay đã có khi ghép chung với camera trực tiếp, và trình diễn được tương tác điều khiển-bằng-camera như mô tả trong Game Design Document.
Create a functional proof of concept for the Egg Rescue MVP that validates the existing gameplay code together with live camera integration and demonstrates the intended camera-driven interaction described in the Game Design Document.
Với tư cách người chơi, tôi muốn trải nghiệm Egg Rescue dùng camera thiết bị như một phần của tương tác cốt lõi, để tôi có thể chơi game thông qua đúng cơ chế gameplay dựa trên camera.
As a player, I want the Egg Rescue experience to use the device camera as part of the core interaction, so that I can interact with the game through the intended camera-based gameplay mechanics.
Dựng một Proof of Concept (POC) cho Egg Rescue MVP, dựa trên phần code tham chiếu đã có và các yêu cầu liên quan đến camera được định nghĩa trong Egg Rescue MVP Game Design Document.
POC phải ghép logic game hiện có với camera của thiết bị đích, và thiết lập được luồng kỹ thuật đầu-cuối cần thiết cho gameplay điều khiển bằng camera.
Phần triển khai tập trung vào kiểm chứng tính khả thi kỹ thuật, không phải làm ra hình ảnh hay nội dung game ở mức production.
Integrate device camera for the object scanning, either MobileNet or YOLO to detect the object. The goal is to simulate the object detection · Adding a button to reset data (XP, DP, eggs collected, fieldnotes collected) between children tests · Porting to a mobile device for testing with kids
Cột "Hiện trạng" là kết quả tôi đã đối chiếu trực tiếp với code trong file zip đính kèm, không phải suy đoán từ README.
| # | Tiêu chí (dịch) | Hiện trạng |
|---|---|---|
| 1 | POC chạy được trên thiết bị / nền tảng đã thống nhất.The POC can be launched successfully on the agreed target device/platform. | Cần HTTPS |
| 2 | POC có nút reset để xoá dữ liệu lưu.The POC has a reset button so that we are able to reset save data on the POC. | Đã có |
| 3 | Ứng dụng xin quyền camera khi chưa từng được cấp.The application requests the required camera permission when camera access has not previously been granted. | Đã có |
| 4 | Xử lý cả trường hợp cấp quyền và từ chối quyền mà không crash.The application handles both granted and denied camera permissions without crashing. | Đã có |
| 5 | Khởi tạo và hiển thị được luồng camera trực tiếp trong POC.A live camera feed can be initialized and displayed as part of the Egg Rescue POC. | Đã có |
| 6 | Dùng lại code game tham chiếu thay vì viết lại chức năng tương đương.The existing referenced game code is integrated or adapted into the POC rather than recreating equivalent functionality unnecessarily. | Đã có |
| 7 | Camera được nối vào đúng luồng gameplay định nghĩa trong GDD.The camera integration is connected to the relevant gameplay flow defined in the Egg Rescue Game Design Document. | Một phần |
| 8 | Tương tác điều khiển-bằng-camera tối thiểu hoạt động được.The minimum camera-driven interaction required to demonstrate the intended Egg Rescue gameplay mechanic is functional. | Đang giả lập |
| 9 | Người dùng vào, thoát, chơi lại được, camera vẫn được quản lý đúng.The user can enter, exit, and restart the POC/gameplay flow while the camera is managed correctly. | Đã có |
| 10 | Camera được giải phóng / tạm dừng khi app chạy nền, thoát, hoặc không cần nữa.Camera resources are released or paused appropriately when the game/application is backgrounded, exited, or the camera feature is no longer required. | Đã có |
| 11 | Xử lý mượt khi khởi tạo camera lỗi / không có phần cứng camera, có màn hình fallback.The POC handles camera initialization failures or unavailable camera hardware gracefully and provides an appropriate fallback/error state. | Đã có |
| 12 | Phần camera và phần gameplay tách bạch đủ để thay/mở rộng ở giai đoạn MVP.Camera integration and gameplay logic are sufficiently separated to allow the camera implementation to be extended or replaced during MVP development. | Đã có |
| 13 | POC trình diễn được luồng đầu-cuối chơi/test được, từ lúc mở camera đến hết tương tác.The POC demonstrates an end-to-end playable or testable flow from camera initialization through the relevant Egg Rescue interaction. | Một phần |
| 14 | Ghi lại giới hạn đã biết, phát hiện kỹ thuật, phụ thuộc, và khuyến nghị bước tiếp từ POC lên MVP.Known limitations, technical findings, dependencies, and recommended next steps for moving from POC to MVP are documented. | Cần viết lại |
AC 8 là điểm nghẽn duy nhất: file zip nhận diện vật thể bằng hàm giả lập, có nhãn ghi rõ trên video. README của nó nói thẳng — "the prototype does not actually distinguish physical objects from photos".
Ticket link sang Egg Rescue MVP — Product Design Document, một tài liệu 700+ block. Không cần đọc hết; đây là toàn bộ phần ràng buộc code POC:
| Hạng mục | Giá trị GDD đã chốt | File zip có đúng? |
|---|---|---|
| Ngưỡng điểm Focus Find | Good 50–70% · Great 71–85% · Perfect 86–100% | Khớp |
| Ngưỡng điểm Trail Track | Good 0–69% · Great 70–89% · Perfect 90–100% | Khớp |
| Số cột chấm điểm Trail Track | 5 cột cố định (bất biến, không phải tham số playtest) | Khớp |
| Công thức accuracy | Số mẫu đúng ÷ tổng số mẫu × 100. Độ tin cậy của model không ảnh hưởng điểm. | Khớp |
| Thưởng DP | Good +5 · Great +10 · Perfect +15 | Khớp |
| Whitelist nhận diện | ~30–35 class, COCO 80-class làm gốc | 35 class |
| Cấm tuyệt đối | person, knife, scissors, tv, laptop, cell phone, đồ gia dụng, wine glass, skis | Khớp |
| Không có màn thua | Focus Find chạy đến khi hoàn thành; Trail Track kết thúc khi hết vệt. Chỉ thoát mới là không hoàn thành. | Khớp |
| Popup nhờ phụ huynh | Sau 5 phút chưa xong, không đổi độ khó | Khớp |
| Lens charge | 5 lượt/ngày, refresh 00:00 SGT, trần 99 | Chưa có |
| Nhắc an toàn trước khi mở camera | "Dừng ở chỗ an toàn trước khi dùng Explorer Lens" | Chưa có |
| Chặn quét trùng vật thể trong ngày | "Con đã khám phá cái này rồi! Tìm thứ mới nhé." | Chưa có |
| Weekly Tasks, COURAGE layer | Có trong GDD cho MVP | Ngoài phạm vi POC |
Bốn dòng "Chưa có" ở trên không nằm trong 14 AC của ticket. Chúng nằm trong GDD, nhưng ticket không yêu cầu. Nếu bạn đưa chúng vào EST thì phải nói rõ là phần mở rộng, nếu không con số sẽ bị hiểu là phình scope.
Tôi đã tải file về, giải nén và chạy: npm test cho 16/16 pass. Đây là web app JavaScript thuần, không dependency, không bước build, khoảng 48 KB code trong thư mục dist/. Trong file có dấu vết .openai/hosting.json — nó được sinh ra bởi một AI, sau khi đọc GDD ngày 10/09/2026.
Nghĩa là ticket không bắt đầu từ số không. Phần lớn công sức nằm ở việc hiểu 48 KB code người khác viết, rồi ghép model nhận diện thật vào đúng một chỗ nối đã được chừa sẵn.
getUserMedia, ưu tiên camera sau (facingMode: environment).pagehide, visibilitychange, thoát màn, và khi ra kết quả.egg-rescue:analytics.window.eggRescueYolo với contract init() / infer(video) / dispose(), trả về {label, confidence, box}."Integrate device camera for the object scanning, either MobileNet or YOLO to detect the object. The goal is to simulate the object detection."
Vế đầu bảo dùng MobileNet hoặc YOLO — tức model thật. Vế sau bảo mục tiêu là simulate — mô phỏng. Hai vế chỏi nhau. Người viết zip đính kèm đã chọn cách hiểu thứ hai và làm nhận diện giả.
| Kịch bản A — "simulate" = giả lập | Kịch bản B — chạy model thật |
|---|---|
| Giữ nguyên nhận diện giả của zip. Việc còn lại: hoàn thiện nút reset, gia cố vòng đời camera, deploy HTTPS, test máy thật, viết tài liệu. Rủi ro: không trả lời được bất kỳ câu hỏi khả thi nào mà GDD §20 liệt kê (latency, tỉ lệ nhận sai, chi phí model, hiệu năng máy yếu). POC gần như không chứng minh được điều nó sinh ra để chứng minh. |
Nhúng @tensorflow-models/coco-ssd (MobileNetV2, ~7 MB) hoặc YOLO qua onnxruntime-web, nối vào adapter đã chừa sẵn, map output sang whitelist, đo hiệu năng trên iOS Safari và Android Chrome.Được: đúng tinh thần "validate technical feasibility" ở Goal, và trả lời được đúng những rủi ro GDD đánh dấu cao nhất. |
Khuyến nghị của tôi: kịch bản B. Goal của ticket viết rõ là kiểm chứng tính khả thi kỹ thuật, mà nhận diện giả thì không kiểm chứng được gì. Nhưng đây là chênh lệch lớn về công, nên cần Product xác nhận trước khi bạn cam kết EST.
Số giờ dưới đây là đề xuất của tôi sau khi đọc code, không phải cam kết. Bấm vào ô để sửa; tổng cập nhật ngay. Quy đổi 8 giờ / ngày.
| # | Hạng mục | Giờ |
|---|---|---|
| 1 | Dựng môi trường, đọc và hiểu 48 KB code POC có sẵnNgười khác viết, không comment nhiều. Phải nắm engine, detection, economy trước khi sửa. | |
| 2 | Đối chiếu POC với 14 AC, lập checklist nghiệm thuAC 14 đòi tài liệu; checklist này là đầu vào của nó. | |
| 3 | Chọn và benchmark model: COCO-SSD MobileNetV2 vs YOLO qua onnxruntime-webSo kích thước tải, thời gian warmup, latency mỗi khung hình. MobileNet nhẹ hơn nhưng phân loại; YOLO cho bounding box — Focus Find cần toạ độ. | |
| 4 | Tích hợp model vào adapter window.eggRescueYoloNạp model, tiền xử lý khung hình, giải mã output, NMS, chuẩn hoá box, giải phóng tensor. | |
| 5 | Map nhãn model sang whitelist 35 class + cổng 3 khung hình ổn địnhLogic đã có sẵn trong zip, chỉ cần nối và chỉnh ngưỡng tin cậy 0.60. | |
| 6 | Tối ưu hiệu năng di động: giãn nhịp suy luận, giảm độ phân giải, warmup, bộ nhớĐây là phần trả lời câu hỏi khả thi của GDD §20. Dễ trượt nhất. | |
| 7 | Hoàn thiện nút reset: XP, DP, trứng, field noteĐã có "Reset demo progress" — cần kiểm tra phủ đủ 4 loại dữ liệu ticket nêu. | |
| 8 | Gia cố vòng đời camera và các trạng thái lỗi theo AC 3, 4, 9, 10, 11Phần lớn đã có; cần test thật và bịt các ca biên như cấp quyền muộn sau khi đã thoát. | |
| 9 | Deploy HTTPS qua tunnel, test thật trên iOS Safari và Android ChromeCamera bắt buộc HTTPS hoặc localhost. Mở qua địa chỉ LAN HTTP từ điện thoại sẽ không chạy. | |
| 10 | Viết tài liệu findings, limitations, dependencies, next steps (AC 14)Đây là một AC độc lập, không phải việc phụ. | |
| 11 | Bằng chứng before/after, dựng demo và chờ duyệtQuy trình bắt buộc của workspace trước khi push. | |
| Tổng | — |
| Hạng mục GDD chưa có trong zip | Giờ |
|---|---|
| Lens charge: 5 lượt/ngày, refresh 00:00 SGT, trần 99, quy tắc tiêu lượt | 4 |
| Nhắc an toàn trước khi mở camera, nhớ lựa chọn trong ngày | 2 |
| Chặn quét trùng vật thể trong cùng ngày | 3 |
| Weekly Tasks + đồng hồ thưởng tuần | 8 |
Đối tượng người dùng là gia đình có trẻ 6–7 tuổi, máy không chọn lọc. Model chạy 2–3 FPS trên máy tầm thấp là kết quả hoàn toàn có thể xảy ra — và nếu vậy thì đó chính là phát hiện mà POC sinh ra để tìm, không phải lỗi. Cần nói trước điều này để không bị tính là làm hỏng.
Quyền camera, autoplay video inline, và WebGL backend của TF.js trên Safari đều có hành vi riêng. GDD §20 liệt kê "iOS Safari camera permission UX" là một hạng mục kiểm chứng độc lập.
COCO-SSD MobileNetV2 khoảng 7 MB, YOLO nhỏ cũng vài MB. Trên 4G ngoài đường, thời gian tải lần đầu là một phần của trải nghiệm — cần đo và báo cáo.
GDD ghi đây là "mục tiêu khả thi cần prototype", không phải năng lực giả định. Model có sẵn không làm được việc này. Đừng để nó lọt vào EST như một việc làm được.
Chạy model thật (MobileNet/YOLO) hay giữ nhận diện giả như file zip đính kèm? Đây là chênh lệch lớn nhất trong EST.
AC 6 nói "dùng lại code đã có thay vì viết lại". Tôi hiểu là lấy zip làm nền và phát triển tiếp. Nếu Product muốn viết lại trong codebase RBWE hiện tại thì EST khác hoàn toàn.
AC 1 nói "the agreed target device/platform" nhưng ticket không ghi thiết bị nào. Cần danh sách máy tối thiểu để test — đây cũng là điều kiện để nghiệm thu AC 1.