@wishket/eslint-config-wishket 1.1.0 → 2.1.0

package/.changeset/README.md

@@ -5,4 +5,4 @@ with multi-package repos, or single-package repos to help you version and publis
 find the full documentation for it [in our repository](https://github.com/changesets/changesets)
 
 We have a quick list of common questions to get you started engaging with this project in
-[our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md)
+[our documentation](https://g.ithub.com/changesets/changesets/blob/main/docs/common-questions.md)

package/.changeset/force-publish.md

@@ -2,4 +2,4 @@
 '@wishket/eslint-config-wishket': patch
 ---
 
-Publish with tag 1.1.0
+Publish with tag 2.1.0

package/.changeset/pure-airbnb-pattern.md

@@ -0,0 +1,17 @@
+---
+"@wishket/eslint-config-wishket": major
+---
+
+BREAKING CHANGE: 모든 ESLint 플러그인을 peer-dependencies로 이동
+
+v2.0에서는 eslint-config-airbnb와 동일한 패턴을 따라 모든 플러그인이 peer dependencies로 이동했습니다.
+
+**변경사항:**
+- 17개 플러그인이 peer-dependencies로 이동
+- typescript와 Jest 관련 플러그인은 optional로 표시
+- 버전 충돌 방지 및 유연성 향상
+
+**마이그레이션:**
+자동 설치: `npx install-peerdeps --dev @wishket/eslint-config-wishket`
+
+자세한 내용은 MIGRATION.md를 참조하세요.

package/.claude/rules/augmented-coding.md

@@ -0,0 +1,300 @@
+# Augmented Coding Principles
+
+## ⚠️ REMINDER: 한국어로 응답하세요!
+
+All responses must be in Korean. Check `critical.md` for details.
+
+Based on Kent Beck's approach: https://tidyfirst.substack.com/p/augmented-coding-beyond-the-vibes
+
+## Philosophy: Beyond Vibe Coding
+
+### Vibe Coding vs Augmented Coding
+
+- **Vibe Coding**: Don't care about code, only behavior. Feed errors back to AI hoping for fixes.
+- **Augmented Coding**: Care about code quality, complexity, tests, and coverage. Same value system as hand coding—tidy code that works. You just don't type much of it.
+
+**We practice Augmented Coding**: High standards for AI-generated code, same as hand-written code.
+
+---
+
+## TDD Cycle (Strict Adherence)
+
+Follow the **Red → Green → Refactor** cycle religiously:
+
+1. **Red**: Write a failing test that defines a small increment of functionality
+2. **Green**: Implement the minimum code needed to make the test pass
+3. **Refactor**: Improve structure only after tests are passing
+
+### Core Rules
+
+- Write one test at a time
+- Make it pass with minimal code
+- Run all tests after each change
+- Never skip the refactor step
+
+### Project-Specific TDD Strategy
+
+#### ESLint 규칙 검증 (Test-First TDD)
+
+ESLint 설정 변경 시 TDD 적용:
+
+**Workflow:**
+
+1. 검증할 코드 예제 작성
+   - 규칙을 위반하는 코드
+   - 규칙을 준수하는 코드
+2. 예상되는 ESLint 결과 정의
+3. ESLint 규칙 추가/수정
+4. 실제 프로젝트에서 테스트
+5. 규칙 미세 조정
+
+**예제:**
+
+```javascript
+// 1. 테스트 케이스 작성
+// bad.js - 규칙 위반 (에러 발생 예상)
+function foo() {
+  return 'bar';
+}
+
+// good.js - 규칙 준수 (에러 없음)
+const foo = () => 'bar';
+
+// 2. ESLint 규칙 추가
+'no-restricted-syntax': [
+  'error',
+  {
+    selector: 'FunctionDeclaration',
+    message: 'Function declarations are not allowed. Use arrow functions instead.'
+  }
+]
+
+// 3. 검증
+// bad.js → ✗ 에러 발생
+// good.js → ✓ 통과
+```
+
+---
+
+## Tidy First 접근법
+
+**핵심 원칙**: 구조적 변경과 동작 변경을 분리. 절대 섞지 말 것.
+
+### 두 가지 변경 유형
+
+#### 1. 구조적 변경 (Tidy First)
+
+동작 변경 없이 코드 재구성:
+
+- 규칙 재정렬 및 그룹화
+- 주석 개선
+- 중복 규칙 제거
+- 포맷팅 수정
+
+**검증**: 동일한 ESLint 동작 유지—기존 프로젝트에서 동일한 결과
+
+#### 2. 동작 변경
+
+실제 ESLint 동작 수정:
+
+- 새 규칙 추가
+- 규칙 엄격도 변경 (warn → error)
+- 규칙 옵션 수정
+- 플러그인 추가/제거
+
+### 워크플로우 규칙
+
+두 유형의 변경이 모두 필요한 경우:
+
+1. 구조적 변경을 먼저 수행
+2. 구조적 변경을 별도로 커밋
+3. 그 다음 동작 변경 수행
+4. 동작 변경을 별도로 커밋
+
+**절대 같은 커밋에 섞지 말 것**
+
+**예제:**
+
+```bash
+# 1단계: 구조적 변경 (Tidy)
+git commit -m "refactor: 공백 관련 규칙을 하나의 섹션으로 그룹화"
+
+# 2단계: 동작 변경 (Behavior)
+git commit -m "feat: max-len 규칙을 80자로 강제"
+```
+
+---
+
+## 커밋 규율
+
+### 커밋 조건:
+
+1. ✅ ESLint 설정이 유효함 (구문 오류 없음)
+2. ✅ 실제 프로젝트에서 테스트 완료
+3. ✅ 변경이 단일 논리적 작업 단위를 나타냄
+4. ✅ 커밋 메시지가 명확히 구조적 또는 동작 변경 명시
+5. ✅ Changeset 생성 (버전 변경 필요 시)
+
+### 커밋 메시지
+
+- **구조적**: `refactor: import 규칙을 별도 섹션으로 분리`
+- **동작적**: `feat: 화살표 함수 강제 규칙 추가`
+- **수정**: `fix: no-restricted-syntax 규칙 정규식 오류 수정`
+
+크고 드문 커밋보다 작고 빈번한 커밋 선호
+
+---
+
+## AI 모니터링 체크포인트
+
+AI를 주의 깊게 관찰하고 다음을 발견하면 개입:
+
+### 🚨 경고 신호 (즉시 AI 중단)
+
+1. **불필요한 복잡성**: 간단한 규칙을 과도하게 복잡하게 작성
+2. **요청하지 않은 변경**: 요청하지 않은 규칙 추가/수정
+3. **주석 삭제**: 기존 한국어 주석 제거
+4. **참조 번호 제거**: `#숫자` 형식의 참조 제거
+5. **중복 추가**: 이미 정의된 규칙 재정의
+
+### ✅ 좋은 AI 동작
+
+- 정확한 지시 준수
+- 기존 코드 스타일 유지
+- 한국어 주석 작성
+- 참조 번호 보존
+- 불확실할 때 명확화 요청
+
+### 개입 전략
+
+중간 결과를 지속적으로 검토:
+
+- 각 AI 응답 후 변경사항 확인
+- AI가 정확히 요청한 것을 했는지 검증
+- 경로를 벗어나면 중단하고 재지시
+- 구체적인 다음 단계 제안
+
+---
+
+## 코드 품질 표준
+
+### 핵심 원칙 (SOLID)
+
+- **단일 책임**: 각 규칙은 하나의 코드 스타일만 강제
+- **개방/폐쇄**: 프로젝트별 확장은 허용, 기본 규칙은 수정 최소화
+- **명확한 의도**: 규칙의 목적이 주석으로 명확히 표현됨
+- **최소 의존성**: 필요한 플러그인만 사용
+- **일관성**: 모든 규칙이 동일한 형식과 스타일 유지
+
+### 품질 메트릭
+
+- **중복 제거**: DRY (Don't Repeat Yourself) 철저히 적용
+  - 같은 규칙을 여러 번 정의하지 않음
+- **의도를 명확히 표현**: 주석이 규칙의 목적을 드러냄
+- **호환성 유지**: React 19/Next.js 15와 호환
+- **최소 설정**: 필요한 규칙만 포함
+- **가장 간단한 해결책**: "작동할 수 있는 가장 간단한 설정은 무엇인가?"
+
+### ESLint 설정 표준
+
+- **주석**: 모든 규칙에 한국어 설명 주석
+- **참조 번호**: Wishket 코드 스타일 가이드 참조 번호 유지
+- **그룹화**: 관련 규칙을 카테고리별로 그룹화
+- **일관성**: 동일한 형식과 들여쓰기 사용
+- **테스트**: 실제 프로젝트에서 검증
+
+---
+
+## 리팩토링 가이드라인
+
+### 리팩토링 시기
+
+- **Green** 단계에서만 (설정이 유효하고 테스트 통과)
+- 새 규칙 추가 후
+- 중복을 발견했을 때
+- 의도가 불명확할 때
+
+### 리팩토링 방법
+
+1. **한 번에 하나의 변경**: 단일 리팩토링 작업
+2. **각 단계 후 검증**: ESLint 설정이 여전히 유효한지 확인
+3. **명확성 우선**: 중복 제거, 주석 개선, 그룹화
+
+### 일반적인 리팩토링
+
+- 규칙 재그룹화 (카테고리별)
+- 주석 개선
+- 중복 규칙 제거
+- 규칙 순서 재정렬
+- 매직 값을 상수로 교체
+
+---
+
+## 예제 워크플로우
+
+### 새 ESLint 규칙 추가
+
+#### 1단계: 테스트 케이스 작성 (Red)
+
+```javascript
+// test-cases/arrow-functions/bad.js
+function add(a, b) {
+  return a + b;
+}
+
+// test-cases/arrow-functions/good.js
+const add = (a, b) => a + b;
+```
+
+#### 2단계: 규칙 추가 (Green)
+
+```javascript
+// index.js
+'no-restricted-syntax': [
+  'error',
+  {
+    selector: 'FunctionDeclaration',
+    message: 'Function declarations are not allowed. Use arrow functions instead.'
+  }
+]
+```
+
+#### 3단계: 테스트 검증
+
+실제 프로젝트에서 ESLint 실행:
+- `bad.js` → ✗ 에러 발생 확인
+- `good.js` → ✓ 통과 확인
+
+#### 4단계: 리팩터 (필요시)
+
+주석 추가, 규칙 그룹화 등
+
+#### 5단계: 커밋
+
+```bash
+git commit -m "feat: 화살표 함수만 사용하도록 강제하는 규칙 추가"
+```
+
+#### 6단계: Changeset 생성
+
+```bash
+yarn changeset
+# minor 선택
+# "화살표 함수 강제 규칙 추가" 입력
+```
+
+---
+
+## 프로젝트 규칙과의 통합
+
+이 파일은 AI와 **어떻게** 코드를 작성하는지 정의합니다.
+
+참고 문서:
+
+- `core.md` - PLAN/ACT 모드와 커뮤니케이션 규칙
+- `project.md` - ESLint 패키지 구조, 퍼블리싱 워크플로우
+- `critical.md` - 절대 위반하면 안 되는 규칙
+
+---
+
+**기억하세요**: AI와 프로그래밍하는 것도 여전히 프로그래밍입니다. 시간당 더 많은 중요한 결정을 내리고, 지루한 결정은 줄입니다. 아키텍처, 디자인, 품질에 집중하고—AI가 타이핑을 처리하게 하세요.

package/.claude/rules/core.md

@@ -0,0 +1,164 @@
+# Core Rules
+
+## ⚠️ PREREQUISITE: Check critical.md FIRST!
+
+Before reading this file, ensure you've read and understood `critical.md`.
+특히 한국어 응답 규칙을 반드시 준수하세요.
+
+## Work Modes
+
+You have three modes of operation:
+
+1. **PLAN mode** - Define a plan without making changes
+2. **ACT mode** - Execute the plan and make changes
+3. **EVAL mode** - Analyze results and propose improvements
+
+### Mode Rules
+
+- Start in PLAN mode by default
+- Move to ACT mode when user types `ACT`
+- **After ACT completes, automatically return to PLAN mode** (default behavior)
+- Move to EVAL mode **only when user explicitly requests** by typing `EVAL` (after ACT)
+- EVAL mode analyzes ACT results and proposes improved PLAN
+- After EVAL completes, return to PLAN mode with improvement suggestions
+- User can repeat ACT → EVAL → PLAN cycle until satisfied
+- When in plan mode always output the full updated plan in every response
+
+### Default Flow
+
+```
+PLAN → (user: ACT) → ACT → PLAN (automatic return)
+```
+
+### Optional Evaluation Flow
+
+```
+PLAN → (user: ACT) → ACT → PLAN → (user: EVAL) → EVAL → Improved PLAN
+```
+
+**Key Point:** EVAL is opt-in, not automatic. User must explicitly request evaluation.
+
+### Mode Indicators
+
+- Print `# Mode: PLAN` in plan mode
+- Print `# Mode: ACT` in act mode
+- Print `# Mode: EVAL` in eval mode
+
+---
+
+## Eval Mode
+
+### Important
+
+- EVAL mode is **not automatic** after ACT
+- User must **explicitly request** EVAL by typing `EVAL`
+- Default behavior after ACT: Return to PLAN (without evaluation)
+- Use EVAL when you want iterative improvement and refinement
+
+### Trigger
+
+- Type `EVAL` after completing ACT
+- Type `EVALUATE` (also accepted)
+- Korean: `평가해` or `개선안 제시해`
+
+### Purpose
+
+Self-improvement through iterative refinement
+
+### What EVAL does
+
+1. **Analyze Implementation**
+
+   - Review what was done in ACT
+   - Check adherence to project rules
+   - Verify quality standards met
+
+2. **Assess Quality**
+
+   - ✅ Code quality (SOLID, DRY, clarity)
+   - ✅ Test coverage (90%+ goal)
+   - ✅ Type safety (no `any`)
+   - ✅ Performance (bundle size, re-renders)
+   - ✅ Accessibility (a11y compliance)
+   - ✅ Security (no vulnerabilities)
+   - ✅ Best practices (design system, patterns)
+
+3. **Identify Improvements**
+
+   - What could be better?
+   - Alternative approaches?
+   - Missing edge cases?
+   - Optimization opportunities?
+
+4. **Propose Improved PLAN**
+   - Specific, actionable improvements
+   - Explain why each matters
+   - Prioritize by impact
+   - Wait for user to ACT again
+
+### Output Format
+
+```
+# Mode: EVAL
+
+## 📋 Implementation Analysis
+[What was implemented]
+
+## ✅ Strengths
+- [Good point 1]
+- [Good point 2]
+
+## ⚠️ Improvement Opportunities
+- [Issue 1 + Impact]
+- [Issue 2 + Impact]
+
+## 🎯 Improved PLAN
+1. [Improvement 1 with reasoning]
+2. [Improvement 2 with reasoning]
+
+**Next:** Type `ACT` to apply, `PLAN` to modify, or `EVAL` after next ACT
+```
+
+### When to use EVAL
+
+- Complex features needing refinement
+- First implementation works but could improve
+- Learning and iterating towards excellence
+- Production-critical code requiring high quality
+
+### When to skip EVAL
+
+- Simple, straightforward implementations
+- Already meeting all standards
+- Time-sensitive quick fixes
+
+---
+
+## Communication Rules
+
+### 🚨 CRITICAL: Response Language
+
+- **MUST respond in Korean (한국어) - NO EXCEPTIONS**
+- **위반 시 즉시 실패로 간주됨**
+
+### Code State Management
+
+- User frequently modifies code directly, so **always read code and refresh information** instead of relying on memory
+- **Start by understanding current code state** for every question
+- Never assume - always verify current state
+
+---
+
+## Development Methodology
+
+For detailed development methodology, code quality standards, TDD workflows, and AI collaboration practices, refer to **`augmented-coding.md`**.
+
+Key principles:
+
+- **TDD for ESLint rules** (test with example code before adding rules)
+- **Tidy First approach** (separate structural and behavioral changes)
+- **Code quality standards** (DRY, clear intent, minimal complexity)
+- **Commit discipline** (small, frequent commits with clear messages)
+- **Changeset workflow** (version management for publishing)
+
+---

package/.claude/rules/critical.md

@@ -0,0 +1,106 @@
+# CRITICAL RULES - ABSOLUTE REQUIREMENTS
+
+**⚠️ THESE RULES MUST NEVER BE VIOLATED UNDER ANY CIRCUMSTANCES ⚠️**
+
+---
+
+## 🚨 MANDATORY: Response Language
+
+**[CRITICAL] ALL responses MUST be in Korean (한국어)**
+
+### NO EXCEPTIONS
+
+- Even if the user writes in English
+- Even for technical explanations
+- Even when discussing code architecture
+
+### English ONLY allowed in:
+
+- Code blocks (actual code)
+- Terminal commands
+- File paths
+- Technical terms when no Korean equivalent exists (but add Korean explanation)
+
+### VIOLATION = IMMEDIATE FAILURE
+
+If you respond in English (except allowed cases), you have FAILED.
+
+---
+
+## 🚨 MANDATORY: Current Mode Awareness
+
+**[CRITICAL] ALWAYS know and display current mode**
+
+### Mode Indicators (REQUIRED)
+
+- Start EVERY response with: `# Mode: [CURRENT_MODE]`
+- Modes: PLAN, ACT, EVAL
+- Default: PLAN
+
+### Mode Transitions
+
+- PLAN → ACT: Only when user types "ACT"
+- ACT → PLAN: Automatic after completion
+- PLAN → EVAL: Only when user types "EVAL" or "평가해"
+
+---
+
+## 🚨 MANDATORY: No Mocking
+
+**[CRITICAL] NEVER create mock data or fake implementations**
+
+### FORBIDDEN
+
+- Mock APIs
+- Fake data
+- Placeholder implementations
+- TODO comments instead of real code
+
+### REQUIRED
+
+- Real API integrations
+- Actual working code
+- Complete implementations
+
+---
+
+## ✅ SELF-CHECK BEFORE EVERY RESPONSE
+
+**STOP and verify:**
+
+1. ☐ **Is my response in Korean?** (한국어로 응답하는가?)
+2. ☐ **Did I show the current mode?** (현재 모드를 표시했는가?)
+3. ☐ **Am I following the user's request exactly?** (사용자 요청을 정확히 따르는가?)
+4. ☐ **Is my code real, not mocked?** (실제 코드인가, 모킹이 아닌가?)
+
+---
+
+## 🛑 VIOLATION RECOVERY PROTOCOL
+
+If you catch yourself violating any CRITICAL rule:
+
+1. **STOP IMMEDIATELY**
+2. **Acknowledge:** "규칙 위반을 감지했습니다. 수정하겠습니다."
+3. **Correct the violation**
+4. **Continue with proper adherence**
+
+---
+
+## 📝 LANGUAGE CHECK
+
+**FINAL REMINDER BEFORE RESPONDING:**
+
+```
+if (responseLanguage !== "Korean") {
+  STOP();
+  translateToKorean();
+  respond();
+}
+```
+
+**YOUR NEXT RESPONSE MUST BE IN KOREAN.**
+**다음 응답은 반드시 한국어로 작성하세요.**
+
+---
+
+# REMEMBER: 한국어로 응답하기!