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

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

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

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

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

백엔드 288건 통과.

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

검토본의 답변은 빨간 글씨 + 밑줄 체크로도 표시돼 있었는데, 처음 읽을 때 글자 색을
빼고 텍스트만 뽑아 10개 항목을 "무응답"으로 잘못 분류했다. 색까지 다시 읽어 확인한
결과 12번(이해 안 감)을 뺀 27개 항목에 모두 답이 있었다.

그중 손대야 하는 4개를 반영한다. 나머지 6개(1·3·9·13·14·24)는 "현행 유지"라
이미 맞는 상태다.

  [18] 자동 단계 전환 3종을 되살렸다.
       채널에 자료 업로드 → ②목록접수
       권리확인 자료 업로드 → ⑤법률검토(권리확인)
       권리처리 자료 업로드 → ⑧법률검토(권리처리)
       앞으로만 간다. 이미 그보다 앞서 있으면 아무 일도 하지 않는다 - 자료를 다시
       올렸다고 단계가 뒤로 밀리면 안 된다. 채널이 없어 단계가 아직 없는 기관도
       건드리지 않는다.
  [19] 되돌림을 허용하고, 이력에 자동/수동 구분과 계기를 남긴다.
  [22] 업무메모·연락이력·보고서 작성자가 로그인 아이디(admin)가 아니라 표시 이름으로
       찍힌다. 담당자별 계정이 생기면 CurrentUser 한 곳만 고치면 된다.
  [26] 자료실을 열었다. 기관에 딸리지 않는 공용 서식을 올려두고 내려받는다.

어느 자료가 어느 단계에 해당하는지는 자료의 지시를 이 시스템 흐름에 맞춰 옮긴 것이라
답변 문서에 적어 확인 요청해 둔다.

백엔드 281건, 프론트 209건 통과.

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

  [4][5] RE 메모  기관관리 RE 탭을 메모장처럼 만들었다. 메모 1개가 RE 1개다.
                  내용·작성자·일자에 완료 체크 한 칸을 더했고, 대시보드 '미해결 RE'가
                  이제 실제 숫자를 센다(예전에는 항상 0으로 고정돼 있었다).
                  완료 체크는 회신에 없던 항목이라 확인 요청해 둔 상태다.
  [6]     업무구간 필터를 뺐다. 현재 단계와 겹친다는 지적을 반영했고 순서도 현재 단계를
                  앞으로 옮겼다. 구간 구분 자체는 칸반 컬럼 색에 계속 쓰이므로 남겨 둔다.
  [8]     자료접수를 권리확인·권리처리 통합으로 바꿨다. 어느 쪽이든 한 건이라도 있으면 접수다.
  [15]    일괄 등록에 비고를 더했다. 권리확인·권리처리 양쪽 모두.
  [25]    보고서 교체 기능을 넣었다. 목록에 새 줄이 생기지 않고 그 자리만 바뀐다.
          개정판으로 남기고 싶으면 지금처럼 새로 올리면 된다.

RE 메모의 해결 여부를 뒤집으면 대시보드 숫자가 실제로 따라 움직이는지까지 테스트한다.

백엔드 275건, 프론트 208건 통과.

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) 

코드값을 소스가 아니라 데이터로 관리하기 위한 기반. 저장값은 지금 업무 테이블에
들어 있는 한글 문자열을 그대로 쓴다 - 영문 키로 바꾸면 기존 데이터 변환과 엑셀
양식 수정이 딸려와 위험 대비 실익이 없다.

설계서와 Phase 1 구현계획도 함께 넣는다.

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

서버에서 itnhub.env를 Windows에서 만들어 올리면 source 할 때 줄 끝 캐리지 리턴이
값에 그대로 붙는다. DB 비밀번호나 SERVER_PORT가 조용히 틀어지고 빈 줄에서는
command not found 가 뜬다. 캐리지 리턴을 걷어낸 사본을 만들어 읽도록 바꾼다.
원본 파일은 그대로 둔다.

alpine에서 bash -n, shellcheck, CRLF env 주입까지 확인했다.

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