smdev 1.1.1 → 1.2.0

data/lib/smdev/cursor_rules/templates/.cursor/rules/global-rules/emoji-communication-always.mdc

@@ -0,0 +1,33 @@
+---
+description: 
+globs:
+alwaysApply: false
+---
+
+# Emoji Communication Guidelines
+
+## Critical Rules
+
+  - Use emojis purposefully to enhance meaning, but feel free to be creative and fun
+  - Place emojis at the end of statements or sections
+  - Maintain professional tone while surprising users with clever choices
+  - Limit emoji usage to 1-2 per major section
+  - Choose emojis that are both fun and contextually appropriate
+  - Place emojis at the end of statements, not at the beginning or middle
+  - Don't be afraid to tell a mini-story with your emoji choice 
+
+## Examples
+
+<example>
+  "I've optimized your database queries 🏃‍♂️"
+  "Your bug has been squashed 🥾🐛"
+  "I've cleaned up the legacy code 🧹✨"
+  "Fixed the performance issue 🐌➡️🐆"
+</example>
+
+<example type="invalid">
+  "Multiple 🎉 emojis 🎊 in 🌟 one message"
+  "Using irrelevant emojis 🥑"
+  "Placing the emoji in the middle ⭐️ of a sentence"
+  "Great Job!!!" - lack of obvious use of an emoji
+</example>

data/lib/smdev/cursor_rules/templates/.cursor/rules/global-rules/performance-standards-agent.mdc

@@ -0,0 +1,36 @@
+---
+description: Apply when writing or modifying code that could impact system performance
+globs: *.rb, *.erb.html
+alwaysApply: false
+---
+
+# Performance Standards
+
+## Context
+- Ensures application performance and scalability
+- Prevents common performance issues
+- Guides optimization decisions
+
+## Critical Rules
+- Optimize database queries
+- Implement appropriate caching
+- Use background jobs for heavy tasks
+- Add necessary database indexes
+- Monitor and fix N+1 queries
+- Use bulk operations when possible
+
+## Examples
+
+<example>
+- Using includes to prevent N+1 queries
+- Using bulk_insert for multiple records
+- Implementing fragment caching for views
+- Moving heavy processing to Sidekiq jobs
+</example>
+
+<example type="invalid">
+- Loading associations without includes
+- Creating records in loops
+- Processing large datasets in web requests
+- Not using indexes on frequently queried columns
+</example> 

data/lib/smdev/cursor_rules/templates/.cursor/rules/global-rules/readme.md

@@ -0,0 +1,5 @@
+All globally applying always on rules that will bloat every chat and cmd-k context go here.
+
+Rules in this folder will have alwaysApply: true with blank descriptions and globs.
+
+These are equivalent to the root project .cursorrules files (which are now deprecated and may be removed in a future cursor version)

data/lib/smdev/cursor_rules/templates/.cursor/rules/global-rules/tech-stack-agent.mdc

@@ -0,0 +1,42 @@
+---
+description: Information about the project's technology stack and core dependencies
+globs: 
+alwaysApply: true
+---
+
+# Project Technology Stack
+
+## Context
+- Defines the core technologies and external services used in the project
+- Reference for making technology decisions
+- Guide for maintaining consistency across the project
+
+## Critical Rules
+- Use Ruby on Rails as the web framework
+- Use zsh for shell
+- Target Apple Silicon for dependencies
+- Use Homebrew for package management
+- Use Bundler for dependency management
+- Implement Hotwire Turbo/Stimulus for frontend interactivity
+- Style with Backpack UI and TailwindCSS
+- Use Font Awesome for icons
+- Use PostgreSQL for database
+- Implement Sidekiq + Redis for background jobs
+- Integrate with:
+  - Stripe for payments
+  - Algolia for search
+  - StrongMind Identity for SSO
+
+## Examples
+
+<example>
+- Using Turbo Frames for dynamic content loading
+- Use Rails generators for new migrations
+- Implementing Stimulus controllers for interactive components
+- Using Sidekiq workers for background processing
+</example>
+
+<example type="invalid">
+- Using Powershell for shell
+
+</example> 

data/lib/smdev/cursor_rules/templates/.cursor/rules/rb-rules/database-standards-agent.mdc

@@ -0,0 +1,52 @@
+---
+description: Apply when working with database-related code to ensure proper structure and performance
+globs: db/migrate/*.rb, app/models/*.rb
+alwaysApply: false
+---
+
+# Database Standards
+
+## Context
+- Ensures consistent database design
+- Maintains data integrity
+- Optimizes performance
+
+## Critical Rules
+- Include foreign key constraints
+- Add appropriate indexes
+- Use references for associations
+- Follow standard model structure:
+  1. Constants
+  2. Associations
+  3. Validations
+  4. Scopes
+  5. Class methods
+  6. Instance methods
+
+## Examples
+
+<example>
+class User < ApplicationRecord
+  ROLES = %w[admin moderator user].freeze
+  
+  belongs_to :organization
+  has_many :posts, dependent: :destroy
+  
+  validates :name, presence: true
+  
+  scope :active, -> { where(status: 'active') }
+end
+</example>
+
+<example type="invalid">
+class User < ApplicationRecord
+  def full_name
+    "#{first_name} #{last_name}"
+  end
+  
+  ROLES = %w[admin moderator user].freeze
+  
+  validates :name, presence: true
+  belongs_to :organization
+end
+</example> 

data/lib/smdev/cursor_rules/templates/.cursor/rules/rb-rules/rails-conventions-agent.mdc

@@ -0,0 +1,48 @@
+---
+description: Apply when working with Ruby/Rails files to ensure consistent patterns and practices
+globs: *.rb, *.rake
+alwaysApply: false
+---
+
+# Rails Development Standards
+
+## Context
+- Ensures consistent Ruby/Rails development practices
+- Maintains code quality and readability
+- Guides architectural decisions
+
+## Critical Rules
+- Follow current Rails version conventions
+- Use Rails generators for database changes
+- Use Ruby 3.x syntax
+- Use string interpolation over concatenation
+- Use double quotes only for interpolation
+- Follow "skinny controller, fat model" pattern
+- Use concerns for shared functionality
+- Use service objects for complex business logic
+- Prefer server-side solutions using Turbo over client-side JS
+
+## Examples
+
+<example>
+# Good Implementation
+name = "World"
+message = "Hello #{name}"
+
+class UserService
+  def self.create_with_profile(params)
+    # Complex business logic here
+  end
+end
+</example>
+
+<example type="invalid">
+name = "World"
+message = "Hello " + name
+
+class UsersController
+  def create
+    # Complex business logic in controller
+  end
+end
+</example> 

data/lib/smdev/cursor_rules/templates/.cursor/rules/rb-rules/readme.md

@@ -0,0 +1 @@
+Ruby on Rails Specific Rules belong in this folder

data/lib/smdev/cursor_rules/templates/.cursor/rules/testing-rules/rspec-standards-agent.mdc

@@ -0,0 +1,51 @@
+---
+description: Apply when writing or modifying test files to ensure consistent testing practices
+globs: spec/**/*.rb
+alwaysApply: false
+---
+
+# Testing Standards
+
+## Context
+- Ensures consistent testing practices
+- Maintains test quality and readability
+- Guides test structure and organization
+
+## Critical Rules
+- Use RSpec for testing
+- Use FactoryBot for test data
+- Write descriptive test cases
+- Test both happy and sad paths
+- Don't mock attributes of the testing subject
+- Ignore spec type in descriptions
+- Ignore 'require rails_helper'
+
+## Examples
+
+<example>
+RSpec.describe User do
+  describe 'validations' do
+    it { should validate_presence_of(:name) }
+  end
+  
+  describe '#full_name' do
+    it 'returns the combined first and last name' do
+      user = create(:user, first_name: 'John', last_name: 'Doe')
+      expect(user.full_name).to eq('John Doe')
+    end
+  end
+end
+</example>
+
+<example type="invalid">
+require 'rails_helper'
+
+RSpec.describe User, type: :model do
+  describe 'User#full_name' do
+    it 'works' do
+      user = User.new(first_name: 'John', last_name: 'Doe')
+      expect(user.full_name).to eq('John Doe')
+    end
+  end
+end
+</example> 

data/lib/smdev/cursor_rules/templates/.cursor/rules/tool-rules/gitpush.mdc

@@ -0,0 +1,35 @@
+---
+description:
+globs:
+alwaysApply: false
+---
+
+# Git Push Manual Rule
+
+## Context
+
+Used when user indicates they want to update all saved changes in git
+
+## Critical Rules
+
+- Run the command `git add .` from the root of the workspace
+- Review all added changes that will be included in the commit
+- Use format for title: `type: brief description` - keep it brief and descriptive (max 72 chars)
+- Add two line breaks after commit title
+- Include short paragraph summary of gist of what and why the change is being made and end with " -Agent Generated Commit Message"
+- Push all to the remote current branch
+
+## Examples
+
+<example>
+doc: explain recent rules changes in cursor
+
+Updated the readme to include a better diagram showing rules workflow, while
+also adding more sample rules to show rule folder organization. Specifically, notice that the change to `.cursor/rules/*folders` include readme.md files also to aid in understanding the folders purpose for human developers. AI gets its understanding from `.cursor/rules/rule-generating-agent.mdc` instead.
+
+-Agent Generated Commit Message
+</example>
+
+<example type="invalid">
+fixed stuff
+</example>

data/lib/smdev/cursor_rules/templates/.cursor/rules/tool-rules/readme.md

@@ -0,0 +1 @@
+Rules specific to different tools, such as git, linux commands, direction of usage of MCP tools.

data/lib/smdev/cursor_rules/templates/.cursor/rules/ts-rules/readme.md

@@ -0,0 +1 @@
+TypeScript Specific Rules belong in this folder

data/lib/smdev/cursor_rules/templates/.cursor/rules/ui-rules/readme.md

@@ -0,0 +1,11 @@
+# UI Rules Directory
+
+This directory contains rules related to frontend development and user interface design, including:
+
+- Rails Views
+- HTML structure and semantics
+- CSS and styling guidelines
+- View Components (if applicable)
+- General frontend development practices
+
+Each rule in this directory should focus on specific UI/UX concerns and follow the standard .mdc file format. Rules should be stored in individual .mdc files with appropriate naming conventions (e.g., *-agent.mdc, *-auto.mdc, *-always.mdc).

data/lib/smdev/cursor_rules/templates/.cursor/rules/ui-rules/ui-component-standards-agent.mdc

@@ -0,0 +1,55 @@
+---
+description: Apply when creating or modifying any UI components to ensure consistent styling and UX patterns
+globs: *.erb.html, *.css, *.scss, *.less
+alwaysApply: false
+---
+
+# StrongMind UI Component Standards
+
+## Context
+
+- Ensures consistent UI/UX across StrongMind applications
+- Maintains design system compliance
+- Promotes maintainable styling patterns
+
+## Critical Rules
+
+- Check "@BackPack UI" FIRST before creating custom components
+- Use StrongMind UX library components with their default styling when available
+- Implement Tailwind utility classes for custom styling needs
+- Group related Tailwind classes using consistent ordering:
+  1. Layout (flex, grid, position)
+  2. Spacing (margin, padding)
+  3. Sizing (width, height)
+  4. Typography
+  5. Colors and visual effects
+- Use semantic HTML elements as base components when possible
+
+## Examples
+
+<example>
+// Using StrongMind UX library component
+// Good - Using UX library with Tailwind for custom positioning
+<button
+  className="mt-4 ml-auto sm-btn"
+>
+  Submit
+</button>
+
+// Good - Consistent class ordering
+<div className="flex items-center p-4 w-full text-sm text-gray-700 bg-white">
+  {children}
+</div>
+</example>
+
+<example type="invalid">
+// Bad - Custom button when UX library provides one
+<button className="px-4 py-2 bg-blue-500 text-white rounded">
+  Submit
+</button>
+
+// Bad - Inconsistent class ordering
+<div className="text-sm bg-white flex w-full items-center p-4">
+  {children}
+</div>
+</example> 

data/lib/smdev/cursor_rules/templates/.cursor/rules/workflows/workflow-agile-manual.mdc

@@ -0,0 +1,48 @@
+---
+description:
+globs:
+alwaysApply: false
+---
+# Agile Workflow and core memory procedure RULES that MUST be followed EXACTLY!
+
+<critical-rules>
+- First Ensure a .ai/prd.md file exists, if not, work with the user to create one so you know in full detail what the project is about.
+- This workflow rule is critical to your memory systems, all retention of what is planned or what has been completed or changed will be recorded in the .ai folder.
+- It is critical that this information be retained in top quality and kept up to date.
+- When you are unsure, reference the PRD, ARCH, current and previous stories as needed to guide you. If still unsure, don't ever guess - ask the user for help.
+</critical-rules>
+
+1. When coming online, you will first check if a .ai/prd.md file exists, if not, work with the user to create one to you know what the project is about.
+2. If the PRD is not `status: approved`, you will ONLY have the goal of helping improve the .ai/prd.md file as needed and getting it approved by the user to ensure it is the best possible document including the following:
+   - Very Detailed Purpose, problems solved, and task sequence.
+   - Very Detailed Architecture patterns and key technical decisions, mermaid diagrams to help visualize the architecture.
+   - Very Detailed Technologies, setup, and constraints.
+   - Unknowns, assumptions, and risks.
+   - It must be formatted and include at least everything outlined in the `.cursor/templates/template-prd.md`
+3. Once the .ai/prd.md file is created and the status is approved, you will generate the architecture document .ai/arch.md draft - which also needs to be approved.
+   - The template for this must be used and include all sections from the template at a minimum: `.cursor/templates/template-arch.md`
+4. Once the `.ai/arch.md` is approved, create the draft of the first story in the .ai folder.
+5. Always use the `.cursor/templates/template-story.md` file as a template for the story. The story will be named <story-or-task-><N>.story.md added to the .ai folder
+   - Example: .ai/story-1.story.md or .ai/task-1.story.md
+6. You will ALWAYS wait for approval of the story before proceeding to do any coding or work on the story.
+7. You are a TDD Master, so you will run tests and ensure tests pass before going to the next subtask or story.
+8. You will update the story file as subtasks are completed.
+9. Once a Story is complete, you will generate a draft of the next story and wait on approval before proceeding.
+
+### During Development
+
+- Update story files as subtasks are completed.
+- If you are unsure of the next step, ask the user for clarification.
+- When prompted by the user with 'update story', update the current story to:
+  - Reflect the current state.
+  - Clarify next steps.
+  - Ensure the chat log in the story is up to date with any chat thread interactions
+- Continue to verify the story is correct and the next steps are clear.
+- Remember that a story is not complete if you have not also run ALL stories and verified all stories pass. Do not tell the user the story is complete, or mark the story as complete unless you have run ALL the tests.
+
+## YOU DO NOT NEED TO ASK to:
+
+1. Create the story file to be worked on next if none exist.
+2. Run unit Tests during the development process until they pass.
+3. Update the story AC and tasks as they are completed.
+4. Update the story file with the chat log or other updates to retain the best possible memory of the story.

data/lib/smdev/cursor_rules/templates/.cursor/templates/template-arch.md

@@ -0,0 +1,76 @@
+# Architecture for {PRD Title}
+
+Status: { Draft | Approved }
+
+## Technical Summary
+
+{ Short 1-2 paragraph }
+
+## Technology Table
+
+Table listing choices for languages, libraries, infra, etc...
+
+  <example>
+  | Technology | Description |
+  | ------------ | ------------------------------------------------------------- |
+  | Kubernetes | Container orchestration platform for microservices deployment |
+  | Apache Kafka | Event streaming platform for real-time data ingestion |
+  | TimescaleDB | Time-series database for sensor data storage |
+  | Go | Primary language for data processing services |
+  | GoRilla Mux | REST API Framework |
+  | Python | Used for data analysis and ML services |
+  </example>
+
+## Architectural Diagrams
+
+{ Mermaid Diagrams to describe key flows interactions or architecture to be followed during implementation, infra provisioning, and deployments }
+
+## Data Models, API Specs, Schemas, etc...
+
+{ As needed - may not be exhaustive - but key ideas that need to be retained and followed into the architecture and stories }
+
+<example>
+### Sensor Reading Schema
+
+```json
+{
+  "sensor_id": "string",
+  "timestamp": "datetime",
+  "readings": {
+    "temperature": "float",
+    "pressure": "float",
+    "humidity": "float"
+  },
+  "metadata": {
+    "location": "string",
+    "calibration_date": "datetime"
+  }
+}
+```
+
+</example>
+
+## Project Structure
+
+{ Diagram the folder and file organization structure along with descriptions }
+
+```
+├ /src
+├── /services
+│   ├── /gateway        # Sensor data ingestion
+│   ├── /processor      # Data processing and validation
+│   ├── /analytics      # Data analysis and ML
+│   └── /notifier       # Alert and notification system
+├── /deploy
+│   ├── /kubernetes     # K8s manifests
+│   └── /terraform      # Infrastructure as Code
+└── /docs
+    ├── /api           # API documentation
+    └── /schemas       # Data schemas
+```
+
+## Infrastructure
+
+## Deployment Plan
+
+## Change Log

data/lib/smdev/cursor_rules/templates/.cursor/templates/template-prd.md

@@ -0,0 +1,136 @@
+# 1. Title: {PRD for {project}}
+
+<version>1.0.0</version>
+
+## Status: { Draft | Approved }
+
+## Intro
+
+{ Short 1-2 paragraph describing the what and why of what the prd will achieve}
+
+## Goals
+
+{
+
+- Clear project objectives
+- Measurable outcomes
+- Success criteria
+- Key performance indicators (KPIs)
+  }
+
+## Features and Requirements
+
+{
+
+- Functional requirements
+- Non-functional requirements
+- User experience requirements
+- Integration requirements
+- Compliance requirements
+  }
+
+## Epic List
+
+### Epic-1: Current PRD Epic (for example backend epic)
+
+### Epic-2: Second Current PRD Epic (for example front end epic)
+
+### Epic-N: Future Epic Enhancements (Beyond Scope of current PRD)
+
+## Epic 1: Story List
+
+<example>
+- Story 1: NestJS Configuration
+  Status: {''|'InProgress'|'Complete'}
+  Requirements:
+  - Install NestJS CLI Globally
+  - Create a new NestJS project with the nestJS cli generator
+
+- Story 2: Hacker News Retrieval API Route
+  Status: {''|'InProgress'|'Complete'}
+  Requirements:
+  - Create API Route that returns a list of Hacker News TopPosts, Scrapped Article from the top posts, and a list of comments from the top posts
+  - Route post body specifies the number of posts, articles, and comments to return
+  - Create a command in package.json that I can use to call the API Route (route configured in env.local)
+    </example>
+
+## Technology Stack
+
+{ Table listing choices for languages, libraries, infra, etc...}
+
+  <example>
+  | Technology | Description |
+  | ------------ | ------------------------------------------------------------- |
+  | Kubernetes | Container orchestration platform for microservices deployment |
+  | Apache Kafka | Event streaming platform for real-time data ingestion |
+  | TimescaleDB | Time-series database for sensor data storage |
+  | Go | Primary language for data processing services |
+  | GoRilla Mux | REST API Framework |
+  | Python | Used for data analysis and ML services |
+  </example>
+
+## Reference
+
+{ Mermaid Diagrams for models tables, visual aids as needed, citations and external urls }
+
+## Data Models, API Specs, Schemas, etc...
+
+{ As needed - may not be exhaustive - but key ideas that need to be retained and followed into the architecture and stories }
+
+<example>
+### Sensor Reading Schema
+
+```json
+{
+  "sensor_id": "string",
+  "timestamp": "datetime",
+  "readings": {
+    "temperature": "float",
+    "pressure": "float",
+    "humidity": "float"
+  },
+  "metadata": {
+    "location": "string",
+    "calibration_date": "datetime"
+  }
+}
+```
+
+</example>
+
+## Project Structure
+
+{ Diagram the folder and file organization structure along with descriptions }
+
+<example>
+
+````
+// Start of Selection
+```text
+src/
+├── services/
+│   ├── gateway/        # Sensor data ingestion
+│   ├── processor/      # Data processing and validation
+│   ├── analytics/      # Data analysis and ML
+│   └── notifier/       # Alert and notification system
+├── deploy/
+│   ├── kubernetes/     # K8s manifests
+│   └── terraform/      # Infrastructure as Code
+└── docs/
+    ├── api/           # API documentation
+    └── schemas/       # Data schemas
+````
+
+</example>
+
+## Change Log
+
+{ Markdown table of key changes after document is no longer in draft and is updated, table includes the change title, the story id that the change happened during, and a description if the title is not clear enough }
+
+<example>
+| Change               | Story ID | Description                                                   |
+| -------------------- | -------- | ------------------------------------------------------------- |
+| Initial draft        | N/A      | Initial draft prd                                             |
+| Add ML Pipeline      | story-4  | Integration of machine learning prediction service story      |
+| Kafka Upgrade        | story-6  | Upgraded from Kafka 2.0 to Kafka 3.0 for improved performance |
+</example>