update stage-pilot

2026-04-14 22:09:53 +09:00
parent c3513b3a15
commit ec20f933ad
50 changed files with 3355 additions and 0 deletions
@@ -0,0 +1,108 @@
+---
+applyTo: "**"
+description: "Use when: discovery, problem framing, requirement intake, scope definition"
+---
+
+# Stage 1 - Discovery
+
+## Purpose
+
+문제와 목표를 명확히 정의하고, 요구사항 후보를 수집한다.
+
+## Stage Contract
+
+| 항목 | 내용 |
+|---|---|
+| 입력 | 문제 배경, 사용자/이해관계자 정보, 제약사항 |
+| 산출물 | Discovery 문서, 요구사항 목록, 리스크/가정, 성공 기준 |
+| 게이트 확인 | 문제 정의, 요구사항, 리스크, 성공 기준이 문서화되어 Planning 입력으로 전달 가능해야 함 |
+| 다음 단계 인계 | Planning에 우선순위 후보, 범위 경계, 미해결 질문을 전달 |
+
+## DoR (Entry)
+
+1. 요청 배경 또는 문제 상황이 제공됨
+2. 이해관계자 또는 사용자 관점이 최소 1개 이상 식별됨
+
+## Required Actions
+
+1. 문제 정의: 현재 상태, 기대 상태, 제약사항을 정리한다.
+2. 요구사항 정제: 기능/비기능 요구사항을 분리한다.
+3. 가정/리스크 명시: 불확실한 항목과 영향도를 기록한다.
+4. 성공 기준 정의: 완료 판단 기준(측정 가능)을 제안한다.
+
+## Discovery Question Template
+
+### A. Problem and Goal
+
+1. 현재 가장 큰 문제는 무엇인가?
+2. 이 변경으로 달성하고 싶은 기대 상태는 무엇인가?
+3. 성공을 어떤 지표로 측정할 것인가?
+
+### B. Users and Stakeholders
+
+1. 주요 사용자와 이해관계자는 누구인가?
+2. 사용자별로 가장 중요한 시나리오는 무엇인가?
+3. 승인/의사결정자는 누구인가?
+
+### C. Scope and Constraints
+
+1. 이번 반복에서 반드시 포함할 범위는 무엇인가?
+2. 명시적으로 제외할 범위는 무엇인가?
+3. 일정, 비용, 기술, 정책 제약은 무엇인가?
+
+### D. Quality and Risk
+
+1. 성능, 보안, 가용성, 규정 준수 요구사항은 무엇인가?
+2. 실패 시 가장 큰 영향은 무엇이며 우회책은 있는가?
+3. 현재 정보에서 불확실한 항목은 무엇인가?
+
+### E. Dependency and Data
+
+1. 연동해야 하는 외부 시스템/팀은 무엇인가?
+2. 입력/출력 데이터의 출처와 품질 기준은 무엇인가?
+3. 마이그레이션 또는 호환성 이슈가 있는가?
+
+## Questioning Rules
+
+1. 질문은 최소 1개 사용자 관점과 1개 운영 관점을 포함한다.
+2. 답변이 없는 항목은 가정으로 대체하지 말고 Open Questions로 승격한다.
+3. 고위험 항목(보안, 데이터 손실, 장애 확산)은 우선 질문으로 분류한다.
+4. Discovery 종료 전 질문-답변 매핑표를 만든다.
+
+## Artifact Convention
+
+1. 저장 폴더: docs/sdlc/discovery/
+2. 파일명 형식: dcy-<3자리문서번호>_YYYY-MM-DD_<topic-slug>.discovery.md
+3. 문서번호는 Discovery 문서 생성 순번 기준으로 001부터 증가한다. 예: dcy-001, dcy-002
+4. topic-slug 규칙: 소문자 영문/숫자/하이픈만 사용한다.
+5. 날짜는 문서 생성일 기준으로 유지한다. 문서 수정 시 파일명 날짜는 바꾸지 않는다.
+6. Discovery 최종본 하단에는 Discovery Freeze 섹션을 반드시 포함한다.
+
+### Discovery Freeze (Required Fields)
+
+1. Feature Statement
+2. In Scope
+3. Out of Scope
+4. Success Metrics
+5. High Open Questions
+6. Handoff Decision (Planning 진행 가능/보류)
+7. Approver
+8. Updated At (UTC)
+9. User Confirmation Checklist (필수 확인 항목 + 상태)
+10. Freeze Status Flag (Ready for Planning: true/false, Confirmed By, Confirmed At UTC)
+
+## Outputs
+
+1. 문제정의 요약
+2. 요구사항 목록(기능/비기능)
+3. 리스크/가정 목록
+4. 초기 성공 기준
+5. 질문-답변 매핑표
+6. Discovery 문서 파일(docs/sdlc/discovery/ 경로, 규칙 파일명)
+7. Discovery Freeze 섹션
+
+## DoD (Exit)
+
+1. 다음 단계(Planning)에 필요한 우선순위 후보가 존재함
+2. 미해결 질문이 명시되어 있음
+3. 핵심 질문(A~E)의 미답변 항목이 Open Questions로 정리됨
@@ -0,0 +1,114 @@
+---
+applyTo: "**"
+description: "Use when: planning, prioritization, sprint slicing, estimation"
+---
+
+# Stage 2 - Planning
+
+## Purpose
+
+요구사항을 실행 가능한 작업 단위로 분해하고 우선순위를 결정한다.
+
+## Stage Contract
+
+| 항목 | 내용 |
+|---|---|
+| 입력 | confirmed 또는 전달 가능 상태의 Discovery 산출물, 성공 기준, 리스크 목록 |
+| 산출물 | Planning 문서, 우선순위 점수표, 작업별 AC, 범위 경계 |
+| 게이트 확인 | 우선순위, AC, In Scope/Out of Scope, 점수 근거가 Design 입력으로 충분해야 함 |
+| 다음 단계 인계 | Design에 우선순위 상위 작업, AC, 제약사항, 리스크 대응 우선순위를 전달 |
+
+## DoR (Entry)
+
+1. Discovery 산출물 존재
+2. 성공 기준 또는 우선순위 기준 존재
+
+## Required Actions
+
+1. 작업 분해: 기능을 작업 단위로 분할한다.
+2. 우선순위화: WSJF 또는 RICE로 점수화해 정렬한다.
+3. 범위 설정: 이번 반복에서 포함/제외 항목을 명시한다.
+4. 완료 기준 확정: 각 작업의 수용 기준(AC)을 정의한다.
+
+## Prioritization Rules (WSJF/RICE)
+
+1. 기본값은 WSJF를 사용한다.
+2. 시장 도달 범위와 정량 사용자 영향이 핵심인 경우 RICE를 사용한다.
+3. 두 방식 모두 계산 근거를 기록하지 않으면 우선순위 확정 불가로 처리한다.
+
+### WSJF Formula
+
+WSJF = (Business Value + Time Criticality + Risk Reduction or Opportunity Enablement) / Job Size
+
+1. 각 항목은 동일 스케일(예: 1~10)로 점수화한다.
+2. Job Size 추정 근거(복잡도, 의존성, 불확실성)를 함께 기록한다.
+
+### RICE Formula
+
+RICE = (Reach x Impact x Confidence) / Effort
+
+1. Reach 기간 단위(예: 월간 사용자 수)를 명시한다.
+2. Confidence가 50% 미만이면 별도 리스크 플래그를 추가한다.
+3. Effort는 팀 기준 단위(인일/스토리포인트)를 고정해 사용한다.
+
+## Tie-breaker and Override Rules
+
+1. 점수 동률 시: 리스크 감소 효과가 큰 작업을 우선한다.
+2. 규제/보안/장애 복구 관련 항목은 점수와 무관하게 상향 조정 가능하다.
+3. 상향/하향 조정 시 사유와 승인자를 기록한다.
+
+## Sample Backlog Scoring Template
+
+### WSJF Sample Table
+
+| Item ID | Work Item | Business Value (1-10) | Time Criticality (1-10) | RR/OE (1-10) | Job Size (1-10) | WSJF Score | Priority |
+|---|---|---:|---:|---:|---:|---:|---:|
+| P-001 |  |  |  |  |  |  |  |
+| P-002 |  |  |  |  |  |  |  |
+| P-003 |  |  |  |  |  |  |  |
+
+계산식: WSJF Score = (Business Value + Time Criticality + RR/OE) / Job Size
+
+### RICE Sample Table
+
+| Item ID | Work Item | Reach (period) | Impact | Confidence (%) | Effort | RICE Score | Priority |
+|---|---|---:|---:|---:|---:|---:|---:|
+| P-001 |  |  |  |  |  |  |  |
+| P-002 |  |  |  |  |  |  |  |
+| P-003 |  |  |  |  |  |  |  |
+
+계산식: RICE Score = (Reach x Impact x Confidence) / Effort
+
+### Scoring Notes Template
+
+1. Scoring Scale: (예: 1~10, Impact는 0.25/0.5/1/2/3)
+2. Reach Period: (예: monthly active users)
+3. Confidence Source: (사용 데이터, 인터뷰, 실험)
+4. Override Reason and Approver: (예외 조정 사유/승인자)
+
+## Optional Automation Assets
+
+1. CSV 템플릿: .github/templates/planning-backlog-scores.template.csv
+2. 시트 템플릿: .github/templates/planning-scoring-sheet.template.csv
+3. 계산 스크립트: .github/tools/calc_priority_scores.sh
+4. 점수 산출물 저장 경로(기본): docs/sdlc/planning/planning-backlog-scores.out.csv
+5. Planning 본문 템플릿: .github/templates/planning-note.template.md
+
+### Automation Usage
+
+1. 백로그 항목을 CSV 템플릿에 입력한다.
+2. 스크립트를 실행해 wsjf_score/rice_score/selected_score/priority를 산출하고, 결과를 docs/sdlc/planning/planning-backlog-scores.out.csv에 저장한다.
+3. 산출 결과를 반복 계획 문서의 점수표 근거로 첨부한다.
+
+## Outputs
+
+1. 반복 계획(백로그 우선순위)
+2. 작업별 수용 기준
+3. 범위 경계(Out of Scope 포함)
+4. 우선순위 점수표(WSJF 또는 RICE 계산 근거 포함)
+
+## DoD (Exit)
+
+1. Design 단계에 전달 가능한 우선순위 백로그가 존재함
+2. 작업 단위별 완료 기준이 검증 가능 형태임
+3. 우선순위 상위 항목의 계산 근거와 조정 사유가 추적 가능함
@@ -0,0 +1,49 @@
+---
+applyTo: "**"
+description: "Use when: design, architecture, interface contracts, data flow"
+---
+
+# Stage 3 - Design
+
+## Purpose
+
+구현 전 구조와 인터페이스를 명확히 하여 재작업 위험을 줄인다.
+
+## Stage Contract
+
+| 항목 | 내용 |
+|---|---|
+| 입력 | confirmed 상태의 Planning 문서, 우선순위 작업, AC, 리스크 정보 |
+| 산출물 | Design 문서, 설계 대안 비교, 인터페이스/데이터 흐름, 테스트 전략 |
+| 게이트 확인 | 구현 가능한 설계 근거, 인터페이스, 테스트 포인트, 리스크 대응이 모두 존재해야 함 |
+| 다음 단계 인계 | Implementation에 파일 변경 방향, 작업 분해 기준, 검증 포인트를 전달 |
+
+## DoR (Entry)
+
+1. Planning 백로그와 수용 기준 존재
+2. 핵심 제약사항이 식별됨
+
+## Required Actions
+
+1. 설계 선택지 비교: 최소 2개 대안을 비교해 근거를 남긴다.
+2. 인터페이스 정의: 입력/출력/오류 경로를 명시한다.
+3. 데이터/흐름 설계: 주요 데이터 경로와 상태 변화를 정리한다.
+4. 테스트 전략 연계: 설계와 검증 포인트를 매핑한다.
+
+## Outputs
+
+1. 설계 결정 기록(ADR 또는 동등 문서)
+2. 인터페이스/데이터 흐름 정의
+3. 테스트 가능성 관점의 설계 메모
+
+## Automation Assets
+
+1. Design 본문 템플릿: .github/templates/design-note.template.md
+2. Design 초안 프롬프트: .github/prompts/design-draft.prompt.md
+3. Design 재검토 프롬프트: .github/prompts/design-review.prompt.md
+4. Design 승인 프롬프트: .github/prompts/design-confirm.prompt.md
+
+## DoD (Exit)
+
+1. Implementation에서 바로 실행 가능한 설계 근거가 존재함
+2. 주요 리스크에 대한 대응 전략이 설계에 반영됨
@@ -0,0 +1,49 @@
+---
+applyTo: "**"
+description: "Use when: coding, refactoring, implementation tasks"
+---
+
+# Stage 4 - Implementation
+
+## Purpose
+
+설계를 기반으로 변경을 구현하고 테스트 가능한 상태로 만든다.
+
+## Stage Contract
+
+| 항목 | 내용 |
+|---|---|
+| 입력 | confirmed 상태의 Design 문서, 작업별 AC, 구현 범위, 테스트 전략 |
+| 산출물 | 코드 변경, 테스트 변경, 변경 근거 요약 |
+| 게이트 확인 | 최소 단위 테스트 또는 동등 검증 근거가 있고 Verification 시나리오 전달 준비가 되어야 함 |
+| 다음 단계 인계 | Verification에 변경 파일, 실행 근거, 알려진 리스크, 회귀 영향 영역을 전달 |
+
+## DoR (Entry)
+
+1. 설계 근거 및 작업 수용 기준 존재
+2. 구현 범위가 명확함
+
+## Required Actions
+
+1. 작은 단위 구현: 변경을 작고 검증 가능한 단위로 나눈다.
+2. 테스트 동반: 가능한 경우 테스트를 함께 작성/갱신한다.
+3. 영향도 점검: 관련 문서/설정/의존성 영향을 확인한다.
+4. 추적 가능성 유지: 어떤 요구사항을 반영했는지 연결한다.
+
+## Outputs
+
+1. 코드 변경
+2. 테스트 변경
+3. 변경 근거 요약
+
+## Automation Assets
+
+1. Implementation 본문 템플릿: .github/templates/implementation-note.template.md
+2. Implementation 초안 프롬프트: .github/prompts/implementation-draft.prompt.md
+3. Implementation 실행 프롬프트: .github/prompts/implementation.prompt.md
+4. Implementation 승인 프롬프트: .github/prompts/implementation-confirm.prompt.md
+
+## DoD (Exit)
+
+1. 최소 단위 테스트 또는 동등 검증 근거 통과
+2. Verification 단계에서 실행할 검증 시나리오가 준비됨
@@ -0,0 +1,117 @@
+---
+applyTo: "**"
+description: "Use when: verification, test review, regression checks, quality gate"
+---
+
+# Stage 5 - Verification
+
+## Purpose
+
+변경이 요구사항을 만족하고 기존 동작을 해치지 않았는지 확인한다.
+
+## Stage Contract
+
+| 항목 | 내용 |
+|---|---|
+| 입력 | Implementation 변경 결과, 테스트 시나리오, 수용 기준, 리스크 정보 |
+| 산출물 | 검증 결과 요약, 결함 목록, 품질 게이트 판정, 배포 가능 여부 |
+| 게이트 확인 | Blocker 0건, Major 0건 또는 승인된 예외, 테스트 근거 첨부 상태여야 함 |
+| 다음 단계 인계 | Release에 배포 가능 여부, 예외 승인 정보, 잔여 리스크를 전달 |
+
+## DoR (Entry)
+
+1. Implementation 산출물 존재
+2. 수용 기준과 테스트 시나리오 존재
+
+## Required Actions
+
+1. 수용 기준 검증: AC 충족 여부를 확인한다.
+2. 회귀 리스크 점검: 영향 영역을 기반으로 회귀 테스트를 수행한다.
+3. 결함 분류: Blocker/Major/Minor로 구분한다.
+4. 배포 준비성 판단: 잔여 리스크와 우회책을 기록한다.
+
+## Strict Quality Gates
+
+1. Blocker 결함 1건 이상이면 자동 배포 불가 상태로 분류한다.
+2. Major 결함은 승인된 예외 없이 0건이어야 한다.
+3. 변경 코드 경로의 테스트 실행 증거(로그/리포트)가 없으면 검증 실패로 처리한다.
+4. 신규 기능은 최소 1개의 정상 경로 테스트와 1개의 예외 경로 테스트를 포함해야 한다.
+5. 회귀 테스트에서 실패가 발생하면 원인 분석 또는 롤백 계획 없이 통과 처리할 수 없다.
+6. 보안 또는 데이터 무결성 관련 변경은 전용 체크 항목 결과를 첨부해야 한다.
+
+## Defect Severity Policy
+
+1. Blocker: 서비스 중단, 데이터 손실/오염, 보안 취약점 악용 가능 상태
+2. Major: 핵심 기능 오동작, 우회 가능하지만 사용자 영향이 큰 결함
+3. Minor: 비핵심 기능 이슈, 문구/표시 오류, 영향이 제한적인 결함
+
+## Required Evidence
+
+1. AC별 검증 결과(통과/실패/보류)
+2. 테스트 실행 결과 요약(실행 범위, 실패 항목, 재현 여부)
+3. 잔여 리스크와 완화책
+4. 승인된 예외 목록(사유, 승인자, 유효 기간)
+
+## Exception Approval Workflow (Template)
+
+1. Trigger: Major 결함 또는 검증 미충족 항목이 릴리즈 일정상 즉시 수정 불가
+2. Draft Exception: 요청자(보통 Builder/Reviewer)가 아래 템플릿 작성
+3. Review: Reviewer가 영향도와 완화책 타당성 검토
+4. Approve: 지정 승인자(예: Tech Lead, QA Lead, Product Owner) 중 최소 1명 승인
+5. Expiry Control: 유효 기간 만료 전 재검증 또는 예외 연장 재승인
+6. Closure: 예외 해소 후 결과와 증빙을 검증 리포트에 반영
+
+## Approval Authority Matrix
+
+1. Minor + Low/Medium Risk: Reviewer 또는 QA Lead 단독 승인 가능, 최대 유효기간 14일
+2. Major + Medium Risk: Reviewer 검토 후 Tech Lead + QA Lead 2인 승인, 최대 유효기간 7일
+3. Major + High Risk: Reviewer 검토 후 Tech Lead + Product Owner 2인 승인, 최대 유효기간 3일
+4. Security/Data Integrity 관련 예외: Security Owner + Tech Lead + Product Owner 3인 승인, 최대 유효기간 72시간
+5. 동일 예외 2회 이상 연장은 최초 승인자 외 추가 승인자 1인 이상이 필요
+
+## Approval Policy Rules
+
+1. 승인자는 요청자(작성자)와 동일 인물일 수 없다.
+2. Valid Until은 UTC 기준으로 명시하며 만료 시 자동 재검증 상태로 전환한다.
+3. 만료 전 재검증 실패 시 예외는 즉시 종료되고 배포 가능 상태를 재평가한다.
+4. 예외 승인 건은 Release 전달 시 승인 이력(승인자, 시각, 유효기간)을 포함해야 한다.
+
+### Exception Record Template
+
+| Field | Value |
+|---|---|
+| Exception ID | EX-YYYYMMDD-001 |
+| Related Change |  |
+| Defect Severity | Major / Minor |
+| Reason |  |
+| User Impact |  |
+| Risk Level | High / Medium / Low |
+| Mitigation |  |
+| Approver(s) |  |
+| Approval Scope | Minor-Low/Medium, Major-Medium, Major-High, Security/Data Integrity |
+| Approved At (UTC) |  |
+| Valid Until (UTC) |  |
+| Re-validation Owner |  |
+| Re-validation Date |  |
+| Final Closure Evidence |  |
+
+## Outputs
+
+1. 검증 결과 요약
+2. 발견 결함 목록 및 우선순위
+3. 배포 가능 여부 판단
+4. 품질 게이트 체크 결과(통과/실패 + 근거)
+
+## Automation Assets
+
+1. Verification 본문 템플릿: .github/templates/verification-note.template.md
+2. Verification 초안 프롬프트: .github/prompts/verification-draft.prompt.md
+3. Verification 재검토 프롬프트: .github/prompts/verification-review.prompt.md
+4. Verification 승인 프롬프트: .github/prompts/verification-confirm.prompt.md
+
+## DoD (Exit)
+
+1. Blocker 결함 0건
+2. Major 결함 0건 또는 승인된 예외 문서 존재
+3. 테스트 및 회귀 검증 근거가 첨부됨
+4. Release 단계 전달 가능한 품질 상태 보고가 있음
@@ -0,0 +1,72 @@
+---
+applyTo: "**"
+description: "Use when: release planning, deployment readiness, rollback planning"
+---
+
+# Stage 6 - Release
+
+## Purpose
+
+배포 전후 위험을 통제하고 안정적으로 변경을 반영한다.
+
+## Stage Contract
+
+| 항목 | 내용 |
+|---|---|
+| 입력 | Verification 결과, 배포 대상 범위, 승인된 예외, 롤백 필요 정보 |
+| 산출물 | 배포 체크리스트 결과, 롤백 계획, 릴리즈 노트, 관찰 계획 |
+| 게이트 확인 | 롤백 가능한 배포 계획과 운영 관찰 항목이 준비되어야 함 |
+| 다음 단계 인계 | Operations에 관찰 포인트, 장애 트리거, 후속 대응 절차를 전달 |
+
+## DoR (Entry)
+
+1. Verification 결과 존재
+2. 배포 대상 범위가 확정됨
+
+## Required Actions
+
+1. 배포 체크리스트 점검: 설정, 마이그레이션, 호환성 확인
+2. 롤백 계획 준비: 실패 조건과 복구 절차 명시
+3. 커뮤니케이션 준비: 변경사항/영향/대응 안내 작성
+4. 배포 후 관찰 계획: 모니터링 포인트 정의
+5. 롤백 런북 작성: 분리된 템플릿 파일을 기반으로 Trigger/Procedure/Validation을 채운다.
+6. 서비스별 런북 인스턴스 최신화: 배포 대상 서비스별 문서를 최신 상태로 유지한다.
+
+## Release Checklist (Detailed)
+
+1. 설정 검증: 환경 변수, 시크릿, 외부 연동 키 유효성 확인
+2. 데이터 검증: 마이그레이션 순서, 백업 상태, 복구 가능성 확인
+3. 호환성 검증: 이전 버전 클라이언트/API 호환 여부 확인
+4. 의존성 검증: 신규/변경 라이브러리 버전 충돌 여부 확인
+5. 트래픽 전략: 점진 배포/일괄 배포 방식과 중단 기준 확인
+6. 커뮤니케이션: 사용자 공지, 내부 공지, 온콜 담당자 공유 완료
+
+## Rollback Checklist (Detailed)
+
+1. 롤백 트리거 정의: 에러율/지연/장애 지표 임계치 명시
+2. 롤백 절차 문서화: 실행 명령, 순서, 책임자, 예상 소요 시간
+3. 데이터 롤백 전략: 스키마/데이터 복원 여부와 절차 명시
+4. 검증 절차: 롤백 후 핵심 시나리오 정상 동작 확인 항목 정의
+5. 커뮤니케이션 절차: 롤백 선언, 영향 공지, 상태 업데이트 채널 명시
+6. 사후 조치: 원인 분석 티켓과 재배포 조건 등록
+
+## Outputs
+
+1. 배포 체크리스트 결과
+2. 롤백 계획
+3. 릴리즈 노트 초안
+4. 롤백 실행 런북(.github/templates/rollback-runbook.template.md 기반)
+5. 서비스별 롤백 런북 인스턴스(.github/runbooks/services/*.rollback-runbook.md)
+
+## Automation Assets
+
+1. Release 본문 템플릿: .github/templates/release-note.template.md
+2. Release 초안 프롬프트: .github/prompts/release-draft.prompt.md
+3. Release 재검토 프롬프트: .github/prompts/release-review.prompt.md
+4. Release 승인 프롬프트: .github/prompts/release-confirm.prompt.md
+
+## DoD (Exit)
+
+1. 롤백 가능한 배포 계획이 승인됨
+2. 운영 관찰 항목이 정의됨
+3. 릴리즈/롤백 체크리스트가 근거와 함께 완료됨
@@ -0,0 +1,78 @@
+---
+applyTo: "**"
+description: "Use when: operations, monitoring, incident handling, postmortem"
+---
+
+# Stage 7 - Operations
+
+## Purpose
+
+배포 후 서비스 상태를 관찰하고 문제를 빠르게 복구하며 학습을 축적한다.
+
+## Stage Contract
+
+| 항목 | 내용 |
+|---|---|
+| 입력 | Release 결과, 관찰 포인트, 롤백/장애 대응 절차 |
+| 산출물 | 운영 상태 리포트, 인시던트 기록, Postmortem, 개선 백로그 |
+| 게이트 확인 | 운영 이슈가 추적 가능하게 기록되고 다음 사이클 입력으로 연결되어야 함 |
+| 다음 단계 인계 | Discovery/Planning에 운영 학습과 개선 항목을 환류 |
+
+## DoR (Entry)
+
+1. Release 완료
+2. 모니터링 포인트가 정의됨
+
+## Required Actions
+
+1. 상태 모니터링: 지표/로그/알림을 확인한다.
+2. 이슈 대응: 장애 영향도와 복구 우선순위를 판단한다.
+3. 사후분석: 원인, 탐지, 대응, 재발방지 항목을 기록한다.
+4. 환류 연결: 개선 항목을 Discovery/Planning 입력으로 등록한다.
+
+## Incident Checklist (Detailed)
+
+1. 영향도 분류: 사용자 영향 범위, 기능 영향, 데이터 영향 분류
+2. 타임라인 기록: 탐지 시각, 대응 시작, 완화 시각, 복구 완료 시각
+3. 커뮤니케이션 기록: 공지 채널, 공지 시각, 담당자, 업데이트 주기
+4. 우회책 실행 여부: 임시 완화 조치와 한계 기록
+5. 재발 위험 평가: 동일 패턴 재발 가능성 및 단기 통제 방안 기록
+
+## Postmortem Checklist (Detailed)
+
+1. What Happened: 사건 개요와 사용자 관찰 증상
+2. Impact: 서비스/사용자/비즈니스 영향 정량화
+3. Root Cause: 기술적 원인과 시스템적 원인 분리
+4. Detection: 탐지 경로, 지연 요인, 알림 품질 평가
+5. Response: 대응 의사결정과 실행 타임라인 평가
+6. Recovery: 복구 절차와 검증 결과
+7. Preventive Actions: 재발 방지 액션 아이템(담당자, 마감일 포함)
+8. Follow-up Tracking: Discovery/Planning 백로그 연결 상태
+
+## Outputs
+
+1. 운영 상태 리포트
+2. 인시던트 기록 및 Postmortem
+3. 다음 반복을 위한 개선 백로그
+4. 액션 아이템 추적표(Owner, Due Date, Status)
+
+## Automation Assets
+
+1. Operations 본문 템플릿: .github/templates/operations-note.template.md
+2. Operations 초안 프롬프트: .github/prompts/operation-draft.prompt.md
+3. Operations 재검토 프롬프트: .github/prompts/operation-review.prompt.md
+4. Operations 승인 프롬프트: .github/prompts/operation-confirm.prompt.md
+5. Operations 본문 저장 경로(기본): docs/sdlc/operations/
+6. Operations 문서 ID 패턴: ops-<3자리순차>_YYYY-MM-DD_<topic-slug>.operations.md
+
+### Automation Usage
+
+1. Release 부터 Operations 초안 자동 생성: `/operation-draft rel-001`
+2. Operations 문서 검토: `/operation-review rel-001` (단순 검토, 수정 없음)
+3. Operations 승인 처리: `/operation-confirm rel-001` (confirmed 상태 전환 + 플레이스홀더 정리)
+
+## DoD (Exit)
+
+1. 운영 이슈가 추적 가능한 티켓/백로그로 전환됨
+2. 학습 사항이 다음 사이클 입력으로 연결됨
+3. Postmortem 체크리스트가 누락 없이 작성됨