두 가지 답하고 바로 반영한다.

이해상충(利害相衝, conflict of interest)이란 — 변호사가 한쪽을 대리하면서 그 상대방도 (현재·과거) 자기 의뢰인인 상황. 예: A를 대리해 B를 상대로 소송하는데 B도 우리 의뢰인이면, 양쪽을 동시에 편드는 셈이라 변호사법상 수임이 제한된다. 그래서 새 사건을 맡기 전, 상대방이 우리 의뢰인 명부에 있는지 검색하는 게 "이해상충 점검"이다. 변호사 필수 윤리 절차라 넣었다.

DB는 합치면 안 되지만 화면은 합치는 게 맞다. 데이터는 의뢰인·사건·상대방·기일이 따로 있어야 한다(의뢰인 1명이 사건 수백 건인 구조라 한 테이블로 뭉치면 무너짐 — 변우석이 짚은 핵심). 다만 메뉴/화면이 3개로 쪼개진 건 불편이 맞다. → 메뉴는 "고객관리" 하나로 합치고, 그 안에서 탭으로 의뢰인·사건·이해상충을 오가게 바꾼다.

먼저 메뉴를 단일화:

이제 세 페이지에 공통 탭바를 넣어 한 화면처럼 이동하게 한다. clients부터:

사건·이해상충 페이지에도 같은 탭바를 넣고 제목을 "고객관리"로 통일한다:

Typecheck, build, deploy:

배포 완료. 메뉴 단일화·탭바를 검증한다:

탭바 통합·active 정확(의뢰인/사건/이해상충), 메뉴 단일화 완료. 사이드바 "고객관리" 링크와 active 동작만 확인한다:

완료. 검증 통과 — /matters·/conflicts에서도 사이드바 "고객관리"가 active(단일 메뉴가 세 화면 모두 커버), 페이지 안에서는 탭으로 이동.

정리 — 고객관리 단일 탭으로 통합

배포(프로덕션): https://bae816d3.lax-dtb.pages.dev/clients

요약하면 — 보는 곳은 "고객관리" 하나, 그 안에서 탭으로 의뢰인↔사건↔이해상충. 데이터 구조는 변호사 실무(의뢰인 1명=사건 N건)에 맞게 뒤에서 분리돼 있고, 사용자한테는 한 탭으로 보인다.

다음 액션:

• [Jason] 브라우저에서 탭 전환·동선 확인. 탭 순서나 명칭 바꾸고 싶으면 알려주세요.
• [박보검][확장] 다음은 사건 ↔ 소장 자동작성 연결 — "이 사건의 구상금 소장"으로 CRM·기능 트리 통합.

데모 데이터를 푸짐하게 — 구상금/보증 실무에 맞는 의뢰인·사건·상대방·기일을 넣겠다(이해상충 사례도 1건 심어둠). id 예측을 위해 시퀀스를 리셋하고 일괄 INSERT한다.

적재 완료 — 의뢰인 12 · 사건 24 · 상대방 31 · 기일 16. 라이브 화면에 제대로 뜨는지, 임박기일·이해상충까지 검증한다.

완료. 데모 데이터가 화면 전반에 정상 표출된다.

데모 데이터 적재 완료

검증된 동작:

• 의뢰인 탭: 의뢰인별 "사건 4건/3건…" 링크 연결 ✓
• 사건 탭: 임박·경과 기일 알림(D+7 경과·D-1·D-3…), 상태칩 7종, 청구금액 ✓
• 이해상충 데모: 사건 #3 "김정훈에 대한 구상금"의 상대방 김정훈이 의뢰인 명부에도 있어 상세에 ⚠️ 이해상충 주의 배너 표출 ✓

확인 위치: https://bae816d3.lax-dtb.pages.dev/clients (탭으로 의뢰인↔사건↔이해상충)

참고: 데모 레코드는 전부 created_by='demo'로 표시해 둬서, 나중에 실데이터와 섞이면 DELETE FROM ... WHERE created_by='demo'로 한 번에 정리 가능하다.

다음 액션:

• [Jason] 브라우저에서 둘러보고, 데이터 양·구성 더 늘리거나 줄일지 알려주세요.
• [박보검] 실고객 온보딩 시 데모 데이터 정리 후 전환.

두 가지 처리한다. 먼저 계획 탭 제거(간단)와 테이블 스타일 클래스 존재 여부를 확인한다.

기존 테이블 패턴을 한 곳에서 확인해 스타일을 맞춘다.

CRM 페이지는 wc 디자인 시스템(브라운 톤)이라 Tailwind slate 테이블과 안 맞다 — wc 토큰 테이블 스타일을 공통 셸에 추가하고 의뢰인·사건 목록을 표로 바꾼다.

먼저 공통 테이블 스타일:

의뢰인 목록을 표로 교체하기 위해 현재 코드를 확인한다.

Now replace the 의뢰인 card list with a table:

사건 목록도 표로 바꾼다. 현재 코드를 확인한다.

(Grep 출력의 \는 표시 아티팩트이고 실제 파일은 /다.) 사건 목록을 표로 교체한다.

타입체크·빌드·배포:

표 헤더·계획 제거는 확인됐다. 행 onclick grep이 0인 건 패턴(특수문자) 탓일 수 있어 단순 패턴으로 행 렌더를 재확인한다.

완료. 검증 통과.

완료 — 표 형태 CRM + 계획 탭 제거

검증: 의뢰인 표 13행(헤더+12)·사건 표 25행(헤더+24)·청구금액 콤마(8,500,000원)·계획 탭 0건·보고서 유지 모두 확인.

확인 위치: https://7005f573.lax-dtb.pages.dev/clients

다음 액션:

• [Jason] 표 컬럼 구성(추가/제외)·정렬·검색 필요하면 알려주세요 — 정렬 헤더나 상단 검색창은 바로 얹을 수 있음.
• [박보검] 다음 후보: 표 컬럼 정렬·페이지네이션, 또는 사건↔소장 자동작성 연결.

좋은 지적이다. 이해상충은 별도 탭이 과하다 — 동의한다. 본질은 "이 이름이 의뢰인이면서 동시에 상대방인가"를 보는 건데, 그건 이름 검색으로 충분하다. 게다가 진짜 안전망은 사건 등록/상세의 자동 경고 배너(상대방이 의뢰인명과 겹치면 자동으로 ⚠️)라 별도 탭 없이도 실수는 막힌다.

→ 이해상충 탭 제거하고, 그 검색 기능을 의뢰인 탭의 검색창으로 흡수한다. 검색하면 의뢰인이 필터되고, 그 이름이 상대방에도 있으면 그 자리에서 충돌 경고가 뜬다.

먼저 의뢰인 탭에 검색+충돌경고 로직 추가:

검색창과 충돌 경고 UI를 탭 아래에 추가:

이해상충 탭을 두 곳의 탭 목록에서 제거하고, /conflicts는 검색으로 리다이렉트시킨다:

타입체크·빌드·배포:

완료. 검증 통과.

정리 — 이해상충 탭 제거, 검색에 통합

검증: 탭 2개·검색창·301 리다이렉트 확인. 김정훈(의뢰인이자 사건#3 상대방) 검색 시 이해상충 주의 배너 + 의뢰인 행 정상 표출.

확인 위치: https://f731373c.lax-dtb.pages.dev/clients

정리하면 — Jason 말대로 별도 탭 없이 이름 검색 하나로 이해상충을 확인하고, 진짜 실수 방지는 사건 화면 자동 경고가 맡는다. 더 단순해졌다.

다음 액션:

• [Jason] 검색을 사건 탭에도 둘지(사건명·상대방 검색), 아니면 의뢰인 탭만으로 충분한지 알려주세요.
• [박보검] 다음 후보: 사건↔소장 자동작성 연결.

좋은 방향이다. 몇 가지 판단부터:

진행단계는 사건(matter) 단위에 둔다. 네 말대로 "한 의뢰인이 여러 사건"이고 "의뢰인+사건명이 한 세트"니까, 단계는 그 세트(=사건)마다 따로 가야 정확하다(의뢰인에 단일 단계를 두면 사건 2개일 때 무너짐).

단계 MECE 검토 — 네 7단계는 대기/완료 쌍이 일관적이고 순차 배타라 좋다. 그대로 채택하되, 한 가지만 명확히: 7. 종결이 정상종결·무산(상담 후 미계약)·거절을 모두 흡수하도록 정의(별도 "무산" 칩을 만들면 표가 지저분해짐). 나머지는 손 안 댄다.

이제 반영한다. 사건의 상태값을 7단계로 교체하고, 표에 No.·진행단계·"의뢰인·사건명" 세트를 넣는다.

먼저 사건 단계 상수·칩·기본값:

Now restructure the 사건 table — No. + 진행단계 + 의뢰인·사건명 세트:

의뢰인 표에 No. 컬럼 추가:

데모 사건의 단계를 7단계로 재배정하고, 타입체크·빌드·배포를 진행한다:

완료. 검증 통과.

완료 — 진행단계 + 표 번호 + 의뢰인·사건 세트

데모 24건도 7단계로 골고루 재배정. 등록폼·상세·필터칩 전부 7단계로 자동 반영(상수 한 곳에서 관리).

확인 위치: https://8d170343.lax-dtb.pages.dev/matters

다음 액션:

• [Jason] 단계 명칭·색, 칸반(단계별 보기) 필요 여부 알려주세요.
• [박보검] 다음 후보: 단계별 필터/칸반 뷰, 또는 사건↔소장 자동작성 연결.

세 가지를 반영한다 — ① 컬럼 너비를 내용에 맞게 ② 의뢰인 클릭 시 의뢰인 상세 페이지 ③ 의뢰인 표에도 진행단계 표시.

먼저 단계 칩을 공유 모듈로 빼서 의뢰인 표에서도 쓰게 한다(단계 정의 한 곳 관리):

matters에서 단계 정의를 공유 모듈로 교체:

사건 표 컬럼 너비를 내용에 맞게 지정한다:

이제 의뢰인 쪽 — 단계 칩 import, latest_stage(최근 사건 단계) 조회, 타입 추가:

Now the 의뢰인 table — add 진행단계 column, set widths, link rows to detail page:

의뢰인 상세 페이지를 만든다. 먼저 금액 포맷 헬퍼 추가:

타입체크·빌드·배포:

행 onclick의 작은따옴표가 HTML 이스케이프되어 grep만 빗나갔다 — 단순 패턴으로 행 링크와 사건 표 너비를 마저 확인한다.

완료. 검증 통과 — 의뢰인 행 클릭 → /clients/1 상세, 사건 행 → /matters/13, 너비 적용 모두 확인.

완료 — 컬럼 너비 · 의뢰인 상세 · 진행단계 표시

확인 위치: https://247bfa1c.lax-dtb.pages.dev/clients

• 의뢰인 행 클릭 → 그 의뢰인 페이지(사건들·진행단계 한눈에)
• 사건 행 클릭 → 사건 상세

참고: 의뢰인 표의 진행단계는 여러 사건 중 최근 사건 기준이다(한 의뢰인이 여러 사건이라). 사건별 단계 전체는 의뢰인 상세나 사건 탭에서 본다.

다음 액션:

• [Jason] 의뢰인 표 단계 기준을 "최근 사건" 말고 다른 기준(진행 중 사건 등) 원하면 알려주세요.
• [박보검] 다음 후보: 단계별 칸반 뷰, 또는 사건↔소장 자동작성 연결.

네 가지 다 반영한다 — ① 헤더 가독성+금색 ② 모든 표 필터 ③ 페이지네이션 ④ 최신 업데이트순 정렬. 정렬을 위해 updated_at이 필요해 컬럼부터 추가한다.

먼저 마이그레이션 + 공통 스타일/컴포넌트:

Now header gold styling + pager CSS in shell:

이제 matters 라우트 — import, touch 헬퍼, 목록(필터·페이지·최신순), 변경 시 갱신. 먼저 import와 헬퍼:

Now the 사건 list query — filters, count, latest-first, pagination:

상태 칩을 드롭다운 필터바로 교체:

사건 표 아래에 페이지네이션 추가:

이제 변경 시 updated_at 갱신 — 등록·상태·상대방·기일 라우트에 touch 추가:

상대방 삭제·기일 토글에도 touch 추가:

이제 의뢰인 쪽 — import, 필터·페이지·최신순 쿼리:

검색폼을 검색+필터 바로 통합:

Add pager after the 의뢰인 table, and updated_at to insert + detail ordering:

마이그레이션 적용·타입체크·빌드·배포:

요청 처리 전에 탭 통합 질문에 내 의견부터 — 결정에 영향이 크니 짚고 간다.

내 의견: 사건 탭은 남기는 걸 추천한다. 다만 네가 제안한 "의뢰인 클릭 시 사건수 분기"는 매우 좋아서 바로 채택한다.

이유:

• 사건 횡단 뷰가 변호사 핵심 워크플로우다. "이번 주 기일 임박한 모든 사건", "착수 단계 사건 전체"를 한 표에서 필터·정렬하려면 의뢰인을 안 거치고 보는 사건 탭이 필요하다. 의뢰인 탭만 있으면 의뢰인을 하나씩 들어가야 해서 이게 안 된다.
• 구상금 맥락에선 더 그렇다. 의뢰인(재단)은 몇 곳인데 사건은 수백 건 → 무게중심이 사건이다. 재단 클릭 후에야 사건에 닿으면 비효율.
• 즉 의뢰인 탭 = 고객 명부 / 사건 탭 = 전체 사건 작업대로 역할이 다르다.

→ 탭 2개 유지 + 클릭 분기 채택을 추천한다. 분기는 지금 바로 넣고, 폰트·정렬도 적용하겠다. (탭을 정말 1개로 합치고 싶으면 그것도 따르겠다 — 아래서 선택)

먼저 헤더 폰트 키우고 정렬 컴포넌트를 만든다:

정렬 헤더에 너비를 줄 수 있게 style prop 추가:

Now matters — import SortTh, sort params, dynamic ORDER BY, split qs:

dir을 소문자로 통일(정렬 헤더와 일관) 후 qs를 필터용/페이저용으로 분리:

사건 표 헤더를 정렬 가능하게 교체하고 페이저에 정렬상태 전달:

이제 의뢰인 표에 정렬 + 클릭 분기(사건 1개면 사건 페이지로). import·타입·정렬 화이트리스트:

의뢰인 qs 분리, 헤더 정렬, 행 클릭 분기:

타입체크·빌드·배포:

완료. 검증 통과 — 정렬(금액 desc 47M→asc 2.6M 정확), 클릭 분기(사건 1개 의뢰인→/matters/20, 여러개→/clients/10) 모두 동작.

완료 — 폰트 · 정렬 · 클릭 분기

사실 사건 탭은 이미 표 형식이다(No.·진행단계·의뢰인·사건명·청구금액·상대방·등록일 + 정렬·필터·페이저). 다만 사건 탭을 열면 위에 임박기일 알림 + 큰 등록폼이 먼저 나와서 표가 한참 아래로 밀려 안 보였을 것이다. → 표를 전면에 오도록 등록폼·기일을 접이식으로 정리한다(두 탭 모두).

먼저 접이식 스타일:

이제 사건 탭에서 임박기일·등록폼을 접이식으로 바꿔 표를 전면에 둔다. 임박기일 접이식:

등록폼 닫기를 details로 마무리:

의뢰인 탭 등록폼도 접이식으로:

타입체크·빌드·배포:

폼은 접혀도 정상 제출(302). 테스트 사건이 남아 id로 정리한다(콘솔 한글 매칭 실패):

완료. 테스트 데이터 정리(사건 24개 복원).

완료 — 표 전면화 (탭 2개 유지)

먼저 확인: 사건 탭은 이미 표였다. 다만 위에 임박기일·등록폼이 먼저 나와 표가 밀려 있던 게 문제였다.

검증: 두 탭 표 정상(사건 20행/페이지, 의뢰인 12행), 접힌 등록폼도 제출 정상(302).

확인 위치: https://a96eca85.lax-dtb.pages.dev/matters

• 사건 탭을 열면 이제 표가 바로 보이고, 그 위에 임박기일 알림 + "새 사건" 버튼만 컴팩트하게 있다.

다음 액션:

• [Jason] 임박기일 기본 펼침/접힘, 컬럼 구성 등 미세조정 있으면 알려주세요.
• [박보검] 다음 후보: 사건↔소장 자동작성 연결(이 사건의 구상금 소장 생성).

두 가지 반영한다 — ① 유입경로(lead source) 필드 ② 임박·경과 기일을 정사각형 가로 스크롤 타일로. 먼저 컬럼 추가와 타일 스타일:

임박기일을 정사각형 타일 가로 스크롤로 교체:

이제 의뢰인 유입경로 — 상수·타입·쿼리·필터:

유입경로 옵션 조회와 쿼리스트링에 반영:

필터바에 유입경로 드롭다운 추가:

등록폼에 유입경로 입력 추가:

INSERT에 source, 표 컬럼·상세에 유입경로 표시:

마이그레이션 적용 + 데모 유입경로 채우기 + 타입체크:

빌드·배포:

배포 출력이 잘렸다. 배포 상태를 확인한다.

완료. 검증 통과.

완료 — 유입경로 + 기일 타일

검증: 유입경로 표/필터/상세 표출, 기일 타일 가로스크롤(158px 정사각) 정상.

확인 위치: https://2a8b8436.lax-dtb.pages.dev/matters (기일 타일) · /clients (유입경로)

다음 액션:

• [Jason] 유입경로를 사건 표에도 노출할지, 추천값 목록 조정할지 알려주세요.
• [박보검] 다음 후보: 유입경로별 통계(어느 경로가 많은지), 또는 사건↔소장 자동작성 연결.

두 가지인데, 먼저 "의뢰인 클릭 시 제대로 안 나온다"부터 진단하고, 소장작성 연동을 위해 현재 구조를 파악한다.

의뢰인 상세는 정상 렌더된다(200 + 정보 + 사건표). "제대로 안 나온다"의 원인은 클릭 분기다 — 사건 1개인 의뢰인(예: 김정훈)을 클릭하면 의뢰인 정보가 아니라 곧장 사건 페이지로 가버려서 의뢰인 정보를 못 본다. 소장 연동 설계를 위해 소장작성 구조를 먼저 본다.

소장작성 구조 파악 완료 — 소장은 chat_session(scope=draft)이고 현재 사건과 연결이 없다. 연동하려면 사건↔문서 연결 테이블이 필요하다. 또 의뢰인 클릭은 상세로 통일한다(분기 제거).

먼저 클릭 통일 + 연결 테이블:

소장작성에 사건 연동 — /complaint-draft?matter=:id로 진입 시 의뢰인·사건명 prefill, 작성 시 사건에 연결:

해당 섹션을 다시 읽고 편집한다(partial read라 편집이 막혔다):

Now the edits apply cleanly:

POST 핸들러를 읽고 연결 로직을 추가한다:

사건 상세에 "소장 작성" 버튼과 관련 문서 섹션을 추가한다. 먼저 문서 조회:

마이그레이션 적용·타입체크·빌드·배포:

완료. 검증 통과.

완료 — 소장작성 연동 + 의뢰인 클릭 정리

A. 소장작성(및 향후 기능) 연동

좋은 정리다. "등록" 버튼을 제목/소제목 줄 오른쪽 끝으로 옮기고, 클릭하면 접이식 폼이 펼쳐지게 한다. 먼저 PageHeader가 우측 버튼(토글)을 지원하도록 확장:

의뢰인 탭 — 제목 우측 버튼 + 등록폼 토글 연결:

S件 탭도 동일하게:

타입체크·빌드·배포:

토글 onclick은 작은따옴표가 HTML 이스케이프돼 grep만 빗나갔다. 버튼에 토글 코드가 실제로 들어갔는지 단순 패턴으로 확인한다.

완료. 검증 통과 — 버튼 onclick 토글 코드 + 헤더 flex(제목 좌·버튼 우) 정상.

완료 — 등록 버튼을 제목 줄 오른쪽 끝으로

확인 위치: https://97ae8b19.lax-dtb.pages.dev/clients

• 제목 오른쪽 "+ 의뢰인 등록" 클릭 → 폼 펼침 → 등록 → 표에 반영.

다음 액션:

• [Jason] 버튼 라벨·색이나 폼 펼침 위치 조정 필요하면 알려주세요.
• [박보검] 다음 후보: 지급명령 등 다른 문서 연동, 또는 유입경로별 통계.

"보관"이 뭔지부터 — 내가 만든 **보관 = 기록을 지우지 않는 삭제(soft delete)**다. 변호사 비밀유지·기록보존 의무 때문에 물리 삭제 대신 목록에서만 숨기고 DB엔 남긴다.

네 지적이 맞다. 종결과 보관은 개념이 다르지만(종결=사건 정상 완료/기록 살아있음, 보관=오등록·중복 치우기), 일상 운영에선 "종결" 진행단계로 충분하고 별도 "보관" 버튼은 혼란이다. 오등록을 치울 삭제 수단만 있으면 된다.

→ 목록의 "보관" 버튼 제거하고, 삭제는 상세에만(오등록 정리용, 이름도 "삭제"로 명확화) 남긴다. 종결은 진행단계 필터로 관리.

먼저 의뢰인 표의 보관 버튼/컬럼 제거:

상세의 "보관"을 "삭제"로 명확화(soft delete 유지):

타입체크·빌드·배포:

완료. 검증 통과.

정리 — "보관" → "삭제"로 명확화, 목록 버튼 제거

보관이 뭐였나: 기록을 지우지 않는 삭제(soft delete). 변호사 기록보존 의무 때문에 DB엔 남기고 목록에서만 숨김.

검증: 목록 보관 버튼 0, 상세 "삭제" 버튼(의뢰인·사건) 정상.

확인 위치: https://779d8950.lax-dtb.pages.dev/clients

정리하면 — 종결 = 사건 정상 완료(기록·통계 살아있음), 삭제 = 오등록 치우기(기록은 보존). 일상은 종결로, 삭제는 예외적으로.

다음 액션:

• [Jason] 목록에서 종결 사건을 기본으로 숨길지(진행 중만 기본 표시) 원하면 그렇게 바꿔드림 — "종결만 보면 된다"는 말이 그 뜻이면.
• [박보검] 다음 후보: 지급명령 등 문서 연동, 유입경로별 통계.

확정 반영한다 — 종결 사건은 기본 숨김, 진행단계 필터로 볼 수 있게. 사건 탭 필터 로직과 드롭다운을 수정한다:

타입체크·빌드·배포:

완료. 검증 전부 정확.

완료 — 종결 사건 기본 숨김

• 사건 탭 진행단계 드롭다운: 첫 옵션이 진행 중(종결 제외) = 기본, 맨 끝에 전체(종결 포함) 옵션.
• 종결 사건은 끝난 거라 평소엔 안 보이고, 필요할 때 필터로 본다.
• (의뢰인 탭은 그대로 — 한 의뢰인이 사건 여러 개라 종결 일괄 숨김이 부정확해서 사건 탭에만 적용)

확인 위치: https://fb127824.lax-dtb.pages.dev/matters

종합하면 — 삭제(오등록 정리, 기록 보존) / 종결(사건 완료, 기본 숨김·필터로 열람)으로 역할이 깔끔히 갈렸다.

다음 액션:

• [Jason] 의뢰인 탭도 "활성 사건 없는(전부 종결) 의뢰인"을 숨길지 원하면 알려주세요.
• [박보검] 다음 후보: 지급명령 등 문서 연동, 유입경로별 통계.

의뢰인 탭도 동일하게 — 최근 사건이 종결인 의뢰인은 기본 숨김, 필터로 열람. (의뢰인은 latest_stage 기준, 사건 없는 신규는 항상 표시)

타입체크·빌드·배포:

완료. 검증 정확 — 기본 11명 + 종결 1명 = 전체 12명, 정확히 분리.

완료 — 의뢰인 탭도 종결 기본 숨김

• 의뢰인은 최근 사건의 진행단계 기준(종결이면 숨김). 사건 없는 신규 의뢰인은 항상 표시(등록 직후 사라지지 않게).
• 사건 탭·의뢰인 탭 동일한 UX로 통일: 기본은 진행 중, 종결은 필터로.

확인 위치: https://f0ebc766.lax-dtb.pages.dev/clients

이제 고객관리 전체가 진행 중인 일에 집중되고, 끝난 건(종결)은 필요할 때만 필터로 본다. 삭제(오등록)와도 깔끔히 구분된다.

다음 액션:

• [Jason] 더 다듬을 곳 있으면 알려주세요.
• [박보검] 다음 후보: 지급명령 등 문서 연동, 유입경로/단계별 통계 대시보드.

폰트 토큰과 Pretendard 로드 여부를 먼저 확인한다.

핵심 발견: --wc-font-sans는 이미 Pretendard, --wc-font-mono는 JetBrains Mono(영문 모노 — 한글이 이상하게 보이는 원인). 진행단계 등 한글에 mono를 써서 그렇다. → CRM 화면의 mono를 전부 sans(Pretendard)로 바꾸고 크기를 키운다.

먼저 공유 컴포넌트(진행단계 칩):

이제 shell의 CRM·셸 mono를 sans로 일괄 변경:

폰트 크기를 키운다 — CRM 표:

개별로 적용한다:

필터·페이저·타일·접이식 헤더 폰트도 키운다:

기일 타일도 키운다:

폼 라벨·입력·D-day 뱃지 폰트도 키운다. 사건 폼 상수:

의뢰인 상세 라벨도 키우고 빌드한다:

mono 전부 제거, 배포 완료. 검증한다:

좋은 질문이다. 두 가지로 답한다 — ① 소장/지급명령 등 문서 시작 화면에서 의뢰인·사건을 직접 매칭하도록 만들고 ② 기일 기입 위치는 의견을 정리한다.

먼저 ① 구현 — 소장 작성 시작 화면에 사건 선택 드롭다운(어디서 시작하든 매칭):

타입체크·빌드·배포:

완료. 검증 통과 — 사건 드롭다운 21개(진행 중), matter=3 진입 시 자동 선택+의뢰인/요지 채움.

① 완료 — 문서 시작 시 의뢰인·사건 매칭

확인: https://1f65e0c0.lax-dtb.pages.dev/complaint-draft

② 기일 기입 — 내 의견

기일은 사건(matter)에 종속되니 주 기입점은 사건 상세가 맞다(현재 구현됨). 거기에 두 가지를 더하면 리걸 실무에 강해진다:

핵심: 기입은 사건 상세 그대로 두되, **자동 기한 생성(①)**이 가장 가치 크다 — 변호사가 깜빡해도 시스템이 기한을 만들어 주는 것. 통합 캘린더(②)는 그 다음.

다음 액션:

• [Jason] 기일을 어떻게 발전시킬지 골라주세요 ↓
• [박보검] 선택 시 해당 방향 구축 (자동 기한 규칙은 변우석과 표준 기한 확정 필요).

@@ASK@@eyJxIjoi6riw7J28IOq4sOyeheydhCDslrTrlrvqsowg67Cc7KCE7Iuc7YKs6rmMPyIsIm8iOlsi64uo6rOEwrfrrLjshJwg7Jew64+ZIOyekOuPmSDquLDtlZwg7IOd7ISxICjstpTsspwpIiwi7Ya17ZWpIOydvOyglSjsupjrprDrjZQpIOu3sCIsIuuRmCDri6Qg64uo6rOE7KCB7Jy866GcIiwi7KeA6riIKOyCrOqxtCDsg4HshLgg6riw7J6FKeycvOuhnCDstqnrtoQiXSwibSI6ZmFsc2V9@@

둘 다 단계적으로 — 1단계는 자동 기한 생성(가치 큼)부터다. 이건 실무 표준 기한이 정확해야 해서 변우석 자문을 먼저 받는다.

변우석 자문이 명확하다(법정기간 확정 + 송달일은 외부입력 필수, 소멸시효 5년 보수적 디폴트). **1단계로 "기준일 입력 → 기한 자동 계산"**을 구현한다. 먼저 규칙과 날짜 계산 헬퍼:

기일 섹션에 자동 계산 폼 추가:

타입체크·빌드·배포:

1단계 완성. 검증 정확 — 소멸시효(2024-01-15 +5년 = 2029-01-15), 답변서(2026-06-01 +30일 = 2026-07-01) 자동 계산.

1단계 완료 — 기한 자동 생성 (변우석 자문 규칙)

사건 상세 기일 섹션에 "기준일 입력 → 기한 자동 계산" 추가:

생성된 기한은 임박기일 타일·D-day로 자동 알림. 누락 위험 1순위(소멸시효)·2순위(항소)·3순위(지급명령 이의) 모두 커버.

중요(변우석 강조): 송달일·판결정본 송달일은 법원에서 확정되는 외부 날짜라 사용자가 기준일로 입력해야 정확하다(소장 작성 데이터로 자동 못 채움). 그래서 "기준일 입력 → 자동 계산" 방식. 소멸시효 5년/10년·공휴일 말일보정은 변호사 확정 사항으로 남김.

확인: https://d60d7d0c.lax-dtb.pages.dev/matters/3 (기일 섹션)

다음 액션:

• [박보검] 2단계 = 통합 일정(캘린더) 뷰 — 전체 사건 기일을 한 화면에.

@@ASK@@eyJxIjoiMuuLqOqzhCDthrXtlakg7LqY66aw642UIOu3sOulvCDsp4DquIgg7KeE7ZaJ7ZWg6rmM7JqUPyIsIm8iOlsi7KeA6riIIOynhO2WiSIsIuyekOuPmSDquLDtlZzrtoDthLAg66mw7LmgIOyNqOuztOqzoCDqsrDsoJUiLCLsupjrprDrjZTripQg7IKs6rG0IO2DrSDslYjsl5Ag64Sj6riwIl0sIm0iOmZhbHNlfQ==@@

2단계 — 통합 일정(캘린더) 뷰를 구축한다. 전체 사건 기일을 월 캘린더로 보는 /schedule 페이지를 만든다.

Register route and add the menu item:

타입체크·빌드·배포:

완료. 검증 통과 — 캘린더 그리드·요일·월 이동·기일 칩(경과 빨강/임박 금색) 정상, 6월 기일 8건 표시.

2단계 완료 — 통합 일정(캘린더) 뷰

둘 다 단계적으로 완성:

일정 캘린더:

• 월 그리드(◀ ▶ 이동, "오늘" 버튼), 날짜 셀에 기일 표시
• 색 구분: 경과(빨강)·14일내 임박(금색)·완료(취소선)·일반(회색)
• 기일 클릭 → 해당 사건으로 이동
• 하루 4건 이상이면 "+N건" 요약, 오늘 날짜 강조

확인: https://ae91956a.lax-dtb.pages.dev/schedule

흐름 정리 — 기일이 사건 상세에서 (수동 또는 자동 계산으로) 입력되고 → 임박 타일·캘린더로 알림 → 클릭하면 사건으로 돌아온다. 변호사 기일 누락 방지 체계가 한 바퀴 돌았다.

다음 액션:

• [Jason] 캘린더에 주간 뷰·필터(사건유형별 색) 등 더 원하면 알려주세요.
• [박보검] 다음 후보: 지급명령 등 다른 문서 연동, 소멸시효 사전경보(6/3/1개월).

두 가지 — 데모 기일을 캘린더에 풍성하게 채우고, 주간 뷰 + 필터를 추가한다. 먼저 데모 기일 추가:

데모 기일 36개로 채워짐. 이제 주간 뷰 + 필터를 추가해 schedule 라우트를 확장한다:

토글 링크를 단순화한다(버그 방지):

타입체크·빌드·배포:

완료. 검증 통과.

완료 — 주간 뷰 + 필터 + 데모 데이터

확인: https://10bff280.lax-dtb.pages.dev/schedule

• [월] 한 달 조망 / [주] 이번 주 집중, 유형·종류로 거를 수 있고 캘린더에 기일이 가득 찼습니다.

종합 — 기일이 사건 상세에서 입력(수동/자동계산) → 임박 타일·월/주 캘린더로 알림 → 클릭하면 사건으로. 일정 관리 한 사이클이 완성됐습니다.

다음 액션:

• [Jason] 더 다듬을 곳(주 뷰 시간대·기일 색을 유형별로 등) 있으면 알려주세요.
• [박보검] 다음 후보: 소멸시효 사전경보(6/3/1개월), 지급명령 등 문서 연동.