이미지, 영상, 음악, 음성, 텍스트를 생성할 수 있는 제품이라면 그중 무엇이든 신고할 수 있어야 합니다. 대부분이 아니라 무엇이든.
버튼은 일부 화면에 있었습니다. 그건 다른 이야기이고, 그 차이는 놓치기 쉽습니다. 콘텐츠 검사가 파이프라인마다 손으로 연결돼 있었기 때문에 스튜디오 두 곳은 검사 없이 출시됐고, 감사가 들여다볼 때까지 아무도 몰랐습니다. 같은 모양이라면 이 수정도 잊힌 화면 하나씩 갉아먹었을 것입니다.
모든 화면, 그리고 그것을 보증하는 검사
이제 신고 버튼이 대화 답변, 이미지, 영상, 음악, 음성, 음성 인식, 읽어주기, 번역, 캔버스 결과물, 워크플로 결과, 어시스턴트 말풍선, 공개 공유 페이지에 있습니다. 웹과 앱 모두에서요.
더 중요한 것은 빌드마다 검사가 도는 점입니다. 생성 인터페이스를 가져오는 파일은 신고 버튼을 그리거나, 그것을 지닌 구성 요소에 넘기거나, 읽는 사람이 확인할 수 있는 사유가 붙은 예외를 지녀야 합니다. 첫 실행에서 진짜 빈틈 여섯 개를 보고했습니다. 이 작업이 닫은 것이 바로 그 여섯입니다.
그다음 운영자가 실행 중인 앱을 열어 검사가 볼 수 없던 다섯 개를 더 찾았습니다. 검사가 한 번도 열지 않는 폴더에 있었기 때문입니다. 이것이 문제의 더 나쁜 절반입니다 — 한 번도 읽지 않은 코드를 지나치면서 0을 보고하는 감시자 — 그래서 검사는 이제 자신의 탐색 범위를 명시하고, 그중 하나가 더는 해석되지 않으면 실패합니다.
하나의 대기열, 그리고 줄 위에서의 처리
공유 페이지에는 한동안 신고 버튼이 있었지만 아무도 읽지 않는 테이블에 쓰고 있었습니다. 소비자도, 대기열 항목도, 알림도 없었죠. 그 신고는 이제 실제 사건도 열고, 검토자가 필요한 본문을 그대로 얼려 곁에 둡니다.
그리고 처리가 다른 페이지에 있는 대기열은 결국 아무도 다루지 않는 대기열이 됩니다. 콘텐츠 숨기기나 신고 종료는 이제 그 줄에서 이뤄지고, 결과가 되돌아 기록되어 같은 일을 다시 논의할 필요가 없습니다.