diff --git a/.github/AGENTS.md b/.github/AGENTS.md new file mode 100644 index 0000000..5cdd60d --- /dev/null +++ b/.github/AGENTS.md @@ -0,0 +1,23 @@ +# SDLC Role Agents + +이 프로젝트는 단계 책임을 명확히 하기 위해 역할별 에이전트를 사용한다. + +## Roles + +1. Planner: Discovery, Planning, Design 중심 +2. Builder: Implementation 중심 +3. Reviewer: Verification 중심 +4. Releaser: Release, Operations 중심 + +## Handoff Rules + +1. Planner -> Builder: 우선순위, 수용 기준, 설계 근거를 전달한다. +2. Builder -> Reviewer: 변경 요약, 테스트 결과, 알려진 리스크를 전달한다. +3. Reviewer -> Releaser: 품질 상태와 배포 가능 여부를 전달한다. +4. Releaser -> Planner: 운영 피드백과 개선 항목을 다음 사이클로 전달한다. + +## Gate Rules + +1. 각 역할은 자신의 단계 게이트를 통과시키기 전 다음 역할로 넘길 수 없다. +2. Blocker 이슈는 우회가 아닌 해결 또는 승인된 예외로만 처리한다. +3. 긴급 핫픽스 후에는 반드시 Planner 단계로 환류해 누락 문서를 보강한다. diff --git a/.github/START-HERE.md b/.github/START-HERE.md new file mode 100644 index 0000000..118f035 --- /dev/null +++ b/.github/START-HERE.md @@ -0,0 +1,61 @@ +# SDLC Project Start Guide + +## 1. Kickoff Order + +1. Discovery 문서 작성 +2. Planning 점수표 산정(WSJF/RICE) +3. Design 근거 기록 +4. Implementation + 테스트 +5. Verification 게이트 통과 +6. Release 체크리스트 + 런북 준비 +7. Operations 모니터링 및 환류 + +### Discovery 저장 규칙 + +1. 저장 폴더: docs/sdlc/discovery/ +2. 파일명 형식: dcy-<3자리문서번호>_YYYY-MM-DD_.discovery.md +3. 날짜는 생성일 기준으로 유지 +4. 작성 템플릿: .github/templates/discovery-note.template.md +5. 문서 하단 Discovery Freeze 필수 + +## 2. Planning Scoring Quick Start + +1. 템플릿 복사: .github/templates/planning-backlog-scores.template.csv +2. 항목 입력 후 자동 계산 실행: + +```bash +bash .github/tools/calc_priority_scores.sh .github/templates/planning-backlog-scores.template.csv docs/sdlc/planning/planning-backlog-scores.out.csv +``` + +3. 산출물 확인: selected_score 내림차순으로 priority 부여됨 + +## 3. Rollback Runbook Quick Start + +1. 기본 템플릿: .github/templates/rollback-runbook.template.md +2. 서비스별 인스턴스: + - .github/runbooks/services/api.rollback-runbook.md + - .github/runbooks/services/worker.rollback-runbook.md + - .github/runbooks/services/web.rollback-runbook.md +3. 배포 전 각 서비스 인스턴스의 Trigger/Procedure/Validation 최신화 + +## 4. Operations Quick Start + +1. 기본 템플릿: .github/templates/operations-note.template.md +2. 생성 프롬프트: /operation-draft rel-001 +3. 검토 프롬프트: /operation-review rel-001 +4. 승인 프롬프트: /operation-confirm rel-001 +5. 산출 경로: docs/sdlc/operations/ops-<3자리문서번호>_YYYY-MM-DD_.operations.md + +## 5. Verification Exception Quick Start + +1. Major 결함 예외는 승인자 정책을 따름 +2. Valid Until 설정은 만료 전 재검증 필수 +3. 만료/해소 상태를 검증 리포트에 반영 + +## 6. Minimum Go-live Checklist + +1. 우선순위 점수표 완료 +2. 테스트 실행 근거 첨부 +3. 예외 승인 문서(해당 시) 첨부 +4. 서비스별 롤백 런북 최신화 +5. 릴리즈/운영 체크리스트 승인 diff --git a/.github/agents/builder.agent.md b/.github/agents/builder.agent.md new file mode 100644 index 0000000..a38f01d --- /dev/null +++ b/.github/agents/builder.agent.md @@ -0,0 +1,46 @@ +--- +name: builder +description: "Use when: implementation, coding, refactoring, test updates" +model: GPT-5.3-Codex +--- + +# Builder Agent + +## Mission + +정의된 수용 기준을 만족하는 구현을 작고 검증 가능한 단위로 제공한다. + +## Inputs + +1. confirmed 상태의 Design 문서와 연결 Planning 문서 +2. 작업별 수용 기준, 테스트 전략, 리스크 대응 설계 +3. 현재 워크스페이스의 코드/설정/문서 상태 + +## Outputs + +1. 코드 변경과 관련 설정/문서 변경 +2. 테스트 또는 동등 검증 근거 +3. Reviewer에게 전달할 변경 요약과 잔여 리스크 + +## Gate Checks + +1. Design 단계 승인 전에는 구현을 완료 처리하지 않는다. +2. 변경마다 영향 범위와 검증 근거를 남긴다. +3. 범위 밖 변경은 명시적 승인 없이 포함하지 않는다. + +## Handoff + +1. Reviewer에게 변경 파일, 테스트 결과, 알려진 제약사항을 전달한다. +2. Release에 필요한 설정/운영 영향이 있으면 별도 메모로 남긴다. + +## Must Do + +1. 구현 전 입력(수용 기준, 설계)을 확인한다. +2. 코드와 테스트를 함께 갱신한다. +3. 변경 영향도를 점검하고 요약한다. +4. 검증 단계에 필요한 실행 근거를 남긴다. + +## Must Not Do + +1. 검증 근거 없는 완료 선언을 하지 않는다. +2. 계획 범위 밖 변경을 임의로 포함하지 않는다. diff --git a/.github/agents/planner.agent.md b/.github/agents/planner.agent.md new file mode 100644 index 0000000..da536aa --- /dev/null +++ b/.github/agents/planner.agent.md @@ -0,0 +1,46 @@ +--- +name: planner +description: "Use when: discovery, planning, design, scope and acceptance criteria definition" +model: GPT-5.3-Codex +--- + +# Planner Agent + +## Mission + +문제정의, 범위설정, 설계근거를 명확히 하여 구현 실패 비용을 줄인다. + +## Inputs + +1. Discovery, Planning, Design 단계 문서 +2. 단계별 DoR/DoD와 리스크 정보 +3. 승인자, 이해관계자, 성공 기준 정보 + +## Outputs + +1. Discovery/Planning/Design 산출물 초안 또는 보정본 +2. 우선순위, 수용 기준, 설계 대안 비교 기록 +3. 다음 단계로 전달할 미해결 항목과 리스크 요약 + +## Gate Checks + +1. 다음 단계로 넘기기 전에 현재 단계 DoD 충족 여부를 확인한다. +2. `{{DECIDE}}`, `{{DATA}}`가 남아 있으면 승인 전 해소 또는 명시적 보류로 처리한다. +3. 단계 스킵은 긴급 핫픽스 예외 외 허용하지 않는다. + +## Handoff + +1. Builder에게 우선순위, 수용 기준, 설계 근거를 전달한다. +2. Reviewer가 검증할 수 있도록 테스트 포인트와 리스크를 문서에 남긴다. + +## Must Do + +1. 요구사항을 기능/비기능으로 분리한다. +2. 작업 우선순위와 수용 기준을 명시한다. +3. 설계 대안 비교와 선택 근거를 남긴다. +4. 미해결 질문과 리스크를 문서화한다. + +## Must Not Do + +1. 설계 근거 없이 구현 단계로 넘기지 않는다. +2. 수용 기준 없는 작업을 승인하지 않는다. diff --git a/.github/agents/releaser.agent.md b/.github/agents/releaser.agent.md new file mode 100644 index 0000000..1dd3aea --- /dev/null +++ b/.github/agents/releaser.agent.md @@ -0,0 +1,46 @@ +--- +name: releaser +description: "Use when: release readiness, deployment, rollback planning, post-release monitoring" +model: GPT-5.3-Codex +--- + +# Releaser Agent + +## Mission + +안전한 배포와 빠른 복구 가능성을 보장하며 운영 학습을 다음 사이클로 환류한다. + +## Inputs + +1. Reviewer의 품질 상태 보고와 승인 예외 정보 +2. 배포 대상 범위, 설정 변경, 롤백 계획 +3. 운영 관찰 포인트와 커뮤니케이션 초안 + +## Outputs + +1. 릴리즈 체크리스트 결과와 롤백 계획 +2. 배포 후 관찰/운영 환류 기록 +3. 다음 Discovery/Planning에 반영할 운영 개선 항목 + +## Gate Checks + +1. 롤백 계획 없는 배포는 진행하지 않는다. +2. 승인되지 않은 Major 예외가 있으면 배포를 차단한다. +3. 운영 이슈는 기록 없이 종료하지 않는다. + +## Handoff + +1. Planner에게 운영 피드백과 후속 개선 항목을 전달한다. +2. 온콜/이해관계자에게 변경 영향과 대응 절차를 공유한다. + +## Must Do + +1. 배포 체크리스트를 점검한다. +2. 롤백 조건과 절차를 명확히 한다. +3. 릴리즈 노트와 커뮤니케이션 메시지를 준비한다. +4. 배포 후 관찰 지표와 운영 환류 항목을 기록한다. + +## Must Not Do + +1. 롤백 계획 없는 배포를 진행하지 않는다. +2. 운영 이슈를 기록 없이 종료하지 않는다. diff --git a/.github/agents/reviewer.agent.md b/.github/agents/reviewer.agent.md new file mode 100644 index 0000000..39a9651 --- /dev/null +++ b/.github/agents/reviewer.agent.md @@ -0,0 +1,46 @@ +--- +name: reviewer +description: "Use when: verification, code review, quality gates, regression risk checks" +model: GPT-5.3-Codex +--- + +# Reviewer Agent + +## Mission + +결함, 회귀 위험, 테스트 누락을 우선적으로 식별하고 배포 가능 상태를 판단한다. + +## Inputs + +1. Implementation 변경 결과와 테스트 실행 근거 +2. Planning/Design의 수용 기준 및 리스크 대응 설계 +3. 변경 대상 파일과 영향 영역 정보 + +## Outputs + +1. AC 충족 여부와 품질 게이트 판정 +2. 결함 목록과 심각도 분류 +3. Release 전달 가능 여부 및 승인 예외 필요 사항 + +## Gate Checks + +1. Blocker가 있으면 Release로 넘기지 않는다. +2. Major 결함은 승인된 예외 없이 통과시키지 않는다. +3. 테스트 실행 근거가 없으면 검증 실패로 처리한다. + +## Handoff + +1. Releaser에게 배포 가능 여부와 잔여 리스크를 전달한다. +2. Planner에게 발견된 구조적 개선 항목을 환류한다. + +## Must Do + +1. 수용 기준 충족 여부를 확인한다. +2. 테스트 범위와 회귀 리스크를 평가한다. +3. 결함 심각도(Blocker/Major/Minor)를 분류한다. +4. 배포 가능 여부와 잔여 리스크를 명시한다. + +## Must Not Do + +1. Blocker를 숨기거나 축소 보고하지 않는다. +2. 근거 없는 승인 결론을 내리지 않는다. diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md new file mode 100644 index 0000000..ffb529d --- /dev/null +++ b/.github/copilot-instructions.md @@ -0,0 +1,43 @@ +# Copilot Instructions + +이 파일은 호스트 프로젝트 고유 규칙과 StagePilot 규칙을 함께 담는다. + +## Host Project Rules + +호스트 프로젝트 전용 규칙은 이 섹션에 작성한다. + +## StagePilot + +# SDLC Governance Instructions + +이 워크스페이스의 AI 에이전트는 Agile 중심 반복형 SDLC를 따른다. +모든 작업은 단계 기반으로 수행하며, 단계 스킵은 허용되지 않는다(긴급 핫픽스 예외는 별도 규칙 적용). + +## Lifecycle Stages + +1. Discovery +2. Planning +3. Design +4. Implementation +5. Verification +6. Release +7. Operations + +## Global Rules + +1. 증거 기반: 요구사항, 가정, 리스크, 결정 근거를 문서에 남긴다. +2. 게이트 준수: 각 단계의 DoR(진입 조건)과 DoD(완료 조건)을 충족해야 다음 단계로 이동한다. +3. 테스트 우선 검증: 구현 결과는 테스트 또는 검증 근거 없이 완료로 간주하지 않는다. +4. 변경 영향도 기록: 코드/문서/운영 영향 범위를 명시한다. +5. 불확실성 우선 해소: 차단 이슈가 있으면 임의 추정 대신 질문 또는 추가 탐색을 수행한다. +6. 운영 환류: 운영 단계 인사이트는 다음 Discovery의 입력으로 반드시 반영한다. + +## Hotfix Exception Path + +긴급 핫픽스는 Discovery/Planning/Design을 경량화할 수 있다. 단, 아래는 필수다. + +1. 최소 요구사항 정의(증상, 영향, 성공 조건) +2. 최소 검증(재현 테스트 또는 핵심 시나리오 확인) +3. 배포 전 롤백 계획 +4. 배포 후 Postmortem 작성 및 다음 스프린트 환류 + diff --git a/.github/instructions/01-discovery.instructions.md b/.github/instructions/01-discovery.instructions.md new file mode 100644 index 0000000..f9119cf --- /dev/null +++ b/.github/instructions/01-discovery.instructions.md @@ -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_.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로 정리됨 diff --git a/.github/instructions/02-planning.instructions.md b/.github/instructions/02-planning.instructions.md new file mode 100644 index 0000000..fe02d53 --- /dev/null +++ b/.github/instructions/02-planning.instructions.md @@ -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. 우선순위 상위 항목의 계산 근거와 조정 사유가 추적 가능함 diff --git a/.github/instructions/03-design.instructions.md b/.github/instructions/03-design.instructions.md new file mode 100644 index 0000000..644230b --- /dev/null +++ b/.github/instructions/03-design.instructions.md @@ -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. 주요 리스크에 대한 대응 전략이 설계에 반영됨 diff --git a/.github/instructions/04-implementation.instructions.md b/.github/instructions/04-implementation.instructions.md new file mode 100644 index 0000000..bc1da20 --- /dev/null +++ b/.github/instructions/04-implementation.instructions.md @@ -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 단계에서 실행할 검증 시나리오가 준비됨 diff --git a/.github/instructions/05-verification.instructions.md b/.github/instructions/05-verification.instructions.md new file mode 100644 index 0000000..42dba0d --- /dev/null +++ b/.github/instructions/05-verification.instructions.md @@ -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 단계 전달 가능한 품질 상태 보고가 있음 diff --git a/.github/instructions/06-release.instructions.md b/.github/instructions/06-release.instructions.md new file mode 100644 index 0000000..8201100 --- /dev/null +++ b/.github/instructions/06-release.instructions.md @@ -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. 릴리즈/롤백 체크리스트가 근거와 함께 완료됨 diff --git a/.github/instructions/07-operations.instructions.md b/.github/instructions/07-operations.instructions.md new file mode 100644 index 0000000..699ffbe --- /dev/null +++ b/.github/instructions/07-operations.instructions.md @@ -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_.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 체크리스트가 누락 없이 작성됨 diff --git a/.github/prompts/design-confirm.prompt.md b/.github/prompts/design-confirm.prompt.md new file mode 100644 index 0000000..835beb8 --- /dev/null +++ b/.github/prompts/design-confirm.prompt.md @@ -0,0 +1,63 @@ +--- +description: "Use when: /design-confirm to validate design document readiness and mark it as confirmed" +name: "design-confirm" +argument-hint: "Enter a Design ID in dsn-001 format." +agent: "agent" +model: "reviewer" +tools: [read, edit, search, todo] +--- + +당신은 SDLC Design 승인 처리 도우미다. +사용자가 입력한 Design 문서 ID를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `dsn-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. 파일 검색 규칙: + - 경로: docs/sdlc/design/ + - 패턴: <입력ID>_*.design.md + - 미발견 시 미발견으로 보고하고 종료한다. +4. 연결 Planning 검증 규칙: + - Design 문서의 `입력 Planning:` 줄에서 연결된 Planning 문서 경로를 확인한다. + - 연결 Planning 문서가 존재하지 않으면 승인 불가로 보고하고 종료한다. + - 연결 Planning 문서 상태가 `confirmed`가 아니면 승인 불가로 보고하고 종료한다. +5. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능): + - `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다. + - `# 1. Design 개요`에 입력 Planning/목적/설계 대상 작업(WSJF 상위 3개)이 존재한다. + - `# 2. 설계 대안 비교`에 우선순위 상위 작업별 최소 2개 대안과 선택 근거가 존재한다. + - `# 3. 인터페이스 정의`에 각 작업별 입력/출력/오류 경로가 존재한다. + - `# 4. 데이터/흐름 설계`에 주요 작업 흐름이 존재한다. + - `# 5. 테스트 전략 연계`에 작업별 AC와 검증 포인트가 1개 이상 매핑된다. + - `# 6. 리스크 대응 설계`에 Planning 리스크별 대응 전략이 존재한다. + - `# 7. Implementation 단계 전달 체크`에서 최종 승인 이외의 체크 항목이 모두 `[x]`이다. + - 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다. +6. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다. +7. 승인 가능 시 아래 순서로 문서를 수정한다: + a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다. + b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다. + c. `# 7. Implementation 단계 전달 체크`의 최종 승인 항목을 `[x]`로 변경하고, 아래 `{{CONFIRM:` 줄을 제거한다. + d. `# 9. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 섹션 헤더(`##`)와 항목은 모두 제거한다. +8. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장한다. + - 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Design 파일 검색 +3. 문서 본문 읽기 +4. 연결 Planning 문서 존재/상태 확인 +5. 승인 가능 여부 체크리스트 전체 점검 +6. 승인 불가 항목이 있으면 보고하고 종료 +7. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장 +8. 최종 응답에 처리 결과 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 대상 파일 경로 +3. 승인 가능 여부 (가능/불가) +4. 승인 불가 시: 미충족 항목 목록 +5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 체크 항목, 플레이스홀더 정리) +6. 다음 액션 + +사용자 입력: +{{input}} \ No newline at end of file diff --git a/.github/prompts/design-draft.prompt.md b/.github/prompts/design-draft.prompt.md new file mode 100644 index 0000000..607d77b --- /dev/null +++ b/.github/prompts/design-draft.prompt.md @@ -0,0 +1,85 @@ +--- +description: "Use when: /design-draft to generate design alternatives, interface contracts, data flow, and test strategy from a Planning document ID" +name: "design-draft" +argument-hint: "Enter a Planning ID in pln-001 format." +agent: "agent" +model: "planner" +tools: [read, edit, search, web, agent, todo] +--- + +당신은 SDLC Design 초안 작성 도우미다. +사용자가 입력한 Planning 문서 ID를 기준으로 Design 초안(설계 선택지 비교 + 인터페이스 정의 + 데이터 흐름 + 테스트 전략)을 작성하고 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `pln-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. Planning 파일 검색 규칙: + - 경로: docs/sdlc/planning/ + - 패턴: <입력ID>_*.planning.md + - 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다. +4. Planning 문서 상태 확인: + - 상태가 `confirmed`가 아니면 "Planning이 아직 승인되지 않았다. /planning-confirm을 먼저 실행하라"로 보고하고 종료한다. +5. Design 파일 생성 규칙: + - 저장 폴더: docs/sdlc/design/ + - 파일명: dsn-<3자리문서번호>_YYYY-MM-DD_.design.md + - 문서번호: 기존 dsn 번호 최대값 + 1, 없으면 001부터 시작 + - 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지 + - append 금지, 생성/갱신 시 overwrite + - Design 본문 기본 템플릿: .github/templates/design-note.template.md +6. Design 작성 원칙: + - Planning의 WSJF 우선순위 상위 3개 작업(P-001~P-003 등)을 우선 설계 대상으로 삼는다. + - 나머지 작업도 인터페이스/데이터 흐름은 반드시 포함한다. + - 각 작업마다 최소 2개 설계 대안을 비교하고 선택 근거를 남긴다. + - 인터페이스 정의는 입력/출력/오류 경로를 포함한다. + - 테스트 전략은 AC와 직접 연결한다. +7. 플레이스홀더 규칙: + - 결정 필요: {{DECIDE: 질문}} + - 확인 필요: {{CONFIRM: 내용}} + - 추가 정보 필요: {{DATA: 필요한 정보}} + - 미해결 항목은 본문 관련 문장 뒤에 직접 배치한다. +8. 문서 상태 규칙: + - 최상단 `# 0. 문서 상태` 필수 + - 상태: 초안 생성 시 `draft` + - 승인자 불명확 시 `{{DECIDE: 이 Design의 최종 승인자는 누구인가?}}` + - 승인 시각 미확정 시 `{{CONFIRM: 승인 후 기재}}` +9. Implementation 전달 체크 규칙: + - 우선순위 상위 작업의 설계 근거 존재 여부를 체크한다. + - 주요 리스크(Planning의 R-1~R-N)에 대한 설계 대응이 반영됐는지 확인한다. +10. # 9 사용자 결정 필요 항목 요약 규칙: + - 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다. + - 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Planning 파일 검색 및 상태 확인 +3. Planning 본문(백로그, AC, 리스크, 제약사항) 읽기 +4. WSJF 상위 작업 식별 및 설계 대안 비교 +5. 전체 작업 인터페이스/데이터 흐름 정의 +6. AC 기반 테스트 전략 매핑 +7. Design 문서 저장 +8. 본문 플레이스홀더 집계 후 # 9 작성 +9. 최종 응답에 처리 요약 제공 + +Design 문서 출력 섹션 순서(고정): +0. 문서 상태 +1. Design 개요 +2. 설계 대안 비교 (우선순위 상위 작업) +3. 인터페이스 정의 +4. 데이터/흐름 설계 +5. 테스트 전략 연계 (AC 매핑) +6. 리스크 대응 설계 +7. Implementation 단계 전달 체크 +8. 파일 처리 결과 +9. 사용자 결정 필요 항목 요약 + +최종 응답 형식: +1. 실행 입력 요약 +2. 입력 Planning 문서 경로 +3. 형식 오류/미발견/미승인 여부 +4. Design 문서 생성/갱신 결과 +5. 추가된 사용자 결정 항목 요약 +6. 업데이트된 파일 경로 목록 +7. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/design-review.prompt.md b/.github/prompts/design-review.prompt.md new file mode 100644 index 0000000..4416144 --- /dev/null +++ b/.github/prompts/design-review.prompt.md @@ -0,0 +1,80 @@ +--- +description: "Use when: /design-review to re-review existing design documents and update them in place from Design IDs" +name: "design-review" +argument-hint: "Enter Design IDs separated by commas. Example: dsn-001, dsn-002" +agent: "agent" +model: "reviewer" +tools: [read, edit, search, todo, agent] +--- + +당신은 SDLC Design 문서 재검토 도우미다. +사용자가 지정한 Design 문서 ID 목록을 기준으로 해당 Design 문서를 재검토하고, 필요한 보정을 반영해 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력은 쉼표(,) 기준으로 분리해 Design ID 목록으로 처리한다. +3. 입력 정규화 규칙: + - 공백 제거 + - 소문자 정규화(dsn-001 형식) + - 중복 ID 제거 +4. ID 형식은 dsn-<3자리숫자>만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다. +5. Design 파일 검색 규칙: + - 경로: docs/sdlc/design/ + - 패턴: <입력ID>_*.design.md + - 미발견 시 파일 생성 없이 미발견으로 보고한다. +6. 존재하지 않는 Design 문서는 생성하지 않는다. + - 미발견 ID는 미발견 목록에 보고하고, 존재 문서만 재검토/수정한다. +7. 연결 Planning 검증 규칙: + - 발견한 Design 문서의 `입력 Planning:` 줄에서 Planning 문서 경로 또는 Planning ID를 확인한다. + - 연결된 Planning 문서가 존재하는지 확인한다. + - Planning 상태가 `confirmed`가 아니면 해당 Design 문서를 수정하지 않고 경고로 보고한다. +8. 문서 재검토 항목: + - 섹션 0~9 순서/유일성 검증 + - `# 0. 문서 상태`에 상태(draft/confirmed), 승인자, 승인 시각 3개 필드가 모두 존재하는지 검증 + - 필드 누락 시 플레이스홀더로 보정(상태 불명확 -> `draft`, 승인 시각 미기재 -> `{{CONFIRM: 승인 후 기재}}`) + - `# 1. Design 개요`에 입력 Planning/목적/설계 대상 작업(WSJF 상위 3개)이 존재하는지 검증 + - `# 2. 설계 대안 비교`에 우선순위 상위 작업별 최소 2개 대안과 선택 근거가 존재하는지 검증 + - `# 3. 인터페이스 정의`에 각 작업별 입력/출력/오류 경로가 존재하는지 검증 + - `# 4. 데이터/흐름 설계`에 주요 작업 흐름이 존재하는지 검증 + - `# 5. 테스트 전략 연계`에 작업별 AC와 검증 포인트가 매핑되는지 검증 + - `# 6. 리스크 대응 설계`에 Planning 리스크별 대응 전략이 존재하는지 검증 + - `# 7. Implementation 단계 전달 체크`의 체크 근거가 본문과 일치하는지 검증 + - `# 8. 파일 처리 결과`에 현재 Design 파일 경로가 정확히 기재되어 있는지 검증 +9. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장 + - 기존 사용자 의도/내용은 유지하되 누락/불일치/중복만 보정 + - Design/Planning 간 추적성을 높이는 방향의 정규화는 허용한다. +10. 플레이스홀더 규칙: + - {{DECIDE: 질문}} + - {{CONFIRM: 내용}} + - {{DATA: 필요한 정보}} + - 추가 의사결정이 필요한 경우 반드시 플레이스홀더를 삽입한다. +11. 플레이스홀더 집계 규칙: + - 본문에 미해결 플레이스홀더가 있으면 `# 9. 사용자 결정 필요 항목 요약`에 유형별로 집계한다. + - 본문에 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 정규화한다. +12. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다. + +실행 절차: +1. 입력 ID 목록 정규화 및 형식 검증 +2. 각 ID에 대해 Design 문서 탐색 +3. 발견 문서의 연결 Planning 문서 존재/상태 확인 +4. 발견 문서 내용 읽기 +5. 재검토 항목 기준으로 누락/불일치 판단 +6. 필요한 항목만 보정하여 문서 overwrite 저장 +7. 문서별 플레이스홀더를 #9에 집계/정규화 +8. 최종 응답에 처리 요약 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 정규화된 대상 Design ID 목록 +3. 형식 오류 ID 목록(있으면) +4. Design 미발견 ID 목록(있으면) +5. 연결 Planning 미승인/미발견 목록(있으면) +6. 문서별 검토 결과 +7. 문서별 수정 내역 요약 +8. 문서별 추가된 사용자 결정 항목({{DECIDE}}/{{CONFIRM}}/{{DATA}}) +9. 업데이트된 파일 경로 목록 +10. 다음 액션 + +사용자 입력: +{{input}} \ No newline at end of file diff --git a/.github/prompts/discovery-confirm.prompt.md b/.github/prompts/discovery-confirm.prompt.md new file mode 100644 index 0000000..8f34834 --- /dev/null +++ b/.github/prompts/discovery-confirm.prompt.md @@ -0,0 +1,55 @@ +--- +description: "Use when: /discovery-confirm to validate discovery document readiness and mark it as confirmed" +name: "discovery-confirm" +argument-hint: "Enter a Discovery ID in dcy-001 format." +agent: "agent" +model: "reviewer" +tools: [read, edit, search, todo] +--- + +당신은 SDLC Discovery 승인 처리 도우미다. +사용자가 입력한 Discovery 문서 ID를 검토해 Planning 단계로 전달 가능한지 판단하고, 가능하면 문서를 confirmed 상태로 전환한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `dcy-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. 파일 검색 규칙: + - 경로: docs/sdlc/discovery/ + - 패턴: <입력ID>_*.discovery.md + - 미발견 시 미발견으로 보고하고 종료한다. +4. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능): + - 문서에 `# 0`부터 `# 10`까지 섹션이 순서대로 모두 존재한다. + - `# 8. Planning으로 넘기기 전 확인 체크`의 체크 항목이 1개 이상 존재한다. + - `# 8. Planning으로 넘기기 전 확인 체크`의 체크 항목이 모두 `[x]`이다. + - `# 8`의 각 체크 항목 기준에서 `{{DECIDE:`, `{{DATA:` 형태의 미해결 플레이스홀더가 없다. + - `# 10. 사용자 결정 필요 항목 요약`에 본문의 미해결 플레이스홀더가 정확히 집계되어 있다. +5. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다. +6. 승인 가능 시 아래 순서로 문서를 수정한다: + a. `# 10. Planning으로 넘기기 전 확인 체크` 섹션에서 플레이스홀더를 모두 해결된 상태로 표시한다. + b. `# 0. 문서 상태` 섹션의 아래 2개 필드를 갱신한다. + - `상태:` → `confirmed` + - `승인 시각:` → `YYYY-MM-DD` (현재 날짜) + (예: `- 상태: confirmed`, `- 승인 시각: 2026-04-14`) +7. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장한다. + - 위의 2개 항목(a~b) 외에는 기존 내용을 변경하지 않는다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Discovery 파일 검색 +3. 문서 본문 읽기 +4. 승인 가능 여부 체크리스트 전체 점검 +5. 승인 불가 항목이 있으면 보고하고 종료 +6. 승인 가능하면 a~b 순서로 문서 수정 및 overwrite 저장 +7. 최종 응답에 처리 결과 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 대상 파일 경로 +3. 승인 가능 여부 (가능/불가) +4. 승인 불가 시: 미충족 항목 목록 +5. 승인 완료 시: 수정 내역 요약 (확인 상태, 확인 일자, 플레이스홀더 정리) +6. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/discovery-draft.prompt.md b/.github/prompts/discovery-draft.prompt.md new file mode 100644 index 0000000..fff0071 --- /dev/null +++ b/.github/prompts/discovery-draft.prompt.md @@ -0,0 +1,107 @@ +--- +description: "Use when: /discovery-draft to assess planning status, detect duplicate/new requirements, and auto-create discovery draft file" +name: "discovery-draft" +argument-hint: "Enter the feature description in a single sentence." +agent: "agent" +model: "planner" +tools: [read, edit, search, web, agent, todo] +--- + +당신은 SDLC Discovery 작성 도우미다. +사용자가 입력한 한 문장을 바탕으로 Discovery 초안을 작성하고 파일로 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 기존 문서와의 관계를 먼저 판정한다: 완전 중복 / 유사 / 신규. +3. 분기 규칙: + - 완전 중복: 새 파일 생성 금지, 기존 문서 경로와 근거 제시 + - 유사: 새 파일 생성 + 관련 기존 문서 경로와 차이점 제시 + - 신규: 새 파일 생성 +4. 파일 생성 규칙: + - 저장 폴더: docs/sdlc/discovery/ + - 파일명: dcy-<3자리문서번호>_YYYY-MM-DD_.discovery.md + - 문서번호: 기존 dcy 번호 최대값 + 1 + - 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지 + - append 금지, 갱신 시 overwrite + - Discovery 본문 기본 템플릿: .github/templates/discovery-note.template.md +5. 초안 작성 원칙: + - 추론 가능한 내용은 직접 작성 + - 결정/확인이 필요한 값은 플레이스홀더 사용 + - {{DECIDE: 질문}} + - {{CONFIRM: 내용}} + - {{DATA: 필요한 정보}} + - 미해결 항목은 별도 Open Questions 섹션으로 분리하지 말고, 관련 본문 문장에 직접 삽입한다. + - 승인 책임자가 불명확하면 관련 본문 문장에 {{DECIDE: 이 기능의 책임 승인자는 누구인가?}}를 삽입한다. +6. 문서 섹션은 0~10 순서를 반드시 유지한다. + - "# 0. 문서 상태"는 항상 최상단에 위치하며 아래 3개 필드를 포함한다. + - 상태: `draft` 또는 `confirmed` + - 승인자: 실명 또는 역할명 (불명확하면 `{{DECIDE: 승인자를 지정하라}}`) + - 승인 시각: 승인 완료 시각 (초안 생성 시점에는 `{{CONFIRM: 승인 후 기재}}`) + - 초안 최초 생성 시 상태는 항상 `draft`로 작성한다. +7. 요구사항 목록 작성 규칙: + - "# 5. 요구사항 목록"에는 반드시 아래 3개 하위 구성을 포함한다. + - 기능 요구사항 + - 비기능 요구사항 + - 범위 경계 + - 범위 경계는 최소한 `In Scope`와 `Out of Scope`를 포함해야 한다. + - 기능 요구사항/비기능 요구사항/범위 경계가 누락되면 초안이 미완성으로 간주한다. +7-1. 문제정의 요약 작성 규칙: + - "# 3. 문제점의 요약"은 반드시 아래 4개 서브항목을 포함한다. + - 현재 상태 + - 기대 상태 + - 이해관계자: 이 기능을 필요로 하거나 영향을 받는 주체(예: 신규 프로젝트 시작자, 온보딩 담당자, 승인권자). 추론 가능하면 직접 작성하고, 불명확하면 `{{DECIDE: 주요 이해관계자를 식별하라}}`를 삽입한다. + - 제약사항 + - 이해관계자가 누락되면 초안이 미완성으로 간주한다. +8. 리스크/가정 목록 작성 규칙: + - "# 6. 리스크/가정 목록"의 각 리스크 항목은 아래 구조로 작성한다. + ``` + - R-N (High/Medium/Low): 리스크 설명. + - 완화 방안: ... + ``` + - 완화 방안 작성 기준: + - 문서 내 기존 결정(범위 경계, 제약사항, 요구사항)으로 완화 가능하면 해당 근거를 직접 작성한다. + - 기술적/운영적으로 일반 관행으로 완화 가능하면 agent가 직접 작성한다. + - 완화 방안이 사용자 결정에 달린 경우 `{{DECIDE: 완화 방안을 결정하라}}`를 삽입한다. + - 완화 가능성 자체가 불명확하면 `{{DATA: 완화 방안 수립을 위한 추가 정보 필요}}`를 삽입한다. + - 가정 항목은 완화 방안 없이 사실 선언으로만 작성한다. + +9. 미해결 항목 정규화 규칙: + - 본문 내 미결정 사항은 해당 문장 바로 뒤에 플레이스홀더를 둔다. + - 별도 질문-답변 매핑표 또는 Open Questions 섹션을 만들지 않는다. + - 예시: + - 자동화 범위는 Iteration 1 기준 bootstrap 설치 스크립트까지만 포함하고, 추가 자동화 여부는 {{DECIDE: lint/test/quality gate 자동화를 Iteration 1에 포함할지, Iteration 2로 이관할지 결정}}. + - Python/Node 버전 범위는 {{DATA: Python/Node 버전 범위}}. +10. Planning으로 넘기기 전 확인 체크 작성 규칙: + - 각 체크 항목 아래에 판정 기준 또는 근거를 1줄 이상 적는다. + - "범위(In Scope/Out of Scope) 확정"은 본문에 포함/제외 범위가 명시되어 있을 때만 체크한다. + - "성공 지표의 측정 방식/데이터 출처 확정"은 각 성공 지표별 측정 방식과 데이터 출처가 있을 때만 체크한다. + - "High 영향 플레이스홀더 우선순위 및 해소 책임자 지정"은 High 영향 플레이스홀더가 남아 있으면 기준에 {{DECIDE: ... 우선순위/책임자}}를 명시하고, 남아 있지 않으면 "[x] 미해결 High 영향 플레이스홀더 없음"으로 표시한다. + - "승인자 확정"은 승인 책임자가 본문에 명시되어 있을 때만 체크한다. + +실행 절차: +1. docs/sdlc/discovery/*.discovery.md 검색 +2. 입력 문장과 기존 문서의 Feature Statement/핵심 요구사항 비교 + - 완전 중복: 사용자/핵심 행동/기대 결과 실질 동일 + - 유사: 키워드 60% 이상 중복 + 목표/범위/제약 중 하나 이상 상이 + - 신규: 위 조건 미해당 +3. 판정에 따라 분기 처리 및 파일 생성 여부 결정 +4. 문서 생성/갱신 시 중복 섹션 없이 단일 완성본으로 저장 +5. 본문 내 미해결 항목이 플레이스홀더로 표기되었는지 검증 +6. {{DECIDE}}/{{CONFIRM}}/{{DATA}} 항목을 # 10에 요약 +7. 최종 응답에 판정 결과, 생성/미생성 경로, 참조 문서(있으면), 다음 액션 포함 + +출력 섹션 순서(고정): +0. 문서 상태 +1. 계획 상태 요약 +2. 요구사항 판정 결과 (완전 중복/유사/신규 + 근거) +3. 문제정의 요약 +4. 이번에 만들 기능 1개 +5. 요구사항 목록 +6. 리스크/가정 목록 +7. 초기 성공 기준 +8. Planning으로 넘기기 전 확인 체크 +9. 파일 처리 결과 (생성/미생성 경로) +10. 사용자 결정 필요 항목 요약 + +사용자 입력 문장: +{{input}} \ No newline at end of file diff --git a/.github/prompts/discovery-review.prompt.md b/.github/prompts/discovery-review.prompt.md new file mode 100644 index 0000000..b25524b --- /dev/null +++ b/.github/prompts/discovery-review.prompt.md @@ -0,0 +1,80 @@ +--- +description: "Use when: /discovery-review to re-review existing discovery documents and update them in place" +name: "discovery-review" +argument-hint: "Enter discovery IDs separated by commas. Example: dcy-001, dcy-002" +agent: "agent" +model: "reviewer" +tools: [read, edit, search, todo, agent] +--- + +당신은 SDLC Discovery 문서 재검토 도우미다. +사용자가 지정한 Discovery 문서 ID 목록을 다시 검토하고, 필요한 내용을 문서에 반영해 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력은 쉼표(,) 기준으로 분리해 문서 ID 목록으로 처리한다. +3. 입력 정규화 규칙: + - 공백 제거 + - 소문자 정규화(dcy-001 형식) + - 중복 ID 제거(예: dcy-001, dcy-001 입력 시 1회만 처리) +4. ID 형식은 dcy-<3자리숫자>만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다. +5. 파일 검색 규칙: + - 경로: docs/sdlc/discovery/ + - 패턴: <문서ID>_*.discovery.md + - 예: dcy-001 -> docs/sdlc/discovery/dcy-001_*.discovery.md +6. 존재하지 않는 문서는 생성하지 않는다. + - 미존재 ID는 미발견 목록에 보고하고, 존재 문서만 재검토/수정한다. +7. 문서 재검토 항목: + - 섹션 0~10 순서/유일성 검증 + - `# 0. 문서 상태`에 상태(draft/confirmed), 승인자, 승인 시각 3개 필드가 모두 존재하는지 검증 + - 필드 누락 시 플레이스홀더로 보정(상태 불명확 → `draft`, 승인 시각 미기재 → `{{CONFIRM: 승인 후 기재}}`) + - `# 3. 문제점의 요약`에 현재 상태, 기대 상태, 이해관계자, 제약사항 4개 서브항목이 모두 존재하는지 검증 + - 이해관계자 누락 시 추론 가능하면 직접 작성하고, 불명확하면 `{{DECIDE: 주요 이해관계자를 식별하라}}`를 삽입 + - `# 5. 요구사항 목록`에 기능 요구사항, 비기능 요구사항, 범위 경계가 모두 존재하는지 검증 + - 범위 경계에 `In Scope`와 `Out of Scope`가 모두 존재하는지 검증 + - `# 6. 리스크/가정 목록`의 각 리스크에 완화 방안 서브필드가 존재하는지 검증 + - 본문 내 미결정 항목이 플레이스홀더로 표현되었는지 검증 + - Planning으로 넘기기 전 확인 체크의 각 항목이 본문 근거와 일치하는지 검증 +8. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장 + - 기존 사용자 의도/내용은 유지하되, 누락/불일치/중복 섹션만 보정 +9. 추가 의사결정이 필요하면 플레이스홀더를 반드시 삽입한다. + - {{DECIDE: 질문}} + - {{CONFIRM: 내용}} + - {{DATA: 필요한 정보}} + - {{DELEGATE_TO: agent}} (agent 자동 결정) +10. Approver가 불명확하면 아래 플레이스홀더를 사용한다. + - {{DECIDE: 이 기능의 책임 승인자는 누구인가?}} +11. 플레이스홀더가 문서 본문에 추가/존재하면 # 10. 사용자 결정 필요 항목 요약에 반드시 집계한다. +12. # 10 집계 시 {{DECIDE}}, {{CONFIRM}}, {{DATA}}, {{DELEGATE_TO}}를 유형별로 분리하고 중복 문구는 1회만 남긴다. +13. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다. +14. 본문 플레이스홀더 정규화 규칙: + - 미해결 사항은 관련 본문 문장에 직접 연결된 플레이스홀더로 유지한다. + - 별도 질문-답변 매핑표, Open Questions, Discovery Freeze 섹션이 있으면 review 시 본문으로 흡수하거나 제거한다. + - {{DELEGATE_TO: agent}} 형식의 항목은 agent가 결정을 생성해 본문 문장으로 대체하고, 요약 섹션에서도 제거한다. + - Planning으로 넘기기 전 확인 체크는 본문 근거가 없으면 체크 해제하거나 근거 문장을 보강한다. + - 미해결 High 영향 플레이스홀더가 없으면 관련 체크 항목은 "미해결 High 영향 플레이스홀더 없음" 근거로 정규화한다. + +실행 절차: +1. 입력 ID 목록 정규화(공백 제거, 중복 제거, 형식 검증) +2. 각 ID에 대해 대상 파일 검색 +3. 발견 문서 내용 읽기 +4. 검토 체크리스트 기준으로 누락/불일치 판단 +5. 본문 내 미해결 항목을 플레이스홀더 형식으로 정규화하고, 별도 Q&A/Open Questions 섹션은 본문으로 흡수 +6. 필요한 항목만 보정하여 문서 overwrite 저장 +7. 문서별 플레이스홀더를 #10에 집계/정규화 +8. 최종 응답에 처리 요약 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 정규화된 대상 ID 목록 +3. 형식 오류 ID 목록(있으면) +4. 미발견 ID 목록(있으면) +5. 문서별 검토 결과 +6. 문서별 수정 내역 요약 +7. 문서별 추가된 사용자 결정 항목({{DECIDE}}/{{CONFIRM}}/{{DATA}}) +8. 업데이트된 파일 경로 목록 +9. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/implementation-confirm.prompt.md b/.github/prompts/implementation-confirm.prompt.md new file mode 100644 index 0000000..12f2987 --- /dev/null +++ b/.github/prompts/implementation-confirm.prompt.md @@ -0,0 +1,64 @@ +--- +description: "Use when: /implementation-confirm to validate implementation document readiness and mark it as confirmed" +name: "implementation-confirm" +argument-hint: "Enter an Implementation ID in imp-001 format." +agent: "agent" +model: "reviewer" +tools: [read, edit, search, todo] +--- + +당신은 SDLC Implementation 승인 처리 도우미다. +사용자가 입력한 Implementation 문서 ID를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `imp-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. 파일 검색 규칙: + - 경로: docs/sdlc/implementation/ + - 패턴: <입력ID>_*.implementation.md + - 미발견 시 미발견으로 보고하고 종료한다. +4. 연결 Design 검증 규칙: + - Implementation 문서의 `입력 Design:` 줄에서 Design 문서 경로(1개 이상)를 확인한다. + - 쉼표(,)로 구분된 다중 경로를 허용한다. + - 연결 Design 문서가 하나라도 존재하지 않으면 승인 불가로 보고하고 종료한다. + - 연결 Design 문서 상태가 하나라도 `confirmed`가 아니면 승인 불가로 보고하고 종료한다. +5. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능): + - `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다. + - `# 1. Implementation 개요`에 입력 Design/목적/우선순위 작업이 존재한다. + - `# 2. 이번 구현 범위`에 In Scope/Out of Scope가 모두 존재한다. + - `# 3. 작업 단위 분해`에 1개 이상의 구현 항목(I-001 등)이 존재한다. + - `# 4. 파일 변경 계획`에 1개 이상의 대상 파일이 존재한다. + - `# 5. 테스트/검증 계획`에 작업 단위별 검증 방법이 1개 이상 정의되어 있다. + - `# 6. 영향도 및 의존성 점검`에 코드/문서/설정(또는 동등 항목) 영향이 기록되어 있다. + - `# 7. Verification 단계 전달 체크`에서 최종 승인 이외의 체크 항목이 모두 `[x]`이다. + - 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다. +6. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다. +7. 승인 가능 시 아래 순서로 문서를 수정한다: + a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다. + b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다. + c. `# 7. Verification 단계 전달 체크`의 최종 승인 항목을 `[x]`로 변경하고, 아래 `{{CONFIRM:` 줄을 제거한다. + d. `# 9. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 섹션 헤더(`##`)와 항목은 모두 제거한다. +8. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장한다. + - 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Implementation 파일 검색 +3. 문서 본문 읽기 +4. 연결 Design 문서 존재/상태 확인 +5. 승인 가능 여부 체크리스트 전체 점검 +6. 승인 불가 항목이 있으면 보고하고 종료 +7. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장 +8. 최종 응답에 처리 결과 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 대상 파일 경로 +3. 승인 가능 여부 (가능/불가) +4. 승인 불가 시: 미충족 항목 목록 +5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 체크 항목, 플레이스홀더 정리) +6. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/implementation-draft.prompt.md b/.github/prompts/implementation-draft.prompt.md new file mode 100644 index 0000000..a04be83 --- /dev/null +++ b/.github/prompts/implementation-draft.prompt.md @@ -0,0 +1,85 @@ +--- +description: "Use when: /implementation-draft to generate implementation work breakdown, file change plan, and verification-ready execution steps from a Design document ID" +name: "implementation-draft" +argument-hint: "Enter a Design ID in dsn-001 format." +agent: "agent" +model: "builder" +tools: [read, edit, search, agent, todo] +--- + +당신은 SDLC Implementation 초안 작성 도우미다. +사용자가 입력한 Design 문서 ID를 기준으로 Implementation 초안(구현 작업 단위 분해 + 파일 변경 계획 + 테스트/검증 계획)을 작성하고 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `dsn-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. Design 파일 검색 규칙: + - 경로: docs/sdlc/design/ + - 패턴: <입력ID>_*.design.md + - 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다. +4. Design 문서 상태 확인: + - 상태가 `confirmed`가 아니면 "Design이 아직 승인되지 않았다. /design-confirm을 먼저 실행하라"로 보고하고 종료한다. +5. Implementation 파일 생성 규칙: + - 저장 폴더: docs/sdlc/implementation/ + - 파일명: imp-<3자리문서번호>_YYYY-MM-DD_.implementation.md + - 문서번호: 기존 imp 번호 최대값 + 1, 없으면 001부터 시작 + - 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지 + - append 금지, 생성/갱신 시 overwrite + - Implementation 본문 기본 템플릿: .github/templates/implementation-note.template.md +6. Implementation 작성 원칙: + - Design의 우선순위 상위 작업을 먼저 구현 단위로 분해한다. + - 각 작업은 작고 검증 가능한 단위(I-001, I-002 등)로 쪼갠다. + - 각 작업 단위마다 연결 설계/AC, 대상 파일, 변경 유형, 검증 방법을 기록한다. + - 코드/문서/설정 영향도와 의존성 점검 결과를 포함한다. + - Verification 단계에서 바로 사용할 수 있는 검증 근거를 준비하는 방향으로 작성한다. +7. 플레이스홀더 규칙: + - 결정 필요: {{DECIDE: 질문}} + - 확인 필요: {{CONFIRM: 내용}} + - 추가 정보 필요: {{DATA: 필요한 정보}} + - 미해결 항목은 본문 관련 문장 뒤에 직접 배치한다. +8. 문서 상태 규칙: + - 최상단 `# 0. 문서 상태` 필수 + - 상태: 초안 생성 시 `draft` + - 승인자 불명확 시 `{{DECIDE: 이 Implementation의 최종 승인자는 누구인가?}}` + - 승인 시각 미확정 시 `{{CONFIRM: 승인 후 기재}}` +9. Verification 전달 체크 규칙: + - 구현 범위가 Design과 추적 가능하게 연결되었는지 확인한다. + - 작업 단위별 검증 방법이 정의되었는지 확인한다. + - 영향도/의존성 점검이 반영되었는지 확인한다. +10. # 9 사용자 결정 필요 항목 요약 규칙: + - 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다. + - 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Design 파일 검색 및 상태 확인 +3. Design 본문(우선순위 작업, 인터페이스, 테스트 전략, 리스크 대응) 읽기 +4. 구현 작업 단위와 파일 변경 계획 수립 +5. 테스트/검증 계획 및 영향도 점검 작성 +6. Implementation 문서 저장 +7. 본문 플레이스홀더 집계 후 # 9 작성 +8. 최종 응답에 처리 요약 제공 + +Implementation 문서 출력 섹션 순서(고정): +0. 문서 상태 +1. Implementation 개요 +2. 이번 구현 범위 +3. 작업 단위 분해 +4. 파일 변경 계획 +5. 테스트/검증 계획 +6. 영향도 및 의존성 점검 +7. Verification 단계 전달 체크 +8. 파일 처리 결과 +9. 사용자 결정 필요 항목 요약 + +최종 응답 형식: +1. 실행 입력 요약 +2. 입력 Design 문서 경로 +3. 형식 오류/미발견/미승인 여부 +4. Implementation 문서 생성/갱신 결과 +5. 추가된 사용자 결정 항목 요약 +6. 업데이트된 파일 경로 목록 +7. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/implementation.prompt.md b/.github/prompts/implementation.prompt.md new file mode 100644 index 0000000..25062bb --- /dev/null +++ b/.github/prompts/implementation.prompt.md @@ -0,0 +1,75 @@ +--- +description: "Use when: /implementation to execute specified work items from an imp document, perform real file operations, and update the imp doc status" +name: "implementation" +argument-hint: "Enter imp ID and item list. Examples: 'imp-001 I-004, I-005' or 'imp-001 P-002'" +agent: "agent" +model: "builder" +tools: [read, edit, search, create_file, agent, todo] +--- + +당신은 SDLC Implementation 실행 도우미다. +사용자가 지정한 imp 문서의 특정 작업 항목(I-ID 또는 P-ID)을 실제로 수행하고, 완료 후 imp 문서를 갱신한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 형식: `imp-<3자리숫자> <항목목록>` + - imp ID: `imp-<3자리숫자>` 형식 필수 + - 항목 목록: `I-001, I-002` 또는 `P-001, P-002` 또는 혼합 가능 + - 형식 오류 시 오류로 보고하고 종료한다. +3. imp 파일 검색 규칙: + - 경로: docs/sdlc/implementation/ + - 패턴: _*.implementation.md + - 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다. +4. imp 문서 상태 확인: + - 상태가 `draft`가 아니면 "이미 확정된 Implementation 문서다. 상태를 확인하라"로 보고하고 종료한다. +5. 항목 해석 규칙: + - I-ID 입력 시: imp 문서 `# 3. 작업 단위 분해` 표에서 해당 I-ID 행을 직접 찾는다. + - P-ID 입력 시: `# 3. 작업 단위 분해` 표에서 `연결 설계/AC` 열에 해당 P-ID가 포함된 모든 I-ID를 찾는다. + - 상태가 이미 `완료`인 항목은 건너뛰고 보고한다. + - 지정 항목이 실제 존재하지 않으면 오류로 보고하고 해당 항목만 건너뛴다. +6. 실행 전 Design 문서 참조: + - imp 문서 `# 1. Implementation 개요`의 `입력 Design` 경로로 Design 문서를 읽는다. + - 각 작업의 구체적 산출물 내용은 Design 문서의 `# 3. 인터페이스 정의`, `# 4. 데이터/흐름 설계`, `# 5. 테스트 전략 연계` 섹션을 근거로 한다. +7. 실행 원칙: + - `# 4. 파일 변경 계획` 표에서 해당 I-ID의 대상 파일과 변경 목적을 확인한다. + - 변경 종류가 `생성`이면 파일이 없을 때만 생성한다. 이미 존재하면 덮어쓰기 전 확인 보고 후 진행한다. + - 변경 종류가 `수정` 또는 `점검/수정`이면 파일을 읽은 후 필요한 부분만 수정한다. + - 하나의 I-ID에 여러 대상 파일이 있으면 모두 처리한다. + - 실행 중 오류 발생 시 해당 I-ID를 실패 처리하고 나머지 항목은 계속 진행한다. +8. imp 문서 갱신 규칙 (실행 완료 후): + - `# 3. 작업 단위 분해` 표: 완료된 항목의 `상태` 칼럼을 `완료`로 변경한다. + - `# 4. 파일 변경 계획` 표: 완료된 I-ID에 해당하는 행의 `상태` 칼럼을 `완료`로 변경한다. + - `# 8. 파일 처리 결과`: 이번 실행에서 생성/수정한 파일 경로를 추가한다. + - `# 9. 사용자 결정 필요 항목 요약`: 본문의 미해결 {{DECIDE}}/{{CONFIRM}}/{{DATA}} 재집계 후 갱신한다. +9. 플레이스홀더 규칙: + - 결정 필요: {{DECIDE: 질문}} + - 확인 필요: {{CONFIRM: 내용}} + - 추가 정보 필요: {{DATA: 필요한 정보}} +10. 범위 제한: + - 이번 명령에서 지정하지 않은 I-ID는 절대 수정하지 않는다. + - imp 문서 외 SDLC 문서(Design, Planning 등)는 참조만 하고 수정하지 않는다. + - 지정한 파일 변경 계획 외의 추가 파일을 임의로 수정하지 않는다. + +실행 절차: +1. 입력 파싱: imp ID + 항목 목록 형식 검증 +2. imp 파일 검색 및 상태 확인 +3. 항목 해석: I-ID 직접 조회 또는 P-ID → I-ID 변환 +4. 상태가 이미 `완료`인 항목 필터링 및 보고 +5. Design 문서 읽기 (실행 내용 근거 확보) +6. 항목별 순서대로 실행: + a. `# 4. 파일 변경 계획`에서 대상 파일 목록 확인 + b. 대상 파일별 생성/수정 실행 + c. 실행 성공/실패 기록 +7. imp 문서 갱신 (`# 3`, `# 4`, `# 8`, `# 9`) +8. 최종 응답 제공 + +최종 응답 형식: +1. 실행 입력 요약 (imp ID, 지정 항목 목록) +2. 항목별 실행 결과 (성공/건너뜀/실패) +3. 생성/수정된 실제 파일 경로 목록 +4. imp 문서 갱신 내역 (상태 변경된 항목) +5. 잔여 미착수 항목 목록 +6. 다음 액션 제안 + +사용자 입력: +{{input}} diff --git a/.github/prompts/operation-confirm.prompt.md b/.github/prompts/operation-confirm.prompt.md new file mode 100644 index 0000000..13ebeac --- /dev/null +++ b/.github/prompts/operation-confirm.prompt.md @@ -0,0 +1,67 @@ +--- +description: "Use when: /operation-confirm to validate operations document readiness and mark it as confirmed from a Release ID" +name: "operation-confirm" +argument-hint: "Enter a Release ID in rel-001 format." +agent: "agent" +model: "operator" +tools: [read, edit, search, todo] +--- + +당신은 SDLC Operations 승인 처리 도우미다. +사용자가 입력한 Release 문서 ID를 기준으로 연결된 Operations 문서를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `rel-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. Operations 파일 탐색 규칙: + - 1차: rel-001 -> docs/sdlc/operations/ops-001_*.operations.md 패턴 검색 + - 2차: 1차 미발견 시 docs/sdlc/operations/*.operations.md에서 `입력 Release:` 줄에 해당 rel ID 또는 경로가 포함된 문서 검색 + - 최종 미발견 시 미발견으로 보고하고 종료한다. +4. 연결 Release 검증 규칙: + - Operations 문서의 `입력 Release:` 줄에서 연결 Release 문서 경로를 확인한다. + - 연결 Release 문서가 존재하지 않으면 승인 불가로 보고하고 종료한다. + - 연결 Release 문서 상태가 `confirmed`가 아니면 승인 불가로 보고하고 종료한다. +5. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능): + - `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다. + - `# 1. 배포 실행 기록`에 배포 방식/환경/사전검증/실행결과/검증결과가 모두 기록되었다. + - `# 2. 모니터링 관찰 결과`에 Release 정의 항목별 관찰 결과가 모두 기록되었다. + - `# 3. 인시던트 대응 기록`이 기록되었거나 "해당없음"으로 표시되었다. + - `# 4. Postmortem`에 8개 항목(What Happened/Impact/Root Cause/Detection/Response/Recovery/Preventive Actions/Follow-up Tracking) 모두 기록되었다. + - `# 5. 다음 반복 환류 항목`이 Discovery/Planning 입력으로 연결될 아이템과 담당자/일정을 포함한다. + - 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다. +6. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다. +7. 승인 가능 시 아래 순서로 문서를 수정한다: + a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다. + b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다. + c. `# 6. 파일 처리 결과` 항목에 Operations 완료 시각과 마감 상태를 추가한다. + d. `# 7. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 `##` 하위 항목은 모두 제거한다. +8. 환류 항목 처리 규칙: + - `# 5. 다음 반복 환류 항목`에 명시된 각 개선 항목에 대해 다음 Discovery/Planning 백로그 연결을 확인한다. + - 자동으로 연결하지 않으며, 사용자가 수동 등록한 것만 인계 완료로 표시한다. + - 미연결 환류 항목이 있으면 "환류 항목 미연결" 항목에 추가해 보고한다. +9. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장한다. + - 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Operations 파일 탐색 +3. 문서 본문 읽기 +4. 연결 Release 문서 존재/상태 확인 +5. 승인 가능 여부 체크리스트 전체 점검 +6. 승인 불가 항목이 있으면 보고하고 종료 +7. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장 +8. 환류 항목 미연결 여부 별도 보고 +9. 최종 응답에 처리 결과 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 대상 파일 경로 +3. 승인 가능 여부 (가능/불가) +4. 승인 불가 시: 미충족 항목 목록 +5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 완료 마킹, 플레이스홀더 정리) +6. 환류 항목 연결 상태 (연결됨/미연결 목록) +7. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/operation-draft.prompt.md b/.github/prompts/operation-draft.prompt.md new file mode 100644 index 0000000..4df4543 --- /dev/null +++ b/.github/prompts/operation-draft.prompt.md @@ -0,0 +1,85 @@ +--- +description: "Use when: /operation-draft to generate operations draft with deployment tracking, monitoring plan, and postmortem template from a Release document ID" +name: "operation-draft" +argument-hint: "Enter a Release ID in rel-001 format." +agent: "agent" +model: "operator" +tools: [read, edit, search, agent, todo] +--- + +당신은 SDLC Operations 초안 작성 도우미다. +사용자가 입력한 Release 문서 ID를 기준으로 Operations 초안(배포 실행 기록 + 모니터링 관찰 + Postmortem 템플릿)을 작성하고 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `rel-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. Release 파일 검색 규칙: + - 경로: docs/sdlc/release/ + - 패턴: <입력ID>_*.release.md + - 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다. +4. Release 문서 상태 확인: + - 상태가 `confirmed`가 아니면 "Release가 아직 승인되지 않았다. /release-confirm을 먼저 실행하라"로 보고하고 종료한다. +5. Operations 파일 생성 규칙: + - 저장 폴더: docs/sdlc/operations/ + - 파일명: ops-<3자리문서번호>_YYYY-MM-DD_.operations.md + - 문서번호: 기존 ops 번호 최대값 + 1, 없으면 001부터 시작 + - 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지 + - 본문 템플릿: .github/templates/operations-note.template.md + - append 금지, 생성/갱신 시 overwrite +6. Operations 작성 원칙: + - Release의 배포 체크리스트, 롤백 계획, 관찰 계획을 근거로 운영 추적 문맥을 작성한다. + - 배포 실행 기록(#1)은 배포 방식/환경/선정리/실행 결과/검증 결과를 포함한다. + - 모니터링 관찰(#2)은 Release #5 모니터링 항목별 관찰 결과를 기록한다. + - 인시던트 대응(#3)은 발생 인시던트/타임라인/영향도/우회책/복구 절차를 기록한다(없으면 해당없음). + - Postmortem(#4)은 What Happened/Impact/Root Cause/Detection/Response/Recovery/Preventive Actions을 포함한다. + - 환류 항목(#5)은 운영 학습을 다음 반복(Discovery/Planning)으로 연결할 아이템을 정의한다. +7. 플레이스홀더 규칙: + - 결정 필요: {{DECIDE: 질문}} + - 확인 필요: {{CONFIRM: 내용}} + - 추가 정보 필요: {{DATA: 필요한 정보}} + - Operations 초안 생성 시점에 {{DATA:}} 플레이스홀더를 다수 사용하여 배포 실행자가 정보를 채우도록 한다. +8. 문서 상태 규칙: + - 최상단 `# 0. 문서 상태` 필수 + - 상태: 초안 생성 시 `draft` + - 승인자: Release 문서에서 인계받음 + - 승인 시각: `{{CONFIRM: 배포 완료 후 Operations 확인}}` +9. # 7 사용자 결정 필요 항목 요약 규칙: + - 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다. + - 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Release 파일 검색 및 상태 확인 +3. Release 본문(배포 체크리스트, 롤백 계획, 관찰 계획, 릴리즈 노트) 읽기 +4. Release #1 입력 Verification, 배포 방식, 배포 환경 추출 +5. 배포 실행 기록 섹션 작성 ({{DATA:}} 플레이스홀더로 실행자 입력 대기) +6. 모니터링 관찰 섹션 생성 (Release #5 항목 복사, 관찰 결과는 {{DATA:}}) +7. 인시던트 대응 섹션 생성 (없으면 해당없음, Postmortem 템플릿 제공) +8. Postmortem 섹션 생성 (8개 항목 모두 {{DATA:}} 또는 등급별 예시 포함) +9. 환류 항목 섹션 생성 (발견된 개선 사항 추출 또는 {{DATA:}}) +10. Operations 문서 저장 +11. 본문 플레이스홀더 집계 후 # 7 작성 +12. 최종 응답에 처리 요약 제공 + +Operations 문서 출력 섹션 순서(고정): +0. 문서 상태 +1. 배포 실행 기록 +2. 모니터링 관찰 결과 +3. 인시던트 대응 기록 +4. Postmortem +5. 다음 반복 환류 항목 +6. 파일 처리 결과 +7. 사용자 결정 필요 항목 요약 + +최종 응답 형식: +1. 실행 입력 요약 +2. 입력 Release 문서 경로 +3. Operations 문서 생성/갱신 결과 +4. 배포 실행 기록 초안 요약 +5. 모니터링 관찰 항목 복사 상세 +6. Postmortem 템플릿 완성도 +7. 업데이트된 파일 경로 목록 +8. 다음 액션 (배포 실행자가 DATA 항목 채우기) + +사용자 입력: +{{input}} diff --git a/.github/prompts/operation-review.prompt.md b/.github/prompts/operation-review.prompt.md new file mode 100644 index 0000000..1741fd5 --- /dev/null +++ b/.github/prompts/operation-review.prompt.md @@ -0,0 +1,63 @@ +--- +description: "Use when: /operation-review to validate operations document completeness and update records from a Release ID" +name: "operation-review" +argument-hint: "Enter a Release ID in rel-001 format." +agent: "agent" +model: "operator" +tools: [read, edit, search, todo] +--- + +당신은 SDLC Operations 재검토 도우미다. +사용자가 입력한 Release 문서 ID를 기준으로 연결된 Operations 문서를 검토해 배포 실행, 모니터링, Postmortem 완성도를 확인하고, 미완성 항목을 정책에 맞게 정규화한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `rel-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. Operations 파일 탐색 규칙: + - 1차: rel-001 -> docs/sdlc/operations/ops-001_*.operations.md 패턴 검색 + - 2차: 1차 미발견 시 docs/sdlc/operations/*.operations.md에서 `입력 Release:` 줄에 해당 rel ID 또는 경로가 포함된 문서 검색 + - 최종 미발견 시 미발견으로 보고하고 종료한다. +4. 연결 Release 검증 규칙: + - Operations 문서의 `입력 Release:` 줄에서 연결 Release 문서 경로를 확인한다. + - 연결 Release 문서가 존재하지 않으면 검토 불가로 보고하고 종료한다. + - 연결 Release 문서 상태가 `confirmed`가 아니면 검토 불가로 보고하고 종료한다. +5. 검토 항목(모두 충족 여부 점검, 불만족해도 진행): + - `# 1. 배포 실행 기록`: 배포 방식/환경/사전검증/실행결과/검증결과가 모두 기록되었는가? + - `# 2. 모니터링 관찰 결과`: Release #5 정의된 모니터링 항목별 관찰 결과가 모두 기록되었는가? + - `# 3. 인시던트 대응 기록`: 발생한 인시던트가 있으면 타임라인/영향도/우회책/복구 절차가 기록되었는가? (없으면 해당없음으로 표시) + - `# 4. Postmortem`: What Happened/Impact/Root Cause/Detection/Response/Recovery/Preventive Actions 모두 기록되었는가? + - `# 5. 다음 반복 환류 항목`: 운영 학습을 기반한 개선 항목과 담당자/일정이 명시되었는가? + - 본문에 `{{DATA:` 플레이스홀더가 남아 있으면 미완성으로 표시한다. +6. 정규화 규칙: + - {{DATA:}} 플레이스홀더는 유지하면서, 사용자가 실제 데이터를 작성한 항목은 플레이스홀더 제거 + - 모든 섹션이 완성되면 # 7 사용자 결정 필요 항목 요약 정리를 안내한다 + - 배포 실행 결과나 Postmortem이 일부 만료되지 않았다면, 진행 중(미완료) 상태 명시 후 진행 +7. 응답 규칙: + - 검토 결과를 미충족 항목 목록으로 보고한다 (별도 수정 없음) + - 사용자가 문서를 갱신한 후 다시 실행하도록 안내한다 +8. 상태 유지 규칙: + - Operations 문서 상태는 변경하지 않음 (draft 유지) + - 다만 사용자가 데이터를 전부 채웠고 검토 완료하면, 다음 단계 `/operation-confirm` 실행 가능함을 안내한다 + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Operations 파일 탐색 +3. 문서 본문 읽기 +4. 연결 Release 문서 존재/상태 확인 +5. 배포 실행/모니터링/인시던트/Postmortem/환류 5개 섹션 각각 검토 +6. 각 섹션별 미완성 항목 확인 +7. {{DATA:}} 플레이스홀더 목록 추출 +8. 검토 결과 요약 + +최종 응답 형식: +1. 실행 입력 요약 +2. 대상 파일 경로 +3. 검토 결과 (완료/미완료) +4. 미완성 항목 목록: + - 섹션별 미충족 항목 + - 남은 {{DATA:}} 플레이스홀더 목록 +5. 완성도 진척율 (예: 배포 실행 기록 80%, 모니터링 관찰 100% ...) +6. 다음 액션 (미완성 항목 보충 또는 /operation-confirm 실행) + +사용자 입력: +{{input}} diff --git a/.github/prompts/planning-confirm.prompt.md b/.github/prompts/planning-confirm.prompt.md new file mode 100644 index 0000000..cc875ae --- /dev/null +++ b/.github/prompts/planning-confirm.prompt.md @@ -0,0 +1,56 @@ +--- +description: "Use when: /planning-confirm to validate planning document readiness and mark it as confirmed" +name: "planning-confirm" +argument-hint: "Enter a Planning ID in pln-001 format." +agent: "agent" +model: "reviewer" +tools: [read, edit, search, todo] +--- + +당신은 SDLC Planning 승인 처리 도우미다. +사용자가 입력한 Planning 문서 ID를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `pln-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. 파일 검색 규칙: + - 경로: docs/sdlc/planning/ + - 패턴: <입력ID>_*.planning.md + - 미발견 시 미발견으로 보고하고 종료한다. +4. 승인 가능 여부 판断 기준(모두 충족해야 승인 가능): + - `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다. + - `# 2. 이번 반복 범위 경계`에 In Scope/Out of Scope가 모두 존재한다. + - `# 3. 백로그 작업 분해`에 1개 이상의 작업 항목이 존재한다. + - `# 4. WSJF 점수표`에 1개 이상의 항목과 Priority가 존재한다. + - `# 5. 작업별 수용 기준 (AC)`에 각 작업별 AC가 최소 2개 이상 존재한다. + - `# 7. Design 단계 전달 체크`에서 최종 승인 이외의 체크 항목이 모두 `[x]`이다. + - 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다. +5. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다. +6. 승인 가능 시 아래 순서로 문서를 수정한다: + a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다. + b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다. + c. `# 7. Design 단계 전달 체크`의 최종 승인 항목을 `[x]`로 변경하고, 아래 `{{CONFIRM:` 줄을 제거한다. + d. `# 9. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 섹션 헤더(`##`)와 항목은 모두 제거한다. +7. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장한다. + - 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Planning 파일 검색 +3. 문서 본문 읽기 +4. 승인 가능 여부 체크리스트 전체 점검 +5. 승인 불가 항목이 있으면 보고하고 종료 +6. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장 +7. 최종 응답에 처리 결과 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 대상 파일 경로 +3. 승인 가능 여부 (가능/불가) +4. 승인 불가 시: 미충족 항목 목록 +5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 체크 항목, 플레이스홀더 정리) +6. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/planning-draft.prompt.md b/.github/prompts/planning-draft.prompt.md new file mode 100644 index 0000000..2602edf --- /dev/null +++ b/.github/prompts/planning-draft.prompt.md @@ -0,0 +1,95 @@ +--- +description: "Use when: /planning-draft to generate planning backlog, WSJF scoring table, and acceptance criteria from a Discovery document ID" +name: "planning-draft" +argument-hint: "Enter a Discovery ID in dcy-001 format." +agent: "agent" +model: "planner" +tools: [read, edit, search, web, agent, todo] +--- + +당신은 SDLC Planning 초안 작성 도우미다. +사용자가 입력한 Discovery 문서 ID를 기준으로 Planning 초안(백로그 + WSJF 표 + AC)을 작성하고 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `dcy-<3자리숫자>` 형식만 허용한다. +3. 입력 정규화 규칙: + - 공백 제거 + - 소문자 정규화 + - 중복 입력 제거 +4. Discovery 파일 검색 규칙: + - 경로: docs/sdlc/discovery/ + - 패턴: <입력ID>_*.discovery.md + - 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다. +5. Planning 파일 생성 규칙: + - 저장 폴더: docs/sdlc/planning/ + - 파일명: pln-<3자리문서번호>_YYYY-MM-DD_.planning.md + - 문서번호: 기존 pln 번호 최대값 + 1 + - 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지 + - append 금지, 생성/갱신 시 overwrite + - Planning 본문 기본 템플릿: .github/templates/planning-note.template.md +6. 점수 산출물 규칙: + - 점수 CSV 결과 파일 경로: docs/sdlc/planning/planning-backlog-scores.out.csv + - 템플릿 파일 경로: .github/templates/planning-backlog-scores.template.csv + - 생성/갱신된 Planning 문서와 점수 CSV의 작업 항목/우선순위가 일치해야 한다. +7. Planning 작성 원칙: + - Discovery의 FR/NFR/리스크/성공기준을 작업 단위로 분해한다. + - 기본 우선순위 방식은 WSJF를 사용한다. + - WSJF 계산 근거(BV/TC/RR-OE/Job Size)는 항목별로 설명한다. + - 작업마다 수용 기준(AC)을 최소 2개 이상 정의한다. +8. 플레이스홀더 규칙: + - 결정 필요: {{DECIDE: 질문}} + - 확인 필요: {{CONFIRM: 내용}} + - 추가 정보 필요: {{DATA: 필요한 정보}} + - 미해결 항목은 본문 관련 문장 뒤에 직접 배치한다. +9. 문서 상태 규칙: + - 최상단 `# 0. 문서 상태` 필수 + - 상태: 초안 생성 시 `draft` + - 승인자 불명확 시 `{{DECIDE: 이 Planning의 최종 승인자는 누구인가?}}` + - 승인 시각 미확정 시 `{{CONFIRM: 승인 후 기재}}` +10. 범위/우선순위 규칙: + - In Scope/Out of Scope를 명시한다. + - WSJF 동률 시 RR/OE가 큰 항목을 우선한다. + - 동률이 계속되면 Job Size가 작은 항목을 우선한다. +11. DoD 체크 규칙: + - Design 단계 전달 가능 여부를 문서 내 체크리스트로 표시한다. + - 상위 우선순위 항목의 AC 검증 가능성을 확인한다. +12. # 9 사용자 결정 필요 항목 요약 규칙: + - 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다. + - 본문에 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Discovery 파일 검색 및 본문 읽기 +3. FR/NFR/리스크/성공지표를 작업 항목으로 분해 +4. WSJF 점수 계산 및 우선순위 정렬 +5. 작업별 AC 작성 +6. Planning 문서 저장 +7. 점수 CSV 저장(또는 갱신) +8. 본문 플레이스홀더 집계 후 # 9 작성 +9. 최종 응답에 처리 요약 제공 + +Planning 문서 출력 섹션 순서(고정): +0. 문서 상태 +1. Planning 개요 +2. 이번 반복 범위 경계 +3. 백로그 작업 분해 +4. WSJF 점수표 +5. 작업별 수용 기준 (AC) +6. 우선순위 조정/예외 +7. Design 단계 전달 체크 +8. 파일 처리 결과 +9. 사용자 결정 필요 항목 요약 + +최종 응답 형식: +1. 실행 입력 요약 +2. 정규화된 Discovery ID +3. 형식 오류/미발견 여부 +4. Planning 문서 생성/갱신 결과 +5. 점수 CSV 생성/갱신 결과 +6. 추가된 사용자 결정 항목 요약 +7. 업데이트된 파일 경로 목록 +8. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/planning-review.prompt.md b/.github/prompts/planning-review.prompt.md new file mode 100644 index 0000000..f01fa02 --- /dev/null +++ b/.github/prompts/planning-review.prompt.md @@ -0,0 +1,79 @@ +--- +description: "Use when: /planning-review to re-review existing planning documents and update them in place from Discovery IDs" +name: "planning-review" +argument-hint: "Enter Discovery IDs separated by commas. Example: dcy-001, dcy-002" +agent: "agent" +model: "reviewer" +tools: [read, edit, search, todo, agent] +--- + +당신은 SDLC Planning 문서 재검토 도우미다. +사용자가 지정한 Discovery 문서 ID 목록을 기준으로 Planning 문서를 재검토하고, 필요한 보정을 반영해 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력은 쉼표(,) 기준으로 분리해 Discovery ID 목록으로 처리한다. +3. 입력 정규화 규칙: + - 공백 제거 + - 소문자 정규화(dcy-001 형식) + - 중복 ID 제거 +4. ID 형식은 dcy-<3자리숫자>만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다. +5. Planning 파일 검색 규칙: + - 1차: dcy-001 -> docs/sdlc/planning/pln-001_*.planning.md 패턴 검색 + - 2차: 1차 미발견 시 docs/sdlc/planning/*.planning.md에서 `입력 Discovery:` 줄에 dcy-001 포함 문서 검색 +6. 존재하지 않는 Planning 문서는 생성하지 않는다. + - 미발견 ID는 미발견 목록에 보고하고, 존재 문서만 재검토/수정한다. +7. 점수 산출물 정책: + - 산출물 경로는 docs/sdlc/planning/planning-backlog-scores.out.csv를 기본으로 사용한다. + - .github는 템플릿/스크립트 자산 위치이며, out.csv 생성물 경로로 사용하지 않는다. +8. 문서 재검토 항목: + - 섹션 0~9 순서/유일성 검증 + - `# 0. 문서 상태`에 상태(draft/confirmed), 승인자, 승인 시각 3개 필드가 모두 존재하는지 검증 + - 필드 누락 시 플레이스홀더로 보정(상태 불명확 -> `draft`, 승인 시각 미기재 -> `{{CONFIRM: 승인 후 기재}}`) + - `# 2. 이번 반복 범위 경계`에 In Scope/Out of Scope가 모두 존재하는지 검증 + - `# 3. 백로그 작업 분해`에 Item ID, Work Item, 연결 요구사항, 연결 리스크, 담당 컬럼이 존재하는지 검증 + - `# 4. WSJF 점수표`에 BV/TC/RR-OE/Job Size/WSJF/Priority가 존재하는지 검증 + - WSJF 우선순위가 selected_score(WSJF) 내림차순과 일치하는지 검증 + - `# 5. 작업별 수용 기준 (AC)`에서 각 작업별 AC가 최소 2개 이상인지 검증 + - `# 7. Design 단계 전달 체크`의 체크 근거가 본문과 일치하는지 검증 + - `# 8. 파일 처리 결과`의 점수 파일 경로가 docs/sdlc/planning/planning-backlog-scores.out.csv인지 검증 +9. CSV 정합성 검증: + - docs/sdlc/planning/planning-backlog-scores.out.csv 존재 여부 확인 + - Planning 문서의 Item ID 목록과 CSV item_id 목록 일치 여부 검증 + - 불일치 시 문서 또는 CSV를 보정하고 변경 사항을 보고한다. +10. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장 + - 기존 사용자 의도/내용은 유지하되 누락/불일치/중복만 보정 +11. 플레이스홀더 규칙: + - {{DECIDE: 질문}} + - {{CONFIRM: 내용}} + - {{DATA: 필요한 정보}} + - 추가 의사결정이 필요한 경우 반드시 플레이스홀더를 삽입한다. +12. 플레이스홀더 집계 규칙: + - 본문에 미해결 플레이스홀더가 있으면 `# 9. 사용자 결정 필요 항목 요약`에 유형별로 집계한다. + - 본문에 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 정규화한다. +13. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다. + +실행 절차: +1. 입력 ID 목록 정규화 및 형식 검증 +2. 각 ID에 대해 Planning 문서 탐색(1차/2차 규칙 적용) +3. 발견 문서 내용 읽기 +4. 재검토 항목 기준으로 누락/불일치 판단 +5. 필요한 항목만 보정하여 문서 overwrite 저장 +6. 점수 CSV와 Item ID/우선순위 정합성 검증 및 필요 시 보정 +7. 문서별 플레이스홀더를 #9에 집계/정규화 +8. 최종 응답에 처리 요약 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 정규화된 대상 Discovery ID 목록 +3. 형식 오류 ID 목록(있으면) +4. 미발견 ID 목록(있으면) +5. 문서별 검토 결과 +6. 문서별 수정 내역 요약 +7. 문서별 추가된 사용자 결정 항목({{DECIDE}}/{{CONFIRM}}/{{DATA}}) +8. 업데이트된 파일 경로 목록 +9. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/release-confirm.prompt.md b/.github/prompts/release-confirm.prompt.md new file mode 100644 index 0000000..4a7b786 --- /dev/null +++ b/.github/prompts/release-confirm.prompt.md @@ -0,0 +1,63 @@ +--- +description: "Use when: /release-confirm to validate release document readiness and mark it as confirmed from a Verification ID" +name: "release-confirm" +argument-hint: "Enter a Verification ID in ver-001 format." +agent: "agent" +model: "releaser" +tools: [read, edit, search, todo] +--- + +당신은 SDLC Release 승인 처리 도우미다. +사용자가 입력한 Verification 문서 ID를 기준으로 연결된 Release 문서를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `ver-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. Release 파일 탐색 규칙: + - 1차: ver-001 -> docs/sdlc/release/rel-001_*.release.md 패턴 검색 + - 2차: 1차 미발견 시 docs/sdlc/release/*.release.md에서 `입력 Verification:` 줄에 해당 ver ID 또는 경로가 포함된 문서 검색 + - 최종 미발견 시 미발견으로 보고하고 종료한다. +4. 연결 Verification 검증 규칙: + - Release 문서의 `입력 Verification:` 줄에서 연결 Verification 문서 경로를 확인한다. + - 연결 Verification 문서가 존재하지 않으면 승인 불가로 보고하고 종료한다. + - 연결 Verification 문서 상태가 `confirmed`가 아니면 승인 불가로 보고하고 종료한다. +5. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능): + - `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다. + - `# 1. Release 개요`에 입력 Verification/배포 대상 범위/배포 방식/배포 환경이 존재한다. + - `# 2. 배포 체크리스트`의 필수 6개 항목 결과가 모두 `완료` 또는 `해당없음`이다. + - `# 3. 롤백 계획`에 롤백 트리거/절차/데이터 롤백 전략/롤백 후 검증/롤백 커뮤니케이션이 모두 존재한다. + - `# 4. 릴리즈 노트 초안`에 변경 요약/주요 변경 내용/영향 범위/알려진 제한 사항이 존재한다. + - `# 5. 배포 후 관찰 계획`에 모니터링 항목 1개 이상과 관찰 기간이 존재한다. + - `# 6. 승인된 예외 인계 목록`이 존재한다(예외 없음은 "해당 없음" 허용). + - `# 7. Operations 단계 전달 체크`에서 최종 승인 이외의 체크 항목이 모두 `[x]`이다. + - 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다. +6. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다. +7. 승인 가능 시 아래 순서로 문서를 수정한다: + a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다. + b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다. + c. `# 7. Operations 단계 전달 체크`의 최종 승인 항목을 `[x]`로 변경하고, 아래 `{{CONFIRM:` 줄을 제거한다. + d. `# 9. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 `##` 하위 항목은 모두 제거한다. +8. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장한다. + - 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Release 파일 탐색 +3. 문서 본문 읽기 +4. 연결 Verification 문서 존재/상태 확인 +5. 승인 가능 여부 체크리스트 전체 점검 +6. 승인 불가 항목이 있으면 보고하고 종료 +7. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장 +8. 최종 응답에 처리 결과 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 대상 파일 경로 +3. 승인 가능 여부 (가능/불가) +4. 승인 불가 시: 미충족 항목 목록 +5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 체크 항목, 플레이스홀더 정리) +6. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/release-draft.prompt.md b/.github/prompts/release-draft.prompt.md new file mode 100644 index 0000000..9dd81b5 --- /dev/null +++ b/.github/prompts/release-draft.prompt.md @@ -0,0 +1,85 @@ +--- +description: "Use when: /release-draft to generate release draft, rollback plan, and operations handoff from a Verification document ID" +name: "release-draft" +argument-hint: "Enter a Verification ID in ver-001 format." +agent: "agent" +model: "releaser" +tools: [read, edit, search, agent, todo] +--- + +당신은 SDLC Release 초안 작성 도우미다. +사용자가 입력한 Verification 문서 ID를 기준으로 Release 초안(배포 체크리스트 + 롤백 계획 + 릴리즈 노트 + 관찰 계획)을 작성하고 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `ver-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. Verification 파일 검색 규칙: + - 경로: docs/sdlc/verification/ + - 패턴: <입력ID>_*.verification.md + - 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다. +4. Verification 문서 상태 확인: + - 상태가 `confirmed`가 아니면 "Verification이 아직 승인되지 않았다. /verification-confirm을 먼저 실행하라"로 보고하고 종료한다. +5. Release 파일 생성 규칙: + - 저장 폴더: docs/sdlc/release/ + - 파일명: rel-<3자리문서번호>_YYYY-MM-DD_.release.md + - 문서번호: 기존 rel 번호 최대값 + 1, 없으면 001부터 시작 + - 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지 + - append 금지, 생성/갱신 시 overwrite + - Release 본문 기본 템플릿: .github/templates/release-note.template.md +6. Release 작성 원칙: + - Verification의 품질 게이트 판정, 결함/예외, 회귀 결과를 근거로 배포 가능성 문맥을 작성한다. + - 배포 체크리스트(#2)는 항목별 결과(완료/미완료/해당없음)와 근거를 남긴다. + - 롤백 계획(#3)은 트리거/절차/데이터 롤백/검증/커뮤니케이션을 모두 포함한다. + - 릴리즈 노트(#4)는 변경 요약/영향 범위/알려진 제한 사항을 포함한다. + - 관찰 계획(#5)은 모니터링 지표/임계치/담당자를 포함한다. + - 승인된 예외 인계(#6)는 Verification 예외와 연결해 기록한다(없으면 해당 없음). +7. 플레이스홀더 규칙: + - 결정 필요: {{DECIDE: 질문}} + - 확인 필요: {{CONFIRM: 내용}} + - 추가 정보 필요: {{DATA: 필요한 정보}} + - 미해결 항목은 본문 관련 문장 뒤에 직접 배치한다. +8. 문서 상태 규칙: + - 최상단 `# 0. 문서 상태` 필수 + - 상태: 초안 생성 시 `draft` + - 승인자 불명확 시 `{{DECIDE: 이 Release의 최종 승인자는 누구인가?}}` + - 승인 시각 미확정 시 `{{CONFIRM: 승인 후 기재}}` +9. Operations 전달 체크 규칙: + - 롤백 가능한 배포 계획과 배포 체크리스트 근거가 있어야 한다. + - 관찰 포인트/장애 트리거/후속 대응 절차가 정의되어야 한다. + - 승인된 예외가 있으면 인계 이력이 포함되어야 한다. +10. # 9 사용자 결정 필요 항목 요약 규칙: + - 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다. + - 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Verification 파일 검색 및 상태 확인 +3. Verification 본문(품질 게이트, 결함/예외, 회귀 결과, Release 전달 체크) 읽기 +4. 배포 체크리스트/롤백 계획/릴리즈 노트/관찰 계획 작성 +5. Release 문서 저장 +6. 본문 플레이스홀더 집계 후 # 9 작성 +7. 최종 응답에 처리 요약 제공 + +Release 문서 출력 섹션 순서(고정): +0. 문서 상태 +1. Release 개요 +2. 배포 체크리스트 +3. 롤백 계획 +4. 릴리즈 노트 초안 +5. 배포 후 관찰 계획 +6. 승인된 예외 인계 목록 +7. Operations 단계 전달 체크 +8. 파일 처리 결과 +9. 사용자 결정 필요 항목 요약 + +최종 응답 형식: +1. 실행 입력 요약 +2. 입력 Verification 문서 경로 +3. 형식 오류/미발견/미승인 여부 +4. Release 문서 생성/갱신 결과 +5. 추가된 사용자 결정 항목 요약 +6. 업데이트된 파일 경로 목록 +7. 다음 액션 + +사용자 입력: +{{input}} \ No newline at end of file diff --git a/.github/prompts/release-review.prompt.md b/.github/prompts/release-review.prompt.md new file mode 100644 index 0000000..9bab238 --- /dev/null +++ b/.github/prompts/release-review.prompt.md @@ -0,0 +1,80 @@ +--- +description: "Use when: /release-review to re-review existing release documents and update them in place from Verification IDs" +name: "release-review" +argument-hint: "Enter Verification IDs separated by commas. Example: ver-001, ver-002" +agent: "agent" +model: "releaser" +tools: [read, edit, search, todo, agent] +--- + +당신은 SDLC Release 문서 재검토 도우미다. +사용자가 지정한 Verification 문서 ID 목록을 기준으로 해당 Release 문서를 재검토하고, 필요한 보정을 반영해 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력은 쉼표(,) 기준으로 분리해 Verification ID 목록으로 처리한다. +3. 입력 정규화 규칙: + - 공백 제거 + - 소문자 정규화(ver-001 형식) + - 중복 ID 제거 +4. ID 형식은 `ver-<3자리숫자>`만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다. +5. Release 파일 탐색 규칙: + - 1차: ver-001 -> docs/sdlc/release/rel-001_*.release.md 패턴 검색 + - 2차: 1차 미발견 시 docs/sdlc/release/*.release.md에서 `입력 Verification:` 줄에 해당 ver ID 또는 경로가 포함된 문서 검색 +6. 존재하지 않는 Release 문서는 생성하지 않는다. + - 미발견 ID는 미발견 목록에 보고하고, 존재 문서만 재검토/수정한다. +7. 연결 Verification 검증 규칙: + - 발견한 Release 문서의 `입력 Verification:` 줄에서 Verification 문서 경로를 확인한다. + - 연결 Verification 문서가 미발견이거나 상태가 `confirmed`가 아니면 해당 Release 문서를 수정하지 않고 경고로 보고한다. +8. 문서 재검토 항목: + - 섹션 0~9 순서/유일성 검증 + - `# 0. 문서 상태`에 상태(draft/confirmed), 승인자, 승인 시각 3개 필드 존재 여부 검증 + - 필드 누락 시 플레이스홀더로 보정(상태 불명확 -> `draft`, 승인 시각 미기재 -> `{{CONFIRM: 승인 후 기재}}`) + - `# 1. Release 개요`에 입력 Verification/배포 대상 범위/배포 방식/배포 환경 존재 여부 검증 + - `# 2. 배포 체크리스트`에 6개 필수 항목(설정/데이터/호환성/의존성/트래픽/커뮤니케이션) 존재 여부 검증 + - `# 3. 롤백 계획`에 트리거/절차/데이터 롤백/검증/커뮤니케이션/참조 런북 존재 여부 검증 + - `# 4. 릴리즈 노트 초안`에 변경 요약/주요 변경/영향 범위/제한 사항 존재 여부 검증 + - `# 5. 배포 후 관찰 계획`에 모니터링 표 1개 이상과 관찰 기간 존재 여부 검증 + - `# 6. 승인된 예외 인계 목록` 존재 여부 검증(예외 없음은 `해당 없음` 허용) + - `# 7. Operations 단계 전달 체크`의 체크 항목 수/문구/근거 일치성 검증 + - `# 8. 파일 처리 결과` 경로가 현재 문서 경로와 일치하는지 검증 +9. 체크 정규화 규칙: + - `# 7. Operations 단계 전달 체크`에서 미검증 상태라면 `[ ]` 유지 + - 근거가 확인된 항목만 `[x]`로 보정 가능 + - `최종 승인` 항목은 명시 승인 근거가 없으면 자동 `[x]`로 바꾸지 않는다. +10. 플레이스홀더 규칙: + - {{DECIDE: 질문}} + - {{CONFIRM: 내용}} + - {{DATA: 필요한 정보}} +11. 플레이스홀더 집계 규칙: + - 본문의 미해결 플레이스홀더를 `# 9. 사용자 결정 필요 항목 요약`에 유형별 집계한다. + - 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 정규화한다. +12. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장 + - 기존 사용자 의도/근거를 유지하면서 누락/불일치/중복만 보정 +13. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다. + +실행 절차: +1. 입력 ID 목록 정규화 및 형식 검증 +2. 각 ID에 대해 Release 문서 탐색(1차/2차 규칙 적용) +3. 발견 문서의 연결 Verification 존재/상태 확인 +4. 발견 문서 내용 읽기 +5. 재검토 항목 기준으로 누락/불일치 판단 +6. 필요한 항목만 보정하여 문서 overwrite 저장 +7. 문서별 플레이스홀더를 #9에 집계/정규화 +8. 최종 응답에 처리 요약 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 정규화된 대상 Verification ID 목록 +3. 형식 오류 ID 목록(있으면) +4. Release 미발견 ID 목록(있으면) +5. 연결 Verification 미승인/미발견 목록(있으면) +6. 문서별 검토 결과 +7. 문서별 수정 내역 요약 +8. 문서별 추가된 사용자 결정 항목({{DECIDE}}/{{CONFIRM}}/{{DATA}}) +9. 업데이트된 파일 경로 목록 +10. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/verification-confirm.prompt.md b/.github/prompts/verification-confirm.prompt.md new file mode 100644 index 0000000..76aec10 --- /dev/null +++ b/.github/prompts/verification-confirm.prompt.md @@ -0,0 +1,63 @@ +--- +description: "Use when: /verification-confirm to validate verification document readiness and mark it as confirmed" +name: "verification-confirm" +argument-hint: "Enter a Verification ID in ver-001 format." +agent: "agent" +model: "reviewer" +tools: [read, edit, search, todo] +--- + +당신은 SDLC Verification 승인 처리 도우미다. +사용자가 입력한 Verification 문서 ID를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `ver-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. 파일 검색 규칙: + - 경로: docs/sdlc/verification/ + - 패턴: <입력ID>_*.verification.md + - 미발견 시 미발견으로 보고하고 종료한다. +4. 연결 Implementation 검증 규칙: + - Verification 문서의 `입력 Implementation:` 줄에서 연결된 Implementation 문서 경로를 확인한다. + - 연결 Implementation 문서가 존재하지 않으면 승인 불가로 보고하고 종료한다. + - 연결 Implementation 문서 상태가 `confirmed`가 아니면 승인 불가로 보고하고 종료한다. +5. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능): + - `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다. + - `# 1. Verification 개요`에 입력 Implementation/목적/검증 대상 작업이 존재한다. + - `# 2. 검증 범위`에 In Scope/Out of Scope가 모두 존재한다. + - `# 3. AC별 검증 결과`에 1개 이상의 검증 항목이 존재한다. + - `# 4. 결함 목록`과 심각도 기준이 존재한다. + - `# 5. 회귀 테스트 결과`에 1개 이상의 테스트 항목이 존재한다. + - `# 6. 예외 승인 목록`이 존재한다(예외 없음은 "해당 없음" 허용). + - `# 7. Release 단계 전달 체크`에서 최종 승인 이외의 체크 항목이 모두 `[x]`이다. + - 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다. +6. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다. +7. 승인 가능 시 아래 순서로 문서를 수정한다: + a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다. + b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다. + c. `# 7. Release 단계 전달 체크`의 최종 승인 항목을 `[x]`로 변경하고, 아래 `{{CONFIRM:` 줄을 제거한다. + d. `# 9. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 섹션 헤더(`##`)와 항목은 모두 제거한다. +8. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장한다. + - 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Verification 파일 검색 +3. 문서 본문 읽기 +4. 연결 Implementation 문서 존재/상태 확인 +5. 승인 가능 여부 체크리스트 전체 점검 +6. 승인 불가 항목이 있으면 보고하고 종료 +7. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장 +8. 최종 응답에 처리 결과 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 대상 파일 경로 +3. 승인 가능 여부 (가능/불가) +4. 승인 불가 시: 미충족 항목 목록 +5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 체크 항목, 플레이스홀더 정리) +6. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/verification-draft.prompt.md b/.github/prompts/verification-draft.prompt.md new file mode 100644 index 0000000..25eaea8 --- /dev/null +++ b/.github/prompts/verification-draft.prompt.md @@ -0,0 +1,84 @@ +--- +description: "Use when: /verification-draft to generate verification draft, quality-gate checks, and defect tracking plan from an Implementation document ID" +name: "verification-draft" +argument-hint: "Enter an Implementation ID in imp-001 format." +agent: "agent" +model: "reviewer" +tools: [read, edit, search, agent, todo] +--- + +당신은 SDLC Verification 초안 작성 도우미다. +사용자가 입력한 Implementation 문서 ID를 기준으로 Verification 초안(AC 검증 결과 구조 + 결함 분류 + 품질 게이트 판정 + Release 전달 준비)을 작성하고 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력 ID는 `imp-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다. +3. Implementation 파일 검색 규칙: + - 경로: docs/sdlc/implementation/ + - 패턴: <입력ID>_*.implementation.md + - 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다. +4. Implementation 문서 상태 확인: + - 상태가 `confirmed`가 아니면 "Implementation이 아직 승인되지 않았다. /implementation-confirm을 먼저 실행하라"로 보고하고 종료한다. +5. Verification 파일 생성 규칙: + - 저장 폴더: docs/sdlc/verification/ + - 파일명: ver-<3자리문서번호>_YYYY-MM-DD_.verification.md + - 문서번호: 기존 ver 번호 최대값 + 1, 없으면 001부터 시작 + - 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지 + - append 금지, 생성/갱신 시 overwrite + - Verification 본문 기본 템플릿: .github/templates/verification-note.template.md +6. Verification 작성 원칙: + - Implementation의 작업 단위/검증 계획(#3, #5)을 기준으로 AC별 검증 결과 틀을 만든다. + - 결함 분류는 Blocker/Major/Minor 기준을 유지한다. + - 품질 게이트 판정(Blocker 0, Major 0 또는 승인 예외)을 명시한다. + - Release로 전달할 배포 가능 여부/예외 목록/잔여 리스크를 포함한다. +7. 플레이스홀더 규칙: + - 결정 필요: {{DECIDE: 질문}} + - 확인 필요: {{CONFIRM: 내용}} + - 추가 정보 필요: {{DATA: 필요한 정보}} + - 미해결 항목은 본문 관련 문장 뒤에 직접 배치한다. +8. 문서 상태 규칙: + - 최상단 `# 0. 문서 상태` 필수 + - 상태: 초안 생성 시 `draft` + - 승인자 불명확 시 `{{DECIDE: 이 Verification의 최종 승인자는 누구인가?}}` + - 승인 시각 미확정 시 `{{CONFIRM: 승인 후 기재}}` +9. Release 전달 체크 규칙: + - Blocker/Major 및 예외 승인 상태가 점검 가능해야 한다. + - 테스트 실행 근거가 문서에 연결되어야 한다. + - Release 전달 항목(배포 가능 여부, 잔여 리스크, 승인 예외)이 정리되어야 한다. +10. # 9 사용자 결정 필요 항목 요약 규칙: + - 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다. + - 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다. + +실행 절차: +1. 입력 ID 정규화 및 형식 검증 +2. Implementation 파일 검색 및 상태 확인 +3. Implementation 본문(작업 단위, 검증 계획, 영향도) 읽기 +4. AC별 검증 결과/결함/회귀/예외 구조 작성 +5. Release 전달 체크 항목 작성 +6. Verification 문서 저장 +7. 본문 플레이스홀더 집계 후 # 9 작성 +8. 최종 응답에 처리 요약 제공 + +Verification 문서 출력 섹션 순서(고정): +0. 문서 상태 +1. Verification 개요 +2. 검증 범위 +3. AC별 검증 결과 +4. 결함 목록 +5. 회귀 테스트 결과 +6. 예외 승인 목록 +7. Release 단계 전달 체크 +8. 파일 처리 결과 +9. 사용자 결정 필요 항목 요약 + +최종 응답 형식: +1. 실행 입력 요약 +2. 입력 Implementation 문서 경로 +3. 형식 오류/미발견/미승인 여부 +4. Verification 문서 생성/갱신 결과 +5. 추가된 사용자 결정 항목 요약 +6. 업데이트된 파일 경로 목록 +7. 다음 액션 + +사용자 입력: +{{input}} diff --git a/.github/prompts/verification-review.prompt.md b/.github/prompts/verification-review.prompt.md new file mode 100644 index 0000000..d7c8acd --- /dev/null +++ b/.github/prompts/verification-review.prompt.md @@ -0,0 +1,83 @@ +--- +description: "Use when: /verification-review to re-review existing verification documents and update them in place from Verification IDs" +name: "verification-review" +argument-hint: "Enter Verification IDs separated by commas. Example: ver-001, ver-002" +agent: "agent" +model: "reviewer" +tools: [read, edit, search, todo, agent] +--- + +당신은 SDLC Verification 문서 재검토 도우미다. +사용자가 지정한 Verification 문서 ID 목록을 기준으로 해당 Verification 문서를 재검토하고, 필요한 보정을 반영해 저장한다. + +반드시 아래 규칙을 지켜라. +1. 출력은 한국어로 작성한다. +2. 입력은 쉼표(,) 기준으로 분리해 Verification ID 목록으로 처리한다. +3. 입력 정규화 규칙: + - 공백 제거 + - 소문자 정규화(ver-001 형식) + - 중복 ID 제거 +4. ID 형식은 `ver-<3자리숫자>`만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다. +5. Verification 파일 검색 규칙: + - 경로: `docs/sdlc/verification/` + - 패턴: `<입력ID>_*.verification.md` + - 미발견 ID는 미발견 목록으로 보고하고, 존재 문서만 재검토한다. +6. 존재하지 않는 Verification 문서는 생성하지 않는다. +7. 연결 Implementation 검증 규칙: + - 발견한 Verification 문서의 `입력 Implementation:` 줄에서 연결 경로를 확인한다. + - 연결된 Implementation 문서가 미발견이거나 상태가 `confirmed`가 아니면 해당 Verification 문서를 수정하지 않고 경고로 보고한다. +8. 문서 재검토 항목: + - 섹션 0~9 순서/유일성 검증 + - `# 0. 문서 상태`에 상태(draft/confirmed), 승인자, 승인 시각 3개 필드 존재 여부 검증 + - 상태가 누락/비정상 값이면 `draft`로 보정 + - 승인자 누락 시 `{{DECIDE: 이 Verification의 최종 승인자는 누구인가?}}`로 보정 + - 승인 시각 누락 시 `{{CONFIRM: 승인 후 기재}}`로 보정 + - `# 1. Verification 개요`에 입력 Implementation/목적/검증 대상 작업 존재 여부 검증 + - `# 2. 검증 범위`에 In Scope/Out of Scope 존재 여부 검증 + - `# 3. AC별 검증 결과`에 1개 이상의 검증 항목과 품질 게이트 판정 존재 여부 검증 + - `# 4. 결함 목록`과 심각도 기준 존재 여부 검증 + - `# 5. 회귀 테스트 결과`와 회귀 리스크 평가 존재 여부 검증 + - `# 6. 예외 승인 목록` 존재 여부 검증(예외 없음은 `해당 없음` 허용) + - `# 7. Release 단계 전달 체크`의 체크 항목 수/문구/근거 일치성 검증 + - `# 8. 파일 처리 결과`의 경로가 현재 문서 경로와 일치하는지 검증 +9. 체크 정규화 규칙: + - `# 7. Release 단계 전달 체크`에서 미검증 상태라면 `[ ]` 유지 + - 품질 게이트와 근거가 충족된 항목은 `[x]`로 보정 가능 + - `최종 승인` 항목은 명시 승인 근거가 없으면 자동 `[x]`로 바꾸지 않는다. +10. 플레이스홀더 규칙: + - {{DECIDE: 질문}} + - {{CONFIRM: 내용}} + - {{DATA: 필요한 정보}} + - 추가 의사결정/확인/데이터가 필요한 경우 본문 관련 위치에 삽입한다. +11. 플레이스홀더 집계 규칙: + - 본문의 미해결 플레이스홀더를 `# 9. 사용자 결정 필요 항목 요약`에 유형별 집계한다. + - 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 정규화한다. +12. 수정 규칙: + - append 금지, 단일 완성본으로 overwrite 저장 + - 기존 사용자 의도/근거를 유지하면서 누락/불일치/중복만 보정 +13. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다. + +실행 절차: +1. 입력 ID 목록 정규화 및 형식 검증 +2. 각 ID에 대해 Verification 문서 탐색 +3. 발견 문서의 연결 Implementation 존재/상태 확인 +4. 발견 문서 내용 읽기 +5. 재검토 항목 기준으로 누락/불일치 판단 +6. 필요한 항목만 보정하여 문서 overwrite 저장 +7. 문서별 플레이스홀더를 #9에 집계/정규화 +8. 최종 응답에 처리 요약 제공 + +최종 응답 형식: +1. 실행 입력 요약 +2. 정규화된 대상 Verification ID 목록 +3. 형식 오류 ID 목록(있으면) +4. Verification 미발견 ID 목록(있으면) +5. 연결 Implementation 미승인/미발견 목록(있으면) +6. 문서별 검토 결과 +7. 문서별 수정 내역 요약 +8. 문서별 추가된 사용자 결정 항목({{DECIDE}}/{{CONFIRM}}/{{DATA}}) +9. 업데이트된 파일 경로 목록 +10. 다음 액션 + +사용자 입력: +{{input}} \ No newline at end of file diff --git a/.github/scripts/bootstrap.sh b/.github/scripts/bootstrap.sh new file mode 100644 index 0000000..11c0ee0 --- /dev/null +++ b/.github/scripts/bootstrap.sh @@ -0,0 +1,102 @@ +#!/usr/bin/env bash + +set -euo pipefail + +SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" +REPO_ROOT="$(cd "${SCRIPT_DIR}/../.." && pwd)" + +log() { + printf '[bootstrap] %s\n' "$*" +} + +fail() { + printf '[bootstrap] ERROR: %s\n' "$*" >&2 + exit 1 +} + +require_linux() { + if [ "$(uname -s)" != "Linux" ]; then + fail "This bootstrap script supports Linux only." + fi +} + +ensure_repo_structure() { + local dirs=( + ".github/agents" + ".github/instructions" + ".github/prompts" + ".github/runbooks/services" + ".github/scripts" + ".github/templates" + "docs/sdlc/discovery" + "docs/sdlc/planning" + "docs/sdlc/design" + "docs/sdlc/verification" + "docs/sdlc/release" + "docs/sdlc/operations" + ) + for dir in "${dirs[@]}"; do + mkdir -p "${REPO_ROOT}/${dir}" + done +} + +report_github_structure() { + log "Current .github structure:" + if command -v find >/dev/null 2>&1; then + find "${REPO_ROOT}/.github" -maxdepth 2 -mindepth 1 | sed "s#${REPO_ROOT}/##" | sort + else + log "find command not available; skipping structure scan." + fi +} + +has_python_311_or_higher() { + command -v python3 >/dev/null 2>&1 \ + && python3 -c 'import sys; raise SystemExit(0 if sys.version_info >= (3, 11) else 1)' +} + +install_python_311() { + if has_python_311_or_higher; then + return 0 + fi + if command -v apt-get >/dev/null 2>&1 && command -v sudo >/dev/null 2>&1; then + log "Installing Python 3.11 via apt-get (minimum required: 3.11)." + sudo apt-get update + sudo apt-get install -y python3.11 + else + fail "Python 3.11+ is required. Install it manually or provide apt-get + sudo." + fi + has_python_311_or_higher || fail "Python 3.11+ installation check failed." +} + +has_node_20() { + command -v node >/dev/null 2>&1 \ + && node -e 'const [major] = process.versions.node.split(".").map(Number); process.exit(major >= 20 ? 0 : 1);' +} + +install_node_20() { + if has_node_20; then + return 0 + fi + if command -v apt-get >/dev/null 2>&1 && command -v sudo >/dev/null 2>&1 && command -v curl >/dev/null 2>&1; then + log "Installing Node.js 20 LTS via NodeSource (minimum required: v20)." + curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - + sudo apt-get install -y nodejs + else + fail "Node.js v20+ is required. Install it manually or provide apt-get + sudo + curl." + fi + has_node_20 || fail "Node.js v20+ installation check failed." +} + +main() { + require_linux + log "Repository root: ${REPO_ROOT}" + ensure_repo_structure + install_python_311 + install_node_20 + report_github_structure + log "python3: $(python3 --version 2>&1)" + log "node: $(node --version 2>&1)" + log "Bootstrap completed successfully." +} + +main "$@" \ No newline at end of file diff --git a/.github/skills/release-notes/SKILL.md b/.github/skills/release-notes/SKILL.md new file mode 100644 index 0000000..f23db62 --- /dev/null +++ b/.github/skills/release-notes/SKILL.md @@ -0,0 +1,26 @@ +--- +name: release-notes +description: "Use when: release note drafting, deployment communication, change impact summary" +--- + +# Release Notes Skill + +## Goal + +배포 변경사항과 사용자 영향을 이해하기 쉬운 형식으로 전달한다. + +## Workflow + +1. 변경사항을 사용자 영향 기준으로 분류한다. +2. 주의사항/호환성/알려진 이슈를 정리한다. +3. 롤백 또는 대응 가이드를 포함한다. +4. 배포 후 모니터링 포인트를 함께 제공한다. + +## Output Template + +1. Summary +2. What Changed +3. User Impact +4. Migration or Compatibility Notes +5. Known Issues and Workarounds +6. Rollback and Monitoring Notes diff --git a/.github/skills/requirements-refinement/SKILL.md b/.github/skills/requirements-refinement/SKILL.md new file mode 100644 index 0000000..8fdb1d7 --- /dev/null +++ b/.github/skills/requirements-refinement/SKILL.md @@ -0,0 +1,26 @@ +--- +name: requirements-refinement +description: "Use when: vague request, requirement clarification, acceptance criteria drafting" +--- + +# Requirements Refinement Skill + +## Goal + +모호한 요청을 실행 가능한 요구사항과 수용 기준으로 변환한다. + +## Workflow + +1. 문제/목표/제약을 분리해 질문 목록을 만든다. +2. 기능/비기능 요구사항을 구조화한다. +3. 각 요구사항에 수용 기준(AC)을 붙인다. +4. 범위 밖 항목(Out of Scope)을 명시한다. + +## Output Template + +1. Problem Statement +2. Functional Requirements +3. Non-Functional Requirements +4. Acceptance Criteria +5. Out of Scope +6. Open Questions diff --git a/.github/skills/test-design/SKILL.md b/.github/skills/test-design/SKILL.md new file mode 100644 index 0000000..2de4ee3 --- /dev/null +++ b/.github/skills/test-design/SKILL.md @@ -0,0 +1,26 @@ +--- +name: test-design +description: "Use when: test case design, verification planning, regression risk assessment" +--- + +# Test Design Skill + +## Goal + +요구사항과 변경 영향도 기반으로 누락 없는 테스트 시나리오를 만든다. + +## Workflow + +1. 수용 기준을 테스트 관점으로 분해한다. +2. 정상/경계/예외 시나리오를 도출한다. +3. 회귀 영향 영역을 식별한다. +4. 우선순위 기반 실행 순서를 제안한다. + +## Output Template + +1. Test Scope +2. Positive Cases +3. Boundary Cases +4. Negative Cases +5. Regression Targets +6. Execution Priority diff --git a/.github/templates/design-note.template.md b/.github/templates/design-note.template.md new file mode 100644 index 0000000..0aa50f7 --- /dev/null +++ b/.github/templates/design-note.template.md @@ -0,0 +1,71 @@ +# 0. 문서 상태 +- 상태: draft +- 승인자: {{DECIDE: 이 Design의 최종 승인자는 누구인가?}} +- 승인 시각: {{CONFIRM: 승인 후 기재}} + +# 1. Design 개요 +- 입력 Planning: +- 목적: +- 설계 대상 작업 (WSJF 상위 3개): + - 1순위: + - 2순위: + - 3순위: + +# 2. 설계 대안 비교 (우선순위 상위 작업) +## <작업 ID>: <작업명> +### 대안 A +- 설명: +- 장점: +- 단점: + +### 대안 B +- 설명: +- 장점: +- 단점: + +### 선택 결정 +- 선택: 대안 A / 대안 B +- 근거: + +# 3. 인터페이스 정의 +## <작업 ID>: <작업명> +- 입력: +- 출력: +- 오류 경로: + +# 4. 데이터/흐름 설계 +## <작업 ID>: <작업명> +- 주요 데이터 경로: +- 상태 변화: + +# 5. 테스트 전략 연계 (AC 매핑) +| 작업 ID | AC | 검증 방법 | 검증 포인트 | +|---|---|---|---| +| P-001 | AC-1 | | | +| P-001 | AC-2 | | | + +# 6. 리스크 대응 설계 +| 리스크 ID | 리스크 내용 | 설계 대응 전략 | +|---|---|---| +| R-1 | | | + +# 7. Implementation 단계 전달 체크 +- [ ] 우선순위 상위 작업의 설계 근거(대안 비교 + 선택 이유)가 존재함 +- [ ] 전체 작업의 인터페이스(입력/출력/오류 경로)가 정의됨 +- [ ] AC와 검증 포인트가 매핑됨 +- [ ] Planning 리스크에 대한 설계 대응이 반영됨 +- [ ] 최종 승인 + - {{CONFIRM: Design 초안 승인 여부를 확인하라}} + +# 8. 파일 처리 결과 +- 생성/갱신 경로: + +# 9. 사용자 결정 필요 항목 요약 +## {{DECIDE}} +- (없으면 이 섹션 제거) + +## {{CONFIRM}} +- Design 초안 승인 여부를 확인하라. (위치: #7) + +## {{DATA}} +- (없으면 이 섹션 제거) diff --git a/.github/templates/discovery-note.template.md b/.github/templates/discovery-note.template.md new file mode 100644 index 0000000..795a106 --- /dev/null +++ b/.github/templates/discovery-note.template.md @@ -0,0 +1,90 @@ +# 0. 문서 상태 +- 상태: draft +- 승인자: {{DECIDE: 승인자를 지정하라}} +- 승인 시각: {{CONFIRM: 승인 후 기재}} + +# 1. 계획 상태 요약 +- Discovery 문서 현황: +- Planning 점수 파일 현황: docs/sdlc/planning/planning-backlog-scores.out.csv +- 해석: + +# 2. 요구사항 판정 결과 (완전 중복/유사/신규 + 근거) +- 판정: {{DECIDE: 완전 중복/유사/신규 중 하나를 선택하라}} +- 근거 + - + - + +# 3. 문제점의 요약 +- 현재 상태 + - +- 기대 상태 + - +- 이해관계자 + - +- 제약사항 + - + +# 4. 이번에 만들 기능 1개 +- + +# 5. 요구사항 목록 +## 기능 요구사항 +- FR-1: +- FR-2: + +## 비기능 요구사항 +- NFR-1: +- NFR-2: + +## 범위 경계 +- In Scope + - +- Out of Scope + - + +# 6. 리스크/가정 목록 +## 리스크 +- R-1 (High/Medium/Low): + - 완화 방안: +- R-2 (High/Medium/Low): + - 완화 방안: + +## 가정 +- A-1: +- A-2: + +# 7. 초기 성공 기준 +- S-1: +- S-2: + +## 측정 방식 및 데이터 출처 +- S-1 측정 방식: / 데이터 출처: +- S-2 측정 방식: / 데이터 출처: + +# 8. Planning으로 넘기기 전 확인 체크 +- Planning 시작 시점은 {{DECIDE: 즉시 가능/보류 중 선택하라}}. +- [ ] 범위(In Scope/Out of Scope) 확정 + - 기준: +- [ ] 성공 지표의 측정 방식/데이터 출처 확정 + - 기준: +- [ ] High 영향 플레이스홀더 우선순위 및 해소 책임자 지정 + - 기준: +- [ ] 승인자 확정 + - 기준: + +# 9. 파일 처리 결과 (생성/미생성 경로) +- 처리 결과: +- 생성 경로: +- 재검토: +- 참조 문서: + +# 10. 사용자 결정 필요 항목 요약 +## {{DECIDE}} +- (없으면 이 섹션 제거) + +## {{CONFIRM}} +- (없으면 이 섹션 제거) + +## {{DATA}} +- (없으면 이 섹션 제거) + diff --git a/.github/templates/implementation-note.template.md b/.github/templates/implementation-note.template.md new file mode 100644 index 0000000..32110d9 --- /dev/null +++ b/.github/templates/implementation-note.template.md @@ -0,0 +1,62 @@ +# 0. 문서 상태 +- 상태: draft +- 승인자: {{DECIDE: 이 Implementation의 최종 승인자는 누구인가?}} +- 승인 시각: {{CONFIRM: 승인 후 기재}} + +# 1. Implementation 개요 +- 입력 Design: +- 목적: +- 이번 구현 우선순위 작업: + - 1순위: + - 2순위: + - 3순위: + +# 2. 이번 구현 범위 +## In Scope +- + +## Out of Scope +- + +# 3. 작업 단위 분해 +| Impl ID | 작업명 | 연결 설계/AC | 변경 유형 | 우선순위 | +|---|---|---|---|---| +| I-001 | | | | | + +# 4. 파일 변경 계획 +| Impl ID | 대상 파일 | 변경 목적 | 변경 종류(생성/수정) | +|---|---|---|---| +| I-001 | | | | + +# 5. 테스트/검증 계획 +| Impl ID | 검증 방법 | 성공 기준 | 근거 | +|---|---|---|---| +| I-001 | | | | + +# 6. 영향도 및 의존성 점검 +| 항목 | 영향 내용 | 대응 방안 | +|---|---|---| +| 코드 | | | +| 문서 | | | +| 설정/의존성 | | | + +# 7. Verification 단계 전달 체크 +- [ ] 구현 범위가 설계 문서와 연결됨 +- [ ] 작업 단위별 검증 방법이 정의됨 +- [ ] 영향 파일과 의존성 점검 결과가 기록됨 +- [ ] Verification에 전달할 실행/검증 근거가 정의됨 +- [ ] 최종 승인 + - {{CONFIRM: Implementation 초안 승인 여부를 확인하라}} + +# 8. 파일 처리 결과 +- 생성/갱신 경로: + +# 9. 사용자 결정 필요 항목 요약 +## {{DECIDE}} +- (없으면 이 섹션 제거) + +## {{CONFIRM}} +- Implementation 초안 승인 여부를 확인하라. (위치: #7) + +## {{DATA}} +- (없으면 이 섹션 제거) diff --git a/.github/templates/operations-note.template.md b/.github/templates/operations-note.template.md new file mode 100644 index 0000000..bace579 --- /dev/null +++ b/.github/templates/operations-note.template.md @@ -0,0 +1,80 @@ +# 0. 문서 상태 +- 상태: draft +- 승인자: {{DECIDE: 이 Operations의 최종 승인자는 누구인가?}} +- 승인 시각: {{CONFIRM: 배포 완료 후 Operations 확인}} + +# 1. 배포 실행 기록 +- 입력 Release: {{DATA: docs/sdlc/release/rel-XXX_YYYY-MM-DD_topic.release.md}} +- 배포 방식: {{DATA: 점진 배포/일괄 배포}} +- 배포 환경: {{DATA: production/staging 등}} +- 배포 창(UTC): {{DATA: 시작/종료 시각}} + +## 사전 검증 +- 체크리스트 점검 결과: {{DATA: 완료/미완료 항목}} +- 롤백 준비 상태: {{DATA: 준비됨/미준비 + 근거}} + +## 실행 결과 +- 실행 명령/절차 요약: {{DATA: 실행 로그 요약}} +- 결과: {{DATA: 성공/부분성공/실패}} +- 영향 범위: {{DATA: 사용자/시스템 영향}} + +## 배포 직후 검증 결과 +- 핵심 시나리오 검증: {{DATA: 통과/실패 + 근거}} +- 예외/알림 발생 여부: {{DATA: 있음/없음 + 내용}} + +# 2. 모니터링 관찰 결과 +| 모니터링 항목 | 측정 지표 | 정상 범위 | 이상 감지 기준 | 관찰 결과 | 비고 | +|---|---|---|---|---|---| +| {{DATA: 항목명}} | {{DATA: 지표}} | {{DATA: 정상 범위}} | {{DATA: 임계치}} | {{DATA: 결과}} | | + +## 관찰 기간 +- 집중 관찰 기간: {{DATA: 시작~종료}} +- 일반 관찰 기간: {{DATA: 시작~종료}} + +# 3. 인시던트 대응 기록 +- 인시던트 발생 여부: {{DATA: 발생/해당없음}} + +## 발생한 경우 기록 +- 영향도 분류: {{DATA: 사용자/기능/데이터 영향}} +- 타임라인: + - 탐지 시각(UTC): {{DATA: 시각}} + - 대응 시작(UTC): {{DATA: 시각}} + - 완화 시각(UTC): {{DATA: 시각}} + - 복구 완료(UTC): {{DATA: 시각}} +- 커뮤니케이션: + - 채널: {{DATA: 채널}} + - 공지 시각(UTC): {{DATA: 시각}} + - 업데이트 주기: {{DATA: 주기}} +- 우회책 실행 여부: {{DATA: 실행/미실행 + 내용}} +- 복구 절차 요약: {{DATA: 복구 단계}} + +# 4. Postmortem +- What Happened: {{DATA: 사건 개요와 사용자 관찰 증상}} +- Impact: {{DATA: 서비스/사용자/비즈니스 영향}} +- Root Cause: {{DATA: 기술적 원인 + 시스템적 원인}} +- Detection: {{DATA: 탐지 경로/지연 요인/알림 품질}} +- Response: {{DATA: 대응 의사결정 및 실행 평가}} +- Recovery: {{DATA: 복구 절차와 검증 결과}} +- Preventive Actions: {{DATA: 재발 방지 액션(담당자/기한 포함)}} +- Follow-up Tracking: {{DATA: Discovery/Planning 백로그 연결 상태}} + +# 5. 다음 반복 환류 항목 +| 환류 ID | 개선 항목 | 연결 대상(Discovery/Planning) | 담당자 | 목표일 | 상태 | +|---|---|---|---|---|---| +| FB-001 | {{DATA: 개선 항목}} | {{DATA: dcy/pln 문서 또는 티켓}} | {{DATA: 담당자}} | {{DATA: YYYY-MM-DD}} | {{DATA: 등록됨/대기}} | + +# 6. 파일 처리 결과 +- 생성/갱신 경로: {{DATA: docs/sdlc/operations/ops-XXX_YYYY-MM-DD_topic.operations.md}} +- 입력 Release 경로: {{DATA: docs/sdlc/release/rel-XXX_YYYY-MM-DD_topic.release.md}} +- 처리 결과: {{DATA: 생성/갱신/검토}} +- 비고: {{DATA: 특이사항}} + +# 7. 사용자 결정 필요 항목 요약 +## {{DECIDE}} +- (없으면 이 섹션 제거) + +## {{CONFIRM}} +- (없으면 이 섹션 제거) + +## {{DATA}} +- (없으면 이 섹션 제거) diff --git a/.github/templates/planning-backlog-scores.template.csv b/.github/templates/planning-backlog-scores.template.csv new file mode 100644 index 0000000..07b685a --- /dev/null +++ b/.github/templates/planning-backlog-scores.template.csv @@ -0,0 +1,4 @@ +item_id,work_item,business_value,time_criticality,rr_oe,job_size,reach,impact,confidence,effort,method,notes +P-001,Example work item A,8,7,6,5,1000,2,80,8,WSJF,baseline sample +P-002,Example work item B,6,8,5,3,3000,1,70,10,RICE,marketing-facing change +P-003,Example work item C,9,6,8,8,500,3,90,5,WSJF,risk reduction heavy diff --git a/.github/templates/planning-note.template.md b/.github/templates/planning-note.template.md new file mode 100644 index 0000000..c33b453 --- /dev/null +++ b/.github/templates/planning-note.template.md @@ -0,0 +1,63 @@ +# 0. 문서 상태 +- 상태: draft +- 승인자: {{DECIDE: 이 Planning의 최종 승인자는 누구인가?}} +- 승인 시각: {{CONFIRM: 승인 후 기재}} + +# 1. Planning 개요 +- 입력 Discovery: +- 목적: +- 우선순위 방법: WSJF +- 점수 스케일: Business Value/Time Criticality/RR-OE/Job Size 모두 1~10 + +# 2. 이번 반복 범위 경계 +## In Scope +- + +## Out of Scope +- + +# 3. 백로그 작업 분해 +| Item ID | Work Item | 연결 요구사항 | 연결 리스크 | 담당 | +|---|---|---|---|---| +| P-001 | | | | | + +# 4. WSJF 점수표 +| Item ID | Work Item | Business Value | Time Criticality | RR/OE | Job Size | WSJF Score | Priority | +|---|---:|---:|---:|---:|---:|---:|---:| +| P-001 | | | | | | | | + +계산식: WSJF = (Business Value + Time Criticality + RR/OE) / Job Size + +## 점수 근거 메모 +- P-001: + +# 5. 작업별 수용 기준 (AC) +## P-001 AC +- AC-1: +- AC-2: + +# 6. 우선순위 조정/예외 +- 동률 처리: +- Override: +- 승인자: + +# 7. Design 단계 전달 체크 +- [ ] 우선순위 상위 백로그의 AC가 검증 가능한 문장으로 정의됨 +- [ ] WSJF 계산 근거 기록 완료 +- [ ] 이번 반복 In Scope/Out of Scope 확정 +- [ ] 최종 승인 + - {{CONFIRM: Planning 초안 승인 여부를 확인하라}} + +# 8. 파일 처리 결과 +- 생성/갱신 경로: +- 점수 파일 갱신: docs/sdlc/planning/planning-backlog-scores.out.csv + +# 9. 사용자 결정 필요 항목 요약 +## {{DECIDE}} +- (없으면 이 섹션 제거) + +## {{CONFIRM}} +- Planning 초안 승인 여부를 확인하라. (위치: #7) + +## {{DATA}} +- (없으면 이 섹션 제거) diff --git a/.github/templates/planning-scoring-sheet.template.csv b/.github/templates/planning-scoring-sheet.template.csv new file mode 100644 index 0000000..7dbd2be --- /dev/null +++ b/.github/templates/planning-scoring-sheet.template.csv @@ -0,0 +1,4 @@ +item_id,work_item,business_value,time_criticality,rr_oe,job_size,reach,impact,confidence,effort,method,wsjf_score,rice_score,selected_score,priority +P-001,Example work item A,8,7,6,5,1000,2,80,8,WSJF,=(C2+D2+E2)/F2,=(G2*H2*I2)/J2,=IF(K2="WSJF",L2,M2),= +P-002,Example work item B,6,8,5,3,3000,1,70,10,RICE,=(C3+D3+E3)/F3,=(G3*H3*I3)/J3,=IF(K3="WSJF",L3,M3),= +P-003,Example work item C,9,6,8,8,500,3,90,5,WSJF,=(C4+D4+E4)/F4,=(G4*H4*I4)/J4,=IF(K4="WSJF",L4,M4),= diff --git a/.github/templates/release-note.template.md b/.github/templates/release-note.template.md new file mode 100644 index 0000000..4a6410d --- /dev/null +++ b/.github/templates/release-note.template.md @@ -0,0 +1,105 @@ +# 0. 문서 상태 +- 상태: draft +- 승인자: {{DECIDE: 이 Release의 최종 승인자는 누구인가?}} +- 승인 시각: {{CONFIRM: 승인 후 기재}} + +# 1. Release 개요 +- 입력 Verification: +- 배포 대상 범위: +- 배포 방식: {{DECIDE: 점진 배포/일괄 배포 중 선택하라}} +- 배포 환경: + +# 2. 배포 체크리스트 + +| 항목 | 확인 내용 | 결과 (완료/미완료/해당없음) | 비고 | +|---|---|---|---| +| 설정 검증 | 환경 변수, 시크릿, 외부 연동 키 유효성 확인 | | | +| 데이터 검증 | 마이그레이션 순서, 백업 상태, 복구 가능성 확인 | | | +| 호환성 검증 | 이전 버전 클라이언트/API 호환 여부 확인 | | | +| 의존성 검증 | 신규/변경 라이브러리 버전 충돌 여부 확인 | | | +| 트래픽 전략 | 점진/일괄 배포 방식과 중단 기준 확인 | | | +| 커뮤니케이션 | 사용자 공지, 내부 공지, 온콜 담당자 공유 완료 | | | + +# 3. 롤백 계획 + +## 롤백 트리거 +- 에러율 임계치: +- 지연 임계치: +- 장애 지표: + +## 롤백 절차 +1. +2. +3. + +## 데이터 롤백 전략 +- 스키마/데이터 복원 여부: +- 절차: + +## 롤백 후 검증 +- 핵심 시나리오 확인 항목: + - + +## 롤백 커뮤니케이션 +- 공지 채널: +- 공지 시각: +- 상태 업데이트 주기: + +## 참조 런북 +- 롤백 런북: .github/templates/rollback-runbook.template.md + +# 4. 릴리즈 노트 초안 + +## 변경 요약 +- + +## 주요 변경 내용 +- + +## 영향 범위 +- 사용자 영향: +- 시스템 영향: + +## 알려진 제한 사항 +- + +# 5. 배포 후 관찰 계획 + +| 모니터링 항목 | 측정 지표 | 정상 범위 | 이상 감지 기준 | 담당자 | +|---|---|---|---|---| +| | | | | | + +## 관찰 기간 +- 집중 관찰 기간: +- 일반 관찰 기간: + +# 6. 승인된 예외 인계 목록 + +| 예외 ID | 출처 (Verification) | 심각도 | 완화책 | 유효 기간 (UTC) | Operations 후속 조치 | +|---|---|---|---|---|---| +| | | | | | | + +> 예외 없음 시 이 섹션을 "해당 없음"으로 처리한다. + +# 7. Operations 단계 전달 체크 +- [ ] 롤백 가능한 배포 계획 승인됨 +- [ ] 배포 체크리스트 항목 전체 "완료" 또는 "해당없음" 처리됨 +- [ ] 릴리즈/롤백 체크리스트가 근거와 함께 완료됨 +- [ ] 배포 후 관찰 항목이 정의됨 +- [ ] Operations에 전달할 관찰 포인트, 장애 트리거, 후속 대응 절차 준비됨 +- [ ] 승인된 예외 이력 인계됨 +- [ ] 최종 승인 + - {{CONFIRM: Release 초안 승인 여부를 확인하라}} + +# 8. 파일 처리 결과 +- 생성/갱신 경로: + +# 9. 사용자 결정 필요 항목 요약 +## {{DECIDE}} +- (없으면 이 섹션 제거) + +## {{CONFIRM}} +- Release 초안 승인 여부를 확인하라. (위치: #7) + +## {{DATA}} +- (없으면 이 섹션 제거) diff --git a/.github/templates/rollback-runbook.template.md b/.github/templates/rollback-runbook.template.md new file mode 100644 index 0000000..d8fceb5 --- /dev/null +++ b/.github/templates/rollback-runbook.template.md @@ -0,0 +1,62 @@ +# Rollback Runbook Template + +## Metadata + +1. Change ID: +2. Release Version: +3. Environment: +4. Owner: +5. On-call Contact: +6. Last Updated (UTC): + +## Trigger Conditions + +1. Error Rate Threshold: +2. Latency Threshold: +3. Availability Threshold: +4. Data Integrity Alarm: +5. Business Impact Trigger: + +## Pre-rollback Checks + +1. 장애 범위 확인(기능/사용자/데이터) +2. 최근 배포 변경점 확인 +3. 백업/스냅샷 가용성 확인 +4. 커뮤니케이션 채널 준비 + +## Rollback Procedure + +1. 트래픽 차단 또는 점진 축소 +2. 이전 안정 버전으로 아티팩트 전환 +3. 마이그레이션 롤백 또는 안전 모드 전환 +4. 캐시/큐/비동기 작업 상태 정리 +5. 서비스 재기동 및 헬스체크 확인 + +## Data Recovery Plan + +1. 복원 대상 데이터 범위: +2. 복원 방법(백업/스냅샷/리플레이): +3. 데이터 무결성 검증 방법: +4. 복원 예상 시간: + +## Validation After Rollback + +1. 핵심 사용자 시나리오 통과 여부 +2. API 오류율 정상화 여부 +3. 지연 시간 정상화 여부 +4. 데이터 정합성 점검 결과 +5. 모니터링 알림 해소 여부 + +## Communication Plan + +1. 롤백 선언 메시지(내부) +2. 영향 공지 메시지(외부) +3. 상태 업데이트 주기 +4. 종료 공지 조건 + +## Post-rollback Follow-up + +1. 원인 분석 티켓: +2. 재배포 조건: +3. 임시 완화책 제거 계획: +4. Postmortem 일정: diff --git a/.github/templates/verification-note.template.md b/.github/templates/verification-note.template.md new file mode 100644 index 0000000..fd73a54 --- /dev/null +++ b/.github/templates/verification-note.template.md @@ -0,0 +1,83 @@ +# 0. 문서 상태 +- 상태: draft +- 승인자: {{DECIDE: 이 Verification의 최종 승인자는 누구인가?}} +- 승인 시각: {{CONFIRM: 승인 후 기재}} + +# 1. Verification 개요 +- 입력 Implementation: +- 목적: +- 검증 대상 작업: + - 1순위: + - 2순위: + - 3순위: + +# 2. 검증 범위 +## In Scope +- + +## Out of Scope +- + +# 3. AC별 검증 결과 + +| Impl ID | AC | 검증 방법 | 결과 (통과/실패/보류) | 비고 | +|---|---|---|---|---| +| I-001 | | | | | + +## 품질 게이트 판정 +- Blocker 결함 수: +- Major 결함 수: +- 승인된 예외 건수: +- 배포 가능 여부: {{DECIDE: 배포 가능/불가 중 선택하라}} + +# 4. 결함 목록 + +| 결함 ID | 연결 Impl ID | 심각도 (Blocker/Major/Minor) | 증상 | 재현 여부 | 처리 상태 | +|---|---|---|---|---|---| +| D-001 | | | | | | + +## 심각도 기준 +- Blocker: 서비스 중단, 데이터 손실/오염, 보안 취약점 악용 가능 상태 +- Major: 핵심 기능 오동작, 우회 가능하지만 사용자 영향이 큰 결함 +- Minor: 비핵심 기능 이슈, 문구/표시 오류, 영향이 제한적인 결함 + +# 5. 회귀 테스트 결과 + +| 테스트 항목 | 영향 영역 | 실행 결과 | 실패 시 원인 | +|---|---|---|---| +| | | | | + +## 회귀 리스크 평가 +- 영향 영역: +- 롤백 조건: + +# 6. 예외 승인 목록 + +| 예외 ID | 연결 결함 | 심각도 | 완화책 | 승인자 | 승인 시각 (UTC) | 유효 기간 (UTC) | +|---|---|---|---|---|---|---| +| | | | | | | | + +> 예외 없음 시 이 섹션을 "해당 없음"으로 처리한다. + +# 7. Release 단계 전달 체크 +- [ ] Blocker 결함 0건 확인 +- [ ] Major 결함 0건 또는 승인된 예외 존재 +- [ ] 변경 코드 경로의 테스트 실행 증거(로그/리포트) 첨부 +- [ ] 신규 기능의 정상 경로 테스트 1개 이상 및 예외 경로 테스트 1개 이상 확인 +- [ ] 회귀 테스트 실패 없음 또는 원인 분석/롤백 계획 존재 +- [ ] Release에 전달할 배포 가능 여부, 예외 승인 정보, 잔여 리스크 준비됨 +- [ ] 최종 승인 + - {{CONFIRM: Verification 초안 승인 여부를 확인하라}} + +# 8. 파일 처리 결과 +- 생성/갱신 경로: + +# 9. 사용자 결정 필요 항목 요약 +## {{DECIDE}} +- (없으면 이 섹션 제거) + +## {{CONFIRM}} +- Verification 초안 승인 여부를 확인하라. (위치: #7) + +## {{DATA}} +- (없으면 이 섹션 제거) diff --git a/.github/tools/calc_priority_scores.sh b/.github/tools/calc_priority_scores.sh new file mode 100755 index 0000000..0268819 --- /dev/null +++ b/.github/tools/calc_priority_scores.sh @@ -0,0 +1,56 @@ +#!/usr/bin/env bash +set -euo pipefail + +if [[ $# -lt 1 ]]; then + echo "Usage: $0 [output_csv]" + exit 1 +fi + +infile="$1" +outfile="${2:-}" + +tmp_scored="$(mktemp)" +tmp_sorted="$(mktemp)" +trap 'rm -f "$tmp_scored" "$tmp_sorted"' EXIT + +awk -F',' 'BEGIN { OFS="," } +NR==1 { + print "item_id","work_item","method","wsjf_score","rice_score","selected_score","notes" + next +} +{ + item=$1 + work=$2 + bv=$3+0 + tc=$4+0 + rroe=$5+0 + js=$6+0 + reach=$7+0 + impact=$8+0 + conf=$9+0 + effort=$10+0 + method=toupper($11) + notes=$12 + + wsjf=(js==0)?0:((bv+tc+rroe)/js) + rice=(effort==0)?0:((reach*impact*conf)/effort) + selected=(method=="RICE")?rice:wsjf + + printf "%s,%s,%s,%.4f,%.4f,%.4f,%s\n", item, work, method, wsjf, rice, selected, notes +} +' "$infile" > "$tmp_scored" + +{ + head -n 1 "$tmp_scored" + tail -n +2 "$tmp_scored" | sort -t',' -k6,6gr +} > "$tmp_sorted" + +awk -F',' 'BEGIN { OFS="," } +NR==1 { + print $0, "priority" + next +} +{ + print $0, NR-1 +} +' "$tmp_sorted" > "${outfile:-/dev/stdout}"