D3-4 과제 앱 Vercel 배포와 공개 검증

구현 요청
이 과제 앱을 학생 본인 GitHub 저장소에서 Vercel로 배포할 절차를 준비해줘. 현재 경로·브랜치·remote, package.json·lockfile·build를 확인해줘. Vercel Root Directory는 실제 앱 위치, Framework는 Vite, Build는 npm run build, Output은 dist로 맞추고 두 VITE 공개 변수의 Production/필요한 Preview 범위를 설명해줘. .env.local·키·토큰은 commit하지 마. Supabase Site URL은 실제 고정 Production 루트, Redirect URLs는 로컬5173/와 정확한 공개 루트로 맞추고 환경값 변경 뒤 재빌드하도록 안내해줘. PR diff·검증표·병합·배포 SHA를 남겨줘. 가입 요청/메일 도착/확인/로그인/DB 저장/재조회/다른 브라우저 동일계정 복원/A·B 분리/미로그인 차단을 따로 검사해줘. RLS 실패를 UI 숨김·RLS 해제·service_role 노출로 우회하지 마. 원격 변경과 SQL 적용은 수업 단계에서 대상 프로젝트를 확인한 뒤 실행하게 해줘.

검증 요청
수업용 Supabase에서 계정 A와 B를 만들어 실제 가입 메일·로그인을 확인해줘. A가 만든 과제를 새로고침과 다른 브라우저의 A 로그인으로 다시 읽고 수정·완료·삭제·되돌리기를 검사해줘. B에서는 A 행 조회0건, A id를 지정한 수정·삭제0건 또는 거절, user_id=A로 위조INSERT 거절, 소유자변경 거절을 Data API 요청으로 검사해줘. 미로그인 요청도 차단되는지 확인해줘. SQL Editor 관리자 조회를 RLS 통과 증거로 쓰지 마. 계정 전환 직후와 늦은 이전 요청 응답에서 A 목록이 B 화면에 나타나지 않는지, 네트워크 실패가 저장 성공으로 표시되지 않는지 확인해줘. 공개 Vercel URL의 배포commit·환경·가입복귀URL도 대조하고 결과를 통과/실패/미확인으로 기록해줘. 이메일·비밀번호·토큰은 보고서에 넣지 마.

실습 절차
1. Git PR → Vercel Vite 배포: 아래처럼 소스·SQL·lockfile·환경 예시만 stage하고 diff를 검토해 commit·push한다. 본인 저장소의 main을 대상으로 PR을 만들고 검토·병합한다. Vercel Add New Project→본인 GitHub 저장소 Import에서 앱이 있는 Root Directory, Vite, npm run build, dist를 확인한다. 두 VITE 공개 변수를 Production과 필요한 Preview에 입력하고 Deploy한다.
2. 공개 URL·인증 복귀·DB 재조회 최종 확인: Vercel의 실제 Production URL을 Supabase Site URL로 넣고 Redirect URLs에 정확한 공개 루트와 필요한 로컬/Preview 루트를 허용한다. 설정 변경 뒤 새 배포를 만들고 가입메일이 공개 앱으로 돌아오는지 확인한다. 공개 앱에서 추가·수정·검색·완료·로그아웃·새로고침·다른 브라우저 A 재조회·B 차단을 다시 검사한다.

완료 확인
solution 안 파일을 저장소 루트에 넣었다면 Root Directory는 루트다. solution 폴더 자체를 저장소에 넣었다면 실제 경로를 지정한다. Vercel이 Next.js 또는 public/을 빌드하도록 설정되어 있으면 고친다. DB 비밀번호나 service_role은 입력하지 않는다.
제출: PR URL·main 커밋·배포 커밋·Vercel URL·Supabase 프로젝트 식별자(키 제외)·메일/로그인/DB/권한 체크표. READY는 빌드·배포 상태이며 실제 가입·저장 통과와 다르다. 대기나 미실행은 미확인으로 기록한다.