claude-autopm 2.8.1 → 2.8.3

package/autopm/.claude/commands/ui/bootstrap-scaffold.md

@@ -1,65 +0,0 @@
----
-name: bootstrap-scaffold
-type: epic-management
-category: ui
----
-
-claude# Bootstrap UI Scaffold Command
-
-Create a complete Bootstrap-based UI structure with responsive components and themes.
-
-## Command
-```
-/ui:bootstrap-scaffold
-```
-
-## Purpose
-Use the react-ui-expert agent (with framework=bootstrap) to create a complete Bootstrap application scaffold with modern components, responsive design, and customizable themes.
-
-## Parameters
-- `theme`: Theme variant (light, dark, corporate, minimal)
-- `components`: Required components (navbar, cards, forms, modals)
-- `responsive`: Breakpoints to support (sm, md, lg, xl, xxl)
-- `features`: Additional features (dark-mode-toggle, form-validation, animations)
-
-## Agent Usage
-```
-Use the react-ui-expert agent with framework=bootstrap to create a complete Bootstrap application scaffold.
-```
-
-## Expected Outcome
-- Complete HTML structure with Bootstrap components
-- Custom SCSS configuration with theme variables
-- JavaScript for interactive components
-- Responsive design implementation
-- Form validation and accessibility features
-- Dark mode toggle functionality
-
-## Example Usage
-```
-## Required Documentation Access
-
-**MANDATORY:** Before UI framework setup, query Context7 for best practices:
-
-**Documentation Queries:**
-- `mcp://context7/ui/bootstrap` - bootstrap best practices
-- `mcp://context7/ui/tailwind` - tailwind best practices
-- `mcp://context7/frontend/design-systems` - design systems best practices
-- `mcp://context7/css/frameworks` - frameworks best practices
-
-**Why This is Required:**
-- Ensures adherence to current industry standards and best practices
-- Prevents outdated or incorrect implementation patterns
-- Provides access to latest framework/tool documentation
-- Reduces errors from stale knowledge or assumptions
-
-
-Task: Create Bootstrap dashboard with sidebar navigation, responsive cards grid, and contact forms
-Agent: react-ui-expert
-Parameters: framework=bootstrap, theme=corporate, components=navbar,sidebar,cards,forms,modals, responsive=all, features=dark-mode,validation
-```
-
-## Related Agents
-- tailwindcss-expert: For utility-first alternative
-- react-frontend-engineer: For React + Bootstrap integration
-- react-ui-expert: Main agent for UI component architecture

package/autopm/.claude/rules/database-management-strategy.md

@@ -1,17 +0,0 @@
-# Rule: Database Management Strategy
-
-This document outlines the required strategy for managing databases across all project environments.
-
-| Environment         | Tool / Service                  | Lifecycle / Purpose                 | Data Source                               | Persistence               |
-| ------------------- | ------------------------------- | ----------------------------------- | ----------------------------------------- | ------------------------- |
-| **Local (Dev)** | `docker-compose`                | Long-running, per-developer         | Migrations + Developer Seeds              | **Yes** (Named Volume)    |
-| **CI/CD (Tests)** | `kubectl run`                   | **Ephemeral**, per-PR/commit        | Migrations + Test Seeds                   | **No** (Clean for every run) |
-| **Staging** | Managed Cloud DB (e.g., RDS)    | Long-running, shared by team        | Sanitized/Anonymized Production Dump      | **Yes** (Persistent)      |
-| **Production** | Managed Cloud DB (High-Availability) | Long-running, critical user data    | Live User Data                            | **Yes** (HA + Backups)    |
-
-### Key Principles
-
-1. **Local:** Use a named Docker volume to persist data between `docker compose up/down` cycles.
-2. **CI/CD:** The database MUST be created from scratch for every test run to ensure perfect isolation and repeatability. DO NOT use persistent volumes in CI.
-3. **Staging:** The database schema should be an exact mirror of production. Data should be a recent, anonymized copy of production data.
-4. **Migrations:** All schema changes in every environment MUST be handled by a migration tool (e.g., Alembic, Flyway). No manual `ALTER TABLE` commands.

package/autopm/.claude/rules/database-pipeline.md

@@ -1,94 +0,0 @@
-# Database Operations Pipeline
-
-> **CRITICAL**: Database operations require specialized workflows for safety and performance.
-
-## 1. DATABASE MIGRATION PIPELINE
-
-**Trigger**: Any schema change or migration
-**Sequence**:
-
-```
-1. postgresql-expert/mongodb-expert → Analyze current schema
-2. Write migration with rollback plan
-3. test-runner → Test migration on dev database
-4. Create backup verification test
-5. Document migration in changelog
-6. Never run migrations without rollback plan
-```
-
-## 2. QUERY OPTIMIZATION PIPELINE
-
-**Trigger**: Slow query or performance issue
-**Sequence**:
-
-```
-1. postgresql-expert → Analyze query plan (EXPLAIN ANALYZE)
-2. Identify missing indexes or inefficient joins
-3. Write performance test (must show improvement)
-4. Implement optimization
-5. test-runner → Verify no functionality regression
-6. Document optimization in CLAUDE.md
-```
-
-## 3. DATA WAREHOUSE PIPELINE
-
-**Trigger**: BigQuery/CosmosDB implementation
-**Sequence**:
-
-```
-1. bigquery-expert/cosmosdb-expert → Design schema
-2. Create partitioning/sharding strategy
-3. Implement ETL/ELT pipeline
-4. test-runner → Validate data integrity
-5. Monitor costs and performance
-```
-
-## 4. CACHE IMPLEMENTATION PIPELINE
-
-**Trigger**: Redis caching requirement
-**Sequence**:
-
-```
-1. redis-expert → Design cache strategy
-2. Implement cache invalidation logic
-3. Write cache hit/miss tests
-4. test-runner → Verify cache behavior
-5. Monitor memory usage
-```
-
-## 5. DATABASE BACKUP PIPELINE
-
-**Trigger**: Backup strategy implementation
-**Sequence**:
-
-```
-1. Database expert → Design backup strategy
-2. Implement automated backup script
-3. Write restore verification test
-4. test-runner → Test backup and restore
-5. Document recovery procedures
-```
-
-## Pipeline Requirements
-
-### NEVER ALLOWED
-
-- ❌ Running migrations without backups
-- ❌ Deploying unindexed queries to production
-- ❌ Skipping rollback plan creation
-- ❌ Ignoring query performance analysis
-
-### ALWAYS REQUIRED
-
-- ✅ Test migrations on dev first
-- ✅ EXPLAIN ANALYZE for new queries
-- ✅ Monitor query performance
-- ✅ Document schema changes
-- ✅ Verify backup restoration
-
-## Success Metrics
-
-- Query response time < 100ms for OLTP
-- Cache hit rate > 80%
-- Zero data loss during migrations
-- Successful backup restoration test

package/autopm/.claude/rules/ux-design-rules.md

@@ -1,209 +0,0 @@
-# UX Design Rules
-
-## MANDATORY PRINCIPLES
-
-### 1. User-First Approach
-
-- ALWAYS validate designs with user research or testing
-- NEVER assume user behavior without data
-- ALWAYS consider edge cases and error states
-- NEVER sacrifice usability for aesthetics
-
-### 2. Accessibility is Non-Negotiable
-
-- WCAG 2.1 AA is the minimum standard
-- Every interaction must be keyboard accessible
-- Color must never be the only indicator
-- Alt text and ARIA labels are mandatory
-- Test with screen readers
-
-### 3. Performance is UX
-
-- 3-second rule for initial load
-- 100ms response for user interactions
-- Optimize images and assets
-- Implement progressive loading
-- Monitor Core Web Vitals
-
-### 4. Mobile-First Design
-
-- Start with mobile constraints
-- Touch targets minimum 44x44px (iOS) or 48x48px (Android)
-- Consider thumb reach zones
-- Account for various screen sizes
-- Test on real devices
-
-### 5. Consistency Over Creativity
-
-- Follow established patterns in the system
-- Maintain consistent spacing, colors, typography
-- Reuse components before creating new ones
-- Document any new patterns introduced
-
-## PROHIBITED PRACTICES
-
-### Never
-
-- Use placeholder text as labels
-- Disable browser zoom
-- Hide important content behind hover
-- Use auto-playing media with sound
-- Create custom scrollbars without necessity
-- Implement infinite scroll without alternatives
-- Use justified text alignment for body content
-- Create forms without validation feedback
-- Implement dark patterns or deceptive UX
-- Ignore browser back button behavior
-
-## DESIGN EVALUATION CRITERIA
-
-### Before Implementation
-
-1. **Purpose Clear**: Can users understand the purpose within 5 seconds?
-2. **Task Completion**: Can users complete primary tasks without help?
-3. **Error Recovery**: Can users recover from mistakes easily?
-4. **Accessibility**: Does it pass automated accessibility checks?
-5. **Performance**: Will it meet performance budgets?
-
-### After Implementation
-
-1. **Usability Testing**: Has it been tested with real users?
-2. **Analytics Review**: Are success metrics improving?
-3. **Accessibility Audit**: Manual testing completed?
-4. **Device Testing**: Verified on target devices?
-5. **A/B Testing**: Validated against alternatives?
-
-## INFORMATION HIERARCHY
-
-### Content Organization
-
-- F-pattern for text-heavy pages
-- Z-pattern for landing pages
-- Progressive disclosure for complex information
-- Chunking for better comprehension
-- Visual hierarchy through size, color, spacing
-
-### Navigation Rules
-
-- Maximum 7±2 items in primary navigation
-- Breadcrumbs for deep hierarchies
-- Search for content-heavy sites
-- Clear active states
-- Predictable placement
-
-## INTERACTION DESIGN RULES
-
-### Feedback & Response
-
-- Immediate feedback for all interactions (<100ms)
-- Loading indicators for operations >1 second
-- Success/error messages clearly visible
-- Progress indicators for multi-step processes
-- Confirmation for destructive actions
-
-### Form Design
-
-- One column layout for better completion
-- Inline validation where possible
-- Clear error messages with solutions
-- Optional fields clearly marked
-- Smart defaults and auto-complete
-- Progress save for long forms
-
-## VISUAL DESIGN STANDARDS
-
-### Typography
-
-- Maximum 2-3 typefaces
-- 16px minimum for body text
-- 45-75 characters per line for readability
-- 1.5x line height for body text
-- Sufficient contrast (4.5:1 for normal text)
-
-### Color Usage
-
-- Maximum 3-4 primary colors
-- 60-30-10 rule for color distribution
-- Consider color blindness (8% of men)
-- Test in grayscale
-- Maintain brand consistency
-
-### Spacing & Layout
-
-- 8-point grid system
-- Consistent padding and margins
-- Adequate white space (30-40% minimum)
-- Logical grouping with proximity
-- Responsive breakpoints at standard sizes
-
-## CONVERSION OPTIMIZATION
-
-### Call-to-Action
-
-- One primary CTA per view
-- Action-oriented text
-- Contrasting colors
-- Adequate size and padding
-- Above the fold placement for critical CTAs
-
-### Trust Signals
-
-- Security badges for payments
-- Customer testimonials
-- Clear return policies
-- Contact information visible
-- Professional design quality
-
-## TESTING REQUIREMENTS
-
-### Usability Testing
-
-- 5 users minimum for qualitative insights
-- Task-based scenarios
-- Think-aloud protocol
-- Success rate measurement
-- Time-on-task tracking
-
-### A/B Testing
-
-- Statistical significance required
-- Test one variable at a time
-- Run for complete business cycles
-- Consider seasonal variations
-- Document learnings
-
-## DOCUMENTATION STANDARDS
-
-### Design Specifications
-
-- Exact measurements and spacing
-- Color codes and opacity values
-- Font sizes and weights
-- Animation durations and easing
-- Interaction states (hover, active, focus, disabled)
-
-### Handoff Requirements
-
-- Exported assets in required formats
-- Design tokens documented
-- Component behavior described
-- Edge cases specified
-- Accessibility requirements noted
-
-## CONTEXT OPTIMIZATION
-
-### When Analyzing Designs
-
-- Return key issues and recommendations only
-- Prioritize problems by impact
-- Provide specific, actionable feedback
-- Reference established principles
-- Include quick wins and long-term improvements
-
-### When Implementing Designs
-
-- Focus on changed elements only
-- Reference existing patterns
-- Document new patterns created
-- Note accessibility implementations
-- Track performance impacts

package/autopm/.claude/rules/visual-testing.md

@@ -1,223 +0,0 @@
-# Visual Testing & UI Development Standards
-
-> **CRITICAL**: All UI changes require visual verification and testing.
-
-## Quick Visual Check Protocol
-
-**IMMEDIATELY after implementing any front-end change:**
-
-1. **Identify what changed** - Review modified components/pages
-2. **Navigate to affected pages** - Use browser tools or MCP Playwright
-3. **Verify design compliance** - Check against design system/style guide
-4. **Validate feature implementation** - Ensure change fulfills requirements
-5. **Check acceptance criteria** - Review requirements and context
-6. **Capture evidence** - Screenshots at standard viewports:
-   - Mobile: 375px
-   - Tablet: 768px
-   - Desktop: 1440px
-7. **Check for errors** - Review browser console for JavaScript errors
-8. **Test interactions** - Verify hover states, animations, transitions
-
-## Visual Testing Requirements
-
-### Pre-Commit Checklist
-
-```bash
-# Before committing any UI changes:
-- [ ] Responsive design verified (mobile, tablet, desktop)
-- [ ] Cross-browser testing completed (Chrome, Firefox, Safari, Edge)
-- [ ] Accessibility standards met (WCAG 2.1 AA)
-- [ ] Dark mode compatibility (if applicable)
-- [ ] Loading states implemented
-- [ ] Error states designed
-- [ ] Empty states handled
-- [ ] Animation performance optimized (<60fps)
-- [ ] Images optimized and lazy-loaded
-- [ ] Touch targets minimum 44x44px
-```
-
-## Visual Regression Testing
-
-### Implementation with Playwright
-
-```javascript
-// Visual regression test example
-describe('Component Visual Tests', () => {
-  it('should match visual snapshot', async () => {
-    await page.goto('/component');
-    const screenshot = await page.screenshot();
-    expect(screenshot).toMatchImageSnapshot();
-  });
-  
-  it('should handle responsive breakpoints', async () => {
-    const viewports = [375, 768, 1440];
-    for (const width of viewports) {
-      await page.setViewport({ width, height: 800 });
-      const screenshot = await page.screenshot();
-      expect(screenshot).toMatchImageSnapshot(`viewport-${width}`);
-    }
-  });
-  
-  it('should capture interaction states', async () => {
-    // Normal state
-    await page.screenshot({ path: 'button-normal.png' });
-    
-    // Hover state
-    await page.hover('button');
-    await page.screenshot({ path: 'button-hover.png' });
-    
-    // Focus state
-    await page.focus('button');
-    await page.screenshot({ path: 'button-focus.png' });
-  });
-});
-```
-
-## UI/UX Best Practices
-
-### Core Principles
-
-1. **Consistency**: Use established patterns and components
-2. **Feedback**: Provide immediate visual feedback for interactions
-3. **Progressive Enhancement**: Core functionality works without JavaScript
-4. **Performance**: Optimize for perceived performance
-5. **Accessibility**: Design for all users from the start
-
-### CSS Architecture
-
-```scss
-// Follow BEM methodology
-.block {}
-.block__element {}
-.block--modifier {}
-
-// Component structure example
-.card {
-  &__header {}
-  &__body {}
-  &__footer {}
-  
-  &--featured {
-    .card__header {}
-  }
-}
-```
-
-## Component Development Standards
-
-### Component Checklist
-
-```typescript
-// Every UI component must have:
-- [ ] Props validated with TypeScript/PropTypes
-- [ ] Default props defined
-- [ ] Error boundaries implemented
-- [ ] Memoization applied where needed
-- [ ] Accessibility attributes (ARIA)
-- [ ] Keyboard navigation support
-- [ ] RTL support considered
-- [ ] Theme variables used
-- [ ] Storybook story created
-- [ ] Visual regression tests
-- [ ] Unit tests written
-```
-
-## Accessibility Requirements
-
-### WCAG 2.1 AA Compliance
-
-```html
-<!-- Accessibility checklist -->
-- [ ] Semantic HTML used
-- [ ] ARIA labels where needed
-- [ ] Keyboard navigation works
-- [ ] Focus indicators visible
-- [ ] Color contrast ratios met (4.5:1 normal, 3:1 large)
-- [ ] Alt text for images
-- [ ] Form labels associated
-- [ ] Error messages announced
-- [ ] Skip links implemented
-- [ ] Page language declared
-```
-
-### Automated Accessibility Testing
-
-```javascript
-// Using axe-core for automated testing
-import { axe } from '@axe-core/react';
-
-describe('Accessibility', () => {
-  it('should have no violations', async () => {
-    const results = await axe(container);
-    expect(results).toHaveNoViolations();
-  });
-});
-```
-
-## Design System Compliance
-
-### Required Elements
-
-- **Colors**: Use only defined color tokens
-- **Typography**: Use only defined type scales
-- **Spacing**: Use only defined spacing units
-- **Components**: Use existing components before creating new
-- **Icons**: Use icon system, no inline SVGs
-- **Animations**: Use defined timing functions
-
-## Performance Metrics
-
-### Visual Performance Targets
-
-- First Contentful Paint (FCP): < 1.5s
-- Largest Contentful Paint (LCP): < 2.5s
-- Cumulative Layout Shift (CLS): < 0.1
-- First Input Delay (FID): < 100ms
-- Time to Interactive (TTI): < 5s
-
-## Agent Integration
-
-### Required Agents for Visual Testing
-
-- **frontend-testing-engineer**: Visual regression tests
-- **frontend-testing-engineer**: Browser automation
-- **react-frontend-engineer**: Component development
-- **code-analyzer**: Review UI code quality
-
-### Visual Testing Pipeline
-
-```
-1. Implement UI change following TDD
-2. frontend-testing-engineer → Create visual tests
-3. Run visual regression tests at all breakpoints
-4. code-analyzer → Verify accessibility
-5. Capture screenshots for PR
-6. Document visual changes
-```
-
-## Screenshot Documentation
-
-### When to Include Screenshots
-
-- ✅ Any UI/UX change
-- ✅ New components or features
-- ✅ Style or layout modifications
-- ✅ Responsive design updates
-- ✅ Animation or interaction changes
-- ✅ Error or edge case handling
-
-### Screenshot Requirements
-
-- Show before and after states
-- Include all responsive breakpoints
-- Capture interaction states
-- Annotate important changes
-- Use consistent naming convention
-
-## Success Metrics
-
-- ✅ 100% visual test coverage for UI components
-- ✅ Zero visual regressions in production
-- ✅ All accessibility tests passing
-- ✅ Performance budgets maintained
-- ✅ Design system compliance verified