점검표

개요

이 체크리스트는 현재 프로젝트가 AI 작업자를 하네스 안에 넣을 준비가 되어 있는지 빠르게 점검하기 위한 것이다.

답이 아니오인 항목이 많을수록, 문제는 모델 품질보다 AI 작업자 하네스 준비 부족일 가능성이 크다.

이 체크리스트는 transition의 진단이 아니라 harness/ai 적용 준비 상태를 빠르게 확인하기 위한 것이다.

각 항목의 상세는 capability boundaries, task contracts, acceptance gates, canonical examples, feedback loop, auto-correction loop, pre-commit hooks, machine-readable failures, trace and observability를 보면 된다. 용어 기준은 용어집, 실제 강제 지점은 실행 통제를 함께 보면 된다.

1. capability boundary ^{권한 경계}

• write scope가 task와 무관한 파일까지 열려 있지 않은가
• 위험 명령과 안전 명령이 같은 층에 있지 않은가
• destructive / external side effect가 별도 승인 경계를 가지는가
• 권한 경계가 문서가 아니라 실제 시스템에서 강제되는가

2. task contract ^{작업 계약}

• 수정 가능한 범위가 명시되어 있는가
• 금지 표면과 canonical path가 같이 보이는가
• 어떤 check를 통과해야 완료인지 분명한가
• unrelated refactor를 막는 조건이 있는가

3. acceptance gates ^{완료 게이트}

• 완료 조건이 command나 rule로 표현되는가
• gate가 task 범위와 직접 정렬되는가
• flaky하거나 너무 큰 gate가 종료 조건을 흐리지 않는가
• 같은 gate를 loop 안에서 반복 확인할 수 있는가

4. canonical examples ^{정본 예시}

• 가장 자주 참고되는 예시가 실제 canonical path를 쓰는가
• fixture, scaffold, starter가 bypass를 정본처럼 보여주지 않는가
• deprecated / exception code가 더 가까운 reference surface에 남아 있지 않은가
• rule 변경 시 canonical example도 같이 갱신되는가

5. feedback loop ^{피드백 루프}

• 가장 자주 깨지는 규칙이 가까운 local loop에서 잡히는가
• failure가 범위를 좁혀주는가
• warning만 있고 실제 교정은 뒤로 밀리지 않는가
• canonical path가 같은 signal 안에서 제시되는가

6. auto-correction loop ^{자동 교정}

• retry budget이 명시되어 있는가
• 매 반복마다 같은 narrow gate를 다시 돌리는가
• task boundary 밖으로 범위가 퍼지지 않는가
• 같은 failure가 반복되면 멈추고 사람에게 넘기는가

7. pre-commit and local gates ^{로컬 게이트}

• pre-commit 훅이 로컬에서 반복하기 충분히 싼가
• changed scope와 너무 멀리 떨어진 검사를 하지 않는가
• 빠르고 결정적인 static rule이 앞쪽에 배치되어 있는가
• CI에서만 잡히는 규칙 중 앞당길 수 있는 것이 있는가

8. machine-readable failures ^{기계 판독 실패}

• stable rule id가 존재하는가
• file / line / symbol 위치가 정확한가
• 허용되는 대안이 failure와 함께 보이는가
• lint, pre-commit, runtime에서 같은 규칙 명칭을 공유하는가

9. trace and observability ^{추적과 관찰성}

• 같은 failure를 stable rule bucket으로 묶을 수 있는가
• retry budget 소진과 stop reason을 볼 수 있는가
• 어떤 gate가 가장 자주 실패를 일으키는지 보이는가
• 관찰 결과가 rule, gate, failure format 개선으로 연결되는가

10. AI coding stress test ^{운영 점검}

• AI가 가장 자주 건드리는 표면에 가까운 gate가 있는가
• AI가 failure를 보고 local fix로 수렴할 수 있는가
• vague한 failure 때문에 broad refactor가 유도되지 않는가
• 같은 우회가 반복될 때 운영 루프를 먼저 점검하는가

요약

좋은 AI 작업자 하네스는 다음을 만족한다.

• capability boundary가 행동 반경을 먼저 줄이고
• task contract가 작업 범위를 고정하고
• acceptance gate가 종료 조건을 닫고
• canonical example이 합법 경로를 더 가까운 reference로 만들고
• 가까운 feedback loop가 있으며
• bounded auto-correction이 가능하고
• local gate가 싸고 안정적이며
• failure format이 machine-readable하고 해석 가능하고
• trace가 반복 실패를 구조 개선으로 환류시킨다

이 항목들이 약하다면, AI는 규칙을 존중하기보다 가장 가까운 shortcut을 계속 학습하게 된다.