---
name: a10-history-manager
description: >
  This skill should be used when the user asks to "개발 히스토리 알려줘", "1차 개발 맥락 로드해줘",
  "이전에 어떻게 개발했어?", "고객 요구사항 반영 이력 있어?", "2차 개발에서 뭐 바뀌었어?",
  "가온 요구사항 반영 내용 알려줘", "히스토리 기록해줘", "이번 개선 배경 알고 싶어",
  또는 특정 개발 차수나 고객사 요구사항 반영 맥락을 파악하려 할 때.
  개발 단계별 히스토리와 고객 요구사항 반영 이력을 관리하고 로드한다.
version: 0.2.0
---

# 히스토리 관리자 (History Manager)

Amaranth 10 모듈의 개발 히스토리와 고객사 요구사항 반영 이력을 관리하는 방법론.
"왜 이렇게 만들어졌는가"의 맥락을 보존해 개선 작업 시 과거 결정을 참고할 수 있게 한다.

## 히스토리 파일 계층 구조

```
{모듈명}/
└── history/
    ├── _timeline.md              # 전체 개발 타임라인 (항상 참고)
    ├── phase-1.md                # 1차 개발 맥락
    ├── phase-2.md                # 2차 개발 맥락
    ├── phase-N.md                # N차 개발 맥락
    └── requests/                 # 고객사/이슈별 요구사항 반영 이력
        ├── {날짜}-{고객사}-{제목}.md
        └── ...
```

## 각 파일의 역할

### _timeline.md
전체 개발 흐름을 한눈에 파악하는 타임라인. 가장 먼저 참고하는 파일.
- 개발 차수별 시기, 주요 변경사항, 담당자
- 고객사 요구사항 반영 이력 목록 (상세는 requests/ 참고)
- 현재 버전 기준 주요 아키텍처 결정 이력

### phase-N.md
각 개발 차수의 상세 맥락.
- 개발 배경 및 목표
- 주요 변경/추가된 기능 목록
- 아키텍처 결정사항 (왜 그렇게 했는가)
- 당시 기술적 제약사항
- 알려진 기술 부채

### requests/{날짜}-{고객사}-{제목}.md
특정 고객사나 이슈로 인한 기능 개선 이력.
- 요청 배경 및 요구사항 원문
- **반영된 것과 남아 있는 제약을 분리해서 설명** (미반영 사유 포함)
  - 반영된 것: 구현 완료된 항목
  - 남아 있는 제약: 기술적/정책적 이유로 미반영된 항목, 향후 개선 예정
- 영향받은 GNB/LNB
- 반영 버전 및 배포일

## 로드 원칙

**작업 전 참고:** `_timeline.md`로 전체 흐름 파악
**특정 차수 작업 시:** 해당 `phase-N.md` 추가 로드
**고객 요구사항 관련 작업 시:** 해당 `requests/` 파일 추가 로드
**개발계획 관련 시:** 해당 `plans/` 파일 참고
**회의 결정사항 관련 시:** 해당 `meetings/` 파일 참고
**진행 상황 보고 시:** 해당 `reports/` 파일 참고

히스토리는 현재 기능 컨텍스트(GNB/LNB)와 함께 로드할 때 가장 효과적이다.
"이 기능이 왜 이렇게 되어 있는가"를 이해하고 개선 방향을 잡을 수 있다.

## LNB 연결 (Linking to LNBs)

**원칙**: 관련 LNB와 현재 업무에 어떤 의미가 있는지 연결한다.

예시:
```
## 영향받은 LNB
- **상담관리 > 상담 등록**: V1.0에서 추가된 기본 기능 (현재 이 기능에 대한 확장 요청 있음)
- **상담관리 > 상담 분석**: V1.2에서 라이선스 분기 추가 (미반영: 성능 최적화 필요)
- **상담관리 > 상담 리포트**: V2.0에서 신규 추가 예정 (기술 부채: 데이터 수집 방식 확정 필요)
```

## 사용 원칙 (Usage Principles)

히스토리를 읽을 때 아래 원칙을 따른다:

1. **단순 기능 설명이 아니라 "변경 이유"를 찾는다**
   - 피해야 할 것: "필드가 추가되었다"
   - 추구할 것: "고객사 X에서 이 정보가 필요해서 필드를 추가했고, 이로 인해 API 구조를 변경했다"

2. **특정 고객사 요구사항이 있으면 요청 파일을 우선 본다**
   - 요청 배경과 반영 내용을 먼저 파악하면 현재 기능을 이해하는 데 도움된다

3. **설계 결정이 반복 등장하면 타임라인에 상위 요약이 있는지 확인한다**
   - 예: "상태값 정의가 계속 변경되었나?" → `_timeline.md`에서 "상태값 설계 변경사" 찾기

4. **현재 기능 맥락과 함께 읽어야 해석이 정확해진다**
   - `context/{GNB}/{LNB}.md` + `history/phase-N.md` 동시 로드 권장
   - 이렇게 하면 "현재 구현"과 "왜 그렇게 됐는가"를 동시에 이해 가능

## 히스토리 기록 시점

- 개발 차수가 완료될 때 → phase-N.md 작성
- 고객사 요구사항이 반영될 때 → requests/ 파일 작성
- 주요 아키텍처 결정이 날 때 → _timeline.md + phase-N.md 업데이트

`/load-history` 커맨드로 특정 히스토리를 로드하고,
`/update-context` 커맨드에 `--history` 옵션으로 히스토리를 기록한다.


## 마크다운 링크 규칙 (필수)

마크다운 파일 작성·업데이트 시 **모든 경로·파일 참조는 클릭 가능한 상대 링크**로 작성한다.

```markdown
# 나쁜 예 (클릭 불가)
법무관리/tasks/_current.md에서 확인

# 좋은 예 (클릭 가능)
[법무관리/tasks/_current.md](../법무관리/tasks/_current.md)에서 확인
```

- 상대 경로는 현재 파일 위치 기준
- 코드블록 안의 폴더 구조 다이어그램은 예외 (링크 불필요)
- 상세 규칙은 douzone-forge CLAUDE.md의 "마크다운 링크 표기 규칙" 섹션 참조