BizCrush 어드민 가이드

여기서 외울 것 세 가지

1. 승인 없이 발행할 수 없습니다. in_review에서 발행 버튼을 눌러도 거부됩니다.
2. 발행은 종단이 아닙니다. 계약이 "삭제·정정 요청 접수 즉시 반영"을 요구하므로 내리는 경로가 반드시 있어야 합니다.
3. 내린 기사를 바로 다시 올릴 수 없습니다. 내린 이유가 사실 오류일 수 있어서, 재발행도 검수를 다시 거칩니다.

기사 말고 하나 더 있습니다 — 정정 요청

정정 요청도 자체 상태 머신을 갖습니다. 기사 전이도만 보고 있으면 여기서 걸립니다.

순차 진행이고 건너뛸 수 없습니다. 로컬 실증에서 reprocessing에서 곧바로 「반영 종결」을 누르면 거부됐습니다 — 반드시 「재검수 진입」을 거쳐야 합니다. api가 요청 상태를 기사 상태보다 먼저 검사하기 때문입니다.

그리고 한 기사에 열린 요청은 하나뿐입니다. 접수·재처리·재검수 중 하나라도 진행 중이면 두 번째 접수가 DB에서 거부되고, 화면은 「처리 중인 정정 요청이 이미 있습니다 — 현재 상태: …」로 이유를 말해 줍니다. 종결·기각 후에는 다시 접수할 수 있습니다.

큐 탭 7종 — in_review · approved · published · unpublished · draft · gate_failed · rejected. 뒤의 두 탭은 나중에 추가됐는데, 없던 동안 반려·탈락 기사는 어느 화면에도 보이지 않았습니다. 반려 사유를 다시 볼 수 있는 곳은 이 탭뿐입니다.

정본 packages/transitions/magazine_transitions/transitions.py · docs/spec/db-schema.md

A. 연습용 — 전부 로컬 안전

로컬 화면이 로컬 api를 보고, 로컬 DB를 씁니다. 무엇을 눌러도 실제 기사에 영향이 없으니 여기서 마음껏 익히세요.

1. 로컬 Postgres와 스키마 준비

   로컬 개발 가이드의 컨테이너 기동과 마이그레이션 적용을 먼저 끝냅니다.

2. 시드 넣기

   파트너 계정 1개와, 검수 큐에 뜰 기사 1건을 만듭니다. 큐 데이터는 한 줄 삽입으로 안 되고 매거진 5단계 체인이 필요합니다 — 가이드에 SQL이 그대로 있습니다.

3. api와 화면을 각각 띄우기

   터미널 두 개를 씁니다. api는 8100, 화면은 8200입니다. 값은 로컬 전용을 명령줄로 줍니다.

   # 터미널 1 — api
   uvicorn engine_api.main:app --port 8100
   
   # 터미널 2 — 어드민 화면
   ENGINE_API_BASE_URL=http://localhost:8100 \
   uvicorn engine_admin_web.main:app --port 8200

4. 브라우저로 왕복

   http://localhost:8200 — 파트너로 로그인해 정정을 접수하고, 내부 로그인으로 넘어가 승인·발행·반려를 눌러 봅니다. 미승인 기사에서 발행을 눌러 거부 배너를 일부러 한 번 보는 것을 권합니다.

B. 실진행 — 로컬 화면 + 라이브 api 실 데이터

개방 전까지 실제 검수·승인·발행을 하는 유일한 경로입니다. 화면만 로컬에서 띄우고 api는 라이브를 가리킵니다. 라이브 api는 이미 열려 있어서 별도 인프라 권한이 필요 없습니다.

정본 docs/guide/dev-local.md §2-3 (시드·기동 명령 전문)

1. 기사 검수하고 발행하기

1. 큐에서 고르기

   /review의 in_review 탭. 행 머리에 매체 라벨이 붙습니다.

2. 상세에서 대조하기

   본문과 AI 요약을 나란히 봅니다. 요약은 원문 요약이 아니라 본문 요약이므로, 요약의 모든 사실이 본문에 있는지가 확인 지점입니다.

3. 출처 표기 확인

   재구성 기사인데 출처 표기가 비어 있으면 붉은 경고 배너가 뜹니다. 발행을 막지는 않습니다 — 판단은 검수자 몫이라는 뜻이니, 배너가 뜨면 원인을 확인하고 넘어갈지 결정하세요.

4. 승인 → 발행

   두 번 누릅니다. 한 번에 되지 않는 것이 설계입니다.

2. 삭제 요청 처리하기

제휴사가 자기 기사 상세에서 삭제를 요청하면 접수와 차단이 함께 일어나고, 발행본은 즉시 내려갑니다. 내부에서 할 일은 사후 관리입니다.

• /review/suppressions에서 무엇이 내려가 있는지 봅니다.
• 잘못 내려간 건은 해제합니다. 해제만 하면 발행본이 살아나지 않으므로, 같은 화면의 되살리기로 검수에 다시 넣습니다.
• 내부 판단으로 먼저 내려야 할 때는 같은 화면에서 수기 차단이 됩니다.

3. 정정 요청 처리하기

/review/corrections에서 목록을 보고, 행을 누르면 우리 재구성 기사로 옵니다. 진행은 네 가지입니다 — 재생성 시작 · 재검수 진입 · 반영 종결 · 기각.

4. 파트너 계정 발급하기

1. 담당자 지정 받기

   계약 채널로 이름과 업무 이메일 하나를 받습니다. 시범 기간은 1인 원칙입니다.

2. 화면에서 발급

   /review/accounts에서 만듭니다. 임시 비밀번호는 서버가 만들고 화면에 딱 한 번 보입니다 — 새로 고치면 다시 볼 수 없으니 그 자리에서 옮겨 두세요.

3. 분리 전달

   주소와 아이디는 메일로, 임시 비밀번호는 다른 채널로 보냅니다. 한 채널이 유출돼도 로그인이 안 되게 하는 최소 조치입니다.

4. 정지·재발급

   같은 화면에서 정지/해제와 비밀번호 재발급이 됩니다. 정지된 계정의 로그인 응답은 없는 계정과 똑같습니다 — 계정 존재 여부를 알려 주지 않기 위해서입니다.

정본 정책 docs/guide/partner-account-issuance.md §1·§3·§4 / 화면 절차 이 문서