admin_account.agent_id 매핑 — 블랙리스트 승인·해제가 운영에서 409 다

무엇을

운영 admin_account 행의 agent_id 가 NULL 이라 블랙리스트 승인 · 해제 · 만료 변경이 전부 409 다 (decisions/304 — 처리자를 상담원 ID 로 남기는 설계). 이것을 푼다.

왜 지금

09-15 에 관리자 로그인이 운영에서 성공한 뒤로 계속 이 상태다. 선택지 셋이 로그에 적혀 있고 아직 고르지 않았다. 시연에서 J 블록(전환 요청 → 관리자 승인)을 보이려면 여기서 막힌다.

같이 볼 것

decisions/406 으로 상담원을 이름으로 만드는 경로가 생겼다(09-21). 관리자에게 agent 행을 붙이는 방법이 그 경로와 겹치는지 먼저 본다 — 두 벌을 만들지 않는다.

완료 조건

• 방식을 고르고 결정 기록(3xx)으로 남긴다
• 운영에서 승인 1건 · 해제 1건이 200 이고 blacklist_entry 에 처리자가 남는다
• 매핑이 없는 관리자가 눌렀을 때의 메시지가 「409」가 아니라 무엇을 해야 하는지를 말한다

2026-09-22 장민석 — 방식을 정하고 코드를 넣었다(_project/decisions/314, 운영 배포 전). 선택지 ①(사용자 선택): 처음 결정할 때 그 관리자 전용 agent 행(admin-<id>, role='admin')을 만들고 admin_account.agent_id 가 비어 있을 때만 채운다. 그래서 「매핑이 없는 관리자」가 더는 생기지 않는다(409 메시지 조건은 대상이 사라졌다). 406 경로는 이름으로도 찾아 동명 상담원을 빌릴 수 있어 쓰지 않았다. 테스트: 유닛(라우터·인터랙터) + 실제 PostgreSQL integration. 남은 완료 조건: 운영에서 승인 1건·해제 1건 200 확인 — 배포 뒤.

2026-09-22 장민석 — 운영 확인은 정성윤 님께 넘긴다. 서버 코드(314)는 0.1.25 로 운영에 나갔다. 남은 완료 조건 「운영에서 승인 1건·해제 1건 200 · 처리자가 남는다」는 운영 관리자 계정으로 해야 하는 운영 확인이라 관리자 계정을 가진 정성윤 님 몫이다 (내 계정은 운영 admin_account 에 있는지 확인되지 않았다). 반려는 프론트 수정 전이라 422 — 확인은 승인 1건 · 해제 1건으로 한다. 확인되면 이 티켓을 done 으로 옮겨 주시면 된다(담당은 코드를 쓴 장민석 그대로).

2026-09-22 — 체크 정리 (장민석)

• 첫째 조건은 decisions/314 가 했다. 셋째 조건은 409 자체가 없어졌다 — 처음 결정할 때 admin-<id> 행을 자동으로 붙인다(admin_agent_link_interactor.py). 매핑이 없는 관리자가 누를 일이 없다
• 남은 것은 둘째(운영에서 승인 1건 · 해제 1건 200 · 처리자 기록) 하나 — 정성윤 님 확인 대기

2026-09-28 — 운영 확인 끝, 닫는다 (정성윤)

남아 있던 둘째 조건(운영에서 승인 1건·해제 1건 200 · 처리자 기록)은 2026-09-22 수동 QA Q-62 에서 이미 확인됐다 — test-qa-08 반려(사유 「반려」) · test-qa-09 승인, 409 없이 처리됐고 decided_by 에 처리자가 남았다 (진행 기록 2026-09-22-18-seongyun). 확인이 QA 기록에만 있어 티켓이 열린 채였다. 코드는 장민석, 확인은 정성윤.