harness-promote-rulelisted

# Harness Promote Rule > PDF 10쪽: *"인간의 취향은 시스템에 지속적으로 피드백됩니다. 리뷰 코멘트, > 리팩터링 pull request, 사용자 측 버그는 문서화 업데이트로 기록되거나 > 툴링에 직접 인코딩됩니다. **문서화가 부족한 경우 규칙을 코드로 승격합니다.**"* 하네스 엔지니어링의 *진화 루프*. 1~4차원 방어가 기존 룰을 지키는 일이라면, 이 스킬은 **새 룰을 만드는 일**이다. ## 언제 invoke 하는가 (트리거) 1. **반복 신호** — 같은 유형의 결함·리뷰 지적·경계 위반이 2회 이상 2. **사용자 명령** — "이거 룰로 박아", "R 룰로 올려", "promote-to-rule" 3. **시스템 신호** — `weekly-doc-gardening` 워크플로가 `[rule-candidate]` 라벨의 Issue 를 생성 4. **대형 커밋 직전** — 도메인 불변 조건이 새로 발견됐는데 아직 강제 장치가 없을 때 ## 언제 invoke 하지 *않는가* - **일회성 버그** — 한 번 난 실수는 룰이 아니다. 고치고 넘어가라. - **개인 취향** — "이렇게 하는 게 더 예뻐" 는 R 룰이 아니다. 팀 합의가 있어야 한다. - **프레임워크 기본 규칙** — ESLint / ruff / prettier 가 이미 잡는 것은 거기서 끝낸다. - **PDF 11쪽 경계 밖** — 다른 프로젝트에도 쓰일 것 같으면 ai-dev-setting 의 `assets/rules/harness/examples/` 를 고려하지, 현재 프로젝트 `core-beliefs.md` 에 박지 않는다. ## 승격 절차 (6단계) ### 1. 패턴 요약 무엇이 반복됐는가? 3문장 이내로 요약: - **증상**: 어떤 코드가 어떻게 잘못 작성됐는가 - **근본 원인**: 에이전트/사람이 이걸 왜 놓쳤는가 (*문서화 부족? 경계 불명확? 유혹?*) - **영향**: 지금까지 발생한 피해 — 버그 티켓 번호, 프로덕션 사고, 시간 낭비 ### 2. R 번호 할당 `docs/design-docs/core-beliefs.md` 의 마지막 R 번호 다음을 할당. 예: 기존 R1~R6 → 이번은 R7. ### 3. `core-beliefs.md` 에 R 룰 추가 아래 양식을 따른다 — rim-kanban 의 실제 형식: ```markdown ## R7: 시간 컬럼은 반드시 TIMESTAMPTZ ### 불변 조건 모든 PostgreSQL 시간 컬럼은 `TIMESTAMPTZ` 로 선언한다. `TIMESTAMP WITHOUT TIME ZONE` 금지. ### 근거 - 2026-03-XX 사건: 배포 시 서버 TZ 변경으로 주문 타임스탬프가 9시간 밀림 - 수정 PR: #142 (마이그레이션 0031_fix_tz.sql) ### 강제 장치 - `tests/test_r7_tz.py` — 모든 `Column(DateTime)` 이 `timezone=True` 인지 단언 - `scripts/lint/