draft

2026-04-14 22:06:39 +09:00
parent a776ea3b1d
commit 9caa073658
45 changed files with 0 additions and 2037 deletions
@@ -1,50 +0,0 @@
---
-description: "Use when customizing REQ candidate discovery rules for /reopen-requirement-status command, including keyword dictionary, scoring, tie-breaks, and normalization policy."
-applyTo: ".github/prompts/reopen-requirement-status.prompt.md"
---
-# Reopen Requirement Discovery Guidelines
-
-## 목적
-`/reopen-requirement-status` 입력에 REQ ID가 없을 때, 관련 REQ 후보를 일관된 기준으로 탐색하고 우선순위를 정한다.
-
-## 후보 탐색 우선순위
-1. 계약 키워드 일치
- `API`, `endpoint`, `request`, `response`, `schema`, `field`, `CLI`, `command`, `option`, `UI`, `event`, `config`, `env`, `deploy`, `integration`
-2. 영향 영역 일치
- 입력의 변경 대상 모듈/문서/테스트와 REQ의 `Impacted Area` 교집합
-3. 목적/행동 일치
- 입력의 동사/의도(추가, 제거, 변경, 완화, 강화, 비활성화 등)와 REQ `Intent`/`Requirement`의 의미 유사도
-4. 상태 가중치
- 현재 상태가 `Approved`, `Implemented`, `Deprecated`인 REQ 우선
-
-## 점수 및 신뢰도
- 점수식: `키워드(0-5) + 영향영역(0-3) + 의미유사(0-2) + 상태가중치(0-1)`
- 정렬: 총점 내림차순
- 신뢰도:
-  - `High(7-11)`
-  - `Medium(4-6)`
-  - `Low(0-3)`
-
-## 도메인 키워드 사전 (커스터마이즈 가능)
- Auth & Access: `auth`, `login`, `oauth`, `token`, `permission`, `rbac`, `role`, `scope`
- Billing & Subscription: `billing`, `invoice`, `payment`, `subscription`, `plan`, `quota`, `credit`
- Data & Migration: `schema`, `migration`, `backfill`, `etl`, `import`, `export`, `retention`
- API & Contract: `api`, `endpoint`, `request`, `response`, `versioning`, `webhook`, `payload`
- Runtime & Operations: `deploy`, `rollback`, `release`, `monitoring`, `alert`, `slo`, `incident`
- Configuration: `config`, `env`, `feature flag`, `toggle`, `secret`, `parameter`
- UX & Interface: `ui`, `ux`, `screen`, `form`, `flow`, `command`, `cli`, `option`
- Testing & Quality: `test`, `e2e`, `regression`, `coverage`, `validation`, `acceptance`
-
-## 정규화 규칙
- 사전에 없는 표현이 입력에 등장하면 의미가 유사한 사전 키워드로 1회 정규화해 근거에 표기한다.
- 예: `권한` -> `permission`, `과금` -> `billing`
-
-## 동점 처리
- 동일 점수 후보가 여러 개면 최신 Change Log 항목이 있는 REQ를 우선한다.
- 여전히 동점이면 현재 active 상태(`Approved`/`Implemented`) REQ를 우선한다.
- 추가 동점이면 REQ ID가 작은 항목을 우선한다.
-
-## 출력 권장
- 후보는 최대 5개 제시
- 각 후보에 `REQ ID`, `신뢰도`, `점수`, `근거 키워드`, `영향 영역`을 포함
- 확정 전에는 `Immediate Questions`로 최종 대상 REQ 선택을 먼저 요청
@@ -1,52 +0,0 @@
---
-description: "Use when evaluating whether a new feature or change request requires a new or updated SRS requirement, a technical spec update only, or needs owner decision. Apply before starting requirement drafting."
-applyTo: "docs/SRS/**/*.md"
---
-# Requirement Scope Decision Guidelines
-
-## 목적
-새 기능 요청이나 변경 사항이 들어왔을 때, SRS에 등록해야 하는지(신규 또는 기존 REQ 수정) 아니면 technical spec / implementation note만 업데이트하면 되는지를 먼저 판정한다.
-이 판정을 거침으로써 불필요한 REQ 생성을 방지하고, SRS에 등록돼야 할 변경이 누락되는 것을 예방한다.
-
-## 판정 결과 분류 (4종)
-1. **New SRS requirement needed** — 새 REQ 문서를 작성해야 한다.
-2. **Update existing SRS requirement** — 기존 REQ 문서를 수정해야 한다.
-3. **Technical spec only** — SRS 변경 없이 technical spec / implementation note만 업데이트한다.
-4. **Needs owner decision** — 운영 리스크나 승인 기준이 불명확하여 소유자(Owner) 결정이 필요하다.
-
-## SRS 대상 판정 기준 (다음 중 하나라도 해당하면 SRS)
-
-### 외부 계약 변화
- 사용자 또는 외부 시스템이 관찰하는 계약이 바뀌는 경우
- API / CLI / UI / Event / Data schema / Config / Deployment / Integration 요구사항이 변경되는 경우
-
-### 측정 가능한 Non-Functional 변경
- 성능, 보안, 가용성, 확장성 등 측정 기준이 추가되거나 변경되는 경우
-
-### Acceptance Criteria 및 승인 게이트 필요
- 변경 사항에 대해 명시적 수락 기준과 승인 이력이 필요한 경우
-
-## Technical Spec Only 판정 기준 (다음에 해당하면 SRS 불필요)
- 내부 리팩터링 (외부 계약 변화 없음)
- 라이브러리 교체 (동일한 외부 인터페이스 유지)
- 코드 구조 / 패턴 변경 (기능 동작 동일)
- 외부 계약을 바꾸지 않는 구현 최적화
-
-## Borderline / Needs Owner Decision 판정 기준
- 운영 리스크나 승인 책임이 불명확한 경우
- 제품 의도가 불분명하거나 범위가 애매한 경우
- 위 기준만으로 분류가 확정되지 않는 경우
-
-## New vs. Update 구분 기준
- 동일 기능/계약 범위의 변경 → `Update existing SRS requirement`
- 새 기능/계약/인터페이스의 추가 → `New SRS requirement needed`
- 기존 REQ 검색 시 `docs/SRS/index.md`의 Requirement Register를 먼저 확인한다.
-
-## 판정 출력 형식
-판정 결과는 항상 다음 항목을 포함해야 한다.
-1. **Decision** — 위 4종 중 하나
-2. **Why** — 판정 근거 (구체적으로 어떤 기준에 해당하는지)
-3. **Recommended Type** — SRS 대상인 경우, 해당 requirement type (Interface / Data / Deployment 등)
-4. **Existing REQ candidates** — Update 가능성이 있는 기존 REQ ID 목록 (해당 시)
-5. **Next Action** — 판정 결과에 따른 다음 단계 안내
-6. **Open Questions** — 추가 확인이 필요한 사항 (없으면 `없음`)
@@ -1,53 +0,0 @@
---
-description: "Use when writing or editing SRS documents, requirement files, acceptance criteria, change logs, or impacted area entries under docs/SRS. Ensures requirement quality, traceability, and testable wording."
-applyTo: "docs/SRS/**/*.md"
---
-# SRS Document Guidelines
-
-## Requirement 타입 분류
-
-### 분류 의사결정 규칙 (우선순위 순)
-1. **Installation**: "시스템 설치, 환경 구성, 초기화 절차를 정의하는가?" → YES면 Installation
-   - 예: Docker 이미지 빌드, 데이터베이스 마이그레이션, 사전 조건 설정
-2. **Interface**: "사용자가 직접 조작하거나 실행하는 방식을 정의하는가?" → YES면 Interface
-   - 예: CLI 명령어, API 엔드포인트, 웹 UI 기능, 제어 방식
-3. **Configuration**: "시스템 또는 기능의 설정 옵션, 커스터마이징을 정의하는가?" → YES면 Configuration
-   - 예: 설정 파라미터, 옵션 항목, 환경 변수, 커스터마이징 포인트
-4. **Data**: "데이터 저장, 로드, 구조, 파일 형식, 스키마를 정의하는가?" → YES면 Data
-   - 예: 설정 파일 형식, 데이터베이스 스키마, API 요청/응답 구조
-5. **Exception & Error Handling**: "오류 처리, 예외 복구, 재시도 전략을 중심으로 하는가?" → YES면 Exception & Error Handling
-   - 예: 네트워크 오류 재시도, 데이터 검증 실패 처리, 복구 절차
-6. **Deployment**: "배포 방식, 운영 절차, 배포 환경을 정의하는가?" → YES면 Deployment
-   - 예: 컨테이너 배포, 스택 관리, 운영 가이드
-7. **Documentation**: "문서 작성, 가이드, 매뉴얼, 안내서를 정의하는가?" → YES면 Documentation
-   - 예: 사용자 가이드, API 문서, 운영 매뉴얼, 튜토리얼
-8. **Integration**: "외부 시스템 연동, 플러그인, 확장 기능을 정의하는가?" → YES면 Integration
-   - 예: 3rd party 서비스 연동, 플러그인 인터페이스, 확장 메커니즘
-9. **Migration**: "데이터 이전, 버전 업그레이드, 마이그레이션을 정의하는가?" → YES면 Migration
-   - 예: 데이터 마이그레이션, 버전 호환성, 업그레이드 절차
-10. **Testing**: "테스트 전략, QA 요구사항, 검증 방식을 정의하는가?" → YES면 Testing
-    - 예: 테스트 커버리지, 회귀 테스트, 수락 테스트 기준
-11. **Non-Functional**: 위 모든 경우에 해당하지 않으면 → Non-Functional
-    - 예: 성능 목표, 보안 정책, 확장성, 호환성, 신뢰성 요구사항
-
-**주의**: requirement가 여러 분류에 해당하면 주된 제약 또는 목적에 따라 하나로만 선택한다. 예를 들어:
- "Docker Compose로 배포할 수 있어야 한다" → Deployment
- "배포 시 환경 변수로 설정 가능해야 한다" → Configuration
- "배포 전에 다음 점검 항목을 검증해야 한다" → Testing/Documentation
-
- `docs/SRS/index.md`는 SRS 운영 기준과 Requirement Register를 관리하는 문서로 유지한다.
- `docs/SRS/REQ-XXX_*.md`는 하나의 requirement만 다루고, 다른 requirement 내용을 섞지 않는다. 파일은 Type별 폴더에 저장한다. 예: `docs/SRS/Deployment/REQ-001_docker-compose-release.md`
- 새 requirement 번호의 source of truth는 `docs/SRS/index.md`의 `Next Requirement ID`다.
- requirement 본문에는 최소한 `Status`, `Type`, `Priority`, `Owner`, `Intent`, `Requirement`, `Acceptance Criteria`, `Impacted Area`, `Change Log`가 포함되어야 한다.
- `Acceptance Criteria`는 관찰 가능하고 test 가능한 문장으로 작성한다.
- 모호한 표현("개선한다", "적절히 처리한다", "최적화한다")은 측정 기준 없이 사용하지 않는다.
- requirement를 수정하면 해당 REQ 파일의 `Change Log`도 함께 갱신한다.
- `Impacted Area`는 `Docs`, `Modules`, `Tests`를 모두 검토한 뒤 작성한다. 해당 항목이 없으면 `없음`으로 명시한다.
- implementation issue/PR를 생성하거나 병합할 때는 `docs/SRS/traceability-matrix.md`에서 해당 REQ 행의 `Issue/PR`, `Tests`, `Status`를 갱신한다.
- 새로운 Type으로 requirement를 추가할 때는 `docs/SRS/<Type>/` 폴더 하위에 저장한다. 아직 없는 Type 폴더면 생성한다.
- 새로운 requirement를 추가하면 `docs/SRS/index.md`의 Requirement Register에도 같은 ID를 추가한다.
- 새로운 requirement를 추가하거나 Register가 바뀌면 `docs/SRS/index.md`의 `Next Requirement ID`도 함께 갱신한다.
- `docs/SRS/index.md`의 `Recent Change Log Summary`는 최신 5건만 유지하고 최신 항목을 위에 둔다.
- requirement ID와 파일명 prefix는 일치해야 한다. 예: `REQ-002`는 `docs/SRS/<Type>/REQ-002_<slug>.md`.
- requirement 상태를 `Approved` 또는 `Implemented`로 바꿀 때는 acceptance criteria와 change history가 누락되지 않았는지 먼저 검토한다.
- requirement 상태를 전환할 때는 `docs/SRS/index.md`의 `Status Transition Evidence` 기준을 따른다.