trim trailing whitespace, ensure files end in newline, add pre-commit hook and CI check

Author: ndbroadbent

.cursor/rules/cursor_rules.mdc

@@ -27,7 +27,7 @@ alwaysApply: true
   ```typescript
   // ✅ DO: Show good examples
   const goodExample = true;
-  
+
   // ❌ DON'T: Show anti-patterns
   const badExample = false;
   ```
@@ -50,4 +50,4 @@ alwaysApply: true
   - Keep descriptions concise
   - Include both DO and DON'T examples
   - Reference actual code over theoretical examples
-  - Use consistent formatting across rules 
+  - Use consistent formatting across rules

.cursor/rules/self_improve.mdc

@@ -38,7 +38,7 @@ alwaysApply: true
     select: { id: true, email: true },
     where: { status: 'ACTIVE' }
   });
-  
+
   // Consider adding to [prisma.mdc](mdc:.cursor/rules/prisma.mdc):
   // - Standard select fields
   // - Common where conditions

.cursor/rules/taskmaster/dev_workflow.mdc

@@ -33,7 +33,7 @@ All your standard command executions should operate on the user's current task c
 For new projects or when users are getting started, operate within the `master` tag context:
 
 -   Start new projects by running `initialize_project` tool / `task-master init` or `parse_prd` / `task-master parse-prd --input='<prd-file.txt>'` (see @`taskmaster.mdc`) to generate initial tasks.json with tagged structure
--   Configure rule sets during initialization with `--rules` flag (e.g., `task-master init --rules cursor,windsurf`) or manage them later with `task-master rules add/remove` commands  
+-   Configure rule sets during initialization with `--rules` flag (e.g., `task-master init --rules cursor,windsurf`) or manage them later with `task-master rules add/remove` commands
 -   Begin coding sessions with `get_tasks` / `task-master list` (see @`taskmaster.mdc`) to see current tasks, status, and IDs
 -   Determine the next task to work on using `next_task` / `task-master next` (see @`taskmaster.mdc`)
 -   Analyze task complexity with `analyze_project_complexity` / `task-master analyze-complexity --research` (see @`taskmaster.mdc`) before breaking down tasks
@@ -136,7 +136,7 @@ Once you transition to tag-based workflows, the `master` tag should ideally cont
 1. **Identify the Initiative**: When user describes a significant feature
 2. **Create Dedicated Tag**: `add_tag feature-[name] --description="[Feature description]"`
 3. **Collaborative PRD Creation**: Work with user to create comprehensive PRD in `.taskmaster/docs/feature-[name]-prd.txt`
-4. **Parse & Prepare**: 
+4. **Parse & Prepare**:
    - `parse_prd .taskmaster/docs/feature-[name]-prd.txt --tag=feature-[name]`
    - `analyze_project_complexity --tag=feature-[name] --research`
    - `expand_all --tag=feature-[name] --research`
@@ -168,7 +168,7 @@ Action: add_tag my-api-work --copy-from-current --description="My API tasks whil
 ```
 User: "I want to add a complete user dashboard with analytics, user management, and reporting"
 Your Response: "This sounds like a major feature that would benefit from detailed planning. Let me create a dedicated context for this work and we can draft a PRD together to ensure we capture all requirements."
-Actions: 
+Actions:
 1. add_tag feature-dashboard --description="User dashboard with analytics and management"
 2. Collaborate on PRD creation
 3. parse_prd dashboard-prd.txt --tag=feature-dashboard
@@ -263,9 +263,9 @@ Taskmaster offers two primary ways to interact:
     - Dependencies are displayed with status indicators (✅ for completed, ⏱️ for pending)
     - This helps quickly identify which prerequisite tasks are blocking work
 - **priority**: Importance level (Example: `"high"`, `"medium"`, `"low"`)
-- **details**: In-depth implementation instructions (Example: `"Use GitHub client ID/secret, handle callback, set session token."`) 
-- **testStrategy**: Verification approach (Example: `"Deploy and call endpoint to confirm 'Hello World' response."`) 
-- **subtasks**: List of smaller, more specific tasks (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`) 
+- **details**: In-depth implementation instructions (Example: `"Use GitHub client ID/secret, handle callback, set session token."`)
+- **testStrategy**: Verification approach (Example: `"Deploy and call endpoint to confirm 'Hello World' response."`)
+- **subtasks**: List of smaller, more specific tasks (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`)
 - Refer to task structure details (previously linked to `tasks.mdc`).
 
 ## Configuration Management (Updated)
@@ -345,7 +345,7 @@ Taskmaster supports multiple AI coding assistant rule sets that can be configure
 - Use `move_task` / `task-master move --from=<id> --to=<id>` to move tasks or subtasks within the hierarchy
 - This command supports several use cases:
   - Moving a standalone task to become a subtask (e.g., `--from=5 --to=7`)
-  - Moving a subtask to become a standalone task (e.g., `--from=5.2 --to=7`) 
+  - Moving a subtask to become a standalone task (e.g., `--from=5.2 --to=7`)
   - Moving a subtask to a different parent (e.g., `--from=5.2 --to=7.3`)
   - Reordering subtasks within the same parent (e.g., `--from=5.2 --to=5.4`)
   - Moving a task to a new, non-existent ID position (e.g., `--from=5 --to=25`)
@@ -421,4 +421,4 @@ Once a task has been broken down into subtasks using `expand_task` or similar me
     - Can help compare functions between files during migrations or identify potential naming conflicts.
 
 ---
-*This workflow provides a general guideline. Adapt it based on your specific project needs and team practices.*
+*This workflow provides a general guideline. Adapt it based on your specific project needs and team practices.*

.cursor/rules/taskmaster/taskmaster.mdc

@@ -8,7 +8,7 @@ alwaysApply: true
 
 This document provides a detailed reference for interacting with Taskmaster, covering both the recommended MCP tools, suitable for integrations like Cursor, and the corresponding `task-master` CLI commands, designed for direct user interaction or fallback.
 
-**Note:** For interacting with Taskmaster programmatically or via integrated tools, using the **MCP tools is strongly recommended** due to better performance, structured data, and error handling. The CLI commands serve as a user-friendly alternative and fallback. 
+**Note:** For interacting with Taskmaster programmatically or via integrated tools, using the **MCP tools is strongly recommended** due to better performance, structured data, and error handling. The CLI commands serve as a user-friendly alternative and fallback.
 
 **Important:** Several MCP tools involve AI processing... The AI-powered tools include `parse_prd`, `analyze_project_complexity`, `update_subtask`, `update_task`, `update`, `expand_all`, `expand_task`, and `add_task`.
 
@@ -38,8 +38,8 @@ This document provides a detailed reference for interacting with Taskmaster, cov
     *   `skipInstall`: `Skip installing dependencies. Default is false.` (CLI: `--skip-install`)
     *   `addAliases`: `Add shell aliases tm and taskmaster. Default is false.` (CLI: `--aliases`)
     *   `yes`: `Skip prompts and use defaults/provided arguments. Default is false.` (CLI: `-y, --yes`)
-*   **Usage:** Run this once at the beginning of a new project, typically via an integrated tool like Cursor. Operates on the current working directory of the MCP server. 
-*   **Important:** Once complete, you *MUST* parse a prd in order to generate tasks. There will be no tasks files until then. The next step after initializing should be to create a PRD using the example PRD in .taskmaster/templates/example_prd.txt. 
+*   **Usage:** Run this once at the beginning of a new project, typically via an integrated tool like Cursor. Operates on the current working directory of the MCP server.
+*   **Important:** Once complete, you *MUST* parse a prd in order to generate tasks. There will be no tasks files until then. The next step after initializing should be to create a PRD using the example PRD in .taskmaster/templates/example_prd.txt.
 *   **Tagging:** Use the `--tag` option to parse the PRD into a specific, non-default tag context. If the tag doesn't exist, it will be created automatically. Example: `task-master parse-prd spec.txt --tag=new-feature`.
 
 ### 2. Parse PRD (`parse_prd`)
@@ -84,7 +84,7 @@ This document provides a detailed reference for interacting with Taskmaster, cov
 *   **Usage (CLI):** Run without flags to view current configuration and available models. Use set flags to update specific roles. Use `--setup` for guided configuration, including custom models. To set a custom model via flags, use `--set-<role>=<model_id>` along with either `--ollama` or `--openrouter`.
 *   **Notes:** Configuration is stored in `.taskmaster/config.json` in the project root. This command/tool modifies that file. Use `listAvailableModels` or `task-master models` to see internally supported models. OpenRouter custom models are validated against their live API. Ollama custom models are not validated live.
 *   **API note:** API keys for selected AI providers (based on their model) need to exist in the mcp.json file to be accessible in MCP context. The API keys must be present in the local .env file for the CLI to be able to read them.
-*   **Model costs:** The costs in supported models are expressed in dollars. An input/output value of 3 is $3.00. A value of 0.8 is $0.80. 
+*   **Model costs:** The costs in supported models are expressed in dollars. An input/output value of 3 is $3.00. A value of 0.8 is $0.80.
 *   **Warning:** DO NOT MANUALLY EDIT THE .taskmaster/config.json FILE. Use the included commands either in the MCP or CLI format as needed. Always prioritize MCP tools when available and use the CLI as a fallback.
 
 ---
@@ -555,4 +555,4 @@ Environment variables are used **only** for sensitive API keys related to AI pro
 
 ---
 
-For details on how these commands fit into the development process, see the [dev_workflow.mdc](mdc:.cursor/rules/taskmaster/dev_workflow.mdc).
+For details on how these commands fit into the development process, see the [dev_workflow.mdc](mdc:.cursor/rules/taskmaster/dev_workflow.mdc).

.env.example

@@ -9,4 +9,4 @@ GROQ_API_KEY="YOUR_GROQ_KEY_HERE"                     # Optional, for Groq model
 OPENROUTER_API_KEY="YOUR_OPENROUTER_KEY_HERE"         # Optional, for OpenRouter models.
 AZURE_OPENAI_API_KEY="your_azure_key_here"            # Optional, for Azure OpenAI models (requires endpoint in .taskmaster/config.json).
 OLLAMA_API_KEY="your_ollama_api_key_here"             # Optional: For remote Ollama servers that require authentication.
-GITHUB_API_KEY="your_github_api_key_here"             # Optional: For GitHub import/export features. Format: ghp_... or github_pat_...
+GITHUB_API_KEY="your_github_api_key_here"             # Optional: For GitHub import/export features. Format: ghp_... or github_pat_...

.github/wait-for-checks.js

@@ -1,6 +1,6 @@
 /**
  * Wait for GitHub Actions checks to complete
- * 
+ *
  * @param {Object} params
  * @param {Object} params.github - GitHub API object
  * @param {Object} params.context - GitHub context
@@ -25,7 +25,7 @@ const POLL_INTERVAL_MS = 10 * 1000; // 10 seconds between polls
 module.exports = async ({ github, context, core, checks }) => {
   // Use provided checks or default to all checks
   const REQUIRED_PREFIXES = checks || DEFAULT_REQUIRED_PREFIXES;
-  
+
   if (checks) {
     core.info(`Waiting for specific checks: ${checks.join(", ")}`);
   } else {

.github/workflows/ci.yml

@@ -40,6 +40,10 @@ jobs:
         if: runner.os != 'Windows'
         run: cargo fmt --all -- --check
 
+      - name: Check whitespace
+        if: runner.os != 'Windows'
+        run: ./scripts/check-whitespace.sh
+
       - name: Run clippy
         if: runner.os != 'Windows'
         run: cargo clippy --all-targets --all-features

.github/workflows/shellcheck.yml

@@ -16,15 +16,15 @@ jobs:
   shellcheck:
     name: ShellCheck
     runs-on: ubuntu-latest
-    
+
     steps:
       - name: Checkout code
         uses: actions/checkout@v4
-      
+
       - name: Install ShellCheck
         run: |
           sudo apt-get update
           sudo apt-get install -y shellcheck
-      
+
       - name: Run ShellCheck
-        run: ./scripts/shellcheck.sh
+        run: ./scripts/shellcheck.sh

.taskmaster/docs/vscode-ext-prd.txt

@@ -165,4 +165,4 @@ A VS Code extension that provides smart case-aware search and replace functional
 - E2E tests with actual CLI
 - UI component tests
 - Performance tests with large codebases
-- Cross-platform testing (Windows, macOS, Linux)
+- Cross-platform testing (Windows, macOS, Linux)

.taskmaster/templates/example_prd.txt

@@ -1,28 +1,28 @@
 <context>
-# Overview  
+# Overview
 [Provide a high-level overview of your product here. Explain what problem it solves, who it's for, and why it's valuable.]
 
-# Core Features  
+# Core Features
 [List and describe the main features of your product. For each feature, include:
 - What it does
 - Why it's important
 - How it works at a high level]
 
-# User Experience  
+# User Experience
 [Describe the user journey and experience. Include:
 - User personas
 - Key user flows
 - UI/UX considerations]
 </context>
 <PRD>
-# Technical Architecture  
+# Technical Architecture
 [Outline the technical implementation details:
 - System components
 - Data models
 - APIs and integrations
 - Infrastructure requirements]
 
-# Development Roadmap  
+# Development Roadmap
 [Break down the development process into phases:
 - MVP requirements
 - Future enhancements
@@ -34,14 +34,14 @@
 - Getting as quickly as possible to something usable/visible front end that works
 - Properly pacing and scoping each feature so it is atomic but can also be built upon and improved as development approaches]
 
-# Risks and Mitigations  
+# Risks and Mitigations
 [Identify potential risks and how they'll be addressed:
 - Technical challenges
 - Figuring out the MVP that we can build upon
 - Resource constraints]
 
-# Appendix  
+# Appendix
 [Include any additional information:
 - Research findings
 - Technical specifications]
-</PRD>
+</PRD>