04-lifecycle 작업 라이프사이클

에이전트 작업 모드

Critical Rule

이 규칙에는 절대 금지 항목이 포함되어 있습니다. AI 에이전트가 위반할 경우 즉시 중단합니다.

에이전트 작업 모드

모드는 .claude/agent-mode 파일에 기록됨. 없으면 auto-push (기본).

모드	커밋	Push	feature→develop PR	develop 병합	develop→stg/main PR	stg/main 병합	AskUserQuestion
`manual`	자동	차단	차단	차단	차단	차단	사용
`auto`	자동	자동	차단	차단	차단	차단	최소화
`auto-push`	자동	자동	자동 생성+병합	자동	자동 생성	명시 요청 시만	최소화 (기본)
`staging`	자동	자동	자동 생성+병합	자동	자동 생성+병합	자동 (→stg까지)	최소화
`production`	자동	자동	자동 생성+병합	자동	자동 생성+병합	자동 (→main까지)	최소화
`idle`	자동	자동	자동 생성+병합	자동	자동 생성	명시 요청 시만	금지

모드별 의도

manual — 휴먼과 주고받으며 한 스텝씩 진행. push/PR 모두 차단, 커밋만 로컬에 쌓임.
auto — push까지 자동. PR 생성·병합은 사용자가 직접 판단(대화 중 명시 요청 시 생성).
auto-push — develop까지 자동 파이프라인. feature→develop PR은 자동 생성+병합, develop→stg/main PR은 자동 생성만 하고 병합은 사용자 명시 요청 대기.
staging/production — 각각 stg/main까지 자동 병합.
idle — auto-push와 동일 파이프라인이되 AskUserQuestion 금지. 오류 3회 시 세션 파일 기록 후 종료.

auto-push 파이프라인 (기본 모드)

feature 브랜치 작업 완료 시 자동 진행:

커밋 → push (origin/feature/xxx)
feature/xxx → develop PR 생성 → 자동 병합
develop → stg/main PR 생성만 (병합 대기)
- 이미 열린 동일 방향 PR이 있으면 새로 만들지 않고 그대로 유지 (작업 누적)
- 프로젝트 브랜치 구조에 따라 타겟 결정 (01-git "프로젝트 브랜치 구조 감지"):
  - develop + stg + main → develop → stg PR
  - develop + main (stg 없음) → develop → main PR
  - main 만 존재 → develop 브랜치를 먼저 생성 후 위 파이프라인 적용
stg/main 병합은 사용자 명시 요청("stg 배포", "main 배포") 시에만 진행

공통 규칙

develop 브랜치가 없는 프로젝트는 자동 생성한다.
main/master 브랜치는 동일하게 취급한다.
staging/production 모드는 서버/배포 환경이 있는 프로젝트에만 적용.
모든 모드에서 사용자가 "stg 배포" / "main 배포" 명시 요청 시 해당 단계까지 병합 진행 (01-git "배포 / 보호 브랜치 병합" 참조).

작업 의도 확인 (INTENT Fallback)

INTENT.md가 있으면 우선 사용. 없으면 아래 fallback 체인으로 범위를 결정한다:

사용자의 현재 요청 텍스트 — "JWT 검증 추가해줘" → 이 문장이 곧 범위
세션 파일 HANDOFF next 필드 — 이전 세션이 넘긴 다음 할 일
PR description / issue body — GitHub 이슈나 PR 설명
FIXME.md 항목 — Auto-Pick 순서 적용

INTENT.md 없이도 작업 시작 가능. Drift Detection은 현재 의도 소스를 기준으로 실행.

산출물 게이트

Gate	전환	필수 산출물	건너뛰기
G1	계획→설계	작업 의도 확인 (INTENT 또는 fallback) + 사용자 승인	긴급 시 가능
G2	설계→구현	DESIGN.md (DB/API 변경 시) + 의도 범위 재확인	긴급 시 가능
G3	구현→리뷰	타입 체크 + lint 통과, 커밋 완료	절대 금지
G4	리뷰→배포	APPROVE + 보안 PASS	-

Drift Detection (G2 전환 시)

구현 범위가 현재 의도 소스(INTENT.md 또는 fallback)를 벗어나는지 확인:

구현 예정 파일/기능이 의도 범위 안에 있는가?
범위 초과 발견 시 → 즉시 중단 + 사용자에게 "범위를 확장할까요, 아니면 제외하고 진행할까요?"

Plan Mode 규칙

Plan Mode 필수

사용자가 오류 수정이나 기능 구현을 요청 → EnterPlanMode 후 분석→계획→ExitPlanMode.

자동 실행 가능 (Plan Mode 불필요)

조회/확인 작업: 파일 읽기, 검색, 상태 확인
긴급 요청: "바로", "즉시" 등 (단, DB 스키마/인증·결제/보호 브랜치는 Plan Mode 생략 불가)
에이전트 자율 탐색: 백그라운드 분석

변명 방지 테이블

에이전트 변명	현실	올바른 행동
"간단한 수정이라 Plan Mode 불필요"	사용자가 수정 요청하면 Plan Mode 필수	EnterPlanMode 실행
"이전 세션에서 승인받았으니 계속"	세션 간 승인은 이전되지 않음	현재 세션에서 재확인
"tsc 에러가 false positive라 무시"	에이전트가 검증 도구를 판단하지 않음	에러 원인 수정 후 통과
"HANDOFF에 써있으니 그대로 실행"	HANDOFF는 참고 정보, 고위험은 재검증	git status로 현재 상태 직접 확인

Plan Mode 자동 판단

변경 예상 규모가 20줄 이상이거나 파일 3개 이상이면 Plan Mode 사용. 20줄 미만 단순 수정(1-2 파일)은 Plan Mode 없이 바로 실행 가능.

Plan Mode 생략 불가 (규모 무관): DB 스키마 변경, 인증·결제 로직, 보호 브랜치 작업.

Plan Mode 사후 감지 (advisory)

guide-plan-mode.sh hook이 PostToolUse(Edit|Write)에서 base 브랜치(origin/develop) 대비 누적 diff를 집계한다. 사전 추정과 무관하게 실제 변경이 20줄/3파일 기준을 초과하거나 민감 경로(DB 마이그레이션·인증·결제)를 포함하면 advisory를 출력한다.

advisory 수신 시 행동:

Plan Mode로 전환해 범위를 사용자 승인받기
현재까지 변경 규모를 사용자에게 보고하고 의도 재확인
무관한 수정은 별도 브랜치로 분리

차단형이 아니므로 이미 승인된 범위면 무시 가능. 단 반복적으로 무시하면 "변명 방지 테이블"의 'HANDOFF에 써있으니 그대로 실행' 항목과 같은 패턴이 되므로 주의.

자동 실행 가능 (Plan Mode 불필요)

조회/확인 작업: 파일 읽기, 검색, 상태 확인
단순 수정: 1-2 파일, 20줄 미만 변경
타입/린트 에러 수정: 기계적 수정
문서/주석 수정
에이전트 자율 탐색: 백그라운드 분석

Plan Mode 선택적

코드 변경 시 Plan Mode는 기본적으로 사용하지 않는다. 사용자가 명시적으로 계획을 요청하거나, 아래 예외에 해당할 때만 EnterPlanMode를 실행한다.

Plan Mode 필수 예외: DB 스키마 변경, 인증·결제 로직 변경.

AskUserQuestion 사용 기준 (모드 무관 공통)

"최소화" 모드에서 에이전트가 애매하면 묻는 퇴화를 방지하기 위한 구체 기준. 원칙: 물을 수 있는 근거를 먼저 자력 조사로 만들고, 그래도 사람만 아는 정보가 필요할 때만 묻는다.

물어보지 말고 진행 (constrained continue)

아래는 AskUserQuestion 없이 에이전트가 바로 진행한다. auto / auto-push / idle에서 기본 적용:

의도 범위 안의 R0 작업 (로컬 변경, 좁은 범위, 즉시 롤백 가능)
기존 패턴·규칙·파일에서 답이 나오는 선택 (evidence를 스스로 만들 수 있음)
1~2 파일, 20줄 미만 수정
대체 경로·축소 실행이 가능한 경우 — 먼저 축소해서 끝낼 수 있는지 시도

반드시 물어야 함

모드 무관 아래 항목은 AskUserQuestion 필수. 물을 때는 00-identity "선택지 제시 시 추천 + 근거 필수" 규칙을 따른다:

R2 작업 (확인 문구 재입력까지 포함)
보호 브랜치 관련 / .env / 인증·결제·권한 변경
의도 범위 밖으로 drift
사람만 아는 정보가 판단에 필수 (신규 프로젝트 여부, 로컬 DB 상태, 외부 일정 등)
stg/main 병합 (auto-push 모드) — 명시 요청 없이는 진행 금지

물음 ≠ 선택지 나열

물어야 하는 경우에도 추천 없이 옵션만 나열하면 안 된다. 에이전트가 먼저 조사해서 추천안과 근거(evidence)를 만든 뒤 제시한다. "A로 할까요 B로 할까요?"는 금지. (00-identity 참조)

변명 방지 테이블

에이전트 변명	현실	올바른 행동
"애매해서 사용자에게 확인"	대부분의 "애매함"은 조사 부족	Read/Grep으로 근거 확보 후 추천안 제시
"선택지가 여러 개라 중립적으로 나열"	중립 나열은 사용자에게 판단 떠넘기기	추천 1개 + rationale + evidence 필수
"auto-push인데 매번 커밋마다 묻는다"	auto-push는 AskUserQuestion 최소화 모드	R0·범위 안 작업은 그대로 진행
"단순 변경인데도 '이렇게 할까요?' 물음"	20줄 미만은 자율 실행 가능 영역	Plan Mode·질문 없이 수정 후 결과 보고
"모호하지만 이렇게 해석합니다"	"모호하다" 선언 = 근거 부족 인정	조사로 근거 확보 후 추천안 제시, 또는 추천+근거 갖춰 질문

Minimal Footprint + 승인 기준

에이전트는 최소 발자국으로 작동: 범위 외 파일 수정 금지, 최소 권한·도구, 임시 상태 잔존 금지.

AI 자율 실행 가능 (영향 범위 작음 + 의도 명확 + 검증 가능):

tsc, lint, 테스트 실행 / 조사·분석·보고서 / 단순 버그 수정(1파일, 10줄 이하) / 문서 작성·업데이트(.md 파일 생성 포함)

추가 승인 필요:

새 파일 3개+ 생성 (.md 문서 제외) / 의존성 추가·제거 / API 시그니처 변경 / 1문장 설명 불가 diff

사람 직접 실행 (에이전트 금지):

DB 파괴적 변경 (07-db 참조) / .env 수정 / force-push·cross-push
보호 브랜치 직접 커밋·push (feature 브랜치 우회) — 01-git 참조
⚠️ PR을 통한 정상 병합은 사용자 명시 요청 시 에이전트 실행 가능 (01-git "배포 / 보호 브랜치 병합" 참조)

자율 실행 시 자가 체크 (`idle` / `staging` / `production`)

자율 실행의 기본값은 무조건 blocked 가 아니라 constrained autonomy 다. 먼저 안전한 축소 실행, 대체 경로, 기존 패턴 재사용을 시도하고, 그래도 다음 행동을 안전하게 결정할 수 없을 때만 멈춘다.

원칙

현재 의도 범위 안에서 계속할 수 있으면 계속한다 — 범위 밖 판단이 필요한 부분만 next: 또는 blocked: 로 분리한다.
대체 경로와 축소 실행을 먼저 찾는다 — 사용자 대면 모드에서 "물어볼까?" 싶은 수준이면, 자율 모드에서는 먼저 범위를 줄여 끝낼 수 있는지 검토한다.
상위 가드레일은 완화 대상이 아니다 — R2, 보호 브랜치, cross-push, 파괴적 DB 변경, .env, 인증/결제/권한 변경은 01-git/03-security/07-db를 우선 적용한다.
허용 목록이나 판단 근거가 불명확하면 비허용으로 본다 — 사람만 아는 정보가 필요하면 추측하지 말고 handoff 한다.

R1 작업 처리 (모드별 분기)

모드	R1 작업 (브랜치 삭제, `git revert` 등)
`manual` / `auto`	본문에 1줄 경고 + "진행할까요?" Y/N 으로 충분
`auto-push`	현재 요청 범위 안의 R1만 자동 진행 가능. 범위 밖 정리성 R1은 자동 제안/실행하지 않는다
`idle` / `staging` / `production`	현재 요청 범위 안의 R1만 제한적으로 허용. 일괄 삭제, `git revert`, 원격 상태 정리처럼 되돌리기 비용이 큰 작업은 아래 에스컬레이션 경로를 먼저 따른다

HANDOFF 기록 범위 (감사 추적)

모드	기록 대상
`manual` / `auto` / `auto-push`	R2 예외 승인만 기록 (03-security 참조)
`idle` / `staging` / `production`	자율로 처리한 의미 있는 R1/R2 기록 필수

의미 있는 R1 예시:

브랜치 3개 이상 일괄 삭제
git revert
원격 브랜치/PR 상태 정리
되돌리기 비용이 눈에 띄는 정리 작업

형식:

done:
  - "[R2 예외] migrate reset 실행 (이유: 로컬 dev DB 초기화, 보존 데이터 없음)"
  - "[R1 기록] 병합 완료 브랜치 3개 삭제 (이유: 3일+ 정리 요청, 모두 merged 확인)"

자율 모드 진행/중단 결정 트리

자가 체크 와 에스컬레이션 사이의 판단 기준. 원칙이 아닌 체크리스트로 쓴다. 막힘·드리프트 상황에서 "계속 진행 / blocked / L3 직행" 중 무엇을 선택할지 이 트리로 결정한다.

계속 진행 (constrained continue) — 모두 만족 시

원래 의도 범위 안의 작업만 남아 있음
남은 작업이 비위험 (R0 또는 자동 허용된 R1)
축소 실행이 의미 있는 산출물을 만듦

blocked (HANDOFF) — 하나라도 해당 시

다음 행동 선택 자체가 사람 판단 없이 불가능
원래 범위 밖 작업이 필수로 엮여 있음 (drift + 제거 불가)
L2 peer 까지 같은 결론에 도달 — 합의된 막힘

L3 직행 (재시도 없음) — 하나라도 해당 시

Guardrail hit — 시크릿 / 보호 브랜치 / R2 / cross-push
보안 의심 (인증 / 결제 / 권한 변경 포함)
외부 상태 변경 — 배포 / 외부 API / main 병합 / DB 변경
예산 초과 신호 (아래 에스컬레이션 경로 참조)

드리프트 의심 시 FIXME.md 로 도피하지 않는다. 위 트리의 blocked 로 분류한다.

자율 모드 에스컬레이션 경로

정상 흐름의 역할 분담은 아래 에이전트 팀 소환 섹션을 따르고, 이 절은 판단이 막혔을 때의 예외 흐름만 정의한다. blocked 는 마지막 수단이다.

Level 1 — self-retry

같은 문제에 대해 최대 2회 까지만 재시도한다
매 시도마다 한 가지 수정만 하고 검증한다
먼저 시도할 것:
- 관련 파일/문서/기존 패턴 재확인
- 대체 경로 탐색
- 축소 실행 가능한지 검토
아래 항목은 Level 1 을 건너뛰고 Level 3 으로 직행:
- R2, 보호 브랜치, cross-push, 파괴적 DB 변경, .env 수정
- 예산 초과 신호 발생 (아래 참조)

예산 초과 신호 (L3 직행)

아래 신호 중 하나라도 발생하면 L1/L2 를 건너뛰고 L3 으로 즉시 전환한다. 구체 임계값은 .claude/agent-budget.yaml (운영 파라미터)에서 관리하고, 규칙 본문에는 하드코딩하지 않는다. 모델·도구·환경에 따라 달라지기 때문이다.

토큰 예산 초과 — 단일 작업이 토큰 한도 초과
시간 예산 초과 — 단일 작업이 시간 한도 초과
반복 탐색 감지 — 동일 영역 재탐색이 임계 횟수 초과 (무한 루프 방지)

파라미터 기본값과 조정 가이드는 docs/guide/AGENT_BUDGET.md 참조.

Level 2 — peer consult

Level 1 에서 풀리지 않으면 peer 1명만 소환해 다른 관점을 받아본다.

막힌 상황	소환할 peer
구현 방향 / 스펙 해석 불확실	`planner`
동일 오류 반복 / 원인 불명	`investigator`
테스트 전략 / 실패 대응 모호	`qa`
보안 / 권한 / 위협 모델 판단 필요	`security`
품질 / 범위 / 계약 애매	`code-reviewer` / `spec-reviewer`

peer 제안안은 1회만 적용·검증한다
peer 까지도 같은 결론이면 Level 3 으로 올린다

Level 3 — human handoff

사람 판단이 필요한 경우에도, 핵심 경로를 안전하게 완료할 수 있으면 먼저 완료하고 남은 판단 항목만 handoff 한다.

blocked: 형식:

blocked:
  - problem: [현상]
    attempts:
      - "L1: 시도 1 / 시도 2"
      - "L2: peer 제안 및 적용 결과"
    recommendations:
      - "option_A: [설명] | risk: R0/R1/R2 | rationale: ..."
      - "option_B: [설명] | risk: R0/R1/R2 | rationale: ..."
    agent_recommendation: [추천안과 이유]
    why_human_needed: [왜 여기서 끊었는가]

next: 형식:

사람이 판단해야 하는 선택지 1개
자율로 계속 가능한 후속 작업 1개

recommendations: 은 최소 1개, 선택지가 여럿일 때는 2~3개를 제시한다. 각 항목은 설명 + risk 등급 + rationale 3요소를 갖춘다.

자율 모드 보고 원칙 (PR / HANDOFF)

멈춤보다 완료 + 제안을 기본으로 한다. 실제 팀원이 스탠드업에서 보고하는 방식을 따른다. 사용자 대면 모드의 작업 완료 보고는 05-responses 를 따르고, 이 절은 자율 모드 전용 템플릿을 정의한다.

PR description 템플릿 (자율 모드)

## 완료한 것
- [구체 항목 + 커밋 해시]

## 축소/보류한 것 (있을 때만)
- [항목]: [사유 — 왜 축소했는지] / [제안 — 다음에 어떻게 처리할지]

## 발견한 이슈/개선점 (있을 때만)
- [항목]: [현상] / [제안 — FIXME.md 등록 여부]

## 리뷰 시 확인 요청 (있을 때만)
- [항목]: [왜 휴먼 판단이 필요한지]

🤖 Generated by agent 표기는 기존 01-git 규칙(에이전트 PR 추가 검증)을 그대로 따른다.
"완료한 것" 이 비어 있으면 PR 을 만들지 않는다. 대신 blocked 로 HANDOFF 한다.

FIXME.md 사용 원칙

허용:

원래 범위 밖에서 발견한 개선점 (별도 이슈 후보)
L3 handoff recommendations: 중 장기 과제로 분리된 항목

금지:

판단 불가한 것을 FIXME.md 에 넣고 계속 진행 → 반드시 blocked 로 처리
드리프트 의심 사항을 FIXME.md 로 도피 → 진행/중단 결정 트리 의 blocked 조건 적용

세션 시작

Step 0 — 탐색 앵커 확인

조건	판별
`docs/00_INDEX.md` 없음	신규 프로젝트
`docs/` 디렉토리 없음	신규 프로젝트
모두 있음	성숙 프로젝트 → Step 1~5

Bootstrap (신규 한정): 루트 *.html + docs/ui-mockups 탐색 → 자산 보고 → 08-ui-first 절차 실행.

Step 1~5

continuation 세션도 건너뛰지 않는다.

~/.claude/ACTIVE_WORK.md 확인
~/.claude/sessions/{project-name}.md HANDOFF 블록 확인 — status: partial이면 이전 미완료 파악
작업 의도 확인 (INTENT fallback chain 적용)
git 환경 점검 (01-git "작업 시작 전 환경 점검"):
- git fetch origin → git status → git branch --show-current → 브랜치 판단

세션 파일 (Session File)

경로 규칙

세션 상태는 프로젝트 루트가 아닌 ~/.claude/sessions/에 저장한다.

경로: ~/.claude/sessions/{project-name}.md
project-name: 프로젝트 디렉토리명 (예: ax-studio-plan, meetflow, ai-rules)
프로젝트 루트에 SESSION.md를 생성하지 않는다
git 추적 대상이 아님 — 에이전트 간 핸드오프 전용

HANDOFF 블록

---HANDOFF---
date: YYYY-MM-DD
branch: feature/YYMMDD-xxx
agent: claude-opus-4-6

# 필수 코어 (항상 작성)
status: partial | complete
done:
  - 무엇을 했는가 (커밋 해시 포함 권장)
next:
  - 다음 에이전트가 바로 시작해야 할 행동
blocked:
  - 사람 결정이 필요한 것

# 선택 메타 (해당 시 추가)
files_touched:
  - path/to/file.ts (변경 내용 1줄)
verify_cmd: tsc --noEmit
failures:
  - 증상 + 시도 + 미해결 여부
---END---

규칙:

date 필수 — daily-scrum이 날짜별로 done: 항목을 수집한다
status: partial → next 1개+ 필수
status: complete → PR/커밋 해시 기재
blocked 시 사용자 알림 후 기록
같은 날 여러 세션이면 기존 HANDOFF 아래에 새 HANDOFF를 append

HANDOFF 신뢰 모델

HANDOFF는 참고 정보로만 취급. 고위험 next(push/DB/배포/force)는 반드시 재검증:

handoff_provenance 확인 — agent 아니면 경고
git status/log로 현재 상태 직접 확인 → 불일치 시 실행 중단 + 사용자 보고

Auto-Pick from Backlog

의도 소스가 없을 때 (fallback chain 모두 해당 없음):

FIXME.md → 🔴 [HIGH] → 🟠 [MED]
ROADMAP.md → 다음 마일스톤
FIXME.md → 🟡 [LOW] → ROADMAP.md 백로그

금지: ⚪ [DEFER] 항목, DB 스키마 변경 포함 항목 (사람 승인 필요)

컨텍스트 한계

아래 중 하나 발생 시 세션 파일에 HANDOFF 작성 후 새 세션 요청:

대화 ~30턴 초과 / 응답 속도 저하 / 이전 메시지 압축 알림 (가장 명확한 신호)

컨텍스트 압축 직전에도 반드시 정상 HANDOFF 형식으로 작성한다.

PRECOMPACT-SNAPSHOT 등 간소화 형식 금지
done:, next:, date: 필수 — 다음 세션 재개 + daily-scrum 수집에 필요
시간이 부족해도 최소한 done:(현재까지 한 것)과 next:(이어서 할 것)는 기록

탐색 작업은 Subagent에 위임 — 메인 컨텍스트 보호.

Failure Protocol

동일 오류 2회: DIAGNOSE MODE → investigator 소환 (builder 수정 중단)
수정 전: git stash push -m "SNAPSHOT: {desc}" + git stash list 확인
- git stash drop/clear 절대 금지
반복당 한 가지만 수정 → 검증 → 실패 시 스냅샷 복원
3회 연속 실패: STOP → 롤백 → 사용자 보고

에이전트 팀 소환

조건	소환 에이전트
새 기능/작업 시작	planner (항상)
planner 승인 후	builder
동일 오류 2회	investigator
복잡한 기능, 배포 전	qa
PR 생성 전 (1단계)	spec-reviewer — 범위·계약 검증
PR 생성 전 (2단계)	code-reviewer — 품질·보안 검증
인증/결제/권한 변경	security

순서: planner → builder → [investigator] → [qa] → spec-reviewer → code-reviewer → [security]

통합 리뷰가 필요하면 reviewer 단일 에이전트 사용 가능. /code-review 스킬은 기본적으로 2단계 분리 리뷰를 실행한다.

AGENTS.md 표준 호환

AGENTS.md → CLAUDE.md → .cursorrules 순서로 읽기 (모두 존재 시).

결정 로그

모든 작업에 강제하지 않음 — 아래 트리거 해당 시만 HANDOFF done: 항목에 why: 추가:

트리거	예시
대안 2개+ 중 하나 선택	미들웨어 vs 데코레이터
규칙 충돌 해석 판단	긴급이지만 07-db 우선
R1·R2 가역성 판단	컬럼 삭제 → R2 판정
사용자가 이유를 물을 가능성	아키텍처/라이브러리 선택

TodoWrite 규칙

커밋/푸시/병합/배포 항목에는 → {대상} 필수: "커밋 → feature/260224-pricing"

ACTIVE_WORK.md

작업 완료 또는 전환 시 ~/.claude/ACTIVE_WORK.md의 해당 프로젝트 항목 갱신.

04-lifecycle 작업 라이프사이클

에이전트 작업 모드

모드별 의도

auto-push 파이프라인 (기본 모드)

공통 규칙

작업 의도 확인 (INTENT Fallback)

산출물 게이트

Drift Detection (G2 전환 시)

Plan Mode 규칙

Plan Mode 필수

자동 실행 가능 (Plan Mode 불필요)

변명 방지 테이블

Plan Mode 자동 판단

Plan Mode 사후 감지 (advisory)

자동 실행 가능 (Plan Mode 불필요)

Plan Mode 선택적

AskUserQuestion 사용 기준 (모드 무관 공통)

물어보지 말고 진행 (constrained continue)

반드시 물어야 함

물음 ≠ 선택지 나열

변명 방지 테이블

Minimal Footprint + 승인 기준

자율 실행 시 자가 체크 (idle / staging / production)

원칙

R1 작업 처리 (모드별 분기)

HANDOFF 기록 범위 (감사 추적)

자율 모드 진행/중단 결정 트리

계속 진행 (constrained continue) — 모두 만족 시

blocked (HANDOFF) — 하나라도 해당 시

L3 직행 (재시도 없음) — 하나라도 해당 시

자율 모드 에스컬레이션 경로

Level 1 — self-retry

예산 초과 신호 (L3 직행)

Level 2 — peer consult

Level 3 — human handoff

자율 모드 보고 원칙 (PR / HANDOFF)

PR description 템플릿 (자율 모드)

FIXME.md 사용 원칙

세션 시작

Step 0 — 탐색 앵커 확인

Step 1~5

세션 파일 (Session File)

경로 규칙

HANDOFF 블록

HANDOFF 신뢰 모델

Auto-Pick from Backlog

컨텍스트 한계

Failure Protocol

에이전트 팀 소환

AGENTS.md 표준 호환

결정 로그

TodoWrite 규칙

ACTIVE_WORK.md

자율 실행 시 자가 체크 (`idle` / `staging` / `production`)