bmad-stella 1.0.0

package/bmad-core/tasks/identify-dependencies.md

@@ -0,0 +1,347 @@
+<!-- Powered by Stella Development Team -->
+
+# Identify Dependencies Task
+
+## Purpose
+
+To analyze a JIRA ticket or implementation plan and identify all technical dependencies, potential blockers, integration points, and risks that could impact successful implementation. This task surfaces critical information early, enabling better planning and risk mitigation.
+
+## Documentation Framework
+
+When identifying items in sections 2-5, document the following for each item:
+
+### For Dependencies (Code, Infrastructure, Third-Party, Data):
+
+- **What:** Name/description and what it provides
+- **Where:** Location (file path, service URL, package name)
+- **State:** Current status (exists, needs creation, needs modification, version)
+- **Requirements:** Configuration, access, permissions needed
+- **Concerns:** Known issues, limitations, performance considerations, costs
+
+### For Blockers (Technical, Information, Resource):
+
+- **What:** What is blocking or missing
+- **Impact:** Severity level (critical, high, medium, low)
+- **Resolution:** Who can unblock, how to obtain, estimated time
+- **Alternatives:** Workarounds or alternative approaches
+- **Partial Progress:** Can work proceed partially?
+
+### For Integration Points (Internal, External):
+
+- **Type:** Connection type and protocol
+- **Contract:** Data format, API specification
+- **Authentication:** Auth method and credentials management
+- **Reliability:** Error handling, retries, rate limits, fallback strategies
+- **Testing:** How to test and monitor the integration
+
+### For Risks (Technical, Integration, Project):
+
+- **Description:** Clear description of the risk
+- **Assessment:** Likelihood (high/medium/low) and Impact (critical/high/medium/low)
+- **Detection:** Early warning signs or detection strategy
+- **Mitigation:** Strategy to prevent or reduce risk
+- **Contingency:** Fallback plan if risk materializes
+
+## Task Execution
+
+### 1. Understand the Ticket/Plan Context
+
+#### 1.1 Load Ticket or Plan Information
+
+- Read the ticket file, plan file, or description provided
+- Extract key information:
+  - Ticket type (feature, bug, migration)
+  - Technical scope
+  - Components involved
+  - Integration requirements
+  - Timeline constraints (if any)
+
+#### 1.2 Load Architecture Context
+
+First, read the architecture index to understand available documentation:
+
+- Read `architecture/index.md` - Contains brief descriptions of all architecture documents
+
+**Fallback for Architecture Documentation:** If no `architecture/` folder exists inside `bmad-docs/` folder, check for `Claude.md` in the root directory of the project if it exists. This file may contain architecture and project information.
+
+Based on the ticket context and the briefs in the index, decide which architecture files are relevant to explore:
+
+- For technology/package dependencies → Review tech stack documentation
+- For project structure/module dependencies → Review structure documentation
+- For backend-specific work → Review backend architecture documentation
+- For frontend-specific work → Review frontend architecture documentation
+- For external integrations → Review external APIs documentation
+- For data/schema changes → Review database documentation
+
+**Decision Point:** Only load the architecture files that are relevant to your specific ticket context.
+
+### 2. Identify Technical Dependencies
+
+#### 2.1 Code Dependencies
+
+Identify and document (per framework above):
+
+- **Modules/Components** - Existing code this must interact with
+- **Shared Services** - Required utilities or services
+- **Data Models** - Required data structures or schemas
+- **APIs** - Internal APIs to consume
+- **State Management** - Required state or context
+
+#### 2.2 Infrastructure Dependencies
+
+Identify and document (per framework above):
+
+- **Databases** - Database access, schema changes, migrations
+- **Caching** - Redis, Memcached, or other caching systems
+- **Message Queues** - Kafka, RabbitMQ, or other queuing systems
+- **Storage** - File storage, S3, CDN requirements
+- **Environment Variables** - New configs or secrets
+- **Deployment** - Build pipeline, deployment scripts, infrastructure changes
+
+#### 2.3 Third-Party Dependencies
+
+Identify and document (per framework above):
+
+- **NPM/Package Dependencies** - New libraries or version updates
+- **External APIs** - Third-party services to integrate
+- **SaaS Services** - Payment gateways, analytics, monitoring
+- **Authentication Providers** - OAuth, SAML providers
+- **CDNs or Static Resources** - External resource dependencies
+
+Note: Include license compatibility, rate limits, and cost implications in documentation.
+
+#### 2.4 Data Dependencies
+
+Identify and document (per framework above):
+
+- **Existing Data** - Required data availability
+- **Data Migrations** - Schema or data migrations required
+- **Data Transformations** - Data conversion needs
+- **Data Volume** - Amount of data involved
+- **Data Quality** - Data quality concerns
+- **Data Access** - Permission or privacy requirements
+
+Note: Include migration strategy, validation, backup, and rollback needs in documentation.
+
+### 3. Identify Blockers
+
+#### 3.1 Technical Blockers
+
+Identify and document (per framework above) anything that could prevent implementation:
+
+- **Missing Infrastructure** - Required services not yet provisioned
+- **Incomplete Features** - Depends on other unfinished work
+- **Technical Debt** - Existing code that must be refactored first
+- **Performance Issues** - Current system can't handle new requirements
+- **Security Gaps** - Security requirements not yet met
+- **Technical Limitations** - Platform or technology constraints
+
+#### 3.2 Information Blockers
+
+Identify and document (per framework above) missing information:
+
+- **Unclear Requirements** - Specifications not fully defined
+- **Ambiguous Acceptance Criteria** - Success conditions unclear
+- **Missing Designs** - UI/UX designs not available
+- **Unknown Integration Details** - Third-party API specs unclear
+- **Undecided Architecture** - Technical approach not yet determined
+
+#### 3.3 Resource Blockers
+
+Identify and document (per framework above) resource constraints:
+
+- **Access/Permissions** - Lack of access to systems, repos, or services
+- **Budget Constraints** - Costs exceeding budget
+- **Time Constraints** - Dependencies won't be ready in time
+- **Skill Gaps** - Specialized knowledge required
+- **Tooling** - Required tools not available
+
+### 4. Identify Integration Points
+
+#### 4.1 Internal Integration Points
+
+Identify and document (per framework above) connections within the system:
+
+- **Frontend-Backend** - API calls, data flows
+- **Service-to-Service** - Microservice communications
+- **Database Connections** - Data access patterns
+- **Event Systems** - Event producers and consumers
+- **Shared State** - Global state or cache dependencies
+
+#### 4.2 External Integration Points
+
+Identify and document (per framework above) connections to external systems:
+
+- **Third-Party APIs** - External service calls
+- **Webhooks** - Incoming or outgoing webhook integrations
+- **File Imports/Exports** - Data exchange with external systems
+- **Authentication** - SSO, OAuth providers
+- **Monitoring/Logging** - External monitoring services
+
+### 5. Assess Risks
+
+#### 5.1 Technical Risks
+
+Identify and document (per framework above):
+
+- **Complexity** - Solution is technically complex
+- **New Technology** - Using unfamiliar tech stack
+- **Performance** - May not meet performance requirements
+- **Scalability** - Solution may not scale
+- **Security** - Potential security vulnerabilities
+- **Data Loss** - Risk of data corruption or loss (especially migrations)
+- **Browser/Platform Compatibility** - May not work across targets
+
+#### 5.2 Integration Risks
+
+Identify and document (per framework above):
+
+- **API Changes** - Third-party APIs may change
+- **Service Downtime** - External services may be unavailable
+- **Version Incompatibility** - Dependency version conflicts
+- **Data Format Changes** - External data formats may change
+- **Rate Limiting** - May hit rate limits under load
+
+#### 5.3 Project Risks
+
+Identify and document (per framework above):
+
+- **Scope Creep** - Requirements may expand
+- **Timeline Pressure** - Tight deadlines may force shortcuts
+- **Dependency Delays** - Other teams may delay
+- **Resource Availability** - Key resources may be unavailable
+- **Requirement Changes** - Requirements may change during implementation
+
+### 6. Recommend Mitigation Strategies
+
+For identified dependencies and risks, provide strategies:
+
+#### 6.1 Dependency Management
+
+- **Early Validation** - Verify dependencies before main implementation
+- **Parallel Workstreams** - Work on independent parts while waiting
+- **Stub/Mock** - Create mocks for unavailable dependencies
+- **Incremental Approach** - Deliver in phases to reduce risk
+- **Fallback Options** - Identify alternative approaches
+
+#### 6.2 Risk Mitigation
+
+- **Proof of Concept** - Validate high-risk approaches early
+- **Feature Flags** - Use flags to enable/disable safely
+- **Gradual Rollout** - Deploy incrementally to subset of users
+- **Monitoring** - Add comprehensive monitoring and alerting
+- **Rollback Plan** - Have clear rollback procedures
+- **Testing** - Extra testing for high-risk areas
+
+### 7. Create Temporary Dependency File
+
+Create a temporary file to store the dependency analysis:
+
+#### 7.1 File Creation
+
+- **File name:** `{{ticket_no}}-dependency-tmp.md`
+- **Location:** `bmad-docs/temporary/`
+- **Purpose:** Store dependencies for use by create-implementation-plan task
+
+**Note:** If the `bmad-docs/temporary` folder doesn't exist, create it first.
+
+#### 7.2 File Content Structure
+
+Write the comprehensive dependency analysis to the temporary file using the following structure:
+
+```markdown
+# Dependency Analysis Report: [Ticket Number] - [Title]
+
+## Summary
+
+- Total Dependencies Identified: [N]
+- Critical Blockers: [N]
+- High-Risk Items: [N]
+- External Integrations: [N]
+- Overall Risk Level: [Low/Medium/High/Critical]
+
+## Technical Dependencies
+
+[List with details]
+
+## Infrastructure Dependencies
+
+[List with details]
+
+## Third-Party Dependencies
+
+[List with details]
+
+## Data Dependencies
+
+[List with details]
+
+## Blockers
+
+[List with severity, impact, mitigation]
+
+## Integration Points
+
+[List with protocols, error handling]
+
+## Risks
+
+[List with likelihood, impact, mitigation]
+
+## Recommended Approach
+
+1. [First priority action]
+2. [Second priority action]
+3. [Continue with remaining actions]
+
+## Critical Path Items
+
+- [Items that must be resolved before starting]
+- [Items that must be resolved during implementation]
+
+## Next Steps
+
+1. Resolve critical blockers
+2. Validate high-risk dependencies
+3. Proceed with implementation plan
+```
+
+#### 7.3 Present Summary to User
+
+After creating the file, provide a summary to the user:
+
+- Location of the temporary file
+- Total dependencies identified
+- Critical blockers that need attention
+- Overall risk level assessment
+
+### 8. Integration with Implementation Plan
+
+The `create-implementation-plan` task will read `{{ticket_no}}-dependency-tmp.md` and integrate dependencies into the implementation plan's "Dependencies and Risks" section, "Technical Approach", and "Tasks / Subtasks".
+
+#### 8.1 Cleanup Logic
+
+After integration, the create-implementation-plan task performs cleanup:
+
+**All dependencies addressed:** Delete `{{ticket_no}}-dependency-tmp.md` completely.
+
+**Dependencies span multiple subtasks:** Remove only addressed dependencies from the temporary file. Keep remaining dependencies for subsequent decomposed subtasks that will reuse the file.
+
+#### 8.2 Workflow
+
+1. **Identify Dependencies** → Creates `{{ticket_no}}-dependency-tmp.md`
+2. **Decompose Task** (if needed) → Breaks large tasks into smaller subtasks
+3. **Create Implementation Plan** → Integrates dependencies, cleans up file as appropriate
+4. **Repeat** → Subsequent subtasks reuse temporary file until all dependencies addressed
+
+## Notes
+
+- This task is typically run as part of create-implementation-plan workflow
+- Can also be run standalone for existing plans or tickets
+- Creates a temporary file `{{ticket_no}}-dependency-tmp.md` in `bmad-docs/temporary/` for use by subsequent tasks
+- Temporary file persists across decomposed subtasks and is cleaned up once all dependencies are addressed
+- Supports BMAD decomposition workflow where large tasks (multiple story points) are broken into smaller tasks (max 1 story point each)
+- Dependency identification helps set realistic timelines
+- Early identification prevents surprises during implementation
+- Risk mitigation strategies should be concrete and actionable
+- Document assumptions clearly when dependencies are uncertain

package/bmad-core/tasks/implement-test.md

@@ -0,0 +1,188 @@
+<!-- Powered by Stella Development Team -->
+
+# implement-test
+
+Implement unit and integration tests from test design scenarios. Execute test scenarios in priority order, validate coverage, and update task documentation. If a scenario is marked as E2E, do not implement it and record it as out of scope in the Test Summary.
+
+## Inputs
+
+```yaml
+required:
+  - test_design_path: '{qa.qaLocation}/assessments/{{ticket_number}}-*-test-design-{YYYYMMDD}.md'
+  - task_path: 'bmad-docs/impl-plan/{{ticket_number}}-*.md'
+  - project_root: '{root from core-config.yaml}'
+```
+
+## Purpose
+
+Convert test design scenarios into executable test code. Implement tests following priority order and ensure all acceptance criteria have working test coverage.
+
+## Dependencies
+
+```yaml
+data:
+  - technical-preferences.md # Project testing framework and patterns
+config:
+  - core-config.yaml # Project paths and test command
+```
+
+## Process
+
+### 1. Load Test Design
+
+Read the test design document at `test_design_path`:
+
+- Extract all test scenarios from the "Test Scenarios by Acceptance Criteria" section
+- Note the test level (unit/integration) for each scenario
+- Identify P0 tests - these MUST be implemented first
+- Record which ACs each test covers
+
+### 2. Identify Test Framework
+
+Read `technical-preferences.md` to determine:
+
+- Testing framework (Jest, Pytest, RSpec, etc.)
+- Test file naming convention
+- Test file location pattern
+- Assertion library in use
+- Mock/stub patterns used in project
+
+### 3. Implement Tests by Priority
+
+For each test scenario in **priority order** per Critical Rule #1:
+
+#### A. Locate or Create Test File
+
+**Unit tests:**
+
+- Follow project convention (e.g., `*.test.ts`, `*_test.py`, `*_spec.rb`)
+- Place adjacent to source file OR in mirror `tests/` directory per project standard
+- If test file exists, append new test cases
+- If new, create with proper imports and setup blocks
+
+**Integration tests:**
+
+- Use integration test directory from project structure
+- Group by feature/module if project does so
+- Include necessary test fixtures and setup
+
+#### B. Write Test Implementation
+
+For each test scenario, write ONE test case:
+
+1. **Test name**: Use exact scenario ID (e.g., `test('1.3-UNIT-001: Validate input format', ...)`)
+
+2. **Structure**: Given-When-Then format (setup → execute → assert)
+
+3. **Style**: Match project's existing test patterns (mocking, assertions, helpers)
+
+#### C. Execute and Validate
+
+After implementing each test:
+
+1. Run the specific test file
+2. If file-level test execution is not supported, run the smallest valid test scope available per project configuration.
+3. Verify the test PASSES
+4. If test FAILS:
+   - Debug the test implementation (NOT the source code)
+   - Verify test data matches scenario requirements
+   - Check assertions match expected behavior
+   - Only if source code has a bug, note it in "Debug Log" section of task and continue
+
+DO NOT proceed to the next test until the current test passes OR the failure is documented in "Debug Log" as a source code bug.
+
+### 4. Update Task File
+
+Add to the task file's "Testing" section:
+
+```markdown
+## Testing
+
+### Implemented Tests
+
+Test design: `{relative path to test design doc}`
+
+Implemented: {date}
+
+**Test Summary:**
+
+- Unit tests: {count} (Files: {list test files})
+- Integration tests: {count} (Files: {list test files})
+- All P0 tests: ✓ PASSING
+- Test design scenarios: {total}
+- Implemented scenarios: {total}
+- Passing tests: {total}
+- Coverage: {percentage}% of ACs
+
+**Coverage:**
+
+- AC1: {test IDs}
+- AC2: {test IDs}
+- [list all ACs with their test IDs]
+
+**Execution:**
+Run tests: `{test command from core-config}`
+```
+
+## Outputs
+
+### Output 1: Test Files
+
+**Created/Updated Files:**
+
+- Unit test files in project test directory
+- Integration test files in project test directory
+- Test fixtures/helpers if needed
+
+**Naming Convention:**
+Follow project standard from `technical-preferences.md`
+
+### Output 2: Execution Report
+
+Print to console:
+
+```text
+TEST IMPLEMENTATION COMPLETE
+==============================
+Task: {ticket_number}-{ticket_title_short}
+Test Design: {filename}
+
+Tests Implemented:
+  Unit:        {count} tests in {file count} files
+  Integration: {count} tests in {file count} files
+
+Priority Breakdown:
+  P0: {count} ✓
+  P1: {count} ✓
+  P2: {count} ✓
+
+Execution Results:
+  ✓ All tests passing
+  ✓ All ACs covered
+
+Run tests: {test command}
+```
+
+## Validation Checklist
+
+Before marking complete:
+
+- [ ] All P0 tests implemented and passing
+- [ ] All P1 and P2 tests implemented and passing or documented as bug
+- [ ] Test IDs match test design document exactly
+- [ ] Every AC has at least one test
+- [ ] Test count matches test design document totals
+- [ ] Full test suite passes (no regressions)
+- [ ] Test files follow project naming conventions
+- [ ] Task "Testing" section updated / added
+- [ ] No tests marked as `.skip()` or `.todo()` (unless documented as bugs in Debug Log)
+
+## Critical Rules
+
+1. **Implement in priority order**: P0 first, then P1, then P2, then P3. Stop if P0 tests fail.
+
+2. **One scenario = one test**: Each scenario ID in test design gets exactly one test case.
+
+3. **Test scope:** Implement only scenarios from test design - no additional test cases.
+
+4. **Test files only**: Do NOT modify source code unless fixing a legitimate bug found during testing.

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

@@ -0,0 +1,175 @@
+<!-- Powered by BMAD™ Core -->
+
+# Index Documentation Task
+
+## Purpose
+
+This task maintains the integrity and completeness of the `bmad-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 `bmad-docs/` directory and all subdirectories
+   - The existing `bmad-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 `bmad-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 `bmad-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 `bmad-docs/` directory (default: `./docs`)
+2. Confirmation of write access to `bmad-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.