[18] 목록접수 조건이 자료에 적힌 것과 달랐다.
     자료  : 「목록접수 = Mattermost에 첫 자료 업로드 + 핀 고정 시」
     구현  : 파일이 올라가기만 하면 넘어감 (핀 고정 조건 누락)

공지 고정이 끝난 뒤에 판단하도록 옮겼다. 자료만 올리고 고정하지 않은 경우, 자료 없이
공지만 올린 경우, 고정에 실패한 경우 모두 넘어가지 않는다. 다섯 갈래를 테스트로 잠갔다.

[통일] 공공누리 유형 표기를 「N유형」으로 맞춘다.
     조사표에 「제4유형」으로 적혀 온 자료가 68건 있었는데 나머지는 모두 「0~4유형」
     형태였다. 같은 유형인데 유형별 집계에서 따로 잡히던 문제다.

세 곳을 함께 손봤다.
  · 기존 데이터를 정규식으로 일괄 변환(V18). 뜻이 다른 「유형 확인 필요」는 건드리지 않는다
  · 「제4유형」을 선택지에서 제외
  · 업로드 시점에도 옛 표기를 표준 표기로 바꿔 넣는다 - 이게 없으면 기관이 예전 파일을
    다시 올릴 때 되살아난다

「제4유형」 코드 행은 지우지 않고 비활성 별칭으로 남긴다. 업로드 변환이 이 행의 sameAs를
보고 동작하기 때문이다. 코드표가 별칭까지 관리하는 셈이라 앞으로 다른 표기가 발견돼도
데이터 한 줄로 흡수할 수 있다.

백엔드 288건 통과.

Co-Authored-By: Claude Opus 5 (1M context) 

시드를 쓸 때 화면 소스를 안 보고 의미만으로 색을 골랐던 탓에 두 가지가 어긋나 있었다.
Phase 2에서 화면이 코드테이블을 보게 되면 조용히 바뀔 값들이다.

  업무구간 색   assign violet->indigo, check sky->emerald, closing emerald->violet
  담당자 구분   MJ 표시명 주관기관->문정원 (주관기관은 엑셀 표기라 importAlias로)
                뱃지색 5개 전부 화면 기준으로 교정

이미 적용된 V13을 고치면 체크섬이 어긋나 기동이 실패하므로 V15로 앞으로 나아가며 고친다.
어긋남이 다시 생기지 않도록 화면 기준값을 테스트로 잠갔다.

STAGE_GROUP의 cardBody 속성은 뺐다. 칸반 카드 본문은 구간이 아니라 단계 번호로 갈리는
자리가 있어(1단계는 신청일, 2·3단계는 목록 건수) 화면 로직으로 두는 편이 정확하다.

Co-Authored-By: Claude Opus 5 (1M context) 

배포 전 정합성 점검을 실제 DB에 돌려보니 코드테이블에 없는 값이 1,926건 있었다.
  review_item.kogl_type = 유형 확인 필요  1,858건
  review_item.kogl_type = 제4유형            68건

둘 다 기관 조사표에서 온 값이라 prior(기존 부착 유형) 자리에만 넣고, 변호사가 고르는
판정값(review/process)에는 넣지 않는다. surveyOnly 속성으로 구분하고 그 구분이 새는지를
테스트로 막는다.

등록하지 않았다면 Phase 2에서 이 1,926건이 상세 화면에 선택 안 됨으로 보였을 것이다.

Co-Authored-By: Claude Opus 5 (1M context) 

진행단계는 요구사항 [7][11]대로 13단계로 넣고, 진행상태(신청/진행중/완료)와
KPI 임계값을 attrs로 데이터화했다. 요구사항 [2](보고서가 올라와야 최종완료)는
completed 임계값을 13번에 두는 것으로 해결된다.

공공누리 유형은 scopes로 사용처(review/process/prior)를 구분한다. 세 화면의
목록이 7/5/6개로 달랐던 것이 실수가 아니라 자리 차이였기 때문이고, 이 구분 없이
합치면 권리처리 화면에 보류가 잘못 노출된다.

Co-Authored-By: Claude Opus 5 (1M context)