smart-spec-kit-mcp 2.1.2 → 2.1.4

package/docs/DOCUMENTATION.md

@@ -238,6 +238,89 @@ speckit: memory ajouter une décision technique
 2. Structures content with dates and context
 3. Auto mode analyzes conversation to extract insights
 
+### speckit_validate
+
+**Purpose**: Validate compliance against customizable rules (security, RGPD, architecture, etc.).
+
+**Triggers**: `speckit: validate`, `valider`, `vérifier`
+
+**Parameters** (all optional):
+
+- `ruleType`: Type of validation to perform
+  - `security` - Validate against security rules (OWASP, encryption, auth...)
+  - `rgpd` - Validate GDPR compliance
+  - Custom rule file name (e.g., `architecture-rules`)
+- `phase`: Phase being validated
+  - `spec` - Validating a specification
+  - `plan` - Validating a plan
+  - `implementation` - Validating code
+- `targetPath`: Path to the file/folder to validate
+
+**Examples**:
+
+```text
+speckit: validate security
+speckit: validate rgpd phase=spec
+speckit: valider la sécurité du code
+speckit: vérifier conformité RGPD
+speckit: validate architecture-rules
+```
+
+**Behavior**:
+
+1. Loads rules from `.spec-kit/rules/{ruleType}-rules.md`
+2. Loads validation prompt from `.spec-kit/prompts/validate.md`
+3. Analyzes target against each rule
+4. Generates validation report with checklist
+5. Output saved to `specs/validations/{ruleType}-validation-{date}.md`
+
+**Available Rules** (default):
+
+| Rule Type | File | Description |
+|-----------|------|-------------|
+| `security` | `security-rules.md` | OWASP Top 10, authentication, encryption, API security |
+| `rgpd` | `rgpd-rules.md` | GDPR Articles 6, 12-22, 28, 30, 32, 35 compliance |
+
+**Creating Custom Rules**:
+
+Create a new file in `.spec-kit/rules/`:
+
+```markdown
+# .spec-kit/rules/my-custom-rules.md
+
+# My Custom Rules
+
+## Category 1
+
+- [ ] **RULE-001**: Rule description
+  - Details about the rule
+  - How to check compliance
+
+- [ ] **RULE-002**: Another rule
+  - Details
+```
+
+Then use: `speckit: validate my-custom`
+
+**Validation Report Format**:
+
+```markdown
+# Validation Report: Security
+
+**Date**: 2024-01-15
+**Phase**: implementation
+**Target**: src/auth/
+
+## Summary
+- ✅ Compliant: 8
+- ⚠️ Partial: 2
+- ❌ Non-compliant: 1
+- ➖ Not applicable: 1
+
+## Detailed Results
+...
+```
+
 ---
 
 ## Customization Guide
@@ -405,6 +488,23 @@ npx smart-spec-kit-mcp setup --project . --force
 
 ## Workflow Reference
 
+### feature-quick
+
+Lightweight workflow for quick wins and simple features.
+
+**Best for**: Small features, quick wins, simple changes
+
+**Steps**:
+
+1. Quick spec (minimal documentation)
+2. Implement directly
+3. Auto-update memory
+
+**Example**:
+```text
+speckit: start_workflow workflow_name="feature-quick"
+```
+
 ### feature-standard
 
 Standard feature specification workflow.
@@ -448,6 +548,47 @@ Bug fix workflow.
 
 ---
 
+## Auto-Memory Enrichment
+
+After each feature or bugfix implementation, Spec-Kit **automatically** enriches project memory with relevant learnings.
+
+### What Gets Captured
+
+| Category | File | Content |
+|----------|------|---------|
+| **Decisions** | `decisions.md` | Architectural and technical decisions |
+| **Conventions** | `conventions.md` | Coding patterns and standards |
+| **Learnings** | `learnings.md` | Lessons learned, gotchas, insights |
+
+### Memory Entry Format
+
+```markdown
+## {Type}: {Title}
+**Date:** YYYY-MM-DD
+**Context:** Which task/feature triggered this
+**Description:** What was decided/learned
+**Rationale:** Why - the reasoning behind it
+```
+
+### Example Entry
+
+```markdown
+## Decision: Use Repository Pattern for Data Access
+**Date:** 2024-01-30
+**Context:** Task #3 - Implement user authentication
+**Description:** Created UserRepository interface with InMemory and SQL implementations
+**Rationale:** Allows easy testing and future database changes without affecting business logic
+```
+
+### Benefits
+
+- **Knowledge retention**: Project learnings are preserved
+- **Onboarding**: New team members can learn from history
+- **Consistency**: Decisions are documented and traceable
+- **AI context**: Future Copilot sessions have richer context
+
+---
+
 ## Best Practices
 
 ### Writing Good Requirements

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "smart-spec-kit-mcp",
-  "version": "2.1.2",
+  "version": "2.1.4",
   "description": "AI-driven specification platform using MCP (Model Context Protocol) for VS Code & GitHub Copilot",
   "main": "dist/index.js",
   "type": "module",

package/starter-kit/copilot-instructions.md

@@ -13,6 +13,7 @@ When the user mentions **"speckit:"** followed by a command, or uses these keywo
 | `speckit: tasks`, `générer les tâches`, `créer les tâches` | `speckit_tasks` | Generate task breakdown |
 | `speckit: implement`, `implémenter`, `coder` | `speckit_implement` | Implement tasks |
 | `speckit: clarify`, `clarifier`, `préciser` | `speckit_clarify` | Clarify requirements |
+| `speckit: validate`, `valider`, `vérifier` | `speckit_validate` | Validate compliance (security, RGPD, etc.) |
 | `speckit: memory`, `enrichir la mémoire`, `ajouter au contexte` | `speckit_memory` | Manage project memory |
 | `speckit: help`, `aide sur speckit`, questions about spec-kit | `speckit_help` | Get help and documentation |
 
@@ -51,16 +52,22 @@ speckit_specify → speckit_plan → speckit_tasks → speckit_implement
 │   ├── tasks.md
 │   ├── implement.md
 │   ├── clarify.md
+│   ├── validate.md
 │   └── memory.md
 ├── templates/         # Document templates
 │   ├── functional-spec.md
 │   ├── plan-template.md
 │   └── tasks-template.md
+├── rules/             # Validation rules
+│   ├── security-rules.md
+│   └── rgpd-rules.md
 ├── memory/            # Project context
 │   └── constitution.md
 └── workflows/         # Automated workflows
+    └── feature-quick.yaml  # Quick wins (lightweight)
 
 specs/                 # Generated specifications (output)
+└── validations/       # Validation reports
 ```
 
 ## Important Conventions
@@ -86,6 +93,7 @@ For multi-step automation, use `start_workflow`:
 
 | User Says | Action |
 |-----------|--------|
+| `speckit: start_workflow workflow_name="feature-quick"` | Start quick feature workflow (lightweight) |
 | `speckit: start_workflow workflow_name="feature-standard" PiP Support` | Start feature workflow for PiP Support |
 | `speckit: start_workflow workflow_name="bugfix" auto=true` | Start bugfix workflow in AUTO mode |
 
@@ -111,6 +119,15 @@ For multi-step automation, use `start_workflow`:
 **User**: "speckit: memory auto"
 **Action**: Call `speckit_memory` with `action: "auto"` to auto-enrich from context
 
+**User**: "speckit: validate security"
+**Action**: Call `speckit_validate` with `ruleType: "security"`
+
+**User**: "speckit: valider la conformité RGPD de la spec"
+**Action**: Call `speckit_validate` with `ruleType: "rgpd"`, `phase: "spec"`
+
+**User**: "speckit: validate architecture-rules"
+**Action**: Call `speckit_validate` with `ruleType: "architecture"` (uses custom rules file)
+
 **User**: "speckit: start_workflow workflow_name="feature-standard" PiP Support auto=true"
 **Action**: Call `start_workflow` with `workflow_name: "feature-standard"`, `context_id: "PiP Support"`, `auto: true`
 

package/starter-kit/prompts/implement.md

@@ -71,7 +71,48 @@ Report:
 - Any deviations from plan
 - Next task to implement (if continuing)
 
-## 8. Iteration
+## 8. Auto-Enrich Memory
+
+After each implementation, **automatically** save relevant learnings to `.spec-kit/memory/`:
+
+### What to capture:
+
+**Decisions** (save to `decisions.md`):
+- Architectural choices made during implementation
+- Technology/library selections
+- Trade-offs considered
+
+**Conventions** (save to `conventions.md`):
+- New patterns established
+- Code conventions discovered or enforced
+- Best practices applied
+
+**Learnings** (save to `learnings.md`):
+- Problems encountered and solutions found
+- Performance insights
+- Gotchas or edge cases discovered
+
+### Format for memory entries:
+
+```markdown
+## {Type}: {Title}
+**Date:** {YYYY-MM-DD}
+**Context:** {Brief context - which task/feature}
+**Description:** {What was decided/learned}
+**Rationale:** {Why - reasoning behind it}
+```
+
+### Example:
+
+```markdown
+## Decision: Use Repository Pattern for Data Access
+**Date:** 2024-01-30
+**Context:** Task #3 - Implement user authentication
+**Description:** Created UserRepository interface with InMemory and SQL implementations
+**Rationale:** Allows easy testing and future database changes without affecting business logic
+```
+
+## 9. Iteration
 
 Ask the user:
 - "Task {ID} completed. Continue with {next task}? (yes/no)"

package/starter-kit/prompts/validate.md

@@ -0,0 +1,89 @@
+# Validation Prompt
+
+## Purpose
+
+Execute validation checks against customizable rules after specific workflow phases.
+
+## Validation Types
+
+Spec-Kit supports multiple validation types:
+
+1. **Security Validation** - Check security rules compliance
+2. **RGPD Validation** - Check GDPR/RGPD compliance
+3. **Architecture Validation** - Check architecture principles
+4. **Custom Validation** - Check custom project rules
+
+## Process
+
+### 1. Load Rules
+
+Load the appropriate rules file from `.spec-kit/rules/`:
+- `security-rules.md` for security validation
+- `rgpd-rules.md` for RGPD/GDPR validation
+- Custom files as defined by user
+
+### 2. Load Target Document
+
+Load the document to validate:
+- For **spec** phase: Load from `specs/*-spec.md`
+- For **plan** phase: Load from `specs/plan.md`
+- For **implementation** phase: Analyze recent code changes
+
+### 3. Evaluate Each Rule
+
+For each rule in the rules file:
+
+1. Determine if the rule is applicable to this feature
+2. Check if the requirement is addressed
+3. Mark status: ✅ Compliant | ⚠️ Partial | ❌ Non-Compliant | ➖ N/A
+4. Document evidence or gaps
+
+### 4. Generate Report
+
+Create a validation report with:
+- Summary statistics
+- Critical issues (blocking)
+- Warnings (should fix)
+- Recommendations (nice to have)
+
+## Validation Triggers
+
+Validations can be triggered:
+
+- **Manually**: `speckit: validate security` or `speckit: validate rgpd`
+- **In Workflow**: As a step in feature-full or custom workflows
+- **After Phase**: Automatically after spec or implementation
+
+## Output
+
+Save validation reports to:
+- `specs/validations/{type}-{date}.md`
+
+## Instructions for Copilot
+
+When performing validation:
+
+1. **Be Thorough**: Check every applicable rule
+2. **Be Specific**: Cite specific sections or code that address rules
+3. **Be Constructive**: Provide actionable recommendations
+4. **Be Honest**: Mark non-compliant if not addressed, don't assume
+
+## Custom Rules
+
+Users can create custom rules files in `.spec-kit/rules/`:
+
+```markdown
+# My Custom Rules
+
+## Category Name
+
+### RULE-001: Rule Title
+- [ ] Checklist item 1
+- [ ] Checklist item 2
+
+### RULE-002: Another Rule
+- [ ] Check this
+- [ ] Check that
+```
+
+Then trigger with: `speckit: validate my-custom-rules`

package/starter-kit/rules/rgpd-rules.md

@@ -0,0 +1,187 @@
+# RGPD/GDPR Validation Rules
+
+These rules are used by Spec-Kit to validate GDPR compliance after specification or implementation phases.
+
+> **Customization**: Edit this file to match your organization's data protection policies and local regulations.
+
+---
+
+## Data Identification
+
+### RGPD-001: Personal Data Inventory
+- [ ] All personal data collected is identified and documented
+- [ ] Data categories are classified (standard, sensitive, special)
+- [ ] Data sources are documented (user input, API, third-party)
+
+### RGPD-002: Data Mapping
+- [ ] Data flow is documented (collection → processing → storage → deletion)
+- [ ] All data processors are identified
+- [ ] Cross-border transfers documented (if applicable)
+
+---
+
+## Legal Basis (Article 6)
+
+### RGPD-010: Lawful Processing
+- [ ] Legal basis for each processing activity is documented
+  - [ ] Consent (freely given, specific, informed, unambiguous)
+  - [ ] Contract execution
+  - [ ] Legal obligation
+  - [ ] Vital interests
+  - [ ] Public interest
+  - [ ] Legitimate interests (with balancing test)
+
+### RGPD-011: Consent Management
+- [ ] Consent is obtained before processing (if consent-based)
+- [ ] Consent can be withdrawn as easily as given
+- [ ] Consent records are maintained
+- [ ] Age verification for minors (< 16 years)
+
+---
+
+## Data Subject Rights (Articles 12-22)
+
+### RGPD-020: Right to Information (Art. 13-14)
+- [ ] Privacy notice provided at data collection
+- [ ] Purpose of processing clearly stated
+- [ ] Data retention period communicated
+- [ ] Third-party sharing disclosed
+
+### RGPD-021: Right of Access (Art. 15)
+- [ ] Users can request copy of their data
+- [ ] Response within 30 days
+- [ ] Data provided in machine-readable format
+
+### RGPD-022: Right to Rectification (Art. 16)
+- [ ] Users can correct inaccurate data
+- [ ] Users can complete incomplete data
+- [ ] Updates propagated to third parties
+
+### RGPD-023: Right to Erasure / RTBF (Art. 17)
+- [ ] Users can request data deletion
+- [ ] Deletion includes backups (within reasonable time)
+- [ ] Third parties notified of erasure requests
+- [ ] Exceptions documented (legal retention, public interest)
+
+### RGPD-024: Right to Data Portability (Art. 20)
+- [ ] Data exportable in structured format (JSON, CSV)
+- [ ] Direct transfer to another controller (if feasible)
+
+### RGPD-025: Right to Object (Art. 21)
+- [ ] Users can object to processing
+- [ ] Objection mechanism easily accessible
+- [ ] Processing stops unless compelling grounds exist
+
+---
+
+## Data Protection Principles
+
+### RGPD-030: Data Minimization
+- [ ] Only necessary data collected
+- [ ] No "nice to have" data collection
+- [ ] Optional fields clearly marked
+
+### RGPD-031: Purpose Limitation
+- [ ] Data used only for stated purposes
+- [ ] New purposes require new consent/basis
+- [ ] No data repurposing without user knowledge
+
+### RGPD-032: Storage Limitation
+- [ ] Retention periods defined for each data type
+- [ ] Automatic deletion after retention period
+- [ ] Archival vs. active data distinguished
+
+### RGPD-033: Accuracy
+- [ ] Data kept up-to-date
+- [ ] Users can update their data
+- [ ] Inaccurate data corrected promptly
+
+---
+
+## Security Measures (Article 32)
+
+### RGPD-040: Technical Measures
+- [ ] Encryption at rest and in transit
+- [ ] Pseudonymization where possible
+- [ ] Access controls implemented
+- [ ] Regular security testing
+
+### RGPD-041: Organizational Measures
+- [ ] Staff trained on data protection
+- [ ] Data protection policies documented
+- [ ] Incident response procedures in place
+
+---
+
+## Third Parties & Processors
+
+### RGPD-050: Processor Agreements (Art. 28)
+- [ ] DPA (Data Processing Agreement) with all processors
+- [ ] Processor security measures verified
+- [ ] Sub-processors documented and approved
+
+### RGPD-051: International Transfers
+- [ ] Adequacy decision exists (for destination country)
+- [ ] Standard Contractual Clauses (SCCs) in place
+- [ ] Supplementary measures if required
+
+---
+
+## Documentation & Accountability
+
+### RGPD-060: Records of Processing (Art. 30)
+- [ ] Processing activities documented
+- [ ] ROPA (Record of Processing Activities) maintained
+- [ ] Available for supervisory authority
+
+### RGPD-061: DPIA (Art. 35)
+- [ ] DPIA required? (high-risk processing)
+- [ ] DPIA completed if required
+- [ ] Residual risks documented and accepted
+
+---
+
+## Validation Instructions
+
+When validating against these rules:
+
+1. **For Specifications**: Verify that data protection requirements are documented and RGPD compliance is designed-in
+2. **For Implementation**: Verify that code implements data protection measures and user rights mechanisms
+3. **Mark Status**:
+   - ✅ **Compliant**: Rule is fully addressed
+   - ⚠️ **Partial**: Rule is partially addressed, needs improvement
+   - ❌ **Non-Compliant**: Rule is not addressed, blocking issue
+   - ➖ **N/A**: Rule does not apply to this feature
+
+## Report Format
+
+```markdown
+## RGPD Compliance Report
+
+**Feature**: {feature_name}
+**Date**: {date}
+**Phase**: {spec|implementation}
+**DPO Review Required**: {yes|no}
+
+### Data Inventory
+| Data Type | Category | Legal Basis | Retention | Processors |
+|-----------|----------|-------------|-----------|------------|
+| email     | Personal | Consent     | 2 years   | SendGrid   |
+
+### Summary
+- Compliant: X rules
+- Partial: X rules
+- Non-Compliant: X rules
+- N/A: X rules
+
+### Findings
+
+#### Critical Issues (Blocking)
+{list blocking compliance issues}
+
+#### Warnings
+{list partial compliance items}
+
+#### Recommendations
+{list improvements for future}
+```

package/starter-kit/rules/security-rules.md

@@ -0,0 +1,138 @@
+# Security Validation Rules
+
+These rules are used by Spec-Kit to validate security compliance after specification or implementation phases.
+
+> **Customization**: Edit this file to match your organization's security policies.
+
+---
+
+## Authentication & Authorization
+
+### AUTH-001: Authentication Required
+- [ ] All endpoints accessing sensitive data require authentication
+- [ ] Authentication mechanism is industry-standard (OAuth2, OIDC, SAML)
+- [ ] No credentials stored in plain text
+
+### AUTH-002: Authorization Controls
+- [ ] Role-based access control (RBAC) implemented
+- [ ] Principle of least privilege applied
+- [ ] Authorization checked on every request (not just UI)
+
+### AUTH-003: Session Management
+- [ ] Session tokens are cryptographically secure
+- [ ] Session timeout implemented
+- [ ] Session invalidation on logout
+
+---
+
+## Data Protection
+
+### DATA-001: Data at Rest
+- [ ] Sensitive data encrypted at rest (AES-256 or equivalent)
+- [ ] Encryption keys managed securely (HSM, Key Vault)
+- [ ] Database credentials not hardcoded
+
+### DATA-002: Data in Transit
+- [ ] TLS 1.2+ required for all communications
+- [ ] Certificate validation enabled
+- [ ] No sensitive data in URLs
+
+### DATA-003: Data Sanitization
+- [ ] Input validation on all user inputs
+- [ ] Output encoding to prevent XSS
+- [ ] Parameterized queries to prevent SQL injection
+
+---
+
+## API Security
+
+### API-001: Input Validation
+- [ ] All inputs validated (type, length, format, range)
+- [ ] Request size limits enforced
+- [ ] File upload restrictions (type, size)
+
+### API-002: Rate Limiting
+- [ ] Rate limiting implemented on all endpoints
+- [ ] Brute force protection on authentication
+- [ ] DDoS mitigation considered
+
+### API-003: Error Handling
+- [ ] No stack traces exposed to users
+- [ ] Generic error messages for security failures
+- [ ] Detailed errors logged server-side only
+
+---
+
+## Infrastructure
+
+### INFRA-001: Secrets Management
+- [ ] Secrets stored in secure vault (Azure Key Vault, AWS Secrets Manager)
+- [ ] No secrets in source code or config files
+- [ ] Secrets rotated regularly
+
+### INFRA-002: Logging & Monitoring
+- [ ] Security events logged (auth failures, access denied)
+- [ ] No sensitive data in logs
+- [ ] Logs protected from tampering
+
+### INFRA-003: Dependencies
+- [ ] Dependencies scanned for vulnerabilities
+- [ ] Regular security updates applied
+- [ ] No known vulnerable dependencies
+
+---
+
+## Compliance Checks
+
+### COMP-001: OWASP Top 10
+- [ ] Injection vulnerabilities addressed
+- [ ] Broken authentication prevented
+- [ ] Sensitive data exposure mitigated
+- [ ] XXE attacks prevented
+- [ ] Broken access control fixed
+- [ ] Security misconfiguration avoided
+- [ ] XSS vulnerabilities prevented
+- [ ] Insecure deserialization handled
+- [ ] Components with known vulnerabilities updated
+- [ ] Insufficient logging addressed
+
+---
+
+## Validation Instructions
+
+When validating against these rules:
+
+1. **For Specifications**: Verify that security requirements are documented and address each applicable rule
+2. **For Implementation**: Verify that code implements the security controls described in the specification
+3. **Mark Status**:
+   - ✅ **Compliant**: Rule is fully addressed
+   - ⚠️ **Partial**: Rule is partially addressed, needs improvement
+   - ❌ **Non-Compliant**: Rule is not addressed, blocking issue
+   - ➖ **N/A**: Rule does not apply to this feature
+
+## Report Format
+
+```markdown
+## Security Validation Report
+
+**Feature**: {feature_name}
+**Date**: {date}
+**Phase**: {spec|implementation}
+
+### Summary
+- Compliant: X rules
+- Partial: X rules
+- Non-Compliant: X rules
+- N/A: X rules
+
+### Findings
+
+#### Critical Issues
+{list critical non-compliant items}
+
+#### Warnings
+{list partial compliance items}
+
+#### Recommendations
+{list improvements}
+```