Squashed '.vendor/stage-pilot/' changes from c24b25d..3a72413

3a72413 Merge pull request #5 from genichin/copilot/add-verification-steps-sdlc-prompt
d362b6b feat: add verification stage to run-sdlc pipeline
9b52ae1 Initial plan
893d465 Merge pull request #3 from genichin/copilot/add-sdlc-prompt-feature
57b3941 feat: add /run-sdlc prompt for automated SDLC pipeline execution
27396ab Initial plan
6979011 Clarify draft creation for new SDLC prompts
1c5557b fix(bootstrap): sdlc 디렉토리 구조 단순화 및 summary 템플릿 추가
af343e5 docs(prompt): SDLC 프롬프트 저장소 현황 탐색 및 대조 절차 강화
cc55e06 chore: Release/Operations 프로세스 템플릿 및 프롬프트 추가 및 README 최신화
386695b commit
4533017 draft
82b7690 draft-design
0503411 draft
9984db0 confirm-discovery, draft-planning, review-planning 명령 추가
cba64f0 add confirm-discovery prompt
9391537 draft
58f2de8 feat: execute implementation during run-sdlc flow
693e3f6 feat: auto-create downstream drafts in run-sdlc
404bc63 docs: translate SDLC orchestration prompts to English
9018e8f feat: add SDLC scaffold and sequential run commands
d60e21c docs: clarify when to create a new discovery
0629eee feat: add operation issue triage prompt
cdc8d87 feat: make update.sh auto-overwrite by default with --no-overwrite option
ead06c2 chore: add execute tool to all prompt files

git-subtree-dir: .vendor/stage-pilot
git-subtree-split: 3a72413acd2edd95053631f900d3c99c1caef359

.github/instructions/01-discovery.instructions.md

@@ -1,108 +0,0 @@
----
-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로 정리됨

.github/instructions/02-planning.instructions.md

@@ -1,114 +0,0 @@
----
-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. 우선순위 상위 항목의 계산 근거와 조정 사유가 추적 가능함

.github/instructions/03-design.instructions.md

@@ -1,49 +0,0 @@
----
-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. 주요 리스크에 대한 대응 전략이 설계에 반영됨

.github/instructions/04-implementation.instructions.md

@@ -1,49 +0,0 @@
----
-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 단계에서 실행할 검증 시나리오가 준비됨

.github/instructions/05-verification.instructions.md

@@ -1,117 +0,0 @@
----
-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 단계 전달 가능한 품질 상태 보고가 있음

.github/instructions/06-release.instructions.md

@@ -1,72 +0,0 @@
----
-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. 릴리즈/롤백 체크리스트가 근거와 함께 완료됨

.github/instructions/07-operations.instructions.md

@@ -1,78 +0,0 @@
----
-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 체크리스트가 누락 없이 작성됨

.github/instructions/placeholder-guide.md

@@ -0,0 +1,243 @@
+# 플레이스홀더 가이드
+
+이 파일은 `.github/templates/` 및 `.github/prompts/`에서 사용하는 `{{...}}` 플레이스홀더의 문법, 처리 주체, 전체 목록을 정의한다.
+템플릿을 수정하거나 새 프롬프트를 작성할 때 이 파일을 기준으로 한다.
+
+---
+
+## 1. 문법 규칙
+
+| 형식 | 의미 | 예시 |
+|---|---|---|
+| `{{KEY}}` | 단순 치환 대상. 힌트 없음. | `{{CYCLE_ID}}` |
+| `{{KEY:hint}}` | 힌트 포함. 치환 시 힌트 텍스트도 함께 제거. | `{{CREATED_AT_KST:TBD}}` |
+| `{{KEY:opt1\|opt2\|opt3}}` | 열거형. 나열된 값 중 하나를 선택. | `{{DOC_STATUS:draft\|review\|confirmed}}` |
+| `{{KEY_N_DECISION:hint}}` | AI agent가 섹션 본문에 임시로 삽입하는 판단 대기 마커. `review-discovery` 등 검토 단계에서 실제 문장으로 치환하거나 `#10`으로 이동. | `{{TARGET_STATE_2_DECISION:...}}` |
+
+> **규칙**: 플레이스홀더를 채울 때는 `{{...}}` 전체를 값으로 교체한다. 힌트나 파이프(`|`) 열거는 최종 문서에 남기지 않는다.
+
+---
+
+## 2. 처리 주체 분류
+
+플레이스홀더는 **누가 채워야 하는가**에 따라 세 가지로 나뉜다.
+
+### A. 자동 치환 (Auto — 프롬프트 실행 시 agent가 즉시 채움)
+
+| 키 | 치환 값 | 사용 위치 |
+|---|---|---|
+| `{{DOC_STATUS}}` / `{{DOC_STATUS:draft\|review\|confirmed}}` | `draft` | 모든 SDLC 문서 `#0` |
+| `{{CYCLE_ID}}` / `{{CYCLE_ID:sdlc-<3자리>_<YYYYMMDD>_<topic-slug>}}` | 계산된 주기 ID | 모든 SDLC 문서 `#0`, index, summary |
+| `{{ISSUE_NAME}}` / `{{ISSUE_NAME:...}}` | 사용자 입력 원문 | 모든 SDLC 문서 `#0`, summary |
+| `{{CREATED_AT_KST}}` / `{{CREATED_AT_KST:TBD}}` | 현재 시각 (KST) | 모든 SDLC 문서 `#0`, summary |
+| `{{UPDATED_AT_KST}}` / `{{UPDATED_AT_KST:TBD}}` | 현재 시각 (KST) | 모든 SDLC 문서 `#0`, summary |
+| `{{OUTPUT_PATH}}` | 생성 파일 경로 | `1_discovery.md` `#9` |
+| `{{FILE_RESULT}}` / `{{FILE_RESULT:생성\|갱신\|미생성}}` | `생성` (신규) 또는 `갱신` | `1_discovery.md` `#9` |
+| `{{SUMMARY_STATUS}}` / `{{SUMMARY_STATUS:draft\|review\|confirmed}}` | `draft` | `summary.md` |
+
+---
+
+### B. AI 추론 치환 (Infer — agent가 입력 요청과 저장소 맥락을 바탕으로 초안을 채움)
+
+> 입력만으로 합리적 추론이 가능한 항목은 플레이스홀더로 남기지 않고 자연어 문장으로 채운다.
+> 추론이 불확실한 경우에는 `_DECISION` 접미사 형태로 남기고 `review-discovery` 단계에서 처리한다.
+
+| 키 | 설명 | 위치 |
+|---|---|---|
+| `{{PLANNING_SCORE_FILE}}` | Planning 점수 파일 경로 또는 `미생성` | `#1` |
+| `{{TODO_FILE}}` | 관련 TODO/메모 경로 또는 `없음` | `#1` |
+| `{{SUMMARY_LINE_1}}`, `{{SUMMARY_LINE_2}}` | 현재 검토 배경 및 이번 Discovery 핵심 요약 | `#1` |
+| `{{REQUIREMENT_CLASSIFICATION}}` | `신규` / `유사` / `완전 중복` | `#2` |
+| `{{CLASSIFICATION_REASON_1}}`, `{{CLASSIFICATION_REASON_2}}` | 판정 근거 2줄 | `#2` |
+| `{{CURRENT_STATE_1}}`, `{{CURRENT_STATE_2}}` | 현재 문제 상태 | `#3` |
+| `{{TARGET_STATE_1}}`, `{{TARGET_STATE_2}}` | 기대 상태 | `#3` |
+| `{{STAKEHOLDER_1~3}}` | 이해관계자 | `#3` |
+| `{{CONSTRAINT_1}}`, `{{CONSTRAINT_2}}` | 제약사항 | `#3` |
+| `{{USER_SCENARIO_1~3}}` | 주요 사용자 시나리오 | `#3` |
+| `{{CHANGE_ITEM_1~3}}` | 핵심 변경 항목 | `#4` |
+| `{{CODE_IMPACT_1~2}}`, `{{DOC_IMPACT_1~2}}`, `{{OPS_IMPACT_1~2}}` | 영향 범위 | `#4` |
+| `{{FR_1~4}}` | 기능 요구사항 (최소 2개) | `#5` |
+| `{{NFR_1~3}}` | 비기능 요구사항 (최소 1개) | `#5` |
+| `{{IN_SCOPE_1~2}}`, `{{OUT_OF_SCOPE_1~2}}` | 범위 경계 | `#5` |
+| `{{RISK_LEVEL_1~3}}`, `{{RISK_1~3}}`, `{{MITIGATION_1~3}}` | 리스크 항목 (최소 2개) | `#6` |
+| `{{ASSUMPTION_1~3}}` | 가정 (최소 2개) | `#6` |
+| `{{OPEN_QUESTION_1~3}}`, `{{OPEN_QUESTION_STATUS_1~3}}` | 오픈 질문 | `#6` |
+| `{{OPEN_QUESTION_ACTION_1~3}}`, `{{OPEN_QUESTION_EXIT_1~3}}` | 오픈 질문 처리 방안/종료 조건 | `#6` |
+| `{{SUCCESS_METRIC_1~3}}` | 성공 기준 (최소 2개) | `#7` |
+| `{{MEASURE_METHOD_1~3}}`, `{{MEASURE_SOURCE_1~3}}` | 측정 방식 및 데이터 출처 | `#7` |
+| `{{CHECK_SCOPE_CRITERIA}}` | 범위 확정 기준 | `#8` |
+| `{{CHECK_METRICS_CRITERIA}}` | 성공 지표 확정 기준 | `#8` |
+| `{{CHECK_RISK_OWNER_CRITERIA}}` | 리스크 책임자 지정 기준 | `#8` |
+| `{{CHECK_CONFIRMEDBY_CRITERIA}}` | Freeze 담당자 지정 기준 | `#8` |
+| `{{REFERENCE_1~3}}` | 참조 문서 목록 | `#9` |
+| `{{SUMMARY_POINT_1~2}}` | summary.md 핵심 요약 | `summary.md` |
+
+---
+
+### C. 사용자 결정 필요 (Decide — 자동 추론 불가, 사용자/승인자가 직접 채워야 함)
+
+> 이 항목들은 `#10 사용자 결정 필요 항목 요약`에 모아서 관리한다.
+> 섹션 본문에는 최소 플레이스홀더만 남기거나 맥락 설명 문장으로 대체한다.
+
+| 키 | 설명 | 위치 |
+|---|---|---|
+| `{{DECIDE_ITEM_1~2}}` | 정책/구조 결정이 필요한 항목 | `#10 > DECIDE` |
+| `{{CONFIRM_ITEM_1~2}}` | 범위나 책임자 확인이 필요한 항목 | `#10 > CONFIRM` |
+| `{{DATA_ITEM_1~2}}` | 외부 데이터나 환경 정보가 필요한 항목 | `#10 > DATA` |
+| `{{FREEZE_HANDOFF_DECISION}}` | Planning 진행 가능 여부 (`Planning 진행 가능` / `보류`) | `#11` |
+| `{{FREEZE_HANDOFF_RATIONALE}}` | Handoff Decision 판단 근거 | `#11` |
+| `{{READY_FOR_PLANNING}}` | `true` / `false` | `#11` |
+| `{{CONFIRMED_BY}}` | Freeze 확정 담당자 이름 | `#11` |
+| `{{CONFIRMED_AT_KST}}` | Freeze 확정 시각 (KST) | `#11` |
+
+---
+
+## 3. `_DECISION` 접미사 패턴
+
+섹션 본문에 판단이 필요한 항목이 생겼을 때 AI agent가 임시로 삽입하는 마커이다.
+
+- **형식**: `{{원래키_N_DECISION:판단 내용 또는 질문}}`
+- **예시**: `{{TARGET_STATE_2_DECISION:README 확장으로 할지, 별도 파일로 분리할지 결정 필요}}`
+- **처리 규칙**:
+  - `review-discovery` 프롬프트 실행 시 각 항목을 검토하여 아래 중 하나로 처리한다.
+    - 추론 가능 → 자연어 문장으로 치환
+    - 사용자 결정 필요 → `#10`으로 이동하고 본문은 맥락 설명 문장으로 대체
+
+---
+
+---
+
+## Planning 전용 플레이스홀더 (`2_planning.md`)
+
+### A. 자동 치환 (Auto)
+
+| 키 | 치환 값 | 사용 위치 |
+|---|---|---|
+| `{{DISCOVERY_PATH}}` | `docs/sdlc/<CYCLE_ID>/1_discovery.md` | `#0`, `#9` |
+
+### B. AI 추론 치환 (Infer)
+
+| 키 | 설명 | 위치 |
+|---|---|---|
+| `{{PLANNING_ISSUE_PURPOSE}}` | Discovery 이슈명과 핵심 목적 요약 | `#1` |
+| `{{PLANNING_IN_SCOPE_1~2}}` | Discovery `#5`에서 이식한 In Scope | `#1` |
+| `{{PLANNING_OUT_OF_SCOPE_1~2}}` | Discovery `#5`에서 이식한 Out of Scope | `#1` |
+| `{{PLANNING_FR_1~4}}` | Discovery `#5` FR 요약 | `#1` |
+| `{{PLANNING_NFR_1~2}}` | Discovery `#5` NFR 요약 | `#1` |
+| `{{DEFERRED_ITEM_1~2}}` | Discovery `#6`에서 Deferred 처리된 오픈 질문 | `#1` |
+| `{{TASK_TITLE_N}}` | FR/NFR 기반 태스크 제목 | `#2` |
+| `{{TASK_TYPE_N}}` | 태스크 유형 (`개발\|문서\|검토\|설계\|운영`) | `#2` |
+| `{{TASK_REF_N}}` | 참조 요구사항 ID (예: `FR-1`) | `#2` |
+| `{{TASK_DEP_N}}` | 의존 태스크 ID 또는 `-` | `#2` |
+| `{{TASK_DOD_N}}` | 태스크 완료 조건 | `#2` |
+| `{{EFFORT_N}}` | 추정 공수 (숫자 또는 범위) | `#3` |
+| `{{EFFORT_UNIT}}` | 공수 단위 (`SP\|시간\|일`) | `#3` |
+| `{{EFFORT_NOTE_N}}` | 공수 추정 비고 | `#3` |
+| `{{TOTAL_EFFORT}}` | 총 추정 공수 | `#3` |
+| `{{EFFORT_CONFIDENCE}}` | 추정 신뢰도 (`High\|Medium\|Low`) | `#3` |
+| `{{EFFORT_BASIS}}` | 추정 근거 | `#3` |
+| `{{MILESTONE_N_NAME}}` | 마일스톤 이름 | `#4` |
+| `{{MILESTONE_N_TASKS}}` | 마일스톤 포함 태스크 목록 | `#4` |
+| `{{MILESTONE_N_DONE}}` | 마일스톤 완료 조건 | `#4` |
+| `{{ITERATION_UNIT}}` | 이터레이션 단위 | `#4` |
+| `{{ITERATION_N_TASKS}}` | 이터레이션 N 포함 태스크 | `#4` |
+| `{{TASK_DEPENDENCY_N}}` | 태스크 간 의존 관계 설명 | `#5` |
+| `{{EXTERNAL_DEP_N}}` | 외부 의존성 항목 | `#5` |
+| `{{TECH_CONSTRAINT_N}}` | 기술/환경 제약 | `#5` |
+| `{{VERIFY_CRITERIA_N}}` | 검증 대상 성공 기준 (Discovery S-N 요약) | `#6` |
+| `{{VERIFY_METHOD_N}}` | 검증 방법 초안 | `#6` |
+| `{{PLAN_RISK_LEVEL_N}}` | Planning 리스크 등급 | `#7` |
+| `{{PLAN_RISK_N}}` | Planning 리스크 내용 | `#7` |
+| `{{PLAN_MITIGATION_N}}` | 리스크 완화 방안 | `#7` |
+| `{{PLAN_ASSUMPTION_N}}` | Planning 단계 가정 | `#7` |
+| `{{PLAN_OPEN_QUESTION_N}}` | Planning 오픈 질문 | `#7` |
+| `{{PLAN_OQ_STATUS_N}}` | 오픈 질문 상태 | `#7` |
+| `{{PLAN_OQ_ACTION_N}}` | 오픈 질문 처리 방안 | `#7` |
+| `{{PLAN_OQ_EXIT_N}}` | 오픈 질문 종료 조건 | `#7` |
+| `{{CHECK_TASKS_CRITERIA}}` | 태스크 확정 기준 | `#8` |
+| `{{CHECK_EFFORT_CRITERIA}}` | 공수 추정 확정 기준 | `#8` |
+| `{{CHECK_SCHEDULE_CRITERIA}}` | 일정 확정 기준 | `#8` |
+| `{{CHECK_DEP_CRITERIA}}` | 외부 의존성 해소 기준 | `#8` |
+
+### C. 사용자 결정 필요 (Decide)
+
+| 키 | 설명 | 위치 |
+|---|---|---|
+| `{{TASK_OWNER_N}}` | 태스크 담당자 | `#2` |
+| `{{MILESTONE_N_DATE}}` | 마일스톤 목표 날짜 | `#4` |
+| `{{ITERATION_N_PERIOD}}` | 이터레이션 날짜 범위 | `#4` |
+| `{{VERIFY_OWNER_N}}` | 검증 담당자 | `#6` |
+| `{{FREEZE_HANDOFF_DECISION}}` | Design 진행 가능 여부 | `#11` |
+| `{{FREEZE_HANDOFF_RATIONALE}}` | Handoff Decision 판단 근거 | `#11` |
+| `{{READY_FOR_DESIGN}}` | `true` / `false` | `#11` |
+| `{{CONFIRMED_BY}}` | Freeze 확정 담당자 이름 | `#11` |
+| `{{CONFIRMED_AT_KST}}` | Freeze 확정 시각 (KST) | `#11` |
+
+---
+
+## Design 전용 플레이스홀더 (`3_design.md`)
+
+### A. 자동 치환 (Auto)
+
+| 키 | 치환 값 | 사용 위치 |
+|---|---|---|
+| `{{PLANNING_PATH}}` | `docs/sdlc/<CYCLE_ID>/2_planning.md` | `#0`, `#8` |
+
+### B. AI 추론 치환 (Infer)
+
+| 키 | 설명 | 위치 |
+|---|---|---|
+| `{{DESIGN_ISSUE_PURPOSE}}` | Planning 이슈명과 핵심 목적 요약 | `#1` |
+| `{{DESIGN_TASK_TITLE_N}}` | Planning `#2`에서 이식한 태스크 제목 | `#1` |
+| `{{DESIGN_TASK_REF_N}}` | Planning `#2`에서 이식한 참조 요구사항 | `#1` |
+| `{{DESIGN_DEFERRED_ITEM_N}}` | Planning `#7`에서 Deferred 처리된 오픈 질문 | `#1` |
+| `{{ARCH_OVERVIEW}}` | 전체 아키텍처/구조 개요 | `#2` |
+| `{{COMPONENT_N_NAME}}` | 주요 컴포넌트 이름 | `#2` |
+| `{{COMPONENT_N_ROLE}}` | 컴포넌트 역할 | `#2` |
+| `{{COMPONENT_N_SCOPE}}` | 컴포넌트 영향 범위 | `#2` |
+| `{{DATA_FLOW_N}}` | 데이터 흐름 단계 | `#2` |
+| `{{DESIGN_DETAIL_N}}` | 태스크별 설계 방향 | `#3` |
+| `{{DESIGN_TARGET_N}}` | 변경 대상 파일/함수/설정 | `#3` |
+| `{{DESIGN_IO_N}}` | 입력/출력 또는 사이드이펙트 | `#3` |
+| `{{DESIGN_EDGE_N}}` | 예외/엣지 케이스 | `#3` |
+| `{{INTERFACE_N}}` | API/함수 시그니처 | `#4` |
+| `{{SCHEMA_N}}` | 데이터 스키마/포맷 | `#4` |
+| `{{EVENT_N}}` | 이벤트/메시지 | `#4` |
+| `{{SEC_INJECTION}}` ~ `{{SEC_OTHER}}` | 보안 항목 해당 여부 | `#5` |
+| `{{SEC_INJECTION_ACTION}}` ~ `{{SEC_OTHER_ACTION}}` | 보안 대응 방안 | `#5` |
+| `{{DESIGN_RISK_LEVEL_N}}` | Design 리스크 등급 | `#6` |
+| `{{DESIGN_RISK_N}}` | Design 리스크 내용 | `#6` |
+| `{{DESIGN_MITIGATION_N}}` | 리스크 완화 방안 | `#6` |
+| `{{DESIGN_ASSUMPTION_N}}` | Design 단계 가정 | `#6` |
+| `{{DESIGN_OPEN_QUESTION_N}}` | Design 오픈 질문 | `#6` |
+| `{{DESIGN_OQ_STATUS_N}}` | 오픈 질문 상태 | `#6` |
+| `{{DESIGN_OQ_ACTION_N}}` | 오픈 질문 처리 방안 | `#6` |
+| `{{DESIGN_OQ_EXIT_N}}` | 오픈 질문 종료 조건 | `#6` |
+| `{{CHECK_DESIGN_COMPLETE}}` | 설계 완성 기준 | `#7` |
+| `{{CHECK_INTERFACE}}` | 인터페이스 확정 기준 | `#7` |
+| `{{CHECK_SECURITY}}` | 보안 점검 완료 기준 | `#7` |
+
+### C. 사용자 결정 필요 (Decide)
+
+| 키 | 설명 | 위치 |
+|---|---|---|
+| `{{DESIGN_TASK_OWNER_N}}` | 태스크 담당자 | `#1` |
+| `{{FREEZE_HANDOFF_DECISION}}` | Implementation 진행 가능 여부 | `#10` |
+| `{{FREEZE_HANDOFF_RATIONALE}}` | Handoff Decision 판단 근거 | `#10` |
+| `{{READY_FOR_IMPLEMENTATION}}` | `true` / `false` | `#10` |
+| `{{CONFIRMED_BY}}` | Freeze 확정 담당자 이름 | `#10` |
+| `{{CONFIRMED_AT_KST}}` | Freeze 확정 시각 (KST) | `#10` |
+
+---
+
+## 4. 참조 위치 요약
+
+| 파일 | 역할 | 관련 플레이스홀더 |
+|---|---|---|
+| `.github/prompts/new-sdlc.prompt.md` | 주기 생성, 자동/추론 치환 실행 | A, B 전체 |
+| `.github/prompts/review-discovery.prompt.md` | 검토, `_DECISION` 처리, 사용자 결정 항목 정리 | B (`_DECISION`), C |
+| `.github/prompts/draft-planning.prompt.md` | Planning 초안 생성, Discovery 내용 이식 | A, B 전체 (Planning) |
+| `.github/prompts/draft-design.prompt.md` | Design 초안 생성, Planning 내용 이식 | A, B 전체 (Design) |
+| `.github/templates/sdlc/1_discovery.md` | Discovery 원본 템플릿 | A, B, C 전체 |
+| `.github/templates/sdlc/2_planning.md` | Planning 원본 템플릿 | A, B, C 전체 (Planning) |
+| `.github/templates/sdlc/3_design.md` | Design 원본 템플릿 | A, B, C 전체 (Design) |