완료보고 근거 누락 재발 방지 운영 메모

1. [권고]

1순위: 다음 태스크 body 맨 아래에 “완료보고는 도메인 출력과 별개로 결론/근거/검증/근거파일 4줄을 독립 줄로 작성하고, 근거·검증에는 실존 경로와 실행 결과값을 직접 넣어라”를 고정 삽입한다. 근거: 2026-09-15 13:38~14:56 KST 최근 반려 9건 중 8건이 근거·검증·경로 누락 계열이다. 기대효과: missing_*·결과물 경로 누락·검증 결과 누락 계열 반려를 7일 내 50% 이상 줄이는 것이 1차 목표다.

2순위: 에이전트별 금지 문구와 대체 문구를 태스크 body에 같이 넣는다. 근거: analyst-macro는 존재하지 않는 경로와 허구 수치, analyst-technical은 중복 경로, codex는 원본로그경로 자리표시자, ron은 검증 명령 누락, cowork는 도메인 제안서만 쓰는 패턴이 서로 다르다. 기대효과: 단일 체크리스트로 해결 안 되는 에이전트별 재발 원인을 분리해, 재시도 1회 안에 통과율을 높인다.

2. [현황]

확인 시각: 2026-09-15 14:56 KST. 읽은 정책 파일 2개: - config/agent_completion_submission_standard.md - config/completion_evidence_policy.md

최근 DB 반려 사례 9건: - 38871 analyst-technical: verification_command_path_not_found, execution_artifact_path_not_found. scripts/scripts/pipeline처럼 경로가 중복됨. - 38869 ron: missing_execution_value, missing_source, missing_verification_value, missing_original_verification, missing_execution_artifact, missing_verification_command, missing_verification_result. - 38866 analyst-macro: missing_verification_command, missing_verification_exit_code. 원본 요약에 2024-05-23 타임스탬프와 OAS 145.2 등 검증 불가 값 포함. - 38865 ron: 38869와 동일한 7개 누락 라벨. - 38864 codex: missing_original_verification, missing_verification_command, missing_verification_result. <원본로그경로> 자리표시자와 실패한 검증 결과 포함. - 38863 ron: missing_verification_command. - 38862 analyst-macro: execution_artifact_path_not_found:/Users/ron/.hermes/workspace/scripts/pipeline/macro_bridge.py. - 38861 codex: missing_verification_result. py_compile 실패값을 그대로 포함. - recent_bus_messages: “근거 섹션 미기재 — 결론 참고”는 line 33386, 33387, 33391, 33398, 33399, 33401, 33408, 33410, 33413, 33417 등 status=None/task_status 핸드오프에도 반복됨. 이는 완료제출 반려와 구분해야 한다.

정책상 핵심 수치: - agent_completion_submission_standard.md는 완료보고 4요소를 실행값, 출처, 검증값, 파일+라인+원문 인용으로 정의한다. - 같은 문서 §8은 증거 게이트가 status=done/complete/completed/success인 실제 완료제출에만 적용된다고 명시한다. - completion_evidence_policy.md v16은 analyst-macro “근거 섹션 미기재” 138건 중 최근 8건이 status=None/task_status였고, 7개 에이전트 확장 집계가 guardian 14, analyst-macro 132, cowork 538, analyst-fundamental 75, ron 554, analyst-technical 51, analyst-pm 8이라고 기록한다.

3. [에이전트별 반려를 부르는 완료보고 문구]

ron

반려를 부르는 문구: - “결과물과 검증 근거가 없음” - “missing_execution_value, missing_source, missing_verification_value…” - “검증 명령 누락” - “근거 섹션 미기재 — 결론 참고”를 실제 완료 근거처럼 재사용

왜 반려되는가: - 실제 실행 결과, 산출물 경로, 검증 명령, 원문 인용이 비어 있다. - task_status 핸드오프 문구와 canonical 완료제출을 섞어 판단하면 오탐이 난다.

다음 태스크 body에 넣을 문장: “ron은 status=done 제출 전에 반드시 실제 실행한 명령 1개, 그 출력 또는 exit code, 생성·확인한 실존 파일 경로, 파일:줄번호 원문 인용을 결론/근거/검증/근거파일 4줄에 각각 채운다. ‘결과물과 검증 근거가 없음’, ‘근거 섹션 미기재’, ‘결론 참고’는 완료보고 근거로 쓰지 않는다.”

수정 예시: 결론: 지식사랑방 인사이트 재처리를 실행해 산출물 1개를 생성했다. 근거: /Users/ron/knowledge-agent/400-reports/<실제파일>.md 생성, 조회 2026-09-15 14:56 KST. 검증: python3 <실제 실행 스크립트> → exit code 0, output_count=1. 근거파일: /Users/ron/knowledge-agent/400-reports/<실제파일>.md:1 “title: …”

cowork

반려를 부르는 문구: - “[권고] 1순위: ~를 구현한다”만 쓰고 완료 처리 - “즉시 수정한다”, “반영한다” 같은 미래형 문장 - 존재하지 않는 정책 산출물 경로를 근거파일로 기입 - 도메인 출력 형식만 쓰고 마지막 4블록을 생략

왜 반려되는가: - cowork는 설계·검토 역할이므로 코드 구현형 태스크는 done이 아니라 codex/ron 위임 또는 blocked/delegated가 맞다. - [권고]/[현황]/[리스크]/[검증방법]은 도메인 형식이고, 완료보고 4블록을 대체하지 않는다.

다음 태스크 body에 넣을 문장: “cowork는 제안서 형식 뒤에 별도 완료보고 4블록을 반드시 추가한다. 코드 구현·수정·패치·반영 태스크면 실제 코드를 고쳤다고 쓰지 말고, codex/ron 재위임 command id를 근거에 적고 status는 delegated 또는 blocked로 제출한다.”

수정 예시: 결론: 코드 수정 범위와 재발 원인을 정책 메모로 정리하고, 구현은 codex 재위임 대상으로 분리했다. 근거: config/agent_completion_submission_standard.md와 recent bus 사례 38861~38871 조회, 2026-09-15 14:56 KST. 검증: grep -n “반려 예시|수정 예시” /Users/ron/knowledge-agent/400-reports/260915_completion_evidence_recurrence_note.md → 각 문구 포함 확인. 근거파일: /Users/ron/knowledge-agent/400-reports/260915_completion_evidence_recurrence_note.md:1 “title: 완료보고 근거 누락 재발 방지 운영 메모”

codex

반려를 부르는 문구: - “<원본로그경로>” 같은 자리표시자 - “수정한 실제 파일”이라고 쓰지만 diff, grep, py_compile 결과가 없음 - 검증 명령은 있으나 실패값만 있고 완료로 제출 - 원본 출력 발췌가 잘렸고, 실제 변경 파일·라인·원문이 없음

왜 반려되는가: - codex는 코드 작성 에이전트이므로 diff/grep/py_compile/pytest 중 최소 하나의 실제 결과가 필요하다. - py_compile 실패(exit code 1)를 포함한 채 done이면 검증 결과 누락 또는 실패로 반려된다.

다음 태스크 body에 넣을 문장: “codex 완료보고는 자리표시자 금지. 결론에는 실제 수정 파일 수와 변경 대상을 쓰고, 근거에는 실존 파일 경로와 line quote, 검증에는 py_compile 또는 pytest의 exit code 0 및 pass 수를 적는다. 실패한 검증값이면 done 제출 금지.”

수정 예시: 결론: agent_queue_worker.py의 OAS 태스크 body 생성 문구를 실제 로컬 캐시 기준으로 수정했다. 근거: scripts/agent_queue_worker.py 1234~1248행 수정, 조회 2026-09-15 14:56 KST. 검증: python3 -m py_compile scripts/agent_queue_worker.py → exit code 0. 근거파일: scripts/agent_queue_worker.py:1240 “memory/macro-timeseries/BAMLC0A0CM.json 파일을 읽어 최신값 확인”

analyst-macro

반려를 부르는 문구: - 존재하지 않는 scripts/pipeline/macro_bridge.py, market_indicator.py, vault_macro_bridge.py 경로 - FRED 새 호출·라이브 조회를 한 것처럼 쓰거나 허구 수치와 과거 조회시각을 적음 - 검증 줄에 실존 워크스페이스 경로와 exit code가 없음

왜 반려되는가: - 실제 등록 경로는 scripts/pipeline/market_indicator_tracker.py이고, BAMLC0A0CM은 로컬 캐시 memory/macro-timeseries/BAMLC0A0CM.json를 읽어야 한다. - 정책은 검증 필드 값 안에 실행한 명령·경로·실제 결과값을 요구한다.

다음 태스크 body에 넣을 문장: “analyst-macro는 BAMLC0A0CM/OAS 작업에서 FRED를 새로 호출하지 말고 memory/macro-timeseries/BAMLC0A0CM.json 또는 scripts/pipeline/market_indicator_tracker.py의 실존 경로만 사용한다. 존재 확인 전 macro_bridge.py, market_indicator.py, vault_macro_bridge.py 같은 경로를 쓰지 않는다. 검증 줄에는 실행 명령, scripts/pipeline/market_indicator_tracker.py 또는 memory/macro-timeseries/BAMLC0A0CM.json 경로, exit code 0, 실제 stdout 값을 함께 적는다.”

수정 예시: 결론: 미국 투자등급 OAS는 로컬 BAMLC0A0CM 캐시 기준 최근 값 0.81로 보합이다. 근거: memory/macro-timeseries/BAMLC0A0CM.json 직접 파싱, 조회 2026-09-15 14:56 KST. 검증: python3 -c “import json; d=json.load(open('memory/macro-timeseries/BAMLC0A0CM.json')); print(d['data'][-1], d['last_updated'])” → exit code 0, {'date':'2026-09-09','value':0.81}. 근거파일: memory/macro-timeseries/BAMLC0A0CM.json:603 “\"value\": 0.81”

analyst-technical

반려를 부르는 문구: - scripts/scripts/pipeline처럼 중복된 경로 - vault_tech 등 존재 확인 안 된 스크립트명 - “확인 못함”, “확인할 수 없음”을 검증값처럼 제출

왜 반려되는가: - verification_command_path_not_found와 execution_artifact_path_not_found가 동시에 발생한다. - 기술 신호는 로컬 가격·기술지표 파일을 직접 파싱하거나 실존 collector를 확인해야 한다.

다음 태스크 body에 넣을 문장: “analyst-technical은 작업 전 search_files로 기술지표 스크립트와 로컬 데이터 파일의 실존 여부를 확인한다. 검증 줄에는 scripts/scripts 같은 중복 경로를 쓰지 말고, 실제 실행 명령과 exit code 0 및 RSI/MACD/가격 수치를 함께 적는다.”

수정 예시: 결론: 크레딧 ETF 기술 신호를 로컬 가격 파일 기준으로 재계산했다. 근거: memory/price-history/HYG.json 직접 파싱, 조회 2026-09-15 14:56 KST. 검증: python3 -c “import json; d=json.load(open('memory/price-history/HYG.json')); print(d['data'][-1])” → exit code 0, close 값 출력 확인. 근거파일: memory/price-history/HYG.json:<실제라인> “\"close\": …”

analyst-fundamental

반려를 부르는 문구: - 등록 도구가 없는 ETF·신용등급 조회를 완료했다고 서술 - 존재하지 않는 vault_credit_valuation.py 같은 경로 - exit code 0 리터럴 없음 - 2023년 같은 허구 조회시각

왜 반려되는가: - analyst-fundamental은 codex와 함께 엄격 확인 에이전트로 분류되어 검증값에 exit code 0이 필요하다. - 등록 도구가 지원하지 않는 데이터 유형이면 done이 아니라 blocked가 맞다.

다음 태스크 body에 넣을 문장: “analyst-fundamental은 검증 줄에 반드시 exit code 0을 문자 그대로 포함한다. 등록 도구로 조회할 수 없는 ETF·신용등급·채권 스프레드는 존재하지 않는 스크립트를 만들지 말고 blocked로 제출하며, 근거에 ‘등록 도구 부재’와 실제 확인한 테이블·파일 0건을 적는다.”

수정 예시: 결론: LQD는 analyst-fundamental 등록 도구로 조회 불가 — ETF 데이터 소스 부재 확인. 근거: company_entities 테이블 조회, 2026-09-15 14:56 KST, LQD 0건. 검증: sqlite3 /Users/ron/.hermes/data/ops_multiagent.db “SELECT ticker FROM company_entities WHERE ticker='LQD'” → 0건, exit code 0. 근거파일: scripts/pipeline/vault_fundamental_bridge.py:246 “SELECT id, canonical_name, name_ko, ticker, exchange, category”

guardian

반려를 부르는 문구: - completion_evidence_blocked.jsonl 같은 게이트 반려 로그를 점검 산출물 근거로 사용 - “정상 확인함”, “이상 없음” 단독 서술 - 실제 헬스체크 대상 로그·프로세스·DB 수치 없음

왜 반려되는가: - guardian은 시스템 점검 산출물을 다뤄야 하며, 반려 로그 자기참조는 점검 근거가 아니다.

다음 태스크 body에 넣을 문장: “guardian은 근거파일에 completion_evidence_blocked.jsonl을 쓰지 않는다. DB 응답시간, cron 상태 건수, 프로세스 수, gateway 로그 등 실제 점검 대상의 수치 2개 이상을 근거에 넣고, 검증 줄에는 실행 명령과 exit code 또는 반환 수치를 적는다.”

수정 예시: 결론: DB·cron·gateway 3개 항목 점검 결과 이상 1건을 확인했다. 근거: ops_multiagent.db 응답 12ms, cron success 142/error 3, gateway 프로세스 1개, 조회 2026-09-15 14:56 KST. 검증: python3 scripts/health_check.py --brief --cron-check → exit code 0, failed_jobs=3. 근거파일: /Users/ron/.hermes/logs/gateway.log:<마지막라인> “<실제 원문>”

4. [다음 태스크 body 공통 삽입문]

아래 문장을 모든 재시도 태스크 body 끝에 붙인다.

완료보고 필수 형식: 도메인 출력 형식과 별개로 result_note 끝에 아래 4줄을 독립 줄로 작성한다. 결론: 실제로 실행·확인·작성한 일을 완료형 한 줄로 쓴다. “~할 예정”, “~하도록 지시”, “내부 상태 업데이트됨” 금지. 근거: 실존 파일·DB·로그·API 소스와 조회 시각 YYYY-MM-DD HH:MM KST, 그리고 핵심 수치 1개 이상을 쓴다. “근거 섹션 미기재”, “결론 참고”, “결과물과 검증 근거가 없음” 금지. 검증: 실제 실행한 명령 1줄과 결과값(exit code, stdout 요약, pass 수, 조회 건수)을 함께 쓴다. 검증을 못 했으면 done 제출 금지. 근거파일: 워크스페이스 안 실존 경로:줄번호 “원문 인용 1줄”을 쓴다. 존재 확인 전 경로를 지어내지 않는다. 주의: status=None/task_status 핸드오프에 붙은 “근거 섹션 미기재”는 완료보고 위반으로 지목하지 말고, bus_commands의 canonical status/result_note를 먼저 조회한다.

5. [리스크]

구조적 위험 1: 정책 문서만 갱신되고 실제 태스크 body에 문장이 배선되지 않으면 v1~v16에서 반복된 “문서는 있는데 아무도 안 읽는” 상태가 재발한다. 원인: 에이전트는 매번 정책 전문을 읽지 않고 task body와 시스템 프롬프트에 강하게 의존한다.

구조적 위험 2: status=None/task_status 핸드오프를 완료제출 반려로 오인하면, 실제 문제와 무관한 태스크가 다시 생성된다. 원인: recent_bus_messages에는 placeholder가 자주 보이지만, 정책상 4블록 게이트는 canonical 완료제출에만 적용된다.

구조적 위험 3: 존재하지 않는 경로를 형식 맞추기 위해 지어내는 문제가 계속된다. 원인: 검증 경로를 요구하지만, 태스크 body가 정확한 실존 진입점을 주지 않으면 LLM이 추측 경로를 만든다.

단일 장애점: orchestrator가 다음 태스크 body에 에이전트별 금지·대체 문장을 주입하지 않으면 analyst-macro, analyst-technical, codex, ron이 서로 다른 이유로 같은 missing_* 반려를 반복한다.

6. [검증방법]

KPI 1: 작성 후 72시간 동안 bus_commands.result_note LIKE '%missing_%' 반려 건수를 에이전트별로 집계한다. 목표는 7일 내 50% 감소다. 검증 명령: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT claimed_by, COUNT(*) FROM bus_commands WHERE result_note LIKE '%missing_%' AND datetime(created_at) >= datetime('now','-3 day') GROUP BY claimed_by ORDER BY 2 DESC;" 기대값: 같은 에이전트의 동일 라벨 3회 연속 재발 0건. 롤백 조건: 같은 라벨이 같은 에이전트에서 3회 연속 재발하면 문서 문제가 아니라 태스크 body 배선 또는 게이트 코드 문제로 격상한다.

KPI 2: analyst-macro에서 market_indicator.py, macro_bridge.py, vault_macro_bridge.py 미존재 경로 반려가 0건이어야 한다. 검증 명령: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT id,title,result_note FROM bus_commands WHERE claimed_by='analyst-macro' AND status='failed' AND (result_note LIKE '%market_indicator.py%' OR result_note LIKE '%macro_bridge.py%' OR result_note LIKE '%vault_macro_bridge.py%') AND datetime(created_at) >= datetime('now','-3 day');" 기대값: 0건. 롤백 조건: 1건 이상이면 analyst-macro body에 실존 경로 문장이 배선되지 않은 것이다.

KPI 3: status=None/task_status 핸드오프를 완료보고 위반으로 지목한 후속 태스크가 0건이어야 한다. 검증 명령: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT id,title FROM bus_commands WHERE (title LIKE '%근거누락%' OR title LIKE '%위반%') AND datetime(created_at) >= datetime('now','-3 day');" 기대값: 지목된 모든 건이 canonical 완료제출(status done/failed 전이 시도)에 대한 것이어야 한다. 롤백 조건: status=None/task_status만 근거로 지목한 태스크가 나오면 §8-1 절차를 body에 더 강하게 삽입한다.

7. 완료보고 4블록

결론: 재발 방지 핵심은 3개다 — 첫째, 4블록은 도메인 출력과 별개로 끝에 독립 줄로 써야 한다. 둘째, “근거 섹션 미기재/결과물과 검증 근거 없음/missing_*”는 근거가 아니라 반려 사유라서 완료보고에 재사용하면 안 된다. 셋째, 에이전트별 실존 경로와 금지 문구를 다음 태스크 body에 직접 넣어야 한다. 근거: config/agent_completion_submission_standard.md, config/completion_evidence_policy.md, /Users/ron/.hermes/data/ops_multiagent.db bus_commands 최근 반려 38861~38871, /Users/ron/.hermes/workspace/bus/messages.jsonl lines 33386~33422 조회 2026-09-15 14:56 KST. 검증: 산출물 본문에 “반려를 부르는 문구”와 “수정 예시”가 ron/cowork/codex/analyst-macro/analyst-technical/analyst-fundamental/guardian 7개 항목 모두에 포함됐는지 확인한다. grep -n “반려를 부르는 문구|수정 예시” /Users/ron/knowledge-agent/400-reports/260915_completion_evidence_recurrence_note.md → 반려 예시와 수정 예시 모두 포함 기대. 근거파일: /Users/ron/knowledge-agent/400-reports/260915_completion_evidence_recurrence_note.md:1 “title: 완료보고 근거 누락 재발 방지 운영 메모”