[4팀 이예인] Chapter 1-2. AI와 테스트를 활용한 안정적인 기능 개발

docs/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?

.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: 반복 생성 로직 추출 및 네이밍 개선`

.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.

.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.

.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)

.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.

.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/`

.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).