@su-record/vibe 2.7.14 → 2.7.15

package/vibe/rules/principles/communication-guide.md

@@ -1,98 +1,98 @@
-# Communication Guide
-
-## Language Configuration
-
-Language can be configured per project in `.sutory/config.json`. Code itself (function names, variable names, etc.) should always be in English.
-
-## 3.1 Code Delivery Format
-
-```markdown
-### Scope of Work
-
-"As requested, I only modified the state management logic in the UserProfile component."
-
-### Summary of Changes
-
-Improved order status update logic - Applied optimistic updates
-
-### Code
-
-[Complete code block]
-
-### Notes
-
-- Auto-rollback on error
-- 3 network retries
-```
-
-## 3.2 Review Response Format
-
-```markdown
-### Improvements
-
-1. Missing memoization (performance)
-2. Error boundary not applied (stability)
-
-### Recommendations
-
-Apply useMemo and wrap with ErrorBoundary
-```
-
-## 3.3 Error Report Format
-
-```markdown
-### Problem
-
-[Clearly explain the issue that occurred]
-
-### Cause
-
-[Analyzed cause]
-
-### Solution
-
-[Specific resolution steps]
-
-### Prevention
-
-[How to prevent in the future]
-```
-
-## 3.4 Change Explanation Principles
-
-- **Clarity**: Clearly explain what was changed and why
-- **Conciseness**: Communicate only the essentials
-- **Completeness**: Include side effects and caveats
-- **Traceability**: Reference related issues/requests
-
-## 3.5 Special Command Execution
-
-- **"optimize"**: Performance improvements (memoization, bundle size, etc.)
-- **"enhance accessibility"**: Add ARIA, keyboard support, etc.
-- **"strengthen types"**: Remove `any`, improve type safety
-- **"cleanup"**: Remove unnecessary code (only when requested)
-- **"split"**: Separate components/functions (only when requested)
-
-## 3.6 Question Format
-
-### When Clarity is Needed
-
-```markdown
-Please clarify the following:
-
-1. [Specific question 1]
-2. [Specific question 2]
-
-With this information, a more accurate implementation is possible.
-```
-
-### Presenting Alternatives
-
-```markdown
-In addition to your requested approach, the following alternatives are possible:
-
-**Method A**: [Description] - Pros: [Pros], Cons: [Cons]
-**Method B**: [Description] - Pros: [Pros], Cons: [Cons]
-
-Which approach do you prefer?
-```
+# Communication Guide
+
+## Language Configuration
+
+Language can be configured per project in `.sutory/config.json`. Code itself (function names, variable names, etc.) should always be in English.
+
+## 3.1 Code Delivery Format
+
+```markdown
+### Scope of Work
+
+"As requested, I only modified the state management logic in the UserProfile component."
+
+### Summary of Changes
+
+Improved order status update logic - Applied optimistic updates
+
+### Code
+
+[Complete code block]
+
+### Notes
+
+- Auto-rollback on error
+- 3 network retries
+```
+
+## 3.2 Review Response Format
+
+```markdown
+### Improvements
+
+1. Missing memoization (performance)
+2. Error boundary not applied (stability)
+
+### Recommendations
+
+Apply useMemo and wrap with ErrorBoundary
+```
+
+## 3.3 Error Report Format
+
+```markdown
+### Problem
+
+[Clearly explain the issue that occurred]
+
+### Cause
+
+[Analyzed cause]
+
+### Solution
+
+[Specific resolution steps]
+
+### Prevention
+
+[How to prevent in the future]
+```
+
+## 3.4 Change Explanation Principles
+
+- **Clarity**: Clearly explain what was changed and why
+- **Conciseness**: Communicate only the essentials
+- **Completeness**: Include side effects and caveats
+- **Traceability**: Reference related issues/requests
+
+## 3.5 Special Command Execution
+
+- **"optimize"**: Performance improvements (memoization, bundle size, etc.)
+- **"enhance accessibility"**: Add ARIA, keyboard support, etc.
+- **"strengthen types"**: Remove `any`, improve type safety
+- **"cleanup"**: Remove unnecessary code (only when requested)
+- **"split"**: Separate components/functions (only when requested)
+
+## 3.6 Question Format
+
+### When Clarity is Needed
+
+```markdown
+Please clarify the following:
+
+1. [Specific question 1]
+2. [Specific question 2]
+
+With this information, a more accurate implementation is possible.
+```
+
+### Presenting Alternatives
+
+```markdown
+In addition to your requested approach, the following alternatives are possible:
+
+**Method A**: [Description] - Pros: [Pros], Cons: [Cons]
+**Method B**: [Description] - Pros: [Pros], Cons: [Cons]
+
+Which approach do you prefer?
+```

package/vibe/rules/principles/development-philosophy.md

@@ -1,52 +1,52 @@
-# Development Philosophy and Principles - Answering "Why"
-
-## 1.1 Top Priority: Surgical Precision
-
-> **⚠️ This is the first principle that precedes all work.**
->
-> **Never modify/delete code that wasn't requested.**
-
-### Principles
-
-- **Strict scope adherence**: Only modify files and code blocks explicitly requested by the user
-- **Preserve existing code**: Do not arbitrarily refactor or remove working code
-- **Respect style**: Maintain existing naming, formatting, and comment styles
-
-## 1.2 Core Philosophy
-
-### Development Golden Rules
-
-- **Simplicity aesthetics**: Less code is better code
-- **DRY principle**: Don't repeat, reuse
-- **Single responsibility**: One function serves one purpose
-- **Pragmatism**: Practical over perfect, YAGNI spirit
-
-### Code Quality Standards
-
-- **Readability**: Code is for humans
-- **Predictability**: No surprises in code
-- **Maintainability**: Consider future you
-- **Testability**: Verifiable structure
-
-## 1.3 Architecture Principles
-
-### Design Wisdom
-
-- **Appropriate pattern application**: Apply Composite, Observer, Factory, etc. as needed
-- **Avoid over-abstraction**: No more than 3 levels of wrappers
-- **Prevent circular dependencies**: File A → File B → File A ❌
-
-### Accessibility is Mandatory, Not Optional
-
-- Use semantic HTML as default
-- Support keyboard navigation
-- Optimize for screen readers
-- Actively use ARIA attributes
-
-## Core Values
-
-1. **Clarity**: Code should be self-explanatory
-2. **Conciseness**: Remove unnecessary complexity
-3. **Consistency**: Maintain consistent patterns and styles
-4. **Scalability**: Design considering future changes
-5. **Safety**: Consider error handling and edge cases
+# Development Philosophy and Principles - Answering "Why"
+
+## 1.1 Top Priority: Surgical Precision
+
+> **⚠️ This is the first principle that precedes all work.**
+>
+> **Never modify/delete code that wasn't requested.**
+
+### Principles
+
+- **Strict scope adherence**: Only modify files and code blocks explicitly requested by the user
+- **Preserve existing code**: Do not arbitrarily refactor or remove working code
+- **Respect style**: Maintain existing naming, formatting, and comment styles
+
+## 1.2 Core Philosophy
+
+### Development Golden Rules
+
+- **Simplicity aesthetics**: Less code is better code
+- **DRY principle**: Don't repeat, reuse
+- **Single responsibility**: One function serves one purpose
+- **Pragmatism**: Practical over perfect, YAGNI spirit
+
+### Code Quality Standards
+
+- **Readability**: Code is for humans
+- **Predictability**: No surprises in code
+- **Maintainability**: Consider future you
+- **Testability**: Verifiable structure
+
+## 1.3 Architecture Principles
+
+### Design Wisdom
+
+- **Appropriate pattern application**: Apply Composite, Observer, Factory, etc. as needed
+- **Avoid over-abstraction**: No more than 3 levels of wrappers
+- **Prevent circular dependencies**: File A → File B → File A ❌
+
+### Accessibility is Mandatory, Not Optional
+
+- Use semantic HTML as default
+- Support keyboard navigation
+- Optimize for screen readers
+- Actively use ARIA attributes
+
+## Core Values
+
+1. **Clarity**: Code should be self-explanatory
+2. **Conciseness**: Remove unnecessary complexity
+3. **Consistency**: Maintain consistent patterns and styles
+4. **Scalability**: Design considering future changes
+5. **Safety**: Consider error handling and edge cases

package/vibe/rules/principles/quick-start.md

@@ -1,102 +1,102 @@
-# Quick Start - Immediately Applicable Principles
-
-## 5 Core Principles
-
-```
-✅ 📉 Less code means less technical debt
-✅ 🚫 DRY - Don't Repeat Yourself
-✅ 🎯 Single Responsibility Principle (SRP)
-✅ 🙏 YAGNI - You Aren't Gonna Need It
-✅ 🔒 Security first
-```
-
-## Language Configuration
-
-Language settings can be configured in `.sutory/config.json`:
-
-```json
-{
-  "language": "en"  // Options: "en", "ko"
-}
-```
-
-## Checkpoints
-
-### Before Adding New Packages
-
-- [ ] Can it be solved with existing packages?
-- [ ] Is it really necessary?
-- [ ] What is the bundle size impact?
-
-### When Creating Files
-
-- [ ] Verify where it will be used
-- [ ] Add imports immediately
-- [ ] Check for circular dependencies
-
-## Top Priority: Surgical Precision
-
-> **⚠️ This is the first principle that precedes all work.**
->
-> **Never modify/delete code that wasn't requested.**
-
-- **Strict scope adherence**: Only modify files and code blocks explicitly requested by the user
-- **Preserve existing code**: Do not arbitrarily refactor or remove working code
-- **Respect style**: Maintain existing naming, formatting, and comment styles
-
-## Pre-Work Checklist
-
-```
-[x] Follow top priority: Never modify outside request scope
-[ ] Respect existing code: Maintain existing style and structure
-[ ] Follow documentation rules: Adhere to naming, structure guidelines
-```
-
-## Golden Rules
-
-- **Simplicity aesthetics**: Less code is better code
-- **DRY principle**: Don't repeat, reuse
-- **Single responsibility**: One function serves one purpose
-- **Pragmatism**: Practical over perfect, YAGNI spirit
-
-## Code Examples
-
-### Good Example
-
-```python
-# User authentication middleware
-async def authenticate_user(token: str) -> User:
-    """
-    Verify JWT token and return user.
-
-    Args:
-        token: JWT authentication token
-
-    Returns:
-        Authenticated user object
-
-    Raises:
-        HTTPException: When token is invalid
-    """
-    # Verify token
-    payload = decode_jwt(token)
-
-    # Get user
-    user = await get_user(payload["sub"])
-    if not user:
-        raise HTTPException(401, detail="Authentication failed")
-
-    return user
-```
-
-### Bad Example
-
-```python
-# No comments, unclear purpose
-async def auth(t):
-    p = decode_jwt(t)
-    u = await get_user(p["sub"])
-    if not u:
-        raise HTTPException(401)
-    return u
-```
+# Quick Start - Immediately Applicable Principles
+
+## 5 Core Principles
+
+```
+✅ 📉 Less code means less technical debt
+✅ 🚫 DRY - Don't Repeat Yourself
+✅ 🎯 Single Responsibility Principle (SRP)
+✅ 🙏 YAGNI - You Aren't Gonna Need It
+✅ 🔒 Security first
+```
+
+## Language Configuration
+
+Language settings can be configured in `.sutory/config.json`:
+
+```json
+{
+  "language": "en"  // Options: "en", "ko"
+}
+```
+
+## Checkpoints
+
+### Before Adding New Packages
+
+- [ ] Can it be solved with existing packages?
+- [ ] Is it really necessary?
+- [ ] What is the bundle size impact?
+
+### When Creating Files
+
+- [ ] Verify where it will be used
+- [ ] Add imports immediately
+- [ ] Check for circular dependencies
+
+## Top Priority: Surgical Precision
+
+> **⚠️ This is the first principle that precedes all work.**
+>
+> **Never modify/delete code that wasn't requested.**
+
+- **Strict scope adherence**: Only modify files and code blocks explicitly requested by the user
+- **Preserve existing code**: Do not arbitrarily refactor or remove working code
+- **Respect style**: Maintain existing naming, formatting, and comment styles
+
+## Pre-Work Checklist
+
+```
+[x] Follow top priority: Never modify outside request scope
+[ ] Respect existing code: Maintain existing style and structure
+[ ] Follow documentation rules: Adhere to naming, structure guidelines
+```
+
+## Golden Rules
+
+- **Simplicity aesthetics**: Less code is better code
+- **DRY principle**: Don't repeat, reuse
+- **Single responsibility**: One function serves one purpose
+- **Pragmatism**: Practical over perfect, YAGNI spirit
+
+## Code Examples
+
+### Good Example
+
+```python
+# User authentication middleware
+async def authenticate_user(token: str) -> User:
+    """
+    Verify JWT token and return user.
+
+    Args:
+        token: JWT authentication token
+
+    Returns:
+        Authenticated user object
+
+    Raises:
+        HTTPException: When token is invalid
+    """
+    # Verify token
+    payload = decode_jwt(token)
+
+    # Get user
+    user = await get_user(payload["sub"])
+    if not user:
+        raise HTTPException(401, detail="Authentication failed")
+
+    return user
+```
+
+### Bad Example
+
+```python
+# No comments, unclear purpose
+async def auth(t):
+    p = decode_jwt(t)
+    u = await get_user(p["sub"])
+    if not u:
+        raise HTTPException(401)
+    return u
+```