6.9 KiB
| name | description |
|---|---|
| bt-commit-rules | BurningTimes 조직 commit·push·main 병합 규칙. git 변경 사항 commit 직전·push 작업·main 브랜치 병합·force push·tag release 시 자동 로드. 키워드 — commit·push·main·merge·branch·git·rebase·force push·rollback·tag·release·병합·푸시·커밋. C18 조직 공유 완료 판정 + C19 승인 범위 엄격 해석 + C20 팀장 재량 + C28 문서 수정 무승인 + C30 git 동기화 작업 전 점검. |
BurningTimes Commit·Push 규칙 (L2)
본 SKILL = git commit·push·main 병합 작업 시 자동 로드. L1
bt-foundation헌법급 동시 적용.
C18. 조직 공유 완료 판정 — main push 완료
단일 세션 전환(2026-04-16)으로 "대상 세션 도달" 개념 소멸. main 브랜치 push(병합) 완료 시점 = "조직 공유 완료".
C18-1. 단계별 상태 정의 (혼동 금지)
| 상태 | 의미 | "조직 공유 완료"? |
|---|---|---|
| 로컬 커밋 | 작업자 로컬에만 존재 | ❌ |
| 원격 push (작업 브랜치) | 원격 저장소의 작업 브랜치 반영 | ❌ |
| main 병합 + push | main 브랜치 merge·push 완료 |
✅ 완료 |
C18-2. 판정 절차
git ls-remote origin refs/heads/main으로 원격 main HEAD 확인- 해당 HEAD에 조직 공용 산출물 포함 여부 확인
- 불확실 시 "push 완료 (main 병합 미확인)"으로 단계별 보고 (완료 단언 금지)
허용 / 금지 표현
- ✅ "main push 완료 — 조직 공유 완료"
- ❌ "동기화 완료" (main 미반영 상태)
C19. 승인 범위 엄격 해석 원칙
PD 승인 표현은 명시적으로 언급된 안건의 범위 내로 해석. 추정·확대·암묵 승인 금지.
C19-1. 해석 규칙
- 자구 그대로 범위 추출. "X는 승인" = X만 승인. 나머지는 별건
- 복수 안건 응답 시 안건별로 승인 여부 구분 표기 후 실행
- 본인 권장안을 자기 승인으로 취급 금지
- 애매하면 명시 확인 후 진행
C19-2. 되돌리기 어려운 액션 — 보수적 해석 의무
다음 액션은 승인 경계 해석 최대 보수. 애매하면 실행 금지·확인 선행:
main브랜치 병합·force push·tag release- 외부 공개 게시 (PR 머지·공지 발송·외부 전송)
- 영구 삭제·시스템 이관·권한 변경
- 프로덕션 빌드·배포·서버 상태 변경
C19-3. 실행 직전 체크리스트
되돌리기 어려운 액션·PD 결정 요청 실행 전:
- PD 명시 승인했는가? (추정·확대 해석 금지)
- 복수 안건 응답 시 승인된 안건 범위 내인가?
- 승인 표현 애매하면 확인 요청 후 진행했는가?
- 자동화(hook·스크립트·스케줄) 설치 여부 — 있다면 정상 동작 검증 후 "문제" 프레이밍 금지
C20. 팀장급 커밋·푸시 재량
일상 commit·push(자기 작업 브랜치 push, main 병합 포함)는 각 팀 팀장급 재량. 우려 이슈 한해서만 PD 사전 확인.
C20-1-A. 공유·push 시점 규칙
작업 완료 시 공유 문서 + Live 더미 + 시그널 즉시 갱신. push는 필요 시에만.
공유 3층 구조
- 공유 문서 즉시 반영 —
공유/하위 md (PD 지시 로그·대화로그·소통 채널·조직공지) - Live 더미 기록 —
.live/변경 요지 (UserPromptSubmit hook 즉시 주입) - 시그널 갱신 — commit 시 post-commit hook(
scripts/git-hooks/post-commit)이 자동sync_signal.sh update
push 필요 시
- PD "세션 공유"·"push" 명시 지시
- 다른 PC로 작업 이관
- 조직 공식 공유 완료 선언(C18) 필요
- 외부 개발자·QA·협력사 공유 대상
push 표준 절차
bash scripts/sync_push.sh main실행 — push + 시그널 재갱신 일괄- 또는
git push origin main단독 (post-commit hook 이미 갱신, 중복 무해)
C20-2. PD님 사전 확인 필수 (우려 이슈)
- 다른 부서·다른 프로젝트 직접 영향 변경
- 헌법 제1원칙·C·P 신설·변경
- 되돌리기가 매우 어려운 변경
- 외부 공개·외부 전송·외부 시스템 영향
- 데이터 테이블·밸런싱 자산 등 PD 결재 영역
- 프로덕션·실기기 빌드·서버 영향
C20-3. C19와의 관계 (위험 액션은 그대로 보수적 해석)
다음은 C20-1 완화 X · C19-2 그대로:
force push(특히 main·공유 브랜치)- 영구 삭제·history rewrite
- 외부 공개 게시
- 권한 변경·시스템 이관
C20-7. 코어룰 신설/변경·main 반영 시 완료 보고 의무
세션 리더가 코어룰(C·P) 신설/변경 또는 변경분을 main에 반영 시 동일 응답 내에 변경 요지·영향 범위·적용 시점 간결 보고.
C28. 문서 수정 무승인 원칙 (헌법급)
모든 .md 파일 수정·커밋·push는 PD 개별 승인 없이 즉시 수행.
C28-1. 무승인 대상
.md파일 수정·신규 생성·삭제 (C6 백업 의무 준수)- git 커밋·push (C20 팀장 재량 범위 내)
- CLAUDE.md·SKILL.md·에이전트 정의 등 모든 마크다운
C28-2. 금지 행위
- PD에게 "md 파일 수정 승인" 요청
- "이 변경 진행해도 되겠습니까?"로 md 수정 전 확인
- 단 C19-2 대상 액션(되돌리기 어려운 액션) 해당 시 C19 우선
C30. git 동기화 프로젝트 작업 전 최신 상태 점검
git 동기화 프로젝트(조직 레포·Unity·BT.Framework·차기 프로젝트 레포)를 건드리는 모든 작업은 착수 전 git 최신 상태 점검.
C30-2. 점검 대상 액션
- 대상 프로젝트 파일 직접 수정
- 관련 MCP 도구 호출 (
mcp__unity-mcp__*등) - 빌드·테스트 실행
- 신규 파일 생성·삭제
C30-3. 점검 절차
git fetch origin && git status- 원격 대비 뒤처짐(
behind) 또는 충돌 확인 - 뒤처짐 있으면
git pull또는git merge origin/main - 충돌 시 즉시 작업 중단 + PD 보고 (C3)
- 최신 상태 확인 후 작업 착수
C30-4. 금지
- git 점검 없이 작업 착수
- "조금 전 확인했으니 괜찮을 것" 추정으로 점검 생략
- 충돌 인지하고도 무시 진행
매니페스트 시스템 정합 (C35-9)
main 워크트리 단일 매니페스트 SOT (<main>/.claude/manifest/active/):
- commit·push 직전 매니페스트 등록 (
bash scripts/manifest_register.sh) - 등록 안 시 PreToolUse hook 차단
- target_files 범위 내 Edit/Write 자동 통과
- post-commit hook 자동 archive 이동
worktree 환경에서 작업 시 auditor_gate.sh 자동 worktree prefix 제거 후 매니페스트 정합 (commit 3854395 결함 3 패치).
연관 규칙
- L1: C1·C2·C5·C9·C23·C42·C44·C45·C46·C47 (
bt-foundation) - C13: PD 지시 트래킹 + 완료 후 동기화 (
bt-pd-tracking) - C32: 대화로그 기록 의무 (
bt-foundation) - C40: 세션 공유·종결 완결성 (
bt-session-mgmt)