시드를 쓸 때 화면 소스를 안 보고 의미만으로 색을 골랐던 탓에 두 가지가 어긋나 있었다.
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)