Add new checklist maintenance rules and Git Bash scripting guidelines, update rules mostly for lint rules

- Introduce checklist maintenance rules for project organization
- Create guidelines for Git Bash scripting best practices
- Remove outdated PowerShell console commands rules
- Update import organization rules for JavaScript/TypeScript
- Add markdown best practices and PowerShell scripting guidelines
- Establish shell choice guidelines for Windows tasks

Author: pstackebrandt

.cursor/rules/checklist-maintenance.mdc

@@ -0,0 +1,70 @@
+---
+description: Rules for maintaining project checklists
+globs: "**/*checklist.md"
+alwaysApply: true
+---
+
+Checklist Maintenance Rules
+===========================
+
+Status Indicators
+-----------------
+
+- ✅ Completed: Task is fully implemented and verified
+- - [ ] Todo: Task not yet started or completed
+- 🔄 In-progress: Work has started but not completed
+- ⚠️ Blocked: Waiting on external dependency
+
+Organization
+------------
+
+- Group by functional area (Docker, Security, etc.)
+- List completed items first within each section
+- Place priority items immediately after completed items
+- Use logical workflow order for sections
+
+Formatting
+----------
+
+- Use h1 (`#`) for document title (Setext-style with `=====`)
+- Use h2 (`##`) for main sections (Setext-style with `-----`)
+- Use h3 (`###`) for subsections (`###` atx-style)
+- Use bullet lists for checklist items
+- Use 2-space indentation for nested items
+- Keep line length under 120 characters
+- Use code blocks with language identifiers
+
+Example
+-------
+
+```markdown
+## Security
+
+✅ HTTPS redirection configured  
+✅ Sensitive files excluded from source control  
+
+- [ ] Add rate limiting for API endpoints  
+- [ ] Implement CORS policy configuration  
+```
+
+Update Process
+--------------
+
+1. Review project status to identify completed items
+2. Update status indicators accordingly
+3. Add new requirements that have emerged
+4. Remove duplicate or obsolete items
+5. Ensure cross-references remain valid
+
+Rule Types
+----------
+
+- **Manual** (`alwaysApply: false`): Only applied when explicitly requested
+- **Always** (`alwaysApply: true`): Applied across all matching files automatically
+- **Auto Attached**: Automatically attaches to relevant files based on content (Cursor feature)
+- **Agent Requested**: Applied when the AI determines they're relevant (Cursor feature)
+
+- **Manual** (`alwaysApply: false`): Only applied when explicitly requested
+- **Always** (`alwaysApply: true`): Applied across all matching files automatically
+- **Auto Attached**: Automatically attaches to relevant files based on content (Cursor feature)
+- **Agent Requested**: Applied when the AI determines they're relevant (Cursor feature)

.cursor/rules/console-commands-for-powershell.mdc

@@ -0,0 +1,39 @@
+---
+description: Guidelines for creating and using Git Bash scripts
+globs: "*.sh"
+alwaysApply: false
+---
+
+Selected Git Bash Scripting Guidelines
+======================================
+
+File Format
+-----------
+- Use LF line endings (not CRLF)
+- Use UTF-8 without BOM
+- Start with shebang: `#!/bin/bash`
+
+Path Handling
+-------------
+- Use forward slashes in paths: `/path/to/dir`
+- Always quote paths with spaces
+- Use relative paths when possible
+
+Error Handling
+--------------
+- Use `set -e` for immediate exit on error
+- Check exit codes: `if [ $? -ne 0 ]; then ... fi`
+- Log errors to stderr: `echo "Error: message" >&2`
+
+PowerShell Integration
+----------------------
+- Use `Invoke-GitBash` helper
+- Example:
+  ```powershell
+  Invoke-GitBash "./scripts/your-script.sh"
+  ```
+
+- Example:
+  ```powershell
+  Invoke-GitBash "./scripts/your-script.sh"
+  ```

.cursor/rules/git-bash-scripting.mdc

@@ -1,9 +1,9 @@
 ---
-description: Empty Lines Between Import Groups
 globs: "**/*.js", "**/*.jsx", "**/*.ts", "**/*.tsx"
-alwaysApply: true
+alwaysApply: false
 ---
-When organizing imports in JavaScript/TypeScript files, maintain at least one empty line between different import groups to follow the eslint import/order rule.
+When organizing imports in JavaScript/TypeScript files, maintain at least one empty line between different import
+groups to follow the eslint import/order rule.
 
 Import groups are typically arranged in this order:
 1. Built-in Node.js modules
@@ -41,4 +41,3 @@ This pattern:
 - Helps maintain consistent code organization
 
 Benefits: Improves readability, makes code organization consistent, and satisfies linting requirements.
-

.cursor/rules/import-groups-spacing.mdc

@@ -1,32 +1,30 @@
 ---
-description: 
-globs: 
-alwaysApply: false
----
----
-description: Import Order Requirements for React Components
 globs: "**/*.js", "**/*.jsx", "**/*.ts", "**/*.tsx"
-alwaysApply: true
+alwaysApply: false
 ---
-# Import Ordering Rules
+Import Ordering Rules
+=====================
 
 For proper linting compliance, imports must follow this specific ordering pattern:
 
-## Order by Import Group
+Order by Import Group
+---------------------
 1. External/npm modules (React, react-router-dom, etc.)
 2. Blank line
 3. Internal project modules (components, utilities)
 4. Stylesheets (CSS, SCSS)
 5. Component imports in alphabetical order
 6. Image/asset imports according to specific pattern
 
-## Image/Asset Import Order
+Image/Asset Import Order
+------------------------
 For image imports with different sizes and formats:
 
 1. Group by size first (large, medium, small)
 2. For each size group, order by format (.jpg first, then .webp)
 
-### Example
+Example
+-------
 ```javascript
 // External packages
 import React from 'react';
@@ -47,7 +45,4 @@ import portraitImageSmall from '../images/portrait-small.jpg';
 import portraitImageSmallWebp from '../images/portrait-small.webp';
 ```
 
-This pattern satisfies ESLint import/order rules and maintains consistent code organization.
-```
-
-</rewritten_file>
+This pattern satisfies ESLint import/order rules and maintains consistent code organization.

.cursor/rules/import-order-rules.mdc

@@ -0,0 +1,115 @@
+
+---
+
+Markdown Best Practices
+=======================
+
+Document Structure
+------------------
+- Use a single `# Title` at the top
+- Follow with a brief description
+- Organize content with hierarchical headings (`##`, `###`)
+- Include a TOC for documents longer than 3 sections
+
+Formatting
+----------
+- Keep lines under 120 characters for readability
+- Break long lines at natural points (after periods, commas, or logical breaks)
+- Use **bold** for emphasis, *italics* for terminology
+- Code blocks: Triple backticks with language identifier (REQUIRED - prevents MD040)
+- Inline code: Single backticks for commands, variables
+- Horizontal rules (`---`) only to separate major sections
+
+Lists
+-----
+- Use ordered lists (1. 2. 3.) for sequential steps
+- Use unordered lists (- or *) for non-sequential items
+- Maintain consistent indentation for nested lists
+
+Links and References
+--------------------
+- Use descriptive link text: `[descriptive text](mdc:URL)`
+- Prefer relative links for project files
+- Group related references at document bottom
+
+Images
+------
+- Include alt text: `![alt text](mdc:image-path)`
+- Keep width under 900px for readability
+- Store images in dedicated `/assets` or `/images` folder
+
+Tables
+------
+- Use tables for structured data comparisons
+- Include header row and alignment indicators
+- Keep tables simple; avoid nested tables
+
+Common Lint Errors to Avoid
+---------------------------
+- MD040: Always specify a language for fenced code blocks
+- MD013: Keep line length under 120 characters
+- MD022: Headers must be surrounded by blank lines
+- MD023: Headers must start at beginning of line
+- MD032: Lists should be surrounded by blank lines
+- MD041: First line should be a top-level header
+
+---
+
+Shell Command Context Specification
+-----------------------------------
+
+Precede command blocks requiring a specific starting directory or shell
+environment with a single comment line specifying the required shell(s)
+and starting path.
+
+**Starting Path**
+- Default: Relative paths from `repo-root` (top-level dir, e.g., with `.git`).
+- Use the most specific relevant directory (e.g., `repo-root/src/project`).
+- Allowed: Absolute paths if necessary (e.g., `C:\Tools`).
+- Use `.` for the specified root/absolute directory itself.
+
+**Shell**
+- Default: Generic names (`PS`, `Bash`).
+- Specify versions (`PS7`) or types (`GitBash`, `Cmd`) ONLY if command depends on them.
+
+Assume user is in the specified directory with the appropriate shell.
+
+**Format**
+`# <ShellSpecifier>: <PathSpecifier>`
+- `<ShellSpecifier>`: Target shell(s) (`PS`, `Bash`, `Bash/GitBash`, `PS7`).
+- `<PathSpecifier>`: Starting path (relative or absolute). Use `\` or `/` matching shell/OS.
+
+Commands in the block should use paths relative to the specified starting directory.
+
+**Examples**
+
+**Generic PS Command (from project dir):**
+```powershell
+# PS: repo-root\code\MatureWeb\Northwind.DataContext
+dotnet user-secrets list --project .\Northwind.DataContext.csproj
+```
+
+**Generic Bash Command (from repo root):**
+```bash
+# Bash: repo-root/.
+git submodule update --init
+```
+
+**PowerShell 7 Specific Command:**
+```powershell
+# PS7: repo-root\scripts
+Get-ChildItem .\*.log | ForEach-Object -Parallel { Remove-Item $_.FullName } -ThrottleLimit 4
+```
+
+**GitBash Specific Scenario:**
+```bash
+# GitBash: repo-root/.
+# Assumes a specific credential helper configured only for GitBash
+git push origin main
+```
+
+**Absolute Path Example (Windows):**
+```powershell
+# PS: C:\ProgramData\MyTool
+.\mytool-config.exe --update-settings
+```

.cursor/rules/markdown-guidelines.mdc

@@ -0,0 +1,39 @@
+PowerShell Scripting Guidelines
+===============================
+
+Prefer PowerShell 7 commands for Windows 11, not Bash syntax.
+Prefer PowerShell-native approaches over cmd.exe commands.
+
+Command Syntax
+--------------
+- Use PowerShell cmdlets: `Get-ChildItem` (not `ls`), `Set-Location` (not `cd`)
+- Flags use single hyphen (`-Force`)
+- Command separation: `;` (not `&&`)
+
+Path Handling
+-------------
+- Use backslashes in Windows paths: `C:\Users\`
+- Use `Join-Path` for path construction
+- Always quote paths with spaces
+
+Variables and Environment
+-------------------------
+- Variables: `$variable`, string interpolation: `"$(...)"`
+- Environment variables: `$env:VARIABLE`
+
+Input/Output
+------------
+- Piping: `|` (with proper object handling)
+- Redirection: `>`, `>>`, `2>`
+
+Error Handling
+--------------
+- Check `$LASTEXITCODE` after external commands
+- Use try/catch blocks for risky operations
+- Log errors with `Write-Error` to stderr
+
+Git Bash Integration
+--------------------
+- Use `Invoke-GitBash.ps1` for bash scripts
+- Handle path conversions
+- Propagate exit codes correctly

.cursor/rules/powershell-scripting.mdc

@@ -0,0 +1,6 @@
+Shell Choice Guidelines
+=======================
+
+- Use PowerShell for Windows-specific tasks and system automation
+- Use Git Bash for cross-platform scripts and git operations
+- Prefer PowerShell when working with .NET or Windows services

.cursor/rules/shell-choice.mdc

@@ -0,0 +1,29 @@
+Standards-First Rule
+====================
+
+The Rule
+--------
+
+**Always default to established industry standards and conventions unless they introduce
+unnecessary overhead or complexity for the specific context. Prefer simplicity and
+familiarity over novel approaches unless there's a compelling reason to deviate.**
+
+Application Examples
+--------------------
+
+- Use `.cursor/rules` instead of `cursor-rules/` for Cursor IDE configuration
+- Follow standard naming conventions for files and folders (e.g., `.vscode`, `.git`)
+- Adopt established coding conventions for the primary language/framework
+- Use standard project structures unless project-specific needs dictate otherwise
+- Implement common design patterns rather than inventing alternatives
+
+When to Deviate
+---------------
+
+Deviation from standards is appropriate when:
+
+1. The standard introduces significant unnecessary complexity
+2. Project requirements strongly conflict with the standard approach
+3. Performance or resource constraints necessitate a different solution
+4. The standard is obsolete or being replaced by a newer standard
+5. The team has established a well-documented alternative that provides clear benefits