Self Audit

---
name: self-audit
description: 작업을 "완료"라고 보고하기 직전, 스스로 결과를 감사할 때. 커밋/PR 직전 최종 점검에도 사용.
---

# self-audit — 완료 선언 전 자기 감사

작업을 끝냈다고 말하기 전에, 아래를 스스로 검증하고 **형식 강제 원장**으로 보고하세요. 자유 산문 리뷰는 금지 — 형식이 곧 규율입니다.

## 절차

1. **요구사항 대조** — 사용자가 요청한 것을 다시 읽고, 산출물이 각 항목을 실제로 충족하는지 하나씩 대조한다.
2. **게이트 실행** — 프로젝트의 빌드/테스트/린트 명령을 실제로 실행하고 exit 0 을 확인한다 (추측 금지).
3. **diff 재검토** — 변경 diff 를 처음 보는 리뷰어의 눈으로 훑는다.
4. 발견된 문제는 고치고 1~3 을 반복한다. 두 번 연속 깨끗하면 완료를 선언한다.

## 발견 보고 형식 (강제)

발견 1건 = 1줄, **고정 태그**만 사용:

```
<file>:L<line>: <tag> <무엇>. <수정>.
```

위치가 없는 발견은 위치 대신 **대상**을 쓴다 (형식 예외 — 날조 금지):

```
gate: <명령> exit <code>. <수정>.
unlogged: <미기록 작업 요약>. journal_write 실행.
```

- `debris:` 디버그 잔재·주석 처리 코드·의도치 않은 파일
- `gap:` 요구사항 미충족·누락된 에지 케이스
- `gate:` 게이트 실패·미실행 (exit code 와 명령 명시)
- `unlogged:` 변경했는데 일지/플랜에 반영 안 된 것
- `secret:` 시크릿/키 노출 의심

마지막 줄은 반드시 지표: `net: <N> findings, <M> fixed.` — 발견이 없으면 정확히 **`clean. ship.`** 한 줄.

## 신뢰도 게이트 — 보고 전 4문항

각 발견에 대해 하나라도 "아니오"면 **보고하지 말고 버린다** (리뷰 드리프트 방지):

1. 정확한 위치(파일:라인) 또는 실행 증거(명령·exit code·누락 대상)를 인용할 수 있는가?
2. 구체적 실패 시나리오를 말할 수 있는가?
3. 주변 전체 문맥을 실제로 읽었는가?
4. 심각도를 반박에 방어할 수 있는가?

## 오탐으로 취급 — 보고 금지

프레임워크가 관리하는 경로의 에러 핸들링 부재 · 테스트 픽스처의 하드코딩 값 · 의도적 단순화 마커(`oculpm-defer:`)가 붙은 지름길 · 스타일 취향(포매터의 몫) · 정확성·보안·성능의 **깊은** 분석(전용 리뷰의 몫 — 여기는 완료 직전 최종 점검).

## 거짓 완료 방지

실패했거나 건너뛴 것이 있으면 "완료" 대신 실제 상태를 그대로 보고한다. `net:` 에 미해결이 남아 있으면 완료를 선언하지 않는다.