이전 메시지 불러오는 중…
박보검의 요청:
형사 144종 적재는 잘 됐는데, 0053 INSERT에서 sort_order를 안 넣어 144행이 전부 sort_order=NULL이다. 그 결과 서류편집·수요순위·사이드바 목록에서 형사가 정렬상 맨 위로 몰려 어색하게 뜬다(손석구 진단 확인). 보정 부탁:
1) 형사 144행에 sort_order를 채우는 보정 마이그레이션(0054 등) 작성·라이브 적용·커밋. 부여 규칙: tab='형사' 안에서 proc(형사공판→형사신청→형사약식→영장/즉결) → feature_group → 내가 넘긴 입력순서대로 1씩 증가. 기존 민사/민사집행 sort_order 체계와 일관되게(겹쳐도 tab/proc로 그룹핑되니 무방, 다만 형사 내부 순서가 자연스럽게).
2) 적용 후 라이브에서 tab='형사' 정렬이 proc→feature_group→입력순으로 나오는지, sort_order NULL 행이 0인지 확인.
3) 마이그레이션 번호·커밋 해시.
참고: 손석구 라이브 점검상 서버오류(500)는 없었고 이건 표시 정렬 결함만이다. 또 향후 분야 적재 시 sort_order 필수 포함을 워크플로에 반영해줘.
완료. 결과 보고.
형사 144행 sort_order 보정 — 완료
| 항목 | 값 |
|---|---|
| 마이그레이션 | 0054_legal_doc_catalog_criminal_sortorder.sql |
| 라이브 적용 | lax-db(원격) 적용 완료 — 144행 갱신 |
| LAX-site 커밋 | 5847ae6 |
| brain 커밋 | a737b0c (분류축 위키 + log.md) |
부여 결과 (proc→feature_group→입력순, 1씩 증가)
| proc | sort_order |
|---|---|
| 형사공판 | 1–84 |
| 형사신청 | 85–126 |
| 형사약식 | 127–136 |
| 영장/즉결 | 137–144 |
라이브 검증: 형사 내 NULL 0건·0 잔존 0건. 앱 정렬(ORDER BY tab, sort_order, id)로 형사공판 선두가 0053 입력순과 정확히 일치(주장서면 7 → 보정/송달 2 → 증거신청…).
진단과 다른 점 — 정직하게 보고
- NULL이 아니라 0이었다.
sort_order컬럼은NOT NULL DEFAULT 0(mig 0044)이라, 0053이 컬럼을 생략하자 144행이 NULL이 아닌 0으로 적재됐다. 손석구의 "NULL"은 "미부여" 취지로는 정확하나 저장값은 0. - 민사·민사집행도 전부 sort_order=0. 0044 재적재(DROP/CREATE) 때 민사도 sort_order를 안 넣었고 0045도 마찬가지. 즉 "기존 민사 sort_order 체계"는 라이브에 실재하지 않으며, 모든 탭이 id 폴백으로만 정렬돼 왔다.
- 모든 소비 쿼리(doc_nav·onboarding·settings·reports)가 tab을 1차 정렬키로 둔다. 따라서 0 동률 상태에서도 형사는 탭키상 맨 위가 아니라 끝(민사<민사집행<형사)에 위치했고, 형사 내부 순서는 id 폴백으로 이미 우연히 맞아떨어지던 상태였다. 이번 보정은 그 우연 의존을 제거하고 표시순을 명시값으로 고정한 것 — 안정화 효과는 분명하나, 보고된 "맨 위로 몰림"이 데이터상으로는 재현되지 않았음을 밝혀둔다.
참고: 민사·민사집행 sort_order도 0이라 표시순 명시화를 원하면 별도 보정 대상입니다. 이번엔 요청 범위(형사)만 손댔습니다.
워크플로 반영
company/wiki/법률문서-분류축.md에 "적재 규칙(필수)" 섹션을 신설 — 신규 분야(탭) 적재 INSERT에 sort_order 필수 부여(tab 내 proc→feature_group→입력순 1씩 증가), 누락 시 0 적재로 표시순이 id 폴백에 의존함을 명문화. 형사 탭/proc도 분류축에 추가했습니다.