delegation: 분석 중인 서브에이전트를 조기 회수하지 않도록 판단 기준 개선

[thisisjun786]

문제

서브에이전트가 파일을 읽고 분석을 진행하는 동안에도, 메인이 wait_agent의 timeout 횟수와 git status의 변경 유무만 보고 작업을 회수할 수 있습니다. 완료된 산출물이 없다는 사실만으로 진행이 멈췄다고 판단하면, 긴 분석이 필요한 executor/reviewer를 중간에 종료하고 같은 작업을 다시 수행하게 됩니다.

확인된 사례

로컬 실행 기록에서 다음을 확인했습니다. 시각은 시작 기준 상대 시간입니다.

경과 시간	관측된 동작
0:00	executor 시작. 쓰기 범위는 UI fixture와 UI 검사 스크립트 두 파일
1:17–17:08	계획, 기존 fixture, 검사 스크립트, 화면 구현을 순차적으로 읽음
18:55	fixture의 기록·관측 범위를 검증하기 위한 history 소스 읽기 완료
18:58	메인이 “19분간 파일 변경 없음”을 이유로 close_agent 호출

• executor는 읽기 도구를 9차례 호출하고 진행 메시지도 5번 남겼습니다.
• 마지막 읽기 결과가 반환된 뒤 약 2.9초 만에 중단됐습니다.
• 메인은 네 차례 기다리는 동안 주로 Git 변경 유무를 확인했습니다. 회수 직전 자식의 최근 활동을 확인하거나 진행 상황을 요청한 기록은 없었습니다.
• 중단 시점까지 코드 변경과 테스트 실행은 없었습니다. 따라서 구현 완료나 품질이 확인된 사례는 아니지만, 무응답 또는 정지 상태였다고 볼 근거도 부족합니다.
• 종료는 메인의 명시적인 도구 호출이었습니다. 고정된 런타임 제한이 자동으로 종료한 사례는 아닙니다.

신고 당시 관련 지침

• plugins/codexclaw/skills/loop/references/waiting.md:31-35는 약 3회 대기 후에도 산출물이 없으면 실패로 처리하고 회수하도록 안내합니다.
• structure/20_pabcd_dispatch_doctrine.md의 DISPATCH-RETIRE-01은 timeout을 회수 사유에 포함합니다.
• plugins/codexclaw/skills/pabcd/references/delegation.md는 native wait timeout을 정상적인 결과로 설명합니다.

신고 당시 문구는 관측을 위한 대기 timeout, 완료 산출물 부재, 실제 진행 정지를 충분히 구분하지 않습니다. 위 문구가 관측 사례의 직접 원인이었다고 확인된 것은 아니며, 회수 판단과 관련 지침을 함께 개선하려는 이슈입니다.

개선 방향

• 대기 횟수나 Git 변경 부재만으로 실패·회수를 결정하지 않습니다.
• 최근 도구 호출/완료, 새 파일이나 소스 영역의 확인, 진행 메시지, 실행 중인 명령, 산출물 변화를 함께 봅니다. 단순히 같은 읽기나 같은 메시지가 반복되는 경우는 실질적인 진전과 구분합니다.
• 느리지만 진행 중인 상태, 장시간 진전이 없는 상태, 확인된 오류, 상태를 관측할 수 없는 경우를 구분합니다. 마지막 관측이 없다는 이유로 무응답을 확정하지 않습니다.
• 읽기 단계가 길어지면 현재까지 확인한 내용·남은 작업·첫 수정 계획을 중단 없이 요청하고, 작업 규모와 명시된 기한을 고려해 회수 여부를 판단합니다. 관측 도구가 없는 호스트에서는 그 한계를 밝히고 사용할 수 있는 상태 확인 경로를 따릅니다.
• 회수가 필요하면 판단 근거, 마지막 활동 시각, 종료 확인, 부분 변경/프로세스 확인, 남은 작업을 남깁니다.
• 기존 fallback 프로토콜을 유지합니다. 실패 보고 결과가 reconcile 또는 stop이면 직접 구현이나 다른 모델로 전환하는 허가로 해석하지 않습니다.

통합 수정 범위

수정은 #180에서 검토합니다. #177과 #179를 통합하되, executor 우선 위임을 강제하는 정책은 철회했습니다. 위임 여부는 기존 CXC 판단 기준을 그대로 따릅니다. executor 우선이나 메인 직접 구현을 새로운 기본 정책으로 추가하지 않습니다. 정식 P 단계의 architect 검토와 독립 리뷰는 유지합니다.

이 이슈의 회수·복구 기준은 실제로 위임한 작업에 적용합니다. 위임 여부와 별개로 이미 실행 중인 자식을 임의로 회수할 수는 없습니다. 관리형 위임의 인계는 여전히 종료·부분 작업 확인과 반환된 main-direct 결과가 필요합니다.

수용 기준

• 파일 변경 없이 읽기·분석이 진행 중인 executor/reviewer는 단순 wait timeout 누적으로 회수되지 않는다.
• 최근 활동이 있는 경우와 실제 무응답·확인된 오류를 구분하는 재현 사례가 있다.
• 반복 읽기/상태 메시지만으로 무기한 생존하는 경우도 다룬다.
• 상태 관측이 제한된 호스트의 처리와 명시적인 취소·기한·예산 제한의 우선순위를 정의한다.
• 회수 근거와 종료/부분 작업 확인을 남기며, 기존 dispatch 및 fallback 권한을 우회하지 않는다.
• 대기 안내와 canonical 회수 지침을 함께 정리하고, 필요한 동작 검증과 문구 일관성 검증을 추가한다.
• 확인된 정체·사용할 수 없는 최종 결과는 명시적인 task_failed 보고로 복구하며, 등록된 자식 ID·종료 상태·부분 작업 확인과 두 번의 시도 한도를 검증한다. 취소·권한 거절·관측 불명은 기존 stop/reconcile 처리를 유지한다.

진행 상태

• 통합 수정 PR: [agent] feat(pabcd): strengthen architect consultation and retain safe recovery #180. 기존 feat(pabcd): make architect and executor delegation explicit #177·#179는 #180으로 대체해 닫았고 원래 브랜치와 기록은 보존합니다.
• 로컬 검증: 전체 3,177개 중 3,103개 통과, 74개 조건부 건너뜀, 실패 0개. 빌드·독립 리뷰·설치본 CLI 검사와 재적용 패치 검증도 완료했습니다. 구체적인 명령과 검증 범위는 #180에 기록했습니다.
• 위임·회수 판단 지침은 에이전트가 따르는 정책입니다. 자동 테스트는 복구 상태 전이와 안내 출력을 검증하며, 모든 모델이 지침을 준수함을 보증하지는 않습니다.
• 아직 upstream에 병합되거나 릴리스된 상태가 아니므로 이슈와 수용 기준은 열린 상태로 둡니다.