launch-checklist은(는) 무엇을 하나요?
자동 감사를 실행하고, 코드에서 실패한 항목을 수정한 후, 깨끗해질 때까지 다시 실행하고, 스크립트가 감지할 수 없는 수동 항목을 사용자와 함께 확인하세요. 변경한 내용과 사용자가 직접 처리해야 할 사항을 사용자에게 보고하십시오.
1단계 — 감사 실행
프로덕션 URL이 존재하면 그 URL을 대상으로, 그렇지 않으면 로컬 프로덕션 빌드(npm run build && npm start, dev 서버 사용 금지 — dev 서버는 스크립트를 추가하고 캐싱을 건너뜁니다)를 대상으로 실행합니다:
python3 scripts/audit_site.py https://example.com # 텍스트 보고서
python3 scripts/audit_site.py http://localhost:3000 --max-pages 30 --json > audit.json
확인하는 항목 (자세한 내용은 references/checks.md 참조):
- 페이지별:
<title>(10–60자), 메타 설명 (50–160자), 정확히 하나의<h1>,<html lang>, viewport, canonical (절대 URL, 동일 호스트), og:title/description/image, twitter:card,<img>에alt누락, HTML 크기, 응답 시간, 색인을 원하는 페이지에noindex가 있는지, 페이지 간 중복 제목/설명. - 사이트:
/robots.txt존재 및Disallow: /로 모든 것을 차단하지 않는지 확인, sitemap 참조;/sitemap.xml(또는 robots에 명시된 sitemap)이 파싱되고 해당 URL이 동일 호스트에서 200을 반환하는지; favicon 접근 가능; apple-touch-icon; 임의의 URL이 404를 반환하는지 (200 반환이나 홈으로 리디렉션 금지); http→https 리디렉션 (https 사이트의 경우); 개인정보처리방침 / 이용약관 링크 (사이트가 무언가를 판매하는 경우 환불정책도);/llms.txt존재 (정보 제공용).
하나라도 FAIL이 있으면 종료 코드 1. 크롤링할 페이지: 시작 URL + 동일 호스트 링크, 최대 --max-pages (기본값 20).
2단계 — 코드베이스에서 수정
프레임워크를 감지하고 일치하는 레시피를 사용하십시오. Next.js App Router의 경우 references/fixes-nextjs.md에 즉시 사용 가능한 robots.ts, sitemap.ts, not-found.tsx, 메타데이터, 아이콘 규칙이 있습니다. 일반 HTML/기타 프레임워크: references/fixes-generic.md.
규칙:
- 문제가 반복될 때 페이지별로 수정하지 말고 근본 원인(공유 레이아웃 / 메타데이터 헬퍼)을 수정하십시오.
noindex를 추가하거나 크롤러를 차단하지 마십시오. 사용자에게 먼저 물어보십시오.- 법적 페이지 누락:
legal-pages스킬이 설치되어 있으면 이를 사용하여 생성하고, 그렇지 않으면 사용자에게 알리십시오 — 인라인으로 법적 텍스트를 지어내지 마십시오. - OG 이미지 누락:
og-image-kit스킬이 설치되어 있으면 사용하십시오.
3단계 — FAIL이 없을 때까지 다시 실행
동일한 명령을 다시 실행하십시오. WARN 항목: 쉬운 것은 수정하고, 나머지는 사용자에게 목록으로 제시하십시오.
4단계 — 수동 항목 (스크립트가 확인 불가)
references/manual-checklist.md를 사용자와 함께 검토하십시오 — 분석 도구 설치, 오류 추적, 트랜잭셔널 이메일 전달성(SPF/DKIM/DMARC), 실제 소액 결제로 엔드투엔드 테스트된 결제 흐름, 백업, 가동 시간 모니터, Search Console / Bing Webmaster 인증 및 sitemap 제출, 도메인 갱신 상태. 각 항목을 완료 / 해당 없음 / 사용자 처리로 표시하십시오.
4b단계 — 결제 자체 점검 (사이트가 결제를 받는 경우)
python3 scripts/payment_check.py --src . --provider creem # 코드 스캔
python3 scripts/payment_check.py --url http://localhost:3000 # 실행 중인 빌드 확인
python3 scripts/payment_check.py --url http://localhost:3000 --secret "$CREEM_WEBHOOK_SECRET" # 테스트 모드 시크릿만
FAIL: 웹훅이 서명되지 않거나 위조된 요청을 수락하는 경우, JSON을 확인 전에 파싱하는 경우, 이벤트 ID에 대한 중복 제거가 없는 경우, 성공 페이지가 액세스를 부여하는 경우, NEXT_PUBLIC_*에 있거나 커밋된 결제 시크릿, 웹훅이 리디렉션되거나 봇 챌린지 뒤에 있는 경우. 이를 수정하고 다시 실행한 후 references/payment-checks.md의 수동 카드 테스트(성공 카드, 거절 카드, 환불, 대시보드 재전송, 취소)를 수행하십시오. 절대 라이브 웹훅 시크릿을 전달하지 마십시오. scripts/test_payment_check.py는 스크립트 자체의 테스트입니다. 테스트, 스펙 및 픽스처 파일(*.test.ts, *.spec.tsx, test_*.py, tests/, e2e/, __tests__/, fixtures/ 아래의 모든 파일)은 핸들러 또는 성공 페이지로 판단되지 않습니다. 이 파일들은 의도적으로 서명되지 않은 요청을 보내고 행을 삽입하기 때문입니다. 그러나 커밋된 라이브 키는 여전히 스캔됩니다. 보고서에는 건너뛴 파일 수가 표시됩니다(INFO test files).
보고서 형식
<url> 출시 감사 — <날짜>
FAIL 수정됨: … (파일:줄 변경됨)
WARN 수정됨: …
열려 있음 (사용자 필요): …
수동 체크리스트: x/y 완료