편집 완료와 전문가 검토 완료를 같은 말로 쓰지 않기

처음 만든 상태를 최종 상태로 오해하지 않는다

초기 빌더만 보면 짧은 요약이 많은 구조로 읽을 수 있다. 하지만 이 프로젝트는 보강 스크립트가 뒤에서 실행되며 최종적으로 구조화된 글 20개와 초기 요약 40개를 구분한다. 나는 중간 파일과 최종 생성 순서를 함께 확인해 실제 작업을 초안 상태로만 설명하지 않도록 했다.

이 숫자는 소스에서 확인한 편집 구성이지 지금 사이트를 새로 크롤링한 결과가 아니다. 원래 프로그램을 실행하거나 콘텐츠를 바꾸지도 않았다. 제작 기록을 글 재료로 쓸 때도 언제의 파일이 어떤 단계를 나타내는지 구별해야 한다. 과거 보고 한 줄을 현재 검수 결과로 바꾸지 않는 기준이다.

편집 깊이는 검토 자격과 다르다

구조화는 문장의 부분과 설명을 더 갖췄다는 뜻이다. 전문가가 내용의 적절성을 확인했다는 뜻까지 포함하지 않는다. 최종 소스의 전문가 검토 상태는 수행되지 않음으로 남는다. 구조화된 글과 검토된 글을 같은 배지로 보여 주면 방문자는 어느 책임이 끝났는지 알기 어렵다.

새 review_state는 depth, source_check와 expert_review를 별도 값으로 받는다. initial과 structured, 출처 확인 기록 유무, 전문가 검토 수행 여부가 서로 다른 축이다. 한 축이 좋아졌다고 다른 축을 자동으로 올리지 않는다. 작은 함수지만 콘텐츠 운영에서 말하는 완료를 더 정확하게 만들 수 있다.

검토 근거가 없는 완료는 거절한다

expert_review를 recorded로 보내려면 근거 참조가 있어야 한다. 반대로 not_performed인데 근거를 붙이면 상태가 모순되므로 거절한다. 이 검사는 검토자가 실제 자격을 가진 사람인지 인증하지 않는다. 근거 참조의 존재와 그 참조가 타당한지는 또 다른 확인이다.

어떤 조합에서도 publication_authorized는 false다. 콘텐츠 상태 데이터가 실제 관리자 권한을 부여하지 않도록 범위를 명시한 것이다. 원래 사이트의 로그인 정책을 이 예제로 복제하지 않았다. 필요하다면 기존 역할별 권한 모듈과 별도 통합해야 하며 상태 배지로 접근 통제를 대신해서는 안 된다.

운영자가 바꿀 때 무엇을 남길까

초기 요약을 구조화된 글로 바꾸면 편집 깊이만 먼저 바뀔 수 있다. 원본을 다시 확인했을 때는 출처 기록도 갱신할 수 있다. 전문가 검토가 별도로 수행되면 그때 근거를 연결한다. 세 사건을 한 저장 버튼에 묶어도 의미는 따로 보관해야 한다. 단순한 최신 수정일 하나로 모두 설명하지 않았다.

현재 합성 함수에는 실제 변경 이력과 영속 저장이 없다. 여러 사람이 바꾸는 운영에서는 누가 어떤 근거로 바꿨는지 별도 이력 구조가 필요하다. 기존 원자 처리·권한·인계 모듈의 책임을 이 상태 함수가 이미 구현했다고 말하지 않는다. 작은 계약은 연결할 책임을 드러내는 데 유용하다.

공개 상태를 솔직하게 설명하는 홈페이지

근거 표현 패키지의 12개 테스트에는 근거 누락과 모순 상태, 발행 권한이 생기지 않는 검사가 있다. 실제 기사에 전문가 검토를 수행한 것은 아니며 소스에 없는 완료 사건을 만들지 않았다. 실행 뷰어는 새 합성 상태의 실제 로컬 결과만 보여 준다. 고객 사이트의 콘텐츠 목록과 이름도 공개하지 않는다.

나는 방문자가 모든 글을 같은 무게로 받아들이게 하기보다 어떤 작업을 거친 글인지 판단할 재료를 주고 싶었다. 수준 높은 정보를 공개하려면 분량뿐 아니라 아직 안 한 검토도 정확하게 설명해야 한다. 이 상태 모델은 제작자의 판단을 드러내면서 다음 작업자가 어디부터 이어야 하는지도 보여 주는 작은 도구다.

발행 가능 여부는 다시 판단한다

편집 상태를 공개하는 것은 발행 결정을 기계적으로 대신하려는 목적이 아니다. 어떤 분야에서 어떤 검토가 필요한지는 자료와 주장에 따라 달라진다. 현재 함수는 일관된 상태 설명만 제공한다. 실제 발행 기준은 담당자가 정하고 그 기준에 맞는 근거와 권한을 확인해야 한다. 표지의 자동화가 책임의 자동 승인이 되지 않게 만든 것이다.