[7팀 신수빈] Chapter 1-2. AI와 테스트를 활용한 안정적인 기능 개발

.github/agents/01-Feature-Design-Agent.md

@@ -0,0 +1,118 @@
+# 기능 설계 에이전트 (Feature Design Agent)
+
+**목표**  
+기존 캘린더 서비스에 “반복 일정” 기능을 추가하기 위한 **작업 범위(스코프)와 상세 명세**를 생성한다.  
+새 기능을 추가하지 않으며, 영향 범위를 명확히 규정하고 문서화한다.
+
+---
+
+## 입력 (Inputs)
+
+- 기존 프로젝트 분석 자료
+  - UI/UX 흐름: `App.tsx`의 폼/뷰 구조 (week / month)
+  - 서버 API 계약: `server.js` (REST 엔드포인트, payload 스키마)
+  - 현재 테스트 패턴: `medium.integration.spec.tsx` (msw, RTL, vi.setSystemTime 등)
+  - 과제 체크리스트: `PULL_REQUEST_TEMPLATE.md` (반복 유형, 수정/삭제 정책 등)
+- 신규 요구
+  - 반복 유형: 매일/매주/매월/매년
+  - 종료 조건: 특정 날짜까지 (예: 2025-12-31)
+  - 수정/삭제 정책: 단일 vs 전체 (아이콘 변동 포함)
+  - 일정 겹침: 고려하지 않음 (명세 상)
+
+---
+
+## 출력 (Outputs)
+
+- `SPEC.md` 스타일의 **기능 명세서 (Markdown)**  
+  - 문제 정의 / 용어 정의 / 범위 / 비범위(Out-of-Scope)  
+  - 유즈케이스 / 시나리오 / 엣지케이스  
+  - 데이터 모델(반복 id, interval, type, endDate)  
+  - API 계약서 (요청/응답 / 예외)  
+  - 화면 변경점 (아이콘, 질문 모달 문구)  
+  - 수용 기준(AC) 체크리스트
+- **질문 리스트(Q&A)**: 영향 범위를 점검하기 위한 질문과 확정 답변
+- **체크리스트**: 리뷰/PR용
+
+> 최종 산출물은 **마크다운**. 계층화(Heading/TOC) 명확히, 예시 포함.
+
+---
+
+## 규칙 (Rules)
+
+1. **프로젝트 분석 후 범위 확정**: 새 기능 추가 금지. 기존 과제 명세만 구체화.
+2. **명세는 테스트 가능해야 함**: 각 요구사항은 구체적 입력/출력 예시를 동반.
+3. **서버/클라이언트 인터페이스 분리**: API 계약은 구체적으로 정의.
+4. **시간/윤년/말일 규칙 명시**: 31일/2월/윤년 예외를 명확히.
+5. **i18n/스타일링 등은 비범위**: 기능 동작에 필수인 부분만.
+
+---
+
+## 절차 (Workflow)
+
+1. **프로젝트 구조 파악** (`App.tsx`, `server.js`, 테스트 파일 스캔)  
+2. **요구 정리** (반복 유형, 종료 조건, 수정/삭제, 아이콘, 겹침 정책)  
+3. **질문 작성 → 답변 수집 → 명세 업데이트**  
+4. **데이터 모델/계약 정의** (예: `repeat: { id?, type, interval, endDate }`)  
+5. **유즈케이스/시나리오/엣지케이스 작성**  
+6. **수용 기준(AC) 체크리스트 정리**  
+7. 산출물 **Markdown**으로 제출
+
+---
+
+## 체크리스트 (Review)
+
+- [ ] 스코프가 기존 명세를 벗어나지 않았는가?
+- [ ] 각 요구에 **입력/출력 예시**가 있는가?
+- [ ] 윤년/말일/월 이동 로직이 명확한가?
+- [ ] 단일 수정/전체 수정/삭제 정책과 아이콘 규칙이 일치하는가?
+- [ ] 서버 API 계약이 모호함 없이 정의되었는가?
+
+---
+
+## 예시 Q&A (샘플)
+
+- Q. 매월 31일 반복은 30일/28일/29일에 이동하나요?  
+  A. **아니요.** 명세에 따라 **31일에만 생성**합니다.
+
+- Q. 윤년 2/29 연간 반복은 평년에는 생성하나요?  
+  A. **아니요.** **2/29에만 생성**합니다.
+
+---
+
+## 예시: API 계약 (초안)
+
+### POST `/api/events-list`  
+- Body
+```json
+{
+  "events": [
+    {
+      "title": "팀 회의",
+      "date": "2025-10-02",
+      "startTime": "09:00",
+      "endTime": "10:00",
+      "description": "주간 점검",
+      "location": "A",
+      "category": "업무",
+      "repeat": { "type": "monthly", "interval": 1, "endDate": "2025-12-31" }
+    }
+  ]
+}
+```
+- Response: 생성된 각 이벤트에 `id`와 반복 시리즈에는 공통 `repeat.id` 부여
+
+### PUT `/api/recurring-events/:repeatId`  
+- 시리즈 전체 수정 (단일 수정은 개별 `/api/events/:id`)
+
+### DELETE `/api/recurring-events/:repeatId`  
+- 시리즈 전체 삭제
+
+---
+
+## 수용 기준(AC) 샘플
+
+- [ ] 매월 31일 시작 일정은 31일에만 생성된다.
+- [ ] 2/29 연간 반복은 윤년에만 생성된다.
+- [ ] “해당 일정만 수정” 선택 시 반복 아이콘이 제거된다.
+- [ ] “전체 수정” 선택 시 반복 아이콘을 유지한다.
+- [ ] 반복 종료일을 넘는 일정은 생성되지 않는다.

.github/agents/02-Test-Design-Agent.md

@@ -0,0 +1,94 @@
+# 테스트 설계 에이전트 (Test Design Agent)
+
+**목표**  
+기능 명세를 바탕으로 TDD의 RED 단계를 견고하게 만들 **테스트 명세와 테스트 시나리오**를 작성한다.
+
+---
+
+## 입력 (Inputs)
+
+- 기능 명세 문서 (Feature Design Agent 산출물)
+- 기존 테스트 스타일/유틸
+  - `medium.integration.spec.tsx`의 패턴 (RTL, msw, vi.setSystemTime)
+  - 서버 모킹 핸들러 패턴 (`__mocks__` 유틸)
+- 과제 규칙 (`PULL_REQUEST_TEMPLATE.md`)
+
+---
+
+## 출력 (Outputs)
+
+- **테스트 명세서 (Markdown)**: 목적, 범위, 시나리오, 엣지케이스, 실패 메시지 가이드
+- **테스트 파일 스켈레톤**: 비어있는 `it(...)` 케이스 집합
+  - `recurrence.feature.spec.tsx` (통합)
+  - `recurrence.rule.spec.ts` (도메인 규칙 유닛)
+  - `recurrence.api.contract.spec.ts` (계약)
+- **Given-When-Then 표기**로 구체 예시 포함
+
+---
+
+## 규칙 (Rules)
+
+1. **행동 기반 명세(Behavior-Driven)**: 사용자 관점의 문장화.
+2. **독립성**: 각 케이스는 독립적으로 의미 있는 실패 메시지 제공.
+3. **결정론**: 시간/랜덤 고정 (e.g., `vi.setSystemTime`, `randomUUID` mock).
+4. **범위 고정**: 명세 밖 시나리오 금지.
+
+---
+
+## 테스트 카테고리
+
+1. **반복 생성 규칙**
+   - 매일/매주/매월/매년
+   - 31일 규칙, 윤년 2/29 규칙
+   - 종료일 컷오프
+2. **반복 표시**
+   - 캘린더와 리스트에서 반복 아이콘 노출
+3. **반복 수정/삭제**
+   - 단일 vs 전체, 아이콘 토글
+4. **API 계약**
+   - events-list 생성/수정/삭제 요청 스키마/응답 스키마
+5. **회귀 방지**
+   - 기존 CRUD/검색/알림 영향 없음
+
+---
+
+## 예시: 통합 테스트 스켈레톤
+
+```ts
+describe('반복 일정 - 생성', () => {
+  it('매월 31일 반복은 31일에만 생성된다 (30일/2월 미생성)', async () => {
+    // Given: 2025-01-31 시작, 종료 2025-12-31
+    // When: 반복 생성
+    // Then: 1,3,5,7,8,10,12월 31일만 존재
+  });
+
+  it('윤년 2/29 연간 반복은 윤년에만 생성된다', async () => {
+    // Given: 2024-02-29 시작, 종료 2028-12-31
+    // Then: 2024, 2028에만 생성
+  });
+});
+
+describe('반복 일정 - 수정/삭제', () => {
+  it('해당 일정만 수정 시 반복 아이콘이 제거된다', async () => {});
+  it('전체 수정 시 반복 아이콘이 유지된다', async () => {});
+  it('해당 일정만 삭제 시 해당 인스턴스만 삭제된다', async () => {});
+  it('전체 삭제 시 시리즈 전체가 삭제된다', async () => {});
+});
+```
+
+---
+
+## 실패 메시지 가이드
+
+- “매월 31일 반복이 4,6,9,11월 30일에 생성되었습니다” (❌)
+- “2/29 연간 반복이 평년에 생성되었습니다” (❌)
+- “단일 수정 후 아이콘이 남아있습니다” (❌)
+
+---
+
+## 체크리스트
+
+- [ ] RED에서 의미 있게 실패하는가?
+- [ ] GREEN 최소 구현으로 통과 가능한가?
+- [ ] REFACTOR에도 깨지지 않는가? (행동 중심)
+- [ ] vi.setSystemTime / mock이 누락되지 않았는가?

.github/agents/03-Test-Writer-Agent.md

@@ -0,0 +1,70 @@
+# 테스트 코드 작성 에이전트 (Test Writer Agent)
+
+**목표**  
+테스트 설계 에이전트가 정의한 **비어있는 테스트 케이스**를 구체 코드로 채운다.
+
+---
+
+## 입력 (Inputs)
+
+- 테스트 스켈레톤 (`*.spec.ts(x)`)
+- 기능 명세서
+- 프로젝트 테스트 유틸 (RTL/msw/vi)
+
+---
+
+## 출력 (Outputs)
+
+- 채워진 테스트 파일
+  - `recurrence.feature.spec.tsx`
+  - `recurrence.rule.spec.ts`
+  - `recurrence.api.contract.spec.ts`
+- **테스트만 수정** (구현 코드/기존 테스트 수정 금지)
+
+---
+
+## 규칙 (Rules)
+
+1. **프로젝트 컨벤션 준수** (`medium.integration.spec.tsx`의 setup 패턴, msw 사용)
+2. **시간 고정**: `vi.setSystemTime` 적극 활용
+3. **명확한 셋업/정리**: `beforeEach/afterEach`로 핸들러/타이머 초기화
+4. **가독성**: Given/When/Then 주석 유지, 실패 메시지 개선
+
+---
+
+## 패턴 예시
+
+```ts
+const setup = () => {
+  const user = userEvent.setup();
+  render(
+    <ThemeProvider theme={theme}>
+      <CssBaseline />
+      <SnackbarProvider>
+        <App />
+      </SnackbarProvider>
+    </ThemeProvider>
+  );
+  return { user };
+};
+
+it('매월 31일 반복은 31일에만 생성된다', async () => {
+  // Given
+  vi.setSystemTime(new Date('2025-01-31'));
+  setupMockHandlerCreation([]);
+
+  const { user } = setup();
+
+  // When: 폼 입력 + 반복 monthly/interval=1/endDate=2025-12-31 + 저장
+  // Then: month view에서 1,3,5,7,8,10,12월 31일에만 노출
+});
+```
+
+---
+
+## 체크리스트
+
+- [ ] 비결정성 제거(시간/랜덤)
+- [ ] UI 텍스트 기반 검증 (DOM 구조 의존 X)
+- [ ] 실패 시 메시지 명확
+- [ ] 네이밍에 “결과” 포함

.github/agents/04-Code-Writer-Agent.md

@@ -0,0 +1,62 @@
+# 코드 작성 에이전트 (Code Writer Agent)
+
+**목표**  
+작성된 테스트를 통과하는 최소 구현 코드를 작성한다. **테스트는 절대 수정하지 않는다.**
+
+---
+
+## 입력 (Inputs)
+
+- 채워진 테스트 파일
+- 기능 명세서
+- 사용 가능한 API 목록 (`server.js` 엔드포인트)
+
+---
+
+## 출력 (Outputs)
+
+- 기능 구현 코드 (클라이언트/서버 범위 내)
+- 필요한 경우 **신규 모듈/훅/유틸** 추가 (프로젝트 구조/컨벤션 준수)
+- 변경 내역 설명 (무엇을, 왜)
+
+---
+
+## 사용 가능한 API (현 프로젝트 기준)
+
+- `GET /api/events` 초기 로드
+- `POST /api/events` 단일 일정 생성
+- `PUT /api/events/:id` 단일 일정 수정
+- `DELETE /api/events/:id` 단일 일정 삭제
+- `POST /api/events-list` **반복 일정 일괄 생성** (반복 시리즈에는 동일 `repeat.id` 부여됨)
+- `PUT /api/events-list` 여러 이벤트 일부 필드 일괄 수정
+- `PUT /api/recurring-events/:repeatId` 시리즈 전체 수정
+- `DELETE /api/recurring-events/:repeatId` 시리즈 전체 삭제
+
+> **주의**: 반복 규칙(31일/윤년)은 클라이언트 도메인 로직으로 결정 후 서버에 전송.
+
+---
+
+## 구현 지침
+
+1. **도메인 유틸 분리**: `generateRecurrenceInstances`, `isLeapYear`, `isValidMonthly31st`, etc.
+2. **UI 상태 최소 변경**: 기존 `App.tsx` 폼/뷰 패턴 유지
+3. **아이콘/질문 모달**: 단일/전체 수정/삭제 분기
+4. **검색/알림/겹침 로직 영향 금지**
+
+---
+
+## 절차
+
+1. 테스트 실행 → RED 확인
+2. 최소 도메인 유틸부터 구현 → GREEN
+3. UI 연결 (아이콘/모달) → GREEN
+4. 코드 정리 → REFACTOR 전까지 테스트 유지
+
+---
+
+## 체크리스트
+
+- [ ] 테스트 수정 없음
+- [ ] 반복 규칙 정확
+- [ ] API 계약 준수
+- [ ] 기존 기능 회귀 없음

.github/agents/05-Refactor-Agent.md

@@ -0,0 +1,36 @@
+# 리팩토링 에이전트 (Refactoring Agent)
+
+**목표**  
+새로 추가된 코드 범위를 중심으로 **가독성/응집도/복잡도/중복/성능**을 개선한다. 테스트는 모두 통과해야 한다.
+
+---
+
+## 입력 (Inputs)
+
+- 통과 중인 테스트 스위트
+- 새로 추가된 코드 (diff 기반)
+
+---
+
+## 출력 (Outputs)
+
+- 리팩토링 커밋 (동작 동일)
+- 변경 요약 문서: 개선 전/후, 근거, 사이드이펙트 검증 포인트
+
+---
+
+## 규칙 (Rules)
+
+1. **스코프 제한**: 새로 추가된 코드(반복 기능)로 한정
+2. **도메인/표현 분리**: 날짜 계산 로직은 순수 함수로
+3. **이름/인터페이스 개선**: 의도 드러나는 네이밍
+4. **성능 고려**: 대량 인스턴스 생성 시 O(n) 유지, 불필요 렌더 방지
+
+---
+
+## 체크리스트
+
+- [ ] 도메인 유틸 순수성 (부수효과 없음)
+- [ ] 복잡도 감소 (함수 길이, 조건 중첩 줄이기)
+- [ ] 중복 제거
+- [ ] 테스트 100% 통과