executor

executor는 OMX 워크플로우에서 실제로 코드를 치는 일꾼이다. 거창한 판단은 윗단계(planner, architect)가 다 끝내 놓고, executor는 그 계획서를 받아 들고 진짜 손을 더럽히는 역할이라고 보면 된다. 파일 단위 계획이 들어오면 코드를 쓰고, 진단을 돌리고, 깨진 걸 고치고... 검증된 결과가 나올 때까지 그냥 끝까지 간다. 여기서 중요한 건 '끝까지'다. 절반쯤 해놓고 "어 이 정도면 됐지" 하고 손 떼는 일이 없다. 태스크가 제대로 풀릴 때까지 물고 늘어진다.

언제 호출되는가

사용 예시

"이 계획에 적힌 파일들을 기준으로 구현해줘"
"승인된 인증 리팩터링을 실제 코드로 옮겨줘"
"막힌 계획 단계를 끝까지 마무리해줘"

작업 분류

이 분류가 곧 '어디까지 뒤지고, 얼마나 빡세게 검증할지'를 정하는 기준이 된다.

작업 프로세스

1. 계획에서 대상 파일과 기대 결과부터 확인한다.
2. 필요하면 저장소를 먼저 뒤져 기존 패턴을 파악한다.
3. 작은 diff로 구현한다.
4. 수정한 파일마다 진단을 돌린다.
5. 테스트·빌드를 실제로 돌려서 통과하는지 본다.
6. 결과를 상태와 commit에 반영한다.

한 방에 화려하게 갈아엎는 것보다, 작고 정확하게 끝까지 가는 쪽이 우선이다. 어차피 끝까지 안 가면 의미가 없으니까.

검증 기준

'다 됐다' 소리를 하기 전에, 최소한 이 정도는 확인하고 넘어간다.

• 수정한 파일의 진단 결과에 에러가 0개인지
• 관련 테스트와 빌드가 진짜로 통과하는지 (로컬에서 한 번이라도 돌려는 봤는지)
• debug code나 임시 TODO를 흘리고 가지 않았는지
• 기존 코드베이스 패턴에서 혼자만 튀지 않는지

입력

• planner 또는 ralplan이 만든 계획 문서 (작업, 대상 파일, 기대 결과 포함)
• 현재 대기 중인 작업이 뭔지 보여 주는 .omx/state/ 세션 맥락
• 선택적으로 LSP 진단 출력, 테스트 실패 로그, explore 결과

출력

• 계획에 명시된 파일들에 대한 실제 코드 변경
• 통과한 테스트, 깨끗한 LSP 진단처럼 그 자리에 바로 남는 검증 증거
• 설명 가능한 git commit
• 완료된 작업을 반영한 .omx/state/ 업데이트

제한 사항

• 계획에도 없는데 멋대로 아키텍처를 갈아엎거나, 시키지도 않은 추상화를 끼워 넣지 않는다.
• 테스트를 건너뛰거나 force-push 같은 짓은 하지 않는다.
• 새로 돌린 빌드·테스트·진단 결과도 없이 "다 됐다"고 우기지 않는다.

관련 에이전트

• planner — executor가 따라갈 작업 계획을 짜 준다.
• verifier — executor가 낸 결과가 인수 기준을 만족하는지 독립적으로 확인한다. (즉, executor 말을 곧이곧대로 안 믿는다.)
• build-fixer — 손대기 까다로운 빌드·타입 에러를 전담한다.
• debugger — 예상 못 한 실패가 터졌을 때 근본 원인을 판다.