Name: planning-pattern
Author: WillWhittakerDHP

Prompt file imported from WillWhittakerDHP/LEGACY_DHP_Differential_Scheduler (.cursor/commands/planning/templates/planning-pattern.md). Copyright stays with the author.

Pattern Selection Planning Template

Purpose: Structure for selecting design patterns, architectural patterns, or code patterns

Use When: Choosing between different patterns, approaches, or design strategies

Pattern Selection: [Pattern Name/Type]

Date: [Date] Status: [Evaluating | Selected | Rejected] Decision Maker: [Name/Role]

Context

Problem Statement: [Describe the problem or need that requires a pattern choice]

Use Case: [Describe the specific use case or scenario]

Current Approach: [Describe current pattern or approach (if any)]

Requirements:

[Requirement 1]
[Requirement 2]
[Requirement 3]

Pattern Options

Pattern 1: [Pattern Name]

Description: [Brief description of the pattern]

When to Use:

[Scenario 1]
[Scenario 2]
[Scenario 3]

When NOT to Use:

[Scenario 1]
[Scenario 2]

Pros:

[Advantage 1]
[Advantage 2]
[Advantage 3]

Cons:

[Disadvantage 1]
[Disadvantage 2]
[Disadvantage 3]

Code Example:

// Brief example showing pattern usage

Existing Usage in Codebase:

[Location 1]
[Location 2]

Pattern 2: [Pattern Name]

Description: [Brief description of the pattern]

When to Use:

[Scenario 1]
[Scenario 2]
[Scenario 3]

When NOT to Use:

[Scenario 1]
[Scenario 2]

Pros:

[Advantage 1]
[Advantage 2]
[Advantage 3]

Cons:

[Disadvantage 1]
[Disadvantage 2]
[Disadvantage 3]

Code Example:

// Brief example showing pattern usage

Existing Usage in Codebase:

[Location 1]
[Location 2]

Pattern 3: [Pattern Name] (if applicable)

[Repeat structure above]

Use Case Analysis

Primary Use Cases:

[Use case 1]
- Pattern 1: [How it addresses this]
- Pattern 2: [How it addresses this]
[Use case 2]
- Pattern 1: [How it addresses this]
- Pattern 2: [How it addresses this]

Edge Cases:

[Edge case 1] - [How each pattern handles it]
[Edge case 2] - [How each pattern handles it]

Trade-offs Comparison

Aspect	Pattern 1	Pattern 2	Pattern 3
Complexity	[Rating]	[Rating]	[Rating]
Maintainability	[Rating]	[Rating]	[Rating]
Performance	[Rating]	[Rating]	[Rating]
Flexibility	[Rating]	[Rating]	[Rating]
Team Familiarity	[Rating]	[Rating]	[Rating]
Code Reusability	[Rating]	[Rating]	[Rating]

Decision

Selected Pattern: [Pattern Name]

Rationale: [Explain why this pattern was chosen. Reference specific use cases, requirements, or trade-offs]

Key Decision Factors:

[Factor 1]
[Factor 2]
[Factor 3]

Rejected Patterns:

[Pattern Name] - [Reason for rejection]
[Pattern Name] - [Reason for rejection]

Implementation Plan

Current State: [Describe current pattern/approach]

Target State: [Describe target pattern/approach]

Implementation Steps:

[Step 1]
[Step 2]
[Step 3]

Files to Modify:

[File 1]
[File 2]
[File 3]

New Files to Create:

[File 1]
[File 2]

Timeline: [Estimated timeline]

Risk Assessment

Technical Risks:

[Risk 1] - [Mitigation]
[Risk 2] - [Mitigation]

Code Quality Risks:

[Risk 1] - [Mitigation]

Team Adoption Risks:

[Risk 1] - [Mitigation]

Security Considerations

SQL Injection Prevention

All database queries use parameterized queries/Sequelize methods
No string concatenation for SQL queries
Input validation before database operations
No use of sequelize.query() with user input in SQL strings

XSS Prevention

User input sanitized before rendering
React: Using React's built-in escaping (default behavior)
Vue: Using v-text or proper escaping for user content
No use of dangerouslySetInnerHTML or v-html with user input
Content Security Policy headers configured

Authentication/Authorization

All protected routes verify authentication
User permissions checked before data access
No sensitive data in client-side code
Session tokens properly secured

Input Validation

Server-side validation for all inputs
Type checking and schema validation (Joi/Zod)
Rate limiting on public endpoints
File upload validation (if applicable)

Secure Configuration

Environment variables for secrets (no hardcoded credentials)
HTTPS enforced in production
CORS properly configured
Security headers (helmet.js) configured

Security Validation

Run /security-audit to check for vulnerabilities
Review dependency vulnerabilities (/security-check-dependencies)
Check for exposed secrets (/security-check-secrets)
Validate security configuration (/security-check-config)
Verify CSRF protection (/security-check-csrf)
Check authentication patterns (/security-check-auth)
Review IDOR vulnerabilities (/security-check-idor)
Run ESLint security checks (/validate-security)

Note: Security audit is automatically run in /planning-plan-with-checks as Step 5. See .cursor/commands/security/QUICK_REFERENCE.md for command details.

Success Criteria

[Criterion 1]
[Criterion 2]
[Criterion 3]

References

[Pattern documentation]
[Related patterns]
[Codebase examples]

Notes

[Additional notes, concerns, or follow-up items]

# Pattern Selection Planning Template **Purpose:** Structure for selecting design patterns, architectural patterns, or code patterns **Use When:** Choosing between different patterns, approaches, or design strategies --- ## Pattern Selection: [Pattern Name/Type] **Date:** [Date] **Status:** [Evaluating | Selected | Rejected] **Decision Maker:** [Name/Role] ### Context **Problem Statement:** [Describe the problem or need that requires a pattern choice] **Use Case:** [Describe the specific use case or scenario] **Current Approach:** [Describe current pattern or approach (if any)] **Requirements:** - [Requirement 1] - [Requirement 2] - [Requirement 3] --- ## Pattern Options ### Pattern 1: [Pattern Name] **Description:** [Brief description of the pattern] **Type:** [Design Pattern | Architectural Pattern | Code Pattern] **Category:** [Creational | Structural | Behavioral | Architectural] **When to Use:** - [Scenario 1] - [Scenario 2] - [Scenario 3] **When NOT to Use:** - [Scenario 1] - [Scenario 2] **Pros:** - [Advantage 1] - [Advantage 2] - [Advantage 3] **Cons:** - [Disadvantage 1] - [Disadvantage 2] - [Disadvantage 3] **Complexity:** [Low | Medium | High] **Maintainability:** [Low | Medium | High] **Performance Impact:** [Positive | Neutral | Negative] **Team Familiarity:** [High | Medium | Low] **Code Example:** ```typescript // Brief example showing pattern usage ``` **Existing Usage in Codebase:** - [Location 1] - [Location 2] --- ### Pattern 2: [Pattern Name] **Description:** [Brief description of the pattern] **Type:** [Design Pattern | Architectural Pattern | Code Pattern] **Category:** [Creational | Structural | Behavioral | Architectural] **When to Use:** - [Scenario 1] - [Scenario 2] - [Scenario 3] **When NOT to Use:** - [Scenario 1] - [Scenario 2] **Pros:** - [Advantage 1] - [Advantage 2] - [Advantage 3] **Cons:** - [Disadvantage 1] - [Disadvantage 2] - [Disadvantage 3] **Complexity:** [Low | Medium | High] **Maintainability:** [Low | Medium | High] **Performance Impact:** [Positive | Neutral | Negative] **Team Familiarity:** [High | Medium | Low] **Code Example:** ```typescript // Brief example showing pattern usage ``` **Existing Usage in Codebase:** - [Location 1] - [Location 2] --- ### Pattern 3: [Pattern Name] (if applicable) [Repeat structure above] --- ## Use Case Analysis **Primary Use Cases:** 1. [Use case 1] - Pattern 1: [How it addresses this] - Pattern 2: [How it addresses this] 2. [Use case 2] - Pattern 1: [How it addresses this] - Pattern 2: [How it addresses this] **Edge Cases:** - [Edge case 1] - [How each pattern handles it] - [Edge case 2] - [How each pattern handles it] --- ## Trade-offs Comparison | Aspect | Pattern 1 | Pattern 2 | Pattern 3 | |--------|-----------|-----------|-----------| | Complexity | [Rating] | [Rating] | [Rating] | | Maintainability | [Rating] | [Rating] | [Rating] | | Performance | [Rating] | [Rating] | [Rating] | | Flexibility | [Rating] | [Rating] | [Rating] | | Team Familiarity | [Rating] | [Rating] | [Rating] | | Code Reusability | [Rating] | [Rating] | [Rating] | --- ## Decision **Selected Pattern:** [Pattern Name] **Rationale:** [Explain why this pattern was chosen. Reference specific use cases, requirements, or trade-offs] **Key Decision Factors:** - [Factor 1] - [Factor 2] - [Factor 3] **Rejected Patterns:** - [Pattern Name] - [Reason for rejection] - [Pattern Name] - [Reason for rejection] --- ## Implementation Plan **Current State:** [Describe current pattern/approach] **Target State:** [Describe target pattern/approach] **Implementation Steps:** 1. [Step 1] 2. [Step 2] 3. [Step 3] **Files to Modify:** - [File 1] - [File 2] - [File 3] **New Files to Create:** - [File 1] - [File 2] **Timeline:** [Estimated timeline] --- ## Risk Assessment **Technical Risks:** - [Risk 1] - [Mitigation] - [Risk 2] - [Mitigation] **Code Quality Risks:** - [Risk 1] - [Mitigation] **Team Adoption Risks:** - [Risk 1] - [Mitigation] --- ## Security Considerations ### SQL Injection Prevention - [ ] All database queries use parameterized queries/Sequelize methods - [ ] No string concatenation for SQL queries - [ ] Input validation before database operations - [ ] No use of `sequelize.query()` with user input in SQL strings ### XSS Prevention - [ ] User input sanitized before rendering - [ ] React: Using React's built-in escaping (default behavior) - [ ] Vue: Using v-text or proper escaping for user content - [ ] No use of `dangerouslySetInnerHTML` or `v-html` with user input - [ ] Content Security Policy headers configured ### Authentication/Authorization - [ ] All protected routes verify authentication - [ ] User permissions checked before data access - [ ] No sensitive data in client-side code - [ ] Session tokens properly secured ### Input Validation - [ ] Server-side validation for all inputs - [ ] Type checking and schema validation (Joi/Zod) - [ ] Rate limiting on public endpoints - [ ] File upload validation (if applicable) ### Secure Configuration - [ ] Environment variables for secrets (no hardcoded credentials) - [ ] HTTPS enforced in production - [ ] CORS properly configured - [ ] Security headers (helmet.js) configured ### Security Validation - [ ] Run `/security-audit` to check for vulnerabilities - [ ] Review dependency vulnerabilities (`/security-check-dependencies`) - [ ] Check for exposed secrets (`/security-check-secrets`) - [ ] Validate security configuration (`/security-check-config`) - [ ] Verify CSRF protection (`/security-check-csrf`) - [ ] Check authentication patterns (`/security-check-auth`) - [ ] Review IDOR vulnerabilities (`/security-check-idor`) - [ ] Run ESLint security checks (`/validate-security`) **Note:** Security audit is automatically run in `/planning-plan-with-checks` as Step 5. See `.cursor/commands/security/QUICK_REFERENCE.md` for command details. --- ## Success Criteria - [ ] [Criterion 1] - [ ] [Criterion 2] - [ ] [Criterion 3] --- ## References - [Pattern documentation] - [Related patterns] - [Codebase examples] --- ## Notes [Additional notes, concerns, or follow-up items]

{ "prompt": "# Pattern Selection Planning Template\n\n**Purpose:** Structure for selecting design patterns, architectural patterns, or code patterns\n\n**Use When:** Choosing between different patterns, approaches, or design strategies\n\n---\n\n## Pattern Selection: [Pattern Name/Type]\n\n**Date:** [Date]\n**Status:** [Evaluating | Selected | Rejected]\n**Decision Maker:** [Name/Role]\n\n### Context\n\n**Problem Statement:**\n[Describe the problem or need that requires a pattern choice]\n\n**Use Case:**\n[Describe the specific use case or scenario]\n\n**Current Approach:**\n[Describe current pattern or approach (if any)]\n\n**Requirements:**\n- [Requirement 1]\n- [Requirement 2]\n- [Requirement 3]\n\n---\n\n## Pattern Options\n\n### Pattern 1: [Pattern Name]\n\n**Description:**\n[Brief description of the pattern]\n\n**Type:** [Design Pattern | Architectural Pattern | Code Pattern]\n**Category:** [Creational | Structural | Behavioral | Architectural]\n\n**When to Use:**\n- [Scenario 1]\n- [Scenario 2]\n- [Scenario 3]\n\n**When NOT to Use:**\n- [Scenario 1]\n- [Scenario 2]\n\n**Pros:**\n- [Advantage 1]\n- [Advantage 2]\n- [Advantage 3]\n\n**Cons:**\n- [Disadvantage 1]\n- [Disadvantage 2]\n- [Disadvantage 3]\n\n**Complexity:** [Low | Medium | High]\n**Maintainability:** [Low | Medium | High]\n**Performance Impact:** [Positive | Neutral | Negative]\n**Team Familiarity:** [High | Medium | Low]\n\n**Code Example:**\n```typescript\n// Brief example showing pattern usage\n```\n\n**Existing Usage in Codebase:**\n- [Location 1]\n- [Location 2]\n\n---\n\n### Pattern 2: [Pattern Name]\n\n**Description:**\n[Brief description of the pattern]\n\n**Type:** [Design Pattern | Architectural Pattern | Code Pattern]\n**Category:** [Creational | Structural | Behavioral | Architectural]\n\n**When to Use:**\n- [Scenario 1]\n- [Scenario 2]\n- [Scenario 3]\n\n**When NOT to Use:**\n- [Scenario 1]\n- [Scenario 2]\n\n**Pros:**\n- [Advantage 1]\n- [Advantage 2]\n- [Advantage 3]\n\n**Cons:**\n- [Disadvantage 1]\n- [Disadvantage 2]\n- [Disadvantage 3]\n\n**Complexity:** [Low | Medium | High]\n**Maintainability:** [Low | Medium | High]\n**Performance Impact:** [Positive | Neutral | Negative]\n**Team Familiarity:** [High | Medium | Low]\n\n**Code Example:**\n```typescript\n// Brief example showing pattern usage\n```\n\n**Existing Usage in Codebase:**\n- [Location 1]\n- [Location 2]\n\n---\n\n### Pattern 3: [Pattern Name] (if applicable)\n\n[Repeat structure above]\n\n---\n\n## Use Case Analysis\n\n**Primary Use Cases:**\n1. [Use case 1]\n - Pattern 1: [How it addresses this]\n - Pattern 2: [How it addresses this]\n\n2. [Use case 2]\n - Pattern 1: [How it addresses this]\n - Pattern 2: [How it addresses this]\n\n**Edge Cases:**\n- [Edge case 1] - [How each pattern handles it]\n- [Edge case 2] - [How each pattern handles it]\n\n---\n\n## Trade-offs Comparison\n\n| Aspect | Pattern 1 | Pattern 2 | Pattern 3 |\n|--------|-----------|-----------|-----------|\n| Complexity | [Rating] | [Rating] | [Rating] |\n| Maintainability | [Rating] | [Rating] | [Rating] |\n| Performance | [Rating] | [Rating] | [Rating] |\n| Flexibility | [Rating] | [Rating] | [Rating] |\n| Team Familiarity | [Rating] | [Rating] | [Rating] |\n| Code Reusability | [Rating] | [Rating] | [Rating] |\n\n---\n\n## Decision\n\n**Selected Pattern:** [Pattern Name]\n\n**Rationale:**\n[Explain why this pattern was chosen. Reference specific use cases, requirements, or trade-offs]\n\n**Key Decision Factors:**\n- [Factor 1]\n- [Factor 2]\n- [Factor 3]\n\n**Rejected Patterns:**\n- [Pattern Name] - [Reason for rejection]\n- [Pattern Name] - [Reason for rejection]\n\n---\n\n## Implementation Plan\n\n**Current State:**\n[Describe current pattern/approach]\n\n**Target State:**\n[Describe target pattern/approach]\n\n**Implementation Steps:**\n1. [Step 1]\n2. [Step 2]\n3. [Step 3]\n\n**Files to Modify:**\n- [File 1]\n- [File 2]\n- [File 3]\n\n**New Files to Create:**\n- [File 1]\n- [File 2]\n\n**Timeline:** [Estimated timeline]\n\n---\n\n## Risk Assessment\n\n**Technical Risks:**\n- [Risk 1] - [Mitigation]\n- [Risk 2] - [Mitigation]\n\n**Code Quality Risks:**\n- [Risk 1] - [Mitigation]\n\n**Team Adoption Risks:**\n- [Risk 1] - [Mitigation]\n\n---\n\n## Security Considerations\n\n### SQL Injection Prevention\n- [ ] All database queries use parameterized queries/Sequelize methods\n- [ ] No string concatenation for SQL queries\n- [ ] Input validation before database operations\n- [ ] No use of `sequelize.query()` with user input in SQL strings\n\n### XSS Prevention\n- [ ] User input sanitized before rendering\n- [ ] React: Using React's built-in escaping (default behavior)\n- [ ] Vue: Using v-text or proper escaping for user content\n- [ ] No use of `dangerouslySetInnerHTML` or `v-html` with user input\n- [ ] Content Security Policy headers configured\n\n### Authentication/Authorization\n- [ ] All protected routes verify authentication\n- [ ] User permissions checked before data access\n- [ ] No sensitive data in client-side code\n- [ ] Session tokens properly secured\n\n### Input Validation\n- [ ] Server-side validation for all inputs\n- [ ] Type checking and schema validation (Joi/Zod)\n- [ ] Rate limiting on public endpoints\n- [ ] File upload validation (if applicable)\n\n### Secure Configuration\n- [ ] Environment variables for secrets (no hardcoded credentials)\n- [ ] HTTPS enforced in production\n- [ ] CORS properly configured\n- [ ] Security headers (helmet.js) configured\n\n### Security Validation\n- [ ] Run `/security-audit` to check for vulnerabilities\n- [ ] Review dependency vulnerabilities (`/security-check-dependencies`)\n- [ ] Check for exposed secrets (`/security-check-secrets`)\n- [ ] Validate security configuration (`/security-check-config`)\n- [ ] Verify CSRF protection (`/security-check-csrf`)\n- [ ] Check authentication patterns (`/security-check-auth`)\n- [ ] Review IDOR vulnerabilities (`/security-check-idor`)\n- [ ] Run ESLint security checks (`/validate-security`)\n\n**Note:** Security audit is automatically run in `/planning-plan-with-checks` as Step 5. See `.cursor/commands/security/QUICK_REFERENCE.md` for command details.\n\n---\n\n## Success Criteria\n\n- [ ] [Criterion 1]\n- [ ] [Criterion 2]\n- [ ] [Criterion 3]\n\n---\n\n## References\n\n- [Pattern documentation]\n- [Related patterns]\n- [Codebase examples]\n\n---\n\n## Notes\n\n[Additional notes, concerns, or follow-up items]", "variables": [], "notes": "[Repeat structure above]", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/WillWhittakerDHP/LEGACY_DHP_Differential_Scheduler", "path": ".cursor/commands/planning/templates/planning-pattern.md", "ref": "1d1659501a23cb4a6156c6e70e8ceb86e55b5663", "url": "https://github.com/WillWhittakerDHP/LEGACY_DHP_Differential_Scheduler/blob/1d1659501a23cb4a6156c6e70e8ceb86e55b5663/.cursor/commands/planning/templates/planning-pattern.md", "key": "WillWhittakerDHP/LEGACY_DHP_Differential_Scheduler/.cursor/commands/planning/templates/planning-pattern.md" } } }

planning-pattern

About