• 오리엔테이션 (20분): 5일간 프로젝트 전체 흐름 및 오늘의 완료 기준 확인
• 강의 (40분): AI 개발 기본 사이클과 Codex vs Antigravity 도구별 역할 분담
• 시연 (30분): 프롬프트 작성, 파일 변경 확인, 브라우저 실행 및 수정 과정
• 실습 1 (50분): 설치·로그인 및 `my-project` 폴더 열기
• 실습 2 (50분): Codex로 `README.md` & `PAGE_REQUIREMENTS.md` 작성
• 실습 3 (70분): Antigravity로 MD 기반 웹페이지(`index.html`) 구현
• 검증 실습 (40분): Codex로 문서 대비 구현 점검 & `VALIDATION.md` 생성
• 공유 & 회고 (30분): 프롬프트 경험 공유 및 Day 2 예고

• AI가 생성한 코드는 완성품이 아니라 검토 대상입니다.
• 한 번에 전체 서비스를 만들기보다, 확인 가능한 작은 단위로 작업을 나눕니다.
• 각 단계마다 파일 형태의 산출물이 남아있어야 다음 AI가 같은 기준을 공유합니다.

• 🔒 보안 원칙: API 키, 개인정보, 비밀번호를 프롬프트에 절대 입력하지 않습니다.
• 🔍 변경 파일 확인: AI가 변경한 파일 목록을 적용 전에 실행 창에서 항상 확인합니다.
• 💾 복구 포인트 생성: 정상 동작하는 시점에 복사본을 남겨 언제든 복구할 수 있게 합니다.

`my-project` 폴더를 생성하고 Codex와 Antigravity에서 각각 엽니다.

이 프로젝트 폴더(my-project)의 기본 역할을 정의해 줘.
프로젝트 목적은 "AI 개발 도구를 활용한 기본 웹 서비스 실습"이야.
기본 README.md 파일을 생성하고 설명 구조를 작성해 줘.

• MVP 정의: 기능이 적은 완제품이 아니라 가장 중요한 가설을 검증하기 위한 최소 제품
• Day 2 제약: 서비스 코드를 구현하지 않는다. 기획과 요구사항 문서화에 집중
• 결과물: 완성된 PROJECT.md는 Day 3 Antigravity 개발의 단일 기준 문서

• ❌ "20~30대 직장인" → 너무 광범위. 인터뷰·테스트 대상을 찾기 어려움
• ✅ "퇴근 후 혼자 저녁 식사 장소를 10분 안에 결정하고 싶은 직장인"

• 핵심 기준: 연령보다 상황과 행동으로 정의
• 테스트 가능성: 관찰 가능·인터뷰 가능·테스트 가능한 사용자인가?

• 핵심 흐름 선택 기준: 가장 중요한 가설을 검증하는 단 하나의 흐름
• 로그인은 핵심 흐름이 아닌 보조 기능일 가능성이 높다.
• 이 흐름이 Day 3 구현 순서와 Day 5 데모 시나리오의 기준이 된다.

• 제공하지 않은 사실은 임의로 확정하지 말고 Open Questions로 분리
• Must 기능은 3~5개로 제한
• 이 문서가 Day 3~5 동안 Antigravity와 Codex가 공유하는 단일 기준 문서

• Must: 핵심 사용자 흐름 동작에 반드시 필요 → 이번 MVP 구현
• Should: 중요하지만 없어도 흐름 동작 → Must 완료 후 구현
• Could: 있으면 좋지만 핵심 가설과 무관 → 향후 개선 목록
• Out of Scope: 5일 안에 구현 어려움 → 이번 과정 제외

• 완료 기준: 목표 사용자, 문제, 핵심 가치, 한 줄 서비스 문장이 각 1~2문장으로 정의됨

• AI 문서 검토: AI가 임의로 추가한 내용은 반드시 검토·수정
• Must 기능이 핵심 사용자 흐름과 연결되는지 확인

• 시나리오 3종: 정상 / 빈 값 / 실패
• Day 5 발표에 사용할 정상 데모 시나리오를 이 시점에 확정

• Day 3에 이 지시문을 Antigravity에 그대로 전달하여 개발 시작

• 📄 한 장 서비스 정의서: 목표 사용자, 핵심 문제, 가치 제안, 한 줄 서비스 문장
• 📄 PROJECT.md: Codex로 작성한 14섹션 기획 문서. Day 3 단일 기준 문서
• 📄 시나리오 검증표: 정상·빈값·실패 3개 시나리오와 화면·기능·데이터 연결
• 📄 HANDOFF_PROMPT.md: Day 3 Antigravity 개발 지시문. 기준문서·범위·완료기준 포함

• 오늘 PROJECT.md와 HANDOFF_PROMPT.md가 완성되었는지 확인
• Must 기능이 3~5개로 제한되었는지 확인
• 정상 데모 시나리오가 정해져 있는지 확인

• 목표: 핵심 사용자 흐름의 시작과 끝이 연결된 MVP v0.1 완성
• 금지: Antigravity에 전체 서비스를 한 번에 요청하지 않는다

• 문서의 각 항목은 구현 또는 검증과 연결되어야 한다

• 핵심 흐름: 사용자 입력 → 화면 이벤트 → 데이터 처리 → 결과 상태 변경 → 화면 갱신
• 파일 이름보다 역할과 연결 관계를 이해한다

• 기본: 입력 또는 시작 안내 — 다음 행동이 분명한가?
• 로딩: 처리 중 표시 — 중복 클릭을 방지하는가?
• 빈 값: 필요한 입력 안내 — 무엇을 입력해야 하는가?
• 성공: 핵심 결과와 다음 행동 — 목표를 완료했는가?
• 오류: 원인과 다시 시도 방법 — 사용자가 복구할 수 있는가?

• 확인 체크: 홈→입력 이동 / 빈 값 메시지 / 모바일 가로 스크롤 없음

• 완료 기준: 정상 시나리오가 처음부터 끝까지 동작 / 5가지 상태 모두 확인

• 🗂️ 기본 프로젝트 구조: 로컬에서 실행 가능한 파일 구조. 홈 화면이 PROJECT.md와 일치
• 🌐 MVP v0.1: 핵심 사용자 흐름(입력→처리→결과)의 시작부터 끝이 연결
• 📄 VALIDATION_DAY3.md: Must별 Pass/Fail/Manual Check와 Day 4 개선 백로그

• CHANGE_REQUEST_DAY4.md 없이 Antigravity에 구현을 요청하지 않는다
• 새 기능이 동작해도 Day 3의 정상 시나리오가 실패하면 MVP v1.0이 아니다
• Must 기능은 최대 두 개만 추가한다

• 🛒 커머스형: 상품, 주문, Mock Payment, Point — 실제 결제·실개인정보 금지
• 🏠 플랫폼형: 회원 상태, 게시물, 검색, 상태 변경 — 간단한 Mock 사용자 허용
• 🔧 업무도구형: 입력, 조회, 수정, 필터, 내보내기 — 민감 데이터 사용 금지
• 🤖 AI 서비스형: 프롬프트, Mock/실제 AI 응답, 결과 저장 — API 키 노출 금지

• 핵심: 추가할 것과 깨지면 안 되는 것을 함께 쓴다

• 빈 값: 아무 반응 없음 → 필요한 입력과 위치 안내
• 중복: 동일 항목 반복 생성 → 중복 안내와 기존 항목 보기
• 처리 실패: 기술 오류 노출 → 쉬운 설명과 다시 시도 버튼
• 권한 없음: 빈 화면 → 접근 조건과 돌아가기 제공
• 데이터 없음: 오류처럼 표시 → 첫 데이터 생성 행동 안내

• 새 기능을 추가했지만 기존 핵심 흐름이 깨졌다 → MVP v1.0이 아니다
• VALIDATION_DAY4.md에 기존 Must와 신규 Must를 구분하여 기록

• 체크포인트: 추가 Must 최대 2개 / 보존 조건 명시 / 회귀 테스트 포함

• 구현 전: 영향 파일 목록을 먼저 받아 예상 범위를 파악
• 구현 후: 신규 기능 + 기존 흐름이 모두 정상 동작하는지 브라우저 확인

• 완료 기준: 동료가 사전 설명 없이 5분간 핵심 흐름을 완주할 수 있는가?

• 중요: 기존 Must(Day 3)와 신규 Must(Day 4)를 명확히 구분하여 기록

• 📄 CHANGE_REQUEST_DAY4.md: 추가 기능, 영향 범위, 보존 조건, 회귀 테스트 포함
• 🌐 MVP v1.0: 선택 트랙 기능, 오류·예외 처리, 반응형 개선 완료
• 📄 VALIDATION_DAY4.md: 기존 Must와 신규 Must 구분 회귀 검증 결과

• 로컬에서 동작함 ≠ 배포 환경에서 동작함
• AI가 완료했다고 말함 ≠ 사용자가 핵심 흐름을 완료함
• 발표가 끝남 ≠ 검증이 끝남

• 🟢 자동 검사: 빌드, 테스트, 정적 검사, 민감정보 패턴 확인
• 🟡 수동 검사: 핵심 흐름, 모바일, 오류 상태, 배포 URL
• 🔴 사용자 검사: 설명 없이 첫 행동과 핵심 결과를 완료하는지 관찰

• 비밀번호, API 키, 토큰이 코드나 MD에 포함되지 않았는가?
• .env 같은 비밀정보 파일이 공개 대상에서 제외됐는가?
• 실제 개인정보 대신 데모 데이터를 사용하는가?
• 실제 결제가 아닌 Mock Payment임을 화면에 표시했는가?
• 외부 API 실패 시 데모가 완전히 중단되지 않는가?

• 로컬 캐시나 로그인 상태에 의존하지 않도록 시크릿 창 또는 다른 기기에서 확인
• 핵심: 배포 성공 메시지보다 실제 URL의 사용자 흐름을 확인한다

• 40초 — 사용자와 문제: "누구가 무엇 때문에 힘들었나?"
• 40초 — 현재 대안과 핵심 가치: Before / After
• 2분 — 핵심 사용자 흐름: 실제 데모 URL 시연
• 50초 — 구현·검증 과정: Codex → Antigravity → Codex 흐름
• 30초 — 배운 점과 다음 단계: 2주 개선 로드맵
• 20초 — 여유: 데모 지연 대비

• 원칙: 검증 전에 코드를 수정하지 않습니다. 검증 결과에서 필수 문제만 이후 최종 개선에서 처리합니다.

• 배포 대상·제외 파일·환경변수 확인 (6분)
• 공통 배포 방식으로 첫 배포 실행 (10분)
• 새 브라우저/모바일 기기에서 데모 URL 접속 (8분)
• 정상·빈 값·실패 상태 및 반응형 레이아웃 확인 (10분)
• 데모 URL과 알려진 제한사항(Known Limitations)을 README.md에 기록 (6분)

• 실전 리허설: 5분 발표를 실제로 말해보며 시간을 측정합니다 (초과 시 데모 단계 압축).

• 블라인드 체험: 설명 없이 동료에게 URL을 주고 첫 5분간 막히는 지점을 관찰
• 최소 긴급 패치: '발표 전 필수'로 분류된 1~2개 항목만 수정 후 재배포

• 5일 과정 종료 후에도 실제 창업/비즈니스로 확장할 수 있는 구체적인 실행 계획 수립

• 문제 명확성: 목표 사용자와 문제가 구체적인가?
• 핵심 가치: 기존 방법보다 나아지는 변화가 보이는가?
• 데모 완성도: 외부 URL에서 핵심 흐름이 동작하는가?
• 문서 일치성: PROJECT.md와 구현 결과가 일치하는가?
• 검증 과정: 테스트·오류·제한사항을 솔직하게 설명하는가?
• 향후 계획: 다음 검증 또는 개선이 구체적인가?

• 5일 동안 검증한 가장 중요한 가설은 무엇인가?
• 사용자 반응으로 새롭게 알게 된 사실은 무엇인가?
• 제거하거나 미룰 기능은 무엇인가?
• 다음에 인터뷰하거나 테스트할 사용자는 누구인가?
• 2주 안에 개선할 기능·문서·검증 항목은 무엇인가?