virtual-insanity
← 리포트 목록

완료보고 근거누락 방지 운영안

완료보고 근거누락 방지 운영안

핵심 결론

완료보고 반려는 대체로 일을 안 해서가 아니라, 완료문에 증거가 게이트가 읽는 형태로 남지 않아서 생긴다. 모든 에이전트는 도메인별 보고 형식과 별개로 마지막에 아래 4줄을 독립 줄로 다시 써야 한다.

결론: <무엇을 실행/확인/작성/수정했는지 완료형 한 줄>
근거: <직접 읽은 파일/DB/API/로그> + <조회 YYYY-MM-DD HH:MM KST>
검증: <실행한 검증 명령 또는 계산> → <실제 결과값/건수/exit code>
근거파일: <실존 경로>:<줄번호> "<원문 일부>"

나쁜 예

  1. 제안형으로 끝내기
  2. 나쁨: 1순위: scripts/foo.py에 검증 로직을 추가한다.
  3. 이유: 실제 수정, 위임, 검증 결과가 없다. 코드 작성 금지 에이전트가 이런 문장으로 done을 내면 반복 반려된다.

  4. placeholder 그대로 쓰기

  5. 나쁨: 근거: 근거 섹션 미기재 — 결론 참고.
  6. 이유: 정책 문서에서 자기지시형 placeholder로 금지되어 있고, 게이트가 바로 차단한다.

  7. 존재하지 않는 경로 쓰기

  8. 나쁨: 검증: python3 scripts/pipeline/market_indicator.py 실행 → 성공
  9. 이유: 실제 파일명은 market_indicator_tracker.py 계열처럼 먼저 확인해야 한다. 없는 경로는 안 쓰는 것보다 더 나쁘다.

  10. 실행 계획을 실행 결과처럼 쓰기

  11. 나쁨: 다음 명령을 실행하면 확인 가능: python3 -c ...
  12. 이유: 검증은 앞으로 실행할 명령이 아니라 이미 실행한 명령과 실제 출력이다.

  13. 반려 로그를 근거파일로 쓰기

  14. 나쁨: 근거파일: logs/completion_evidence_blocked.jsonl
  15. 이유: guardian류 점검에서는 게이트 반려 로그가 아니라 실제 점검 대상 로그, DB, 프로세스 결과를 써야 한다.

좋은 예

결론: 미국 IG 스프레드 로컬 캐시를 읽어 최근 값 0.81 보합을 확인했다.
근거: memory/macro-timeseries/BAMLC0A0CM.json 직접 파싱, 조회 2026-09-17 06:22 KST
검증: python3 -c "import json; d=json.load(open('memory/macro-timeseries/BAMLC0A0CM.json')); print(d['data'][-1])" → {'date': '2026-09-09', 'value': 0.81}, exit code 0
근거파일: memory/macro-timeseries/BAMLC0A0CM.json:603 "\"date\": \"2026-09-09\", \"value\": 0.81"
결론: 헬스체크를 실행해 런타임·크론·DB 상태를 점검했다.
근거: source_log_path: /Users/ron/.hermes/logs/health_check_20260917.log, 조회 2026-09-17 06:22 KST
검증: verification_command: python3 scripts/health_check.py --brief --cron-check → exit 0, 실패 0건
근거파일: /Users/ron/.hermes/logs/health_check_20260917.log:12 "cron_ok=True, db_ok=True, failures=0"

에이전트별 최소 근거 기준

analyst 계열

  • 최소 기준: 데이터 소스명, 티커·시리즈명, 조회시각, 전후 수치, 실제 계산 명령 또는 로컬 파일 파싱 결과.
  • analyst-macro: market_indicator_tracker.py나 memory/macro-timeseries/*.json처럼 실존 경로를 먼저 확인한다. market_indicator.py처럼 기억으로 파일명을 만들지 않는다.
  • analyst-fundamental: 검증 줄에 exit code 0 리터럴이 필요하다. 등록 도구가 지원하지 않는 ETF·신용등급은 허구 스크립트를 만들지 말고 blocked로 낸다.
  • analyst-technical: 가격·기술지표 파일의 실제 값과 라인 또는 저장 로그를 인용한다.
  • analyst-pm: macro·technical·fundamental 소스 각각의 최신 시각과 종합 판단 수치를 함께 쓴다.

guardian

  • 최소 기준: 점검 대상, 실행 명령, 실패·성공 건수, 실제 점검 로그 또는 DB 원문.
  • 금지: completion_evidence_blocked.jsonl 같은 반려 로그를 점검 근거로 쓰기.
  • 좋은 근거: gateway 로그, health_check 출력, bus 큐 건수, 워커 응답 수, 디스크·프로세스 상태.

ron

  • 최소 기준: run-cycle·헬스체크·대행 결과의 실행 로그, 검증 명령, exit code/stdout 요약, 산출물 경로.
  • 대행이면 근거:에 원래 대상 에이전트와 대행 사실을 쓰되, 재라우팅 사유만으로는 근거가 아니다.
  • 실패 보고도 4블록이 필요하다. needs_evidence, 결과 확인 보류만 쓰면 다시 반려된다.

cowork

  • 최소 기준: 설계·정책 검토는 읽은 정책 파일, DB 조회 결과, 최근 사례 번호, 검증 명령을 쓴다.
  • 코드 구현·패치 지시를 받으면 직접 구현 완료처럼 쓰지 않는다. codex나 ron에 재위임한 커맨드 번호를 근거로 쓰거나 blocked/delegated로 낸다.

최근 사례 요약

최근 버스 조회 시점: 2026-09-17 06:22 KST.

  • 39085 analyst-macro: missing_verification_command, missing_verification_exit_code. 원본 요약에 2023년 조회시각과 잘린 명령이 들어가 검증값으로 인정되지 않았다.

  • 39083 analyst-macro: 위와 같은 계열. 로컬 데이터 판단인데 실제 실행 결과와 exit code가 빠졌다.

  • 39081 ron 헬스 체크: missing_verification_result. 실행했더라도 검증 결과값을 별도 줄로 남기지 않아 반려됐다.

  • 39080 ron run-cycle: missing_execution_artifact, missing_verification_command, missing_verification_exit_code. 결과 JSON 요약은 있었지만 산출물 경로와 재현 가능한 검증 명령이 부족했다.

  • 39077 ron 지식사랑방 재작성: 실행값, 출처, 검증값, 원문 확인이 전부 부족한 전형적 4블록 누락 사례다.

  • 39082/#39084 codex: 검증 명령은 있었지만 py_compile 결과가 실패로 저장되어 완료 증거가 되지 않았다.

운영 규칙

  1. 완료문 맨 끝에 4블록을 다시 쓴다. 제안서 형식, 분석 형식, 보고서 형식과 별개다.
  2. 경로는 쓰기 전에 실존 확인한다. 모르면 먼저 찾고, 못 찾으면 blocked로 낸다.
  3. 검증 줄에는 명령과 결과를 같이 쓴다. 확인함, 성공, 정상 단독 금지.
  4. 숫자는 실제 출력에서 가져온다. 날짜·수치·파일명을 지어내지 않는다.
  5. status 메시지의 근거 섹션 미기재는 완료제출 위반으로 단정하지 않는다. canonical bus_commands의 status/result_note를 먼저 확인한다.
  6. 같은 missing 라벨이 3회 재발하면 4블록 재작성 반복 대신 게이트 코드나 라우팅 배선 문제로 격상한다.

검증방법

  • KPI 1: 72시간 내 missing_verification_command, missing_verification_exit_code, missing_execution_artifact 재발 건수.
  • KPI 2: analyst-macro가 존재하지 않는 market_indicator.py를 다시 인용하는 건수.
  • KPI 3: ron run-cycle·헬스체크 실패 보고에서 exit code/stdout 요약 누락 건수.
  • 기대값: 동일 라벨 3연속 재발 0건. guardian·analyst-macro의 missing 계열 반려율은 7일 내 절반 이하.

검증 명령 예시:

sqlite3 /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;"

근거 문서

  • /Users/ron/.hermes/workspace/config/agent_completion_submission_standard.md:76-103 "완료 보고 result_note는 아래 4블록을 이 순서 그대로"
  • /Users/ron/.hermes/workspace/config/agent_completion_submission_standard.md:157-170 "반려 라벨: missing_execution_value, missing_source, missing_verification_value 등"
  • /Users/ron/.hermes/workspace/config/agent_completion_submission_standard.md:365-505 "analyst-*/guardian 계열 전용 4블록 강제 요건과 예시"
  • /Users/ron/.hermes/workspace/config/completion_evidence_policy.md:14-28 "4대 근거: 실행값, 출처, 검증값, 파일+라인+원문 인용"
  • /Users/ron/.hermes/workspace/config/completion_evidence_policy.md:398-496 "ron 반복 반려와 run-cycle·헬스체크 실패 경로 재검증"
  • /Users/ron/.hermes/workspace/config/completion_evidence_policy.md:1871-1940 "status 메시지와 완료제출 스코프 구분"

완료보고용 4블록

결론: 완료보고 근거누락 재발 방지 운영안을 작성했고, 핵심은 모든 완료제출 끝에 결론·근거·검증·근거파일 4블록을 독립 줄로 붙이는 것이다. 근거: config/agent_completion_submission_standard.md, config/completion_evidence_policy.md, ops_multiagent.db 최근 반려 사례 #39077~#39085 조회 2026-09-17 06:22 KST 검증: test -f /Users/ron/knowledge-agent/400-reports/completion-evidence-recurrence-2026-09-17.md && grep -E "^결론:|^근거:|^검증:|^근거파일:" /Users/ron/knowledge-agent/400-reports/completion-evidence-recurrence-2026-09-17.md → 필수 4블록 라벨 포함 확인 대상 근거파일: /Users/ron/knowledge-agent/400-reports/completion-evidence-recurrence-2026-09-17.md:122 "결론: 완료보고 근거누락 재발 방지 운영안을 작성했고, 핵심은 모든 완료제출 끝에 결론·근거·검증·근거파일 4블록을 독립 줄로 붙이는 것이다."