결과 기록하기: 상태, 증거, 그리고 record.py

모든 디렉터리 시도는 명령 하나로 끝납니다. scripts/record.py는 제품 폴더의 submissions.json에 플랫폼마다 현재 상태를 나타내는 행을 하나씩 기록하며, 툴킷이 증명되지 않았거나 안전하지 않다고 보는 행은 거부합니다. 이 거부가 핵심입니다. 트래커가 있기에 “디렉터리 40곳에 제출했다”가 “폼 40개를 채우고 잘되길 바랐다”라는 뜻이 되지 않습니다. 이 가이드는 상태, 각 상태에 필요한 증거, 명령의 플래그, 메모에 쓸 수 있는 것과 없는 것을 다룹니다. RUNBOOK.md와 스크립트 자체 검사를 요약한 것일 뿐, 그것을 대신하지는 않습니다.

명령

이미 만들어 둔 비공개 프로젝트 폴더를 대상으로, 툴킷 디렉터리에서 실행하는 런북의 예시입니다.

Windows에서는 아래 명령의 python3 대신 py -3를 사용하세요(Python 3.10 이상을 실행하는 명령이 python이라면 그것을 써도 됩니다). 워크스페이스는 OneDrive 같은 동기화 폴더가 아닌 비공개 로컬 폴더에 두세요. 여러 줄로 된 셸 예시는 PowerShell에서 명령을 한 줄로 합치고 줄 끝의 \ 문자를 지우세요.

python3 scripts/record.py --project ../private-product pitchwall draft \
  --note "Product import corrected; final form not sent" \
  --next-action "Check saved profile and review final form"

위치 인수 두 개(플랫폼 ID, 상태)와 필수 옵션 두 개(--note, --next-action)가 있습니다. 선택 플래그는 --public-url, --confirmed-public, --launch-date, --replace입니다. 플랫폼 ID는 소문자 슬러그여야 하고, 상태는 아래 11가지 중 하나여야 하며, 규칙을 하나라도 어기면 트래커는 이유를 설명하고 종료합니다. 로컬 대시보드의 기록 폼도 같은 규칙으로 같은 함수를 호출합니다.

11가지 상태와 최소 증거

런북의 표를 간단히 옮기면 다음과 같습니다.

상태	반드시 관찰했어야 하는 것
draft	작업은 준비됐지만 최종 제출은 확인되지 않음.
prepared_needs_human	소유자가 해야 할 구체적인 조치나 확인 절차(CAPTCHA, 2단계 인증)가 준비된 작업을 막고 있음.
submitted_pending_review	플랫폼이 제출을 명시적으로 접수했고, 검토가 남아 있음.
queued	플랫폼이 대기열 순번이나 대기자 명단 등록을 확인함.
scheduled	플랫폼이 하한선 당일 또는 그 이후의 출시일을 확정함. 남은 승인 절차는 메모에 남김.
live	대기 표시 없는 공개 등록 페이지를 검증함. 공개 URL과 --confirmed-public 필요.
already_listed	기존 공개 등록 페이지를 검증함. 요건은 live와 같음.
blocked	자격 요건, 계정 한도, 누락된 필수 정보 때문에 진행할 수 없음.
deferred_paid	이용 가능한 경로가 결제를 요구함. 아무것도 구매하지 않음.
not_a_fit	제품이 대상 사용자나 등록 기준에 맞지 않음.
unavailable	해당 경로나 플랫폼을 현재 이용할 수 없음. 문제를 메모에 남김.

가장 중요한 구분은 초안과 제출의 차이, 그리고 검토 대기와 게시의 차이입니다. 감사 인사 화면이 떴다고 등록 페이지가 게시된 것은 아닙니다. 접속할 수 있는 페이지라도 여전히 승인 대기 중일 수 있습니다. “파트너 사이트에도 배포” 체크박스에 표시했다고 해서 두 번째 플랫폼이 무언가를 받았다는 뜻도 아닙니다. 합계가 부풀려지지 않도록 플랫폼마다 결과를 독립적으로 관리합니다.

스크립트가 적용하는 규칙

• 공개 상태에는 증거가 필요합니다. live와 already_listed에는 직접 검토한 HTTPS URL을 담은 --public-url(쿼리 문자열, 프래그먼트, 계정·대시보드·로그인 경로가 없어야 함)과 함께 페이지를 직접 확인했다는 진술인 --confirmed-public이 필요합니다.
• 예약에는 날짜가 필요합니다. --launch-date YYYY-MM-DD는 필수이며 product.json의 earliest_launch_date보다 이르면 안 됩니다. 이유는 출시일 하한선 가이드에서 설명합니다.
• 메모는 깨끗하게 유지합니다. 메모와 다음 할 일에는 링크, 이메일 주소, password= 형태의 키-값 쌍, 알려진 토큰 접두사를 넣을 수 없습니다. 트래커 파일은 공유할 수 있도록 만든 것이며, 계정 URL이 담긴 증거는 비공개 저장소에 두어야 합니다.
• 플랫폼당 한 행. 플랫폼에 이미 행이 있으면 --replace를 넘기지 않는 한 명령이 실패합니다. --replace는 기존 행과 플랫폼을 모두 확인한 뒤에만 쓰세요. 교체는 의도해서 하는 일이지, 부수 효과로 일어나서는 안 됩니다.
• 심볼릭 링크 금지, 원자적 쓰기, 잠금 파일. 지루한 세부 사항이지만, 에이전트 두 개가 동시에 기록해도 트래커가 망가지지 않는 이유가 바로 이것입니다.

중복 없이 재개하기

다음 세션을 시작할 때는 폼을 건드리기 전에 트래커부터 읽으세요. 사람에게 넘긴 작업과 확인할 때가 된 예약 출시를 먼저 처리하고, 그다음 안내된 검토 기간이 지난 대기 중 제출을 확인하세요. 플랫폼이 검토 기간을 알려 주지 않는다면 날짜를 지어내지 말고 소유자와 후속 확인 날짜를 합의하세요. 그리고 대기열에서 순서를 앞당기려고 다시 제출하지 마세요. 기존 기록을 다시 확인하면 됩니다. 트래커는 이력이 아니라 현재 상태를 저장합니다. 감사 추적이 필요하다면 민감 정보를 가린 실행 요약을 따로 보관하세요.

실제 플랫폼에서 각 상태가 어떻게 나타나는지는 제출 상태에 관한 글과 먼저 나온 중복 집계 없는 제출 추적 가이드에서 볼 수 있습니다. 상태 용어 자체는 등록 상태에 정의되어 있습니다.