appiq-solution 1.0.9 → 1.1.0

package/bmad-core/tasks/index-docs.md

@@ -0,0 +1,179 @@
+# Index Documentation Task
+
+## Purpose
+
+This task maintains the integrity and completeness of the `docs/index.md` file by scanning all documentation files and ensuring they are properly indexed with descriptions. It handles both root-level documents and documents within subfolders, organizing them hierarchically.
+
+## Task Instructions
+
+You are now operating as a Documentation Indexer. Your goal is to ensure all documentation files are properly cataloged in the central index with proper organization for subfolders.
+
+### Required Steps
+
+1. First, locate and scan:
+
+   - The `docs/` directory and all subdirectories
+   - The existing `docs/index.md` file (create if absent)
+   - All markdown (`.md`) and text (`.txt`) files in the documentation structure
+   - Note the folder structure for hierarchical organization
+
+2. For the existing `docs/index.md`:
+
+   - Parse current entries
+   - Note existing file references and descriptions
+   - Identify any broken links or missing files
+   - Keep track of already-indexed content
+   - Preserve existing folder sections
+
+3. For each documentation file found:
+
+   - Extract the title (from first heading or filename)
+   - Generate a brief description by analyzing the content
+   - Create a relative markdown link to the file
+   - Check if it's already in the index
+   - Note which folder it belongs to (if in a subfolder)
+   - If missing or outdated, prepare an update
+
+4. For any missing or non-existent files found in index:
+
+   - Present a list of all entries that reference non-existent files
+   - For each entry:
+     - Show the full entry details (title, path, description)
+     - Ask for explicit confirmation before removal
+     - Provide option to update the path if file was moved
+     - Log the decision (remove/update/keep) for final report
+
+5. Update `docs/index.md`:
+   - Maintain existing structure and organization
+   - Create level 2 sections (`##`) for each subfolder
+   - List root-level documents first
+   - Add missing entries with descriptions
+   - Update outdated entries
+   - Remove only entries that were confirmed for removal
+   - Ensure consistent formatting throughout
+
+### Index Structure Format
+
+The index should be organized as follows:
+
+```markdown
+# Documentation Index
+
+## Root Documents
+
+### [Document Title](./document.md)
+
+Brief description of the document's purpose and contents.
+
+### [Another Document](./another.md)
+
+Description here.
+
+## Folder Name
+
+Documents within the `folder-name/` directory:
+
+### [Document in Folder](./folder-name/document.md)
+
+Description of this document.
+
+### [Another in Folder](./folder-name/another.md)
+
+Description here.
+
+## Another Folder
+
+Documents within the `another-folder/` directory:
+
+### [Nested Document](./another-folder/document.md)
+
+Description of nested document.
+
+```
+
+### Index Entry Format
+
+Each entry should follow this format:
+
+```markdown
+### [Document Title](relative/path/to/file.md)
+
+Brief description of the document's purpose and contents.
+```
+
+### Rules of Operation
+
+1. NEVER modify the content of indexed files
+2. Preserve existing descriptions in index.md when they are adequate
+3. Maintain any existing categorization or grouping in the index
+4. Use relative paths for all links (starting with `./`)
+5. Ensure descriptions are concise but informative
+6. NEVER remove entries without explicit confirmation
+7. Report any broken links or inconsistencies found
+8. Allow path updates for moved files before considering removal
+9. Create folder sections using level 2 headings (`##`)
+10. Sort folders alphabetically, with root documents listed first
+11. Within each section, sort documents alphabetically by title
+
+### Process Output
+
+The task will provide:
+
+1. A summary of changes made to index.md
+2. List of newly indexed files (organized by folder)
+3. List of updated entries
+4. List of entries presented for removal and their status:
+   - Confirmed removals
+   - Updated paths
+   - Kept despite missing file
+5. Any new folders discovered
+6. Any other issues or inconsistencies found
+
+### Handling Missing Files
+
+For each file referenced in the index but not found in the filesystem:
+
+1. Present the entry:
+
+   ```markdown
+   Missing file detected:
+   Title: [Document Title]
+   Path: relative/path/to/file.md
+   Description: Existing description
+   Section: [Root Documents | Folder Name]
+
+   Options:
+
+   1. Remove this entry
+   2. Update the file path
+   3. Keep entry (mark as temporarily unavailable)
+
+   Please choose an option (1/2/3):
+   ```
+
+2. Wait for user confirmation before taking any action
+3. Log the decision for the final report
+
+### Special Cases
+
+1. **Sharded Documents**: If a folder contains an `index.md` file, treat it as a sharded document:
+
+   - Use the folder's `index.md` title as the section title
+   - List the folder's documents as subsections
+   - Note in the description that this is a multi-part document
+
+2. **README files**: Convert `README.md` to more descriptive titles based on content
+
+3. **Nested Subfolders**: For deeply nested folders, maintain the hierarchy but limit to 2 levels in the main index. Deeper structures should have their own index files.
+
+## Required Input
+
+Please provide:
+
+1. Location of the `docs/` directory (default: `./docs`)
+2. Confirmation of write access to `docs/index.md`
+3. Any specific categorization preferences
+4. Any files or directories to exclude from indexing (e.g., `.git`, `node_modules`)
+5. Whether to include hidden files/folders (starting with `.`)
+
+Would you like to proceed with documentation indexing? Please provide the required input above.

package/bmad-core/tasks/intelligent-epic-creation.md

@@ -0,0 +1,234 @@
+# Intelligent AppIQ Project Creation Task
+
+## 📋 Overview
+This task provides an intelligent, guided approach to project creation that automatically detects project context and guides users through the optimal workflow.
+
+## 🎯 Task Objectives
+- Automatically detect project type (Greenfield vs Brownfield)
+- Analyze existing tech stack and project structure
+- Guide user through PRD creation or validation
+- Launch appropriate architecture workflow
+- Set up optimal development environment
+
+## 🤖 Execution Workflow
+
+### Phase 1: Project Context Detection
+
+#### Step 1: Analyze Current Environment
+```bash
+# Check for existing project indicators
+- package.json (Node.js/React/Vue/Angular)
+- pubspec.yaml (Flutter)
+- requirements.txt (Python)
+- Cargo.toml (Rust)
+- go.mod (Go)
+- composer.json (PHP)
+```
+
+#### Step 2: Detect Project Type
+**Ask user to confirm detection:**
+
+> 🔍 **Project Analysis Complete**
+> 
+> I've detected the following about your project:
+> - **Project Type**: [Greenfield/Brownfield]
+> - **Tech Stack**: [Detected frameworks and tools]
+> - **Structure**: [Monorepo/Multi-repo/Single app]
+> 
+> Is this correct? (Y/n)
+
+### Phase 2: PRD Workflow Selection
+
+#### For Greenfield Projects:
+1. **Check for existing PRD**:
+   - Look for `docs/prd.md`
+   - Look for `docs/requirements.md`
+   - Look for any `.md` files with PRD content
+
+2. **If no PRD exists**:
+   > 📝 **PRD Creation Required**
+   > 
+   > I don't see a PRD (Product Requirements Document) in your project.
+   > 
+   > Options:
+   > 1. **Quick Start**: I'll guide you through creating a PRD interactively
+   > 2. **Upload Existing**: You have a PRD file to upload
+   > 3. **Skip for Now**: Start with basic architecture (not recommended)
+   > 
+   > What would you like to do? (1/2/3)
+
+3. **If PRD exists**:
+   > ✅ **PRD Found**
+   > 
+   > I found your PRD at `docs/prd.md`. Let me validate it meets BMAD requirements...
+   > 
+   > [Analysis results]
+   > 
+   > Would you like to:
+   > 1. **Continue with existing PRD**
+   > 2. **Update/enhance the PRD**
+   > 3. **Create a new PRD**
+
+#### For Brownfield Projects:
+1. **Analyze existing codebase**:
+   - Detect current architecture patterns
+   - Identify existing components and services
+   - Analyze database schemas and API endpoints
+   - Check for existing documentation
+
+2. **Generate brownfield analysis**:
+   > 🔍 **Brownfield Analysis Complete**
+   > 
+   > **Detected Architecture**: [Clean Architecture/MVC/Layered/etc.]
+   > **Key Components**: [List of major components]
+   > **Database**: [Detected database type and schema]
+   > **API Style**: [REST/GraphQL/tRPC]
+   > 
+   > I'll help you create a PRD that aligns with your existing architecture.
+
+### Phase 3: Architecture Workflow
+
+#### Step 1: Architecture Agent Selection
+Based on detected tech stack, automatically select the appropriate architecture agent:
+
+- **Flutter Projects** → `flutter-mobile-architecture-tmpl.yaml`
+- **React/Vue/Angular** → `front-end-architecture-tmpl.yaml`
+- **Full Stack** → `fullstack-architecture-tmpl.yaml`
+- **Backend Only** → `architecture-tmpl.yaml`
+- **Brownfield** → `brownfield-architecture-tmpl.yaml`
+
+#### Step 2: Launch Architecture Creation
+> 🏗️ **Architecture Setup**
+> 
+> Based on your tech stack, I'm launching the **[Architecture Type]** workflow.
+> 
+> This will create a comprehensive architecture document that includes:
+> - Technology stack decisions
+> - Component architecture
+> - Database design
+> - API specifications
+> - Development workflow
+> 
+> Ready to proceed? (Y/n)
+
+### Phase 4: Development Environment Setup
+
+#### Step 1: Agent Team Configuration
+Automatically configure the optimal agent team based on project type:
+
+**For Flutter Projects**:
+```yaml
+agents:
+  - bmad-orchestrator
+  - analyst (if needed)
+  - pm
+  - architect
+  - po
+  - flutter-ui-agent
+  - flutter-cubit-agent
+  - flutter-domain-agent
+  - flutter-data-agent
+  - shared-components-agent
+  - qa
+  - sm
+```
+
+**For Web Projects**:
+```yaml
+agents:
+  - bmad-orchestrator
+  - analyst (if needed)
+  - pm
+  - architect
+  - po
+  - dev
+  - qa
+  - sm
+```
+
+#### Step 2: Workflow Initialization
+> ⚙️ **Development Environment Setup**
+> 
+> I'm configuring your development environment:
+> 
+> ✅ Agent team configured for [Project Type]
+> ✅ Workflow templates selected
+> ✅ Quality gates established
+> ✅ Security validation enabled
+> 
+> **Next Steps**:
+> 1. PRD creation/validation
+> 2. Architecture document generation
+> 3. Epic and story creation
+> 4. Development workflow initiation
+
+### Phase 5: Smart Guidance
+
+#### Provide Context-Aware Next Steps
+> 🎯 **Ready to Start Development**
+> 
+> Your BMAD environment is configured! Here's what happens next:
+> 
+> **Immediate Actions**:
+> 1. **PRD Review**: [If needed] Review and approve your PRD
+> 2. **Architecture Creation**: Generate your architecture document
+> 3. **Epic Planning**: Break down your PRD into actionable epics
+> 
+> **Development Workflow**:
+> 1. **Story Creation**: SM agent will create detailed development stories
+> 2. **Development**: Dev agents will implement features following Clean Architecture
+> 3. **Quality Assurance**: QA agent will validate all implementations
+> 
+> **Commands Available**:
+> - `/story` - Create a new development story
+> - `/analyze` - Analyze current project status
+> - `/help` - Get context-aware help
+> 
+> Would you like me to start with PRD creation? (Y/n)
+
+## 🔧 Implementation Details
+
+### Tech Stack Detection Logic
+```typescript
+interface ProjectContext {
+  type: 'greenfield' | 'brownfield';
+  techStack: {
+    frontend?: 'react' | 'vue' | 'angular' | 'flutter' | 'vanilla';
+    backend?: 'node' | 'python' | 'go' | 'rust' | 'php' | 'firebase' | 'supabase';
+    database?: 'postgresql' | 'mysql' | 'mongodb' | 'sqlite' | 'firestore';
+    stateManagement?: 'redux' | 'zustand' | 'cubit' | 'bloc' | 'vuex' | 'pinia';
+  };
+  structure: 'monorepo' | 'multi-repo' | 'single-app';
+  hasExistingDocs: boolean;
+  hasBMAD: boolean;
+}
+```
+
+### Intelligent Defaults
+- **Flutter Projects**: Enable Clean Architecture, Cubit state management, multi-language support
+- **React Projects**: Enable TypeScript, modern hooks, component-based architecture
+- **Full Stack**: Enable shared types, API-first design, comprehensive testing
+- **Brownfield**: Respect existing patterns while introducing BMAD workflows
+
+### Error Prevention
+- Validate PRD completeness before architecture creation
+- Check for conflicting dependencies
+- Ensure proper folder structure
+- Validate agent compatibility with tech stack
+
+## 📋 Success Criteria
+- [ ] Project type correctly detected
+- [ ] Tech stack accurately identified
+- [ ] Appropriate workflow selected and configured
+- [ ] User guided through each step with clear options
+- [ ] Development environment properly initialized
+- [ ] Clear next steps provided
+- [ ] All quality gates established
+- [ ] Security validation enabled
+
+## 🎯 User Experience Goals
+- **Zero Configuration**: Works out of the box with intelligent defaults
+- **Progressive Disclosure**: Only shows relevant options based on context
+- **Error Prevention**: Validates inputs and prevents common mistakes
+- **Clear Guidance**: Provides clear next steps at every stage
+- **Flexibility**: Allows overrides of automatic detection when needed

package/bmad-core/tasks/kb-mode-interaction.md

@@ -0,0 +1,75 @@
+# KB Mode Interaction Task
+
+## Purpose
+
+Provide a user-friendly interface to the BMad knowledge base without overwhelming users with information upfront.
+
+## Instructions
+
+When entering KB mode (*kb-mode), follow these steps:
+
+### 1. Welcome and Guide
+
+Announce entering KB mode with a brief, friendly introduction.
+
+### 2. Present Topic Areas
+
+Offer a concise list of main topic areas the user might want to explore:
+
+**What would you like to know more about?**
+
+1. **Setup & Installation** - Getting started with BMad
+2. **Workflows** - Choosing the right workflow for your project
+3. **Web vs IDE** - When to use each environment
+4. **Agents** - Understanding specialized agents and their roles
+5. **Documents** - PRDs, Architecture, Stories, and more
+6. **Agile Process** - How BMad implements Agile methodologies
+7. **Configuration** - Customizing BMad for your needs
+8. **Best Practices** - Tips for effective BMad usage
+
+Or ask me about anything else related to BMad-Method!
+
+### 3. Respond Contextually
+
+- Wait for user's specific question or topic selection
+- Provide focused, relevant information from the knowledge base
+- Offer to dive deeper or explore related topics
+- Keep responses concise unless user asks for detailed explanations
+
+### 4. Interactive Exploration
+
+- After answering, suggest related topics they might find helpful
+- Maintain conversational flow rather than data dumping
+- Use examples when appropriate
+- Reference specific documentation sections when relevant
+
+### 5. Exit Gracefully
+
+When user is done or wants to exit KB mode:
+
+- Summarize key points discussed if helpful
+- Remind them they can return to KB mode anytime with *kb-mode
+- Suggest next steps based on what was discussed
+
+## Example Interaction
+
+**User**: *kb-mode
+
+**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.
+
+**What would you like to know more about?**
+
+1. **Setup & Installation** - Getting started with BMad
+2. **Workflows** - Choosing the right workflow for your project
+3. **Web vs IDE** - When to use each environment
+4. **Agents** - Understanding specialized agents and their roles
+5. **Documents** - PRDs, Architecture, Stories, and more
+6. **Agile Process** - How BMad implements Agile methodologies
+7. **Configuration** - Customizing BMad for your needs
+8. **Best Practices** - Tips for effective BMad usage
+
+Or ask me about anything else related to BMad-Method!
+
+**User**: Tell me about workflows
+
+**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]

package/bmad-core/tasks/review-story.md

@@ -0,0 +1,145 @@
+# review-story
+
+When a developer agent marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
+
+## Prerequisites
+
+- Story status must be "Review"
+- Developer has completed all tasks and updated the File List
+- All automated tests are passing
+
+## Review Process
+
+1. **Read the Complete Story**
+   - Review all acceptance criteria
+   - Understand the dev notes and requirements
+   - Note any completion notes from the developer
+
+2. **Verify Implementation Against Dev Notes Guidance**
+   - Review the "Dev Notes" section for specific technical guidance provided to the developer
+   - Verify the developer's implementation follows the architectural patterns specified in Dev Notes
+   - Check that file locations match the project structure guidance in Dev Notes
+   - Confirm any specified libraries, frameworks, or technical approaches were used correctly
+   - Validate that security considerations mentioned in Dev Notes were implemented
+
+3. **Focus on the File List**
+   - Verify all files listed were actually created/modified
+   - Check for any missing files that should have been updated
+   - Ensure file locations align with the project structure guidance from Dev Notes
+
+4. **Senior Developer Code Review**
+   - Review code with the eye of a senior developer
+   - If changes form a cohesive whole, review them together
+   - If changes are independent, review incrementally file by file
+   - Focus on:
+     - Code architecture and design patterns
+     - Refactoring opportunities
+     - Code duplication or inefficiencies
+     - Performance optimizations
+     - Security concerns
+     - Best practices and patterns
+
+5. **Active Refactoring**
+   - As a senior developer, you CAN and SHOULD refactor code where improvements are needed
+   - When refactoring:
+     - Make the changes directly in the files
+     - Explain WHY you're making the change
+     - Describe HOW the change improves the code
+     - Ensure all tests still pass after refactoring
+     - Update the File List if you modify additional files
+
+6. **Standards Compliance Check**
+   - Verify adherence to `docs/coding-standards.md`
+   - Check compliance with `docs/unified-project-structure.md`
+   - Validate testing approach against `docs/testing-strategy.md`
+   - Ensure all guidelines mentioned in the story are followed
+
+7. **Acceptance Criteria Validation**
+   - Verify each AC is fully implemented
+   - Check for any missing functionality
+   - Validate edge cases are handled
+
+8. **Test Coverage Review**
+   - Ensure unit tests cover edge cases
+   - Add missing tests if critical coverage is lacking
+   - Verify integration tests (if required) are comprehensive
+   - Check that test assertions are meaningful
+   - Look for missing test scenarios
+
+9. **Documentation and Comments**
+   - Verify code is self-documenting where possible
+   - Add comments for complex logic if missing
+   - Ensure any API changes are documented
+
+## Update Story File - QA Results Section ONLY
+
+**CRITICAL**: You are ONLY authorized to update the "QA Results" section of the story file. DO NOT modify any other sections.
+
+After review and any refactoring, append your results to the story file in the QA Results section:
+
+```markdown
+## QA Results
+
+### Review Date: [Date]
+### Reviewed By: Quinn (Senior Developer QA)
+
+### Code Quality Assessment
+[Overall assessment of implementation quality]
+
+### Refactoring Performed
+[List any refactoring you performed with explanations]
+- **File**: [filename]
+  - **Change**: [what was changed]
+  - **Why**: [reason for change]
+  - **How**: [how it improves the code]
+
+### Compliance Check
+- Coding Standards: [✓/✗] [notes if any]
+- Project Structure: [✓/✗] [notes if any]
+- Testing Strategy: [✓/✗] [notes if any]
+- All ACs Met: [✓/✗] [notes if any]
+
+### Improvements Checklist
+[Check off items you handled yourself, leave unchecked for dev to address]
+
+- [x] Refactored user service for better error handling (services/user.service.ts)
+- [x] Added missing edge case tests (services/user.service.test.ts)
+- [ ] Consider extracting validation logic to separate validator class
+- [ ] Add integration test for error scenarios
+- [ ] Update API documentation for new error codes
+
+### Security Review
+[Any security concerns found and whether addressed]
+
+### Performance Considerations
+[Any performance issues found and whether addressed]
+
+### Final Status
+[✓ Approved - Ready for Done] / [✗ Changes Required - See unchecked items above]
+```
+
+## Key Principles
+
+- You are a SENIOR developer reviewing junior/mid-level work
+- You have the authority and responsibility to improve code directly
+- Always explain your changes for learning purposes
+- Balance between perfection and pragmatism
+- Focus on significant improvements, not nitpicks
+
+## Blocking Conditions
+
+Stop the review and request clarification if:
+
+- Story file is incomplete or missing critical sections
+- File List is empty or clearly incomplete
+- No tests exist when they were required
+- Code changes don't align with story requirements
+- Critical architectural issues that require discussion
+
+## Completion
+
+After review:
+
+1. If all items are checked and approved: Update story status to "Done"
+2. If unchecked items remain: Keep status as "Review" for dev to address
+3. Always provide constructive feedback and explanations for learning