self-auditlisted

# 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:` 에 미해결이 남아 있으면 완료를 선언하지 않는다.