아이티데일리 어드민 E2E 런북

0배포 URL

두 로그인은 입구가 다르다. 파트너는 /login(이메일·비밀번호, 계정별), 내부는 /internal/login(공용 패스프레이즈 1개). 세션 종류가 달라 서로의 화면에 들어가지 못한다.

프로젝트 번호 425032198823. api 루트·/docs는 404가 정상이다(코드에서 꺼져 있고 문서는 GCS URL이 대신한다).

0-1 · 자격증명 취급주의

패스프레이즈 출처

Secret Manager admin-web-internal-password 버전 1(유일 버전). 버전이 늘면 latest가 도는 리비전의 값과 갈릴 수 있다 — Cloud Run은 인스턴스 시작 때 해석한다.

파트너 계정

id 13 · itdaily 스코프 · 「T6 데모 파트너」. 임시비번은 변경 완료라 password_reset_required=false — 첫 화면이 /my/password가 아니라 /my/articles다.

실데이터 주의

13에는 8/18 회차의 실제 이력이 붙어 있다(takedown #2 · correction #13). 여기서 또 요청을 걸면 그 위에 쌓인다.

회차 후 되돌림

/review/accounts에서 13 정지 — 8/18 audit이 기록한 상태(R2 검증 결과)로 복귀시킨다.

A내부 검수자 E2E

패스프레이즈 하나로 들어가는 검수 대시보드. 발행 왕복(AC ⑧⑨⑩⑪)이 핵심 구간이다.

A-1 · 로그인

1. 패스프레이즈 확보

   Secret Manager admin-web-internal-password. 값을 아는 사람에게 받거나 권한이 있으면:

   gcloud secrets versions access latest \
     --secret=admin-web-internal-password --project=<프로젝트>

2. /internal/login에서 입력 → /review로 이동

   잠금 정책

   IP 기준 10회 / 15분 실패 시 15분 잠금(429). 잠금 중엔 옳은 값을 넣어도 429다 — 카운터는 api DB에 있어 인스턴스가 여러 개여도 상한이 하나다.

A-2 · 검수 큐 → 승인 → 발행 → 확인

1. 큐에서 기사 고르기

   /review 기본 탭은 in_review. 탭 7개: in_review · approved · published · unpublished · draft · gate_failed · rejected. 사전 적재분 중 검수 대기 5건이 있다.

2. 상세 /review/{magazine_id}에서 볼 것

   • 재구성 본문 · AI 요약 박스 · 본문 말미 출처 블록
   • 고지 2필드 미리보기(ai_notice · source_notice) — 검수자가 보는 문면 = 소비자가 받는 문면
   • 계약 협의 기한 배너(2027-01-17) 상시 노출
   • 액션 6종: approve reject publish unpublish requeue regenerate

3. 먼저 publish를 눌러 본다 → 409 + 사유 배너

   승인 없이 발행 불가(불변 원칙 4)의 라이브 실증. 화면이 막는 게 아니라 api·전이 모듈이 막고 화면은 사유를 그대로 보여 준다.

4. approve → publish

   approved 탭으로 옮겨진 뒤 다시 publish. 전이는 api → packages/transitions. 이 시점에 소비자 API에서 바로 보인다.

5. 세 표면에서 확인

   ① 발행 API — publisher · source_url · ai_notice · source_notice · summary 필드 확인:

   curl -H "x-api-key: <published 키>" \
     "https://engine-api-425032198823.asia-northeast3.run.app/v1/published/<slug>"

   ② GCS 발행 스냅샷 — 워커의 다음 사이클(최대 30분)에 생긴다:

   gcloud storage ls gs://vertical-news-published/<article_id>/

   ③ 이미지 — 응답 images가 null이면 재호스팅 전이다. 다음 사이클에 배열로 채워진다.

6. unpublish → 위 curl이 404

   내린 기사는 존재를 증언하지 않는다(410 아님). 목록·단건·조회수 POST 전부 같은 판정.

7. requeue → in_review 재진입 → 재승인·재발행

   slug가 바뀌지 않는지 본다(URL 파괴 방지). 정정 요청이 딸린 건은 이 버튼이 아니라 정정 화면의 requeue-review로 처리한다.

A-3 · 나머지 내부 화면

B아이티데일리(파트너) E2E

계약 상대방이 자기 자격증명으로 들어와 자사 기사를 열람하고 삭제·정정을 접수하는 창구(AC ⑫). 스코프는 서버가 강제한다.

B-0 · 계정 발급 (내부 세션에서)

1. /review/accounts에서 이메일 입력 → 생성

   대상은 계약 당사자(주식회사 아이티엠지)가 지정한 담당자 1인. 임시 비밀번호는 화면에 1회만 렌더된다 — 새로고침하면 사라지니 바로 복사. 같은 이메일 중복 발급은 409.

2. 분리 전달

   이메일과 임시 비밀번호는 다른 채널로. 안내 문안은 docs/guide/partner-account-issuance.md §4 — 발송 전 계약 문면 확인.

   테스트라면

   아이티데일리 실담당자 계정으로 시연하지 말고 테스트용 이메일로 별도 계정을 만든다. 삭제·정정 요청 이력이 실데이터로 남고, 정정 접수는 발행본을 즉시 내린다.

B-1 · 로그인 · 강제 변경

1. /login → 이메일 + 임시 비밀번호

   잠금 정책: 계정 10회/15분 + IP 30회/15분. 정지된 계정과 없는 계정은 같은 401(계정 열거 방지).

2. 최초 로그인은 /my/password로 강제 이동

   변경 전까지 /my/* 전부 이 화면으로 튄다(가드 한 곳). 현재 비밀번호 + 새 비밀번호 → 세션 재발급 → /my/articles.

B-2 · 자사 기사 열람 (스코프)

/my/articles에는 itdaily 소스 기사만 보인다. 상세에서 출처 표기·고지 미리보기(검수자와 같은 조립). 타사 기사 id를 URL에 직접 넣으면 404 — 「없는 기사」와 구별되지 않는다.

B-3 · 삭제 요청 (takedown)

1. 상세 → 「삭제 요청」 폼(사유) → 접수

   접수 즉시 article_suppressions 행 + 매거진 발행본 unpublished. 동기 처리 — 「클릭 즉시」.

2. 양 API 미반환 확인

   # 수집 Pull API — 해당 URL 행이 사라진다
   curl -H "x-api-key: <구독자 키>" \
     "https://engine-api-425032198823.asia-northeast3.run.app/v1/articles?source=itdaily" | grep <url>
   
   # 발행 API — 404
   curl -H "x-api-key: <published 키>" \
     "https://engine-api-425032198823.asia-northeast3.run.app/v1/published/<slug>"

3. /my/requests 삭제 축 이력

   접수 시각 · 기사 · 사유 · 상태(접수됨 / 차단 완료 / 해제됨 — 상태는 차단 행에서 유도한다). 되돌림은 내부 /review/suppressions에서 release → requeue.

B-4 · 정정 요청 (correction)

1. 상세 → 「정정 요청」 폼(사유 필수) → 접수

   접수와 함께 발행본 즉시 unpublish + correction_requests 행(received). /my/requests 정정 축에 진행 표시.

2. 내부 세션 /review/corrections/{id}에서 진행

   • 재파싱 시작(advance → reprocessing)
   • 재파싱 자동 기동은 없다 — 운영이 backfill을 돌린 뒤 재검수 진입(requeue-review → in_review, 기사 전이와 원자적)
   • A-2 반복(재승인·재발행) → 반영 종결(resolved). 기각(rejected)도 가능

3. 파트너 화면 /my/requests에서 상태 변화 확인

B-5 · 세션 무효화

내부 /review/accounts에서 해당 계정 정지 → 파트너 세션은 다음 요청부터 401 → 쿠키 삭제 + /login. 해제하면 재로그인 가능(해시가 그대로라 세션 epoch도 그대로). 재발급하면 기존 세션은 영구 사망. 파트너 본인의 비밀번호 변경은 본인 세션만 살아남는다.

주의 · 미완 항목