Aplikacja treningowa: plan wdrożenia etapowego i harmonogram weryfikacji
ArtefaktTo jest artefakt użyty w odcinku 4: Plan implementacji aplikacji bez kodu. Możesz użyć tej mapy, aby koordynować rozwój oparty na kamieniach milowych z dwuwarstwową weryfikacją i bramkami gałęzi/tagów Git.
Zaloguj się, aby uzyskać dostęp do tego artefaktu
Zaloguj się za pomocą profilu dewelopera w Google, aby wyświetlić i skopiować pełny artefakt używany w serii Build It!
Wymagany jest profil dewelopera
Nie kwalifikujesz się do utworzenia profilu dewelopera. Poproś administratora Workspace o włączenie tej funkcji.
Utwórz profil dewelopera
Utwórz bezpłatny profil dewelopera w Google, aby odblokować wszystkie prompty i artefakty w Build It!
Dołącz do Builder Central, aby odblokować
Odbierz bezpłatną plakietkę wspierającego programu Builder jednym kliknięciem, aby odblokować wszystkie prompty i artefakty Build It!
Status: zatwierdzony i gotowy do realizacji
Docelowi odbiorcy: autonomiczny agent AI do programowania i osoba kierująca projektem
Dokumenty towarzyszące: specyfikacja architektury danych, specyfikacja architektury klienta, specyfikacja agenta AI do trenowania
Streszczenie i strategia wykonania
Ten plan wdrożenia obejmuje cały proces tworzenia aplikacji Smart Fitness – od podstawowych schematów po gotowość do wdrożenia wersji produkcyjnej.
Model realizacji: oparty na etapach z dwuwarstwową weryfikacją
Aby zachować równowagę między szybkością działania agenta a precyzją architektury, ten plan jest zgodny z strukturą etapów i kamieni milowych:
- Autonomiczne wykonywanie zadań w ramach kamieni milowych: agent wdrażający działa nieprzerwanie, wykonując kroki każdego kamienia milowego, pisząc kod, wykonując kompilacje, naprawiając błędy kompilatora i samodzielnie rozwiązując problemy bez konieczności mikrozarządzania przez człowieka.
- Weryfikacja na poziomie 1 – bariera przed bramką agenta autonomicznego: zanim agent poprosi o zatwierdzenie przez człowieka, musi przeprowadzić testy kompilatora, wykonać skrypty testowe backendu i uruchomić autonomiczną weryfikację przeglądarki Google Antigravity (za pomocą Narzędzi deweloperskich w Chrome), aby zasymulować rzeczywiste interakcje użytkowników mobilnych, wykonać elementy testowania w języku angielskim, sprawdzić stan DOM i wykonać zrzuty ekranu.
- Weryfikacja na poziomie 2 – punkt kontrolny z udziałem człowieka: gdy agent przejdzie automatyczne kontrole, człowiek przeprowadza 2-minutową weryfikację na podstawie konkretnej listy kontrolnej, aby sprawdzić wrażenia użytkownika, zgodność z celami biznesowymi i integralność danych, zanim zezwoli na przejście do następnego etapu.
Protokół kontroli wersji i tagowania Git
Aby zapewnić odtwarzanie awaryjne, przejrzyste różnice w inspekcji kodu i brak błędów złożonych w poszczególnych etapach, agent wdrażający musi ściśle przestrzegać tego protokołu Git:
- Strategia rozgałęziania:
main: gałąź chroniona. W tym miejscu scalane są tylko zatwierdzone przez człowieka wersje kamieni milowych.- Gałęzie funkcji kamieni milowych: osobna gałąź dla każdego kamienia milowego (od
feat/m1-scaffolding-typesdofeat/m6-pwa-production).
- Ceremonia zatwierdzenia przed bramką:
git add -A git commit -m "feat(mX): complete milestone X tasks and pre-gate verifications" - Weryfikacja różnic przez człowieka:
git diff main..HEAD # or across gates: git diff gate-[N-1]-approved..HEAD - Zatwierdzanie etapów i oznaczanie kamieni milowych:
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" - Wycofanie i odtwarzanie awaryjne:
git checkout main git branch -D feat/mX-... git checkout -b feat/mX-... gate-[N-1]-approved
Wykres zależności architektury podstawowej
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}Etap 1. Szkielet projektu, podstawowe typy i warstwa bazy danych
Cel: utworzenie podstawy repozytorium, ścisłych umów dotyczących domeny TypeScript i połączeń z pakietem Firebase SDK oraz wypełnienie statycznej encyklopedii ćwiczeń.
- Zadanie 1.0. Inicjowanie gałęzi Git – utwórz gałąź
feat/m1-scaffolding-typesi przełącz się na nią. - Zadanie 1.1. Tworzenie szkieletu projektu i konfigurowanie łańcucha narzędzi – zainicjuj Next.js 19 (App Router) z trybem ścisłym TypeScript, Tailwind CSS v4, Tailwind Variants, Lucide React, Zustand, TanStack Query, pakietami SDK Firebase, pakietem SDK generatywnej AI od Google, Recharts i podstawową aplikacją PWA.
- Zadanie 1.2. Kanoniczne definicje typów domen TypeScript – utwórz moduł
src/types/(exercise.ts,plan.ts,session.ts,profile.ts,chat.ts,pr.ts) ściśle zgodny ze specyfikacją architektury danych. - Zadanie 1.3. Konfiguracja klienta Firebase i pakietu Admin SDK – zaimplementuj
src/lib/firebase/client.tsisrc/lib/firebase/admin.ts. - Zadanie 1.4. Skrypt do wypełniania encyklopedii ćwiczeń – utwórz
scripts/seed-exercises.ts, aby wypełnić/exerciseskanonicznymi slugami i metadanymi. - Zadanie 1.5. Reguły i indeksy Firestore – wdróż
firestore.rulesifirestore.indexes.json.
Weryfikacja warstwy 1 i warstwy 2 (bramka 1): uruchom npx tsc --noEmit, npm run lint i npx ts-node scripts/seed-exercises.ts; sprawdź git diff main..HEAD i zweryfikuj dokumenty Firestore z danymi początkowymi przed oznaczeniem gate-1-approved.
Kamień milowy 2. Moduły obsługi tras interfejsu API backendu i potok mechanizmu AI
Cel: zaimplementowanie modułów obsługi tras serwera na potrzeby logowania treningów i potoku trenowania AI od Gemini z pamięcią podręczną kontekstu, obsługą mutacji pamięci i propozycjami etapowymi.
- Zadanie 2.0. Inicjowanie gałęzi Git – utwórz gałąź
feat/m2-backend-apisi przełącz się na nią z gałęzimain. - Zadanie 2.1. Pomocnicze oprogramowanie pośredniczące do uwierzytelniania – zaimplementuj
src/lib/auth/server-auth.tsweryfikujące tokeny identyfikatora Firebase. - Zadanie 2.2. Punkt końcowy logowania treningu (
POST /api/workouts/log) – obliczanie objętości sesji, stosowanie wzoru Brzyckiego na 1RM, aktualizowanie rekordów życiowych, utrwalanie niezmiennego logu i oznaczanie zaplanowanego dnia jakocompleted. - Zadanie 2.3. Pamięć podręczna kontekstu Gemini i dynamiczne tworzenie promptów – skonfiguruj
cachedContents.createz głównymi instrukcjami systemowymi i dynamicznym tworzeniem kontekstu w czasie działania. - Zadanie 2.4. Ujednolicony punkt końcowy czatu (
POST /api/coach/chat) – wymuszanie ustrukturyzowanych danych wyjściowych schematu JSON, podwójny zapis wweekly_chatsi wymuszanie izolacji etapowej mutacji. - Zadanie 2.5: autonomiczny procesor mutacji pamięci – zastosuj
memory_mutations(CREATE,UPDATE,DELETE) do/users/{userId}/profile/main. - Zadanie 2.6. Narzędzia do wysyłania zapytań analitycznych tylko do odczytu – wdróż
get_historical_exercise_logs,get_volume_trendsiget_pr_records.
Weryfikacja warstwy 1 i warstwy 2 (bramka 2): uruchom npx ts-node scripts/test-api-routes.ts, sprawdź izolację mutacji etapowej, sprawdź opóźnienie w pamięci podręcznej (<2,5 s) i otaguj gate-2-approved.
Kamień milowy 3. Infrastruktura stanu klienta i podstawowy moduł śledzenia na siłowni
Cel: utworzenie powłoki aplikacji, stałego dolnego doku, lokalnej architektury stanu Zustand i TanStack Query oraz widoku wykonywania na siłowni /workout/active o wysokiej stawce.
- Zadanie 3.0. Inicjowanie gałęzi Git – utwórz gałąź
feat/m3-client-state-trackeri przełącz się na nią z gałęzimain. - Zadanie 3.1. Powłoka aplikacji i stała nawigacja – zaimplementuj
<AppContainer />i<BottomNavigationBar />z 5 dotykowymi elementami docelowymi o rozmiarze 48 dp i dynamicznym przyciskiem centralnym. - Zadanie 3.2. Zarządzanie stanem klienta i Step-Graph Flattener – zaimplementuj
useActiveSessionStore(Zustand +localStorage) i algorytm Step-Graph Flattener. - Zadanie 3.3. Katalog komponentów bloków treningowych wielokrotnego użytku – zaimplementuj
<WorkoutHeader />,<WorkoutExerciseSummary />,<WorkoutBlock />,<ExerciseCard />,<EmptyDayPlaceholder />i<ModifyWithCoachCard />. - Zadanie 3.4. Widoki podglądu codziennego treningu – zaimplementuj
DailyWorkoutViewdla/todayi/workouts/:day. - Zadanie 3.5. Ekran aktywnego treningu (
/workout/active) – zaimplementuj nagłówek stopera,<CurrentSetTargetCard />(optymistyczny interfejs <16 ms),<ActiveRestTimerDock />,<ExerciseSetsTable />,<SwapExerciseModal />i<FinishConfirmationModal />. - Zadanie 3.6. Widok encyklopedii ze szczegółami ćwiczenia (
/exercises/:exerciseId) – zaimplementuj automatycznie zapętlony wyciszony film<ExerciseVideoPlayer />, docelowe mięśnie, kroki i wskazówki dotyczące formy.
Weryfikacja warstwy 1 i warstwy 2 (bramka 3): wykonaj pakiety 1, 2, 5 i 6 w widoku mobilnym Narzędzi deweloperskich w Chrome (390 x 844), sprawdź przywracanie po ponownym załadowaniu localStorage i tag gate-3-approved.
Kamień milowy 4. Centrum konwersacyjne trenera AI i interfejs propozycji etapowych
Cel: wdrożenie interfejsu konwersacyjnego coachingu (/coach) z zamianą mowy na tekst, rekomendacjami elementów z promptem, załącznikami banerów kontekstowych i interaktywnymi kartami propozycji etapowych.
- Zadanie 4.0. Inicjowanie gałęzi Git – utwórz gałąź
feat/m4-coach-chati przełącz się na nią z gałęzimain. - Zadanie 4.1. Stan czatu i synchronizacja w czasie rzeczywistym – zaimplementuj
useCoachChatStorez subskrypcją FirestoreonSnapshot. - Zadanie 4.2. Układ widoku czatu z trenerem i strumień wiadomości – zaimplementuj
<CoachHeader />,<ChatMessageList />,<ChatBubble />i wskaźnik oczekiwania na odpowiedź trenera. - Zadanie 4.3. Dołączanie kontekstu i elementy z promptem – zaimplementuj
<ContextBanner />,<ContextualPromptsBar />,<ChatInputBar />i<SpeechToTextButton />. - Zadanie 4.4. Implementacja karty propozycji etapowej – zaimplementuj
<StagedProposalCard />dla różnicUPDATE_DAYiUPDATE_WEEK. - Zadanie 4.5. Zatwierdzanie propozycji w procesie z udziałem człowieka – zatwierdź
proposal.dataw Firestoreweekly_planstylko wtedy, gdy kliknięto[Accept Plan].
Weryfikacja warstwy 1 i warstwy 2 (bramka 4): uruchom Suite 4 w Narzędziach deweloperskich w Chrome, sprawdź izolację i zatwierdzenie etapowej mutacji [Accept Plan] oraz tag gate-4-approved.
Etap 5. Przebudowa harmonogramu, statystyki postępów i ustawienia profilu
Cel: dokończ pozostałe widoki aplikacji: tygodniowy harmonogram (/week), postępy i statystyki (/progress) oraz profil/ustawienia (/settings) z 3-poziomowym zarządzaniem pamięcią.
- Zadanie 5.0. Inicjowanie gałęzi Git – utwórz gałąź
feat/m5-schedule-progress-settingsi przełącz się na nią z gałęzimain. - Zadanie 5.1. Widok harmonogramu tygodniowego (
/week) – zaimplementuj<WeekHeader />,<WeeklyStatsSummary />,<DayScheduleCard variant="normal" />i<ModifyWeekWithCoachCard />. - Zadanie 5.2. Widok analityczny postępów (
/progress) – zaimplementuj<PRShowcaseBanner />, Recharts<VolumeProgressChartCard />(4W | 3M | 1Y),<AllTimeStatsGrid />i<WorkoutHistorySection />. - Zadanie 5.3. Profil, ustawienia i widok pamięci AI (
/settings) – zaimplementuj<UserProfileCard />,<EquipmentSelectorCard />,<PreferencesGroup />i<MemoryTierViewerCard />z usuwaniem[🗑].
Weryfikacja warstwy 1 i warstwy 2 (bramka 5): wykonaj zestawy 3, 7 i 8 w Narzędziach deweloperskich w Chrome, sprawdź przełączniki wykresów i usuwanie pamięci oraz oznacz tagiem użytkownika gate-5-approved.
Kamień milowy 6. Zabezpieczanie środowiska produkcyjnego, bufor offline aplikacji PWA i pełne zatwierdzenie matrycy
Cel: wzmocnienie aplikacji pod kątem rzeczywistych środowisk siłowni: skonfigurowanie buforowania zasobów PWA offline, wdrożenie synchronizacji dziennika treningów offline i wykonanie pełnej macierzy weryfikacji obejmującej 42 testy w języku angielskim.
- Zadanie 6.0. Inicjowanie gałęzi Git – utwórz gałąź
feat/m6-pwa-productioni przełącz się na nią z gałęzimain. - Zadanie 6.1. Skrypt service worker PWA i buforowanie zasobów – sfinalizuj skrypt service worker Serwist / next-pwa i samodzielny plik manifestu PWA.
- Zadanie 6.2. Basement Gym Offline Sync Buffer – zaimplementuj kolejkę offline w IndexedDB/localStorage dla
POST /api/workouts/logz automatycznym opróżnianiem po ponownym połączeniu. - Zadanie 6.3. Granice błędów i widoki zastępcze – sprawdź błąd 404, nieprawidłowy dzień i nieprawidłowe ćwiczenie.
- Zadanie 6.4.Pełna macierz wykonania i audyt wydajności – wykonaj wszystkie 42 elementy testowania w języku naturalnym w zestawach 1–8 i przeprowadź audyt Lighthouse (wydajność >90, LCP <2,5 s, docelowe elementy dotykowe ≥48 dp).
Weryfikacja warstwy 1 i warstwy 2 (bramka 6): uruchom npm run build, zasymuluj tryb sieci offline w Narzędziach deweloperskich w Chrome, sprawdź, czy wszystkie 42 testy zostały zaliczone, i otaguj v1.0.0.
Podsumowanie etapów weryfikacji dla weryfikatora
| Brama | Główny obszar | Gałąź Git i tag wersji | Kluczowy element do dostarczenia przez agenta | Oczekiwany czas weryfikacji przez człowieka |
|---|---|---|---|---|
| Bramka 1 | Typy, schemat bazy danych i zasiew | feat/m1-scaffolding-typesTag: gate-1-approved |
src/types/, wykonano skrypt inicjujący, czysta kompilacja |
~2 minuty (sprawdzenie różnic i bazy danych z danymi początkowymi) |
| Bramka 2 | Interfejsy API backendu i potok Gemini | feat/m2-backend-apisTag: gate-2-approved |
/api/workouts/log, /api/coach/chat, testy integracyjne |
~3 minuty (uruchomienie skryptu testowego interfejsu API i sprawdzenie schematu) |
| Bramka 3 | Stan klienta i monitor aktywności | feat/m3-client-state-trackerTag: gate-3-approved |
Shell, /today, /workout/active, test przeglądarki zakończony powodzeniem |
~3 minuty (kliknij elementy sterujące treningiem i przetestuj stoper) |
| Bramka 4 | Czat z trenerem i propozycje etapowe | feat/m4-coach-chatTag: gate-4-approved |
/coach, <StagedProposalCard />, zatwierdzenie propozycji |
~3 minuty (czat z trenerem, test [Accept Plan]) |
| Bramka 5 | Harmonogram, statystyki i ustawienia | feat/m5-schedule-progress-settingsTag: gate-5-approved |
/week, /progress, /settings, menedżer pamięci |
~3 minuty (przeglądanie wykresów i usuwanie pamięci testowej) |
| Bramka 6 | PWA Offline Sync & Full Release | feat/m6-pwa-productionTag: v1.0.0 |
Kompilacja produkcyjna, pamięć podręczna PWA, zaliczone testy: 42/42 | ~5 minut (przejrzenie raportu końcowego i sprawdzenie działania na urządzeniach mobilnych) |