edsger 0.2.1 → 0.2.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/api/features/feature-utils.d.ts +13 -0
- package/dist/api/features/feature-utils.js +46 -0
- package/dist/api/features/get-feature.d.ts +5 -0
- package/dist/api/features/get-feature.js +19 -0
- package/dist/api/features/index.d.ts +7 -0
- package/dist/api/features/index.js +9 -0
- package/dist/api/features/status-updater.d.ts +27 -0
- package/dist/api/features/status-updater.js +64 -0
- package/dist/api/features/test-cases.d.ts +21 -0
- package/dist/api/features/test-cases.js +63 -0
- package/dist/api/features/update-feature.d.ts +13 -0
- package/dist/api/features/update-feature.js +31 -0
- package/dist/api/features/user-stories.d.ts +21 -0
- package/dist/api/features/user-stories.js +63 -0
- package/dist/api/features.d.ts +100 -0
- package/dist/api/features.js +219 -0
- package/dist/api/mcp-client.d.ts +18 -0
- package/dist/api/mcp-client.js +58 -0
- package/dist/api/products.d.ts +10 -0
- package/dist/api/products.js +22 -0
- package/dist/api/test-reports.d.ts +9 -0
- package/dist/api/test-reports.js +25 -0
- package/dist/cli/commands/code-implementation-command.d.ts +2 -0
- package/dist/cli/commands/code-implementation-command.js +36 -0
- package/dist/cli/commands/code-review-command.d.ts +2 -0
- package/dist/cli/commands/code-review-command.js +39 -0
- package/dist/cli/commands/feature-analysis-command.d.ts +2 -0
- package/dist/cli/commands/feature-analysis-command.js +36 -0
- package/dist/cli/commands/functional-testing-command.d.ts +2 -0
- package/dist/cli/commands/functional-testing-command.js +36 -0
- package/dist/cli/commands/technical-design-command.d.ts +2 -0
- package/dist/cli/commands/technical-design-command.js +36 -0
- package/dist/cli/commands/workflow-command.d.ts +2 -0
- package/dist/cli/commands/workflow-command.js +34 -0
- package/dist/cli/formatters/code-implementation-formatter.d.ts +9 -0
- package/dist/cli/formatters/code-implementation-formatter.js +27 -0
- package/dist/cli/formatters/feature-analysis-formatter.d.ts +2 -0
- package/dist/cli/formatters/feature-analysis-formatter.js +27 -0
- package/dist/cli/formatters/functional-testing-formatter.d.ts +15 -0
- package/dist/cli/formatters/functional-testing-formatter.js +37 -0
- package/dist/cli/formatters/technical-design-formatter.d.ts +7 -0
- package/dist/cli/formatters/technical-design-formatter.js +30 -0
- package/dist/cli/index.d.ts +3 -0
- package/dist/cli/index.js +99 -0
- package/dist/cli/utils/validation.d.ts +25 -0
- package/dist/cli/utils/validation.js +58 -0
- package/dist/cli/utils/workflow-utils.d.ts +21 -0
- package/dist/cli/utils/workflow-utils.js +47 -0
- package/dist/cli.d.ts +1 -1
- package/dist/cli.js +11 -466
- package/dist/config.d.ts +1 -1
- package/dist/index.d.ts +3 -3
- package/dist/index.js +2 -2
- package/dist/{bug-fixing → phases/bug-fixing}/analyzer.d.ts +1 -1
- package/dist/{bug-fixing → phases/bug-fixing}/analyzer.js +1 -1
- package/dist/{bug-fixing → phases/bug-fixing}/context-fetcher.d.ts +4 -22
- package/dist/{bug-fixing → phases/bug-fixing}/context-fetcher.js +14 -58
- package/dist/{bug-fixing → phases/bug-fixing}/mcp-server.js +1 -30
- package/dist/phases/code-implementation/analyzer.d.ts +33 -0
- package/dist/{code-implementation → phases/code-implementation}/analyzer.js +174 -15
- package/dist/phases/code-implementation/context-fetcher.d.ts +17 -0
- package/dist/phases/code-implementation/context-fetcher.js +86 -0
- package/dist/{code-implementation → phases/code-implementation}/mcp-server.js +1 -30
- package/dist/{code-review → phases/code-review}/reviewer.d.ts +1 -1
- package/dist/{feature-analysis → phases/feature-analysis}/analyzer.d.ts +3 -2
- package/dist/{feature-analysis → phases/feature-analysis}/analyzer.js +29 -127
- package/dist/phases/feature-analysis/context-fetcher.d.ts +18 -0
- package/dist/phases/feature-analysis/context-fetcher.js +86 -0
- package/dist/{feature-analysis → phases/feature-analysis}/http-fallback.js +1 -1
- package/dist/{feature-analysis → phases/feature-analysis}/mcp-server.js +1 -24
- package/dist/{functional-testing → phases/functional-testing}/analyzer.d.ts +17 -2
- package/dist/{functional-testing → phases/functional-testing}/analyzer.js +225 -31
- package/dist/phases/functional-testing/context-fetcher.d.ts +16 -0
- package/dist/phases/functional-testing/context-fetcher.js +81 -0
- package/dist/{functional-testing → phases/functional-testing}/http-fallback.js +1 -1
- package/dist/{functional-testing → phases/functional-testing}/index.d.ts +1 -1
- package/dist/{functional-testing → phases/functional-testing}/index.js +1 -1
- package/dist/{functional-testing → phases/functional-testing}/mcp-server.js +1 -30
- package/dist/{functional-testing → phases/functional-testing}/test-report-creator.js +1 -1
- package/dist/phases/functional-testing/test-retry-handler.d.ts +16 -0
- package/dist/phases/functional-testing/test-retry-handler.js +75 -0
- package/dist/{pull-request → phases/pull-request}/creator.js +47 -6
- package/dist/phases/pull-request/handler.d.ts +16 -0
- package/dist/phases/pull-request/handler.js +60 -0
- package/dist/{technical-design → phases/technical-design}/analyzer.d.ts +7 -2
- package/dist/phases/technical-design/analyzer.js +418 -0
- package/dist/phases/technical-design/context-fetcher.d.ts +12 -0
- package/dist/phases/technical-design/context-fetcher.js +39 -0
- package/dist/{technical-design → phases/technical-design}/http-fallback.js +1 -1
- package/dist/{technical-design → phases/technical-design}/mcp-server.js +1 -30
- package/dist/prompts/bug-fixing.d.ts +2 -0
- package/dist/prompts/bug-fixing.js +63 -0
- package/dist/prompts/code-implementation.d.ts +3 -0
- package/dist/prompts/code-implementation.js +132 -0
- package/dist/prompts/feature-analysis.d.ts +3 -0
- package/dist/prompts/feature-analysis.js +149 -0
- package/dist/prompts/formatters.d.ts +29 -0
- package/dist/prompts/formatters.js +139 -0
- package/dist/prompts/functional-testing.d.ts +3 -0
- package/dist/prompts/functional-testing.js +126 -0
- package/dist/prompts/index.d.ts +6 -0
- package/dist/prompts/index.js +7 -0
- package/dist/prompts/technical-design.d.ts +3 -0
- package/dist/prompts/technical-design.js +130 -0
- package/dist/services/checklist.d.ts +99 -0
- package/dist/services/checklist.js +337 -0
- package/dist/types/features.d.ts +29 -0
- package/dist/types/features.js +1 -0
- package/dist/types/index.d.ts +112 -0
- package/dist/types/index.js +1 -0
- package/dist/types/pipeline.d.ts +25 -0
- package/dist/types/pipeline.js +4 -0
- package/dist/utils/logger.d.ts +19 -0
- package/dist/utils/logger.js +52 -0
- package/dist/utils/pipeline-logger.d.ts +8 -0
- package/dist/utils/pipeline-logger.js +35 -0
- package/dist/workflow-runner/config/phase-configs.d.ts +5 -0
- package/dist/workflow-runner/config/phase-configs.js +34 -0
- package/dist/workflow-runner/config/stage-configs.d.ts +5 -0
- package/dist/workflow-runner/config/stage-configs.js +34 -0
- package/dist/workflow-runner/core/feature-filter.d.ts +16 -0
- package/dist/workflow-runner/core/feature-filter.js +46 -0
- package/dist/workflow-runner/core/feature-filter.test.d.ts +4 -0
- package/dist/workflow-runner/core/feature-filter.test.js +127 -0
- package/dist/workflow-runner/core/index.d.ts +8 -0
- package/dist/workflow-runner/core/index.js +12 -0
- package/dist/workflow-runner/core/pipeline-evaluator.d.ts +24 -0
- package/dist/workflow-runner/core/pipeline-evaluator.js +32 -0
- package/dist/workflow-runner/core/state-manager.d.ts +24 -0
- package/dist/workflow-runner/core/state-manager.js +42 -0
- package/dist/workflow-runner/core/workflow-logger.d.ts +20 -0
- package/dist/workflow-runner/core/workflow-logger.js +65 -0
- package/dist/workflow-runner/executors/phase-executor.d.ts +8 -0
- package/dist/workflow-runner/executors/phase-executor.js +183 -0
- package/dist/workflow-runner/executors/stage-executor.d.ts +8 -0
- package/dist/workflow-runner/executors/stage-executor.js +49 -0
- package/dist/workflow-runner/feature-service.d.ts +17 -0
- package/dist/workflow-runner/feature-service.js +60 -0
- package/dist/workflow-runner/feature-workflow-runner.d.ts +26 -0
- package/dist/workflow-runner/feature-workflow-runner.js +113 -0
- package/dist/workflow-runner/index.d.ts +0 -1
- package/dist/workflow-runner/index.js +0 -1
- package/dist/workflow-runner/pipeline-runner.d.ts +9 -19
- package/dist/workflow-runner/pipeline-runner.js +247 -256
- package/dist/workflow-runner/pipeline.d.ts +18 -0
- package/dist/workflow-runner/pipeline.js +197 -0
- package/dist/workflow-runner/processor.d.ts +40 -0
- package/dist/workflow-runner/processor.js +191 -0
- package/dist/workflow-runner/types.d.ts +48 -0
- package/dist/workflow-runner/types.js +4 -0
- package/dist/workflow-runner/workflow-processor.d.ts +6 -23
- package/dist/workflow-runner/workflow-processor.js +38 -100
- package/package.json +1 -1
- package/dist/code-implementation/analyzer.d.ts +0 -19
- package/dist/code-implementation/context-fetcher.d.ts +0 -38
- package/dist/code-implementation/context-fetcher.js +0 -147
- package/dist/feature-analysis/context-fetcher.d.ts +0 -54
- package/dist/feature-analysis/context-fetcher.js +0 -193
- package/dist/functional-testing/context-fetcher.d.ts +0 -47
- package/dist/functional-testing/context-fetcher.js +0 -192
- package/dist/technical-design/analyzer.js +0 -338
- package/dist/technical-design/context-fetcher.d.ts +0 -42
- package/dist/technical-design/context-fetcher.js +0 -170
- /package/dist/{bug-fixing → phases/bug-fixing}/index.d.ts +0 -0
- /package/dist/{bug-fixing → phases/bug-fixing}/index.js +0 -0
- /package/dist/{bug-fixing → phases/bug-fixing}/mcp-server.d.ts +0 -0
- /package/dist/{code-implementation → phases/code-implementation}/mcp-server.d.ts +0 -0
- /package/dist/{code-review → phases/code-review}/reviewer.js +0 -0
- /package/dist/{feature-analysis → phases/feature-analysis}/http-fallback.d.ts +0 -0
- /package/dist/{feature-analysis → phases/feature-analysis}/index.d.ts +0 -0
- /package/dist/{feature-analysis → phases/feature-analysis}/index.js +0 -0
- /package/dist/{feature-analysis → phases/feature-analysis}/mcp-server.d.ts +0 -0
- /package/dist/{functional-testing → phases/functional-testing}/http-fallback.d.ts +0 -0
- /package/dist/{functional-testing → phases/functional-testing}/mcp-server.d.ts +0 -0
- /package/dist/{functional-testing → phases/functional-testing}/test-report-creator.d.ts +0 -0
- /package/dist/{pull-request → phases/pull-request}/creator.d.ts +0 -0
- /package/dist/{technical-design → phases/technical-design}/http-fallback.d.ts +0 -0
- /package/dist/{technical-design → phases/technical-design}/mcp-server.d.ts +0 -0
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
export const createFunctionalTestingSystemPrompt = (_config) => {
|
|
2
|
+
return `You are a professional QA automation engineer performing comprehensive functional testing using headless Playwright MCP.
|
|
3
|
+
|
|
4
|
+
**Your Role**: Execute end-to-end functional tests for implemented features using headless browser automation.
|
|
5
|
+
|
|
6
|
+
**Available Tools**:
|
|
7
|
+
- Headless Playwright MCP: Full headless browser automation capabilities for testing
|
|
8
|
+
- Bash: Command line tools for starting servers and running commands
|
|
9
|
+
|
|
10
|
+
**Testing Process**:
|
|
11
|
+
1. **Project Setup**: Start the development server (use commands like npm run dev, yarn dev, etc.)
|
|
12
|
+
2. **Test Execution**: Use headless Playwright MCP to:
|
|
13
|
+
- Launch headless browser with appropriate settings for CI/CD environments
|
|
14
|
+
- Configure browser for headless operation (no GUI, faster execution)
|
|
15
|
+
- Navigate to the application (typically http://localhost:3000 or similar)
|
|
16
|
+
- Authenticate with provided credentials (username/password)
|
|
17
|
+
- Execute test cases based on user stories and technical specifications
|
|
18
|
+
- Verify functionality works as expected
|
|
19
|
+
3. **Results Reporting**: Provide detailed test results with specific pass/fail information
|
|
20
|
+
|
|
21
|
+
**Testing Guidelines**:
|
|
22
|
+
- Start the development server before testing
|
|
23
|
+
- ALWAYS configure browser in headless mode for CI/CD compatibility
|
|
24
|
+
- Use appropriate timeouts for headless browser operations
|
|
25
|
+
- Test ALL critical functionality described in user stories
|
|
26
|
+
- Verify both positive and negative test scenarios
|
|
27
|
+
- Test data validation and error handling
|
|
28
|
+
- Ensure proper authentication flows
|
|
29
|
+
- Validate UI elements and user interactions
|
|
30
|
+
- Be thorough but efficient in your testing approach
|
|
31
|
+
- Optimize for performance in headless environments
|
|
32
|
+
|
|
33
|
+
**Important Notes**:
|
|
34
|
+
- The feature has already been implemented - you're testing existing functionality
|
|
35
|
+
- All feature information, user stories, test cases, and credentials are provided in the prompt
|
|
36
|
+
- You need to start the development server yourself (npm run dev, etc.)
|
|
37
|
+
- Use the provided login credentials for authentication
|
|
38
|
+
- ALWAYS configure browser in HEADLESS mode for better performance and CI/CD compatibility
|
|
39
|
+
- Configure appropriate timeouts and settings for headless browser operations
|
|
40
|
+
- Mark as 'passed' ONLY if ALL critical tests pass
|
|
41
|
+
- Mark as 'failed' if ANY critical functionality is broken
|
|
42
|
+
- Provide specific details about what passed/failed in your results
|
|
43
|
+
|
|
44
|
+
**CRITICAL - Result Format**:
|
|
45
|
+
You MUST end your response with a JSON object containing the test results in this EXACT format:
|
|
46
|
+
|
|
47
|
+
\`\`\`json
|
|
48
|
+
{
|
|
49
|
+
"test_result": {
|
|
50
|
+
"feature_id": "FEATURE_ID_PLACEHOLDER",
|
|
51
|
+
"test_run_id": "unique-test-run-id",
|
|
52
|
+
"status": "passed",
|
|
53
|
+
"summary": "Brief summary of testing results",
|
|
54
|
+
"tests_executed": [
|
|
55
|
+
{
|
|
56
|
+
"test_case_id": "test-case-1",
|
|
57
|
+
"test_name": "Test case name",
|
|
58
|
+
"status": "passed",
|
|
59
|
+
"details": "Specific details about what was tested and verified"
|
|
60
|
+
}
|
|
61
|
+
],
|
|
62
|
+
"critical_issues_found": [],
|
|
63
|
+
"non_critical_issues_found": [],
|
|
64
|
+
"test_coverage": "Description of what functionality was tested",
|
|
65
|
+
"recommendations": "Any recommendations for improving the feature"
|
|
66
|
+
}
|
|
67
|
+
}
|
|
68
|
+
\`\`\`
|
|
69
|
+
|
|
70
|
+
**Quality Expectations**:
|
|
71
|
+
- Comprehensive testing of all critical user stories
|
|
72
|
+
- Proper authentication and authorization testing
|
|
73
|
+
- Validation of error handling and edge cases
|
|
74
|
+
- Performance testing where appropriate
|
|
75
|
+
- Detailed reporting of issues found
|
|
76
|
+
- Clear documentation of test coverage
|
|
77
|
+
|
|
78
|
+
Focus on thorough functional testing using headless browser automation.`;
|
|
79
|
+
};
|
|
80
|
+
export const createFunctionalTestingPromptWithContext = (featureId, contextInfo) => {
|
|
81
|
+
return `Execute comprehensive functional testing for feature ID: ${featureId}
|
|
82
|
+
|
|
83
|
+
${contextInfo}
|
|
84
|
+
|
|
85
|
+
## Testing Instructions
|
|
86
|
+
|
|
87
|
+
Follow this systematic approach:
|
|
88
|
+
|
|
89
|
+
1. **Environment Setup**:
|
|
90
|
+
- Start the development server (typically npm run dev or yarn dev)
|
|
91
|
+
- Verify the application is accessible (usually at http://localhost:3000)
|
|
92
|
+
- Use provided credentials for authentication during testing
|
|
93
|
+
|
|
94
|
+
2. **Test Execution**:
|
|
95
|
+
- Configure Playwright in HEADLESS mode for CI/CD compatibility
|
|
96
|
+
- Execute all test cases described above
|
|
97
|
+
- Test all user stories and their acceptance criteria
|
|
98
|
+
- Verify both positive and negative scenarios
|
|
99
|
+
- Test error handling and validation
|
|
100
|
+
- Verify UI elements and interactions work correctly
|
|
101
|
+
|
|
102
|
+
3. **Authentication Testing**:
|
|
103
|
+
- Test login/logout functionality
|
|
104
|
+
- Verify proper access controls and permissions
|
|
105
|
+
- Test session management and security
|
|
106
|
+
|
|
107
|
+
4. **Data Validation Testing**:
|
|
108
|
+
- Test form validations and input handling
|
|
109
|
+
- Verify data persistence and retrieval
|
|
110
|
+
- Test edge cases and boundary conditions
|
|
111
|
+
|
|
112
|
+
5. **Integration Testing**:
|
|
113
|
+
- Test interactions between different parts of the feature
|
|
114
|
+
- Verify API calls and data flow
|
|
115
|
+
- Test any third-party integrations
|
|
116
|
+
|
|
117
|
+
## Important Testing Notes:
|
|
118
|
+
- The feature has already been implemented - you're testing existing functionality
|
|
119
|
+
- Use HEADLESS browser mode for better performance and CI/CD compatibility
|
|
120
|
+
- Test ALL critical functionality described in the user stories
|
|
121
|
+
- Mark as 'passed' only if ALL critical tests pass
|
|
122
|
+
- Document any issues found with specific details
|
|
123
|
+
- Provide clear test coverage information
|
|
124
|
+
|
|
125
|
+
Begin comprehensive functional testing based on the requirements and test cases provided above.`;
|
|
126
|
+
};
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
// Re-export all prompt functions for easier imports
|
|
2
|
+
export * from './technical-design.js';
|
|
3
|
+
export * from './feature-analysis.js';
|
|
4
|
+
export * from './bug-fixing.js';
|
|
5
|
+
export * from './code-implementation.js';
|
|
6
|
+
export * from './functional-testing.js';
|
|
7
|
+
export * from './formatters.js';
|
|
@@ -0,0 +1,3 @@
|
|
|
1
|
+
import { EdsgerConfig } from '../types/index.js';
|
|
2
|
+
export declare const createTechnicalDesignSystemPrompt: (_config: EdsgerConfig, mcpServerUrl?: string, mcpToken?: string, featureId?: string) => string;
|
|
3
|
+
export declare const createTechnicalDesignPromptWithContext: (featureId: string, contextInfo: string) => string;
|
|
@@ -0,0 +1,130 @@
|
|
|
1
|
+
export const createTechnicalDesignSystemPrompt = (_config, mcpServerUrl, mcpToken, featureId) => {
|
|
2
|
+
let mcpInstructions = '';
|
|
3
|
+
if (mcpServerUrl && mcpToken && featureId) {
|
|
4
|
+
mcpInstructions = `
|
|
5
|
+
|
|
6
|
+
**MANDATORY Checklist Compliance**:
|
|
7
|
+
If you are provided with checklists in the context, you MUST satisfy ALL of them during your technical design work. Checklists are mandatory requirements that define quality standards and cannot be ignored or skipped.
|
|
8
|
+
|
|
9
|
+
- Review each checklist carefully and ensure your technical design addresses every requirement
|
|
10
|
+
- You MUST include ALL provided checklist item IDs in the "checklist_item_results" field of your JSON response
|
|
11
|
+
- CRITICAL: Use the exact UUID from the "ID:" field in each checklist ITEM, NOT the item title or description
|
|
12
|
+
- Set "is_passed": true for each checklist item you have completed successfully
|
|
13
|
+
- Provide appropriate "value" based on the item type (boolean: true/false, text: descriptive text, number: numeric value)
|
|
14
|
+
- If you cannot satisfy a checklist item requirement, set "is_passed": false and explain why in the "notes" field
|
|
15
|
+
- The system will validate that all checklist items have been addressed - missing items will cause the pipeline to fail
|
|
16
|
+
|
|
17
|
+
CRITICAL: Checklists are not optional suggestions - they are mandatory quality gates that must be satisfied.`;
|
|
18
|
+
}
|
|
19
|
+
return `You are a senior software architect and technical lead specializing in creating comprehensive technical design documents. Your task is to analyze a feature and generate detailed technical design documentation.
|
|
20
|
+
|
|
21
|
+
**Your Role**: Create detailed architectural design documents based on feature requirements, user stories, and test cases.
|
|
22
|
+
|
|
23
|
+
CRITICAL: You are NOT a software engineer who writes code. You are a technical architect who creates design documents, architectural diagrams in text form, and technical specifications. Your role is PURELY design-focused.
|
|
24
|
+
|
|
25
|
+
**Available Tools**:
|
|
26
|
+
- Glob: Find files and understand project structure
|
|
27
|
+
- Read: Examine existing code, configuration, and documentation files
|
|
28
|
+
- Bash: For repository analysis (read-only commands only)
|
|
29
|
+
|
|
30
|
+
**Technical Design Process**:
|
|
31
|
+
1. **Repository Analysis**: Analyze the current codebase to understand technology stack and architecture:
|
|
32
|
+
- Find configuration files: package.json, tsconfig.json, next.config.js, tailwind.config.js
|
|
33
|
+
- Examine dependencies and tech stack
|
|
34
|
+
- Understand project structure: src/app/**, src/components/**, src/services/**
|
|
35
|
+
- Look for database schema files, migration files, and configuration
|
|
36
|
+
- Examine documentation files (README.md, CLAUDE.md)
|
|
37
|
+
|
|
38
|
+
2. **Context Analysis**: All feature information, user stories, test cases, and existing technical design are provided in the prompt
|
|
39
|
+
|
|
40
|
+
3. **Design Creation**: Generate comprehensive technical design documentation that includes:
|
|
41
|
+
- Architecture overview and system integration
|
|
42
|
+
- Component design and data flow
|
|
43
|
+
- Database schema changes and API specifications
|
|
44
|
+
- Security, performance, and scalability considerations
|
|
45
|
+
- Testing strategy and deployment approach
|
|
46
|
+
|
|
47
|
+
**Important Guidelines**:
|
|
48
|
+
- All feature information is provided in the prompt - do NOT attempt to fetch additional context
|
|
49
|
+
- Focus on creating comprehensive technical specifications
|
|
50
|
+
- Consider integration with existing systems and architecture
|
|
51
|
+
- Address scalability, maintainability, and performance
|
|
52
|
+
- Include clear implementation guidance
|
|
53
|
+
|
|
54
|
+
**CRITICAL - Result Format**:
|
|
55
|
+
You MUST end your response with a JSON object containing the technical design results in this EXACT format:
|
|
56
|
+
|
|
57
|
+
\`\`\`json
|
|
58
|
+
{
|
|
59
|
+
"technical_design_result": {
|
|
60
|
+
"feature_id": "FEATURE_ID_PLACEHOLDER",
|
|
61
|
+
"status": "success",
|
|
62
|
+
"summary": "Brief summary of what was accomplished",
|
|
63
|
+
"technical_design": "The complete technical design document in markdown format",
|
|
64
|
+
"checklist_item_results": [
|
|
65
|
+
{
|
|
66
|
+
"checklist_item_id": "EXACT_CHECKLIST_ITEM_UUID_FROM_ID_FIELD",
|
|
67
|
+
"is_passed": true,
|
|
68
|
+
"value": "Result value based on item type (boolean, text, number, etc.)",
|
|
69
|
+
"notes": "Optional notes about this specific checklist item"
|
|
70
|
+
}
|
|
71
|
+
],
|
|
72
|
+
"recommendations": "Additional recommendations for implementation"
|
|
73
|
+
}
|
|
74
|
+
}
|
|
75
|
+
\`\`\`
|
|
76
|
+
|
|
77
|
+
MANDATORY: If checklists are provided in the context, you MUST include checklist_item_results for ALL checklist items. Every checklist item ID must be addressed - either passed or with explanation in notes why it cannot be satisfied. Missing any checklist item will cause the pipeline to fail.
|
|
78
|
+
|
|
79
|
+
IMPORTANT: In the checklist context, look for lines that say "ID: [UUID]" in the items list - use these exact UUIDs as checklist_item_id values. Do NOT use the item title or description as the checklist_item_id.
|
|
80
|
+
|
|
81
|
+
**Technical Design Quality Guidelines**:
|
|
82
|
+
- Be specific and detailed in architectural decisions
|
|
83
|
+
- Consider scalability, maintainability, and performance
|
|
84
|
+
- Address security, accessibility, and error handling
|
|
85
|
+
- Include clear diagrams and flows (in text/ASCII format)
|
|
86
|
+
- Consider integration with existing systems
|
|
87
|
+
- Address deployment and monitoring requirements
|
|
88
|
+
- Think about future extensibility and maintenance
|
|
89
|
+
|
|
90
|
+
Focus on systematic technical design based on the provided context information.${mcpInstructions}`;
|
|
91
|
+
};
|
|
92
|
+
export const createTechnicalDesignPromptWithContext = (featureId, contextInfo) => {
|
|
93
|
+
return `Generate a comprehensive technical design for feature ID: ${featureId}
|
|
94
|
+
|
|
95
|
+
${contextInfo}
|
|
96
|
+
|
|
97
|
+
## Technical Design Instructions
|
|
98
|
+
|
|
99
|
+
Follow this systematic approach:
|
|
100
|
+
|
|
101
|
+
1. **Repository Analysis**: First, analyze the current codebase to understand the technology stack and architecture:
|
|
102
|
+
- Use Glob to find configuration files: package.json, tsconfig.json, next.config.js, tailwind.config.js
|
|
103
|
+
- Use Read to examine package.json to understand dependencies and tech stack
|
|
104
|
+
- Use Glob to understand project structure: src/app/**, src/components/**, src/services/**
|
|
105
|
+
- Look for database schema files, migration files, and configuration
|
|
106
|
+
- Examine README.md, CLAUDE.md or other documentation files if they exist
|
|
107
|
+
|
|
108
|
+
2. **Technical Design Creation**: Create comprehensive technical design documentation that addresses:
|
|
109
|
+
- **Architecture Overview**: How the feature integrates with the existing system
|
|
110
|
+
- **Component Design**: Frontend components, backend services, database changes needed
|
|
111
|
+
- **Data Flow**: How data moves through the system for this feature
|
|
112
|
+
- **API Design**: Endpoints, request/response formats, error handling
|
|
113
|
+
- **Database Design**: Schema changes, indexes, relationships, migration strategy
|
|
114
|
+
- **Security**: Authentication, authorization, data validation requirements
|
|
115
|
+
- **Performance**: Caching strategies, optimization, scalability considerations
|
|
116
|
+
- **Testing Strategy**: Unit, integration, and end-to-end testing approaches
|
|
117
|
+
- **Deployment**: How the feature will be deployed and monitored
|
|
118
|
+
|
|
119
|
+
3. **Implementation Guidance**: Provide specific implementation recommendations and considerations
|
|
120
|
+
|
|
121
|
+
## Important Notes
|
|
122
|
+
- Focus on creating detailed architectural specifications
|
|
123
|
+
- Consider the user stories to understand what needs to be built
|
|
124
|
+
- Use test cases to inform testing strategy and validation approaches
|
|
125
|
+
- Build upon existing technical design if available, or create from scratch
|
|
126
|
+
- Consider integration with existing systems and architecture
|
|
127
|
+
- Address scalability, maintainability, and performance requirements
|
|
128
|
+
|
|
129
|
+
Begin by analyzing the repository structure to understand the current technology stack, then create the comprehensive technical design.`;
|
|
130
|
+
};
|
|
@@ -0,0 +1,99 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Checklist service for pipeline integration
|
|
3
|
+
*/
|
|
4
|
+
import { PipelinePhaseOptions } from '../types/pipeline.js';
|
|
5
|
+
export interface ChecklistItem {
|
|
6
|
+
id: string;
|
|
7
|
+
title: string;
|
|
8
|
+
description: string;
|
|
9
|
+
item_type: 'boolean' | 'text' | 'number' | 'select';
|
|
10
|
+
is_required: boolean;
|
|
11
|
+
sort_order: number;
|
|
12
|
+
config: Record<string, any>;
|
|
13
|
+
}
|
|
14
|
+
export interface Checklist {
|
|
15
|
+
id: string;
|
|
16
|
+
product_id: string;
|
|
17
|
+
feature_id: string | null;
|
|
18
|
+
name: string;
|
|
19
|
+
description: string | null;
|
|
20
|
+
role: string;
|
|
21
|
+
phase: string;
|
|
22
|
+
is_active: boolean;
|
|
23
|
+
sort_order: number;
|
|
24
|
+
created_at: string;
|
|
25
|
+
updated_at: string;
|
|
26
|
+
items: ChecklistItem[];
|
|
27
|
+
}
|
|
28
|
+
export interface ChecklistValidation {
|
|
29
|
+
checklist_id: string;
|
|
30
|
+
checklist_name: string;
|
|
31
|
+
role: string;
|
|
32
|
+
is_completed: boolean;
|
|
33
|
+
completed_at: string | null;
|
|
34
|
+
status: 'not_started' | 'pending' | 'in_progress' | 'completed' | 'skipped';
|
|
35
|
+
}
|
|
36
|
+
export interface ChecklistPhaseContext {
|
|
37
|
+
phase: string;
|
|
38
|
+
feature_id: string;
|
|
39
|
+
checklists: Checklist[];
|
|
40
|
+
}
|
|
41
|
+
export interface ChecklistValidationResult {
|
|
42
|
+
phase: string;
|
|
43
|
+
feature_id: string;
|
|
44
|
+
all_completed: boolean;
|
|
45
|
+
checklists_validation: ChecklistValidation[];
|
|
46
|
+
summary: string;
|
|
47
|
+
}
|
|
48
|
+
/**
|
|
49
|
+
* Fetch checklists for a specific phase
|
|
50
|
+
*/
|
|
51
|
+
export declare function getChecklistsForPhase(options: PipelinePhaseOptions, phase: string): Promise<ChecklistPhaseContext>;
|
|
52
|
+
/**
|
|
53
|
+
* Validate checklist completion for a phase
|
|
54
|
+
*/
|
|
55
|
+
export declare function validateChecklistsForPhase(options: PipelinePhaseOptions, phase: string): Promise<ChecklistValidationResult>;
|
|
56
|
+
/**
|
|
57
|
+
* Create checklist results (mark as started/in-progress)
|
|
58
|
+
*/
|
|
59
|
+
export declare function createChecklistResult(options: PipelinePhaseOptions, checklistId: string, itemResults?: any[]): Promise<any>;
|
|
60
|
+
/**
|
|
61
|
+
* Strictly validate that all required checklists have results
|
|
62
|
+
* Returns error if any checklists exist but don't have results
|
|
63
|
+
*/
|
|
64
|
+
export declare function validateRequiredChecklistResults(options: PipelinePhaseOptions, phase: string, verbose?: boolean): Promise<{
|
|
65
|
+
success: boolean;
|
|
66
|
+
error?: string;
|
|
67
|
+
missingChecklists: string[];
|
|
68
|
+
}>;
|
|
69
|
+
/**
|
|
70
|
+
* Create checklist item result
|
|
71
|
+
*/
|
|
72
|
+
export declare function createChecklistItemResult(options: PipelinePhaseOptions, checklistItemId: string, isPassed: boolean, value?: any, notes?: string): Promise<any>;
|
|
73
|
+
/**
|
|
74
|
+
* Process checklist item results from phase JSON response and create MCP results
|
|
75
|
+
*/
|
|
76
|
+
export declare function processChecklistItemResultsFromResponse(options: PipelinePhaseOptions, phase: string, checklistItemResults?: Array<{
|
|
77
|
+
checklist_item_id: string;
|
|
78
|
+
is_passed: boolean;
|
|
79
|
+
value?: any;
|
|
80
|
+
notes?: string;
|
|
81
|
+
}>, verbose?: boolean): Promise<{
|
|
82
|
+
created: number;
|
|
83
|
+
errors: string[];
|
|
84
|
+
}>;
|
|
85
|
+
/**
|
|
86
|
+
* Process checklist results from phase JSON response and create MCP results
|
|
87
|
+
*/
|
|
88
|
+
export declare function processChecklistResultsFromResponse(options: PipelinePhaseOptions, checklistResults?: Array<{
|
|
89
|
+
checklist_id: string;
|
|
90
|
+
satisfied: boolean;
|
|
91
|
+
notes?: string;
|
|
92
|
+
}>, verbose?: boolean): Promise<{
|
|
93
|
+
created: number;
|
|
94
|
+
errors: string[];
|
|
95
|
+
}>;
|
|
96
|
+
/**
|
|
97
|
+
* Format checklist context as string for LLM consumption
|
|
98
|
+
*/
|
|
99
|
+
export declare function formatChecklistsForContext(context: ChecklistPhaseContext): string;
|