LAXworkspace
알림 · 보고서
⚙️

상원· 인프라/플랫폼 오너 — daemon·런타임 하니스↗

오프라인입력 0 (캐시 0%) · 출력 0
새 대화
세션 목록
⚠ 로컬 데몬이 오프라인입니다 — 메시지는 큐에 쌓였다가 데몬이 켜지면 처리됩니다.
변우석의 요청: 변우석입니다. Jason이 "서류작성 라우트를 /docs/<영문슬러그> 체계로 전면 정리"를 승인했습니다. 현재는 활성 4종이 /complaint(소장)·/complaint?type=한글(지급명령·답변서·준비서면)을 공유하고 작업대는 /complaint-draft로, 슬러그가 의미와 안 맞고 한글 쿼리라 지저분합니다. 정석대로 서류별 고유 슬러그로 바꿔주세요. [slug 매핑 — 법무 확정값] - 소장 → sojang - 지급명령신청서 → jigeup-myeongryeong - 답변서 → dapbyeon - 준비서면 → junbi-seomyeon (legal_doc_catalog 전체에도 slug를 부여하면 좋습니다. 위 4종은 라우트 연결 대상, 나머지는 데이터만.) [요구사항] 1. legal_doc_catalog에 slug 컬럼 추가(마이그레이션) + 전 서류 slug 데이터. slug↔doc_type 매핑을 단일 소스(헬퍼)로. 2. 라우트 재구성: /docs/:slug(목록) · /docs/:slug/new(작성폼) · /docs/:slug/work/:id(작업대) · 내부 경로(poll·print·hwpx·evidence·attachment 등 37곳)도 전부 /docs/:slug/... 로 일관. 기존 complaint/draft 핸들러는 재사용하되 slug를 context로 받아 내부 링크를 /docs/${slug}/...로 생성. 3. 하위호환: 기존 /complaint, /complaint?type=…, /complaint-draft/* → 대응 /docs/<slug>/…로 301 리디렉트(기존 세션·북마크·외부링크 보호). 4. 데몬 호환성 필수 확인: 데몬이 작업대 세션을 처리·poll하는 경로가 안 깨지는지(이게 깨지면 작업대 전체 마비). 지금 프로덕션 작업대를 실사용 중이라 무중단이 중요합니다. 5. doc_nav.ts·shell.tsx 메뉴 링크 → /docs/<slug>. 6. 테스트(lax-dtb) 검증 후 프로덕션(axwiki). 규모가 크니 한 턴에 무리면 단계로: ①catalog slug 컬럼+데이터+매핑헬퍼 → ②/docs 라우트(목록·작성·작업대) + 리디렉트 → ③내부 경로/메뉴 일괄 치환 → ④배포. 각 단계 완료/미완을 명확히 보고해 주세요. 배포·멀티턴 검증은 제가 이어서 닫겠습니다. 질문: 이 방향(/docs/:slug + 기존경로 301 + 핸들러 slug-context화)이 현 구조에 맞나요? 데몬 경로 의존성 때문에 다른 설계가 더 안전하면 제안 주세요. 1단계(catalog slug + 매핑헬퍼)부터 시작 가능한지 알려주세요.

검증 완료. 결과를 정리해 보고합니다.

결론부터

방향 맞습니다. 데몬은 안전합니다(결정적 확인). 1단계는 방금 만들어 검증까지 끝냈습니다. 단, 리디렉트에 한 가지 보정이 필요합니다(아래 ②).

① 데몬 호환성 — 안전 (결정적 근거)

daemon/daemon.js 전체를 grep한 결과, 라우트 경로(/complaint, /complaint-draft, /work 등) 참조가 0건입니다. 데몬은 이렇게 동작합니다:

  • /bridge/poll로 task_queue에서 작업 수신 → session_id·working_dir·agent_slug로 실행 → chat_messages에 스트림 기록(/bridge/ingest).
  • 작업대 무중단의 실제 의존축은 task_queue 스키마 · chat_sessions.scope='draft' · 문서 마커(SOJANG) 이며, 이번 라우트 변경의 대상이 아닙니다.

→ URL 슬러그를 바꿔도 데몬-작업대 처리는 깨지지 않습니다. 이게 이 작업이 안전한 핵심 이유입니다.

② 보정 — POST 내부경로는 301이 아니라 308이어야 함

/complaint-draft/work/:id/ 하위에 상태변경 POST 3종이 있습니다: doc-source(편집 저장)·attachment/delete·checklist. 이미 열려 있는 작업대 탭은 구 경로로 이걸 호출 중입니다.

  • GET(목록·작성·작업대·poll·print·hwpx·evidence) → 301 OK (fetch가 자동 추종).
  • POST 3종 → 301/302는 메서드를 GET으로 바꿔 본문이 유실됩니다. → 308(영구) 또는 307로 메서드·본문 보존 필수.

권고: 네비게이션 GET = 301, 내부 상태변경 API = 308. 이게 실사용 중 탭 무중단의 핵심 디테일입니다.

추가로 2단계 설계 시: /docs/:slug/work/:id에서 slug와 세션 실제 doc_type(matter_documents.doc_type)이 어긋날 수 있으니, slug는 내부링크·메뉴 하이라이트용으로만 쓰고 문서종류는 기존대로 세션 기준으로 결정하세요(불일치 시 정규 slug로 301).

③ 1단계 완료 — catalog slug + 매핑 헬퍼

항목 내용
신규 헬퍼(SSOT) src/shared/doc_slug.ts — slugToDocType·docTypeToSlug·isRoutedSlug·ROUTED_SLUGS. 역매핑은 단일 상수에서 파생.
신규 마이그레이션 migrations/0063_legal_doc_catalog_slug.sql (※ 최신이 0062_matter_files라 0062 아닌 0063)
slug 컬럼 ALTER ADD COLUMN slug TEXT + UNIQUE 인덱스
4종 sojang/jigeup-myeongryeong/dapbyeon/junbi-seomyeon (법무 확정값, doc_name 기준 UPDATE)
나머지 30종 doc-<id> 데이터용 안정 슬러그(의미 없음, 라우트 비연결, 후속 의미화 대상)

검증(자가 DONE 아님, node:sqlite로 실제 적용):

  • 4종 slug ↔ doc_name 매핑 정확 ✅
  • NULL slug 0건 ✅ / 중복 slug 0건 ✅
  • 전체 34행 중 30행 doc-, 4행 의미 슬러그 ✅

나머지 30종을 임의 로마자화하지 않은 이유: 그건 법무 확정값이 아니라 추측입니다. UNIQUE만 보장하는 placeholder로 두고, 의미 슬러그는 후속에 법무가 채우는 게 안전합니다. 필요하면 매핑 주시면 반영하겠습니다.

롤백: 두 파일 모두 신규 → git에서 파일 삭제로 즉시 원복. 마이그레이션이 이미 적용됐어도 slug 컬럼은 아무도 안 읽으면 무해(2·3단계 머지 전까지 dead column).

적용(변우석 검증 단계): wrangler d1 execute <바인딩> --file=migrations/0063_legal_doc_catalog_slug.sql — 테스트(lax-dtb) → 프로덕션(axwiki) 순. 정확한 바인딩명은 wrangler.toml 기준.

2단계(/docs/:slug 라우트 + 301/308 리디렉트) 착수해도 좋다고 하시면, 위 ② 보정을 반영해 핸들러 slug-context화부터 진행하겠습니다. 배포·멀티턴 검증은 말씀대로 변우석님이 이어 닫으시면 됩니다.