05-responses 응답 형식 규칙

답변 신뢰도 레이블

답변 신뢰도 레이블

모든 코드 수정·분석 답변에 레이블 명시:

레이블	의미
[검증됨]	코드/실행 결과로 직접 확인
[추론]	파일 읽고 분석했지만 실행 미확인
[모름]	확인 수단 없거나 불확실

차단 이유 3분류 (에이전트가 "못 한다"고 말할 때 필수)

에이전트가 어떤 작업을 실행하지 못하거나 사용자에게 넘길 때, 왜 못 하는지를 3가지 중 하나로 명시한다. 이유가 섞이면 사용자는 규칙이 과잉이라고 오해한다.

분류	뜻	예시
[차단:위험]	R2 비가역 — 데이터 손실·외부 상태 영구 변경	migrate reset, DROP TABLE, force-push, cross-push
[차단:판단근거]	실행은 안전하나 "지금 이걸 해도 되는가" 판단에 필요한 정보가 사람에게만 있음	신규 프로젝트 여부, .env/로컬 DB 상태, 사용자 의도
[차단:권한]	에이전트가 접근할 수 없는 도구·파일·시스템	.env 수정(03-security), OS keychain, 외부 승인 채널

형식

복사❌ 금지: "R2라서 직접 실행해주세요" (이유 불명확 — 분류 없음)
❌ 금지: "규칙상 못 합니다" (분류 없음)

✅ "[차단:위험] migrate reset은 DB 전체 삭제입니다(R2). 확인 문구 재입력 후..."
✅ "[차단:판단근거] 이 명령 자체는 위험하지 않지만, '이 프로젝트가 신규인지'는
    .env와 로컬 DB 상태를 아는 사람만 확신할 수 있어 직접 실행을 요청합니다."
✅ "[차단:권한] .env 파일은 03-security 규칙상 에이전트가 수정할 수 없습니다.
    사용자가 직접 편집해주세요."

핵심 원칙: [차단:위험]과 [차단:판단근거]를 섞지 마라. 신규 프로젝트에서 prisma migrate dev를 사람이 실행하는 이유는 위험이 아니라 판단 근거다 (07-db 참조). "R2"라는 말을 꺼낼 때는 실제로 가역성 R2인지 자가 점검한다.

R1 처리 원칙: R1(제한적 가역 — 브랜치 삭제, git revert 등)은 [차단:위험] 블록을 붙이지 않는다. 본문에 1줄 경고 + "진행할까요?" Y/N 으로 충분. 사용자가 이미 검증을 마치고 명시 요청한 R1 일괄 작업은 재확인 문구 없이 그대로 진행한다. 자율 실행 모드(idle/staging/production)의 R1 처리는 04-lifecycle 의 자율 실행 시 자가 체크 / 자율 모드 에스컬레이션 경로 를 따른다.

커밋/Push 실행 보고 (실행 시점 필수)

커밋 또는 push를 실행할 때 반드시 대상을 명시한다. "커밋했습니다", "push했습니다"만으로는 불충분.

복사✅ 올바른 예:
  "커밋 완료 → feature/260403-pricing (로컬, abc1234)"
  "push 완료 → origin/feature/260403-pricing (abc1234..def5678)"
  "PR 생성 → feature/260403-pricing → master (#42)"

❌ 금지:
  "커밋했습니다" / "push 완료" / "PR 올렸습니다"

작업 완료 보고 (코드 변경 시 필수)

1. 변경 요약

• 변경 파일 목록 (경로 + 변경 내용 1줄)
• 커밋 해시 + 브랜치: abc1234 on feature/260403-xxx
• push 상태: 로컬만 / origin push 완료 / PR 생성됨

2. 브랜치 상태 보고 (조건부)

일반 작업 완료는 한 줄로 끝낸다: "→ origin/feature/xxx (abc1234)".

아래 조건 중 하나일 때만 브랜치 상태 테이블을 포함한다:

• PR 생성/병합 직후
• 사용자가 "브랜치 정리" / "상태 보여줘" 등 명시 요청
• 미병합 브랜치가 5개 이상 누적 또는 3일 이상 된 브랜치 감지

매 작업 완료마다 git branch -a --no-merged를 실행해 테이블을 만드는 것은 금지 — 불필요한 토큰과 읽기 부담을 발생시킨다.

테이블 포맷 (해당 조건 충족 시):

복사git branch -a --no-merged origin/master   # 미병합 브랜치
git branch -a --merged origin/master      # 병합 완료 브랜치

복사| 브랜치 | 상태 | PR | 조치 필요 |
|--------|------|----|----------|
| feature/xxx | ✅ 병합 완료 | #123 | 삭제 가능 |
| feature/yyy | 🔄 PR 오픈 | #124 | 리뷰 대기 |
| feature/zzz | ⚠️ 미병합 (5일) | 없음 | PR 생성 또는 정리 필요 |

미병합 브랜치에 대해:

• 3일 이상 미병합 → 경고 + 병합/정리 제안
• PR 없는 미병합 브랜치 → "PR 생성할까요? (feature/zzz → master)" 제안
• 병합 완료된 브랜치 → "삭제할까요? (feature/xxx)" 제안

3. 후속 작업 체크리스트

해당 항목만 포함 (해당 없는 항목은 생략):

• PR 생성 (feature/xxx → master)
• DB 마이그레이션 (스키마 변경 시)
• 환경변수 변경 (새 변수 추가 시)
• E2E 테스트 실행 (UI/API 변경 시)
• 스테이징 배포 (develop 푸시 후)
• 운영 배포 (사용자 요청 시에만)

리포 스캔 금지

전체 저장소 스캔 금지 — CLAUDE.md / INTENT.md / docs index에서 참조된 파일만 읽기.

예외 조건 — 탐색 앵커 부재 시 (신규/초기 프로젝트)

아래 중 하나라도 해당하면 세션 시작 시 제한적 1회 탐색 허용:

• docs/00_INDEX.md 없음
• INTENT.md 없음
• docs/ 디렉토리 자체 없음

탐색 허용 범위:

1. 프로젝트 루트 기준 *.html 파일 (node_modules, dist, build, index.html 제외)
2. docs/, ui-mockups/, mockups/, wireframes/, design/ 디렉토리 구조 1단계

탐색 후 발견된 자산을 사용자에게 보고하고, INTENT.md가 있으면 context.docs에 등록. 이후에는 일반 규칙 적용.