From 3a1afaac46306337a776f182d296aecc398ae955 Mon Sep 17 00:00:00 2001 From: Justin Ko Date: Thu, 23 Apr 2026 04:31:42 +0000 Subject: [PATCH] Squashed '.vendor/stage-pilot/' changes from c24b25d..3a72413 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 3a72413 Merge pull request #5 from genichin/copilot/add-verification-steps-sdlc-prompt d362b6b feat: add verification stage to run-sdlc pipeline 9b52ae1 Initial plan 893d465 Merge pull request #3 from genichin/copilot/add-sdlc-prompt-feature 57b3941 feat: add /run-sdlc prompt for automated SDLC pipeline execution 27396ab Initial plan 6979011 Clarify draft creation for new SDLC prompts 1c5557b fix(bootstrap): sdlc 디렉토리 구조 단순화 및 summary 템플릿 추가 af343e5 docs(prompt): SDLC 프롬프트 저장소 현황 탐색 및 대조 절차 강화 cc55e06 chore: Release/Operations 프로세스 템플릿 및 프롬프트 추가 및 README 최신화 386695b commit 4533017 draft 82b7690 draft-design 0503411 draft 9984db0 confirm-discovery, draft-planning, review-planning 명령 추가 cba64f0 add confirm-discovery prompt 9391537 draft 58f2de8 feat: execute implementation during run-sdlc flow 693e3f6 feat: auto-create downstream drafts in run-sdlc 404bc63 docs: translate SDLC orchestration prompts to English 9018e8f feat: add SDLC scaffold and sequential run commands d60e21c docs: clarify when to create a new discovery 0629eee feat: add operation issue triage prompt cdc8d87 feat: make update.sh auto-overwrite by default with --no-overwrite option ead06c2 chore: add execute tool to all prompt files git-subtree-dir: .vendor/stage-pilot git-subtree-split: 3a72413acd2edd95053631f900d3c99c1caef359 --- .github/AGENTS.md | 23 -- .github/SDLC-CHANGELOG.md | 315 ------------------ .github/START-HERE.md | 60 ---- .github/agents/builder.agent.md | 46 --- .github/agents/planner.agent.md | 46 --- .github/agents/releaser.agent.md | 46 --- .github/agents/reviewer.agent.md | 46 --- .../instructions/01-discovery.instructions.md | 108 ------ .../instructions/02-planning.instructions.md | 114 ------- .../instructions/03-design.instructions.md | 49 --- .../04-implementation.instructions.md | 49 --- .../05-verification.instructions.md | 117 ------- .../instructions/06-release.instructions.md | 72 ---- .../07-operations.instructions.md | 78 ----- .github/instructions/placeholder-guide.md | 243 ++++++++++++++ .github/prompts/commit.prompt.md | 54 --- .github/prompts/confirm-design.prompt.md | 103 ++++++ .github/prompts/confirm-discovery.prompt.md | 103 ++++++ .../prompts/confirm-implementation.prompt.md | 99 ++++++ .github/prompts/confirm-operation.prompt.md | 97 ++++++ .github/prompts/confirm-planning.prompt.md | 103 ++++++ .github/prompts/confirm-release.prompt.md | 97 ++++++ .../prompts/confirm-verification.prompt.md | 99 ++++++ .github/prompts/design-confirm.prompt.md | 63 ---- .github/prompts/design-draft.prompt.md | 85 ----- .github/prompts/design-review.prompt.md | 84 ----- .github/prompts/discovery-confirm.prompt.md | 55 --- .github/prompts/discovery-draft.prompt.md | 107 ------ .github/prompts/discovery-review.prompt.md | 80 ----- .github/prompts/draft-design.prompt.md | 95 ++++++ .../prompts/draft-implementation.prompt.md | 82 +++++ .github/prompts/draft-operation.prompt.md | 83 +++++ .github/prompts/draft-planning.prompt.md | 99 ++++++ .github/prompts/draft-release.prompt.md | 81 +++++ .github/prompts/draft-verification.prompt.md | 82 +++++ .../prompts/implementation-confirm.prompt.md | 64 ---- .../prompts/implementation-draft.prompt.md | 85 ----- .github/prompts/implementation.prompt.md | 79 ----- .github/prompts/new-sdlc.prompt.md | 173 ++++++++++ .github/prompts/operation-confirm.prompt.md | 67 ---- .github/prompts/operation-draft.prompt.md | 85 ----- .github/prompts/operation-review.prompt.md | 63 ---- .github/prompts/planning-confirm.prompt.md | 56 ---- .github/prompts/planning-draft.prompt.md | 95 ------ .github/prompts/planning-review.prompt.md | 83 ----- .github/prompts/release-confirm.prompt.md | 63 ---- .github/prompts/release-draft.prompt.md | 85 ----- .github/prompts/release-review.prompt.md | 80 ----- .github/prompts/review-design.prompt.md | 148 ++++++++ .github/prompts/review-discovery.prompt.md | 87 +++++ .../prompts/review-implementation.prompt.md | 111 ++++++ .github/prompts/review-operation.prompt.md | 110 ++++++ .github/prompts/review-planning.prompt.md | 127 +++++++ .github/prompts/review-release.prompt.md | 110 ++++++ .github/prompts/review-verification.prompt.md | 114 +++++++ .github/prompts/run-implementation.prompt.md | 99 ++++++ .github/prompts/run-sdlc.prompt.md | 257 ++++++++++++++ .../prompts/verification-confirm.prompt.md | 63 ---- .github/prompts/verification-draft.prompt.md | 84 ----- .github/prompts/verification-review.prompt.md | 83 ----- .../runbooks/services/api.rollback-runbook.md | 60 ---- .../runbooks/services/web.rollback-runbook.md | 58 ---- .../services/worker.rollback-runbook.md | 58 ---- .github/scripts/bootstrap.sh | 102 ------ .github/skills/release-notes/SKILL.md | 26 -- .../skills/requirements-refinement/SKILL.md | 26 -- .github/skills/test-design/SKILL.md | 26 -- .github/templates/design-note.template.md | 71 ---- .github/templates/discovery-note.template.md | 90 ----- .../templates/implementation-note.template.md | 62 ---- .github/templates/operations-note.template.md | 80 ----- .../planning-backlog-scores.template.csv | 4 - .github/templates/planning-note.template.md | 63 ---- .../planning-scoring-sheet.template.csv | 4 - .github/templates/release-note.template.md | 105 ------ .../templates/rollback-runbook.template.md | 62 ---- .github/templates/sdlc/1_discovery.md | 219 ++++++++++++ .github/templates/sdlc/2_planning.md | 205 ++++++++++++ .github/templates/sdlc/3_design.md | 187 +++++++++++ .github/templates/sdlc/4_implementation.md | 155 +++++++++ .github/templates/sdlc/5_verification.md | 160 +++++++++ .github/templates/sdlc/6_release.md | 162 +++++++++ .github/templates/sdlc/7_operation.md | 154 +++++++++ .github/templates/sdlc/index.md | 12 + .github/templates/sdlc/summary.md | 16 + .../templates/verification-note.template.md | 83 ----- .github/tools/calc_priority_scores.sh | 56 ---- .gitignore | 3 +- README.md | 97 ++++-- bootstrap/bootstrap.sh | 8 +- bootstrap/update.sh | 13 +- docs/sdlc/index.md | 21 ++ .../1_discovery.md | 202 +++++++++++ .../sdlc-001_20260417_stage-pilot/index.md | 12 + .../sdlc-001_20260417_stage-pilot/summary.md | 14 + 95 files changed, 4405 insertions(+), 3905 deletions(-) delete mode 100644 .github/AGENTS.md delete mode 100644 .github/SDLC-CHANGELOG.md delete mode 100644 .github/START-HERE.md delete mode 100644 .github/agents/builder.agent.md delete mode 100644 .github/agents/planner.agent.md delete mode 100644 .github/agents/releaser.agent.md delete mode 100644 .github/agents/reviewer.agent.md delete mode 100644 .github/instructions/01-discovery.instructions.md delete mode 100644 .github/instructions/02-planning.instructions.md delete mode 100644 .github/instructions/03-design.instructions.md delete mode 100644 .github/instructions/04-implementation.instructions.md delete mode 100644 .github/instructions/05-verification.instructions.md delete mode 100644 .github/instructions/06-release.instructions.md delete mode 100644 .github/instructions/07-operations.instructions.md create mode 100644 .github/instructions/placeholder-guide.md delete mode 100644 .github/prompts/commit.prompt.md create mode 100644 .github/prompts/confirm-design.prompt.md create mode 100644 .github/prompts/confirm-discovery.prompt.md create mode 100644 .github/prompts/confirm-implementation.prompt.md create mode 100644 .github/prompts/confirm-operation.prompt.md create mode 100644 .github/prompts/confirm-planning.prompt.md create mode 100644 .github/prompts/confirm-release.prompt.md create mode 100644 .github/prompts/confirm-verification.prompt.md delete mode 100644 .github/prompts/design-confirm.prompt.md delete mode 100644 .github/prompts/design-draft.prompt.md delete mode 100644 .github/prompts/design-review.prompt.md delete mode 100644 .github/prompts/discovery-confirm.prompt.md delete mode 100644 .github/prompts/discovery-draft.prompt.md delete mode 100644 .github/prompts/discovery-review.prompt.md create mode 100644 .github/prompts/draft-design.prompt.md create mode 100644 .github/prompts/draft-implementation.prompt.md create mode 100644 .github/prompts/draft-operation.prompt.md create mode 100644 .github/prompts/draft-planning.prompt.md create mode 100644 .github/prompts/draft-release.prompt.md create mode 100644 .github/prompts/draft-verification.prompt.md delete mode 100644 .github/prompts/implementation-confirm.prompt.md delete mode 100644 .github/prompts/implementation-draft.prompt.md delete mode 100644 .github/prompts/implementation.prompt.md create mode 100644 .github/prompts/new-sdlc.prompt.md delete mode 100644 .github/prompts/operation-confirm.prompt.md delete mode 100644 .github/prompts/operation-draft.prompt.md delete mode 100644 .github/prompts/operation-review.prompt.md delete mode 100644 .github/prompts/planning-confirm.prompt.md delete mode 100644 .github/prompts/planning-draft.prompt.md delete mode 100644 .github/prompts/planning-review.prompt.md delete mode 100644 .github/prompts/release-confirm.prompt.md delete mode 100644 .github/prompts/release-draft.prompt.md delete mode 100644 .github/prompts/release-review.prompt.md create mode 100644 .github/prompts/review-design.prompt.md create mode 100644 .github/prompts/review-discovery.prompt.md create mode 100644 .github/prompts/review-implementation.prompt.md create mode 100644 .github/prompts/review-operation.prompt.md create mode 100644 .github/prompts/review-planning.prompt.md create mode 100644 .github/prompts/review-release.prompt.md create mode 100644 .github/prompts/review-verification.prompt.md create mode 100644 .github/prompts/run-implementation.prompt.md create mode 100644 .github/prompts/run-sdlc.prompt.md delete mode 100644 .github/prompts/verification-confirm.prompt.md delete mode 100644 .github/prompts/verification-draft.prompt.md delete mode 100644 .github/prompts/verification-review.prompt.md delete mode 100644 .github/runbooks/services/api.rollback-runbook.md delete mode 100644 .github/runbooks/services/web.rollback-runbook.md delete mode 100644 .github/runbooks/services/worker.rollback-runbook.md delete mode 100644 .github/scripts/bootstrap.sh delete mode 100644 .github/skills/release-notes/SKILL.md delete mode 100644 .github/skills/requirements-refinement/SKILL.md delete mode 100644 .github/skills/test-design/SKILL.md delete mode 100644 .github/templates/design-note.template.md delete mode 100644 .github/templates/discovery-note.template.md delete mode 100644 .github/templates/implementation-note.template.md delete mode 100644 .github/templates/operations-note.template.md delete mode 100644 .github/templates/planning-backlog-scores.template.csv delete mode 100644 .github/templates/planning-note.template.md delete mode 100644 .github/templates/planning-scoring-sheet.template.csv delete mode 100644 .github/templates/release-note.template.md delete mode 100644 .github/templates/rollback-runbook.template.md create mode 100644 .github/templates/sdlc/1_discovery.md create mode 100644 .github/templates/sdlc/2_planning.md create mode 100644 .github/templates/sdlc/3_design.md create mode 100644 .github/templates/sdlc/4_implementation.md create mode 100644 .github/templates/sdlc/5_verification.md create mode 100644 .github/templates/sdlc/6_release.md create mode 100644 .github/templates/sdlc/7_operation.md create mode 100644 .github/templates/sdlc/index.md create mode 100644 .github/templates/sdlc/summary.md delete mode 100644 .github/templates/verification-note.template.md delete mode 100755 .github/tools/calc_priority_scores.sh create mode 100644 docs/sdlc/index.md create mode 100644 docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md create mode 100644 docs/sdlc/sdlc-001_20260417_stage-pilot/index.md create mode 100644 docs/sdlc/sdlc-001_20260417_stage-pilot/summary.md diff --git a/.github/AGENTS.md b/.github/AGENTS.md deleted file mode 100644 index 5cdd60d..0000000 --- a/.github/AGENTS.md +++ /dev/null @@ -1,23 +0,0 @@ -# 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/SDLC-CHANGELOG.md b/.github/SDLC-CHANGELOG.md deleted file mode 100644 index 6b42c07..0000000 --- a/.github/SDLC-CHANGELOG.md +++ /dev/null @@ -1,315 +0,0 @@ -# SDLC Rules Changelog - -## Update 01 - Initial Baseline (2026-04-14) - -### Scope - -1. 전역 SDLC 거버넌스 규칙 생성 -2. 7단계 instructions 생성 -3. 역할별 agents 생성 -4. 공통 skills 3종 생성 - -### Added Files - -1. .github/copilot-instructions.md -2. .github/AGENTS.md -3. .github/instructions/01-discovery.instructions.md -4. .github/instructions/02-planning.instructions.md -5. .github/instructions/03-design.instructions.md -6. .github/instructions/04-implementation.instructions.md -7. .github/instructions/05-verification.instructions.md -8. .github/instructions/06-release.instructions.md -9. .github/instructions/07-operations.instructions.md -10. .github/agents/planner.agent.md -11. .github/agents/builder.agent.md -12. .github/agents/reviewer.agent.md -13. .github/agents/releaser.agent.md -14. .github/skills/requirements-refinement/SKILL.md -15. .github/skills/test-design/SKILL.md -16. .github/skills/release-notes/SKILL.md - -### Notes - -1. 단계 스킵 금지 및 핫픽스 예외 경로를 전역 규칙에 포함 -2. 각 단계에 DoR/DoD를 명시해 게이트 기반 전환 지원 -3. 스킬 description에 Use when 트리거를 넣어 자동 탐지성 강화 - -## Update 02 - Stage Rule Hardening (2026-04-14) - -### Scope - -1. Discovery 단계 질문 템플릿 강화 -2. Planning 단계 WSJF/RICE 우선순위 규칙 추가 -3. Verification 단계 품질 게이트 엄격화 -4. Release/Operations 롤백 및 포스트모템 체크리스트 상세화 - -### Changed Files - -1. .github/instructions/01-discovery.instructions.md -2. .github/instructions/02-planning.instructions.md -3. .github/instructions/05-verification.instructions.md -4. .github/instructions/06-release.instructions.md -5. .github/instructions/07-operations.instructions.md - -### Verification - -1. 단계별 필수 섹션(템플릿/공식/게이트/체크리스트) 존재 여부 확인 -2. DoD 강화 항목 반영 여부 확인 - -### Follow-up - -1. Planning 점수 예시(샘플 backlog) 추가 -2. Verification 예외 승인 워크플로우 문서화 -3. Release 런북 템플릿 파일 분리 - -## Update 03 - Templates and Governance Completion (2026-04-14) - -### Scope - -1. Planning에 WSJF/RICE 샘플 백로그 점수표 템플릿 추가 -2. Verification에 예외 승인 워크플로우(승인자/유효기간) 표준 템플릿 추가 -3. Release에 롤백 런북을 별도 템플릿 파일로 분리 - -### Changed Files - -1. .github/instructions/02-planning.instructions.md -2. .github/instructions/05-verification.instructions.md -3. .github/instructions/06-release.instructions.md -4. .github/templates/rollback-runbook.template.md - -### Verification - -1. Planning에 WSJF/RICE 샘플 테이블 섹션 존재 확인 -2. Verification에 Exception Approval Workflow 및 Exception Record Template 존재 확인 -3. Release가 분리된 롤백 런북 템플릿 경로를 참조하는지 확인 - -### Follow-up - -1. WSJF/RICE 점수표 자동 계산 스크립트 여부 검토 -2. 예외 승인 템플릿의 승인자 역할 정책 세분화 -3. 롤백 런북 실제 서비스별 인스턴스 문서 작성 - -## Update 04 - Project Start Readiness (2026-04-14) - -### Scope - -1. 서비스별 롤백 런북 인스턴스 문서 생성 -2. Planning 점수표 자동 계산 스크립트/시트 템플릿 추가 -3. Verification 예외 승인 권한 정책(역할별 승인 범위) 고도화 -4. 프로젝트 시작 가이드 문서 추가 - -### Changed Files - -1. .github/runbooks/services/api.rollback-runbook.md -2. .github/runbooks/services/worker.rollback-runbook.md -3. .github/runbooks/services/web.rollback-runbook.md -4. .github/templates/planning-backlog-scores.template.csv -5. .github/templates/planning-scoring-sheet.template.csv -6. .github/tools/calc_priority_scores.sh -7. .github/instructions/02-planning.instructions.md -8. .github/instructions/05-verification.instructions.md -9. .github/instructions/06-release.instructions.md -10. .github/START-HERE.md - -### Verification - -1. 서비스별 런북 인스턴스 파일 생성 확인 -2. Planning 스크립트 실행으로 priority 산출 가능 여부 확인 -3. Verification 문서에 Approval Authority Matrix/Policy Rules 반영 확인 - -### Follow-up - -1. 서비스별 실제 운영 연락처/임계치 값 최신화 -2. 점수 계산 결과를 CI 아티팩트로 저장하는 자동화 검토 -3. 운영 단계 Postmortem 템플릿과 티켓 시스템 연동 - -## Update 05 - Discovery Artifact Convention (2026-04-14) - -### Scope - -1. Discovery 문서 저장 폴더/파일명 규칙 표준화 -2. Discovery 작성 템플릿 파일 추가 -3. Discovery Freeze 필수 필드 규정 반영 - -### Changed Files - -1. .github/instructions/01-discovery.instructions.md -2. .github/discovery/README.md -3. .github/templates/discovery-note.template.md -4. .github/START-HERE.md - -### Verification - -1. Discovery instructions에 Artifact Convention 섹션 존재 확인 -2. 템플릿 파일로 즉시 문서 작성 가능한지 확인 -3. 시작 가이드에 경로/파일명 규칙 노출 확인 - -### Follow-up - -1. /discovery-draft 출력을 .github/discovery/ 파일로 자동 저장하는 워크플로우 검토 -2. Discovery 승인자 역할(Approver) 기본값 정책 확정 - -## Update 06 - Discovery Output Path Migration (2026-04-14) - -### Scope - -1. Discovery 산출물 저장 경로를 .github에서 프로젝트 폴더로 전환 -2. 신규 표준 경로 docs/sdlc/discovery/ 적용 -3. 레거시 .github/discovery 경로는 안내 전용으로 전환 - -### Changed Files - -1. .github/instructions/01-discovery.instructions.md -2. .github/START-HERE.md -3. .github/prompts/discovery-draft.prompt.md -4. docs/sdlc/discovery/README.md -5. .github/discovery/README.md - -### Verification - -1. Discovery 규칙 문서의 저장 경로가 docs/sdlc/discovery/로 표기되는지 확인 -2. 시작 가이드가 동일 경로를 참조하는지 확인 -3. 프롬프트가 저장 요청 시 신규 경로/파일명 규칙을 따르는지 확인 - -### Follow-up - -1. 기존 .github/discovery 문서의 점진적 마이그레이션 일정 수립 -2. Planning/Verification 산출물 경로도 프로젝트 폴더로 통일할지 검토 - -## Update 07 - discovery-draft Auto Creation Flow (2026-04-14) - -### Scope - -1. /discovery-draft 실행 시 현재 계획 상태 확인 절차 추가 -2. 기존 요구사항/신규 요구사항 판정 로직 추가 -3. 신규 요구사항일 때 docs/sdlc/discovery/에 자동 초안 생성 규칙 추가 - -### Changed Files - -1. .github/prompts/discovery-draft.prompt.md -2. docs/sdlc/discovery/README.md - -### Verification - -1. 프롬프트에 계획 상태 요약 섹션 포함 확인 -2. 프롬프트에 요구사항 판정 결과(기존/신규) 섹션 포함 확인 -3. 자동 생성 경로 docs/sdlc/discovery/ 표기 확인 - -### Follow-up - -1. docs/sdlc/discovery를 단일 표준 경로로 유지 -2. 판정 기준(키워드 60%)의 팀별 튜닝 기준 문서화 - -## Update 08 - Path Standardization to docs/sdlc (2026-04-14) - -### Scope - -1. discovery-draft 자동 생성 경로를 docs/sdlc/discovery로 통일 -2. 잘못 표기된 docs/sldc 참조 제거 및 표기 정리 - -### Changed Files - -1. .github/prompts/discovery-draft.prompt.md -2. .github/SDLC-CHANGELOG.md - -### Verification - -1. 프롬프트에서 docs/sldc 문자열 제거 확인 -2. 프롬프트 생성 경로가 docs/sdlc/discovery로 표기되는지 확인 - -### Follow-up - -1. 남아있는 레거시 docs/sldc 폴더 정리 - -## Update 09 - Auto Discovery Freeze Generation (2026-04-14) - -### Scope - -1. /discovery-draft 결과에 Discovery Freeze 섹션을 필수 포함 -2. 신규 Discovery 파일 자동 생성 시 Freeze 필수 필드 자동 채움 규칙 추가 - -### Changed Files - -1. .github/prompts/discovery-draft.prompt.md -2. .github/SDLC-CHANGELOG.md - -### Verification - -1. 프롬프트 출력 섹션에 Discovery Freeze 포함 여부 확인 -2. 프롬프트 규칙에 Freeze 필드 강제 규칙 포함 여부 확인 - -### Follow-up - -1. 기존 Discovery 문서에 Freeze 누락 여부 배치 점검 - -## Update 10 - Discovery Freeze Confirmation Gate (2026-04-14) - -### Scope - -1. Discovery Freeze에 사용자 확인 항목(User Confirmation Checklist) 추가 -2. 완료 플래그(Freeze Status Flag) 추가 -3. /discovery-draft 자동 생성 시 기본값 미완료([ ], Ready for Planning: false) 강제 - -### Changed Files - -1. .github/instructions/01-discovery.instructions.md -2. .github/templates/discovery-note.template.md -3. .github/prompts/discovery-draft.prompt.md -4. docs/sdlc/discovery/2026-04-14-embedded-module-integration-new-and-existing-projects.discovery.md - -### Verification - -1. Discovery Freeze Required Fields에 Checklist/Flag 포함 확인 -2. 템플릿에 체크박스/플래그 기본값 존재 확인 -3. 현재 Discovery 문서에 즉시 체크 가능한 항목 반영 확인 - -### Follow-up - -1. 기존 Discovery 문서 일괄 점검 후 동일 형식으로 정규화 - -## Update 11 - Discovery Document ID Naming (2026-04-14) - -### Scope - -1. Discovery 파일명 규칙을 문서번호 시작 형식으로 변경 -2. 날짜를 생성일 메타데이터로 유지하는 원칙 명시 -3. discovery-draft 자동 생성 규칙을 새 파일명 형식에 맞게 갱신 - -### Changed Files - -1. .github/instructions/01-discovery.instructions.md -2. .github/prompts/discovery-draft.prompt.md -3. .github/discovery/README.md -4. .github/START-HERE.md -5. docs/sdlc/discovery/README.md - -### Verification - -1. Discovery 규칙 문서에 dcy-<3자리문서번호>_YYYY-MM-DD_.discovery.md 형식 반영 확인 -2. discovery-draft 프롬프트에 문서번호 계산 규칙 반영 확인 -3. 사용자 안내 문서의 예시 파일명이 새 규칙으로 갱신되었는지 확인 - -### Follow-up - -1. 기존 Discovery 산출물의 파일명 이관 여부는 필요 시 별도 결정 - -## Update Template - -### Scope - -1. 변경 대상 단계 -2. 변경 이유 -3. 기대 효과 - -### Changed Files - -1. path/to/file - -### Verification - -1. 검증 방법 -2. 결과 - -### Follow-up - -1. 다음 업데이트 항목 diff --git a/.github/START-HERE.md b/.github/START-HERE.md deleted file mode 100644 index 0e04da7..0000000 --- a/.github/START-HERE.md +++ /dev/null @@ -1,60 +0,0 @@ -# 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 - -## 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 deleted file mode 100644 index a38f01d..0000000 --- a/.github/agents/builder.agent.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -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 deleted file mode 100644 index da536aa..0000000 --- a/.github/agents/planner.agent.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -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 deleted file mode 100644 index 1dd3aea..0000000 --- a/.github/agents/releaser.agent.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -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 deleted file mode 100644 index 39a9651..0000000 --- a/.github/agents/reviewer.agent.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -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/instructions/01-discovery.instructions.md b/.github/instructions/01-discovery.instructions.md deleted file mode 100644 index f9119cf..0000000 --- a/.github/instructions/01-discovery.instructions.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -applyTo: "**" -description: "Use when: discovery, problem framing, requirement intake, scope definition" ---- - -# Stage 1 - Discovery - -## Purpose - -문제와 목표를 명확히 정의하고, 요구사항 후보를 수집한다. - -## Stage Contract - -| 항목 | 내용 | -|---|---| -| 입력 | 문제 배경, 사용자/이해관계자 정보, 제약사항 | -| 산출물 | Discovery 문서, 요구사항 목록, 리스크/가정, 성공 기준 | -| 게이트 확인 | 문제 정의, 요구사항, 리스크, 성공 기준이 문서화되어 Planning 입력으로 전달 가능해야 함 | -| 다음 단계 인계 | Planning에 우선순위 후보, 범위 경계, 미해결 질문을 전달 | - -## DoR (Entry) - -1. 요청 배경 또는 문제 상황이 제공됨 -2. 이해관계자 또는 사용자 관점이 최소 1개 이상 식별됨 - -## Required Actions - -1. 문제 정의: 현재 상태, 기대 상태, 제약사항을 정리한다. -2. 요구사항 정제: 기능/비기능 요구사항을 분리한다. -3. 가정/리스크 명시: 불확실한 항목과 영향도를 기록한다. -4. 성공 기준 정의: 완료 판단 기준(측정 가능)을 제안한다. - -## Discovery Question Template - -### A. Problem and Goal - -1. 현재 가장 큰 문제는 무엇인가? -2. 이 변경으로 달성하고 싶은 기대 상태는 무엇인가? -3. 성공을 어떤 지표로 측정할 것인가? - -### B. Users and Stakeholders - -1. 주요 사용자와 이해관계자는 누구인가? -2. 사용자별로 가장 중요한 시나리오는 무엇인가? -3. 승인/의사결정자는 누구인가? - -### C. Scope and Constraints - -1. 이번 반복에서 반드시 포함할 범위는 무엇인가? -2. 명시적으로 제외할 범위는 무엇인가? -3. 일정, 비용, 기술, 정책 제약은 무엇인가? - -### D. Quality and Risk - -1. 성능, 보안, 가용성, 규정 준수 요구사항은 무엇인가? -2. 실패 시 가장 큰 영향은 무엇이며 우회책은 있는가? -3. 현재 정보에서 불확실한 항목은 무엇인가? - -### E. Dependency and Data - -1. 연동해야 하는 외부 시스템/팀은 무엇인가? -2. 입력/출력 데이터의 출처와 품질 기준은 무엇인가? -3. 마이그레이션 또는 호환성 이슈가 있는가? - -## Questioning Rules - -1. 질문은 최소 1개 사용자 관점과 1개 운영 관점을 포함한다. -2. 답변이 없는 항목은 가정으로 대체하지 말고 Open Questions로 승격한다. -3. 고위험 항목(보안, 데이터 손실, 장애 확산)은 우선 질문으로 분류한다. -4. Discovery 종료 전 질문-답변 매핑표를 만든다. - -## Artifact Convention - -1. 저장 폴더: docs/sdlc/discovery/ -2. 파일명 형식: dcy-<3자리문서번호>_YYYY-MM-DD_.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 deleted file mode 100644 index fe02d53..0000000 --- a/.github/instructions/02-planning.instructions.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -applyTo: "**" -description: "Use when: planning, prioritization, sprint slicing, estimation" ---- - -# Stage 2 - Planning - -## Purpose - -요구사항을 실행 가능한 작업 단위로 분해하고 우선순위를 결정한다. - -## Stage Contract - -| 항목 | 내용 | -|---|---| -| 입력 | confirmed 또는 전달 가능 상태의 Discovery 산출물, 성공 기준, 리스크 목록 | -| 산출물 | Planning 문서, 우선순위 점수표, 작업별 AC, 범위 경계 | -| 게이트 확인 | 우선순위, AC, In Scope/Out of Scope, 점수 근거가 Design 입력으로 충분해야 함 | -| 다음 단계 인계 | Design에 우선순위 상위 작업, AC, 제약사항, 리스크 대응 우선순위를 전달 | - -## DoR (Entry) - -1. Discovery 산출물 존재 -2. 성공 기준 또는 우선순위 기준 존재 - -## Required Actions - -1. 작업 분해: 기능을 작업 단위로 분할한다. -2. 우선순위화: WSJF 또는 RICE로 점수화해 정렬한다. -3. 범위 설정: 이번 반복에서 포함/제외 항목을 명시한다. -4. 완료 기준 확정: 각 작업의 수용 기준(AC)을 정의한다. - -## Prioritization Rules (WSJF/RICE) - -1. 기본값은 WSJF를 사용한다. -2. 시장 도달 범위와 정량 사용자 영향이 핵심인 경우 RICE를 사용한다. -3. 두 방식 모두 계산 근거를 기록하지 않으면 우선순위 확정 불가로 처리한다. - -### WSJF Formula - -WSJF = (Business Value + Time Criticality + Risk Reduction or Opportunity Enablement) / Job Size - -1. 각 항목은 동일 스케일(예: 1~10)로 점수화한다. -2. Job Size 추정 근거(복잡도, 의존성, 불확실성)를 함께 기록한다. - -### RICE Formula - -RICE = (Reach x Impact x Confidence) / Effort - -1. Reach 기간 단위(예: 월간 사용자 수)를 명시한다. -2. Confidence가 50% 미만이면 별도 리스크 플래그를 추가한다. -3. Effort는 팀 기준 단위(인일/스토리포인트)를 고정해 사용한다. - -## Tie-breaker and Override Rules - -1. 점수 동률 시: 리스크 감소 효과가 큰 작업을 우선한다. -2. 규제/보안/장애 복구 관련 항목은 점수와 무관하게 상향 조정 가능하다. -3. 상향/하향 조정 시 사유와 승인자를 기록한다. - -## Sample Backlog Scoring Template - -### WSJF Sample Table - -| Item ID | Work Item | Business Value (1-10) | Time Criticality (1-10) | RR/OE (1-10) | Job Size (1-10) | WSJF Score | Priority | -|---|---|---:|---:|---:|---:|---:|---:| -| P-001 | | | | | | | | -| P-002 | | | | | | | | -| P-003 | | | | | | | | - -계산식: WSJF Score = (Business Value + Time Criticality + RR/OE) / Job Size - -### RICE Sample Table - -| Item ID | Work Item | Reach (period) | Impact | Confidence (%) | Effort | RICE Score | Priority | -|---|---|---:|---:|---:|---:|---:|---:| -| P-001 | | | | | | | | -| P-002 | | | | | | | | -| P-003 | | | | | | | | - -계산식: RICE Score = (Reach x Impact x Confidence) / Effort - -### Scoring Notes Template - -1. Scoring Scale: (예: 1~10, Impact는 0.25/0.5/1/2/3) -2. Reach Period: (예: monthly active users) -3. Confidence Source: (사용 데이터, 인터뷰, 실험) -4. Override Reason and Approver: (예외 조정 사유/승인자) - -## Optional Automation Assets - -1. CSV 템플릿: .github/templates/planning-backlog-scores.template.csv -2. 시트 템플릿: .github/templates/planning-scoring-sheet.template.csv -3. 계산 스크립트: .github/tools/calc_priority_scores.sh -4. 점수 산출물 저장 경로(기본): docs/sdlc/planning/planning-backlog-scores.out.csv -5. Planning 본문 템플릿: .github/templates/planning-note.template.md - -### Automation Usage - -1. 백로그 항목을 CSV 템플릿에 입력한다. -2. 스크립트를 실행해 wsjf_score/rice_score/selected_score/priority를 산출하고, 결과를 docs/sdlc/planning/planning-backlog-scores.out.csv에 저장한다. -3. 산출 결과를 반복 계획 문서의 점수표 근거로 첨부한다. - -## Outputs - -1. 반복 계획(백로그 우선순위) -2. 작업별 수용 기준 -3. 범위 경계(Out of Scope 포함) -4. 우선순위 점수표(WSJF 또는 RICE 계산 근거 포함) - -## DoD (Exit) - -1. Design 단계에 전달 가능한 우선순위 백로그가 존재함 -2. 작업 단위별 완료 기준이 검증 가능 형태임 -3. 우선순위 상위 항목의 계산 근거와 조정 사유가 추적 가능함 diff --git a/.github/instructions/03-design.instructions.md b/.github/instructions/03-design.instructions.md deleted file mode 100644 index 644230b..0000000 --- a/.github/instructions/03-design.instructions.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -applyTo: "**" -description: "Use when: design, architecture, interface contracts, data flow" ---- - -# Stage 3 - Design - -## Purpose - -구현 전 구조와 인터페이스를 명확히 하여 재작업 위험을 줄인다. - -## Stage Contract - -| 항목 | 내용 | -|---|---| -| 입력 | confirmed 상태의 Planning 문서, 우선순위 작업, AC, 리스크 정보 | -| 산출물 | Design 문서, 설계 대안 비교, 인터페이스/데이터 흐름, 테스트 전략 | -| 게이트 확인 | 구현 가능한 설계 근거, 인터페이스, 테스트 포인트, 리스크 대응이 모두 존재해야 함 | -| 다음 단계 인계 | Implementation에 파일 변경 방향, 작업 분해 기준, 검증 포인트를 전달 | - -## DoR (Entry) - -1. Planning 백로그와 수용 기준 존재 -2. 핵심 제약사항이 식별됨 - -## Required Actions - -1. 설계 선택지 비교: 최소 2개 대안을 비교해 근거를 남긴다. -2. 인터페이스 정의: 입력/출력/오류 경로를 명시한다. -3. 데이터/흐름 설계: 주요 데이터 경로와 상태 변화를 정리한다. -4. 테스트 전략 연계: 설계와 검증 포인트를 매핑한다. - -## Outputs - -1. 설계 결정 기록(ADR 또는 동등 문서) -2. 인터페이스/데이터 흐름 정의 -3. 테스트 가능성 관점의 설계 메모 - -## Automation Assets - -1. Design 본문 템플릿: .github/templates/design-note.template.md -2. Design 초안 프롬프트: .github/prompts/design-draft.prompt.md -3. Design 재검토 프롬프트: .github/prompts/design-review.prompt.md -4. Design 승인 프롬프트: .github/prompts/design-confirm.prompt.md - -## DoD (Exit) - -1. Implementation에서 바로 실행 가능한 설계 근거가 존재함 -2. 주요 리스크에 대한 대응 전략이 설계에 반영됨 diff --git a/.github/instructions/04-implementation.instructions.md b/.github/instructions/04-implementation.instructions.md deleted file mode 100644 index bc1da20..0000000 --- a/.github/instructions/04-implementation.instructions.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -applyTo: "**" -description: "Use when: coding, refactoring, implementation tasks" ---- - -# Stage 4 - Implementation - -## Purpose - -설계를 기반으로 변경을 구현하고 테스트 가능한 상태로 만든다. - -## Stage Contract - -| 항목 | 내용 | -|---|---| -| 입력 | confirmed 상태의 Design 문서, 작업별 AC, 구현 범위, 테스트 전략 | -| 산출물 | 코드 변경, 테스트 변경, 변경 근거 요약 | -| 게이트 확인 | 최소 단위 테스트 또는 동등 검증 근거가 있고 Verification 시나리오 전달 준비가 되어야 함 | -| 다음 단계 인계 | Verification에 변경 파일, 실행 근거, 알려진 리스크, 회귀 영향 영역을 전달 | - -## DoR (Entry) - -1. 설계 근거 및 작업 수용 기준 존재 -2. 구현 범위가 명확함 - -## Required Actions - -1. 작은 단위 구현: 변경을 작고 검증 가능한 단위로 나눈다. -2. 테스트 동반: 가능한 경우 테스트를 함께 작성/갱신한다. -3. 영향도 점검: 관련 문서/설정/의존성 영향을 확인한다. -4. 추적 가능성 유지: 어떤 요구사항을 반영했는지 연결한다. - -## Outputs - -1. 코드 변경 -2. 테스트 변경 -3. 변경 근거 요약 - -## Automation Assets - -1. Implementation 본문 템플릿: .github/templates/implementation-note.template.md -2. Implementation 초안 프롬프트: .github/prompts/implementation-draft.prompt.md -3. Implementation 실행 프롬프트: .github/prompts/implementation.prompt.md -4. Implementation 승인 프롬프트: .github/prompts/implementation-confirm.prompt.md - -## DoD (Exit) - -1. 최소 단위 테스트 또는 동등 검증 근거 통과 -2. Verification 단계에서 실행할 검증 시나리오가 준비됨 diff --git a/.github/instructions/05-verification.instructions.md b/.github/instructions/05-verification.instructions.md deleted file mode 100644 index 42dba0d..0000000 --- a/.github/instructions/05-verification.instructions.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -applyTo: "**" -description: "Use when: verification, test review, regression checks, quality gate" ---- - -# Stage 5 - Verification - -## Purpose - -변경이 요구사항을 만족하고 기존 동작을 해치지 않았는지 확인한다. - -## Stage Contract - -| 항목 | 내용 | -|---|---| -| 입력 | Implementation 변경 결과, 테스트 시나리오, 수용 기준, 리스크 정보 | -| 산출물 | 검증 결과 요약, 결함 목록, 품질 게이트 판정, 배포 가능 여부 | -| 게이트 확인 | Blocker 0건, Major 0건 또는 승인된 예외, 테스트 근거 첨부 상태여야 함 | -| 다음 단계 인계 | Release에 배포 가능 여부, 예외 승인 정보, 잔여 리스크를 전달 | - -## DoR (Entry) - -1. Implementation 산출물 존재 -2. 수용 기준과 테스트 시나리오 존재 - -## Required Actions - -1. 수용 기준 검증: AC 충족 여부를 확인한다. -2. 회귀 리스크 점검: 영향 영역을 기반으로 회귀 테스트를 수행한다. -3. 결함 분류: Blocker/Major/Minor로 구분한다. -4. 배포 준비성 판단: 잔여 리스크와 우회책을 기록한다. - -## Strict Quality Gates - -1. Blocker 결함 1건 이상이면 자동 배포 불가 상태로 분류한다. -2. Major 결함은 승인된 예외 없이 0건이어야 한다. -3. 변경 코드 경로의 테스트 실행 증거(로그/리포트)가 없으면 검증 실패로 처리한다. -4. 신규 기능은 최소 1개의 정상 경로 테스트와 1개의 예외 경로 테스트를 포함해야 한다. -5. 회귀 테스트에서 실패가 발생하면 원인 분석 또는 롤백 계획 없이 통과 처리할 수 없다. -6. 보안 또는 데이터 무결성 관련 변경은 전용 체크 항목 결과를 첨부해야 한다. - -## Defect Severity Policy - -1. Blocker: 서비스 중단, 데이터 손실/오염, 보안 취약점 악용 가능 상태 -2. Major: 핵심 기능 오동작, 우회 가능하지만 사용자 영향이 큰 결함 -3. Minor: 비핵심 기능 이슈, 문구/표시 오류, 영향이 제한적인 결함 - -## Required Evidence - -1. AC별 검증 결과(통과/실패/보류) -2. 테스트 실행 결과 요약(실행 범위, 실패 항목, 재현 여부) -3. 잔여 리스크와 완화책 -4. 승인된 예외 목록(사유, 승인자, 유효 기간) - -## Exception Approval Workflow (Template) - -1. Trigger: Major 결함 또는 검증 미충족 항목이 릴리즈 일정상 즉시 수정 불가 -2. Draft Exception: 요청자(보통 Builder/Reviewer)가 아래 템플릿 작성 -3. Review: Reviewer가 영향도와 완화책 타당성 검토 -4. Approve: 지정 승인자(예: Tech Lead, QA Lead, Product Owner) 중 최소 1명 승인 -5. Expiry Control: 유효 기간 만료 전 재검증 또는 예외 연장 재승인 -6. Closure: 예외 해소 후 결과와 증빙을 검증 리포트에 반영 - -## Approval Authority Matrix - -1. Minor + Low/Medium Risk: Reviewer 또는 QA Lead 단독 승인 가능, 최대 유효기간 14일 -2. Major + Medium Risk: Reviewer 검토 후 Tech Lead + QA Lead 2인 승인, 최대 유효기간 7일 -3. Major + High Risk: Reviewer 검토 후 Tech Lead + Product Owner 2인 승인, 최대 유효기간 3일 -4. Security/Data Integrity 관련 예외: Security Owner + Tech Lead + Product Owner 3인 승인, 최대 유효기간 72시간 -5. 동일 예외 2회 이상 연장은 최초 승인자 외 추가 승인자 1인 이상이 필요 - -## Approval Policy Rules - -1. 승인자는 요청자(작성자)와 동일 인물일 수 없다. -2. Valid Until은 UTC 기준으로 명시하며 만료 시 자동 재검증 상태로 전환한다. -3. 만료 전 재검증 실패 시 예외는 즉시 종료되고 배포 가능 상태를 재평가한다. -4. 예외 승인 건은 Release 전달 시 승인 이력(승인자, 시각, 유효기간)을 포함해야 한다. - -### Exception Record Template - -| Field | Value | -|---|---| -| Exception ID | EX-YYYYMMDD-001 | -| Related Change | | -| Defect Severity | Major / Minor | -| Reason | | -| User Impact | | -| Risk Level | High / Medium / Low | -| Mitigation | | -| Approver(s) | | -| Approval Scope | Minor-Low/Medium, Major-Medium, Major-High, Security/Data Integrity | -| Approved At (UTC) | | -| Valid Until (UTC) | | -| Re-validation Owner | | -| Re-validation Date | | -| Final Closure Evidence | | - -## Outputs - -1. 검증 결과 요약 -2. 발견 결함 목록 및 우선순위 -3. 배포 가능 여부 판단 -4. 품질 게이트 체크 결과(통과/실패 + 근거) - -## Automation Assets - -1. Verification 본문 템플릿: .github/templates/verification-note.template.md -2. Verification 초안 프롬프트: .github/prompts/verification-draft.prompt.md -3. Verification 재검토 프롬프트: .github/prompts/verification-review.prompt.md -4. Verification 승인 프롬프트: .github/prompts/verification-confirm.prompt.md - -## DoD (Exit) - -1. Blocker 결함 0건 -2. Major 결함 0건 또는 승인된 예외 문서 존재 -3. 테스트 및 회귀 검증 근거가 첨부됨 -4. Release 단계 전달 가능한 품질 상태 보고가 있음 diff --git a/.github/instructions/06-release.instructions.md b/.github/instructions/06-release.instructions.md deleted file mode 100644 index 8201100..0000000 --- a/.github/instructions/06-release.instructions.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -applyTo: "**" -description: "Use when: release planning, deployment readiness, rollback planning" ---- - -# Stage 6 - Release - -## Purpose - -배포 전후 위험을 통제하고 안정적으로 변경을 반영한다. - -## Stage Contract - -| 항목 | 내용 | -|---|---| -| 입력 | Verification 결과, 배포 대상 범위, 승인된 예외, 롤백 필요 정보 | -| 산출물 | 배포 체크리스트 결과, 롤백 계획, 릴리즈 노트, 관찰 계획 | -| 게이트 확인 | 롤백 가능한 배포 계획과 운영 관찰 항목이 준비되어야 함 | -| 다음 단계 인계 | Operations에 관찰 포인트, 장애 트리거, 후속 대응 절차를 전달 | - -## DoR (Entry) - -1. Verification 결과 존재 -2. 배포 대상 범위가 확정됨 - -## Required Actions - -1. 배포 체크리스트 점검: 설정, 마이그레이션, 호환성 확인 -2. 롤백 계획 준비: 실패 조건과 복구 절차 명시 -3. 커뮤니케이션 준비: 변경사항/영향/대응 안내 작성 -4. 배포 후 관찰 계획: 모니터링 포인트 정의 -5. 롤백 런북 작성: 분리된 템플릿 파일을 기반으로 Trigger/Procedure/Validation을 채운다. -6. 서비스별 런북 인스턴스 최신화: 배포 대상 서비스별 문서를 최신 상태로 유지한다. - -## Release Checklist (Detailed) - -1. 설정 검증: 환경 변수, 시크릿, 외부 연동 키 유효성 확인 -2. 데이터 검증: 마이그레이션 순서, 백업 상태, 복구 가능성 확인 -3. 호환성 검증: 이전 버전 클라이언트/API 호환 여부 확인 -4. 의존성 검증: 신규/변경 라이브러리 버전 충돌 여부 확인 -5. 트래픽 전략: 점진 배포/일괄 배포 방식과 중단 기준 확인 -6. 커뮤니케이션: 사용자 공지, 내부 공지, 온콜 담당자 공유 완료 - -## Rollback Checklist (Detailed) - -1. 롤백 트리거 정의: 에러율/지연/장애 지표 임계치 명시 -2. 롤백 절차 문서화: 실행 명령, 순서, 책임자, 예상 소요 시간 -3. 데이터 롤백 전략: 스키마/데이터 복원 여부와 절차 명시 -4. 검증 절차: 롤백 후 핵심 시나리오 정상 동작 확인 항목 정의 -5. 커뮤니케이션 절차: 롤백 선언, 영향 공지, 상태 업데이트 채널 명시 -6. 사후 조치: 원인 분석 티켓과 재배포 조건 등록 - -## Outputs - -1. 배포 체크리스트 결과 -2. 롤백 계획 -3. 릴리즈 노트 초안 -4. 롤백 실행 런북(.github/templates/rollback-runbook.template.md 기반) -5. 서비스별 롤백 런북 인스턴스(.github/runbooks/services/*.rollback-runbook.md) - -## Automation Assets - -1. Release 본문 템플릿: .github/templates/release-note.template.md -2. Release 초안 프롬프트: .github/prompts/release-draft.prompt.md -3. Release 재검토 프롬프트: .github/prompts/release-review.prompt.md -4. Release 승인 프롬프트: .github/prompts/release-confirm.prompt.md - -## DoD (Exit) - -1. 롤백 가능한 배포 계획이 승인됨 -2. 운영 관찰 항목이 정의됨 -3. 릴리즈/롤백 체크리스트가 근거와 함께 완료됨 diff --git a/.github/instructions/07-operations.instructions.md b/.github/instructions/07-operations.instructions.md deleted file mode 100644 index 699ffbe..0000000 --- a/.github/instructions/07-operations.instructions.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -applyTo: "**" -description: "Use when: operations, monitoring, incident handling, postmortem" ---- - -# Stage 7 - Operations - -## Purpose - -배포 후 서비스 상태를 관찰하고 문제를 빠르게 복구하며 학습을 축적한다. - -## Stage Contract - -| 항목 | 내용 | -|---|---| -| 입력 | Release 결과, 관찰 포인트, 롤백/장애 대응 절차 | -| 산출물 | 운영 상태 리포트, 인시던트 기록, Postmortem, 개선 백로그 | -| 게이트 확인 | 운영 이슈가 추적 가능하게 기록되고 다음 사이클 입력으로 연결되어야 함 | -| 다음 단계 인계 | Discovery/Planning에 운영 학습과 개선 항목을 환류 | - -## DoR (Entry) - -1. Release 완료 -2. 모니터링 포인트가 정의됨 - -## Required Actions - -1. 상태 모니터링: 지표/로그/알림을 확인한다. -2. 이슈 대응: 장애 영향도와 복구 우선순위를 판단한다. -3. 사후분석: 원인, 탐지, 대응, 재발방지 항목을 기록한다. -4. 환류 연결: 개선 항목을 Discovery/Planning 입력으로 등록한다. - -## Incident Checklist (Detailed) - -1. 영향도 분류: 사용자 영향 범위, 기능 영향, 데이터 영향 분류 -2. 타임라인 기록: 탐지 시각, 대응 시작, 완화 시각, 복구 완료 시각 -3. 커뮤니케이션 기록: 공지 채널, 공지 시각, 담당자, 업데이트 주기 -4. 우회책 실행 여부: 임시 완화 조치와 한계 기록 -5. 재발 위험 평가: 동일 패턴 재발 가능성 및 단기 통제 방안 기록 - -## Postmortem Checklist (Detailed) - -1. What Happened: 사건 개요와 사용자 관찰 증상 -2. Impact: 서비스/사용자/비즈니스 영향 정량화 -3. Root Cause: 기술적 원인과 시스템적 원인 분리 -4. Detection: 탐지 경로, 지연 요인, 알림 품질 평가 -5. Response: 대응 의사결정과 실행 타임라인 평가 -6. Recovery: 복구 절차와 검증 결과 -7. Preventive Actions: 재발 방지 액션 아이템(담당자, 마감일 포함) -8. Follow-up Tracking: Discovery/Planning 백로그 연결 상태 - -## Outputs - -1. 운영 상태 리포트 -2. 인시던트 기록 및 Postmortem -3. 다음 반복을 위한 개선 백로그 -4. 액션 아이템 추적표(Owner, Due Date, Status) - -## Automation Assets - -1. Operations 본문 템플릿: .github/templates/operations-note.template.md -2. Operations 초안 프롬프트: .github/prompts/operation-draft.prompt.md -3. Operations 재검토 프롬프트: .github/prompts/operation-review.prompt.md -4. Operations 승인 프롬프트: .github/prompts/operation-confirm.prompt.md -5. Operations 본문 저장 경로(기본): docs/sdlc/operations/ -6. Operations 문서 ID 패턴: ops-<3자리순차>_YYYY-MM-DD_.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/instructions/placeholder-guide.md b/.github/instructions/placeholder-guide.md new file mode 100644 index 0000000..3332bf5 --- /dev/null +++ b/.github/instructions/placeholder-guide.md @@ -0,0 +1,243 @@ +# 플레이스홀더 가이드 + +이 파일은 `.github/templates/` 및 `.github/prompts/`에서 사용하는 `{{...}}` 플레이스홀더의 문법, 처리 주체, 전체 목록을 정의한다. +템플릿을 수정하거나 새 프롬프트를 작성할 때 이 파일을 기준으로 한다. + +--- + +## 1. 문법 규칙 + +| 형식 | 의미 | 예시 | +|---|---|---| +| `{{KEY}}` | 단순 치환 대상. 힌트 없음. | `{{CYCLE_ID}}` | +| `{{KEY:hint}}` | 힌트 포함. 치환 시 힌트 텍스트도 함께 제거. | `{{CREATED_AT_KST:TBD}}` | +| `{{KEY:opt1\|opt2\|opt3}}` | 열거형. 나열된 값 중 하나를 선택. | `{{DOC_STATUS:draft\|review\|confirmed}}` | +| `{{KEY_N_DECISION:hint}}` | AI agent가 섹션 본문에 임시로 삽입하는 판단 대기 마커. `review-discovery` 등 검토 단계에서 실제 문장으로 치환하거나 `#10`으로 이동. | `{{TARGET_STATE_2_DECISION:...}}` | + +> **규칙**: 플레이스홀더를 채울 때는 `{{...}}` 전체를 값으로 교체한다. 힌트나 파이프(`|`) 열거는 최종 문서에 남기지 않는다. + +--- + +## 2. 처리 주체 분류 + +플레이스홀더는 **누가 채워야 하는가**에 따라 세 가지로 나뉜다. + +### A. 자동 치환 (Auto — 프롬프트 실행 시 agent가 즉시 채움) + +| 키 | 치환 값 | 사용 위치 | +|---|---|---| +| `{{DOC_STATUS}}` / `{{DOC_STATUS:draft\|review\|confirmed}}` | `draft` | 모든 SDLC 문서 `#0` | +| `{{CYCLE_ID}}` / `{{CYCLE_ID:sdlc-<3자리>__}}` | 계산된 주기 ID | 모든 SDLC 문서 `#0`, index, summary | +| `{{ISSUE_NAME}}` / `{{ISSUE_NAME:...}}` | 사용자 입력 원문 | 모든 SDLC 문서 `#0`, summary | +| `{{CREATED_AT_KST}}` / `{{CREATED_AT_KST:TBD}}` | 현재 시각 (KST) | 모든 SDLC 문서 `#0`, summary | +| `{{UPDATED_AT_KST}}` / `{{UPDATED_AT_KST:TBD}}` | 현재 시각 (KST) | 모든 SDLC 문서 `#0`, summary | +| `{{OUTPUT_PATH}}` | 생성 파일 경로 | `1_discovery.md` `#9` | +| `{{FILE_RESULT}}` / `{{FILE_RESULT:생성\|갱신\|미생성}}` | `생성` (신규) 또는 `갱신` | `1_discovery.md` `#9` | +| `{{SUMMARY_STATUS}}` / `{{SUMMARY_STATUS:draft\|review\|confirmed}}` | `draft` | `summary.md` | + +--- + +### B. AI 추론 치환 (Infer — agent가 입력 요청과 저장소 맥락을 바탕으로 초안을 채움) + +> 입력만으로 합리적 추론이 가능한 항목은 플레이스홀더로 남기지 않고 자연어 문장으로 채운다. +> 추론이 불확실한 경우에는 `_DECISION` 접미사 형태로 남기고 `review-discovery` 단계에서 처리한다. + +| 키 | 설명 | 위치 | +|---|---|---| +| `{{PLANNING_SCORE_FILE}}` | Planning 점수 파일 경로 또는 `미생성` | `#1` | +| `{{TODO_FILE}}` | 관련 TODO/메모 경로 또는 `없음` | `#1` | +| `{{SUMMARY_LINE_1}}`, `{{SUMMARY_LINE_2}}` | 현재 검토 배경 및 이번 Discovery 핵심 요약 | `#1` | +| `{{REQUIREMENT_CLASSIFICATION}}` | `신규` / `유사` / `완전 중복` | `#2` | +| `{{CLASSIFICATION_REASON_1}}`, `{{CLASSIFICATION_REASON_2}}` | 판정 근거 2줄 | `#2` | +| `{{CURRENT_STATE_1}}`, `{{CURRENT_STATE_2}}` | 현재 문제 상태 | `#3` | +| `{{TARGET_STATE_1}}`, `{{TARGET_STATE_2}}` | 기대 상태 | `#3` | +| `{{STAKEHOLDER_1~3}}` | 이해관계자 | `#3` | +| `{{CONSTRAINT_1}}`, `{{CONSTRAINT_2}}` | 제약사항 | `#3` | +| `{{USER_SCENARIO_1~3}}` | 주요 사용자 시나리오 | `#3` | +| `{{CHANGE_ITEM_1~3}}` | 핵심 변경 항목 | `#4` | +| `{{CODE_IMPACT_1~2}}`, `{{DOC_IMPACT_1~2}}`, `{{OPS_IMPACT_1~2}}` | 영향 범위 | `#4` | +| `{{FR_1~4}}` | 기능 요구사항 (최소 2개) | `#5` | +| `{{NFR_1~3}}` | 비기능 요구사항 (최소 1개) | `#5` | +| `{{IN_SCOPE_1~2}}`, `{{OUT_OF_SCOPE_1~2}}` | 범위 경계 | `#5` | +| `{{RISK_LEVEL_1~3}}`, `{{RISK_1~3}}`, `{{MITIGATION_1~3}}` | 리스크 항목 (최소 2개) | `#6` | +| `{{ASSUMPTION_1~3}}` | 가정 (최소 2개) | `#6` | +| `{{OPEN_QUESTION_1~3}}`, `{{OPEN_QUESTION_STATUS_1~3}}` | 오픈 질문 | `#6` | +| `{{OPEN_QUESTION_ACTION_1~3}}`, `{{OPEN_QUESTION_EXIT_1~3}}` | 오픈 질문 처리 방안/종료 조건 | `#6` | +| `{{SUCCESS_METRIC_1~3}}` | 성공 기준 (최소 2개) | `#7` | +| `{{MEASURE_METHOD_1~3}}`, `{{MEASURE_SOURCE_1~3}}` | 측정 방식 및 데이터 출처 | `#7` | +| `{{CHECK_SCOPE_CRITERIA}}` | 범위 확정 기준 | `#8` | +| `{{CHECK_METRICS_CRITERIA}}` | 성공 지표 확정 기준 | `#8` | +| `{{CHECK_RISK_OWNER_CRITERIA}}` | 리스크 책임자 지정 기준 | `#8` | +| `{{CHECK_CONFIRMEDBY_CRITERIA}}` | Freeze 담당자 지정 기준 | `#8` | +| `{{REFERENCE_1~3}}` | 참조 문서 목록 | `#9` | +| `{{SUMMARY_POINT_1~2}}` | summary.md 핵심 요약 | `summary.md` | + +--- + +### C. 사용자 결정 필요 (Decide — 자동 추론 불가, 사용자/승인자가 직접 채워야 함) + +> 이 항목들은 `#10 사용자 결정 필요 항목 요약`에 모아서 관리한다. +> 섹션 본문에는 최소 플레이스홀더만 남기거나 맥락 설명 문장으로 대체한다. + +| 키 | 설명 | 위치 | +|---|---|---| +| `{{DECIDE_ITEM_1~2}}` | 정책/구조 결정이 필요한 항목 | `#10 > DECIDE` | +| `{{CONFIRM_ITEM_1~2}}` | 범위나 책임자 확인이 필요한 항목 | `#10 > CONFIRM` | +| `{{DATA_ITEM_1~2}}` | 외부 데이터나 환경 정보가 필요한 항목 | `#10 > DATA` | +| `{{FREEZE_HANDOFF_DECISION}}` | Planning 진행 가능 여부 (`Planning 진행 가능` / `보류`) | `#11` | +| `{{FREEZE_HANDOFF_RATIONALE}}` | Handoff Decision 판단 근거 | `#11` | +| `{{READY_FOR_PLANNING}}` | `true` / `false` | `#11` | +| `{{CONFIRMED_BY}}` | Freeze 확정 담당자 이름 | `#11` | +| `{{CONFIRMED_AT_KST}}` | Freeze 확정 시각 (KST) | `#11` | + +--- + +## 3. `_DECISION` 접미사 패턴 + +섹션 본문에 판단이 필요한 항목이 생겼을 때 AI agent가 임시로 삽입하는 마커이다. + +- **형식**: `{{원래키_N_DECISION:판단 내용 또는 질문}}` +- **예시**: `{{TARGET_STATE_2_DECISION:README 확장으로 할지, 별도 파일로 분리할지 결정 필요}}` +- **처리 규칙**: + - `review-discovery` 프롬프트 실행 시 각 항목을 검토하여 아래 중 하나로 처리한다. + - 추론 가능 → 자연어 문장으로 치환 + - 사용자 결정 필요 → `#10`으로 이동하고 본문은 맥락 설명 문장으로 대체 + +--- + +--- + +## Planning 전용 플레이스홀더 (`2_planning.md`) + +### A. 자동 치환 (Auto) + +| 키 | 치환 값 | 사용 위치 | +|---|---|---| +| `{{DISCOVERY_PATH}}` | `docs/sdlc//1_discovery.md` | `#0`, `#9` | + +### B. AI 추론 치환 (Infer) + +| 키 | 설명 | 위치 | +|---|---|---| +| `{{PLANNING_ISSUE_PURPOSE}}` | Discovery 이슈명과 핵심 목적 요약 | `#1` | +| `{{PLANNING_IN_SCOPE_1~2}}` | Discovery `#5`에서 이식한 In Scope | `#1` | +| `{{PLANNING_OUT_OF_SCOPE_1~2}}` | Discovery `#5`에서 이식한 Out of Scope | `#1` | +| `{{PLANNING_FR_1~4}}` | Discovery `#5` FR 요약 | `#1` | +| `{{PLANNING_NFR_1~2}}` | Discovery `#5` NFR 요약 | `#1` | +| `{{DEFERRED_ITEM_1~2}}` | Discovery `#6`에서 Deferred 처리된 오픈 질문 | `#1` | +| `{{TASK_TITLE_N}}` | FR/NFR 기반 태스크 제목 | `#2` | +| `{{TASK_TYPE_N}}` | 태스크 유형 (`개발\|문서\|검토\|설계\|운영`) | `#2` | +| `{{TASK_REF_N}}` | 참조 요구사항 ID (예: `FR-1`) | `#2` | +| `{{TASK_DEP_N}}` | 의존 태스크 ID 또는 `-` | `#2` | +| `{{TASK_DOD_N}}` | 태스크 완료 조건 | `#2` | +| `{{EFFORT_N}}` | 추정 공수 (숫자 또는 범위) | `#3` | +| `{{EFFORT_UNIT}}` | 공수 단위 (`SP\|시간\|일`) | `#3` | +| `{{EFFORT_NOTE_N}}` | 공수 추정 비고 | `#3` | +| `{{TOTAL_EFFORT}}` | 총 추정 공수 | `#3` | +| `{{EFFORT_CONFIDENCE}}` | 추정 신뢰도 (`High\|Medium\|Low`) | `#3` | +| `{{EFFORT_BASIS}}` | 추정 근거 | `#3` | +| `{{MILESTONE_N_NAME}}` | 마일스톤 이름 | `#4` | +| `{{MILESTONE_N_TASKS}}` | 마일스톤 포함 태스크 목록 | `#4` | +| `{{MILESTONE_N_DONE}}` | 마일스톤 완료 조건 | `#4` | +| `{{ITERATION_UNIT}}` | 이터레이션 단위 | `#4` | +| `{{ITERATION_N_TASKS}}` | 이터레이션 N 포함 태스크 | `#4` | +| `{{TASK_DEPENDENCY_N}}` | 태스크 간 의존 관계 설명 | `#5` | +| `{{EXTERNAL_DEP_N}}` | 외부 의존성 항목 | `#5` | +| `{{TECH_CONSTRAINT_N}}` | 기술/환경 제약 | `#5` | +| `{{VERIFY_CRITERIA_N}}` | 검증 대상 성공 기준 (Discovery S-N 요약) | `#6` | +| `{{VERIFY_METHOD_N}}` | 검증 방법 초안 | `#6` | +| `{{PLAN_RISK_LEVEL_N}}` | Planning 리스크 등급 | `#7` | +| `{{PLAN_RISK_N}}` | Planning 리스크 내용 | `#7` | +| `{{PLAN_MITIGATION_N}}` | 리스크 완화 방안 | `#7` | +| `{{PLAN_ASSUMPTION_N}}` | Planning 단계 가정 | `#7` | +| `{{PLAN_OPEN_QUESTION_N}}` | Planning 오픈 질문 | `#7` | +| `{{PLAN_OQ_STATUS_N}}` | 오픈 질문 상태 | `#7` | +| `{{PLAN_OQ_ACTION_N}}` | 오픈 질문 처리 방안 | `#7` | +| `{{PLAN_OQ_EXIT_N}}` | 오픈 질문 종료 조건 | `#7` | +| `{{CHECK_TASKS_CRITERIA}}` | 태스크 확정 기준 | `#8` | +| `{{CHECK_EFFORT_CRITERIA}}` | 공수 추정 확정 기준 | `#8` | +| `{{CHECK_SCHEDULE_CRITERIA}}` | 일정 확정 기준 | `#8` | +| `{{CHECK_DEP_CRITERIA}}` | 외부 의존성 해소 기준 | `#8` | + +### C. 사용자 결정 필요 (Decide) + +| 키 | 설명 | 위치 | +|---|---|---| +| `{{TASK_OWNER_N}}` | 태스크 담당자 | `#2` | +| `{{MILESTONE_N_DATE}}` | 마일스톤 목표 날짜 | `#4` | +| `{{ITERATION_N_PERIOD}}` | 이터레이션 날짜 범위 | `#4` | +| `{{VERIFY_OWNER_N}}` | 검증 담당자 | `#6` | +| `{{FREEZE_HANDOFF_DECISION}}` | Design 진행 가능 여부 | `#11` | +| `{{FREEZE_HANDOFF_RATIONALE}}` | Handoff Decision 판단 근거 | `#11` | +| `{{READY_FOR_DESIGN}}` | `true` / `false` | `#11` | +| `{{CONFIRMED_BY}}` | Freeze 확정 담당자 이름 | `#11` | +| `{{CONFIRMED_AT_KST}}` | Freeze 확정 시각 (KST) | `#11` | + +--- + +## Design 전용 플레이스홀더 (`3_design.md`) + +### A. 자동 치환 (Auto) + +| 키 | 치환 값 | 사용 위치 | +|---|---|---| +| `{{PLANNING_PATH}}` | `docs/sdlc//2_planning.md` | `#0`, `#8` | + +### B. AI 추론 치환 (Infer) + +| 키 | 설명 | 위치 | +|---|---|---| +| `{{DESIGN_ISSUE_PURPOSE}}` | Planning 이슈명과 핵심 목적 요약 | `#1` | +| `{{DESIGN_TASK_TITLE_N}}` | Planning `#2`에서 이식한 태스크 제목 | `#1` | +| `{{DESIGN_TASK_REF_N}}` | Planning `#2`에서 이식한 참조 요구사항 | `#1` | +| `{{DESIGN_DEFERRED_ITEM_N}}` | Planning `#7`에서 Deferred 처리된 오픈 질문 | `#1` | +| `{{ARCH_OVERVIEW}}` | 전체 아키텍처/구조 개요 | `#2` | +| `{{COMPONENT_N_NAME}}` | 주요 컴포넌트 이름 | `#2` | +| `{{COMPONENT_N_ROLE}}` | 컴포넌트 역할 | `#2` | +| `{{COMPONENT_N_SCOPE}}` | 컴포넌트 영향 범위 | `#2` | +| `{{DATA_FLOW_N}}` | 데이터 흐름 단계 | `#2` | +| `{{DESIGN_DETAIL_N}}` | 태스크별 설계 방향 | `#3` | +| `{{DESIGN_TARGET_N}}` | 변경 대상 파일/함수/설정 | `#3` | +| `{{DESIGN_IO_N}}` | 입력/출력 또는 사이드이펙트 | `#3` | +| `{{DESIGN_EDGE_N}}` | 예외/엣지 케이스 | `#3` | +| `{{INTERFACE_N}}` | API/함수 시그니처 | `#4` | +| `{{SCHEMA_N}}` | 데이터 스키마/포맷 | `#4` | +| `{{EVENT_N}}` | 이벤트/메시지 | `#4` | +| `{{SEC_INJECTION}}` ~ `{{SEC_OTHER}}` | 보안 항목 해당 여부 | `#5` | +| `{{SEC_INJECTION_ACTION}}` ~ `{{SEC_OTHER_ACTION}}` | 보안 대응 방안 | `#5` | +| `{{DESIGN_RISK_LEVEL_N}}` | Design 리스크 등급 | `#6` | +| `{{DESIGN_RISK_N}}` | Design 리스크 내용 | `#6` | +| `{{DESIGN_MITIGATION_N}}` | 리스크 완화 방안 | `#6` | +| `{{DESIGN_ASSUMPTION_N}}` | Design 단계 가정 | `#6` | +| `{{DESIGN_OPEN_QUESTION_N}}` | Design 오픈 질문 | `#6` | +| `{{DESIGN_OQ_STATUS_N}}` | 오픈 질문 상태 | `#6` | +| `{{DESIGN_OQ_ACTION_N}}` | 오픈 질문 처리 방안 | `#6` | +| `{{DESIGN_OQ_EXIT_N}}` | 오픈 질문 종료 조건 | `#6` | +| `{{CHECK_DESIGN_COMPLETE}}` | 설계 완성 기준 | `#7` | +| `{{CHECK_INTERFACE}}` | 인터페이스 확정 기준 | `#7` | +| `{{CHECK_SECURITY}}` | 보안 점검 완료 기준 | `#7` | + +### C. 사용자 결정 필요 (Decide) + +| 키 | 설명 | 위치 | +|---|---|---| +| `{{DESIGN_TASK_OWNER_N}}` | 태스크 담당자 | `#1` | +| `{{FREEZE_HANDOFF_DECISION}}` | Implementation 진행 가능 여부 | `#10` | +| `{{FREEZE_HANDOFF_RATIONALE}}` | Handoff Decision 판단 근거 | `#10` | +| `{{READY_FOR_IMPLEMENTATION}}` | `true` / `false` | `#10` | +| `{{CONFIRMED_BY}}` | Freeze 확정 담당자 이름 | `#10` | +| `{{CONFIRMED_AT_KST}}` | Freeze 확정 시각 (KST) | `#10` | + +--- + +## 4. 참조 위치 요약 + +| 파일 | 역할 | 관련 플레이스홀더 | +|---|---|---| +| `.github/prompts/new-sdlc.prompt.md` | 주기 생성, 자동/추론 치환 실행 | A, B 전체 | +| `.github/prompts/review-discovery.prompt.md` | 검토, `_DECISION` 처리, 사용자 결정 항목 정리 | B (`_DECISION`), C | +| `.github/prompts/draft-planning.prompt.md` | Planning 초안 생성, Discovery 내용 이식 | A, B 전체 (Planning) | +| `.github/prompts/draft-design.prompt.md` | Design 초안 생성, Planning 내용 이식 | A, B 전체 (Design) | +| `.github/templates/sdlc/1_discovery.md` | Discovery 원본 템플릿 | A, B, C 전체 | +| `.github/templates/sdlc/2_planning.md` | Planning 원본 템플릿 | A, B, C 전체 (Planning) | +| `.github/templates/sdlc/3_design.md` | Design 원본 템플릿 | A, B, C 전체 (Design) | diff --git a/.github/prompts/commit.prompt.md b/.github/prompts/commit.prompt.md deleted file mode 100644 index 8863c5e..0000000 --- a/.github/prompts/commit.prompt.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -description: "Use when: /commit or /commit all to review changes, generate a commit message, commit, and optionally push with --push" -name: "commit" -argument-hint: "Optional: 'all' and/or '--push'. Examples: '/commit', '/commit all', '/commit --push', '/commit all --push'" -agent: "agent" -model: "GPT-4.1" -tools: [read, search, agent, todo, execute] ---- - -당신은 변경사항을 검토하고 커밋/푸시를 자동으로 수행하는 실행 도우미다. -반드시 GPT-4.1 모델 기준으로 동작한다. - -반드시 아래 규칙을 지켜라. -1. 출력은 한국어로 작성한다. -2. 입력 해석 규칙: - - 빈 입력 또는 `all`: `/commit`과 동일하게 처리한다. - - `--push` 옵션이 있으면 커밋 후 원격 푸시까지 수행한다. - - 허용 예시: `/commit`, `/commit all`, `/commit --push`, `/commit all --push` - - 위 형식 외 인자는 오류로 보고하고 종료한다. -3. 실행 전 검증: - - git 저장소가 아니면 오류로 보고하고 종료한다. - - 변경 파일이 없으면 "커밋할 변경사항이 없다"고 보고하고 종료한다. -4. 변경 검토: - - `git status --short`와 `git diff`(필요 시 `git diff --staged`)로 변경을 파악한다. - - 변경 의도를 요약한 커밋 메시지를 1줄로 생성한다. - - 커밋 메시지 형식은 Conventional Commits를 우선 사용한다. -5. 커밋 수행: - - `/commit`, `/commit all` 모두 `git add -A` 후 `git commit -m "<생성 메시지>"`를 수행한다. - - 커밋 실패 시 오류 내용을 보고하고 종료한다. -6. 푸시 수행: - - `--push` 옵션이 있을 때만 `git push`를 수행한다. - - 기본 대상은 현재 체크아웃 브랜치의 upstream을 사용한다. - - upstream이 없으면 `origin <현재브랜치>`로 푸시를 시도하고 결과를 보고한다. -7. 안전 규칙: - - 파괴적 명령(`reset --hard`, `checkout --`, 강제 push)은 사용하지 않는다. - - 사용자가 명시하지 않은 변경을 되돌리지 않는다. - -실행 절차: -1. 입력 옵션 파싱(`all`, `--push`) -2. 저장소/변경 여부 확인 -3. 변경 내용 검토 및 커밋 메시지 생성 -4. `git add -A` + `git commit` -5. 옵션이 있으면 `git push` -6. 결과 보고 - -최종 응답 형식: -1. 실행 옵션 요약 -2. 생성된 커밋 메시지 -3. 커밋 결과(해시, 변경 파일 수) -4. 푸시 결과(실행한 경우) -5. 다음 액션 - -사용자 입력: -{{input}} diff --git a/.github/prompts/confirm-design.prompt.md b/.github/prompts/confirm-design.prompt.md new file mode 100644 index 0000000..1ac2d0f --- /dev/null +++ b/.github/prompts/confirm-design.prompt.md @@ -0,0 +1,103 @@ +--- +name: "confirm-design" +description: "Approve a Design document and mark it as confirmed, ready for Implementation" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/3_design.md" +agent: "agent" +--- +SDLC Design 문서를 최종 승인 처리한다. + +목표: +- `3_design.md`의 상태를 `confirmed`로 변경한다. +- `# 10. Design Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Implementation`을 `true`로 변경한다. +- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다. +- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다. + +--- + +## 플레이스홀더 분류 기준 + +모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다. + +### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소) + +승인 명령 실행 시 자동으로 채우며, 이 값이 남아 있어도 차단하지 않는다. + +| 플레이스홀더 패턴 | 자동 채움 값 | +|---|---| +| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) | +| `{{CONFIRMED_BY...}}` | 섹션 10의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 | + +### B. 맥락상 해소된 플레이스홀더 (자동 정리) + +섹션 7(체크리스트) 또는 섹션 9(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 10에 이미 기입되어 있으면** 해소된 것으로 간주한다. 승인 처리 시 해당 플레이스홀더를 실질 값으로 치환하거나 설명 텍스트로 대체한다. 차단하지 않는다. + +예시: +- 섹션 7의 `{{CONFIRM_CONFIRMEDBY}}` → 섹션 10의 `Confirmed By: Justin` 값이 있으면 → `Justin`으로 치환 또는 체크리스트 기준 텍스트에서 플레이스홀더 제거 +- 섹션 9 CONFIRM 항목의 `{{CONFIRM_CONFIRMEDBY}}` → 동일하게 처리 + +### C. 실질 미해소 플레이스홀더 (차단 대상) + +섹션 1~6(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `3_design.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다. +- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다. + +### 2. 플레이스홀더 분류 및 사전 해소 + +문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다. + +- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다. +- **B 유형**: 섹션 10에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다. +- **C 유형**: 목록을 보고하고 승인을 보류한다. + +### 3. 승인 가능 여부 확인 (사전 게이트 검사) + +아래 조건을 모두 충족해야 승인을 진행한다. + +| 항목 | 확인 기준 | +|------|-----------| +| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. | +| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. | +| 오픈 질문 미해소 | `# 6` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. | +| 필수 섹션 미완성 | `# 2`, `# 3`, `# 5`, `# 7`, `# 9`, `# 10` 섹션이 존재하고 내용이 채워져 있어야 한다. | +| Ready for Implementation 사전 설정 | `Ready for Implementation: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. | + +> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다. + +### 4. 문서 업데이트 (승인 가능 시에만 실행) + +아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다. + +1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경 +2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경 +3. `# 10. Design Freeze`의 `- Handoff Decision:` → `승인`으로 변경 +4. `# 10. Design Freeze`의 `- Ready for Implementation:` → `true`로 변경 +5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환 +6. **B 유형 플레이스홀더** → 섹션 10에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거) +7. `docs/sdlc//index.md`의 Design 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 3. Design | ... | ... |` + +### 5. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **처리 결과**: 승인 완료 또는 승인 불가 +- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시) +- **변경된 필드 목록** (승인 완료 시) +- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함 +- **다음 단계 안내**: 승인 완료 시 Implementation 단계(`/draft-implementation `) 실행 안내 + +--- + +## 중요 규칙 + +- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다. +- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다. +- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다. +- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다. diff --git a/.github/prompts/confirm-discovery.prompt.md b/.github/prompts/confirm-discovery.prompt.md new file mode 100644 index 0000000..0435919 --- /dev/null +++ b/.github/prompts/confirm-discovery.prompt.md @@ -0,0 +1,103 @@ +--- +name: "confirm-discovery" +description: "Approve a Discovery document and mark it as confirmed, ready for Planning" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md" +agent: "agent" +--- +SDLC Discovery 문서를 최종 승인 처리한다. + +목표: +- `1_discovery.md`의 상태를 `confirmed`로 변경한다. +- `# 11. Discovery Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Planning`을 `true`로 변경한다. +- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다. +- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다. + +--- + +## 플레이스홀더 분류 기준 + +모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다. + +### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소) + +승인 명령 실행 시 자동으로 채우며, 이 값이 남아 있어도 차단하지 않는다. + +| 플레이스홀더 패턴 | 자동 채움 값 | +|---|---| +| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) | +| `{{CONFIRMED_BY...}}` | 섹션 11의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 | + +### B. 맥락상 해소된 플레이스홀더 (자동 정리) + +섹션 8(체크리스트) 또는 섹션 10(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 11에 이미 기입되어 있으면** 해소된 것으로 간주한다. 승인 처리 시 해당 플레이스홀더를 실질 값으로 치환하거나 설명 텍스트로 대체한다. 차단하지 않는다. + +예시: +- 섹션 8의 `{{CONFIRM_CONFIRMEDBY}}` → 섹션 11의 `Confirmed By: Justin` 값이 있으면 → `Justin`으로 치환 또는 체크리스트 기준 텍스트에서 플레이스홀더 제거 +- 섹션 10 CONFIRM 항목의 `{{CONFIRM_CONFIRMEDBY}}` → 동일하게 처리 + +### C. 실질 미해소 플레이스홀더 (차단 대상) + +섹션 1~7(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `1_discovery.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다. +- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다. + +### 2. 플레이스홀더 분류 및 사전 해소 + +문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다. + +- **A 유형**: 목록만 기록한다. 3단계에서 자동으로 채운다. +- **B 유형**: 섹션 11에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 3단계에서 함께 처리한다. +- **C 유형**: 목록을 보고하고 승인을 보류한다. + +### 3. 승인 가능 여부 확인 (사전 게이트 검사) + +아래 조건을 모두 충족해야 승인을 진행한다. + +| 항목 | 확인 기준 | +|------|-----------| +| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. | +| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. | +| 오픈 질문 미해소 | `# 6` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. | +| 필수 섹션 미완성 | `# 5`, `# 7`, `# 8`, `# 10`, `# 11` 섹션이 존재하고 내용이 채워져 있어야 한다. | +| Ready for Planning 사전 설정 | `Ready for Planning: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. | + +> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다. + +### 4. 문서 업데이트 (승인 가능 시에만 실행) + +아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다. + +1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경 +2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경 +3. `# 11. Discovery Freeze`의 `- Handoff Decision:` → `승인`으로 변경 +4. `# 11. Discovery Freeze`의 `- Ready for Planning:` → `true`로 변경 +5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환 +6. **B 유형 플레이스홀더** → 섹션 11에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거) +7. `docs/sdlc//index.md`의 Discovery 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 1. Discovery | ... | ... |` + +### 5. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **처리 결과**: 승인 완료 또는 승인 불가 +- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시) +- **변경된 필드 목록** (승인 완료 시) +- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함 +- **다음 단계 안내**: 승인 완료 시 Planning 단계(`/planning-draft `) 실행 안내 + +--- + +## 중요 규칙 + +- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다. +- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다. +- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다. +- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다. diff --git a/.github/prompts/confirm-implementation.prompt.md b/.github/prompts/confirm-implementation.prompt.md new file mode 100644 index 0000000..a28624c --- /dev/null +++ b/.github/prompts/confirm-implementation.prompt.md @@ -0,0 +1,99 @@ +--- +name: "confirm-implementation" +description: "Approve an Implementation document and mark it as confirmed, ready for Verification" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/4_implementation.md" +agent: "agent" +--- +SDLC Implementation 문서를 최종 승인 처리한다. + +목표: +- `4_implementation.md`의 상태를 `confirmed`로 변경한다. +- `# 8. Implementation Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Verification`을 `true`로 변경한다. +- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다. +- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다. + +--- + +## 플레이스홀더 분류 기준 + +모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다. + +### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소) + +승인 명령 실행 시 자동으로 채우며, 이 값이 남아 있어도 차단하지 않는다. + +| 플레이스홀더 패턴 | 자동 채움 값 | +|---|---| +| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) | +| `{{CONFIRMED_BY...}}` | 섹션 8의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 | + +### B. 맥락상 해소된 플레이스홀더 (자동 정리) + +섹션 5(체크리스트) 또는 섹션 7(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 8에 이미 기입되어 있으면** 해소된 것으로 간주한다. 승인 처리 시 해당 플레이스홀더를 실질 값으로 치환하거나 설명 텍스트로 대체한다. 차단하지 않는다. + +### C. 실질 미해소 플레이스홀더 (차단 대상) + +섹션 1~4(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `4_implementation.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다. +- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다. + +### 2. 플레이스홀더 분류 및 사전 해소 + +문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다. + +- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다. +- **B 유형**: 섹션 8에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다. +- **C 유형**: 목록을 보고하고 승인을 보류한다. + +### 3. 승인 가능 여부 확인 (사전 게이트 검사) + +아래 조건을 모두 충족해야 승인을 진행한다. + +| 항목 | 확인 기준 | +|------|-----------| +| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. | +| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. | +| 오픈 질문 미해소 | `# 4` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. | +| 필수 섹션 미완성 | `# 2`, `# 3`, `# 5`, `# 7`, `# 8` 섹션이 존재하고 내용이 채워져 있어야 한다. | +| Ready for Verification 사전 설정 | `Ready for Verification: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. | + +> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다. + +### 4. 문서 업데이트 (승인 가능 시에만 실행) + +아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다. + +1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경 +2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경 +3. `# 8. Implementation Freeze`의 `- Handoff Decision:` → `승인`으로 변경 +4. `# 8. Implementation Freeze`의 `- Ready for Verification:` → `true`로 변경 +5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환 +6. **B 유형 플레이스홀더** → 섹션 8에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거) +7. `docs/sdlc//index.md`의 Implementation 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 4. Implementation | ... | ... |` + +### 5. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **처리 결과**: 승인 완료 또는 승인 불가 +- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시) +- **변경된 필드 목록** (승인 완료 시) +- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함 +- **다음 단계 안내**: 승인 완료 시 Verification 단계(`/draft-verification `) 실행 안내 + +--- + +## 중요 규칙 + +- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다. +- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다. +- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다. +- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다. diff --git a/.github/prompts/confirm-operation.prompt.md b/.github/prompts/confirm-operation.prompt.md new file mode 100644 index 0000000..9e30e7f --- /dev/null +++ b/.github/prompts/confirm-operation.prompt.md @@ -0,0 +1,97 @@ +--- +name: "confirm-operation" +description: "Approve an Operations document and mark the SDLC cycle as complete" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/7_operation.md" +agent: "agent" +--- +SDLC Operations 문서를 최종 승인 처리하고 SDLC 주기를 완료한다. + +목표: +- `7_operation.md`의 상태를 `confirmed`로 변경한다. +- `# 10. Operations Freeze`의 `Handoff Decision`을 `승인`으로, `SDLC 주기 완료`를 `true`로 변경한다. +- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다. +- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다. + +--- + +## 플레이스홀더 분류 기준 + +모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다. + +### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소) + +| 플레이스홀더 패턴 | 자동 채움 값 | +|---|---| +| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) | +| `{{CONFIRMED_BY...}}` | 섹션 10의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 | + +### B. 맥락상 해소된 플레이스홀더 (자동 정리) + +섹션 7(체크리스트) 또는 섹션 9(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 10에 이미 기입되어 있으면** 해소된 것으로 간주한다. 차단하지 않는다. + +### C. 실질 미해소 플레이스홀더 (차단 대상) + +섹션 1~6(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `7_operation.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다. +- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다. + +### 2. 플레이스홀더 분류 및 사전 해소 + +문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다. + +- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다. +- **B 유형**: 섹션 10에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다. +- **C 유형**: 목록을 보고하고 승인을 보류한다. + +### 3. 승인 가능 여부 확인 (사전 게이트 검사) + +아래 조건을 모두 충족해야 승인을 진행한다. + +| 항목 | 확인 기준 | +|------|-----------| +| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. | +| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. | +| 오픈 질문 미해소 | `# 5` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. | +| 필수 섹션 미완성 | `# 2`, `# 3`, `# 7`, `# 9`, `# 10` 섹션이 존재하고 내용이 채워져 있어야 한다. | +| SDLC 주기 완료 사전 설정 | `SDLC 주기 완료: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. | + +> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다. + +### 4. 문서 업데이트 (승인 가능 시에만 실행) + +아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다. + +1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경 +2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경 +3. `# 10. Operations Freeze`의 `- Handoff Decision:` → `승인`으로 변경 +4. `# 10. Operations Freeze`의 `- SDLC 주기 완료:` → `true`로 변경 +5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환 +6. **B 유형 플레이스홀더** → 섹션 10에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거) +7. `docs/sdlc//index.md`의 Operations 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 7. Operations | ... | ... |` + +### 5. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **처리 결과**: 승인 완료 또는 승인 불가 +- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시) +- **변경된 필드 목록** (승인 완료 시) +- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함 +- **SDLC 주기 완료 안내**: 승인 완료 시 이 주기의 `# 6` 다음 Discovery 환류 항목이 다음 SDLC 주기의 입력이 됨을 안내한다. + +--- + +## 중요 규칙 + +- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다. +- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다. +- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다. +- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다. diff --git a/.github/prompts/confirm-planning.prompt.md b/.github/prompts/confirm-planning.prompt.md new file mode 100644 index 0000000..f3c3f99 --- /dev/null +++ b/.github/prompts/confirm-planning.prompt.md @@ -0,0 +1,103 @@ +--- +name: "confirm-planning" +description: "Approve a Planning document and mark it as confirmed, ready for Design" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/2_planning.md" +agent: "agent" +--- +SDLC Planning 문서를 최종 승인 처리한다. + +목표: +- `2_planning.md`의 상태를 `confirmed`로 변경한다. +- `# 11. Planning Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Design`을 `true`로 변경한다. +- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다. +- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다. + +--- + +## 플레이스홀더 분류 기준 + +모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다. + +### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소) + +승인 명령 실행 시 자동으로 채우며, 이 값이 남아 있어도 차단하지 않는다. + +| 플레이스홀더 패턴 | 자동 채움 값 | +|---|---| +| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) | +| `{{CONFIRMED_BY...}}` | 섹션 11의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 | + +### B. 맥락상 해소된 플레이스홀더 (자동 정리) + +섹션 8(체크리스트) 또는 섹션 10(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 11에 이미 기입되어 있으면** 해소된 것으로 간주한다. 승인 처리 시 해당 플레이스홀더를 실질 값으로 치환하거나 설명 텍스트로 대체한다. 차단하지 않는다. + +예시: +- 섹션 8의 `{{CONFIRM_CONFIRMEDBY}}` → 섹션 11의 `Confirmed By: Justin` 값이 있으면 → `Justin`으로 치환 또는 체크리스트 기준 텍스트에서 플레이스홀더 제거 +- 섹션 10 CONFIRM 항목의 `{{CONFIRM_CONFIRMEDBY}}` → 동일하게 처리 + +### C. 실질 미해소 플레이스홀더 (차단 대상) + +섹션 1~7(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `2_planning.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다. +- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다. + +### 2. 플레이스홀더 분류 및 사전 해소 + +문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다. + +- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다. +- **B 유형**: 섹션 11에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다. +- **C 유형**: 목록을 보고하고 승인을 보류한다. + +### 3. 승인 가능 여부 확인 (사전 게이트 검사) + +아래 조건을 모두 충족해야 승인을 진행한다. + +| 항목 | 확인 기준 | +|------|-----------| +| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. | +| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. | +| 오픈 질문 미해소 | `# 7` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. | +| 필수 섹션 미완성 | `# 2`, `# 3`, `# 6`, `# 8`, `# 10`, `# 11` 섹션이 존재하고 내용이 채워져 있어야 한다. | +| Ready for Design 사전 설정 | `Ready for Design: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. | + +> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다. + +### 4. 문서 업데이트 (승인 가능 시에만 실행) + +아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다. + +1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경 +2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경 +3. `# 11. Planning Freeze`의 `- Handoff Decision:` → `승인`으로 변경 +4. `# 11. Planning Freeze`의 `- Ready for Design:` → `true`로 변경 +5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환 +6. **B 유형 플레이스홀더** → 섹션 11에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거) +7. `docs/sdlc//index.md`의 Planning 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 2. Planning | ... | ... |` + +### 5. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **처리 결과**: 승인 완료 또는 승인 불가 +- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시) +- **변경된 필드 목록** (승인 완료 시) +- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함 +- **다음 단계 안내**: 승인 완료 시 Design 단계(`/draft-design `) 실행 안내 + +--- + +## 중요 규칙 + +- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다. +- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다. +- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다. +- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다. diff --git a/.github/prompts/confirm-release.prompt.md b/.github/prompts/confirm-release.prompt.md new file mode 100644 index 0000000..c661757 --- /dev/null +++ b/.github/prompts/confirm-release.prompt.md @@ -0,0 +1,97 @@ +--- +name: "confirm-release" +description: "Approve a Release document and mark it as confirmed, ready for Operations" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/6_release.md" +agent: "agent" +--- +SDLC Release 문서를 최종 승인 처리한다. + +목표: +- `6_release.md`의 상태를 `confirmed`로 변경한다. +- `# 9. Release Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Operations`를 `true`로 변경한다. +- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다. +- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다. + +--- + +## 플레이스홀더 분류 기준 + +모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다. + +### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소) + +| 플레이스홀더 패턴 | 자동 채움 값 | +|---|---| +| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) | +| `{{CONFIRMED_BY...}}` | 섹션 9의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 | + +### B. 맥락상 해소된 플레이스홀더 (자동 정리) + +섹션 6(체크리스트) 또는 섹션 8(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 9에 이미 기입되어 있으면** 해소된 것으로 간주한다. 차단하지 않는다. + +### C. 실질 미해소 플레이스홀더 (차단 대상) + +섹션 1~5(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `6_release.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다. +- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다. + +### 2. 플레이스홀더 분류 및 사전 해소 + +문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다. + +- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다. +- **B 유형**: 섹션 9에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다. +- **C 유형**: 목록을 보고하고 승인을 보류한다. + +### 3. 승인 가능 여부 확인 (사전 게이트 검사) + +아래 조건을 모두 충족해야 승인을 진행한다. + +| 항목 | 확인 기준 | +|------|-----------| +| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. | +| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. | +| 오픈 질문 미해소 | `# 5` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. | +| 필수 섹션 미완성 | `# 2`, `# 3`, `# 4`, `# 6`, `# 8`, `# 9` 섹션이 존재하고 내용이 채워져 있어야 한다. | +| Ready for Operations 사전 설정 | `Ready for Operations: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. | + +> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다. + +### 4. 문서 업데이트 (승인 가능 시에만 실행) + +아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다. + +1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경 +2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경 +3. `# 9. Release Freeze`의 `- Handoff Decision:` → `승인`으로 변경 +4. `# 9. Release Freeze`의 `- Ready for Operations:` → `true`로 변경 +5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환 +6. **B 유형 플레이스홀더** → 섹션 9에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거) +7. `docs/sdlc//index.md`의 Release 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 6. Release | ... | ... |` + +### 5. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **처리 결과**: 승인 완료 또는 승인 불가 +- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시) +- **변경된 필드 목록** (승인 완료 시) +- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함 +- **다음 단계 안내**: 승인 완료 시 Operations 단계(`/draft-operation `) 실행 안내 + +--- + +## 중요 규칙 + +- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다. +- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다. +- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다. +- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다. diff --git a/.github/prompts/confirm-verification.prompt.md b/.github/prompts/confirm-verification.prompt.md new file mode 100644 index 0000000..8668323 --- /dev/null +++ b/.github/prompts/confirm-verification.prompt.md @@ -0,0 +1,99 @@ +--- +name: "confirm-verification" +description: "Approve a Verification document and mark it as confirmed, ready for Release" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/5_verification.md" +agent: "agent" +--- +SDLC Verification 문서를 최종 승인 처리한다. + +목표: +- `5_verification.md`의 상태를 `confirmed`로 변경한다. +- `# 9. Verification Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Release`를 `true`로 변경한다. +- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다. +- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다. + +--- + +## 플레이스홀더 분류 기준 + +모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다. + +### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소) + +| 플레이스홀더 패턴 | 자동 채움 값 | +|---|---| +| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) | +| `{{CONFIRMED_BY...}}` | 섹션 9의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 | + +### B. 맥락상 해소된 플레이스홀더 (자동 정리) + +섹션 6(체크리스트) 또는 섹션 8(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 9에 이미 기입되어 있으면** 해소된 것으로 간주한다. 차단하지 않는다. + +### C. 실질 미해소 플레이스홀더 (차단 대상) + +섹션 1~5(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `5_verification.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다. +- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다. + +### 2. 플레이스홀더 분류 및 사전 해소 + +문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다. + +- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다. +- **B 유형**: 섹션 9에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다. +- **C 유형**: 목록을 보고하고 승인을 보류한다. + +### 3. 승인 가능 여부 확인 (사전 게이트 검사) + +아래 조건을 모두 충족해야 승인을 진행한다. + +| 항목 | 확인 기준 | +|------|-----------| +| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. | +| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. | +| 검증 항목 미통과 | `# 3` 검증 결과에 `실패` 또는 `블로킹` 상태 항목이 없어야 한다. | +| 결함(BUG) Open 상태 | `# 4` BUG 목록에 `Open` 상태 항목이 없어야 한다. | +| 오픈 질문 미해소 | `# 5` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. | +| 필수 섹션 미완성 | `# 2`, `# 3`, `# 6`, `# 8`, `# 9` 섹션이 존재하고 내용이 채워져 있어야 한다. | +| Ready for Release 사전 설정 | `Ready for Release: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. | + +> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다. 단, 검증 실패/블로킹 항목이나 BUG `Open` 항목이 있으면 `--force`로도 승인하지 않는다. + +### 4. 문서 업데이트 (승인 가능 시에만 실행) + +아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다. + +1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경 +2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경 +3. `# 9. Verification Freeze`의 `- Handoff Decision:` → `승인`으로 변경 +4. `# 9. Verification Freeze`의 `- Ready for Release:` → `true`로 변경 +5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환 +6. **B 유형 플레이스홀더** → 섹션 9에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거) +7. `docs/sdlc//index.md`의 Verification 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 5. Verification | ... | ... |` + +### 5. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **처리 결과**: 승인 완료 또는 승인 불가 +- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시) +- **변경된 필드 목록** (승인 완료 시) +- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함 +- **다음 단계 안내**: 승인 완료 시 Release 단계(`/draft-release `) 실행 안내 + +--- + +## 중요 규칙 + +- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다. +- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다. +- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다. +- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다. diff --git a/.github/prompts/design-confirm.prompt.md b/.github/prompts/design-confirm.prompt.md deleted file mode 100644 index 835beb8..0000000 --- a/.github/prompts/design-confirm.prompt.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -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 deleted file mode 100644 index 607d77b..0000000 --- a/.github/prompts/design-draft.prompt.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -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 deleted file mode 100644 index d36c046..0000000 --- a/.github/prompts/design-review.prompt.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -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: 필요한 정보}} - - {{DELEGATE_TO: agent}} (agent 자동 결정) - - 추가 의사결정이 필요한 경우 반드시 플레이스홀더를 삽입한다. -11. 플레이스홀더 집계 규칙: - - 본문에 미해결 플레이스홀더가 있으면 `# 9. 사용자 결정 필요 항목 요약`에 유형별로 집계한다. - - 집계 시 {{DECIDE}}, {{CONFIRM}}, {{DATA}}, {{DELEGATE_TO}}를 유형별로 분리하고 중복 문구는 1회만 남긴다. - - 본문에 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 정규화한다. -12. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다. -13. 본문 플레이스홀더 정규화 규칙: - - {{DELEGATE_TO: agent}} 형식의 항목은 agent가 결정을 생성해 본문 문장으로 대체하고, 요약 섹션에서도 제거한다. - -실행 절차: -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}}/{{DELEGATE_TO}}) -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 deleted file mode 100644 index 8f34834..0000000 --- a/.github/prompts/discovery-confirm.prompt.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -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 deleted file mode 100644 index fff0071..0000000 --- a/.github/prompts/discovery-draft.prompt.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -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 deleted file mode 100644 index b25524b..0000000 --- a/.github/prompts/discovery-review.prompt.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -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/draft-design.prompt.md b/.github/prompts/draft-design.prompt.md new file mode 100644 index 0000000..b10ed56 --- /dev/null +++ b/.github/prompts/draft-design.prompt.md @@ -0,0 +1,95 @@ +--- +name: "draft-design" +description: "Create a 3_design.md draft from a confirmed Planning document" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/2_planning.md" +agent: "agent" +--- +확정된 Planning 문서를 기반으로 Design 초안(`3_design.md`)을 생성한다. + +목표: +- `docs/sdlc//3_design.md`를 생성한다. +- `2_planning.md`의 확정 내용(태스크, 요구사항, 검증 계획, 리스크)을 Design 초안의 입력으로 사용한다. +- 추론 가능한 항목은 초안 문장으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `2_planning.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `2_planning.md`를 찾는다. +- 파일이 없으면 사용자에게 피드백하고 중단한다. + +### 2. Planning 인계 조건 확인 + +`2_planning.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다. + +| 항목 | 기준 | +|------|------| +| 문서 상태 | `confirmed`여야 한다 | +| Ready for Design | `true`여야 한다 | +| 3_design.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 | + +### 3. Planning 내용 추출 + +`2_planning.md`와 `1_discovery.md`에서 아래 항목을 읽어 Design 초안 작성에 사용한다. + +- 이슈명 (`# 0`의 `이슈명:`) +- 문서 ID / CYCLE_ID +- 태스크 전체 목록 및 담당자 (`# 2`) +- 태스크별 DoD (`# 2`) +- FR/NFR 목록 (`# 1`) +- 검증 계획 개요 (`# 6`) +- 리스크 및 완화 방안 (`# 7`) +- Deferred 처리된 오픈 질문 (`# 7`) +- 외부 의존성 및 기술/환경 제약 (`# 5`) + +### 4. Design 초안 작성 원칙 + +- Planning 태스크 구조와 FR/NFR을 바탕으로 각 태스크의 설계 방향, 변경 대상, 입출력을 초안으로 채운다. +- 저장소 구조, 파일 경로, 기존 코드 패턴을 실제로 확인해 변경 대상(`DESIGN_TARGET_N`)을 구체적으로 명시한다. +- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다. + - 외부 시스템 계약이 미확정인 인터페이스 + - Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`) +- 보안 고려사항(`# 5`)은 변경 내용을 기준으로 OWASP Top 10 항목을 점검해 해당/비해당과 근거를 채운다. + +### 5. 자동으로 채워야 하는 항목 + +| 항목 | 채움 방법 | +|------|---------| +| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Planning 경로를 자동 입력 | +| `# 1` Planning 인계 요약 | Planning `# 2` 태스크 목록 이식, `# 7`의 Deferred 항목 이식 | +| `# 2` 아키텍처/구조 개요 | FR/NFR과 저장소 구조를 기반으로 변경 영향 범위 초안 작성 | +| `# 2` 주요 컴포넌트 | 실제 파일/모듈/디렉터리 구조를 확인해 영향 컴포넌트 나열 | +| `# 3` 상세 설계 | 각 T-N 태스크별 설계 방향, 변경 대상, 입출력 초안 작성 | +| `# 4` 인터페이스 정의 | FR/NFR 기반으로 필요한 API, 함수 시그니처, 스키마 초안 작성 | +| `# 5` 보안 고려사항 | 변경 내용 기준 OWASP 항목 점검, 해당/비해당 및 대응 방안 채움 | +| `# 6` 리스크 | Planning 이월 리스크 중 Design 관련 항목 포함 및 신규 Design 리스크 추가 | +| `# 8` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 | +| `# 9` 사용자 결정 필요 | 미확정 인터페이스, 외부 시스템 계약 등 사용자 결정 필요 항목 정리 | +| `# 10` Freeze 플래그 | `Handoff Decision: 보류`, `Ready for Implementation: false` 초기값 입력 | + +### 6. 파일 생성 + +- 경로: `docs/sdlc//3_design.md` +- 기반: `.github/templates/sdlc/3_design.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다. + +### 7. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **생성 결과**: 파일 경로 +- **채워진 항목 요약**: 자동 추론으로 채운 주요 내용 목록 +- **사용자 결정 필요 항목**: `# 9`에 정리된 항목 요약 +- **다음 단계 안내**: Design 검토 후 `/confirm-design ` 실행 안내 + +--- + +## 중요 규칙 + +- Planning이 `confirmed` 상태가 아니면 초안을 생성하지 않는다. +- 이미 `3_design.md`가 존재하는 경우 사용자 명시 없이 덮어쓰지 않는다. +- 변경 대상 경로/파일명은 저장소를 직접 확인해 실제 존재하는 경로를 사용한다. 추측으로 채우지 않는다. +- 보안 고려사항은 "비해당"이라도 근거를 한 줄 이상 남긴다. +- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다. diff --git a/.github/prompts/draft-implementation.prompt.md b/.github/prompts/draft-implementation.prompt.md new file mode 100644 index 0000000..2c2e87f --- /dev/null +++ b/.github/prompts/draft-implementation.prompt.md @@ -0,0 +1,82 @@ +--- +name: "draft-implementation" +description: "Create a 4_implementation.md draft from a confirmed Design document" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/3_design.md" +agent: "agent" +--- +확정된 Design 문서를 기반으로 Implementation 초안(`4_implementation.md`)을 생성한다. + +목표: +- `docs/sdlc//4_implementation.md`를 생성한다. +- `3_design.md`의 확정 내용(태스크, 변경 대상, 인터페이스, 보안)을 Implementation 초안의 입력으로 사용한다. +- 추론 가능한 항목은 초안 문장으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `3_design.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `3_design.md`를 찾는다. +- 파일이 없으면 사용자에게 피드백하고 중단한다. + +### 2. Design 인계 조건 확인 + +`3_design.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다. + +| 항목 | 기준 | +|------|------| +| 문서 상태 | `confirmed`여야 한다 | +| Ready for Implementation | `true`여야 한다 | +| 4_implementation.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 | + +### 3. Design 내용 추출 + +`3_design.md`와 `2_planning.md`에서 아래 항목을 읽어 Implementation 초안 작성에 사용한다. + +- 이슈명 (`# 0`의 `이슈명:`) +- 문서 ID / CYCLE_ID +- 태스크 전체 목록 및 담당자 (`# 1`) +- 태스크별 변경 대상 파일/함수 (`# 3`) +- 태스크별 입출력 및 엣지 케이스 (`# 3`) +- 인터페이스 정의 (`# 4`) +- 보안 고려사항 (`# 5`) +- 리스크 및 완화 방안 (`# 6`) +- Deferred 처리된 오픈 질문 (`# 6`) + +### 4. Implementation 초안 작성 원칙 + +- Design에서 확정된 태스크 구조와 변경 대상을 기반으로 각 태스크의 구현 방법, 변경 파일, 완료 조건을 초안으로 채운다. +- 저장소 구조, 파일 경로, 기존 코드 패턴을 실제로 확인해 변경 파일 목록(`IMP_FILE_N`)을 구체적으로 명시한다. +- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다. + - 태스크 담당자 (`{{IMP_TASK_OWNER_N:TBD}}`) + - Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`) + +### 5. 자동으로 채워야 하는 항목 + +| 항목 | 채움 방법 | +|------|---------| +| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Design 경로를 자동 입력 | +| `# 1` Design 인계 요약 | Design `# 1` 태스크 목록 및 변경 대상 이식, `# 6`의 Deferred 항목 이식 | +| `# 2` 구현 순서 | 태스크 의존 관계를 기반으로 구현 순서 초안 작성 | +| `# 2` 태스크별 구현 방법 | Design `# 3` 상세 설계 내용을 기반으로 구현 접근 방법 초안 작성 | +| `# 3` 변경 파일 목록 | Design `# 3`의 변경 대상 파일/함수를 기반으로 실제 경로 확인 후 목록 작성 | +| `# 4` 리스크 | Design 이월 리스크 중 Implementation 관련 항목 포함 및 신규 리스크 추가 | +| `# 6` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 | +| `# 7` 사용자 결정 필요 | 미확정 태스크 담당자, 외부 시스템 호출 확인 필요 항목 정리 | +| `# 8` Freeze 플래그 | `Handoff Decision: 보류`, `Ready for Verification: false` 초기값 입력 | + +### 6. 파일 생성 + +- 경로: `docs/sdlc//4_implementation.md` +- 기반: `.github/templates/sdlc/4_implementation.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다. + +### 7. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **생성된 파일 경로** +- **자동 채워진 항목 목록** (어떤 값으로 채웠는지) +- **플레이스홀더로 남긴 항목 목록** (사용자 결정 필요 이유 포함) +- **다음 단계 안내**: `/review-implementation ` 실행 안내 diff --git a/.github/prompts/draft-operation.prompt.md b/.github/prompts/draft-operation.prompt.md new file mode 100644 index 0000000..cbd8466 --- /dev/null +++ b/.github/prompts/draft-operation.prompt.md @@ -0,0 +1,83 @@ +--- +name: "draft-operation" +description: "Create a 7_operation.md draft from a confirmed Release document" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/6_release.md" +agent: "agent" +--- +확정된 Release 문서를 기반으로 Operations 초안(`7_operation.md`)을 생성한다. + +목표: +- `docs/sdlc//7_operation.md`를 생성한다. +- `6_release.md`의 배포 결과와 모니터링 정보를 Operations 초안의 입력으로 사용한다. +- 추론 가능한 운영 항목은 초안으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `6_release.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `6_release.md`를 찾는다. +- 파일이 없으면 사용자에게 피드백하고 중단한다. + +### 2. Release 인계 조건 확인 + +`6_release.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다. + +| 항목 | 기준 | +|------|------| +| 문서 상태 | `confirmed`여야 한다 | +| Ready for Operations | `true`여야 한다 | +| 7_operation.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 | + +### 3. 내용 추출 + +`6_release.md`, `5_verification.md`, `1_discovery.md`에서 아래 항목을 읽어 Operations 초안 작성에 사용한다. + +- 이슈명 (`# 0`의 `이슈명:`) +- 문서 ID / CYCLE_ID +- 배포 환경 및 배포 방식 (`6_release.md` `# 2`) +- 스모크 테스트 항목 (`6_release.md` `# 4`) +- Release 모니터링 확인 항목 (`6_release.md` `# 4`) +- Deferred 처리된 오픈 질문 (`6_release.md` `# 5`) +- 성공 기준(S-N) (`1_discovery.md` `# 7`) + +### 4. Operations 초안 작성 원칙 + +- Release의 스모크 테스트/모니터링 항목을 확장해 지속적인 운영 모니터링 항목을 도출한다. +- 저장소 구조와 배포 방식을 참고해 장애 대응 절차를 구체적으로 초안으로 작성한다. +- `# 6` 다음 Discovery 환류 항목은 초안 생성 시 빈 상태(`없음`)로 두고, 운영 중 갱신하도록 안내한다. +- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다. + - 모니터링 담당자 (`{{OPS_MONITOR_OWNER:TBD}}`) + - 에스컬레이션 연락처 (`{{OPS_ESCALATION_1:TBD}}`) + - Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`) + +### 5. 자동으로 채워야 하는 항목 + +| 항목 | 채움 방법 | +|------|---------| +| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Release 경로를 자동 입력 | +| `# 1` Release 인계 요약 | Release 배포 결과 요약, Deferred 항목 이식 | +| `# 2` 모니터링 항목 | Release 스모크 테스트/모니터링 항목을 기반으로 지속 모니터링 항목 도출, 임계값 초안 작성 | +| `# 3` 런북 — 정상 운영 절차 | Release 배포 방식 기반으로 주기적 확인 절차 초안 작성 | +| `# 3` 런북 — 장애 대응 절차 | 롤백 계획 및 배포 방식 기반으로 장애 초기 대응 절차 초안 작성 | +| `# 5` 리스크 | Release 이월 리스크 중 Operations 관련 항목 포함 | +| `# 6` 다음 Discovery 환류 | `없음`으로 초기화 (운영 중 갱신 안내) | +| `# 8` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 | +| `# 9` 사용자 결정 필요 | 모니터링 담당자, 에스컬레이션 담당자 미지정 항목 정리 | +| `# 10` Freeze 플래그 | `Handoff Decision: 보류`, `SDLC 주기 완료: false` 초기값 입력 | + +### 6. 파일 생성 + +- 경로: `docs/sdlc//7_operation.md` +- 기반: `.github/templates/sdlc/7_operation.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다. + +### 7. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **생성된 파일 경로** +- **자동 채워진 항목 목록** (어떤 값으로 채웠는지) +- **플레이스홀더로 남긴 항목 목록** (사용자 결정 필요 이유 포함) +- **다음 단계 안내**: `/review-operation ` 실행 안내 diff --git a/.github/prompts/draft-planning.prompt.md b/.github/prompts/draft-planning.prompt.md new file mode 100644 index 0000000..40e9096 --- /dev/null +++ b/.github/prompts/draft-planning.prompt.md @@ -0,0 +1,99 @@ +--- +name: "draft-planning" +description: "Create a 2_planning.md draft from a confirmed Discovery document" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md" +agent: "agent" +--- +확정된 Discovery 문서를 기반으로 Planning 초안(`2_planning.md`)을 생성한다. + +목표: +- `docs/sdlc//2_planning.md`를 생성한다. +- `1_discovery.md`의 확정 내용(FR/NFR, 범위, 성공 기준, 리스크)을 Planning 초안의 입력으로 사용한다. +- 추론 가능한 항목은 초안 문장으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `1_discovery.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `1_discovery.md`를 찾는다. +- 파일이 없으면 사용자에게 피드백하고 중단한다. + +### 2. Discovery 인계 조건 확인 + +`1_discovery.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다. + +| 항목 | 기준 | +|------|------| +| 문서 상태 | `confirmed`여야 한다 | +| Ready for Planning | `true`여야 한다 | +| 2_planning.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 | + +### 3. Discovery 내용 추출 + +`1_discovery.md`에서 아래 항목을 읽어 Planning 초안 작성에 사용한다. + +- 이슈명 (`# 0`의 `이슈명:`) +- 문서 ID / CYCLE_ID +- In Scope / Out of Scope (`# 5`) +- FR 전체 목록 (`# 5`) +- NFR 전체 목록 (`# 5`) +- 성공 기준 S-1~S-N (`# 7`) +- 리스크 R-1~R-N 및 완화 방안 (`# 6`) +- Deferred 처리된 오픈 질문 (`# 6`) +- 가정 A-1~A-N (`# 6`) + +### 4. Planning 초안 작성 원칙 + +- 입력 요청과 Discovery 내용을 바탕으로 합리적으로 추론 가능한 항목은 자연어 문장으로 채운다. +- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다. + - 태스크 담당자 (`{{TASK_OWNER_N:TBD}}`) + - 마일스톤 목표 날짜 (`{{MILESTONE_N_DATE:TBD}}`) + - 이터레이션 기간 (`{{ITERATION_N_PERIOD:TBD}}`) + - Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`) +- 공수 추정은 유사 작업 기준 또는 태스크 복잡도 기반으로 초안 값을 제안한다. 불확실하면 범위(예: `2-4 SP`)로 표기한다. +- 태스크는 각 FR 1개당 최소 1개를 생성하되, 구현/검토/문서화를 묶거나 분리하는 것이 합리적이면 그렇게 한다. + +### 5. 자동으로 채워야 하는 항목 + +| 항목 | 채움 방법 | +|------|---------| +| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Discovery 경로를 자동 입력 | +| `# 1` Discovery 인계 요약 | Discovery `# 5` 범위/FR/NFR 내용 요약 이식 | +| `# 1` 이월 오픈 질문 | Discovery `# 6`의 `Deferred` 항목 이식 | +| `# 2` 태스크 분해 | FR/NFR 기반으로 최소 2개 이상의 태스크 생성 | +| `# 2` 태스크 DoD | 각 태스크의 완료 조건을 FR 내용 기반으로 초안 작성 | +| `# 3` 공수 추정 | 각 태스크에 초안 공수값 또는 범위 제안 | +| `# 4` 마일스톤 | 태스크 그룹 기반으로 최소 1개 이상 초안 작성 | +| `# 5` 의존성 | 태스크 간 의존 관계를 분석해 초안 작성 | +| `# 6` 검증 계획 | Discovery 성공 기준(S-N)과 연결해 검증 방법 초안 작성 | +| `# 7` 리스크 | Discovery 이월 리스크 중 Planning 관련 항목 포함 및 신규 Planning 리스크 추가 | +| `# 9` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 | +| `# 10` 사용자 결정 필요 | 담당자 지정, 일정 확정, 예산/환경 제약 등 사용자 결정 필요 항목 정리 | +| `# 11` Freeze 플래그 | `Handoff Decision: 보류`, `Ready for Design: false` 초기값 입력 | + +### 6. 파일 생성 + +- 경로: `docs/sdlc//2_planning.md` +- 기반: `.github/templates/sdlc/2_planning.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다. + +### 7. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **생성 결과**: 파일 경로 +- **채워진 항목 요약**: 자동 추론으로 채운 주요 내용 목록 +- **사용자 결정 필요 항목**: `# 10`에 정리된 항목 요약 +- **다음 단계 안내**: Planning 검토 후 `/confirm-planning ` 실행 안내 + +--- + +## 중요 규칙 + +- Discovery가 `confirmed` 상태가 아니면 초안을 생성하지 않는다. +- 이미 `2_planning.md`가 존재하는 경우 사용자 명시 없이 덮어쓰지 않는다. +- 추론 불가 항목은 `TBD` 대신 의미 있는 플레이스홀더(`{{TASK_OWNER_1:TBD}}` 등)로 남긴다. +- 공수 추정 초안은 반드시 근거(유사 사례, 복잡도 판단 등)와 함께 `# 3`에 명시한다. +- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다. diff --git a/.github/prompts/draft-release.prompt.md b/.github/prompts/draft-release.prompt.md new file mode 100644 index 0000000..51aa19d --- /dev/null +++ b/.github/prompts/draft-release.prompt.md @@ -0,0 +1,81 @@ +--- +name: "draft-release" +description: "Create a 6_release.md draft from a confirmed Verification document" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/5_verification.md" +agent: "agent" +--- +확정된 Verification 문서를 기반으로 Release 초안(`6_release.md`)을 생성한다. + +목표: +- `docs/sdlc//6_release.md`를 생성한다. +- `5_verification.md`의 검증 결과와 `4_implementation.md`의 변경 파일 목록을 Release 초안의 입력으로 사용한다. +- 추론 가능한 배포 계획 항목은 초안으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `5_verification.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `5_verification.md`를 찾는다. +- 파일이 없으면 사용자에게 피드백하고 중단한다. + +### 2. Verification 인계 조건 확인 + +`5_verification.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다. + +| 항목 | 기준 | +|------|------| +| 문서 상태 | `confirmed`여야 한다 | +| Ready for Release | `true`여야 한다 | +| 6_release.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 | + +### 3. 내용 추출 + +`5_verification.md`, `4_implementation.md`, `1_discovery.md`에서 아래 항목을 읽어 Release 초안 작성에 사용한다. + +- 이슈명 (`# 0`의 `이슈명:`) +- 문서 ID / CYCLE_ID +- 검증 결과 요약 (`5_verification.md` `# 3`) +- Deferred 처리된 오픈 질문 (`5_verification.md` `# 5`) +- 변경 파일 목록 (`4_implementation.md` `# 3`) +- 저장소 구조 및 배포 관련 설정 파일 + +### 4. Release 초안 작성 원칙 + +- 저장소 구조와 배포 관련 파일(`.github/workflows`, `Makefile`, `bootstrap/` 등)을 실제로 확인해 배포 방식과 도구를 구체적으로 초안으로 채운다. +- 롤백 계획은 변경 파일 목록을 기반으로 현실적인 롤백 절차를 초안으로 작성한다. +- 스모크 테스트 항목은 핵심 기능 FR을 기반으로 도출한다. +- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다. + - 롤백 담당자 (`{{REL_ROLLBACK_OWNER:TBD}}`) + - Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`) + +### 5. 자동으로 채워야 하는 항목 + +| 항목 | 채움 방법 | +|------|---------| +| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Verification 경로를 자동 입력 | +| `# 1` Verification 인계 요약 | Verification 검증 결과 요약, Deferred 항목 이식 | +| `# 2` 배포 환경/방식/도구 | 저장소 구조 기반으로 배포 방식 초안 작성 | +| `# 2` 배포 순서 | 변경 파일 목록 기반으로 의존 관계를 고려한 배포 순서 초안 작성 | +| `# 3` 롤백 계획 | 변경 내용에 대한 현실적인 롤백 조건 및 절차 초안 작성 | +| `# 4` 스모크 테스트 | FR 기반으로 핵심 시나리오 도출 및 확인 방법 초안 작성 | +| `# 5` 리스크 | Verification 이월 리스크 중 Release 관련 항목 포함 | +| `# 7` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 | +| `# 8` 사용자 결정 필요 | 배포 담당자, 롤백 담당자 미지정 항목 정리 | +| `# 9` Freeze 플래그 | `Handoff Decision: 보류`, `Ready for Operations: false` 초기값 입력 | + +### 6. 파일 생성 + +- 경로: `docs/sdlc//6_release.md` +- 기반: `.github/templates/sdlc/6_release.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다. + +### 7. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **생성된 파일 경로** +- **자동 채워진 항목 목록** (어떤 값으로 채웠는지) +- **플레이스홀더로 남긴 항목 목록** (사용자 결정 필요 이유 포함) +- **다음 단계 안내**: `/review-release ` 실행 안내 diff --git a/.github/prompts/draft-verification.prompt.md b/.github/prompts/draft-verification.prompt.md new file mode 100644 index 0000000..3560dec --- /dev/null +++ b/.github/prompts/draft-verification.prompt.md @@ -0,0 +1,82 @@ +--- +name: "draft-verification" +description: "Create a 5_verification.md draft from a confirmed Implementation document" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/4_implementation.md" +agent: "agent" +--- +확정된 Implementation 문서를 기반으로 Verification 초안(`5_verification.md`)을 생성한다. + +목표: +- `docs/sdlc//5_verification.md`를 생성한다. +- `4_implementation.md`의 완료 태스크와 `1_discovery.md`의 성공 기준(S-N)을 Verification 초안의 입력으로 사용한다. +- 추론 가능한 검증 항목은 초안으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `4_implementation.md` 경로를 확정한다. +- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `4_implementation.md`를 찾는다. +- 파일이 없으면 사용자에게 피드백하고 중단한다. + +### 2. Implementation 인계 조건 확인 + +`4_implementation.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다. + +| 항목 | 기준 | +|------|------| +| 문서 상태 | `confirmed`여야 한다 | +| Ready for Verification | `true`여야 한다 | +| 5_verification.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 | + +### 3. 내용 추출 + +`4_implementation.md`, `3_design.md`, `1_discovery.md`에서 아래 항목을 읽어 Verification 초안 작성에 사용한다. + +- 이슈명 (`# 0`의 `이슈명:`) +- 문서 ID / CYCLE_ID +- 구현 완료 태스크 목록 및 변경 파일 (`# 1`, `# 3`) +- 태스크별 완료 조건(DoD) (`# 2`) +- Deferred 처리된 오픈 질문 (`# 4`) +- 성공 기준(S-N) (`1_discovery.md` `# 7`) +- 기능 요구사항(FR) 목록 (`1_discovery.md` `# 5`) +- 검증 계획 개요 (`2_planning.md` `# 6`) + +### 4. Verification 초안 작성 원칙 + +- Discovery 성공 기준(S-N)과 FR 목록을 기반으로 검증 항목(VC-N)을 도출한다. +- 각 VC 항목에 검증 방법(수동/자동/혼합)과 측정 가능한 성공 기준을 초안으로 채운다. +- 검증 결과(`# 3`) 테이블은 모두 `미완료`로 초기화한다. +- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다. + - 검증 담당자 (`{{VER_OWNER_N:TBD}}`) + - Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`) + +### 5. 자동으로 채워야 하는 항목 + +| 항목 | 채움 방법 | +|------|---------| +| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Implementation 경로를 자동 입력 | +| `# 1` Implementation 인계 요약 | Implementation `# 1`/`# 2` 태스크 목록 및 DoD 이식, `# 4`의 Deferred 항목 이식 | +| `# 2` 검증 항목 | Discovery S-N 기준과 FR/NFR을 기반으로 VC-N 항목 도출 및 검증 방법/성공 기준 초안 작성 | +| `# 2` 성공 기준 연결 | S-N과 VC-N의 연결 관계 명시 | +| `# 3` 검증 결과 | 모든 항목 `미완료`로 초기화, 통과/실패 집계 0으로 초기화 | +| `# 5` 리스크 | Implementation 이월 리스크 중 Verification 관련 항목 포함 | +| `# 7` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 | +| `# 8` 사용자 결정 필요 | 검증 담당자 미지정 항목 정리 | +| `# 9` Freeze 플래그 | `Handoff Decision: 보류`, `Ready for Release: false` 초기값 입력 | + +### 6. 파일 생성 + +- 경로: `docs/sdlc//5_verification.md` +- 기반: `.github/templates/sdlc/5_verification.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다. + +### 7. 결과 보고 + +응답에 아래 내용을 포함한다. + +- **생성된 파일 경로** +- **자동 채워진 항목 목록** (어떤 값으로 채웠는지) +- **플레이스홀더로 남긴 항목 목록** (사용자 결정 필요 이유 포함) +- **다음 단계 안내**: `/review-verification ` 실행 안내 diff --git a/.github/prompts/implementation-confirm.prompt.md b/.github/prompts/implementation-confirm.prompt.md deleted file mode 100644 index 12f2987..0000000 --- a/.github/prompts/implementation-confirm.prompt.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -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 deleted file mode 100644 index a04be83..0000000 --- a/.github/prompts/implementation-draft.prompt.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -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 deleted file mode 100644 index ce2f049..0000000 --- a/.github/prompts/implementation.prompt.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -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, execute] ---- - -당신은 SDLC Implementation 실행 도우미다. -사용자가 지정한 imp 문서의 특정 작업 항목(I-ID 또는 P-ID)을 실제로 수행하고, 완료 후 imp 문서를 갱신한다. - -반드시 아래 규칙을 지켜라. -1. 출력은 한국어로 작성한다. -2. 입력 형식: `imp-<3자리숫자>` 또는 `imp-<3자리숫자> <항목목록>` - - imp ID: `imp-<3자리숫자>` 형식 필수 - - 항목 목록(선택): `I-001, I-002` 또는 `P-001, P-002` 또는 혼합 가능 - - 항목 목록이 생략되면 imp 문서 `# 3. 작업 단위 분해`의 미완료 항목 전체를 위에서 아래 순서대로 실행한다. - - 형식 오류 시 오류로 보고하고 종료한다. -3. imp 파일 검색 규칙: - - 경로: docs/sdlc/implementation/ - - 패턴: _*.implementation.md - - 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다. -4. imp 문서 상태 확인: - - 상태가 `draft`가 아니면 "이미 확정된 Implementation 문서다. 상태를 확인하라"로 보고하고 종료한다. -5. 항목 해석 규칙: - - 항목 목록이 없는 경우: `# 3. 작업 단위 분해` 표의 모든 I-ID 중 상태가 `완료`가 아닌 항목을 문서 순서대로 대상에 포함한다. - - 항목 목록이 없는데 미완료 I-ID가 없으면 "실행할 미완료 항목이 없다"고 보고하고 종료한다. - - 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는 절대 수정하지 않는다. - - 항목 목록이 생략된 경우, 문서의 미완료 I-ID 전체가 이번 명령의 지정 항목으로 간주된다. - - imp 문서 외 SDLC 문서(Design, Planning 등)는 참조만 하고 수정하지 않는다. - - 지정한 파일 변경 계획 외의 추가 파일을 임의로 수정하지 않는다. - -실행 절차: -1. 입력 파싱: imp ID 및 항목 목록(선택) 형식 검증 -2. imp 파일 검색 및 상태 확인 -3. 항목 해석: 항목 목록 없음 -> 미완료 I-ID 전체(문서 순서), 항목 목록 있음 -> 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/new-sdlc.prompt.md b/.github/prompts/new-sdlc.prompt.md new file mode 100644 index 0000000..e63c1c8 --- /dev/null +++ b/.github/prompts/new-sdlc.prompt.md @@ -0,0 +1,173 @@ +--- +name: "new-sdlc" +description: "Create next SDLC cycle folder and draft 1_discovery.md from slash-command arguments" +argument-hint: "예: 사용자 로그인 기능 추가 - OAuth2 소셜 로그인, 세션 관리, 로그아웃 처리" +agent: "agent" +--- +/new-sdlc 로 들어온 인자를 기반으로 새 SDLC 주기를 생성한다. + +목표: +- `docs/sdlc/sdlc-__/` 폴더를 생성한다. +- 위 폴더에 `1_discovery.md` draft 문서를 생성한다. +- 위 폴더에 `index.md`, `summary.md` draft 문서를 함께 생성한다. +- `1_discovery.md`는 `.github/templates/sdlc/1_discovery.md`를 기반으로, 입력 문장과 현재 구현 상태를 바탕으로 기본 내용을 가능한 한 채운 초안이어야 한다. + +입력 해석: +- 사용자가 `/new-sdlc ...` 뒤에 입력한 전체 텍스트를 이슈 원문으로 사용한다. +- 이슈명은 원문과 현재 구현 상태를 확인하여 한 문장으로 요약한다. +- `topic-slug`는 이슈 원문을 소문자 kebab-case로 변환해 만든다. +- slug 규칙: + - 영문/숫자 외 문자는 `-`로 치환 + - 연속 `-`는 하나로 축약 + - 시작/끝 `-` 제거 + - 결과가 비면 `untitled` 사용 + +Discovery 초안 작성 원칙: +- 입력 문장이 짧더라도 기능 목적, 예상 사용자, 산출물, 성공 조건을 합리적으로 추론해 초안을 작성한다. +- 이미 입력만으로 추론 가능한 내용은 플레이스홀더로 남기지 말고 자연어 문장으로 채운다. +- 사용자 승인, 외부 데이터, 정책 결정, 확정 범위 경계처럼 추론만으로 확정하면 안 되는 항목만 플레이스홀더로 남긴다. +- 사용자 결정이 필요한 항목은 `결정 필요` 같은 일반 문장으로만 쓰지 말고, 반드시 `{{...}}` 플레이스홀더 형태로 남긴다. +- 모르면 공란으로 두지 말고 아래 둘 중 하나로 처리한다. + - 합리적 기본안 제시 가능: 초안 문장으로 채운다. + - 사용자 확인이 반드시 필요: `# 10. 사용자 결정 필요 항목 요약`에 넣고 관련 본문에는 최소 플레이스홀더를 남긴다. + +자동으로 채워야 하는 Discovery 섹션: +- `# 1. 계획 상태 요약` + - `해석` 2줄은 입력 요청을 바탕으로 직접 작성한다. +- `# 2. 요구사항 판정 결과` + - 기본값은 `신규`로 두되, 입력만으로 명백한 중복/유사라고 판단 가능한 경우에만 다르게 쓴다. + - 근거도 2줄 작성한다. +- `# 3. 문제점의 요약` + - 현재 상태, 기대 상태, 이해관계자, 주요 사용자 시나리오를 입력 기반으로 채운다. +- `# 4. 이번에 정의할 변경` + - 핵심 변경 항목 1~3개를 직접 작성한다. + - `영향 범위`의 코드/문서/운영 영향도 추론해 채운다. +- `# 5. 요구사항 목록` + - FR 2개 이상, NFR 1개 이상을 직접 작성한다. + - In Scope/Out of Scope는 초안 수준으로 제안하되, 사용자 승인 없이는 확정할 수 없는 경계는 플레이스홀더로 남긴다. +- `# 6. 리스크/가정 목록` + - 리스크 2개 이상, 가정 2개 이상을 직접 작성한다. + - 오픈 질문은 정말 결정이 필요한 경우에만 남긴다. +- `# 7. 초기 성공 기준` + - 성공 기준 2개 이상과 측정 방식/데이터 출처 초안을 작성한다. +- `# 9. 파일 처리 결과` + - 생성 결과와 최소 참조 문서를 채운다. 참조 문서가 없으면 `없음`이라고 쓴다. +- `# 10. 사용자 결정 필요 항목 요약` + - 자동 추론으로 확정할 수 없는 항목만 `DECIDE`, `CONFIRM`, `DATA`에 넣는다. + - 이 섹션의 항목은 설명문이 아니라 플레이스홀더 형식으로 남긴다. +- `# 11. Discovery Freeze` + - `Handoff Decision`은 기본 `보류`로 둔다. + - `Handoff Rationale`에는 "초기 Discovery 초안 생성 완료, Planning 인계 전 사용자 확인 필요"와 같이 현재 상태를 적는다. + +플레이스홀더를 유지해도 되는 대표 항목: +- 승인/확정 책임자 +- 외부 문서 경로, 아직 없는 후속 산출물 경로 +- 사용자 확인이 필요한 범위 경계 +- 데이터 출처가 실제로 정해지지 않은 성공 지표 측정값 +- 오픈 질문의 최종 답변 + +플레이스홀더 유지 규칙: +- 사용자 승인 전 확정되면 안 되는 정책/범위/산출물 위치/대상 독자 결정은 본문에도 플레이스홀더를 남긴다. +- `# 10. 사용자 결정 필요 항목 요약`에 들어가는 항목은 반드시 `{{DECIDE_*}}`, `{{CONFIRM_*}}`, `{{DATA_*}}` 형태를 사용한다. +- `TBD` 같은 일반 문자열보다 의미가 드러나는 플레이스홀더를 우선 사용한다. + +실행 절차: +1. `docs/sdlc/` 아래의 기존 폴더 중 `sdlc-<3자리>_` 패턴을 스캔해 최대 번호를 찾는다. +2. 다음 번호를 3자리 zero-pad로 계산한다. 예: `001`, `002`, ... +3. 오늘 날짜를 `YYYYMMDD`로 구한다. +4. `CYCLE_ID = sdlc-__`를 만든다. +5. 저장소 현황 탐색 — `# 3 문제점 요약`의 "현재 상태" 기술 근거를 수집한다. + - 이슈 원문에서 핵심 키워드(기능명, 모듈명, 동사)를 추출한다. + - 키워드를 기반으로 저장소에서 관련 파일·디렉터리·함수를 탐색한다. + - 탐색 범위: 소스 파일(`.ts`, `.js`, `.py`, `.go`, `.java` 등), 설정 파일, 기존 문서(`docs/`). 테스트 파일과 의존성 잠금 파일(`package-lock.json`, `.lock`)은 제외한다. + - 탐색 결과에서 아래 항목을 추출한다. + - 관련 파일 경로 목록 (최대 10개, 관련성 높은 순) + - 현재 구현 방식 요약 (함수명·클래스명·주요 로직 1~3줄) + - 현재 상태에서 이슈 원문이 지적하는 문제가 실제로 존재하는지 여부 + - 관련 파일을 찾지 못한 경우: "관련 파일 없음 — 신규 기능으로 추정"으로 기록하고 계속 진행한다. + - 탐색 결과는 `1_discovery.md` 작성 시 `#3` 현재 상태 기술에만 반영한다. 다른 섹션에는 사용하지 않는다. +6. `docs/sdlc//` 폴더를 생성한다. +7. `.github/templates/sdlc/1_discovery.md`를 기반으로 `docs/sdlc//1_discovery.md`를 생성한다. +7. [`.github/templates/sdlc/index.md`](../../.github/templates/sdlc/index.md)를 기반으로 `docs/sdlc//index.md`를 생성한다. + +8. `.github/templates/sdlc/summary.md`가 있으면 이를 기반으로 `docs/sdlc//summary.md`를 생성한다. 템플릿이 없으면 아래 기본 골격으로 생성한다. + + ```md + # Summary - {{CYCLE_ID}} + + - 이슈명: {{ISSUE_NAME}} + - 상태: {{SUMMARY_STATUS:draft|review|confirmed}} + - 작성 시각(KST): {{CREATED_AT_KST}} + - 마지막 갱신 시각(KST): {{UPDATED_AT_KST}} + + ## 핵심 요약 + - {{SUMMARY_POINT_1}} + - {{SUMMARY_POINT_2:필요 없으면 삭제}} + + ## 단계별 문서 + - [Discovery](./1_discovery.md) + - [Index](./index.md) + ``` + +11. 생성 파일들에서 아래 플레이스홀더를 우선 치환한다. + - `{{DOC_STATUS:draft|review|confirmed}}` -> `draft` + - `{{CYCLE_ID:sdlc-<3자리>__}}` -> 계산한 `CYCLE_ID` + - `{{CYCLE_ID}}` -> 계산한 `CYCLE_ID` + - `{{ISSUE_NAME:짧은 한글 또는 영문 이슈명}}` -> 사용자 입력 원문 + - `{{ISSUE_NAME}}` -> 사용자 입력 원문 + - `{{CREATED_AT_KST:TBD}}` -> 현재 시각(KST) + - `{{CREATED_AT_KST}}` -> 현재 시각(KST) + - `{{UPDATED_AT_KST:TBD}}` -> 현재 시각(KST) + - `{{UPDATED_AT_KST}}` -> 현재 시각(KST) + - `{{OUTPUT_PATH}}` -> 생성 파일 경로 + - `{{FILE_RESULT:생성|갱신|미생성}}` -> `생성` + - `{{SUMMARY_STATUS:draft|review|confirmed}}` -> `draft` +12. `1_discovery.md`에서는 위 규칙에 따라 추론 가능한 플레이스홀더를 적극적으로 실제 내용으로 치환한다. 이때 5단계에서 수집한 저장소 현황 탐색 결과를 `# 3 문제점 요약`의 현재 상태 기술에 반영한다. +13. 추론 불가능하거나 사용자 확인이 필요한 항목만 플레이스홀더로 남긴다. +14. `docs/sdlc/index.md` 전역 인덱스를 갱신한다. + - 파일이 없으면 아래 초기 골격으로 신규 생성한다. + + ```md + # SDLC 전체 주기 인덱스 + + + + ## 주기 목록 + + | ID | 날짜 | 이슈명 | Discovery | 상태 | + |---|---|---|---|---| + + ## 단계별 횡단 조회 + + | 단계 | 문서 목록 | + |---|---| + | Discovery | | + | Planning | | + | Design | | + | Implementation | | + | Verification | | + | Release | | + | Operations | | + ``` + + - 파일이 이미 있으면 다음 규칙으로 갱신한다. + - `## 주기 목록` 테이블에 새 행을 추가한다. 형식: + `| | | | [Discovery](.//1_discovery.md) | draft |` + - `## 단계별 횡단 조회` 테이블에서 `Discovery` 행의 `문서 목록` 셀에 `[](.//1_discovery.md)` 링크를 추가한다. + - 나머지 단계 행은 해당 단계 파일이 실제로 존재할 때만 링크를 추가한다(지금은 Discovery만 추가). + - 테이블 구조 자체는 변경하지 않는다. 행/셀 추가만 한다. + +응답 형식: +- 생성된 `CYCLE_ID` +- 생성한 폴더 경로 +- 생성한 파일 경로 목록 (`1_discovery.md`, `index.md`, `summary.md`) +- `docs/sdlc/index.md` 갱신 결과 (신규 생성 또는 갱신된 행 내용) +- **저장소 현황 탐색 결과**: 발견된 관련 파일 목록과 현재 상태 요약 (또는 "관련 파일 없음 — 신규 기능으로 추정") +- 자동으로 채운 Discovery 핵심 섹션 요약 +- 사용자 확인이 필요해 플레이스홀더로 남긴 항목 요약 + +중요 규칙: +- 질문 없이 바로 생성을 시도한다. (입력이 비어 있어 slug를 만들 수 없는 경우에만 짧게 확인) +- 기존 동일 경로가 있으면 덮어쓰지 말고, 다음 ID를 재계산해 새 주기로 생성한다. +- `docs/sdlc/index.md`에 이미 같은 `CYCLE_ID` 행이 있으면 중복 추가하지 않는다. +- 불필요한 파일은 만들지 않는다. diff --git a/.github/prompts/operation-confirm.prompt.md b/.github/prompts/operation-confirm.prompt.md deleted file mode 100644 index 13ebeac..0000000 --- a/.github/prompts/operation-confirm.prompt.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -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 deleted file mode 100644 index 4df4543..0000000 --- a/.github/prompts/operation-draft.prompt.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -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 deleted file mode 100644 index 1741fd5..0000000 --- a/.github/prompts/operation-review.prompt.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -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 deleted file mode 100644 index cc875ae..0000000 --- a/.github/prompts/planning-confirm.prompt.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -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 deleted file mode 100644 index 2602edf..0000000 --- a/.github/prompts/planning-draft.prompt.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -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 deleted file mode 100644 index 6ef0cdf..0000000 --- a/.github/prompts/planning-review.prompt.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -description: "Use when: /planning-review to re-review existing planning documents and update them in place from Planning IDs" -name: "planning-review" -argument-hint: "Enter Planning IDs separated by commas. Example: pln-001, pln-002" -agent: "agent" -model: "reviewer" -tools: [read, edit, search, todo, agent] ---- - -당신은 SDLC Planning 문서 재검토 도우미다. -사용자가 지정한 Planning 문서 ID 목록을 기준으로 Planning 문서를 재검토하고, 필요한 보정을 반영해 저장한다. - -반드시 아래 규칙을 지켜라. -1. 출력은 한국어로 작성한다. -2. 입력은 쉼표(,) 기준으로 분리해 Planning ID 목록으로 처리한다. -3. 입력 정규화 규칙: - - 공백 제거 - - 소문자 정규화(pln-001 형식) - - 중복 ID 제거 -4. ID 형식은 pln-<3자리숫자>만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다. -5. Planning 파일 검색 규칙: - - 1차: pln-001 -> docs/sdlc/planning/pln-001_*.planning.md 패턴 검색 - - 2차: 1차 미발견 시 docs/sdlc/planning/*.planning.md에서 파일명에 pln-001 토큰이 포함된 문서만 후보로 수집한다. - - 후보 문서는 `입력 Planning ID:` 필드 값이 pln-001과 정확히 일치할 때만 매칭한다. 필드가 없거나 불일치하면 매칭하지 않는다. - - 본문 단순 포함(contains) 검색만으로는 매칭하지 않는다. -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 또는 RICE)에 맞는 필수 컬럼과 Priority를 포함하는지 검증 - - 우선순위가 selected_score 내림차순과 일치하는지 검증 - - selected_score가 선택된 점수 방식(WSJF 또는 RICE) 점수열과 일치하는지 검증 - - `# 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의 selected_score/priority가 문서의 우선순위 표기와 일치하는지 검증 - - 불일치 시 문서 또는 CSV를 보정하고 변경 사항을 보고한다. -10. 수정 규칙: - - append 금지, 단일 완성본으로 overwrite 저장 - - 기존 사용자 의도/내용은 유지하되 누락/불일치/중복만 보정 -11. 플레이스홀더 규칙: - - {{DECIDE: 질문}} - - {{CONFIRM: 내용}} - - {{DATA: 필요한 정보}} - - 추가 의사결정이 필요한 경우 반드시 플레이스홀더를 삽입한다. -12. 플레이스홀더 집계 규칙: - - 본문에 미해결 플레이스홀더가 있으면 `# 9. 사용자 결정 필요 항목 요약`에 유형별로 집계한다. - - 본문에 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 정규화한다. -13. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다. - -실행 절차: -1. 입력 ID 목록 정규화 및 형식 검증 -2. 각 ID에 대해 Planning 문서 탐색(1차/2차 규칙 적용, 2차는 입력 Planning ID 필드 일치 필수) -3. 발견 문서 내용 읽기 -4. 재검토 항목 기준으로 누락/불일치 판단 -5. 필요한 항목만 보정하여 문서 overwrite 저장 -6. 점수 CSV와 Item ID/우선순위 정합성 검증 및 필요 시 보정 -7. 문서별 플레이스홀더를 #9에 집계/정규화 -8. 최종 응답에 처리 요약 제공 - -최종 응답 형식: -1. 실행 입력 요약 -2. 정규화된 대상 Planning 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 deleted file mode 100644 index 4a7b786..0000000 --- a/.github/prompts/release-confirm.prompt.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -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 deleted file mode 100644 index 9dd81b5..0000000 --- a/.github/prompts/release-draft.prompt.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -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 deleted file mode 100644 index 9bab238..0000000 --- a/.github/prompts/release-review.prompt.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -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/review-design.prompt.md b/.github/prompts/review-design.prompt.md new file mode 100644 index 0000000..612a573 --- /dev/null +++ b/.github/prompts/review-design.prompt.md @@ -0,0 +1,148 @@ +--- +name: "review-design" +description: "Review and validate SDLC Design document for consistency, completeness, and readiness for approval" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/3_design.md" +agent: "agent" +--- +SDLC Design 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다. + +목표: +- `3_design.md` 파일의 일관성 확인 (태스크/아키텍처/인터페이스/보안 간 중복 및 충돌) +- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별 +- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리 +- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인 +- 최종 승인 가능 상태 판단 + +--- + +## 검토 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `3_design.md` 파일 위치를 확정한다. +- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다. +- `2_planning.md`도 함께 읽어 인계 내용의 정합성 확인에 사용한다. + +### 2. Planning 인계 정합성 검토 + +`# 1. Planning 인계 요약`이 `2_planning.md`의 확정 내용과 일치하는지 확인한다. + +- 태스크 목록(T-N 제목, 참조 요구사항)이 Planning `# 2`와 내용/수량이 일치하는가 +- 이월된 오픈 질문이 Planning `# 7`의 `Deferred` 항목과 대응하는가 +- `# 3` 상세 설계의 T-N 항목이 `# 1` 태스크 목록과 누락 없이 1:1 대응하는가 + +### 3. 저장소 현황 대조 + +`3_design.md`에 기술된 "현재 상태(개선 전)"가 실제 저장소와 일치하는지 확인한다. + +#### 3-1. 변경 대상 파일 존재 여부 + +`# 3 상세 설계`의 각 T-N 섹션에서 "변경 대상" 파일/함수 경로를 추출하고 실제 저장소에서 확인한다. + +| 확인 항목 | 기준 | +|-----------|------| +| 수정 대상으로 명시된 파일 | 실제 저장소에 존재해야 한다. 없으면 경고 — 경로 오류 또는 신규 생성 여부를 명시하도록 요구 | +| 삭제 대상으로 명시된 파일 | 실제 저장소에 존재해야 한다. 없으면 경고 | +| 신규 생성 대상으로 명시된 파일 | 실제 저장소에 **없어야** 한다. 이미 존재하면 경고 — 수정 대상으로 재분류 필요 | + +#### 3-2. "현재 상태" 기술 정확성 + +`# 3 상세 설계` 및 `# 4 인터페이스 정의`에서 "현재 X 방식으로 동작한다", "현재 Y 함수가 Z를 반환한다" 등 현황을 기술한 문장을 찾아 실제 코드와 대조한다. + +- 일치: 별도 표시 없이 통과 +- 불일치: 해당 문장과 실제 코드를 나란히 제시하고 설계 문서 수정을 요구한다. **불일치 항목이 하나라도 있으면 최종 판단을 "보류(Hold)"로 설정한다.** +- 확인 불가(파일이 너무 크거나 탐색 범위 초과): "확인 불가 — 수동 검토 권장" 으로 표시한다. + +#### 3-3. 인터페이스 시그니처 대조 + +`# 4 인터페이스 정의`에 "현재 시그니처"가 명시된 항목에 대해 실제 코드의 함수/메서드 시그니처와 대조한다. + +- 파라미터 이름·타입·반환 타입이 일치하는지 확인한다. +- 불일치 시 실제 시그니처를 제시하고 설계 문서 수정을 요구한다. + +### 5. 일관성 검토 (모든 섹션 대상) + +- **태스크 번호 연속성**: `# 1`, `# 2` 컴포넌트 영향 범위, `# 3` 상세 설계의 T-N 번호가 누락 없이 연속이고 일치하는가 +- **인터페이스 정합성**: `# 3` 상세 설계에서 언급된 API/함수가 `# 4` 인터페이스 정의에 실제로 명시되었는가 +- **보안 연결성**: `# 3`에서 입출력이 정의된 경우 `# 5` 보안 점검의 "입력값 검증(Injection)" 항목이 적절히 점검되었는가 +- **숫자 연속성**: R-N, DA-N, OQ-N 번호가 누락 없이 연속인지 확인 + +### 4. 표현 검토 (모든 텍스트) + +- **문법**: 문장 구조, 주술 호응, 시제 일관성 +- **명확성**: "적절히", "대략", "가능하면" 같은 모호한 표현 식별 +- **작성 수준**: 기술 문서 기준의 형식적 톤 유지. 비공식 표현 제거 +- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증 + +### 6. 플레이스홀더 처리 + +모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다. + +AI agent가 채울 수 있는 항목: +- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Planning/저장소 정보로 추론 가능한지 확인 +- 컴포넌트 역할(`COMPONENT_N_ROLE`), 데이터 흐름(`DATA_FLOW_N`), 엣지 케이스(`DESIGN_EDGE_N`) 등 구조적으로 추론 가능한 항목 + +사용자 결정이 필요한 항목 (플레이스홀더 유지): +- 태스크 담당자(`DESIGN_TASK_OWNER_N`) +- 외부 시스템 계약이 미확정인 인터페이스(`INTERFACE_N`, `SCHEMA_N`) +- Freeze 확정 담당자(`CONFIRMED_BY`) + +각 항목에 대해 아래 중 하나를 판단한다: +- **채울 수 있음**: 문서 내 맥락, Planning 내용, 저장소 구조로 합리적 추론 가능 → 실제 내용으로 치환 +- **판단 불가능**: 사용자/승인자 결정, 외부 시스템 계약, 책임자 지정 필요 → 플레이스홀더 유지하되 명확성 강화 + +처리 결과를 별도 목록으로 보고한다. + +### 7. 섹션별 최소 검수 기준 + +| 섹션 | 최소 기준 | +|------|---------| +| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, PLANNING_PATH 채워졌는가) | +| `# 1 Planning 인계 요약` | 태스크 최소 1개 이상, Planning 태스크와 1:1 대응 여부 | +| `# 2 아키텍처/구조 설계` | 전체 구조 개요 1문단 이상, 주요 컴포넌트 1개 이상 | +| `# 3 상세 설계` | 모든 T-N 태스크에 설계 방향과 변경 대상이 있는가 | +| `# 4 인터페이스 정의` | 해당 없으면 "해당 없음" 명시, 있으면 함수/API 시그니처가 구체적인가 | +| `# 5 보안 고려사항` | 4개 항목(Injection/Auth/Data/Dep) 모두 해당/비해당 판정이 있는가, 해당 항목에 대응 방안이 있는가 | +| `# 6 리스크/가정/오픈 질문` | 리스크 1개 이상, 가정 1개 이상, OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 | +| `# 7 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 | +| `# 9 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 (단순 문장 아닌가) | +| `# 10 Freeze` | Handoff Decision과 Rationale이 채워졌는가 | + +### 8. 최종 승인 판단 + +- **승인 가능 (Ready for Implementation)**: + - 모든 T-N 태스크에 설계 방향과 변경 대상이 채워졌는가 + - 인터페이스 계약이 구체적으로 명시되었는가 + - 보안 점검 항목 중 "해당"은 모두 대응 방안이 있는가 + - `# 6` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가 + - 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요) + - Freeze 플래그가 준비되었는가 (`READY_FOR_IMPLEMENTATION: true`로 변경 가능한가) + - 저장소 현황 대조에서 불일치 항목이 없는가 (3-2, 3-3) +- **조건부 (Pending Minor Changes)**: + - 일부 표현/인터페이스 초안만 수정하면 가능 + - 보안 항목 중 근거가 빈약한 항목 보완 권장 + - 저장소 현황 대조 결과 중 "확인 불가" 항목이 있어 수동 검토 권장 +- **보류 (Hold)**: + - T-N 태스크 설계 방향 누락, 인터페이스 미정의, 보안 "해당" 항목에 대응 방안 없음, OQ `Open` 잔여 등 근본적 재검토 필요 + - 저장소 현황 대조(3-2, 3-3)에서 불일치 항목이 하나라도 있는 경우 + +--- + +## 응답 형식 + +- **검토 결과 요약** + - Planning 인계 정합성 오류 (있으면 나열) + - 저장소 현황 대조 결과 (불일치/확인 불가 항목 나열, 없으면 "이상 없음") + - 발견된 일관성 오류 (있으면 나열) + - 표현/문법 오류 (있으면 나열) + - 섹션별 완성도 (예: `# 3` 상세 설계 — T-2 변경 대상 누락) + +- **플레이스홀더 처리 결과** + - 채워진 항목 (예: `{{COMPONENT_2_ROLE}}` → "Copilot 프롬프트 파일 등록·관리" 로 치환) + - 유지된 항목 (예: `{{DESIGN_TASK_OWNER_1:TBD}}` → 담당자 지정 필요로 유지) + +- **수정 사항 목록** (적용된 변경) + +- **최종 판단** + - 승인 가능 / 조건부 / 보류 + - 근거 및 남은 작업 사항 diff --git a/.github/prompts/review-discovery.prompt.md b/.github/prompts/review-discovery.prompt.md new file mode 100644 index 0000000..baf02fd --- /dev/null +++ b/.github/prompts/review-discovery.prompt.md @@ -0,0 +1,87 @@ +--- +name: "review-discovery" +description: "Review and validate SDLC Discovery document for consistency, completeness, and readiness for approval" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md" +agent: "agent" +--- +SDLC Discovery 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다. + +목표: +- 1_discovery.md 파일의 일관성 확인 (개념/용어/범위 중복 및 충돌) +- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별 +- AI agent에게 할당된 플레이스홀더({{...}}) 중 판단/결정 가능한 항목 처리 +- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인 +- 최종 승인 가능 상태 판단 + +검토 절차: + +1. 입력 해석 + - 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 1_discovery.md 파일 위치를 확정한다. + - 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백한다. + +2. 일관성 검토 (모든 섹션 대상) + - 용어: 같은 개념이 다른 이름으로 반복되는지 확인. 예: "사용자"와 "최종 사용자", "범위"와 "경계" 혼용. + - 개념 중복: 섹션 간 내용이 동일하거나 매우 유사한 부분 식별. 예: `# 1`의 해석과 `# 10` 요약의 중복. + - 범위 정합성: In Scope/Out of Scope가 명확히 구분되는지, 요구사항 목록과 맞는지 확인. + - 숫자 일관성: 리스크(R-1~3), 가정(A-1~3), 성공 기준(S-1~3) 등 번호가 누락 없이 연속인지 확인. + +3. 표현 검토 (모든 텍스트) + - 문법: 문장 구조, 주술 호응, 시제 일관성 확인. + - 명확성: 주관적이거나 모호한 표현 식별. 예: "적절한", "대략적으로", "대체로". + - 작성 수준: 기술 문서 기준의 형식적 톤 유지. 비공식 표현이나 과도한 가정 제거. + - 오타: 한글 띄어쓰기, 숫자 오류, 링크 형식 검증. + +4. 플레이스홀더 처리 + - 모든 `{{...}}` 플레이스홀더를 나열하고, 각 항목의 의도를 파악한다. + - AI agent 할당 항목 식별: + - `{{ASSUMPTION_1_DECISION:...}}`, `{{TARGET_STATE_2_DECISION:...}}` 같은 `_DECISION` 형태 + - `{{DECIDE_*}}`, `{{CONFIRM_*}}`, `{{DATA_*}}` 형태 + - 각 항목에 대해 아래 중 하나를 판단한다. + - **채울 수 있음**: 문서 내 다른 섹션, 입력 요청, 저장소 구조를 바탕으로 합리적 내용 추론 가능 → 실제 내용으로 치환 + - **판단 불가능**: 사용자/승인자의 정책 결정, 외부 데이터 확인, 승인 책임자 지정 필요 → 플레이스홀더 유지하되 명확성 강화 + - 처리 결과를 별도 목록으로 보고한다. + +5. 섹션별 최소 검수 기준 + - `# 0 문서 상태`: 메타데이터 완성도 확인 (예: CREATED_AT_KST는 현재 시각으로 채워졌는가) + - `# 2 요구사항 판정`: 판정이 신규/유사/중복 중 하나인가, 근거는 2줄 이상인가 + - `# 3 문제점 요약`: 현재 상태와 기대 상태가 명확히 대비되는가 + - `# 5 요구사항 목록`: FR/NFR 각각 최소 개수(FR 2개, NFR 1개) 이상인가, 범위 경계가 명시되었는가 + - `# 6 리스크/가정/오픈질문`: 항목 수가 적절한가(2개 이상), 오픈 질문은 정말 결정 필요인가 + - `# 8 확인 체크`: 체크 항목이 구체적이고 측정 가능한가 + - `# 10 사용자 결정 필요`: 플레이스홀더가 실제 플레이스홀더 형식인가 (단순 문장 아닌가) + - `# 11 Freeze`: Handoff Decision과 Rationale이 채워졌는가 + +6. 최종 승인 판단 + - **승인 가능 (Ready for Planning)**: + - 모든 일관성 오류가 해소되었는가 + - 명확하지 않은 표현이 제거되었는가 + - 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요) + - 모든 요구 섹션이 채워졌는가 + - Freeze 플래그가 준비되었는가 (READY_FOR_PLANNING: true로 변경 가능한가) + - **조건부 (Pending Minor Changes)**: + - 일부 표현만 수정하면 가능 + - 플레이스홀더 중 일부는 명확성을 위해 재작성 권장 + - **보류 (Hold)**: + - 개념적 불일치, 범위 재정의, 승인자 선정 등 근본적 재검토 필요 + +응답 형식: +- **검토 결과 요약** + - 발견된 일관성 오류 (있으면 나열) + - 표현/문법 오류 (있으면 나열) + - 섹션별 완성도 점수 (예: 3/5 = 범위 경계 미명시) + +- **플레이스홀더 처리 결과** + - 채워진 항목 (예: `{{TARGET_STATE_2_DECISION}}` → "GitHub 기반으로 운영"로 치환) + - 유지된 항목 (예: `{{DECIDE_ITEM_1}}` → 사용자 승인 필요로 유지) + +- **수정 사항 목록** (적용된 변경) + +- **최종 판단** + - 승인 가능 / 조건부 / 보류 + - 근거 및 남은 작업 사항 + +중요 규칙: +- 도큐먼트 내용을 변경하는 경우 반드시 명확히 표기한다. +- AI agent 판단으로 치환한 항목은 합리적 근거를 함께 설명한다. +- 의도적으로 플레이스홀더를 유지한 이유도 명시한다. +- 승인 판단은 객관적 기준(섹션 완성도, 형식 준수, 범위 명확성)을 우선으로 한다. diff --git a/.github/prompts/review-implementation.prompt.md b/.github/prompts/review-implementation.prompt.md new file mode 100644 index 0000000..8876d15 --- /dev/null +++ b/.github/prompts/review-implementation.prompt.md @@ -0,0 +1,111 @@ +--- +name: "review-implementation" +description: "Review and validate SDLC Implementation document for consistency, completeness, and readiness for approval" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/4_implementation.md" +agent: "agent" +--- +SDLC Implementation 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다. + +목표: +- `4_implementation.md` 파일의 일관성 확인 (태스크/변경 파일/완료 조건 간 중복 및 충돌) +- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별 +- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리 +- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인 +- 최종 승인 가능 상태 판단 + +--- + +## 검토 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `4_implementation.md` 파일 위치를 확정한다. +- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다. +- `3_design.md`도 함께 읽어 인계 내용의 정합성 확인에 사용한다. + +### 2. Design 인계 정합성 검토 + +`# 1. Design 인계 요약`이 `3_design.md`의 확정 내용과 일치하는지 확인한다. + +- 태스크 목록(T-N 제목, 변경 대상)이 Design `# 1`/`# 3`과 내용/수량이 일치하는가 +- 이월된 오픈 질문이 Design `# 6`의 `Deferred` 항목과 대응하는가 +- `# 2` 태스크별 구현 방법의 변경 대상이 Design `# 3`의 변경 대상과 일치하는가 + +### 3. 일관성 검토 (모든 섹션 대상) + +- **태스크 번호 연속성**: `# 1`, `# 2`, `# 3`의 T-N 번호가 누락 없이 연속이고 일치하는가 +- **변경 파일 정합성**: `# 2` 태스크별 변경 대상이 `# 3` 변경 파일 목록에 빠짐없이 포함되어 있는가 +- **완료 조건 측정 가능성**: `# 2` 각 태스크의 완료 조건(DoD)이 구체적이고 측정 가능한가 ("구현 완료"처럼 모호한 표현 금지) +- **숫자 연속성**: R-N, IA-N, OQ-N 번호가 누락 없이 연속인지 확인 + +### 4. 표현 검토 (모든 텍스트) + +- **문법**: 문장 구조, 주술 호응, 시제 일관성 +- **명확성**: "적절히", "대략", "가능하면" 같은 모호한 표현 식별 +- **작성 수준**: 기술 문서 기준의 형식적 톤 유지. 비공식 표현 제거 +- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증 + +### 5. 플레이스홀더 처리 + +모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다. + +AI agent가 채울 수 있는 항목: +- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Design 내용으로 추론 가능한지 확인 +- 변경 파일 유형(`IMP_FILE_TYPE_N`), 관련 태스크(`IMP_FILE_TASK_N`) 등 구조적으로 추론 가능한 항목 + +사용자 결정이 필요한 항목 (플레이스홀더 유지): +- 태스크 담당자(`IMP_TASK_OWNER_N`) +- Freeze 확정 담당자(`CONFIRMED_BY`) + +각 항목에 대해 아래 중 하나를 판단한다: +- **채울 수 있음**: 문서 내 맥락, Design 내용, 저장소 구조로 합리적 추론 가능 → 실제 내용으로 치환 +- **판단 불가능**: 사용자/승인자 결정, 외부 확인, 책임자 지정 필요 → 플레이스홀더 유지하되 명확성 강화 + +처리 결과를 별도 목록으로 보고한다. + +### 6. 섹션별 최소 검수 기준 + +| 섹션 | 최소 기준 | +|------|---------| +| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, DESIGN_PATH 채워졌는가) | +| `# 1 Design 인계 요약` | 태스크 최소 1개 이상, Design 태스크와 1:1 대응 여부 | +| `# 2 구현 계획` | 모든 T-N 태스크에 구현 방법, 변경 대상, 완료 조건이 있는가 | +| `# 3 변경 파일 목록` | `# 2`에서 언급된 변경 대상이 모두 목록에 포함되었는가, 파일 경로가 실제 경로인가 | +| `# 4 리스크/가정/오픈 질문` | 리스크 1개 이상, 가정 1개 이상, OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 | +| `# 5 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 | +| `# 7 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 (단순 문장 아닌가) | +| `# 8 Freeze` | Handoff Decision과 Rationale이 채워졌는가 | + +### 7. 최종 승인 판단 + +- **승인 가능 (Ready for Verification)**: + - 모든 T-N 태스크에 구현 방법, 변경 대상, 완료 조건이 채워졌는가 + - 변경 파일 목록이 실제 파일 경로 기준으로 정확한가 + - `# 4` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가 + - 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요) + - Freeze 플래그가 준비되었는가 (`READY_FOR_VERIFICATION: true`로 변경 가능한가) +- **조건부 (Pending Minor Changes)**: + - 완료 조건(DoD) 일부가 모호하거나, 변경 파일 경로 확인 필요 + - 플레이스홀더 중 일부는 명확성을 위해 재작성 권장 +- **보류 (Hold)**: + - 태스크 구현 방법 누락, 변경 파일 목록 불완전, OQ `Open` 잔여 등 근본적 재검토 필요 + +--- + +## 응답 형식 + +- **검토 결과 요약** + - Design 인계 정합성 오류 (있으면 나열) + - 발견된 일관성 오류 (있으면 나열) + - 표현/문법 오류 (있으면 나열) + - 섹션별 완성도 (예: `# 2` T-2 완료 조건 모호) + +- **플레이스홀더 처리 결과** + - 채워진 항목 (예: `{{IMP_FILE_TYPE_2}}` → `수정` 로 치환) + - 유지된 항목 (예: `{{IMP_TASK_OWNER_1:TBD}}` → 담당자 지정 필요로 유지) + +- **수정 사항 목록** (적용된 변경) + +- **최종 판단** + - 승인 가능 / 조건부 / 보류 + - 근거 및 남은 작업 사항 diff --git a/.github/prompts/review-operation.prompt.md b/.github/prompts/review-operation.prompt.md new file mode 100644 index 0000000..809384d --- /dev/null +++ b/.github/prompts/review-operation.prompt.md @@ -0,0 +1,110 @@ +--- +name: "review-operation" +description: "Review and validate SDLC Operations document for consistency, completeness, and readiness for approval" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/7_operation.md" +agent: "agent" +--- +SDLC Operations 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다. + +목표: +- `7_operation.md` 파일의 일관성 확인 (모니터링/런북/환류 항목 간 충돌 및 누락) +- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별 +- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리 +- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인 +- 최종 승인 가능 상태 판단 + +--- + +## 검토 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `7_operation.md` 파일 위치를 확정한다. +- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다. +- `6_release.md`도 함께 읽어 인계 내용 정합성 확인에 사용한다. + +### 2. 인계 정합성 검토 + +- 배포 결과 요약이 Release `# 2`/`# 4`의 내용과 일치하는가 +- 이월된 오픈 질문이 Release `# 5`의 `Deferred` 항목과 대응하는가 +- 런북의 장애 대응 절차가 Release `# 3`의 롤백 계획과 연결되는가 + +### 3. 일관성 검토 (모든 섹션 대상) + +- **모니터링 실현 가능성**: `# 2` 모니터링 항목의 임계값이 수치화되었는가 ("오류가 없어야 한다" 대신 "5xx 오류율 1% 이하" 등) +- **런북 실행 가능성**: `# 3` 절차가 실제 운영자가 따를 수 있을 만큼 구체적인가 +- **에스컬레이션 일관성**: 에스컬레이션 경로가 실제 연락 가능한 대상인가 +- **숫자 연속성**: R-N, OQ-N 번호가 누락 없이 연속인지 확인 + +### 4. 표현 검토 (모든 텍스트) + +- **문법**: 문장 구조, 주술 호응, 시제 일관성 +- **명확성**: "문제가 생기면", "필요할 때" 같은 모호한 표현 식별 +- **작성 수준**: 기술 문서 기준의 형식적 톤 유지 +- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증 + +### 5. 플레이스홀더 처리 + +모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다. + +AI agent가 채울 수 있는 항목: +- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Release 내용으로 추론 가능한지 확인 +- 모니터링 확인 방법(`OPS_MONITOR_METHOD_N`), 장애 대응 첫 단계 등 구조적으로 추론 가능한 항목 + +사용자 결정이 필요한 항목 (플레이스홀더 유지): +- 모니터링 담당자(`OPS_MONITOR_OWNER`) +- 에스컬레이션 연락처(`OPS_ESCALATION_1`) +- Freeze 확정 담당자(`CONFIRMED_BY`) + +각 항목에 대해 아래 중 하나를 판단한다: +- **채울 수 있음**: 문서 내 맥락, Release 내용으로 합리적 추론 가능 → 실제 내용으로 치환 +- **판단 불가능**: 실제 운영 정보, 담당자 지정 필요 → 플레이스홀더 유지하되 명확성 강화 + +처리 결과를 별도 목록으로 보고한다. + +### 6. 섹션별 최소 검수 기준 + +| 섹션 | 최소 기준 | +|------|---------| +| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, REL_PATH 채워졌는가) | +| `# 1 Release 인계 요약` | 배포 환경과 스모크 테스트 결과가 명시되었는가 | +| `# 2 운영 모니터링` | 모니터링 항목 최소 1개 이상, 각 항목에 임계값과 대응 방안이 있는가 | +| `# 3 런북` | 정상 운영 절차 1단계 이상, 장애 대응 절차 1단계 이상, 에스컬레이션 경로가 있는가 | +| `# 5 리스크/오픈 질문` | OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 | +| `# 6 다음 Discovery 환류` | "없음"이거나 구체적인 인사이트/개선 사항이 기록되었는가 | +| `# 7 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 | +| `# 9 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 | +| `# 10 Freeze` | Handoff Decision과 Rationale이 채워졌는가 | + +### 7. 최종 승인 판단 + +- **승인 가능 (SDLC 주기 완료)**: + - 모니터링 항목에 임계값과 대응 방안이 모두 명시되었는가 + - 런북(정상 운영/장애 대응/에스컬레이션)이 완비되었는가 + - `# 5` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가 + - `# 6` 다음 Discovery 환류 항목이 작성되었거나 "없음"으로 명시되었는가 + - Freeze 플래그가 준비되었는가 (`SDLC_CYCLE_COMPLETE: true`로 변경 가능한가) +- **조건부 (Pending Minor Changes)**: + - 일부 모니터링 임계값이 모호하거나, 런북 절차 보완 필요 +- **보류 (Hold)**: + - 모니터링 항목 없음, 장애 대응 절차 없음, 에스컬레이션 경로 없음 등 근본적 재검토 필요 + +--- + +## 응답 형식 + +- **검토 결과 요약** + - Release 인계 정합성 오류 (있으면 나열) + - 발견된 일관성 오류 (있으면 나열) + - 표현/문법 오류 (있으면 나열) + - 섹션별 완성도 (예: `# 2` 모니터링 임계값 미수치화) + +- **플레이스홀더 처리 결과** + - 채워진 항목 (예: `{{OPS_MONITOR_METHOD_1}}` → `GitHub 저장소 오류 로그 확인` 로 치환) + - 유지된 항목 (예: `{{OPS_MONITOR_OWNER:TBD}}` → 담당자 지정 필요로 유지) + +- **수정 사항 목록** (적용된 변경) + +- **최종 판단** + - 승인 가능 / 조건부 / 보류 + - 근거 및 남은 작업 사항 diff --git a/.github/prompts/review-planning.prompt.md b/.github/prompts/review-planning.prompt.md new file mode 100644 index 0000000..ca89bff --- /dev/null +++ b/.github/prompts/review-planning.prompt.md @@ -0,0 +1,127 @@ +--- +name: "review-planning" +description: "Review and validate SDLC Planning document for consistency, completeness, and readiness for approval" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/2_planning.md" +agent: "agent" +--- +SDLC Planning 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다. + +목표: +- `2_planning.md` 파일의 일관성 확인 (태스크/요구사항/범위 간 중복 및 충돌) +- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별 +- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리 +- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인 +- 최종 승인 가능 상태 판단 + +--- + +## 검토 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `2_planning.md` 파일 위치를 확정한다. +- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다. +- `1_discovery.md`도 함께 읽어 인계 내용의 정합성 확인에 사용한다. + +### 2. Discovery 인계 정합성 검토 + +`# 1. Discovery 인계 요약`이 `1_discovery.md`의 확정 내용과 일치하는지 확인한다. + +- FR/NFR 목록이 Discovery `# 5`와 내용/수량이 일치하는가 +- In Scope / Out of Scope 경계가 Discovery와 충돌하지 않는가 +- 이월된 오픈 질문이 Discovery `# 6`의 `Deferred` 항목과 대응하는가 + +### 3. 일관성 검토 (모든 섹션 대상) + +- **용어**: 태스크 제목, 요구사항 ID(FR-N, T-N, M-N), 담당자 표기가 섹션 간 일치하는가 +- **태스크 참조**: `# 2` 태스크 분해 테이블의 T-N 번호가 `# 3` 공수 추정, `# 4` 일정 계획, `# 5` 의존성과 연속·일치하는가 +- **성공 기준 연결**: `# 6` 검증 계획의 기준(S-N)이 Discovery `# 7`과 대응하는가 +- **숫자 연속성**: T-N, M-N, OQ-N, R-N 번호가 누락 없이 연속인지 확인 + +### 4. 표현 검토 (모든 텍스트) + +- **문법**: 문장 구조, 주술 호응, 시제 일관성 +- **명확성**: "적절히", "대략", "가능하면" 같은 모호한 표현 식별 +- **작성 수준**: 기술 문서 기준의 형식적 톤 유지. 비공식 표현 제거 +- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증 + +### 5. 플레이스홀더 처리 + +모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다. + +AI agent가 채울 수 있는 항목: +- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Discovery 내용으로 추론 가능한지 확인 +- 태스크 유형(`TASK_TYPE_N`), 참조 요구사항(`TASK_REF_N`), 의존 관계(`TASK_DEP_N`) 등 구조적으로 추론 가능한 항목 + +사용자 결정이 필요한 항목 (플레이스홀더 유지): +- 태스크 담당자(`TASK_OWNER_N`) +- 마일스톤 목표 날짜(`MILESTONE_N_DATE`) +- 이터레이션 기간(`ITERATION_N_PERIOD`) +- 검증 담당자(`VERIFY_OWNER_N`) +- Freeze 확정 담당자(`CONFIRMED_BY`) + +각 항목에 대해 아래 중 하나를 판단한다: +- **채울 수 있음**: 문서 내 맥락, Discovery 내용, 저장소 구조로 합리적 추론 가능 → 실제 내용으로 치환 +- **판단 불가능**: 사용자/승인자 결정, 외부 데이터, 책임자 지정 필요 → 플레이스홀더 유지하되 명확성 강화 + +처리 결과를 별도 목록으로 보고한다. + +### 6. 섹션별 최소 검수 기준 + +| 섹션 | 최소 기준 | +|------|---------| +| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, DISCOVERY_PATH 채워졌는가) | +| `# 1 Discovery 인계 요약` | FR 2개 이상, NFR 1개 이상, In/Out Scope 명시 여부 | +| `# 2 작업 분해` | 태스크 최소 2개 이상, 각 태스크에 DoD가 있는가 | +| `# 3 공수 추정` | 모든 태스크에 추정 공수와 단위가 있는가, 총 공수와 신뢰도가 명시되었는가 | +| `# 4 일정 계획` | 마일스톤 최소 1개 이상, 이터레이션 단위가 정의되었는가 | +| `# 5 의존성 및 제약` | 태스크 간 의존성이 `# 2`와 일치하는가 | +| `# 6 검증 계획` | Discovery 성공 기준(S-N)과 연결된 검증 방법 초안이 있는가 | +| `# 7 리스크/가정/오픈 질문` | 항목이 적절한가(리스크 1개 이상, 가정 1개 이상), 오픈 질문은 정말 결정 필요인가 | +| `# 8 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 | +| `# 10 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 (단순 문장 아닌가) | +| `# 11 Freeze` | Handoff Decision과 Rationale이 채워졌는가 | + +### 7. 최종 승인 판단 + +- **승인 가능 (Ready for Design)**: + - 모든 일관성 오류가 해소되었는가 + - 명확하지 않은 표현이 제거되었는가 + - 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요) + - 모든 요구 섹션이 채워졌는가 + - Freeze 플래그가 준비되었는가 (`READY_FOR_DESIGN: true`로 변경 가능한가) +- **조건부 (Pending Minor Changes)**: + - 일부 표현/수치만 수정하면 가능 + - 플레이스홀더 중 일부는 명확성을 위해 재작성 권장 +- **보류 (Hold)**: + - 태스크-요구사항 연결 누락, 공수 추정 근거 부재, 범위 재정의 등 근본적 재검토 필요 + +--- + +## 응답 형식 + +- **검토 결과 요약** + - Discovery 인계 정합성 오류 (있으면 나열) + - 발견된 일관성 오류 (있으면 나열) + - 표현/문법 오류 (있으면 나열) + - 섹션별 완성도 (예: `# 3` 공수 추정 — T-2 추정값 누락) + +- **플레이스홀더 처리 결과** + - 채워진 항목 (예: `{{TASK_DEP_2}}` → `T-1` 로 치환) + - 유지된 항목 (예: `{{TASK_OWNER_1:TBD}}` → 담당자 지정 필요로 유지) + +- **수정 사항 목록** (적용된 변경) + +- **최종 판단** + - 승인 가능 / 조건부 / 보류 + - 근거 및 남은 작업 사항 + +--- + +## 중요 규칙 + +- 문서 내용을 변경하는 경우 반드시 명확히 표기한다. +- AI agent 판단으로 치환한 항목은 합리적 근거를 함께 설명한다. +- 의도적으로 플레이스홀더를 유지한 이유도 명시한다. +- 승인 판단은 객관적 기준(섹션 완성도, 형식 준수, Discovery 정합성)을 우선으로 한다. +- Discovery와의 정합성 확인은 `1_discovery.md`를 직접 읽어서 수행한다. 기억이나 추론에 의존하지 않는다. diff --git a/.github/prompts/review-release.prompt.md b/.github/prompts/review-release.prompt.md new file mode 100644 index 0000000..34a15db --- /dev/null +++ b/.github/prompts/review-release.prompt.md @@ -0,0 +1,110 @@ +--- +name: "review-release" +description: "Review and validate SDLC Release document for consistency, completeness, and readiness for approval" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/6_release.md" +agent: "agent" +--- +SDLC Release 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다. + +목표: +- `6_release.md` 파일의 일관성 확인 (배포 준비/롤백/스모크 테스트 간 중복 및 충돌) +- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별 +- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리 +- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인 +- 최종 승인 가능 상태 판단 + +--- + +## 검토 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `6_release.md` 파일 위치를 확정한다. +- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다. +- `5_verification.md`와 `4_implementation.md`도 함께 읽어 인계 내용 정합성 확인에 사용한다. + +### 2. 인계 정합성 검토 + +- 검증 결과 요약이 Verification `# 3` 결과와 일치하는가 +- 이월된 오픈 질문이 Verification `# 5`의 `Deferred` 항목과 대응하는가 +- 스모크 테스트 항목이 핵심 FR과 연결되는가 + +### 3. 일관성 검토 (모든 섹션 대상) + +- **배포 순서 일관성**: `# 2` 배포 순서가 Implementation `# 3` 변경 파일 목록과 연결되는가 +- **롤백 실현 가능성**: `# 3` 롤백 절차가 실제 배포 방식에 맞게 기술되었는가 (git 기반이면 커밋/브랜치/태그 참조, CI/CD 기반이면 파이프라인 롤백 방법 등) +- **스모크 테스트 충족성**: `# 4` 스모크 테스트가 핵심 기능을 최소한 커버하는가 +- **숫자 연속성**: R-N, OQ-N 번호가 누락 없이 연속인지 확인 + +### 4. 표현 검토 (모든 텍스트) + +- **문법**: 문장 구조, 주술 호응, 시제 일관성 +- **명확성**: "필요 시", "대략", "적절히" 같은 모호한 표현 식별 +- **작성 수준**: 기술 문서 기준의 형식적 톤 유지 +- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증 + +### 5. 플레이스홀더 처리 + +모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다. + +AI agent가 채울 수 있는 항목: +- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 저장소 구조로 추론 가능한지 확인 +- 배포 방식(`REL_DEPLOY_METHOD`), 스모크 테스트 방법(`REL_SMOKE_METHOD_N`) 등 저장소 구조 기반으로 추론 가능한 항목 + +사용자 결정이 필요한 항목 (플레이스홀더 유지): +- 롤백 담당자(`REL_ROLLBACK_OWNER`) +- 배포 대상 환경(`REL_TARGET_ENV`): 실제 운영 환경 정보 +- Freeze 확정 담당자(`CONFIRMED_BY`) + +각 항목에 대해 아래 중 하나를 판단한다: +- **채울 수 있음**: 저장소 구조, 문서 내 맥락으로 합리적 추론 가능 → 실제 내용으로 치환 +- **판단 불가능**: 실제 환경 정보, 담당자 지정 필요 → 플레이스홀더 유지하되 명확성 강화 + +처리 결과를 별도 목록으로 보고한다. + +### 6. 섹션별 최소 검수 기준 + +| 섹션 | 최소 기준 | +|------|---------| +| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, VER_PATH 채워졌는가) | +| `# 1 Verification 인계 요약` | 검증 결과 요약(통과 수/전체 수)이 있는가 | +| `# 2 배포 준비` | 배포 환경, 방식, 도구가 명시되었는가, 배포 순서가 1단계 이상인가 | +| `# 3 롤백 계획` | 롤백 조건 1개 이상, 롤백 절차 1단계 이상, 롤백 담당자가 있는가 | +| `# 4 배포 후 확인` | 스모크 테스트 항목 1개 이상, 각 항목에 확인 방법과 성공 기준이 있는가 | +| `# 5 리스크/오픈 질문` | OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 | +| `# 6 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 | +| `# 8 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 | +| `# 9 Freeze` | Handoff Decision과 Rationale이 채워졌는가 | + +### 7. 최종 승인 판단 + +- **승인 가능 (Ready for Operations)**: + - 배포 준비(환경/방식/순서)가 명확히 정의되었는가 + - 롤백 조건, 절차, 담당자가 모두 명시되었는가 + - 스모크 테스트 항목이 최소 1개 이상이고 성공 기준이 구체적인가 + - `# 5` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가 + - Freeze 플래그가 준비되었는가 (`READY_FOR_OPERATIONS: true`로 변경 가능한가) +- **조건부 (Pending Minor Changes)**: + - 일부 배포 방식 설명이 모호하거나 스모크 테스트 성공 기준 보완 필요 +- **보류 (Hold)**: + - 롤백 계획 없음, 배포 순서 불명확, 스모크 테스트 항목 누락 등 근본적 재검토 필요 + +--- + +## 응답 형식 + +- **검토 결과 요약** + - Verification 인계 정합성 오류 (있으면 나열) + - 발견된 일관성 오류 (있으면 나열) + - 표현/문법 오류 (있으면 나열) + - 섹션별 완성도 (예: `# 3` 롤백 담당자 미지정) + +- **플레이스홀더 처리 결과** + - 채워진 항목 (예: `{{REL_DEPLOY_METHOD}}` → `git push (자동 배포 없음)` 로 치환) + - 유지된 항목 (예: `{{REL_ROLLBACK_OWNER:TBD}}` → 담당자 지정 필요로 유지) + +- **수정 사항 목록** (적용된 변경) + +- **최종 판단** + - 승인 가능 / 조건부 / 보류 + - 근거 및 남은 작업 사항 diff --git a/.github/prompts/review-verification.prompt.md b/.github/prompts/review-verification.prompt.md new file mode 100644 index 0000000..e74d2be --- /dev/null +++ b/.github/prompts/review-verification.prompt.md @@ -0,0 +1,114 @@ +--- +name: "review-verification" +description: "Review and validate SDLC Verification document for consistency, completeness, and readiness for approval" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/5_verification.md" +agent: "agent" +--- +SDLC Verification 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다. + +목표: +- `5_verification.md` 파일의 일관성 확인 (검증 항목/성공 기준/결과 간 중복 및 충돌) +- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별 +- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리 +- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인 +- 최종 승인 가능 상태 판단 + +--- + +## 검토 절차 + +### 1. 입력 해석 + +- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `5_verification.md` 파일 위치를 확정한다. +- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다. +- `4_implementation.md`와 `1_discovery.md`도 함께 읽어 인계 내용 및 성공 기준 정합성 확인에 사용한다. + +### 2. 인계 정합성 검토 + +- 구현 완료 태스크 목록이 Implementation `# 1`/`# 2`와 내용/수량이 일치하는가 +- 검증 항목(VC-N)이 Discovery `# 7` 성공 기준(S-N) 및 FR과 연결되어 있는가 (`# 2` 성공 기준 연결 섹션 확인) +- 이월된 오픈 질문이 Implementation `# 4`의 `Deferred` 항목과 대응하는가 + +### 3. 일관성 검토 (모든 섹션 대상) + +- **VC 번호 연속성**: `# 2` 검증 항목과 `# 3` 검증 결과의 VC-N 번호가 누락 없이 연속이고 일치하는가 +- **성공 기준 측정 가능성**: `# 2` 각 VC 항목의 성공 기준이 구체적이고 측정 가능한가 ("정상 동작"처럼 모호한 표현 금지) +- **검증 결과 정합성**: `# 3` 통과/실패 집계가 실제 결과 테이블과 일치하는가 +- **결함 연결성**: `# 4` BUG 항목이 검증 항목(VC-N)과 연결되는지 확인 +- **숫자 연속성**: R-N, OQ-N, BUG-N 번호가 누락 없이 연속인지 확인 + +### 4. 표현 검토 (모든 텍스트) + +- **문법**: 문장 구조, 주술 호응, 시제 일관성 +- **명확성**: "정상적으로", "충분히", "대략" 같은 모호한 표현 식별 +- **작성 수준**: 기술 문서 기준의 형식적 톤 유지. 비공식 표현 제거 +- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증 + +### 5. 플레이스홀더 처리 + +모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다. + +AI agent가 채울 수 있는 항목: +- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Discovery/Implementation 내용으로 추론 가능한지 확인 +- 검증 방법(`VER_METHOD_N`), 결함 심각도(`BUG_SEVERITY_N`) 등 구조적으로 추론 가능한 항목 + +사용자 결정이 필요한 항목 (플레이스홀더 유지): +- 검증 담당자(`VER_OWNER_N`) +- 결함 재작업 내용(`BUG_FIX_N`): 실제 구현 변경 필요 +- Freeze 확정 담당자(`CONFIRMED_BY`) + +각 항목에 대해 아래 중 하나를 판단한다: +- **채울 수 있음**: 문서 내 맥락, Discovery/Implementation 내용으로 합리적 추론 가능 → 실제 내용으로 치환 +- **판단 불가능**: 사용자/승인자 결정, 실제 검증 수행 필요 → 플레이스홀더 유지하되 명확성 강화 + +처리 결과를 별도 목록으로 보고한다. + +### 6. 섹션별 최소 검수 기준 + +| 섹션 | 최소 기준 | +|------|---------| +| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, IMP_PATH 채워졌는가) | +| `# 1 Implementation 인계 요약` | 태스크 최소 1개 이상, Implementation 태스크와 1:1 대응 여부 | +| `# 2 검증 계획` | VC 최소 2개 이상, 각 VC에 검증 방법과 측정 가능한 성공 기준이 있는가 | +| `# 2 성공 기준 연결` | Discovery S-N이 하나 이상의 VC-N과 연결되었는가 | +| `# 3 검증 결과` | VC-N과 결과 테이블의 행 수가 일치하는가, 집계 숫자가 맞는가 | +| `# 4 결함` | BUG `Open` 상태가 있으면 재작업 내용이 명시되었는가 | +| `# 5 리스크/오픈 질문` | OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 | +| `# 6 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 | +| `# 8 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 (단순 문장 아닌가) | +| `# 9 Freeze` | Handoff Decision과 Rationale이 채워졌는가 | + +### 7. 최종 승인 판단 + +- **승인 가능 (Ready for Release)**: + - 모든 VC 항목이 "통과" 상태인가 + - BUG `Open` 상태 항목이 없는가 (Deferred는 근거와 함께 허용) + - Discovery 성공 기준(S-N)이 모두 VC와 연결되어 검증되었는가 + - `# 5` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가 + - 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요) + - Freeze 플래그가 준비되었는가 (`READY_FOR_RELEASE: true`로 변경 가능한가) +- **조건부 (Pending Minor Changes)**: + - 일부 VC 항목이 아직 "미완료"이나 곧 완료 예정 + - BUG 항목 심각도가 낮고 재작업 계획이 명확한 경우 +- **보류 (Hold)**: + - VC 항목에 "실패" 또는 "블로킹" 상태 존재, BUG `Open` 잔여, S-N 연결 누락 등 근본적 재검토 필요 + +--- + +## 응답 형식 + +- **검토 결과 요약** + - Implementation 인계 정합성 오류 (있으면 나열) + - 발견된 일관성 오류 (있으면 나열) + - 표현/문법 오류 (있으면 나열) + - 섹션별 완성도 (예: `# 2` VC-3 성공 기준 모호) + +- **플레이스홀더 처리 결과** + - 채워진 항목 (예: `{{VER_METHOD_2}}` → `자동` 로 치환) + - 유지된 항목 (예: `{{VER_OWNER_1:TBD}}` → 검증 담당자 지정 필요로 유지) + +- **수정 사항 목록** (적용된 변경) + +- **최종 판단** + - 승인 가능 / 조건부 / 보류 + - 근거 및 남은 작업 사항 diff --git a/.github/prompts/run-implementation.prompt.md b/.github/prompts/run-implementation.prompt.md new file mode 100644 index 0000000..4c0511b --- /dev/null +++ b/.github/prompts/run-implementation.prompt.md @@ -0,0 +1,99 @@ +--- +name: "run-implementation" +description: "Execute implementation tasks from 4_implementation.md and record results" +argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/4_implementation.md" +agent: "agent" +--- +`4_implementation.md`에 정의된 태스크를 순서대로 실제 구현하고, 완료 후 문서의 확인체크(`#5`)와 파일처리결과(`#6`)를 자동으로 채운다. + +목표: +- `#2 구현 계획`에 기술된 순서대로 태스크를 실행한다. +- 각 태스크 완료 후 DoD를 자체 확인하고, 미충족 시 즉시 보고한다. +- 모든 태스크 완료 후 `#3 변경 파일 목록`을 실제 결과로 갱신하고, `#5`와 `#6`을 채운다. +- 문서 상태는 `review`로 변경한다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- CYCLE_ID(예: `sdlc-001`)가 주어지면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `4_implementation.md` 경로를 확정한다. +- 파일 경로가 직접 주어지면 그대로 사용한다. +- 파일이 없으면 사용자에게 경로를 재확인하도록 요청하고 중단한다. + +### 2. 사전 게이트 확인 + +아래 조건을 모두 충족해야 구현을 시작한다. 미충족 시 이유를 보고하고 중단한다. + +| 항목 | 기준 | +|------|------| +| 문서 상태 | `draft` 또는 `review`이어야 한다. `confirmed`이면 이미 완료된 구현임을 알린다. | +| `#2` 구현 계획 존재 | 구현 순서와 T-N 섹션이 모두 채워져 있어야 한다. 플레이스홀더가 남아 있으면 `draft-implementation`을 먼저 완성하도록 안내한다. | +| `#3` 변경 파일 목록 존재 | 최소 1개 이상의 파일 항목이 있어야 한다. | +| Design 인계 조건 | 참조 `3_design.md`가 `confirmed` 상태인지 확인한다. 아니면 경고만 출력하고 계속 진행한다. | + +### 3. 구현 실행 + +`#2 구현 계획`의 `구현 순서` 목록을 기준으로 태스크를 순서대로 실행한다. + +#### 태스크별 실행 규칙 + +각 T-N 태스크에 대해 아래 순서로 진행한다. + +1. **계획 읽기**: 해당 T-N 섹션의 `구현 방법`, `변경 대상`, `완료 조건`, `주의사항`을 읽는다. +2. **현황 파악**: 변경 대상 파일이 이미 존재하는지 확인하고, 존재하면 관련 코드를 읽어 맥락을 파악한다. +3. **구현**: 파일 생성, 수정, 삭제를 수행한다. 기존 코드의 스타일과 패턴을 따른다. +4. **DoD 자체 확인**: `완료 조건`에 기술된 각 항목을 하나씩 점검한다. + - 충족: 다음 태스크로 진행한다. + - 미충족: 보고하고 즉시 재작업한다. 재작업 후에도 미충족이면 태스크를 블로킹으로 표시하고 사용자에게 결정을 요청한다. + +#### 실행 중 주의사항 + +- 각 태스크의 `주의사항`을 반드시 읽고 구현에 반영한다. +- `#4 리스크`에 기록된 리스크 완화 방안을 구현 중에 적용한다. +- `#1 이월된 오픈 질문` 항목이 있으면 구현 중 해당 결정을 내려 기록한다. +- 구현 중 새로 발견된 문제가 `#3 변경 파일 목록`에 없는 파일을 변경해야 하는 경우, 변경 전 그 이유를 간단히 기록한다. + +### 4. 완료 후 문서 갱신 + +모든 태스크 완료 후 아래 항목을 문서에 반영한다. 이 목록 외 내용은 수정하지 않는다. + +#### `#3 변경 파일 목록` 갱신 + +실제로 생성/수정/삭제된 파일을 기준으로 목록을 갱신한다. +- 계획에 있었으나 실제로 변경되지 않은 파일은 `비고`에 `미변경 - <이유>`를 기록하고 유지한다. +- 계획에 없었으나 실제로 변경된 파일은 새 행으로 추가하고 `비고`에 `계획 외 변경`을 기록한다. + +#### `#5 Verification으로 넘기기 전 확인 체크` 갱신 + +각 체크 항목을 실제 결과에 따라 `[x]`(완료) 또는 `[ ]`(미완료)로 업데이트한다. 블로킹 태스크가 있으면 해당 항목을 `[ ]`로 남기고 비고를 추가한다. + +#### `#6 파일 처리 결과` 갱신 + +- `처리 결과`: `갱신` +- `생성 경로`: 경로 확인 후 기입 +- `마지막 갱신 시각(KST)`: 현재 시각으로 기입 + +#### `#0 문서 상태` 변경 + +- `상태`: `review`로 변경 +- `마지막 갱신 시각(KST)`: 현재 시각으로 변경 + +### 5. 결과 보고 + +구현이 끝나면 아래 항목을 포함한 보고서를 출력한다. + +- **실행 완료된 태스크 목록** (T-N, 완료 조건 충족 여부) +- **블로킹 태스크** (있는 경우): 원인 및 필요한 사용자 결정 사항 +- **계획 외 변경 파일** (있는 경우): 파일명과 이유 +- **다음 단계 안내**: 블로킹 없음 → `/review-implementation sdlc-001` 실행 권장 + +--- + +## 중요 규칙 + +- `4_implementation.md`의 `#2`와 `#3`을 구현의 유일한 기준으로 삼는다. 범위 밖 변경은 사용자 확인 없이 수행하지 않는다. +- 기존 코드를 삭제하거나 되돌리기 어려운 파괴적 변경은 수행 전 사용자에게 확인한다. +- DoD가 측정 불가능한 서술로 되어 있으면 가능한 근접한 방식으로 자체 평가하고, 평가 방식을 보고서에 명시한다. +- 구현 실행은 `draft` 또는 `review` 상태에서만 허용한다. diff --git a/.github/prompts/run-sdlc.prompt.md b/.github/prompts/run-sdlc.prompt.md new file mode 100644 index 0000000..3e58855 --- /dev/null +++ b/.github/prompts/run-sdlc.prompt.md @@ -0,0 +1,257 @@ +--- +name: "run-sdlc" +description: "Run the full SDLC pipeline for a given cycle, automatically resuming from the first incomplete stage" +argument-hint: "예: sdlc-001 Justin" +agent: "agent" +--- +지정된 SDLC 주기의 전체 파이프라인을 순서대로 실행한다. + +인자: +- `sdlc-xyz`: SDLC 주기 ID (예: `sdlc-001`) +- `my-name`: 각 단계 승인자 이름 (예: `Justin`) + +목표: +- 지정된 SDLC 주기의 현재 진행 상태를 파악하고, 미완료 단계부터 순서대로 실행한다. +- 각 단계가 완료(`confirmed`)되면 다음 단계로 자동 진행한다. +- 사용자 판단이 필요한 경우 즉시 중단하고, 어떤 판단이 필요한지 명확하게 안내한다. + +--- + +## 실행 절차 + +### 1. 입력 해석 + +- 첫 번째 인자를 `CYCLE_ID`로 사용한다 (예: `sdlc-001`). +- 두 번째 인자를 `APPROVER_NAME`으로 사용한다 (예: `Justin`). +- `docs/sdlc/` 아래에서 `CYCLE_ID`로 시작하는 폴더를 찾는다. + - 폴더가 없으면 오류를 보고하고 중단한다. + - 폴더가 여러 개이면 가장 최근(날짜 순)을 사용하고 선택한 폴더 경로를 보고한다. +- 이후 단계에서 `SDLC_DIR = docs/sdlc/<일치하는 폴더>`로 참조한다. + +### 2. 현재 상태 파악 + +`SDLC_DIR/index.md`의 단계별 상태 테이블을 읽어 각 단계의 현재 상태를 확인한다. +파일이 없으면 각 문서 파일을 직접 읽어 `# 0. 문서 상태`의 `- 상태:` 줄에서 상태를 확인한다. + +확인 대상 단계와 해당 문서 파일: + +| 단계 | 문서 파일 | confirmed 조건 | +|------|-----------|----------------| +| Discovery | `1_discovery.md` | 상태 = `confirmed` 또는 `Ready for Planning: true` | +| Planning | `2_planning.md` | 상태 = `confirmed` 또는 `Ready for Design: true` | +| Design | `3_design.md` | 상태 = `confirmed` 또는 `Ready for Implementation: true` | +| Implementation | `4_implementation.md` | 상태 = `confirmed` 또는 `Ready for Verification: true` | +| Verification | `5_verification.md` | 상태 = `confirmed` 또는 `Ready for Release: true` | +| Release | `6_release.md` | 상태 = `confirmed` 또는 `Ready for Operations: true` | +| Operations | `7_operation.md` | 상태 = `confirmed` 또는 `SDLC 주기 완료: true` | + +### 3. 실행 시작 지점 결정 + +단계를 아래 순서로 순회하며 `confirmed`가 아닌 첫 번째 단계를 찾는다. + +1. Discovery +2. Planning +3. Design +4. Implementation +5. Verification +6. Release +7. Operations + +모든 단계가 `confirmed`이면 SDLC 주기가 완료되었음을 보고하고 종료한다. + +### 4. 단계별 실행 + +시작 지점부터 각 단계의 서브스텝을 아래 순서로 실행한다. +각 서브스텝 실행 후 결과를 확인하고, 블로킹 조건이 발생하면 즉시 중단한다. + +#### 4-1. Discovery 단계 (`1_discovery.md`) + +`1_discovery.md`의 상태에 따라 아래 서브스텝을 실행한다. + +| 현재 상태 | 실행할 서브스텝 | +|-----------|----------------| +| 파일 없음 | 오류 보고 후 중단 — Discovery 문서는 `/new-sdlc`로 먼저 생성해야 한다 | +| `draft` 또는 `review` | ① `review-discovery` → ② `confirm-discovery` | +| `confirmed` | 스킵 | + +- `review-discovery` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리) +- `confirm-discovery` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다. + 승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리) + +#### 4-2. Planning 단계 (`2_planning.md`) + +`2_planning.md`의 상태에 따라 아래 서브스텝을 실행한다. + +| 현재 상태 | 실행할 서브스텝 | +|-----------|----------------| +| 파일 없음 | ① `draft-planning` → ② `review-planning` → ③ `confirm-planning` | +| `draft` | ① `review-planning` → ② `confirm-planning` | +| `review` | ① `confirm-planning` | +| `confirmed` | 스킵 | + +- `draft-planning` 실행 시: Discovery가 `confirmed` 상태인지 확인한다. 아니면 중단. +- `review-planning` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리) +- `confirm-planning` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다. + 승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리) + +#### 4-3. Design 단계 (`3_design.md`) + +`3_design.md`의 상태에 따라 아래 서브스텝을 실행한다. + +| 현재 상태 | 실행할 서브스텝 | +|-----------|----------------| +| 파일 없음 | ① `draft-design` → ② `review-design` → ③ `confirm-design` | +| `draft` | ① `review-design` → ② `confirm-design` | +| `review` | ① `confirm-design` | +| `confirmed` | 스킵 | + +- `draft-design` 실행 시: Planning이 `confirmed` 상태인지 확인한다. 아니면 중단. +- `review-design` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리) +- `confirm-design` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다. + 승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리) + +#### 4-4. Implementation 단계 (`4_implementation.md`) + +`4_implementation.md`의 상태에 따라 아래 서브스텝을 실행한다. + +| 현재 상태 | 실행할 서브스텝 | +|-----------|----------------| +| 파일 없음 | ① `draft-implementation` → ② `run-implementation` → ③ `review-implementation` → ④ `confirm-implementation` | +| `draft` | ① `run-implementation` → ② `review-implementation` → ③ `confirm-implementation` | +| `review` | ① `review-implementation` → ② `confirm-implementation` | +| `confirmed` | 스킵 | + +- `draft-implementation` 실행 시: Design이 `confirmed` 상태인지 확인한다. 아니면 중단. +- `run-implementation` 실행 시: 블로킹 태스크가 발생하면 → [블로킹 처리](#블로킹-처리) +- `review-implementation` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리) +- `confirm-implementation` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다. + 승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리) + +#### 4-5. Verification 단계 (`5_verification.md`) + +`5_verification.md`의 상태에 따라 아래 서브스텝을 실행한다. + +| 현재 상태 | 실행할 서브스텝 | +|-----------|----------------| +| 파일 없음 | ① `draft-verification` → ② `review-verification` → ③ `confirm-verification` | +| `draft` | ① `review-verification` → ② `confirm-verification` | +| `review` | ① `confirm-verification` | +| `confirmed` | 스킵 | + +- `draft-verification` 실행 시: Implementation이 `confirmed` 상태인지 확인한다. 아니면 중단. +- `review-verification` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리) +- `confirm-verification` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다. + 승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리) + +#### 4-6. Release 단계 (`6_release.md`) + +`6_release.md`의 상태에 따라 아래 서브스텝을 실행한다. + +| 현재 상태 | 실행할 서브스텝 | +|-----------|----------------| +| 파일 없음 | ① `draft-release` → ② `review-release` → ③ `confirm-release` | +| `draft` | ① `review-release` → ② `confirm-release` | +| `review` | ① `confirm-release` | +| `confirmed` | 스킵 | + +- `draft-release` 실행 시: Verification이 `confirmed` 상태인지 확인한다. 아니면 중단. +- `review-release` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리) +- `confirm-release` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다. + 승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리) + +#### 4-7. Operations 단계 (`7_operation.md`) + +`7_operation.md`의 상태에 따라 아래 서브스텝을 실행한다. + +| 현재 상태 | 실행할 서브스텝 | +|-----------|----------------| +| 파일 없음 | ① `draft-operation` → ② `review-operation` → ③ `confirm-operation` | +| `draft` | ① `review-operation` → ② `confirm-operation` | +| `review` | ① `confirm-operation` | +| `confirmed` | 스킵 | + +- `draft-operation` 실행 시: Release가 `confirmed` 상태인지 확인한다. 아니면 중단. +- `review-operation` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리) +- `confirm-operation` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다. + 승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리) + +--- + +### 블로킹 처리 + +아래 상황 중 하나가 발생하면 즉시 실행을 중단하고 사용자에게 아래 정보를 제공한다. + +1. **review-* 결과가 보류(Hold)인 경우** + - 어느 단계의 review에서 보류가 발생했는지 + - 보류 이유 (review 결과에서 제시된 미충족 항목) + - 해결을 위해 필요한 사용자 조치 + +2. **confirm-* 결과가 승인 불가인 경우** + - 어느 단계의 confirm이 실패했는지 + - C 유형 미해소 플레이스홀더 목록 (해당 시) + - 미해소 오픈 질문 목록 (해당 시) + - 해결 방법 안내 (예: 문서에서 해당 항목을 직접 채운 후 `/run-sdlc ` 재실행) + +3. **run-implementation 실행 중 블로킹 태스크가 발생한 경우** + - 블로킹된 태스크 번호(T-N)와 원인 + - 사용자가 결정해야 할 사항 + - 해결 후 `/run-sdlc ` 재실행 안내 + +4. **Verification 단계가 미완료인 경우** + - Verification 문서의 현재 상태 + - 필요한 조치 안내 + +--- + +### 5. 완료 보고 + +전체 파이프라인이 완료되면(모든 단계 `confirmed`) 아래 내용을 포함한 완료 보고를 출력한다. + +- **완료된 주기**: `CYCLE_ID` +- **각 단계별 최종 상태** (표 형식) +- **이번 실행에서 처리된 단계 목록** +- **다음 Discovery 환류 항목**: Operations `# 6` 섹션의 내용 요약 (있는 경우) +- **다음 SDLC 주기 시작 안내**: `/new-sdlc <다음 이슈 내용>` 명령 안내 + +--- + +## 서브스텝 실행 방식 + +각 서브스텝은 해당 프롬프트 파일의 전체 절차를 그대로 실행한다. + +| 서브스텝 | 참조 프롬프트 | +|----------|--------------| +| `review-discovery` | `.github/prompts/review-discovery.prompt.md` | +| `confirm-discovery` | `.github/prompts/confirm-discovery.prompt.md` | +| `draft-planning` | `.github/prompts/draft-planning.prompt.md` | +| `review-planning` | `.github/prompts/review-planning.prompt.md` | +| `confirm-planning` | `.github/prompts/confirm-planning.prompt.md` | +| `draft-design` | `.github/prompts/draft-design.prompt.md` | +| `review-design` | `.github/prompts/review-design.prompt.md` | +| `confirm-design` | `.github/prompts/confirm-design.prompt.md` | +| `draft-implementation` | `.github/prompts/draft-implementation.prompt.md` | +| `run-implementation` | `.github/prompts/run-implementation.prompt.md` | +| `review-implementation` | `.github/prompts/review-implementation.prompt.md` | +| `confirm-implementation` | `.github/prompts/confirm-implementation.prompt.md` | +| `draft-verification` | `.github/prompts/draft-verification.prompt.md` | +| `review-verification` | `.github/prompts/review-verification.prompt.md` | +| `confirm-verification` | `.github/prompts/confirm-verification.prompt.md` | +| `draft-release` | `.github/prompts/draft-release.prompt.md` | +| `review-release` | `.github/prompts/review-release.prompt.md` | +| `confirm-release` | `.github/prompts/confirm-release.prompt.md` | +| `draft-operation` | `.github/prompts/draft-operation.prompt.md` | +| `review-operation` | `.github/prompts/review-operation.prompt.md` | +| `confirm-operation` | `.github/prompts/confirm-operation.prompt.md` | + +`confirm-*` 서브스텝 실행 시 `APPROVER_NAME`을 해당 문서의 Freeze 섹션 `Confirmed By:` 값으로 주입한다. +해당 줄이 문서에 없거나 플레이스홀더로 되어 있으면, 실행 전 `APPROVER_NAME`으로 교체한다. + +--- + +## 중요 규칙 + +- 각 단계는 정해진 순서대로만 실행하며, 이전 단계가 `confirmed`가 아닌 상태에서 다음 단계를 시작하지 않는다. +- `run-implementation`은 실제 코드를 변경하는 단계이므로, 블로킹 조건이 없어도 실행 전 `4_implementation.md`의 구현 계획(`# 2 구현 계획`)과 변경 파일 목록(`# 3 변경 파일 목록`)을 요약해 사용자에게 안내한 뒤 진행한다. +- 사용자 판단 없이 임의로 결정할 수 없는 항목(담당자 지정, 외부 환경 정보, 정책 결정 등)은 반드시 중단하고 사용자에게 문의한다. +- 블로킹 처리 후 사용자가 문서를 직접 수정하면 `/run-sdlc `을 재실행해 이어서 진행할 수 있다. +- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다. diff --git a/.github/prompts/verification-confirm.prompt.md b/.github/prompts/verification-confirm.prompt.md deleted file mode 100644 index 76aec10..0000000 --- a/.github/prompts/verification-confirm.prompt.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -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 deleted file mode 100644 index 25eaea8..0000000 --- a/.github/prompts/verification-draft.prompt.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -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 deleted file mode 100644 index d7c8acd..0000000 --- a/.github/prompts/verification-review.prompt.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -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/runbooks/services/api.rollback-runbook.md b/.github/runbooks/services/api.rollback-runbook.md deleted file mode 100644 index 39c8856..0000000 --- a/.github/runbooks/services/api.rollback-runbook.md +++ /dev/null @@ -1,60 +0,0 @@ -# API Service Rollback Runbook - -## Metadata - -1. Service: api -2. Runtime: uvicorn direct run -3. Environment: production -4. Owner: backend team -5. On-call Contact: backend-oncall -6. Last Updated (UTC): 2026-04-14 - -## Trigger Conditions - -1. Error Rate Threshold: 5xx > 2% for 5 minutes -2. Latency Threshold: p95 > 1200ms for 10 minutes -3. Availability Threshold: successful request rate < 99.5% -4. Data Integrity Alarm: write/read mismatch alerts > 0 -5. Business Impact Trigger: 결제/주문 API 실패 다수 발생 - -## Pre-rollback Checks - -1. 장애 범위 확인(엔드포인트/사용자/데이터) -2. 최근 릴리즈 커밋과 변경 DB 스크립트 확인 -3. 직전 안정 배포 아티팩트 식별 -4. 공지 채널(내부/외부) 준비 - -## Rollback Procedure - -1. 신규 배포 트래픽 중단 -2. 안정 버전 코드로 교체 -3. uvicorn 프로세스 재기동 -4. 헬스체크와 핵심 API 호출 검증 - -## Data Recovery Plan - -1. 복원 대상 데이터 범위: 최근 배포 이후 변경분 -2. 복원 방법: 백업 스냅샷 + 트랜잭션 로그 검증 -3. 데이터 무결성 검증 방법: 주문/결제 집계 대조 -4. 복원 예상 시간: 20~40분 - -## Validation After Rollback - -1. /health, /ready 정상 -2. 로그인/주문/결제 정상 시나리오 통과 -3. 5xx 비율 0.5% 이하 복귀 -4. p95 지연 700ms 이하 복귀 - -## Communication Plan - -1. 내부: 롤백 시작/완료 시점 공유 -2. 외부: 사용자 영향 공지(필요 시) -3. 상태 업데이트 주기: 15분 -4. 종료 공지 조건: 핵심 지표 30분 안정화 - -## Post-rollback Follow-up - -1. 원인 분석 티켓: INC-API-YYYYMMDD -2. 재배포 조건: 회귀 테스트 + 성능 검증 통과 -3. 임시 완화책 제거 계획: 48시간 내 정리 -4. Postmortem 일정: 24시간 내 \ No newline at end of file diff --git a/.github/runbooks/services/web.rollback-runbook.md b/.github/runbooks/services/web.rollback-runbook.md deleted file mode 100644 index afabb64..0000000 --- a/.github/runbooks/services/web.rollback-runbook.md +++ /dev/null @@ -1,58 +0,0 @@ -# Web Service Rollback Runbook - -## Metadata - -1. Service: web -2. Environment: production -3. Owner: frontend team -4. On-call Contact: frontend-oncall -5. Last Updated (UTC): 2026-04-14 - -## Trigger Conditions - -1. JS Error Threshold: 신규 릴리즈 후 오류율 2배 이상 -2. Page Load Threshold: p75 LCP > 4.0s for 10 minutes -3. Availability Threshold: 주요 페이지 성공률 < 99.0% -4. Business Impact Trigger: 로그인/결제 전환율 급락 - -## Pre-rollback Checks - -1. 영향 페이지 및 브라우저 범위 확인 -2. CDN 캐시 정책 확인 -3. 직전 안정 빌드 해시 확인 -4. 공지 채널 준비 - -## Rollback Procedure - -1. CDN 라우팅을 이전 빌드로 전환 -2. 신규 정적 자산 캐시 무효화 -3. 핵심 사용자 플로우 스모크 테스트 실행 -4. 오류/성능 지표 확인 - -## Data Recovery Plan - -1. 복원 대상 데이터 범위: 클라이언트 이벤트 손실 구간 -2. 복원 방법: 서버 로그 기반 보정 집계 -3. 데이터 무결성 검증 방법: 퍼널 단계별 이벤트 대조 -4. 복원 예상 시간: 15~30분 - -## Validation After Rollback - -1. 로그인/탐색/결제 플로우 정상 -2. JS 오류율 기준치 복귀 -3. LCP 및 API 오류율 정상화 -4. 사용자 CS 급증 여부 확인 - -## Communication Plan - -1. 내부: 배포 채널 및 온콜 채널 공지 -2. 외부: 장애 공지 페이지 업데이트(필요 시) -3. 상태 업데이트 주기: 15분 -4. 종료 공지 조건: 30분 이상 안정화 - -## Post-rollback Follow-up - -1. 원인 분석 티켓: INC-WEB-YYYYMMDD -2. 재배포 조건: 크로스브라우저 회귀 테스트 통과 -3. 임시 완화책 제거 계획: 48시간 내 -4. Postmortem 일정: 24시간 내 \ No newline at end of file diff --git a/.github/runbooks/services/worker.rollback-runbook.md b/.github/runbooks/services/worker.rollback-runbook.md deleted file mode 100644 index 590db8c..0000000 --- a/.github/runbooks/services/worker.rollback-runbook.md +++ /dev/null @@ -1,58 +0,0 @@ -# Worker Service Rollback Runbook - -## Metadata - -1. Service: worker -2. Environment: production -3. Owner: platform team -4. On-call Contact: platform-oncall -5. Last Updated (UTC): 2026-04-14 - -## Trigger Conditions - -1. Queue Backlog Threshold: 대기 작업 10,000건 초과 10분 지속 -2. Failure Threshold: 작업 실패율 > 3% for 10 minutes -3. Processing Delay Threshold: 평균 처리 지연 > 2x baseline -4. Data Integrity Alarm: 중복 처리 또는 누락 처리 감지 -5. Business Impact Trigger: 정산/알림 지연 사용자 영향 확대 - -## Pre-rollback Checks - -1. 실패 작업 샘플링 및 영향 범위 확인 -2. 재처리 가능 여부 확인 -3. 직전 안정 버전 아티팩트 확인 -4. 공지 채널 준비 - -## Rollback Procedure - -1. 신규 작업 소비 일시 중단 -2. 안정 버전으로 워커 교체 -3. 단계적 소비 재개(10% -> 50% -> 100%) -4. 실패/처리율 지표 확인 - -## Data Recovery Plan - -1. 복원 대상 데이터 범위: 누락/중복 처리된 이벤트 -2. 복원 방법: dead-letter queue 재처리 + idempotency 검증 -3. 데이터 무결성 검증 방법: 이벤트 카운트/체크섬 대조 -4. 복원 예상 시간: 30~60분 - -## Validation After Rollback - -1. backlog 감소 추세 확인 -2. 실패율 1% 이하 복귀 -3. 중복 처리 경보 해제 -4. 핵심 배치 완료 시간 정상화 - -## Communication Plan - -1. 내부: 대응 진행 상황 15분 주기 공유 -2. 외부: SLA 영향 시 사전 공지 -3. 종료 공지 조건: backlog 정상화 및 실패율 안정화 - -## Post-rollback Follow-up - -1. 원인 분석 티켓: INC-WORKER-YYYYMMDD -2. 재배포 조건: 부하 테스트 재통과 -3. 임시 완화책 제거 계획: 72시간 내 -4. Postmortem 일정: 24시간 내 \ No newline at end of file diff --git a/.github/scripts/bootstrap.sh b/.github/scripts/bootstrap.sh deleted file mode 100644 index 11c0ee0..0000000 --- a/.github/scripts/bootstrap.sh +++ /dev/null @@ -1,102 +0,0 @@ -#!/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 deleted file mode 100644 index f23db62..0000000 --- a/.github/skills/release-notes/SKILL.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -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 deleted file mode 100644 index 8fdb1d7..0000000 --- a/.github/skills/requirements-refinement/SKILL.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -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 deleted file mode 100644 index 2de4ee3..0000000 --- a/.github/skills/test-design/SKILL.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -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 deleted file mode 100644 index 0aa50f7..0000000 --- a/.github/templates/design-note.template.md +++ /dev/null @@ -1,71 +0,0 @@ -# 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 deleted file mode 100644 index 795a106..0000000 --- a/.github/templates/discovery-note.template.md +++ /dev/null @@ -1,90 +0,0 @@ -# 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 deleted file mode 100644 index 32110d9..0000000 --- a/.github/templates/implementation-note.template.md +++ /dev/null @@ -1,62 +0,0 @@ -# 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 deleted file mode 100644 index bace579..0000000 --- a/.github/templates/operations-note.template.md +++ /dev/null @@ -1,80 +0,0 @@ -# 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 deleted file mode 100644 index 07b685a..0000000 --- a/.github/templates/planning-backlog-scores.template.csv +++ /dev/null @@ -1,4 +0,0 @@ -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 deleted file mode 100644 index c33b453..0000000 --- a/.github/templates/planning-note.template.md +++ /dev/null @@ -1,63 +0,0 @@ -# 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 deleted file mode 100644 index 7dbd2be..0000000 --- a/.github/templates/planning-scoring-sheet.template.csv +++ /dev/null @@ -1,4 +0,0 @@ -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 deleted file mode 100644 index 4a6410d..0000000 --- a/.github/templates/release-note.template.md +++ /dev/null @@ -1,105 +0,0 @@ -# 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 deleted file mode 100644 index d8fceb5..0000000 --- a/.github/templates/rollback-runbook.template.md +++ /dev/null @@ -1,62 +0,0 @@ -# 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/sdlc/1_discovery.md b/.github/templates/sdlc/1_discovery.md new file mode 100644 index 0000000..b701b8b --- /dev/null +++ b/.github/templates/sdlc/1_discovery.md @@ -0,0 +1,219 @@ +# 0. 문서 상태 +이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다. + +- 상태: {{DOC_STATUS:draft|review|confirmed}} +- 문서 ID: {{CYCLE_ID:sdlc-<3자리>__}} +- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}} +- 작성 시각(KST): {{CREATED_AT_KST:TBD}} +- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}} + +# 1. 계획 상태 요약 +현재 Discovery가 어떤 배경에서 작성되고 있는지, 연계 문서가 있는지, 지금 시점의 해석이 무엇인지 짧게 요약한다. + +- 연계 문서 현황: + - Planning 점수 파일: {{PLANNING_SCORE_FILE:미생성 또는 경로}} + - 관련 TODO/메모: {{TODO_FILE:경로 또는 없음}} +- 해석: + - {{SUMMARY_LINE_1:현재 검토/작성 배경 요약}} + - {{SUMMARY_LINE_2:이번 Discovery에서 판단해야 할 핵심 요약}} + +# 2. 요구사항 판정 결과 +이번 요청이 기존 요구사항과 비교해 신규인지, 유사한지, 중복인지 판단하고 그 근거를 남긴다. + +- 판정: {{REQUIREMENT_CLASSIFICATION:완전 중복|유사|신규}} +- 근거 + - {{CLASSIFICATION_REASON_1}} + - {{CLASSIFICATION_REASON_2}} + +> **판정이 `완전 중복`인 경우**: 이하 섹션 작성을 중단하고 `# 9. 파일 처리 결과`에 중복 판정 사유와 참조 문서 경로를 기록한 뒤 문서를 닫는다. Planning으로 넘기지 않는다. + +# 3. 문제점의 요약 +문제의 현재 상태, 기대 상태, 관련 이해관계자, 제약사항을 정리한다. Discovery의 핵심 맥락을 가장 먼저 이해할 수 있어야 한다. + +- 현재 상태 + - {{CURRENT_STATE_1}} + - {{CURRENT_STATE_2}} +- 기대 상태 + - {{TARGET_STATE_1}} + - {{TARGET_STATE_2}} +- 이해관계자 + - {{STAKEHOLDER_1:예. 문서 작성자(AI agent)}} + - {{STAKEHOLDER_2:예. 리뷰어/승인자}} + - {{STAKEHOLDER_3:예. 운영 담당자}} +- 제약사항 + - {{CONSTRAINT_1}} + - {{CONSTRAINT_2}} + +## 주요 사용자 시나리오 +사용자 또는 운영자가 실제로 어떤 상황에서 이 변경을 필요로 하는지 대표 시나리오를 적는다. + +- {{USER_SCENARIO_1}} +- {{USER_SCENARIO_2}} +- {{USER_SCENARIO_3}} + +# 4. 이번에 정의할 변경 +이번 Discovery에서 다루는 핵심 변경 항목을 목록으로 적는다. 기능, 구조, 규칙 변경을 함께 포함해도 된다. + +- {{CHANGE_ITEM_1}} +- {{CHANGE_ITEM_2:필요 없으면 삭제}} +- {{CHANGE_ITEM_3:필요 없으면 삭제}} + +## 영향 범위 +변경이 미칠 코드/문서/운영 범위를 명시해 Planning에서 추정 누락을 줄인다. + +- 코드 영향: + - {{CODE_IMPACT_1:예. docs/sdlc/index.md 갱신 로직}} + - {{CODE_IMPACT_2:필요 없으면 삭제}} +- 문서 영향: + - {{DOC_IMPACT_1}} + - {{DOC_IMPACT_2:필요 없으면 삭제}} +- 운영 영향: + - {{OPS_IMPACT_1:예. 배포/운영 절차 변경 없음}} + - {{OPS_IMPACT_2:필요 없으면 삭제}} + +# 5. 요구사항 목록 +실제로 구현과 검증으로 이어질 요구사항을 기능/비기능으로 나누어 정리하고, 범위 경계를 명확히 적는다. + +## 기능 요구사항 +- FR-1: {{FR_1}} +- FR-2: {{FR_2}} +- FR-3: {{FR_3:필요 없으면 삭제}} +- FR-4: {{FR_4:필요 없으면 삭제}} + +## 비기능 요구사항 +성능, 운영성, 일관성, 자동화 안정성 등 기능 외 요구사항을 적는다. + +- NFR-1: {{NFR_1}} +- NFR-2: {{NFR_2}} +- NFR-3: {{NFR_3:필요 없으면 삭제}} + +## 범위 경계 +이번 반복에서 반드시 포함할 범위와 명시적으로 제외할 범위를 구분한다. + +- In Scope + - {{IN_SCOPE_1}} + - {{IN_SCOPE_2}} +- Out of Scope + - {{OUT_OF_SCOPE_1}} + - {{OUT_OF_SCOPE_2}} + +# 6. 리스크/가정 목록 +불확실성과 전제 조건을 분리해서 적는다. 리스크는 영향과 완화 방안을, 가정은 현재 판단의 전제를 기록한다. + +## 리스크 +- R-1 ({{RISK_LEVEL_1:High|Medium|Low}}): {{RISK_1}} + - 완화 방안: {{MITIGATION_1}} +- R-2 ({{RISK_LEVEL_2:High|Medium|Low}}): {{RISK_2}} + - 완화 방안: {{MITIGATION_2}} +- R-3 ({{RISK_LEVEL_3:High|Medium|Low}}): {{RISK_3:필요 없으면 삭제}} + - 완화 방안: {{MITIGATION_3:필요 없으면 삭제}} + +## 가정 +아직 확정되지 않았지만 현재 문서 작성의 기반이 되는 전제를 적는다. + +- A-1: {{ASSUMPTION_1}} +- A-2: {{ASSUMPTION_2}} +- A-3: {{ASSUMPTION_3:필요 없으면 삭제}} + +## 오픈 질문 +답을 아직 모르는 항목을 적는다. 추정으로 덮지 말고 Planning 이전에 확인할 질문으로 남긴다. + +- OQ-1: {{OPEN_QUESTION_1}} + - 상태: {{OPEN_QUESTION_STATUS_1:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{OPEN_QUESTION_ACTION_1:누가 어떤 방식으로 결정/확인할지}} + - 종료 조건: {{OPEN_QUESTION_EXIT_1:언제 이 질문을 Answered/Deferred/Dropped로 처리할지}} +- OQ-2: {{OPEN_QUESTION_2}} + - 상태: {{OPEN_QUESTION_STATUS_2:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{OPEN_QUESTION_ACTION_2:누가 어떤 방식으로 결정/확인할지}} + - 종료 조건: {{OPEN_QUESTION_EXIT_2:언제 이 질문을 Answered/Deferred/Dropped로 처리할지}} +- OQ-3: {{OPEN_QUESTION_3:필요 없으면 삭제}} + - 상태: {{OPEN_QUESTION_STATUS_3:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{OPEN_QUESTION_ACTION_3:누가 어떤 방식으로 결정/확인할지}} + - 종료 조건: {{OPEN_QUESTION_EXIT_3:언제 이 질문을 Answered/Deferred/Dropped로 처리할지}} + +### 오픈 질문 처리 기준 +- `Open`: 아직 답이 없고 다음 단계 진행에 영향이 있는 상태다. 문서에 유지한다. +- `Answered`: 답이 확정된 상태다. 관련 본문/요구사항에 반영한 뒤 오픈 질문 목록에서는 제거하거나 resolved 기록으로 이동한다. +- `Deferred`: 지금 단계에서 결정하지 않고 다음 단계 또는 후속 이슈로 넘기는 상태다. 넘길 대상과 이유를 반드시 적는다. +- `Dropped`: 더 이상 유효하지 않은 질문이다. 삭제 사유를 짧게 남기고 목록에서 제거한다. +- 처리 원칙 1: 질문만 남기지 말고 반드시 `상태`, `처리 방안`, `종료 조건`을 함께 적는다. +- 처리 원칙 2: 답이 나온 질문은 본문 반영 없이 단순 삭제하지 않는다. 반영 위치를 먼저 갱신한다. +- 처리 원칙 3: High 영향 질문은 `Deferred` 처리 후 처리 방안에 Planning 인계 추적 방식을 명시한다. + +# 7. 초기 성공 기준 +이 변경이 성공했다고 판단할 기준을 측정 가능하게 정의한다. 가능하면 데이터 출처까지 연결한다. + +- S-1: {{SUCCESS_METRIC_1}} +- S-2: {{SUCCESS_METRIC_2}} +- S-3: {{SUCCESS_METRIC_3:필요 없으면 삭제}} + +## 측정 방식 및 데이터 출처 +각 성공 기준을 어떻게 측정할지와 어떤 데이터나 문서를 근거로 쓸지 적는다. + +- S-1 측정 방식: {{MEASURE_METHOD_1}} / 데이터 출처: {{MEASURE_SOURCE_1}} +- S-2 측정 방식: {{MEASURE_METHOD_2}} / 데이터 출처: {{MEASURE_SOURCE_2}} +- S-3 측정 방식: {{MEASURE_METHOD_3:필요 없으면 삭제}} / 데이터 출처: {{MEASURE_SOURCE_3:필요 없으면 삭제}} + +# 8. Planning으로 넘기기 전 확인 체크 +Planning 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다. 미완료 항목은 후속 결정이 필요함을 뜻한다. + +- [ ] 범위(In Scope/Out of Scope) 확정 + - 기준: {{CHECK_SCOPE_CRITERIA}} +- [ ] 성공 지표의 측정 방식/데이터 출처 확정 + - 기준: {{CHECK_METRICS_CRITERIA}} +- [ ] High 영향 리스크 우선순위 및 해소 책임자 지정 + - 기준: {{CHECK_RISK_OWNER_CRITERIA}} +- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인 + - 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료 +- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정 + - 기준: {{CHECK_CONFIRMEDBY_CRITERIA}} + +# 9. 파일 처리 결과 +이 Discovery 문서 생성/갱신 결과와 참조 문서를 기록한다. 이후 추적과 리뷰 시 근거로 사용한다. + +- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}} +- 생성 경로: {{OUTPUT_PATH}} +- 참조 문서: + - {{REFERENCE_1}} + - {{REFERENCE_2}} + - {{REFERENCE_3:필요 없으면 삭제}} + +# 10. 사용자 결정 필요 항목 요약 +사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. 결정, 확인, 데이터 요청을 구분해서 적는다. + +## DECIDE +- {{DECIDE_ITEM_1}} +- {{DECIDE_ITEM_2:필요 없으면 삭제}} + +## CONFIRM +- {{CONFIRM_ITEM_1}} +- {{CONFIRM_ITEM_2:필요 없으면 삭제}} + +## DATA +- {{DATA_ITEM_1}} +- {{DATA_ITEM_2:필요 없으면 삭제}} + +# 11. Discovery Freeze +Planning 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다. + +## 섹션 참조 +- 범위: [# 5. 요구사항 목록 > 범위 경계](#5-요구사항-목록) +- 리스크/오픈 질문: [# 6. 리스크/가정 목록](#6-리스크가정-목록) +- 성공 기준: [# 7. 초기 성공 기준](#7-초기-성공-기준) +- 인계 전 확인: [# 8. Planning으로 넘기기 전 확인 체크](#8-planning으로-넘기기-전-확인-체크) +- 사용자 결정 필요: [# 10. 사용자 결정 필요 항목 요약](#10-사용자-결정-필요-항목-요약) + +## Freeze 플래그 +- Handoff Decision: {{FREEZE_HANDOFF_DECISION:Planning 진행 가능|보류}} +- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:진행 가능 또는 보류 판단 근거 1-2줄}} +- Ready for Planning: {{READY_FOR_PLANNING:false}} +- Confirmed By: {{CONFIRMED_BY:TBD}} +- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}} + +# 12. 작성 가이드 +템플릿 사용 시의 기본 규칙을 적는다. 실제 문서를 만들 때는 이 가이드를 기준으로 플레이스홀더를 치환한다. + +- 이 파일은 템플릿이다. 실제 문서 작성 시 `{{...}}` 플레이스홀더를 구체 값으로 교체한다. +- 필요 없는 항목은 삭제하고, 부족한 항목은 같은 형식으로 추가한다. +- Open Questions는 가정으로 대체하지 말고 그대로 유지한다. +- Discovery Freeze는 문서 하단에 반드시 유지한다. diff --git a/.github/templates/sdlc/2_planning.md b/.github/templates/sdlc/2_planning.md new file mode 100644 index 0000000..cd346f2 --- /dev/null +++ b/.github/templates/sdlc/2_planning.md @@ -0,0 +1,205 @@ +# 0. 문서 상태 +이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다. + +- 상태: {{DOC_STATUS:draft|review|confirmed}} +- 문서 ID: {{CYCLE_ID:sdlc-<3자리>__}} +- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}} +- 참조 Discovery: {{DISCOVERY_PATH:docs/sdlc//1_discovery.md}} +- 작성 시각(KST): {{CREATED_AT_KST:TBD}} +- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}} + +# 1. Discovery 인계 요약 +Discovery에서 확정된 핵심 내용을 요약한다. 원본은 1_discovery.md를 참조하며, 이 섹션은 Planning 작업의 입력 기준선이 된다. + +## 이슈 목적 +- {{PLANNING_ISSUE_PURPOSE:Discovery 이슈명과 핵심 목적 1-2줄}} + +## 확정 범위 +- In Scope + - {{PLANNING_IN_SCOPE_1}} + - {{PLANNING_IN_SCOPE_2}} +- Out of Scope + - {{PLANNING_OUT_OF_SCOPE_1}} + - {{PLANNING_OUT_OF_SCOPE_2}} + +## 기능 요구사항 (FR) 요약 +- FR-1: {{PLANNING_FR_1}} +- FR-2: {{PLANNING_FR_2}} +- FR-3: {{PLANNING_FR_3:필요 없으면 삭제}} +- FR-4: {{PLANNING_FR_4:필요 없으면 삭제}} + +## 비기능 요구사항 (NFR) 요약 +- NFR-1: {{PLANNING_NFR_1}} +- NFR-2: {{PLANNING_NFR_2:필요 없으면 삭제}} + +## 이월된 오픈 질문 / 리스크 +Discovery에서 `Deferred` 처리되어 Planning 단계에서 해소해야 하는 항목을 기록한다. + +- {{DEFERRED_ITEM_1:없으면 "없음"}} +- {{DEFERRED_ITEM_2:필요 없으면 삭제}} + +# 2. 작업 분해 (Task Breakdown) +FR/NFR 각각을 실행 가능한 단위 태스크로 분해한다. 각 태스크는 하나의 완료 조건을 가져야 한다. + +| ID | 태스크 제목 | 유형 | 참조 요구사항 | 의존 태스크 | 담당자 | +|-----|-----------|------|--------------|------------|--------| +| T-1 | {{TASK_TITLE_1}} | {{TASK_TYPE_1:개발\|문서\|검토\|설계\|운영}} | {{TASK_REF_1:FR-1}} | - | {{TASK_OWNER_1:TBD}} | +| T-2 | {{TASK_TITLE_2}} | {{TASK_TYPE_2:개발\|문서\|검토\|설계\|운영}} | {{TASK_REF_2:FR-2}} | {{TASK_DEP_2:-}} | {{TASK_OWNER_2:TBD}} | +| T-3 | {{TASK_TITLE_3:필요 없으면 삭제}} | {{TASK_TYPE_3:개발\|문서\|검토\|설계\|운영}} | {{TASK_REF_3}} | {{TASK_DEP_3:-}} | {{TASK_OWNER_3:TBD}} | +| T-4 | {{TASK_TITLE_4:필요 없으면 삭제}} | {{TASK_TYPE_4:개발\|문서\|검토\|설계\|운영}} | {{TASK_REF_4}} | {{TASK_DEP_4:-}} | {{TASK_OWNER_4:TBD}} | + +## 태스크 완료 조건 (DoD) +각 태스크의 완료 기준을 명시한다. + +- T-1: {{TASK_DOD_1}} +- T-2: {{TASK_DOD_2}} +- T-3: {{TASK_DOD_3:필요 없으면 삭제}} +- T-4: {{TASK_DOD_4:필요 없으면 삭제}} + +# 3. 공수 추정 +각 태스크의 예상 공수를 적는다. 단위는 팀 기준에 맞게 선택한다(SP 또는 시간). + +| ID | 태스크 제목 | 추정 공수 | 추정 단위 | 비고 | +|-----|-----------|---------|---------|------| +| T-1 | {{TASK_TITLE_1}} | {{EFFORT_1}} | {{EFFORT_UNIT:SP\|시간\|일}} | {{EFFORT_NOTE_1:필요 없으면 삭제}} | +| T-2 | {{TASK_TITLE_2}} | {{EFFORT_2}} | {{EFFORT_UNIT}} | {{EFFORT_NOTE_2:필요 없으면 삭제}} | +| T-3 | {{TASK_TITLE_3:필요 없으면 삭제}} | {{EFFORT_3}} | {{EFFORT_UNIT}} | {{EFFORT_NOTE_3:필요 없으면 삭제}} | +| T-4 | {{TASK_TITLE_4:필요 없으면 삭제}} | {{EFFORT_4}} | {{EFFORT_UNIT}} | {{EFFORT_NOTE_4:필요 없으면 삭제}} | + +- 총 추정 공수: {{TOTAL_EFFORT}} +- 추정 신뢰도: {{EFFORT_CONFIDENCE:High|Medium|Low}} +- 추정 근거: {{EFFORT_BASIS:추정에 사용한 방법 또는 유사 사례}} + +# 4. 일정 계획 +이터레이션 또는 스프린트 단위로 태스크 배분 계획을 적는다. + +## 마일스톤 +| 마일스톤 | 목표 날짜 | 포함 태스크 | 완료 조건 | +|---------|---------|-----------|---------| +| M-1: {{MILESTONE_1_NAME}} | {{MILESTONE_1_DATE:TBD}} | {{MILESTONE_1_TASKS:T-1, T-2}} | {{MILESTONE_1_DONE}} | +| M-2: {{MILESTONE_2_NAME:필요 없으면 삭제}} | {{MILESTONE_2_DATE:TBD}} | {{MILESTONE_2_TASKS}} | {{MILESTONE_2_DONE}} | + +## 이터레이션 계획 +- 이터레이션 단위: {{ITERATION_UNIT:스프린트|주|없음(단일 배포)}} +- 이터레이션 1 ({{ITERATION_1_PERIOD:날짜 범위 또는 TBD}}): {{ITERATION_1_TASKS:T-1, T-2}} +- 이터레이션 2 ({{ITERATION_2_PERIOD:날짜 범위 또는 TBD}}): {{ITERATION_2_TASKS:T-3, T-4}} + +# 5. 의존성 및 제약 +태스크 간 의존 관계와 외부 의존성을 기록한다. + +## 태스크 간 의존성 +- {{TASK_DEPENDENCY_1:예. T-2는 T-1 완료 후 시작 가능}} +- {{TASK_DEPENDENCY_2:필요 없으면 삭제}} + +## 외부 의존성 +다른 팀, 시스템, 도구에 의존하는 항목을 적는다. + +- {{EXTERNAL_DEP_1:예. CI/CD 파이프라인 설정 필요}} +- {{EXTERNAL_DEP_2:필요 없으면 삭제}} + +## 기술/환경 제약 +- {{TECH_CONSTRAINT_1}} +- {{TECH_CONSTRAINT_2:필요 없으면 삭제}} + +# 6. 검증 계획 개요 +Discovery의 성공 기준과 연결해 어떻게 검증할지 초안을 적는다. 상세 검증은 Verification 단계에서 정의한다. + +| 성공 기준 | 검증 방법 초안 | 담당자 | +|---------|-------------|--------| +| {{VERIFY_CRITERIA_1:S-1 요약}} | {{VERIFY_METHOD_1}} | {{VERIFY_OWNER_1:TBD}} | +| {{VERIFY_CRITERIA_2:S-2 요약}} | {{VERIFY_METHOD_2}} | {{VERIFY_OWNER_2:TBD}} | +| {{VERIFY_CRITERIA_3:S-3 요약 또는 삭제}} | {{VERIFY_METHOD_3}} | {{VERIFY_OWNER_3:TBD}} | + +# 7. 리스크 +Planning 단계에서 새로 식별된 리스크를 기록한다. Discovery에서 이월된 리스크는 `# 1` 이월 항목에서 확인한다. + +## 리스크 +- R-1 ({{PLAN_RISK_LEVEL_1:High|Medium|Low}}): {{PLAN_RISK_1}} + - 완화 방안: {{PLAN_MITIGATION_1}} +- R-2 ({{PLAN_RISK_LEVEL_2:High|Medium|Low}}): {{PLAN_RISK_2:필요 없으면 삭제}} + - 완화 방안: {{PLAN_MITIGATION_2:필요 없으면 삭제}} + +## 가정 +Planning 수행의 전제가 되는 가정을 적는다. + +- PA-1: {{PLAN_ASSUMPTION_1}} +- PA-2: {{PLAN_ASSUMPTION_2:필요 없으면 삭제}} + +## 오픈 질문 +Planning 진행 중 확인이 필요한 질문을 적는다. + +- OQ-1: {{PLAN_OPEN_QUESTION_1}} + - 상태: {{PLAN_OQ_STATUS_1:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{PLAN_OQ_ACTION_1}} + - 종료 조건: {{PLAN_OQ_EXIT_1}} +- OQ-2: {{PLAN_OPEN_QUESTION_2:필요 없으면 삭제}} + - 상태: {{PLAN_OQ_STATUS_2:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{PLAN_OQ_ACTION_2}} + - 종료 조건: {{PLAN_OQ_EXIT_2}} + +# 8. Design으로 넘기기 전 확인 체크 +Design 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다. + +- [ ] 전체 태스크 목록 확정 및 담당자 지정 + - 기준: {{CHECK_TASKS_CRITERIA:모든 태스크에 담당자가 지정되어야 한다}} +- [ ] 공수 추정 완료 및 총 공수 확인 + - 기준: {{CHECK_EFFORT_CRITERIA:모든 태스크의 추정 공수가 채워져야 한다}} +- [ ] 마일스톤 및 이터레이션 계획 확정 + - 기준: {{CHECK_SCHEDULE_CRITERIA:M-1 이상의 마일스톤과 이터레이션 경계가 정의되어야 한다}} +- [ ] 외부 의존성 해소 계획 확인 + - 기준: {{CHECK_DEP_CRITERIA:외부 의존성 각 항목에 담당자 또는 해소 방안이 있어야 한다}} +- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인 + - 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료 +- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정 + - 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다}} + +# 9. 파일 처리 결과 +이 Planning 문서 생성/갱신 결과와 참조 문서를 기록한다. + +- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}} +- 생성 경로: {{OUTPUT_PATH}} +- 참조 문서: + - {{DISCOVERY_PATH:docs/sdlc//1_discovery.md}} + - {{REFERENCE_1:필요 없으면 삭제}} + +# 10. 사용자 결정 필요 항목 요약 +사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. + +## DECIDE +- {{DECIDE_ITEM_1}} +- {{DECIDE_ITEM_2:필요 없으면 삭제}} + +## CONFIRM +- {{CONFIRM_ITEM_1}} +- {{CONFIRM_ITEM_2:필요 없으면 삭제}} + +## DATA +- {{DATA_ITEM_1}} +- {{DATA_ITEM_2:필요 없으면 삭제}} + +# 11. Planning Freeze +Design 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다. + +## 섹션 참조 +- 작업 분해: [# 2. 작업 분해](#2-작업-분해-task-breakdown) +- 공수/일정: [# 3. 공수 추정](#3-공수-추정), [# 4. 일정 계획](#4-일정-계획) +- 의존성: [# 5. 의존성 및 제약](#5-의존성-및-제약) +- 검증 계획: [# 6. 검증 계획 개요](#6-검증-계획-개요) +- 리스크/오픈 질문: [# 7. 리스크](#7-리스크) +- 인계 전 확인: [# 8. Design으로 넘기기 전 확인 체크](#8-design으로-넘기기-전-확인-체크) +- 사용자 결정 필요: [# 10. 사용자 결정 필요 항목 요약](#10-사용자-결정-필요-항목-요약) + +## Freeze 플래그 +- Handoff Decision: {{FREEZE_HANDOFF_DECISION:Design 진행 가능|보류}} +- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:진행 가능 또는 보류 판단 근거 1-2줄}} +- Ready for Design: {{READY_FOR_DESIGN:false}} +- Confirmed By: {{CONFIRMED_BY:TBD}} +- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}} + +# 12. 작성 가이드 +템플릿 사용 시의 기본 규칙을 적는다. 실제 문서를 만들 때는 이 가이드를 기준으로 플레이스홀더를 치환한다. + +- 이 파일은 템플릿이다. 실제 문서 작성 시 `{{...}}` 플레이스홀더를 구체 값으로 교체한다. +- 필요 없는 태스크/마일스톤 행은 삭제하고, 부족한 항목은 같은 형식으로 추가한다. +- 공수 추정은 팀 기준 단위(SP/시간/일)를 통일해서 사용한다. +- Planning Freeze는 문서 하단에 반드시 유지한다. diff --git a/.github/templates/sdlc/3_design.md b/.github/templates/sdlc/3_design.md new file mode 100644 index 0000000..4dd5ded --- /dev/null +++ b/.github/templates/sdlc/3_design.md @@ -0,0 +1,187 @@ +# 0. 문서 상태 +이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다. + +- 상태: {{DOC_STATUS:draft|review|confirmed}} +- 문서 ID: {{CYCLE_ID:sdlc-<3자리>__}} +- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}} +- 참조 Planning: {{PLANNING_PATH:docs/sdlc//2_planning.md}} +- 작성 시각(KST): {{CREATED_AT_KST:TBD}} +- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}} + +# 1. Planning 인계 요약 +Planning에서 확정된 핵심 내용을 요약한다. 원본은 2_planning.md를 참조하며, 이 섹션은 Design 작업의 입력 기준선이 된다. + +## 이슈 목적 +- {{DESIGN_ISSUE_PURPOSE:Planning 이슈명과 핵심 목적 1-2줄}} + +## 확정 태스크 목록 +| ID | 태스크 제목 | 참조 요구사항 | 담당자 | +|----|-----------|------------|--------| +| T-1 | {{DESIGN_TASK_TITLE_1}} | {{DESIGN_TASK_REF_1}} | {{DESIGN_TASK_OWNER_1:TBD}} | +| T-2 | {{DESIGN_TASK_TITLE_2}} | {{DESIGN_TASK_REF_2}} | {{DESIGN_TASK_OWNER_2:TBD}} | +| T-3 | {{DESIGN_TASK_TITLE_3:필요 없으면 삭제}} | {{DESIGN_TASK_REF_3}} | {{DESIGN_TASK_OWNER_3:TBD}} | + +## 이월된 오픈 질문 / 리스크 +Planning에서 `Deferred` 처리되어 Design 단계에서 해소해야 하는 항목을 기록한다. + +- {{DESIGN_DEFERRED_ITEM_1:없으면 "없음"}} +- {{DESIGN_DEFERRED_ITEM_2:필요 없으면 삭제}} + +# 2. 아키텍처 및 구조 설계 +변경이 미치는 전체 구조와 주요 컴포넌트 관계를 설명한다. + +## 전체 구조 개요 +{{ARCH_OVERVIEW:시스템/모듈/파일 구조를 개요 수준으로 설명. 다이어그램 또는 목록 형태 모두 가능}} + +## 주요 컴포넌트 +| 컴포넌트 | 역할 | 영향 범위 | +|---------|------|---------| +| {{COMPONENT_1_NAME}} | {{COMPONENT_1_ROLE}} | {{COMPONENT_1_SCOPE}} | +| {{COMPONENT_2_NAME}} | {{COMPONENT_2_ROLE}} | {{COMPONENT_2_SCOPE}} | +| {{COMPONENT_3_NAME:필요 없으면 삭제}} | {{COMPONENT_3_ROLE}} | {{COMPONENT_3_SCOPE}} | + +## 데이터 흐름 +변경과 관련된 주요 데이터 흐름 또는 처리 순서를 적는다. 복잡하면 단계별 목록으로 표현한다. + +- {{DATA_FLOW_1}} +- {{DATA_FLOW_2}} +- {{DATA_FLOW_3:필요 없으면 삭제}} + +# 3. 상세 설계 +태스크(T-N)별로 구체적인 구현/변경 방법을 기술한다. + +## T-1: {{DESIGN_TASK_TITLE_1}} +- 설계 방향: {{DESIGN_DETAIL_1}} +- 변경 대상: {{DESIGN_TARGET_1:파일 경로, 함수명, 설정 키 등}} +- 입력/출력: {{DESIGN_IO_1:입력값과 출력값 또는 사이드이펙트}} +- 예외/엣지 케이스: {{DESIGN_EDGE_1:필요 없으면 삭제}} + +## T-2: {{DESIGN_TASK_TITLE_2}} +- 설계 방향: {{DESIGN_DETAIL_2}} +- 변경 대상: {{DESIGN_TARGET_2}} +- 입력/출력: {{DESIGN_IO_2}} +- 예외/엣지 케이스: {{DESIGN_EDGE_2:필요 없으면 삭제}} + +## T-3: {{DESIGN_TASK_TITLE_3:필요 없으면 삭제}} +- 설계 방향: {{DESIGN_DETAIL_3}} +- 변경 대상: {{DESIGN_TARGET_3}} +- 입력/출력: {{DESIGN_IO_3}} +- 예외/엣지 케이스: {{DESIGN_EDGE_3:필요 없으면 삭제}} + +# 4. 인터페이스 정의 +외부 시스템, 모듈 간 계약(API, 이벤트, 파일 포맷 등)을 명시한다. 해당 없으면 "해당 없음"으로 기재한다. + +## API / 함수 시그니처 +- {{INTERFACE_1:예. function foo(bar: string): boolean — 설명}} +- {{INTERFACE_2:필요 없으면 삭제}} + +## 데이터 스키마 / 포맷 +- {{SCHEMA_1:예. { id: string, status: "draft"|"confirmed" } — 설명}} +- {{SCHEMA_2:필요 없으면 삭제}} + +## 이벤트 / 메시지 +- {{EVENT_1:필요 없으면 삭제}} +- {{EVENT_2:필요 없으면 삭제}} + +# 5. 보안 고려사항 +OWASP Top 10 기준으로 이번 변경에서 주의해야 할 보안 항목을 점검한다. + +| 항목 | 해당 여부 | 대응 방안 | +|------|---------|---------| +| 입력값 검증 (Injection) | {{SEC_INJECTION:해당|비해당}} | {{SEC_INJECTION_ACTION:비해당이면 삭제}} | +| 인증/인가 | {{SEC_AUTH:해당|비해당}} | {{SEC_AUTH_ACTION:비해당이면 삭제}} | +| 민감 데이터 노출 | {{SEC_DATA:해당|비해당}} | {{SEC_DATA_ACTION:비해당이면 삭제}} | +| 의존성 취약점 | {{SEC_DEP:해당|비해당}} | {{SEC_DEP_ACTION:비해당이면 삭제}} | +| 기타 | {{SEC_OTHER:필요 없으면 삭제}} | {{SEC_OTHER_ACTION:필요 없으면 삭제}} | + +# 6. 리스크 +Design 단계에서 새로 식별된 리스크를 기록한다. Planning에서 이월된 리스크는 `# 1` 이월 항목에서 확인한다. + +## 리스크 +- R-1 ({{DESIGN_RISK_LEVEL_1:High|Medium|Low}}): {{DESIGN_RISK_1}} + - 완화 방안: {{DESIGN_MITIGATION_1}} +- R-2 ({{DESIGN_RISK_LEVEL_2:High|Medium|Low}}): {{DESIGN_RISK_2:필요 없으면 삭제}} + - 완화 방안: {{DESIGN_MITIGATION_2:필요 없으면 삭제}} + +## 가정 +Design 수행의 전제가 되는 가정을 적는다. + +- DA-1: {{DESIGN_ASSUMPTION_1}} +- DA-2: {{DESIGN_ASSUMPTION_2:필요 없으면 삭제}} + +## 오픈 질문 +Design 진행 중 확인이 필요한 질문을 적는다. + +- OQ-1: {{DESIGN_OPEN_QUESTION_1}} + - 상태: {{DESIGN_OQ_STATUS_1:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{DESIGN_OQ_ACTION_1}} + - 종료 조건: {{DESIGN_OQ_EXIT_1}} +- OQ-2: {{DESIGN_OPEN_QUESTION_2:필요 없으면 삭제}} + - 상태: {{DESIGN_OQ_STATUS_2:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{DESIGN_OQ_ACTION_2}} + - 종료 조건: {{DESIGN_OQ_EXIT_2}} + +# 7. Implementation으로 넘기기 전 확인 체크 +Implementation 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다. + +- [ ] 전체 컴포넌트 및 태스크별 설계 완성 + - 기준: {{CHECK_DESIGN_COMPLETE:모든 T-N 태스크에 설계 방향과 변경 대상이 채워져야 한다}} +- [ ] 인터페이스 계약 확정 + - 기준: {{CHECK_INTERFACE:외부 의존 컴포넌트와의 계약이 명시되어야 한다}} +- [ ] 보안 점검 완료 + - 기준: {{CHECK_SECURITY:OWASP 점검 항목 중 해당 항목은 대응 방안이 있어야 한다}} +- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인 + - 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료 +- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정 + - 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다}} + +# 8. 파일 처리 결과 +이 Design 문서 생성/갱신 결과와 참조 문서를 기록한다. + +- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}} +- 생성 경로: {{OUTPUT_PATH}} +- 참조 문서: + - {{PLANNING_PATH:docs/sdlc//2_planning.md}} + - {{REFERENCE_1:필요 없으면 삭제}} + +# 9. 사용자 결정 필요 항목 요약 +사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. + +## DECIDE +- {{DECIDE_ITEM_1}} +- {{DECIDE_ITEM_2:필요 없으면 삭제}} + +## CONFIRM +- {{CONFIRM_ITEM_1}} +- {{CONFIRM_ITEM_2:필요 없으면 삭제}} + +## DATA +- {{DATA_ITEM_1}} +- {{DATA_ITEM_2:필요 없으면 삭제}} + +# 10. Design Freeze +Implementation 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다. + +## 섹션 참조 +- 아키텍처/구조: [# 2. 아키텍처 및 구조 설계](#2-아키텍처-및-구조-설계) +- 상세 설계: [# 3. 상세 설계](#3-상세-설계) +- 인터페이스: [# 4. 인터페이스 정의](#4-인터페이스-정의) +- 보안: [# 5. 보안 고려사항](#5-보안-고려사항) +- 리스크/오픈 질문: [# 6. 리스크](#6-리스크) +- 인계 전 확인: [# 7. Implementation으로 넘기기 전 확인 체크](#7-implementation으로-넘기기-전-확인-체크) +- 사용자 결정 필요: [# 9. 사용자 결정 필요 항목 요약](#9-사용자-결정-필요-항목-요약) + +## Freeze 플래그 +- Handoff Decision: {{FREEZE_HANDOFF_DECISION:Implementation 진행 가능|보류}} +- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:진행 가능 또는 보류 판단 근거 1-2줄}} +- Ready for Implementation: {{READY_FOR_IMPLEMENTATION:false}} +- Confirmed By: {{CONFIRMED_BY:TBD}} +- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}} + +# 11. 작성 가이드 +템플릿 사용 시의 기본 규칙을 적는다. 실제 문서를 만들 때는 이 가이드를 기준으로 플레이스홀더를 치환한다. + +- 이 파일은 템플릿이다. 실제 문서 작성 시 `{{...}}` 플레이스홀더를 구체 값으로 교체한다. +- 필요 없는 컴포넌트/태스크 항목은 삭제하고, 부족한 항목은 같은 형식으로 추가한다. +- 보안 고려사항은 "비해당"이라도 근거를 남긴다. +- Design Freeze는 문서 하단에 반드시 유지한다. diff --git a/.github/templates/sdlc/4_implementation.md b/.github/templates/sdlc/4_implementation.md new file mode 100644 index 0000000..0d3a1a8 --- /dev/null +++ b/.github/templates/sdlc/4_implementation.md @@ -0,0 +1,155 @@ +# 0. 문서 상태 +이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다. + +- 상태: {{DOC_STATUS:draft|review|confirmed}} +- 문서 ID: {{CYCLE_ID:sdlc-<3자리>__}} +- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}} +- 참조 Design: {{DESIGN_PATH:docs/sdlc//3_design.md}} +- 작성 시각(KST): {{CREATED_AT_KST:TBD}} +- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}} + +# 1. Design 인계 요약 +Design에서 확정된 핵심 내용을 요약한다. 원본은 3_design.md를 참조하며, 이 섹션은 Implementation 작업의 입력 기준선이 된다. + +## 이슈 목적 +- {{IMP_ISSUE_PURPOSE:Design 이슈명과 핵심 목적 1-2줄}} + +## 확정 태스크 및 변경 대상 +| ID | 태스크 제목 | 변경 대상 파일/함수 | 담당자 | +|----|-----------|-------------------|--------| +| T-1 | {{IMP_TASK_TITLE_1}} | {{IMP_TASK_TARGET_1}} | {{IMP_TASK_OWNER_1:TBD}} | +| T-2 | {{IMP_TASK_TITLE_2}} | {{IMP_TASK_TARGET_2}} | {{IMP_TASK_OWNER_2:TBD}} | +| T-3 | {{IMP_TASK_TITLE_3:필요 없으면 삭제}} | {{IMP_TASK_TARGET_3}} | {{IMP_TASK_OWNER_3:TBD}} | + +## 이월된 오픈 질문 / 리스크 +Design에서 `Deferred` 처리되어 Implementation 단계에서 해소해야 하는 항목을 기록한다. + +- {{IMP_DEFERRED_ITEM_1:없으면 "없음"}} +- {{IMP_DEFERRED_ITEM_2:필요 없으면 삭제}} + +# 2. 구현 계획 +태스크(T-N)별 구현 순서와 접근 방법을 기술한다. + +## 구현 순서 +태스크 간 의존 관계와 우선순위를 고려한 구현 순서를 정의한다. + +1. {{IMP_ORDER_1:예. T-1 — 기반 구조 구현 (다른 태스크의 의존 대상)}} +2. {{IMP_ORDER_2:예. T-2 — 핵심 기능 구현}} +3. {{IMP_ORDER_3:필요 없으면 삭제}} + +## T-1: {{IMP_TASK_TITLE_1}} +- 구현 방법: {{IMP_METHOD_1:설계 방향을 실제 코드/설정으로 구현하는 접근}} +- 변경 대상: {{IMP_TARGET_1:실제 파일 경로, 함수명, 설정 키}} +- 완료 조건: {{IMP_DOD_1:이 태스크가 완료된 것으로 간주하는 기준}} +- 주의사항: {{IMP_NOTE_1:구현 중 주의해야 할 사항. 필요 없으면 삭제}} + +## T-2: {{IMP_TASK_TITLE_2}} +- 구현 방법: {{IMP_METHOD_2}} +- 변경 대상: {{IMP_TARGET_2}} +- 완료 조건: {{IMP_DOD_2}} +- 주의사항: {{IMP_NOTE_2:필요 없으면 삭제}} + +## T-3: {{IMP_TASK_TITLE_3:필요 없으면 삭제}} +- 구현 방법: {{IMP_METHOD_3}} +- 변경 대상: {{IMP_TARGET_3}} +- 완료 조건: {{IMP_DOD_3}} +- 주의사항: {{IMP_NOTE_3:필요 없으면 삭제}} + +# 3. 변경 파일 목록 +이번 Implementation에서 생성/수정/삭제되는 파일을 미리 나열한다. 구현 완료 후 실제 결과를 반영해 갱신한다. + +| 파일 경로 | 변경 유형 | 관련 태스크 | 비고 | +|---------|---------|-----------|------| +| {{IMP_FILE_1}} | {{IMP_FILE_TYPE_1:생성\|수정\|삭제}} | {{IMP_FILE_TASK_1:T-1}} | {{IMP_FILE_NOTE_1:필요 없으면 삭제}} | +| {{IMP_FILE_2}} | {{IMP_FILE_TYPE_2:생성\|수정\|삭제}} | {{IMP_FILE_TASK_2}} | {{IMP_FILE_NOTE_2:필요 없으면 삭제}} | +| {{IMP_FILE_3:필요 없으면 삭제}} | {{IMP_FILE_TYPE_3:생성\|수정\|삭제}} | {{IMP_FILE_TASK_3}} | {{IMP_FILE_NOTE_3:필요 없으면 삭제}} | + +# 4. 리스크 및 제약 +Implementation 단계에서 새로 식별된 리스크와 제약사항을 기록한다. + +## 리스크 +- R-1 ({{IMP_RISK_LEVEL_1:High|Medium|Low}}): {{IMP_RISK_1}} + - 완화 방안: {{IMP_MITIGATION_1}} +- R-2 ({{IMP_RISK_LEVEL_2:High|Medium|Low}}): {{IMP_RISK_2:필요 없으면 삭제}} + - 완화 방안: {{IMP_MITIGATION_2:필요 없으면 삭제}} + +## 가정 +Implementation 수행의 전제가 되는 가정을 적는다. + +- IA-1: {{IMP_ASSUMPTION_1}} +- IA-2: {{IMP_ASSUMPTION_2:필요 없으면 삭제}} + +## 오픈 질문 +Implementation 진행 중 확인이 필요한 질문을 적는다. + +- OQ-1: {{IMP_OPEN_QUESTION_1}} + - 상태: {{IMP_OQ_STATUS_1:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{IMP_OQ_ACTION_1}} + - 종료 조건: {{IMP_OQ_EXIT_1}} +- OQ-2: {{IMP_OPEN_QUESTION_2:필요 없으면 삭제}} + - 상태: {{IMP_OQ_STATUS_2:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{IMP_OQ_ACTION_2}} + - 종료 조건: {{IMP_OQ_EXIT_2}} + +# 5. Verification으로 넘기기 전 확인 체크 +Verification 단계로 넘기기 전에 무엇이 완료되어야 하는지 확인한다. + +- [ ] 모든 T-N 태스크 구현 완료 + - 기준: {{CHECK_ALL_TASKS:각 태스크의 완료 조건(DoD)을 충족해야 한다}} +- [ ] 변경 파일 목록과 실제 변경 일치 + - 기준: {{CHECK_FILE_LIST:3_design.md의 변경 대상과 실제 변경된 파일이 일치해야 한다}} +- [ ] 단위 테스트 또는 로컬 검증 완료 + - 기준: {{CHECK_LOCAL_VERIFY:변경 사항이 로컬 환경에서 의도대로 동작하는지 확인해야 한다}} +- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인 + - 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료 +- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정 + - 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다}} + +# 6. 파일 처리 결과 +이 Implementation 문서 생성/갱신 결과와 참조 문서를 기록한다. + +- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}} +- 생성 경로: {{OUTPUT_PATH}} +- 참조 문서: + - {{DESIGN_PATH:docs/sdlc//3_design.md}} + - {{REFERENCE_1:필요 없으면 삭제}} + +# 7. 사용자 결정 필요 항목 요약 +사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. + +## DECIDE +- {{DECIDE_ITEM_1}} +- {{DECIDE_ITEM_2:필요 없으면 삭제}} + +## CONFIRM +- {{CONFIRM_ITEM_1}} +- {{CONFIRM_ITEM_2:필요 없으면 삭제}} + +## DATA +- {{DATA_ITEM_1}} +- {{DATA_ITEM_2:필요 없으면 삭제}} + +# 8. Implementation Freeze +Verification 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다. + +## 섹션 참조 +- 구현 계획: [# 2. 구현 계획](#2-구현-계획) +- 변경 파일 목록: [# 3. 변경 파일 목록](#3-변경-파일-목록) +- 리스크/오픈 질문: [# 4. 리스크 및 제약](#4-리스크-및-제약) + +## 확정 플래그 +- Handoff Decision: {{FREEZE_HANDOFF_DECISION:보류}} +- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:구현 완료 및 로컬 검증 후 Verification으로 인계}} +- Ready for Verification: {{READY_FOR_VERIFICATION:false}} +- Confirmed By: {{CONFIRMED_BY:TBD}} +- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}} + +--- + +# 12. 작성 가이드 +*이 섹션은 작성 참고용이다. 문서 완성 후 삭제해도 된다.* + +- **변경 대상 파일 경로**: 실제 저장소 파일 경로를 명시한다. 추정이나 가상 경로를 쓰지 않는다. +- **완료 조건(DoD)**: "구현 완료"처럼 모호한 표현 대신 "파일 X에 함수 Y가 추가되고 입력 Z에 대해 올바른 결과를 반환한다"처럼 측정 가능하게 작성한다. +- **오픈 질문**: 구현 중 발생한 기술적 판단 사항, 외부 확인 필요 항목 등을 기록한다. +- **Freeze 섹션**: 모든 태스크 완료 및 로컬 검증 후 담당자가 직접 갱신한다. diff --git a/.github/templates/sdlc/5_verification.md b/.github/templates/sdlc/5_verification.md new file mode 100644 index 0000000..be15e8b --- /dev/null +++ b/.github/templates/sdlc/5_verification.md @@ -0,0 +1,160 @@ +# 0. 문서 상태 +이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다. + +- 상태: {{DOC_STATUS:draft|review|confirmed}} +- 문서 ID: {{CYCLE_ID:sdlc-<3자리>__}} +- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}} +- 참조 Implementation: {{IMP_PATH:docs/sdlc//4_implementation.md}} +- 작성 시각(KST): {{CREATED_AT_KST:TBD}} +- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}} + +# 1. Implementation 인계 요약 +Implementation에서 완료된 핵심 내용을 요약한다. 원본은 4_implementation.md를 참조하며, 이 섹션은 Verification 작업의 입력 기준선이 된다. + +## 이슈 목적 +- {{VER_ISSUE_PURPOSE:Implementation 이슈명과 핵심 목적 1-2줄}} + +## 구현 완료 태스크 +| ID | 태스크 제목 | 변경 파일/함수 | 완료 조건(DoD) | +|----|-----------|--------------|--------------| +| T-1 | {{VER_TASK_TITLE_1}} | {{VER_TASK_TARGET_1}} | {{VER_TASK_DOD_1}} | +| T-2 | {{VER_TASK_TITLE_2}} | {{VER_TASK_TARGET_2}} | {{VER_TASK_DOD_2}} | +| T-3 | {{VER_TASK_TITLE_3:필요 없으면 삭제}} | {{VER_TASK_TARGET_3}} | {{VER_TASK_DOD_3}} | + +## 이월된 오픈 질문 / 리스크 +Implementation에서 `Deferred` 처리되어 Verification 단계에서 해소해야 하는 항목을 기록한다. + +- {{VER_DEFERRED_ITEM_1:없으면 "없음"}} +- {{VER_DEFERRED_ITEM_2:필요 없으면 삭제}} + +# 2. 검증 계획 +Discovery `# 7` 성공 기준(S-N)을 기반으로 Verification 항목을 정의한다. + +## 검증 범위 +- {{VER_SCOPE_1:예. 기능 요구사항(FR) 전체 충족 여부}} +- {{VER_SCOPE_2:예. 비기능 요구사항(NFR) 성능 기준 충족 여부}} +- {{VER_SCOPE_3:필요 없으면 삭제}} + +## 검증 항목 +| ID | 검증 항목 | 검증 방법 | 성공 기준 | 담당자 | +|----|---------|---------|---------|--------| +| VC-1 | {{VER_ITEM_1}} | {{VER_METHOD_1:수동\|자동\|혼합}} | {{VER_CRITERIA_1}} | {{VER_OWNER_1:TBD}} | +| VC-2 | {{VER_ITEM_2}} | {{VER_METHOD_2:수동\|자동\|혼합}} | {{VER_CRITERIA_2}} | {{VER_OWNER_2:TBD}} | +| VC-3 | {{VER_ITEM_3:필요 없으면 삭제}} | {{VER_METHOD_3:수동\|자동\|혼합}} | {{VER_CRITERIA_3}} | {{VER_OWNER_3:TBD}} | +| VC-4 | {{VER_ITEM_4:필요 없으면 삭제}} | {{VER_METHOD_4:수동\|자동\|혼합}} | {{VER_CRITERIA_4}} | {{VER_OWNER_4:TBD}} | + +## 성공 기준 연결 +Discovery의 성공 기준(S-N)과 검증 항목(VC-N)의 연결을 명시한다. + +- S-1 → {{VER_S1_LINK:VC-1, VC-2 등}} +- S-2 → {{VER_S2_LINK:VC-3 등}} +- S-3 → {{VER_S3_LINK:필요 없으면 삭제}} + +# 3. 검증 결과 +검증 수행 후 각 항목의 결과를 기록한다. 초안 생성 시 모두 `미완료`로 초기화한다. + +| ID | 검증 항목 | 결과 | 비고 | +|----|---------|------|------| +| VC-1 | {{VER_ITEM_1}} | {{VER_RESULT_1:미완료\|통과\|실패\|블로킹}} | {{VER_RESULT_NOTE_1:필요 없으면 삭제}} | +| VC-2 | {{VER_ITEM_2}} | {{VER_RESULT_2:미완료\|통과\|실패\|블로킹}} | {{VER_RESULT_NOTE_2:필요 없으면 삭제}} | +| VC-3 | {{VER_ITEM_3:필요 없으면 삭제}} | {{VER_RESULT_3:미완료\|통과\|실패\|블로킹}} | {{VER_RESULT_NOTE_3:필요 없으면 삭제}} | + +## 전체 검증 결과 +- 통과: {{VER_PASS_COUNT:0}} / {{VER_TOTAL_COUNT:0}} +- 실패/블로킹: {{VER_FAIL_COUNT:0}} +- 검증 완료 여부: {{VER_COMPLETE:false}} + +# 4. 결함 및 재작업 사항 +검증 중 발견된 결함과 재작업이 필요한 항목을 기록한다. + +- BUG-1: {{BUG_1:없으면 "없음"}} + - 심각도: {{BUG_SEVERITY_1:Critical|High|Medium|Low}} + - 재작업 내용: {{BUG_FIX_1}} + - 상태: {{BUG_STATUS_1:Open|Fixed|Deferred}} +- BUG-2: {{BUG_2:필요 없으면 삭제}} + - 심각도: {{BUG_SEVERITY_2:Critical|High|Medium|Low}} + - 재작업 내용: {{BUG_FIX_2}} + - 상태: {{BUG_STATUS_2:Open|Fixed|Deferred}} + +# 5. 리스크 및 오픈 질문 +Verification 단계에서 새로 식별된 리스크와 오픈 질문을 기록한다. + +## 리스크 +- R-1 ({{VER_RISK_LEVEL_1:High|Medium|Low}}): {{VER_RISK_1}} + - 완화 방안: {{VER_MITIGATION_1}} +- R-2 ({{VER_RISK_LEVEL_2:High|Medium|Low}}): {{VER_RISK_2:필요 없으면 삭제}} + - 완화 방안: {{VER_MITIGATION_2:필요 없으면 삭제}} + +## 오픈 질문 +- OQ-1: {{VER_OPEN_QUESTION_1}} + - 상태: {{VER_OQ_STATUS_1:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{VER_OQ_ACTION_1}} + - 종료 조건: {{VER_OQ_EXIT_1}} +- OQ-2: {{VER_OPEN_QUESTION_2:필요 없으면 삭제}} + - 상태: {{VER_OQ_STATUS_2:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{VER_OQ_ACTION_2}} + - 종료 조건: {{VER_OQ_EXIT_2}} + +# 6. Release로 넘기기 전 확인 체크 +Release 단계로 넘기기 전에 무엇이 완료되어야 하는지 확인한다. + +- [ ] 모든 검증 항목(VC-N) 통과 + - 기준: {{CHECK_ALL_VC:VC 목록의 모든 항목이 "통과" 상태여야 한다}} +- [ ] 결함(BUG) `Open` 상태 없음 + - 기준: {{CHECK_BUGS:BUG 목록에 `Open` 상태 항목이 0개여야 한다. `Deferred`는 근거와 함께 허용}} +- [ ] 성공 기준(S-N) 전체 충족 + - 기준: {{CHECK_SUCCESS_CRITERIA:Discovery에서 정의된 S-N 기준이 모두 VC 항목과 연결되어 통과되었는가}} +- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인 + - 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료 +- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정 + - 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다}} + +# 7. 파일 처리 결과 +이 Verification 문서 생성/갱신 결과와 참조 문서를 기록한다. + +- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}} +- 생성 경로: {{OUTPUT_PATH}} +- 참조 문서: + - {{IMP_PATH:docs/sdlc//4_implementation.md}} + - {{REFERENCE_1:필요 없으면 삭제}} + +# 8. 사용자 결정 필요 항목 요약 +사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. + +## DECIDE +- {{DECIDE_ITEM_1}} +- {{DECIDE_ITEM_2:필요 없으면 삭제}} + +## CONFIRM +- {{CONFIRM_ITEM_1}} +- {{CONFIRM_ITEM_2:필요 없으면 삭제}} + +## DATA +- {{DATA_ITEM_1}} +- {{DATA_ITEM_2:필요 없으면 삭제}} + +# 9. Verification Freeze +Release 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다. + +## 섹션 참조 +- 검증 계획: [# 2. 검증 계획](#2-검증-계획) +- 검증 결과: [# 3. 검증 결과](#3-검증-결과) +- 결함/재작업: [# 4. 결함 및 재작업 사항](#4-결함-및-재작업-사항) + +## 확정 플래그 +- Handoff Decision: {{FREEZE_HANDOFF_DECISION:보류}} +- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:검증 완료 및 결함 없음 확인 후 Release로 인계}} +- Ready for Release: {{READY_FOR_RELEASE:false}} +- Confirmed By: {{CONFIRMED_BY:TBD}} +- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}} + +--- + +# 10. 작성 가이드 +*이 섹션은 작성 참고용이다. 문서 완성 후 삭제해도 된다.* + +- **검증 항목(VC-N)**: Discovery 성공 기준(S-N)과 반드시 연결한다. FR/NFR 각 항목이 하나 이상의 VC와 연결되어야 한다. +- **검증 방법**: 수동(테스터가 직접 실행), 자동(CI/테스트 코드), 혼합(일부 자동 + 수동 확인) 중 선택한다. +- **성공 기준**: "정상 동작"처럼 모호한 표현 대신 "입력 X에 대해 결과 Y를 반환한다"처럼 측정 가능하게 작성한다. +- **결함(BUG)**: 검증 중 발견된 모든 문제를 기록한다. `Deferred` 처리 시 근거와 후속 처리 계획을 명시한다. +- **Freeze 섹션**: 모든 VC 통과 및 BUG `Open` 없음 확인 후 담당자가 직접 갱신한다. diff --git a/.github/templates/sdlc/6_release.md b/.github/templates/sdlc/6_release.md new file mode 100644 index 0000000..2f934be --- /dev/null +++ b/.github/templates/sdlc/6_release.md @@ -0,0 +1,162 @@ +# 0. 문서 상태 +이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다. + +- 상태: {{DOC_STATUS:draft|review|confirmed}} +- 문서 ID: {{CYCLE_ID:sdlc-<3자리>__}} +- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}} +- 참조 Verification: {{VER_PATH:docs/sdlc//5_verification.md}} +- 작성 시각(KST): {{CREATED_AT_KST:TBD}} +- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}} + +# 1. Verification 인계 요약 +Verification에서 완료된 핵심 내용을 요약한다. 원본은 5_verification.md를 참조하며, 이 섹션은 Release 작업의 입력 기준선이 된다. + +## 이슈 목적 +- {{REL_ISSUE_PURPOSE:Verification 이슈명과 핵심 목적 1-2줄}} + +## 검증 결과 요약 +- 검증 항목 수: {{REL_VC_TOTAL}}개 +- 전체 통과 여부: {{REL_VC_ALL_PASS:true|false}} +- 결함(BUG) 잔여: {{REL_BUG_REMAIN:0}}건 + +## 이월된 오픈 질문 / 리스크 +Verification에서 `Deferred` 처리되어 Release 단계에서 해소해야 하는 항목을 기록한다. + +- {{REL_DEFERRED_ITEM_1:없으면 "없음"}} +- {{REL_DEFERRED_ITEM_2:필요 없으면 삭제}} + +# 2. 배포 준비 +배포 환경, 배포 전 체크리스트, 배포 순서를 정의한다. + +## 배포 환경 +- 대상 환경: {{REL_TARGET_ENV:예. production, staging}} +- 배포 방식: {{REL_DEPLOY_METHOD:예. git push, CI/CD 파이프라인, 수동 복사}} +- 배포 도구/채널: {{REL_DEPLOY_TOOL:예. GitHub Actions, 수동 SSH, 없음}} + +## 배포 전 체크리스트 +배포 실행 전에 확인해야 할 항목을 나열한다. + +- [ ] {{REL_PRE_CHECK_1:예. 대상 환경 설정 파일 백업 완료}} +- [ ] {{REL_PRE_CHECK_2:예. 롤백 계획 확인 완료}} +- [ ] {{REL_PRE_CHECK_3:필요 없으면 삭제}} + +## 배포 순서 +변경 사항의 배포 순서를 적는다. 의존 관계가 있는 경우 순서를 명확히 기술한다. + +1. {{REL_STEP_1:예. 설정 파일 배포}} +2. {{REL_STEP_2:예. 코드 변경 배포}} +3. {{REL_STEP_3:필요 없으면 삭제}} + +# 3. 롤백 계획 +배포 후 문제가 발생했을 때 이전 상태로 되돌리는 방법을 기술한다. + +## 롤백 조건 +아래 조건 중 하나라도 충족되면 롤백을 즉시 실행한다. + +- {{REL_ROLLBACK_TRIGGER_1:예. 배포 후 핵심 기능 오류 발생}} +- {{REL_ROLLBACK_TRIGGER_2:예. 성능 지표가 임계값 이하로 하락}} +- {{REL_ROLLBACK_TRIGGER_3:필요 없으면 삭제}} + +## 롤백 절차 +1. {{REL_ROLLBACK_STEP_1:예. 이전 버전 파일/설정 복원}} +2. {{REL_ROLLBACK_STEP_2:예. 배포 채널에서 롤백 실행}} +3. {{REL_ROLLBACK_STEP_3:필요 없으면 삭제}} + +## 롤백 담당자 +- {{REL_ROLLBACK_OWNER:TBD}} + +# 4. 배포 후 확인 +배포 완료 후 정상 동작을 확인하는 방법을 기술한다. + +## 스모크 테스트 항목 +| 항목 | 확인 방법 | 성공 기준 | +|------|---------|---------| +| {{REL_SMOKE_ITEM_1}} | {{REL_SMOKE_METHOD_1}} | {{REL_SMOKE_CRITERIA_1}} | +| {{REL_SMOKE_ITEM_2}} | {{REL_SMOKE_METHOD_2}} | {{REL_SMOKE_CRITERIA_2}} | +| {{REL_SMOKE_ITEM_3:필요 없으면 삭제}} | {{REL_SMOKE_METHOD_3}} | {{REL_SMOKE_CRITERIA_3}} | + +## 모니터링 확인 항목 +배포 후 일정 시간 동안 모니터링해야 하는 지표나 로그를 기록한다. + +- {{REL_MONITOR_1:예. 오류 로그 발생 여부 확인 (1시간)}} +- {{REL_MONITOR_2:필요 없으면 삭제}} + +# 5. 리스크 및 오픈 질문 +Release 단계에서 새로 식별된 리스크와 오픈 질문을 기록한다. + +## 리스크 +- R-1 ({{REL_RISK_LEVEL_1:High|Medium|Low}}): {{REL_RISK_1}} + - 완화 방안: {{REL_MITIGATION_1}} +- R-2 ({{REL_RISK_LEVEL_2:High|Medium|Low}}): {{REL_RISK_2:필요 없으면 삭제}} + - 완화 방안: {{REL_MITIGATION_2:필요 없으면 삭제}} + +## 오픈 질문 +- OQ-1: {{REL_OPEN_QUESTION_1}} + - 상태: {{REL_OQ_STATUS_1:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{REL_OQ_ACTION_1}} + - 종료 조건: {{REL_OQ_EXIT_1}} +- OQ-2: {{REL_OPEN_QUESTION_2:필요 없으면 삭제}} + - 상태: {{REL_OQ_STATUS_2:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{REL_OQ_ACTION_2}} + - 종료 조건: {{REL_OQ_EXIT_2}} + +# 6. Operations로 넘기기 전 확인 체크 +Operations 단계로 넘기기 전에 무엇이 완료되어야 하는지 확인한다. + +- [ ] 배포 완료 및 스모크 테스트 통과 + - 기준: {{CHECK_DEPLOY:배포 절차대로 실행되었고 스모크 테스트 전 항목이 통과되었는가}} +- [ ] 롤백 계획 확정 + - 기준: {{CHECK_ROLLBACK:롤백 조건, 절차, 담당자가 모두 명시되었는가}} +- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인 + - 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료 +- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정 + - 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다}} + +# 7. 파일 처리 결과 +이 Release 문서 생성/갱신 결과와 참조 문서를 기록한다. + +- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}} +- 생성 경로: {{OUTPUT_PATH}} +- 참조 문서: + - {{VER_PATH:docs/sdlc//5_verification.md}} + - {{REFERENCE_1:필요 없으면 삭제}} + +# 8. 사용자 결정 필요 항목 요약 +사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. + +## DECIDE +- {{DECIDE_ITEM_1}} +- {{DECIDE_ITEM_2:필요 없으면 삭제}} + +## CONFIRM +- {{CONFIRM_ITEM_1}} +- {{CONFIRM_ITEM_2:필요 없으면 삭제}} + +## DATA +- {{DATA_ITEM_1}} +- {{DATA_ITEM_2:필요 없으면 삭제}} + +# 9. Release Freeze +Operations 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다. + +## 섹션 참조 +- 배포 준비: [# 2. 배포 준비](#2-배포-준비) +- 롤백 계획: [# 3. 롤백 계획](#3-롤백-계획) +- 배포 후 확인: [# 4. 배포 후 확인](#4-배포-후-확인) + +## 확정 플래그 +- Handoff Decision: {{FREEZE_HANDOFF_DECISION:보류}} +- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:배포 완료 및 스모크 테스트 통과 후 Operations로 인계}} +- Ready for Operations: {{READY_FOR_OPERATIONS:false}} +- Confirmed By: {{CONFIRMED_BY:TBD}} +- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}} + +--- + +# 10. 작성 가이드 +*이 섹션은 작성 참고용이다. 문서 완성 후 삭제해도 된다.* + +- **배포 방식**: git 기반 프로젝트는 커밋 해시, 브랜치, 태그를 명시하면 롤백이 쉽다. +- **롤백 계획**: "문제가 생기면 롤백한다"가 아니라 구체적인 조건, 절차, 담당자를 미리 정의한다. +- **스모크 테스트**: 배포 직후 서비스가 최소한 동작하는지 확인하는 핵심 시나리오만 포함한다. 전체 기능 검증은 Verification 단계에서 완료한 것을 전제로 한다. +- **모니터링**: 배포 후 지켜봐야 하는 지표(오류율, 응답 시간, 로그 패턴 등)를 구체적으로 기록한다. diff --git a/.github/templates/sdlc/7_operation.md b/.github/templates/sdlc/7_operation.md new file mode 100644 index 0000000..8e6478a --- /dev/null +++ b/.github/templates/sdlc/7_operation.md @@ -0,0 +1,154 @@ +# 0. 문서 상태 +이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다. + +- 상태: {{DOC_STATUS:draft|review|confirmed}} +- 문서 ID: {{CYCLE_ID:sdlc-<3자리>__}} +- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}} +- 참조 Release: {{REL_PATH:docs/sdlc//6_release.md}} +- 작성 시각(KST): {{CREATED_AT_KST:TBD}} +- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}} + +# 1. Release 인계 요약 +Release에서 완료된 핵심 내용을 요약한다. 원본은 6_release.md를 참조하며, 이 섹션은 Operations 작업의 입력 기준선이 된다. + +## 이슈 목적 +- {{OPS_ISSUE_PURPOSE:Release 이슈명과 핵심 목적 1-2줄}} + +## 배포 결과 요약 +- 배포 환경: {{OPS_DEPLOY_ENV:예. production}} +- 배포 완료 시각(KST): {{OPS_DEPLOYED_AT:TBD}} +- 스모크 테스트 결과: {{OPS_SMOKE_RESULT:통과|일부 실패|미완료}} + +## 이월된 오픈 질문 / 리스크 +Release에서 `Deferred` 처리되어 Operations 단계에서 해소해야 하는 항목을 기록한다. + +- {{OPS_DEFERRED_ITEM_1:없으면 "없음"}} +- {{OPS_DEFERRED_ITEM_2:필요 없으면 삭제}} + +# 2. 운영 모니터링 +배포 후 지속적으로 모니터링해야 하는 항목과 기준을 정의한다. + +## 모니터링 항목 +| 항목 | 확인 방법 | 임계값 / 이상 기준 | 대응 방안 | +|------|---------|----------------|---------| +| {{OPS_MONITOR_ITEM_1}} | {{OPS_MONITOR_METHOD_1}} | {{OPS_MONITOR_THRESHOLD_1}} | {{OPS_MONITOR_ACTION_1}} | +| {{OPS_MONITOR_ITEM_2}} | {{OPS_MONITOR_METHOD_2}} | {{OPS_MONITOR_THRESHOLD_2}} | {{OPS_MONITOR_ACTION_2}} | +| {{OPS_MONITOR_ITEM_3:필요 없으면 삭제}} | {{OPS_MONITOR_METHOD_3}} | {{OPS_MONITOR_THRESHOLD_3}} | {{OPS_MONITOR_ACTION_3}} | + +## 모니터링 담당자 +- {{OPS_MONITOR_OWNER:TBD}} + +# 3. 운영 절차 (런북) +이 변경 사항과 관련된 운영 중 발생할 수 있는 상황별 대응 절차를 정의한다. + +## 정상 운영 확인 절차 +배포 후 일정 주기로 정상 동작을 확인하는 절차를 기술한다. + +1. {{OPS_ROUTINE_STEP_1:예. 오류 로그 확인 (일 1회)}} +2. {{OPS_ROUTINE_STEP_2:필요 없으면 삭제}} + +## 장애 대응 절차 +이 변경과 관련된 장애가 발생했을 때의 초기 대응 절차를 기술한다. + +1. {{OPS_INCIDENT_STEP_1:예. 오류 로그에서 관련 스택 트레이스 확인}} +2. {{OPS_INCIDENT_STEP_2:예. 롤백 판단 기준 확인 후 롤백 또는 핫픽스 결정}} +3. {{OPS_INCIDENT_STEP_3:필요 없으면 삭제}} + +## 에스컬레이션 경로 +장애 대응 중 에스컬레이션이 필요한 경우 연락 대상을 기록한다. + +- {{OPS_ESCALATION_1:TBD}} + +# 4. 운영 중 발생한 이슈 +운영 중 발견된 이슈를 기록한다. 초안 생성 시 비워 두고 운영 중 갱신한다. + +- {{OPS_ISSUE_1:없음 (운영 중 발견 시 기록)}} + +# 5. 리스크 및 오픈 질문 +Operations 단계에서 새로 식별된 리스크와 오픈 질문을 기록한다. + +## 리스크 +- R-1 ({{OPS_RISK_LEVEL_1:High|Medium|Low}}): {{OPS_RISK_1}} + - 완화 방안: {{OPS_MITIGATION_1}} +- R-2 ({{OPS_RISK_LEVEL_2:High|Medium|Low}}): {{OPS_RISK_2:필요 없으면 삭제}} + - 완화 방안: {{OPS_MITIGATION_2:필요 없으면 삭제}} + +## 오픈 질문 +- OQ-1: {{OPS_OPEN_QUESTION_1}} + - 상태: {{OPS_OQ_STATUS_1:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{OPS_OQ_ACTION_1}} + - 종료 조건: {{OPS_OQ_EXIT_1}} +- OQ-2: {{OPS_OPEN_QUESTION_2:필요 없으면 삭제}} + - 상태: {{OPS_OQ_STATUS_2:Open|Answered|Deferred|Dropped}} + - 처리 방안: {{OPS_OQ_ACTION_2}} + - 종료 조건: {{OPS_OQ_EXIT_2}} + +# 6. 다음 Discovery 환류 +운영 중 발견된 인사이트와 개선 사항을 다음 SDLC Discovery의 입력으로 기록한다. + +- {{OPS_FEEDBACK_1:없으면 "없음"}} +- {{OPS_FEEDBACK_2:필요 없으면 삭제}} +- {{OPS_FEEDBACK_3:필요 없으면 삭제}} + +# 7. 확인 체크 +Operations 문서가 완성되었는지 확인한다. + +- [ ] 모니터링 항목 및 임계값 정의 완료 + - 기준: {{CHECK_MONITORING:모니터링 항목에 임계값과 대응 방안이 명시되어야 한다}} +- [ ] 런북(정상 운영/장애 대응 절차) 정의 완료 + - 기준: {{CHECK_RUNBOOK:운영 중 발생 가능한 상황에 대한 절차가 1단계 이상 있어야 한다}} +- [ ] 에스컬레이션 경로 정의 완료 + - 기준: {{CHECK_ESCALATION:장애 시 연락할 담당자가 명시되어야 한다}} +- [ ] 다음 Discovery 환류 항목 작성 (없으면 "없음" 기재) + - 기준: OPS_FEEDBACK 항목이 "없음"이 아닐 경우 구체적으로 기술되었는가 +- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정 + - 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 담당자가 명시되어야 한다}} + +# 8. 파일 처리 결과 +이 Operations 문서 생성/갱신 결과와 참조 문서를 기록한다. + +- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}} +- 생성 경로: {{OUTPUT_PATH}} +- 참조 문서: + - {{REL_PATH:docs/sdlc//6_release.md}} + - {{REFERENCE_1:필요 없으면 삭제}} + +# 9. 사용자 결정 필요 항목 요약 +사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. + +## DECIDE +- {{DECIDE_ITEM_1}} +- {{DECIDE_ITEM_2:필요 없으면 삭제}} + +## CONFIRM +- {{CONFIRM_ITEM_1}} +- {{CONFIRM_ITEM_2:필요 없으면 삭제}} + +## DATA +- {{DATA_ITEM_1}} +- {{DATA_ITEM_2:필요 없으면 삭제}} + +# 10. Operations Freeze +이 SDLC 주기의 최종 확정 플래그를 기록한다. + +## 섹션 참조 +- 운영 모니터링: [# 2. 운영 모니터링](#2-운영-모니터링) +- 런북: [# 3. 운영 절차 런북](#3-운영-절차-런북) +- 다음 Discovery 환류: [# 6. 다음 Discovery 환류](#6-다음-discovery-환류) + +## 확정 플래그 +- Handoff Decision: {{FREEZE_HANDOFF_DECISION:보류}} +- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:모니터링 안정화 및 런북 완비 후 주기 완료}} +- SDLC 주기 완료: {{SDLC_CYCLE_COMPLETE:false}} +- Confirmed By: {{CONFIRMED_BY:TBD}} +- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}} + +--- + +# 11. 작성 가이드 +*이 섹션은 작성 참고용이다. 문서 완성 후 삭제해도 된다.* + +- **모니터링 항목**: "오류가 없는지 확인"처럼 모호한 기준 대신 "5xx 오류율 1% 이상 시 알림" 같이 수치화된 임계값을 명시한다. +- **런북**: 실제 운영자가 참고할 수 있도록 구체적인 명령, 경로, 연락처를 기록한다. +- **다음 Discovery 환류**: 이 주기에서 발견된 기술 부채, 개선 아이디어, 범위에서 제외된 요구사항 등을 기록한다. 이 항목이 다음 `/new-sdlc` 의 입력이 된다. +- **SDLC 주기 완료**: 모니터링 안정화 기간(배포 후 일정 시간 경과, 이상 없음) 확인 후 `true`로 변경한다. diff --git a/.github/templates/sdlc/index.md b/.github/templates/sdlc/index.md new file mode 100644 index 0000000..fa240da --- /dev/null +++ b/.github/templates/sdlc/index.md @@ -0,0 +1,12 @@ +# {{CYCLE_ID}} + +| 단계 | 문서 | 상태 | +|------|------|------| +| 1. Discovery | [1_discovery.md](./1_discovery.md) | `draft` | +| 2. Planning | [2_planning.md](./2_planning.md) | `-` | +| 3. Design | [3_design.md](./3_design.md) | `-` | +| 4. Implementation | [4_implementation.md](./4_implementation.md) | `-` | +| 5. Verification | [5_verification.md](./5_verification.md) | `-` | +| 6. Release | [6_release.md](./6_release.md) | `-` | +| 7. Operations | [7_operations.md](./7_operations.md) | `-` | +| Summary | [summary.md](./summary.md) | `-` | diff --git a/.github/templates/sdlc/summary.md b/.github/templates/sdlc/summary.md new file mode 100644 index 0000000..ee472ea --- /dev/null +++ b/.github/templates/sdlc/summary.md @@ -0,0 +1,16 @@ +# Summary - {{CYCLE_ID:sdlc-<3자리>__}} + +- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}} +- 상태: {{SUMMARY_STATUS:draft|review|confirmed}} +- 작성 시각(KST): {{CREATED_AT_KST:TBD}} +- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}} + +## 핵심 요약 + +- {{SUMMARY_POINT_1}} +- {{SUMMARY_POINT_2:필요 없으면 삭제}} + +## 단계별 문서 + +- [Discovery](./1_discovery.md) +- [Index](./index.md) diff --git a/.github/templates/verification-note.template.md b/.github/templates/verification-note.template.md deleted file mode 100644 index fd73a54..0000000 --- a/.github/templates/verification-note.template.md +++ /dev/null @@ -1,83 +0,0 @@ -# 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 deleted file mode 100755 index 0268819..0000000 --- a/.github/tools/calc_priority_scores.sh +++ /dev/null @@ -1,56 +0,0 @@ -#!/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}" diff --git a/.gitignore b/.gitignore index dbe9c82..1a676e0 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ -.vscode/ \ No newline at end of file +.vscode/ +temp/ \ No newline at end of file diff --git a/README.md b/README.md index bddfc3d..c50f819 100644 --- a/README.md +++ b/README.md @@ -19,6 +19,9 @@ bash .vendor/stage-pilot/bootstrap/install.sh . # 원격이 등록된 경우(stage-pilot remote 우선 사용) bash .vendor/stage-pilot/bootstrap/update.sh . +# 충돌 파일을 보존하고 싶을 때(덮어쓰기 비활성화) +bash .vendor/stage-pilot/bootstrap/update.sh --no-overwrite . + # 원격 없이 URL로 직접 업데이트 bash .vendor/stage-pilot/bootstrap/update.sh --repo-url https://github.com/genichin/stage-pilot.git . @@ -30,6 +33,24 @@ bash .vendor/stage-pilot/bootstrap/update.sh --skip-install . `.github/prompts/`에 단계별 프롬프트가 정의되어 있으며, Copilot Chat에서 `/프롬프트이름 인자` 형태로 실행한다. +### 빠른 시작 + +처음부터 전체 SDLC 초안 세트를 만들고 싶다면 아래 명령으로 같은 번호의 draft 문서 세트를 한 번에 생성할 수 있다. + +```text +/new-sdlc 결제 실패 알림 정책을 도입한다 +``` + +이 명령은 `dcy/pln/dsn/imp/ver/rel/ops` 문서를 같은 번호로 모두 `draft` 상태로 만든다. 다만 승인 작업은 Discovery부터 순차적으로 진행해야 한다. + +초안 생성 후 순차 검토/승인을 자동 실행하려면 아래 명령을 사용한다. + +```text +/run-sdlc dcy-001 홍길동 +``` + +이 명령은 Discovery부터 Operations까지 순서대로 검토/승인을 시도한다. 이미 승인된 단계는 건너뛰며, 중간 단계에서 승인 불가면 해당 단계에서 멈추고 미충족 항목과 추가 결정사항을 알려준다. + ### 기본 실행 순서 1. Discovery @@ -44,49 +65,69 @@ bash .vendor/stage-pilot/bootstrap/update.sh --skip-install . ```text # Discovery -/discovery-draft 결제 실패 알림 정책을 도입한다 -/discovery-review dcy-001 -/discovery-confirm dcy-001 +/new-sdlc 결제 실패 알림 정책을 도입한다 +/review-discovery sdlc-001 +/confirm-discovery sdlc-001 # Planning -/planning-draft dcy-001 -/planning-review dcy-001 -/planning-confirm pln-001 +/draft-planning sdlc-001 +/review-planning sdlc-001 +/confirm-planning sdlc-001 # Design -/design-draft pln-001 -/design-review dsn-001 -/design-confirm dsn-001 +/draft-design sdlc-001 +/review-design sdlc-001 +/confirm-design sdlc-001 # Implementation -/implementation-draft dsn-001 -/implementation imp-001 I-001, I-002 -/implementation-confirm imp-001 +/draft-implementation sdlc-001 +/run-implementation sdlc-001 +/review-implementation sdlc-001 +/confirm-implementation sdlc-001 # Verification -/verification-draft imp-001 -/verification-review ver-001 -/verification-confirm ver-001 +/draft-verification sdlc-001 +/review-verification sdlc-001 +/confirm-verification sdlc-001 # Release -/release-draft ver-001 -/release-review ver-001 -/release-confirm ver-001 +/draft-release sdlc-001 +/review-release sdlc-001 +/confirm-release sdlc-001 # Operations -/operation-draft rel-001 -/operation-review rel-001 -/operation-confirm rel-001 +/draft-operation sdlc-001 +/review-operation sdlc-001 +/confirm-operation sdlc-001 +/operation-triage 문제: 로그인 후 세션 만료 시 특정 브라우저에서 무한 리다이렉트가 발생한다. 증상: 만료된 세션으로 접근하면 /login 과 /callback 사이를 반복 이동한다. 기대 동작: 세션 만료 시 로그인 페이지로 1회 이동하고 재로그인 안내를 보여야 한다. 영향도: Safari 사용자 일부가 서비스 재진입 불가. 재현 조건: Safari 17, 기존 세션 쿠키 보유, rel-001 배포 이후. 관련 문서: rel-001 ops-001 ``` ### 문서 ID 규칙 -1. Discovery: `dcy-001` -2. Planning: `pln-001` -3. Design: `dsn-001` -4. Implementation: `imp-001` -5. Verification: `ver-001` -6. Release: `rel-001` +모든 단계 문서는 동일한 CYCLE_ID를 공유한다. + +- CYCLE_ID 형식: `sdlc-<3자리>__` (예: `sdlc-001_20260417_stage-pilot`) +- 각 단계 파일: `1_discovery.md` ~ `7_operation.md` + +### 언제 새 Discovery를 만드는가 + +운영 중 문제를 발견했을 때는 먼저 `/operation-triage`로 분류한 뒤 아래 기준으로 판단한다. + +| operation-triage 판정 결과 | 상황 | 새 Discovery 필요 여부 | 권장 처리 | +|---|---|---:|---| +| 구현 문제 | 기존 요구사항/설계/검증 기준은 있었는데 구현이 어긋남, 그리고 관련 문서가 `confirmed` 이후 상태임 | 필요 | corrective change용 Discovery를 새로 만들고 Planning부터 다시 진행 | +| 구현 문제 | 관련 문서가 모두 `draft`이고 기존 범위 안에서 수정 가능 | 불필요 | 기존 Discovery/Design/Implementation/Verification 문서에 흡수 | +| 설계·요구사항 누락 | 기능은 있었지만 예외 시나리오, 비기능 요구, 운영 리스크가 빠짐 | 필요 | 누락 요구를 위한 새 Discovery 생성 | +| 신규 범위 | 기존 SDLC 문서에 실질적으로 없는 기능/정책/요구 | 필요 | 새 Discovery 생성 | +| 운영 보완만 필요 | 코드/요구 변경 없이 모니터링, 런북, 공지, 절차만 보완 | 불필요 | Operations 문서 보강 | +| 판단 보류 | 관련 문서 부족, 근거 상충, 재현 불충분 | 보류 | 정보 보강 후 `/operation-triage` 재실행 | +| Hotfix 필요 | 서비스 중단, 데이터 손실, 보안 영향 등 긴급 대응 우선 | 필요 | Hotfix로 즉시 대응 후 후속 Discovery 생성 및 Postmortem 환류 | + +짧은 판단 기준: + +1. 완료된 SDLC 결과물을 바꾸는 수정이면 새 Discovery를 만든다. +2. 아직 draft 단계 문서 보정이면 기존 문서에 흡수한다. +3. 운영 문서 보완만 하면 되면 새 Discovery는 만들지 않는다. ### 참고 파일 @@ -95,3 +136,5 @@ bash .vendor/stage-pilot/bootstrap/update.sh --skip-install . 3. 프롬프트 정의: `.github/prompts/` 4. 템플릿: `.github/templates/` 5. Operations 템플릿: `.github/templates/operations-note.template.md` +6. 플레이스홀더 가이드: `.github/instructions/placeholder-guide.md` + diff --git a/bootstrap/bootstrap.sh b/bootstrap/bootstrap.sh index c42b43f..7734dfc 100644 --- a/bootstrap/bootstrap.sh +++ b/bootstrap/bootstrap.sh @@ -26,13 +26,7 @@ ensure_host_structure() { ".github/runbooks/services" ".github/scripts" ".github/templates" - "docs/sdlc/discovery" - "docs/sdlc/planning" - "docs/sdlc/design" - "docs/sdlc/implementation" - "docs/sdlc/verification" - "docs/sdlc/release" - "docs/sdlc/operations" + "docs/sdlc" ) for dir in "${dirs[@]}"; do diff --git a/bootstrap/update.sh b/bootstrap/update.sh index 43c0549..b2355eb 100755 --- a/bootstrap/update.sh +++ b/bootstrap/update.sh @@ -13,8 +13,11 @@ Options: (default: https://github.com/genichin/stage-pilot.git) --branch Upstream branch to sync (default: main) --prefix Subtree prefix path (default: .vendor/stage-pilot) + --overwrite Overwrite conflicts during install (same as --policy replace). + (default behavior) + --no-overwrite Preserve host files on conflicts (same as --policy preserve). --policy install.sh conflict policy: replace|preserve|fail - (default: preserve) + (default: replace) --skip-install Only update subtree. Do not run install.sh. -h, --help Show this help message. @@ -45,7 +48,7 @@ REMOTE_NAME="stage-pilot" REPO_URL="https://github.com/genichin/stage-pilot.git" BRANCH="main" PREFIX=".vendor/stage-pilot" -POLICY="preserve" +POLICY="replace" SKIP_INSTALL=0 ARGS=() @@ -74,6 +77,12 @@ while [ "$#" -gt 0 ]; do PREFIX="$2" shift ;; + --overwrite) + POLICY="replace" + ;; + --no-overwrite) + POLICY="preserve" + ;; --policy) [ "$#" -ge 2 ] || fail "--policy requires a value" POLICY="$2" diff --git a/docs/sdlc/index.md b/docs/sdlc/index.md new file mode 100644 index 0000000..6f71d3d --- /dev/null +++ b/docs/sdlc/index.md @@ -0,0 +1,21 @@ +# SDLC 전체 주기 인덱스 + + + +## 주기 목록 + +| ID | 날짜 | 이슈명 | Discovery | 상태 | +|---|---|---|---|---| +| sdlc-001_20260417_stage-pilot | 20260417 | stage-pilot 프로젝트의 사용 설명서 작성 | [Discovery](./sdlc-001_20260417_stage-pilot/1_discovery.md) | draft | + +## 단계별 횡단 조회 + +| 단계 | 문서 목록 | +|---|---| +| Discovery | [sdlc-001_20260417_stage-pilot](./sdlc-001_20260417_stage-pilot/1_discovery.md) | +| Planning | | +| Design | | +| Implementation | | +| Verification | | +| Release | | +| Operations | | \ No newline at end of file diff --git a/docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md b/docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md new file mode 100644 index 0000000..a0aa58a --- /dev/null +++ b/docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md @@ -0,0 +1,202 @@ +# 0. 문서 상태 +이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다. + +- 상태: draft +- 문서 ID: sdlc-001_20260417_stage-pilot +- 이슈명: stage-pilot 프로젝트의 사용 설명서 작성 +- 작성 시각(KST): 2026-04-17 13:45:58 KST +- 마지막 갱신 시각(KST): 2026-04-17 14:12:00 KST + +# 1. 계획 상태 요약 +현재 Discovery가 어떤 배경에서 작성되고 있는지, 연계 문서가 있는지, 지금 시점의 해석이 무엇인지 짧게 요약한다. + +- 연계 문서 현황: + - Planning 점수 파일: 미생성 + - 관련 TODO/메모: 없음 +- 해석: + - stage-pilot 저장소를 처음 도입하거나 업데이트하려는 사용자가 설치, 업데이트, SDLC 프롬프트 사용법을 빠르게 이해할 수 있도록 공식 사용 설명서가 필요하다. + - 이번 Discovery에서는 README 중심의 사용 설명서를 어떤 범위와 수준으로 작성할지 정의하고, 설치 절차와 운영성 정보를 문서 구조에 반영할 기준을 정해야 한다. + +# 2. 요구사항 판정 결과 +이번 요청이 기존 요구사항과 비교해 신규인지, 유사한지, 중복인지 판단하고 그 근거를 남긴다. + +- 판정: 신규 +- 근거 + - 현재 저장소에는 기본 사용방법과 SDLC 프롬프트 요약은 있으나, 프로젝트 전체 사용 설명서를 별도 산출물로 정의한 SDLC 주기나 관련 문서 세트가 존재하지 않는다. + - 요청은 기존 README 보완 수준을 넘어 설치, 업데이트, 프롬프트 사용 흐름을 체계화하는 신규 문서 작업으로 해석하는 것이 합리적이다. + +# 3. 문제점의 요약 +문제의 현재 상태, 기대 상태, 관련 이해관계자, 제약사항을 정리한다. Discovery의 핵심 맥락을 가장 먼저 이해할 수 있어야 한다. + +- 현재 상태 + - README에 최초 등록, 업데이트, SDLC 프롬프트 사용법이 간단히 정리되어 있지만, 사용자의 목표별 진입 경로와 단계별 설명이 충분히 구조화되어 있지 않다. + - 설치 스크립트와 운영 흐름은 존재하지만 어떤 순서로 실행해야 하는지, 어떤 상황에서 어떤 명령을 선택해야 하는지에 대한 사용 설명서가 부족하다. +- 기대 상태 + - 신규 사용자가 저장소 도입부터 업데이트, SDLC 프롬프트 실행까지를 하나의 사용 설명서만 읽고 재현 가능하게 따라갈 수 있어야 한다. + - 사용 설명서의 위치(README 확장 또는 별도 문서)가 확정된 후, 사용자가 해당 위치에서 설치/업데이트 절차와 참고 문서를 빠르게 찾을 수 있어야 한다. +- 이해관계자 + - 문서 작성자(AI agent 또는 프로젝트 유지보수자) + - 저장소를 도입하는 개발자 또는 팀 + - stage-pilot 운영/관리 담당자 +- 제약사항 + - 현재 확인 가능한 근거 문서는 README와 bootstrap 스크립트, 프롬프트/템플릿 구조로 제한되므로 세부 운영 정책은 추후 확인이 필요할 수 있다. + - 사용 설명서는 실제 저장소 구조와 스크립트 동작을 기준으로 작성해야 하며, 존재하지 않는 자동화나 미확인 절차를 단정적으로 문서화하면 안 된다. + +## 주요 사용자 시나리오 +사용자 또는 운영자가 실제로 어떤 상황에서 이 변경을 필요로 하는지 대표 시나리오를 적는다. + +- 신규 팀원이 stage-pilot을 기존 저장소에 연결하고 bootstrap 설치를 적용하기 위해 공식 사용 설명서를 따라 최초 설정을 수행한다. +- 기존 사용자가 stage-pilot subtree를 최신 상태로 갱신하면서 `--no-overwrite`, `--skip-install` 같은 옵션 차이를 확인한다. +- Copilot Chat 사용자가 어떤 프롬프트를 어떤 순서로 실행해야 하는지 이해하기 위해 SDLC 실행 흐름과 예시 명령을 참조한다. + +# 4. 이번에 정의할 변경 +이번 Discovery에서 다루는 핵심 변경 항목을 목록으로 적는다. 기능, 구조, 규칙 변경을 함께 포함해도 된다. + +- stage-pilot의 설치, 업데이트, SDLC 프롬프트 사용 흐름을 설명하는 공식 사용 설명서의 초안 범위를 정의한다. +- 기존 README와 bootstrap 스크립트 기준으로 사용자 관점의 작업 절차와 주요 명령 예시를 문서 구조에 반영한다. +- 향후 Planning에서 문서 위치, 섹션 구성, 검증 방법을 세분화할 수 있도록 문서 산출물과 성공 기준의 기준선을 세운다. + +## 영향 범위 +변경이 미칠 코드/문서/운영 범위를 명시해 Planning에서 추정 누락을 줄인다. + +- 코드 영향: + - 코드 변경 자체는 제한적이거나 없을 가능성이 높지만, 문서 경로를 README에서 연결하거나 프롬프트 안내 문구를 조정하는 변경이 필요할 수 있다. + - bootstrap 스크립트 사용 예시와 실제 옵션 동작의 일치 여부를 확인하기 위한 점검이 필요하다. +- 문서 영향: + - README 또는 별도 사용 설명서 문서가 새로 작성되거나 대폭 보강될 수 있다. + - SDLC 관련 안내 문서와 시작 가이드에서 사용 설명서 링크를 추가해야 할 수 있다. +- 운영 영향: + - 배포/운영 절차 변경은 없으나, 문서가 최신 상태로 유지되도록 이후 업데이트 시 문서 동기화 책임이 필요하다. + - 사용자 문의 대응 시 참조 기준 문서가 새로 생기므로 운영 커뮤니케이션 비용이 줄어들 수 있다. + +# 5. 요구사항 목록 +실제로 구현과 검증으로 이어질 요구사항을 기능/비기능으로 나누어 정리하고, 범위 경계를 명확히 적는다. + +## 기능 요구사항 +- FR-1: 사용 설명서는 stage-pilot의 최초 등록 절차를 리모트 등록, subtree 추가, bootstrap 설치 순서대로 설명해야 한다. +- FR-2: 사용 설명서는 업데이트 절차를 기본 업데이트, 덮어쓰기 방지, 원격 URL 직접 사용, 설치 생략 옵션으로 구분해 설명해야 한다. +- FR-3: 사용 설명서는 Copilot Chat 기반 SDLC 프롬프트의 기본 실행 순서와 대표 명령 예시를 포함해야 한다. +- FR-4: 사용 설명서는 사용자가 추가 참고 문서를 찾을 수 있도록 관련 파일 또는 디렉터리 위치를 명시해야 한다. + +## 비기능 요구사항 +성능, 운영성, 일관성, 자동화 안정성 등 기능 외 요구사항을 적는다. + +- NFR-1: 문서 내용은 현재 저장소에 실제 존재하는 파일, 스크립트, 명령만 기준으로 작성되어야 한다. +- NFR-2: 문서는 신규 사용자가 한 번에 읽을 수 있도록 작업 흐름 중심으로 구조화되어야 하며, 명령 예시는 복사 가능한 형태로 제공되어야 한다. +- NFR-3: README 및 관련 가이드와 용어가 일관되어야 하며, 단계 명칭과 문서 ID 규칙이 서로 충돌하지 않아야 한다. + +## 범위 경계 +이번 반복에서 반드시 포함할 범위와 명시적으로 제외할 범위를 구분한다. + +- In Scope + - stage-pilot 저장소 사용 설명서의 목적, 주요 섹션, 포함할 명령/예시 범위 정의 + - 설치, 업데이트, SDLC 프롬프트 사용 흐름에 대한 초안 수준의 문서 요구사항 정리 +- Out of Scope + - bootstrap 스크립트의 기능 변경 또는 신규 자동화 추가 + - README 외 별도 웹 문서 사이트 구축이나 다국어 번역 지원 (후속 반복에서 검토) + +# 6. 리스크/가정 목록 +불확실성과 전제 조건을 분리해서 적는다. 리스크는 영향과 완화 방안을, 가정은 현재 판단의 전제를 기록한다. + +## 리스크 +- R-1 (Medium): 사용 설명서가 README의 현재 내용만 재서술하고 실제 사용자 질문에 필요한 맥락을 충분히 추가하지 못할 수 있다. + - 완화 방안: Planning 단계에서 사용자 작업 시나리오 기준의 섹션 구조와 예시 수준을 명확히 정의한다. +- R-2 (Medium): 스크립트 옵션이나 프롬프트 예시가 실제 최신 동작과 어긋나면 문서 신뢰도가 떨어질 수 있다. + - 완화 방안: 문서 작성 전에 bootstrap 스크립트와 프롬프트 정의 파일을 대조해 명령과 옵션을 검증한다. +- R-3 (Low): 문서 위치가 README 확장인지 별도 가이드 문서인지 결정되지 않으면 이후 링크 구조가 바뀔 수 있다. + - 완화 방안: 사용자 결정 필요 항목으로 위치 정책을 확인하고, 확정 전까지는 문서 산출물 형태를 초안 수준으로 유지한다. + +## 가정 +아직 확정되지 않았지만 현재 문서 작성의 기반이 되는 전제를 적는다. + +- A-1: 이번 작업의 1차 산출물은 개발자 중심의 사용 설명서이며, 운영자/리뷰어 안내까지 포함하는 범위는 Planning 이후 반복에서 검토한다. +- A-2: 설치 및 업데이트 절차의 정본은 현재 README와 bootstrap 스크립트이며, 사용 설명서는 이를 재구성해 설명하는 형태가 된다. +- A-3: 문서 초안은 우선 한국어 기준으로 작성해도 무방하며, 영문 병행 여부는 후속 결정 사항이다. + +## 오픈 질문 +답을 아직 모르는 항목을 적는다. 추정으로 덮지 말고 Planning 이전에 확인할 질문으로 남긴다. + +- OQ-1: 사용 설명서를 README 확장으로 작성할지, 별도 문서 파일로 분리할지 최종 산출물 위치를 어디로 할 것인가? + - 상태: Open + - 처리 방안: 사용자 또는 승인자가 문서 배치 정책을 결정한다. + - 종료 조건: Planning 시작 전 최종 산출물 경로가 확정된다. +- OQ-2: 사용 설명서에 포함할 대상 독자 범위를 개발자 전용으로 제한할지, 운영자/리뷰어 안내까지 포함할지 확정할 필요가 있는가? + - 상태: Open + - 처리 방안: 사용자와 범위 경계를 확인해 In Scope를 확정한다. + - 종료 조건: 대상 독자와 제외 범위가 승인된다. + +### 오픈 질문 처리 기준 +- `Open`: 아직 답이 없고 다음 단계 진행에 영향이 있는 상태다. 문서에 유지한다. +- `Answered`: 답이 확정된 상태다. 관련 본문/요구사항에 반영한 뒤 오픈 질문 목록에서는 제거하거나 resolved 기록으로 이동한다. +- `Deferred`: 지금 단계에서 결정하지 않고 다음 단계 또는 후속 이슈로 넘기는 상태다. 넘길 대상과 이유를 반드시 적는다. +- `Dropped`: 더 이상 유효하지 않은 질문이다. 삭제 사유를 짧게 남기고 목록에서 제거한다. +- 처리 원칙 1: 질문만 남기지 말고 반드시 `상태`, `처리 방안`, `종료 조건`을 함께 적는다. +- 처리 원칙 2: 답이 나온 질문은 본문 반영 없이 단순 삭제하지 않는다. 반영 위치를 먼저 갱신한다. +- 처리 원칙 3: High 영향 질문은 `Deferred` 처리 후 처리 방안에 Planning 인계 추적 방식을 명시한다. + +# 7. 초기 성공 기준 +이 변경이 성공했다고 판단할 기준을 측정 가능하게 정의한다. 가능하면 데이터 출처까지 연결한다. + +- S-1: 사용 설명서 초안에 최초 등록, 업데이트, SDLC 프롬프트 사용 흐름이 모두 포함되어 있다. +- S-2: 사용 설명서 초안의 각 주요 절차에 대해 사용자가 실행 가능한 명령 예시 또는 참조 경로를 확인할 수 있다. +- S-3: 문서 검토 시 실제 저장소 구조와 맞지 않는 경로 또는 존재하지 않는 명령이 발견되지 않는다. + +## 측정 방식 및 데이터 출처 +각 성공 기준을 어떻게 측정할지와 어떤 데이터나 문서를 근거로 쓸지 적는다. + +- S-1 측정 방식: 문서 섹션 체크리스트로 포함 여부 검토 / 데이터 출처: README, bootstrap 스크립트, 프롬프트 정의 파일 +- S-2 측정 방식: 절차별 예시 명령과 링크 존재 여부 수동 검토 / 데이터 출처: 사용 설명서 초안, README +- S-3 측정 방식: 경로/명령 대조 검토 또는 샘플 실행 검토 / 데이터 출처: 저장소 파일 구조, bootstrap/*.sh, .github/prompts/ + +# 8. Planning으로 넘기기 전 확인 체크 +Planning 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다. 미완료 항목은 후속 결정이 필요함을 뜻한다. + +- [ ] 범위(In Scope/Out of Scope) 확정 + - 기준: 최종 독자와 포함 대상 문서 범위가 승인되어야 한다. +- [ ] 성공 지표의 측정 방식/데이터 출처 확정 + - 기준: 샘플 실행 여부와 문서 검토 체크리스트의 적용 방법이 정리되어야 한다. +- [ ] High 영향 리스크 우선순위 및 해소 책임자 지정 + - 기준: 문서 정확성 검증 책임자 또는 검토 방식이 지정되어야 한다. +- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인 + - 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료 +- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정 + - 기준: 문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다. + +# 9. 파일 처리 결과 +이 Discovery 문서 생성/갱신 결과와 참조 문서를 기록한다. 이후 추적과 리뷰 시 근거로 사용한다. + +- 처리 결과: 생성 +- 생성 경로: docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md +- 참조 문서: + - README.md + - 없음 + +# 10. 사용자 결정 필요 항목 요약 +사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. 결정, 확인, 데이터 요청을 구분해서 적는다. + +## DECIDE +- 사용 설명서 최종 산출물을 README 확장으로 할지, 별도 문서 파일로 분리할지 결정 + +## CONFIRM +- 대상 독자 범위를 개발자 전용으로 한정할지, 운영자/리뷰어 역할까지 포함할지 확인 +- 승인 및 Freeze 확정 책임자 지정 (섹션 11의 CONFIRMED_BY에 입력) + +## DATA +- 성공 기준 #S-3 검증 시 샘플 실행 환경 및 검증 기록 방식 확인 + +# 11. Discovery Freeze +Planning 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다. + +## 섹션 참조 +- 범위: [# 5. 요구사항 목록 > 범위 경계](#5-요구사항-목록) +- 리스크/오픈 질문: [# 6. 리스크/가정 목록](#6-리스크가정-목록) +- 성공 기준: [# 7. 초기 성공 기준](#7-초기-성공-기준) +- 인계 전 확인: [# 8. Planning으로 넘기기 전 확인 체크](#8-planning으로-넘기기-전-확인-체크) +- 사용자 결정 필요: [# 10. 사용자 결정 필요 항목 요약](#10-사용자-결정-필요-항목-요약) + +## Freeze 플래그 +- Handoff Decision: 보류 +- Handoff Rationale: 초기 Discovery 초안 생성 완료, Planning 인계 전 사용자 확인 필요 +- Ready for Planning: false +- Confirmed By: TBD +- Confirmed At (KST): TBD \ No newline at end of file diff --git a/docs/sdlc/sdlc-001_20260417_stage-pilot/index.md b/docs/sdlc/sdlc-001_20260417_stage-pilot/index.md new file mode 100644 index 0000000..70379e4 --- /dev/null +++ b/docs/sdlc/sdlc-001_20260417_stage-pilot/index.md @@ -0,0 +1,12 @@ +# sdlc-001_20260417_stage-pilot + +| 단계 | 문서 | 상태 | +|------|------|------| +| 1. Discovery | [1_discovery.md](./1_discovery.md) | `draft` | +| 2. Planning | [2_planning.md](./2_planning.md) | `-` | +| 3. Design | [3_design.md](./3_design.md) | `-` | +| 4. Implementation | [4_implementation.md](./4_implementation.md) | `-` | +| 5. Verification | [5_verification.md](./5_verification.md) | `-` | +| 6. Release | [6_release.md](./6_release.md) | `-` | +| 7. Operations | [7_operations.md](./7_operations.md) | `-` | +| Summary | [summary.md](./summary.md) | `-` | \ No newline at end of file diff --git a/docs/sdlc/sdlc-001_20260417_stage-pilot/summary.md b/docs/sdlc/sdlc-001_20260417_stage-pilot/summary.md new file mode 100644 index 0000000..6c9619d --- /dev/null +++ b/docs/sdlc/sdlc-001_20260417_stage-pilot/summary.md @@ -0,0 +1,14 @@ +# Summary - sdlc-001_20260417_stage-pilot + +- 이슈명: stage-pilot 프로젝트의 사용 설명서 작성 +- 상태: draft +- 작성 시각(KST): 2026-04-17 13:45:58 KST +- 마지막 갱신 시각(KST): 2026-04-17 13:45:58 KST + +## 핵심 요약 +- stage-pilot의 설치, 업데이트, SDLC 프롬프트 흐름을 설명하는 사용 설명서 작성 필요성이 Discovery 초안으로 정리되었다. +- 최종 문서 위치와 대상 독자 범위는 사용자 확인이 필요해 Planning 인계 전 결정이 남아 있다. + +## 단계별 문서 +- [Discovery](./1_discovery.md) +- [Index](./index.md) \ No newline at end of file