@sduck/sduck-cli 0.1.1 → 0.1.2

package/sduck-assets/types/fix.md

@@ -1,174 +0,0 @@
-# [fix] {버그 요약 한 줄}
-
-> **작업 타입:** `fix` (Quick Fix)
-> **심각도:** `critical` / `high` / `medium` / `low`
-> **작성자:**
-> **작성일:** YYYY-MM-DD
-> **연관 티켓:**
-
----
-
-## 1. 버그 개요
-
-### 문제 요약
-
-<!-- 한두 문장으로 버그의 핵심을 요약 -->
-
-### 발견 경위
-
-- [ ] 사용자 제보
-- [ ] 모니터링 알림
-- [ ] 코드 리뷰 중 발견
-- [ ] QA 테스트
-- [ ] 기타:
-
-### 발생 빈도
-
-- [ ] 항상 재현됨 (100%)
-- [ ] 간헐적 재현 (약 %)
-- [ ] 특정 조건에서만 재현
-
----
-
-## 2. 재현 방법 (Steps to Reproduce)
-
-**환경 정보**
-| 항목 | 내용 |
-|------|------|
-| 환경 (local / dev / staging / production) | |
-| OS / 브라우저 / 앱 버전 | |
-| 계정 유형 / 권한 | |
-| 관련 데이터 ID / 조건 | |
-
-**재현 단계**
-
-1.
-2.
-3.
-
-**실제 결과 (Actual)**
-
-<!-- 무슨 일이 일어났는지 -->
-
-**기대 결과 (Expected)**
-
-<!-- 원래 어떻게 동작해야 하는지 -->
-
----
-
-## 3. 원인 분석 (Root Cause)
-
-### 원인 파악 현황
-
-- [ ] 원인 특정 완료
-- [ ] 원인 조사 중
-- [ ] 원인 불명
-
-### 원인 요약
-
-<!-- 코드 레벨에서 왜 이 버그가 발생하는지 기술 -->
-
-### 원인 코드 위치
-
-```
-파일: src/...
-함수 / 라인:
-```
-
-### 발생 조건
-
-<!-- 특정 값, 상태, 순서 등 버그를 트리거하는 조건 -->
-
----
-
-## 4. 수정 방안
-
-### 방안 검토
-
-| 방안   | 설명 | 장점 | 단점 |
-| ------ | ---- | ---- | ---- |
-| 방안 A |      |      |      |
-| 방안 B |      |      |      |
-
-### 선택한 방안 및 이유
-
-> **선택:** 방안 \_
->
-> **이유:**
-
-### 변경 파일 목록 (예상)
-
-```
-target_paths:
-  - src/...
-  - tests/...
-```
-
----
-
-## 5. 테스트 계획
-
-### 버그 재현 테스트 (수정 전 실패 확인)
-
-- [ ] 기존 버그 재현 테스트 케이스 작성 완료
-
-### 수정 검증 테스트 (수정 후 통과 확인)
-
-| 테스트 케이스 | 조건           | 예상 결과      |
-| ------------- | -------------- | -------------- |
-|               | 버그 유발 조건 | 정상 동작      |
-|               | 정상 입력      | 기존 동작 유지 |
-|               | 경계값         |                |
-
-### 회귀 테스트
-
-<!-- 이 수정으로 인해 영향받을 수 있는 관련 기능의 테스트 목록 -->
-
-- [ ]
-- [ ]
-
----
-
-## 6. 영향 범위
-
-### 사이드 이펙트 검토
-
-<!-- 이 수정이 다른 기능에 미칠 수 있는 영향 -->
-
-### 데이터 정합성
-
-- [ ] DB 데이터 정정 작업 필요 없음
-- [ ] DB 데이터 정정 작업 필요: _(내용 작성)_
-
----
-
-## 7. 롤백 계획
-
-<!-- 수정 후에도 문제가 지속되거나 새로운 문제 발생 시 대응 방안 -->
-
-- 롤백 방법:
-- 롤백 판단 기준 (임계값 또는 조건):
-
----
-
-## 8. 임시 조치 (Workaround, 해당 시)
-
-<!-- 수정 배포 전까지 사용자 또는 운영팀이 취할 수 있는 임시 방편 -->
-
----
-
-## 9. 재발 방지 대책
-
-<!-- 동일한 유형의 버그가 다시 발생하지 않도록 개선할 점 -->
-
-- [ ] 테스트 케이스 추가
-- [ ] 코드 리뷰 체크리스트 항목 추가
-- [ ] 모니터링 알림 추가
-- [ ] 기타:
-
----
-
-## 10. 참고 자료
-
-- 에러 로그:
-- 관련 이슈 / PR:

package/sduck-assets/types/refactor.md

@@ -1,174 +0,0 @@
-# [refactor] {리팩토링 대상 및 목적}
-
-> **작업 타입:** `refactor` (Refactor)
-> **작성자:**
-> **작성일:** YYYY-MM-DD
-> **연관 티켓:**
-
----
-
-## ⚠️ 리팩토링 불변 조건
-
-> **이 작업은 외부 동작(기능, API 응답, UI)을 변경하지 않는다.**
-> 코드 구조만 개선하며, 비즈니스 로직의 변경은 별도의 `feature` 또는 `fix` 작업으로 분리한다.
-
----
-
-## 1. 배경 및 목적
-
-### 리팩토링이 필요한 이유
-
-<!-- 현재 코드의 어떤 문제(기술 부채, 가독성, 유지보수성, 성능 등)가 있는지 구체적으로 기술 -->
-
-### 기대 효과
-
-- [ ] 가독성 / 이해하기 쉬운 코드
-- [ ] 유지보수성 향상
-- [ ] 중복 코드 제거
-- [ ] 테스트 용이성 향상
-- [ ] 성능 개선 (측정 지표 명시 필요)
-- [ ] 기타:
-
----
-
-## 2. 현재 상태 (As-Is)
-
-### 문제 코드 / 구조
-
-```
-파일: src/...
-```
-
-<!-- 문제가 되는 코드 패턴, 구조, 의존 관계 등을 스케치 또는 설명 -->
-
-### 측정 지표 (개선 전)
-
-| 지표                                | 현재 값 | 목표 값 |
-| ----------------------------------- | ------- | ------- |
-| 순환 복잡도 (Cyclomatic Complexity) |         |         |
-| 중복 코드 라인 수                   |         |         |
-| 함수/클래스 크기                    |         |         |
-| 응답 시간 (해당 시)                 |         |         |
-| 테스트 커버리지                     |         |         |
-
----
-
-## 3. 목표 상태 (To-Be)
-
-### 개선된 구조
-
-```
-파일: src/...
-```
-
-<!-- 리팩토링 후 디렉토리 구조, 클래스 구조, 함수 분리 방향 등을 기술 -->
-
-### 적용할 패턴 / 원칙
-
-- [ ] SOLID 원칙 적용:
-- [ ] 디자인 패턴 적용:
-- [ ] 기타 컨벤션:
-
----
-
-## 4. 리팩토링 범위
-
-### 변경 대상 파일
-
-```
-target_paths:
-  - src/...
-  - tests/...
-```
-
-### 변경하지 않는 범위 (명시적 경계)
-
-```
-blocked_paths:
-  - src/api/routes/    # 외부 API 계약 불변
-  - migrations/        # DB 스키마 불변
-```
-
-### 인터페이스 불변 확인
-
-<!-- 다음 항목들이 변경 전후 동일하게 유지되어야 함을 확인 -->
-
-- [ ] Public API 엔드포인트 및 응답 스펙
-- [ ] 공개 함수 / 메서드 시그니처
-- [ ] DB 스키마 및 마이그레이션
-- [ ] 이벤트 / 메시지 포맷
-
----
-
-## 5. 테스트 전략
-
-> 리팩토링의 안전성은 테스트가 보장한다. 기존 테스트가 통과하는 것이 완료 기준이다.
-
-### 기존 테스트 현황
-
-- 현재 테스트 커버리지:
-- 테스트 통과 여부 (작업 시작 전 확인):
-  - [ ] 모든 기존 테스트 통과 확인됨
-
-### 리팩토링 중 테스트 전략
-
-- [ ] 기존 테스트를 변경하지 않고 통과시키며 리팩토링 진행
-- [ ] 구조 변경에 따라 테스트도 함께 재구성 (이유 명시):
-
-### 보완 테스트
-
-<!-- 기존 테스트 커버리지가 낮아 리팩토링 전 보강이 필요한 경우 -->
-
-- [ ] 추가 테스트 케이스 작성 대상:
-
----
-
-## 6. 단계별 분리 계획
-
-> 리팩토링은 한 번에 모든 것을 바꾸지 않고 작은 단위로 나눠서 진행한다.
-
-| 단계 | 작업 내용 | 검증 방법        |
-| ---- | --------- | ---------------- |
-| 1    |           | 테스트 전부 통과 |
-| 2    |           | 테스트 전부 통과 |
-| 3    |           | 테스트 전부 통과 |
-
----
-
-## 7. 영향 범위 분석
-
-### 의존 모듈 목록
-
-<!-- 리팩토링 대상을 import / 사용하는 다른 모듈 -->
-
-| 모듈 | 영향 내용 | 대응 방안 |
-| ---- | --------- | --------- |
-|      |           |           |
-
-### 회귀 테스트 필요 영역
-
-- [ ]
-
----
-
-## 8. 롤백 계획
-
-- 롤백 방법: Git 스펙 단위 커밋 되돌리기
-- 롤백 기준: 테스트 실패 / 예상치 못한 동작 변경 발생 시
-
----
-
-## 9. 완료 정의 (Definition of Done)
-
-- [ ] 기존 테스트 전체 통과
-- [ ] 신규 추가 테스트(있다면) 통과
-- [ ] 테스트 커버리지 감소 없음
-- [ ] 외부 동작 변경 없음 확인
-- [ ] 코드 리뷰 승인
-- [ ] 측정 지표 목표치 달성
-
----
-
-## 10. 참고 자료
-
--