lee-spec-kit 0.6.32 → 0.6.34
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
# Feature Scope Split Guide (Issue Unit Preserved)
|
|
2
|
+
|
|
3
|
+
Use this guide when one Feature/Issue becomes too large to review safely.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Threshold policy
|
|
8
|
+
|
|
9
|
+
- Split suggestion starts when:
|
|
10
|
+
- `tasks.md` task count is `>= 40`, or
|
|
11
|
+
- `decisions.md` line count is `>= 1200`.
|
|
12
|
+
- Strong 4-way split recommendation when:
|
|
13
|
+
- task count is `>= 80`, or
|
|
14
|
+
- decisions line count is `>= 2500`.
|
|
15
|
+
|
|
16
|
+
Notes:
|
|
17
|
+
|
|
18
|
+
- Keep one issue only for small, tightly coupled work.
|
|
19
|
+
- Preserve "Feature = Issue" by creating multiple linked child issues/features.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## How to decide split boundaries
|
|
24
|
+
|
|
25
|
+
Evaluate each candidate group with these four criteria:
|
|
26
|
+
|
|
27
|
+
1. Coupling
|
|
28
|
+
- Can this group change without forcing edits in the others?
|
|
29
|
+
2. Changed-file overlap
|
|
30
|
+
- Do PRs mostly touch separate files/modules?
|
|
31
|
+
3. Test boundary
|
|
32
|
+
- Can tests be run and reviewed per group?
|
|
33
|
+
4. Deployment independence
|
|
34
|
+
- Can each group merge safely with flags/compatibility guards?
|
|
35
|
+
|
|
36
|
+
Prefer boundaries that maximize independence and minimize rebase conflicts.
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## Required per-issue template
|
|
41
|
+
|
|
42
|
+
For every split issue/feature, fill all fields below:
|
|
43
|
+
|
|
44
|
+
```md
|
|
45
|
+
## Split Issue: <name>
|
|
46
|
+
- Goal:
|
|
47
|
+
- Included Scope:
|
|
48
|
+
- Excluded Scope:
|
|
49
|
+
- Depends On:
|
|
50
|
+
- PR Done Criteria:
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
Minimum quality bar:
|
|
54
|
+
|
|
55
|
+
- `Included Scope` and `Excluded Scope` must be explicit.
|
|
56
|
+
- `Depends On` must list predecessor issue(s) or `None`.
|
|
57
|
+
- `PR Done Criteria` must be checkable in review.
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
## Recommended split shapes
|
|
62
|
+
|
|
63
|
+
- 2-way split (typical for medium-large):
|
|
64
|
+
- Base/refactor lane
|
|
65
|
+
- Product behavior lane
|
|
66
|
+
- 4-way split (typical for very large):
|
|
67
|
+
- Foundation (types/contracts/data)
|
|
68
|
+
- Core flow
|
|
69
|
+
- Edge cases/integrations
|
|
70
|
+
- Cleanup/docs/final hardening
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
## Merge sequencing
|
|
75
|
+
|
|
76
|
+
When dependencies exist, use a linear merge order:
|
|
77
|
+
|
|
78
|
+
1. Merge foundation PR
|
|
79
|
+
2. Rebase/merge core flow PR
|
|
80
|
+
3. Rebase/merge integration PR
|
|
81
|
+
4. Rebase/merge cleanup PR
|
|
82
|
+
|
|
83
|
+
Keep every PR independently reviewable and releasable.
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## Split execution checklist
|
|
88
|
+
|
|
89
|
+
1. Freeze new TODO inflow in the current oversized feature.
|
|
90
|
+
2. Define split boundaries with the 4 criteria.
|
|
91
|
+
3. Create linked child issues/features.
|
|
92
|
+
4. Move TODO tasks to the correct child feature.
|
|
93
|
+
5. Record dependencies and merge order.
|
|
94
|
+
6. Continue implementation per child feature.
|
|
95
|
+
|
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
# Feature 범위 분할 가이드 (Feature = Issue 유지)
|
|
2
|
+
|
|
3
|
+
하나의 Feature/Issue가 리뷰 가능한 범위를 넘었을 때 사용하는 가이드입니다.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 임계값 정책
|
|
8
|
+
|
|
9
|
+
- 분할 제안 시작 기준:
|
|
10
|
+
- `tasks.md` 태스크 수 `>= 40`, 또는
|
|
11
|
+
- `decisions.md` 줄 수 `>= 1200`.
|
|
12
|
+
- 4분할 강한 권장 기준:
|
|
13
|
+
- 태스크 수 `>= 80`, 또는
|
|
14
|
+
- decisions 줄 수 `>= 2500`.
|
|
15
|
+
|
|
16
|
+
주의:
|
|
17
|
+
|
|
18
|
+
- 작은 범위, 강결합 작업은 단일 이슈 유지가 가능합니다.
|
|
19
|
+
- "Feature = Issue" 원칙을 유지하면서 연관 child 이슈/feature를 생성합니다.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## 분할 경계 판단 기준
|
|
24
|
+
|
|
25
|
+
후보 묶음을 아래 4가지로 평가하세요.
|
|
26
|
+
|
|
27
|
+
1. 결합도
|
|
28
|
+
- 다른 묶음 수정 없이 독립 변경 가능한가?
|
|
29
|
+
2. 변경 파일 겹침
|
|
30
|
+
- PR 간 파일/모듈 겹침이 낮은가?
|
|
31
|
+
3. 테스트 경계
|
|
32
|
+
- 묶음 단위로 테스트 실행/검토가 가능한가?
|
|
33
|
+
4. 배포 독립성
|
|
34
|
+
- 플래그/호환성 보호 하에서 순차 머지가 안전한가?
|
|
35
|
+
|
|
36
|
+
독립성이 높고 리베이스 충돌이 적은 경계를 우선합니다.
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## 분할 이슈 필수 템플릿
|
|
41
|
+
|
|
42
|
+
각 분할 이슈/feature마다 아래 항목을 모두 작성하세요.
|
|
43
|
+
|
|
44
|
+
```md
|
|
45
|
+
## 분할 이슈: <name>
|
|
46
|
+
- 목표:
|
|
47
|
+
- 포함 범위:
|
|
48
|
+
- 제외 범위:
|
|
49
|
+
- 선행 의존성:
|
|
50
|
+
- PR 완료 기준:
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
최소 품질 기준:
|
|
54
|
+
|
|
55
|
+
- `포함 범위`/`제외 범위`를 명확히 구분합니다.
|
|
56
|
+
- `선행 의존성`은 선행 이슈 또는 `None`을 명시합니다.
|
|
57
|
+
- `PR 완료 기준`은 리뷰에서 검증 가능해야 합니다.
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
## 권장 분할 형태
|
|
62
|
+
|
|
63
|
+
- 2분할(중대형 기본):
|
|
64
|
+
- 기반 정비(리팩터/계약/토대)
|
|
65
|
+
- 사용자 동작(핵심 기능)
|
|
66
|
+
- 4분할(초대형 기본):
|
|
67
|
+
- Foundation(타입/계약/데이터)
|
|
68
|
+
- Core flow
|
|
69
|
+
- Integration/edge cases
|
|
70
|
+
- Cleanup/docs/final hardening
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
## 머지 순서
|
|
75
|
+
|
|
76
|
+
의존성이 있으면 선형 순서로 머지합니다.
|
|
77
|
+
|
|
78
|
+
1. foundation PR 머지
|
|
79
|
+
2. core flow PR 리베이스 후 머지
|
|
80
|
+
3. integration PR 리베이스 후 머지
|
|
81
|
+
4. cleanup PR 리베이스 후 머지
|
|
82
|
+
|
|
83
|
+
각 PR은 독립 리뷰/릴리스가 가능해야 합니다.
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## 분할 실행 체크리스트
|
|
88
|
+
|
|
89
|
+
1. 현재 과대 feature의 신규 TODO 유입을 잠시 중지합니다.
|
|
90
|
+
2. 4가지 기준으로 분할 경계를 확정합니다.
|
|
91
|
+
3. 연관 child 이슈/feature를 생성합니다.
|
|
92
|
+
4. TODO를 올바른 child feature로 이관합니다.
|
|
93
|
+
5. 의존성/머지 순서를 문서화합니다.
|
|
94
|
+
6. child feature 단위로 구현을 재개합니다.
|
|
95
|
+
|