แอปฟิตเนสอัจฉริยะ: แผนการใช้งานแบบแบ่งระยะและแผนกลยุทธ์การยืนยัน
Artifactนี่คืออาร์ติแฟกต์ที่ใช้ในตอนที่ 4: แผนการติดตั้งใช้งานแอปแบบไม่ต้องเขียนโค้ด คุณสามารถใช้แผนกลยุทธ์นี้เพื่อจัดการการพัฒนาที่ขับเคลื่อนด้วยเป้าหมายสำคัญด้วยการยืนยันแบบ 2 ชั้นและเกตสาขา/แท็ก Git
ลงชื่อเข้าใช้เพื่อเข้าถึงอาร์ติแฟกต์นี้
ลงชื่อเข้าใช้ด้วยโปรไฟล์นักพัฒนาแอปของ Google เพื่อดูและคัดลอกอาร์ติแฟกต์ทั้งหมดที่ใช้ในซีรีส์ Build It!
ต้องมีโปรไฟล์นักพัฒนาแอป
คุณไม่มีสิทธิ์สร้างโปรไฟล์นักพัฒนาแอป แจ้งให้ผู้ดูแลระบบ Workspace เปิดใช้ฟีเจอร์นี้
สร้างโปรไฟล์นักพัฒนาซอฟต์แวร์
สร้างโปรไฟล์นักพัฒนาแอปของ Google ฟรีเพื่อปลดล็อกพรอมต์และอาร์ติแฟกต์ทั้งหมดของ Build It!
เข้าร่วม Builder Central เพื่อปลดล็อก
รับป้ายการเป็นสมาชิก Builder ฟรีในคลิกเดียวเพื่อปลดล็อกพรอมต์และอาร์ติแฟกต์ทั้งหมดของ Build It!
สถานะ: อนุมัติแล้วและพร้อมดำเนินการ
กลุ่มเป้าหมาย: ตัวแทนนักพัฒนา AI อัตโนมัติและหัวหน้าโปรเจ็กต์ที่เป็นมนุษย์
เอกสารประกอบ: ข้อกำหนดสถาปัตยกรรมข้อมูล, ข้อกำหนดสถาปัตยกรรมไคลเอ็นต์, ข้อกำหนดตัวแทนเทรนเนอร์ AI
ข้อมูลสรุปและกลยุทธ์การดำเนินการ
แผนการติดตั้งใช้งานนี้จะจัดระเบียบการสร้างแอปพลิเคชัน Smart Fitness ทั้งหมดตั้งแต่สคีมาพื้นฐานไปจนถึงความพร้อมของเวอร์ชันที่ใช้งานจริง
กระบวนทัศน์การดำเนินการ: ขับเคลื่อนด้วยเหตุการณ์สำคัญพร้อมการยืนยันแบบ 2 ชั้น
แผนนี้ใช้เฟรมเวิร์กเหตุการณ์สำคัญที่มีการแบ่งระยะเพื่อสร้างสมดุลระหว่างความเร็วสูงของ Agent กับความแม่นยำทางสถาปัตยกรรม
- การดำเนินการโดยอัตโนมัติภายในเป้าหมาย: Agent ที่ติดตั้งใช้งานจะทำงานอย่างต่อเนื่องผ่านขั้นตอนของแต่ละเป้าหมาย โดยเขียนโค้ด เรียกใช้บิลด์ แก้ไขข้อผิดพลาดของคอมไพเลอร์ และแก้ไขปัญหาด้วยตนเองโดยไม่ต้องมีคนคอยจัดการอย่างละเอียด
- การยืนยันเลเยอร์ 1 - อุปสรรคก่อนเข้าสู่เกตเวย์ของ Agent อัตโนมัติ: ก่อนขอการอนุมัติจากเจ้าหน้าที่ Agent ต้องเรียกใช้การตรวจสอบคอมไพเลอร์ เรียกใช้สคริปต์ทดสอบแบ็กเอนด์ และเปิดใช้การยืนยันเบราว์เซอร์อัตโนมัติของ Google Antigravity (โดยใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome) เพื่อจำลองการโต้ตอบของผู้ใช้จริงบนอุปกรณ์เคลื่อนที่ เรียกใช้กรอบการทดสอบภาษาอังกฤษแบบธรรมดา ตรวจสอบสถานะ DOM และจับภาพหน้าจอ
- การยืนยันเลเยอร์ 2 - จุดตรวจสอบโดยผู้ควบคุมที่เป็นมนุษย์: เมื่อการตรวจสอบอัตโนมัติของ Agent ผ่านแล้ว ผู้ควบคุมที่เป็นมนุษย์จะตรวจสอบรายการตรวจสอบที่ชัดเจนซึ่งใช้เวลา 2 นาทีเพื่อยืนยันความรู้สึกเกี่ยวกับ UX, ความสอดคล้องทางธุรกิจ และความสมบูรณ์ของข้อมูลก่อนที่จะให้สิทธิ์ในการก้าวไปสู่เป้าหมายถัดไป
โปรโตคอลการควบคุมเวอร์ชันและการติดแท็ก Git
เพื่อให้มั่นใจว่ามีการกู้ข้อมูลคืนหลังจากภัยพิบัติ ความแตกต่างของการรีวิวโค้ดที่โปร่งใส และไม่มีข้อผิดพลาดที่ซับซ้อนในเหตุการณ์สำคัญต่างๆ Agent ที่ติดตั้งใช้งานจะต้องปฏิบัติตามโปรโตคอล Git ต่อไปนี้อย่างเคร่งครัด
- กลยุทธ์การแยกสาขา
main: สาขาที่ได้รับการคุ้มครอง เฉพาะเวอร์ชันหลักที่ได้รับอนุมัติจากเจ้าหน้าที่เท่านั้นที่จะผสานรวมที่นี่- Branch ของฟีเจอร์หลัก: Branch เฉพาะสำหรับแต่ละเหตุการณ์สำคัญ (
feat/m1-scaffolding-typesถึงfeat/m6-pwa-production)
- พิธีการยืนยันก่อนเข้าประตู:
git add -A git commit -m "feat(mX): complete milestone X tasks and pre-gate verifications" - การตรวจสอบความแตกต่างโดยผู้ตรวจสอบที่เป็นมนุษย์:
git diff main..HEAD # or across gates: git diff gate-[N-1]-approved..HEAD - การอนุมัติเกตและการติดแท็กเหตุการณ์สำคัญ:
git checkout main git merge --no-ff feat/mX-... -m "merge: approve milestone X" git tag -a gate-X-approved -m "Milestone X: Verified and approved by Gatekeeper" - การย้อนกลับและการกู้ข้อมูลคืนหลังจากภัยพิบัติ:
git checkout main git branch -D feat/mX-... git checkout -b feat/mX-... gate-[N-1]-approved
กราฟทรัพยากร Dependency ของสถาปัตยกรรมหลัก
M1 [Milestone 1: Foundations, Types & Database Seed] ──> G1 {Gate 1 Sign-Off}
├──> M2 [Milestone 2: Server APIs & Gemini Coach Engine] ──> G2 {Gate 2 Sign-Off}
└──> M3 [Milestone 3: Client State & Gym-Floor Tracker] ──> G3 {Gate 3 Sign-Off}
├──> M4 [Milestone 4: Coach Chat & Staged Proposal Interface] ──> G4 {Gate 4 Sign-Off}
└──> M5 [Milestone 5: Schedule, Analytics & Profile Settings] ──> G5 {Gate 5 Sign-Off}
└──> M6 [Milestone 6: PWA Offline Sync & E2E Validation] ──> G6 {Gate 6: Final Production Acceptance}เป้าหมายที่ 1: โครงสร้างโปรเจ็กต์ ประเภทหลัก และเลเยอร์ฐานข้อมูล
วัตถุประสงค์: สร้างรากฐานของที่เก็บ สัญญาโดเมน TypeScript ที่เข้มงวด การเชื่อมต่อ Firebase SDK และสร้างสารานุกรมการออกกำลังกายแบบคงที่
- งาน 1.0: การเริ่มต้น Git Branch — สร้างและเปลี่ยนไปใช้
feat/m1-scaffolding-types - งานที่ 1.1: การสร้างโครงสร้างโปรเจ็กต์และการตั้งค่า Toolchain — เริ่มต้น Next.js 19 (App Router) ด้วยโหมดเข้มงวดของ TypeScript, Tailwind CSS v4, Tailwind Variants, Lucide React, Zustand, TanStack Query, Firebase SDK, Google Generative AI SDK, Recharts และเกณฑ์พื้นฐานของ PWA
- งานที่ 1.2: คำจำกัดความประเภทโดเมน TypeScript ตามรูปแบบมาตรฐาน — สร้างโมดูล
src/types/(exercise.ts,plan.ts,session.ts,profile.ts,chat.ts,pr.ts) ที่ตรงกับข้อกำหนดสถาปัตยกรรมข้อมูลอย่างเคร่งครัด - งานที่ 1.3: การตั้งค่า Firebase Client และ Admin SDK — ใช้
src/lib/firebase/client.tsและsrc/lib/firebase/admin.ts - งาน 1.4: Exercise Encyclopedia Seeding Script — สร้าง
scripts/seed-exercises.tsเพื่อสร้าง/exercisesด้วย Slug Canonical และข้อมูลเมตา - งาน 1.5: กฎและดัชนี Firestore — ติดตั้งใช้งาน
firestore.rulesและfirestore.indexes.json
การยืนยันเลเยอร์ 1 และเลเยอร์ 2 (เกต 1): เรียกใช้ npx tsc --noEmit, npm run lint และ npx ts-node scripts/seed-exercises.ts ตรวจสอบ git diff main..HEAD และยืนยันเอกสาร Firestore ที่สร้างขึ้นก่อนติดแท็ก gate-1-approved
เป้าหมายที่ 2: ตัวแฮนเดิลเส้นทาง API แบ็กเอนด์และไปป์ไลน์เครื่องมือ AI
วัตถุประสงค์: ใช้ตัวแฮนเดิลเส้นทางเซิร์ฟเวอร์สำหรับการบันทึกการออกกำลังกายและไปป์ไลน์การฝึกสอน AI ของ Gemini ด้วยการแคชบริบท การจัดการการเปลี่ยนแปลงหน่วยความจำ และข้อเสนอที่แบ่งเป็นระยะ
- งาน 2.0: การเริ่มต้น Git Branch — สร้างและเปลี่ยนไปใช้
feat/m2-backend-apisจากmain - งานที่ 2.1: ตัวช่วยมิดเดิลแวร์การตรวจสอบสิทธิ์ - ใช้
src/lib/auth/server-auth.tsเพื่อยืนยันโทเค็น Firebase ID - งาน 2.2: ปลายทางการบันทึกการออกกำลังกาย (
POST /api/workouts/log) — คำนวณปริมาณเซสชัน ใช้สูตร Brzycki 1RM, อัปเดต/แทรก PR, คงบันทึกที่เปลี่ยนแปลงไม่ได้ และทำเครื่องหมายวันที่กำหนดเวลาไว้เป็นcompleted - งาน 2.3: การแคชบริบทของ Gemini และการประกอบพรอมต์แบบไดนามิก — ตั้งค่า
cachedContents.createด้วยคำสั่งระบบหลักและการประกอบบริบทรันไทม์แบบไดนามิก - งาน 2.4: Unified Chat Endpoint (
POST /api/coach/chat) — บังคับใช้เอาต์พุตสคีมา JSON ที่มีโครงสร้าง เขียนแบบ Dual-write ไปยังweekly_chatsและบังคับใช้ Staged Mutation Isolation - งาน 2.5: ตัวประมวลผลการกลายพันธุ์ของหน่วยความจำอัตโนมัติ — ใช้
memory_mutations(CREATE,UPDATE,DELETE) กับ/users/{userId}/profile/main - งานที่ 2.6: เครื่องมือ Query เชิงวิเคราะห์แบบอ่านอย่างเดียว - ใช้
get_historical_exercise_logs,get_volume_trendsและget_pr_records
การยืนยันเลเยอร์ 1 และเลเยอร์ 2 (เกต 2): เรียกใช้ npx ts-node scripts/test-api-routes.ts, ยืนยันการแยกการกลายพันธุ์ที่จัดเตรียมไว้, ตรวจสอบเวลาในการตอบสนองที่แคชไว้ (<2.5 วินาที) และแท็ก gate-2-approved
เป้าหมายที่ 3: โครงสร้างพื้นฐานของสถานะไคลเอ็นต์และเครื่องมือติดตาม Gym-Floor หลัก
วัตถุประสงค์: สร้าง Application Shell, แถบด้านล่างแบบถาวร, สถาปัตยกรรมสถานะ Zustand และ TanStack Query ในเครื่อง และมุมมองการดำเนินการบนพื้นสนาม/workout/activeที่มีความสำคัญสูง
- งาน 3.0: การเริ่มต้น Git Branch — สร้างและเปลี่ยนไปใช้
feat/m3-client-state-trackerจากmain - งาน 3.1: Application Shell และการนำทางแบบถาวร — ใช้
<AppContainer />และ<BottomNavigationBar />กับเป้าหมายการแตะขนาด 48dp ที่สัมผัสได้ 5 รายการและปุ่มตรงกลางแบบไดนามิก - งาน 3.2: การจัดการสถานะไคลเอ็นต์และ Step-Graph Flattener — ใช้
useActiveSessionStore(Zustand +localStorage) และอัลกอริทึม Step-Graph Flattener - งาน 3.3: แคตตาล็อกคอมโพเนนต์บล็อกการออกกำลังกายที่นำกลับมาใช้ใหม่ได้ — ใช้
<WorkoutHeader />,<WorkoutExerciseSummary />,<WorkoutBlock />,<ExerciseCard />,<EmptyDayPlaceholder />และ<ModifyWithCoachCard /> - งาน 3.4: ยอดดูตัวอย่างการออกกำลังกายรายวัน - ใช้
DailyWorkoutViewสำหรับ/todayและ/workouts/:day - งาน 3.5: หน้าจอการออกกำลังกายที่กำลังทำอยู่ (
/workout/active) — ใช้ส่วนหัวของนาฬิกาจับเวลา,<CurrentSetTargetCard />(UI ที่มองโลกในแง่ดี <16 มิลลิวินาที),<ActiveRestTimerDock />,<ExerciseSetsTable />,<SwapExerciseModal />และ<FinishConfirmationModal /> - งานที่ 3.6: มุมมองสารานุกรมรายละเอียดการออกกำลังกาย (
/exercises/:exerciseId) - ใช้<ExerciseVideoPlayer />แบบวนซ้ำอัตโนมัติและปิดเสียง กล้ามเนื้อเป้าหมาย ขั้นตอน และเคล็ดลับเกี่ยวกับท่าทาง
การยืนยันเลเยอร์ 1 และเลเยอร์ 2 (เกต 3): เรียกใช้ชุดทดสอบ 1, 2, 5 และ 6 ในวิวพอร์ตบนอุปกรณ์เคลื่อนที่ของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome (390x844) ยืนยันการกู้คืนการโหลดซ้ำของ localStorage และแท็ก gate-3-approved
เป้าหมายที่ 4: ศูนย์กลางการสนทนาของโค้ช AI และอินเทอร์เฟซข้อเสนอแบบแบ่งระยะ
วัตถุประสงค์: ใช้อินเทอร์เฟซการโค้ชแบบสนทนา (/coach) ที่มีการพิมพ์ตามคำบอกด้วยการแปลงเสียงพูดเป็นข้อความ, คำแนะนำชิปพรอมต์, ไฟล์แนบแบนเนอร์บริบท และการ์ดข้อเสนอแบบแบ่งระยะที่มีการโต้ตอบ
- งาน 4.0: การเริ่มต้น Branch ของ Git — สร้างและเปลี่ยนไปใช้
feat/m4-coach-chatจากmain - งาน 4.1: สถานะแชทและการซิงค์แบบเรียลไทม์ - ใช้
useCoachChatStoreกับการสมัครใช้บริการonSnapshotของ Firestore - งานที่ 4.2: เลย์เอาต์มุมมองแชทและสตรีมข้อความของโค้ช - ใช้
<CoachHeader />,<ChatMessageList />,<ChatBubble />และตัวหมุนแสดงการคิดของโค้ช - งาน 4.3: ไฟล์แนบบริบทและชิปพรอมต์ — ใช้
<ContextBanner />,<ContextualPromptsBar />,<ChatInputBar />และ<SpeechToTextButton /> - งาน 4.4: การติดตั้งใช้งานการ์ดข้อเสนอแบบแบ่งระยะ - ติดตั้งใช้งาน
<StagedProposalCard />สำหรับความแตกต่างของUPDATE_DAYและUPDATE_WEEK - งาน 4.5: การคอมมิตข้อเสนอแบบมีมนุษย์ร่วม — คอมมิต
proposal.dataไปยัง Firestoreweekly_plansเฉพาะเมื่อมีการแตะ[Accept Plan]
การยืนยันเลเยอร์ 1 และเลเยอร์ 2 (เกต 4): เรียกใช้ชุดที่ 4 ในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome, ยืนยันการแยกการกลายพันธุ์ที่จัดเตรียมไว้และคอมมิต [Accept Plan] และแท็ก gate-4-approved
เป้าหมายที่ 5: การปรับปรุงกำหนดการ, การวิเคราะห์ความคืบหน้า และการตั้งค่าโปรไฟล์
วัตถุประสงค์: สร้างมุมมองแอปพลิเคชันที่เหลือให้เสร็จสมบูรณ์ ซึ่งได้แก่ ตารางเวลารายสัปดาห์ (/week), ความคืบหน้าและข้อมูลวิเคราะห์ (/progress) และโปรไฟล์/การตั้งค่า (/settings) พร้อมการจัดการหน่วยความจำ 3 ระดับ
- งาน 5.0: การเริ่มต้น Git Branch - สร้างและเปลี่ยนไปใช้
feat/m5-schedule-progress-settingsจากmain - งาน 5.1: มุมมองกำหนดการรายสัปดาห์ (
/week) - ใช้<WeekHeader />,<WeeklyStatsSummary />,<DayScheduleCard variant="normal" />และ<ModifyWeekWithCoachCard /> - งาน 5.2: มุมมองความคืบหน้าและข้อมูลวิเคราะห์ (
/progress) — ใช้<PRShowcaseBanner />, Recharts<VolumeProgressChartCard />(4W | 3M | 1Y),<AllTimeStatsGrid />และ<WorkoutHistorySection /> - งานที่ 5.3: มุมมองโปรไฟล์ การตั้งค่า และความจำ AI (
/settings) — ใช้<UserProfileCard />,<EquipmentSelectorCard />,<PreferencesGroup />และ<MemoryTierViewerCard />พร้อมการลบ[🗑]
การยืนยันเลเยอร์ 1 และเลเยอร์ 2 (เกต 5): เรียกใช้ชุดทดสอบ 3, 7 และ 8 ในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome, ยืนยันการเปิด/ปิดแผนภูมิและการลบหน่วยความจำ และแท็ก gate-5-approved
เป้าหมายที่ 6: การเพิ่มความปลอดภัยในเวอร์ชันที่ใช้งานจริง, บัฟเฟอร์ออฟไลน์ของ PWA และการอนุมัติเมทริกซ์ทั้งหมด
วัตถุประสงค์: เสริมความแข็งแกร่งให้แอปพลิเคชันสำหรับสภาพแวดล้อมในยิมจริง โดยกำหนดค่าการแคชเนื้อหา PWA แบบออฟไลน์ ใช้การซิงค์บันทึกการออกกำลังกายแบบออฟไลน์ และดำเนินการเมทริกซ์การยืนยันภาษาอังกฤษแบบธรรมดา 42 รายการให้เสร็จสมบูรณ์
- งาน 6.0: การเริ่มต้น Git Branch — สร้างและเปลี่ยนไปใช้
feat/m6-pwa-productionจากmain - งาน 6.1: Service Worker ของ PWA และการแคชเนื้อหา — สรุป Service Worker ของ Serwist/next-pwa และไฟล์ Manifest ของ PWA แบบสแตนด์อโลน
- งาน 6.2: บัฟเฟอร์การซิงค์ออฟไลน์ของ Basement Gym — ใช้คิวออฟไลน์ใน IndexedDB/localStorage สำหรับ
POST /api/workouts/logพร้อมการล้างข้อมูลการเชื่อมต่อใหม่อัตโนมัติ - งานที่ 6.3: ขอบเขตข้อผิดพลาดและมุมมองสำรอง - ยืนยันการสำรอง 404, การสำรองวันไม่ถูกต้อง และการสำรองการออกกำลังกายไม่ถูกต้อง
- งาน 6.4: การดำเนินการเมทริกซ์แบบเต็มและการตรวจสอบประสิทธิภาพ — ดำเนินการกรอบการทดสอบภาษาอังกฤษแบบธรรมดาทั้ง 42 รายการในชุดที่ 1-8 และเรียกใช้การตรวจสอบ Lighthouse (ประสิทธิภาพ >90, LCP <2.5 วินาที, เป้าหมายการสัมผัส ≥48dp)
การยืนยันเลเยอร์ 1 และเลเยอร์ 2 (เกต 6): เรียกใช้ npm run build, จำลองโหมดเครือข่ายออฟไลน์ในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome, ยืนยันว่าชุดโปรแกรมทดสอบ 42/42 ทั้งหมดผ่าน และแท็ก v1.0.0
สรุปเกตการยืนยันสำหรับผู้ตรวจสอบที่เป็นมนุษย์
| ประตู | ส่วนที่กระชับ | Branch ของ Git และแท็กการเผยแพร่ | สิ่งที่ต้องส่งมอบที่สำคัญของตัวแทน | เวลาที่คาดว่าจะใช้ในการยืนยันโดยเจ้าหน้าที่ |
|---|---|---|---|---|
| ประตู 1 | ประเภท, สคีมา DB และค่าตั้งต้น | feat/m1-scaffolding-typesแท็ก: gate-1-approved |
src/types/, สคริปต์เริ่มต้นทำงานแล้ว, คอมไพล์ใหม่ทั้งหมด |
~2 นาที (ตรวจสอบความแตกต่างและฐานข้อมูลที่สร้างขึ้น) |
| ประตู 2 | API แบ็กเอนด์และไปป์ไลน์ Gemini | feat/m2-backend-apisแท็ก: gate-2-approved |
/api/workouts/log, /api/coach/chat, การทดสอบการผสานรวม |
ประมาณ 3 นาที (เรียกใช้สคริปต์ทดสอบ API และตรวจสอบสคีมา) |
| ประตู 3 | เครื่องมือติดตามสถานะและกิจกรรมของไคลเอ็นต์ | feat/m3-client-state-trackerแท็ก: gate-3-approved |
Shell, /today, /workout/active, ผ่านการทดสอบเบราว์เซอร์ |
ประมาณ 3 นาที (แตะการควบคุมการออกกำลังกายและทดสอบนาฬิกาจับเวลา) |
| ประตู 4 | แชทกับโค้ชและข้อเสนอที่จัดเตรียมไว้ | feat/m4-coach-chatแท็ก: gate-4-approved |
/coach, <StagedProposalCard />, การคอมมิตข้อเสนอ |
ประมาณ 3 นาที (แชทกับโค้ช, ทดสอบ [Accept Plan]) |
| ประตู 5 | กำหนดการ ข้อมูลวิเคราะห์ และการตั้งค่า | feat/m5-schedule-progress-settingsแท็ก: gate-5-approved |
/week, /progress, /settings, ตัวจัดการหน่วยความจำ |
~3 นาที (ตรวจสอบแผนภูมิและลบความทรงจำทดสอบ) |
| ประตู 6 | การซิงค์แบบออฟไลน์ของ PWA และการเปิดตัวเต็มรูปแบบ | feat/m6-pwa-productionแท็ก: v1.0.0 |
บิลด์เวอร์ชันที่ใช้งานจริง, แคช PWA, ผ่านการทดสอบ 42/42 รายการ | ~5 นาที (ตรวจสอบรายงานขั้นสุดท้ายและการตรวจสอบความถูกต้องบนอุปกรณ์เคลื่อนที่) |