claude-autopm 2.8.1 → 2.8.3

package/packages/plugin-core/rules/golden-rules.md

@@ -0,0 +1,181 @@
+# 🏆 Golden Rules of Development
+
+> **These are the fundamental truths that guide all development decisions.**
+
+## The 12 Golden Rules
+
+### 1. **If it's not tested, it's broken**
+
+Every piece of code must have tests. No exceptions.
+
+### 2. **If it's not documented, it doesn't exist**
+
+Undocumented features are unknown features. Document as you build.
+
+### 3. **If it's not in version control, it didn't happen**
+
+All work must be committed. No local-only changes.
+
+### 4. **If it's not monitored, it's not production-ready**
+
+You can't fix what you can't see. Monitor everything.
+
+### 5. **If it's not secure, it's not shippable**
+
+Security is not optional. Every release must be secure.
+
+### 6. **If it's not accessible, it's not complete**
+
+Accessibility is a requirement, not a nice-to-have.
+
+### 7. **If it's not performant, it's not acceptable**
+
+Performance is a feature. Slow is broken.
+
+### 8. **If it's not maintainable, it's technical debt**
+
+Write code for the next developer (it might be you).
+
+### 9. **If it's not reviewed, it's not ready**
+
+All code needs a second pair of eyes. No solo commits to main.
+
+### 10. **If it's not automated, it's not scalable**
+
+Manual processes don't scale. Automate everything.
+
+### 11. **If it's not responsive, it's not modern**
+
+Mobile-first is not optional in 2024+.
+
+### 12. **If it's not user-friendly, it's not finished**
+
+User experience trumps developer convenience.
+
+## Application of Golden Rules
+
+### During Development
+
+- Before writing code: Which rules apply?
+- During implementation: Am I violating any rules?
+- Before committing: Have I satisfied all rules?
+- During review: Check against all 12 rules
+
+### In Code Reviews
+
+Use golden rules as review criteria:
+
+```markdown
+## Review Checklist
+- [ ] Rule #1: Tests written and passing
+- [ ] Rule #2: Documentation updated
+- [ ] Rule #3: Changes committed properly
+- [ ] Rule #4: Monitoring in place
+- [ ] Rule #5: Security reviewed
+- [ ] Rule #6: Accessibility verified
+- [ ] Rule #7: Performance acceptable
+- [ ] Rule #8: Code is maintainable
+- [ ] Rule #9: Peer reviewed
+- [ ] Rule #10: Automation added
+- [ ] Rule #11: Responsive design
+- [ ] Rule #12: UX considered
+```
+
+### In Architecture Decisions
+
+Every architectural decision must:
+
+1. Not violate any golden rule
+2. Support multiple golden rules
+3. Make following rules easier
+
+## Rule Prioritization
+
+When rules conflict (rare but possible):
+
+### Priority 1: Safety & Security
+
+- Rule #5 (Security)
+- Rule #1 (Testing)
+
+### Priority 2: User Impact
+
+- Rule #12 (User-friendly)
+- Rule #6 (Accessibility)
+- Rule #7 (Performance)
+
+### Priority 3: Sustainability
+
+- Rule #8 (Maintainable)
+- Rule #2 (Documentation)
+- Rule #10 (Automation)
+
+### Priority 4: Process
+
+- Rule #3 (Version control)
+- Rule #9 (Review)
+- Rule #4 (Monitoring)
+- Rule #11 (Responsive)
+
+## Enforcement
+
+### Automatic Checks
+
+- CI/CD pipeline enforces rules #1, #3, #5, #7
+- Linters enforce rule #8
+- Accessibility tools enforce rule #6
+- Design tools enforce rule #11
+
+### Manual Verification
+
+- Code review enforces rules #2, #9, #12
+- Architecture review enforces rule #10
+- Security review enforces rule #5
+- UX review enforces rules #6, #11, #12
+
+## Consequences of Violation
+
+### Immediate Action Required
+
+- **Rule #1 violation**: Block deployment
+- **Rule #5 violation**: Security incident process
+- **Rule #6 violation**: Accessibility fix required
+
+### Fix in Current Sprint
+
+- **Rule #2 violation**: Documentation debt ticket
+- **Rule #7 violation**: Performance optimization ticket
+- **Rule #8 violation**: Refactoring ticket
+
+### Track and Improve
+
+- **Rule #4 violation**: Add monitoring
+- **Rule #10 violation**: Automation backlog
+- **Rule #11 violation**: Responsive design update
+
+## Quick Reference
+
+```bash
+# Before starting work
+"What rules apply to this task?"
+
+# During implementation
+"Am I following all applicable rules?"
+
+# Before committing
+"Have I validated against all 12 rules?"
+
+# During review
+"Does this PR satisfy the golden rules?"
+
+# In production
+"Are we monitoring rule compliance?"
+```
+
+## Remember
+
+**Excellence is not a skill, it's an attitude.**
+
+These rules are not suggestions—they are the foundation of quality software. Every line of code is an opportunity to uphold these standards. When in doubt, refer to the rules. When facing a decision, let the rules guide you.
+
+**Quality is everyone's responsibility.**

package/packages/plugin-core/rules/naming-conventions.md

@@ -0,0 +1,111 @@
+# Naming Conventions and Code Standards
+
+> **CRITICAL**: Consistent naming and zero technical debt. No exceptions.
+
+## Absolute Naming Prohibitions
+
+### NEVER USE These Suffixes
+
+- ❌ `_advanced`, `_fixed`, `_improved`, `_new`, `_old`
+- ❌ `_v2`, `_v3`, `_backup`, `_copy`, `_temp`
+- ❌ `_updated`, `_modified`, `_changed`
+- ❌ Generic suffixes that don't describe function
+- ❌ Version numbers in names (use git for versioning)
+
+### NEVER CREATE These Documentation Files
+
+- ❌ `CHANGES_[DATE]_[FEATURE].md`
+- ❌ `SUMMARY_OBJECTIVE_[N].md`
+- ❌ `WORKFLOW_SETUP_GUIDE.md`
+- ❌ One-off documentation files for single changes
+- ❌ Documentation files unless explicitly requested
+- ❌ Temporary explanation files
+
+## Required Naming Patterns
+
+### Before ANY Implementation
+
+1. Check existing codebase for naming patterns
+2. Read naming conventions from existing code
+3. Follow established patterns exactly
+4. When in doubt, search for similar functions
+
+### Function/Variable Naming
+
+- Use descriptive names that explain purpose
+- Follow language-specific conventions (camelCase, snake_case)
+- Maintain consistency with existing codebase
+- Prefer clarity over brevity
+
+### File Naming
+
+- Match existing file naming patterns
+- Use semantic names that describe content
+- No temporary or versioned file names
+- Keep extensions consistent
+
+## Code Quality Standards
+
+### NEVER TOLERATE
+
+- ❌ Partial implementations
+- ❌ "Simplified" code with TODOs
+- ❌ Duplicate functions (always search first)
+- ❌ Mixed concerns (UI with DB, validation with API)
+- ❌ Resource leaks (unclosed connections, listeners)
+- ❌ Dead code (unused functions, imports)
+- ❌ Inconsistent formatting
+
+### ALWAYS ENFORCE
+
+- ✅ Single responsibility principle
+- ✅ Proper separation of concerns
+- ✅ Resource cleanup (close connections, clear timeouts)
+- ✅ Consistent error handling
+- ✅ Meaningful variable names
+- ✅ DRY principle (Don't Repeat Yourself)
+
+## Anti-Pattern Prevention
+
+### Over-Engineering
+
+- Don't add unnecessary abstractions
+- Don't create factory patterns when simple functions work
+- Don't add middleware for trivial operations
+- Don't think "enterprise" when you need "working"
+
+### Under-Engineering
+
+- Don't skip error handling
+- Don't ignore edge cases
+- Don't hardcode values that should be configurable
+- Don't assume happy path only
+
+## Code Review Checklist
+
+Before ANY commit:
+
+1. No naming convention violations
+2. No duplicate code
+3. No resource leaks
+4. No mixed concerns
+5. No partial implementations
+6. No unnecessary complexity
+7. All tests passing
+
+## Enforcement
+
+### Discovery of Violation
+
+1. Stop current work immediately
+2. Fix naming to match conventions
+3. Remove any duplicate code
+4. Clean up resources properly
+5. Document pattern in CLAUDE.md
+
+### Prevention Strategy
+
+- Always search before creating new functions
+- Always read existing code for patterns
+- Always use agents for code analysis
+- Never assume, always verify

package/packages/plugin-core/rules/no-pr-workflow.md

@@ -0,0 +1,183 @@
+# Hybrid Development Workflow
+
+## FLEXIBLE DEVELOPMENT STRATEGY
+
+**This project supports both direct commits and Pull Requests, adapting to different scenarios and team needs.**
+
+## Workflow Options
+
+### 1. Direct to Main (Trunk-Based)
+**When to use:**
+- ✅ You're a trusted core contributor
+- ✅ Making hotfixes or critical patches
+- ✅ Small, low-risk changes
+- ✅ Documentation updates
+- ✅ Working solo or in a small, high-trust team
+
+**Process:**
+```bash
+# Ensure main is up to date
+git checkout main
+git pull origin main
+
+# Make changes
+# ... edit files ...
+
+# Run tests locally
+npm test
+
+# Commit and push directly
+git add .
+git commit -m "fix: resolve critical issue"
+git push origin main
+```
+
+### 2. Pull Request Workflow
+**When to use:**
+- ✅ You're an external contributor
+- ✅ Making major features or breaking changes
+- ✅ Changes need review or discussion
+- ✅ Working in a larger team
+- ✅ Updating dependencies
+
+**Process:**
+```bash
+# Create feature branch
+git checkout -b feat/new-feature
+
+# Make changes
+# ... edit files ...
+
+# Commit and push to branch
+git add .
+git commit -m "feat: add new feature"
+git push origin feat/new-feature
+
+# Open PR on GitHub
+```
+
+## Decision Matrix
+
+| Scenario | Direct Commit | Pull Request |
+|----------|--------------|--------------|
+| **Hotfix** | ✅ Preferred | Use if complex |
+| **Documentation** | ✅ Preferred | Optional |
+| **Minor feature** | ✅ Allowed | Recommended |
+| **Major feature** | ❌ Discouraged | ✅ Required |
+| **Breaking change** | ❌ Not allowed | ✅ Required |
+| **External contributor** | ❌ Not allowed | ✅ Required |
+| **Dependency update** | ⚠️ Use caution | ✅ Preferred |
+| **Experimental work** | ❌ Not allowed | ✅ Required |
+
+## Commit Guidelines
+
+### Commit Message Format
+Always use conventional commits regardless of workflow:
+- `feat:` New feature
+- `fix:` Bug fix
+- `docs:` Documentation
+- `style:` Formatting
+- `refactor:` Code restructuring
+- `test:` Testing
+- `chore:` Maintenance
+
+### Before Any Push
+1. **Run tests locally**: `npm test`
+2. **Check linting**: `npm run lint`
+3. **Verify build**: `npm run build`
+4. **Pull latest changes**: `git pull origin main`
+
+## Branch Protection Settings
+
+### Main Branch
+- ✅ Allow direct commits from administrators
+- ✅ Require status checks for PRs
+- ✅ Run CI/CD on both direct commits and PRs
+- ❌ Do NOT require PRs for all changes
+
+### Feature Branches
+- Naming: `feat/*`, `fix/*`, `docs/*`, `chore/*`
+- Auto-delete after merge
+- Can be force-pushed by creator
+
+## CI/CD Behavior
+
+### On Direct Commits
+- Run essential tests quickly
+- Deploy if tests pass
+- Rollback on failure
+
+### On Pull Requests
+- Run comprehensive test suite
+- Generate coverage reports
+- Preview deployments (if applicable)
+- Security scanning
+
+## Safety Measures
+
+Both workflows maintain quality through:
+- **Pre-commit hooks** for formatting and linting
+- **Automated testing** on every push
+- **Rollback capability** via git tags
+- **Protected credentials** via secrets management
+
+## Team Evolution Path
+
+Teams can adapt their workflow over time:
+
+1. **Starting Out** → Use PRs for everything
+2. **Building Trust** → Allow direct commits for docs
+3. **High Trust** → Direct commits for most changes
+4. **Optimal** → Hybrid based on change type
+
+## Git Aliases for Efficiency
+
+```bash
+# Add to ~/.gitconfig
+[alias]
+    # Direct commit and push
+    dcp = !git add . && git commit -m "$1" && git push origin main
+
+    # Create PR branch
+    pr = checkout -b
+
+    # Update main
+    update = !git checkout main && git pull origin main
+
+    # Quick status
+    st = status -sb
+```
+
+## Key Benefits
+
+### Direct Commits
+- 🚀 Maximum speed
+- 🎯 Minimal overhead
+- ⚡ Instant integration
+
+### Pull Requests
+- 🔍 Code review
+- 💬 Discussion platform
+- 📝 Change documentation
+- 🛡️ Additional safety
+
+## Important Notes
+
+1. **This is intentional design** - Supporting both workflows provides flexibility
+2. **Choose based on context** - Not all changes are equal
+3. **Trust is earned** - Start with PRs, earn direct commit access
+4. **Quality over speed** - When in doubt, use a PR
+
+## Migration Support
+
+### From PR-Only
+- Grant direct access gradually
+- Start with documentation commits
+- Monitor quality metrics
+
+### From Direct-Only
+- Introduce PRs for major changes
+- Use branch protection rules
+- Educate on PR benefits
+
+This hybrid approach ensures the project can adapt to different team sizes, trust levels, and development phases while maintaining code quality and velocity.

package/packages/plugin-core/rules/pipeline-mandatory.md

@@ -0,0 +1,109 @@
+# Mandatory Pipeline Execution
+
+> **CRITICAL**: These pipelines are MANDATORY for specific scenarios. No exceptions.
+
+## 1. ERROR HANDLING PIPELINE
+
+**Trigger**: ANY error encountered
+**Sequence**:
+
+```
+1. code-analyzer → Identify root cause and affected files
+2. code-analyzer → Implement fix following TDD:
+   - Write failing test (RED)
+   - Implement minimum code to pass (GREEN)
+   - Refactor while tests pass (REFACTOR)
+3. test-runner → Verify fix across entire codebase
+4. file-analyzer → Document fix in error log
+5. Update CLAUDE.md with new error pattern
+```
+
+## 2. FEATURE IMPLEMENTATION PIPELINE
+
+**Trigger**: Any new feature request
+**Sequence**:
+
+```
+1. /pm:issue-analyze → Decompose into work streams
+2. parallel-worker → Spawn sub-agents for each stream:
+   - Write failing tests first (RED phase)
+   - Implement minimal solution (GREEN phase)
+   - Refactor for quality (REFACTOR phase)
+3. test-runner → Run full test suite
+4. code-analyzer → Review for bugs and edge cases
+5. Update README.md with feature documentation
+6. Update CLAUDE.md with new patterns learned
+```
+
+## 3. BUG FIX PIPELINE
+
+**Trigger**: Bug reported or discovered
+**Sequence**:
+
+```
+1. code-analyzer → Trace bug through codebase
+2. Write test that reproduces bug (must fail)
+3. code-analyzer → Implement fix
+4. test-runner → Verify fix doesn't break other tests
+5. test-runner → Run regression tests
+6. Document bug pattern in CLAUDE.md
+```
+
+## 4. CODE SEARCH/RESEARCH PIPELINE
+
+**Trigger**: Any code exploration need
+**Sequence**:
+
+```
+1. code-analyzer → Initial search and analysis
+2. file-analyzer → Summarize findings
+3. Never use grep/find directly - always use agents
+```
+
+## 5. LOG/OUTPUT ANALYSIS PIPELINE
+
+**Trigger**: Verbose outputs or logs to analyze
+**Sequence**:
+
+```
+1. file-analyzer → Extract critical information
+2. Return only actionable insights (10-20% of original)
+3. Never dump raw logs to main conversation
+```
+
+## 6. EMERGENCY DEBUG PIPELINE
+
+**Trigger**: Critical blocker or production issue
+**Sequence**:
+
+```
+1. /pm:blocked → Document blocker
+2. code-analyzer → Trace bug through codebase
+3. Write failing test → Reproduce issue (RED)
+4. Fix implementation → Make test pass (GREEN)
+5. test-runner → Verify no regressions
+6. /pm:issue-close → Mark resolved
+```
+
+## Pipeline Bypass Violations
+
+### NEVER ALLOWED
+
+- ❌ Skipping any step in a pipeline
+- ❌ Using direct commands instead of agents
+- ❌ Implementing without the required pipeline
+- ❌ Merging code without pipeline completion
+
+### Enforcement
+
+- Pipelines are atomic - all steps or none
+- Each step must complete before next
+- Failures require pipeline restart
+- No manual overrides permitted
+
+## Success Verification
+
+- Pipeline completion logged
+- All agents return success codes
+- Tests pass at pipeline end
+- Documentation updated as required