Task Wait

작업 완료 대기

2026-09-10 실제 실행에서 조율자가 50초 sleep과 전체 terminal read를 100회 이상 반복했다. 대기 자체보다 매번 다시 실행되는 모델과 큰 문맥 재입력이 문제였다.

실행 전에 정할 것

• 작업 ID, 결과 파일, 완료/실패 신호, 마감 시각을 인계서에 명시한다. 검수 기본 상한은 45분, 집필은 90분이며 기존 실행기의 더 짧은 상한을 우선한다. 사용자가 정한 상한이 있으면 따른다.
• 이미 실행기가 있다면 그 프로세스의 종료 코드와 실행 영수증을 사용한다. 보호자 노트는 audit-status.mjs --wait, 내차공략은 기존 검수 실행기의 완료·보류 영수증을 회수한다. 같은 작업에 별도 감시 루프를 추가하지 않는다.
• Orca 구조화 작업이면 orca-cli와 orca skills get orchestration의 현재 가이드를 읽고 유효한 Run/Task/Dispatch를 사용한다. 작업자는 결과를 저장한 뒤 자기 Dispatch에서 worker_done을 한 번 보낸다. 단순 terminal send에는 이 완료 통지가 자동으로 생기지 않는다. 유효한 Dispatch 없이 lifecycle ID를 만들어 보내지 않는다.

대기는 실행기가 담당한다

• 런타임이 제공하는 완료 알림과 비동기 재개를 우선한다. 실제 지원 여부를 확인하며, 파일만 저장하면 조율자가 자동으로 깨어난다고 가정하지 않는다.
• Orca에서는 check --wait --types worker_done,escalation,question을 사용하고 모든 Delivery를 처리·ack한다. 대기 창이 끝나도 동일 작업·마감을 유지한다. 타임아웃마다 terminal read/list 또는 새 작업자 실행을 붙이지 않는다.
• 도구가 실행 세션 ID를 반환하면 그 프로세스를 재사용한다. 알림이 없는 도구는 같은 프로세스의 결과만 제한된 출력으로 회수한다. 상위 도구의 응답 시간·사용자 진행 보고 규칙을 지키고, 매 회수마다 전체 터미널·원고·상태 파일을 다시 읽지 않는다.
• sleep → terminal read, 반복 find/stat, 짧은 write_stdin 폴링을 작업 진행 확인 수단으로 쓰지 않는다. 실행기 내부의 유한 파일/PID 확인은 허용한다. 모델을 부르는 외부 반복과 구분한다.
• 원시 터미널 확인은 시작 준비 1회, 오류나 마감 도달 시 진단 1회를 기본 상한으로 한다. 추가 읽기는 새 오류·사용자 개입 등 구체적인 이유가 있을 때만 변경분(cursor)으로 읽는다. 매번 같은 전체 화면을 읽지 않는다.
• tui-idle, heartbeat, 파일 존재, 출력 없음은 성공 판정이 아니다. 완료 신호 뒤 결과 파일·검수 해시·종료 코드를 확인한다. 대기 명령의 종료 코드 0도 검수 PASS와 구분한다.

상한과 재개

• 정해진 마감에 완료가 없으면 한 번 진단하고 현재 작업 ID, handle, 결과 경로, 원인과 재개 조건을 기록한다. 대기 상한을 자동 갱신하거나 같은 작업자를 다시 시작하지 않는다.
• 대기 종료는 작업자 실패나 프로세스 종료를 뜻하지 않는다. 살아 있는 작업자의 파일 소유권을 유지하며 강제 종료·큐 소유권 탈취를 하지 않는다. 이후 완료 알림 또는 명시적인 재개 요청에서 같은 실행을 회수한다.
• 추가 지침이 없는 검수는 단계별 최초 1회 + 재검수 2회까지다. 미통과면 보류로 남긴다. 상한은 품질 기준 완화나 자동 통과의 근거가 아니다. 기존의 더 엄격한 상한은 유지한다.
• 단순 대기를 위해 고급 모델의 추론을 반복하지 않는다. 사용자가 지정한 집필·검수 모델과 품질 기준은 보존한다.