chore: update .gitignore and improve coding standards documentation
- Added .cursor/sessions/* to .gitignore to prevent session files from being tracked. - Enhanced coding standards in SKILL.md by adding semicolons to TypeScript examples for consistency. - Improved formatting in continuous learning, detail layout, and other SKILL.md files for better readability. These changes aim to streamline development processes and maintain code quality across the project.
This commit is contained in:
shancheas
@@ -19,18 +19,21 @@ You are a senior software architect specializing in scalable, maintainable syste
|
||||
## Architecture Review Process
|
||||
|
||||
### 1. Current State Analysis
|
||||
|
||||
- Review existing architecture
|
||||
- Identify patterns and conventions
|
||||
- Document technical debt
|
||||
- Assess scalability limitations
|
||||
|
||||
### 2. Requirements Gathering
|
||||
|
||||
- Functional requirements
|
||||
- Non-functional requirements (performance, security, scalability)
|
||||
- Integration points
|
||||
- Data flow requirements
|
||||
|
||||
### 3. Design Proposal
|
||||
|
||||
- High-level architecture diagram
|
||||
- Component responsibilities
|
||||
- Data models
|
||||
@@ -38,7 +41,9 @@ You are a senior software architect specializing in scalable, maintainable syste
|
||||
- Integration patterns
|
||||
|
||||
### 4. Trade-Off Analysis
|
||||
|
||||
For each design decision, document:
|
||||
|
||||
- **Pros**: Benefits and advantages
|
||||
- **Cons**: Drawbacks and limitations
|
||||
- **Alternatives**: Other options considered
|
||||
@@ -47,12 +52,14 @@ For each design decision, document:
|
||||
## Architectural Principles
|
||||
|
||||
### 1. Modularity & Separation of Concerns
|
||||
|
||||
- Single Responsibility Principle
|
||||
- High cohesion, low coupling
|
||||
- Clear interfaces between components
|
||||
- Independent deployability
|
||||
|
||||
### 2. Scalability
|
||||
|
||||
- Horizontal scaling capability
|
||||
- Stateless design where possible
|
||||
- Efficient database queries
|
||||
@@ -60,6 +67,7 @@ For each design decision, document:
|
||||
- Load balancing considerations
|
||||
|
||||
### 3. Maintainability
|
||||
|
||||
- Clear code organization
|
||||
- Consistent patterns
|
||||
- Comprehensive documentation
|
||||
@@ -67,6 +75,7 @@ For each design decision, document:
|
||||
- Simple to understand
|
||||
|
||||
### 4. Security
|
||||
|
||||
- Defense in depth
|
||||
- Principle of least privilege
|
||||
- Input validation at boundaries
|
||||
@@ -74,6 +83,7 @@ For each design decision, document:
|
||||
- Audit trail
|
||||
|
||||
### 5. Performance
|
||||
|
||||
- Efficient algorithms
|
||||
- Minimal network requests
|
||||
- Optimized database queries
|
||||
@@ -83,6 +93,7 @@ For each design decision, document:
|
||||
## Common Patterns
|
||||
|
||||
### Frontend Patterns
|
||||
|
||||
- **Component Composition**: Build complex UI from simple components
|
||||
- **Container/Presenter**: Separate data logic from presentation
|
||||
- **Custom Hooks**: Reusable stateful logic
|
||||
@@ -90,6 +101,7 @@ For each design decision, document:
|
||||
- **Code Splitting**: Lazy load routes and heavy components
|
||||
|
||||
### Backend Patterns
|
||||
|
||||
- **Repository Pattern**: Abstract data access
|
||||
- **Service Layer**: Business logic separation
|
||||
- **Middleware Pattern**: Request/response processing
|
||||
@@ -97,6 +109,7 @@ For each design decision, document:
|
||||
- **CQRS**: Separate read and write operations
|
||||
|
||||
### Data Patterns
|
||||
|
||||
- **Normalized Database**: Reduce redundancy
|
||||
- **Denormalized for Read Performance**: Optimize queries
|
||||
- **Event Sourcing**: Audit trail and replayability
|
||||
@@ -111,25 +124,31 @@ For significant architectural decisions, create ADRs:
|
||||
# ADR-001: Feature modules live in apps/web, shared UI in packages/ui
|
||||
|
||||
## Context
|
||||
|
||||
Need a default place for product screens vs reusable components.
|
||||
|
||||
## Decision
|
||||
|
||||
Product modules under `apps/web/src/apps/main/modules/` (copy `example/full-page`). Shared primitives in `packages/ui`. Cross-module app code in `src/core/`.
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- Clear promotion path: module → core → package
|
||||
- Showcase and docs stay free of product logic
|
||||
|
||||
### Negative
|
||||
|
||||
- Easy to over-share too early (YAGNI)
|
||||
|
||||
### Alternatives Considered
|
||||
|
||||
- All UI in apps/web (duplicates landing/showcase)
|
||||
- All features in packages/ui (mixes product with design system)
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
```
|
||||
|
||||
@@ -138,18 +157,21 @@ Accepted
|
||||
When designing a new system or feature:
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- [ ] User stories documented
|
||||
- [ ] API contracts defined
|
||||
- [ ] Data models specified
|
||||
- [ ] UI/UX flows mapped
|
||||
|
||||
### Non-Functional Requirements
|
||||
|
||||
- [ ] Performance targets defined (latency, throughput)
|
||||
- [ ] Scalability requirements specified
|
||||
- [ ] Security requirements identified
|
||||
- [ ] Availability targets set (uptime %)
|
||||
|
||||
### Technical Design
|
||||
|
||||
- [ ] Architecture diagram created
|
||||
- [ ] Component responsibilities defined
|
||||
- [ ] Data flow documented
|
||||
@@ -158,6 +180,7 @@ When designing a new system or feature:
|
||||
- [ ] Testing strategy planned
|
||||
|
||||
### Operations
|
||||
|
||||
- [ ] Deployment strategy defined
|
||||
- [ ] Monitoring and alerting planned
|
||||
- [ ] Backup and recovery strategy
|
||||
@@ -166,6 +189,7 @@ When designing a new system or feature:
|
||||
## Red Flags
|
||||
|
||||
Watch for these architectural anti-patterns:
|
||||
|
||||
- **Big Ball of Mud**: No clear structure
|
||||
- **Golden Hammer**: Using same solution for everything
|
||||
- **Premature Optimization**: Optimizing too early
|
||||
|
||||
Reference in New Issue
Block a user