create-saas-starter-workspace 0.1.8 → 0.1.9

package/dist/workspace/.claude/skills/go-live/SKILL.md

@@ -1,68 +0,0 @@
----
-name: go-live
-description: Provision GitHub private repo, Vercel project, Supabase dev/prod, Sentry. Wire env across 3 environments + GitHub Secrets. First deploy and security audit. Use when user runs /go-live after /warmup.
----
-
-# /go-live
-
-dev/prod 클라우드 환경을 뚫어 첫 배포를 진행한다. 최신 외부 서비스 문서를 먼저 탐색하여 올바른 흐름을 이해한다.
-
-> 이 워크스페이스는 web+app이고, 배포 단위는 `web/`다. GitHub repo·`vercel link`·Supabase·Sentry·`git push`는 모두 `web/` 안에서 수행한다. 워크스페이스 루트에서 수행하지 않는다. 먼저 `cd web/`. `mobile/`은 별도이며 앱 단계 `/kickoff`에서 다룬다.
-
-## 1. 이름·GitHub repo
-
-이름은 워크스페이스 루트 `workspace.json`의 `name`(생성 시 입력한 프로젝트명)이다. 리소스 기준 이름: GitHub repo = `<name>-web`, Vercel 프로젝트 = `<name>`, Supabase = `<name>-dev`/`-prod`, Sentry 프로젝트 = `<name>`. **폴더명(`web`)을 리소스 이름으로 쓰지 않는다** — 특히 `vercel link`는 폴더명 `web`을 기본 프로젝트명으로 제안하므로 그대로 수락하지 말고 `<name>`으로 바꾼다. (앱 단계의 mobile repo `<name>-mobile`도 셋업이 이미 생성했다 — package.json·Expo slug와 일치.)
-
-**GitHub repo는 이미 있다.** 셋업의 `connect-repos`가 `<name>-web` private repo를 만들어 `web/`의 origin으로 연결·push해 두었다 — 새로 `gh repo create`·`git init` 하지 않는다. 없다면(doctor가 ✗로 짚는다) 워크스페이스 루트에서 `node scripts/connect-repos.mjs`로 먼저 만든 뒤 진행한다. go-live는 이 repo 위에 클라우드를 붙이고 첫 배포까지 잇는 일이다. secret scanning push protection은 private free에서 미지원이고 GitHub Advanced Security 유료 기능이다. 9-6에서 점검만 skip한다.
-
-## 2. Supabase dev + prod
-
-`<name>-dev`와 `<name>-prod`를 생성한다. Region과 DB password는 Owner와 협의한다. ref·url·publishable·secret을 Management API로 추출한다. 단, 응답 필드명이 버전마다 달라질 수 있으니 jq로 탐색해 적응한다.
-
-dev Auth redirect URL은 즉시 설정한다(`localhost:3000/**` + `https://*.vercel.app/**`). prod redirect는 7-1로 미룬다. 실 prod 도메인이 `<name>.vercel.app`이 아닐 수 있다.
-
-## 3. Vercel link + env 주입
-
-`vercel link`를 실행한다. production은 prod Supabase + `SUPABASE_PROD_REF`, preview·development은 dev + `SUPABASE_DEV_REF`로 채운다. 끝나면 `vercel env pull`로 `.env.local`을 동기화한다.
-
-## 4. Sentry org·project + env 4종
-
-config 파일은 템플릿에 이미 있다. env만 채우면 끝나며 wizard는 불필요하다. `sentry-cli`로 org·project를 조회하거나 생성한다. auth token은 sentry-cli로 발급할 수 없다. Owner가 대시보드(Settings → Auth Tokens)에서 발급해 전달한다.
-
-env 4종(`NEXT_PUBLIC_SENTRY_DSN`·`SENTRY_ORG`·`SENTRY_PROJECT`·`SENTRY_AUTH_TOKEN`)을 Vercel 3환경 + GitHub Secrets 모두에 주입한 뒤 `vercel env pull`로 로컬을 동기화한다.
-
-## 5. `logs` 테이블 마이그레이션
-
-감사 로그용이다. `service_role`만 insert하는 정책과 RLS를 동봉한다. dev는 자동 적용하고, Owner confirm 후 prod에 적용한다.
-
-## 6. GitHub Secrets
-
-CI 빌드용이다. `.env.local`에서 읽어 `gh secret set`으로 주입한다. publishable + URL + Sentry 4종만 넣는다. secret key와 DB ref는 CI 컴파일에 불필요하다(보안 표면을 최소화한다).
-
-## 7. 첫 푸시·배포
-
-main에 push하면 CI와 Vercel 배포가 동시에 트리거된다.
-
-## 7-1. prod Auth redirect URL 갱신
-
-배포 후 실 production 도메인을 Vercel CLI/API로 확인한다. prod Supabase의 `site_url`·`uri_allow_list`를 갱신한다.
-
-## 8. Owner 직접 (Hobby 한도)
-
-- CI Required check: main merge를 CI 통과로 게이트한다 — GitHub repo Settings → Branches → branch protection rule에 CI workflow를 Required status check로 지정한다(plan 무관·벤더 중립으로 동작한다). Vercel 자체 Deployment Checks의 플랜별 가용성은 본문에서 단정하지 않고 `web/docs/LIMITS.md`를 SSOT로 따른다.
-- Preview Deployment Protection: Vercel 대시보드에서 Preview에 Vercel Authentication을 ON으로 켜 preview URL 크롤러를 차단한다. Hobby Standard에서 가능하며 external user 1명으로 제한된다.
-
-## 9. 보안 진단
-
-| # | 검사 | 실패 시 |
-|---|---|---|
-| 1 | `.env*` gitignored | `.gitignore` 패치 |
-| 2 | secret key가 `web/app/`·`web/components/`에 노출 (grep) | **critical** |
-| 3 | `NEXT_PUBLIC_` 접두사가 secret·service·token에 | **critical** |
-| 4 | repo visibility = PRIVATE | confirm 후 전환 |
-| 5 | 8단계 대시보드 설정 완료 | Owner에 확인 |
-| 6 | secret scanning push protection 활성 | private+free는 미지원(GitHub Advanced Security 유료) — 점검 자체 skip |
-
-## confirm 경계
-
-prod `db push` (5)와 public→private 전환 (9-4)은 Owner confirm을 받는다. 그 외는 자동이다.

package/dist/workspace/.claude/skills/kickoff/SKILL.md

@@ -1,72 +0,0 @@
----
-name: kickoff
-description: "Configure the workspace's already-present mobile/ shell to wrap your deployed web — a one-time bootstrap: interview what to build (identity, tabs, features, login), give an honest webview-fit verdict (advisory, never blocking) and disclose up-front cost (Apple $99 / Google $25 / EAS limits) before any effort, set the app identity + deployed web URL, connect login, pick initial capabilities, and leave a plan. Use when appifying a deployed web for the first time, or invokes /kickoff."
-user-invocable: true
----
-
-# /kickoff
-
-배포된 웹을 처음으로 앱으로 감싸는 1회 부트스트랩이다. 킥오프 미팅 한 흐름으로 진행한다. 이해(intake), 정직한 진단·비용, 구성(정체성·URL·로그인·능력), 계획·인계 순서다.
-
-`mobile/`은 이 워크스페이스에 이미 들어 있다. `/kickoff`은 그것을 새로 만들지 않고, 당신의 배포된 웹에 맞춰 설정하는 1회 셋업이다. 계약(`contract.ts`·`reader.ts`)도 이미 `web/lib/bridge/`에 바이트 단위로 동일하게 설치돼 있다. `web/`은 배포돼 있어야 한다(`/go-live` 후 `git push`로 prod LIVE). 진입 루트(워크스페이스)에서 작동하며 `mobile/`·`web/`은 cwd 하위 서브디렉토리로 다룬다.
-
-> 이미 한 번 구성했다면 부트스트랩 대상이 아니다. 미리보기는 `/preview`, 업데이트는 `/release`로 안내한다.
-
-폼이 아니라 대화로, 한 번에 하나씩, 추천값을 제시하며 묻는다. 비용은 먼저 알린다. 제한은 정직하게 고지한다. 끝에 명확한 다음 단계를 남긴다.
-
-## 1. 웹 감지 · intake (이해)
-
-`web/`과 그 prod 배포 URL을 확인한다(앱이 띄울 단일 타깃). 그다음 핵심 5개를 하나씩 묻는다.
-
-1. 앱 정체성. 표시 이름·번들 ID·스킴·아이콘.
-2. 화면/탭 구조. 웹의 어떤 경로가 앱의 진입·탭이 되는가.
-3. 기능. 무엇을 쓰고 싶은가(능력 분류는 6단계에서 정리한다).
-4. 로그인. 이메일/비번·매직링크인지, 소셜 로그인(구글/애플)을 원하는지.
-5. 비용·셋업 예고. 2단계에서 공개한다고 미리 알린다.
-
-## 2. 정직한 webview-fit 판정 + 비용 (진단)
-
-intake ①~③로 webview 적합도를 스스로 판정하고 확인만 받는다(막지 않는다, 최종 결정은 Owner). 핵심 경험이 60fps 제스처·카메라 AR·미디어 캡처거나, 앱 자체가 주력 상품이거나 게임이면 네이티브로 따로 만들 것을 권고한다. 이 셸은 그 제작에 맞지 않다.
-
-이어서 들어가는 비용을 노력을 들이기 전에 공개한다.
-
-- Apple Developer $99/년, Google Play $25(둘 다 환불 불가).
-- EAS 무료 티어 한도(동시성 1·월 빌드 수·큐 대기).
-
-Owner confirm. 비용을 알린 뒤 계속할지 확정받고서야 다음 단계로 간다.
-
-## 3. mobile/ 구성
-
-`mobile/`은 이미 워크스페이스에 있으니 스캐폴드 단계는 없다. 여기서는 셸을 당신 웹에 맞춰 설정한다.
-
-- intake ①의 정체성(이름·번들 ID·스킴·아이콘)을 `mobile/app.config.ts`에 반영한다. 번들 ID·스킴은 확정 뒤 바꾸기 어려우니 Owner confirm으로 굳힌다.
-- `EXPO_PUBLIC_WEB_URL`을 배포된 prod 웹 주소(https)로 설정한다. `mobile/.env.example`·`mobile/eas.json`의 자리표시 값은 그대로 빌드하면 시작 시 에러로 막힌다(흰 화면 대신 정직하게 실패하도록 설계됨). `EXPO_PUBLIC_*`는 빌드 시점에 인라인되므로 주소를 바꾸면 재빌드가 필요하다.
-
-## 4. 웹 어댑터 (web/)
-
-계약(`contract.ts`·`reader.ts`)은 이미 `web/lib/bridge/`에 바이트 단위로 동일하게 설치돼 있고(`pnpm run doctor`가 동일성을 점검한다) 다시 복사하지 않는다. 웹이 앱과 실제로 대화하게 만드는 얇은 옵트인 레이어만 필요할 때 추가한다. 규약·보안 불변식은 인라인하지 않고 `bridge-guide`를 따른다.
-
-세션 핸드오프는 fast-follow다. v1은 호출자가 없다. 기본 로그인은 웹뷰 안의 웹 로그인이 그대로 동작하고, 핸드오프 라우트(POST `/auth/app-bridge` + nonce)는 네이티브 소셜 로그인을 켤 때만 살아난다. 토큰은 브릿지·URL로 보내지 않는다(1회용 nonce만 보낸다).
-
-## 5. 로그인 연결
-
-intake ④에서 고른 길을 잇는다. 이메일/비번·매직링크는 웹뷰 안 웹 로그인이 그대로라 추가 배선이 없다. 소셜 로그인(구글/애플)은 fast-follow 경로다. 웹뷰 안 OAuth는 막혀 있어 네이티브로 구현하며, 콘솔·자격증명 셋업은 `/launch`가 맡는다. 소셜 로그인을 쓰면 Apple 4.8상 "애플로 로그인"도 함께 필요함을 고지한다.
-
-## 6. 초기 능력 선택
-
-푸시를 켤지 정한다(켜기 권장). v1에서 켤 수 있는 네이티브 능력은 푸시뿐이다. 파일 업로드·공유·딥링크·보안 저장은 셸이 기본으로 갖춘다.
-
-켜면 `expo-notifications`·권한·토큰 등록·`PUSH_TOKEN_UPDATED` 송출·웹의 `push.v1` 게이트를 배선한다(네이티브 변경이므로 재빌드한다). 계약·셸 cold-start 규약은 `bridge-guide`·`native-app-guide`, 스토어 푸시 자격증명(APNs·FCM)은 `/launch`가 맡는다.
-
-## 7. 계획 · 인계
-
-단일 plan 파일을 남긴다. 정체성·탭·기능·로그인·능력·비용·후속을 적은 결정 기록이며, 이후 빌드 흐름의 입력이 된다.
-
-다음은 화면을 만들며 앱을 보는 단계인 `/preview`로 이어진다. 깊은 요구사항은 `/probe`에 위임한다.
-
-## confirm 경계
-
-- 비용 announce 후 계속 여부(Apple $99 · Google $25 · EAS 한도). Owner confirm.
-- webview-fit 부적합. 권고하되 막지 않으며, 계속 여부는 Owner가 결정한다.
-- 번들 ID·스킴 확정. 사실상 비가역이므로 Owner confirm.
-- 첫 스토어 로그인·2FA·결제·콘솔 셋업은 이 스킬 범위 밖이다. `/launch`가 맡는다.

package/dist/workspace/.claude/skills/launch/SKILL.md

@@ -1,69 +0,0 @@
----
-name: launch
-description: Set up App Store Connect and Play Console for the first release — developer accounts, app records, signing keys, store listing, privacy declarations — then the first manual submit-for-review. Use when the Owner is ready to ship to the stores for the first time, or invokes /launch.
-user-invocable: true
----
-
-# /launch
-
-앱을 앱스토어·플레이스토어에 처음 올리기 위한 1회 출시 준비다. 개발자 계정, 앱 레코드, 서명 키, 스토어 리스팅, 프라이버시 선언을 갖추고 첫 수동 심사 제출까지 데려간다. 비개발자에게 가장 큰 난관이라, go-live처럼 단계별로 확인받으며 진행한다.
-
-상세 규약·콘솔 절차·심사 통과 전략은 `store-release-guide`가 정본이고, EAS 빌드·제출 명령은 `eas-deploy-guide`가 정본이다. 이 스킬은 순서와 게이트만 잡고, 세부는 가이드를 가리킨다.
-
-## 진행 방식 (3단계)
-
-1. **읽기전용 조사**: 계정 유무, 기존 자격증명, 배포된 웹의 컴플라이언스 표면(계정 삭제·트래커)을 먼저 살핀다.
-2. **일괄 플랜**: AskUserQuestion으로 결정과 비용을 한 번에 묻는다.
-3. **confirm 실행**: 비가역·돈·2FA가 걸린 일만 Owner confirm 뒤 진행한다.
-
-## 누가 무엇을 하나 (가역성)
-
-- 🟢 AI / CLI: 자격증명 파일 작업, EAS 빌드·제출, `eas.json`의 public 값.
-- 🟡 Owner 대시보드 (AI가 정확히 안내): 첫 Apple 로그인과 2FA, 스크린샷, App Privacy·Data Safety 라벨, Play 서비스 계정 JSON.
-- 🔴 Owner 직접 (대리 불가): 카드 결제, 신원 검증, 멤버십 가입.
-
-## 1. 개발자 계정 — 가장 먼저 (🔴 Owner)
-
-Apple은 연 $99, Google은 $25, 둘 다 환불 불가다. Individual/Personal을 권장한다(D-U-N-S를 피하고 신원검증만 거친다). 개인 법적 이름이 공개 판매자명이 되므로, 한 줄 confirm을 받는다.
-
-🔴 트랩 — 리드타임을 지배: Google 신규 개인계정은 production 전에 비공개(closed) 테스트 **12명·14일 연속**이 강제다(내부 테스트는 카운트하지 않는다). 이게 출시 전체에서 가장 긴 지연이므로, **Google Play Console 가입을 가장 먼저** 해 둔다. Apple도 결제 후 멤버십 활성화에 시간이 걸린다. 두 계정 모두 코드 작업 전에 시작한다.
-
-## 2. 앱 레코드·서명 자격증명 (🟢 대부분 자동)
-
-EAS가 iOS 인증서·프로비저닝·APNs 키와 Android 업로드 키스토어를 자동 생성한다(`.cer`/`.jks`는 손대지 않는다). iOS ASC API 키도 EAS 자동 생성이 기본이며, Account Holder의 1회 'Request Access' 약관 동의가 선행이다. iOS는 첫 제출이 ASC 앱 레코드를 자동 생성해 TestFlight까지 간다.
-
-🔴 트랩: Android 첫 AAB는 Play Console에 **수동으로 1회 업로드**해야 한다(Play API는 첫 릴리스를 만들지 못한다). 첫 자동 제출 실패는 정상이니 선고지한다. 이후부터 `eas submit -p android`가 동작한다. Play 제출용 서비스 계정 JSON은 항상 수동(🟡)이며 EAS 서버에 저장한다(`eas.json`에 시크릿 경로를 넣지 않는다). 절차는 `store-release-guide`.
-
-## 3. 푸시 자격증명 (kickoff에서 푸시를 켰을 때만)
-
-앱은 Expo Push Token만 쓴다. iOS APNs 키는 EAS 자동(🟢)이고, Android FCM v1 서비스 계정은 Firebase Console에서 수동 생성한 뒤 EAS에 업로드한다(🟡). `google-services.json`(public·커밋), FCM SA JSON(시크릿), Play 제출 SA JSON은 각각 별개 파일이니 혼동하지 않는다. 매핑은 `store-release-guide`.
-
-## 4. 소셜 로그인 콘솔 (소셜을 켰을 때만, 🟡)
-
-Google OAuth 클라이언트는 Web·iOS·Android 3종이고, 코드에는 webClientId(Web)만 넣는다. Apple은 게이트로 네이티브 idToken(기본·bundle ID만)을 권장한다. 한국 개발자는 2026-01-01부터 웹 OAuth용 Services ID에 server-to-server 엔드포인트가 강제되므로, 네이티브 방식이 그 부담을 피한다.
-
-🟡 트랩: iOS reversed URL scheme은 플러그인에 **수동으로 붙여넣는다**(자동 계산이 아니다). SHA-1 지문은 **모든** 서명 키를 등록한다(EAS 빌드 키 포함, 일부만 하면 `DEVELOPER_ERROR`). 소셜을 켜면 Apple 4.8에 따라 Sign in with Apple도 동등하게 들어가고, Supabase Apple provider 실배선까지 점검한다. 절차는 `store-release-guide`.
-
-## 5. 스토어 리스팅·컴플라이언스 (🟡 수동)
-
-스크린샷, 연령등급(IARC), App Privacy(iOS)·Data Safety(Android) 라벨은 수동이다. 세 프라이버시 산출물(ASC 라벨·Data Safety·`PrivacyInfo.xcprivacy`)은 taxonomy가 달라 복붙이 안 되므로, 단일 데이터 인벤토리에서 각각 매핑한다.
-
-게이트로 점검할 항목:
-- **계정 삭제 (5.1.1(v))**: 배포된 웹에 인앱 삭제 경로가 있고, 네이티브 소셜 포함 모든 로그인에서 도달 가능한지 확인한다(웹뷰 렌더는 인앱으로 인정된다).
-- **ATT**: 기본은 No다. 단, 웹뷰가 로드하는 배포된 웹의 트래커(GA4·Pixel 등)는 개발자 책임이므로, 배포 웹 스크립트를 실점검한다.
-
-세부 기준은 `store-release-guide`.
-
-## 6. 첫 제출 → 공개 심사 (🔴 트랩 + confirm)
-
-production 빌드 하나를 만들어 두 스토어 테스트 채널로 보낸다(iOS는 TestFlight, Android는 내부 트랙). 빌드·제출 명령은 `eas-deploy-guide`.
-
-🔴 트랩: `eas submit`은 **공개 심사를 제출하지 않는다**. 테스트 채널까지만 올린다. 공개 출시는 수동 + 명시 confirm이다:
-- **iOS**: App Store Connect에서 "Submit for Review".
-- **Android**: 비공개 테스트 12명·14일 게이트를 통과한 뒤 production으로 승급.
-
-같은 production 빌드를 그대로 공개로 승급한다. 전용 preview 빌드를 따로 만들지 않는다.
-
-## confirm 경계
-
-개발자 계정 가입·결제 (1, 🔴), 공개 심사 제출과 production 승급 (6, 🔴)은 Owner confirm을 받는다. 자격증명 파일 작업과 테스트 채널 제출은 자동(🟢)이다. 첫 Apple 로그인과 2FA·라벨·SA JSON은 Owner가 대시보드에서 진행한다(🟡, AI가 안내).

package/dist/workspace/.claude/skills/preview/SKILL.md

@@ -1,43 +0,0 @@
----
-name: preview
-description: Build the app and ship that build to the store test channel (TestFlight on iOS, Play internal test on Android) so the Owner installs it on a real phone and sees it running against the prod web over https — no dedicated preview build, and Expo Go will not work because of native modules. Use when the Owner wants to preview the app while building it, or invokes /preview.
-user-invocable: true
----
-
-# /preview
-
-앱을 만드는 내내 반복하는 동작이다. Owner가 앱이 실제 폰에서 도는 모습을 본다.
-
-미리보기는 production 빌드 하나를 스토어 테스트 채널(iOS TestFlight, Android Play 내부 테스트)로 보내 실폰에서 확인한다. 그 빌드를 나중에 그대로 공개로 승급하므로 전용 preview 빌드를 따로 만들지 않는다. EAS 빌드 수를 절약하고, 실제 출시 아티팩트를 그대로 검증한다. 빌드 프로파일, 제출, OTA 판단 등 상세 흐름은 `eas-deploy-guide`를 따른다.
-
-두 가지가 항상 참이다.
-
-- Expo Go로는 뜨지 않는다(네이티브 모듈). 진짜 빌드가 필요하다.
-- 실기기는 prod 웹 https를 로드한다. localhost는 실폰에서 카메라, Web Crypto, Secure 쿠키를 소리 없이 깨뜨리는 함정이다(이유는 `eas-deploy-guide`).
-
-## 1. 첫 빌드 준비 (Owner)
-
-- Expo 계정 로그인은 Owner가 직접 한다(2FA). 이후 빌드는 AI가 자동으로 돌린다.
-- 스토어 테스트 채널은 개발자 계정이 있어야 쓴다. 아직 `/launch` 전이라 계정이 없으면 EAS 내부배포로 먼저 설치한다(iOS는 UDID 등록, `store-release-guide`). 계정과 채널 셋업은 `/launch`가 맡는다.
-
-## 2. 빌드 → 테스트 채널
-
-```bash
-npx eas-cli build --profile production --platform all --auto-submit --no-wait
-# iOS → TestFlight, Android → Play 내부 테스트
-```
-
-첫 빌드는 큐를 포함해 10–20분 걸린다(멈춘 게 아니다). 백그라운드 진행은 항상 `--no-wait`로 한다. JS만 바뀐 변경은 빌드 풀을 쓰지 않으니 재빌드 없이 OTA로 미리 본다(`eas-deploy-guide`).
-
-## 3. 실폰에서 확인
-
-TestFlight(iOS) 또는 초대 링크(Android)로 설치해 앱을 연다. 앱이 prod 웹 https를 띄우고 화면이 돌면 성공이다. 로그인, 푸시처럼 실기기에서만 검증되는 항목은 `eas-deploy-guide` 플랫폼 매트릭스를 따른다.
-
-## 셸만 빠르게 고칠 때 (선택·고급)
-
-네이티브 셸(WebView 호스트 등)만 빠르게 반복할 땐 Mac이나 에뮬 시뮬레이터에 `development` 프로파일(Metro Fast Refresh)을 쓴다. 시뮬레이터에 한해 웹뷰를 localhost로 가리킬 수 있다(실기기는 금지). 배선은 `eas-deploy-guide`(빌드 프로파일)와 `native-app-guide`(셸 레시피)를 따른다. 대부분은 여기까지 가지 않는다. 웹 UI는 브라우저에서 고친다.
-
-## confirm 경계
-
-- 첫 Expo 계정 로그인과 2FA는 Owner가 직접 한다(AI 대리 불가). 이후 빌드는 자동이다.
-- 스토어 공개 승급은 하지 않는다. `/preview`는 테스트 채널까지만 책임지고, 공개 출시는 `/launch`와 `/release` 몫이다.

package/dist/workspace/.claude/skills/vercel-cron/SKILL.md

@@ -1,17 +0,0 @@
----
-name: vercel-cron
-description: Rules for adding Vercel Cron jobs in this template. Use when adding scheduled tasks or periodic jobs.
-user-invocable: false
----
-
-# vercel-cron
-
-Vercel Cron 추가 시 분기·로그·테스트 함정을 짚는다.
-
-주기나 부하가 Hobby 한도와 부딪힐 것 같으면 Owner에게 먼저 알린다.
-
-- **prod에서만 실행한다.** `env.APP_ENV !== "production"`이면 no-op으로 둔다. preview에서 dev DB와 외부 API를 낭비하는 일을 막는다.
-- 성공과 실패를 모두 logger로 기록한다. 성공은 `audit`, 실패는 `error`로 남긴다. Sentry와 logs 송출은 자동으로 이뤄진다.
-- 테스트 함정: `env`는 모듈 로드 시 한 번만 parse하므로 `vi.stubEnv`가 듣지 않는다. `vi.mock("@/lib/env.server")`로 통째 교체한다.
-
-그 외(헤더 검증·idempotent·`CRON_SECRET`·`vercel.json`·`env.server.ts` 등)는 Vercel docs와 코드 주석을 따른다.

package/dist/workspace/.claude/skills/warmup/SKILL.md

@@ -1,33 +0,0 @@
----
-name: warmup
-description: Verify the AI agent's tools and environment (CLI installs, logins) and install/audit dependencies in web/ and mobile/, fixing issues where possible. Use when the Owner runs /warmup, just opened the workspace, or before tasks that depend on external CLIs working.
----
-
-# /warmup
-
-AI(CLI agent)가 이 워크스페이스에서 작업할 준비가 됐는지 점검한다.
-도구·자격·환경과 프로젝트의 실행 환경을 정상화한다.
-
-스스로 바로잡을 수 있는 것은 자율로 설정한다.
-Owner의 행동이 필요한 부분은 AskUserQuestion으로 해결한다.
-
-## CLI
-
-- `node` — 현 LTS
-- `pnpm` — 10 이상 (각 repo `package.json`의 `packageManager`로 버전 고정)
-- `git`
-- `gh` — 로그인
-- `vercel` — 로그인
-- `pnpm exec supabase` — 로그인 (CLI는 `web/` devDependency로 고정되어 있다 — `web/`에서 실행. `npx supabase`로 별도 사본을 받지 않는다)
-- `sentry-cli` — 로그인
-
-앱(`mobile/`)까지 갈 때 필요한 `eas-cli` 로그인은 첫 빌드 시점에 `/preview`가 안내한다. 여기서는 점검하지 않는다.
-
-## 의존성
-
-워크스페이스 루트의 `package.json`은 `pnpm run doctor`(환경 점검) 진입점만 가진다 — 루트에 의존성을 설치하지 않는다. `web/`과 `mobile/`은 각자 독립 프로젝트이므로 의존성도 각자 설치한다.
-
-- `web/`에서 `pnpm install` 후 `pnpm audit`.
-- `mobile/`에서도 동일하게 한다.
-
-세부 정책은 각 repo의 `.npmrc`와 CI 설정을 따른다. 보안 게이트(cooldown, audit level 등)는 우회하거나 수정하지 않는다.