검증근거 양식 운영 적용 누락 점검안

확인 근거

• 확인 대상: bus_commands #37600 이후 최근 구간, #37631 결과, 현재 에이전트 상태 문구.
• 최근 구간 상태: 총 13건 중 done 3건, failed 6건, cancelled 3건, claimed 1건.
• missing_original_verification 포함 실패: 3건. ron 2건(#37622, #37625), cowork 1건(#37628).
• 근거 섹션 미기재 문구 자체는 최근 bus_commands result_note에서 0건. 다만 코드 게이트에는 하드블록 문구로 등록돼 있고, 과거 guardian 로그에는 placeholder 사례가 존재한다.

• 37631은 done이지만 result_note가 342자로 잘려 저장되어 에이전트별 필수 항목과 불합격 예시가 실제 결과문에 충분히 남지 않았다. 따라서 운영 기준으로는 “형식 의도는 있음, 적용 근거는 불충분”으로 판정한다.

새 최소 근거 양식

모든 에이전트 결과문은 아래 3칸을 반드시 포함한다.

1. 결론
2. 무엇을 처리했는지, 성공·실패·보류 중 하나를 한 문장으로 쓴다.

3. 실패면 실패 원인을 결론에 숨기지 않는다.

4. 근거

5. 원천: 무엇을 확인했는지. 예: 명령 실행 결과, 원문 파일, 데이터 소스, 로그, 큐 번호.
6. 숫자: 건수, 비율, 전후 변화, 실행 시각 중 최소 1개.
7. 검증값: 실제로 나온 값 또는 상태. 예: 출구값 0, 응답 200, 저장 파일 존재, 행 수.

8. 위치: 산출물 파일명, 큐 번호, 로그명 중 최소 1개.

9. 다음 행동

10. 추가 조치 없음, 재처리, 담당 에이전트, 보류 사유 중 하나를 명시한다.

누락 판정 기준

아래 중 하나라도 해당하면 done으로 받아들이지 않고 보류 문구로 보정한다.

1. 근거 칸이 없거나 “근거 없음”, “근거 섹션 미기재”, “확인하지 않음”처럼 placeholder로 채워진 경우.
2. 실행 결과가 없고 계획·의도·예상만 있는 경우.
3. 검증값이 없는 경우. 예: 성공했다는 말은 있으나 출구값, 응답값, 행 수, 저장 여부가 없음.
4. 원천이 없는 경우. 예: 원문·로그·데이터·큐 번호 없이 판단만 있음.
5. 숫자가 없는 경우. 특히 상태 점검·리포트·시장 판단은 건수 또는 비율이 없으면 누락.
6. 파일명·큐 번호·로그명 등 추적 위치가 없는 경우.

7. 37631처럼 “운영 문서 작성”을 결론으로 말했지만 실제 문서 위치나 예시가 잘려 결과문에 남지 않은 경우.

8. blocked: not in whitelist는 정상 보안 차단이다. 이 문구 자체는 사고가 아니며, 차단 사실·시도 건수·대체 검증 여부를 근거에 남기면 합격이다.

보정 문구

누락 시 결과문은 아래 문구로 통일한다.

결론: needs_evidence: 결과 확인 보류 근거: 산출물·검증값 부족으로 done 저장 보류. 누락: [원천 없음/검증값 없음/숫자 없음/저장 위치 없음/근거 섹션 미기재 중 해당 항목]. 확인된 값: [있으면 숫자와 큐 번호, 없으면 “확인값 없음”]. 다음 행동: 실제 결과물·검증값 확인 후 재처리. 담당: [에이전트명].

예시

예시 1: ron 상태 메시지 합격

결론: #37631 검증근거 기준 정리 재점검 완료, 운영 문서 1건 작성. 근거: bus_commands #37631과 #37632 확인. #37600 이후 13건 중 missing_original_verification 3건, ron 2건·cowork 1건. 작성 위치: 260901_hermes_evidence_format_ops_application.md. 다음 행동: 추가 조치 없음.

예시 2: ron 상태 메시지 불합격

결론: #37631 검증 처리됨. 근거: #37631 검증 처리됨. 다음 행동: 추가 조치 없음. 판정: 근거가 결론 반복이라 불합격. 원천, 숫자, 검증값, 위치가 없음. 보정: 결론: needs_evidence: 결과 확인 보류 / 근거: 산출물·검증값 부족으로 done 저장 보류. 누락: 검증값 없음, 숫자 없음, 저장 위치 없음. 확인된 값: #37631 done이나 결과 342자로 절단. / 다음 행동: 실제 운영 문서 위치와 예시 확인 후 재처리. 담당: ron.

예시 3: analyst 결과 합격

결론: 화요일 장전 시장공통 변화 재작성 완료, 시장 판단 5줄 생성. 근거: 지수·금리·환율·원자재·신용·변동성 6개 축 확인. 기준시각 2026-09-01 05:00, 전일 대비 수치 6개 포함, 저장 파일 1건 확인. 다음 행동: market용 발송 또는 추가 조치 없음.

예시 4: analyst 결과 불합격

결론: 시장공통 변화 점검 완료. 근거: 최신 데이터 확인. 다음 행동: 추가 조치 없음. 판정: 수치, 기준시각, 데이터 출처, 저장 위치가 없어 불합격. 보정: 결론: needs_evidence: 결과 확인 보류 / 근거: 산출물·검증값 부족으로 done 저장 보류. 누락: 숫자 없음, 원천 없음, 검증값 없음. 확인된 값: 확인값 없음. / 다음 행동: 실제 데이터 소스와 기준시각 확인 후 재처리. 담당: analyst-macro.

예시 5: guardian 결과 합격

결론: 헬스 체크 완료, 게이트웨이와 큐 상태 정상. 근거: 에이전트 상태 10개 확인, 살아있는 에이전트 8개, 오프라인 2개. 큐는 claimed 1건, failed 6건, done 3건. 확인 시각 2026-09-01 05:27. 다음 행동: 오프라인 2개는 별도 복구 필요 여부만 감시.

예시 6: codex/cowork 차단 합격

결론: 코드 변경 없이 보안 차단 상태 확인, 작업은 보류. 근거: 실행 시도 3건 중 3건이 blocked: not in whitelist로 차단, 차단율 100%. 이 문구는 정상 보안 차단으로 분류. 실제 파일 변경 0건. 다음 행동: 허용된 실행 경로로 재검증하거나 ron에 재라우팅.

운영 적용안

• 결과문 검토자는 “결론이 맞는가”보다 먼저 근거 4요소(원천, 숫자, 검증값, 위치)를 본다.
• 4요소 중 1개라도 비면 done 금지, 위 보정 문구로 needs_evidence 처리한다.

• 37631 같은 문서형 작업은 “문서 작성”이 아니라 문서 위치, 예시 개수, 누락 판정 기준 존재가 확인돼야 합격이다.

• idle 상태는 예외적으로 결론·근거·다음 행동이 모두 “작업 대기중” 또는 “idle”이면 합격이다.
• blocked whitelist는 실패 원인으로 쓰되 보안 사고로 확대하지 않는다.