핵심까지 다 확인됐습니다. 결론부터 보고합니다.

진단 결과: 라이브 서버 에러(500)·렌더 크래시 없음

dev 계정 기준 실제 HTTP로 전부 때려봤고, 모두 정상 응답입니다.

500은 한 건도 안 나왔습니다. wrangler tail은 요청-시점 캡처라 사후 로그가 없어, 500 여부는 라이브 HTTP 응답코드로 직접 판정했습니다(이게 500에 대해선 결정적). 추측 아닌 실측입니다.

질문별 답

2) 형사 144 렌더 중 예외? 없음. 144행 전부 200으로 렌더. id 716("변호인 선임계")까지 정상 — 카탈로그 max id가 715보다 큰 건 과거 삭제로 생긴 id 갭일 뿐(행 수 715 ≠ max id).

3) 0053이 sort_order/feature_group 누락으로 렌더를 깨뜨리나? 깨뜨리지 않음. 근거:

• 0053 INSERT는 sort_order를 안 넣어 144행 모두 sort_order=NULL. 하지만 SQLite ORDER BY에서 NULL은 에러가 아니라 맨 앞 정렬일 뿐 → 크래시 없음.
• 단, 부작용: doc-demand·사이드바에서 형사 144행이 형사 탭 그룹 상단에 몰려 보임(NULL이 먼저 정렬). 시각적 어색함이지 오류는 아님.
• feature_group은 144행 전부 채워져 있음(빈 값 없음). 빈 feature_group 행 없음.

4) 라이브 빌드가 최신인가? 최신 맞음. /settings/docs에 직전 코드커밋 2a1b09e의 필터 라벨("현재 메뉴"/"메뉴 없음")이 라이브에 그대로 떠 있음. 카탈로그도 715종으로 0053(5398e4e) 반영됨. 코드-데이터 불일치 없음.

콕 집은 의심점 (오류는 아니지만 "깨졌다"는 인상의 원인일 가능성)

in_scope='out' 144행이 /reports/doc-demand와 /settings/docs를 도배함.

• 두 페이지의 필터는 WHERE in_scope != 'excluded'. 형사 144행은 'excluded'가 아니라 'out'이라 전부 노출 → 수요순위 표가 571 → 715행, "형사" 147회 등장.
• 다만 in_scope 관례상 **'out'은 기존 지배값(670건)**이라 원래도 'out' 행은 늘 노출돼 왔음. 즉 형사 전용 신규 버그가 아니고, 기존 설계(비-excluded 전부 노출)에 144행이 더해진 것.
• 변호사가 수요순위 페이지를 열면 구상금과 무관한 형사 144종이 표를 채워 "페이지가 이상하다/깨졌다"고 인지했을 수 있음. 이게 가장 유력한 제보 원인.

권고 (수정은 의사결정 필요라 미실행)

형사 144종을 구상금 워크스페이스의 수요순위·서류편집기에서 숨기려는 의도였다면, 두 갈래:

• (A) 0053 데이터를 in_scope='out' → 'excluded'로 변경(데이터 마이그레이션, revert는 역마이그레이션), 또는
• (B) 두 쿼리 필터를 in_scope NOT IN ('excluded','out') 또는 in_scope = 'core' 계열로 변경(코드 변경).

단 (B)는 기존 670개 'out' 시민/구상금 문서까지 같이 사라지므로 의도 확인 없이는 못 건드립니다. 어느 쪽이 맞는 정책인지가 Jason/리아의 결정 사항이라 여기서 임의 변경하지 않았습니다.

한 줄 결론: 라이브는 안 깨졌습니다(전 페이지 200/302, 500 없음, 최신 빌드). "오류"의 정체는 형사 144종이 수요순위·서류편집 목록에 끼어든 데이터 노출 범위 문제일 가능성이 높고, 이는 in_scope='out' 관례와 != 'excluded' 필터의 의미 불일치에서 옵니다. 어느 정책이 맞는지 확정해주시면 (A)/(B) 중 하나를 롤백 가능한 형태로 반영하겠습니다.