km-workflow

Knowledge Manager Workflow

Complete 6-phase workflow guide for content processing

---

Workflow Overview

Phase 0: Load Configuration
    ↓
Phase 1: Detect Input Source
    ↓
Phase 1.5: Collect User Preferences
    ↓
Phase 2: Extract Content
    ↓
Phase 3: Analyze Content
    ↓
Phase 4: Select Output Format
    ↓
Phase 5: Execute Export
    ↓
Phase 6: Verify and Report

---

🛑 MANDATORY WORKFLOW - 절대 건너뛰지 마세요!

Antigravity/Gemini CLI에서 반드시 실행:

STEP 1: 사용자 선호도 확인 (Phase 1.5) - 필수!

콘텐츠 처리 전 반드시 아래 질문을 사용자에게 물어야 합니다:

📊 상세 수준: 1.요약 / 2.보통 / 3.상세
🎯 중점 영역: A.개념 / B.실용 / C.기술 / D.인사이트 / E.전체
📝 노트 분할: ①단일 / ②주제별 / ③원자적 / ④3-tier
🔗 연결 수준: 최소 / 보통 / 최대

기본값(3.상세, E.전체, ④3-tier, 최대)을 사용하시겠습니까?

💡 3-tier란? 개요 노트 + 주제별 노트 + 원자적 노트로 계층 구조화

소셜 미디어(Threads/Instagram) URL인 경우 추가 질문:

🔄 답글 수집 범위:
  1) depth=1: 직접 답글만 (빠름)
  2) depth=2: 답글의 답글까지 (더 완전한 맥락)

⚠️ 이 단계를 건너뛰면 안 됩니다!

• 사용자가 "빠르게", "기본으로" 등 퀵 프리셋 키워드를 사용한 경우만 생략 가능
• 그 외 모든 경우: 반드시 질문 후 진행

STEP 2-0: 저장 루트·위치 결정 (Phase 3.4) - 필수! 🔴

저장 루트는 backend 설정이 아니라 사용자가 연 프로젝트가 정한다. ChatGPT Work 로컬 프로젝트에서는 host가 제공하는 primary 연결 폴더, Codex CLI에서는 대화를 시작한 작업 디렉터리, IDE에서는 선택한 workspace root를 target_root로 기록한다. ChatGPT 프로젝트(로컬 프로젝트 아님)는 컴퓨터 폴더에 직접 접근하지 못하므로 target_root를 추측하지 않는다.

우선순위: 사용자가 이번 요청에서 명시한 대상 폴더 > host가 제공한 primary project/workspace root > project-scoped 요청이 아닐 때만 km-config.json backend. 사용자가 명시적으로 다른 연결 폴더나 Notion을 선택한 경우는 그 지시를 따른다.

1. 루트 확정: target_root = realpath(host_project_root)로 canonicalize한다. host가 primary root와 shell cwd를 구분하면 cwd를 프로젝트 루트로 추정하지 않는다. project-scoped 요청인데 root를 확인할 수 없으면 저장을 중단하고 대상 폴더를 요청한다.
2. 구조 선독 (MUST-read): ${target_root}/VAULT-STRUCTURE.md가 있으면 경로를 정하기 전에 반드시 read하고 그 구조(예: 직군/사업/연도/문서종류)에 맞는 폴더를 결정한다. 있으면 ${target_root}/MOC-Map.md도 read하여 기존 허브·관련 문서 연결에 사용한다. 사용자가 경로를 지정했으면 그 지시가 우선이다. read 실패·부재 시 새 최상위 폴더를 추정 생성하지 말고, 명시 경로가 없으면 target root에 저장하고 그 fallback을 보고한다.
3. 경로 봉쇄: relativePath를 정규화한 뒤 candidate_path = realpath(parent) + filename을 계산한다. candidate_path가 target_root 밖이면 저장하지 않는다(.., 절대경로, symlink escape 포함).
4. 도구는 루트 뒤에 선택: Obsidian CLI/MCP의 실제 연결 볼트를 canonicalize하여 target_root와 동일하다고 확인한 때만 사용한다. 불일치·확인 불가면 파일 쓰기 도구로 target root 안에 저장한다.
5. Provenance: 최종 보고에 구조 문서 read 결과, target_root, 선택한 상대 경로, 저장 후 관측한 actual_saved_path를 남긴다.