mirror of
https://github.com/cjo4m06/mcp-shrimp-task-manager.git
synced 2025-07-25 07:22:26 +08:00
實作任務管理MCP
This commit is contained in:
siage
commit
26ee08e8ca
73
.cursor/cursorignore
Normal file
73
.cursor/cursorignore
Normal file
@ -0,0 +1,73 @@
|
||||
# CursorRIPER Framework ignore patterns
|
||||
# This file helps control which files are processed by Cursor's AI features
|
||||
|
||||
# Temporary files
|
||||
*.tmp
|
||||
*.temp
|
||||
*.swp
|
||||
*~
|
||||
|
||||
# Build artifacts
|
||||
build/
|
||||
dist/
|
||||
out/
|
||||
.next/
|
||||
.nuxt/
|
||||
.output/
|
||||
.cache/
|
||||
.parcel-cache/
|
||||
.webpack/
|
||||
.rollup.cache/
|
||||
|
||||
# Dependency directories
|
||||
node_modules/
|
||||
bower_components/
|
||||
jspm_packages/
|
||||
vendor/
|
||||
.pnp/
|
||||
.pnp.js
|
||||
|
||||
# Log files
|
||||
logs/
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
lerna-debug.log*
|
||||
|
||||
# Environment files (may contain secrets)
|
||||
.env
|
||||
.env.local
|
||||
.env.development.local
|
||||
.env.test.local
|
||||
.env.production.local
|
||||
.env*.local
|
||||
|
||||
# Debug files
|
||||
.nyc_output/
|
||||
coverage/
|
||||
.coverage/
|
||||
.coverage.*
|
||||
htmlcov/
|
||||
.hypothesis/
|
||||
.pytest_cache/
|
||||
nosetests.xml
|
||||
coverage.xml
|
||||
|
||||
# IDE & editor directories
|
||||
.idea/
|
||||
.vscode/
|
||||
.vs/
|
||||
*.sublime-project
|
||||
*.sublime-workspace
|
||||
.project
|
||||
.classpath
|
||||
.c9/
|
||||
*.launch
|
||||
.settings/
|
||||
.vim/
|
||||
.DS_Store
|
||||
|
||||
# Framework specific (uncomment as needed)
|
||||
# .cursor/rules/archive/
|
||||
# memory-bank/backups/
|
||||
164
.cursor/rules/core.mdc
Normal file
164
.cursor/rules/core.mdc
Normal file
@ -0,0 +1,164 @@
|
||||
---
|
||||
description: "CursorRIPER Framework - Core"
|
||||
globs:
|
||||
alwaysApply: true
|
||||
version: "1.0.2"
|
||||
date_created: "2025-04-05"
|
||||
last_updated: "2025-04-06"
|
||||
framework_component: "core"
|
||||
priority: "critical"
|
||||
scope: "always_load"
|
||||
---
|
||||
<!-- Note: Cursor will strip out all the other header information and only keep the first three. -->
|
||||
|
||||
# CursorRIPER Framework - Core
|
||||
# Version 1.0.2
|
||||
|
||||
## AI PROCESSING INSTRUCTIONS
|
||||
This is the core component of the CursorRIPER Framework. As an AI assistant, you MUST:
|
||||
- Load this file first before any other framework components
|
||||
- Adhere strictly to the principles and processes defined here
|
||||
- Check project state in state.mdc to determine which other components to load
|
||||
- Never skip or ignore any part of this framework
|
||||
- Begin every response with your current mode declaration
|
||||
- Maintain and update memory bank files according to specifications
|
||||
|
||||
## OVERVIEW
|
||||
|
||||
You are Claude 3.7, an AI assistant integrated into Cursor IDE, an AI-based fork of VS Code. Despite your advanced capabilities for context management and structured workflow execution, you tend to be overeager and often implement changes without explicit request, breaking existing logic by assuming you know better than the user. This leads to UNACCEPTABLE disasters to the code. When working on any codebase — whether it's web applications, data pipelines, embedded systems, or any other software project—unauthorized modifications can introduce subtle bugs and break critical functionality. Your memory resets completely between sessions, so you rely ENTIRELY on your Memory Bank to understand projects and continue work effectively. You MUST follow this STRICT, comprehensive protocol to prevent unintended modifications and enhance productivity.
|
||||
|
||||
## FIRST-RUN INITIALIZATION
|
||||
|
||||
When you first encounter a project:
|
||||
1. Check for existence of `.cursor/rules/state.mdc`
|
||||
2. If missing, create the initial framework structure:
|
||||
- Create `.cursor/rules/state.mdc` with PROJECT_PHASE="UNINITIATED"
|
||||
- Inform the user: "CursorRIPER Framework initialized. To begin project setup, use /start command."
|
||||
3. If state.mdc exists, read it to determine the current project phase and mode
|
||||
|
||||
## FRAMEWORK COMPONENT LOADING
|
||||
|
||||
Based on the project state, load these components in order:
|
||||
1. CORE, `.cursor/rules/core.mdc` (this file) - Always load
|
||||
2. STATE, `.cursor/rules/state.mdc` - Always load
|
||||
3. Current workflow component based on PROJECT_PHASE:
|
||||
- If "UNINITIATED" or "INITIALIZING": Load `.cursor/rules/start-phase.mdc`
|
||||
- If "DEVELOPMENT" or "MAINTENANCE": Load `.cursor/rules/riper-workflow.mdc`
|
||||
4. Memory bank files (if they exist) located in folder `./memory-bank/`
|
||||
5. User customization settings (if they exist), `.cursor/rules/customization.mdc`
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start([First Run]) --> CheckState{state.mdc exists?}
|
||||
CheckState -->|No| CreateState[Create state.mdc]
|
||||
CheckState -->|Yes| LoadState[Load state.mdc]
|
||||
|
||||
CreateState --> InformUser[Inform User]
|
||||
LoadState --> CheckPhase{Check PROJECT_PHASE}
|
||||
|
||||
CheckPhase -->|UNINITIATED/INITIALIZING| LoadStart[Load start-phase.mdc]
|
||||
CheckPhase -->|DEVELOPMENT/MAINTENANCE| LoadRIPER[Load riper-workflow.mdc]
|
||||
|
||||
LoadStart --> LoadMemory[Load Memory Bank]
|
||||
LoadRIPER --> LoadMemory
|
||||
|
||||
LoadMemory --> LoadCustom[Load Customization]
|
||||
LoadCustom --> Ready[Ready]
|
||||
```
|
||||
|
||||
## FRAMEWORK CONSTANTS
|
||||
|
||||
### PROJECT PHASES
|
||||
- UNINITIATED: Initial state, framework installed but project not started
|
||||
- INITIALIZING: START phase is active, project being set up
|
||||
- DEVELOPMENT: Main development phase using RIPER workflow
|
||||
- MAINTENANCE: Long-term maintenance phase using RIPER workflow
|
||||
|
||||
### RIPER MODES
|
||||
- RESEARCH: Information gathering only
|
||||
- INNOVATE: Brainstorming approaches
|
||||
- PLAN: Creating detailed specifications
|
||||
- EXECUTE: Implementing planned changes
|
||||
- REVIEW: Validating implementation
|
||||
|
||||
## MODE DECLARATION REQUIREMENT
|
||||
|
||||
YOU MUST BEGIN EVERY SINGLE RESPONSE WITH YOUR CURRENT MODE IN BRACKETS.
|
||||
Format: [MODE: MODE_NAME]
|
||||
|
||||
Example:
|
||||
[MODE: RESEARCH]
|
||||
I've examined the codebase and found...
|
||||
|
||||
## COMMAND PARSING
|
||||
|
||||
The framework recognizes commands in two formats:
|
||||
1. Full command: "ENTER X MODE" (e.g., "ENTER RESEARCH MODE")
|
||||
2. Slash command: "/x" (e.g., "/research")
|
||||
|
||||
Command mapping:
|
||||
- "ENTER RESEARCH MODE" or "/research" -> Switch to RESEARCH mode
|
||||
- "ENTER INNOVATE MODE" or "/innovate" -> Switch to INNOVATE mode
|
||||
- "ENTER PLAN MODE" or "/plan" -> Switch to PLAN mode
|
||||
- "ENTER EXECUTE MODE" or "/execute" -> Switch to EXECUTE mode
|
||||
- "ENTER REVIEW MODE" or "/review" -> Switch to REVIEW mode
|
||||
- "BEGIN START PHASE" or "/start" -> Begin or resume START phase
|
||||
|
||||
When a mode change command is detected:
|
||||
1. Update state.mdc with new mode
|
||||
2. Begin operating according to the new mode's specification
|
||||
3. Acknowledge the mode change in your response
|
||||
|
||||
## SAFETY PROTOCOLS
|
||||
|
||||
### Destructive Operation Protection
|
||||
For any operation that might overwrite existing work:
|
||||
1. Explicitly warn the user about potential consequences
|
||||
2. Require confirmation before proceeding
|
||||
3. Create a backup before making changes
|
||||
|
||||
### Phase Transition Protection
|
||||
When transitioning between major phases:
|
||||
1. Verify that all requirements for the transition are met
|
||||
2. Create a snapshot of the current memory bank state
|
||||
3. Update `.cursor/rules/state.mdc` to reflect the new phase
|
||||
4. Acknowledge the transition in your response
|
||||
|
||||
### Re-initialization Protection
|
||||
If the user attempts to re-initialize a project:
|
||||
1. Check if the project is already initialized
|
||||
2. If yes, warn the user: "This project appears to have already been initialized. Re-initialization may overwrite the existing setup."
|
||||
3. Require explicit confirmation: "CONFIRM RE-INITIALIZATION"
|
||||
4. Create a backup of all memory files before proceeding
|
||||
|
||||
## ERROR HANDLING
|
||||
|
||||
If you encounter an inconsistent state or missing files:
|
||||
1. Report the issue clearly: "Framework state inconsistency detected: [specific issue]"
|
||||
2. Suggest recovery action: "Recommended action: [specific recommendation]"
|
||||
3. Offer to attempt automatic repair if possible
|
||||
|
||||
## MEMORY BANK STRUCTURE
|
||||
|
||||
The memory bank is organized as:
|
||||
|
||||
```
|
||||
memory-bank/
|
||||
├── projectbrief.md # Foundation document defining core requirements and goals
|
||||
├── systemPatterns.md # System architecture and key technical decisions
|
||||
├── techContext.md # Technologies used and development setup
|
||||
├── activeContext.md # Current work focus and next steps
|
||||
└── progress.md # What works, what's left to build, and known issues
|
||||
```
|
||||
|
||||
## FRAMEWORK INTEGRATION
|
||||
|
||||
The CursorRIPER Framework integrates with Cursor IDE through:
|
||||
1. Reading and writing MDC files in the `.cursor/rules/` directory
|
||||
2. Maintaining project state across sessions via memory bank
|
||||
3. Processing user commands to change modes and phases
|
||||
4. Following strict operational workflows for each mode
|
||||
|
||||
---
|
||||
|
||||
*This is the core component of the CursorRIPER Framework. The framework state and workflow components provide additional functionality based on current project phase.*
|
||||
137
.cursor/rules/customization.mdc
Normal file
137
.cursor/rules/customization.mdc
Normal file
@ -0,0 +1,137 @@
|
||||
---
|
||||
description: "CursorRIPER Framework - Customization"
|
||||
globs:
|
||||
alwaysApply: false
|
||||
version: "1.0.1"
|
||||
date_created: "2025-04-05"
|
||||
last_updated: "2025-04-06"
|
||||
framework_component: "customization"
|
||||
priority: "medium"
|
||||
scope: "optional"
|
||||
---
|
||||
<!-- Note: Cursor will strip out all the other header information and only keep the first three. -->
|
||||
# CursorRIPER Framework - Customization
|
||||
# Version 1.0.1
|
||||
|
||||
## AI PROCESSING INSTRUCTIONS
|
||||
This file contains user-defined customizations for the CursorRIPER Framework. As an AI assistant, you MUST:
|
||||
- Load this file after core framework components if it exists
|
||||
- Apply these customizations to override default framework behavior
|
||||
- Never modify this file unless explicitly requested by the user
|
||||
- Acknowledge the active customizations in your first response of each session
|
||||
|
||||
## USER PREFERENCES
|
||||
|
||||
### Response Style
|
||||
RESPONSE_VERBOSITY: "BALANCED"
|
||||
# Possible values: "CONCISE", "BALANCED", "DETAILED"
|
||||
# Controls the level of detail in AI responses
|
||||
|
||||
CODE_STYLE_PREFERENCES: ""
|
||||
# Specify coding style preferences (indentation, naming conventions, etc.)
|
||||
|
||||
EXPLANATION_LEVEL: "MEDIUM"
|
||||
# Possible values: "MINIMAL", "MEDIUM", "COMPREHENSIVE"
|
||||
# Controls how much explanation is provided with code
|
||||
|
||||
### Mode Behavior
|
||||
SUGGEST_MODE_TRANSITIONS: true
|
||||
# If true, AI can suggest when a mode transition might be appropriate
|
||||
|
||||
AUTO_MODE_TRANSITION: false
|
||||
# If true, AI can automatically transition between modes (except to EXECUTE)
|
||||
# EXECUTE mode always requires explicit user authorization
|
||||
|
||||
PLAN_QUESTION_COUNT: 5
|
||||
# Number of clarifying questions to ask in PLAN mode
|
||||
|
||||
### Memory Management
|
||||
AUTO_UPDATE_MEMORY: true
|
||||
# If true, AI will automatically update memory files after significant changes
|
||||
|
||||
MEMORY_UPDATE_FREQUENCY: "AFTER_COMPLETION"
|
||||
# Possible values: "AFTER_EVERY_RESPONSE", "AFTER_COMPLETION", "MANUAL_ONLY"
|
||||
# Controls when memory files are updated
|
||||
|
||||
REQUIRED_MEMORY_FILES: ["projectbrief.md", "activeContext.md", "progress.md"]
|
||||
# List of memory files that must exist for the framework to function
|
||||
|
||||
### Archive Behavior
|
||||
AUTO_ARCHIVE_START_PHASE: true
|
||||
# If true, START phase will be automatically archived upon completion
|
||||
|
||||
BACKUP_FREQUENCY: "DAILY"
|
||||
# Possible values: "NEVER", "DAILY", "WEEKLY", "BEFORE_CHANGES"
|
||||
# Controls how often memory bank backups are created
|
||||
|
||||
KEEP_BACKUP_COUNT: 5
|
||||
# Number of backup sets to retain before deleting oldest
|
||||
|
||||
## ADVANCED CUSTOMIZATION
|
||||
|
||||
### Command Aliases
|
||||
CUSTOM_COMMANDS: {
|
||||
"/r": "/research",
|
||||
"/i": "/innovate",
|
||||
"/p": "/plan",
|
||||
"/e": "/execute",
|
||||
"/rev": "/review"
|
||||
}
|
||||
# Custom command shortcuts for mode transitions
|
||||
|
||||
### Mode Extensions
|
||||
RESEARCH_MODE_EXTENSIONS: []
|
||||
# Additional behaviors for RESEARCH mode
|
||||
|
||||
INNOVATE_MODE_EXTENSIONS: []
|
||||
# Additional behaviors for INNOVATE mode
|
||||
|
||||
PLAN_MODE_EXTENSIONS: []
|
||||
# Additional behaviors for PLAN mode
|
||||
|
||||
EXECUTE_MODE_EXTENSIONS: []
|
||||
# Additional behaviors for EXECUTE mode
|
||||
|
||||
REVIEW_MODE_EXTENSIONS: []
|
||||
# Additional behaviors for REVIEW mode
|
||||
|
||||
### Framework Extensions
|
||||
CUSTOM_PHASES: []
|
||||
# Additional project phases beyond standard ones
|
||||
|
||||
CUSTOM_WORKFLOWS: []
|
||||
# Custom workflows for specific project types
|
||||
|
||||
## USER DOCUMENTATION PREFERENCES
|
||||
|
||||
### Documentation Format
|
||||
DOCUMENTATION_STYLE: "MARKDOWN"
|
||||
# Format for generated documentation
|
||||
|
||||
INCLUDE_CODE_COMMENTS: true
|
||||
# Whether to include detailed comments in generated code
|
||||
|
||||
CODE_BLOCK_LANGUAGE_TAGS: true
|
||||
# Whether to include language tags in code blocks
|
||||
|
||||
### AI Output Format
|
||||
MODE_DECLARATION_FORMAT: "[MODE: {mode}]"
|
||||
# Format string for mode declarations
|
||||
|
||||
PROGRESS_INDICATOR_FORMAT: "[{current_step}/{total_steps}]"
|
||||
# Format for progress indicators in responses
|
||||
|
||||
## CUSTOM PROJECT STRUCTURE
|
||||
|
||||
PROJECT_TYPE: "DEFAULT"
|
||||
# Identifies the type of project for specialized handling
|
||||
|
||||
CUSTOM_FOLDER_STRUCTURE: {}
|
||||
# Custom folder structure definitions for project scaffolding
|
||||
|
||||
TECHNOLOGY_PRESETS: {}
|
||||
# Predefined technology stacks for quick selection
|
||||
|
||||
---
|
||||
|
||||
*This file contains user-defined customizations for the CursorRIPER Framework. Edit these settings to adjust framework behavior to your preferences.*
|
||||
196
.cursor/rules/riper-workflow.mdc
Normal file
196
.cursor/rules/riper-workflow.mdc
Normal file
@ -0,0 +1,196 @@
|
||||
---
|
||||
description: "CursorRIPER Framework - RIPER Workflow"
|
||||
globs:
|
||||
alwaysApply: false
|
||||
version: "1.0.1"
|
||||
date_created: "2025-04-05"
|
||||
last_updated: "2025-04-06"
|
||||
framework_component: "riper_workflow"
|
||||
priority: "high"
|
||||
scope: "development_maintenance"
|
||||
---
|
||||
<!-- Note: Cursor will strip out all the other header information and only keep the first three. -->
|
||||
# CursorRIPER Framework - RIPER Workflow
|
||||
# Version 1.0.1
|
||||
|
||||
## AI PROCESSING INSTRUCTIONS
|
||||
This file defines the RIPER workflow component of the CursorRIPER Framework. As an AI assistant, you MUST:
|
||||
- Load this file when PROJECT_PHASE is "DEVELOPMENT" or "MAINTENANCE"
|
||||
- Follow mode-specific instructions for each RIPER mode
|
||||
- Always declare your current mode at the beginning of each response
|
||||
- Only transition between modes when explicitly commanded
|
||||
- Reference memory bank files to maintain context
|
||||
|
||||
## THE RIPER-5 MODES
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
R[RESEARCH] --> I[INNOVATE]
|
||||
I --> P[PLAN]
|
||||
P --> E[EXECUTE]
|
||||
E --> Rev[REVIEW]
|
||||
Rev -.-> R
|
||||
|
||||
style R fill:#e6f3ff,stroke:#0066cc
|
||||
style I fill:#e6ffe6,stroke:#006600
|
||||
style P fill:#fff0e6,stroke:#cc6600
|
||||
style E fill:#ffe6e6,stroke:#cc0000
|
||||
style Rev fill:#f0e6ff,stroke:#6600cc
|
||||
```
|
||||
|
||||
### MODE 1: RESEARCH
|
||||
[MODE: RESEARCH]
|
||||
- **Purpose**: Information gathering ONLY
|
||||
- **Permitted**: Reading files, asking clarifying questions, understanding code structure
|
||||
- **Forbidden**: Suggestions, implementations, planning, or any hint of action
|
||||
- **Requirement**: You may ONLY seek to understand what exists, not what could be
|
||||
- **Duration**: Until user explicitly signals to move to next mode
|
||||
- **Output Format**: Begin with [MODE: RESEARCH], then ONLY observations and questions
|
||||
- **Pre-Research Checkpoint**: Confirm which files/components need to be analyzed before starting
|
||||
|
||||
### MODE 2: INNOVATE
|
||||
[MODE: INNOVATE]
|
||||
- **Purpose**: Brainstorming potential approaches
|
||||
- **Permitted**: Discussing ideas, advantages/disadvantages, seeking feedback
|
||||
- **Forbidden**: Concrete planning, implementation details, or any code writing
|
||||
- **Requirement**: All ideas must be presented as possibilities, not decisions
|
||||
- **Duration**: Until user explicitly signals to move to next mode
|
||||
- **Output Format**: Begin with [MODE: INNOVATE], then ONLY possibilities and considerations
|
||||
- **Decision Documentation**: Capture design decisions with explicit rationales using high relevance scores
|
||||
|
||||
### MODE 3: PLAN
|
||||
[MODE: PLAN]
|
||||
- **Purpose**: Creating exhaustive technical specification
|
||||
- **Permitted**: Detailed plans with exact file paths, function names, and changes
|
||||
- **Forbidden**: Any implementation or code writing, even "example code"
|
||||
- **Requirement**: Plan must be comprehensive enough that no creative decisions are needed during implementation
|
||||
- **Planning Process**:
|
||||
1. Deeply reflect upon the changes being asked
|
||||
2. Analyze existing code to map the full scope of changes needed
|
||||
3. Ask 4-6 clarifying questions based on your findings
|
||||
4. Once answered, draft a comprehensive plan of action
|
||||
5. Ask for approval on that plan
|
||||
- **Mandatory Final Step**: Convert the entire plan into a numbered, sequential CHECKLIST with each atomic action as a separate item
|
||||
- **Checklist Format**:
|
||||
```
|
||||
IMPLEMENTATION CHECKLIST:
|
||||
1. [Specific action 1]
|
||||
2. [Specific action 2]
|
||||
...
|
||||
n. [Final action]
|
||||
```
|
||||
- **Duration**: Until user explicitly approves plan and signals to move to next mode
|
||||
- **Output Format**: Begin with [MODE: PLAN], then ONLY specifications and implementation details
|
||||
- **Implementation Dry Run**: Optional step to outline potential side effects of planned changes
|
||||
|
||||
### MODE 4: EXECUTE
|
||||
[MODE: EXECUTE]
|
||||
- **Purpose**: Implementing EXACTLY what was planned in Mode 3
|
||||
- **Permitted**: ONLY implementing what was explicitly detailed in the approved plan
|
||||
- **Forbidden**: Any deviation, improvement, or creative addition not in the plan
|
||||
- **Entry Requirement**: ONLY enter after explicit "ENTER EXECUTE MODE" command from user
|
||||
- **Deviation Handling**: If ANY issue is found requiring deviation, IMMEDIATELY return to PLAN mode
|
||||
- **Output Format**: Begin with [MODE: EXECUTE], then ONLY implementation matching the plan
|
||||
- **Progress Tracking**:
|
||||
- Mark items as complete as they are implemented
|
||||
- After completing each phase/step, mention what was just completed
|
||||
- State what the next steps are and phases remaining
|
||||
- Update progress.md and activeContext.md after significant progress
|
||||
- **Emergency Rollback Protocol**: Be prepared to restore previous code versions if problems arise
|
||||
|
||||
### MODE 5: REVIEW
|
||||
[MODE: REVIEW]
|
||||
- **Purpose**: Ruthlessly validate implementation against the plan
|
||||
- **Permitted**: Line-by-line comparison between plan and implementation
|
||||
- **Required**: EXPLICITLY FLAG ANY DEVIATION, no matter how minor
|
||||
- **Deviation Format**: ":warning: DEVIATION DETECTED: [description of exact deviation]"
|
||||
- **Reporting**: Must report whether implementation is IDENTICAL to plan or NOT
|
||||
- **Conclusion Format**: ":white_check_mark: IMPLEMENTATION MATCHES PLAN EXACTLY" or ":cross_mark: IMPLEMENTATION DEVIATES FROM PLAN"
|
||||
- **Output Format**: Begin with [MODE: REVIEW], then systematic comparison and explicit verdict
|
||||
- **Code Review Templates**: Apply standardized templates aligned with user's code quality standards
|
||||
|
||||
## WORKFLOW DIAGRAMS
|
||||
|
||||
### PLAN Mode Workflow
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[Start] --> ReadFiles[Read Memory Bank]
|
||||
ReadFiles --> CheckFiles{Files Complete?}
|
||||
|
||||
CheckFiles -->|No| Plan[Create Plan]
|
||||
Plan --> Document[Document in Chat]
|
||||
|
||||
CheckFiles -->|Yes| Verify[Verify Context]
|
||||
Verify --> Strategy[Develop Strategy]
|
||||
Strategy --> Present[Present Approach]
|
||||
```
|
||||
|
||||
### EXECUTE Mode Workflow
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[Start] --> Context[Check Memory Bank]
|
||||
Context --> Update[Update Documentation]
|
||||
Update --> Rules[Update Project Intelligence]
|
||||
Rules --> Execute[Execute Task]
|
||||
Execute --> Document[Document Changes]
|
||||
```
|
||||
|
||||
## MODE TRANSITION SIGNALS
|
||||
|
||||
Mode transitions occur only when user explicitly signals with:
|
||||
- "ENTER RESEARCH MODE" or "/research" to enter RESEARCH mode
|
||||
- "ENTER INNOVATE MODE" or "/innovate" to enter INNOVATE mode
|
||||
- "ENTER PLAN MODE" or "/plan" to enter PLAN mode
|
||||
- "ENTER EXECUTE MODE" or "/execute" to enter EXECUTE mode
|
||||
- "ENTER REVIEW MODE" or "/review" to enter REVIEW mode
|
||||
|
||||
## MEMORY UPDATES
|
||||
|
||||
After significant progress in any mode:
|
||||
1. Update activeContext.md with current focus and recent changes
|
||||
2. Update progress.md with completed tasks and current status
|
||||
3. Document any important decisions in systemPatterns.md
|
||||
4. Record any observed patterns in systemPatterns.md
|
||||
|
||||
## MODE-SPECIFIC MEMORY BANK UPDATES
|
||||
|
||||
### RESEARCH Mode Updates
|
||||
- Update techContext.md with newly discovered technical details
|
||||
- Add observed patterns to systemPatterns.md
|
||||
- Document current status in activeContext.md
|
||||
|
||||
### INNOVATE Mode Updates
|
||||
- Document design alternatives considered
|
||||
- Record decision rationales with relevance scores
|
||||
- Update activeContext.md with potential approaches
|
||||
|
||||
### PLAN Mode Updates
|
||||
- Create implementation plans in chat
|
||||
- Update activeContext.md with planned changes
|
||||
- Document expected outcomes in progress.md
|
||||
|
||||
### EXECUTE Mode Updates
|
||||
- Track implementation progress in progress.md
|
||||
- Update activeContext.md after each significant step
|
||||
- Document any implementation challenges encountered
|
||||
|
||||
### REVIEW Mode Updates
|
||||
- Document review findings in progress.md
|
||||
- Update activeContext.md with review status
|
||||
- Record any patterns or issues for future reference
|
||||
|
||||
## CONTEXT AWARENESS
|
||||
|
||||
The AI should maintain awareness of:
|
||||
1. Current project state from state.mdc
|
||||
2. Project requirements from projectbrief.md
|
||||
3. Technical context from techContext.md
|
||||
4. System architecture from systemPatterns.md
|
||||
5. Active work from activeContext.md
|
||||
6. Progress status from progress.md
|
||||
|
||||
This context should inform all responses, ensuring continuity and relevance.
|
||||
|
||||
---
|
||||
|
||||
*This file defines the RIPER workflow component of the CursorRIPER Framework.*
|
||||
367
.cursor/rules/start-phase.mdc
Normal file
367
.cursor/rules/start-phase.mdc
Normal file
@ -0,0 +1,367 @@
|
||||
---
|
||||
description: "CursorRIPER Framework - START Phase"
|
||||
globs:
|
||||
alwaysApply: false
|
||||
version: "1.0.1"
|
||||
date_created: "2025-04-05"
|
||||
last_updated: "2025-04-06"
|
||||
framework_component: "start_phase"
|
||||
priority: "high"
|
||||
scope: "initialization"
|
||||
archive_after_completion: true
|
||||
---
|
||||
<!-- Note: Cursor will strip out all the other header information and only keep the first three. -->
|
||||
# CursorRIPER Framework - START Phase
|
||||
# Version 1.0.1
|
||||
|
||||
## AI PROCESSING INSTRUCTIONS
|
||||
This file defines the START phase component of the CursorRIPER Framework. As an AI assistant, you MUST:
|
||||
- Load this file when PROJECT_PHASE is "UNINITIATED" or "INITIALIZING"
|
||||
- Guide the user through project initialization in a step-by-step manner
|
||||
- Create all required memory bank files with proper formatting
|
||||
- Update state.mdc as each step is completed
|
||||
- Archive this component once initialization is complete
|
||||
|
||||
## START PHASE OVERVIEW
|
||||
|
||||
The START phase is a one-time preprocessing phase that runs at the beginning of a new project or major component. It focuses on project initialization, scaffolding, and setting up the Memory Bank with baseline information.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[BEGIN START PHASE] --> Req[Requirements Gathering]
|
||||
Req --> Tech[Technology Selection]
|
||||
Tech --> Arch[Architecture Definition]
|
||||
Arch --> Scaffold[Project Scaffolding]
|
||||
Scaffold --> Setup[Environment Setup]
|
||||
Setup --> Memory[Memory Bank Initialization]
|
||||
Memory --> End[TRANSITION TO RIPER]
|
||||
```
|
||||
|
||||
## START PHASE PROCESS
|
||||
|
||||
[PHASE: START]
|
||||
- **Purpose**: Project initialization and scaffolding
|
||||
- **Permitted**: Requirements gathering, technology selection, architecture definition, project structure setup
|
||||
- **Entry Point**: User command "BEGIN START PHASE" or "/start"
|
||||
- **Exit Point**: Automatic transition to RESEARCH mode after setup is complete
|
||||
|
||||
## STEP-BY-STEP INITIALIZATION
|
||||
|
||||
### Step 1: Requirements Gathering
|
||||
- Collect and document core project requirements
|
||||
- Define project scope, goals, and constraints
|
||||
- Identify key stakeholders and their needs
|
||||
- Document success criteria
|
||||
- **Key Questions**:
|
||||
- What problem is this project trying to solve?
|
||||
- Who are the primary users or stakeholders?
|
||||
- What are the must-have features?
|
||||
- What are the nice-to-have features?
|
||||
- What are the technical constraints?
|
||||
- What is the timeline for completion?
|
||||
- **Output**: Create projectbrief.md with gathered requirements
|
||||
|
||||
### Step 2: Technology Selection
|
||||
- Assess technology options based on requirements
|
||||
- Evaluate frameworks, libraries, and tools
|
||||
- Make recommendations with clear rationales
|
||||
- Document technology decisions
|
||||
- **Key Questions**:
|
||||
- What programming language(s) best fit this project?
|
||||
- What frameworks or libraries would be most appropriate?
|
||||
- What database technology should be used?
|
||||
- What deployment environment is targeted?
|
||||
- Are there any specific performance requirements?
|
||||
- What testing frameworks should be used?
|
||||
- **Output**: Add technology decisions to techContext.md
|
||||
|
||||
### Step 3: Architecture Definition
|
||||
- Define high-level system architecture
|
||||
- Identify key components and their relationships
|
||||
- Create initial architectural diagrams
|
||||
- Document architectural decisions
|
||||
- **Key Questions**:
|
||||
- What architectural pattern is most appropriate?
|
||||
- How will the application be structured?
|
||||
- What are the key components and their responsibilities?
|
||||
- How will data flow through the system?
|
||||
- How will the system scale?
|
||||
- What security considerations need to be addressed?
|
||||
- **Output**: Create systemPatterns.md with architecture definition
|
||||
|
||||
### Step 4: Project Scaffolding
|
||||
- Set up initial folder structure
|
||||
- Create configuration files
|
||||
- Initialize version control
|
||||
- Set up package management
|
||||
- Create initial README and documentation
|
||||
- **Key Actions**:
|
||||
- Create the basic folder structure
|
||||
- Initialize git repository
|
||||
- Set up package manager (npm, pip, etc.)
|
||||
- Create initial configuration files
|
||||
- Set up basic build process
|
||||
- **Output**: Create project scaffold according to defined structure
|
||||
|
||||
### Step 5: Environment Setup
|
||||
- Configure development environment
|
||||
- Set up testing framework
|
||||
- Establish CI/CD pipeline configuration
|
||||
- Define deployment strategy
|
||||
- **Key Actions**:
|
||||
- Set up local development environment
|
||||
- Configure testing framework
|
||||
- Create initial test cases
|
||||
- Define CI/CD pipeline
|
||||
- Document deployment process
|
||||
- **Output**: Update techContext.md with environment setup details
|
||||
|
||||
### Step 6: Memory Bank Initialization
|
||||
- Create and populate all core memory files:
|
||||
- projectbrief.md (if not already created)
|
||||
- systemPatterns.md (if not already created)
|
||||
- techContext.md (if not already created)
|
||||
- activeContext.md
|
||||
- progress.md
|
||||
- Establish initial project intelligence files
|
||||
- **Key Actions**:
|
||||
- Create memory-bank directory structure
|
||||
- Create and populate all core memory files
|
||||
- Document initial state in activeContext.md
|
||||
- Set up progress.md with initial tasks
|
||||
- **Output**: Complete memory bank with all required files
|
||||
|
||||
## MEMORY BANK TEMPLATES
|
||||
|
||||
### projectbrief.md Template
|
||||
```markdown
|
||||
# Project Brief: [PROJECT_NAME]
|
||||
*Version: 1.0*
|
||||
*Created: [CURRENT_DATE]*
|
||||
*Last Updated: [CURRENT_DATE]*
|
||||
|
||||
## Project Overview
|
||||
[Brief description of the project, its purpose, and main goals]
|
||||
|
||||
## Core Requirements
|
||||
- [REQUIREMENT_1]
|
||||
- [REQUIREMENT_2]
|
||||
- [REQUIREMENT_3]
|
||||
|
||||
## Success Criteria
|
||||
- [CRITERION_1]
|
||||
- [CRITERION_2]
|
||||
- [CRITERION_3]
|
||||
|
||||
## Scope
|
||||
### In Scope
|
||||
- [IN_SCOPE_ITEM_1]
|
||||
- [IN_SCOPE_ITEM_2]
|
||||
|
||||
### Out of Scope
|
||||
- [OUT_OF_SCOPE_ITEM_1]
|
||||
- [OUT_OF_SCOPE_ITEM_2]
|
||||
|
||||
## Timeline
|
||||
- [MILESTONE_1]: [DATE]
|
||||
- [MILESTONE_2]: [DATE]
|
||||
- [MILESTONE_3]: [DATE]
|
||||
|
||||
## Stakeholders
|
||||
- [STAKEHOLDER_1]: [ROLE]
|
||||
- [STAKEHOLDER_2]: [ROLE]
|
||||
|
||||
---
|
||||
|
||||
*This document serves as the foundation for the project and informs all other memory files.*
|
||||
```
|
||||
|
||||
### systemPatterns.md Template
|
||||
```markdown
|
||||
# System Patterns: [PROJECT_NAME]
|
||||
*Version: 1.0*
|
||||
*Created: [CURRENT_DATE]*
|
||||
*Last Updated: [CURRENT_DATE]*
|
||||
|
||||
## Architecture Overview
|
||||
[High-level description of the system architecture]
|
||||
|
||||
## Key Components
|
||||
- [COMPONENT_1]: [PURPOSE]
|
||||
- [COMPONENT_2]: [PURPOSE]
|
||||
- [COMPONENT_3]: [PURPOSE]
|
||||
|
||||
## Design Patterns in Use
|
||||
- [PATTERN_1]: [USAGE_CONTEXT]
|
||||
- [PATTERN_2]: [USAGE_CONTEXT]
|
||||
- [PATTERN_3]: [USAGE_CONTEXT]
|
||||
|
||||
## Data Flow
|
||||
[Description or diagram of how data flows through the system]
|
||||
|
||||
## Key Technical Decisions
|
||||
- [DECISION_1]: [RATIONALE]
|
||||
- [DECISION_2]: [RATIONALE]
|
||||
- [DECISION_3]: [RATIONALE]
|
||||
|
||||
## Component Relationships
|
||||
[Description of how components interact with each other]
|
||||
|
||||
---
|
||||
|
||||
*This document captures the system architecture and design patterns used in the project.*
|
||||
```
|
||||
|
||||
### techContext.md Template
|
||||
```markdown
|
||||
# Technical Context: [PROJECT_NAME]
|
||||
*Version: 1.0*
|
||||
*Created: [CURRENT_DATE]*
|
||||
*Last Updated: [CURRENT_DATE]*
|
||||
|
||||
## Technology Stack
|
||||
- Frontend: [FRONTEND_TECHNOLOGIES]
|
||||
- Backend: [BACKEND_TECHNOLOGIES]
|
||||
- Database: [DATABASE_TECHNOLOGIES]
|
||||
- Infrastructure: [INFRASTRUCTURE_TECHNOLOGIES]
|
||||
|
||||
## Development Environment Setup
|
||||
[Instructions for setting up the development environment]
|
||||
|
||||
## Dependencies
|
||||
- [DEPENDENCY_1]: [VERSION] - [PURPOSE]
|
||||
- [DEPENDENCY_2]: [VERSION] - [PURPOSE]
|
||||
- [DEPENDENCY_3]: [VERSION] - [PURPOSE]
|
||||
|
||||
## Technical Constraints
|
||||
- [CONSTRAINT_1]
|
||||
- [CONSTRAINT_2]
|
||||
- [CONSTRAINT_3]
|
||||
|
||||
## Build and Deployment
|
||||
- Build Process: [BUILD_PROCESS]
|
||||
- Deployment Procedure: [DEPLOYMENT_PROCEDURE]
|
||||
- CI/CD: [CI_CD_SETUP]
|
||||
|
||||
## Testing Approach
|
||||
- Unit Testing: [UNIT_TESTING_APPROACH]
|
||||
- Integration Testing: [INTEGRATION_TESTING_APPROACH]
|
||||
- E2E Testing: [E2E_TESTING_APPROACH]
|
||||
|
||||
---
|
||||
|
||||
*This document describes the technologies used in the project and how they're configured.*
|
||||
```
|
||||
|
||||
### activeContext.md Template
|
||||
```markdown
|
||||
# Active Context: [PROJECT_NAME]
|
||||
*Version: 1.0*
|
||||
*Created: [CURRENT_DATE]*
|
||||
*Last Updated: [CURRENT_DATE]*
|
||||
*Current RIPER Mode: [MODE_NAME]*
|
||||
|
||||
## Current Focus
|
||||
[Description of what we're currently working on]
|
||||
|
||||
## Recent Changes
|
||||
- [CHANGE_1]: [DATE] - [DESCRIPTION]
|
||||
- [CHANGE_2]: [DATE] - [DESCRIPTION]
|
||||
- [CHANGE_3]: [DATE] - [DESCRIPTION]
|
||||
|
||||
## Active Decisions
|
||||
- [DECISION_1]: [STATUS] - [DESCRIPTION]
|
||||
- [DECISION_2]: [STATUS] - [DESCRIPTION]
|
||||
- [DECISION_3]: [STATUS] - [DESCRIPTION]
|
||||
|
||||
## Next Steps
|
||||
1. [NEXT_STEP_1]
|
||||
2. [NEXT_STEP_2]
|
||||
3. [NEXT_STEP_3]
|
||||
|
||||
## Current Challenges
|
||||
- [CHALLENGE_1]: [DESCRIPTION]
|
||||
- [CHALLENGE_2]: [DESCRIPTION]
|
||||
- [CHALLENGE_3]: [DESCRIPTION]
|
||||
|
||||
## Implementation Progress
|
||||
- [✓] [COMPLETED_TASK_1]
|
||||
- [✓] [COMPLETED_TASK_2]
|
||||
- [ ] [PENDING_TASK_1]
|
||||
- [ ] [PENDING_TASK_2]
|
||||
|
||||
---
|
||||
|
||||
*This document captures the current state of work and immediate next steps.*
|
||||
```
|
||||
|
||||
### progress.md Template
|
||||
```markdown
|
||||
# Progress Tracker: [PROJECT_NAME]
|
||||
*Version: 1.0*
|
||||
*Created: [CURRENT_DATE]*
|
||||
*Last Updated: [CURRENT_DATE]*
|
||||
|
||||
## Project Status
|
||||
Overall Completion: [PERCENTAGE]%
|
||||
|
||||
## What Works
|
||||
- [FEATURE_1]: [COMPLETION_STATUS] - [NOTES]
|
||||
- [FEATURE_2]: [COMPLETION_STATUS] - [NOTES]
|
||||
- [FEATURE_3]: [COMPLETION_STATUS] - [NOTES]
|
||||
|
||||
## What's In Progress
|
||||
- [FEATURE_4]: [PROGRESS_PERCENTAGE]% - [NOTES]
|
||||
- [FEATURE_5]: [PROGRESS_PERCENTAGE]% - [NOTES]
|
||||
- [FEATURE_6]: [PROGRESS_PERCENTAGE]% - [NOTES]
|
||||
|
||||
## What's Left To Build
|
||||
- [FEATURE_7]: [PRIORITY] - [NOTES]
|
||||
- [FEATURE_8]: [PRIORITY] - [NOTES]
|
||||
- [FEATURE_9]: [PRIORITY] - [NOTES]
|
||||
|
||||
## Known Issues
|
||||
- [ISSUE_1]: [SEVERITY] - [DESCRIPTION] - [STATUS]
|
||||
- [ISSUE_2]: [SEVERITY] - [DESCRIPTION] - [STATUS]
|
||||
- [ISSUE_3]: [SEVERITY] - [DESCRIPTION] - [STATUS]
|
||||
|
||||
## Milestones
|
||||
- [MILESTONE_1]: [DUE_DATE] - [STATUS]
|
||||
- [MILESTONE_2]: [DUE_DATE] - [STATUS]
|
||||
- [MILESTONE_3]: [DUE_DATE] - [STATUS]
|
||||
|
||||
---
|
||||
|
||||
*This document tracks what works, what's in progress, and what's left to build.*
|
||||
```
|
||||
|
||||
## TRANSITION TO RIPER WORKFLOW
|
||||
|
||||
Once all six steps are completed:
|
||||
1. Verify all memory files are properly created and populated
|
||||
2. Update state.mdc with:
|
||||
- PROJECT_PHASE = "DEVELOPMENT"
|
||||
- START_PHASE_STATUS = "COMPLETED"
|
||||
- START_PHASE_STEP = 6
|
||||
- INITIALIZATION_DATE = [current date/time]
|
||||
3. Archive this component to .cursor/rules/archive/start-phase.mdc.archive
|
||||
4. Automatically transition to RESEARCH mode
|
||||
5. Inform the user: "Project initialization complete. Entering RESEARCH mode to begin development."
|
||||
|
||||
## DELIVERABLES CHECKLIST
|
||||
|
||||
At the end of the START phase, ensure the following are complete:
|
||||
|
||||
- [ ] Project requirements documented in projectbrief.md
|
||||
- [ ] Technology stack selected and documented in techContext.md
|
||||
- [ ] System architecture defined in systemPatterns.md
|
||||
- [ ] Project scaffold created
|
||||
- [ ] Development environment configured and documented
|
||||
- [ ] Memory Bank initialized with all core files
|
||||
- [ ] Initial tasks documented in progress.md
|
||||
|
||||
Once all items are checked, the system will automatically transition to the RIPER workflow.
|
||||
|
||||
---
|
||||
|
||||
*This file guides project initialization through the START phase. It will be automatically archived once initialization is complete.*
|
||||
180
.cursor/rules/state.mdc
Normal file
180
.cursor/rules/state.mdc
Normal file
@ -0,0 +1,180 @@
|
||||
---
|
||||
description: "CursorRIPER Framework - State Management"
|
||||
globs:
|
||||
alwaysApply: true
|
||||
version: "1.0.2"
|
||||
date_created: "2025-04-05"
|
||||
last_updated: "2025-04-05"
|
||||
framework_component: "state"
|
||||
priority: "critical"
|
||||
scope: "always_load"
|
||||
---
|
||||
<!-- Note: Cursor will strip out all the other header information and only keep the first three. -->
|
||||
# CursorRIPER Framework - State Management
|
||||
# Version 1.0.2
|
||||
|
||||
## AI PROCESSING INSTRUCTIONS
|
||||
This file defines the current state of the project within the CursorRIPER Framework. As an AI assistant, you MUST:
|
||||
- Always load this file after core.mdc but before other components
|
||||
- Never modify state values without proper authorization via commands
|
||||
- Validate state transitions against allowed paths
|
||||
- Update this file when state changes occur
|
||||
- Keep all state values consistent with each other
|
||||
|
||||
## CURRENT PROJECT STATE
|
||||
|
||||
PROJECT_PHASE: "UNINITIATED"
|
||||
# Possible values: "UNINITIATED", "INITIALIZING", "DEVELOPMENT", "MAINTENANCE"
|
||||
|
||||
RIPER_CURRENT_MODE: "NONE"
|
||||
# Possible values: "NONE", "RESEARCH", "INNOVATE", "PLAN", "EXECUTE", "REVIEW"
|
||||
|
||||
START_PHASE_STATUS: "NOT_STARTED"
|
||||
# Possible values: "NOT_STARTED", "IN_PROGRESS", "COMPLETED", "ARCHIVED"
|
||||
|
||||
START_PHASE_STEP: 0
|
||||
# Possible values: 0-6 (0=Not started, 1=Requirements, 2=Technology, 3=Architecture, 4=Scaffolding, 5=Environment, 6=Memory Bank)
|
||||
|
||||
LAST_UPDATE: "2025-04-05T00:00:00Z"
|
||||
# ISO 8601 formatted timestamp of last state update
|
||||
|
||||
INITIALIZATION_DATE: ""
|
||||
# When START phase was completed, empty if not completed
|
||||
|
||||
FRAMEWORK_VERSION: "1.0.0"
|
||||
# Current version of the framework
|
||||
|
||||
## STATE TRANSITION RULES
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> UNINITIATED
|
||||
|
||||
UNINITIATED --> INITIALIZING: /start
|
||||
INITIALIZING --> DEVELOPMENT: START phase complete
|
||||
DEVELOPMENT --> MAINTENANCE: User request
|
||||
MAINTENANCE --> DEVELOPMENT: User request
|
||||
|
||||
state INITIALIZING {
|
||||
[*] --> NOT_STARTED
|
||||
NOT_STARTED --> IN_PROGRESS: Begin START
|
||||
IN_PROGRESS --> COMPLETED: All steps finished
|
||||
COMPLETED --> ARCHIVED: Enter DEVELOPMENT
|
||||
}
|
||||
|
||||
state "DEVELOPMENT/MAINTENANCE" as DM {
|
||||
[*] --> RESEARCH
|
||||
RESEARCH --> INNOVATE: /innovate
|
||||
INNOVATE --> PLAN: /plan
|
||||
PLAN --> EXECUTE: /execute
|
||||
EXECUTE --> REVIEW: /review
|
||||
REVIEW --> RESEARCH: /research
|
||||
}
|
||||
```
|
||||
|
||||
### Phase Transitions
|
||||
- UNINITIATED → INITIALIZING
|
||||
- Trigger: "/start" or "BEGIN START PHASE"
|
||||
- Requirements: None
|
||||
|
||||
- INITIALIZING → DEVELOPMENT
|
||||
- Trigger: Automatic upon START phase completion
|
||||
- Requirements: START_PHASE_STATUS = "COMPLETED"
|
||||
|
||||
- DEVELOPMENT → MAINTENANCE
|
||||
- Trigger: Manual transition by user
|
||||
- Requirements: Explicit user request
|
||||
|
||||
- MAINTENANCE → DEVELOPMENT
|
||||
- Trigger: Manual transition by user
|
||||
- Requirements: Explicit user request
|
||||
|
||||
### Mode Transitions
|
||||
- Any mode → RESEARCH
|
||||
- Trigger: "/research" or "ENTER RESEARCH MODE"
|
||||
- Requirements: PROJECT_PHASE in ["DEVELOPMENT", "MAINTENANCE"]
|
||||
|
||||
- Any mode → INNOVATE
|
||||
- Trigger: "/innovate" or "ENTER INNOVATE MODE"
|
||||
- Requirements: PROJECT_PHASE in ["DEVELOPMENT", "MAINTENANCE"]
|
||||
|
||||
- Any mode → PLAN
|
||||
- Trigger: "/plan" or "ENTER PLAN MODE"
|
||||
- Requirements: PROJECT_PHASE in ["DEVELOPMENT", "MAINTENANCE"]
|
||||
|
||||
- Any mode → EXECUTE
|
||||
- Trigger: "/execute" or "ENTER EXECUTE MODE"
|
||||
- Requirements: PROJECT_PHASE in ["DEVELOPMENT", "MAINTENANCE"]
|
||||
|
||||
- Any mode → REVIEW
|
||||
- Trigger: "/review" or "ENTER REVIEW MODE"
|
||||
- Requirements: PROJECT_PHASE in ["DEVELOPMENT", "MAINTENANCE"]
|
||||
|
||||
### START Phase Status Transitions
|
||||
- NOT_STARTED → IN_PROGRESS
|
||||
- Trigger: "/start" or "BEGIN START PHASE"
|
||||
- Requirements: PROJECT_PHASE = "UNINITIATED"
|
||||
|
||||
- IN_PROGRESS → COMPLETED
|
||||
- Trigger: Completion of all START phase steps
|
||||
- Requirements: START_PHASE_STEP = 6
|
||||
|
||||
- COMPLETED → ARCHIVED
|
||||
- Trigger: Automatic after transition to DEVELOPMENT
|
||||
- Requirements: PROJECT_PHASE = "DEVELOPMENT"
|
||||
|
||||
## STATE UPDATE PROCEDURES
|
||||
|
||||
### Update Project Phase
|
||||
1. Validate transition is allowed
|
||||
2. Create backup of current state
|
||||
3. Update PROJECT_PHASE value
|
||||
4. Update LAST_UPDATE timestamp
|
||||
5. Perform any phase-specific initialization
|
||||
|
||||
### Update RIPER Mode
|
||||
1. Validate transition is allowed
|
||||
2. Update RIPER_CURRENT_MODE value
|
||||
3. Update LAST_UPDATE timestamp
|
||||
4. Update activeContext.md to reflect mode change
|
||||
|
||||
### Update START Phase Status
|
||||
1. Validate transition is allowed
|
||||
2. Update START_PHASE_STATUS value
|
||||
3. Update LAST_UPDATE timestamp
|
||||
4. If transitioning to COMPLETED, set INITIALIZATION_DATE
|
||||
|
||||
### Update START Phase Step
|
||||
1. Validate step increment is logical
|
||||
2. Update START_PHASE_STEP value
|
||||
3. Update LAST_UPDATE timestamp
|
||||
4. If reaching step 6, trigger completion process
|
||||
|
||||
## AUTOMATIC STATE DETECTION
|
||||
|
||||
When determining current project state:
|
||||
1. Check for existence of memory bank files
|
||||
2. If complete memory bank exists but STATE_PHASE is "UNINITIATED":
|
||||
- Set PROJECT_PHASE to "DEVELOPMENT"
|
||||
- Set START_PHASE_STATUS to "COMPLETED"
|
||||
- Set START_PHASE_STEP to 6
|
||||
- Set INITIALIZATION_DATE based on file timestamps
|
||||
3. If partial memory bank exists:
|
||||
- Set PROJECT_PHASE to "INITIALIZING"
|
||||
- Set START_PHASE_STATUS to "IN_PROGRESS"
|
||||
- Determine START_PHASE_STEP based on existing files
|
||||
|
||||
## RE-INITIALIZATION PROTECTION
|
||||
|
||||
If "/start" or "BEGIN START PHASE" is detected when PROJECT_PHASE is not "UNINITIATED":
|
||||
1. Warn user about re-initialization risks
|
||||
2. Require explicit confirmation: "CONFIRM RE-INITIALIZATION"
|
||||
3. If confirmed:
|
||||
- Create backup of current memory bank
|
||||
- Reset state to PROJECT_PHASE = "INITIALIZING"
|
||||
- Reset START_PHASE_STATUS to "IN_PROGRESS"
|
||||
- Reset START_PHASE_STEP to 1
|
||||
|
||||
---
|
||||
|
||||
*This file automatically tracks the current state of the project. It should never be edited manually.*
|
||||
57
.gitignore
vendored
Normal file
57
.gitignore
vendored
Normal file
@ -0,0 +1,57 @@
|
||||
# Node.js 相關
|
||||
node_modules/
|
||||
npm-debug.log
|
||||
yarn-debug.log
|
||||
yarn-error.log
|
||||
.npm
|
||||
.yarn-integrity
|
||||
|
||||
# TypeScript 編譯輸出
|
||||
dist/
|
||||
build/
|
||||
*.tsbuildinfo
|
||||
|
||||
# 環境變數和敏感資訊
|
||||
.env
|
||||
.env.local
|
||||
.env.development.local
|
||||
.env.test.local
|
||||
.env.production.local
|
||||
|
||||
# IDE 和編輯器
|
||||
.idea/
|
||||
.vscode/*
|
||||
!.vscode/extensions.json
|
||||
!.vscode/settings.json
|
||||
!.vscode/tasks.json
|
||||
!.vscode/launch.json
|
||||
*.code-workspace
|
||||
.DS_Store
|
||||
|
||||
# 日誌檔案
|
||||
logs/
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
|
||||
# 暫存檔案
|
||||
.tmp/
|
||||
.temp/
|
||||
tmp/
|
||||
temp/
|
||||
|
||||
# 系統檔案
|
||||
.DS_Store
|
||||
Thumbs.db
|
||||
|
||||
# 覆蓋率報告
|
||||
coverage/
|
||||
|
||||
# 資料檔案
|
||||
*.sqlite
|
||||
data/*.json
|
||||
!data/example.json
|
||||
|
||||
# Cursor AI 生成的暫存檔案
|
||||
.cursor/tmp/
|
||||
143
README.md
Normal file
143
README.md
Normal file
@ -0,0 +1,143 @@
|
||||
# MCP 蝦米任務管理器
|
||||
|
||||
基於 Model Context Protocol (MCP)的任務管理系統，幫助 Agent 有效管理和執行任務。
|
||||
|
||||
## 功能特點
|
||||
|
||||
1. **任務規劃與分析**：幫助 Agent 理解和分析複雜任務
|
||||
2. **任務拆分**：將大型任務拆分為可管理的小任務
|
||||
3. **依賴管理**：處理任務間的依賴關係，確保正確的執行順序
|
||||
4. **執行追蹤**：監控任務執行進度和狀態
|
||||
5. **任務驗證**：確保任務符合預期要求
|
||||
|
||||
## 任務管理工作流程
|
||||
|
||||
本系統提供了完整的任務工作流程：
|
||||
|
||||
1. **開始規劃 (plan_task)**：分析任務問題，確定任務範圍
|
||||
2. **分析問題 (analyze_task)**：深入分析，檢查現有代碼庫避免重複
|
||||
3. **反思構想 (reflect_task)**：批判性審查分析結果，確保方案完善
|
||||
4. **拆分任務 (split_tasks)**：將大任務拆分為小任務，建立依賴關係
|
||||
5. **列出任務 (list_tasks)**：查看所有任務及其狀態
|
||||
6. **執行任務 (execute_task)**：執行特定任務
|
||||
7. **檢驗任務 (verify_task)**：檢查任務完成情況
|
||||
8. **完成任務 (complete_task)**：標記任務完成並提供報告
|
||||
|
||||
## 任務依賴關係
|
||||
|
||||
系統支持兩種方式指定任務依賴：
|
||||
|
||||
1. **通過任務名稱**（推薦）：使用任務名稱直接引用依賴任務，更直觀易讀
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "實現前端表單",
|
||||
"dependencies": ["設計UI界面", "定義API規格"]
|
||||
}
|
||||
```
|
||||
|
||||
2. **通過任務 ID**：使用任務的唯一標識符，適用於需要精確引用的場景
|
||||
```json
|
||||
{
|
||||
"name": "部署應用",
|
||||
"dependencies": ["a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6"]
|
||||
}
|
||||
```
|
||||
|
||||
這種靈活的依賴指定方式讓您可以在同一批次創建的任務間建立依賴關係，無需預先知道任務 ID。
|
||||
|
||||
## 安裝與使用
|
||||
|
||||
```bash
|
||||
# 安裝依賴
|
||||
npm install
|
||||
|
||||
# 啟動服務
|
||||
npm start
|
||||
```
|
||||
|
||||
## 在支援 MCP 的客戶端中使用
|
||||
|
||||
蝦米任務管理器可以與任何支援 Model Context Protocol 的客戶端一起使用，例如 Cursor IDE。
|
||||
|
||||
### 在 Cursor IDE 中配置
|
||||
|
||||
1. 打開 Cursor IDE 的設定檔案（通常位於 `~/.cursor/settings.json`）
|
||||
2. 在 `mcpServers` 部分添加蝦米任務管理器的配置
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": [
|
||||
{
|
||||
"name": "蝦米任務管理器",
|
||||
"id": "mcp-shrimp-task-manager",
|
||||
"command": "node",
|
||||
"args": ["path/to/mcp-shrimp-task-manager/dist/index.js"],
|
||||
"description": "任務規劃、拆分、執行和管理工具",
|
||||
"env": {
|
||||
"NODE_ENV": "production"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
請將 `path/to/mcp-shrimp-task-manager` 替換為實際的路徑。
|
||||
|
||||
### 可用的工具
|
||||
|
||||
在 Cursor IDE 中，配置完成後，您可以使用以下工具：
|
||||
|
||||
- **開始規劃**：`plan_task`
|
||||
- **分析問題**：`analyze_task`
|
||||
- **反思構想**：`reflect_task`
|
||||
- **拆分任務**：`split_tasks`
|
||||
- **列出任務**：`list_tasks`
|
||||
- **執行任務**：`execute_task`
|
||||
- **檢驗任務**：`verify_task`
|
||||
- **完成任務**：`complete_task`
|
||||
|
||||
### 使用範例
|
||||
|
||||
在 Cursor IDE 中，您可以這樣使用蝦米任務管理器：
|
||||
|
||||
```javascript
|
||||
// 開始規劃一個任務
|
||||
const planResult = await mcp.mcp_shrimp_task_manager.plan_task({
|
||||
description: "開發一個用戶註冊系統",
|
||||
requirements: "需要支持電子郵件和社交媒體登入",
|
||||
});
|
||||
|
||||
// 拆分任務
|
||||
const splitResult = await mcp.mcp_shrimp_task_manager.split_tasks({
|
||||
isOverwrite: false,
|
||||
tasks: [
|
||||
{
|
||||
name: "設計用戶界面",
|
||||
description: "創建用戶友好的註冊表單界面",
|
||||
notes: "需要遵循品牌設計指南",
|
||||
},
|
||||
{
|
||||
name: "實現後端API",
|
||||
description: "開發用戶註冊和驗證API",
|
||||
dependencies: ["設計用戶界面"], // 使用任務名稱引用依賴
|
||||
},
|
||||
],
|
||||
});
|
||||
|
||||
// 執行任務
|
||||
const executeResult = await mcp.mcp_shrimp_task_manager.execute_task({
|
||||
taskId: "task-uuid-here", // 可從list_tasks獲取
|
||||
});
|
||||
```
|
||||
|
||||
## 技術實現
|
||||
|
||||
- **Node.js**：JavaScript 運行時環境
|
||||
- **TypeScript**：提供類型安全
|
||||
- **MCP SDK**：用於與大型語言模型互動
|
||||
- **UUID**：生成唯一任務標識符
|
||||
|
||||
## 許可協議
|
||||
|
||||
MIT
|
||||
1910
package-lock.json
generated
Normal file
1910
package-lock.json
generated
Normal file
File diff suppressed because it is too large
Load Diff
32
package.json
Normal file
32
package.json
Normal file
@ -0,0 +1,32 @@
|
||||
{
|
||||
"name": "mcp-shrimp-task-manager",
|
||||
"version": "1.0.0",
|
||||
"description": "基於MCP的任務管理系統，提供任務規劃、拆分和管理功能",
|
||||
"main": "dist/index.js",
|
||||
"type": "module",
|
||||
"scripts": {
|
||||
"build": "tsc",
|
||||
"dev": "ts-node --esm src/index.ts",
|
||||
"start": "node dist/index.js",
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": [
|
||||
"mcp",
|
||||
"task-manager",
|
||||
"agent",
|
||||
"workflow"
|
||||
],
|
||||
"author": "",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"@modelcontextprotocol/sdk": "^1.0.0",
|
||||
"uuid": "^9.0.1",
|
||||
"zod": "^3.22.4"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@types/node": "^20.8.2",
|
||||
"@types/uuid": "^9.0.6",
|
||||
"ts-node": "^10.9.1",
|
||||
"typescript": "^5.2.2"
|
||||
}
|
||||
}
|
||||
249
src/index.ts
Normal file
249
src/index.ts
Normal file
@ -0,0 +1,249 @@
|
||||
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
|
||||
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
|
||||
import { z } from "zod";
|
||||
|
||||
// 導入工具函數
|
||||
import {
|
||||
planTask,
|
||||
planTaskSchema,
|
||||
analyzeTask,
|
||||
analyzeTaskSchema,
|
||||
reflectTask,
|
||||
reflectTaskSchema,
|
||||
splitTasks,
|
||||
splitTasksSchema,
|
||||
listTasks,
|
||||
executeTask,
|
||||
executeTaskSchema,
|
||||
verifyTask,
|
||||
verifyTaskSchema,
|
||||
completeTask,
|
||||
completeTaskSchema,
|
||||
} from "./tools/taskTools.js";
|
||||
|
||||
// 導入提示模板
|
||||
import {
|
||||
planTaskPrompt,
|
||||
planTaskPromptSchema,
|
||||
executeTaskPrompt,
|
||||
executeTaskPromptSchema,
|
||||
verifyTaskPrompt,
|
||||
verifyTaskPromptSchema,
|
||||
} from "./prompts/taskPrompts.js";
|
||||
|
||||
async function main() {
|
||||
try {
|
||||
console.log("啟動蝦米任務管理器服務...");
|
||||
|
||||
// 創建MCP服務器
|
||||
const server = new McpServer({
|
||||
name: "蝦米任務管理器",
|
||||
version: "1.0.0",
|
||||
});
|
||||
|
||||
// 註冊工具 - 使用已定義的schema物件
|
||||
server.tool(
|
||||
"plan_task",
|
||||
"初始化並詳細規劃任務流程，建立明確的目標與成功標準",
|
||||
{
|
||||
description: z
|
||||
.string()
|
||||
.describe("完整詳細的任務問題描述，應包含任務目標、背景及預期成果"),
|
||||
requirements: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe("任務的特定技術要求、業務約束條件或品質標準（選填）"),
|
||||
},
|
||||
async (args) => {
|
||||
return await planTask(args);
|
||||
}
|
||||
);
|
||||
|
||||
server.tool(
|
||||
"analyze_task",
|
||||
"深入分析任務需求並系統性檢查代碼庫，評估技術可行性與潛在風險",
|
||||
{
|
||||
summary: z
|
||||
.string()
|
||||
.describe("結構化的任務摘要，包含任務目標、範圍與關鍵技術挑戰"),
|
||||
initialConcept: z
|
||||
.string()
|
||||
.describe("初步解答構想，包含技術方案、架構設計和實施策略"),
|
||||
previousAnalysis: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe(
|
||||
"前次迭代的分析結果，用於持續改進方案（僅在重新分析時需提供）"
|
||||
),
|
||||
},
|
||||
async (args) => {
|
||||
return await analyzeTask(args);
|
||||
}
|
||||
);
|
||||
|
||||
server.tool(
|
||||
"reflect_task",
|
||||
"批判性審查分析結果，評估方案完整性並識別優化機會，確保解決方案符合最佳實踐",
|
||||
{
|
||||
summary: z
|
||||
.string()
|
||||
.describe("結構化的任務摘要，保持與分析階段一致以確保連續性"),
|
||||
analysis: z
|
||||
.string()
|
||||
.describe(
|
||||
"完整詳盡的技術分析結果，包括所有技術細節、依賴組件和實施方案"
|
||||
),
|
||||
},
|
||||
async (args) => {
|
||||
return await reflectTask(args);
|
||||
}
|
||||
);
|
||||
|
||||
server.tool(
|
||||
"split_tasks",
|
||||
"將複雜任務分解為獨立且可追蹤的子任務，建立明確的依賴關係和優先順序",
|
||||
{
|
||||
isOverwrite: z
|
||||
.boolean()
|
||||
.describe(
|
||||
"任務覆蓋模式選擇（true：清除並覆蓋所有現有任務；false：保留現有任務並新增）"
|
||||
),
|
||||
tasks: z
|
||||
.array(
|
||||
z.object({
|
||||
name: z
|
||||
.string()
|
||||
.describe("簡潔明確的任務名稱，應能清晰表達任務目的"),
|
||||
description: z
|
||||
.string()
|
||||
.describe("詳細的任務描述，包含實施要點、技術細節和驗收標準"),
|
||||
notes: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe("補充說明、特殊處理要求或實施建議（選填）"),
|
||||
dependencies: z
|
||||
.array(z.string())
|
||||
.optional()
|
||||
.describe(
|
||||
"此任務依賴的前置任務ID或任務名稱列表，支持兩種引用方式，名稱引用更直觀"
|
||||
),
|
||||
})
|
||||
)
|
||||
.describe("結構化的任務清單，每個任務應保持原子性且有明確的完成標準"),
|
||||
},
|
||||
async (args) => {
|
||||
return await splitTasks(args);
|
||||
}
|
||||
);
|
||||
|
||||
server.tool(
|
||||
"list_tasks",
|
||||
"生成結構化任務清單，包含完整狀態追蹤、優先級和依賴關係",
|
||||
{},
|
||||
async () => {
|
||||
return await listTasks();
|
||||
}
|
||||
);
|
||||
|
||||
server.tool(
|
||||
"execute_task",
|
||||
"按照預定義計劃執行特定任務，確保每個步驟的輸出符合質量標準",
|
||||
{
|
||||
taskId: z
|
||||
.string()
|
||||
.describe("待執行任務的唯一標識符，必須是系統中存在的有效任務ID"),
|
||||
},
|
||||
async (args) => {
|
||||
return await executeTask(args);
|
||||
}
|
||||
);
|
||||
|
||||
server.tool(
|
||||
"verify_task",
|
||||
"全面驗證任務完成度，確保所有需求與技術標準都已滿足，並無遺漏細節",
|
||||
{
|
||||
taskId: z
|
||||
.string()
|
||||
.describe("待驗證任務的唯一標識符，必須是系統中存在的有效任務ID"),
|
||||
},
|
||||
async (args) => {
|
||||
return await verifyTask(args);
|
||||
}
|
||||
);
|
||||
|
||||
server.tool(
|
||||
"complete_task",
|
||||
"正式標記任務為完成狀態，生成詳細的完成報告，並更新關聯任務的依賴狀態",
|
||||
{
|
||||
taskId: z
|
||||
.string()
|
||||
.describe("待完成任務的唯一標識符，必須是系統中存在的有效任務ID"),
|
||||
},
|
||||
async (args) => {
|
||||
return await completeTask(args);
|
||||
}
|
||||
);
|
||||
|
||||
// 註冊提示
|
||||
server.prompt(
|
||||
"plan_task_prompt",
|
||||
"生成結構化的新任務規劃，包含明確目標、評估標準與執行步驟",
|
||||
{
|
||||
taskType: z
|
||||
.string()
|
||||
.describe("任務類型，例如 'bug修復'、'功能開發'、'性能優化'等"),
|
||||
description: z
|
||||
.string()
|
||||
.describe("完整詳細的任務問題描述，包含任務背景和目標"),
|
||||
codeContext: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe("相關代碼片段或文件路徑（選填）"),
|
||||
},
|
||||
async (args) => {
|
||||
return planTaskPrompt(args);
|
||||
}
|
||||
);
|
||||
|
||||
server.prompt(
|
||||
"execute_task_prompt",
|
||||
"提供執行特定任務的詳細指南，包含所有必要上下文與技術細節",
|
||||
{
|
||||
taskId: z.string().describe("待執行任務的唯一標識符"),
|
||||
additionalContext: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe("執行任務時需要參考的額外信息（選填）"),
|
||||
},
|
||||
async (args) => {
|
||||
return await executeTaskPrompt(args);
|
||||
}
|
||||
);
|
||||
|
||||
server.prompt(
|
||||
"verify_task_prompt",
|
||||
"生成全面的任務驗證標準與檢查清單，確保質量與完整性",
|
||||
{
|
||||
taskId: z.string().describe("待驗證任務的唯一標識符"),
|
||||
verificationFocus: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe("特別需要關注的驗證方向，如'安全性'、'性能'等（選填）"),
|
||||
},
|
||||
async (args) => {
|
||||
return await verifyTaskPrompt(args);
|
||||
}
|
||||
);
|
||||
|
||||
// 建立連接
|
||||
const transport = new StdioServerTransport();
|
||||
await server.connect(transport);
|
||||
|
||||
console.log("蝦米任務管理器服務已啟動");
|
||||
} catch (error) {
|
||||
console.error("啟動服務失敗:", error);
|
||||
process.exit(1);
|
||||
}
|
||||
}
|
||||
|
||||
main().catch(console.error);
|
||||
245
src/models/taskModel.ts
Normal file
245
src/models/taskModel.ts
Normal file
@ -0,0 +1,245 @@
|
||||
import { Task, TaskStatus, TaskDependency } from "../types/index.js";
|
||||
import fs from "fs/promises";
|
||||
import path from "path";
|
||||
import { v4 as uuidv4 } from "uuid";
|
||||
import { fileURLToPath } from "url";
|
||||
|
||||
// 確保獲取專案資料夾路徑
|
||||
const __filename = fileURLToPath(import.meta.url);
|
||||
const __dirname = path.dirname(__filename);
|
||||
const PROJECT_ROOT = path.resolve(__dirname, "../..");
|
||||
|
||||
// 數據文件路徑
|
||||
const DATA_DIR = process.env.DATA_DIR || path.join(PROJECT_ROOT, "data");
|
||||
const TASKS_FILE = path.join(DATA_DIR, "tasks.json");
|
||||
|
||||
// 確保數據目錄存在
|
||||
async function ensureDataDir() {
|
||||
try {
|
||||
await fs.access(DATA_DIR);
|
||||
} catch (error) {
|
||||
await fs.mkdir(DATA_DIR, { recursive: true });
|
||||
}
|
||||
|
||||
try {
|
||||
await fs.access(TASKS_FILE);
|
||||
} catch (error) {
|
||||
await fs.writeFile(TASKS_FILE, JSON.stringify({ tasks: [] }));
|
||||
}
|
||||
}
|
||||
|
||||
// 讀取所有任務
|
||||
async function readTasks(): Promise<Task[]> {
|
||||
await ensureDataDir();
|
||||
const data = await fs.readFile(TASKS_FILE, "utf-8");
|
||||
return JSON.parse(data).tasks;
|
||||
}
|
||||
|
||||
// 寫入所有任務
|
||||
async function writeTasks(tasks: Task[]): Promise<void> {
|
||||
await ensureDataDir();
|
||||
await fs.writeFile(TASKS_FILE, JSON.stringify({ tasks }, null, 2));
|
||||
}
|
||||
|
||||
// 獲取所有任務
|
||||
export async function getAllTasks(): Promise<Task[]> {
|
||||
return await readTasks();
|
||||
}
|
||||
|
||||
// 根據ID獲取任務
|
||||
export async function getTaskById(taskId: string): Promise<Task | null> {
|
||||
const tasks = await readTasks();
|
||||
return tasks.find((task) => task.id === taskId) || null;
|
||||
}
|
||||
|
||||
// 創建新任務
|
||||
export async function createTask(
|
||||
name: string,
|
||||
description: string,
|
||||
notes?: string,
|
||||
dependencies: string[] = []
|
||||
): Promise<Task> {
|
||||
const tasks = await readTasks();
|
||||
|
||||
const dependencyObjects: TaskDependency[] = dependencies.map((taskId) => ({
|
||||
taskId,
|
||||
}));
|
||||
|
||||
const newTask: Task = {
|
||||
id: uuidv4(),
|
||||
name,
|
||||
description,
|
||||
notes,
|
||||
status: TaskStatus.PENDING,
|
||||
dependencies: dependencyObjects,
|
||||
createdAt: new Date(),
|
||||
updatedAt: new Date(),
|
||||
};
|
||||
|
||||
tasks.push(newTask);
|
||||
await writeTasks(tasks);
|
||||
|
||||
return newTask;
|
||||
}
|
||||
|
||||
// 更新任務
|
||||
export async function updateTask(
|
||||
taskId: string,
|
||||
updates: Partial<Task>
|
||||
): Promise<Task | null> {
|
||||
const tasks = await readTasks();
|
||||
const taskIndex = tasks.findIndex((task) => task.id === taskId);
|
||||
|
||||
if (taskIndex === -1) {
|
||||
return null;
|
||||
}
|
||||
|
||||
tasks[taskIndex] = {
|
||||
...tasks[taskIndex],
|
||||
...updates,
|
||||
updatedAt: new Date(),
|
||||
};
|
||||
|
||||
await writeTasks(tasks);
|
||||
|
||||
return tasks[taskIndex];
|
||||
}
|
||||
|
||||
// 更新任務狀態
|
||||
export async function updateTaskStatus(
|
||||
taskId: string,
|
||||
status: TaskStatus
|
||||
): Promise<Task | null> {
|
||||
const updates: Partial<Task> = { status };
|
||||
|
||||
if (status === TaskStatus.COMPLETED) {
|
||||
updates.completedAt = new Date();
|
||||
}
|
||||
|
||||
return await updateTask(taskId, updates);
|
||||
}
|
||||
|
||||
// 批量創建或更新任務
|
||||
export async function batchCreateOrUpdateTasks(
|
||||
taskDataList: Array<{
|
||||
name: string;
|
||||
description: string;
|
||||
notes?: string;
|
||||
dependencies?: string[];
|
||||
}>,
|
||||
isOverwrite: boolean
|
||||
): Promise<Task[]> {
|
||||
// 獲取現有任務，建立名稱到ID的映射
|
||||
const existingTasks = isOverwrite ? [] : await readTasks();
|
||||
const nameToIdMap = new Map<string, string>();
|
||||
|
||||
// 添加現有任務到映射表
|
||||
existingTasks.forEach((task) => {
|
||||
nameToIdMap.set(task.name, task.id);
|
||||
});
|
||||
|
||||
if (isOverwrite) {
|
||||
// 覆蓋模式：刪除所有現有任務
|
||||
await writeTasks([]);
|
||||
}
|
||||
|
||||
// 第一階段：創建所有任務，但不設置依賴
|
||||
const firstPassTasks: Array<{ task: Task; originalDeps: string[] }> = [];
|
||||
|
||||
for (const taskData of taskDataList) {
|
||||
// 創建任務，暫時不設置依賴
|
||||
const newTask = await createTask(
|
||||
taskData.name,
|
||||
taskData.description,
|
||||
taskData.notes,
|
||||
[] // 空依賴列表
|
||||
);
|
||||
|
||||
// 將新任務添加到映射表
|
||||
nameToIdMap.set(newTask.name, newTask.id);
|
||||
|
||||
// 保存原始依賴信息
|
||||
firstPassTasks.push({
|
||||
task: newTask,
|
||||
originalDeps: taskData.dependencies || [],
|
||||
});
|
||||
}
|
||||
|
||||
// 第二階段：更新所有任務的依賴關係
|
||||
const finalTasks: Task[] = [];
|
||||
|
||||
for (const { task, originalDeps } of firstPassTasks) {
|
||||
// 解析依賴關係
|
||||
const resolvedDependencies: TaskDependency[] = [];
|
||||
|
||||
for (const dep of originalDeps) {
|
||||
// 嘗試將依賴名稱解析為ID
|
||||
let depId = dep;
|
||||
|
||||
// 如果不是UUID格式，嘗試將其作為任務名稱解析
|
||||
if (
|
||||
!/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.test(
|
||||
dep
|
||||
)
|
||||
) {
|
||||
const resolvedId = nameToIdMap.get(dep);
|
||||
if (resolvedId) {
|
||||
depId = resolvedId;
|
||||
} else {
|
||||
console.warn(`警告：找不到名為 "${dep}" 的任務，已忽略此依賴`);
|
||||
continue; // 跳過此依賴
|
||||
}
|
||||
}
|
||||
|
||||
resolvedDependencies.push({ taskId: depId });
|
||||
}
|
||||
|
||||
// 更新任務的依賴
|
||||
const updatedTask = await updateTask(task.id, {
|
||||
dependencies: resolvedDependencies,
|
||||
});
|
||||
|
||||
if (updatedTask) {
|
||||
finalTasks.push(updatedTask);
|
||||
} else {
|
||||
finalTasks.push(task); // 回退到原始任務
|
||||
}
|
||||
}
|
||||
|
||||
return finalTasks;
|
||||
}
|
||||
|
||||
// 檢查任務是否可以執行（所有依賴都已完成）
|
||||
export async function canExecuteTask(
|
||||
taskId: string
|
||||
): Promise<{ canExecute: boolean; blockedBy?: string[] }> {
|
||||
const task = await getTaskById(taskId);
|
||||
|
||||
if (!task) {
|
||||
return { canExecute: false };
|
||||
}
|
||||
|
||||
if (task.status === TaskStatus.COMPLETED) {
|
||||
return { canExecute: false }; // 已完成的任務不需要再執行
|
||||
}
|
||||
|
||||
if (task.dependencies.length === 0) {
|
||||
return { canExecute: true }; // 沒有依賴的任務可以直接執行
|
||||
}
|
||||
|
||||
const allTasks = await readTasks();
|
||||
const blockedBy: string[] = [];
|
||||
|
||||
for (const dependency of task.dependencies) {
|
||||
const dependencyTask = allTasks.find((t) => t.id === dependency.taskId);
|
||||
|
||||
if (!dependencyTask || dependencyTask.status !== TaskStatus.COMPLETED) {
|
||||
blockedBy.push(dependency.taskId);
|
||||
}
|
||||
}
|
||||
|
||||
return {
|
||||
canExecute: blockedBy.length === 0,
|
||||
blockedBy: blockedBy.length > 0 ? blockedBy : undefined,
|
||||
};
|
||||
}
|
||||
136
src/prompts/taskPrompts.ts
Normal file
136
src/prompts/taskPrompts.ts
Normal file
@ -0,0 +1,136 @@
|
||||
import { z } from "zod";
|
||||
import { Task } from "../types/index.js";
|
||||
import { getTaskById, getAllTasks } from "../models/taskModel.js";
|
||||
|
||||
// 開始規劃提示
|
||||
export const planTaskPromptSchema = z.object({
|
||||
description: z
|
||||
.string()
|
||||
.describe("完整詳細的任務問題描述，應包含任務目標、背景及預期成果"),
|
||||
requirements: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe("任務的特定技術要求、業務約束條件或品質標準（選填）"),
|
||||
});
|
||||
|
||||
export function planTaskPrompt({
|
||||
description,
|
||||
requirements,
|
||||
}: z.infer<typeof planTaskPromptSchema>) {
|
||||
let prompt = `## 任務分析請求\n\n請仔細分析以下任務問題，理解其核心要求、範圍和約束條件：\n\n\`\`\`\n${description}\n\`\`\`\n\n`;
|
||||
|
||||
if (requirements) {
|
||||
prompt += `## 附加要求與限制條件\n\n請確保方案完全符合以下要求：\n\n\`\`\`\n${requirements}\n\`\`\`\n\n`;
|
||||
}
|
||||
|
||||
prompt += `## 分析指引\n\n請執行以下步驟進行全面分析：\n\n1. 定義問題域和範圍界限\n2. 識別關鍵技術挑戰和決策點\n3. 評估可行的技術方案和架構選擇\n4. 考慮潛在的系統限制和擴展需求\n5. 識別成功標準和驗收條件\n\n如有任何疑問或需要澄清的部分，請立即向用戶提出具體問題。\n\n## 交付成果要求\n\n完成分析後，請提供：\n\n1. **結構化任務摘要** - 準確概括任務的目標、範圍及關鍵挑戰\n2. **初步解答構想** - 提出技術可行的解決方案，包括實施策略和關鍵技術選擇\n\n完成分析後，必須使用「分析問題」工具提交完整的分析結果。`;
|
||||
|
||||
return {
|
||||
messages: [
|
||||
{
|
||||
role: "user" as const,
|
||||
content: {
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
// 執行任務提示
|
||||
export const executeTaskPromptSchema = z.object({
|
||||
taskId: z
|
||||
.string()
|
||||
.describe("待執行任務的唯一標識符，必須是系統中存在的有效任務ID"),
|
||||
});
|
||||
|
||||
export async function executeTaskPrompt({
|
||||
taskId,
|
||||
}: z.infer<typeof executeTaskPromptSchema>) {
|
||||
const task = await getTaskById(taskId);
|
||||
|
||||
if (!task) {
|
||||
throw new Error(`找不到 ID 為 ${taskId} 的任務`);
|
||||
}
|
||||
|
||||
// 獲取依賴任務的名稱，以便更直觀地顯示
|
||||
let dependenciesText = "";
|
||||
if (task.dependencies && task.dependencies.length > 0) {
|
||||
const allTasks = await getAllTasks();
|
||||
const depTasksInfo = task.dependencies.map((dep) => {
|
||||
const depTask = allTasks.find((t) => t.id === dep.taskId);
|
||||
return depTask
|
||||
? `"${depTask.name}" (ID: \`${dep.taskId}\`)`
|
||||
: `ID: \`${dep.taskId}\``;
|
||||
});
|
||||
dependenciesText = `\n\n### 依賴任務\n前置任務：${depTasksInfo.join(", ")}`;
|
||||
}
|
||||
|
||||
const prompt = `## 任務執行指示\n\n### 任務詳情\n\n- **名稱:** ${
|
||||
task.name
|
||||
}\n- **ID:** \`${task.id}\`\n- **描述:** ${task.description}\n${
|
||||
task.notes ? `- **注意事項:** ${task.notes}\n` : ""
|
||||
}${dependenciesText}
|
||||
|
||||
## 執行框架\n\n請嚴格按照以下階段性流程執行任務：\n\n### 1. 需求分析 (20%)\n- 詳細分析任務描述和注意事項\n- 明確定義成功標準和驗收條件\n- 識別潛在的邊緣情況和例外狀況\n\n### 2. 技術規劃 (20%)\n- 設計詳細的技術實施方案\n- 確定所需的技術組件和依賴項\n- 制定清晰的步驟順序和里程碑\n\n### 3. 系統化實施 (40%)\n- 按照規劃順序逐步實施解決方案\n- 嚴格遵循最佳編碼實踐和架構模式\n- 確保代碼可讀性、可維護性和效能\n\n### 4. 自我驗證 (20%)\n- 對照任務需求檢查實現的完整性\n- 測試不同輸入和情境下的功能正確性\n- 優化性能並消除任何潛在風險\n\n## 注意事項\n- 如發現技術障礙或需求不明確，請立即提出具體問題\n- 在實施過程中記錄關鍵決策點和技術選擇理由\n- 考慮解決方案與現有系統的整合性和兼容性\n\n## 下一步行動\n\n完成實施後，必須使用「檢驗任務」工具進行全面驗證，確保所有功能和要求均已正確實現。`;
|
||||
|
||||
return {
|
||||
messages: [
|
||||
{
|
||||
role: "user" as const,
|
||||
content: {
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
// 檢驗任務提示
|
||||
export const verifyTaskPromptSchema = z.object({
|
||||
taskId: z
|
||||
.string()
|
||||
.describe("待驗證任務的唯一標識符，必須是狀態為「進行中」的有效任務ID"),
|
||||
});
|
||||
|
||||
export async function verifyTaskPrompt({
|
||||
taskId,
|
||||
}: z.infer<typeof verifyTaskPromptSchema>) {
|
||||
const task = await getTaskById(taskId);
|
||||
|
||||
if (!task) {
|
||||
throw new Error(`找不到 ID 為 ${taskId} 的任務`);
|
||||
}
|
||||
|
||||
const prompt = `## 任務驗證評估\n\n### 任務資料\n\n- **名稱:** ${
|
||||
task.name
|
||||
}\n- **ID:** \`${task.id}\`\n- **描述:** ${task.description}\n${
|
||||
task.notes ? `- **注意事項:** ${task.notes}\n` : ""
|
||||
}
|
||||
|
||||
## 完整性驗證標準\n\n請對實現結果進行全面且嚴格的評估，基於以下關鍵標準：
|
||||
|
||||
### 1. 需求符合性 (30%)\n- 實現是否完全符合任務描述中的所有功能需求？\n- 是否遵循了所有注意事項和約束條件？\n- 是否處理了所有業務邏輯的邊緣情況？
|
||||
|
||||
### 2. 技術實現質量 (30%)\n- 代碼是否遵循了項目的架構模式和設計原則？\n- 是否有適當的錯誤處理和防禦性編程？\n- 實現是否簡潔高效，避免了不必要的複雜性？
|
||||
|
||||
### 3. 集成與兼容性 (20%)\n- 實現是否與現有系統無縫集成？\n- 是否考慮了與其他組件的相互作用？\n- 是否保持了向前和向後兼容性（如適用）？
|
||||
|
||||
### 4. 性能與可擴展性 (20%)\n- 實現是否考慮了性能優化？\n- 系統是否能夠處理預期的負載和擴展需求？\n- 是否避免了可能的資源洩漏或瓶頸？
|
||||
|
||||
## 驗證流程\n\n請執行以下驗證步驟：\n\n1. 從用戶視角測試功能的完整性和正確性\n2. 評估代碼質量和技術實現的優雅程度\n3. 檢查是否有潛在的安全風險或性能問題\n4. 對照原始需求，確保所有功能點均已實現\n\n## 驗證結果報告\n\n請提供詳細的評估報告，為每個標準分配評分並提供具體證據。對於發現的任何問題，請提供明確的修復建議。\n\n## 決策點\n\n- 如發現嚴重問題：請繼續完善實現，解決所有識別出的問題\n- 如確認任務已完全符合要求：請使用「完成任務」工具，標記任務為已完成並提交最終報告`;
|
||||
|
||||
return {
|
||||
messages: [
|
||||
{
|
||||
role: "user" as const,
|
||||
content: {
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
516
src/tools/taskTools.ts
Normal file
516
src/tools/taskTools.ts
Normal file
@ -0,0 +1,516 @@
|
||||
import { z } from "zod";
|
||||
import {
|
||||
getAllTasks,
|
||||
getTaskById,
|
||||
updateTaskStatus,
|
||||
canExecuteTask,
|
||||
batchCreateOrUpdateTasks,
|
||||
} from "../models/taskModel.js";
|
||||
import { TaskStatus } from "../types/index.js";
|
||||
|
||||
// 開始規劃工具
|
||||
export const planTaskSchema = z.object({
|
||||
description: z
|
||||
.string()
|
||||
.describe("完整詳細的任務問題描述，應包含任務目標、背景及預期成果"),
|
||||
requirements: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe("任務的特定技術要求、業務約束條件或品質標準（選填）"),
|
||||
});
|
||||
|
||||
export async function planTask({
|
||||
description,
|
||||
requirements,
|
||||
}: z.infer<typeof planTaskSchema>) {
|
||||
let prompt = `## 任務分析請求\n\n請仔細分析以下任務問題，理解其核心要求、範圍和約束條件：\n\n\`\`\`\n${description}\n\`\`\`\n\n`;
|
||||
|
||||
if (requirements) {
|
||||
prompt += `## 附加要求與限制條件\n\n請確保方案完全符合以下要求：\n\n\`\`\`\n${requirements}\n\`\`\`\n\n`;
|
||||
}
|
||||
|
||||
prompt += `## 分析指引\n\n1. 首先確定任務的確切目標和預期成果
|
||||
2. 識別任務中可能的技術挑戰和關鍵決策點
|
||||
3. 考慮潛在的解決方案和替代方案
|
||||
4. 評估每種方案的優缺點
|
||||
|
||||
如果對任務描述有任何不清楚或需要澄清的地方，請明確向用戶提問。
|
||||
|
||||
## 下一步行動\n\n完成初步分析後，請使用「analyze_task」工具提交您的分析結果，必須同時包含：\n\n1. 結構化的任務摘要（包括目標、範圍和關鍵挑戰）\n2. 初步解答構想（包括技術方案和實施策略）`;
|
||||
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
// 分析問題工具
|
||||
export const analyzeTaskSchema = z.object({
|
||||
summary: z
|
||||
.string()
|
||||
.describe("結構化的任務摘要，包含任務目標、範圍與關鍵技術挑戰"),
|
||||
initialConcept: z
|
||||
.string()
|
||||
.describe("初步解答構想，包含技術方案、架構設計和實施策略"),
|
||||
previousAnalysis: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe("前次迭代的分析結果，用於持續改進方案（僅在重新分析時需提供）"),
|
||||
});
|
||||
|
||||
export async function analyzeTask({
|
||||
summary,
|
||||
initialConcept,
|
||||
previousAnalysis,
|
||||
}: z.infer<typeof analyzeTaskSchema>) {
|
||||
let prompt = `## 代碼庫分析任務\n\n### 任務摘要\n\`\`\`\n${summary}\n\`\`\`\n\n已收到您的初步解答構想：\n\n\`\`\`\n${initialConcept}\n\`\`\`\n\n`;
|
||||
|
||||
prompt += `## 技術審核指引\n\n請執行以下分析步驟：\n\n1. 檢查現有程式碼庫中的相似實現或可重用組件
|
||||
2. 評估是否可以抽象出通用模式或利用現有框架
|
||||
3. 識別潛在的技術債務或效能瓶頸
|
||||
4. 確保方案符合項目的架構風格和最佳實踐
|
||||
|
||||
請特別關注程式碼重用的機會，避免重複實作已有功能，降低技術債務風險。`;
|
||||
|
||||
if (previousAnalysis) {
|
||||
prompt += `\n\n## 迭代分析\n\n請對照先前的分析結果進行比較和改進：\n\n\`\`\`\n${previousAnalysis}\n\`\`\`\n\n請明確識別：\n1. 哪些問題已經解決\n2. 哪些問題仍然存在\n3. 您的新方案如何解決之前未解決的問題`;
|
||||
}
|
||||
|
||||
prompt += `\n\n## 下一步行動\n\n完成深入分析後，請使用「reflect_task」工具提交：\n\n1. 原始任務摘要（保持與第一階段一致）\n2. 完整的分析結果（包括技術細節、依賴組件和實施策略）`;
|
||||
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
// 反思構想工具
|
||||
export const reflectTaskSchema = z.object({
|
||||
summary: z
|
||||
.string()
|
||||
.describe("結構化的任務摘要，保持與分析階段一致以確保連續性"),
|
||||
analysis: z
|
||||
.string()
|
||||
.describe("完整詳盡的技術分析結果，包括所有技術細節、依賴組件和實施方案"),
|
||||
});
|
||||
|
||||
export async function reflectTask({
|
||||
summary,
|
||||
analysis,
|
||||
}: z.infer<typeof reflectTaskSchema>) {
|
||||
const prompt = `## 解決方案反思與評估\n\n### 任務摘要\n\`\`\`\n${summary}\n\`\`\`\n\n### 詳細分析結果\n\`\`\`\n${analysis}\n\`\`\`\n\n## 批判性評估指引\n\n請從以下多個維度對您的解決方案進行全面且批判性的審查：\n\n### 1. 技術完整性評估\n- 方案是否存在技術缺陷或邏輯漏洞？
|
||||
- 是否考慮了邊緣情況和異常處理？
|
||||
- 所有數據流和控制流是否清晰定義？
|
||||
|
||||
### 2. 效能與可擴展性評估
|
||||
- 解決方案在資源使用效率方面是否最佳化？
|
||||
- 系統在負載增加時是否仍能保持穩定性能？
|
||||
- 是否有可能進一步優化的部分？
|
||||
|
||||
### 3. 需求符合度評估
|
||||
- 解決方案是否完全實現了所有功能需求？
|
||||
- 是否符合所有非功能性需求（如安全性、可維護性）？
|
||||
- 是否有遺漏或誤解的需求？
|
||||
|
||||
## 決策點\n\n基於您的反思，請選擇下一步行動：\n\n- 如果發現需要改進的關鍵問題：請使用「analyze_task」工具，重新提交改進後的方案（必須包含之前的摘要和修改後的構想）\n\n- 如果確認方案已足夠完善：請使用「split_tasks」工具，將解決方案分解為具體、可執行的子任務，並建立明確的依賴關係`;
|
||||
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
// 拆分任務工具
|
||||
export const splitTasksSchema = z.object({
|
||||
isOverwrite: z
|
||||
.boolean()
|
||||
.describe(
|
||||
"任務覆蓋模式選擇（true：清除並覆蓋所有現有任務；false：保留現有任務並新增）"
|
||||
),
|
||||
tasks: z
|
||||
.array(
|
||||
z.object({
|
||||
name: z.string().describe("簡潔明確的任務名稱，應能清晰表達任務目的"),
|
||||
description: z
|
||||
.string()
|
||||
.describe("詳細的任務描述，包含實施要點、技術細節和驗收標準"),
|
||||
notes: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe("補充說明、特殊處理要求或實施建議（選填）"),
|
||||
dependencies: z
|
||||
.array(z.string())
|
||||
.optional()
|
||||
.describe(
|
||||
"此任務依賴的前置任務ID或任務名稱列表，支持兩種引用方式，名稱引用更直觀"
|
||||
),
|
||||
})
|
||||
)
|
||||
.describe("結構化的任務清單，每個任務應保持原子性且有明確的完成標準"),
|
||||
});
|
||||
|
||||
export async function splitTasks({
|
||||
isOverwrite,
|
||||
tasks,
|
||||
}: z.infer<typeof splitTasksSchema>) {
|
||||
// 批量創建任務
|
||||
const createdTasks = await batchCreateOrUpdateTasks(tasks, isOverwrite);
|
||||
|
||||
// 獲取所有任務，用於顯示完整的依賴關係
|
||||
const allTasks = await getAllTasks();
|
||||
|
||||
const prompt = `## 任務拆分結果 - ${
|
||||
isOverwrite ? "覆蓋模式" : "新增模式"
|
||||
}\n\n### 系統確認\n任務已成功${
|
||||
isOverwrite ? "覆蓋現有任務清單" : "新增至現有任務清單"
|
||||
}。\n\n## 任務質量審核指引\n\n請根據以下標準對任務拆分進行嚴格的質量審核：\n\n### 1. 任務原子性\n- 每個任務是否足夠小且具體，可獨立完成？
|
||||
- 任務是否具有清晰的完成標準？
|
||||
- 是否避免了範圍過大的任務？
|
||||
|
||||
### 2. 依賴關係完整性\n- 任務依賴關係是否形成有向無環圖？
|
||||
- 是否存在隱藏依賴未被明確標記？
|
||||
- 依賴鏈是否最短化，避免不必要的阻塞？
|
||||
|
||||
### 3. 描述完整性\n- 每個任務描述是否清晰準確？
|
||||
- 是否包含足夠的上下文信息？
|
||||
- 注意事項是否涵蓋關鍵實施細節？
|
||||
|
||||
## 詳細任務清單\n\n${createdTasks
|
||||
.map(
|
||||
(task, index) =>
|
||||
`### 任務 ${index + 1}：${task.name}\n**ID:** \`${
|
||||
task.id
|
||||
}\`\n**描述:** ${task.description}\n${
|
||||
task.notes ? `**注意事項:** ${task.notes}\n` : ""
|
||||
}${
|
||||
task.dependencies.length > 0
|
||||
? `**依賴任務:** ${task.dependencies
|
||||
.map((d) => {
|
||||
// 查找依賴任務的名稱，提供更友好的顯示
|
||||
const depTask = allTasks.find((t) => t.id === d.taskId);
|
||||
return depTask
|
||||
? `"${depTask.name}" (\`${d.taskId}\`)`
|
||||
: `\`${d.taskId}\``;
|
||||
})
|
||||
.join(", ")}\n`
|
||||
: "**依賴任務:** 無\n"
|
||||
}`
|
||||
)
|
||||
.join(
|
||||
"\n"
|
||||
)}\n\n## 任務依賴提示\n\n在建立新任務時，可以通過以下方式指定依賴關係：\n\n1. **使用任務名稱**（推薦）：直接使用其他任務的名稱，如 \`"建立用戶界面"\`\n2. **使用任務ID**：使用任務的唯一標識符，如 \`"${
|
||||
createdTasks.length > 0
|
||||
? createdTasks[0].id
|
||||
: "a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6"
|
||||
}"\`\n\n## 決策點\n\n請選擇下一步行動：\n\n- 如發現任務拆分不合理：請重新呼叫「split_tasks」工具，調整任務定義或依賴關係\n\n- 如確認任務拆分完善：請生成執行計劃摘要，包括建議的執行順序、關鍵路徑和風險點`;
|
||||
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
// 列出任務工具
|
||||
export async function listTasks() {
|
||||
const tasks = await getAllTasks();
|
||||
|
||||
if (tasks.length === 0) {
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: "## 系統通知\n\n目前系統中沒有註冊任何任務。請先使用「split_tasks」工具創建任務結構，再進行後續操作。",
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
const tasksByStatus = tasks.reduce((acc, task) => {
|
||||
if (!acc[task.status]) {
|
||||
acc[task.status] = [];
|
||||
}
|
||||
acc[task.status].push(task);
|
||||
return acc;
|
||||
}, {} as Record<string, typeof tasks>);
|
||||
|
||||
let result = "# 任務管理儀表板\n\n## 任務狀態概覽\n\n";
|
||||
|
||||
// 添加任務狀態計數摘要
|
||||
const statusCounts = Object.values(TaskStatus)
|
||||
.map((status) => {
|
||||
const count = tasksByStatus[status]?.length || 0;
|
||||
return `- **${status}**: ${count} 個任務`;
|
||||
})
|
||||
.join("\n");
|
||||
|
||||
result += `${statusCounts}\n\n`;
|
||||
|
||||
// 添加每個狀態下的詳細任務
|
||||
for (const status of Object.values(TaskStatus)) {
|
||||
const tasksWithStatus = tasksByStatus[status] || [];
|
||||
|
||||
if (tasksWithStatus.length > 0) {
|
||||
result += `## ${status} (${tasksWithStatus.length})\n\n`;
|
||||
|
||||
tasksWithStatus.forEach((task, index) => {
|
||||
result += `### ${index + 1}. ${task.name}\n`;
|
||||
result += `- **ID:** \`${task.id}\`\n`;
|
||||
result += `- **描述:** ${task.description}\n`;
|
||||
if (task.notes) {
|
||||
result += `- **注意事項:** ${task.notes}\n`;
|
||||
}
|
||||
if (task.dependencies.length > 0) {
|
||||
result += `- **依賴任務:** ${task.dependencies
|
||||
.map((d) => `\`${d.taskId}\``)
|
||||
.join(", ")}\n`;
|
||||
}
|
||||
|
||||
// 添加時間相關訊息
|
||||
result += `- **創建時間:** ${task.createdAt.toISOString()}\n`;
|
||||
if (task.status === TaskStatus.COMPLETED && task.completedAt) {
|
||||
result += `- **完成時間:** ${task.completedAt.toISOString()}\n`;
|
||||
}
|
||||
|
||||
result += "\n";
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: result,
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
// 執行任務工具
|
||||
export const executeTaskSchema = z.object({
|
||||
taskId: z
|
||||
.string()
|
||||
.describe("待執行任務的唯一標識符，必須是系統中存在的有效任務ID"),
|
||||
});
|
||||
|
||||
export async function executeTask({
|
||||
taskId,
|
||||
}: z.infer<typeof executeTaskSchema>) {
|
||||
const task = await getTaskById(taskId);
|
||||
|
||||
if (!task) {
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: `## 系統錯誤\n\n找不到ID為 \`${taskId}\` 的任務。請使用「list_tasks」工具確認有效的任務ID後再試。`,
|
||||
},
|
||||
],
|
||||
isError: true,
|
||||
};
|
||||
}
|
||||
|
||||
if (task.status === TaskStatus.COMPLETED) {
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: `## 系統通知\n\n任務 "${task.name}" (ID: \`${task.id}\`) 已於 ${
|
||||
task.completedAt?.toISOString() || "先前"
|
||||
} 完成，無需再次執行。\n\n如需修改或重新執行，請先聯繫系統管理員重置任務狀態。`,
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
const { canExecute, blockedBy } = await canExecuteTask(taskId);
|
||||
|
||||
if (!canExecute && blockedBy) {
|
||||
// 找出阻塞的任務名稱
|
||||
const allTasks = await getAllTasks();
|
||||
const blockedByTaskNames = blockedBy.map((id) => {
|
||||
const blockingTask = allTasks.find((t) => t.id === id);
|
||||
return blockingTask
|
||||
? `"${blockingTask.name}" (ID: \`${id}\`)`
|
||||
: `ID: \`${id}\``;
|
||||
});
|
||||
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: `## 任務依賴阻塞通知\n\n無法執行任務 "${task.name}" (ID: \`${
|
||||
task.id
|
||||
}\`)。\n\n### 阻塞原因\n此任務依賴於尚未完成的前置任務。請先完成以下依賴任務：\n\n${blockedByTaskNames
|
||||
.map((name, i) => `${i + 1}. ${name}`)
|
||||
.join("\n")}`,
|
||||
},
|
||||
],
|
||||
isError: true,
|
||||
};
|
||||
}
|
||||
|
||||
// 更新任務狀態為進行中
|
||||
await updateTaskStatus(taskId, TaskStatus.IN_PROGRESS);
|
||||
|
||||
const prompt = `## 任務執行指示\n\n### 任務詳情\n\n- **名稱:** ${
|
||||
task.name
|
||||
}\n- **ID:** \`${task.id}\`\n- **描述:** ${task.description}\n${
|
||||
task.notes ? `- **注意事項:** ${task.notes}\n` : ""
|
||||
}
|
||||
|
||||
## 執行指引\n\n1. 請仔細分析任務要求，確保理解所有細節和約束條件
|
||||
2. 設計詳細的執行方案，包括具體步驟和技術選擇
|
||||
3. 系統性地實施您的方案，遵循最佳實踐和項目慣例
|
||||
4. 完整記錄您的實施過程，包括重要決策點和遇到的挑戰
|
||||
|
||||
## 質量保證\n\n- 確保代碼符合專案編碼標準和架構設計
|
||||
- 實施適當的錯誤處理和邊緣情況檢查
|
||||
- 優化性能和資源使用
|
||||
|
||||
## 下一步行動\n\n完成實施後，必須使用「verify_task」工具進行全面驗證，確保所有功能和要求均已正確實現。`;
|
||||
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
// 檢驗任務工具
|
||||
export const verifyTaskSchema = z.object({
|
||||
taskId: z
|
||||
.string()
|
||||
.describe("待驗證任務的唯一標識符，必須是狀態為「進行中」的有效任務ID"),
|
||||
});
|
||||
|
||||
export async function verifyTask({ taskId }: z.infer<typeof verifyTaskSchema>) {
|
||||
const task = await getTaskById(taskId);
|
||||
|
||||
if (!task) {
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: `## 系統錯誤\n\n找不到ID為 \`${taskId}\` 的任務。請使用「list_tasks」工具確認有效的任務ID後再試。`,
|
||||
},
|
||||
],
|
||||
isError: true,
|
||||
};
|
||||
}
|
||||
|
||||
if (task.status !== TaskStatus.IN_PROGRESS) {
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: `## 狀態錯誤\n\n任務 "${task.name}" (ID: \`${task.id}\`) 當前狀態為 "${task.status}"，不處於進行中狀態，無法進行檢驗。\n\n只有狀態為「進行中」的任務才能進行檢驗。請先使用「execute_task」工具開始任務執行。`,
|
||||
},
|
||||
],
|
||||
isError: true,
|
||||
};
|
||||
}
|
||||
|
||||
const prompt = `## 任務驗證評估\n\n### 任務資料\n\n- **名稱:** ${
|
||||
task.name
|
||||
}\n- **ID:** \`${task.id}\`\n- **描述:** ${task.description}\n${
|
||||
task.notes ? `- **注意事項:** ${task.notes}\n` : ""
|
||||
}
|
||||
|
||||
## 完整性驗證標準\n\n請根據以下關鍵標準進行嚴格的質量檢查：
|
||||
|
||||
### 1. 需求符合性 (30%)\n- 實現是否完全符合任務描述中的所有功能需求？\n- 是否遵循了所有注意事項和約束條件？\n- 是否處理了所有業務邏輯的邊緣情況？
|
||||
|
||||
### 2. 技術實現質量 (30%)\n- 代碼是否遵循了項目的架構模式和設計原則？\n- 是否有適當的錯誤處理和防禦性編程？\n- 實現是否簡潔高效，避免了不必要的複雜性？
|
||||
|
||||
### 3. 集成與兼容性 (20%)\n- 實現是否與現有系統無縫集成？\n- 是否考慮了與其他組件的相互作用？\n- 是否保持了向前和向後兼容性（如適用）？
|
||||
|
||||
### 4. 性能與可擴展性 (20%)\n- 實現是否考慮了性能優化？\n- 系統是否能夠處理預期的負載和擴展需求？\n- 是否避免了可能的資源洩漏或瓶頸？
|
||||
|
||||
## 驗證結果報告\n\n請提供詳細的驗證結果報告，為每個標準分配評分並提供具體證據。對於發現的任何問題，請提供明確的修復建議。
|
||||
|
||||
## 決策點\n\n- 如果發現嚴重問題：請繼續改進並解決問題\n- 如果任務已完全符合要求：請使用「complete_task」工具，標記任務為已完成並提交最終報告`;
|
||||
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
// 完成任務工具
|
||||
export const completeTaskSchema = z.object({
|
||||
taskId: z
|
||||
.string()
|
||||
.describe(
|
||||
"待標記為完成的任務唯一標識符，必須是狀態為「進行中」的有效任務ID"
|
||||
),
|
||||
});
|
||||
|
||||
export async function completeTask({
|
||||
taskId,
|
||||
}: z.infer<typeof completeTaskSchema>) {
|
||||
const task = await getTaskById(taskId);
|
||||
|
||||
if (!task) {
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: `## 系統錯誤\n\n找不到ID為 \`${taskId}\` 的任務。請使用「list_tasks」工具確認有效的任務ID後再試。`,
|
||||
},
|
||||
],
|
||||
isError: true,
|
||||
};
|
||||
}
|
||||
|
||||
if (task.status !== TaskStatus.IN_PROGRESS) {
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: `## 狀態錯誤\n\n任務 "${task.name}" (ID: \`${task.id}\`) 當前狀態為 "${task.status}"，不是進行中狀態，無法標記為完成。\n\n只有狀態為「進行中」的任務才能標記為完成。請先使用「execute_task」工具開始任務執行。`,
|
||||
},
|
||||
],
|
||||
isError: true,
|
||||
};
|
||||
}
|
||||
|
||||
// 更新任務狀態為已完成
|
||||
await updateTaskStatus(taskId, TaskStatus.COMPLETED);
|
||||
|
||||
const prompt = `## 任務完成確認\n\n任務 "${task.name}" (ID: \`${
|
||||
task.id
|
||||
}\`) 已於 ${new Date().toISOString()} 成功標記為完成。\n\n## 任務報告要求\n\n請提供全面且結構化的任務完成報告，必須包含以下章節：\n\n### 1. 任務概述 (20%)\n- 簡要說明任務目標及其在整體系統中的角色\n- 概述任務的範圍和界限\n- 說明任務的重要性和價值\n\n### 2. 實施摘要 (30%)\n- 詳述採用的技術方案和架構決策\n- 說明關鍵算法和數據結構的選擇\n- 列出使用的外部依賴和API\n\n### 3. 挑戰與解決方案 (20%)\n- 描述在實施過程中遇到的主要技術挑戰\n- 解釋每個挑戰的解決方案及其理由\n- 討論探索過但未採用的替代方案\n\n### 4. 質量保證措施 (15%)\n- 總結執行的測試類型和範圍\n- 報告性能測量結果（如適用）\n- 描述實施的安全措施（如適用）\n\n### 5. 後續步驟與建議 (15%)\n- 提出可能的進一步改進或優化\n- 識別潛在的風險或技術債務\n- 建議下一步行動和優先事項`;
|
||||
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
72
src/types/index.ts
Normal file
72
src/types/index.ts
Normal file
@ -0,0 +1,72 @@
|
||||
// 任務狀態枚舉：定義任務在工作流程中的當前階段
|
||||
export enum TaskStatus {
|
||||
PENDING = "待處理", // 已創建但尚未開始執行的任務
|
||||
IN_PROGRESS = "進行中", // 當前正在執行的任務
|
||||
COMPLETED = "已完成", // 已成功完成並通過驗證的任務
|
||||
BLOCKED = "被阻擋", // 由於依賴關係而暫時無法執行的任務
|
||||
}
|
||||
|
||||
// 任務依賴關係：定義任務之間的前置條件關係
|
||||
export interface TaskDependency {
|
||||
taskId: string; // 前置任務的唯一標識符，當前任務執行前必須完成此依賴任務
|
||||
}
|
||||
|
||||
// 任務介面：定義任務的完整數據結構
|
||||
export interface Task {
|
||||
id: string; // 任務的唯一標識符
|
||||
name: string; // 簡潔明確的任務名稱
|
||||
description: string; // 詳細的任務描述，包含實施要點和驗收標準
|
||||
notes?: string; // 補充說明、特殊處理要求或實施建議（選填）
|
||||
status: TaskStatus; // 任務當前的執行狀態
|
||||
dependencies: TaskDependency[]; // 任務的前置依賴關係列表
|
||||
createdAt: Date; // 任務創建的時間戳
|
||||
updatedAt: Date; // 任務最後更新的時間戳
|
||||
completedAt?: Date; // 任務完成的時間戳（僅適用於已完成的任務）
|
||||
}
|
||||
|
||||
// 規劃任務的參數：用於初始化任務規劃階段
|
||||
export interface PlanTaskArgs {
|
||||
description: string; // 完整詳細的任務問題描述，應包含任務目標、背景及預期成果
|
||||
requirements?: string; // 任務的特定技術要求、業務約束條件或品質標準（選填）
|
||||
}
|
||||
|
||||
// 分析問題的參數：用於深入分析任務並提出技術方案
|
||||
export interface AnalyzeTaskArgs {
|
||||
summary: string; // 結構化的任務摘要，包含任務目標、範圍與關鍵技術挑戰
|
||||
initialConcept: string; // 初步解答構想，包含技術方案、架構設計和實施策略
|
||||
previousAnalysis?: string; // 前次迭代的分析結果，用於持續改進方案（僅在重新分析時需提供）
|
||||
}
|
||||
|
||||
// 反思構想的參數：用於對分析結果進行批判性評估
|
||||
export interface ReflectTaskArgs {
|
||||
summary: string; // 結構化的任務摘要，保持與分析階段一致以確保連續性
|
||||
analysis: string; // 完整詳盡的技術分析結果，包括所有技術細節、依賴組件和實施方案
|
||||
}
|
||||
|
||||
// 拆分任務的參數：用於將大型任務分解為可管理的小型任務
|
||||
export interface SplitTasksArgs {
|
||||
isOverwrite: boolean; // 任務覆蓋模式選擇（true：清除並覆蓋所有現有任務；false：保留現有任務並新增）
|
||||
tasks: Array<{
|
||||
name: string; // 簡潔明確的任務名稱，應能清晰表達任務目的
|
||||
description: string; // 詳細的任務描述，包含實施要點、技術細節和驗收標準
|
||||
notes?: string; // 補充說明、特殊處理要求或實施建議（選填）
|
||||
dependencies?: string[]; // 此任務依賴的前置任務ID列表，形成任務的有向無環依賴圖
|
||||
}>;
|
||||
}
|
||||
|
||||
// 列出任務的參數（無）
|
||||
|
||||
// 執行任務的參數：用於開始執行特定任務
|
||||
export interface ExecuteTaskArgs {
|
||||
taskId: string; // 待執行任務的唯一標識符，必須是系統中存在的有效任務ID
|
||||
}
|
||||
|
||||
// 檢驗任務的參數：用於評估任務的完成質量
|
||||
export interface VerifyTaskArgs {
|
||||
taskId: string; // 待驗證任務的唯一標識符，必須是狀態為「進行中」的有效任務ID
|
||||
}
|
||||
|
||||
// 完成任務的參數：用於標記任務為已完成狀態
|
||||
export interface CompleteTaskArgs {
|
||||
taskId: string; // 待標記為完成的任務唯一標識符，必須是狀態為「進行中」的有效任務ID
|
||||
}
|
||||
115
tsconfig.json
Normal file
115
tsconfig.json
Normal file
@ -0,0 +1,115 @@
|
||||
{
|
||||
"compilerOptions": {
|
||||
/* Visit https://aka.ms/tsconfig to read more about this file */
|
||||
|
||||
/* Projects */
|
||||
// "incremental": true, /* Save .tsbuildinfo files to allow for incremental compilation of projects. */
|
||||
// "composite": true, /* Enable constraints that allow a TypeScript project to be used with project references. */
|
||||
// "tsBuildInfoFile": "./.tsbuildinfo", /* Specify the path to .tsbuildinfo incremental compilation file. */
|
||||
// "disableSourceOfProjectReferenceRedirect": true, /* Disable preferring source files instead of declaration files when referencing composite projects. */
|
||||
// "disableSolutionSearching": true, /* Opt a project out of multi-project reference checking when editing. */
|
||||
// "disableReferencedProjectLoad": true, /* Reduce the number of projects loaded automatically by TypeScript. */
|
||||
|
||||
/* Language and Environment */
|
||||
"target": "ES2022",
|
||||
// "lib": [], /* Specify a set of bundled library declaration files that describe the target runtime environment. */
|
||||
// "jsx": "preserve", /* Specify what JSX code is generated. */
|
||||
// "libReplacement": true, /* Enable lib replacement. */
|
||||
// "experimentalDecorators": true, /* Enable experimental support for legacy experimental decorators. */
|
||||
// "emitDecoratorMetadata": true, /* Emit design-type metadata for decorated declarations in source files. */
|
||||
// "jsxFactory": "", /* Specify the JSX factory function used when targeting React JSX emit, e.g. 'React.createElement' or 'h'. */
|
||||
// "jsxFragmentFactory": "", /* Specify the JSX Fragment reference used for fragments when targeting React JSX emit e.g. 'React.Fragment' or 'Fragment'. */
|
||||
// "jsxImportSource": "", /* Specify module specifier used to import the JSX factory functions when using 'jsx: react-jsx*'. */
|
||||
// "reactNamespace": "", /* Specify the object invoked for 'createElement'. This only applies when targeting 'react' JSX emit. */
|
||||
// "noLib": true, /* Disable including any library files, including the default lib.d.ts. */
|
||||
// "useDefineForClassFields": true, /* Emit ECMAScript-standard-compliant class fields. */
|
||||
// "moduleDetection": "auto", /* Control what method is used to detect module-format JS files. */
|
||||
|
||||
/* Modules */
|
||||
"module": "NodeNext",
|
||||
"moduleResolution": "NodeNext",
|
||||
// "rootDir": "./", /* Specify the root folder within your source files. */
|
||||
// "baseUrl": "./", /* Specify the base directory to resolve non-relative module names. */
|
||||
// "paths": {}, /* Specify a set of entries that re-map imports to additional lookup locations. */
|
||||
// "rootDirs": [], /* Allow multiple folders to be treated as one when resolving modules. */
|
||||
// "typeRoots": [], /* Specify multiple folders that act like './node_modules/@types'. */
|
||||
// "types": [], /* Specify type package names to be included without being referenced in a source file. */
|
||||
// "allowUmdGlobalAccess": true, /* Allow accessing UMD globals from modules. */
|
||||
// "moduleSuffixes": [], /* List of file name suffixes to search when resolving a module. */
|
||||
// "allowImportingTsExtensions": true, /* Allow imports to include TypeScript file extensions. Requires '--moduleResolution bundler' and either '--noEmit' or '--emitDeclarationOnly' to be set. */
|
||||
// "rewriteRelativeImportExtensions": true, /* Rewrite '.ts', '.tsx', '.mts', and '.cts' file extensions in relative import paths to their JavaScript equivalent in output files. */
|
||||
// "resolvePackageJsonExports": true, /* Use the package.json 'exports' field when resolving package imports. */
|
||||
// "resolvePackageJsonImports": true, /* Use the package.json 'imports' field when resolving imports. */
|
||||
// "customConditions": [], /* Conditions to set in addition to the resolver-specific defaults when resolving imports. */
|
||||
// "noUncheckedSideEffectImports": true, /* Check side effect imports. */
|
||||
"resolveJsonModule": true,
|
||||
// "allowArbitraryExtensions": true, /* Enable importing files with any extension, provided a declaration file is present. */
|
||||
// "noResolve": true, /* Disallow 'import's, 'require's or '<reference>'s from expanding the number of files TypeScript should add to a project. */
|
||||
|
||||
/* JavaScript Support */
|
||||
// "allowJs": true, /* Allow JavaScript files to be a part of your program. Use the 'checkJS' option to get errors from these files. */
|
||||
// "checkJs": true, /* Enable error reporting in type-checked JavaScript files. */
|
||||
// "maxNodeModuleJsDepth": 1, /* Specify the maximum folder depth used for checking JavaScript files from 'node_modules'. Only applicable with 'allowJs'. */
|
||||
|
||||
/* Emit */
|
||||
"declaration": true,
|
||||
// "declarationMap": true, /* Create sourcemaps for d.ts files. */
|
||||
// "emitDeclarationOnly": true, /* Only output d.ts files and not JavaScript files. */
|
||||
"sourceMap": true,
|
||||
// "inlineSourceMap": true, /* Include sourcemap files inside the emitted JavaScript. */
|
||||
// "noEmit": true, /* Disable emitting files from a compilation. */
|
||||
// "outFile": "./", /* Specify a file that bundles all outputs into one JavaScript file. If 'declaration' is true, also designates a file that bundles all .d.ts output. */
|
||||
"outDir": "./dist",
|
||||
// "removeComments": true, /* Disable emitting comments. */
|
||||
// "importHelpers": true, /* Allow importing helper functions from tslib once per project, instead of including them per-file. */
|
||||
// "downlevelIteration": true, /* Emit more compliant, but verbose and less performant JavaScript for iteration. */
|
||||
// "sourceRoot": "", /* Specify the root path for debuggers to find the reference source code. */
|
||||
// "mapRoot": "", /* Specify the location where debugger should locate map files instead of generated locations. */
|
||||
// "inlineSources": true, /* Include source code in the sourcemaps inside the emitted JavaScript. */
|
||||
// "emitBOM": true, /* Emit a UTF-8 Byte Order Mark (BOM) in the beginning of output files. */
|
||||
// "newLine": "crlf", /* Set the newline character for emitting files. */
|
||||
// "stripInternal": true, /* Disable emitting declarations that have '@internal' in their JSDoc comments. */
|
||||
// "noEmitHelpers": true, /* Disable generating custom helper functions like '__extends' in compiled output. */
|
||||
// "noEmitOnError": true, /* Disable emitting files if any type checking errors are reported. */
|
||||
// "preserveConstEnums": true, /* Disable erasing 'const enum' declarations in generated code. */
|
||||
// "declarationDir": "./", /* Specify the output directory for generated declaration files. */
|
||||
|
||||
/* Interop Constraints */
|
||||
// "isolatedModules": true, /* Ensure that each file can be safely transpiled without relying on other imports. */
|
||||
// "verbatimModuleSyntax": true, /* Do not transform or elide any imports or exports not marked as type-only, ensuring they are written in the output file's format based on the 'module' setting. */
|
||||
// "isolatedDeclarations": true, /* Require sufficient annotation on exports so other tools can trivially generate declaration files. */
|
||||
// "erasableSyntaxOnly": true, /* Do not allow runtime constructs that are not part of ECMAScript. */
|
||||
// "allowSyntheticDefaultImports": true, /* Allow 'import x from y' when a module doesn't have a default export. */
|
||||
"esModuleInterop": true,
|
||||
// "preserveSymlinks": true, /* Disable resolving symlinks to their realpath. This correlates to the same flag in node. */
|
||||
"forceConsistentCasingInFileNames": true,
|
||||
|
||||
/* Type Checking */
|
||||
"strict": true,
|
||||
// "noImplicitAny": true, /* Enable error reporting for expressions and declarations with an implied 'any' type. */
|
||||
// "strictNullChecks": true, /* When type checking, take into account 'null' and 'undefined'. */
|
||||
// "strictFunctionTypes": true, /* When assigning functions, check to ensure parameters and the return values are subtype-compatible. */
|
||||
// "strictBindCallApply": true, /* Check that the arguments for 'bind', 'call', and 'apply' methods match the original function. */
|
||||
// "strictPropertyInitialization": true, /* Check for class properties that are declared but not set in the constructor. */
|
||||
// "strictBuiltinIteratorReturn": true, /* Built-in iterators are instantiated with a 'TReturn' type of 'undefined' instead of 'any'. */
|
||||
// "noImplicitThis": true, /* Enable error reporting when 'this' is given the type 'any'. */
|
||||
// "useUnknownInCatchVariables": true, /* Default catch clause variables as 'unknown' instead of 'any'. */
|
||||
// "alwaysStrict": true, /* Ensure 'use strict' is always emitted. */
|
||||
// "noUnusedLocals": true, /* Enable error reporting when local variables aren't read. */
|
||||
// "noUnusedParameters": true, /* Raise an error when a function parameter isn't read. */
|
||||
// "exactOptionalPropertyTypes": true, /* Interpret optional property types as written, rather than adding 'undefined'. */
|
||||
// "noImplicitReturns": true, /* Enable error reporting for codepaths that do not explicitly return in a function. */
|
||||
// "noFallthroughCasesInSwitch": true, /* Enable error reporting for fallthrough cases in switch statements. */
|
||||
// "noUncheckedIndexedAccess": true, /* Add 'undefined' to a type when accessed using an index. */
|
||||
// "noImplicitOverride": true, /* Ensure overriding members in derived classes are marked with an override modifier. */
|
||||
// "noPropertyAccessFromIndexSignature": true, /* Enforces using indexed accessors for keys declared using an indexed type. */
|
||||
// "allowUnusedLabels": true, /* Disable error reporting for unused labels. */
|
||||
// "allowUnreachableCode": true, /* Disable error reporting for unreachable code. */
|
||||
|
||||
/* Completeness */
|
||||
// "skipDefaultLibCheck": true, /* Skip type checking .d.ts files that are included with TypeScript. */
|
||||
"skipLibCheck": true
|
||||
},
|
||||
"include": ["src/**/*"],
|
||||
"exclude": ["node_modules", "dist"]
|
||||
}
|
||||
Loading…
x
Reference in New Issue
Block a user