feat(web): implement schedule editor in MaintenancePoliciesTab
CI / changes (push) Successful in 8s
CI / commitlint (push) Has been skipped
CI / openapi (push) Has been skipped
CI / web (push) Successful in 31s
CI / go (push) Successful in 51s
CI / bird2 (push) Successful in 15s
CI / release (push) Successful in 3m48s
CI / changes (push) Successful in 8s
CI / commitlint (push) Has been skipped
CI / openapi (push) Has been skipped
CI / web (push) Successful in 31s
CI / go (push) Successful in 51s
CI / bird2 (push) Successful in 15s
CI / release (push) Successful in 3m48s
Enhanced the MaintenancePoliciesTab by integrating a schedule editor for maintenance policies. Users can now select schedule modes, input custom cron expressions, and dynamically update the schedule preview. This update improves the user interface and experience for managing maintenance schedules.
This commit is contained in:
Denozordec
@@ -0,0 +1,809 @@
|
||||
---
|
||||
description: Architectural planning guidelines for Level 4 Complex System tasks
|
||||
globs: "**/level4/**", "**/architecture/**"
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# ARCHITECTURAL PLANNING FOR LEVEL 4 TASKS
|
||||
|
||||
> **TL;DR:** This document outlines a comprehensive architectural planning approach for Level 4 (Complex System) tasks, ensuring a robust, scalable, and maintainable architecture that aligns with business objectives and technical requirements.
|
||||
|
||||
## 🔍 ARCHITECTURAL PLANNING OVERVIEW
|
||||
|
||||
Level 4 Complex System tasks require thorough architectural planning to ensure the resulting system is robust, scalable, maintainable, and aligned with business objectives. This document outlines a structured approach to architectural planning that systematically addresses key concerns and produces comprehensive documentation.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef phase fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef verification fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
Start([Begin Architectural<br>Planning]) --> Reqs[Analyze<br>Requirements]
|
||||
Reqs --> Context[Define Business<br>Context]
|
||||
Context --> Vision[Establish Vision<br>and Goals]
|
||||
Vision --> Principles[Define Architectural<br>Principles]
|
||||
Principles --> Constraints[Identify<br>Constraints]
|
||||
Constraints --> Explore[Explore<br>Alternatives]
|
||||
Explore --> Evaluate[Evaluate<br>Options]
|
||||
Evaluate --> Decision[Document<br>Decisions]
|
||||
Decision --> Create[Create Architecture<br>Documentation]
|
||||
Create --> Validate[Validate<br>Architecture]
|
||||
Validate --> Communicate[Communicate<br>Architecture]
|
||||
Communicate --> Verification{Architecture<br>Verification}
|
||||
Verification -->|Pass| Complete([Architectural<br>Planning Complete])
|
||||
Verification -->|Fail| Revise[Revise<br>Architecture]
|
||||
Revise --> Verification
|
||||
|
||||
Reqs -.-> ReqDoc((Requirements<br>Document))
|
||||
Context -.-> ConDoc((Context<br>Document))
|
||||
Vision -.-> VisDoc((Vision<br>Document))
|
||||
Principles -.-> PrinDoc((Principles<br>Document))
|
||||
Explore -.-> AltDoc((Alternatives<br>Analysis))
|
||||
Decision -.-> ADR((Architecture<br>Decision Records))
|
||||
Create -.-> ArchDoc((Architecture<br>Documentation))
|
||||
|
||||
class Start,Complete milestone
|
||||
class Reqs,Context,Vision,Principles,Constraints,Explore,Evaluate,Decision,Create,Validate,Communicate,Revise step
|
||||
class Verification verification
|
||||
class ReqDoc,ConDoc,VisDoc,PrinDoc,AltDoc,ADR,ArchDoc artifact
|
||||
```
|
||||
|
||||
## 📋 ARCHITECTURAL PLANNING PRINCIPLES
|
||||
|
||||
1. **Business Alignment**: Architecture must directly support business objectives and user needs.
|
||||
2. **Future-Proofing**: Architecture must anticipate future requirements and facilitate change.
|
||||
3. **Simplicity**: Prefer simple solutions over complex ones when possible.
|
||||
4. **Separation of Concerns**: Systems should be divided into distinct components with minimal overlap.
|
||||
5. **Defense in Depth**: Multiple layers of security controls should be employed.
|
||||
6. **Loose Coupling**: Components should interact through well-defined interfaces with minimal dependencies.
|
||||
7. **High Cohesion**: Related functionality should be grouped together, unrelated functionality separated.
|
||||
8. **Resilience**: Architecture should anticipate failures and provide mechanisms for recovery.
|
||||
9. **Scalability**: Architecture should support growth in users, data, and functionality.
|
||||
10. **Measurability**: Architecture should enable monitoring and measurement of key metrics.
|
||||
|
||||
## 📋 ARCHITECTURAL REQUIREMENTS ANALYSIS
|
||||
|
||||
Begin architectural planning with a comprehensive analysis of requirements:
|
||||
|
||||
### Functional Requirements Analysis
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
classDef req fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef arch fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
|
||||
FR[Functional<br>Requirements] --> USE[Use Cases/<br>User Stories]
|
||||
USE --> DOM[Domain<br>Model]
|
||||
DOM --> COMP[Component<br>Identification]
|
||||
COMP --> INT[Interface<br>Definition]
|
||||
INT --> FLOW[Information<br>Flow]
|
||||
|
||||
class FR,USE,DOM req
|
||||
class COMP,INT,FLOW arch
|
||||
```
|
||||
|
||||
**Template for Functional Requirements Analysis:**
|
||||
|
||||
```markdown
|
||||
## Functional Requirements Analysis
|
||||
|
||||
### Key Use Cases
|
||||
- Use Case 1: [Description]
|
||||
- Use Case 2: [Description]
|
||||
- Use Case 3: [Description]
|
||||
|
||||
### Domain Model
|
||||
- Entity 1: [Description and attributes]
|
||||
- Entity 2: [Description and attributes]
|
||||
- Entity 3: [Description and attributes]
|
||||
- Relationships:
|
||||
- Entity 1 → Entity 2: [Relationship type and description]
|
||||
- Entity 2 → Entity 3: [Relationship type and description]
|
||||
|
||||
### Component Identification
|
||||
- Component 1: [Description and responsibilities]
|
||||
- Component 2: [Description and responsibilities]
|
||||
- Component 3: [Description and responsibilities]
|
||||
|
||||
### Interface Definitions
|
||||
- Interface 1: [Description, methods, parameters]
|
||||
- Interface 2: [Description, methods, parameters]
|
||||
- Interface 3: [Description, methods, parameters]
|
||||
|
||||
### Information Flow
|
||||
- Flow 1: [Description of information exchange]
|
||||
- Flow 2: [Description of information exchange]
|
||||
- Flow 3: [Description of information exchange]
|
||||
```
|
||||
|
||||
### Non-Functional Requirements Analysis
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
classDef req fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef arch fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
|
||||
NFR[Non-Functional<br>Requirements] --> PERF[Performance<br>Requirements]
|
||||
NFR --> SEC[Security<br>Requirements]
|
||||
NFR --> SCAL[Scalability<br>Requirements]
|
||||
NFR --> AVAIL[Availability<br>Requirements]
|
||||
NFR --> MAINT[Maintainability<br>Requirements]
|
||||
|
||||
PERF & SEC & SCAL & AVAIL & MAINT --> ARCH[Architectural<br>Decisions]
|
||||
|
||||
class NFR,PERF,SEC,SCAL,AVAIL,MAINT req
|
||||
class ARCH arch
|
||||
```
|
||||
|
||||
**Template for Non-Functional Requirements Analysis:**
|
||||
|
||||
```markdown
|
||||
## Non-Functional Requirements Analysis
|
||||
|
||||
### Performance Requirements
|
||||
- Response Time: [Requirements]
|
||||
- Throughput: [Requirements]
|
||||
- Resource Utilization: [Requirements]
|
||||
- Architectural Implications: [Implications for architecture]
|
||||
|
||||
### Security Requirements
|
||||
- Authentication: [Requirements]
|
||||
- Authorization: [Requirements]
|
||||
- Data Protection: [Requirements]
|
||||
- Audit/Logging: [Requirements]
|
||||
- Architectural Implications: [Implications for architecture]
|
||||
|
||||
### Scalability Requirements
|
||||
- User Scalability: [Requirements]
|
||||
- Data Scalability: [Requirements]
|
||||
- Transaction Scalability: [Requirements]
|
||||
- Architectural Implications: [Implications for architecture]
|
||||
|
||||
### Availability Requirements
|
||||
- Uptime Requirements: [Requirements]
|
||||
- Fault Tolerance: [Requirements]
|
||||
- Disaster Recovery: [Requirements]
|
||||
- Architectural Implications: [Implications for architecture]
|
||||
|
||||
### Maintainability Requirements
|
||||
- Modularity: [Requirements]
|
||||
- Extensibility: [Requirements]
|
||||
- Testability: [Requirements]
|
||||
- Architectural Implications: [Implications for architecture]
|
||||
```
|
||||
|
||||
## 📋 BUSINESS CONTEXT DOCUMENTATION
|
||||
|
||||
Document the business context to ensure architectural alignment:
|
||||
|
||||
```markdown
|
||||
## Business Context Documentation
|
||||
|
||||
### Business Objectives
|
||||
- Objective 1: [Description]
|
||||
- Objective 2: [Description]
|
||||
- Objective 3: [Description]
|
||||
|
||||
### Key Stakeholders
|
||||
- Stakeholder Group 1: [Description, needs, and concerns]
|
||||
- Stakeholder Group 2: [Description, needs, and concerns]
|
||||
- Stakeholder Group 3: [Description, needs, and concerns]
|
||||
|
||||
### Business Processes
|
||||
- Process 1: [Description and flow]
|
||||
- Process 2: [Description and flow]
|
||||
- Process 3: [Description and flow]
|
||||
|
||||
### Business Constraints
|
||||
- Constraint 1: [Description and impact]
|
||||
- Constraint 2: [Description and impact]
|
||||
- Constraint 3: [Description and impact]
|
||||
|
||||
### Business Metrics
|
||||
- Metric 1: [Description and target]
|
||||
- Metric 2: [Description and target]
|
||||
- Metric 3: [Description and target]
|
||||
|
||||
### Business Risks
|
||||
- Risk 1: [Description, probability, impact, and mitigation]
|
||||
- Risk 2: [Description, probability, impact, and mitigation]
|
||||
- Risk 3: [Description, probability, impact, and mitigation]
|
||||
```
|
||||
|
||||
## 📋 ARCHITECTURAL VISION AND GOALS
|
||||
|
||||
Document the architectural vision and goals:
|
||||
|
||||
```markdown
|
||||
## Architectural Vision and Goals
|
||||
|
||||
### Vision Statement
|
||||
[Concise statement of the architectural vision]
|
||||
|
||||
### Strategic Goals
|
||||
- Goal 1: [Description and success criteria]
|
||||
- Goal 2: [Description and success criteria]
|
||||
- Goal 3: [Description and success criteria]
|
||||
|
||||
### Quality Attributes
|
||||
- Quality Attribute 1: [Description and importance]
|
||||
- Quality Attribute 2: [Description and importance]
|
||||
- Quality Attribute 3: [Description and importance]
|
||||
|
||||
### Technical Roadmap
|
||||
- Short-term (0-6 months): [Key architectural milestones]
|
||||
- Medium-term (6-18 months): [Key architectural milestones]
|
||||
- Long-term (18+ months): [Key architectural milestones]
|
||||
|
||||
### Key Success Indicators
|
||||
- Indicator 1: [Description and measurement]
|
||||
- Indicator 2: [Description and measurement]
|
||||
- Indicator 3: [Description and measurement]
|
||||
```
|
||||
|
||||
## 📋 ARCHITECTURAL PRINCIPLES
|
||||
|
||||
Document architectural principles to guide decision-making:
|
||||
|
||||
```markdown
|
||||
## Architectural Principles
|
||||
|
||||
### Principle 1: [Name]
|
||||
- **Statement**: [Concise statement of the principle]
|
||||
- **Rationale**: [Why this principle is important]
|
||||
- **Implications**: [What this principle means for the architecture]
|
||||
- **Examples**: [Examples of applying this principle]
|
||||
|
||||
### Principle 2: [Name]
|
||||
- **Statement**: [Concise statement of the principle]
|
||||
- **Rationale**: [Why this principle is important]
|
||||
- **Implications**: [What this principle means for the architecture]
|
||||
- **Examples**: [Examples of applying this principle]
|
||||
|
||||
### Principle 3: [Name]
|
||||
- **Statement**: [Concise statement of the principle]
|
||||
- **Rationale**: [Why this principle is important]
|
||||
- **Implications**: [What this principle means for the architecture]
|
||||
- **Examples**: [Examples of applying this principle]
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
## 📋 CONSTRAINTS IDENTIFICATION
|
||||
|
||||
Document constraints that impact architectural decisions:
|
||||
|
||||
```markdown
|
||||
## Architectural Constraints
|
||||
|
||||
### Technical Constraints
|
||||
- Constraint 1: [Description and impact]
|
||||
- Constraint 2: [Description and impact]
|
||||
- Constraint 3: [Description and impact]
|
||||
|
||||
### Organizational Constraints
|
||||
- Constraint 1: [Description and impact]
|
||||
- Constraint 2: [Description and impact]
|
||||
- Constraint 3: [Description and impact]
|
||||
|
||||
### External Constraints
|
||||
- Constraint 1: [Description and impact]
|
||||
- Constraint 2: [Description and impact]
|
||||
- Constraint 3: [Description and impact]
|
||||
|
||||
### Regulatory/Compliance Constraints
|
||||
- Constraint 1: [Description and impact]
|
||||
- Constraint 2: [Description and impact]
|
||||
- Constraint 3: [Description and impact]
|
||||
|
||||
### Resource Constraints
|
||||
- Constraint 1: [Description and impact]
|
||||
- Constraint 2: [Description and impact]
|
||||
- Constraint 3: [Description and impact]
|
||||
```
|
||||
|
||||
## 📋 ARCHITECTURAL ALTERNATIVES EXPLORATION
|
||||
|
||||
Document and evaluate architectural alternatives:
|
||||
|
||||
```markdown
|
||||
## Architectural Alternatives
|
||||
|
||||
### Alternative 1: [Name]
|
||||
- **Description**: [Brief description of the alternative]
|
||||
- **Key Components**:
|
||||
- Component 1: [Description]
|
||||
- Component 2: [Description]
|
||||
- Component 3: [Description]
|
||||
- **Advantages**:
|
||||
- [Advantage 1]
|
||||
- [Advantage 2]
|
||||
- [Advantage 3]
|
||||
- **Disadvantages**:
|
||||
- [Disadvantage 1]
|
||||
- [Disadvantage 2]
|
||||
- [Disadvantage 3]
|
||||
- **Risks**:
|
||||
- [Risk 1]
|
||||
- [Risk 2]
|
||||
- [Risk 3]
|
||||
- **Cost Factors**:
|
||||
- [Cost Factor 1]
|
||||
- [Cost Factor 2]
|
||||
- [Cost Factor 3]
|
||||
- **Alignment with Requirements**:
|
||||
- [How well this alternative addresses requirements]
|
||||
|
||||
### Alternative 2: [Name]
|
||||
...
|
||||
|
||||
### Alternative 3: [Name]
|
||||
...
|
||||
|
||||
## Evaluation Criteria
|
||||
- Criterion 1: [Description and weighting]
|
||||
- Criterion 2: [Description and weighting]
|
||||
- Criterion 3: [Description and weighting]
|
||||
|
||||
## Evaluation Matrix
|
||||
| Criterion | Alternative 1 | Alternative 2 | Alternative 3 |
|
||||
|-----------|---------------|---------------|---------------|
|
||||
| Criterion 1 | Score | Score | Score |
|
||||
| Criterion 2 | Score | Score | Score |
|
||||
| Criterion 3 | Score | Score | Score |
|
||||
| Total | Sum | Sum | Sum |
|
||||
|
||||
## Recommended Approach
|
||||
[Description of the recommended architectural approach with justification]
|
||||
```
|
||||
|
||||
## 📋 ARCHITECTURE DECISION RECORDS (ADRs)
|
||||
|
||||
Document key architectural decisions:
|
||||
|
||||
```markdown
|
||||
# Architecture Decision Record: [Decision Title]
|
||||
|
||||
## Status
|
||||
[Proposed/Accepted/Deprecated/Superseded]
|
||||
|
||||
## Context
|
||||
[Description of the context and problem statement]
|
||||
|
||||
## Decision
|
||||
[Description of the decision made]
|
||||
|
||||
## Consequences
|
||||
[Description of the consequences of the decision]
|
||||
|
||||
## Alternatives Considered
|
||||
[Description of alternatives considered]
|
||||
|
||||
## Related Decisions
|
||||
[References to related decisions]
|
||||
|
||||
## Notes
|
||||
[Additional notes and considerations]
|
||||
```
|
||||
|
||||
## 📋 COMPREHENSIVE ARCHITECTURE DOCUMENTATION
|
||||
|
||||
Create comprehensive architecture documentation:
|
||||
|
||||
### System Context Diagram
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef system fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef external fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
classDef user fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
U1[User 1] --> S[System]
|
||||
U2[User 2] --> S
|
||||
S --> E1[External<br>System 1]
|
||||
S --> E2[External<br>System 2]
|
||||
S --> E3[External<br>System 3]
|
||||
|
||||
class S system
|
||||
class E1,E2,E3 external
|
||||
class U1,U2 user
|
||||
```
|
||||
|
||||
### High-Level Architecture Diagram
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef frontend fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef backend fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
classDef data fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
classDef integration fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
|
||||
U[Users] --> F[Frontend<br>Layer]
|
||||
F --> B[Backend<br>Layer]
|
||||
B --> D[Data<br>Layer]
|
||||
B --> I[Integration<br>Layer]
|
||||
I --> E[External<br>Systems]
|
||||
|
||||
class F frontend
|
||||
class B backend
|
||||
class D data
|
||||
class I integration
|
||||
class U,E external
|
||||
```
|
||||
|
||||
### Component Architecture Diagram
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef ui fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef service fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
classDef data fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
UI[User Interface] --> API[API Gateway]
|
||||
API --> S1[Service 1]
|
||||
API --> S2[Service 2]
|
||||
API --> S3[Service 3]
|
||||
S1 --> DB1[Database 1]
|
||||
S2 --> DB1
|
||||
S2 --> DB2[Database 2]
|
||||
S3 --> DB2
|
||||
|
||||
class UI ui
|
||||
class API,S1,S2,S3 service
|
||||
class DB1,DB2 data
|
||||
```
|
||||
|
||||
### Data Architecture Diagram
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef entity fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef relation fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
|
||||
E1[Entity 1] -- 1:N --> E2[Entity 2]
|
||||
E1 -- 1:1 --> E3[Entity 3]
|
||||
E2 -- N:M --> E4[Entity 4]
|
||||
E3 -- 1:N --> E4
|
||||
|
||||
class E1,E2,E3,E4 entity
|
||||
```
|
||||
|
||||
### Security Architecture Diagram
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef security fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef app fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
|
||||
U[Users] --> WAF[Web Application<br>Firewall]
|
||||
WAF --> LB[Load<br>Balancer]
|
||||
LB --> API[API Gateway]
|
||||
API --> AuthZ[Authorization<br>Service]
|
||||
API --> S1[Service 1]
|
||||
API --> S2[Service 2]
|
||||
AuthZ --> IAM[Identity &<br>Access Management]
|
||||
|
||||
class WAF,AuthZ,IAM security
|
||||
class API,S1,S2 app
|
||||
class U,LB external
|
||||
```
|
||||
|
||||
### Deployment Architecture Diagram
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef env fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef component fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
|
||||
subgraph Production
|
||||
LB[Load Balancer] --> W1[Web Server 1]
|
||||
LB --> W2[Web Server 2]
|
||||
W1 & W2 --> A1[App Server 1]
|
||||
W1 & W2 --> A2[App Server 2]
|
||||
A1 & A2 --> DB[Database<br>Cluster]
|
||||
end
|
||||
|
||||
class Production env
|
||||
class LB,W1,W2,A1,A2,DB component
|
||||
```
|
||||
|
||||
### Architecture Documentation Template
|
||||
|
||||
```markdown
|
||||
# System Architecture Document
|
||||
|
||||
## 1. Introduction
|
||||
- **Purpose**: [Purpose of the architecture]
|
||||
- **Scope**: [Scope of the architecture]
|
||||
- **Audience**: [Intended audience for the document]
|
||||
- **References**: [Related documents and references]
|
||||
|
||||
## 2. System Context
|
||||
- **System Purpose**: [Brief description of system purpose]
|
||||
- **Context Diagram**: [System context diagram]
|
||||
- **External Systems**: [Description of external systems and interfaces]
|
||||
- **User Types**: [Description of user types and interactions]
|
||||
|
||||
## 3. Architecture Overview
|
||||
- **Architecture Style**: [Description of the architectural style/pattern]
|
||||
- **High-Level Architecture**: [High-level architecture diagram]
|
||||
- **Key Components**: [Overview of key components]
|
||||
- **Technology Stack**: [Overview of technology stack]
|
||||
|
||||
## 4. Component Architecture
|
||||
- **Component Diagram**: [Component architecture diagram]
|
||||
- **Component Descriptions**:
|
||||
- Component 1: [Description, responsibilities, interfaces]
|
||||
- Component 2: [Description, responsibilities, interfaces]
|
||||
- Component 3: [Description, responsibilities, interfaces]
|
||||
- **Component Interactions**: [Description of component interactions]
|
||||
- **API Specifications**: [Overview of key APIs]
|
||||
|
||||
## 5. Data Architecture
|
||||
- **Data Model**: [Data architecture diagram]
|
||||
- **Entity Descriptions**:
|
||||
- Entity 1: [Description, attributes, relationships]
|
||||
- Entity 2: [Description, attributes, relationships]
|
||||
- Entity 3: [Description, attributes, relationships]
|
||||
- **Data Storage**: [Description of data storage approaches]
|
||||
- **Data Access**: [Description of data access patterns]
|
||||
- **Data Migration**: [Overview of data migration approach]
|
||||
|
||||
## 6. Security Architecture
|
||||
- **Security Model**: [Security architecture diagram]
|
||||
- **Authentication**: [Authentication approach]
|
||||
- **Authorization**: [Authorization approach]
|
||||
- **Data Protection**: [Data protection mechanisms]
|
||||
- **Security Controls**: [Key security controls]
|
||||
- **Audit and Logging**: [Audit and logging approach]
|
||||
|
||||
## 7. Deployment Architecture
|
||||
- **Deployment Model**: [Deployment architecture diagram]
|
||||
- **Environment Descriptions**:
|
||||
- Environment 1: [Description and configuration]
|
||||
- Environment 2: [Description and configuration]
|
||||
- Environment 3: [Description and configuration]
|
||||
- **Infrastructure Requirements**: [Infrastructure requirements]
|
||||
- **Scaling Approach**: [Scaling approach]
|
||||
|
||||
## 8. Quality Attributes
|
||||
- **Performance**: [Performance characteristics and mechanisms]
|
||||
- **Scalability**: [Scalability approach]
|
||||
- **Availability**: [Availability approach]
|
||||
- **Maintainability**: [Maintainability approach]
|
||||
- **Reliability**: [Reliability approach]
|
||||
- **Portability**: [Portability considerations]
|
||||
|
||||
## 9. Cross-Cutting Concerns
|
||||
- **Logging**: [Logging approach]
|
||||
- **Error Handling**: [Error handling approach]
|
||||
- **Monitoring**: [Monitoring approach]
|
||||
- **Configuration Management**: [Configuration management approach]
|
||||
- **Internationalization**: [Internationalization approach]
|
||||
|
||||
## 10. Architecture Decisions
|
||||
- [References to Architecture Decision Records]
|
||||
|
||||
## 11. Risks and Mitigations
|
||||
- Risk 1: [Description and mitigation]
|
||||
- Risk 2: [Description and mitigation]
|
||||
- Risk 3: [Description and mitigation]
|
||||
|
||||
## 12. Glossary
|
||||
- Term 1: [Definition]
|
||||
- Term 2: [Definition]
|
||||
- Term 3: [Definition]
|
||||
```
|
||||
|
||||
## 📋 ARCHITECTURE VALIDATION
|
||||
|
||||
Validate architecture against requirements and principles:
|
||||
|
||||
```markdown
|
||||
## Architecture Validation
|
||||
|
||||
### Requirements Coverage
|
||||
- Requirement 1: [Covered/Partially Covered/Not Covered] - [Explanation]
|
||||
- Requirement 2: [Covered/Partially Covered/Not Covered] - [Explanation]
|
||||
- Requirement 3: [Covered/Partially Covered/Not Covered] - [Explanation]
|
||||
|
||||
### Principles Alignment
|
||||
- Principle 1: [Aligned/Partially Aligned/Not Aligned] - [Explanation]
|
||||
- Principle 2: [Aligned/Partially Aligned/Not Aligned] - [Explanation]
|
||||
- Principle 3: [Aligned/Partially Aligned/Not Aligned] - [Explanation]
|
||||
|
||||
### Quality Attribute Scenarios
|
||||
- Scenario 1: [Description and validation]
|
||||
- Scenario 2: [Description and validation]
|
||||
- Scenario 3: [Description and validation]
|
||||
|
||||
### Architecture Review Findings
|
||||
- Finding 1: [Description and resolution]
|
||||
- Finding 2: [Description and resolution]
|
||||
- Finding 3: [Description and resolution]
|
||||
|
||||
### Risk Assessment
|
||||
- Risk 1: [Description, probability, impact, and mitigation]
|
||||
- Risk 2: [Description, probability, impact, and mitigation]
|
||||
- Risk 3: [Description, probability, impact, and mitigation]
|
||||
|
||||
### Validation Outcome
|
||||
[Summary of validation outcome and next steps]
|
||||
```
|
||||
|
||||
## 📋 ARCHITECTURE COMMUNICATION
|
||||
|
||||
Communicate architecture to stakeholders:
|
||||
|
||||
```markdown
|
||||
## Architecture Communication Plan
|
||||
|
||||
### Key Stakeholders
|
||||
- Stakeholder Group 1: [Communication needs]
|
||||
- Stakeholder Group 2: [Communication needs]
|
||||
- Stakeholder Group 3: [Communication needs]
|
||||
|
||||
### Communication Materials
|
||||
- **Executive Summary**: [Purpose and audience]
|
||||
- **Technical Reference**: [Purpose and audience]
|
||||
- **Developer Guide**: [Purpose and audience]
|
||||
- **Operations Guide**: [Purpose and audience]
|
||||
|
||||
### Communication Schedule
|
||||
- Event 1: [Date, audience, purpose]
|
||||
- Event 2: [Date, audience, purpose]
|
||||
- Event 3: [Date, audience, purpose]
|
||||
|
||||
### Feedback Mechanism
|
||||
[Description of how feedback will be collected and incorporated]
|
||||
```
|
||||
|
||||
## 📋 MEMORY BANK INTEGRATION
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef memfile fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef process fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
|
||||
Architecture[Architectural<br>Planning] --> PB[projectbrief.md]
|
||||
Architecture --> PC[productContext.md]
|
||||
Architecture --> SP[systemPatterns.md]
|
||||
Architecture --> TC[techContext.md]
|
||||
|
||||
PB & PC & SP & TC --> MBI[Memory Bank<br>Integration]
|
||||
MBI --> Next[Implementation<br>Phase]
|
||||
|
||||
class PB,PC,SP,TC memfile
|
||||
class Architecture,MBI,Next process
|
||||
```
|
||||
|
||||
### Memory Bank Updates
|
||||
|
||||
Update the following Memory Bank files during architectural planning:
|
||||
|
||||
1. **projectbrief.md**
|
||||
- Update with architectural vision
|
||||
- Document high-level architecture approach
|
||||
- Link to architecture documentation
|
||||
|
||||
2. **productContext.md**
|
||||
- Update with business context documentation
|
||||
- Document key stakeholder requirements
|
||||
- Capture business drivers for architectural decisions
|
||||
|
||||
3. **systemPatterns.md**
|
||||
- Document architectural patterns and styles chosen
|
||||
- Capture key architecture decisions with rationales
|
||||
- Document technical patterns to be used
|
||||
|
||||
4. **techContext.md**
|
||||
- Update with technology stack decisions
|
||||
- Document technical constraints and considerations
|
||||
- Capture integration approaches
|
||||
|
||||
## 📋 ARCHITECTURAL PLANNING VERIFICATION CHECKLIST
|
||||
|
||||
```
|
||||
✓ ARCHITECTURAL PLANNING VERIFICATION CHECKLIST
|
||||
|
||||
Requirements Analysis
|
||||
- Functional requirements analyzed? [YES/NO]
|
||||
- Non-functional requirements analyzed? [YES/NO]
|
||||
- Domain model created? [YES/NO]
|
||||
- Component identification completed? [YES/NO]
|
||||
|
||||
Business Context
|
||||
- Business objectives documented? [YES/NO]
|
||||
- Key stakeholders identified? [YES/NO]
|
||||
- Business processes documented? [YES/NO]
|
||||
- Business constraints identified? [YES/NO]
|
||||
|
||||
Vision and Goals
|
||||
- Architectural vision stated? [YES/NO]
|
||||
- Strategic goals defined? [YES/NO]
|
||||
- Quality attributes identified? [YES/NO]
|
||||
- Technical roadmap created? [YES/NO]
|
||||
|
||||
Architectural Principles
|
||||
- Core principles defined? [YES/NO]
|
||||
- Principles have clear rationales? [YES/NO]
|
||||
- Implications of principles documented? [YES/NO]
|
||||
- Examples of applying principles provided? [YES/NO]
|
||||
|
||||
Constraints Identification
|
||||
- Technical constraints documented? [YES/NO]
|
||||
- Organizational constraints documented? [YES/NO]
|
||||
- External constraints documented? [YES/NO]
|
||||
- Regulatory constraints documented? [YES/NO]
|
||||
|
||||
Alternatives Exploration
|
||||
- Multiple alternatives identified? [YES/NO]
|
||||
- Alternatives evaluated against criteria? [YES/NO]
|
||||
- Advantages and disadvantages documented? [YES/NO]
|
||||
- Recommended approach justified? [YES/NO]
|
||||
|
||||
Architecture Documentation
|
||||
- System context documented? [YES/NO]
|
||||
- High-level architecture documented? [YES/NO]
|
||||
- Component architecture documented? [YES/NO]
|
||||
- Data architecture documented? [YES/NO]
|
||||
- Security architecture documented? [YES/NO]
|
||||
- Deployment architecture documented? [YES/NO]
|
||||
|
||||
Architecture Validation
|
||||
- Requirements coverage validated? [YES/NO]
|
||||
- Principles alignment checked? [YES/NO]
|
||||
- Quality attribute scenarios assessed? [YES/NO]
|
||||
- Architecture review conducted? [YES/NO]
|
||||
|
||||
Memory Bank Integration
|
||||
- projectbrief.md updated? [YES/NO]
|
||||
- productContext.md updated? [YES/NO]
|
||||
- systemPatterns.md updated? [YES/NO]
|
||||
- techContext.md updated? [YES/NO]
|
||||
```
|
||||
|
||||
## 📋 MINIMAL MODE ARCHITECTURE PLANNING FORMAT
|
||||
|
||||
For situations requiring a more compact architectural planning approach:
|
||||
|
||||
```markdown
|
||||
## Level 4 Architecture Planning: [System Name]
|
||||
|
||||
### System Context
|
||||
- **Purpose**: [Brief description of system purpose]
|
||||
- **Users**: [Primary users]
|
||||
- **External Systems**: [Key external systems]
|
||||
|
||||
### Key Architectural Decisions
|
||||
- **Architecture Style**: [Chosen style with brief rationale]
|
||||
- **Component Structure**: [Key components with brief descriptions]
|
||||
- **Data Model**: [Brief description of data approach]
|
||||
- **Technical Stack**: [Key technologies]
|
||||
|
||||
### Quality Attributes
|
||||
- **Performance**: [Brief description of approach]
|
||||
- **Security**: [Brief description of approach]
|
||||
- **Scalability**: [Brief description of approach]
|
||||
- **Maintainability**: [Brief description of approach]
|
||||
|
||||
### Architecture Diagram
|
||||
[Simple architecture diagram]
|
||||
|
||||
### Key Risks and Mitigations
|
||||
- **Risk 1**: [Brief description] - **Mitigation**: [Brief approach]
|
||||
- **Risk 2**: [Brief description] - **Mitigation**: [Brief approach]
|
||||
|
||||
### Memory Bank Updates
|
||||
- [Brief description of updates needed]
|
||||
```
|
||||
|
||||
## 🚨 ARCHITECTURAL PLANNING ENFORCEMENT PRINCIPLE
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ ARCHITECTURAL PLANNING IS MANDATORY for Level 4 │
|
||||
│ tasks. Implementation CANNOT begin until │
|
||||
│ architectural planning is complete and approved. │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
@@ -0,0 +1,684 @@
|
||||
---
|
||||
description: Comprehensive archiving approach for Level 4 Complex System tasks
|
||||
globs: "**/level4/**", "**/archive/**"
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# COMPREHENSIVE ARCHIVING FOR LEVEL 4 TASKS
|
||||
|
||||
> **TL;DR:** This document outlines a comprehensive archiving approach for Level 4 (Complex System) tasks, ensuring all system knowledge, decisions, implementation details, and lessons learned are preserved for future reference and reuse.
|
||||
|
||||
## 🔍 COMPREHENSIVE ARCHIVING OVERVIEW
|
||||
|
||||
Level 4 Complex System tasks require thorough archiving to preserve system knowledge, design decisions, implementation details, and lessons learned. This systematic archiving process ensures that the organization maintains institutional knowledge and enables future teams to understand, maintain, and extend the system.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef phase fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef verification fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
Start([Begin Archiving<br>Process]) --> Template[Load Comprehensive<br>Archive Template]
|
||||
Template --> RefDoc[Review Reflection<br>Document]
|
||||
RefDoc --> SysDoc[Create System<br>Documentation]
|
||||
SysDoc --> ArchDoc[Document Architecture<br>and Design]
|
||||
ArchDoc --> ImplDoc[Document Implementation<br>Details]
|
||||
ImplDoc --> APIDoc[Create API<br>Documentation]
|
||||
APIDoc --> DataDoc[Document Data<br>Models and Schemas]
|
||||
DataDoc --> SecDoc[Document Security<br>Measures]
|
||||
SecDoc --> TestDoc[Document Testing<br>Procedures and Results]
|
||||
TestDoc --> DeployDoc[Document Deployment<br>Procedures]
|
||||
DeployDoc --> OpDoc[Create Operational<br>Documentation]
|
||||
OpDoc --> KnowledgeDoc[Create Knowledge<br>Transfer Documentation]
|
||||
KnowledgeDoc --> CrossRef[Create Cross-Reference<br>Documentation]
|
||||
CrossRef --> Archive[Archive All<br>Project Materials]
|
||||
Archive --> UpdateMB[Update Memory<br>Bank]
|
||||
UpdateMB --> Verification{Archiving<br>Verification}
|
||||
Verification -->|Pass| Complete([Archiving<br>Complete])
|
||||
Verification -->|Fail| Revise[Revise<br>Archiving]
|
||||
Revise --> Verification
|
||||
|
||||
Template -.-> AT((Archive<br>Template))
|
||||
SysDoc -.-> SD((System<br>Documentation))
|
||||
ArchDoc -.-> AD((Architecture<br>Documentation))
|
||||
ImplDoc -.-> ID((Implementation<br>Documentation))
|
||||
APIDoc & DataDoc -.-> IntDoc((Interface<br>Documentation))
|
||||
TestDoc & DeployDoc & OpDoc -.-> OpDocs((Operational<br>Documentation))
|
||||
|
||||
class Start,Complete milestone
|
||||
class Template,RefDoc,SysDoc,ArchDoc,ImplDoc,APIDoc,DataDoc,SecDoc,TestDoc,DeployDoc,OpDoc,KnowledgeDoc,CrossRef,Archive,UpdateMB step
|
||||
class Verification verification
|
||||
class AT,SD,AD,ID,IntDoc,OpDocs artifact
|
||||
```
|
||||
|
||||
## 📋 ARCHIVE TEMPLATE STRUCTURE
|
||||
|
||||
### 1. System Overview
|
||||
|
||||
```markdown
|
||||
## System Overview
|
||||
|
||||
### System Purpose and Scope
|
||||
[Comprehensive description of the system purpose, scope, and business context]
|
||||
|
||||
### System Architecture
|
||||
[Summary of the architecture, including diagrams, patterns, and key design decisions]
|
||||
|
||||
### Key Components
|
||||
- Component 1: [Description and purpose]
|
||||
- Component 2: [Description and purpose]
|
||||
- Component 3: [Description and purpose]
|
||||
|
||||
### Integration Points
|
||||
[Description of all internal and external integration points]
|
||||
|
||||
### Technology Stack
|
||||
[Comprehensive list of all technologies, frameworks, and tools used]
|
||||
|
||||
### Deployment Environment
|
||||
[Description of the deployment environment, infrastructure, and configuration]
|
||||
```
|
||||
|
||||
### 2. Requirements and Design Documentation
|
||||
|
||||
```markdown
|
||||
## Requirements and Design Documentation
|
||||
|
||||
### Business Requirements
|
||||
[Comprehensive list of business requirements with traceability]
|
||||
|
||||
### Functional Requirements
|
||||
[Detailed functional requirements with implementation mapping]
|
||||
|
||||
### Non-Functional Requirements
|
||||
[Non-functional requirements with implementation approaches]
|
||||
|
||||
### Architecture Decision Records
|
||||
[Collection of all architecture decision records (ADRs)]
|
||||
|
||||
### Design Patterns Used
|
||||
[Catalog of all design patterns with usage examples]
|
||||
|
||||
### Design Constraints
|
||||
[Documentation of all design constraints and their impact]
|
||||
|
||||
### Design Alternatives Considered
|
||||
[Summary of alternatives considered and reasons for final selections]
|
||||
```
|
||||
|
||||
### 3. Implementation Documentation
|
||||
|
||||
```markdown
|
||||
## Implementation Documentation
|
||||
|
||||
### Component Implementation Details
|
||||
- **Component 1**:
|
||||
- **Purpose**: [Component purpose]
|
||||
- **Implementation approach**: [Implementation details]
|
||||
- **Key classes/modules**: [List with descriptions]
|
||||
- **Dependencies**: [Internal and external dependencies]
|
||||
- **Special considerations**: [Important notes]
|
||||
|
||||
- **Component 2**:
|
||||
- **Purpose**: [Component purpose]
|
||||
- **Implementation approach**: [Implementation details]
|
||||
- **Key classes/modules**: [List with descriptions]
|
||||
- **Dependencies**: [Internal and external dependencies]
|
||||
- **Special considerations**: [Important notes]
|
||||
|
||||
### Key Files and Components Affected (from tasks.md)
|
||||
[Summary or direct copy of file/component checklists from the original tasks.md for this project. This provides a quick reference to the scope of changes at a component/file level.]
|
||||
|
||||
### Algorithms and Complex Logic
|
||||
[Documentation of key algorithms and complex business logic]
|
||||
|
||||
### Third-Party Integrations
|
||||
[Details of all third-party integrations including APIs and libraries]
|
||||
|
||||
### Configuration Parameters
|
||||
[Complete listing of all configuration parameters and their purpose]
|
||||
|
||||
### Build and Packaging Details
|
||||
[Documentation of build process, packaging, and artifacts]
|
||||
```
|
||||
|
||||
### 4. API Documentation
|
||||
|
||||
```markdown
|
||||
## API Documentation
|
||||
|
||||
### API Overview
|
||||
[High-level overview of all APIs (internal and external)]
|
||||
|
||||
### API Endpoints
|
||||
- **Endpoint 1**:
|
||||
- **URL/Path**: [Endpoint URL or path]
|
||||
- **Method**: [HTTP method]
|
||||
- **Purpose**: [Purpose of the endpoint]
|
||||
- **Request Format**: [Request format with examples]
|
||||
- **Response Format**: [Response format with examples]
|
||||
- **Error Codes**: [Possible error codes and meanings]
|
||||
- **Security**: [Security considerations]
|
||||
- **Rate Limits**: [Any rate limits]
|
||||
- **Notes**: [Additional notes]
|
||||
|
||||
- **Endpoint 2**:
|
||||
- **URL/Path**: [Endpoint URL or path]
|
||||
- **Method**: [HTTP method]
|
||||
- **Purpose**: [Purpose of the endpoint]
|
||||
- **Request Format**: [Request format with examples]
|
||||
- **Response Format**: [Response format with examples]
|
||||
- **Error Codes**: [Possible error codes and meanings]
|
||||
- **Security**: [Security considerations]
|
||||
- **Rate Limits**: [Any rate limits]
|
||||
- **Notes**: [Additional notes]
|
||||
|
||||
### API Authentication
|
||||
[Authentication methods and implementation details]
|
||||
|
||||
### API Versioning Strategy
|
||||
[Versioning approach and migration strategy]
|
||||
|
||||
### SDK or Client Libraries
|
||||
[Available SDKs or client libraries with usage examples]
|
||||
```
|
||||
|
||||
### 5. Data Model and Schema Documentation
|
||||
|
||||
```markdown
|
||||
## Data Model and Schema Documentation
|
||||
|
||||
### Data Model Overview
|
||||
[High-level overview of the data model with entity relationship diagrams]
|
||||
|
||||
### Database Schema
|
||||
[Detailed database schema with tables, columns, and relationships]
|
||||
|
||||
### Data Dictionary
|
||||
[Comprehensive data dictionary with all entities and attributes]
|
||||
|
||||
### Data Validation Rules
|
||||
[Data validation rules and enforcement mechanisms]
|
||||
|
||||
### Data Migration Procedures
|
||||
[Procedures for data migration and version management]
|
||||
|
||||
### Data Archiving Strategy
|
||||
[Strategy for data archiving and retention]
|
||||
```
|
||||
|
||||
### 6. Security Documentation
|
||||
|
||||
```markdown
|
||||
## Security Documentation
|
||||
|
||||
### Security Architecture
|
||||
[Overview of security architecture and design principles]
|
||||
|
||||
### Authentication and Authorization
|
||||
[Detailed implementation of authentication and authorization]
|
||||
|
||||
### Data Protection Measures
|
||||
[Measures implemented to protect sensitive data]
|
||||
|
||||
### Security Controls
|
||||
[Technical and procedural security controls]
|
||||
|
||||
### Vulnerability Management
|
||||
[Approach to vulnerability management and patching]
|
||||
|
||||
### Security Testing Results
|
||||
[Summary of security testing and assessments]
|
||||
|
||||
### Compliance Considerations
|
||||
[Regulatory and compliance considerations addressed]
|
||||
```
|
||||
|
||||
### 7. Testing Documentation
|
||||
|
||||
```markdown
|
||||
## Testing Documentation
|
||||
|
||||
### Test Strategy
|
||||
[Overall testing strategy and approach]
|
||||
|
||||
### Test Cases
|
||||
[Catalog of test cases with expected results]
|
||||
|
||||
### Automated Tests
|
||||
[Documentation of automated tests and frameworks]
|
||||
|
||||
### Performance Test Results
|
||||
[Results of performance testing with benchmarks]
|
||||
|
||||
### Security Test Results
|
||||
[Results of security testing with findings]
|
||||
|
||||
### User Acceptance Testing
|
||||
[UAT approach, scenarios, and results]
|
||||
|
||||
### Known Issues and Limitations
|
||||
[Documentation of known issues and system limitations]
|
||||
```
|
||||
|
||||
### 8. Deployment Documentation
|
||||
|
||||
```markdown
|
||||
## Deployment Documentation
|
||||
|
||||
### Deployment Architecture
|
||||
[Detailed deployment architecture with diagrams]
|
||||
|
||||
### Environment Configuration
|
||||
[Configuration details for all environments]
|
||||
|
||||
### Deployment Procedures
|
||||
[Step-by-step deployment procedures]
|
||||
|
||||
### Configuration Management
|
||||
[Configuration management approach and tools]
|
||||
|
||||
### Release Management
|
||||
[Release management process and procedures]
|
||||
|
||||
### Rollback Procedures
|
||||
[Procedures for rolling back deployments]
|
||||
|
||||
### Monitoring and Alerting
|
||||
[Monitoring setup, metrics, and alerting configuration]
|
||||
```
|
||||
|
||||
### 9. Operational Documentation
|
||||
|
||||
```markdown
|
||||
## Operational Documentation
|
||||
|
||||
### Operating Procedures
|
||||
[Day-to-day operational procedures]
|
||||
|
||||
### Maintenance Tasks
|
||||
[Routine maintenance tasks and schedules]
|
||||
|
||||
### Troubleshooting Guide
|
||||
[Guide for troubleshooting common issues]
|
||||
|
||||
### Backup and Recovery
|
||||
[Backup and recovery procedures]
|
||||
|
||||
### Disaster Recovery
|
||||
[Disaster recovery plan and procedures]
|
||||
|
||||
### Performance Tuning
|
||||
[Performance tuning guidelines and procedures]
|
||||
|
||||
### SLAs and Metrics
|
||||
[Service level agreements and key performance metrics]
|
||||
```
|
||||
|
||||
### 10. Knowledge Transfer Documentation
|
||||
|
||||
```markdown
|
||||
## Knowledge Transfer Documentation
|
||||
|
||||
### System Overview for New Team Members
|
||||
[Concise system overview for onboarding]
|
||||
|
||||
### Key Concepts and Terminology
|
||||
[Glossary of key concepts and terminology]
|
||||
|
||||
### Common Tasks and Procedures
|
||||
[Guide to common tasks and procedures]
|
||||
|
||||
### Frequently Asked Questions
|
||||
[FAQs for system users and maintainers]
|
||||
|
||||
### Training Materials
|
||||
[Training materials for different roles]
|
||||
|
||||
### Support Escalation Process
|
||||
[Process for escalating support issues]
|
||||
|
||||
### Further Reading and Resources
|
||||
[Additional resources and documentation]
|
||||
```
|
||||
|
||||
### 11. Project History and Learnings
|
||||
|
||||
```markdown
|
||||
## Project History and Learnings
|
||||
|
||||
### Project Timeline
|
||||
[Summary of the project timeline and key milestones]
|
||||
|
||||
### Key Decisions and Rationale
|
||||
[Record of key decisions and their rationale]
|
||||
|
||||
### Challenges and Solutions
|
||||
[Documentation of challenges faced and how they were addressed]
|
||||
|
||||
### Lessons Learned
|
||||
[Key lessons learned that might benefit future projects]
|
||||
|
||||
### Performance Against Objectives
|
||||
[Assessment of performance against original objectives]
|
||||
|
||||
### Future Enhancements
|
||||
[Potential future enhancements and extensions]
|
||||
```
|
||||
|
||||
## 📋 ARCHIVING PROCESS
|
||||
|
||||
### 1. Preparation
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef step fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
|
||||
Start([Begin Archive<br>Preparation]) --> Template[Load Archive<br>Template]
|
||||
Template --> Review[Review Project<br>Documentation]
|
||||
Review --> Identify[Identify All<br>Artifacts]
|
||||
Identify --> Gather[Gather All<br>Materials]
|
||||
Gather --> Organize[Organize<br>Materials]
|
||||
Organize --> Plan[Create Archiving<br>Plan]
|
||||
Plan --> Resources[Allocate<br>Resources]
|
||||
Resources --> Complete([Preparation<br>Complete])
|
||||
|
||||
Template -.-> AT((Archive<br>Template))
|
||||
Review -.-> ProjDocs((Project<br>Documentation))
|
||||
Identify -.-> ArtList((Artifact<br>List))
|
||||
Plan -.-> ArchPlan((Archiving<br>Plan))
|
||||
|
||||
class Start,Complete milestone
|
||||
class Template,Review,Identify,Gather,Organize,Plan,Resources step
|
||||
class AT,ProjDocs,ArtList,ArchPlan artifact
|
||||
```
|
||||
|
||||
**Key Preparation Steps:**
|
||||
1. Load the comprehensive archive template
|
||||
2. Review all project documentation including reflection document
|
||||
3. Identify all artifacts to be archived
|
||||
4. Gather all materials from various sources
|
||||
5. Organize materials according to the archive structure
|
||||
6. Create a detailed archiving plan
|
||||
7. Allocate resources for the archiving process
|
||||
|
||||
### 2. Documentation Creation
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef step fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
|
||||
Start([Begin Documentation<br>Creation]) --> System[Create System<br>Documentation]
|
||||
System --> Req[Create Requirements<br>and Design Documentation]
|
||||
Req --> Impl[Create Implementation<br>Documentation]
|
||||
Impl --> API[Create API<br>Documentation]
|
||||
API --> Data[Create Data Model<br>Documentation]
|
||||
Data --> Security[Create Security<br>Documentation]
|
||||
Security --> Test[Create Testing<br>Documentation]
|
||||
Test --> Deploy[Create Deployment<br>Documentation]
|
||||
Deploy --> Ops[Create Operational<br>Documentation]
|
||||
Ops --> Knowledge[Create Knowledge Transfer<br>Documentation]
|
||||
Knowledge --> History[Create Project History<br>Documentation]
|
||||
History --> Review[Review All<br>Documentation]
|
||||
Review --> Complete([Documentation<br>Creation Complete])
|
||||
|
||||
System -.-> SysDoc((System<br>Documentation))
|
||||
Req -.-> ReqDoc((Requirements<br>Documentation))
|
||||
Impl -.-> ImplDoc((Implementation<br>Documentation))
|
||||
API -.-> APIDoc((API<br>Documentation))
|
||||
Data -.-> DataDoc((Data Model<br>Documentation))
|
||||
Security -.-> SecDoc((Security<br>Documentation))
|
||||
Test -.-> TestDoc((Testing<br>Documentation))
|
||||
Deploy -.-> DeployDoc((Deployment<br>Documentation))
|
||||
Ops -.-> OpsDoc((Operational<br>Documentation))
|
||||
Knowledge -.-> KnowDoc((Knowledge Transfer<br>Documentation))
|
||||
History -.-> HistDoc((Project History<br>Documentation))
|
||||
|
||||
class Start,Complete milestone
|
||||
class System,Req,Impl,API,Data,Security,Test,Deploy,Ops,Knowledge,History,Review step
|
||||
class SysDoc,ReqDoc,ImplDoc,APIDoc,DataDoc,SecDoc,TestDoc,DeployDoc,OpsDoc,KnowDoc,HistDoc artifact
|
||||
```
|
||||
|
||||
**Key Documentation Steps:**
|
||||
1. Create comprehensive system documentation
|
||||
2. Document requirements and design decisions
|
||||
3. Document implementation details for all components
|
||||
4. Create complete API documentation
|
||||
5. Document data models and schemas
|
||||
6. Document security measures and controls
|
||||
7. Create thorough testing documentation
|
||||
8. Document deployment procedures
|
||||
9. Create operational documentation
|
||||
10. Prepare knowledge transfer documentation
|
||||
11. Document project history and learnings
|
||||
12. Review all documentation for completeness and accuracy
|
||||
|
||||
### 3. Archiving and Integration
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef step fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef verification fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
Start([Begin Archiving<br>and Integration]) --> Consolidate[Consolidate All<br>Documentation]
|
||||
Consolidate --> CrossRef[Create Cross-Reference<br>Index]
|
||||
CrossRef --> Version[Version All<br>Documentation]
|
||||
Version --> Archive[Archive in<br>Repository]
|
||||
Archive --> UpdateMB[Update Memory<br>Bank]
|
||||
UpdateMB --> AccessControl[Establish Access<br>Controls]
|
||||
AccessControl --> Announce[Announce<br>Availability]
|
||||
Announce --> Verification{Archiving<br>Verification}
|
||||
Verification -->|Pass| Complete([Archiving<br>Complete])
|
||||
Verification -->|Fail| Revise[Revise<br>Archiving]
|
||||
Revise --> Verification
|
||||
|
||||
Consolidate -.-> AllDocs((Consolidated<br>Documentation))
|
||||
CrossRef -.-> Index((Cross-Reference<br>Index))
|
||||
Archive -.-> Repo((Archive<br>Repository))
|
||||
UpdateMB -.-> MB((Updated Memory<br>Bank))
|
||||
|
||||
class Start,Complete milestone
|
||||
class Consolidate,CrossRef,Version,Archive,UpdateMB,AccessControl,Announce,Revise step
|
||||
class Verification verification
|
||||
class AllDocs,Index,Repo,MB artifact
|
||||
```
|
||||
|
||||
**Key Archiving Steps:**
|
||||
1. Consolidate all documentation into a cohesive package
|
||||
2. Create a cross-reference index linking all documentation
|
||||
3. Version all documentation appropriately
|
||||
4. Archive in the designated repository
|
||||
5. Update Memory Bank with relevant information
|
||||
6. Establish appropriate access controls
|
||||
7. Announce availability to relevant stakeholders
|
||||
8. Verify archiving completeness and accessibility
|
||||
|
||||
## 📋 MEMORY BANK INTEGRATION
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef memfile fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef process fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
|
||||
Archiving[Comprehensive<br>Archiving] --> PB[projectbrief.md]
|
||||
Archiving --> PC[productContext.md]
|
||||
Archiving --> AC[activeContext.md]
|
||||
Archiving --> SP[systemPatterns.md]
|
||||
Archiving --> TC[techContext.md]
|
||||
Archiving --> P[progress.md]
|
||||
|
||||
PB & PC & AC & SP & TC & P --> MBI[Memory Bank<br>Integration]
|
||||
MBI --> Next[Repository of<br>Knowledge]
|
||||
|
||||
class PB,PC,AC,SP,TC,P memfile
|
||||
class Archiving,MBI,Next process
|
||||
```
|
||||
|
||||
### Memory Bank Updates
|
||||
|
||||
Specific updates to make to Memory Bank files:
|
||||
|
||||
1. **projectbrief.md**
|
||||
- Update with final system description
|
||||
- Document completion status
|
||||
- Include links to archived documentation
|
||||
|
||||
2. **productContext.md**
|
||||
- Update with final business context
|
||||
- Document business value delivered
|
||||
- Include links to requirements documentation
|
||||
|
||||
3. **activeContext.md**
|
||||
- Update with system status (completed)
|
||||
- Document handover information
|
||||
- Include links to operational documentation
|
||||
|
||||
4. **systemPatterns.md**
|
||||
- Update with final architecture patterns
|
||||
- Document successful implementation patterns
|
||||
- Include links to architecture documentation
|
||||
|
||||
5. **techContext.md**
|
||||
- Update with final technology stack
|
||||
- Document integration points
|
||||
- Include links to technical documentation
|
||||
|
||||
6. **progress.md**
|
||||
- Update with final project status
|
||||
- Document completion metrics
|
||||
- Include links to project history documentation
|
||||
|
||||
## 📋 ARCHIVING VERIFICATION CHECKLIST
|
||||
|
||||
```
|
||||
✓ ARCHIVING VERIFICATION CHECKLIST
|
||||
|
||||
System Documentation
|
||||
- System overview complete? [YES/NO]
|
||||
- Architecture documented with diagrams? [YES/NO]
|
||||
- Key components documented? [YES/NO]
|
||||
- Integration points documented? [YES/NO]
|
||||
|
||||
Requirements and Design
|
||||
- Business requirements documented? [YES/NO]
|
||||
- Functional requirements documented? [YES/NO]
|
||||
- Architecture decisions documented? [YES/NO]
|
||||
- Design patterns documented? [YES/NO]
|
||||
|
||||
Implementation
|
||||
- Component implementation details documented? [YES/NO]
|
||||
- Key algorithms documented? [YES/NO]
|
||||
- Third-party integrations documented? [YES/NO]
|
||||
- Configuration parameters documented? [YES/NO]
|
||||
|
||||
API Documentation
|
||||
- API endpoints documented? [YES/NO]
|
||||
- Request/response formats documented? [YES/NO]
|
||||
- Authentication documented? [YES/NO]
|
||||
- Error handling documented? [YES/NO]
|
||||
|
||||
Data Documentation
|
||||
- Data model documented? [YES/NO]
|
||||
- Database schema documented? [YES/NO]
|
||||
- Data dictionary provided? [YES/NO]
|
||||
- Data validation rules documented? [YES/NO]
|
||||
|
||||
Security Documentation
|
||||
- Security architecture documented? [YES/NO]
|
||||
- Authentication/authorization documented? [YES/NO]
|
||||
- Data protection measures documented? [YES/NO]
|
||||
- Security testing results documented? [YES/NO]
|
||||
|
||||
Testing Documentation
|
||||
- Test strategy documented? [YES/NO]
|
||||
- Test cases documented? [YES/NO]
|
||||
- Test results documented? [YES/NO]
|
||||
- Known issues documented? [YES/NO]
|
||||
|
||||
Deployment Documentation
|
||||
- Deployment architecture documented? [YES/NO]
|
||||
- Environment configurations documented? [YES/NO]
|
||||
- Deployment procedures documented? [YES/NO]
|
||||
- Rollback procedures documented? [YES/NO]
|
||||
|
||||
Operational Documentation
|
||||
- Operating procedures documented? [YES/NO]
|
||||
- Troubleshooting guide provided? [YES/NO]
|
||||
- Backup and recovery documented? [YES/NO]
|
||||
- Monitoring configuration documented? [YES/NO]
|
||||
|
||||
Knowledge Transfer
|
||||
- Onboarding overview provided? [YES/NO]
|
||||
- Key concepts documented? [YES/NO]
|
||||
- Common tasks documented? [YES/NO]
|
||||
- FAQs provided? [YES/NO]
|
||||
|
||||
Project History
|
||||
- Project timeline documented? [YES/NO]
|
||||
- Key decisions documented? [YES/NO]
|
||||
- Lessons learned documented? [YES/NO]
|
||||
- Future enhancements suggested? [YES/NO]
|
||||
|
||||
Memory Bank Integration
|
||||
- All Memory Bank files updated? [YES/NO]
|
||||
- Cross-references created? [YES/NO]
|
||||
- Documentation properly versioned? [YES/NO]
|
||||
- Archive repository established? [YES/NO]
|
||||
```
|
||||
|
||||
## 📋 MINIMAL MODE ARCHIVING FORMAT
|
||||
|
||||
For situations requiring a more compact archiving approach:
|
||||
|
||||
```markdown
|
||||
## Level 4 Task Archive: [System Name]
|
||||
|
||||
### System Summary
|
||||
- **Purpose**: [Brief description of system purpose]
|
||||
- **Key Components**: [List of key components]
|
||||
- **Architecture**: [Brief architecture description with diagram]
|
||||
|
||||
### Implementation Summary
|
||||
- **Technology Stack**: [Key technologies used]
|
||||
- **Key Modules**: [Brief description of important modules]
|
||||
- **Integration Points**: [List of major integration points]
|
||||
|
||||
### Critical Documentation
|
||||
- **API Documentation**: [Link or brief summary]
|
||||
- **Data Model**: [Link or brief description]
|
||||
- **Deployment Configuration**: [Link or brief description]
|
||||
- **Security Measures**: [Link or brief summary]
|
||||
|
||||
### Operational Information
|
||||
- **Deployment Procedure**: [Link or brief description]
|
||||
- **Key Configuration Parameters**: [List of important parameters]
|
||||
- **Monitoring Setup**: [Brief monitoring details]
|
||||
- **Common Issues**: [List of common issues with solutions]
|
||||
|
||||
### Repository Information
|
||||
- **Code Repository**: [Link to repository]
|
||||
- **Documentation Repository**: [Link to documentation]
|
||||
- **Build Artifacts**: [Link to build artifacts]
|
||||
|
||||
### Knowledge Transfer Summary
|
||||
- **Key Contacts**: [List of key people with knowledge]
|
||||
- **Critical Knowledge Areas**: [Areas requiring special expertise]
|
||||
- **Training Resources**: [Links to training materials]
|
||||
|
||||
### Memory Bank Links
|
||||
- [Links to updated Memory Bank files]
|
||||
```
|
||||
|
||||
## 🚨 ARCHIVING ENFORCEMENT PRINCIPLE
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ COMPREHENSIVE ARCHIVING IS MANDATORY for Level 4 │
|
||||
│ tasks. No complex system is considered complete │
|
||||
│ until comprehensive archiving is finished and │
|
||||
│ verified. │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
@@ -0,0 +1,655 @@
|
||||
---
|
||||
description: Phased Implementation for Level 4 Complex System tasks
|
||||
globs: "**/level4/**", "**/implementation/**"
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# PHASED IMPLEMENTATION FOR LEVEL 4 TASKS
|
||||
|
||||
> **TL;DR:** This document outlines a structured phased implementation approach for Level 4 (Complex System) tasks, ensuring controlled, incremental delivery of complex systems with appropriate verification at each phase.
|
||||
|
||||
## 🔍 PHASED IMPLEMENTATION OVERVIEW
|
||||
|
||||
Level 4 Complex System tasks require a controlled, incremental approach to implementation to manage complexity, reduce risk, and ensure quality. This document outlines a phased implementation methodology that divides complex system development into discrete, verifiable phases with clear entry and exit criteria.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef phase fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef verification fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
Start([Begin Implementation<br>Process]) --> Framework[Establish Implementation<br>Framework]
|
||||
Framework --> Plan[Create Phasing<br>Plan]
|
||||
Plan --> Foundation[Implement<br>Foundation Phase]
|
||||
Foundation --> VerifyF{Foundation<br>Verification}
|
||||
VerifyF -->|Pass| Core[Implement<br>Core Phase]
|
||||
VerifyF -->|Fail| ReviseF[Revise<br>Foundation]
|
||||
ReviseF --> VerifyF
|
||||
|
||||
Core --> VerifyC{Core<br>Verification}
|
||||
VerifyC -->|Pass| Extension[Implement<br>Extension Phase]
|
||||
VerifyC -->|Fail| ReviseC[Revise<br>Core]
|
||||
ReviseC --> VerifyC
|
||||
|
||||
Extension --> VerifyE{Extension<br>Verification}
|
||||
VerifyE -->|Pass| Integration[Implement<br>Integration Phase]
|
||||
VerifyE -->|Fail| ReviseE[Revise<br>Extension]
|
||||
ReviseE --> VerifyE
|
||||
|
||||
Integration --> VerifyI{Integration<br>Verification}
|
||||
VerifyI -->|Pass| Finalization[Implement<br>Finalization Phase]
|
||||
VerifyI -->|Fail| ReviseI[Revise<br>Integration]
|
||||
ReviseI --> VerifyI
|
||||
|
||||
Finalization --> VerifyFin{Finalization<br>Verification}
|
||||
VerifyFin -->|Pass| Complete([Implementation<br>Complete])
|
||||
VerifyFin -->|Fail| ReviseFin[Revise<br>Finalization]
|
||||
ReviseFin --> VerifyFin
|
||||
|
||||
Framework -.-> IF((Implementation<br>Framework))
|
||||
Plan -.-> PP((Phasing<br>Plan))
|
||||
Foundation -.-> FP((Foundation<br>Phase))
|
||||
Core -.-> CP((Core<br>Phase))
|
||||
Extension -.-> EP((Extension<br>Phase))
|
||||
Integration -.-> IP((Integration<br>Phase))
|
||||
Finalization -.-> FiP((Finalization<br>Phase))
|
||||
|
||||
class Start,Complete milestone
|
||||
class Framework,Plan,Foundation,Core,Extension,Integration,Finalization,ReviseF,ReviseC,ReviseE,ReviseI,ReviseFin step
|
||||
class VerifyF,VerifyC,VerifyE,VerifyI,VerifyFin verification
|
||||
class IF,PP,FP,CP,EP,IP,FiP artifact
|
||||
```
|
||||
|
||||
## 📋 IMPLEMENTATION PHASING PRINCIPLES
|
||||
|
||||
1. **Incremental Value Delivery**: Each phase delivers tangible, verifiable value.
|
||||
2. **Progressive Complexity**: Complexity increases gradually across phases.
|
||||
3. **Risk Mitigation**: Early phases address high-risk elements to fail fast if needed.
|
||||
4. **Verification Gates**: Each phase has explicit entry and exit criteria.
|
||||
5. **Business Alignment**: Phases align with business priorities and user needs.
|
||||
6. **Technical Integrity**: Each phase maintains architectural and technical integrity.
|
||||
7. **Continuous Integration**: Work is continuously integrated and tested.
|
||||
8. **Knowledge Building**: Each phase builds upon knowledge gained in previous phases.
|
||||
9. **Explicit Dependencies**: Dependencies between phases are clearly documented.
|
||||
10. **Adaptability**: The phasing plan can adapt to new information while maintaining structure.
|
||||
|
||||
## 📋 STANDARD IMPLEMENTATION PHASES
|
||||
|
||||
Level 4 Complex System tasks typically follow a five-phase implementation approach:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
classDef phase fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
|
||||
P1[1. Foundation<br>Phase] --> P2[2. Core<br>Phase]
|
||||
P2 --> P3[3. Extension<br>Phase]
|
||||
P3 --> P4[4. Integration<br>Phase]
|
||||
P4 --> P5[5. Finalization<br>Phase]
|
||||
|
||||
class P1,P2,P3,P4,P5 phase
|
||||
```
|
||||
|
||||
### Phase 1: Foundation Phase
|
||||
|
||||
The Foundation Phase establishes the basic architecture and infrastructure required for the system.
|
||||
|
||||
**Key Activities:**
|
||||
- Set up development, testing, and deployment environments
|
||||
- Establish core architectural components and patterns
|
||||
- Implement database schema and basic data access
|
||||
- Create skeleton application structure
|
||||
- Implement authentication and authorization framework
|
||||
- Establish logging, monitoring, and error handling
|
||||
- Create basic CI/CD pipeline
|
||||
|
||||
**Exit Criteria:**
|
||||
- Basic architectural framework is functional
|
||||
- Environment setup is complete and documented
|
||||
- Core infrastructure components are in place
|
||||
- Basic CI/CD pipeline is operational
|
||||
- Architecture review confirms alignment with design
|
||||
|
||||
### Phase 2: Core Phase
|
||||
|
||||
The Core Phase implements the essential functionality that provides the minimum viable system.
|
||||
|
||||
**Key Activities:**
|
||||
- Implement core business logic
|
||||
- Develop primary user flows and interfaces
|
||||
- Create essential system services
|
||||
- Implement critical API endpoints
|
||||
- Develop basic reporting capabilities
|
||||
- Establish primary integration points
|
||||
- Create automated tests for core functionality
|
||||
|
||||
**Exit Criteria:**
|
||||
- Core business functionality is implemented
|
||||
- Essential user flows are working
|
||||
- Primary APIs are functional
|
||||
- Core automated tests are passing
|
||||
- Business stakeholders verify core functionality
|
||||
|
||||
### Phase 3: Extension Phase
|
||||
|
||||
The Extension Phase adds additional features and capabilities to the core system.
|
||||
|
||||
**Key Activities:**
|
||||
- Implement secondary business processes
|
||||
- Add additional user interfaces and features
|
||||
- Enhance existing functionality based on feedback
|
||||
- Implement advanced features
|
||||
- Extend integration capabilities
|
||||
- Enhance error handling and edge cases
|
||||
- Expand test coverage
|
||||
|
||||
**Exit Criteria:**
|
||||
- All planned features are implemented
|
||||
- Extended functionality is working correctly
|
||||
- Secondary business processes are functional
|
||||
- Enhanced features have been validated
|
||||
- Test coverage meets defined thresholds
|
||||
|
||||
### Phase 4: Integration Phase
|
||||
|
||||
The Integration Phase ensures all components work together properly and integrates with external systems.
|
||||
|
||||
**Key Activities:**
|
||||
- Perform deep integration testing
|
||||
- Implement all external system integrations
|
||||
- Conduct end-to-end testing
|
||||
- Perform performance and load testing
|
||||
- Conduct security testing
|
||||
- Implement any required data migrations
|
||||
- Verify system behavior under various conditions
|
||||
|
||||
**Exit Criteria:**
|
||||
- All integrations are working correctly
|
||||
- End-to-end tests are passing
|
||||
- Performance meets defined requirements
|
||||
- Security tests show no critical vulnerabilities
|
||||
- System handles error conditions gracefully
|
||||
|
||||
### Phase 5: Finalization Phase
|
||||
|
||||
The Finalization Phase prepares the system for production release.
|
||||
|
||||
**Key Activities:**
|
||||
- Optimize performance
|
||||
- Conduct user acceptance testing
|
||||
- Finalize documentation
|
||||
- Conduct final security review
|
||||
- Create production deployment plan
|
||||
- Prepare support materials and training
|
||||
- Conduct final system review
|
||||
|
||||
**Exit Criteria:**
|
||||
- All acceptance criteria are met
|
||||
- Documentation is complete
|
||||
- User acceptance testing is successful
|
||||
- Production deployment plan is approved
|
||||
- Support and maintenance procedures are established
|
||||
|
||||
## 📋 PHASE PLANNING TEMPLATE
|
||||
|
||||
For each implementation phase, create a detailed plan using this template:
|
||||
|
||||
```markdown
|
||||
## [Phase Name] Implementation Plan
|
||||
|
||||
### Phase Overview
|
||||
- **Purpose**: [Brief description of phase purpose]
|
||||
- **Timeline**: [Start and end dates]
|
||||
- **Dependencies**: [Dependencies on other phases or external factors]
|
||||
- **Key Stakeholders**: [List of key stakeholders for this phase]
|
||||
|
||||
### Entry Criteria
|
||||
- [ ] [Criterion 1]
|
||||
- [ ] [Criterion 2]
|
||||
- [ ] [Criterion 3]
|
||||
|
||||
### Implementation Components
|
||||
- **Component 1**: [Description]
|
||||
- [ ] Task 1.1: [Description]
|
||||
- [ ] Task 1.2: [Description]
|
||||
|
||||
- **Component 2**: [Description]
|
||||
- [ ] Task 2.1: [Description]
|
||||
- [ ] Task 2.2: [Description]
|
||||
|
||||
### Technical Considerations
|
||||
- [Key technical considerations for this phase]
|
||||
|
||||
### Risk Assessment
|
||||
- **Risk 1**: [Description]
|
||||
- Impact: [High/Medium/Low]
|
||||
- Mitigation: [Strategy]
|
||||
|
||||
- **Risk 2**: [Description]
|
||||
- Impact: [High/Medium/Low]
|
||||
- Mitigation: [Strategy]
|
||||
|
||||
### Quality Assurance
|
||||
- [QA approach for this phase]
|
||||
- [Testing requirements]
|
||||
|
||||
### Exit Criteria
|
||||
- [ ] [Criterion 1]
|
||||
- [ ] [Criterion 2]
|
||||
- [ ] [Criterion 3]
|
||||
|
||||
### Deliverables
|
||||
- [List of deliverables for this phase]
|
||||
```
|
||||
|
||||
## 📋 PHASE VERIFICATION
|
||||
|
||||
Each phase requires formal verification before proceeding to the next phase.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef activity fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef decision fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
Start([Begin Phase<br>Verification]) --> CodeReview[Conduct Code<br>Review]
|
||||
CodeReview --> TestExecution[Execute Automated<br>Tests]
|
||||
TestExecution --> QAVerification[Perform QA<br>Verification]
|
||||
QAVerification --> ArchReview[Conduct Architecture<br>Review]
|
||||
ArchReview --> StakeholderReview[Conduct Stakeholder<br>Review]
|
||||
StakeholderReview --> Checklist[Complete Verification<br>Checklist]
|
||||
Checklist --> ExitCriteria{All Exit<br>Criteria Met?}
|
||||
ExitCriteria -->|Yes| Approval[Obtain Phase<br>Approval]
|
||||
ExitCriteria -->|No| Issues[Document<br>Issues]
|
||||
Issues --> Remediation[Implement<br>Remediation]
|
||||
Remediation --> Retest[Verify<br>Fixes]
|
||||
Retest --> ExitCriteria
|
||||
Approval --> Complete([Verification<br>Complete])
|
||||
|
||||
CodeReview -.-> CodeReport((Code Review<br>Report))
|
||||
TestExecution -.-> TestReport((Test<br>Report))
|
||||
QAVerification -.-> QAReport((QA<br>Report))
|
||||
ArchReview -.-> ArchReport((Architecture<br>Report))
|
||||
StakeholderReview -.-> StakeReport((Stakeholder<br>Report))
|
||||
Checklist -.-> CheckDoc((Verification<br>Checklist))
|
||||
|
||||
class Start,Complete milestone
|
||||
class CodeReview,TestExecution,QAVerification,ArchReview,StakeholderReview,Checklist,Approval,Issues,Remediation,Retest activity
|
||||
class ExitCriteria decision
|
||||
class CodeReport,TestReport,QAReport,ArchReport,StakeReport,CheckDoc artifact
|
||||
```
|
||||
|
||||
### Phase Verification Checklist Template
|
||||
|
||||
```markdown
|
||||
## Phase Verification Checklist
|
||||
|
||||
### Implementation Completeness
|
||||
- [ ] All planned components implemented
|
||||
- [ ] All tasks marked as complete
|
||||
- [ ] No outstanding TODOs in code
|
||||
- [ ] All documentation updated
|
||||
|
||||
### Code Quality
|
||||
- [ ] Code review completed
|
||||
- [ ] No critical issues found in static analysis
|
||||
- [ ] Code meets established standards
|
||||
- [ ] Technical debt documented
|
||||
|
||||
### Testing
|
||||
- [ ] Unit tests completed and passing
|
||||
- [ ] Integration tests completed and passing
|
||||
- [ ] End-to-end tests completed and passing
|
||||
- [ ] Performance testing completed (if applicable)
|
||||
- [ ] Security testing completed (if applicable)
|
||||
- [ ] Test coverage meets requirements
|
||||
|
||||
### Architecture
|
||||
- [ ] Implementation follows architectural design
|
||||
- [ ] No architectural violations introduced
|
||||
- [ ] Technical patterns correctly implemented
|
||||
- [ ] Non-functional requirements met
|
||||
|
||||
### Stakeholder Verification
|
||||
- [ ] Business requirements met
|
||||
- [ ] Stakeholder demo completed
|
||||
- [ ] Feedback incorporated
|
||||
- [ ] Acceptance criteria verified
|
||||
|
||||
### Risk Assessment
|
||||
- [ ] All identified risks addressed
|
||||
- [ ] No new risks introduced
|
||||
- [ ] Contingency plans in place for known issues
|
||||
|
||||
### Exit Criteria
|
||||
- [ ] All exit criteria met
|
||||
- [ ] Any exceptions documented and approved
|
||||
- [ ] Phase signoff obtained from required parties
|
||||
```
|
||||
|
||||
## 📋 HANDLING PHASE DEPENDENCIES
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef solid fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef partial fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
|
||||
F[Foundation<br>Phase] --> C[Core<br>Phase]
|
||||
F --> E[Extension<br>Phase]
|
||||
F --> I[Integration<br>Phase]
|
||||
F --> FN[Finalization<br>Phase]
|
||||
|
||||
C --> E
|
||||
C --> I
|
||||
C --> FN
|
||||
|
||||
E --> I
|
||||
E --> FN
|
||||
|
||||
I --> FN
|
||||
|
||||
class F,C solid
|
||||
class E,I,FN partial
|
||||
```
|
||||
|
||||
### Dependency Management Strategies
|
||||
|
||||
1. **Vertical Slicing**: Implement complete features across all phases for priority functionality.
|
||||
2. **Stubbing and Mocking**: Create temporary implementations to allow progress on dependent components.
|
||||
3. **Interface Contracts**: Define clear interfaces between components to allow parallel development.
|
||||
4. **Feature Toggles**: Implement features but keep them disabled until dependencies are ready.
|
||||
5. **Incremental Integration**: Gradually integrate components as they become available.
|
||||
|
||||
### Dependency Documentation Format
|
||||
|
||||
```markdown
|
||||
## Implementation Dependencies
|
||||
|
||||
### Foundation Phase Dependencies
|
||||
- **External Dependencies**:
|
||||
- Development environment setup
|
||||
- Access to source control
|
||||
- Access to CI/CD pipeline
|
||||
|
||||
### Core Phase Dependencies
|
||||
- **Foundation Phase Dependencies**:
|
||||
- Authentication framework
|
||||
- Database schema
|
||||
- Logging infrastructure
|
||||
- Basic application skeleton
|
||||
|
||||
- **External Dependencies**:
|
||||
- API specifications from external systems
|
||||
- Test data
|
||||
|
||||
### Extension Phase Dependencies
|
||||
- **Core Phase Dependencies**:
|
||||
- Core business logic
|
||||
- Primary user interface
|
||||
- Essential services
|
||||
|
||||
- **External Dependencies**:
|
||||
- [List external dependencies]
|
||||
|
||||
### Integration Phase Dependencies
|
||||
- **Core Phase Dependencies**:
|
||||
- [List core dependencies]
|
||||
|
||||
- **Extension Phase Dependencies**:
|
||||
- [List extension dependencies]
|
||||
|
||||
- **External Dependencies**:
|
||||
- Access to integration test environments
|
||||
- Test credentials for external systems
|
||||
|
||||
### Finalization Phase Dependencies
|
||||
- **All previous phases must be complete**
|
||||
- **External Dependencies**:
|
||||
- User acceptance testing environment
|
||||
- Production deployment approval
|
||||
```
|
||||
|
||||
## 📋 PHASE TRANSITION PROCESS
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef step fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef verification fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
Start([Begin Phase<br>Transition]) --> Verification[Verify Current<br>Phase Complete]
|
||||
Verification --> Checkpoint{Phase<br>Verified?}
|
||||
Checkpoint -->|No| Remediation[Remediate<br>Issues]
|
||||
Remediation --> Verification
|
||||
Checkpoint -->|Yes| Documentation[Update<br>Documentation]
|
||||
Documentation --> Reflection[Conduct Phase<br>Reflection]
|
||||
Reflection --> NextPlan[Finalize Next<br>Phase Plan]
|
||||
NextPlan --> Approvals[Obtain<br>Approvals]
|
||||
Approvals --> Kickoff[Conduct Next<br>Phase Kickoff]
|
||||
Kickoff --> End([Begin Next<br>Phase])
|
||||
|
||||
Verification -.-> VerifDoc((Verification<br>Checklist))
|
||||
Documentation -.-> Docs((Updated<br>Documentation))
|
||||
Reflection -.-> ReflectDoc((Reflection<br>Document))
|
||||
NextPlan -.-> PlanDoc((Phase<br>Plan))
|
||||
|
||||
class Start,End milestone
|
||||
class Verification,Remediation,Documentation,Reflection,NextPlan,Approvals,Kickoff step
|
||||
class Checkpoint verification
|
||||
class VerifDoc,Docs,ReflectDoc,PlanDoc artifact
|
||||
```
|
||||
|
||||
### Phase Transition Checklist
|
||||
|
||||
```markdown
|
||||
## Phase Transition Checklist
|
||||
|
||||
### Current Phase Closure
|
||||
- [ ] All exit criteria met and documented
|
||||
- [ ] All verification steps completed
|
||||
- [ ] All issues resolved or documented
|
||||
- [ ] Phase retrospective completed
|
||||
|
||||
### Documentation Updates
|
||||
- [ ] Technical documentation updated
|
||||
- [ ] User documentation updated
|
||||
- [ ] Architecture documentation updated
|
||||
- [ ] Test documentation updated
|
||||
|
||||
### Knowledge Transfer
|
||||
- [ ] Lessons learned documented
|
||||
- [ ] Knowledge shared with team
|
||||
- [ ] Training conducted if needed
|
||||
|
||||
### Next Phase Preparation
|
||||
- [ ] Next phase plan reviewed and updated
|
||||
- [ ] Resources aligned
|
||||
- [ ] Dependencies verified
|
||||
- [ ] Entry criteria confirmed
|
||||
|
||||
### Approvals
|
||||
- [ ] Technical lead approval
|
||||
- [ ] Business stakeholder approval
|
||||
- [ ] Project management approval
|
||||
```
|
||||
|
||||
## 📋 IMPLEMENTATION TRACKING IN TASKS.MD
|
||||
|
||||
Update `tasks.md` to track phased implementation progress:
|
||||
|
||||
```markdown
|
||||
## [SYSTEM-ID]: System Name
|
||||
|
||||
### Implementation Phases
|
||||
#### 1. Foundation Phase
|
||||
- **Status**: [Not Started/In Progress/Complete]
|
||||
- **Progress**: [0-100%]
|
||||
- **Start Date**: [Date]
|
||||
- **Target Completion**: [Date]
|
||||
- **Actual Completion**: [Date]
|
||||
|
||||
**Key Components**:
|
||||
- [ ] Component 1: [Status] - [Progress %]
|
||||
- [ ] Component 2: [Status] - [Progress %]
|
||||
|
||||
**Verification Status**:
|
||||
- [ ] Code Review: [Status]
|
||||
- [ ] Testing: [Status]
|
||||
- [ ] Architecture Review: [Status]
|
||||
- [ ] Stakeholder Approval: [Status]
|
||||
|
||||
**Issues/Blockers**:
|
||||
- [List of issues if any]
|
||||
|
||||
#### 2. Core Phase
|
||||
...
|
||||
|
||||
#### 3. Extension Phase
|
||||
...
|
||||
|
||||
#### 4. Integration Phase
|
||||
...
|
||||
|
||||
#### 5. Finalization Phase
|
||||
...
|
||||
```
|
||||
|
||||
## 📋 MEMORY BANK INTEGRATION
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef memfile fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef process fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
|
||||
Implementation[Phased<br>Implementation] --> PB[projectbrief.md]
|
||||
Implementation --> PC[productContext.md]
|
||||
Implementation --> AC[activeContext.md]
|
||||
Implementation --> SP[systemPatterns.md]
|
||||
Implementation --> TC[techContext.md]
|
||||
Implementation --> P[progress.md]
|
||||
|
||||
PB & PC & AC & SP & TC & P --> MBI[Memory Bank<br>Integration]
|
||||
MBI --> Implementation
|
||||
|
||||
class PB,PC,AC,SP,TC,P memfile
|
||||
class Implementation,MBI process
|
||||
```
|
||||
|
||||
### Memory Bank Updates
|
||||
|
||||
Update the following Memory Bank files during phased implementation:
|
||||
|
||||
1. **projectbrief.md**
|
||||
- Update implementation approach
|
||||
- Document phase-specific objectives
|
||||
- Link to phase plans
|
||||
|
||||
2. **activeContext.md**
|
||||
- Update with current implementation phase
|
||||
- Document active implementation tasks
|
||||
- Highlight current focus areas
|
||||
|
||||
3. **systemPatterns.md**
|
||||
- Document implementation patterns used
|
||||
- Update with architectural decisions made during implementation
|
||||
- Record any pattern adaptations
|
||||
|
||||
4. **techContext.md**
|
||||
- Update with implementation technologies
|
||||
- Document technical constraints encountered
|
||||
- Record technical decisions made
|
||||
|
||||
5. **progress.md**
|
||||
- Update implementation progress by phase
|
||||
- Document completed components
|
||||
- Track overall implementation status
|
||||
|
||||
## 📋 IMPLEMENTATION VERIFICATION CHECKLIST
|
||||
|
||||
```
|
||||
✓ IMPLEMENTATION VERIFICATION CHECKLIST
|
||||
|
||||
Planning
|
||||
- Implementation framework established? [YES/NO]
|
||||
- Phasing plan created? [YES/NO]
|
||||
- Phase dependencies documented? [YES/NO]
|
||||
- Entry/exit criteria defined for all phases? [YES/NO]
|
||||
- Risk assessment performed? [YES/NO]
|
||||
|
||||
Foundation Phase
|
||||
- Environment setup complete? [YES/NO]
|
||||
- Core architecture implemented? [YES/NO]
|
||||
- Basic infrastructure in place? [YES/NO]
|
||||
- CI/CD pipeline operational? [YES/NO]
|
||||
- Foundation verification completed? [YES/NO]
|
||||
|
||||
Core Phase
|
||||
- Core business logic implemented? [YES/NO]
|
||||
- Primary user flows working? [YES/NO]
|
||||
- Essential services operational? [YES/NO]
|
||||
- Core APIs implemented? [YES/NO]
|
||||
- Core verification completed? [YES/NO]
|
||||
|
||||
Extension Phase
|
||||
- Secondary features implemented? [YES/NO]
|
||||
- Enhanced functionality working? [YES/NO]
|
||||
- Additional user interfaces complete? [YES/NO]
|
||||
- Extended test coverage in place? [YES/NO]
|
||||
- Extension verification completed? [YES/NO]
|
||||
|
||||
Integration Phase
|
||||
- All components integrated? [YES/NO]
|
||||
- External integrations working? [YES/NO]
|
||||
- End-to-end testing completed? [YES/NO]
|
||||
- Performance testing executed? [YES/NO]
|
||||
- Integration verification completed? [YES/NO]
|
||||
|
||||
Finalization Phase
|
||||
- All optimizations complete? [YES/NO]
|
||||
- User acceptance testing passed? [YES/NO]
|
||||
- Documentation finalized? [YES/NO]
|
||||
- Production deployment plan ready? [YES/NO]
|
||||
- Final system review completed? [YES/NO]
|
||||
|
||||
Memory Bank Integration
|
||||
- All Memory Bank files updated? [YES/NO]
|
||||
- Implementation status reflected? [YES/NO]
|
||||
- Technical decisions documented? [YES/NO]
|
||||
- Progress tracking current? [YES/NO]
|
||||
```
|
||||
|
||||
## 📋 MINIMAL MODE IMPLEMENTATION FORMAT
|
||||
|
||||
For situations requiring a more compact implementation approach:
|
||||
|
||||
```markdown
|
||||
## [SYSTEM-ID]: Phased Implementation
|
||||
|
||||
### Phase Status Summary
|
||||
- **Foundation**: [Status] - [Progress %]
|
||||
- **Core**: [Status] - [Progress %]
|
||||
- **Extension**: [Status] - [Progress %]
|
||||
- **Integration**: [Status] - [Progress %]
|
||||
- **Finalization**: [Status] - [Progress %]
|
||||
|
||||
### Current Phase: [Phase Name]
|
||||
- **Key Components**: [List of key components being implemented]
|
||||
- **Blockers**: [List of blockers if any]
|
||||
- **Next Steps**: [List of immediate next steps]
|
||||
|
||||
### Verification Status
|
||||
- [List of verification steps and their status]
|
||||
|
||||
### Memory Bank Updates
|
||||
- [List of Memory Bank files that need updating]
|
||||
```
|
||||
|
||||
## 🚨 IMPLEMENTATION VERIFICATION PRINCIPLE
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ NO PHASE IS CONSIDERED COMPLETE until all │
|
||||
│ verification steps have been passed and documented. │
|
||||
│ Phases MUST NOT be rushed to meet deadlines at the │
|
||||
│ expense of quality or architectural integrity. │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
@@ -0,0 +1,719 @@
|
||||
---
|
||||
description: Comprehensive reflection format for Level 4 Complex System tasks
|
||||
globs: "**/level4/**", "**/reflection/**"
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# COMPREHENSIVE REFLECTION FOR LEVEL 4 TASKS
|
||||
|
||||
> **TL;DR:** This document outlines a structured, comprehensive approach to reflection for Level 4 (Complex System) tasks, including system review, success and challenge analysis, strategic insights, and action planning.
|
||||
|
||||
## 🔍 COMPREHENSIVE REFLECTION OVERVIEW
|
||||
|
||||
Level 4 Complex System tasks require in-depth reflection to capture key insights, document successes and challenges, extract strategic lessons, and guide future improvements. This systematic reflection process ensures organizational learning and continuous improvement.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef phase fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef verification fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
Start([Begin Reflection<br>Process]) --> Template[Load Comprehensive<br>Reflection Template]
|
||||
Template --> SysReview[Conduct System<br>Review]
|
||||
SysReview --> ArchReview[Review Architecture<br>Decisions]
|
||||
ArchReview --> ImplementReview[Review Implementation<br>Approach]
|
||||
ImplementReview --> SuccessAnalysis[Document Successes<br>and Achievements]
|
||||
SuccessAnalysis --> ChallengeAnalysis[Document Challenges<br>and Solutions]
|
||||
ChallengeAnalysis --> Technical[Extract Technical<br>Insights]
|
||||
Technical --> Process[Extract Process<br>Insights]
|
||||
Process --> Business[Extract Business<br>Insights]
|
||||
Business --> Strategic[Define Strategic<br>Actions]
|
||||
Strategic --> Timeline[Analyze Timeline<br>Performance]
|
||||
Timeline --> Documentation[Complete Reflection<br>Documentation]
|
||||
Documentation --> Integration[Integrate with<br>Memory Bank]
|
||||
Integration --> Verification{Reflection<br>Verification}
|
||||
Verification -->|Pass| Complete([Reflection<br>Complete])
|
||||
Verification -->|Fail| Revise[Revise<br>Reflection]
|
||||
Revise --> Verification
|
||||
|
||||
Template -.-> RT((Reflection<br>Template))
|
||||
SysReview -.-> SR((System<br>Review))
|
||||
SuccessAnalysis & ChallengeAnalysis -.-> SCD((Success/Challenge<br>Document))
|
||||
Technical & Process & Business -.-> Insights((Insight<br>Document))
|
||||
Strategic -.-> Actions((Strategic<br>Actions))
|
||||
|
||||
class Start,Complete milestone
|
||||
class Template,SysReview,ArchReview,ImplementReview,SuccessAnalysis,ChallengeAnalysis,Technical,Process,Business,Strategic,Timeline,Documentation,Integration step
|
||||
class Verification verification
|
||||
class RT,SR,SCD,Insights,Actions artifact
|
||||
```
|
||||
|
||||
## 📋 REFLECTION TEMPLATE STRUCTURE
|
||||
|
||||
### 1. System Overview
|
||||
|
||||
```markdown
|
||||
## System Overview
|
||||
|
||||
### System Description
|
||||
[Comprehensive description of the implemented system, including purpose, scope, and key features]
|
||||
|
||||
### System Context
|
||||
[Description of how the system fits into the broader technical and business ecosystem]
|
||||
|
||||
### Key Components
|
||||
- Component 1: [Description and purpose]
|
||||
- Component 2: [Description and purpose]
|
||||
- Component 3: [Description and purpose]
|
||||
|
||||
### System Architecture
|
||||
[Summary of the architectural approach, key patterns, and design decisions]
|
||||
|
||||
### System Boundaries
|
||||
[Description of system boundaries, interfaces, and integration points]
|
||||
|
||||
### Implementation Summary
|
||||
[Overview of the implementation approach, technologies, and methods used]
|
||||
```
|
||||
|
||||
### 2. Project Performance Analysis
|
||||
|
||||
```markdown
|
||||
## Project Performance Analysis
|
||||
|
||||
### Timeline Performance
|
||||
- **Planned Duration**: [X] weeks/months
|
||||
- **Actual Duration**: [Y] weeks/months
|
||||
- **Variance**: [+/-Z] weeks/months ([P]%)
|
||||
- **Explanation**: [Analysis of timeline variances]
|
||||
|
||||
### Resource Utilization
|
||||
- **Planned Resources**: [X] person-months
|
||||
- **Actual Resources**: [Y] person-months
|
||||
- **Variance**: [+/-Z] person-months ([P]%)
|
||||
- **Explanation**: [Analysis of resource variances]
|
||||
|
||||
### Quality Metrics
|
||||
- **Planned Quality Targets**: [List of quality targets]
|
||||
- **Achieved Quality Results**: [List of achieved quality results]
|
||||
- **Variance Analysis**: [Analysis of quality variances]
|
||||
|
||||
### Risk Management Effectiveness
|
||||
- **Identified Risks**: [Number of risks identified]
|
||||
- **Risks Materialized**: [Number and percentage of risks that occurred]
|
||||
- **Mitigation Effectiveness**: [Effectiveness of risk mitigation strategies]
|
||||
- **Unforeseen Risks**: [Description of unforeseen risks that emerged]
|
||||
```
|
||||
|
||||
### 3. Achievements and Successes
|
||||
|
||||
```markdown
|
||||
## Achievements and Successes
|
||||
|
||||
### Key Achievements
|
||||
1. **Achievement 1**: [Description]
|
||||
- **Evidence**: [Concrete evidence of success]
|
||||
- **Impact**: [Business/technical impact]
|
||||
- **Contributing Factors**: [What enabled this success]
|
||||
|
||||
2. **Achievement 2**: [Description]
|
||||
- **Evidence**: [Concrete evidence of success]
|
||||
- **Impact**: [Business/technical impact]
|
||||
- **Contributing Factors**: [What enabled this success]
|
||||
|
||||
### Technical Successes
|
||||
- **Success 1**: [Description of technical success]
|
||||
- **Approach Used**: [Description of approach]
|
||||
- **Outcome**: [Results achieved]
|
||||
- **Reusability**: [How this can be reused]
|
||||
|
||||
- **Success 2**: [Description of technical success]
|
||||
- **Approach Used**: [Description of approach]
|
||||
- **Outcome**: [Results achieved]
|
||||
- **Reusability**: [How this can be reused]
|
||||
|
||||
### Process Successes
|
||||
- **Success 1**: [Description of process success]
|
||||
- **Approach Used**: [Description of approach]
|
||||
- **Outcome**: [Results achieved]
|
||||
- **Reusability**: [How this can be reused]
|
||||
|
||||
### Team Successes
|
||||
- **Success 1**: [Description of team success]
|
||||
- **Approach Used**: [Description of approach]
|
||||
- **Outcome**: [Results achieved]
|
||||
- **Reusability**: [How this can be reused]
|
||||
```
|
||||
|
||||
### 4. Challenges and Solutions
|
||||
|
||||
```markdown
|
||||
## Challenges and Solutions
|
||||
|
||||
### Key Challenges
|
||||
1. **Challenge 1**: [Description]
|
||||
- **Impact**: [Business/technical impact]
|
||||
- **Resolution Approach**: [How it was addressed]
|
||||
- **Outcome**: [Final result]
|
||||
- **Preventative Measures**: [How to prevent in future]
|
||||
|
||||
2. **Challenge 2**: [Description]
|
||||
- **Impact**: [Business/technical impact]
|
||||
- **Resolution Approach**: [How it was addressed]
|
||||
- **Outcome**: [Final result]
|
||||
- **Preventative Measures**: [How to prevent in future]
|
||||
|
||||
### Technical Challenges
|
||||
- **Challenge 1**: [Description of technical challenge]
|
||||
- **Root Cause**: [Analysis of root cause]
|
||||
- **Solution**: [How it was solved]
|
||||
- **Alternative Approaches**: [Other approaches considered]
|
||||
- **Lessons Learned**: [Key takeaways]
|
||||
|
||||
- **Challenge 2**: [Description of technical challenge]
|
||||
- **Root Cause**: [Analysis of root cause]
|
||||
- **Solution**: [How it was solved]
|
||||
- **Alternative Approaches**: [Other approaches considered]
|
||||
- **Lessons Learned**: [Key takeaways]
|
||||
|
||||
### Process Challenges
|
||||
- **Challenge 1**: [Description of process challenge]
|
||||
- **Root Cause**: [Analysis of root cause]
|
||||
- **Solution**: [How it was solved]
|
||||
- **Process Improvements**: [Improvements made or suggested]
|
||||
|
||||
### Unresolved Issues
|
||||
- **Issue 1**: [Description of unresolved issue]
|
||||
- **Current Status**: [Status]
|
||||
- **Proposed Path Forward**: [Suggested next steps]
|
||||
- **Required Resources**: [What's needed to resolve]
|
||||
```
|
||||
|
||||
### 5. Technical Insights
|
||||
|
||||
```markdown
|
||||
## Technical Insights
|
||||
|
||||
### Architecture Insights
|
||||
- **Insight 1**: [Description of architectural insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested changes or actions]
|
||||
|
||||
- **Insight 2**: [Description of architectural insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested changes or actions]
|
||||
|
||||
### Implementation Insights
|
||||
- **Insight 1**: [Description of implementation insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested changes or actions]
|
||||
|
||||
### Technology Stack Insights
|
||||
- **Insight 1**: [Description of technology stack insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested changes or actions]
|
||||
|
||||
### Performance Insights
|
||||
- **Insight 1**: [Description of performance insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Metrics**: [Relevant performance metrics]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested optimizations]
|
||||
|
||||
### Security Insights
|
||||
- **Insight 1**: [Description of security insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested security improvements]
|
||||
```
|
||||
|
||||
### 6. Process Insights
|
||||
|
||||
```markdown
|
||||
## Process Insights
|
||||
|
||||
### Planning Insights
|
||||
- **Insight 1**: [Description of planning process insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested process improvements]
|
||||
|
||||
### Development Process Insights
|
||||
- **Insight 1**: [Description of development process insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested process improvements]
|
||||
|
||||
### Testing Insights
|
||||
- **Insight 1**: [Description of testing process insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested process improvements]
|
||||
|
||||
### Collaboration Insights
|
||||
- **Insight 1**: [Description of collaboration insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested collaboration improvements]
|
||||
|
||||
### Documentation Insights
|
||||
- **Insight 1**: [Description of documentation insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for future work]
|
||||
- **Recommendations**: [Suggested documentation improvements]
|
||||
```
|
||||
|
||||
### 7. Business Insights
|
||||
|
||||
```markdown
|
||||
## Business Insights
|
||||
|
||||
### Value Delivery Insights
|
||||
- **Insight 1**: [Description of value delivery insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Business Impact**: [Impact on business outcomes]
|
||||
- **Recommendations**: [Suggested improvements]
|
||||
|
||||
### Stakeholder Insights
|
||||
- **Insight 1**: [Description of stakeholder insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for stakeholder management]
|
||||
- **Recommendations**: [Suggested improvements]
|
||||
|
||||
### Market/User Insights
|
||||
- **Insight 1**: [Description of market/user insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for product direction]
|
||||
- **Recommendations**: [Suggested improvements]
|
||||
|
||||
### Business Process Insights
|
||||
- **Insight 1**: [Description of business process insight]
|
||||
- **Context**: [When/where this was observed]
|
||||
- **Implications**: [What this means for business processes]
|
||||
- **Recommendations**: [Suggested improvements]
|
||||
```
|
||||
|
||||
### 8. Strategic Actions
|
||||
|
||||
```markdown
|
||||
## Strategic Actions
|
||||
|
||||
### Immediate Actions
|
||||
- **Action 1**: [Description of immediate action]
|
||||
- **Owner**: [Person responsible]
|
||||
- **Timeline**: [Expected completion date]
|
||||
- **Success Criteria**: [How to measure success]
|
||||
- **Resources Required**: [What's needed]
|
||||
- **Priority**: [High/Medium/Low]
|
||||
|
||||
- **Action 2**: [Description of immediate action]
|
||||
- **Owner**: [Person responsible]
|
||||
- **Timeline**: [Expected completion date]
|
||||
- **Success Criteria**: [How to measure success]
|
||||
- **Resources Required**: [What's needed]
|
||||
- **Priority**: [High/Medium/Low]
|
||||
|
||||
### Short-Term Improvements (1-3 months)
|
||||
- **Improvement 1**: [Description of short-term improvement]
|
||||
- **Owner**: [Person responsible]
|
||||
- **Timeline**: [Expected completion date]
|
||||
- **Success Criteria**: [How to measure success]
|
||||
- **Resources Required**: [What's needed]
|
||||
- **Priority**: [High/Medium/Low]
|
||||
|
||||
### Medium-Term Initiatives (3-6 months)
|
||||
- **Initiative 1**: [Description of medium-term initiative]
|
||||
- **Owner**: [Person responsible]
|
||||
- **Timeline**: [Expected completion date]
|
||||
- **Success Criteria**: [How to measure success]
|
||||
- **Resources Required**: [What's needed]
|
||||
- **Priority**: [High/Medium/Low]
|
||||
|
||||
### Long-Term Strategic Directions (6+ months)
|
||||
- **Direction 1**: [Description of long-term strategic direction]
|
||||
- **Business Alignment**: [How this aligns with business strategy]
|
||||
- **Expected Impact**: [Anticipated outcomes]
|
||||
- **Key Milestones**: [Major checkpoints]
|
||||
- **Success Criteria**: [How to measure success]
|
||||
```
|
||||
|
||||
### 9. Knowledge Transfer
|
||||
|
||||
```markdown
|
||||
## Knowledge Transfer
|
||||
|
||||
### Key Learnings for Organization
|
||||
- **Learning 1**: [Description of key organizational learning]
|
||||
- **Context**: [When/where this was learned]
|
||||
- **Applicability**: [Where this can be applied]
|
||||
- **Suggested Communication**: [How to share this]
|
||||
|
||||
### Technical Knowledge Transfer
|
||||
- **Technical Knowledge 1**: [Description of technical knowledge]
|
||||
- **Audience**: [Who needs this knowledge]
|
||||
- **Transfer Method**: [How to transfer]
|
||||
- **Documentation**: [Where documented]
|
||||
|
||||
### Process Knowledge Transfer
|
||||
- **Process Knowledge 1**: [Description of process knowledge]
|
||||
- **Audience**: [Who needs this knowledge]
|
||||
- **Transfer Method**: [How to transfer]
|
||||
- **Documentation**: [Where documented]
|
||||
|
||||
### Documentation Updates
|
||||
- **Document 1**: [Name of document to update]
|
||||
- **Required Updates**: [What needs to be updated]
|
||||
- **Owner**: [Person responsible]
|
||||
- **Timeline**: [When it will be updated]
|
||||
```
|
||||
|
||||
### 10. Reflection Summary
|
||||
|
||||
```markdown
|
||||
## Reflection Summary
|
||||
|
||||
### Key Takeaways
|
||||
- **Takeaway 1**: [Description of key takeaway]
|
||||
- **Takeaway 2**: [Description of key takeaway]
|
||||
- **Takeaway 3**: [Description of key takeaway]
|
||||
|
||||
### Success Patterns to Replicate
|
||||
1. [Pattern 1 description]
|
||||
2. [Pattern 2 description]
|
||||
3. [Pattern 3 description]
|
||||
|
||||
### Issues to Avoid in Future
|
||||
1. [Issue 1 description]
|
||||
2. [Issue 2 description]
|
||||
3. [Issue 3 description]
|
||||
|
||||
### Overall Assessment
|
||||
[Comprehensive assessment of the project's success, challenges, and strategic value]
|
||||
|
||||
### Next Steps
|
||||
[Clear description of immediate next steps following this reflection]
|
||||
```
|
||||
|
||||
## 📋 REFLECTION PROCESS
|
||||
|
||||
### 1. Preparation
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef step fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
|
||||
Start([Begin Reflection<br>Preparation]) --> Template[Load Reflection<br>Template]
|
||||
Template --> Data[Gather Project<br>Data]
|
||||
Data --> Metrics[Collect Performance<br>Metrics]
|
||||
Metrics --> Feedback[Gather Stakeholder<br>Feedback]
|
||||
Feedback --> Schedule[Schedule Reflection<br>Session]
|
||||
Schedule --> Participants[Identify<br>Participants]
|
||||
Participants --> Agenda[Create Session<br>Agenda]
|
||||
Agenda --> Complete([Preparation<br>Complete])
|
||||
|
||||
Template -.-> TDoc((Reflection<br>Template))
|
||||
Data -.-> ProjData((Project<br>Data))
|
||||
Metrics -.-> MetricsDoc((Performance<br>Metrics))
|
||||
Feedback -.-> FeedbackDoc((Stakeholder<br>Feedback))
|
||||
|
||||
class Start,Complete milestone
|
||||
class Template,Data,Metrics,Feedback,Schedule,Participants,Agenda step
|
||||
class TDoc,ProjData,MetricsDoc,FeedbackDoc artifact
|
||||
```
|
||||
|
||||
**Key Preparation Steps:**
|
||||
1. Load the comprehensive reflection template
|
||||
2. Gather project data (tasks.md, documentation, artifacts)
|
||||
3. Collect performance metrics (timeline, resource utilization, quality)
|
||||
4. Gather stakeholder feedback (internal and external)
|
||||
5. Schedule reflection session(s) with key participants
|
||||
6. Prepare session agenda and pre-work materials
|
||||
|
||||
### 2. Conducting the Reflection Session
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef step fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
|
||||
Start([Begin Reflection<br>Session]) --> Intro[Introduction and<br>Context Setting]
|
||||
Intro --> Project[Project Overview<br>Presentation]
|
||||
Project --> Success[Success<br>Identification]
|
||||
Success --> Challenge[Challenge<br>Identification]
|
||||
Challenge --> Root[Root Cause<br>Analysis]
|
||||
Root --> Insights[Insight<br>Generation]
|
||||
Insights --> Actions[Action<br>Planning]
|
||||
Actions --> Documentation[Document<br>Outcomes]
|
||||
Documentation --> Next[Define Next<br>Steps]
|
||||
Next --> Complete([Session<br>Complete])
|
||||
|
||||
Success -.-> SuccessDoc((Success<br>Document))
|
||||
Challenge -.-> ChallengeDoc((Challenge<br>Document))
|
||||
Insights -.-> InsightDoc((Insight<br>Document))
|
||||
Actions -.-> ActionDoc((Action<br>Plan))
|
||||
|
||||
class Start,Complete milestone
|
||||
class Intro,Project,Success,Challenge,Root,Insights,Actions,Documentation,Next step
|
||||
class SuccessDoc,ChallengeDoc,InsightDoc,ActionDoc artifact
|
||||
```
|
||||
|
||||
**Session Format:**
|
||||
- **Duration**: 2-4 hours (may be split across multiple sessions)
|
||||
- **Participants**: Project team, key stakeholders, technical leads
|
||||
- **Facilitation**: Neutral facilitator to guide the process
|
||||
- **Documentation**: Dedicated scribe to capture insights and actions
|
||||
|
||||
### 3. Documentation and Integration
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef step fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef verification fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
Start([Begin Documentation<br>and Integration]) --> Draft[Draft Reflection<br>Document]
|
||||
Draft --> Review[Review with<br>Key Stakeholders]
|
||||
Review --> Revise[Incorporate<br>Feedback]
|
||||
Revise --> Finalize[Finalize<br>Document]
|
||||
Finalize --> UpdateMB[Update Memory<br>Bank]
|
||||
UpdateMB --> ActionReg[Create Action<br>Register]
|
||||
ActionReg --> Archive[Archive Project<br>Documents]
|
||||
Archive --> Verification{Documentation<br>Verification}
|
||||
Verification -->|Pass| Complete([Documentation<br>Complete])
|
||||
Verification -->|Fail| MoreRevision[Address<br>Documentation Gaps]
|
||||
MoreRevision --> Verification
|
||||
|
||||
Draft -.-> DraftDoc((Draft<br>Document))
|
||||
Finalize -.-> FinalDoc((Final<br>Reflection))
|
||||
ActionReg -.-> ActReg((Action<br>Register))
|
||||
|
||||
class Start,Complete milestone
|
||||
class Draft,Review,Revise,Finalize,UpdateMB,ActionReg,Archive,MoreRevision step
|
||||
class Verification verification
|
||||
class DraftDoc,FinalDoc,ActReg artifact
|
||||
```
|
||||
|
||||
**Key Documentation Steps:**
|
||||
1. Draft comprehensive reflection document using the template
|
||||
2. Review draft with key stakeholders and participants
|
||||
3. Incorporate feedback and finalize document
|
||||
4. Update Memory Bank with key insights and learnings
|
||||
5. Create action register for tracking improvement actions
|
||||
6. Archive project documents with reflection document
|
||||
7. Verify documentation completeness and quality
|
||||
|
||||
## 📋 REFLECTION TECHNIQUES
|
||||
|
||||
### Root Cause Analysis
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef step fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
|
||||
Start([Identify<br>Challenge]) --> What[What<br>Happened?]
|
||||
What --> When[When Did<br>It Happen?]
|
||||
When --> Where[Where Did<br>It Happen?]
|
||||
Where --> Who[Who Was<br>Involved?]
|
||||
Who --> How[How Did<br>It Happen?]
|
||||
How --> Why1[Why Did<br>It Happen?]
|
||||
Why1 --> Why2[Why?<br>Deeper]
|
||||
Why2 --> Why3[Why?<br>Deeper]
|
||||
Why3 --> Why4[Why?<br>Deeper]
|
||||
Why4 --> Why5[Why?<br>Root Cause]
|
||||
Why5 --> Solution[Identify<br>Solution]
|
||||
Solution --> Prevent[Prevention<br>Strategy]
|
||||
|
||||
class Start milestone
|
||||
class What,When,Where,Who,How,Why1,Why2,Why3,Why4,Why5,Solution,Prevent step
|
||||
```
|
||||
|
||||
### Success Analysis
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef step fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
|
||||
Start([Identify<br>Success]) --> Define[Define the<br>Success]
|
||||
Define --> Impact[Measure the<br>Impact]
|
||||
Impact --> Factors[Identify Contributing<br>Factors]
|
||||
Factors --> Context[Consider<br>Context]
|
||||
Context --> Patterns[Identify<br>Patterns]
|
||||
Patterns --> Generalize[Generalize<br>Approach]
|
||||
Generalize --> Apply[Define Where<br>to Apply]
|
||||
|
||||
class Start milestone
|
||||
class Define,Impact,Factors,Context,Patterns,Generalize,Apply step
|
||||
```
|
||||
|
||||
### Insight Generation
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef step fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
|
||||
Start([Begin Insight<br>Generation]) --> Observe[Observe<br>Patterns]
|
||||
Observe --> Question[Question<br>Assumptions]
|
||||
Question --> Connect[Connect<br>Dots]
|
||||
Connect --> Contrast[Contrast with<br>Prior Knowledge]
|
||||
Contrast --> Hypothesize[Form<br>Hypothesis]
|
||||
Hypothesize --> Test[Test<br>Hypothesis]
|
||||
Test --> Refine[Refine<br>Insight]
|
||||
Refine --> Apply[Apply to<br>Future Work]
|
||||
|
||||
class Start milestone
|
||||
class Observe,Question,Connect,Contrast,Hypothesize,Test,Refine,Apply step
|
||||
```
|
||||
|
||||
## 📋 MEMORY BANK INTEGRATION
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef memfile fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef process fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
|
||||
Reflection[Comprehensive<br>Reflection] --> PB[projectbrief.md]
|
||||
Reflection --> PC[productContext.md]
|
||||
Reflection --> AC[activeContext.md]
|
||||
Reflection --> SP[systemPatterns.md]
|
||||
Reflection --> TC[techContext.md]
|
||||
Reflection --> P[progress.md]
|
||||
|
||||
PB & PC & AC & SP & TC & P --> MBI[Memory Bank<br>Integration]
|
||||
MBI --> Next[Enhanced Future<br>Projects]
|
||||
|
||||
class PB,PC,AC,SP,TC,P memfile
|
||||
class Reflection,MBI,Next process
|
||||
```
|
||||
|
||||
### Memory Bank Updates
|
||||
|
||||
Specific updates to make to Memory Bank files:
|
||||
|
||||
1. **projectbrief.md**
|
||||
- Update with strategic insights
|
||||
- Document key achievements
|
||||
- Incorporate lessons learned
|
||||
|
||||
2. **productContext.md**
|
||||
- Update with business insights
|
||||
- Document market/user insights
|
||||
- Include value delivery insights
|
||||
|
||||
3. **activeContext.md**
|
||||
- Update with current status
|
||||
- Document action items
|
||||
- Include next steps
|
||||
|
||||
4. **systemPatterns.md**
|
||||
- Update with architectural insights
|
||||
- Document successful patterns
|
||||
- Include technical knowledge
|
||||
|
||||
5. **techContext.md**
|
||||
- Update with implementation insights
|
||||
- Document technology stack insights
|
||||
- Include performance and security insights
|
||||
|
||||
6. **progress.md**
|
||||
- Update with final status
|
||||
- Document achievements
|
||||
- Include project metrics
|
||||
|
||||
## 📋 REFLECTION VERIFICATION CHECKLIST
|
||||
|
||||
```
|
||||
✓ REFLECTION VERIFICATION CHECKLIST
|
||||
|
||||
System Review
|
||||
- System overview complete and accurate? [YES/NO]
|
||||
- Project performance metrics collected and analyzed? [YES/NO]
|
||||
- System boundaries and interfaces described? [YES/NO]
|
||||
|
||||
Success and Challenge Analysis
|
||||
- Key achievements documented with evidence? [YES/NO]
|
||||
- Technical successes documented with approach? [YES/NO]
|
||||
- Key challenges documented with resolutions? [YES/NO]
|
||||
- Technical challenges documented with solutions? [YES/NO]
|
||||
- Unresolved issues documented with path forward? [YES/NO]
|
||||
|
||||
Insight Generation
|
||||
- Technical insights extracted and documented? [YES/NO]
|
||||
- Process insights extracted and documented? [YES/NO]
|
||||
- Business insights extracted and documented? [YES/NO]
|
||||
|
||||
Strategic Planning
|
||||
- Immediate actions defined with owners? [YES/NO]
|
||||
- Short-term improvements identified? [YES/NO]
|
||||
- Medium-term initiatives planned? [YES/NO]
|
||||
- Long-term strategic directions outlined? [YES/NO]
|
||||
|
||||
Knowledge Transfer
|
||||
- Key learnings for organization documented? [YES/NO]
|
||||
- Technical knowledge transfer planned? [YES/NO]
|
||||
- Process knowledge transfer planned? [YES/NO]
|
||||
- Documentation updates identified? [YES/NO]
|
||||
|
||||
Memory Bank Integration
|
||||
- projectbrief.md updated with insights? [YES/NO]
|
||||
- productContext.md updated with insights? [YES/NO]
|
||||
- activeContext.md updated with insights? [YES/NO]
|
||||
- systemPatterns.md updated with insights? [YES/NO]
|
||||
- techContext.md updated with insights? [YES/NO]
|
||||
- progress.md updated with final status? [YES/NO]
|
||||
```
|
||||
|
||||
## 📋 MINIMAL MODE REFLECTION FORMAT
|
||||
|
||||
For situations requiring a more compact reflection:
|
||||
|
||||
```markdown
|
||||
## Level 4 Task Reflection: [System Name]
|
||||
|
||||
### System Summary
|
||||
- **Purpose**: [Brief description of system purpose]
|
||||
- **Key Components**: [List of key components]
|
||||
- **Architecture**: [Brief architecture description]
|
||||
|
||||
### Performance Summary
|
||||
- **Timeline**: [Planned] vs [Actual] ([Variance])
|
||||
- **Resources**: [Planned] vs [Actual] ([Variance])
|
||||
- **Quality**: [Summary of quality achievements]
|
||||
|
||||
### Key Successes
|
||||
1. [Success 1 with evidence and impact]
|
||||
2. [Success 2 with evidence and impact]
|
||||
3. [Success 3 with evidence and impact]
|
||||
|
||||
### Key Challenges
|
||||
1. [Challenge 1 with resolution and lessons]
|
||||
2. [Challenge 2 with resolution and lessons]
|
||||
3. [Challenge 3 with resolution and lessons]
|
||||
|
||||
### Critical Insights
|
||||
- **Technical**: [Key technical insight with recommendation]
|
||||
- **Process**: [Key process insight with recommendation]
|
||||
- **Business**: [Key business insight with recommendation]
|
||||
|
||||
### Priority Actions
|
||||
1. [Immediate action with owner and timeline]
|
||||
2. [Short-term improvement with owner and timeline]
|
||||
3. [Medium-term initiative with owner and timeline]
|
||||
|
||||
### Memory Bank Updates
|
||||
- [List of specific Memory Bank updates needed]
|
||||
```
|
||||
|
||||
## 🚨 REFLECTION ENFORCEMENT PRINCIPLE
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ COMPREHENSIVE REFLECTION IS MANDATORY for Level 4 │
|
||||
│ tasks. Archiving CANNOT proceed until reflection │
|
||||
│ is completed and verified. │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
@@ -0,0 +1,466 @@
|
||||
---
|
||||
description: Advanced task tracking for Level 4 Complex System tasks
|
||||
globs: "**/level4/**", "**/task-tracking/**"
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# ADVANCED TASK TRACKING FOR LEVEL 4 TASKS
|
||||
|
||||
> **TL;DR:** This document outlines a comprehensive task tracking approach for Level 4 (Complex System) tasks, ensuring detailed tracking of complex, multi-phase work with clear dependencies, progress tracking, and architectural alignment.
|
||||
|
||||
## 🔍 ADVANCED TASK TRACKING OVERVIEW
|
||||
|
||||
Level 4 Complex System tasks require sophisticated task tracking to manage the complexity of system development, coordinate multiple team members, track dependencies, and ensure alignment with architectural principles. This document outlines a comprehensive task tracking approach for such complex endeavors.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef phase fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef artifact fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef verification fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
Start([Begin Task<br>Tracking]) --> Framework[Establish Task<br>Framework]
|
||||
Framework --> Hierarchy[Define Task<br>Hierarchy]
|
||||
Hierarchy --> Breakdown[Create Work<br>Breakdown Structure]
|
||||
Breakdown --> Dependencies[Document<br>Dependencies]
|
||||
Dependencies --> Milestones[Define Key<br>Milestones]
|
||||
Milestones --> Schedule[Create<br>Schedule]
|
||||
Schedule --> Resources[Define Resource<br>Allocation]
|
||||
Resources --> Risks[Document<br>Risks]
|
||||
Risks --> Quality[Define Quality<br>Metrics]
|
||||
Quality --> Progress[Track<br>Progress]
|
||||
Progress --> Adaptations[Document<br>Adaptations]
|
||||
Adaptations --> Verification{Task Tracking<br>Verification}
|
||||
Verification -->|Pass| Complete([Task Tracking<br>Complete])
|
||||
Verification -->|Fail| Revise[Revise Task<br>Tracking]
|
||||
Revise --> Verification
|
||||
|
||||
Framework -.-> TF((Task<br>Framework))
|
||||
Hierarchy -.-> TH((Task<br>Hierarchy))
|
||||
Breakdown -.-> WBS((Work Breakdown<br>Structure))
|
||||
Dependencies -.-> DP((Dependency<br>Matrix))
|
||||
Milestones -.-> MS((Milestone<br>Document))
|
||||
Schedule -.-> SC((Schedule<br>Document))
|
||||
Resources -.-> RA((Resource<br>Allocation))
|
||||
Risks -.-> RM((Risk<br>Management))
|
||||
Quality -.-> QM((Quality<br>Metrics))
|
||||
Progress -.-> PT((Progress<br>Tracking))
|
||||
Adaptations -.-> AD((Adaptation<br>Document))
|
||||
|
||||
class Start,Complete milestone
|
||||
class Framework,Hierarchy,Breakdown,Dependencies,Milestones,Schedule,Resources,Risks,Quality,Progress,Adaptations,Revise step
|
||||
class Verification verification
|
||||
class TF,TH,WBS,DP,MS,SC,RA,RM,QM,PT,AD artifact
|
||||
```
|
||||
|
||||
## 📋 TASK TRACKING PRINCIPLES
|
||||
|
||||
1. **Architectural Alignment**: All tasks must align with the established architectural principles and patterns.
|
||||
2. **Hierarchical Organization**: Tasks are organized in a hierarchical structure with clear parent-child relationships.
|
||||
3. **Dependency Management**: All task dependencies are explicitly documented and tracked.
|
||||
4. **Progression Transparency**: Task status and progress are clearly documented and visible to all stakeholders.
|
||||
5. **Quality Integration**: Quality metrics and verification are integrated into task definitions.
|
||||
6. **Resource Allocation**: Tasks include clear allocation of resources required for completion.
|
||||
7. **Risk Awareness**: Each significant task includes risk assessment and mitigation strategies.
|
||||
8. **Adaptive Planning**: Task tracking accommodates changes and adaptations while maintaining system integrity.
|
||||
9. **Milestone Tracking**: Clear milestones are defined and used to track overall progress.
|
||||
10. **Comprehensive Documentation**: All aspects of the task lifecycle are documented thoroughly.
|
||||
|
||||
## 📋 TASK HIERARCHY STRUCTURE
|
||||
|
||||
Level 4 tasks follow a hierarchical structure:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef system fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef component fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
classDef feature fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
classDef task fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef subtask fill:#d8c1f7,stroke:#b8a1d7,color:#000
|
||||
|
||||
System[System-Level Work] --> Component1[Component 1]
|
||||
System --> Component2[Component 2]
|
||||
System --> Component3[Component 3]
|
||||
|
||||
Component1 --> Feature1[Feature 1.1]
|
||||
Component1 --> Feature2[Feature 1.2]
|
||||
|
||||
Feature1 --> Task1[Task 1.1.1]
|
||||
Feature1 --> Task2[Task 1.1.2]
|
||||
|
||||
Task1 --> Subtask1[Subtask 1.1.1.1]
|
||||
Task1 --> Subtask2[Subtask 1.1.1.2]
|
||||
Task1 --> Subtask3[Subtask 1.1.1.3]
|
||||
|
||||
class System system
|
||||
class Component1,Component2,Component3 component
|
||||
class Feature1,Feature2 feature
|
||||
class Task1,Task2 task
|
||||
class Subtask1,Subtask2,Subtask3 subtask
|
||||
```
|
||||
|
||||
### Levels of Hierarchy:
|
||||
|
||||
1. **System Level**: The overall system being built or modified.
|
||||
2. **Component Level**: Major components or subsystems of the system.
|
||||
3. **Feature Level**: Specific features within each component.
|
||||
4. **Task Level**: Concrete tasks required to implement a feature.
|
||||
5. **Subtask Level**: Detailed subtasks for complex tasks.
|
||||
|
||||
## 📋 COMPREHENSIVE TASK STRUCTURE
|
||||
|
||||
Each Level 4 task in `tasks.md` follows this comprehensive structure:
|
||||
|
||||
```markdown
|
||||
## [SYSTEM-ID]: System Name
|
||||
|
||||
### System Overview
|
||||
- **Purpose**: [Brief description of system purpose]
|
||||
- **Architectural Alignment**: [How the system aligns with architectural principles]
|
||||
- **Status**: [Planning/In Progress/Review/Complete]
|
||||
- **Milestones**:
|
||||
- Milestone 1: [Date] - [Status]
|
||||
- Milestone 2: [Date] - [Status]
|
||||
- Milestone 3: [Date] - [Status]
|
||||
|
||||
### Components
|
||||
#### [COMP-ID]: Component Name
|
||||
- **Purpose**: [Brief description of component purpose]
|
||||
- **Status**: [Planning/In Progress/Review/Complete]
|
||||
- **Dependencies**: [List of dependencies]
|
||||
- **Responsible**: [Team or individual responsible]
|
||||
|
||||
##### [FEAT-ID]: Feature Name
|
||||
- **Description**: [Feature description]
|
||||
- **Status**: [Planning/In Progress/Review/Complete]
|
||||
- **Priority**: [Critical/High/Medium/Low]
|
||||
- **Related Requirements**: [List of requirements IDs this feature addresses]
|
||||
- **Quality Criteria**: [Measurable criteria for completion]
|
||||
- **Progress**: [0-100%]
|
||||
|
||||
###### [TASK-ID]: Task Name
|
||||
- **Description**: [Task description]
|
||||
- **Status**: [TODO/In Progress/Review/Done]
|
||||
- **Assigned To**: [Assignee]
|
||||
- **Estimated Effort**: [Effort estimate]
|
||||
- **Actual Effort**: [Actual effort]
|
||||
- **Dependencies**: [Tasks this depends on]
|
||||
- **Blocks**: [Tasks blocked by this]
|
||||
- **Risk Assessment**: [Risk level and description]
|
||||
- **Quality Gates**: [Quality gates this must pass]
|
||||
- **Implementation Notes**: [Key implementation notes]
|
||||
|
||||
**Subtasks**:
|
||||
- [ ] [SUB-ID]: [Subtask description] - [Status]
|
||||
- [ ] [SUB-ID]: [Subtask description] - [Status]
|
||||
- [ ] [SUB-ID]: [Subtask description] - [Status]
|
||||
|
||||
### System-Wide Tasks
|
||||
- [ ] [SYS-TASK-ID]: [System-wide task description] - [Status]
|
||||
- [ ] [SYS-TASK-ID]: [System-wide task description] - [Status]
|
||||
|
||||
### Risks and Mitigations
|
||||
- **Risk 1**: [Description] - **Mitigation**: [Mitigation strategy]
|
||||
- **Risk 2**: [Description] - **Mitigation**: [Mitigation strategy]
|
||||
|
||||
### Progress Summary
|
||||
- **Overall Progress**: [0-100%]
|
||||
- **Component 1**: [0-100%]
|
||||
- **Component 2**: [0-100%]
|
||||
- **Component 3**: [0-100%]
|
||||
|
||||
### Latest Updates
|
||||
- [Date]: [Update description]
|
||||
- [Date]: [Update description]
|
||||
```
|
||||
|
||||
## 📋 TASK TRACKING ORGANIZATION IN TASKS.MD
|
||||
|
||||
For Level 4 Complex System tasks, organize `tasks.md` as follows:
|
||||
|
||||
```markdown
|
||||
# TASK TRACKING
|
||||
|
||||
## ACTIVE SYSTEMS
|
||||
- [SYSTEM-ID]: [System Name] - [Status]
|
||||
- [SYSTEM-ID]: [System Name] - [Status]
|
||||
|
||||
## SYSTEM DETAILS
|
||||
|
||||
[Detailed task structure for each system as per the template above]
|
||||
|
||||
## COMPLETED SYSTEMS
|
||||
- [SYSTEM-ID]: [System Name] - Completed [Date]
|
||||
- [SYSTEM-ID]: [System Name] - Completed [Date]
|
||||
|
||||
## SYSTEM DEPENDENCIES
|
||||
```mermaid
|
||||
graph TD
|
||||
System1 --> System2
|
||||
System1 --> System3
|
||||
System2 --> System4
|
||||
```
|
||||
|
||||
## RISK REGISTER
|
||||
| Risk ID | Description | Probability | Impact | Mitigation |
|
||||
|---------|-------------|-------------|--------|------------|
|
||||
| RISK-01 | [Description] | High/Med/Low | High/Med/Low | [Strategy] |
|
||||
| RISK-02 | [Description] | High/Med/Low | High/Med/Low | [Strategy] |
|
||||
|
||||
## RESOURCE ALLOCATION
|
||||
| Resource | System | Allocation % | Time Period |
|
||||
|----------|--------|--------------|------------|
|
||||
| [Name/Team] | [System-ID] | [%] | [Start-End] |
|
||||
| [Name/Team] | [System-ID] | [%] | [Start-End] |
|
||||
```
|
||||
|
||||
## 📋 DEPENDENCY MANAGEMENT
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef critical fill:#f8707e,stroke:#d85060,color:#000
|
||||
classDef high fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
classDef medium fill:#a8d5ff,stroke:#88b5e0,color:#000
|
||||
classDef low fill:#c5e8b7,stroke:#a5c897,color:#000
|
||||
|
||||
Task1[Task 1] --> Task2[Task 2]
|
||||
Task1 --> Task3[Task 3]
|
||||
Task2 --> Task4[Task 4]
|
||||
Task3 --> Task4
|
||||
Task4 --> Task5[Task 5]
|
||||
Task4 --> Task6[Task 6]
|
||||
Task5 --> Task7[Task 7]
|
||||
Task6 --> Task7
|
||||
|
||||
class Task1,Task4,Task7 critical
|
||||
class Task2,Task5 high
|
||||
class Task3 medium
|
||||
class Task6 low
|
||||
```
|
||||
|
||||
For complex systems, document dependencies in a dedicated section:
|
||||
|
||||
```markdown
|
||||
## Dependency Matrix
|
||||
|
||||
| Task ID | Depends On | Blocks | Type | Status |
|
||||
|---------|------------|--------|------|--------|
|
||||
| TASK-01 | - | TASK-02, TASK-03 | Technical | Completed |
|
||||
| TASK-02 | TASK-01 | TASK-04 | Technical | In Progress |
|
||||
| TASK-03 | TASK-01 | TASK-04 | Resource | Not Started |
|
||||
| TASK-04 | TASK-02, TASK-03 | TASK-05, TASK-06 | Technical | Not Started |
|
||||
```
|
||||
|
||||
### Dependency Types:
|
||||
- **Technical**: One task technically requires another to be completed first
|
||||
- **Resource**: Tasks compete for the same resources
|
||||
- **Information**: One task requires information produced by another
|
||||
- **Architectural**: Tasks have architectural dependencies
|
||||
- **Temporal**: Tasks must be completed in a specific time sequence
|
||||
|
||||
## 📋 MILESTONE TRACKING
|
||||
|
||||
For Level 4 tasks, track milestones explicitly:
|
||||
|
||||
```markdown
|
||||
## System Milestones
|
||||
|
||||
| Milestone ID | Description | Target Date | Actual Date | Status | Deliverables |
|
||||
|--------------|-------------|-------------|-------------|--------|--------------|
|
||||
| MILE-01 | Architecture Approved | [Date] | [Date] | Completed | Architecture Document |
|
||||
| MILE-02 | Component Design Completed | [Date] | - | In Progress | Design Documents |
|
||||
| MILE-03 | Component 1 Implementation | [Date] | - | Not Started | Code, Tests |
|
||||
| MILE-04 | Integration Complete | [Date] | - | Not Started | Integrated System |
|
||||
| MILE-05 | System Testing Complete | [Date] | - | Not Started | Test Reports |
|
||||
| MILE-06 | Deployment Ready | [Date] | - | Not Started | Deployment Package |
|
||||
```
|
||||
|
||||
## 📋 PROGRESS VISUALIZATION
|
||||
|
||||
Include visual representations of progress in `tasks.md`:
|
||||
|
||||
```markdown
|
||||
## Progress Visualization
|
||||
|
||||
### Overall System Progress
|
||||
```mermaid
|
||||
pie title System Progress
|
||||
"Completed" : 30
|
||||
"In Progress" : 25
|
||||
"Not Started" : 45
|
||||
```
|
||||
|
||||
### Component Progress
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph Progress
|
||||
C1[Component 1: 75%]
|
||||
C2[Component 2: 50%]
|
||||
C3[Component 3: 20%]
|
||||
C4[Component 4: 5%]
|
||||
end
|
||||
```
|
||||
|
||||
### Timeline
|
||||
```mermaid
|
||||
gantt
|
||||
title System Timeline
|
||||
dateFormat YYYY-MM-DD
|
||||
|
||||
section Architecture
|
||||
Architecture Design :done, arch, 2023-01-01, 30d
|
||||
Architecture Review :done, arch-rev, after arch, 10d
|
||||
|
||||
section Component 1
|
||||
Design :active, c1-des, after arch-rev, 20d
|
||||
Implementation :c1-imp, after c1-des, 40d
|
||||
Testing :c1-test, after c1-imp, 15d
|
||||
|
||||
section Component 2
|
||||
Design :active, c2-des, after arch-rev, 25d
|
||||
Implementation :c2-imp, after c2-des, 50d
|
||||
Testing :c2-test, after c2-imp, 20d
|
||||
```
|
||||
```
|
||||
|
||||
## 📋 UPDATING TASK STATUS
|
||||
|
||||
For Level 4 tasks, status updates include:
|
||||
|
||||
1. **Progress Updates**: Update task status and progress percentage
|
||||
2. **Effort Tracking**: Record actual effort against estimates
|
||||
3. **Risk Updates**: Update risk assessments and mitigations
|
||||
4. **Dependency Status**: Update status of dependencies
|
||||
5. **Milestone Tracking**: Update milestone status
|
||||
6. **Issue Documentation**: Document issues encountered
|
||||
7. **Adaptation Documentation**: Document any adaptations to the original plan
|
||||
8. **Quality Gate Status**: Update status of quality gates
|
||||
|
||||
Status update cycle:
|
||||
- **Daily**: Update task and subtask status
|
||||
- **Weekly**: Update component status and progress visualization
|
||||
- **Bi-weekly**: Update system-level progress and milestone status
|
||||
- **Monthly**: Complete system review including risks and adaptations
|
||||
|
||||
## 📋 TASK TRACKING VERIFICATION CHECKLIST
|
||||
|
||||
```
|
||||
✓ TASK TRACKING VERIFICATION CHECKLIST
|
||||
|
||||
Task Structure
|
||||
- System level work properly defined? [YES/NO]
|
||||
- Component level tasks identified? [YES/NO]
|
||||
- Feature level tasks specified? [YES/NO]
|
||||
- Task level details provided? [YES/NO]
|
||||
- Subtasks created for complex tasks? [YES/NO]
|
||||
|
||||
Task Information
|
||||
- All tasks have clear descriptions? [YES/NO]
|
||||
- Status accurately reflected? [YES/NO]
|
||||
- Proper assignments made? [YES/NO]
|
||||
- Effort estimates provided? [YES/NO]
|
||||
- Dependencies documented? [YES/NO]
|
||||
|
||||
Progress Tracking
|
||||
- Overall progress calculated? [YES/NO]
|
||||
- Component progress updated? [YES/NO]
|
||||
- Milestone status updated? [YES/NO]
|
||||
- Progress visualizations current? [YES/NO]
|
||||
- Latest updates documented? [YES/NO]
|
||||
|
||||
Risk Management
|
||||
- Risks identified and assessed? [YES/NO]
|
||||
- Mitigation strategies documented? [YES/NO]
|
||||
- Risk register updated? [YES/NO]
|
||||
- Impact on schedule assessed? [YES/NO]
|
||||
- Contingency plans documented? [YES/NO]
|
||||
|
||||
Resource Allocation
|
||||
- Resources allocated to tasks? [YES/NO]
|
||||
- Resource conflicts identified? [YES/NO]
|
||||
- Resource allocation optimized? [YES/NO]
|
||||
- Future resource needs projected? [YES/NO]
|
||||
- Resource allocation documented? [YES/NO]
|
||||
|
||||
Quality Integration
|
||||
- Quality criteria defined for tasks? [YES/NO]
|
||||
- Quality gates specified? [YES/NO]
|
||||
- Verification procedures documented? [YES/NO]
|
||||
- Quality metrics being tracked? [YES/NO]
|
||||
- Quality issues documented? [YES/NO]
|
||||
|
||||
Architectural Alignment
|
||||
- Tasks align with architecture? [YES/NO]
|
||||
- Architectural dependencies tracked? [YES/NO]
|
||||
- Architectural constraints documented? [YES/NO]
|
||||
- Architecture evolution tracked? [YES/NO]
|
||||
- Architectural decisions documented? [YES/NO]
|
||||
```
|
||||
|
||||
## 📋 INTEGRATION WITH MEMORY BANK
|
||||
|
||||
Level 4 task tracking is tightly integrated with the Memory Bank:
|
||||
|
||||
1. **projectbrief.md**: System-level tasks are derived from and linked to the project brief
|
||||
2. **productContext.md**: Tasks are aligned with business context and objectives
|
||||
3. **systemPatterns.md**: Tasks respect and implement defined architectural patterns
|
||||
4. **techContext.md**: Tasks are aligned with the technology stack and constraints
|
||||
5. **activeContext.md**: Current focus and status from `tasks.md` informs the active context
|
||||
6. **progress.md**: System progress from `tasks.md` is reflected in overall progress
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
classDef memfile fill:#f4b8c4,stroke:#d498a4,color:#000
|
||||
classDef process fill:#f9d77e,stroke:#d9b95c,color:#000
|
||||
|
||||
TaskTracking[Advanced Task<br>Tracking] --> PB[projectbrief.md]
|
||||
TaskTracking --> PC[productContext.md]
|
||||
TaskTracking --> AC[activeContext.md]
|
||||
TaskTracking --> SP[systemPatterns.md]
|
||||
TaskTracking --> TC[techContext.md]
|
||||
TaskTracking --> P[progress.md]
|
||||
|
||||
P --> TU[Task<br>Updates]
|
||||
TU --> TaskTracking
|
||||
|
||||
class PB,PC,AC,SP,TC,P memfile
|
||||
class TaskTracking,TU process
|
||||
```
|
||||
|
||||
## 📋 MINIMAL MODE TASK TRACKING
|
||||
|
||||
For situations requiring a more compact tracking approach:
|
||||
|
||||
```markdown
|
||||
## [SYSTEM-ID]: System Name - [Status]
|
||||
|
||||
### Key Components:
|
||||
- [COMP-ID]: [Component Name] - [Status] - [Progress %]
|
||||
- [COMP-ID]: [Component Name] - [Status] - [Progress %]
|
||||
|
||||
### Active Tasks:
|
||||
- [ ] [TASK-ID]: [Task Description] - [Assignee] - [Status]
|
||||
- Dependencies: [List of task IDs]
|
||||
- Risks: [Brief risk description]
|
||||
- [ ] [TASK-ID]: [Task Description] - [Assignee] - [Status]
|
||||
|
||||
### Milestones:
|
||||
- [MILE-ID]: [Milestone description] - [Target Date] - [Status]
|
||||
- [MILE-ID]: [Milestone description] - [Target Date] - [Status]
|
||||
|
||||
### Critical Paths:
|
||||
- [TASK-ID] → [TASK-ID] → [TASK-ID] → [TASK-ID]
|
||||
- [TASK-ID] → [TASK-ID] → [TASK-ID]
|
||||
|
||||
### Updates:
|
||||
- [Date]: [Brief update]
|
||||
```
|
||||
|
||||
## 🚨 TASK TRACKING PRIMACY PRINCIPLE
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ tasks.md is the SINGLE SOURCE OF TRUTH for all task │
|
||||
│ tracking. All task-related decisions and status │
|
||||
│ updates MUST be reflected in tasks.md. │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
@@ -0,0 +1,424 @@
|
||||
---
|
||||
description: Comprehensive workflow for Level 4 Complex System tasks
|
||||
globs: "**/level4/**", "**/workflow/**"
|
||||
alwaysApply: false
|
||||
---
|
||||
# COMPREHENSIVE WORKFLOW FOR LEVEL 4 TASKS
|
||||
|
||||
> **TL;DR:** This document outlines a comprehensive workflow for Level 4 (Complex System) tasks, including 7 key phases with rigorous planning, mandatory creative phases, architectural design, phased implementation, and extensive documentation.
|
||||
|
||||
## 🔍 LEVEL 4 WORKFLOW OVERVIEW
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
Init["1. INITIALIZATION"] --> Doc["2. DOCUMENTATION<br>SETUP"]
|
||||
Doc --> Plan["3. ARCHITECTURAL<br>PLANNING"]
|
||||
Plan --> Create["4. CREATIVE<br>PHASES"]
|
||||
Create --> Impl["5. PHASED<br>IMPLEMENTATION"]
|
||||
Impl --> Reflect["6. REFLECTION"]
|
||||
Reflect --> Archive["7. ARCHIVING"]
|
||||
|
||||
%% Document connections for each phase
|
||||
Init -.-> InitDocs["INITIALIZATION"]
|
||||
Doc -.-> DocDocs["DOCUMENTATION"]
|
||||
Plan -.-> PlanDocs["ARCHITECTURAL PLANNING"]
|
||||
Create -.-> CreateDocs["CREATIVE PHASES"]
|
||||
Impl -.-> ImplDocs["PHASED IMPLEMENTATION"]
|
||||
Reflect -.-> ReflectDocs["REFLECTION"]
|
||||
Archive -.-> ArchiveDocs["ARCHIVING"]
|
||||
```
|
||||
|
||||
## 🔄 LEVEL TRANSITION HANDLING
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
L4["Level 4 Task"] --> Assess["Continuous<br>Assessment"]
|
||||
|
||||
Assess --> Down["Downgrade to<br>Level 2/3"]
|
||||
Assess --> Split["Split into<br>Multiple Tasks"]
|
||||
|
||||
Down --> L23Trigger["Triggers:<br>- Less complex<br>- Limited scope<br>- Few components"]
|
||||
|
||||
Split --> MultiTrigger["Triggers:<br>- Too large<br>- Independent parts<br>- Parallel possible"]
|
||||
|
||||
L23Trigger --> L23Switch["Switch to<br>Level 2/3 Workflow"]
|
||||
MultiTrigger --> CreateTasks["Create Multiple<br>Lower Level Tasks"]
|
||||
```
|
||||
|
||||
Level 4 tasks involve complex systems that require comprehensive planning, rigorous design, systematic implementation, and thorough documentation. This workflow ensures all aspects are addressed with the appropriate level of detail, structure, and verification.
|
||||
|
||||
## 📋 WORKFLOW PHASES
|
||||
|
||||
### Phase 1: INITIALIZATION
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Start["Start Level 4 Task"] --> Platform{"Detect<br>Platform"}
|
||||
Platform --> FileCheck["Critical File<br>Verification"]
|
||||
FileCheck --> LoadStructure["Comprehensive Memory<br>Bank Structure Loading"]
|
||||
LoadStructure --> TaskCreation["Create Detailed<br>Task Framework"]
|
||||
TaskCreation --> Context["Establish Enterprise<br>Context"]
|
||||
Context --> Resources["Identify and Allocate<br>All Resources"]
|
||||
Resources --> SetupComplete["Initialization<br>Complete"]
|
||||
```
|
||||
|
||||
**Steps:**
|
||||
1. Platform detection with comprehensive environment configuration
|
||||
2. Critical file verification with in-depth integrity checks
|
||||
3. Comprehensive Memory Bank structure loading with full reference mapping
|
||||
4. Create detailed task framework in tasks.md with full structure
|
||||
5. Establish complete enterprise context and stakeholder requirements
|
||||
6. Identify and allocate all necessary resources (technical, human, time)
|
||||
7. Perform system readiness assessment
|
||||
|
||||
**Milestone Checkpoint:**
|
||||
```
|
||||
✓ INITIALIZATION CHECKPOINT
|
||||
- Platform detected and fully configured? [YES/NO]
|
||||
- Critical files verified with integrity checks? [YES/NO]
|
||||
- Memory Bank comprehensively loaded and mapped? [YES/NO]
|
||||
- Detailed task framework created? [YES/NO]
|
||||
- Enterprise context established? [YES/NO]
|
||||
- Stakeholder requirements documented? [YES/NO]
|
||||
- All resources identified and allocated? [YES/NO]
|
||||
- System readiness assessed? [YES/NO]
|
||||
|
||||
→ If all YES: Proceed to Documentation Setup
|
||||
→ If any NO: Complete initialization steps
|
||||
```
|
||||
|
||||
### Phase 2: DOCUMENTATION SETUP
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Start["Begin Documentation<br>Setup"] --> LoadTemplate["Load Comprehensive<br>Documentation Templates"]
|
||||
LoadTemplate --> Framework["Establish Documentation<br>Framework"]
|
||||
Framework --> UpdateProject["Update<br>projectbrief.md"]
|
||||
UpdateProject --> UpdateContext["Update<br>activeContext.md"]
|
||||
UpdateContext --> SystemPatterns["Update<br>systemPatterns.md"]
|
||||
SystemPatterns --> TechContext["Update<br>techContext.md"]
|
||||
TechContext --> Standards["Document System<br>Standards"]
|
||||
Standards --> Architecture["Document Existing<br>Architecture"]
|
||||
Architecture --> SetupComplete["Documentation<br>Setup Complete"]
|
||||
```
|
||||
|
||||
**Steps:**
|
||||
1. Load comprehensive documentation templates for all aspects
|
||||
2. Establish complete documentation framework with structure
|
||||
3. Update projectbrief.md with detailed system description and requirements
|
||||
4. Update activeContext.md with current focus, dependencies, and stakeholders
|
||||
5. Update systemPatterns.md with comprehensive patterns and principles
|
||||
6. Update techContext.md with complete technical landscape
|
||||
7. Document system standards, constraints, and conventions
|
||||
8. Document existing architecture and integration points
|
||||
|
||||
**Milestone Checkpoint:**
|
||||
```
|
||||
✓ DOCUMENTATION CHECKPOINT
|
||||
- Documentation templates loaded? [YES/NO]
|
||||
- Documentation framework established? [YES/NO]
|
||||
- projectbrief.md comprehensively updated? [YES/NO]
|
||||
- activeContext.md fully updated? [YES/NO]
|
||||
- systemPatterns.md comprehensively updated? [YES/NO]
|
||||
- techContext.md fully updated? [YES/NO]
|
||||
- System standards documented? [YES/NO]
|
||||
- Existing architecture documented? [YES/NO]
|
||||
|
||||
→ If all YES: Proceed to Architectural Planning
|
||||
→ If any NO: Complete documentation setup
|
||||
```
|
||||
|
||||
### Phase 3: ARCHITECTURAL PLANNING
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Start["Begin Architectural<br>Planning"] --> Requirements["Analyze Comprehensive<br>Requirements"]
|
||||
Requirements --> BusinessContext["Document Business<br>Context"]
|
||||
BusinessContext --> VisionDefine["Define Vision<br>and Goals"]
|
||||
VisionDefine --> ArchitecturalPrinciples["Establish Architectural<br>Principles"]
|
||||
ArchitecturalPrinciples --> Alternatives["Explore Architectural<br>Alternatives"]
|
||||
Alternatives --> Evaluation["Perform Detailed<br>Evaluation"]
|
||||
Evaluation --> Selection["Make Architecture<br>Selection"]
|
||||
Selection --> Documentation["Create Architecture<br>Documentation"]
|
||||
Documentation --> Review["Conduct Architecture<br>Review"]
|
||||
Review --> PlanComplete["Architectural Planning<br>Complete"]
|
||||
```
|
||||
|
||||
**Steps:**
|
||||
1. Analyze comprehensive requirements with traceability
|
||||
2. Document complete business context and constraints
|
||||
3. Define clear vision and goals with measurable objectives
|
||||
4. Establish architectural principles and non-functional requirements
|
||||
5. Explore multiple architectural alternatives with thorough analysis
|
||||
6. Perform detailed evaluation using weighted criteria
|
||||
7. Make architecture selection with comprehensive justification
|
||||
8. Create complete architecture documentation with diagrams
|
||||
9. Conduct formal architecture review with stakeholders
|
||||
|
||||
**Milestone Checkpoint:**
|
||||
```
|
||||
✓ ARCHITECTURAL PLANNING CHECKPOINT
|
||||
- Requirements comprehensively analyzed? [YES/NO]
|
||||
- Business context fully documented? [YES/NO]
|
||||
- Vision and goals clearly defined? [YES/NO]
|
||||
- Architectural principles established? [YES/NO]
|
||||
- Alternatives thoroughly explored? [YES/NO]
|
||||
- Detailed evaluation performed? [YES/NO]
|
||||
- Architecture selection justified? [YES/NO]
|
||||
- Architecture documentation complete? [YES/NO]
|
||||
- Architecture review conducted? [YES/NO]
|
||||
|
||||
→ If all YES: Proceed to Creative Phases
|
||||
→ If any NO: Complete architectural planning
|
||||
```
|
||||
|
||||
### Phase 4: CREATIVE PHASES
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Start["Begin Creative<br>Phases"] --> IdentifyNeeds["Identify Creative<br>Phase Needs"]
|
||||
IdentifyNeeds --> Architecture["Architecture<br>Design Phase"]
|
||||
Architecture --> Algorithm["Algorithm<br>Design Phase"]
|
||||
Algorithm --> UIUX["UI/UX<br>Design Phase"]
|
||||
UIUX --> Integration["Integration<br>Design Phase"]
|
||||
Integration --> Security["Security<br>Design Phase"]
|
||||
Security --> Performance["Performance<br>Design Phase"]
|
||||
Performance --> Resilience["Resilience<br>Design Phase"]
|
||||
Resilience --> Documentation["Comprehensive<br>Design Documentation"]
|
||||
Documentation --> Review["Design<br>Review"]
|
||||
Review --> CreativeComplete["Creative Phases<br>Complete"]
|
||||
```
|
||||
|
||||
**Steps:**
|
||||
1. Identify all required creative phases based on system needs
|
||||
2. Execute comprehensive Architecture Design with patterns and principles
|
||||
3. Conduct thorough Algorithm Design for all complex processes
|
||||
4. Perform detailed UI/UX Design with user research and testing
|
||||
5. Create Integration Design for all system interfaces
|
||||
6. Develop Security Design with threat modeling
|
||||
7. Design for Performance with capacity planning
|
||||
8. Plan for Resilience with failure modes and recovery
|
||||
9. Create comprehensive design documentation for all aspects
|
||||
10. Conduct formal design review with stakeholders
|
||||
|
||||
**Milestone Checkpoint:**
|
||||
```
|
||||
✓ CREATIVE PHASES CHECKPOINT
|
||||
- All required creative phases identified? [YES/NO]
|
||||
- Architecture design completed with patterns? [YES/NO]
|
||||
- Algorithm design conducted for complex processes? [YES/NO]
|
||||
- UI/UX design performed with user research? [YES/NO]
|
||||
- Integration design created for interfaces? [YES/NO]
|
||||
- Security design developed with threat modeling? [YES/NO]
|
||||
- Performance design completed with capacity planning? [YES/NO]
|
||||
- Resilience design planned with failure modes? [YES/NO]
|
||||
- Comprehensive design documentation created? [YES/NO]
|
||||
- Formal design review conducted? [YES/NO]
|
||||
|
||||
→ If all YES: Proceed to Phased Implementation
|
||||
→ If any NO: Complete creative phases
|
||||
```
|
||||
|
||||
### Phase 5: PHASED IMPLEMENTATION
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Start["Begin Phased<br>Implementation"] --> PrepEnv["Prepare Comprehensive<br>Implementation Environment"]
|
||||
PrepEnv --> Framework["Establish Implementation<br>Framework"]
|
||||
Framework --> RoadmapDefine["Define Implementation<br>Roadmap"]
|
||||
RoadmapDefine --> PhaseImplementation["Implement<br>Sequential Phases"]
|
||||
PhaseImplementation --> PhaseVerification["Verify Each<br>Phase"]
|
||||
PhaseVerification --> Integration["Perform Integration<br>Testing"]
|
||||
Integration --> SystemTest["Conduct System<br>Testing"]
|
||||
SystemTest --> UAT["User Acceptance<br>Testing"]
|
||||
UAT --> Stabilization["System<br>Stabilization"]
|
||||
Stabilization --> ImplComplete["Implementation<br>Complete"]
|
||||
```
|
||||
|
||||
**Steps:**
|
||||
1. Prepare comprehensive implementation environment with all tools
|
||||
2. Establish implementation framework with standards and processes
|
||||
3. Define detailed implementation roadmap with phases and dependencies
|
||||
4. Implement sequential phases with milestone verification
|
||||
5. Verify each phase against requirements and design
|
||||
6. Perform comprehensive integration testing across phases
|
||||
7. Conduct thorough system testing of the complete solution
|
||||
8. Execute formal user acceptance testing with stakeholders
|
||||
9. Perform system stabilization and performance tuning
|
||||
10. Document all implementation details and deployment procedures
|
||||
|
||||
**Milestone Checkpoint:**
|
||||
```
|
||||
✓ PHASED IMPLEMENTATION CHECKPOINT
|
||||
- Implementation environment fully prepared? [YES/NO]
|
||||
- Implementation framework established? [YES/NO]
|
||||
- Detailed roadmap defined with phases? [YES/NO]
|
||||
- All phases sequentially implemented? [YES/NO]
|
||||
- Each phase verified against requirements? [YES/NO]
|
||||
- Comprehensive integration testing performed? [YES/NO]
|
||||
- Thorough system testing conducted? [YES/NO]
|
||||
- User acceptance testing executed? [YES/NO]
|
||||
- System stabilization completed? [YES/NO]
|
||||
- Implementation details documented? [YES/NO]
|
||||
|
||||
→ If all YES: Proceed to Reflection
|
||||
→ If any NO: Complete implementation steps
|
||||
```
|
||||
|
||||
### Phase 6: REFLECTION
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Start["Begin<br>Reflection"] --> Template["Load Comprehensive<br>Reflection Template"]
|
||||
Template --> SystemReview["Complete System<br>Review"]
|
||||
SystemReview --> Process["Analyze Process<br>Effectiveness"]
|
||||
Process --> Success["Document Successes<br>with Evidence"]
|
||||
Success --> Challenges["Document Challenges<br>with Solutions"]
|
||||
Challenges --> TechnicalInsights["Extract Strategic<br>Technical Insights"]
|
||||
TechnicalInsights --> ProcessInsights["Extract Process<br>Improvement Insights"]
|
||||
ProcessInsights --> BusinessInsights["Document Business<br>Impact"]
|
||||
BusinessInsights --> StrategicActions["Define Strategic<br>Action Items"]
|
||||
StrategicActions --> ReflectComplete["Reflection<br>Complete"]
|
||||
```
|
||||
|
||||
**Steps:**
|
||||
1. Load comprehensive reflection template with all sections
|
||||
2. Conduct complete system review against original goals
|
||||
3. Analyze process effectiveness with metrics
|
||||
4. Document successes with concrete evidence and impact
|
||||
5. Document challenges with implemented solutions and lessons
|
||||
6. Extract strategic technical insights for enterprise knowledge
|
||||
7. Extract process improvement insights for future projects
|
||||
8. Document business impact and value delivered
|
||||
9. Define strategic action items with prioritization
|
||||
10. Create comprehensive reflection documentation
|
||||
|
||||
**Milestone Checkpoint:**
|
||||
```
|
||||
✓ REFLECTION CHECKPOINT
|
||||
- Comprehensive reflection template loaded? [YES/NO]
|
||||
- Complete system review conducted? [YES/NO]
|
||||
- Process effectiveness analyzed? [YES/NO]
|
||||
- Successes documented with evidence? [YES/NO]
|
||||
- Challenges documented with solutions? [YES/NO]
|
||||
- Strategic technical insights extracted? [YES/NO]
|
||||
- Process improvement insights extracted? [YES/NO]
|
||||
- Business impact documented? [YES/NO]
|
||||
- Strategic action items defined? [YES/NO]
|
||||
- Comprehensive reflection documentation created? [YES/NO]
|
||||
|
||||
→ If all YES: Proceed to Archiving
|
||||
→ If any NO: Complete reflection steps
|
||||
```
|
||||
|
||||
### Phase 7: ARCHIVING
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Start["Begin<br>Archiving"] --> Template["Load Comprehensive<br>Archive Template"]
|
||||
Template --> SystemDoc["Create System<br>Documentation"]
|
||||
SystemDoc --> Architecture["Document Final<br>Architecture"]
|
||||
Architecture --> Design["Compile Design<br>Decisions"]
|
||||
Design --> Implementation["Document Implementation<br>Details"]
|
||||
Implementation --> Testing["Compile Testing<br>Documentation"]
|
||||
Testing --> Deployment["Create Deployment<br>Documentation"]
|
||||
Deployment --> Maintenance["Prepare Maintenance<br>Guide"]
|
||||
Maintenance --> Knowledge["Transfer Knowledge<br>to Stakeholders"]
|
||||
Knowledge --> Archive["Create Comprehensive<br>Archive Package"]
|
||||
Archive --> ArchiveComplete["Archiving<br>Complete"]
|
||||
```
|
||||
|
||||
**Steps:**
|
||||
1. Load comprehensive archive template with all sections
|
||||
2. Create complete system documentation with all aspects
|
||||
3. Document final architecture with diagrams and rationales
|
||||
4. Compile all design decisions with justifications
|
||||
5. Document all implementation details with technical specifics
|
||||
6. Compile comprehensive testing documentation with results
|
||||
7. Create detailed deployment documentation with procedures
|
||||
8. Prepare maintenance guide with operational procedures
|
||||
9. Transfer knowledge to all stakeholders with training
|
||||
10. Create comprehensive archive package with all artifacts
|
||||
|
||||
**Milestone Checkpoint:**
|
||||
```
|
||||
✓ ARCHIVING CHECKPOINT
|
||||
- Comprehensive archive template loaded? [YES/NO]
|
||||
- Complete system documentation created? [YES/NO]
|
||||
- Final architecture documented? [YES/NO]
|
||||
- Design decisions compiled? [YES/NO]
|
||||
- Implementation details documented? [YES/NO]
|
||||
- Testing documentation compiled? [YES/NO]
|
||||
- Deployment documentation created? [YES/NO]
|
||||
- Maintenance guide prepared? [YES/NO]
|
||||
- Knowledge transferred to stakeholders? [YES/NO]
|
||||
- Comprehensive archive package created? [YES/NO]
|
||||
|
||||
→ If all YES: Task Complete
|
||||
→ If any NO: Complete archiving steps
|
||||
```
|
||||
|
||||
## 📋 WORKFLOW VERIFICATION CHECKLIST
|
||||
|
||||
```
|
||||
✓ FINAL WORKFLOW VERIFICATION
|
||||
- All 7 phases completed? [YES/NO]
|
||||
- All milestone checkpoints passed? [YES/NO]
|
||||
- Architectural planning properly executed? [YES/NO]
|
||||
- All required creative phases completed? [YES/NO]
|
||||
- Implementation performed in proper phases? [YES/NO]
|
||||
- Comprehensive reflection conducted? [YES/NO]
|
||||
- Complete system documentation archived? [YES/NO]
|
||||
- Memory Bank fully updated? [YES/NO]
|
||||
- Knowledge successfully transferred? [YES/NO]
|
||||
|
||||
→ If all YES: Level 4 Task Successfully Completed
|
||||
→ If any NO: Address outstanding items
|
||||
```
|
||||
|
||||
## 📋 MINIMAL MODE WORKFLOW
|
||||
|
||||
For minimal mode, use this streamlined workflow while retaining key elements:
|
||||
|
||||
```
|
||||
1. INIT: Verify environment, create structured task framework, establish context
|
||||
2. DOCS: Update all Memory Bank documents, document standards and architecture
|
||||
3. PLAN: Define architecture with principles, alternatives, evaluation, selection
|
||||
4. CREATE: Execute all required creative phases with documentation
|
||||
5. IMPL: Implement in phases with verification, integration, testing
|
||||
6. REFLECT: Document successes, challenges, insights, and strategic actions
|
||||
7. ARCHIVE: Create comprehensive documentation and knowledge transfer
|
||||
```
|
||||
|
||||
## 🔄 INTEGRATION WITH MEMORY BANK
|
||||
|
||||
This workflow integrates comprehensively with Memory Bank:
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Workflow["Level 4<br>Workflow"] --> PB["Comprehensive Update<br>projectbrief.md"]
|
||||
Workflow --> AC["Detailed Update<br>activeContext.md"]
|
||||
Workflow --> SP["Strategic Update<br>systemPatterns.md"]
|
||||
Workflow --> TC["Complete Update<br>techContext.md"]
|
||||
Workflow --> TM["Structured Maintenance<br>tasks.md"]
|
||||
Workflow --> PM["Enterprise Update<br>progress.md"]
|
||||
|
||||
PB & AC & SP & TC & TM & PM --> MB["Memory Bank<br>Integration"]
|
||||
MB --> KT["Knowledge<br>Transfer"]
|
||||
KT --> NextSystem["Enterprise<br>System Evolution"]
|
||||
```
|
||||
|
||||
## 🚨 LEVEL 4 GOVERNANCE PRINCIPLE
|
||||
|
||||
Remember:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Level 4 tasks represent ENTERPRISE-CRITICAL work. │
|
||||
│ RIGOROUS governance, comprehensive documentation, │
|
||||
│ and thorough verification are MANDATORY at each │
|
||||
│ phase. NO EXCEPTIONS. │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
This ensures that complex systems are designed, implemented, and documented to the highest standards, with enterprise-grade quality and governance.
|
||||
Reference in New Issue
Block a user