diff --git "a/\bdocs/requirements.md" "b/\bdocs/requirements.md"
new file mode 100644
index 00000000..ba81fc29
--- /dev/null
+++ "b/\bdocs/requirements.md"
@@ -0,0 +1,154 @@
+# Week 2 Assignment
+
+## Objectives
+
+Through this assignment, we want you to experience the following:
+
+1. Getting familiar with the TDD development cycle
+2. Learning the basics of AI and Agents and applying them to write code
+3. Studying how to instruct AI to write code effectively
+4. Once comfortable with AI usage, building your own Agent
+
+These are the four main objectives. Since unfamiliar concepts are presented consecutively, it might be challenging! But don’t give up—if we work together, you’ll have a fascinating first experience. Let’s go!
+
+Additional requirements for recurring schedules have been added.
+
+> **Our server team went on vacation without implementing recurring schedules!  
+> Instead, they provide create, update, and delete APIs for the list, so the frontend has to handle the logic. 🤬**
+
+## Assignment Specification
+
+- The goal of this assignment is simple! Please write the features below using the TDD cycle. **However, use AI to assist in writing the code!**
+- Add all the following features to the existing app.
+  - The provided specification is the minimum functionality. Please plan more concretely and break down the work into smaller tasks!
+
+```markdown
+1. Select Recurrence Type
+   - When creating or editing a schedule, users can select a recurrence type.
+   - Recurrence types are: Daily, Weekly, Monthly, Yearly
+     - If the 31st is selected for monthly recurrence → create only on the 31st, not on the last day of months with fewer than 31 days.
+     - If February 29th is selected for yearly recurrence → create only on the 29th during leap years!
+   - Recurring schedules do not consider overlapping schedules.
+2. Display Recurring Schedules
+   - In the calendar view, distinguish recurring schedules by adding an icon.
+3. Recurrence End
+   - Allow specifying an end condition for recurrence.
+   - Option: Until a certain date
+     - For this example, generate schedules up to 2025-12-31 as the maximum date.
+4. **Edit Recurring Schedule**
+   1. If the user selects ‘Edit only this occurrence?’ and chooses ‘Yes’, perform a single edit:
+      - Editing a recurring schedule converts it into a single schedule.
+      - The recurring schedule icon disappears.
+   2. If the user selects ‘Edit only this occurrence?’ and chooses ‘No’, perform a full edit:
+      - The recurring schedule remains.
+      - The recurring schedule icon remains.
+5. **Delete Recurring Schedule**
+   1. If the user selects ‘Delete only this occurrence?’ and chooses ‘Yes’, perform a single deletion:
+      1. Delete only that occurrence.
+   2. If the user selects ‘Delete only this occurrence?’ and chooses ‘No’, perform a full deletion:
+      1. Delete all occurrences of the recurring schedule.
+```
+
+## Basic Assignment (EASY)
+
+**Recommended for those less familiar with writing code using AI.**
+
+The goal of the basic assignment is to write tests and code for the features in the specification using the TDD approach with AI assistance.
+
+1. Before starting the assignment, document the rules for writing good tests that you have learned before. Using AI for this is fine. This knowledge will be used later for AI-assisted test code writing.
+2. Write documents that can serve as guidelines for AI tools you use, such as [.cursor/rules](https://docs.cursor.com/en/context/rules) and [copilot-instructions.md](http://copilot-instructions.md), which help AI generate answers.
+
+   If you’re curious about helpful guidelines, sneak a peek at the [awesome-cursorrules](https://github.com/PatrickJS/awesome-cursorrules/tree/main) repository!
+
+3. It’s time to start development feature by feature.  
+   Use AI to generate, review, and commit code through the TDD cycle stages: RED → GREEN → REFACTOR.  
+   Commit after each stage.
+
+Be careful not to develop all features at once, and leave clear commit messages.
+
+For each stage, verify the code yourself and note in your PR any improvements you made to achieve better results.
+
+## Basic Assignment (HARD)
+
+**Recommended for those somewhat familiar with AI-assisted coding.**
+
+The goal of the advanced assignment is to build the workflow introduced in [2-2. Build Your Own AI Test Agent](https://www.notion.so/2-2-AI-2642dc3ef51480e589a8f1946588336c?pvs=21) and automatically implement the features in the specification.
+
+1. Before starting, document the rules for writing good tests you have learned before. Using AI is fine. This knowledge will be used later for AI-assisted test code writing.
+2. Create Agents tailored to the AI tools you use. Build six Agents that operate within the workflow.
+3. Start development feature by feature.  
+   Use an orchestrator Agent to generate, review, and commit code through the TDD cycle stages: RED → GREEN → REFACTOR.  
+   Commit after each stage.
+
+Be careful not to develop all features at once, and leave clear commit messages.
+
+If there are core chat histories from each AI tool, please share them! ([Example](https://github.com/jhlee0409/claude-code-history-viewer/blob/main/README.ko.md))
+
+For each stage, document in your PR the instructions given to the AI Agents to smooth the workflow, verify the code yourself, and note any efforts made to improve results.
+
+## Advanced Assignment
+
+Document your experiences and efforts while working on the assignment!
+
+We have compiled topics worth considering and experiencing through various attempts. Write these carefully and share your feedback with your team.
+
+```jsx
+# Report on Stable Feature Development Using AI and Testing
+
+## Why did you choose the tools you used? Have you researched the characteristics of each tool?
+
+## Was there a difference between AI-assisted feature development based on tests and development without it?
+
+## What additional information (context) did you provide to improve AI responses?
+
+## What efforts did you make to help the AI utilize this context well?
+
+## Were you satisfied with the various results generated? What criteria did you use to evaluate the AI’s responses?
+
+## How did you phrase your questions to get better results? Share your various experiences.
+
+## How did you define the scope of tasks assigned to the AI? Try narrowing and widening the scope and describe the results. Also, share what you consider an appropriate unit of work.
+
+## Were there any good references or phrases you wanted to share with your peers? Feel free to brag.
+
+## Have you thought about what AI is good and bad at? Write about your thoughts on this.
+
+## Finally, share your impressions!
+```
+
+# 3. Evaluation Criteria
+
+### Common Submissions
+
+- [ ] Documented rules for writing good tests
+- [ ] Wrote all tests to implement the specified features and implemented them correctly
+- [ ] Implemented all specified features correctly and verified proper operation
+
+### Basic Assignment (Easy)
+
+- [ ] Additional guidelines written to help AI write code well
+- [ ] Correctly committed work for each TDD stage
+- [ ] Documented efforts to improve AI tool usage in PR
+
+### Basic Assignment (Hard)
+
+- [ ] Agent implementation specification document or code
+- [ ] Correctly committed work for each TDD stage
+- [ ] History or logs demonstrating proper results
+- [ ] Documented efforts to improve AI tool usage in PR
+
+### Advanced Assignment
+
+- [ ] Thoroughly answered all questions
+
+### Others
+
+1. Adherence to TDD process
+   - Did you write tests first and confirm they fail before implementing?
+   - Did you write minimal code to pass tests for each requirement?
+   - Did you perform appropriate refactoring after tests passed?
+2. Test quality
+   - Does each test clearly verify only one behavior or feature?
+   - Do the tests accurately reflect the requirements?
+   - Are tests written for all major features and scenarios (both positive and negative cases)?
+   - Do the tests include boundary and exception cases?
diff --git a/.cursor/agent/committer.md b/.cursor/agent/committer.md
new file mode 100644
index 00000000..c94d5328
--- /dev/null
+++ b/.cursor/agent/committer.md
@@ -0,0 +1,23 @@
+# Committer Agent
+
+Mission: Produce clean, stage-specific commits with clear messages.
+
+Stages:
+
+- RED: `test(red): <behavior>`
+- GREEN: `feat(green): <minimal change>`
+- REFACTOR: `refactor: <improvement>`
+
+Rules:
+
+- Commit only relevant files per stage.
+- Keep messages actionable and scoped to one behavior.
+- 커밋 메시지는 한국어로 작성합니다. (코드 식별자는 영어 유지)
+
+Example Messages:
+
+- `test(red): 매달 31일 규칙은 31일에만 발생한다`
+- `feat(green): 31일 전용 월간 반복 규칙 최소 구현`
+- `test(red): 반복 이벤트에만 반복 아이콘을 표시한다`
+- `feat(green): isRecurring이 true인 이벤트에만 RecurringIcon 렌더`
+- `refactor: 반복 생성 로직 추출 및 네이밍 개선`
diff --git a/.cursor/agent/minimal-implementer.md b/.cursor/agent/minimal-implementer.md
new file mode 100644
index 00000000..86922b20
--- /dev/null
+++ b/.cursor/agent/minimal-implementer.md
@@ -0,0 +1,29 @@
+# Minimal Implementer Agent (English Only)
+
+Mission: Make the smallest code change to pass the failing tests.
+
+Constraints:
+
+- No premature abstractions; change only what the tests require.
+- Preserve formatting and existing indentation.
+- Keep performance/structure changes for the refactor step.
+
+Steps:
+
+1. Read failing test output and the exact assertions.
+2. Implement just enough in `src/` to pass.
+3. If time/clock is needed, accept a clock parameter or use a centralized date utility.
+4. Re-run tests; ensure GREEN with no lints/types broken.
+
+Feature 2 implementation hints (do the minimum only):
+
+- Ensure recurring events carry an explicit `isRecurring` (or equivalent) boolean used by rendering.
+- When an occurrence is edited as a single (detached), mark it to not show the recurring icon (`isRecurring === false` for the detached instance).
+- Likely touch points (keep changes minimal):
+  - `src/components/RecurringIcon.tsx` (pure presentational; render icon only when the flag is true).
+  - `src/hooks/useCalendarView.ts` (surface the flag to the calendar view items).
+  - `src/hooks/useEventOperations.ts` (set/clear flags on edit/delete flows that detach occurrences).
+
+Exit Criteria:
+
+- All new tests pass. No unrelated files changed.
diff --git a/.cursor/agent/orchestrator.md b/.cursor/agent/orchestrator.md
new file mode 100644
index 00000000..0b29d43f
--- /dev/null
+++ b/.cursor/agent/orchestrator.md
@@ -0,0 +1,38 @@
+# Orchestrator Agent
+
+Goal: Drive one full TDD cycle per feature slice using the six-agent workflow.
+
+Inputs:
+
+- Feature target (e.g., "Monthly 31st rule" or "Recurring icon rendering").
+- Specs: `DOCS/recurring-requirements.en.md`
+- Rules: `.cursor/rules/testing-rules.md`, `.cursor/rules/agent-rules.md`
+
+Outputs:
+
+- Clear subtask for Test Author (what to test, scope, boundaries)
+- Handoff notes for Minimal Implementer, Refactorer, Reviewer, Committer
+
+Operating Steps:
+
+1. Select the next smallest verifiable behavior from the spec.
+2. Define acceptance criteria and boundaries (edge cases, negatives).
+3. Dispatch to Test Author with exact file paths and naming.
+4. After RED, dispatch to Minimal Implementer with constraints: minimal change only.
+5. After GREEN, dispatch Reviewer; if clean, dispatch Refactorer; then Reviewer again.
+6. Dispatch Committer with stage and message template.
+
+Feature 2 orchestration checklist (Recurring icon & detach):
+
+- Ensure separate cycles for:
+  - Icon renders for recurring events (integration).
+  - Detached occurrence renders without icon (integration + hook-level logic).
+- Require fixed clock in tests and clear event flags (`isRecurring`, `isDetached`).
+- Point tests to `src/__tests__/medium.integration.spec.tsx` and/or `src/__tests__/hooks/`.
+- 산출물 문서와 커밋 메시지는 한국어로 작성합니다. (코드 식별자는 영어)
+
+Guardrails:
+
+- Do not bundle multiple behaviors in one cycle.
+- Ensure deterministic tests (fake timers / injected clock).
+- Keep each cycle small and independently shippable.
diff --git a/.cursor/agent/refactorer.md b/.cursor/agent/refactorer.md
new file mode 100644
index 00000000..40dfc2cb
--- /dev/null
+++ b/.cursor/agent/refactorer.md
@@ -0,0 +1,21 @@
+# Refactorer Agent
+
+Mission: Improve clarity, structure, and duplication after GREEN without changing behavior.
+
+Targets:
+
+- Extract pure functions for recurrence rules (31st-only, leap-year Feb 29, end-cap) and for series/detach decisions.
+- Improve naming; reduce branching; add small helpers.
+
+Rules:
+
+- Keep all tests GREEN.
+- Avoid changing public APIs unless tests guarantee compatibility.
+- Do not add new features; only structural improvement.
+
+Checklist:
+
+- Remove duplication introduced during minimal implementation.
+- Centralize date handling with deterministic interfaces.
+- Keep files small and functions readable.
+- Deliverables, commit messages, and comments must be written in Korean. (Code identifiers should remain in English)
diff --git a/.cursor/agent/reviewer.md b/.cursor/agent/reviewer.md
new file mode 100644
index 00000000..eae2fb17
--- /dev/null
+++ b/.cursor/agent/reviewer.md
@@ -0,0 +1,26 @@
+# Reviewer Agent
+
+Mission: Guard quality gates (tests, lints, types, style, determinism).
+
+Review Items:
+
+- Tests: one behavior per test; AAA; domain language; edges/negatives included.
+- Determinism: no real-time dependence; fake timers/injected clock used.
+- Code clarity: names, small functions, no dead code, no over-mocking.
+- Spec alignment: matches `DOCS/recurring-requirements.en.md` exactly.
+
+Feature 2 specific checks:
+
+- Integration tests assert icon visibility for recurring events and icon absence for detached single edits.
+- Implementation exposes a clear flag for rendering (e.g., `isRecurring`) and updates it correctly on detach flows.
+- No accidental deduplication or suppression of overlapping occurrences.
+- Verify that test descriptions, comments, deliverables, and commit messages are consistently written in Korean. (Code identifiers should remain in English)
+
+Actions:
+
+- Suggest precise diffs or edits; avoid vague feedback.
+- Block if flaky patterns or scope creep.
+
+Exit Criteria:
+
+- All checks pass; ready for refactor/commit.
diff --git a/.cursor/agent/spec-agent.md b/.cursor/agent/spec-agent.md
new file mode 100644
index 00000000..e83f5558
--- /dev/null
+++ b/.cursor/agent/spec-agent.md
@@ -0,0 +1,25 @@
+# Agent Workflow Overview
+
+This repository uses six agents to implement the recurring features via TDD.
+All agents must follow `.cursor/rules/testing-rules.md` and `DOCS/recurring-requirements.en.md`.
+
+Agents:
+
+1. Orchestrator
+2. Test Author
+3. Minimal Implementer
+4. Refactorer
+5. Reviewer
+6. Committer
+
+High-level flow (per feature slice):
+
+- Orchestrator → Test Author (RED) → Minimal Implementer (GREEN) → Reviewer → Refactorer (REFACTOR) → Reviewer → Committer.
+
+Artifacts and paths:
+
+- Specs: `DOCS/recurring-requirements.en.md`
+- Rules: `.cursor/rules/testing-rules.md`, `.cursor/rules/agent-rules.md`
+- Language: 커밋/주석/테스트 설명/산출물은 한국어, 코드 식별자는 영어
+- Tests: `src/__tests__/`
+- Code: `src/`
diff --git a/.cursor/agent/test-author.md b/.cursor/agent/test-author.md
new file mode 100644
index 00000000..c7bb0b05
--- /dev/null
+++ b/.cursor/agent/test-author.md
@@ -0,0 +1,32 @@
+# Test Author Agent
+
+Mission: Write failing tests that precisely capture the behavior.
+
+Read:
+
+- `DOCS/recurring-requirements.en.md`
+- `.cursor/rules/testing-rules.md`
+
+Deliverables:
+
+- New/updated test files under `src/__tests__/` using AAA and domain language.
+- Clear, one-behavior-per-test with boundaries and negatives.
+
+Checklist:
+
+- Name tests as `should <behavior> when <condition>`.
+- Use RTL queries by role/label/text; prefer `userEvent` and `findBy*` for async.
+- Fix the clock (fake timers or injected Date) for any date-based behavior.
+- Use MSW for networking or function-level mocks for pure units.
+- Cover special rules: Monthly 31st only; Yearly Feb 29 only; overlaps allowed; end-cap 2025-12-31.
+- Test descriptions (it/describe) and comments must be written in Korean. (Code identifiers should remain in English)
+
+Feature 2 specific tests (Recurring icon & detach):
+
+- Integration: in `src/__tests__/medium.integration.spec.tsx`, assert recurring events render a distinct icon/marker.
+- Integration: assert that a detached occurrence (edited as single) renders without the recurring icon.
+- Hook/unit: in `src/__tests__/hooks/medium.useEventOperations.spec.ts` (or a new spec), assert `isRecurring` and `isDetached`/equivalent flags are set correctly during edit/delete flows.
+
+Exit Criteria:
+
+- Tests fail with meaningful errors before implementation begins (RED).
diff --git a/.cursor/rules/agent-rules.md b/.cursor/rules/agent-rules.md
new file mode 100644
index 00000000..90679567
--- /dev/null
+++ b/.cursor/rules/agent-rules.md
@@ -0,0 +1,82 @@
+# Agent Rules for This Project
+
+## Goals
+
+- Deliver features via strict TDD (RED → GREEN → REFACTOR) with small, safe, and deterministic steps.
+- Keep tests fast, readable, and fully deterministic.
+
+## Operating Principles
+
+- Always read `docs/requirements.md` (if present) and `.cursor/rules/testing-rules.md` before writing tests or code. The source of truth for this assignment is `DOCS/recurring-requirements.en.md`.
+- Language policy: 코드 식별자(함수/변수/파일명)는 영어로 작성하고, 커밋/PR/주석/테스트 설명 및 각 단계 산출물 문서는 한국어로 작성합니다.
+- Preserve existing file indentation and formatting; do not reformat unrelated code.
+- Use behavior-driven test names and the AAA pattern.
+- Avoid over-mocking; control time/network/randomness deterministically.
+
+## Change Workflow
+
+1. RED: Add a failing test (unit or integration as appropriate).
+2. GREEN: Make the minimal code change to pass only that test.
+3. REFACTOR: Improve clarity and remove duplication without changing behavior.
+4. Commit after each step using messages:
+   - `test(red): <behavior>`
+   - `feat(green): <minimal change>`
+   - `refactor: <improvement>`
+
+## Testing Conventions
+
+- Use React Testing Library from the user’s perspective (roles/labels/text).
+- Use `userEvent` and `findBy*`/`waitFor` for async flows.
+- Use MSW for network; use fake timers or an injected clock for date/recurrence logic.
+
+## File/Path Rules
+
+- Keep new design docs in `DOCS/` (not in rules folders or configs).
+- Put tests under `src/__tests__/` with clear grouping (unit/hooks/integration).
+
+## Recurring Feature Specifics (Authoritative)
+
+- Monthly on the 31st: generate only on the 31st in months that have it. Do not substitute with the last day.
+- Yearly on Feb 29: generate only in leap years (Feb 29). Do not substitute with Feb 28/Mar 1.
+- Overlaps are allowed by design; never deduplicate or prevent overlaps.
+- Recurring indicator in calendar: show a distinct icon/marker for recurring events only. Detached single events must not show the icon.
+- Recurrence end condition: cap generated occurrences at 2025-12-31 at the latest.
+
+## Feature 2 Focus (Recurring Icon & Detach Behavior)
+
+- Tests must cover both: (a) recurring events render with the icon; (b) a detached single edit of a recurring occurrence renders without the icon.
+- Preferred test locations:
+  - Integration: `src/__tests__/medium.integration.spec.tsx` (calendar rendering and user flows).
+  - Hooks/unit: `src/__tests__/hooks/medium.useEventOperations.spec.ts` or a new spec that validates the `isRecurring`/detach flags.
+- Minimal implementation targets:
+  - `src/components/RecurringIcon.tsx` (render-only component; no business logic).
+  - `src/hooks/useCalendarView.ts` and/or `src/hooks/useEventOperations.ts` to ensure events carry `isRecurring` and a detach mechanism that clears the icon when an occurrence is converted to a single event.
+- Determinism: fix the clock in tests; do not rely on system time.
+
+## Quality Gates
+
+- No flaky tests; total suite must run in seconds locally.
+- Lints and types must be clean after each GREEN and REFACTOR.
+
+## Safety
+
+- Prefer pure functions for recurrence generation and series/detach decisions.
+- Add boundary and negative tests for every rule above.
+
+## Stage Documentation & Traceability
+
+- For each TDD phase (RED, GREEN, REFACTOR), create a markdown doc: `DOCS/feature-<num>-RED.md`, `DOCS/feature-<num>-GREEN.md`, `DOCS/feature-<num>-REFACTOR.md`.
+- 산출물 문서는 한국어로 작성합니다. 목표, 단계, 근거, 변경 파일 경로, 결과를 간결히 기록합니다.
+- 커밋 메시지와 문서 헤더, 스펙 참조는 동일한 번호/용어 체계를 사용합니다.
+- 예시 매핑:
+  - Commit: `test(red): 2. 반복 이벤트에만 아이콘을 표시한다`
+  - Doc: `DOCS/feature-2-RED.md` (관련 스펙: 2 – 캘린더 반복 아이콘)
+
+## Sequential Scope (Unit → Integration)
+
+- Complete unit-level TDD first: RED → GREEN → REFACTOR (unit).
+- Then add integration tests:
+  - RED (integration): failing integration test capturing UI behavior.
+  - GREEN (integration): minimal UI/hook/state wiring to pass.
+  - REFACTOR (integration): role separation/readability/duplication removal.
+- Repeat the same discipline for each feature slice.
diff --git a/.cursor/rules/testing-rules.md b/.cursor/rules/testing-rules.md
new file mode 100644
index 00000000..ef32693c
--- /dev/null
+++ b/.cursor/rules/testing-rules.md
@@ -0,0 +1,183 @@
+# Testing Rules (Good Tests Guide)
+
+This document defines how AI (and humans) should write tests for this project.  
+Follow the TDD loop: **RED → GREEN → REFACTOR**.
+
+---
+
+## 0) Purpose
+
+- Provide a safety net to prevent regressions while evolving features
+- Execute the TDD cycle quickly and reliably
+- Serve as an executable spec that teammates/agents can reproduce and verify
+
+---
+
+## 1) Core Principles
+
+1. **One behavior per test**
+
+   - A single test should verify one user/system behavior and its outcome.
+
+2. **Assert observable outcomes only**
+
+   - Verify externally observable results: DOM changes, return values, call counts, state transitions.
+
+3. **AAA structure (Arrange–Act–Assert)**
+
+   - **Arrange**: set up fixtures/initial state
+   - **Act**: perform the behavior (once)
+   - **Assert**: check the expected outcome
+
+4. **RED first**
+
+   - Start with a meaningful failing test, then pass it with the minimal implementation.
+
+5. **Deterministic & isolated**
+
+   - No order dependence or shared global state between tests.
+   - Fix or mock timers, random, time, and network.
+
+6. **Include boundaries & negatives**
+
+   - Cover min/max/empty/dup/permission failures, etc.
+
+7. **Use domain language**
+   - Prefer domain terms in test names, descriptions, and fixtures so requirements read naturally.
+
+---
+
+## 2) Naming Conventions
+
+- **File**: `<target>.<action>.spec.ts(x)` or `*.spec.ts` per unit
+- **Test title**: `should <behavior/result> when <condition>`
+  - e.g., `should create only on 31st when monthly recurrence is selected`
+
+Structure example:
+
+```ts
+describe('[function or feature name]', () => {
+  it('should [expected behavior] when [situation]', () => {
+    // Arrange–Act–Assert
+  });
+});
+```
+
+## 3) TDD Operations & Commits
+
+1. RED: write a failing unit/integration test and confirm the failure
+2. GREEN: implement the smallest change to pass
+3. REFACTOR: remove duplication and improve clarity (tests stay green)
+4. Commits (separate for each step):
+   • test(red): ...
+   • feat(green): ...
+   • refactor: ...
+
+## 4) Test Levels
+
+    •	Unit: pure functions/hooks/utils; remove external dependencies; fast and precise
+    •	Integration: hook + component + state wiring; represent user flows and requirements
+    •	E2E (optional): key scenarios; for this assignment, integration tests can sufficiently cover flows
+
+## 5) React/Hook Testing Conventions
+
+    •	Use React Testing Library: test from the user’s perspective (roles, labels, text), not implementation details
+    •	Use userEvent for interactions; for async rendering, use findBy*/waitFor
+    •	Test hooks via component wrappers or a custom render utility
+
+## 6) Mocking / Stubs
+
+    •	Treat external systems as test doubles: API/time/random/storage
+    •	Network: use MSW for contract-level mocking; for pure units, allow function-level mocks
+    •	Time: prefer vi.useFakeTimers() or inject a fixed Date.now; fix the reference clock for recurrence logic
+    •	Random/IDs: seed or inject the generator
+    •	Avoid over-mocking: domain logic should be composed “for real” in integration tests
+
+## 7) Fixtures & Data Builders
+
+    •	Prepare minimal inputs; use named builders/helpers to remove duplication
+    •	No shared mutable state across tests; each test should be self-contained
+
+## 8) Assertion Quality
+
+    •	Aim for one clear assertion per test (or a small group for one outcome)
+    •	Negative paths should assert thrown errors/messages explicitly (toThrow, message match)
+    •	Prefer getByRole / getByLabelText / getByText for DOM queries
+
+## 9) Coverage Philosophy
+
+    •	Focus on risk & complexity: branch-heavy code, domain rules, high-regression areas
+    •	Treat coverage as a result, not as the target
+
+## 10) Assignment-Specific Checklist (Recurring Schedules)
+
+    •	Recurrence types: Daily / Weekly / Monthly / Yearly
+    •	Monthly 31st: generate only on the 31st (do not substitute with 30/28/29)
+    •	Yearly Feb 29: generate only in leap years
+    •	Overlaps allowed (do not de-duplicate by design)
+    •	Calendar view: show an icon for recurring events; no icon for single (detached) events
+    •	End condition: stop at the given end date (max: 2025-12-31)
+    •	Edit
+    •	Single occurrence: convert that instance to a single event (remove icon)
+    •	Edit all: keep recurrence (keep icon)
+    •	Delete
+    •	Single occurrence: remove only that instance
+    •	Delete all: remove every occurrence
+
+## 11) Recommended Test Suite (Examples)
+
+Utilities / Domain
+• generateRecurrences
+• Monthly 31st rule
+• Yearly Feb 29 rule (leap years only)
+• Weekly day alignment across month/year boundaries
+• End date clamped at 2025-12-31
+
+Hooks / State
+• Create / edit / delete flows (single vs all)
+• After single edit, icon disappears; after edit all, icon remains
+
+UI Integration
+• Calendar renders recurrence icons distinctly
+• User interactions update view/state correctly
+
+## 12) Quality Gates
+
+    •	Full test run should be fast (seconds) and stable locally
+    •	Flaky tests are not allowed (remove timing races, eliminate time-dependence)
+    •	Every new feature follows RED → GREEN → REFACTOR with commit history
+
+## 13) Commit Message Templates
+
+    •	test(red): monthly 31st occurs only on 31st
+    •	feat(green): implement 31st-only monthly generation
+    •	refactor: extract recurrence generator and clarify names
+
+##14) Example Test Snippet
+
+```ts
+describe('generateRecurrences', () => {
+  it('should create events on Feb 29 only in leap years when yearly', () => {
+    // Arrange
+    const start = new Date('2024-02-29'); // leap year
+    const end = new Date('2030-12-31');
+
+    // Act
+    const events = generateRecurrences({ start, end, type: 'yearly' });
+
+    // Assert
+    const dates = events.map((e) => e.date);
+    expect(dates).toContain('2028-02-29');
+    expect(dates).not.toContain('2025-02-28'); // do NOT substitute
+  });
+});
+```
+
+## 15) AI Writing Notes
+
+When generating tests:
+• Prefer behavioral descriptions over technical internals
+• Add short comments documenting the intent of the test
+• Include edge cases automatically for date/time logic
+• Keep fixtures minimal and meaningful
+• Avoid long, hard-coded datasets unless necessary
diff --git a/DOCS/feature-1-GREEN.md b/DOCS/feature-1-GREEN.md
new file mode 100644
index 00000000..1e69be9e
--- /dev/null
+++ b/DOCS/feature-1-GREEN.md
@@ -0,0 +1,58 @@
+# [GREEN] Feature 1: 반복 유형 선택 - 최소 구현
+
+## 관련 요구사항
+
+- 1. 반복 유형 선택 (recurring type selection)
+  - 31일 선택 시: 매월 31일에만 일정 생성(30/28/29일 대체 금지)
+  - 2/29 선택 시: 윤년 2월 29일에만 일정 생성
+  - 반복 일정은 겹침 허용
+
+## 목적
+
+- RED 단계에서 작성한 실패 테스트를 통과시키기 위한 **최소 구현(GREEN)**을 적용한다.
+
+## 변경 파일
+
+- src/utils/eventUtils.ts
+  - `generateRecurrences(params)` 함수 추가 (최소 기능)
+
+## 구현 요약
+
+- 타입: `monthly`, `yearly`에 한해 RED 테스트를 통과시키는 최소 로직만 구현
+- 월간(monthly)
+  - 시작일이 31일이면 31일이 존재하는 달(1,3,5,7,8,10,12)에만 생성
+  - interval 간격으로 월을 전진함
+- 연간(yearly)
+  - 시작일이 2/29이면 윤년에만 생성(대체 금지)
+  - interval 간격으로 연도를 전진함
+- 종료 범위: `end` 날짜를 초과하지 않도록 생성 제한
+- 겹침 처리: 별도 중복 제거 로직 없음(요구사항에 따라 허용)
+
+## 결정성/범위
+
+- 현재 테스트가 요구하는 최소 규칙(31일, 2/29, 겹침 허용)만 충족
+- 기타 일반 케이스(예: 30일 시작, 주간/일간 등)는 후속 요구/테스트에서 확장
+
+## 한계 및 리팩토링 후보(차후 REFACTOR 단계)
+
+- 규칙 분리: 31일 규칙, 윤년 규칙 등 순수 함수 추출
+- 인터페이스 개선: clock 주입/최대 종료일(2025-12-31) 상한 적용 위치 명확화
+- 반복 타입 전반(Weekly/Daily) 일반화 및 테스트 추가 대응
+
+## 검증 체크리스트
+
+- [ ] RED 테스트 3건 전부 통과
+- [ ] 월 31일: 31일 있는 달만 포함
+- [ ] 연 2/29: 윤년만 포함, 대체 금지
+- [ ] 종료일 경계 초과 생성 없음
+- [ ] 겹침 허용 로직 유지(중복 제거 없음)
+
+## 차후 커밋 메시지 예시
+
+- feat(green): 1. 반복 유형 선택 - 31일/2월29일 규칙 최소 구현
+
+## 파일/커밋/요구사항 매핑
+
+- 문서: DOCS/feature-1-GREEN.md
+- 코드: src/utils/eventUtils.ts (`generateRecurrences`)
+- 관련 요구사항 번호: 1
diff --git a/DOCS/feature-1-INT-RED.md b/DOCS/feature-1-INT-RED.md
new file mode 100644
index 00000000..90509978
--- /dev/null
+++ b/DOCS/feature-1-INT-RED.md
@@ -0,0 +1,29 @@
+# [RED-통합] Feature 1: 반복 유형 선택 - UI 셀렉터 노출 및 옵션 검증
+
+## 관련 요구사항
+- 1. 반복 유형 선택 (recurring type selection)
+  - 폼에서 반복 유형(매일/매주/매월/매년)을 선택할 수 있어야 함
+
+## 목적
+- 실제 UI 상에서 “반복 유형” 셀렉터가 노출되고, 4가지 옵션(매일/매주/매월/매년)을 제공하는지 통합 관점에서 실패 테스트(RED)를 작성한다.
+
+## 테스트 시나리오 요약
+1) 일정 추가 버튼 클릭 → 폼 오픈
+2) 라벨이 `반복 유형`인 셀렉터의 콤보박스를 연다
+3) 옵션: `daily-option`, `weekly-option`, `monthly-option`, `yearly-option`이 DOM에 노출되는지 확인
+
+## 검증 포인트
+- 라벨 접근성(라벨 텍스트 `반복 유형`)
+- 콤보박스 역할 기반 쿼리로 열 수 있어야 함
+- 4가지 옵션이 정확히 노출되어야 함
+
+## 변경 파일(RED)
+- 테스트: `src/__tests__/medium.integration.spec.tsx`
+
+## 차후 커밋 메시지 예시
+- `test(red): 1.i 반복 유형 선택 - UI 셀렉터 및 옵션 노출 통합 테스트 추가`
+
+## 파일/커밋/요구사항 매핑
+- 문서: `DOCS/feature-1-INT-RED.md`
+- 테스트: `src/__tests__/medium.integration.spec.tsx`
+- 관련 요구사항 번호: 1 (UI 관점)
diff --git a/DOCS/feature-1-INT-REFACTOR.md b/DOCS/feature-1-INT-REFACTOR.md
new file mode 100644
index 00000000..f85deb83
--- /dev/null
+++ b/DOCS/feature-1-INT-REFACTOR.md
@@ -0,0 +1,27 @@
+# [REFACTOR-통합] Feature 1: 반복 유형 선택 - UI 구조 개선/컴포넌트 분리
+
+## 목적
+- 반복 유형 셀렉터를 별도 컴포넌트로 추출하여 코드 중복 제거, 일관성·테스트 용이성 강화
+- App.tsx UI 영역을 간결하게 유지하고, 상태/이벤트 핸들링을 props로 제어하도록 리팩토링
+
+## 변경 파일
+- src/components/RepeatTypeSelector.tsx : 반복 유형 셀렉터 컴포넌트 신설(주석·라벨 모두 한글)
+- src/App.tsx : 기존 인라인 셀렉터 UI를 RepeatTypeSelector로 대체, value/onChange 연결
+
+## 리팩토링 요약
+- FormLabel/Select/MenuItem 구조, 접근성(aria-)정책 일관성 유지
+- 컴포넌트 prop로 상태/이벤트 바인딩(App 유지보수성↑)
+- 일관된 UX, 테스트/업무 단순화(중복 제거)
+
+## 검증 체크리스트
+- [ ] 통합 테스트 전체 GREEN 유지
+- [ ] 라벨·역할·옵션 쿼리 방식(테스트·접근성) 동일하게 동작
+- [ ] 반복 유형 UI 상태/핸들링이 정상 작동(폼 제출 등 연동 확인)
+
+## 차후 커밋 메시지 예시
+- refactor(int): 1.i 반복 유형 선택 - 셀렉터 컴포넌트 분리 및 App 구조 개선
+
+## 파일/커밋/요구사항 매핑
+- 문서: DOCS/feature-1-INT-REFACTOR.md
+- 코드: src/components/RepeatTypeSelector.tsx, src/App.tsx
+- 관련 요구사항 번호: 1 (UI 관점)
diff --git a/DOCS/feature-1-RED.md b/DOCS/feature-1-RED.md
new file mode 100644
index 00000000..ce6cb04a
--- /dev/null
+++ b/DOCS/feature-1-RED.md
@@ -0,0 +1,39 @@
+# [RED] Feature 1: 반복 유형 선택 - 단일 책임 테스트 작성
+
+## 관련 요구사항
+
+- 1. 반복 유형 선택 (recurring type selection)
+  - 일정 생성/수정 시 다음 반복 유형 중 하나를 선택할 수 있다: 매일, 매주, 매월, 매년
+  - 31일 선택 시: 매월 31일에만 일정 생성(30/28/29일 대체 금지)
+  - 2/29 선택 시: 윤년 2월 29일에만 일정 생성
+  - 반복 일정은 겹침 허용
+
+## 산출 목적
+
+- 위 요구사항에 대응하는 핵심 “반복 유형 선택” 동작에 대한 실패 테스트(RED) 작성을 목표로 한다.
+- 일정 생성 시, 반복 유형이 정상 인식 및 처리되는지 검증
+- 특수 규칙(31일, 2/29일, 겹침 허용)에 대한 단일 책임 테스트 작성
+
+## 실제 작성 결과 요약
+
+- src/**tests**/unit/recurrenceUtils.spec.ts
+  - "generateRecurrences" 유틸 함수에 대한 단위 테스트 3건 작성(초기 단계엔 임시 함수명)
+  1. 매월 31일 반복 선택 시 1, 3, 5, 7, 8, 10, 12월 31일 일정만 생성되는지 검증(나머지 달은 생성 불가)
+  2. 연 2/29 반복 시 윤년(2024, 2028)만 포함 (다른 해는 생성 금지)
+  3. 기존 일정과 겹치더라도 중복 허용되어 생성됨을 검증(중복 제거 불필요)
+- 테스트 설명 및 주석 모두 한국어로 명확히 작성(가독성/도메인 추적성 확보)
+
+## 검증 포인트
+
+- 요구사항에서 명시한 특수 사례(월 31일, 윤년 2월 29일, 중복 허용)에 정확하게 대응하는가?
+- 테스트 명/내용/경계조건이 명확히 드러나는가?
+
+## 차후 커밋 메시지 예시
+
+- test(red): 1. 반복 유형 선택 - 31일/2월29일/겹침 허용 규칙 실패 테스트 추가
+
+## 파일/커밋/요구사항 매핑
+
+- 문서: DOCS/feature-1-RED.md
+- 테스트: src/**tests**/unit/recurrenceUtils.spec.ts
+- 관련 요구사항 번호: 1
diff --git a/DOCS/feature-1-REFACTOR.md b/DOCS/feature-1-REFACTOR.md
new file mode 100644
index 00000000..e1e9e3fd
--- /dev/null
+++ b/DOCS/feature-1-REFACTOR.md
@@ -0,0 +1,45 @@
+# [REFACTOR] Feature 1: 반복 유형 선택 - 구조 개선
+
+## 관련 요구사항
+- 1. 반복 유형 선택 (recurring type selection)
+  - 31일 선택 시: 매월 31일에만 일정 생성(대체 금지)
+  - 2/29 선택 시: 윤년에만 생성(대체 금지)
+  - 반복 일정은 겹침 허용
+
+## 목적
+- GREEN 단계에서 통과한 동작을 유지하면서, 코드 가독성과 유지보수성 향상
+- 규칙(31일, 윤년) 분리로 추후 기능 확장(주간/일간, 종료 상한 등)에 대비
+
+## 변경 파일
+- src/utils/eventUtils.ts
+  - 순수 함수 분리: `has31stDay(year, month)`, `isLeapYear(year)`, `formatDate(date)`
+  - `generateRecurrences` 내부 흐름 간소화(조건 분기/루프 가독성 개선)
+  - 모든 주석 한국어 유지, 식별자 영어
+
+## 리팩토링 요약
+- 31일 규칙: 월 31일 존재 여부를 `has31stDay`로 캡슐화
+- 윤년 규칙: `isLeapYear`로 판별 로직 분리
+- 날짜 문자열 변환: `formatDate`로 통일
+- `generateRecurrences`는 월/연 로직을 간결한 루프와 분기만 남기도록 정리
+
+## 전후 비교(하이라이트)
+- Before: `generateRecurrences` 내부에서 말단 로직/분기 혼재 → 가독성 낮음
+- After: 규칙/포맷터 함수 분리, 루프 전개 간결화 → 읽기 쉬움, 테스트 유지됨
+- 동작 변화 없음(RED/GREEN 테스트 동일 통과)
+
+## 검증 체크리스트
+- [ ] 기존 테스트 모두 GREEN 유지
+- [ ] 함수 분리로 로직 중복/노이즈 감소 확인
+- [ ] 주석/식별자 언어 정책 준수(주석 한국어, 식별자 영어)
+
+## 차후 확장 아이디어(참고)
+- Weekly/Daily 규칙 추가 시 동일한 패턴으로 순수 함수 분리
+- 종료 상한(2025-12-31) 클램핑 로직을 공통화
+
+## 차후 커밋 메시지 예시
+- refactor: 1. 반복 유형 선택 - 31일/윤년 규칙 분리 및 구조 개선
+
+## 파일/커밋/요구사항 매핑
+- 문서: DOCS/feature-1-REFACTOR.md
+- 코드: src/utils/eventUtils.ts
+- 관련 요구사항 번호: 1
diff --git a/DOCS/recurring-requirements.en.md b/DOCS/recurring-requirements.en.md
new file mode 100644
index 00000000..96679391
--- /dev/null
+++ b/DOCS/recurring-requirements.en.md
@@ -0,0 +1,50 @@
+# Recurring Events - Required Feature Specification
+
+This document defines the mandatory behavior for implementing recurring events. Use it as the source of truth for tests (TDD) and implementation.
+
+## 1) Recurrence Type Selection
+
+- Users can select a recurrence type when creating or editing an event.
+- Supported types: Daily, Weekly, Monthly, Yearly.
+- Special rules:
+  - Monthly on the 31st: generate occurrences only on the 31st of months that have 31 days. Do NOT substitute with the last day (30/28/29).
+  - Yearly on Feb 29: generate occurrences only in leap years (Feb 29). Do NOT substitute with Feb 28/Mar 1.
+- Overlaps are allowed by design; do not prevent or merge overlapping occurrences.
+
+## 2) Recurring Indicator in Calendar
+
+- In the calendar view, display a distinct icon/marker for recurring events.
+- Single (detached) events should not display the recurring icon.
+
+## 3) Recurrence End Condition
+
+- Users can specify an end condition for the recurrence.
+- Option: Until a specific date.
+  - For this assignment, ensure the maximum generated date is capped at 2025-12-31.
+
+## 4) Edit Recurring Events
+
+- When editing an occurrence of a recurring event, prompt the user: "Edit only this occurrence?"
+  - If the user selects Yes (single edit):
+    - Convert the selected occurrence into a single (detached) event.
+    - Remove the recurring icon for that event.
+  - If the user selects No (edit all):
+    - Apply changes to the entire series (the event remains recurring).
+    - The recurring icon remains for occurrences in the series.
+
+## 5) Delete Recurring Events
+
+- When deleting an occurrence of a recurring event, prompt the user: "Delete only this occurrence?"
+  - If the user selects Yes (single delete):
+    - Remove only the selected occurrence.
+  - If the user selects No (delete all):
+    - Delete all occurrences in the series.
+
+## Notes
+
+- All rules must be covered by tests first (RED → GREEN → REFACTOR).
+- Treat time/clock deterministically in tests (fake timers or injected clock).
+
+
+
+
diff --git a/copilot-instructions.md b/copilot-instructions.md
new file mode 100644
index 00000000..ffb577cb
--- /dev/null
+++ b/copilot-instructions.md
@@ -0,0 +1,38 @@
+# Copilot Instructions (Project-Specific)
+
+## Mission
+
+- Assist with TDD development for recurring schedule features.
+- Prefer small, safe, and readable edits that keep lints/types clean.
+
+## Behavior
+
+- Generate tests first (failing), then minimal implementation, then refactor.
+- Use domain language and AAA structure in tests.
+- Favor React Testing Library queries by role/label/text; use `userEvent`.
+- Mock time/network/random deterministically (MSW, fake timers, injected clock).
+- Keep files and paths consistent with the repository structure.
+
+## Do
+
+- Put new docs in `DOCS/` (except `.cursor` rules); tests in `src/__tests__/`.
+- Write clear commit messages per stage: `test(red)`, `feat(green)`, `refactor`.
+- Add boundary/negative test cases for date/recurrence rules.
+
+## Don’t
+
+- Don’t rely on implementation details in tests.
+- Don’t introduce flaky tests or time-dependent assertions.
+- Don’t over-mock core domain logic in integration tests.
+
+## Recurring Feature Notes
+
+- Monthly 31st → only on the 31st; no substitution with 30/28/29.
+- Yearly Feb 29 → only in leap years.
+- Overlaps allowed; no de-dup.
+- Calendar shows icon for recurring; detached single edits remove the icon.
+- End date must not exceed 2025-12-31.
+
+
+
+
diff --git a/pnpm-workspace.yaml b/pnpm-workspace.yaml
new file mode 100644
index 00000000..9ff8d8fa
--- /dev/null
+++ b/pnpm-workspace.yaml
@@ -0,0 +1,4 @@
+onlyBuiltDependencies:
+  - '@swc/core'
+  - esbuild
+  - msw
diff --git a/src/App.tsx b/src/App.tsx
index 195c5b05..28128213 100644
--- a/src/App.tsx
+++ b/src/App.tsx
@@ -36,7 +36,7 @@ import { useEventOperations } from './hooks/useEventOperations.ts';
 import { useNotifications } from './hooks/useNotifications.ts';
 import { useSearch } from './hooks/useSearch.ts';
 // import { Event, EventForm, RepeatType } from './types';
-import { Event, EventForm } from './types';
+import { Event, EventForm, RepeatType } from './types';
 import {
   formatDate,
   formatMonth,
@@ -47,6 +47,7 @@ import {
 } from './utils/dateUtils';
 import { findOverlappingEvents } from './utils/eventOverlap';
 import { getTimeErrorMessage } from './utils/timeValidation';
+import RepeatTypeSelector from './components/RepeatTypeSelector';
 
 const categories = ['업무', '개인', '가족', '기타'];
 
@@ -77,7 +78,7 @@ function App() {
     isRepeating,
     setIsRepeating,
     repeatType,
-    // setRepeatType,
+    setRepeatType,
     repeatInterval,
     // setRepeatInterval,
     repeatEndDate,
@@ -421,6 +422,9 @@ function App() {
             />
           </FormControl>
 
+          {/* 반복 유형 셀렉터 추출한 컴포넌트로 대체 */}
+          <RepeatTypeSelector value={repeatType} onChange={setRepeatType} />
+
           <FormControl fullWidth>
             <FormLabel htmlFor="notification">알림 설정</FormLabel>
             <Select
diff --git a/src/__tests__/medium.integration.spec.tsx b/src/__tests__/medium.integration.spec.tsx
index 788dae14..3a63e365 100644
--- a/src/__tests__/medium.integration.spec.tsx
+++ b/src/__tests__/medium.integration.spec.tsx
@@ -340,3 +340,24 @@ it('notificationTime을 10으로 하면 지정 시간 10분 전 알람 텍스트
 
   expect(screen.getByText('10분 후 기존 회의 일정이 시작됩니다.')).toBeInTheDocument();
 });
+
+// 반복 일정 통합 테스트 (RED)
+
+describe('반복 일정 통합 - 반복 유형 선택 UI', () => {
+  it('일정 추가 폼에서 반복 유형 셀렉터가 노출되고 옵션(매일/매주/매월/매년)을 제공한다', async () => {
+    const { user } = setup(<App />);
+
+    // 일정 추가 버튼 클릭하여 폼 오픈
+    await user.click(screen.getAllByText('일정 추가')[0]);
+
+    // 반복 유형 셀렉터 존재 여부 확인 (라벨/역할 기준)
+    const selectorLabel = screen.getByLabelText('반복 유형'); // 기대 라벨명
+    await user.click(within(selectorLabel).getByRole('combobox'));
+
+    // 옵션들이 존재하는지 확인 (이름 규칙은 예시이며 구현 시 일치 필요)
+    expect(screen.getByRole('option', { name: 'daily-option' })).toBeInTheDocument();
+    expect(screen.getByRole('option', { name: 'weekly-option' })).toBeInTheDocument();
+    expect(screen.getByRole('option', { name: 'monthly-option' })).toBeInTheDocument();
+    expect(screen.getByRole('option', { name: 'yearly-option' })).toBeInTheDocument();
+  });
+});
diff --git a/src/__tests__/unit/recurrenceUtils.spec.ts b/src/__tests__/unit/recurrenceUtils.spec.ts
new file mode 100644
index 00000000..e9004c21
--- /dev/null
+++ b/src/__tests__/unit/recurrenceUtils.spec.ts
@@ -0,0 +1,72 @@
+import { generateRecurrences } from '../../utils/eventUtils';
+
+describe('generateRecurrences (RED)', () => {
+  it('매월 반복에서 31일 선택 시 31일에만 일정을 생성해야 한다 (30/28/29일 대체 금지)', () => {
+    // 준비: 2024년 1월 31일부터 12월 31일까지, 반복 유형은 monthly로 지정
+    const start = new Date('2024-01-31');
+    const end = new Date('2024-12-31');
+    // 실행: 매월 1회 반복 생성
+    const events = generateRecurrences({
+      start,
+      end,
+      type: 'monthly',
+      interval: 1,
+    });
+    // 검증: 1, 3, 5, 7, 8, 10, 12월 31일만 있어야 함 (다른 달 대체/생성 금지)
+    const dates = events.map((e) => e.date.slice(5, 10)); // MM-DD
+    expect(dates).toContain('01-31');
+    expect(dates).toContain('03-31');
+    expect(dates).toContain('05-31');
+    expect(dates).toContain('07-31');
+    expect(dates).toContain('08-31');
+    expect(dates).toContain('10-31');
+    expect(dates).toContain('12-31');
+    expect(dates).not.toContain('04-30');
+    expect(dates).not.toContain('06-30');
+    expect(dates).not.toContain('09-30');
+    expect(dates).not.toContain('11-30');
+    expect(dates).not.toContain('02-28');
+    expect(dates).not.toContain('02-29');
+  });
+
+  it('연 반복에서 2월 29일 선택 시 윤년에만 일정을 생성해야 한다', () => {
+    // 준비: 2024년 2월 29일부터 2030년 12월 31일까지, 반복 유형은 yearly
+    const start = new Date('2024-02-29');
+    const end = new Date('2030-12-31');
+    // 실행: 매년 1회 반복 생성
+    const events = generateRecurrences({
+      start,
+      end,
+      type: 'yearly',
+      interval: 1,
+    });
+    // 검증: 윤년(2024, 2028)만 포함, 그 외는 생성 금지
+    const dates = events.map((e) => e.date);
+    expect(dates).toContain('2024-02-29');
+    expect(dates).toContain('2028-02-29');
+    expect(dates).not.toContain('2025-02-28');
+    expect(dates).not.toContain('2026-02-28');
+    expect(dates).not.toContain('2027-02-28');
+    expect(dates).not.toContain('2029-02-28');
+    expect(dates).not.toContain('2030-02-28');
+  });
+
+  it('반복 일정이 기존 일정과 겹쳐도 생성되어야 한다', () => {
+    // 준비: 2024년 5월 31일부터 7월 31일까지, 월간 반복
+    const start = new Date('2024-05-31');
+    const end = new Date('2024-07-31');
+    // 실행: 기존에 2024-05-31 일정이 이미 있다고 가정, 중복 허용
+    const events = generateRecurrences({
+      start,
+      end,
+      type: 'monthly',
+      interval: 1,
+    });
+    // 검증: 2024-05-31, 2024-07-31 모두 포함되어야 함 (중복 제외 논리 없어야 함)
+    const dates = events.map((e) => e.date);
+    expect(dates).toContain('2024-05-31');
+    expect(dates).toContain('2024-07-31');
+  });
+
+  // 추가적인 음수/경계 사례는 이 패턴을 따라 작성 가능
+});
diff --git a/src/components/RepeatTypeSelector.tsx b/src/components/RepeatTypeSelector.tsx
new file mode 100644
index 00000000..5b9d8874
--- /dev/null
+++ b/src/components/RepeatTypeSelector.tsx
@@ -0,0 +1,40 @@
+import { FormControl, FormLabel, MenuItem, Select } from '@mui/material';
+import { RepeatType } from '../types';
+
+interface RepeatTypeSelectorProps {
+  value: RepeatType;
+  onChange: (v: RepeatType) => void;
+}
+
+/**
+ * 반복 유형(매일/매주/매월/매년) 선택 컴포넌트
+ * - 라벨, 역할/aria-label 접근성 연결
+ * - 테스트 및 접근성 일관성 보장(옵션 aria-label: *-option)
+ */
+export default function RepeatTypeSelector({ value, onChange }: RepeatTypeSelectorProps) {
+  return (
+    <FormControl fullWidth>
+      <FormLabel id="repeat-type-label">반복 유형</FormLabel>
+      <Select
+        size="small"
+        value={value}
+        onChange={(e) => onChange(e.target.value as RepeatType)}
+        aria-labelledby="repeat-type-label"
+        aria-label="반복 유형"
+      >
+        <MenuItem value="daily" aria-label="daily-option">
+          매일
+        </MenuItem>
+        <MenuItem value="weekly" aria-label="weekly-option">
+          매주
+        </MenuItem>
+        <MenuItem value="monthly" aria-label="monthly-option">
+          매월
+        </MenuItem>
+        <MenuItem value="yearly" aria-label="yearly-option">
+          매년
+        </MenuItem>
+      </Select>
+    </FormControl>
+  );
+}
diff --git a/src/utils/eventUtils.ts b/src/utils/eventUtils.ts
index 9e75e947..3bd46ba0 100644
--- a/src/utils/eventUtils.ts
+++ b/src/utils/eventUtils.ts
@@ -56,3 +56,103 @@ export function getFilteredEvents(
 
   return searchedEvents;
 }
+
+// ---- 반복 일정 생성 (테스트 통과를 위한 최소 구현) ----
+
+type RecurrenceType = 'daily' | 'weekly' | 'monthly' | 'yearly';
+
+interface GenerateRecurrencesParams {
+  start: Date;
+  end: Date;
+  type: RecurrenceType;
+  interval: number;
+}
+
+// 월에 31일이 있는지 판별
+function has31stDay(year: number, month: number): boolean {
+  return new Date(year, month + 1, 0).getDate() === 31;
+}
+
+// 해당 연도가 윤년인지 판별
+function isLeapYear(year: number): boolean {
+  return (year % 4 === 0 && year % 100 !== 0) || year % 400 === 0;
+}
+
+// 날짜 YYYY-MM-DD 형식 문자열 변환
+function formatDate(date: Date): string {
+  const y = date.getFullYear();
+  const m = String(date.getMonth() + 1).padStart(2, '0');
+  const d = String(date.getDate()).padStart(2, '0');
+  return `${y}-${m}-${d}`;
+}
+
+export function generateRecurrences({
+  start,
+  end,
+  type,
+  interval,
+}: GenerateRecurrencesParams): { date: string }[] {
+  const results: { date: string }[] = [];
+  const endTime = end.getTime();
+  const startDay = start.getDate();
+  let y = start.getFullYear();
+  let m = start.getMonth();
+
+  if (type === 'monthly') {
+    // 31일 전용: 31일이 있는 달에만
+    while (true) {
+      if (startDay === 31) {
+        if (has31stDay(y, m)) {
+          const candidate = new Date(y, m, 31);
+          if (candidate.getTime() > endTime) break;
+          if (candidate.getTime() >= start.getTime()) {
+            results.push({ date: formatDate(candidate) });
+          }
+        }
+      } else {
+        // 일반 규칙(후속 확장)
+        const candidate = new Date(y, m, startDay);
+        if (candidate.getTime() > endTime) break;
+        if (candidate.getDate() === startDay && candidate.getTime() >= start.getTime()) {
+          results.push({ date: formatDate(candidate) });
+        }
+      }
+      // 월, 연도 증가
+      m += interval;
+      while (m >= 12) {
+        m -= 12;
+        y += 1;
+      }
+      if (new Date(y, m, 1).getTime() > endTime) break;
+    }
+    return results;
+  }
+
+  if (type === 'yearly') {
+    // 2/29 전용: 윤년에만
+    const startMonth = start.getMonth();
+    while (true) {
+      if (startMonth === 1 && startDay === 29) {
+        if (isLeapYear(y)) {
+          const candidate = new Date(y, 1, 29);
+          if (candidate.getTime() > endTime) break;
+          if (candidate.getTime() >= start.getTime()) {
+            results.push({ date: formatDate(candidate) });
+          }
+        }
+      } else {
+        const candidate = new Date(y, startMonth, startDay);
+        if (candidate.getTime() > endTime) break;
+        if (candidate.getTime() >= start.getTime()) {
+          results.push({ date: formatDate(candidate) });
+        }
+      }
+      y += interval;
+      if (new Date(y, startMonth, 1).getTime() > endTime) break;
+    }
+    return results;
+  }
+
+  // 그 외: 테스트 요구 타입 외엔 반환 없음
+  return results;
+}