설계서에서 "업로드와 다운로드가 따로 정의돼 어긋날 수 있다"고 적었던 그 결함이
실제로 나 있었다.

  다운로드  기존 증빙자료를 헤더 자리인 T열(19)에 쓴다
  업로드    U열(20)을 읽는다

기관 원본 파일은 헤더가 T인데 데이터가 U에 있어서(T에는 엑셀 화면용 '수정' 링크가
들어 있다) 파서가 U를 읽도록 돼 있었는데, 이 시스템이 만들어 주는 다운로드 파일은
T에 쓴다. 그래서 내려받아 고쳐서 다시 올리면 그 칸만 조용히 비워졌다.

파서가 U를 먼저 보고 비어 있으면 T를 보게 했다. 한쪽만 맞추면 다른 쪽이 깨지므로
둘 다 읽는다.

왕복 테스트를 먼저 만들어 결함을 재현한 뒤 고쳤다. 헤더 이름과 파서 컬럼이 같은
자리를 가리키는지도 24개 필드 전부 확인한다 - 앞으로 한쪽만 고치면 여기서 깨진다.

덤: PowerShell로 파일을 손보다 들어간 BOM 14건을 제거했다.

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

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

SQL 5곳(ProcessItemMapper 4 + DashboardMapper 1)과 자바 화이트리스트 1곳에 '처리완료'가
남아 있었다. 쿼리는 코드표를 참조할 방법이 없어 서비스가 값을 읽어 파라미터로 넘긴다.

처리상태 검증도 코드표를 따른다. 상태를 하나 더 만들어도 자바를 안 고쳐도 된다.

지정이 없을 때는 빈 문자열이 아니라 매칭되지 않는 값을 넘긴다. 빈 문자열을 주면
처리상태가 비어 있는 행이 전부 완료로 잡힌다.

파라미터화가 형식만 바뀐 게 아님을 확인하는 테스트를 넣었다. 코드표에서 done 속성을
'미처리' 쪽으로 옮기면 진행률과 상태 필터가 실제로 뒤집힌다 - 예전 구조에서는 코드표를
바꿔도 아무 일도 일어나지 않았다.

이로써 조사에서 세었던 13곳이 모두 정리됐다.

백엔드 266건 통과.

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)