Hwp Migrate

1. _workspace/ 존재 여부 확인
2. 실행 모드 결정:
   • _workspace/ 없음 → 초기 실행 (Phase 1~4 전체)
   • _workspace/ 있음 + 특정 모듈 수정 요청 → 해당 모듈만 재실행
   • _workspace/ 있음 + 새 모듈 요청 → Phase 2~4만 실행 (기존 _workspace 보존)

Phase 1: 준비

1. 사용자 입력에서 마이그레이션할 모듈 목록 파악
   • 명시되지 않으면 references/parser-module-map.md의 구현 순서 기준
   • 이전 세션에서 완료된 모듈은 _workspace/completed.md에서 확인
2. _workspace/ 디렉토리 생성 (없는 경우)
3. 작업 목록 구성:
   • analyst 작업: 각 모듈 설계 ({module}-design.md)
   • implementer 작업: 각 모듈 구현 (설계 완료 후 시작)
   • validator 작업: 각 모듈 검증 (구현 완료 후 시작)

Phase 2: 팀 구성

팀 생성:

TeamCreate(
  team_name: "hwp-migration-team",
  members: [
    {
      name: "hwp-analyst",
      agent_type: "hwp-analyst",
      model: "opus",
      prompt: "hwp-module-port 스킬을 참조하여 {모듈 목록}을 분석하고 TypeScript 설계 문서를 생성하라.
               설계 완료 시 hwp-implementer에게 SendMessage로 알린다.
               설계 문서는 _workspace/{module}-design.md에 저장."
    },
    {
      name: "hwp-implementer",
      agent_type: "hwp-implementer",
      model: "opus",
      prompt: "hwp-module-port 스킬을 참조하여 analyst의 설계 문서를 기반으로 TypeScript를 구현하라.
               구현 후 tsc --noEmit로 컴파일 확인.
               완료 시 hwp-validator에게 SendMessage로 알린다."
    },
    {
      name: "hwp-validator",
      agent_type: "hwp-validator",
      model: "opus",
      prompt: "implementer가 완료 메시지를 보내면 구현을 검증하라.
               Rust CLI(rhwp dump)와 출력을 비교한다.
               PASS 시 오케스트레이터에게 알림, FAIL 시 implementer에게 수정 요청."
    }
  ]
)

작업 등록:

TaskCreate(tasks: [
  { title: "{module} 분석", assignee: "hwp-analyst" },
  { title: "{module} 구현", assignee: "hwp-implementer", depends_on: ["{module} 분석"] },
  { title: "{module} 검증", assignee: "hwp-validator", depends_on: ["{module} 구현"] },
  ...
])

Phase 3: 마이그레이션 실행

팀원들이 자체 조율하며 파이프라인 방식으로 작업한다:

• analyst → implementer → validator 순서
• 모듈 간 의존성을 지킨다 (참조: references/parser-module-map.md 구현 순서)

오케스트레이터는 다음 상황에서 개입한다:

• validator FAIL이 2회 이상 반복될 때
• implementer가 블로킹됐다고 알릴 때
• 팀원이 유휴 상태가 10분 이상 지속될 때

Phase 4: 통합 및 완료 처리

1. 모든 모듈 검증 통과 시:
   • _workspace/completed.md 업데이트 (완료 모듈 목록)
   • src/index.ts에 공개 API 노출 여부 확인
2. 파서 레이어 완료 시:
   • npm run type-check 실행 (전체 프로젝트)
   • MCP 서버 구현 가능 여부 사용자에게 보고

에러 핸들링

• validator 2회 연속 FAIL: 해당 모듈 작업 중단, 사용자에게 보고하고 수동 검토 요청
• 컴파일 오류: implementer가 수정. 3회 실패 시 analyst에게 설계 재검토 요청
• npm 패키지 없음: implementer가 package.json에 추가 후 npm install

데이터 흐름

_workspace/
├── completed.md          ← 완료된 모듈 목록
├── {module}-design.md    ← analyst 산출물
├── {module}-validation.md ← validator 산출물
└── test-runner.ts        ← validator 테스트 스크립트

src/                      ← implementer 산출물 (실제 프로젝트 코드)
├── parser/
├── model/
└── index.ts

테스트 시나리오

정상 흐름

입력: "byte_reader.rs와 record.rs를 TypeScript로 포팅해줘"
1. analyst가 두 파일 읽고 설계 문서 생성
2. implementer가 byte-reader.ts, record.ts 구현
3. validator가 컴파일 + 기본 파싱 동작 확인
4. 사용자에게 완료 보고

에러 흐름

입력: "doc_info.rs 포팅해줘" (byte_reader, record 미구현 상태)
1. analyst가 의존성 확인
2. 선행 모듈(byte_reader, record, header) 미구현 감지
3. 사용자에게 "선행 모듈 먼저 구현 필요" 보고 후 순서 제안

참고

• 파서 모듈 전체 목록 및 구현 순서: references/parser-module-map.md
• Rust→TS 변환 패턴: hwp-module-port 스킬
• MCP 서버 구축: hwp-mcp-build 스킬