trentlarson/crowd-funder-from-jason
1
0
Fork 0
forked from jsnbuchanan/crowd-funder-for-time-pwa
Code Issues Pull Requests Projects Releases Wiki Activity

refactor(cursor-rules): restructure rules architecture with meta-rule system

Browse Source 
- Reorganize cursor rules into logical domain-based directories
- Implement meta-rule system for workflow-specific rule bundling
- Move core rules to dedicated /core directory
- Consolidate development rules under /development namespace
- Add architectural patterns and implementation examples
- Create workflow-specific meta-rules for common development tasks
- Remove deprecated standalone rule files
- Update package dependencies for new rule structure

BREAKING CHANGE: Cursor rules file structure has been reorganized
Files moved from root rules directory to domain-specific subdirectories
This commit is contained in:
Matthew Raymer
2025-08-23 13:04:09 +00:00
parent b9ca59a718
commit a224aced85
61 changed files with 8944 additions and 2847 deletions
Download Patch File Download Diff File Expand all files Collapse all files

196
.cursor/rules/workflow/commit_messages.mdc Normal file
View File

@@ -0,0 +1,196 @@
# Commit Message Format and Templates
> **Agent role**:
Reference this file for commit message formatting and templates.
## Commit Message Format (Normative)
### A. Subject Line (required)
```
<type>(<scope>)<!>: <summary>
```
- **type** (lowercase, Conventional Commits):
`feat|fix|refactor|perf|docs|test|build|chore|ci|revert`
- **scope**: optional module/package/area (e.g., `api`, `ui/login`, `db`)
- **!**: include when a breaking change is introduced
- **summary**: imperative mood, ≤ 72 chars, no trailing period
**Examples**
- `fix(api): handle null token in refresh path`
- `feat(ui/login)!: require OTP after 3 failed attempts`
### B. Body (optional, when it adds non-obvious value)
- One blank line after subject.
- Wrap at ~72 chars.
- Explain **what** and **why**, not line-by-line "how".
- Include brief notes like tests passing or TS/lint issues resolved
**only if material**.
**Body checklist**
- [ ] Problem/symptom being addressed
- [ ] High-level approach or rationale
- [ ] Risks, tradeoffs, or follow-ups (if any)
### C. Footer (optional)
- Issue refs: `Closes #123`, `Refs #456`
- Breaking change (alternative to `!`):
`BREAKING CHANGE: <impact + migration note>`
- Authors: `Co-authored-by: Name <email>`
- Security: `CVE-XXXX-YYYY: <short note>` (if applicable)
## Content Guidance
### Include (when relevant)
- Specific fixes/features delivered
- Symptoms/problems fixed
- Brief note that tests passed or TS/lint errors resolved
### Avoid
- Vague: *improved, enhanced, better*
- Trivialities: tiny docs, one-liners, pure lint cleanups (separate,
focused commits if needed)
- Redundancy: generic blurbs repeated across files
- Multi-purpose dumps: keep commits **narrow and focused**
- Long explanations that good inline code comments already cover
**Guiding Principle:** Let code and inline docs speak. Use commits to
highlight what isn't obvious.
## Copy-Paste Templates
### Minimal (no body)
```text
<type>(<scope>): <summary>
```
### Standard (with body & footer)
```text
<type>(<scope>)<!>: <summary>
<why-this-change?>
<what-it-does?>
<risks-or-follow-ups?>
Closes #<id>
BREAKING CHANGE: <impact + migration>
Co-authored-by: <Name> <email>
```
## Type Descriptions
### feat
New feature for the user
### fix
Bug fix for the user
### docs
Documentation only changes
### style
Changes that do not affect the meaning of the code
### refactor
Code change that neither fixes a bug nor adds a feature
### perf
Code change that improves performance
### test
Adding missing tests or correcting existing tests
### build
Changes that affect the build system or external dependencies
### ci
Changes to CI configuration files and scripts
### chore
Other changes that don't modify src or test files
---
**See also**:
- `.cursor/rules/workflow/version_control.mdc` for
core version control principles
- `.cursor/rules/workflow/version_sync.mdc` for version synchronization details
**Status**: Active commit message guidelines
**Priority**: High
**Estimated Effort**: Ongoing reference
**Dependencies**: version_control.mdc
**Stakeholders**: Development team, AI assistants
## Model Implementation Checklist
### Before Creating Commits
- [ ] **Change Review**: Review all changes to be committed
- [ ] **Scope Assessment**: Determine if changes belong in single or multiple commits
- [ ] **Message Planning**: Plan clear, descriptive commit message
- [ ] **Convention Check**: Review commit message format requirements
### During Commit Creation
- [ ] **Type Selection**: Choose appropriate commit type (feat, fix, docs, etc.)
- [ ] **Message Writing**: Write clear, concise commit message
- [ ] **Body Content**: Add detailed description if needed
- [ ] **Breaking Changes**: Document breaking changes with `!` and migration notes
### After Commit Creation
- [ ] **Message Review**: Verify commit message follows conventions
- [ ] **Change Validation**: Confirm all intended changes are included
- [ ] **Documentation**: Update any related documentation
- [ ] **Team Communication**: Communicate significant changes to team

321
.cursor/rules/workflow/version_control.mdc
View File

@@ -1,155 +1,41 @@
---
description: interacting with git
alwaysApply: false
---
# Directive: Peaceful Co-Existence with Developers
**Author**: Matthew Raymer
**Date**: 2025-08-19
**Status**: 🎯 **ACTIVE** - Version control guidelines
## 1) Version-Control Ownership
## Core Principles
### 1) Version-Control Ownership
- **MUST NOT** run `git add`, `git commit`, or any write action.
- **MUST** leave staging/committing to the developer.
## 2) Source of Truth for Commit Text
### 2) Source of Truth for Commit Text
- **MUST** derive messages **only** from:
- files **staged** for commit (primary), and
- files **awaiting staging** (context).
- **MUST** use the **diffs** to inform content.
- **MUST NOT** invent changes or imply work not present in diffs.
## 3) Mandatory Preview Flow
### 3) Mandatory Preview Flow
- **ALWAYS** present, before any real commit:
- file list + brief per-file notes,
- a **draft commit message** (copy-paste ready),
- nothing auto-applied.
## 4) Version Synchronization Requirements
### 4) Version Synchronization Requirements
- **MUST** check for version changes in `package.json` before committing
- **MUST** ensure `CHANGELOG.md` is updated when `package.json` version
changes
- **MUST** ensure `CHANGELOG.md` is updated when `package.json` version changes
- **MUST** validate version format consistency between both files
- **MUST** include version bump commits in changelog with proper semantic
versioning
### Version Sync Checklist (Before Commit)
- [ ] `package.json` version matches latest `CHANGELOG.md` entry
- [ ] New version follows semantic versioning
(MAJOR.MINOR.PATCH[-PRERELEASE])
- [ ] Changelog entry includes all significant changes since last version
- [ ] Version bump commit message follows `build(version): bump to X.Y.Z`
format
- [ ] Breaking changes properly documented with migration notes
- [ ] Alert developer in chat message that version has been updated
### Version Change Detection
- **Check for version changes** in staged/unstaged `package.json`
- **Alert developer** if version changed but changelog not updated
- **Suggest changelog update** with proper format and content
- **Validate semantic versioning** compliance
### Implementation Notes
- **Version Detection**: Compare `package.json` version field with latest
changelog entry
- **Semantic Validation**: Ensure version follows `X.Y.Z[-PRERELEASE]`
format
- **Changelog Format**: Follow [Keep a Changelog](https://keepachangelog.com/)
standards
- **Breaking Changes**: Use `!` in commit message and `BREAKING CHANGE:`
in changelog
- **Pre-release Versions**: Include beta/alpha/rc suffixes in both files
consistently
## Commit Message Format (Normative)
### A. Subject Line (required)
```
<type>(<scope>)<!>: <summary>
```
- **type** (lowercase, Conventional Commits):
`feat|fix|refactor|perf|docs|test|build|chore|ci|revert`
- **scope**: optional module/package/area (e.g., `api`, `ui/login`, `db`)
- **!**: include when a breaking change is introduced
- **summary**: imperative mood, ≤ 72 chars, no trailing period
**Examples**
- `fix(api): handle null token in refresh path`
- `feat(ui/login)!: require OTP after 3 failed attempts`
### B. Body (optional, when it adds non-obvious value)
- One blank line after subject.
- Wrap at ~72 chars.
- Explain **what** and **why**, not line-by-line "how".
- Include brief notes like tests passing or TS/lint issues resolved
**only if material**.
**Body checklist**
- [ ] Problem/symptom being addressed
- [ ] High-level approach or rationale
- [ ] Risks, tradeoffs, or follow-ups (if any)
### C. Footer (optional)
- Issue refs: `Closes #123`, `Refs #456`
- Breaking change (alternative to `!`):
`BREAKING CHANGE: <impact + migration note>`
- Authors: `Co-authored-by: Name <email>`
- Security: `CVE-XXXX-YYYY: <short note>` (if applicable)
## Content Guidance
### Include (when relevant)
- Specific fixes/features delivered
- Symptoms/problems fixed
- Brief note that tests passed or TS/lint errors resolved
### Avoid
- Vague: *improved, enhanced, better*
- Trivialities: tiny docs, one-liners, pure lint cleanups (separate,
focused commits if needed)
- Redundancy: generic blurbs repeated across files
- Multi-purpose dumps: keep commits **narrow and focused**
- Long explanations that good inline code comments already cover
**Guiding Principle:** Let code and inline docs speak. Use commits to
highlight what isn't obvious.
## Copy-Paste Templates
### Minimal (no body)
```text
<type>(<scope>): <summary>
```
### Standard (with body & footer)
```text
<type>(<scope>)<!>: <summary>
<why-this-change?>
<what-it-does?>
<risks-or-follow-ups?>
Closes #<id>
BREAKING CHANGE: <impact + migration>
Co-authored-by: <Name> <email>
```
- **MUST** include version bump commits in changelog with
proper semantic versioning
## Assistant Output Checklist (before showing the draft)
@@ -159,177 +45,42 @@ Co-authored-by: <Name> <email>
- [ ] Body only if it adds non-obvious value
- [ ] No invented changes; aligns strictly with diffs
- [ ] Render as a single copy-paste block for the developer
- [ ] No invented changes; aligns strictly with diffs
- [ ] Render as a single copy-paste block for the developer
---
**See also**:
- `.cursor/rules/workflow/commit_messages.mdc` for commit message format and
templates
- `.cursor/rules/workflow/version_sync.mdc` for version synchronization details
**Status**: Active version control guidelines
**Priority**: High
**Estimated Effort**: Ongoing reference
**Dependencies**: git, package.json, CHANGELOG.md
**Stakeholders**: Development team, AI assistants
- [ ] No invented changes; aligns strictly with diffs
- [ ] Render as a single copy-paste block for the developer
## Model Implementation Checklist
## 1) Version-Control Ownership
### Before Version Control Work
- **MUST NOT** run `git add`, `git commit`, or any write action.
- **MUST** leave staging/committing to the developer.
- [ ] **File Analysis**: Review files staged and awaiting staging
- [ ] **Version Check**: Check for version changes in package.json
- [ ] **Changelog Review**: Verify CHANGELOG.md is updated if version changed
- [ ] **Diff Analysis**: Analyze actual changes from git diffs
## 2) Source of Truth for Commit Text
### During Version Control Work
- **MUST** derive messages **only** from:
- files **staged** for commit (primary), and
- files **awaiting staging** (context).
- **MUST** use the **diffs** to inform content.
- **MUST NOT** invent changes or imply work not present in diffs.
- [ ] **Commit Preview**: Present file list with brief notes per file
- [ ] **Message Draft**: Provide focused draft commit message
- [ ] **Format Validation**: Ensure message follows type(scope)! syntax
- [ ] **Version Sync**: Validate version consistency between files
## 3) Mandatory Preview Flow
### After Version Control Work
- **ALWAYS** present, before any real commit:
- file list + brief per-file notes,
- a **draft commit message** (copy-paste ready),
- nothing auto-applied.
## 4) Version Synchronization Requirements
- **MUST** check for version changes in `package.json` before committing
- **MUST** ensure `CHANGELOG.md` is updated when `package.json` version
changes
- **MUST** validate version format consistency between both files
- **MUST** include version bump commits in changelog with proper semantic
versioning
### Version Sync Checklist (Before Commit)
- [ ] `package.json` version matches latest `CHANGELOG.md` entry
- [ ] New version follows semantic versioning
(MAJOR.MINOR.PATCH[-PRERELEASE])
- [ ] Changelog entry includes all significant changes since last version
- [ ] Version bump commit message follows `build(version): bump to X.Y.Z`
format
- [ ] Breaking changes properly documented with migration notes
- [ ] Alert developer in chat message that version has been updated
### Version Change Detection
- **Check for version changes** in staged/unstaged `package.json`
- **Alert developer** if version changed but changelog not updated
- **Suggest changelog update** with proper format and content
- **Validate semantic versioning** compliance
### Implementation Notes
- **Version Detection**: Compare `package.json` version field with latest
changelog entry
- **Semantic Validation**: Ensure version follows `X.Y.Z[-PRERELEASE]`
format
- **Changelog Format**: Follow [Keep a Changelog](https://keepachangelog.com/)
standards
- **Breaking Changes**: Use `!` in commit message and `BREAKING CHANGE:`
in changelog
- **Pre-release Versions**: Include beta/alpha/rc suffixes in both files
consistently
## Commit Message Format (Normative)
### A. Subject Line (required)
```
<type>(<scope>)<!>: <summary>
```
- **type** (lowercase, Conventional Commits):
`feat|fix|refactor|perf|docs|test|build|chore|ci|revert`
- **scope**: optional module/package/area (e.g., `api`, `ui/login`, `db`)
- **!**: include when a breaking change is introduced
- **summary**: imperative mood, ≤ 72 chars, no trailing period
**Examples**
- `fix(api): handle null token in refresh path`
- `feat(ui/login)!: require OTP after 3 failed attempts`
### B. Body (optional, when it adds non-obvious value)
- One blank line after subject.
- Wrap at ~72 chars.
- Explain **what** and **why**, not line-by-line "how".
- Include brief notes like tests passing or TS/lint issues resolved
**only if material**.
**Body checklist**
- [ ] Problem/symptom being addressed
- [ ] High-level approach or rationale
- [ ] Risks, tradeoffs, or follow-ups (if any)
### C. Footer (optional)
- Issue refs: `Closes #123`, `Refs #456`
- Breaking change (alternative to `!`):
`BREAKING CHANGE: <impact + migration note>`
- Authors: `Co-authored-by: Name <email>`
- Security: `CVE-XXXX-YYYY: <short note>` (if applicable)
## Content Guidance
### Include (when relevant)
- Specific fixes/features delivered
- Symptoms/problems fixed
- Brief note that tests passed or TS/lint errors resolved
### Avoid
- Vague: *improved, enhanced, better*
- Trivialities: tiny docs, one-liners, pure lint cleanups (separate,
focused commits if needed)
- Redundancy: generic blurbs repeated across files
- Multi-purpose dumps: keep commits **narrow and focused**
- Long explanations that good inline code comments already cover
**Guiding Principle:** Let code and inline docs speak. Use commits to
highlight what isn't obvious.
## Copy-Paste Templates
### Minimal (no body)
```text
<type>(<scope>): <summary>
```
### Standard (with body & footer)
```text
<type>(<scope>)<!>: <summary>
<why-this-change?>
<what-it-does?>
<risks-or-follow-ups?>
Closes #<id>
BREAKING CHANGE: <impact + migration>
Co-authored-by: <Name> <email>
```
## Assistant Output Checklist (before showing the draft)
- [ ] List changed files + 1–2 line notes per file
- [ ] Provide **one** focused draft message (subject/body/footer)
- [ ] Subject ≤ 72 chars, imperative mood, correct `type(scope)!` syntax
- [ ] Body only if it adds non-obvious value
- [ ] No invented changes; aligns strictly with diffs
- [ ] Render as a single copy-paste block for the developer
---
**Status**: Active version control guidelines
**Priority**: High
**Estimated Effort**: Ongoing reference
**Dependencies**: git, package.json, CHANGELOG.md
**Stakeholders**: Development team, AI assistants
* [ ] No invented changes; aligns strictly with diffs
* [ ] Render as a single copy-paste block for the developer
- [ ] **Developer Control**: Leave staging/committing to developer
- [ ] **Message Validation**: Verify message aligns strictly with diffs
- [ ] **Version Validation**: Confirm version format consistency
- [ ] **Documentation**: Update relevant version control documentation

176
.cursor/rules/workflow/version_sync.mdc Normal file
View File

@@ -0,0 +1,176 @@
# Version Synchronization and Changelog Management
> **Agent role**: Reference this file for version synchronization
> requirements and changelog management.
## Version Sync Checklist (Before Commit)
- [ ] `package.json` version matches latest `CHANGELOG.md` entry
- [ ] New version follows semantic versioning
(MAJOR.MINOR.PATCH[-PRERELEASE])
- [ ] Changelog entry includes all significant changes since last version
- [ ] Version bump commit message follows `build(version): bump to X.Y.Z`
format
- [ ] Breaking changes properly documented with migration notes
- [ ] Alert developer in chat message that version has been updated
## Version Change Detection
- **Check for version changes** in staged/unstaged `package.json`
- **Alert developer** if version changed but changelog not updated
- **Suggest changelog update** with proper format and content
- **Validate semantic versioning** compliance
## Implementation Notes
### Version Detection
- Compare `package.json` version field with latest changelog entry
- Use semantic versioning validation
- Check for pre-release version consistency
### Semantic Validation
- Ensure version follows `X.Y.Z[-PRERELEASE]` format
- Validate major.minor.patch components
- Handle pre-release suffixes (beta, alpha, rc)
### Changelog Format
- Follow [Keep a Changelog](https://keepachangelog.com/) standards
- Use consistent section headers
- Include breaking change notes
- Maintain chronological order
### Breaking Changes
- Use `!` in commit message
- Include `BREAKING CHANGE:` in changelog
- Provide migration notes
- Document impact clearly
### Pre-release Versions
- Include beta/alpha/rc suffixes consistently
- Update both `package.json` and changelog
- Maintain version number alignment
- Document pre-release status
## Changelog Sections
### Added
- New features
- New capabilities
- New dependencies
### Changed
- Changes in existing functionality
- API changes
- Performance improvements
### Deprecated
- Soon-to-be removed features
- Migration paths
- Sunset timelines
### Removed
- Removed features
- Breaking changes
- Deprecated items
### Fixed
- Bug fixes
- Security patches
- Performance fixes
### Security
- Security vulnerabilities
- CVE references
- Mitigation steps
## Version Bump Guidelines
### Patch (X.Y.Z+1)
- Bug fixes
- Documentation updates
- Minor improvements
### Minor (X.Y+1.Z)
- New features
- Backward-compatible changes
- Significant improvements
### Major (X+1.Y.Z)
- Breaking changes
- Major API changes
- Incompatible changes
## Pre-release Guidelines
### Beta Versions
- Feature complete
- Testing phase
- API stable
### Alpha Versions
- Early development
- API may change
- Limited testing
### Release Candidates
- Final testing
- API frozen
- Production ready
---
**See also**:
- `.cursor/rules/workflow/version_control.mdc` for core version
control principles
- `.cursor/rules/workflow/commit_messages.mdc` for commit message
format
**Status**: Active version synchronization guide
**Priority**: High
**Estimated Effort**: Ongoing reference
**Dependencies**: version_control.mdc
**Stakeholders**: Development team, Release team
## Model Implementation Checklist
### Before Version Changes
- [ ] **Version Review**: Check current version in `package.json` and `CHANGELOG.md`
- [ ] **Change Assessment**: Identify what type of version bump is needed (patch/minor/major)
- [ ] **Breaking Changes**: Review if any changes are breaking and require
major version
- [ ] **Pre-release Status**: Determine if this should be a pre-release version
### During Version Synchronization
- [ ] **Semantic Validation**: Ensure version follows `X.Y.Z[-PRERELEASE]` format
- [ ] **Package Update**: Update `package.json` version field
- [ ] **Changelog Entry**: Add entry to `CHANGELOG.md` following Keep a Changelog
format
- [ ] **Breaking Changes**: Document breaking changes with migration notes
if applicable
### After Version Changes
- [ ] **Commit Format**: Use `build(version): bump to X.Y.Z` commit message format
- [ ] **Developer Alert**: Alert developer that version has been updated
- [ ] **Validation**: Verify `package.json` and `CHANGELOG.md` are in sync
- [ ] **Pre-release Handling**: Ensure pre-release versions are consistently formatted