[refactor] Orca 연동을 걷어내고 direct 실행과 Herdr·수동 터미널 인계만 남긴다 #560

요약

IssueOps에서 Orca 연동과 실행 방식 선택 개념을 걷어냅니다. 실행 경로는 git sibling worktree와 lease를 쓰는 하나만 남깁니다. 구현 세션 인계는 Herdr나 사용자가 직접 연 두 번째 터미널에서 기존 lease 인수 절차로 처리합니다. 기존 holder가 release하면 새 세션이 replace --preview, --reseed, claim 순서로 인수합니다. 호환 읽기 경로는 남기지 않으며, 로컬에 남은 옛 모양 데이터의 정리는 후속 작업으로 미룹니다.

배경

• 실제 사용 경로는 이미 direct입니다. 기본 흐름이 execution prepare --mode direct로 worktree를 만든 뒤 Herdr나 현재 세션으로 이어 가고, 로컬 기록 가운데 Orca 모드 기록은 하나도 없습니다.
• 그런데도 Orca 지원 코드가 공용 경로에 넓게 퍼져 있습니다. 이름에 orca가 들어간 Go 파일이 87개(본 코드 약 4,900줄, 테스트 약 12,100줄)이고, 공용 파일 134개에 Orca 분기가 1,019곳 있습니다. lease 검증, prepare, reconcile, replace, cleanup, doctor가 모두 Orca 경우를 따로 다룹니다.
• Orca가 언급된 이슈가 158개로, 유지 비용이 계속 들고 있습니다.
• Herdr 연동은 스킬 문서만으로 동작하므로 Orca를 지워도 Herdr 쪽 Go 코드는 바뀌지 않습니다.

범위

1. 기본 경로에서 Orca 제거: 스킬과 운영 문서의 자동 세션 선택에서 Orca 확인과 Orca 인계를 지웁니다. 선택 순서는 Herdr, 그다음 현재 세션 또는 수동 터미널입니다.
2. Orca 모드 코드 삭제: orca·auto 실행 모드, execution resume, execution switch-mode, Orca intent 체인과 reconcile 분기, Orca claim 봉인 자료, doctor의 Orca 판정, cleanup의 Orca 제거 단계, 인계 기록의 orca 런처, Orca owner 프롬프트, Orca adapter와 port를 지웁니다.
3. 계약 정리: 실행 방식이 하나만 남으므로 방식을 기록하던 필드(execution.mode, execution.selection, workspace.driver)와 Orca 필드(execution.orca, Orca 전용 pending 종류, cleanup의 Orca 항목)를 기록·CLI·MCP 계약에서 지웁니다. execution prepare는 --id, actor 플래그, --confirm만 받습니다. 지운 필드나 런처를 읽기 위한 호환 경로는 두지 않습니다.

영향:

• 이전 바이너리가 쓴 실행 기록(mode·selection·driver 포함)은 새 바이너리에서 읽히지 않습니다.
• 인계 감사 파일에 orca 런처 줄이 남은 lifecycle에서는 감사 기록 전체 읽기가 실패해 cmux 인계가 막힙니다.
• 이 데이터 정리는 이번 범위에 넣지 않고 필요할 때 따로 작업합니다.

비목표:

• cmux 연동(execution handoff-cmux)은 유지합니다.
• 로컬 state의 옛 모양 데이터(실행 기록, 인계 감사 줄)는 정리하지 않습니다.
• 사용자 머신의 Orca 설치나 리소스는 정리하지 않습니다.
• 저장소 밖 사용자 전역 스킬은 수정하지 않습니다.
• Herdr 연동을 Go 코드로 옮기지 않습니다.
• 과거 작업 기록 문서는 수정하지 않습니다. 기존 결정 기록에는 새 결정으로 대체됐다는 표시만 남깁니다.

완료 기준

• 추적되는 Go 파일 가운데 Orca를 언급하는 파일이 0개입니다.
• issueops --help와 usage golden에 execution resume, execution switch-mode, --mode가 없습니다.
• 실행 기록 계약에 mode, selection, driver 필드가 없고, 지운 명령·플래그·필드 이름이 현행 코드·스킬·문서에 남아 있지 않습니다.
• 임시 저장소에서 prepare, release, replace preview, reseed, claim 순서의 인계가 실제로 동작합니다.
• skills/ 아래 Orca 언급이 0개이고, 자동 세션 선택은 Herdr를 먼저 확인한 뒤 현재 세션 또는 수동 터미널로 넘어갑니다.
• lease generation·holder·canonical cwd 검증은 약해지지 않습니다.
• Orca 제거 결정과 옛 데이터 영향을 새 결정 기록(ADR)으로 남깁니다.

검증

git ls-files '*.go' | xargs grep -il orca | wc -l   # 0
grep -ril orca skills | wc -l                       # 0
gofmt -l $(git ls-files '*.go')
go vet ./...
go test ./... -count=1
go test -race ./... -count=1
go build -o bin/issueops ./cmd/issueops
./bin/issueops self-verify --seed=100 --target-score=95 --llm-eval=false --json

임시 state와 임시 Git 저장소에서 새 바이너리로 인계 체인을 직접 실행해 각 단계의 lease 상태와 generation을 확인합니다.

계획 검토

계획 검토: 1차 수정 요청(지적 5건) → 계획 수정 → 2차 수정 요청(지적 4건) → 계획 수정 → 3차 수정 요청(지적 2건) → 계획 수정 → 4차 수정 요청(지적 1건) → 계획 수정 → 5차 통과(지적 3건)

진행 결과

IssueOps에서 Orca 연동과 실행 방식 선택(auto, direct, orca)을 코드, 계약, 스킬, 현행 문서에서 모두 지웠고, PR #565가 squash로 머지됐습니다. 실행 방식은 direct 하나만 남고, 세션 인계는 같은 인수 체인을 Herdr나 두 번째 터미널에서 실행합니다.

• 계획: internal/adapter/orca와 Orca 포트, 실행 기록의 mode·selection·driver·orca 필드, execution resume·switch-mode 같은 Orca 전용 명령을 호환 경로 없이 지우기로 했습니다.
• 리뷰: 병합 전 다섯 라운드에서 필수 결함 5건을, 병합 뒤 두 라운드에서 1건을 고쳤고 마지막 라운드에서 통과했습니다.
• 구현: [refactor] Orca 연동을 걷어내고 direct 실행과 Herdr·수동 터미널 인계만 남긴다 #565 에서 파일 723개를 바꿨고, usage·MCP·response contract·설치 golden을 다시 만들었습니다.
• 재작업: 첫 완료 뒤 옛 main의 lint 부채와 새 main과의 충돌로 CI가 막혀, #563과 #561이 들어간 main을 병합하고 충돌 11개를 해소한 뒤 사이클을 다시 열어 검증과 완료를 다시 받았습니다.
• 확인: 게이트 13개, go test -race ./..., self-verify, GOOS=linux와 darwin lint 0 issues., 인계 체인 통합 테스트가 통과했고, PR CI는 push와 pull_request 두 이벤트 모두 통과했습니다.
• 남은 것: 옛 바이너리가 쓴 실행 기록과 orca launcher가 남은 감사 파일은 새 바이너리에서 읽히지 않으므로, 바이너리를 갱신하기 전에 남은 사이클을 옛 바이너리로 끝내야 합니다.