# ArchToolkit 안정화 워크플로우 (Stability Workflow)

목표: 기능을 더 추가해도 “촘촘히 쌓아올린 것”이 무너지지 않도록, **회귀(Regression) 리스크를 구조적으로 낮추는 운영 규칙**을 둡니다.

## 1) 기준점: `pallet-town`

- `pallet-town` 태그는 “언제든 돌아갈 수 있는 고향”입니다.
- **평소에는 움직이지 않습니다.**
- 충분히 검증된 시점(스모크 테스트 통과 + 실사용 확인)에만, 의도적으로 업데이트합니다.

권장 규칙
- “작업하다 망가졌다” 싶으면 `pallet-town`로 즉시 복귀합니다.
- `pallet-town`을 업데이트할 땐 반드시 **GitHub에도 같이** 반영합니다(태그 푸시).

## 2) 전진기지: `viridian-city`

- `viridian-city`는 “돌아올 수 있는 두 번째 고향(작업 거점)”입니다.
- 새 기능 개발/수정은 기본적으로 `viridian-city`를 기준으로 진행합니다.
- 일정 기간 안정적이라고 판단되면, 그 시점을 스냅샷 태그로 고정합니다(예: `viridian-city-YYYYMMDD-vX.Y.Z`).
- `viridian-city` 자체를 새로 갱신할 때는, 먼저 날짜가 들어간 스냅샷 태그를 찍고(GitHub에 태그 푸시) 바꾸는 것을 권장합니다.
- 큰 회귀가 나면 `pallet-town`으로 돌아가 다시 출발합니다.

## 3) 개발 방식: 작업 브랜치에서만

원칙
- `main`: 배포/안정 브랜치(가능하면 “항상 동작”).
- `work/*`: 실험/수정 브랜치(여기서만 적극 변경).

권장 흐름
1. `viridian-city`를 기준으로 브랜치 생성
2. 작은 단위로 수정(한 번에 한 이슈)
3. 스모크 테스트 통과
4. GitHub에 푸시 + 스냅샷 태그
5. 최종적으로 `main`에 반영

## 4) 커밋 규칙(회귀 방지)

- “리팩터링+기능추가+버그수정”을 한 커밋에 섞지 않습니다.
- 가능한 한 **한 커밋 = 한 이슈**로 쪼갭니다.
- 불안정한 변경(대규모 UI 개편/구조 변경)은 별도 브랜치에서 장기적으로 진행합니다.

## 5) 스냅샷 태그 규칙

- 위험한 변경을 하기 전/후로 스냅샷 태그를 찍어 둡니다.
- 태그 예시: `snapshot-YYYYMMDD-HHMM` 또는 `pallet-town-YYYYMMDD-vX.Y.Z` 또는 `viridian-city-YYYYMMDD-vX.Y.Z`

스냅샷은 “되돌아갈 버튼”입니다. 아끼지 말고 찍는 게 장기적으로 더 빠릅니다.

## 6) 스모크 테스트

자세한 체크리스트는 `SMOKE_TEST.md`를 따릅니다.

