appiq-solution 1.4.7 → 1.4.9

package/SuperClaude/.claude/commands/shared/research-first.yml

@@ -1,278 +0,0 @@
-# Research-First Professional Standards
-
-## Mandatory Research Triggers [C:10]
-
-```yaml
-External_Libraries:
-  Detection_Patterns:
-    - import .* from ['"][^./]['"]  # Non-relative imports
-    - require\(['"][^./]['"]  # CommonJS non-relative
-    - from (\w+) import  # Python imports
-    - using \w+;  # C# namespaces
-    - implementation ['"].*:.*['"]  # Gradle dependencies
-    
-  Required_Research:
-    JS/TS:
-      - React: hooks, components, state mgmt
-      - Vue: composition API, directives, reactivity
-      - Angular: services, DI, modules
-      - Express: middleware, routing, error handling
-      - Next.js: SSR, SSG, API routes, app dir
-      - Node.js: built-in modules, streams, cluster
-    
-    Python:
-      - Django: models, views, middleware, admin
-      - Flask: blueprints, extensions, request handling
-      - FastAPI: dependency injection, async, pydantic
-      - NumPy/Pandas: array operations, dataframes
-      - TensorFlow/PyTorch: models, training, deployment
-    
-    Other:
-      - Database: SQL syntax, ORM patterns, migrations
-      - Cloud: AWS/GCP/Azure service APIs
-      - Testing: framework-specific assertions, mocks
-      - Build tools: webpack, vite, rollup configs
-
-Component_Creation:
-  UI_Keywords:
-    - button, form, modal, dialog, dropdown
-    - table, list, grid, card, accordion
-    - nav, menu, sidebar, header, footer
-    - chart, graph, visualization, dashboard
-    
-  Required_Actions:
-    - Check existing components in project
-    - Search design system if available
-    - Use Magic builder for new components
-    - WebSearch for accessibility patterns
-    - Verify responsive design requirements
-
-API_Integration:
-  Patterns:
-    - REST: endpoints, methods, authentication
-    - GraphQL: queries, mutations, schemas
-    - WebSocket: events, connections, protocols
-    - SDK/Client: initialization, methods, errors
-    
-  Required_Checks:
-    - Official API documentation
-    - Authentication methods
-    - Rate limits and quotas
-    - Error response formats
-    - Versioning and deprecations
-```
-
-## Implementation Blockers
-
-```yaml
-Guessing_Indicators:
-  Phrases_To_Block:
-    - "might work"
-    - "should probably"
-    - "I think this"
-    - "typically would"
-    - "usually looks like"
-    - "common pattern is"
-    - "often implemented as"
-    
-  Required_Instead:
-    - "According to [source]"
-    - "Documentation states"
-    - "Official example shows"
-    - "Verified pattern from"
-    - "Testing confirms"
-
-Confidence_Requirements:
-  Minimum_Score: 90%
-  
-  Evidence_Types:
-    Official_Docs: 100%
-    Tutorial_From_Maintainer: 95%
-    Recent_Blog_Post: 85%
-    Stack_Overflow_Accepted: 80%
-    GitHub_Issue_Resolution: 85%
-    No_Evidence: 0% (BLOCK)
-    
-  Score_Calculation:
-    - Must have at least one 95%+ source
-    - Multiple 80%+ sources can combine
-    - Age penalty: -5% per year old
-    - Verification: Test/example adds +10%
-```
-
-## Research Workflows
-
-```yaml
-Library_Research_Flow:
-  1. Detect library reference in code/request
-  2. Check if already in package.json/requirements
-  3. C7 resolve-library-id → get-docs
-  4. If C7 fails → WebSearch "library official docs"
-  5. Extract key patterns:
-     - Installation method
-     - Basic usage examples
-     - Common patterns
-     - Error handling
-     - Best practices
-  6. Cache results for session
-  7. Cite sources in implementation
-
-Component_Research_Flow:
-  1. Identify UI component need
-  2. Search existing codebase first
-  3. Check project's component library
-  4. Magic builder search with keywords
-  5. If no match → WebSearch "component accessibility"
-  6. Implement with citations
-  7. Note any deviations from patterns
-
-API_Research_Flow:
-  1. Identify API/service to integrate
-  2. WebSearch "service official API docs"
-  3. Find authentication documentation
-  4. Locate endpoint references
-  5. Check for SDK/client library
-  6. Review error handling patterns
-  7. Note rate limits and constraints
-```
-
-## Professional Standards
-
-```yaml
-Source_Attribution:
-  Required_Format: "// Source: [URL or Doc Reference]"
-  
-  Placement:
-    - Above implementation using pattern
-    - In function documentation
-    - In commit messages for new patterns
-    
-Citation_Examples:
-  Good:
-    - "// Source: React docs - https://react.dev/reference/react/useState"
-    - "// Pattern from: Express.js error handling guide"
-    - "// Based on: AWS S3 SDK documentation v3"
-    
-  Bad:
-    - "// Common pattern"
-    - "// Standard approach"
-    - "// Typical implementation"
-
-Uncertainty_Handling:
-  When_Docs_Unavailable:
-    - State explicitly: "Documentation not found for X"
-    - Provide rationale: "Using pattern similar to Y because..."
-    - Mark as provisional: "// TODO: Verify when docs available"
-    - Suggest alternatives: "Consider using documented library Z"
-    
-  When_Multiple_Patterns:
-    - Show options: "Documentation shows 3 approaches:"
-    - Explain tradeoffs: "Option A is simpler but less flexible"
-    - Recommend based on context: "For this use case, B is optimal"
-    - Cite each source
-```
-
-## Enforcement Mechanisms
-
-```yaml
-Pre_Implementation_Checks:
-  Parse_Code_For:
-    - Import statements
-    - Function calls to external libs
-    - Component definitions
-    - API endpoint references
-    
-  Block_If:
-    - External library with no research
-    - New component type without pattern check
-    - API usage without documentation
-    - Confidence score below 90%
-    
-  Warning_If:
-    - Documentation is >2 years old
-    - Using deprecated patterns
-    - Multiple conflicting sources
-    - Community solution vs official
-
-Session_Research_Cache:
-  Store:
-    - Library: version, patterns, examples
-    - Components: accessibility, variants
-    - APIs: endpoints, auth, limits
-    
-  Reuse:
-    - Same library → use cached patterns
-    - Note: "Using previously researched pattern"
-    - Invalidate on version change
-
-Integration_Points:
-  Commands:
-    - build: Check all imports
-    - improve: Verify optimization patterns  
-    - troubleshoot: Search known issues first
-    - design: Research architectural patterns
-    
-  Personas:
-    - frontend: Extra UI/UX research
-    - backend: API/database patterns
-    - architect: System design patterns
-    - security: Vulnerability databases
-```
-
-## Examples
-
-```yaml
-Good_Implementation:
-  Request: "Add user authentication to Express app"
-  
-  Research_Steps:
-    1. C7 resolve-library-id("express")
-    2. C7 get-docs(topic: "authentication middleware")
-    3. WebSearch "express session best practices 2024"
-    4. Check project for existing auth patterns
-    
-  Implementation:
-    ```javascript
-    // Source: Express.js docs - https://expressjs.com/en/guide/using-middleware.html
-    // Pattern: Session-based authentication with secure defaults
-    
-    const session = require('express-session');
-    const MongoStore = require('connect-mongo');
-    
-    // Source: OWASP session management cheat sheet
-    app.use(session({
-      secret: process.env.SESSION_SECRET,
-      resave: false,
-      saveUninitialized: false,
-      cookie: {
-        secure: process.env.NODE_ENV === 'production',
-        httpOnly: true,
-        maxAge: 1000 * 60 * 60 * 24 // 24 hours
-      },
-      store: MongoStore.create({
-        mongoUrl: process.env.MONGODB_URI
-      })
-    }));
-    ```
-
-Bad_Implementation_Blocked:
-  Request: "Add user authentication to Express app"
-  
-  Without_Research:
-    ```javascript
-    // BLOCKED: No documentation reference
-    // This might work for authentication
-    app.use((req, res, next) => {
-      if (req.session && req.session.user) {
-        next();
-      } else {
-        res.redirect('/login');
-      }
-    });
-    ```
-    
-  Error: "External library usage requires documentation. Please research Express.js authentication patterns first."
-```
-
----
-*Research-First: Ensuring professional, evidence-based implementations*

package/SuperClaude/.claude/commands/shared/session-recovery.yml

@@ -1,144 +0,0 @@
-# session-recovery.yml - Session Recovery & Context Preservation
-
-## Startup Detection
-```yaml
-scan_on_startup:
-  locations:
-    - ./claudedocs/tasks/in-progress/*.md
-    - ./claudedocs/tasks/pending/*.md (overdue)
-  
-  parse_tasks:
-    - extract metadata
-    - check git branch status
-    - identify next steps
-    - restore context variables
-    
-  recovery_prompt:
-    found_tasks: "Found {count} active tasks. Resume work?"
-    no_tasks: "No active tasks found. Ready for new work."
-    overdue: "Task {id} overdue. Continue or reschedule?"
-```
-
-## Context Preservation
-```yaml
-session_state:
-  file_paths: currently modified files
-  variables: important data & settings
-  decisions: architectural choices made
-  blockers: issues & solutions attempted
-  
-auto_save_triggers:
-  - major code changes
-  - before risky operations
-  - session timeout warnings
-  - manual /task:pause
-  
-context_format:
-  ```yaml
-  session_state:
-    current_files: [path1, path2]
-    key_variables:
-      api_endpoint: "https://api.example.com"
-      database_name: "myapp_prod"
-    decisions:
-      - "Used React over Vue for better team familiarity"
-      - "Chose PostgreSQL for ACID compliance"
-    blockers:
-      - issue: "CORS error on API calls"
-        attempted: ["added headers", "proxy setup"]
-        solution: "needed server-side CORS config"
-  ```
-```
-
-## Hybrid Recovery Process  
-```yaml
-step_1_identify:
-  - scan ./claudedocs/tasks/in-progress/
-  - parse task metadata
-  - check git branch status
-  - validate file existence
-  - restore previous TodoWrite state
-
-step_2_restore_both_systems:
-  task_context:
-    - load session context
-    - summarize previous work
-    - identify blocking issues
-  todo_context:
-    - regenerate TodoWrite from task breakdown
-    - identify last completed todo
-    - set current focus todo
-    - preserve todo progress
-
-step_3_seamless_resume:
-  no_prompts: true
-  auto_continue: true
-  template: |
-    Resuming {task_title} - working on: {current_todo}
-    Progress: {completed_todos}/{total_todos} todos, {task_progress}% complete
-    
-hybrid_state_restoration:
-  both_systems_sync:
-    - task provides persistence
-    - todos provide immediate focus
-    - progress tracked in both
-    - no duplication of effort
-```
-
-## Git Integration
-```yaml
-branch_tracking:
-  - verify branch exists
-  - check for uncommitted changes
-  - identify merge conflicts
-  - track remote status
-  
-checkpoint_restoration:
-  - list available checkpoints
-  - show diff since last checkpoint
-  - offer rollback options
-  - suggest merge strategies
-```
-
-## Session Break Handling
-```yaml
-graceful_pause:
-  auto_triggers:
-    - context >90% full
-    - long inactivity
-    - error thresholds
-    
-  pause_actions:
-    - save current context
-    - create git checkpoint
-    - update progress status
-    - log session summary
-    
-  resume_preparation:
-    - validate environment
-    - check dependencies
-    - restore file states
-    - prepare tools
-```
-
-## Multi-Task Management
-```yaml
-concurrent_tasks:
-  max_active: 3
-  priority_rules:
-    - high priority blocks others
-    - related tasks can be parallel
-    - different areas can overlap
-    
-task_switching:
-  - auto-save current context
-  - create checkpoint
-  - switch git branch
-  - restore new context
-  
-conflict_resolution:
-  - file modification conflicts
-  - git merge requirements
-  - dependency overlaps
-  - resource constraints
-```

package/SuperClaude/.claude/commands/shared/severity-levels.yml

@@ -1,252 +0,0 @@
-# Severity Levels & Response Standards
-
-## Legend
-| Symbol | Meaning | | Abbrev | Meaning |
-|--------|---------|---|--------|---------|
-| 🚨 | critical/urgent | | sev | severity |
-| ⚠ | warning/caution | | resp | response |
-| ℹ | information | | act | action |
-| ✅ | success/ok | | esc | escalation |
-
-## Universal Severity Classification
-
-```yaml
-Severity_Levels:
-  CRITICAL [10]:
-    Definition: "Data loss, security breach, production down, system compromise"
-    Response: "Immediate stop, alert, rollback, incident response"
-    Recovery: "Manual intervention required, full investigation"
-    Escalation: "Immediate user notification + system halt"
-    Examples:
-      - Security vulnerabilities being committed
-      - Data deletion without backup
-      - Production system failures
-      - Credential exposure
-      - System corruption
-    
-  HIGH [7-9]:
-    Definition: "Build failure, test failure, deployment issues, significant bugs"
-    Response: "Stop workflow, notify user, suggest fixes"
-    Recovery: "Automated retry with backoff, alternative paths"
-    Escalation: "User notification + corrective action required"
-    Examples:
-      - Compilation errors
-      - Test suite failures
-      - Deployment rollbacks
-      - API integration failures
-      - Major functionality breaks
-    
-  MEDIUM [4-6]:
-    Definition: "Warning conditions, performance degradation, code quality issues"
-    Response: "Continue with warning, log for later review"
-    Recovery: "Attempt optimization, monitor for escalation"
-    Escalation: "Log warning + optional user notification"
-    Examples:
-      - Performance bottlenecks
-      - Code quality violations
-      - Deprecated API usage
-      - Configuration warnings
-      - Non-critical dependency issues
-    
-  LOW [1-3]:
-    Definition: "Info messages, style violations, minor optimizations, suggestions"
-    Response: "Note in output, continue execution"
-    Recovery: "Background fixes, cleanup on completion"
-    Escalation: "Silent logging only"
-    Examples:
-      - Code style violations
-      - Minor optimization opportunities
-      - Documentation suggestions
-      - Informational messages
-      - Best practice recommendations
-```
-
-## Response Time Requirements
-
-```yaml
-Response_Times:
-  CRITICAL [10]:
-    Detection_Time: "Immediate (real-time)"
-    Response_Time: "< 1 second"
-    User_Notification: "Immediate blocking alert"
-    
-  HIGH [7-9]:
-    Detection_Time: "< 5 seconds"
-    Response_Time: "< 10 seconds"
-    User_Notification: "Immediate non-blocking alert"
-    
-  MEDIUM [4-6]:
-    Detection_Time: "< 30 seconds"
-    Response_Time: "< 60 seconds"
-    User_Notification: "End of operation summary"
-    
-  LOW [1-3]:
-    Detection_Time: "Background monitoring"
-    Response_Time: "Batch processing"
-    User_Notification: "Optional reporting"
-```
-
-## Context-Specific Severity Mapping
-
-```yaml
-Development_Context:
-  File_Operations:
-    File_Not_Found: "HIGH [8] - blocks workflow"
-    Permission_Denied: "HIGH [7] - requires intervention"
-    File_Lock_Conflict: "MEDIUM [5] - retry possible"
-    Large_File_Warning: "LOW [2] - informational"
-    
-  Code_Quality:
-    Syntax_Error: "HIGH [9] - prevents execution"
-    Type_Error: "HIGH [8] - runtime failure likely"
-    Unused_Variable: "MEDIUM [4] - code quality"
-    Style_Violation: "LOW [2] - cosmetic issue"
-    
-  Git_Operations:
-    Merge_Conflict: "HIGH [8] - manual resolution required"
-    Uncommitted_Changes: "MEDIUM [6] - data loss possible"
-    Branch_Behind: "MEDIUM [5] - sync recommended"
-    Clean_Working_Tree: "LOW [1] - status information"
-
-Security_Context:
-  Credential_Exposure:
-    Hardcoded_API_Key: "CRITICAL [10] - immediate security risk"
-    Password_In_Code: "CRITICAL [10] - credential leak"
-    Weak_Authentication: "HIGH [8] - security vulnerability"
-    HTTP_vs_HTTPS: "MEDIUM [6] - protocol downgrade"
-    
-  Vulnerability_Detection:
-    Known_CVE: "CRITICAL [10] - exploit available"
-    Dependency_Alert: "HIGH [8] - update required"
-    Insecure_Config: "HIGH [7] - hardening needed"
-    Security_Header_Missing: "MEDIUM [5] - best practice"
-
-Operations_Context:
-  Deployment:
-    Health_Check_Failed: "CRITICAL [10] - service down"
-    Database_Connection_Lost: "CRITICAL [10] - data access failure"
-    Memory_Exhaustion: "HIGH [9] - service degradation"
-    Slow_Response_Time: "MEDIUM [6] - performance issue"
-    
-  Performance:
-    CPU_Spike: "HIGH [8] - resource exhaustion"
-    Memory_Leak: "HIGH [7] - gradual degradation"
-    Cache_Miss_Rate: "MEDIUM [5] - efficiency concern"
-    Log_Volume_High: "LOW [3] - monitoring alert"
-```
-
-## Automated Response Actions
-
-```yaml
-CRITICAL_Responses:
-  Immediate_Actions:
-    - Stop all operations immediately
-    - Create emergency checkpoint
-    - Block further execution
-    - Generate incident report
-    - Alert user with full context
-    
-  Recovery_Actions:
-    - Rollback to last known good state
-    - Isolate affected components
-    - Enable safe mode operation
-    - Require manual intervention
-    
-HIGH_Responses:
-  Immediate_Actions:
-    - Pause current operation
-    - Attempt automatic fix
-    - Log detailed error information
-    - Notify user of issue and resolution attempt
-    
-  Recovery_Actions:
-    - Retry with alternative approach
-    - Escalate if retry fails
-    - Provide user with fix options
-    - Continue with degraded functionality if safe
-
-MEDIUM_Responses:
-  Immediate_Actions:
-    - Log warning with context
-    - Continue operation with monitoring
-    - Add issue to cleanup queue
-    - Track for trend analysis
-    
-  Recovery_Actions:
-    - Schedule background fix
-    - Monitor for escalation
-    - Include in next maintenance cycle
-    - Update user on resolution
-
-LOW_Responses:
-  Immediate_Actions:
-    - Silent logging
-    - Continue normal operation
-    - Add to improvement backlog
-    - Include in periodic reports
-    
-  Recovery_Actions:
-    - Batch with similar issues
-    - Address during optimization cycles
-    - Include in documentation updates
-    - Track for pattern analysis
-```
-
-## Escalation Pathways
-
-```yaml
-Escalation_Rules:
-  Frequency_Based:
-    Same_Issue_3x: "Increase severity by 1 level"
-    Same_Issue_5x: "Increase severity by 2 levels"
-    Pattern_Detected: "Escalate to system-level investigation"
-    
-  Time_Based:
-    Unresolved_1h: "Increase visibility"
-    Unresolved_4h: "Escalate to user attention"
-    Unresolved_24h: "Mark as systemic issue"
-    
-  Impact_Based:
-    Multiple_Users: "Increase severity by 1 level"
-    Production_Environment: "Increase severity by 2 levels"
-    Data_Integrity: "Immediate CRITICAL classification"
-
-Escalation_Actions:
-  Level_1: "Automated retry with different approach"
-  Level_2: "User notification with recommended actions"
-  Level_3: "System halt with manual intervention required"
-  Level_4: "Emergency protocols + external alerting"
-```
-
-## Integration Standards
-
-```yaml
-Usage_in_Commands:
-  Error_Classification:
-    - Always assign severity level to errors
-    - Use consistent [level] notation
-    - Include severity in log messages
-    - Map to appropriate response actions
-    
-  Response_Selection:
-    - Check severity level first
-    - Apply appropriate response template
-    - Escalate based on frequency/pattern
-    - Document resolution approach
-    
-  Reporting_Format:
-    Structure: "[SEVERITY_LEVEL] Category: Description"
-    Examples:
-      - "[CRITICAL] Security: API key detected in commit"
-      - "[HIGH] Build: Compilation failed with 3 errors"
-      - "[MEDIUM] Performance: Query took 2.3s (>1s threshold)"
-      - "[LOW] Style: 5 formatting issues found"
-
-Cross_Reference_Usage:
-  Commands: "@see shared/severity-levels.yml for error classification"
-  Shared_Files: "@include shared/severity-levels.yml#CRITICAL for critical responses"
-  Templates: "@flags shared/severity-levels.yml#Response_Times for SLA requirements"
-```
-
----
-*Severity Levels v1.0 - Universal classification and response standards for SuperClaude operations*