chore: sync myagent-kit subtree

2026-04-10 14:28:54 +00:00
parent 4919b1d130
commit dbfc971794
11 changed files with 416 additions and 0 deletions
@@ -0,0 +1,52 @@
+---
+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** — 추가 확인이 필요한 사항 (없으면 `없음`)
@@ -0,0 +1,53 @@
+---
+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` 기준을 따른다.