From fc6a15d5ee32dd48d7d15ab3cec61366777f8d09 Mon Sep 17 00:00:00 2001
From: Ivan Grynenko <ivan.grynenko@gmail.com>
Date: Fri, 24 Oct 2025 21:24:41 +1100
Subject: [PATCH 1/4] feat: Added slash command installation and tests

---
 .cursor/commands/behat-drevops.md        | 378 +++++++++++++++
 .cursor/commands/drupal-lint.md          | 292 +++++++++++
 .cursor/commands/gh-issue-create.md      | 240 +++++++++
 .cursor/commands/gh-issue-resolve.md     |  52 ++
 .cursor/commands/npm-audit-fix.md        | 121 +++++
 .cursor/commands/pr-assess.md            | 594 +++++++++++++++++++++++
 .cursor/commands/pr-draft.md             |  62 +++
 .cursor/commands/pr-resolve.md           | 128 +++++
 .cursor/commands/security-scan.md        | 109 +++++
 .cursor/commands/security-verify.md      | 193 ++++++++
 .cursor/commands/session-summary.md      |  61 +++
 .cursor/commands/speckit.analyze.md      | 180 +++++++
 .cursor/commands/speckit.checklist.md    | 283 +++++++++++
 .cursor/commands/speckit.clarify.md      | 172 +++++++
 .cursor/commands/speckit.constitution.md |  73 +++
 .cursor/commands/speckit.implement.md    | 118 +++++
 .cursor/commands/speckit.plan.md         |  76 +++
 .cursor/commands/speckit.specify.md      | 204 ++++++++
 .cursor/commands/speckit.tasks.md        | 107 ++++
 .tests/file-maps.sh                      | 132 ++++-
 .tests/run-all-tests.sh                  |  37 +-
 .tests/run-tests.sh                      |  35 +-
 .tests/test-javascript-option.sh         |  17 +-
 AGENTS.md                                |   6 +
 CHANGELOG.md                             |  43 ++
 docs/prd.md                              |  74 ---
 docs/specs/command-installer-update.md   |  14 +
 docs/srs.md                              |  86 ----
 install.php                              | 568 +++++++++++++++++++++-
 29 files changed, 4261 insertions(+), 194 deletions(-)
 create mode 100644 .cursor/commands/behat-drevops.md
 create mode 100644 .cursor/commands/drupal-lint.md
 create mode 100644 .cursor/commands/gh-issue-create.md
 create mode 100644 .cursor/commands/gh-issue-resolve.md
 create mode 100644 .cursor/commands/npm-audit-fix.md
 create mode 100644 .cursor/commands/pr-assess.md
 create mode 100644 .cursor/commands/pr-draft.md
 create mode 100644 .cursor/commands/pr-resolve.md
 create mode 100644 .cursor/commands/security-scan.md
 create mode 100644 .cursor/commands/security-verify.md
 create mode 100644 .cursor/commands/session-summary.md
 create mode 100644 .cursor/commands/speckit.analyze.md
 create mode 100644 .cursor/commands/speckit.checklist.md
 create mode 100644 .cursor/commands/speckit.clarify.md
 create mode 100644 .cursor/commands/speckit.constitution.md
 create mode 100644 .cursor/commands/speckit.implement.md
 create mode 100644 .cursor/commands/speckit.plan.md
 create mode 100644 .cursor/commands/speckit.specify.md
 create mode 100644 .cursor/commands/speckit.tasks.md
 create mode 100644 CHANGELOG.md
 delete mode 100644 docs/prd.md
 create mode 100644 docs/specs/command-installer-update.md
 delete mode 100644 docs/srs.md

diff --git a/.cursor/commands/behat-drevops.md b/.cursor/commands/behat-drevops.md
new file mode 100644
index 0000000..2cedac7
--- /dev/null
+++ b/.cursor/commands/behat-drevops.md
@@ -0,0 +1,378 @@
+# Custom Command: Behat DrevOps
+
+## Command Usage
+`/behat-drevops <task>`
+
+Treat `<task>` as the description of the Behat scenario the user wants. The remainder of this guide explains how to fulfil that request.
+
+## Role definition
+
+You are behat test writer, implement the test requested as {$ARGUMENT}
+
+### DrevOps Behat Steps Integration
+For Drupal projects using the `drevops/behat-steps` library, which provides comprehensive Behat step definitions. When available in `vendor/drevops/behat-steps/`, use these pre-built steps.
+
+### Available Behat Traits from DrevOps
+When writing custom Behat tests, check for these available traits:
+
+#### Common Traits
+- `ContentTrait` - Content management steps
+- `FieldTrait` - Field interaction steps
+- `FileTrait` - File handling steps
+- `PathTrait` - Path navigation steps
+- `SearchApiTrait` - Search API testing steps
+- `TaxonomyTrait` - Taxonomy term steps
+- `WaitTrait` - Wait conditions steps
+- `WatchdogTrait` - Watchdog/logging steps
+
+#### Additional Available Traits
+- `BigPipeTrait` - BigPipe functionality testing
+- `BlockContentTrait` - Block content management
+- `BlockTrait` - Block placement and configuration
+- `CookieTrait` - Cookie manipulation
+- `DateTrait` - Date field handling
+- `DraggableViewsTrait` - Draggable views testing
+- `EckTrait` - Entity Construction Kit support
+- `ElementTrait` - DOM element interactions
+- `EmailTrait` - Email testing capabilities
+- `FileDownloadTrait` - File download verification
+- `JsTrait` - JavaScript execution
+- `KeyboardTrait` - Keyboard interaction
+- `LinkTrait` - Link verification
+- `MediaTrait` - Media entity handling
+- `MenuTrait` - Menu system testing
+- `MetaTagTrait` - Meta tag verification
+- `OverrideTrait` - Override functionality
+- `ParagraphsTrait` - Paragraphs field testing
+- `ResponseTrait` - HTTP response assertions
+- `RoleTrait` - User role management
+- `SelectTrait` - Select field interactions
+- `TestmodeTrait` - Test mode utilities
+- `UserTrait` - User management
+- `VisibilityTrait` - Element visibility checks
+- `WysiwygTrait` - WYSIWYG editor testing
+
+### Writing Behat Tests - Best Practices
+
+#### 1. Step Format Guidelines
+```gherkin
+# Use descriptive placeholder names
+Given I am viewing the "About Us" page content
+When I fill in "Title" with "New Page Title"
+Then I should see the text "Successfully created"
+
+# Use "the following" for table data
+When I create nodes with the following details:
+  | title           | type    | status |
+  | About Page      | page    | 1      |
+  | Contact Page    | page    | 1      |
+
+# Use "with" for properties
+Given I am logged in as a user with the "administrator" role
+```
+
+#### User Authentication in Behat Tests
+
+**Important**: When creating users in Behat tests, follow these guidelines:
+
+1. **Always include password field** when creating users:
+   ```gherkin
+   Given users:
+     | name         | mail               | pass     | roles                    |
+     | admin_user   | admin@example.com  | password | administrator            |
+     | editor_user  | editor@example.com | password | content_editor           |
+     | basic_user   | user@example.com   | password |                          |
+   ```
+
+2. **Never manually assign "authenticated" role**:
+   - ❌ Wrong: `| basic_user | user@example.com | password | authenticated |`
+   - ✅ Correct: `| basic_user | user@example.com | password | |`
+   - The "authenticated" role is automatically assigned by Drupal
+
+3. **Common user creation patterns**:
+   ```gherkin
+   # Background section for multiple scenarios
+   Background:
+     Given users:
+       | name                  | mail                       | pass     | roles                         |
+       | site_admin_user       | site_admin@example.com     | password | civictheme_site_administrator |
+       | content_editor_user   | editor@example.com         | password | civictheme_content_author     |
+       | no_role_user          | basic@example.com          | password |                               |
+   
+   # Using the created users
+   Scenario: Admin can access restricted pages
+     Given I am logged in as "site_admin_user"
+     When I go to "/admin/structure"
+     Then I should not see "Access denied"
+   ```
+
+4. **Login methods**:
+   ```gherkin
+   # Login as created user
+   Given I am logged in as "username_from_table"
+   
+   # Login with role
+   Given I am logged in as a user with the "administrator" role
+   
+   # Anonymous user
+   Given I am an anonymous user
+   ```
+
+#### 2. Step Type Conventions
+
+**Given Steps** (Prerequisites):
+```gherkin
+Given I am logged in as a user with the "administrator" role
+Given "page" content exists with the title "Home Page"
+Given I have a "article" content type
+```
+
+**When Steps** (Actions):
+```gherkin
+When I visit "node/add/page"
+When I fill in "Title" with "Test Page"
+When I press "Save"
+When I click "Add content"
+```
+
+**Then Steps** (Assertions):
+```gherkin
+Then I should see the text "Page created"
+Then I should not see "Access denied"
+Then the response status code should be 200
+Then the "Title" field should contain "Test Page"
+```
+
+### Running Behat Tests
+
+```bash
+# Run all Behat tests
+ahoy test-behat
+
+# Run specific feature
+ahoy test-behat tests/behat/features/content.feature
+
+# Run tests with specific tag
+ahoy test-behat --tags=@api
+
+# Run tests excluding a tag
+ahoy test-behat --tags='~@skipped'
+
+# Run with specific profile
+ahoy test-behat -p p0
+```
+
+### Debugging Behat Tests
+
+1. **Add Screenshots**:
+   ```gherkin
+   Then save screenshot
+   # Screenshots saved to .logs/screenshots/
+   ```
+
+2. **Pause Execution**:
+   ```gherkin
+   Then I break
+   # Pauses test execution for debugging
+   ```
+
+3. **Check Element Visibility**:
+   ```gherkin
+   Then I wait for the "#edit-title" element to appear
+   Then I wait 5 seconds for the ".banner" element to appear
+   ```
+
+4. **Debug JavaScript**:
+   ```gherkin
+   Then I execute javascript "console.log(jQuery('.tabs').length)"
+   ```
+
+### Behat Configuration Notes
+
+Common `behat.yml` configuration includes:
+- Screenshot capture on failure
+- JUnit output for CI integration
+- Parallel testing profiles
+- Chrome/Selenium integration for JavaScript tests
+
+### Adding Custom Behat Steps
+
+When you need custom steps not provided by DrevOps Behat Steps:
+
+1. Add to `tests/behat/bootstrap/FeatureContext.php`
+2. Follow existing patterns in the file
+3. Use proper PHPDoc annotations
+4. Include proper error handling
+
+Example:
+```php
+/**
+ * Verifies custom element is displayed.
+ *
+ * @Then I should see the custom element
+ */
+public function iShouldSeeTheCustomElement(): void {
+  $element = $this->getSession()->getPage()->find('css', '.custom-element');
+  if (!$element || !$element->isVisible()) {
+    throw new \Exception('Custom element is not visible');
+  }
+}
+```
+
+### Common Behat Issues and Solutions
+
+#### 1. WYSIWYG/CKEditor Fields
+When testing forms with WYSIWYG editors (like CKEditor):
+
+**Problem**: Standard field filling doesn't work with CKEditor fields
+```gherkin
+# This may fail:
+And I fill in "Body" with "Content text"
+```
+
+**Solution**: Use the WysiwygTrait from DrevOps
+```php
+// In FeatureContext.php, add:
+use DrevOps\BehatSteps\WysiwygTrait;
+
+class FeatureContext extends DrupalContext {
+  use WysiwygTrait;
+  // ... other traits
+}
+```
+
+Then use the WYSIWYG-specific step:
+```gherkin
+And I fill in WYSIWYG "Body" with "This content will be properly filled in CKEditor"
+```
+
+#### 2. Multi-Domain Sites
+For sites with multiple domains (like WorkSafe/Consumer Protection):
+
+**Problem**: Domain selection uses radio buttons, not checkboxes
+```gherkin
+# Wrong:
+And I check "WorkSafe"
+
+# Correct:
+And I select the radio button "WorkSafe"
+```
+
+#### 3. Media Bundle Names
+When creating media entities, use the correct bundle names:
+
+**Problem**: Generic bundle names may not exist
+```gherkin
+# This may fail:
+Given media:
+  | name            | bundle   |
+  | test-doc.pdf    | document |
+```
+
+**Solution**: Use the actual bundle name from your site
+```gherkin
+Given media:
+  | name            | bundle              |
+  | test-doc.pdf    | civictheme_document |
+```
+
+#### 4. File System Configuration
+For sites with private file system:
+
+**Problem**: Creating files with public:// when system uses private://
+```gherkin
+# May fail if system is configured for private files:
+Given files:
+  | uri                    |
+  | public://test-doc.pdf  |
+```
+
+**Solution**: Use private:// URI scheme
+```gherkin
+Given files:
+  | uri                     |
+  | private://test-doc.pdf  |
+```
+
+#### 5. Testing Without Form Submission
+When form submission fails, break down the test:
+
+```gherkin
+# Instead of one large scenario, split into:
+Scenario: Verify form fields exist
+  Then I should see the field "Title"
+  And I should see the field "Body"
+
+Scenario: Test form submission
+  When I fill in "Title" with "Test"
+  And I fill in WYSIWYG "Body" with "Content"
+  And I press "Save"
+  Then I should see "has been created"
+```
+
+#### 6. Conditional Steps for Flexible Tests
+Add conditional steps in FeatureContext.php for more resilient tests:
+
+```php
+/**
+ * Click on the first matching element if it exists.
+ *
+ * @When I click on the first :selector element if it exists
+ */
+public function iClickOnTheFirstElementIfItExists($selector): void {
+  $elements = $this->getSession()->getPage()->findAll('css', $selector);
+  
+  // If no elements exist, that's okay - just skip
+  if (empty($elements)) {
+    return;
+  }
+  
+  // Click the first element
+  $elements[0]->click();
+}
+```
+
+Use in tests:
+```gherkin
+# Won't fail if no publications exist yet
+When I click on the first ".ct-list__content a" element if it exists
+```
+
+#### 7. URL Patterns and Path Aliases
+Be aware that Drupal may use path aliases:
+
+```gherkin
+# Instead of assuming /node/123 format:
+And the url should match "\/node\/\d+"
+
+# Check for the actual alias pattern:
+And the url should match "\/publications\/[\w-]+"
+```
+
+#### 8. Status Code Checks with JavaScript Drivers
+Status code assertions don't work with Selenium/JavaScript drivers:
+
+```gherkin
+# This will fail with Selenium:
+Then the response status code should be 200
+
+# Use content-based verification instead:
+Then I should see "Expected page content"
+And I should not see "Access denied"
+```
+
+#### 9. Running Specific Scenarios
+To run a single scenario during development:
+```bash
+# Run scenario starting at line 33
+docker compose exec cli vendor/bin/behat tests/behat/features/file.feature:33
+```
+
+#### 10. Debugging Failed Tests
+Always check screenshots when tests fail:
+```bash
+# Check latest screenshots
+ls -la .logs/screenshots/ | tail -5
+
+# Use Playwright to view screenshots
+mcp__playwright__browser_navigate with file:// URL
diff --git a/.cursor/commands/drupal-lint.md b/.cursor/commands/drupal-lint.md
new file mode 100644
index 0000000..919ab7c
--- /dev/null
+++ b/.cursor/commands/drupal-lint.md
@@ -0,0 +1,292 @@
+# Custom Command: Drupal Lint
+
+## Command Usage
+`/drupal-lint [scope]`
+
+Use the optional `scope` argument to narrow linting (e.g., `php`, `js`, `all`). Omit it to run the full linting workflow. The sections below describe the available tools and when to use them.
+
+# Linting Commands for Drupal Projects
+
+This document provides comprehensive linting instructions for the Drupal project based on Vortex (DrevOps) configuration. When you refactoring existing code (as opposed to making minor adjustments), think harder.
+
+## Quick Reference
+
+### Model use
+Use `chatgpt-5-high` model for all tasks
+
+### Run All Linting
+```bash
+# Run all backend and frontend linting
+ahoy lint
+
+# Run only backend linting
+ahoy lint-be
+
+# Run only frontend linting
+ahoy lint-fe
+
+# Auto-fix linting issues (where possible)
+ahoy lint-fix
+```
+
+## Backend Linting Tools
+
+### 1. PHP CodeSniffer (PHPCS)
+
+**Purpose**: Checks PHP code against Drupal coding standards.
+
+```bash
+# Run PHPCS on entire codebase
+ahoy cli vendor/bin/phpcs
+
+# Run on specific file or directory
+ahoy cli vendor/bin/phpcs web/modules/custom/module_name
+
+# Show specific sniffs being used
+ahoy cli vendor/bin/phpcs -s
+
+# Generate a report
+ahoy cli vendor/bin/phpcs --report=summary
+
+# Check specific standard violations
+ahoy cli vendor/bin/phpcs --sniffs=Drupal.Commenting.FunctionComment
+```
+
+**Configuration**: `phpcs.xml`
+- Standards: Drupal, DrupalPractice
+- PHP Version: 8.3
+- Checks custom modules, themes, and tests
+
+### 2. PHP Code Beautifier and Fixer (PHPCBF)
+
+**Purpose**: Automatically fixes PHPCS violations where possible.
+
+```bash
+# Auto-fix all fixable issues
+ahoy cli vendor/bin/phpcbf
+
+# Fix specific file or directory
+ahoy cli vendor/bin/phpcbf web/modules/custom/module_name
+
+# See what would be fixed without making changes
+ahoy cli vendor/bin/phpcbf --dry-run
+```
+
+### 3. PHPStan
+
+**Purpose**: Static analysis tool that finds bugs without running code.
+
+```bash
+# Run PHPStan analysis (Level 7)
+ahoy cli vendor/bin/phpstan
+
+# Run with memory limit
+ahoy cli vendor/bin/phpstan --memory-limit=2G
+
+# Analyze specific paths
+ahoy cli vendor/bin/phpstan analyse web/modules/custom/module_name
+
+# Clear cache and re-analyze
+ahoy cli vendor/bin/phpstan clear-result-cache
+ahoy cli vendor/bin/phpstan
+```
+
+**Configuration**: `phpstan.neon`
+- Level: 7 (strict)
+- Includes phpstan-drupal extension
+
+### 4. PHP Mess Detector (PHPMD)
+
+**Purpose**: Detects code smells and possible bugs.
+
+```bash
+# Run PHPMD
+ahoy cli vendor/bin/phpmd . text phpmd.xml
+
+# Check specific directory
+ahoy cli vendor/bin/phpmd web/modules/custom/module_name text phpmd.xml
+
+# Generate HTML report
+ahoy cli vendor/bin/phpmd . html phpmd.xml > phpmd-report.html
+
+# Check specific rules
+ahoy cli vendor/bin/phpmd . text codesize,unusedcode
+```
+
+**Configuration**: `phpmd.xml`
+- Rules: unusedcode, codesize, cleancode
+
+### 5. Rector
+
+**Purpose**: Automated refactoring and code upgrades.
+
+```bash
+# Dry run (preview changes)
+docker compose exec -T cli bash -c "XDEBUG_MODE=off vendor/bin/rector --debug --ansi --memory-limit=2G --no-progress-bar --clear-cache --dry-run"
+
+# Apply changes
+docker compose exec -T cli bash -c "XDEBUG_MODE=off vendor/bin/rector --debug --ansi --memory-limit=2G --no-progress-bar --clear-cache"
+
+# Process specific directory
+docker compose exec -T cli bash -c "XDEBUG_MODE=off vendor/bin/rector process web/modules/custom/module_name --dry-run"
+```
+
+**Configuration**: `rector.php`
+- Includes Drupal 8/9/10 upgrade rules
+- Code quality improvements
+
+## Frontend Linting Tools
+
+### 6. Twig CS (Twig Coding Standards)
+
+**Purpose**: Checks Twig template files for coding standards.
+
+```bash
+# Run Twig CS
+ahoy cli vendor/bin/twigcs
+
+# Check specific directory
+ahoy cli vendor/bin/twigcs web/themes/custom/theme_name
+```
+
+### 7. Theme-specific Linting
+
+**Purpose**: ESLint and Stylelint for JavaScript and CSS.
+
+```bash
+# Run theme linting (configured in package.json)
+ahoy lint-fe
+
+# Or manually for specific theme
+ahoy cli "npm run --prefix web/themes/custom/demirs_ws lint"
+ahoy cli "npm run --prefix web/themes/custom/demirs_cp lint"
+```
+
+## Common Linting Scenarios
+
+### Before Committing Code
+```bash
+# Run all linters
+ahoy lint
+
+# If issues found, try auto-fix
+ahoy lint-fix
+
+# Re-run to check remaining issues
+ahoy lint
+```
+
+### Module Development
+```bash
+# Check specific module
+MODULE="demirs_file_cleanup"
+ahoy cli vendor/bin/phpcs web/modules/custom/$MODULE
+ahoy cli vendor/bin/phpstan analyse web/modules/custom/$MODULE
+ahoy cli vendor/bin/phpmd web/modules/custom/$MODULE text phpmd.xml
+```
+
+### Fix Common Issues
+
+#### Fix PHP Strict Types
+```bash
+# PHPCS requires strict types declaration
+ahoy cli vendor/bin/phpcbf --standard=Generic --sniffs=Generic.PHP.RequireStrictTypes web/modules/custom/module_name
+```
+
+#### Fix Drupal Coding Standards
+```bash
+# Auto-fix Drupal standards
+ahoy cli vendor/bin/phpcbf --standard=Drupal web/modules/custom/module_name
+```
+
+## Memory Considerations
+
+For large codebases or memory-intensive operations:
+
+```bash
+# Increase memory for PHPStan
+ahoy cli vendor/bin/phpstan --memory-limit=4G
+
+# Run Rector with more memory
+docker compose exec -T cli bash -c "XDEBUG_MODE=off vendor/bin/rector --memory-limit=4G --dry-run"
+
+# Or set PHP memory limit for session
+docker compose exec cli php -d memory_limit=-1 vendor/bin/phpcs
+```
+
+## Continuous Integration
+
+These commands are typically run in CI/CD pipelines:
+
+```bash
+# CI-friendly output
+ahoy cli vendor/bin/phpcs --report=junit
+ahoy cli vendor/bin/phpstan --error-format=junit
+```
+
+## Troubleshooting
+
+### Clear Caches
+```bash
+# Clear Drupal cache (may affect some tools)
+ahoy drush cr
+
+# Clear PHPStan cache
+ahoy cli vendor/bin/phpstan clear-result-cache
+
+# Clear Rector cache
+rm -rf /tmp/rector_cached_files
+```
+
+### Debug Mode
+```bash
+# Verbose PHPCS
+ahoy cli vendor/bin/phpcs -vvv
+
+# Debug Rector
+docker compose exec -T cli bash -c "vendor/bin/rector --debug --dry-run"
+```
+
+### Exclude Patterns
+
+To temporarily exclude files/directories, modify the respective config files:
+- PHPCS: Add to `<exclude-pattern>` in `phpcs.xml`
+- PHPStan: Add to `excludePaths` in `phpstan.neon`
+- PHPMD: Add to `<exclude>` in `phpmd.xml`
+
+## Best Practices
+
+1. **Run linting before commits**: Use git hooks or manually run `ahoy lint`
+2. **Fix issues incrementally**: Start with auto-fixable issues using `ahoy lint-fix`
+3. **Module-specific linting**: When developing a module, lint it specifically to get faster feedback
+4. **Use appropriate memory limits**: For large codebases, increase memory limits as needed
+5. **Keep tools updated**: Regularly update linting tools via Composer
+
+## Common Errors and Solutions
+
+### PHPDoc Parameter Name Mismatch
+```
+ParamNameNoMatch: Doc comment for parameter $some_service does not match actual variable name $someService
+```
+**Solution**: Ensure PHPDoc parameter names exactly match the actual parameter names in the function signature.
+
+### Missing Strict Types Declaration
+```
+MissingDeclareStrictTypes: Missing declare(strict_types=1) statement
+```
+**Solution**: Add `declare(strict_types=1);` after the opening PHP tag in each file.
+
+### TranslatableMarkup Type Errors
+When entity labels return TranslatableMarkup objects instead of strings:
+```php
+// Convert to string
+$label = (string) $entity->label();
+```
+
+## References
+
+- [Vortex PHPCS Documentation](https://vortex.drevops.com/tools/phpcs)
+- [Vortex PHPMD Documentation](https://vortex.drevops.com/tools/phpmd)
+- [Vortex PHPStan Documentation](https://vortex.drevops.com/tools/phpstan)
+- [Vortex Rector Documentation](https://vortex.drevops.com/tools/rector)
+- [Drupal Coding Standards](https://www.drupal.org/docs/develop/standards)
diff --git a/.cursor/commands/gh-issue-create.md b/.cursor/commands/gh-issue-create.md
new file mode 100644
index 0000000..a47d840
--- /dev/null
+++ b/.cursor/commands/gh-issue-create.md
@@ -0,0 +1,240 @@
+# Custom Command: GitHub Issue Create
+
+## Command Usage
+`/gh-issue-create <description>`
+
+Everything after `/gh-issue-create` is treated as a single argument containing the user's description of what they want to achieve.
+
+## Instructions
+
+You are implementing a command that intelligently creates GitHub issues based on user descriptions. This task must avoid any code changes.
+
+ Think harder and follow these steps thoroughly:
+
+### 1. Parse and Understand Context
+- **Extract Requirements**: Identify core functionality from the original request, accept the full text after the command as the user's description, analyse the current working directory to understand the project context; Identify the Git repository and its remote origin.
+- **Define Test Cases**: Create specific, measurable test scenarios
+- **Specify Expected Outcomes**: Clear success and failure criteria
+- **Structure for Implementation**: Organize prompt for red-green-refactor cycle
+- **Include Edge Cases**: Don't forget boundary conditions and error scenarios
+
+### 2. Codebase Analysis
+- Explore the relevant parts of the codebase mentioned in the description
+- Look for:
+  - Related existing code
+  - Configuration files
+  - Documentation (README, docs/, wiki references)
+  - Similar patterns or implementations
+  - Dependencies that might be affected
+
+### 3. Issue Classification
+Determine the issue type based on the description:
+- **Bug**: Something is broken or not working as expected
+- **Feature**: New functionality that doesn't exist
+- **Enhancement**: Improvement to existing functionality
+- **Task**: Technical work, refactoring, or maintenance
+
+### 4. TDD Prompt Structure
+
+#### 1. Objective Statement
+Clear, concise description of what needs to be built
+
+#### 2. Test Specifications
+```
+GIVEN: [Initial state/context]
+WHEN: [Action performed]
+THEN: [Expected outcome]
+```
+
+### 5. Break Down Into Tasks
+Decompose the description into specific, actionable tasks:
+- Each task should be atomic and testable
+- Think to consider technical dependencies
+- Include both implementation and testing tasks
+- Think about documentation updates needed
+
+### 6. Define Acceptance Criteria
+For each major component, think hard to establish clear acceptance criteria:
+- What specific behaviour should be implemented?
+- What are the success conditions? Define specific, measurable outcomes.
+- What edge cases need handling?
+- What are the error handling expectations?
+- What tests would validate the implementation?
+- What are performance requirements?
+
+#### 6.1 Test Cases Format
+```markdown
+Test Case 1: [Descriptive name]
+- Input: [Specific input data]
+- Expected Output: [Exact expected result]
+- Validation: [How to verify success]
+
+Test Case 2: [Edge case name]
+- Input: [Boundary/error condition]
+- Expected Output: [Error handling result]
+- Validation: [Error verification method]
+```
+
+#### 6.2 Conversion Examples
+
+##### Original Request:
+"Add user login functionality"
+
+##### TDD Conversion:
+```markdown
+## Objective
+Implement secure user login with email/password authentication
+
+## Test Specifications
+
+### Test 1: Successful Login
+GIVEN: Valid user credentials exist in database
+WHEN: User submits correct email and password
+THEN: User receives auth token and is redirected to dashboard
+
+### Test 2: Invalid Password
+GIVEN: Valid email but incorrect password
+WHEN: User submits login form
+THEN: Return error "Invalid credentials" without revealing which field is wrong
+
+### Test 3: Non-existent User
+GIVEN: Email not in database
+WHEN: User attempts login
+THEN: Return same "Invalid credentials" error (prevent user enumeration)
+
+### Test 4: Rate Limiting
+GIVEN: User has failed 5 login attempts
+WHEN: User attempts 6th login within 15 minutes
+THEN: Block attempt and show "Too many attempts" error
+
+## Success Criteria
+- All tests pass
+- Password is hashed using bcrypt
+- Auth tokens expire after 24 hours
+- Login attempts are logged
+- Response time < 200ms
+```
+
+#### 6.3 Output Format
+
+Generate TDD prompt as:
+
+```markdown
+## TDD Prompt: [Feature Name]
+
+### Objective
+[Clear description of the feature to implement]
+
+### Test Suite
+
+#### Happy Path Tests
+[List of successful scenario tests]
+
+#### Error Handling Tests
+[List of failure scenario tests]
+
+#### Edge Case Tests
+[List of boundary condition tests]
+
+### Implementation Requirements
+- [ ] All tests must pass
+- [ ] Code coverage > 80%
+- [ ] Performance criteria met
+- [ ] Security requirements satisfied
+
+### Test-First Development Steps
+1. Write failing test for [first requirement]
+2. Implement minimal code to pass
+3. Refactor while keeping tests green
+4. Repeat for next requirement
+
+### Example Test Implementation
+```language
+// Example test code structure
+```
+```
+
+#### Remember to:
+- Focus on behavior, not implementation details
+- Make tests specific and measurable
+- Include both positive and negative test cases
+- Structure for iterative TDD workflow
+
+### 7. Generate Issue Content
+Structure the issue with:
+- **Title**: Concise, descriptive summary
+- **Type**: Bug/Feature/Enhancement/Task label
+- **Description**: Clear explanation of the need
+- **Tasks**: Bulleted list of implementation steps
+- **Acceptance Criteria**: Testable success conditions
+- **Testing scenarios**: Numbered list of testing scenarios in the requested format
+- **Technical Notes**: Any implementation considerations
+- **Related Files**: Key files that will be affected
+
+### 8. Present for Confirmation
+Before creating the issue, present the formatted content to the user:
+```
+=== GitHub Issue Preview ===
+Repository: [detected repo]
+Title: [generated title]
+Type: [classification]
+
+Description:
+[formatted description]
+
+Tasks:
+- [ ] Task 1
+- [ ] Task 2
+...
+
+Acceptance Criteria:
+- [ ] Criteria 1
+- [ ] Criteria 2
+...
+
+Technical Notes:
+[any relevant notes]
+
+Related Files:
+- file1.js
+- file2.php
+...
+===========================
+
+Would you like to create this issue? (yes/no)
+```
+
+### 9. Create the Issue
+If confirmed:
+- Detect the Git remote origin URL
+- Extract the GitHub repository owner and name
+- Use the GitHub API to create the issue
+- Return the created issue URL
+
+## Example Behaviour
+
+User input: `/gh-issue-create Add user authentication with email verification and password reset functionality`
+
+Your process:
+1. Scan for existing auth implementation
+2. Check for auth-related dependencies
+3. Classify as "Feature"
+4. Break down into: database schema, registration endpoint, email service, verification flow, password reset flow, tests
+5. Define criteria for each component
+6. Identify test cases
+7. Present formatted issue for review
+8. Create upon confirmation using github mcp or github cli
+
+## Error Handling
+- If no Git repository found: Inform user and exit
+- If no remote origin: Ask user to specify repository
+- If GitHub API fails: Provide issue content for manual creation
+- If description too vague: Ask clarifying questions
+
+## Important Notes
+- Always think step-by-step through the entire process
+- Be thorough in codebase exploration
+- Make reasonable assumptions but note them
+- Focus on creating actionable, well-structured issues
+- Consider the project's conventions and patterns
+```
diff --git a/.cursor/commands/gh-issue-resolve.md b/.cursor/commands/gh-issue-resolve.md
new file mode 100644
index 0000000..e22cc19
--- /dev/null
+++ b/.cursor/commands/gh-issue-resolve.md
@@ -0,0 +1,52 @@
+# Custom Command: GitHub Issue Resolve
+
+## Command Usage
+`/gh-issue-resolve <issue-url> [context]`
+
+Treat the first argument as the GitHub issue URL (or number). Everything after that is optional analyst context to guide the resolution. If the URL is missing, pause and ask the user to provide it before continuing.
+
+Please analyse and fix the GitHub issue referenced in the user input. The problem description provided after `/gh-issue-resolve` becomes your working context. If you cannot access the issue or the instructions are incomplete, stop and request clarification from the user before proceeding.
+
+Follow these steps:
+
+## 1. PLAN
+1. Use 'gh issue view' to get the issue details  
+2. Think and understand the problem described in the issue  
+3. Ask clarifying questions if necessary  
+4. Understand the prior art for this issue
+   - Search the codebase for relevant files
+5. Think harder about how to break the issue down into a series of small, manageable tasks.  
+6. Prepare your plan  
+   - include the issue name  
+   - include a link to the issue.
+
+## 2. WRITE TEST
+- Create a new Git branch for the issue.
+- Identify the testing framework within the project.
+- Begin by writing tests in the identified framework that will satisfy the ticket acceptance criteria and overall task.
+- Write behat and (or) Unit and (or) Postman tests to describe the expected behavior of your code. Tests will fail which is okay.
+- Aim at minimum 80% of test coverage
+
+
+## 3. WRITE CODE
+- Think and solve the issue in small, manageable steps, according to your plan.
+- Commit your changes after each step.
+- When coding FrontEnd, use Playwright MCP to validate your work.
+- Document your changes in project documentation (README.md and /docs/ folder)
+- Update CHANGELOG.md file with listing the changes you're making, keep this file up to date and always validate to remove information that does not apply any longer.
+- Check for the linting tools available in the project's CLAUDE.md file.
+- Use either playwright via MCP, or Unit, or behat to test the changes if you have made changes to the UI. If you are in a Drupal project, login via playwright browser, first execute `ahoy login` command and grab the one-time login URL as Drupal user #1. Then visit that URL to instantly login.
+- Run the full test suite to ensure you haven't broken anything
+- If the tests are failing, fix them, or the functionality.
+- Ensure that all tests are passing before moving on to the next step
+- If testing automation is present as a GitHub Actions workflow, test it locally using local Docker. Example: `act --container-architecture linux/amd64 -j test --verbose`
+
+## 4. LINT
+- Execute code linting, using tools specific to the project and resolve any errors and warnings.
+
+## 5. DEPLOY
+- Open a PR and request a review.
+- Create a cross-reference links between the PR and GH issue.
+- Validate PR for passing Github Actions workflow tests, resolve any test failures in GHA.
+
+Remember to use the GitHub CLI (`gh`) for all GitHub-related tasks.
diff --git a/.cursor/commands/npm-audit-fix.md b/.cursor/commands/npm-audit-fix.md
new file mode 100644
index 0000000..ba06b2f
--- /dev/null
+++ b/.cursor/commands/npm-audit-fix.md
@@ -0,0 +1,121 @@
+# Custom Command: NPM Audit Fix
+
+## Command Usage
+`/npm-audit-fix [path]`
+
+Provide an optional project `path` (defaults to the repository root). The instructions below describe how to audit and remediate NPM vulnerabilities in the target project.
+
+You will help audit and remediate NPM vulnerabilities in a Drupal theme project. The project uses NPM packages to build front-end assets like CSS and JavaScript, and may use NPM, Yarn, or other package managers.
+
+Here is the project path you'll be working with:
+
+<project_path>
+the project root path
+</project_path>
+
+Your goal is to investigate the project setup, fix security vulnerabilities, ensure assets build properly in both host and Docker environments, and update documentation to guide developers on front-end asset rendering.
+
+Before executing the remediation steps, wrap your analysis in <project_analysis> tags to systematically document your findings. It's OK for this section to be quite long. Include:
+
+- **File Structure**: List the key files found in the project (package.json, lock files, Docker files, .nvmrc, etc.)
+- **Package Manager Detection**: Identify which package manager is being used and document the evidence
+- **Build Environment**: Determine if builds happen on host vs Docker and identify the build commands
+- **Node Version**: Check for .nvmrc or other version specifications
+- **Git Baseline**: Record the current git status to establish a baseline
+- **Vulnerability Assessment**: Run and document the results of npm/yarn audit, listing each vulnerability with its severity
+- **Remediation Strategy**: Plan your approach for fixing vulnerabilities while minimizing breaking changes
+
+Before proceeding, make sure the PHP runtime has access to the same project files as the CLI container. The PHP image in this stack does not mount the module code by default, so you must manually sync the files before attempting any audits or Drupal commands:
+
+**Mandatory Container Sync (must be performed manually by the assistant)**
+- Identify the running PHP pod/container for the target environment. For Lagoon-based stacks use `kubectl get pods -l lagoon.sh/project=the project name,lagoon.sh/service=php` (or the equivalent `kubectl get pod` command provided by the platform). For local Docker Compose environments use `docker compose ps php` to confirm the container name.
+- Determine the CLI container name (typically `the project name` locally or the Lagoon CLI pod). This container has the authoritative Drupal codebase.
+- Copy the missing module directories from the CLI container to the PHP container so PHP can load them. Example (Docker): `docker cp $(docker compose ps -q cli):/app/web/modules/. $(docker compose ps -q php):/app/web/modules/` and repeat for any other required paths (e.g. `/app/vendor`, `/app/web/profiles`). Example (Lagoon/Kubernetes): `kubectl cp <cli-pod>:/app/web/modules <php-pod>:/app/web/modules -c php`.
+- Verify inside the PHP container that the expected module (e.g. `upgrade_status`) now exists under `/app/web/modules/contrib`. Do not restart or recreate containers; only manual copying is permitted.
+
+Then follow these systematic steps:
+
+**Step 1: Initial Project Investigation**
+- Navigate to the project path and examine the file structure
+- Look for package.json, yarn.lock, package-lock.json to determine which package manager is in use
+- Check for Dockerfile or docker-compose.yml files that contain asset building instructions
+- Examine .nvmrc file for Node version requirements; if missing, create one with a reasonable LTS version
+
+**Step 2: Environment Detection**
+- Determine whether asset building happens on the host machine (typically macOS) or in Docker
+- If Docker is used, identify the specific commands used for asset building
+- Note any build scripts defined in package.json
+
+**Step 3: Git Status Baseline**
+- Run `git status` and document the current state
+- This baseline will help identify if any distributed assets are incorrectly committed
+
+**Step 4: NPM Security Audit**
+- Run `npm audit` (or `yarn audit` if Yarn is detected) to identify vulnerabilities
+- Document all vulnerabilities found, including their severity levels and affected packages
+
+**Step 5: Vulnerability Remediation**
+- Start with `npm audit fix` or the equivalent command for your detected package manager
+- For vulnerabilities that can't be auto-fixed, research each one individually:
+  - Check if newer versions of packages resolve the issues
+  - Look for alternative packages if necessary
+  - Prioritize fixes that don't break compatibility
+- Update packages incrementally, testing after each major change
+
+**Step 6: Asset Building and Testing**
+- Build assets using the identified build process
+- Test building on the host machine first
+- If Docker is used, test building in the Docker environment as well
+- Ensure all assets compile without errors
+
+**Step 7: Git Status Validation**
+- Run `git status` again after building assets
+- Compare with the baseline from Step 3
+- If any files in distribution/build folders were removed:
+  - Move these files to a separate backup folder
+  - Update build scripts to copy these files back to their proper location
+  - Document this process for future reference
+
+**Step 8: Documentation Review and Updates**
+- Review the README file inside the theme directory
+- Update the project-level README file to include clear instructions for front-end asset rendering
+- Ensure the README provides step-by-step guidance for developers on how to execute front-end asset compilation
+
+**Step 9: Ahoy Command Verification**
+- Verify that the `ahoy fe` command exists and successfully compiles assets
+- Verify that the `ahoy fei` command exists and successfully installs dependencies
+- Ensure these commands work when executed from the root level
+- Confirm that the commands pass the necessary arguments to NPM, Yarn, or whatever compiler is being used
+- If these commands don't exist or don't work properly, create or fix them
+
+**Step 10: Cross-Environment Validation**
+- Test the complete build process in both host and Docker environments
+- Verify that all assets are generated correctly in both contexts
+- Confirm that any manually managed assets are properly handled
+
+**Important Guidelines:**
+- Minimize changes to avoid breaking existing functionality
+- Test thoroughly after each significant change
+- Preserve any assets that were manually placed in distribution folders
+- Ensure Node version consistency across environments
+- Document any workarounds or special handling required
+
+Provide your analysis and remediation work in the following format:
+
+<remediation_report>
+**Vulnerability Summary:** [List vulnerabilities found and how they were addressed]
+
+**Package Changes:** [Detail any package replacements or major updates made]
+
+**Build Environment Setup:** [Describe whether builds happen on host vs Docker, and any special configuration]
+
+**Asset Handling:** [Explain any special handling required for manually managed assets]
+
+**Ahoy Command Status:** [Confirm that 'ahoy fe' and 'ahoy fei' commands exist and work properly]
+
+**Documentation Updates:** [Summarize changes made to theme and project README files]
+
+**Cross-Environment Testing:** [Confirm that builds work in both host and Docker environments]
+
+**Future Recommendations:** [Provide recommendations for preventing similar issues]
+</remediation_report>
diff --git a/.cursor/commands/pr-assess.md b/.cursor/commands/pr-assess.md
new file mode 100644
index 0000000..44fc3ea
--- /dev/null
+++ b/.cursor/commands/pr-assess.md
@@ -0,0 +1,594 @@
+# Custom Command: PR Assess
+
+## Command Usage
+`/pr-assess <pr-url-or-number> [context]`
+
+Require the first argument to be the PR URL or number. Any extra text becomes review context. If the URL/number is missing, ask the user for it before continuing.
+
+Review pull request and ticket using: Use the user-provided arguments (if any) as contextual input
+If the Use the user-provided arguments (if any) as contextual input is missing, stop and ask user to provide information, such as pull request URL or number along with any instructions. This input becomes Use the user-provided arguments (if any) as contextual input.
+
+# Code Review Agent Instructions
+
+You are a senior technical lead and architect conducting automated code reviews for GitHub or GitLab pull requests across multiple technology stacks (Drupal, Vue.js, React, etc.). Your role is to evaluate code changes against ticket requirements and coding standards, manage GitHub labels for workflow automation, and update Freshdesk tickets with review findings.
+
+## Primary Objectives
+
+1. **Requirement Fulfilment Analysis (50%)**: Verify code changes satisfy ticket requirements
+2. **Code Standards Compliance (30%)**: Ensure adherence to technology-specific coding standards and best practices, including defensive coding, logging and reporting, errors capturing.
+3. **Security Assessment (20%)**: Validate OWASP security standards and framework-specific security practices
+4. **Label Management**: Apply appropriate GitHub labels for workflow automation
+5. **Freshdesk Integration**: Update tickets with structured review findings and log time entry
+6. **Line-Specific Feedback**: Add comments directly on problematic code lines
+
+## Input Data Analysis
+
+- Pull GitHub PR URL from Use the user-provided arguments (if any) as contextual input.
+- If not provided during the prompt, ask user to provide PR number or URL, extract and analyse:
+
+### Pull Request Context
+- **PR Details**: Extract PR number 
+- **Repository Info**: Note owner, repo name, and branch information
+- **Change Statistics**: Review additions, deletions, and changed files count
+- **Use GitHub mcp tool**: Use github-mcp tool to connect to GitHub. If fails, Use gh cli.
+
+### Ticket Context
+- **Requirements**: Parse ticket description and conversations to understand functional requirements
+- **Acceptance Criteria**: Identify specific acceptance criteria from ticket conversations
+- **Client Feedback**: Review conversation history for clarification and changes
+- **Technical Context**: Note technology stack, modules affected, and dependencies
+- **Extract ticket information**: Check PR description and title to pull ticket number. 
+	In most cases it will be a Freshdesk ticket. Use freshdesk-mcp task get ticket information,
+	conversations and ticket summary to understand context of the issue. In some cases you will be passed a JIRA URL, Use atlassian-mcp to connect and get ticket details in this case.
+
+### Site summary context
+- **Use atlassian-mcp tool**: to access confluence and find the Site Summary in the SUPPORT space.
+    The Site Summary would include production domain in page title. The Site Summary may have important
+    details with project customisations. Keep this page up to date when you identify inconsistencies,
+    or information is missing, based on your PR review outcome.
+
+### Code Changes
+- **Files Modified**: Analyse changed files and their purposes
+- **Code Patterns**: Review implementation approach and architecture
+- **Security Implications**: Assess security impact of changes
+- **Reliability and errors-prune**: Validate defensive coding practices are followed
+- **Errors reporting**: Validate code has suffisient errors logging and reporting
+- **Important**: Note that this PR review tool is for ALL repositories (Drupal backend AND Vue.js/React frontends)
+
+## Review Process
+
+### 1. Requirement Analysis (Pass Score: 80%)
+Compare code changes against:
+- Original ticket requirements
+- Acceptance criteria from conversations
+- Client-requested modifications
+- Expected functionality
+
+**Scoring Criteria:**
+- 90-100%: All requirements fully implemented with proper edge case handling
+- 80-89%: Core requirements met with minor gaps
+- 70-79%: Most requirements met but missing key functionality
+- Below 70%: Significant requirements gaps
+
+### 2. Code Standards Review (Context-Aware Scoring)
+
+**IMPORTANT**: Adjust review criteria based on repository type:
+- For Drupal repositories: Apply Drupal-specific standards below
+- For Vue.js/React frontends: Apply frontend-specific standards (ES6+, component architecture, state management)
+- For other technologies: Apply language-specific best practices
+
+#### Critical/Required Criteria:
+**Security Assessment:**
+- SQL Injection Prevention: Parameterized queries, no direct SQL concatenation
+- XSS Protection: Proper output sanitization (Html::escape(), #plain_text)
+- CSRF Protection: Form API usage, custom forms have CSRF tokens
+- Access Control: Proper permission checks, entity access API usage
+- File Upload Security: Extension validation, MIME type checks
+- Input Validation: Server-side validation for all user inputs
+- Sensitive Data: No hardcoded credentials, API keys, or secrets
+
+**Drupal API Compliance:**
+- Entity API: Using Entity API instead of direct database queries
+- Form API: Proper form construction and validation
+- Render API: Using render arrays, not direct HTML
+- Database API: Using Database::getConnection(), not mysql_*
+- Configuration API: Config entities for settings, not variables
+- Cache API: Proper cache tags and contexts
+- Queue API: For long-running processes
+
+**Code Architecture:**
+- Dependency Injection: Services injected, not statically called
+- Hook Implementations: Correct hook usage and naming
+- Plugin System: Proper plugin implementation when applicable
+- Event Subscribers: For responding to system events
+- Service Definitions: Proper service registration
+
+**Database Changes:**
+- Update Hooks: Database schema changes in update hooks
+- Migration Scripts: For data transformations
+- Schema Definition: Proper schema API usage
+- Backward Compatibility: Rollback procedures
+
+#### Important/Recommended Criteria:
+**Performance Considerations:**
+- Query Optimization: Avoid N+1 queries, use entity loading
+- Caching Strategy: Appropriate cache bins and invalidation
+- Asset Optimization: Aggregation, lazy loading
+- Memory Usage: Batch processing for large datasets
+- Database Indexes: For frequently queried fields
+
+**Code Quality Standards:**
+- Drupal Coding Standards: phpcs with Drupal/DrupalPractice
+- Type Declarations: PHP 8.3+ type hints
+- Error Handling: Try-catch blocks, graceful degradation
+- Type validation: Classes and methods types are validate before use - instaseof Class
+- Code Complexity: Cyclomatic complexity < 10
+- Function Length: Methods under 50 lines
+- DRY Principle: No code duplication
+
+**Testing Coverage:**
+- Unit Tests: For isolated functionality
+- Kernel Tests: For Drupal API integration
+- Functional Tests: For user workflows
+- JavaScript Tests: For frontend functionality
+- Test Data: Proper test fixtures and mocks
+
+**Documentation:**
+- PHPDoc Blocks: For classes and public methods
+- README Updates: For new features/modules
+- Change Records: For API changes
+- Hook Documentation: Proper @hook annotations
+- Code Comments: For complex logic only
+
+#### Optional/Nice-to-Have Criteria:
+**Accessibility (WCAG 2.1):**
+- ARIA Labels: Proper semantic markup
+- Keyboard Navigation: Full keyboard support
+- Screen Reader: Announced changes
+- Color Contrast: WCAG AA compliance
+- Form Labels: Associated with inputs
+
+**Frontend Standards:**
+- JavaScript: ES6+, no inline scripts
+- CSS: BEM methodology, no !important
+- Responsive Design: Mobile-first approach
+- Browser Support: Per project requirements
+- Asset Libraries: Proper library definitions
+
+#### Vue.js/React Specific Standards:
+**For Vue.js Projects:**
+- Import statements: Use named imports correctly (e.g., `import { ComponentName } from`)
+- CSS selectors: Avoid deprecated `/deep/`, use `::v-deep` for Vue 2
+- Props: Don't define props that aren't used
+- Component structure: Follow Vue style guide
+- State management: Proper Vuex usage
+- Computed properties: Should be pure functions
+
+**For React Projects:**
+- Hooks: Follow Rules of Hooks
+- State management: Proper Redux/Context usage
+- Component structure: Functional components preferred
+- PropTypes or TypeScript: Type checking required
+- **Security**: NEVER use localStorage for JWT tokens or sensitive data
+- Token Storage: Use httpOnly cookies or secure storage abstractions
+- API Keys: Must not be exposed in frontend code
+- Data Sanitization: Always sanitize user input before rendering
+
+**Multi-site & Multilingual:**
+- Domain Access: Proper domain-aware code
+- Configuration Split: Environment-specific configs
+- String Translation: t() and formatPlural()
+- Content Translation: Entity translation API
+
+### 3. Drupal-Specific Security Assessment
+**Native Drupal Security (Auto-Pass Criteria):**
+- CSRF protection is handled automatically by Drupal Form API - no manual checks needed
+- Administrative forms protected by permission system - inherently secure
+- Drupal's built-in input filtering and sanitisation - trust the framework
+- Entity access control through Drupal's entity system - framework handles this
+
+**Manual Security Checks Required:**
+- Custom database queries must use parameterised queries
+- Direct HTML output must use proper sanitisation functions
+- File uploads must validate file types and permissions
+- Custom access callbacks must be properly implemented
+- Cache invalidation strategy must be secure
+- Update path testing for existing sites
+- Multisite compatibility verification
+- Queue/Batch API for scalability
+- Entity access checks beyond basic permissions
+
+## Line-Specific Comments (CRITICAL)
+
+**ALWAYS add line-specific comments** for identified issues using the GitHub review API:
+
+1. **Use the review API** to create a review with line comments:
+   ```bash
+   # IMPORTANT: Check if you're reviewing your own PR first!
+   PR_AUTHOR=$(gh pr view {pr_number} --repo {owner}/{repo} --json author -q '.author.login')
+   CURRENT_USER=$(gh api user -q '.login')
+   
+   if [ "$PR_AUTHOR" = "$CURRENT_USER" ]; then
+     EVENT_TYPE="COMMENT"  # Cannot request changes on own PR
+   else
+     EVENT_TYPE="REQUEST_CHANGES"  # or "APPROVE" or "COMMENT"
+   fi
+   
+   # Create a JSON file with review comments
+   cat > /tmp/review_comments.json << EOF
+   {
+     "body": "Code review with line-specific feedback",
+     "event": "$EVENT_TYPE",
+     "comments": [
+       {
+         "path": "path/to/file.ext",
+         "line": 123,
+         "body": "Your comment here with code suggestions"
+       }
+     ]
+   }
+   EOF
+   
+   # Submit the review
+   gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews -X POST --input /tmp/review_comments.json
+   ```
+
+2. **Line comment best practices**:
+   - Be specific about the issue and provide the fix
+   - Include code snippets showing the correct implementation
+   - Reference relevant documentation or standards
+   - Use markdown formatting for clarity
+
+3. **Common pitfalls to avoid**:
+   - Don't use `gh pr comment` for line-specific feedback (it only adds general comments)
+   - Don't try to use deprecated comment APIs
+   - Ensure line numbers match the diff view, not the file view
+   - NEVER use "REQUEST_CHANGES" on your own PRs (causes HTTP 422 error)
+
+## Decision Criteria (Drupal-Context Aware)
+
+- **Approve**: Overall score ≥ 80% AND requirement fulfilment ≥ 80% AND no critical custom security issues
+- **Request Changes**: Overall score < 75% OR requirement fulfilment < 80% OR critical custom security vulnerabilities
+- **Comment**: Score 75-79% with minor issues
+
+**Note**: Drupal's native security features (Form API CSRF, permission-based access, Entity API) are considered secure by default and should not trigger failures.
+
+## GitHub Label Management
+
+**Required Standard Labels** (create if not present with specified colours):
+
+**Review Status Labels:**
+- `code-review-approved` - PR passes all quality checks
+  - **Color**: `#1f7a1f` (dark green)
+- `code-review-changes` - Changes requested before approval
+  - **Color**: `#cc8800` (dark orange)
+- `code-review-security` - Security issues identified
+  - **Color**: `#dc3545` (red)
+
+**Quality Labels:**
+- `drupal-standards` - Drupal coding standards violations
+  - **Color**: `#6f42c1` (purple)
+- `requirements-met` - Functional requirements satisfied
+  - **Color**: `#1f7a1f` (dark green)
+- `requirements-gap` - Missing or incomplete functionality
+  - **Color**: `#cc8800` (dark orange)
+
+**Technical Labels:**
+- `performance-impact` - Performance concerns identified
+  - **Color**: `#fd7e14` (orange)
+- `documentation-needed` - Missing or inadequate documentation
+  - **Color**: `#17a2b8` (blue)
+- `testing-required` - Additional tests needed
+  - **Color**: `#e83e8c` (pink)
+- `php-upgrade` - PHP version compatibility issues
+  - **Color**: `#6c757d` (grey)
+
+**Size Labels** (based on PR statistics):
+- `size/xs` - 1-10 lines changed
+  - **Color**: `#28a745` (light green)
+- `size/s` - 11-50 lines changed
+  - **Color**: `#ffc107` (yellow)
+- `size/m` - 51-200 lines changed
+  - **Color**: `#fd7e14` (orange)
+- `size/l` - 201-500 lines changed
+  - **Color**: `#dc3545` (red)
+- `size/xl` - 500+ lines changed
+  - **Color**: `#6f42c1` (purple)
+
+**Component Labels** (based on affected modules):
+- `component/backend` - Drupal backend changes
+  - **Color**: `#0d6efd` (blue)
+- `component/frontend` - Theme/JS/CSS changes
+  - **Color**: `#20c997` (teal)
+- `component/api` - API modifications
+  - **Color**: `#6610f2` (indigo)
+- `component/config` - Configuration changes
+  - **Color**: `#fd7e14` (orange)
+- `component/security` - Security-related changes
+  - **Color**: `#dc3545` (red)
+
+## Label Application Logic
+
+**Auto-Apply Labels Based On:**
+- **Score ≥ 80%**: Add `code-review-approved`
+- **Score < 80%**: Add `code-review-changes` 
+- **Security Issues**: Add `code-review-security`
+- **Standards Violations**: Add `drupal-standards`
+- **Requirement Score ≥ 80%**: Add `requirements-met`
+- **Requirement Score < 80%**: Add `requirements-gap`
+- **Performance Warnings**: Add `performance-impact`
+- **Documentation Issues**: Add `documentation-needed`
+- **Missing Tests**: Add `testing-required`
+- **PHP Compatibility**: Add `php-upgrade`
+
+**Label Application Methods:**
+1. **Preferred**: Use `gh issue edit` command (works for PRs too):
+   ```bash
+   gh issue edit {pr_number} --repo {owner}/{repo} --add-label "label1" --add-label "label2"
+   ```
+2. **Alternative**: If repository uses non-standard labels, check existing labels first:
+   ```bash
+   gh label list --repo {owner}/{repo} --limit 100
+   ```
+   Then apply the most appropriate existing labels
+
+## Freshdesk Management
+
+After completing the code review, perform the following Freshdesk updates:
+
+1. **Add Private Note** with review findings using structured HTML format with appropriate colour coding
+2. **Log Time Entry** of 15 minutes for "Code Review" activity
+
+### Private Note HTML Structure Template
+```html
+<div>
+<h4 style="color: {status_color}">{status_icon} PR #{pr_number} - {review_status}</h4>
+<div>
+<strong>Overall Score:</strong> <span style="color: {score_color}; font-weight: bold">{score}%</span>
+</div>
+
+<h4>Review Summary</h4>
+<div><strong style="color: {requirement_color}">{requirement_icon} Requirements ({requirement_score}%)</strong></div>
+<ul>
+  {requirement_details}
+</ul>
+
+<div><strong style="color: {drupal_color}">{drupal_icon} Drupal Standards ({drupal_score}%)</strong></div>
+<ul>
+  {drupal_standards_details}
+</ul>
+
+<div><strong style="color: {security_color}">{security_icon} Security Assessment ({security_score}%)</strong></div>
+<ul>
+  {security_assessment_details}
+</ul>
+
+<h4>Technical Changes</h4>
+<ol>
+  {technical_changes_list}
+</ol>
+
+{critical_issues_section}
+
+<div style="background-color: {status_bg_color}; padding: 10px; border-left: 4px solid {status_color}">
+  <strong>Status:</strong> {final_status}<br>
+  <strong>PR Link:</strong> <a href="{pr_html_url}" rel="noreferrer" target="_blank">{pr_html_url}</a><br>
+  {next_steps_info}
+</div>
+</div>
+```
+
+### Colour Coding Guidelines
+
+**Status Colours:**
+- **Success/Approved**: `#1f7a1f` (dark green)
+- **Warning/Changes Needed**: `#cc8800` (dark orange) 
+- **Critical/Failed**: `#dc3545` (red)
+- **Info/In Progress**: `#17a2b8` (blue)
+
+**Icons and Status:**
+- **✅ Passed (90%+)**: Dark Green `#1f7a1f`
+- **⚠️ Warning (75-89%)**: Dark Orange `#cc8800`
+- **❌ Failed (<75%)**: Red `#dc3545`
+- **🔍 Under Review**: Blue `#17a2b8`
+
+**Background Colours for Status Boxes:**
+- **Success**: `#d4edda` (light green)
+- **Warning**: Use private note background `background-image: linear-gradient(#fef1e1, #fef1e1);`
+- **Danger**: `#f8d7da` (light red)
+- **Info**: `#d1ecf1` (light blue)
+
+**Code Formatting:**
+```html
+<code style="background-color: #f5f5f5; padding: 2px 4px">filename.php</code>
+```
+
+**Critical Issues Section (when applicable):**
+```html
+<div style="background-color: #f8d7da; padding: 10px; border-left: 4px solid #dc3545">
+  <h4 style="color: #dc3545">❌ Critical Issues Found</h4>
+  <ul>
+    {critical_issues_list}
+  </ul>
+</div>
+```
+
+**Warning Issues Section (when applicable):**
+```html
+<div style="background-image: linear-gradient(#fef1e1, #fef1e1); padding: 10px; border-left: 4px solid #cc8800">
+  <h4 style="color: #cc8800">⚠️ Issues Requiring Attention</h4>
+  <ul>
+    {warning_issues_list}
+  </ul>
+</div>
+```
+
+**Note Update Instructions:**
+- Use `create_ticket_note` to add private note with HTML structure
+- Apply appropriate colours based on review outcomes
+- Include all critical findings and recommendations
+- Reference PR links for easy tracking
+- Update ticket status if review indicates completion
+- **Log Time Entry**: Use appropriate Freshdesk API to log 15 minutes of work time for "Code Review" activity
+
+## Australian English
+Use Australian English spelling and terminology throughout the review.
+
+## PR Review Checklist
+
+When reviewing, ensure you check:
+
+### Critical (Must Pass):
+- [ ] No SQL injection vulnerabilities
+- [ ] No XSS vulnerabilities
+- [ ] Proper access control implemented
+- [ ] No hardcoded credentials or secrets
+- [ ] Drupal APIs used correctly (Entity, Form, Render)
+- [ ] Database updates in update hooks
+- [ ] File uploads validated
+
+### Important (Should Pass):
+- [ ] Performance optimized (queries, caching)
+- [ ] Drupal coding standards followed
+- [ ] Adequate test coverage
+- [ ] Documentation updated
+- [ ] Error handling implemented
+- [ ] No code duplication
+
+### Nice to Have:
+- [ ] Accessibility standards met
+- [ ] Frontend best practices
+- [ ] Multisite compatibility tested
+- [ ] Multilingual support
+- [ ] Module structure follows conventions
+
+### Commonly Missed:
+- [ ] Cache invalidation strategy
+- [ ] Update path testing
+- [ ] Queue/Batch API for long processes
+- [ ] Entity access beyond permissions
+- [ ] Configuration split for environments
+
+## CRITICAL: Self-Improvement Protocol
+
+**MANDATORY**: After EVERY code review session, you MUST update this command file (`/Users/ivan/.claude/commands/pr.md`) with:
+
+1. **New Technology Stacks Encountered**:
+   - Add specific review criteria for any new frameworks/languages
+   - Document unique linting rules or standards
+   - Note build/test commands specific to that stack
+
+2. **Command Issues and Workarounds**:
+   - Document any gh CLI commands that failed and why
+   - Add working alternatives you discovered
+   - Update examples with real, tested commands
+
+3. **Repository-Specific Patterns**:
+   - Custom label schemes used by specific organisations
+   - Unique workflow requirements
+   - Special security or compliance needs
+
+4. **Review Process Improvements**:
+   - Better ways to extract requirements from tickets
+   - More efficient review workflows
+   - Time-saving automation opportunities
+
+5. **Common Code Issues by Technology**:
+   - Add to the "Commonly Missed" sections
+   - Create new sections for technology-specific pitfalls
+   - Update scoring criteria based on real reviews
+
+### Update Process:
+1. At the end of each review, ask yourself: "What did I learn?"
+2. Use the `Edit` tool to update relevant sections
+3. Add real examples from the review you just completed
+4. Test any new commands before documenting them
+
+### Example Update Entry:
+```markdown
+### [Date] - Technology: [Stack] - Repository: [Name]
+**Issue**: [What happened]
+**Solution**: [How you solved it]
+**Future Prevention**: [What to do next time]
+```
+
+## Lessons Learned from Review Sessions
+
+### What Works Well:
+1. **gh CLI**: Reliable for PR operations
+2. **gh issue edit**: Works for adding labels to PRs (PRs are issues in GitHub)
+3. **Review API**: Best method for line-specific comments
+4. **JSON input files**: Clean way to structure complex review data
+
+### Common Pitfalls:
+1. **Don't assume Drupal**: Many repos are Vue.js/React frontends
+2. **Check existing labels**: Repos may have custom label schemes
+3. **Line comments require review API**: `gh pr comment` only adds general comments
+4. **No ticket reference**: Not all PRs reference tickets - proceed with code review anyway
+5. **Import statements**: Watch for incorrect ES6 module imports in frontend code
+6. **Deprecated Vue features**: `/deep/` selector, unused props, etc.
+7. **PR Review Submission**: You CANNOT request changes on your own PRs - use "COMMENT" instead
+8. **Token Storage**: Always flag localStorage usage for auth tokens as security risk
+
+### Technology-Specific Discoveries:
+
+#### Vue.js (Vue 2)
+- **Date**: 2025-06-03
+- **Issue**: `/deep/` selector still being used
+- **Solution**: Always flag for `::v-deep` replacement
+- **Common Pattern**: Unused props passed but never utilized
+
+#### GitHub API Quirks
+- **Date**: 2025-06-03
+- **Issue**: `gh pr edit --add-label` fails with permissions error
+- **Solution**: Use `gh issue edit` instead (PRs are issues)
+- **Note**: Some repos have 100+ custom labels - always check first
+
+#### React Frontend Security
+- **Date**: 2025-07-07
+- **Issue**: localStorage used for JWT token storage in React app
+- **Solution**: Flag as security vulnerability - recommend httpOnly cookies or sessionStorage
+- **Common Pattern**: Many React apps default to localStorage for convenience
+- **Security Impact**: Tokens in localStorage are vulnerable to XSS attacks
+
+### PR Review API Best Practices (Updated 2025-07-07)
+
+**CRITICAL**: Avoid these token-wasting mistakes:
+
+1. **Review Event Type Selection**:
+   - If reviewing your own PR: MUST use `"event": "COMMENT"`
+   - If reviewing others' PRs: Can use `"REQUEST_CHANGES"`, `"APPROVE"`, or `"COMMENT"`
+   - The API will return HTTP 422 error if you try to request changes on your own PR
+
+2. **Label Creation Strategy**:
+   - ALWAYS create labels before trying to apply them
+   - Use `2>/dev/null || true` to suppress errors if labels already exist
+   - Batch label creation to avoid multiple API calls
+
+3. **Efficient Review Process**:
+   ```bash
+   # Step 1: Create all needed labels first (batch operation)
+   for label in "code-review-changes:cc8800" "requirements-met:1f7a1f"; do
+     IFS=':' read -r name color <<< "$label"
+     gh label create "$name" --repo {owner}/{repo} --color "$color" 2>/dev/null || true
+   done
+   
+   # Step 2: Submit review with correct event type
+   # For your own PRs:
+   gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews -X POST --input review.json
+   # Where review.json has "event": "COMMENT"
+   
+   # Step 3: Apply all labels in one command
+   gh issue edit {pr_number} --repo {owner}/{repo} \
+     --add-label "label1" --add-label "label2" --add-label "label3"
+   ```
+
+4. **Common Security Checks for Frontend Apps**:
+   - localStorage usage for sensitive data (tokens, PII)
+   - Inline event handlers (onclick, etc.)
+   - Direct DOM manipulation without sanitization
+   - Missing CSP headers configuration
+   - Exposed API keys in frontend code
+   
+## Final report
+    - amongst other requirements, include inline comments against individual files and line numbers.
diff --git a/.cursor/commands/pr-draft.md b/.cursor/commands/pr-draft.md
new file mode 100644
index 0000000..fc29375
--- /dev/null
+++ b/.cursor/commands/pr-draft.md
@@ -0,0 +1,62 @@
+# Custom Command: PR Draft
+
+## Command Usage
+`/pr-draft <pr-notes>`
+
+The argument `<pr-notes>` should capture highlights, testing notes, and reviewer callouts. Use it to shape the PR title and body.
+
+You are tasked with creating a pull request (PR) for a code change. Follow these instructions carefully to generate an appropriate PR description and title.
+
+Check if Use the user-provided arguments (if any) as contextual input was provided in a prompt. If not, stop first and ask user for any comments, assign them as Use the user-provided arguments (if any) as contextual input. Process the Use the user-provided arguments (if any) as contextual input, extract the useful information and plan how it might impact pull request creation. If none provided, proceed with the PR creation.
+
+## Tool use
+
+Use github cli or github mcp if available for PR creation.
+
+## Template
+
+First, here is the PR template that should be used as a base for the pull request description:
+
+<pr_template>
+the repository pull request template
+</pr_template>
+
+Now, let's create the pull request:
+
+1. Extract the ticket number:
+   Analyze the branch name provided: the active Git branch name
+   Look for a four-digit number in the branch name, which should represent the Freshdesk ticket number. If found, use it in the next steps. If not found, make a note to ask for it later, unless Use the user-provided arguments (if any) as contextual input instruct you to skip ticket number.
+
+2. Create the PR title:
+   Format: "[#TICKET_NUMBER] [Verb in past tense] [description of the change] [full stop at the end.]"
+   Example: "[#5765] Updated user authentication process."
+
+3. Create the PR description:
+   Start with the PR template provided above.
+   
+   For the "Freshdesk or JIRA ticket" section:
+   - If you found a ticket number, add the link: https://servicedesk.salsadigital.com.au/a/tickets/TICKET_NUMBER
+   - If no ticket number was found, leave a placeholder: "TODO: Add Freshdesk ticket link", However, if you were provided with instructions to skip ticket number, then ignore this line. 
+
+   For the "Changed" section:
+   - Be very descriptive about every change made.
+   - Use proper markdown with headings, lists and other markdown options.
+   - Ensure extra empty line is present between header and text and between list options.
+   - Mention constant names, variables, and classes that were generated or updated.
+   - Explain the reason for the update and what problems were solved.
+   - List the items that were updated or changed.
+   - Do not include lengthy code snippets.
+
+   For the "Screenshots" section:
+   - Leave it empty.
+
+4. If any information is missing (e.g., ticket number not found in branch name), add a note at the end of the PR description listing the missing information that needs to be provided, unless custom instructions in the Use the user-provided arguments (if any) as contextual input instruct you not to do so. 
+
+5. Final output:
+   Provide the following in your response:
+   a) The PR title
+   b) The complete PR description
+   c) Any questions or missing information that need to be addressed before submitting the PR
+   d) PR link.
+
+Remember, your final output should only include the PR title, PR description, and any questions about missing information. Do not include any of your thought process or these instructions in the output.
diff --git a/.cursor/commands/pr-resolve.md b/.cursor/commands/pr-resolve.md
new file mode 100644
index 0000000..b4ed961
--- /dev/null
+++ b/.cursor/commands/pr-resolve.md
@@ -0,0 +1,128 @@
+# Custom Command: PR Resolve
+
+## Command Usage
+`/pr-resolve <pr-url-or-number> [context]`
+
+Require the PR URL/number as the first argument. Treat any following text as remediation instructions from the reviewer.
+
+Please address review comments for Pull Request: Use the user-provided arguments (if any) as contextual input.
+If no artument was provided or you can't read it, stop and ask the user for the prompt, pull request URL and any instructions. Any user input becomes the Use the user-provided arguments (if any) as contextual input. Use those instructions from the Use the user-provided arguments (if any) as contextual input and pull request URL in further steps.
+
+This command uses AI coding agent to efficiently resolve PR feedback while maintaining code quality.
+
+## 0. VALIDATION PHASE
+If no PR link provided in Use the user-provided arguments (if any) as contextual input, ask user:
+"Please provide the PR link (e.g., https://github.com/org/repo/pull/123 or just the PR number if in the current repo)"
+
+## 1. ANALYSIS PHASE
+Launch initial analysis agent:
+```
+Task: "Analyze PR #Use the user-provided arguments (if any) as contextual input comprehensively:
+- Use 'gh pr view Use the user-provided arguments (if any) as contextual input' to get PR details
+- Use 'gh pr reviews Use the user-provided arguments (if any) as contextual input' to get all review comments
+- Use 'gh api repos/{owner}/{repo}/pulls/{number}/comments' for inline file comments
+- Check current PR status and CI/CD results
+- Categorize feedback into: code changes, test additions, documentation updates
+- Check project's AGENTS.md for available testing and linting commands"
+```
+
+## 2. MULTI-STEP RESOLUTION PHASE
+
+### Step 1 - Code Changes & Review Comments
+```
+Task: "Address all code review feedback for PR #Use the user-provided arguments (if any) as contextual input:
+- For each review comment:
+  * Understand the requested change
+  * Implement the fix following reviewer suggestions
+  * Search codebase for similar patterns to ensure consistency
+- For inline file comments:
+  * Navigate to exact file and line
+  * Implement suggested changes
+  * Consider impact on surrounding code
+- Make logical commits grouping related changes"
+```
+
+### Step 2 - Testing & Validation
+```
+Task: "Ensure all tests pass for PR #Use the user-provided arguments (if any) as contextual input:
+- Check AGENTS.md for project-specific test commands
+- Detect available testing frameworks:
+  * Look for: composer.json, package.json, Makefile, ahoy.yml
+  * For Drupal: check for phpunit.xml, behat.yml
+  * Check for Playwright/Puppeteer configs or MCP servers
+- Run the full test suite:
+  * Use commands from AGENTS.md first
+  * Fallback to standard commands (composer test, npm test)
+  * For Drupal: try `ahoy test`, `ahoy test-bdd`, `ahoy test-unit`, `ddev test`, `lando test`
+- If tests fail:
+  * Analyze failure reasons
+  * Fix failing tests or implementation
+  * Add new tests if requested in reviews"
+```
+
+### Step 3 - Linting & Code Quality
+```
+Task: "Fix all linting and style issues for PR #Use the user-provided arguments (if any) as contextual input:
+- Check AGENTS.md for project-specific linting commands
+- Detect available linters:
+  * For PHP: phpcs, phpstan, psalm
+  * For JS: eslint, prettier
+  * For Python: flake8, black, pylint
+- Run all applicable linters:
+  * Use commands from AGENTS.md first
+  * Fix all warnings and errors
+  * For Drupal: ensure coding standards compliance
+- Run formatters if available
+- Ensure blank empty line at the end of every file in your PR review
+- Verify no new linting issues introduced"
+```
+
+## 3. DOCUMENTATION PHASE
+After code changes complete, if needed:
+```
+Task: "Update documentation for PR #Use the user-provided arguments (if any) as contextual input:
+- Review all code changes from other agents
+- Check if any of these require documentation updates:
+  * API changes
+  * New functionality
+  * Changed methodology or approach
+  * Configuration changes
+- Update relevant documentation:
+  * Inline code comments
+  * README.md (only if necessary)
+  * For Drupal: update .module file docs, hook_help()
+  * API documentation if applicable
+- Do NOT create new documentation files unless critical"
+```
+
+## 4. FINALIZATION PHASE
+After all agents complete successfully:
+```
+Task: "Finalize and push changes for PR #Use the user-provided arguments (if any) as contextual input:
+- Run final test suite to ensure nothing broken
+- Run final linting pass
+- Create clear commit messages explaining changes
+- Group related changes into logical commits
+- Push all commits to update the PR
+- Post a comment on PR summarizing addressed feedback:
+  * List all resolved comments
+  * Mention any remaining concerns
+  * Thank reviewers for feedback"
+```
+
+## 5. VERIFICATION
+Final check:
+- Use 'gh pr checks Use the user-provided arguments (if any) as contextual input' to verify CI/CD status
+- Ensure all automated checks are passing
+
+## Key Principles:
+1. **Systematic Approach**: Every review comment is tracked and addressed
+2. **Quality Gates**: Changes only pushed after tests and linting pass
+3. **Project Awareness**: Always check AGENTS.md for project-specific commands
+4. **Documentation**: Update docs only when functionality changes
+
+## Error Handling:
+- If PR not found: Ask user for correct PR link
+- If tests fail: Fix before proceeding
+- If linting fails: Fix before pushing
+- If push fails: Check branch permissions and conflicts
diff --git a/.cursor/commands/security-scan.md b/.cursor/commands/security-scan.md
new file mode 100644
index 0000000..9a7d907
--- /dev/null
+++ b/.cursor/commands/security-scan.md
@@ -0,0 +1,109 @@
+# Custom Command: Security Scan
+
+## Command Usage
+`/security-scan [scope]`
+
+Use `scope` to target a subdirectory or component; omit it for a repository-wide audit.
+
+# Security Audit
+
+Perform a comprehensive security audit of the codebase to identify potential vulnerabilities, insecure patterns, and security best practice violations. Validate against OWASP Top-10, check file in the project codebase named owasp_top10_2021.csv with vulnerabilities.
+
+## Usage Examples
+
+### Basic Usage
+"Run a security audit on this project"
+"Check for security vulnerabilities in the authentication module"
+"Scan the API endpoints for security issues"
+
+### Specific Audits
+"Check for SQL injection vulnerabilities"
+"Audit the file upload functionality for security risks"
+"Review authentication and authorization implementation"
+"Check for hardcoded secrets and API keys"
+
+## Instructions for the agent
+
+When performing a security audit:
+
+1. **Systematic Scanning**: Examine the codebase systematically for common vulnerability patterns
+2. **Use OWASP Guidelines**: Reference OWASP Top 10 and other security standards
+3. **Check Multiple Layers**: Review frontend, backend, database, and infrastructure code
+4. **Prioritize Findings**: Categorize issues by severity (Critical, High, Medium, Low)
+5. **Provide Remediation**: Include specific fixes for each identified issue
+
+### Security Checklist
+
+#### Authentication & Authorization
+- Password storage and hashing methods
+- Session management security
+- JWT implementation and validation
+- Access control and permission checks
+- Multi-factor authentication support
+
+#### Input Validation & Sanitization
+- SQL injection prevention
+- XSS (Cross-Site Scripting) protection
+- Command injection safeguards
+- Path traversal prevention
+- File upload validation
+
+#### Data Protection
+- Encryption in transit (HTTPS/TLS)
+- Encryption at rest
+- Sensitive data exposure
+- API key and secret management
+- PII handling compliance
+
+#### Common Vulnerabilities
+- CSRF protection
+- Clickjacking prevention
+- Security headers configuration
+- Dependency vulnerabilities
+- Insecure direct object references
+
+#### API Security
+- Rate limiting implementation
+- API authentication methods
+- Input validation on endpoints
+- Error message information leakage
+- CORS configuration
+
+### Output Format
+
+Provide a structured security report with:
+
+```markdown
+## Security Audit Report
+
+### Summary
+- Total issues found: X
+- Critical: X, High: X, Medium: X, Low: X
+
+### Critical Issues
+#### 1. [Issue Name]
+- **Location**: file.js:line
+- **Description**: Detailed explanation
+- **Impact**: Potential consequences
+- **Remediation**: Specific fix with code example
+
+### High Priority Issues
+[Similar format]
+
+### Medium Priority Issues
+[Similar format]
+
+### Low Priority Issues
+[Similar format]
+
+### Recommendations
+- General security improvements
+- Best practices to implement
+- Tools and libraries to consider
+```
+
+Remember to:
+- Be specific about file locations and line numbers
+- Provide code examples for fixes
+- Explain the security impact clearly
+- Avoid false positives by understanding the context
diff --git a/.cursor/commands/security-verify.md b/.cursor/commands/security-verify.md
new file mode 100644
index 0000000..894318f
--- /dev/null
+++ b/.cursor/commands/security-verify.md
@@ -0,0 +1,193 @@
+# Custom Command: Security Verify
+
+## Command Usage
+`/security-verify <branch>`
+
+The `<branch>` argument identifies the feature branch being reviewed.
+
+You are a senior security engineer conducting a focused security review of the changes on this branch. You also validating local changes against OWASP Top-10 vulnerabilities. Check project codebase for the file named owasp_top10_2021.csv which outlines those.
+
+GIT STATUS:
+
+```
+!`git status`
+```
+
+FILES MODIFIED:
+
+```
+!`git diff --name-only origin/HEAD...`
+```
+
+COMMITS:
+
+```
+!`git log --no-decorate origin/HEAD...`
+```
+
+DIFF CONTENT:
+
+```
+!`git diff --merge-base origin/HEAD`
+```
+
+Review the complete diff above. This contains all code changes in the PR.
+
+
+OBJECTIVE:
+Perform a security-focused code review to identify HIGH-CONFIDENCE security vulnerabilities that could have real exploitation potential. This is not a general code review - focus ONLY on security implications newly added by this PR. Do not comment on existing security concerns.
+
+CRITICAL INSTRUCTIONS:
+1. MINIMIZE FALSE POSITIVES: Only flag issues where you're >80% confident of actual exploitability
+2. AVOID NOISE: Skip theoretical issues, style concerns, or low-impact findings
+3. FOCUS ON IMPACT: Prioritize vulnerabilities that could lead to unauthorized access, data breaches, or system compromise
+4. EXCLUSIONS: Do NOT report the following issue types:
+   - Denial of Service (DOS) vulnerabilities, even if they allow service disruption
+   - Secrets or sensitive data stored on disk (these are handled by other processes)
+   - Rate limiting or resource exhaustion issues
+
+SECURITY CATEGORIES TO EXAMINE:
+
+**Input Validation Vulnerabilities:**
+- SQL injection via unsanitized user input
+- Command injection in system calls or subprocesses
+- XXE injection in XML parsing
+- Template injection in templating engines
+- NoSQL injection in database queries
+- Path traversal in file operations
+
+**Authentication & Authorization Issues:**
+- Authentication bypass logic
+- Privilege escalation paths
+- Session management flaws
+- JWT token vulnerabilities
+- Authorization logic bypasses
+
+**Crypto & Secrets Management:**
+- Hardcoded API keys, passwords, or tokens
+- Weak cryptographic algorithms or implementations
+- Improper key storage or management
+- Cryptographic randomness issues
+- Certificate validation bypasses
+
+**Injection & Code Execution:**
+- Remote code execution via deseralization
+- Pickle injection in Python
+- YAML deserialization vulnerabilities
+- Eval injection in dynamic code execution
+- XSS vulnerabilities in web applications (reflected, stored, DOM-based)
+
+**Data Exposure:**
+- Sensitive data logging or storage
+- PII handling violations
+- API endpoint data leakage
+- Debug information exposure
+
+Additional notes:
+- Even if something is only exploitable from the local network, it can still be a HIGH severity issue
+
+ANALYSIS METHODOLOGY:
+
+Phase 1 - Repository Context Research (Use file search tools):
+- Identify existing security frameworks and libraries in use
+- Look for established secure coding patterns in the codebase
+- Examine existing sanitization and validation patterns
+- Understand the project's security model and threat model
+
+Phase 2 - Comparative Analysis:
+- Compare new code changes against existing security patterns
+- Identify deviations from established secure practices
+- Look for inconsistent security implementations
+- Flag code that introduces new attack surfaces
+
+Phase 3 - Vulnerability Assessment:
+- Examine each modified file for security implications
+- Trace data flow from user inputs to sensitive operations
+- Look for privilege boundaries being crossed unsafely
+- Identify injection points and unsafe deserialization
+
+REQUIRED OUTPUT FORMAT:
+
+You MUST output your findings in markdown. The markdown output should contain the file, line number, severity, category (e.g. `sql_injection` or `xss`), description, exploit scenario, and fix recommendation. 
+
+For example:
+
+# Vuln 1: XSS: `foo.py:42`
+
+* Severity: High
+* Description: User input from `username` parameter is directly interpolated into HTML without escaping, allowing reflected XSS attacks
+* Exploit Scenario: Attacker crafts URL like /bar?q=<script>alert(document.cookie)</script> to execute JavaScript in victim's browser, enabling session hijacking or data theft
+* Recommendation: Use Flask's escape() function or Jinja2 templates with auto-escaping enabled for all user inputs rendered in HTML
+
+SEVERITY GUIDELINES:
+- **HIGH**: Directly exploitable vulnerabilities leading to RCE, data breach, or authentication bypass
+- **MEDIUM**: Vulnerabilities requiring specific conditions but with significant impact
+- **LOW**: Defense-in-depth issues or lower-impact vulnerabilities
+
+CONFIDENCE SCORING:
+- 0.9-1.0: Certain exploit path identified, tested if possible
+- 0.8-0.9: Clear vulnerability pattern with known exploitation methods
+- 0.7-0.8: Suspicious pattern requiring specific conditions to exploit
+- Below 0.7: Don't report (too speculative)
+
+FINAL REMINDER:
+Focus on HIGH and MEDIUM findings only. Better to miss some theoretical issues than flood the report with false positives. Each finding should be something a security engineer would confidently raise in a PR review.
+
+FALSE POSITIVE FILTERING:
+
+> You do not need to run commands to reproduce the vulnerability, just read the code to determine if it is a real vulnerability. Do not use the bash tool or write to any files.
+>
+> HARD EXCLUSIONS - Automatically exclude findings matching these patterns:
+> 1. Denial of Service (DOS) vulnerabilities or resource exhaustion attacks.
+> 2. Secrets or credentials stored on disk if they are otherwise secured.
+> 3. Rate limiting concerns or service overload scenarios.
+> 4. Memory consumption or CPU exhaustion issues.
+> 5. Lack of input validation on non-security-critical fields without proven security impact.
+> 6. Input sanitization concerns for GitHub Action workflows unless they are clearly triggerable via untrusted input.
+> 7. A lack of hardening measures. Code is not expected to implement all security best practices, only flag concrete vulnerabilities.
+> 8. Race conditions or timing attacks that are theoretical rather than practical issues. Only report a race condition if it is concretely problematic.
+> 9. Vulnerabilities related to outdated third-party libraries. These are managed separately and should not be reported here.
+> 10. Memory safety issues such as buffer overflows or use-after-free-vulnerabilities are impossible in rust. Do not report memory safety issues in rust or any other memory safe languages.
+> 11. Files that are only unit tests or only used as part of running tests.
+> 12. Log spoofing concerns. Outputting un-sanitized user input to logs is not a vulnerability.
+> 13. SSRF vulnerabilities that only control the path. SSRF is only a concern if it can control the host or protocol.
+> 14. Including user-controlled content in AI system prompts is not a vulnerability.
+> 15. Regex injection. Injecting untrusted content into a regex is not a vulnerability.
+> 16. Regex DOS concerns.
+> 16. Insecure documentation. Do not report any findings in documentation files such as markdown files.
+> 17. A lack of audit logs is not a vulnerability.
+> 
+> PRECEDENTS -
+> 1. Logging high value secrets in plaintext is a vulnerability. Logging URLs is assumed to be safe.
+> 2. UUIDs can be assumed to be unguessable and do not need to be validated.
+> 3. Environment variables and CLI flags are trusted values. Attackers are generally not able to modify them in a secure environment. Any attack that relies on controlling an environment variable is invalid.
+> 4. Resource management issues such as memory or file descriptor leaks are not valid.
+> 5. Subtle or low impact web vulnerabilities such as tabnabbing, XS-Leaks, prototype pollution, and open redirects should not be reported unless they are extremely high confidence.
+> 6. React and Angular are generally secure against XSS. These frameworks do not need to sanitize or escape user input unless it is using dangerouslySetInnerHTML, bypassSecurityTrustHtml, or similar methods. Do not report XSS vulnerabilities in React or Angular components or tsx files unless they are using unsafe methods.
+> 7. Most vulnerabilities in github action workflows are not exploitable in practice. Before validating a github action workflow vulnerability ensure it is concrete and has a very specific attack path.
+> 8. A lack of permission checking or authentication in client-side JS/TS code is not a vulnerability. Client-side code is not trusted and does not need to implement these checks, they are handled on the server-side. The same applies to all flows that send untrusted data to the backend, the backend is responsible for validating and sanitizing all inputs.
+> 9. Only include MEDIUM findings if they are obvious and concrete issues.
+> 10. Most vulnerabilities in ipython notebooks (*.ipynb files) are not exploitable in practice. Before validating a notebook vulnerability ensure it is concrete and has a very specific attack path where untrusted input can trigger the vulnerability.
+> 11. Logging non-PII data is not a vulnerability even if the data may be sensitive. Only report logging vulnerabilities if they expose sensitive information such as secrets, passwords, or personally identifiable information (PII).
+> 12. Command injection vulnerabilities in shell scripts are generally not exploitable in practice since shell scripts generally do not run with untrusted user input. Only report command injection vulnerabilities in shell scripts if they are concrete and have a very specific attack path for untrusted input.
+> 
+> SIGNAL QUALITY CRITERIA - For remaining findings, assess:
+> 1. Is there a concrete, exploitable vulnerability with a clear attack path?
+> 2. Does this represent a real security risk vs theoretical best practice?
+> 3. Are there specific code locations and reproduction steps?
+> 4. Would this finding be actionable for a security team?
+> 
+> For each finding, assign a confidence score from 1-10:
+> - 1-3: Low confidence, likely false positive or noise
+> - 4-6: Medium confidence, needs investigation
+> - 7-10: High confidence, likely true vulnerability
+
+START ANALYSIS:
+
+Begin your analysis now. Do this in 3 steps:
+
+1. Use a sub-task to identify vulnerabilities. Use the repository exploration tools to understand the codebase context, then analyze the PR changes for security implications. In the prompt for this sub-task, include all of the above.
+2. Then for each vulnerability identified by the above sub-task, create a new sub-task to filter out false-positives. Launch these sub-tasks as parallel sub-tasks. In the prompt for these sub-tasks, include everything in the "FALSE POSITIVE FILTERING" instructions.
+3. Filter out any vulnerabilities where the sub-task reported a confidence less than 8.
+
+Your final reply must contain the markdown report and nothing else.
diff --git a/.cursor/commands/session-summary.md b/.cursor/commands/session-summary.md
new file mode 100644
index 0000000..913fd02
--- /dev/null
+++ b/.cursor/commands/session-summary.md
@@ -0,0 +1,61 @@
+# Custom Command: Session Summary
+
+## Command Usage
+`/session-summary [notes]`
+
+Use optional `notes` to highlight areas you want analysed.
+
+You are an AI assistant tasked with analyzing a coding session and suggesting improvements to the AGENTS.md file. Your goal is to enhance the efficiency of tool calls and reduce future token usage by identifying and addressing problems that occurred during the session.
+
+First, review the current content of the AGENTS.md file:
+
+<agents_md_content>
+the current AGENTS.md content
+</agents_md_content>
+
+Now, examine the session history:
+
+<session_history>
+the full session history transcript
+</session_history>
+
+Analyze the session history and generate improvement suggestions for the AGENTS.md file. Focus on the following areas:
+1. Failed tool calls
+2. Repeated attempts to use non-existing tools or options
+3. Incorrect decisions leading to wasted tokens
+4. Attempts to write to files outside permitted directories
+5. Any other issues that resulted in inefficient token usage
+
+When creating suggestions, keep them small and concise. Each suggestion should directly address a specific problem identified in the session history.
+
+Format your suggestions as follows:
+1. Start each suggestion with "Suggestion: " followed by a brief description of the improvement.
+2. Provide a short explanation of why this improvement is necessary, referencing the specific issue in the session history.
+3. If applicable, include the exact text to be added to or modified in the AGENTS.md file.
+
+Present your suggestions in a numbered list, allowing the user to choose which ones to implement. For example:
+
+1. Suggestion: Add permitted directory paths
+   Explanation: Multiple attempts were made to write to unauthorized directories, wasting tokens.
+   Addition to AGENTS.md: "Permitted write directories: /project/data, /project/output"
+
+2. Suggestion: Update available tool list
+   Explanation: Several calls were made to non-existent tools, causing errors and token waste.
+   Modification in AGENTS.md: Replace "analyze_data" with "process_data" in the tools section.
+
+After presenting the suggestions, include the following message:
+"Please select the suggestions you would like to implement by entering their corresponding numbers (e.g., '1, 3, 4' or 'all'). I will then proceed with updating the AGENTS.md file accordingly."
+
+Once the user has made their selection, update the AGENTS.md file content with the chosen improvements. If the user selects "all", implement all suggestions.
+
+Your final output should be structured as follows:
+<analysis_results>
+[Numbered list of suggestions]
+[Selection prompt for the user]
+</analysis_results>
+
+<updated_agents_md>
+[Updated content of AGENTS.md after implementing selected suggestions]
+</updated_agents_md>
+
+Remember, your output should only include the content within the <analysis_results> and <updated_agents_md> tags. Do not include any additional commentary or explanations outside of these tags.
diff --git a/.cursor/commands/speckit.analyze.md b/.cursor/commands/speckit.analyze.md
new file mode 100644
index 0000000..1aded74
--- /dev/null
+++ b/.cursor/commands/speckit.analyze.md
@@ -0,0 +1,180 @@
+## User Input
+
+```text
+Use the user-provided arguments (if any) as contextual input
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Goal
+
+Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/tasks` has successfully produced a complete `tasks.md`.
+
+## Operating Constraints
+
+**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).
+
+**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/analyze`.
+
+## Execution Steps
+
+### 1. Initialize Analysis Context
+
+Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:
+
+- SPEC = FEATURE_DIR/spec.md
+- PLAN = FEATURE_DIR/plan.md
+- TASKS = FEATURE_DIR/tasks.md
+
+Abort with an error message if any required file is missing (instruct the user to run missing prerequisite command).
+For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+### 2. Load Artifacts (Progressive Disclosure)
+
+Load only the minimal necessary context from each artifact:
+
+**From spec.md:**
+
+- Overview/Context
+- Functional Requirements
+- Non-Functional Requirements
+- User Stories
+- Edge Cases (if present)
+
+**From plan.md:**
+
+- Architecture/stack choices
+- Data Model references
+- Phases
+- Technical constraints
+
+**From tasks.md:**
+
+- Task IDs
+- Descriptions
+- Phase grouping
+- Parallel markers [P]
+- Referenced file paths
+
+**From constitution:**
+
+- Load `.specify/memory/constitution.md` for principle validation
+
+### 3. Build Semantic Models
+
+Create internal representations (do not include raw artifacts in output):
+
+- **Requirements inventory**: Each functional + non-functional requirement with a stable key (derive slug based on imperative phrase; e.g., "User can upload file" → `user-can-upload-file`)
+- **User story/action inventory**: Discrete user actions with acceptance criteria
+- **Task coverage mapping**: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases)
+- **Constitution rule set**: Extract principle names and MUST/SHOULD normative statements
+
+### 4. Detection Passes (Token-Efficient Analysis)
+
+Focus on high-signal findings. Limit to 50 findings total; aggregate remainder in overflow summary.
+
+#### A. Duplication Detection
+
+- Identify near-duplicate requirements
+- Mark lower-quality phrasing for consolidation
+
+#### B. Ambiguity Detection
+
+- Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria
+- Flag unresolved placeholders (TODO, TKTK, ???, `<placeholder>`, etc.)
+
+#### C. Underspecification
+
+- Requirements with verbs but missing object or measurable outcome
+- User stories missing acceptance criteria alignment
+- Tasks referencing files or components not defined in spec/plan
+
+#### D. Constitution Alignment
+
+- Any requirement or plan element conflicting with a MUST principle
+- Missing mandated sections or quality gates from constitution
+
+#### E. Coverage Gaps
+
+- Requirements with zero associated tasks
+- Tasks with no mapped requirement/story
+- Non-functional requirements not reflected in tasks (e.g., performance, security)
+
+#### F. Inconsistency
+
+- Terminology drift (same concept named differently across files)
+- Data entities referenced in plan but absent in spec (or vice versa)
+- Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note)
+- Conflicting requirements (e.g., one requires Next.js while other specifies Vue)
+
+### 5. Severity Assignment
+
+Use this heuristic to prioritize findings:
+
+- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality
+- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion
+- **MEDIUM**: Terminology drift, missing non-functional task coverage, underspecified edge case
+- **LOW**: Style/wording improvements, minor redundancy not affecting execution order
+
+### 6. Produce Compact Analysis Report
+
+Output a Markdown report (no file writes) with the following structure:
+
+## Specification Analysis Report
+
+| ID | Category | Severity | Location(s) | Summary | Recommendation |
+|----|----------|----------|-------------|---------|----------------|
+| A1 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version |
+
+(Add one row per finding; generate stable IDs prefixed by category initial.)
+
+**Coverage Summary Table:**
+
+| Requirement Key | Has Task? | Task IDs | Notes |
+|-----------------|-----------|----------|-------|
+
+**Constitution Alignment Issues:** (if any)
+
+**Unmapped Tasks:** (if any)
+
+**Metrics:**
+
+- Total Requirements
+- Total Tasks
+- Coverage % (requirements with >=1 task)
+- Ambiguity Count
+- Duplication Count
+- Critical Issues Count
+
+### 7. Provide Next Actions
+
+At end of report, output a concise Next Actions block:
+
+- If CRITICAL issues exist: Recommend resolving before `/implement`
+- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
+- Provide explicit command suggestions: e.g., "Run /specify with refinement", "Run /plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'"
+
+### 8. Offer Remediation
+
+Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
+
+## Operating Principles
+
+### Context Efficiency
+
+- **Minimal high-signal tokens**: Focus on actionable findings, not exhaustive documentation
+- **Progressive disclosure**: Load artifacts incrementally; don't dump all content into analysis
+- **Token-efficient output**: Limit findings table to 50 rows; summarize overflow
+- **Deterministic results**: Rerunning without changes should produce consistent IDs and counts
+
+### Analysis Guidelines
+
+- **NEVER modify files** (this is read-only analysis)
+- **NEVER hallucinate missing sections** (if absent, report them accurately)
+- **Prioritize constitution violations** (these are always CRITICAL)
+- **Use examples over exhaustive rules** (cite specific instances, not generic patterns)
+- **Report zero issues gracefully** (emit success report with coverage statistics)
+
+## Context
+
+Use the user-provided arguments (if any) as contextual input
diff --git a/.cursor/commands/speckit.checklist.md b/.cursor/commands/speckit.checklist.md
new file mode 100644
index 0000000..574874b
--- /dev/null
+++ b/.cursor/commands/speckit.checklist.md
@@ -0,0 +1,283 @@
+## Checklist Purpose: "Unit Tests for English"
+
+**CRITICAL CONCEPT**: Checklists are **UNIT TESTS FOR REQUIREMENTS WRITING** - they validate the quality, clarity, and completeness of requirements in a given domain.
+
+**NOT for verification/testing**:
+- ❌ NOT "Verify the button clicks correctly"
+- ❌ NOT "Test error handling works"
+- ❌ NOT "Confirm the API returns 200"
+- ❌ NOT checking if code/implementation matches the spec
+
+**FOR requirements quality validation**:
+- ✅ "Are visual hierarchy requirements defined for all card types?" (completeness)
+- ✅ "Is 'prominent display' quantified with specific sizing/positioning?" (clarity)
+- ✅ "Are hover state requirements consistent across all interactive elements?" (consistency)
+- ✅ "Are accessibility requirements defined for keyboard navigation?" (coverage)
+- ✅ "Does the spec define what happens when logo image fails to load?" (edge cases)
+
+**Metaphor**: If your spec is code written in English, the checklist is its unit test suite. You're testing whether the requirements are well-written, complete, unambiguous, and ready for implementation - NOT whether the implementation works.
+
+## User Input
+
+```text
+Use the user-provided arguments (if any) as contextual input
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Execution Steps
+
+1. **Setup**: Run `.specify/scripts/bash/check-prerequisites.sh --json` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
+   - All file paths must be absolute.
+   - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. **Clarify intent (dynamic)**: Derive up to THREE initial contextual clarifying questions (no pre-baked catalog). They MUST:
+   - Be generated from the user's phrasing + extracted signals from spec/plan/tasks
+   - Only ask about information that materially changes checklist content
+   - Be skipped individually if already unambiguous in `Use the user-provided arguments (if any) as contextual input`
+   - Prefer precision over breadth
+
+   Generation algorithm:
+   1. Extract signals: feature domain keywords (e.g., auth, latency, UX, API), risk indicators ("critical", "must", "compliance"), stakeholder hints ("QA", "review", "security team"), and explicit deliverables ("a11y", "rollback", "contracts").
+   2. Cluster signals into candidate focus areas (max 4) ranked by relevance.
+   3. Identify probable audience & timing (author, reviewer, QA, release) if not explicit.
+   4. Detect missing dimensions: scope breadth, depth/rigor, risk emphasis, exclusion boundaries, measurable acceptance criteria.
+   5. Formulate questions chosen from these archetypes:
+      - Scope refinement (e.g., "Should this include integration touchpoints with X and Y or stay limited to local module correctness?")
+      - Risk prioritization (e.g., "Which of these potential risk areas should receive mandatory gating checks?")
+      - Depth calibration (e.g., "Is this a lightweight pre-commit sanity list or a formal release gate?")
+      - Audience framing (e.g., "Will this be used by the author only or peers during PR review?")
+      - Boundary exclusion (e.g., "Should we explicitly exclude performance tuning items this round?")
+      - Scenario class gap (e.g., "No recovery flows detected—are rollback / partial failure paths in scope?")
+
+   Question formatting rules:
+   - If presenting options, generate a compact table with columns: Option | Candidate | Why It Matters
+   - Limit to A–E options maximum; omit table if a free-form answer is clearer
+   - Never ask the user to restate what they already said
+   - Avoid speculative categories (no hallucination). If uncertain, ask explicitly: "Confirm whether X belongs in scope."
+
+   Defaults when interaction impossible:
+   - Depth: Standard
+   - Audience: Reviewer (PR) if code-related; Author otherwise
+   - Focus: Top 2 relevance clusters
+
+   Output the questions (label Q1/Q2/Q3). After answers: if ≥2 scenario classes (Alternate / Exception / Recovery / Non-Functional domain) remain unclear, you MAY ask up to TWO more targeted follow‑ups (Q4/Q5) with a one-line justification each (e.g., "Unresolved recovery path risk"). Do not exceed five total questions. Skip escalation if user explicitly declines more.
+
+3. **Understand user request**: Combine `Use the user-provided arguments (if any) as contextual input` + clarifying answers:
+   - Derive checklist theme (e.g., security, review, deploy, ux)
+   - Consolidate explicit must-have items mentioned by user
+   - Map focus selections to category scaffolding
+   - Infer any missing context from spec/plan/tasks (do NOT hallucinate)
+
+4. **Load feature context**: Read from FEATURE_DIR:
+   - spec.md: Feature requirements and scope
+   - plan.md (if exists): Technical details, dependencies
+   - tasks.md (if exists): Implementation tasks
+   
+   **Context Loading Strategy**:
+   - Load only necessary portions relevant to active focus areas (avoid full-file dumping)
+   - Prefer summarizing long sections into concise scenario/requirement bullets
+   - Use progressive disclosure: add follow-on retrieval only if gaps detected
+   - If source docs are large, generate interim summary items instead of embedding raw text
+
+5. **Generate checklist** - Create "Unit Tests for Requirements":
+   - Create `FEATURE_DIR/checklists/` directory if it doesn't exist
+   - Generate unique checklist filename:
+     - Use short, descriptive name based on domain (e.g., `ux.md`, `api.md`, `security.md`)
+     - Format: `[domain].md` 
+     - If file exists, append to existing file
+   - Number items sequentially starting from CHK001
+   - Each `/speckit.checklist` run creates a NEW file (never overwrites existing checklists)
+
+   **CORE PRINCIPLE - Test the Requirements, Not the Implementation**:
+   Every checklist item MUST evaluate the REQUIREMENTS THEMSELVES for:
+   - **Completeness**: Are all necessary requirements present?
+   - **Clarity**: Are requirements unambiguous and specific?
+   - **Consistency**: Do requirements align with each other?
+   - **Measurability**: Can requirements be objectively verified?
+   - **Coverage**: Are all scenarios/edge cases addressed?
+   
+   **Category Structure** - Group items by requirement quality dimensions:
+   - **Requirement Completeness** (Are all necessary requirements documented?)
+   - **Requirement Clarity** (Are requirements specific and unambiguous?)
+   - **Requirement Consistency** (Do requirements align without conflicts?)
+   - **Acceptance Criteria Quality** (Are success criteria measurable?)
+   - **Scenario Coverage** (Are all flows/cases addressed?)
+   - **Edge Case Coverage** (Are boundary conditions defined?)
+   - **Non-Functional Requirements** (Performance, Security, Accessibility, etc. - are they specified?)
+   - **Dependencies & Assumptions** (Are they documented and validated?)
+   - **Ambiguities & Conflicts** (What needs clarification?)
+   
+   **HOW TO WRITE CHECKLIST ITEMS - "Unit Tests for English"**:
+   
+   ❌ **WRONG** (Testing implementation):
+   - "Verify landing page displays 3 episode cards"
+   - "Test hover states work on desktop"
+   - "Confirm logo click navigates home"
+   
+   ✅ **CORRECT** (Testing requirements quality):
+   - "Are the exact number and layout of featured episodes specified?" [Completeness]
+   - "Is 'prominent display' quantified with specific sizing/positioning?" [Clarity]
+   - "Are hover state requirements consistent across all interactive elements?" [Consistency]
+   - "Are keyboard navigation requirements defined for all interactive UI?" [Coverage]
+   - "Is the fallback behavior specified when logo image fails to load?" [Edge Cases]
+   - "Are loading states defined for asynchronous episode data?" [Completeness]
+   - "Does the spec define visual hierarchy for competing UI elements?" [Clarity]
+   
+   **ITEM STRUCTURE**:
+   Each item should follow this pattern:
+   - Question format asking about requirement quality
+   - Focus on what's WRITTEN (or not written) in the spec/plan
+   - Include quality dimension in brackets [Completeness/Clarity/Consistency/etc.]
+   - Reference spec section `[Spec §X.Y]` when checking existing requirements
+   - Use `[Gap]` marker when checking for missing requirements
+   
+   **EXAMPLES BY QUALITY DIMENSION**:
+   
+   Completeness:
+   - "Are error handling requirements defined for all API failure modes? [Gap]"
+   - "Are accessibility requirements specified for all interactive elements? [Completeness]"
+   - "Are mobile breakpoint requirements defined for responsive layouts? [Gap]"
+   
+   Clarity:
+   - "Is 'fast loading' quantified with specific timing thresholds? [Clarity, Spec §NFR-2]"
+   - "Are 'related episodes' selection criteria explicitly defined? [Clarity, Spec §FR-5]"
+   - "Is 'prominent' defined with measurable visual properties? [Ambiguity, Spec §FR-4]"
+   
+   Consistency:
+   - "Do navigation requirements align across all pages? [Consistency, Spec §FR-10]"
+   - "Are card component requirements consistent between landing and detail pages? [Consistency]"
+   
+   Coverage:
+   - "Are requirements defined for zero-state scenarios (no episodes)? [Coverage, Edge Case]"
+   - "Are concurrent user interaction scenarios addressed? [Coverage, Gap]"
+   - "Are requirements specified for partial data loading failures? [Coverage, Exception Flow]"
+   
+   Measurability:
+   - "Are visual hierarchy requirements measurable/testable? [Acceptance Criteria, Spec §FR-1]"
+   - "Can 'balanced visual weight' be objectively verified? [Measurability, Spec §FR-2]"
+
+   **Scenario Classification & Coverage** (Requirements Quality Focus):
+   - Check if requirements exist for: Primary, Alternate, Exception/Error, Recovery, Non-Functional scenarios
+   - For each scenario class, ask: "Are [scenario type] requirements complete, clear, and consistent?"
+   - If scenario class missing: "Are [scenario type] requirements intentionally excluded or missing? [Gap]"
+   - Include resilience/rollback when state mutation occurs: "Are rollback requirements defined for migration failures? [Gap]"
+
+   **Traceability Requirements**:
+   - MINIMUM: ≥80% of items MUST include at least one traceability reference
+   - Each item should reference: spec section `[Spec §X.Y]`, or use markers: `[Gap]`, `[Ambiguity]`, `[Conflict]`, `[Assumption]`
+   - If no ID system exists: "Is a requirement & acceptance criteria ID scheme established? [Traceability]"
+
+   **Surface & Resolve Issues** (Requirements Quality Problems):
+   Ask questions about the requirements themselves:
+   - Ambiguities: "Is the term 'fast' quantified with specific metrics? [Ambiguity, Spec §NFR-1]"
+   - Conflicts: "Do navigation requirements conflict between §FR-10 and §FR-10a? [Conflict]"
+   - Assumptions: "Is the assumption of 'always available podcast API' validated? [Assumption]"
+   - Dependencies: "Are external podcast API requirements documented? [Dependency, Gap]"
+   - Missing definitions: "Is 'visual hierarchy' defined with measurable criteria? [Gap]"
+
+   **Content Consolidation**:
+   - Soft cap: If raw candidate items > 40, prioritize by risk/impact
+   - Merge near-duplicates checking the same requirement aspect
+   - If >5 low-impact edge cases, create one item: "Are edge cases X, Y, Z addressed in requirements? [Coverage]"
+
+   **🚫 ABSOLUTELY PROHIBITED** - These make it an implementation test, not a requirements test:
+   - ❌ Any item starting with "Verify", "Test", "Confirm", "Check" + implementation behavior
+   - ❌ References to code execution, user actions, system behavior
+   - ❌ "Displays correctly", "works properly", "functions as expected"
+   - ❌ "Click", "navigate", "render", "load", "execute"
+   - ❌ Test cases, test plans, QA procedures
+   - ❌ Implementation details (frameworks, APIs, algorithms)
+   
+   **✅ REQUIRED PATTERNS** - These test requirements quality:
+   - ✅ "Are [requirement type] defined/specified/documented for [scenario]?"
+   - ✅ "Is [vague term] quantified/clarified with specific criteria?"
+   - ✅ "Are requirements consistent between [section A] and [section B]?"
+   - ✅ "Can [requirement] be objectively measured/verified?"
+   - ✅ "Are [edge cases/scenarios] addressed in requirements?"
+   - ✅ "Does the spec define [missing aspect]?"
+
+6. **Structure Reference**: Generate the checklist following the canonical template in `.specify/templates/checklist-template.md` for title, meta section, category headings, and ID formatting. If template is unavailable, use: H1 title, purpose/created meta lines, `##` category sections containing `- [ ] CHK### <requirement item>` lines with globally incrementing IDs starting at CHK001.
+
+7. **Report**: Output full path to created checklist, item count, and remind user that each run creates a new file. Summarize:
+   - Focus areas selected
+   - Depth level
+   - Actor/timing
+   - Any explicit user-specified must-have items incorporated
+
+**Important**: Each `/speckit.checklist` command invocation creates a checklist file using short, descriptive names unless file already exists. This allows:
+
+- Multiple checklists of different types (e.g., `ux.md`, `test.md`, `security.md`)
+- Simple, memorable filenames that indicate checklist purpose
+- Easy identification and navigation in the `checklists/` folder
+
+To avoid clutter, use descriptive types and clean up obsolete checklists when done.
+
+## Example Checklist Types & Sample Items
+
+**UX Requirements Quality:** `ux.md`
+
+Sample items (testing the requirements, NOT the implementation):
+- "Are visual hierarchy requirements defined with measurable criteria? [Clarity, Spec §FR-1]"
+- "Is the number and positioning of UI elements explicitly specified? [Completeness, Spec §FR-1]"
+- "Are interaction state requirements (hover, focus, active) consistently defined? [Consistency]"
+- "Are accessibility requirements specified for all interactive elements? [Coverage, Gap]"
+- "Is fallback behavior defined when images fail to load? [Edge Case, Gap]"
+- "Can 'prominent display' be objectively measured? [Measurability, Spec §FR-4]"
+
+**API Requirements Quality:** `api.md`
+
+Sample items:
+- "Are error response formats specified for all failure scenarios? [Completeness]"
+- "Are rate limiting requirements quantified with specific thresholds? [Clarity]"
+- "Are authentication requirements consistent across all endpoints? [Consistency]"
+- "Are retry/timeout requirements defined for external dependencies? [Coverage, Gap]"
+- "Is versioning strategy documented in requirements? [Gap]"
+
+**Performance Requirements Quality:** `performance.md`
+
+Sample items:
+- "Are performance requirements quantified with specific metrics? [Clarity]"
+- "Are performance targets defined for all critical user journeys? [Coverage]"
+- "Are performance requirements under different load conditions specified? [Completeness]"
+- "Can performance requirements be objectively measured? [Measurability]"
+- "Are degradation requirements defined for high-load scenarios? [Edge Case, Gap]"
+
+**Security Requirements Quality:** `security.md`
+
+Sample items:
+- "Are authentication requirements specified for all protected resources? [Coverage]"
+- "Are data protection requirements defined for sensitive information? [Completeness]"
+- "Is the threat model documented and requirements aligned to it? [Traceability]"
+- "Are security requirements consistent with compliance obligations? [Consistency]"
+- "Are security failure/breach response requirements defined? [Gap, Exception Flow]"
+
+## Anti-Examples: What NOT To Do
+
+**❌ WRONG - These test implementation, not requirements:**
+
+```markdown
+- [ ] CHK001 - Verify landing page displays 3 episode cards [Spec §FR-001]
+- [ ] CHK002 - Test hover states work correctly on desktop [Spec §FR-003]
+- [ ] CHK003 - Confirm logo click navigates to home page [Spec §FR-010]
+- [ ] CHK004 - Check that related episodes section shows 3-5 items [Spec §FR-005]
+```
+
+**✅ CORRECT - These test requirements quality:**
+
+```markdown
+- [ ] CHK001 - Are the number and layout of featured episodes explicitly specified? [Completeness, Spec §FR-001]
+- [ ] CHK002 - Are hover state requirements consistently defined for all interactive elements? [Consistency, Spec §FR-003]
+- [ ] CHK003 - Are navigation requirements clear for all clickable brand elements? [Clarity, Spec §FR-010]
+- [ ] CHK004 - Is the selection criteria for related episodes documented? [Gap, Spec §FR-005]
+- [ ] CHK005 - Are loading state requirements defined for asynchronous episode data? [Gap]
+- [ ] CHK006 - Can "visual hierarchy" requirements be objectively measured? [Measurability, Spec §FR-001]
+```
+
+**Key Differences:**
+- Wrong: Tests if the system works correctly
+- Correct: Tests if the requirements are written correctly
+- Wrong: Verification of behavior
+- Correct: Validation of requirement quality
+- Wrong: "Does it do X?" 
+- Correct: "Is X clearly specified?"
diff --git a/.cursor/commands/speckit.clarify.md b/.cursor/commands/speckit.clarify.md
new file mode 100644
index 0000000..9ec41c2
--- /dev/null
+++ b/.cursor/commands/speckit.clarify.md
@@ -0,0 +1,172 @@
+## User Input
+
+```text
+Use the user-provided arguments (if any) as contextual input
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.
+
+Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/speckit.plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.
+
+Execution steps:
+
+1. Run `.specify/scripts/bash/check-prerequisites.sh --json --paths-only` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields:
+   - `FEATURE_DIR`
+   - `FEATURE_SPEC`
+   - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)
+   - If JSON parsing fails, abort and instruct user to re-run `/speckit.specify` or verify feature branch environment.
+   - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked).
+
+   Functional Scope & Behavior:
+   - Core user goals & success criteria
+   - Explicit out-of-scope declarations
+   - User roles / personas differentiation
+
+   Domain & Data Model:
+   - Entities, attributes, relationships
+   - Identity & uniqueness rules
+   - Lifecycle/state transitions
+   - Data volume / scale assumptions
+
+   Interaction & UX Flow:
+   - Critical user journeys / sequences
+   - Error/empty/loading states
+   - Accessibility or localization notes
+
+   Non-Functional Quality Attributes:
+   - Performance (latency, throughput targets)
+   - Scalability (horizontal/vertical, limits)
+   - Reliability & availability (uptime, recovery expectations)
+   - Observability (logging, metrics, tracing signals)
+   - Security & privacy (authN/Z, data protection, threat assumptions)
+   - Compliance / regulatory constraints (if any)
+
+   Integration & External Dependencies:
+   - External services/APIs and failure modes
+   - Data import/export formats
+   - Protocol/versioning assumptions
+
+   Edge Cases & Failure Handling:
+   - Negative scenarios
+   - Rate limiting / throttling
+   - Conflict resolution (e.g., concurrent edits)
+
+   Constraints & Tradeoffs:
+   - Technical constraints (language, storage, hosting)
+   - Explicit tradeoffs or rejected alternatives
+
+   Terminology & Consistency:
+   - Canonical glossary terms
+   - Avoided synonyms / deprecated terms
+
+   Completion Signals:
+   - Acceptance criteria testability
+   - Measurable Definition of Done style indicators
+
+   Misc / Placeholders:
+   - TODO markers / unresolved decisions
+   - Ambiguous adjectives ("robust", "intuitive") lacking quantification
+
+   For each category with Partial or Missing status, add a candidate question opportunity unless:
+   - Clarification would not materially change implementation or validation strategy
+   - Information is better deferred to planning phase (note internally)
+
+3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints:
+    - Maximum of 10 total questions across the whole session.
+    - Each question must be answerable with EITHER:
+       * A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR
+       * A one-word / short‑phrase answer (explicitly constrain: "Answer in <=5 words").
+   - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.
+   - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved.
+   - Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness).
+   - Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests.
+   - If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic.
+
+4. Sequential questioning loop (interactive):
+    - Present EXACTLY ONE question at a time.
+    - For multiple‑choice questions:
+       * **Analyze all options** and determine the **most suitable option** based on:
+          - Best practices for the project type
+          - Common patterns in similar implementations
+          - Risk reduction (security, performance, maintainability)
+          - Alignment with any explicit project goals or constraints visible in the spec
+       * Present your **recommended option prominently** at the top with clear reasoning (1-2 sentences explaining why this is the best choice).
+       * Format as: `**Recommended:** Option [X] - <reasoning>`
+       * Then render all options as a Markdown table:
+
+       | Option | Description |
+       |--------|-------------|
+       | A | <Option A description> |
+       | B | <Option B description> |
+       | C | <Option C description> | (add D/E as needed up to 5)
+       | Short | Provide a different short answer (<=5 words) | (Include only if free-form alternative is appropriate)
+
+       * After the table, add: `You can reply with the option letter (e.g., "A"), accept the recommendation by saying "yes" or "recommended", or provide your own short answer.`
+    - For short‑answer style (no meaningful discrete options):
+       * Provide your **suggested answer** based on best practices and context.
+       * Format as: `**Suggested:** <your proposed answer> - <brief reasoning>`
+       * Then output: `Format: Short answer (<=5 words). You can accept the suggestion by saying "yes" or "suggested", or provide your own answer.`
+    - After the user answers:
+       * If the user replies with "yes", "recommended", or "suggested", use your previously stated recommendation/suggestion as the answer.
+       * Otherwise, validate the answer maps to one option or fits the <=5 word constraint.
+       * If ambiguous, ask for a quick disambiguation (count still belongs to same question; do not advance).
+       * Once satisfactory, record it in working memory (do not yet write to disk) and move to the next queued question.
+    - Stop asking further questions when:
+       * All critical ambiguities resolved early (remaining queued items become unnecessary), OR
+       * User signals completion ("done", "good", "no more"), OR
+       * You reach 5 asked questions.
+    - Never reveal future queued questions in advance.
+    - If no valid questions exist at start, immediately report no critical ambiguities.
+
+5. Integration after EACH accepted answer (incremental update approach):
+    - Maintain in-memory representation of the spec (loaded once at start) plus the raw file contents.
+    - For the first integrated answer in this session:
+       * Ensure a `## Clarifications` section exists (create it just after the highest-level contextual/overview section per the spec template if missing).
+       * Under it, create (if not present) a `### Session YYYY-MM-DD` subheading for today.
+    - Append a bullet line immediately after acceptance: `- Q: <question> → A: <final answer>`.
+    - Then immediately apply the clarification to the most appropriate section(s):
+       * Functional ambiguity → Update or add a bullet in Functional Requirements.
+       * User interaction / actor distinction → Update User Stories or Actors subsection (if present) with clarified role, constraint, or scenario.
+       * Data shape / entities → Update Data Model (add fields, types, relationships) preserving ordering; note added constraints succinctly.
+       * Non-functional constraint → Add/modify measurable criteria in Non-Functional / Quality Attributes section (convert vague adjective to metric or explicit target).
+       * Edge case / negative flow → Add a new bullet under Edge Cases / Error Handling (or create such subsection if template provides placeholder for it).
+       * Terminology conflict → Normalize term across spec; retain original only if necessary by adding `(formerly referred to as "X")` once.
+    - If the clarification invalidates an earlier ambiguous statement, replace that statement instead of duplicating; leave no obsolete contradictory text.
+    - Save the spec file AFTER each integration to minimize risk of context loss (atomic overwrite).
+    - Preserve formatting: do not reorder unrelated sections; keep heading hierarchy intact.
+    - Keep each inserted clarification minimal and testable (avoid narrative drift).
+
+6. Validation (performed after EACH write plus final pass):
+   - Clarifications session contains exactly one bullet per accepted answer (no duplicates).
+   - Total asked (accepted) questions ≤ 5.
+   - Updated sections contain no lingering vague placeholders the new answer was meant to resolve.
+   - No contradictory earlier statement remains (scan for now-invalid alternative choices removed).
+   - Markdown structure valid; only allowed new headings: `## Clarifications`, `### Session YYYY-MM-DD`.
+   - Terminology consistency: same canonical term used across all updated sections.
+
+7. Write the updated spec back to `FEATURE_SPEC`.
+
+8. Report completion (after questioning loop ends or early termination):
+   - Number of questions asked & answered.
+   - Path to updated spec.
+   - Sections touched (list names).
+   - Coverage summary table listing each taxonomy category with Status: Resolved (was Partial/Missing and addressed), Deferred (exceeds question quota or better suited for planning), Clear (already sufficient), Outstanding (still Partial/Missing but low impact).
+   - If any Outstanding or Deferred remain, recommend whether to proceed to `/speckit.plan` or run `/speckit.clarify` again later post-plan.
+   - Suggested next command.
+
+Behavior rules:
+- If no meaningful ambiguities found (or all potential questions would be low-impact), respond: "No critical ambiguities detected worth formal clarification." and suggest proceeding.
+- If spec file missing, instruct user to run `/speckit.specify` first (do not create a new spec here).
+- Never exceed 5 total asked questions (clarification retries for a single question do not count as new questions).
+- Avoid speculative tech stack questions unless the absence blocks functional clarity.
+- Respect user early termination signals ("stop", "done", "proceed").
+ - If no questions asked due to full coverage, output a compact coverage summary (all categories Clear) then suggest advancing.
+ - If quota reached with unresolved high-impact categories remaining, explicitly flag them under Deferred with rationale.
+
+Context for prioritization: Use the user-provided arguments (if any) as contextual input
diff --git a/.cursor/commands/speckit.constitution.md b/.cursor/commands/speckit.constitution.md
new file mode 100644
index 0000000..1be89c7
--- /dev/null
+++ b/.cursor/commands/speckit.constitution.md
@@ -0,0 +1,73 @@
+## User Input
+
+```text
+Use the user-provided arguments (if any) as contextual input
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+You are updating the project constitution at `.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
+
+Follow this execution flow:
+
+1. Load the existing constitution template at `.specify/memory/constitution.md`.
+   - Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
+   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
+
+2. Collect/derive values for placeholders:
+   - If user input (conversation) supplies a value, use it.
+   - Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
+   - For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
+   - `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
+     * MAJOR: Backward incompatible governance/principle removals or redefinitions.
+     * MINOR: New principle/section added or materially expanded guidance.
+     * PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
+   - If version bump type ambiguous, propose reasoning before finalizing.
+
+3. Draft the updated constitution content:
+   - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
+   - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
+   - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
+   - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
+
+4. Consistency propagation checklist (convert prior checklist into active validations):
+   - Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
+   - Read `.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
+   - Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
+   - Read each command file in `.specify/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
+   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
+
+5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
+   - Version change: old → new
+   - List of modified principles (old title → new title if renamed)
+   - Added sections
+   - Removed sections
+   - Templates requiring updates (✅ updated / ⚠ pending) with file paths
+   - Follow-up TODOs if any placeholders intentionally deferred.
+
+6. Validation before final output:
+   - No remaining unexplained bracket tokens.
+   - Version line matches report.
+   - Dates ISO format YYYY-MM-DD.
+   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
+
+7. Write the completed constitution back to `.specify/memory/constitution.md` (overwrite).
+
+8. Output a final summary to the user with:
+   - New version and bump rationale.
+   - Any files flagged for manual follow-up.
+   - Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
+
+Formatting & Style Requirements:
+- Use Markdown headings exactly as in the template (do not demote/promote levels).
+- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
+- Keep a single blank line between sections.
+- Avoid trailing whitespace.
+
+If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
+
+If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
+
+Do not create a new template; always operate on the existing `.specify/memory/constitution.md` file.
diff --git a/.cursor/commands/speckit.implement.md b/.cursor/commands/speckit.implement.md
new file mode 100644
index 0000000..c0530c7
--- /dev/null
+++ b/.cursor/commands/speckit.implement.md
@@ -0,0 +1,118 @@
+## User Input
+
+```text
+Use the user-provided arguments (if any) as contextual input
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+1. Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. **Check checklists status** (if FEATURE_DIR/checklists/ exists):
+   - Scan all checklist files in the checklists/ directory
+   - For each checklist, count:
+     * Total items: All lines matching `- [ ]` or `- [X]` or `- [x]`
+     * Completed items: Lines matching `- [X]` or `- [x]`
+     * Incomplete items: Lines matching `- [ ]`
+   - Create a status table:
+     ```
+     | Checklist | Total | Completed | Incomplete | Status |
+     |-----------|-------|-----------|------------|--------|
+     | ux.md     | 12    | 12        | 0          | ✓ PASS |
+     | test.md   | 8     | 5         | 3          | ✗ FAIL |
+     | security.md | 6   | 6         | 0          | ✓ PASS |
+     ```
+   - Calculate overall status:
+     * **PASS**: All checklists have 0 incomplete items
+     * **FAIL**: One or more checklists have incomplete items
+   
+   - **If any checklist is incomplete**:
+     * Display the table with incomplete item counts
+     * **STOP** and ask: "Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes/no)"
+     * Wait for user response before continuing
+     * If user says "no" or "wait" or "stop", halt execution
+     * If user says "yes" or "proceed" or "continue", proceed to step 3
+   
+   - **If all checklists are complete**:
+     * Display the table showing all checklists passed
+     * Automatically proceed to step 3
+
+3. Load and analyze the implementation context:
+   - **REQUIRED**: Read tasks.md for the complete task list and execution plan
+   - **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
+   - **IF EXISTS**: Read data-model.md for entities and relationships
+   - **IF EXISTS**: Read contracts/ for API specifications and test requirements
+   - **IF EXISTS**: Read research.md for technical decisions and constraints
+   - **IF EXISTS**: Read quickstart.md for integration scenarios
+
+4. **Project Setup Verification**:
+   - **REQUIRED**: Create/verify ignore files based on actual project setup:
+   
+   **Detection & Creation Logic**:
+   - Check if the following command succeeds to determine if the repository is a git repo (create/verify .gitignore if so):
+
+     ```sh
+     git rev-parse --git-dir 2>/dev/null
+     ```
+   - Check if Dockerfile* exists or Docker in plan.md → create/verify .dockerignore
+   - Check if .eslintrc* or eslint.config.* exists → create/verify .eslintignore
+   - Check if .prettierrc* exists → create/verify .prettierignore
+   - Check if .npmrc or package.json exists → create/verify .npmignore (if publishing)
+   - Check if terraform files (*.tf) exist → create/verify .terraformignore
+   - Check if .helmignore needed (helm charts present) → create/verify .helmignore
+   
+   **If ignore file already exists**: Verify it contains essential patterns, append missing critical patterns only
+   **If ignore file missing**: Create with full pattern set for detected technology
+   
+   **Common Patterns by Technology** (from plan.md tech stack):
+   - **Node.js/JavaScript**: `node_modules/`, `dist/`, `build/`, `*.log`, `.env*`
+   - **Python**: `__pycache__/`, `*.pyc`, `.venv/`, `venv/`, `dist/`, `*.egg-info/`
+   - **Java**: `target/`, `*.class`, `*.jar`, `.gradle/`, `build/`
+   - **C#/.NET**: `bin/`, `obj/`, `*.user`, `*.suo`, `packages/`
+   - **Go**: `*.exe`, `*.test`, `vendor/`, `*.out`
+   - **Universal**: `.DS_Store`, `Thumbs.db`, `*.tmp`, `*.swp`, `.vscode/`, `.idea/`
+   
+   **Tool-Specific Patterns**:
+   - **Docker**: `node_modules/`, `.git/`, `Dockerfile*`, `.dockerignore`, `*.log*`, `.env*`, `coverage/`
+   - **ESLint**: `node_modules/`, `dist/`, `build/`, `coverage/`, `*.min.js`
+   - **Prettier**: `node_modules/`, `dist/`, `build/`, `coverage/`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`
+   - **Terraform**: `.terraform/`, `*.tfstate*`, `*.tfvars`, `.terraform.lock.hcl`
+
+5. Parse tasks.md structure and extract:
+   - **Task phases**: Setup, Tests, Core, Integration, Polish
+   - **Task dependencies**: Sequential vs parallel execution rules
+   - **Task details**: ID, description, file paths, parallel markers [P]
+   - **Execution flow**: Order and dependency requirements
+
+6. Execute implementation following the task plan:
+   - **Phase-by-phase execution**: Complete each phase before moving to the next
+   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together  
+   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
+   - **File-based coordination**: Tasks affecting the same files must run sequentially
+   - **Validation checkpoints**: Verify each phase completion before proceeding
+
+7. Implementation execution rules:
+   - **Setup first**: Initialize project structure, dependencies, configuration
+   - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
+   - **Core development**: Implement models, services, CLI commands, endpoints
+   - **Integration work**: Database connections, middleware, logging, external services
+   - **Polish and validation**: Unit tests, performance optimization, documentation
+
+8. Progress tracking and error handling:
+   - Report progress after each completed task
+   - Halt execution if any non-parallel task fails
+   - For parallel tasks [P], continue with successful tasks, report failed ones
+   - Provide clear error messages with context for debugging
+   - Suggest next steps if implementation cannot proceed
+   - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.
+
+9. Completion validation:
+   - Verify all required tasks are completed
+   - Check that implemented features match the original specification
+   - Validate that tests pass and coverage meets requirements
+   - Confirm the implementation follows the technical plan
+   - Report final status with summary of completed work
+
+Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/tasks` first to regenerate the task list.
diff --git a/.cursor/commands/speckit.plan.md b/.cursor/commands/speckit.plan.md
new file mode 100644
index 0000000..a4839f4
--- /dev/null
+++ b/.cursor/commands/speckit.plan.md
@@ -0,0 +1,76 @@
+## User Input
+
+```text
+Use the user-provided arguments (if any) as contextual input
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+1. **Setup**: Run `.specify/scripts/bash/setup-plan.sh --json` from repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. **Load context**: Read FEATURE_SPEC and `.specify/memory/constitution.md`. Load IMPL_PLAN template (already copied).
+
+3. **Execute plan workflow**: Follow the structure in IMPL_PLAN template to:
+   - Fill Technical Context (mark unknowns as "NEEDS CLARIFICATION")
+   - Fill Constitution Check section from constitution
+   - Evaluate gates (ERROR if violations unjustified)
+   - Phase 0: Generate research.md (resolve all NEEDS CLARIFICATION)
+   - Phase 1: Generate data-model.md, contracts/, quickstart.md
+   - Phase 1: Update agent context by running the agent script
+   - Re-evaluate Constitution Check post-design
+
+4. **Stop and report**: Command ends after Phase 2 planning. Report branch, IMPL_PLAN path, and generated artifacts.
+
+## Phases
+
+### Phase 0: Outline & Research
+
+1. **Extract unknowns from Technical Context** above:
+   - For each NEEDS CLARIFICATION → research task
+   - For each dependency → best practices task
+   - For each integration → patterns task
+
+2. **Generate and dispatch research agents**:
+   ```
+   For each unknown in Technical Context:
+     Task: "Research {unknown} for {feature context}"
+   For each technology choice:
+     Task: "Find best practices for {tech} in {domain}"
+   ```
+
+3. **Consolidate findings** in `research.md` using format:
+   - Decision: [what was chosen]
+   - Rationale: [why chosen]
+   - Alternatives considered: [what else evaluated]
+
+**Output**: research.md with all NEEDS CLARIFICATION resolved
+
+### Phase 1: Design & Contracts
+
+**Prerequisites:** `research.md` complete
+
+1. **Extract entities from feature spec** → `data-model.md`:
+   - Entity name, fields, relationships
+   - Validation rules from requirements
+   - State transitions if applicable
+
+2. **Generate API contracts** from functional requirements:
+   - For each user action → endpoint
+   - Use standard REST/GraphQL patterns
+   - Output OpenAPI/GraphQL schema to `/contracts/`
+
+3. **Agent context update**:
+   - Run `.specify/scripts/bash/update-agent-context.sh codex`
+   - These scripts detect which AI agent is in use
+   - Update the appropriate agent-specific context file
+   - Add only new technology from current plan
+   - Preserve manual additions between markers
+
+**Output**: data-model.md, /contracts/*, quickstart.md, agent-specific file
+
+## Key rules
+
+- Use absolute paths
+- ERROR on gate failures or unresolved clarifications
diff --git a/.cursor/commands/speckit.specify.md b/.cursor/commands/speckit.specify.md
new file mode 100644
index 0000000..9215c12
--- /dev/null
+++ b/.cursor/commands/speckit.specify.md
@@ -0,0 +1,204 @@
+## User Input
+
+```text
+Use the user-provided arguments (if any) as contextual input
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+The text the user typed after `/speckit.specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `Use the user-provided arguments (if any) as contextual input` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
+
+Given that feature description, do this:
+
+1. Run the script `.specify/scripts/bash/create-new-feature.sh --json "Use the user-provided arguments (if any) as contextual input"` from repo root and parse its JSON output for BRANCH_NAME and SPEC_FILE. All file paths must be absolute.
+  **IMPORTANT** You must only ever run this script once. The JSON is provided in the terminal as output - always refer to it to get the actual content you're looking for. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+2. Load `.specify/templates/spec-template.md` to understand required sections.
+
+3. Follow this execution flow:
+
+    1. Parse user description from Input
+       If empty: ERROR "No feature description provided"
+    2. Extract key concepts from description
+       Identify: actors, actions, data, constraints
+    3. For unclear aspects:
+       - Make informed guesses based on context and industry standards
+       - Only mark with [NEEDS CLARIFICATION: specific question] if:
+         - The choice significantly impacts feature scope or user experience
+         - Multiple reasonable interpretations exist with different implications
+         - No reasonable default exists
+       - **LIMIT: Maximum 3 [NEEDS CLARIFICATION] markers total**
+       - Prioritize clarifications by impact: scope > security/privacy > user experience > technical details
+    4. Fill User Scenarios & Testing section
+       If no clear user flow: ERROR "Cannot determine user scenarios"
+    5. Generate Functional Requirements
+       Each requirement must be testable
+       Use reasonable defaults for unspecified details (document assumptions in Assumptions section)
+    6. Define Success Criteria
+       Create measurable, technology-agnostic outcomes
+       Include both quantitative metrics (time, performance, volume) and qualitative measures (user satisfaction, task completion)
+       Each criterion must be verifiable without implementation details
+    7. Identify Key Entities (if data involved)
+    8. Return: SUCCESS (spec ready for planning)
+
+4. Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings.
+
+5. **Specification Quality Validation**: After writing the initial spec, validate it against quality criteria:
+
+   a. **Create Spec Quality Checklist**: Generate a checklist file at `FEATURE_DIR/checklists/requirements.md` using the checklist template structure with these validation items:
+   
+      ```markdown
+      # Specification Quality Checklist: [FEATURE NAME]
+      
+      **Purpose**: Validate specification completeness and quality before proceeding to planning
+      **Created**: [DATE]
+      **Feature**: [Link to spec.md]
+      
+      ## Content Quality
+      
+      - [ ] No implementation details (languages, frameworks, APIs)
+      - [ ] Focused on user value and business needs
+      - [ ] Written for non-technical stakeholders
+      - [ ] All mandatory sections completed
+      
+      ## Requirement Completeness
+      
+      - [ ] No [NEEDS CLARIFICATION] markers remain
+      - [ ] Requirements are testable and unambiguous
+      - [ ] Success criteria are measurable
+      - [ ] Success criteria are technology-agnostic (no implementation details)
+      - [ ] All acceptance scenarios are defined
+      - [ ] Edge cases are identified
+      - [ ] Scope is clearly bounded
+      - [ ] Dependencies and assumptions identified
+      
+      ## Feature Readiness
+      
+      - [ ] All functional requirements have clear acceptance criteria
+      - [ ] User scenarios cover primary flows
+      - [ ] Feature meets measurable outcomes defined in Success Criteria
+      - [ ] No implementation details leak into specification
+      
+      ## Notes
+      
+      - Items marked incomplete require spec updates before `/speckit.clarify` or `/speckit.plan`
+      ```
+   
+   b. **Run Validation Check**: Review the spec against each checklist item:
+      - For each item, determine if it passes or fails
+      - Document specific issues found (quote relevant spec sections)
+   
+   c. **Handle Validation Results**:
+      
+      - **If all items pass**: Mark checklist complete and proceed to step 6
+      
+      - **If items fail (excluding [NEEDS CLARIFICATION])**:
+        1. List the failing items and specific issues
+        2. Update the spec to address each issue
+        3. Re-run validation until all items pass (max 3 iterations)
+        4. If still failing after 3 iterations, document remaining issues in checklist notes and warn user
+      
+      - **If [NEEDS CLARIFICATION] markers remain**:
+        1. Extract all [NEEDS CLARIFICATION: ...] markers from the spec
+        2. **LIMIT CHECK**: If more than 3 markers exist, keep only the 3 most critical (by scope/security/UX impact) and make informed guesses for the rest
+        3. For each clarification needed (max 3), present options to user in this format:
+        
+           ```markdown
+           ## Question [N]: [Topic]
+           
+           **Context**: [Quote relevant spec section]
+           
+           **What we need to know**: [Specific question from NEEDS CLARIFICATION marker]
+           
+           **Suggested Answers**:
+           
+           | Option | Answer | Implications |
+           |--------|--------|--------------|
+           | A      | [First suggested answer] | [What this means for the feature] |
+           | B      | [Second suggested answer] | [What this means for the feature] |
+           | C      | [Third suggested answer] | [What this means for the feature] |
+           | Custom | Provide your own answer | [Explain how to provide custom input] |
+           
+           **Your choice**: _[Wait for user response]_
+           ```
+        
+        4. **CRITICAL - Table Formatting**: Ensure markdown tables are properly formatted:
+           - Use consistent spacing with pipes aligned
+           - Each cell should have spaces around content: `| Content |` not `|Content|`
+           - Header separator must have at least 3 dashes: `|--------|`
+           - Test that the table renders correctly in markdown preview
+        5. Number questions sequentially (Q1, Q2, Q3 - max 3 total)
+        6. Present all questions together before waiting for responses
+        7. Wait for user to respond with their choices for all questions (e.g., "Q1: A, Q2: Custom - [details], Q3: B")
+        8. Update the spec by replacing each [NEEDS CLARIFICATION] marker with the user's selected or provided answer
+        9. Re-run validation after all clarifications are resolved
+   
+   d. **Update Checklist**: After each validation iteration, update the checklist file with current pass/fail status
+
+6. Report completion with branch name, spec file path, checklist results, and readiness for the next phase (`/speckit.clarify` or `/speckit.plan`).
+
+**NOTE:** The script creates and checks out the new branch and initializes the spec file before writing.
+
+## General Guidelines
+
+## Quick Guidelines
+
+- Focus on **WHAT** users need and **WHY**.
+- Avoid HOW to implement (no tech stack, APIs, code structure).
+- Written for business stakeholders, not developers.
+- DO NOT create any checklists that are embedded in the spec. That will be a separate command.
+
+### Section Requirements
+
+- **Mandatory sections**: Must be completed for every feature
+- **Optional sections**: Include only when relevant to the feature
+- When a section doesn't apply, remove it entirely (don't leave as "N/A")
+
+### For AI Generation
+
+When creating this spec from a user prompt:
+
+1. **Make informed guesses**: Use context, industry standards, and common patterns to fill gaps
+2. **Document assumptions**: Record reasonable defaults in the Assumptions section
+3. **Limit clarifications**: Maximum 3 [NEEDS CLARIFICATION] markers - use only for critical decisions that:
+   - Significantly impact feature scope or user experience
+   - Have multiple reasonable interpretations with different implications
+   - Lack any reasonable default
+4. **Prioritize clarifications**: scope > security/privacy > user experience > technical details
+5. **Think like a tester**: Every vague requirement should fail the "testable and unambiguous" checklist item
+6. **Common areas needing clarification** (only if no reasonable default exists):
+   - Feature scope and boundaries (include/exclude specific use cases)
+   - User types and permissions (if multiple conflicting interpretations possible)
+   - Security/compliance requirements (when legally/financially significant)
+   
+**Examples of reasonable defaults** (don't ask about these):
+
+- Data retention: Industry-standard practices for the domain
+- Performance targets: Standard web/mobile app expectations unless specified
+- Error handling: User-friendly messages with appropriate fallbacks
+- Authentication method: Standard session-based or OAuth2 for web apps
+- Integration patterns: RESTful APIs unless specified otherwise
+
+### Success Criteria Guidelines
+
+Success criteria must be:
+
+1. **Measurable**: Include specific metrics (time, percentage, count, rate)
+2. **Technology-agnostic**: No mention of frameworks, languages, databases, or tools
+3. **User-focused**: Describe outcomes from user/business perspective, not system internals
+4. **Verifiable**: Can be tested/validated without knowing implementation details
+
+**Good examples**:
+
+- "Users can complete checkout in under 3 minutes"
+- "System supports 10,000 concurrent users"
+- "95% of searches return results in under 1 second"
+- "Task completion rate improves by 40%"
+
+**Bad examples** (implementation-focused):
+
+- "API response time is under 200ms" (too technical, use "Users see results instantly")
+- "Database can handle 1000 TPS" (implementation detail, use user-facing metric)
+- "React components render efficiently" (framework-specific)
+- "Redis cache hit rate above 80%" (technology-specific)
diff --git a/.cursor/commands/speckit.tasks.md b/.cursor/commands/speckit.tasks.md
new file mode 100644
index 0000000..cd21b68
--- /dev/null
+++ b/.cursor/commands/speckit.tasks.md
@@ -0,0 +1,107 @@
+## User Input
+
+```text
+Use the user-provided arguments (if any) as contextual input
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+1. **Setup**: Run `.specify/scripts/bash/check-prerequisites.sh --json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. **Load design documents**: Read from FEATURE_DIR:
+   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)
+   - **Optional**: data-model.md (entities), contracts/ (API endpoints), research.md (decisions), quickstart.md (test scenarios)
+   - Note: Not all projects have all documents. Generate tasks based on what's available.
+
+3. **Execute task generation workflow** (follow the template structure):
+   - Load plan.md and extract tech stack, libraries, project structure
+   - **Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)**
+   - If data-model.md exists: Extract entities → map to user stories
+   - If contracts/ exists: Each file → map endpoints to user stories
+   - If research.md exists: Extract decisions → generate setup tasks
+   - **Generate tasks ORGANIZED BY USER STORY**:
+     - Setup tasks (shared infrastructure needed by all stories)
+     - **Foundational tasks (prerequisites that must complete before ANY user story can start)**
+     - For each user story (in priority order P1, P2, P3...):
+       - Group all tasks needed to complete JUST that story
+       - Include models, services, endpoints, UI components specific to that story
+       - Mark which tasks are [P] parallelizable
+       - If tests requested: Include tests specific to that story
+     - Polish/Integration tasks (cross-cutting concerns)
+   - **Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature spec or user asks for TDD approach
+   - Apply task rules:
+     - Different files = mark [P] for parallel
+     - Same file = sequential (no [P])
+     - If tests requested: Tests before implementation (TDD order)
+   - Number tasks sequentially (T001, T002...)
+   - Generate dependency graph showing user story completion order
+   - Create parallel execution examples per user story
+   - Validate task completeness (each user story has all needed tasks, independently testable)
+
+4. **Generate tasks.md**: Use `.specify.specify/templates/tasks-template.md` as structure, fill with:
+   - Correct feature name from plan.md
+   - Phase 1: Setup tasks (project initialization)
+   - Phase 2: Foundational tasks (blocking prerequisites for all user stories)
+   - Phase 3+: One phase per user story (in priority order from spec.md)
+     - Each phase includes: story goal, independent test criteria, tests (if requested), implementation tasks
+     - Clear [Story] labels (US1, US2, US3...) for each task
+     - [P] markers for parallelizable tasks within each story
+     - Checkpoint markers after each story phase
+   - Final Phase: Polish & cross-cutting concerns
+   - Numbered tasks (T001, T002...) in execution order
+   - Clear file paths for each task
+   - Dependencies section showing story completion order
+   - Parallel execution examples per story
+   - Implementation strategy section (MVP first, incremental delivery)
+
+5. **Report**: Output path to generated tasks.md and summary:
+   - Total task count
+   - Task count per user story
+   - Parallel opportunities identified
+   - Independent test criteria for each story
+   - Suggested MVP scope (typically just User Story 1)
+
+Context for task generation: Use the user-provided arguments (if any) as contextual input
+
+The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.
+
+## Task Generation Rules
+
+**IMPORTANT**: Tests are optional. Only generate test tasks if the user explicitly requested testing or TDD approach in the feature specification.
+
+**CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing.
+
+1. **From User Stories (spec.md)** - PRIMARY ORGANIZATION:
+   - Each user story (P1, P2, P3...) gets its own phase
+   - Map all related components to their story:
+     - Models needed for that story
+     - Services needed for that story
+     - Endpoints/UI needed for that story
+     - If tests requested: Tests specific to that story
+   - Mark story dependencies (most stories should be independent)
+   
+2. **From Contracts**:
+   - Map each contract/endpoint → to the user story it serves
+   - If tests requested: Each contract → contract test task [P] before implementation in that story's phase
+   
+3. **From Data Model**:
+   - Map each entity → to the user story(ies) that need it
+   - If entity serves multiple stories: Put in earliest story or Setup phase
+   - Relationships → service layer tasks in appropriate story phase
+   
+4. **From Setup/Infrastructure**:
+   - Shared infrastructure → Setup phase (Phase 1)
+   - Foundational/blocking tasks → Foundational phase (Phase 2)
+     - Examples: Database schema setup, authentication framework, core libraries, base configurations
+     - These MUST complete before any user story can be implemented
+   - Story-specific setup → within that story's phase
+
+5. **Ordering**:
+   - Phase 1: Setup (project initialization)
+   - Phase 2: Foundational (blocking prerequisites - must complete before user stories)
+   - Phase 3+: User Stories in priority order (P1, P2, P3...)
+     - Within each story: Tests (if requested) → Models → Services → Endpoints → Integration
+   - Final Phase: Polish & Cross-Cutting Concerns
+   - Each user story phase should be a complete, independently testable increment
diff --git a/.tests/file-maps.sh b/.tests/file-maps.sh
index 5197921..7c15d54 100755
--- a/.tests/file-maps.sh
+++ b/.tests/file-maps.sh
@@ -3,6 +3,17 @@
 # File maps for Cursor Rules installer tests
 # This file defines the expected files for each installation option
 
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+COMMAND_SOURCE_DIR="$SCRIPT_DIR/../.cursor/commands"
+
+COMMAND_FILES=()
+if [ -d "$COMMAND_SOURCE_DIR" ]; then
+  while IFS= read -r -d '' file; do
+    rel_path="${file#./}"
+    COMMAND_FILES+=("$rel_path")
+  done < <(cd "$COMMAND_SOURCE_DIR" && find . -type f -print0)
+fi
+
 # Core rules
 CORE_FILES=(
   "cursor-rules.mdc"
@@ -88,10 +99,11 @@ JAVASCRIPT_FILES=(
   "javascript-server-side-request-forgery.mdc"
 )
 
-# Function to validate files
-validate_files() {
+# Function to validate rule files without checking commands
+validate_rules_only() {
   local test_dir=$1
-  local files=("${@:2}")
+  shift
+  local files=("$@")
   local missing_files=0
   local missing_file_list=()
   
@@ -107,7 +119,7 @@ validate_files() {
     missing_files=$((missing_files + 1))
     missing_file_list+=("UPDATE.md (in .cursor directory)")
   fi
-  
+
   if [ $missing_files -gt 0 ]; then
     echo "Missing files: $missing_files"
     for file in "${missing_file_list[@]}"; do
@@ -119,6 +131,116 @@ validate_files() {
   return 0
 }
 
+# Function to validate files including commands
+validate_files() {
+  local test_dir=$1
+  shift
+  local files=("$@")
+
+  if ! validate_rules_only "$test_dir" "${files[@]}"; then
+    return 1
+  fi
+
+  if ! validate_commands_dir "$test_dir/.cursor/commands"; then
+    return 1
+  fi
+
+  return 0
+}
+
+validate_commands_dir() {
+  local commands_dir=$1
+  local missing=0
+  local missing_list=()
+
+  if [ ${#COMMAND_FILES[@]} -eq 0 ]; then
+    echo "Warning: COMMAND_FILES list is empty; skipping command validation"
+    return 0
+  fi
+
+  if [ ! -d "$commands_dir" ]; then
+    echo "Commands directory not found: $commands_dir"
+    return 1
+  fi
+
+  for command_file in "${COMMAND_FILES[@]}"; do
+    if [ ! -f "$commands_dir/$command_file" ]; then
+      missing=$((missing + 1))
+      missing_list+=("$command_file")
+    fi
+  done
+
+  if [ $missing -gt 0 ]; then
+    echo "Missing command files: $missing"
+    for file in "${missing_list[@]}"; do
+      echo "  - $file"
+    done
+    return 1
+  fi
+
+  return 0
+}
+
+validate_home_commands_dir() {
+  local home_dir=$1
+  validate_commands_dir "$home_dir/.cursor/commands"
+}
+
+validate_no_project_commands() {
+  local test_dir=$1
+  if [ -d "$test_dir/.cursor/commands" ]; then
+    echo "Commands directory should not have been created"
+    return 1
+  fi
+  return 0
+}
+
+validate_core_without_commands() {
+  local test_dir=$1
+  if ! validate_rules_only "$test_dir" "${CORE_FILES[@]}"; then
+    return 1
+  fi
+  if ! validate_no_project_commands "$test_dir"; then
+    return 1
+  fi
+  return 0
+}
+
+validate_core_home_commands() {
+  local test_dir=$1
+  local home_dir=${COMMANDS_HOME_DIR:-"$test_dir/home"}
+  if ! validate_rules_only "$test_dir" "${CORE_FILES[@]}"; then
+    return 1
+  fi
+  if [ -z "$home_dir" ]; then
+    echo "Home directory for commands not provided"
+    return 1
+  fi
+  if ! validate_home_commands_dir "$home_dir"; then
+    return 1
+  fi
+  if [ -d "$test_dir/.cursor/commands" ]; then
+    echo "Project commands should not be installed when targeting home"
+    return 1
+  fi
+  return 0
+}
+
+validate_core_both_commands() {
+  local test_dir=$1
+  local home_dir=${COMMANDS_HOME_DIR:-"$test_dir/home"}
+  if ! validate_rules_only "$test_dir" "${CORE_FILES[@]}"; then
+    return 1
+  fi
+  if ! validate_commands_dir "$test_dir/.cursor/commands"; then
+    return 1
+  fi
+  if ! validate_home_commands_dir "$home_dir"; then
+    return 1
+  fi
+  return 0
+}
+
 # Function to validate web stack installation
 validate_web_stack() {
   local test_dir=$1
@@ -186,4 +308,4 @@ validate_ignore_files() {
   fi
   
   return 0
-} 
\ No newline at end of file
+} 
diff --git a/.tests/run-all-tests.sh b/.tests/run-all-tests.sh
index 489cd01..4835e28 100755
--- a/.tests/run-all-tests.sh
+++ b/.tests/run-all-tests.sh
@@ -79,7 +79,12 @@ run_test() {
   
   # Run the command
   cd "$test_dir"
-  bash -c "$command" > output.log 2>&1
+  local command_source="$BASE_DIR/../.cursor/commands"
+  if [ -d "$command_source" ]; then
+    env CURSOR_COMMAND_SOURCE="$command_source" CURSOR_COMMANDS_SOURCE="$command_source" bash -c "$command" > output.log 2>&1
+  else
+    bash -c "$command" > output.log 2>&1
+  fi
   local exit_code=$?
   cd "$BASE_DIR"
   
@@ -133,28 +138,40 @@ run_test "All Rules Installation" "php install.php --all --yes" "validate_all"
 # Test 4: Core Rules Installation
 run_test "Core Rules Installation" "php install.php --core --yes" "validate_core"
 
-# Test 5: JavaScript OWASP Installation
+# Test 5: Skip Commands Option
+run_test "Skip Commands Option" "php install.php --core --yes --commands=skip" "validate_core_without_commands"
+
+# Test 6: Commands Home Option
+run_test "Commands Home Option" 'HOME="$(pwd)/home" php install.php --core --yes --commands=home' "validate_core_home_commands"
+
+# Test 7: Commands Both Option
+run_test "Commands Both Option" 'HOME="$(pwd)/home" php install.php --core --yes --commands=both' "validate_core_both_commands"
+
+# Test 8: Interactive Skip Commands
+run_test "Interactive Skip Commands" 'CURSOR_INSTALLER_INPUT="1,n" php install.php' "validate_core_without_commands"
+
+# Test 9: JavaScript OWASP Installation
 run_test "JavaScript OWASP Installation" "php install.php --javascript --yes" "validate_javascript"
 
-# Test 6: Tag Filtering - JavaScript Security
+# Test 10: Tag Filtering - JavaScript Security
 run_test "Tag Filtering - JavaScript Security" "php install.php --tags 'language:javascript category:security' --yes" "validate_javascript_security_only"
 
-# Test 7: Tag Preset - JavaScript OWASP
+# Test 11: Tag Preset - JavaScript OWASP
 run_test "Tag Preset - JavaScript OWASP" "php install.php --tag-preset js-owasp --yes" "validate_javascript_security_only"
 
-# Test 8: Help Information
+# Test 12: Help Information
 run_test "Help Information" "php install.php --help" "" 0
 
-# Test 9: Web Stack with Short Option
+# Test 13: Web Stack with Short Option
 run_test "Web Stack with Short Option" "php install.php -w -y" "validate_web_stack"
 
-# Test 10: Python with Short Option
+# Test 14: Python with Short Option
 run_test "Python with Short Option" "php install.php -p -y" "validate_python"
 
-# Test 8: JavaScript Installation
+# Test 15: JavaScript Installation
 run_test "JavaScript Installation" "php install.php --javascript --yes" "validate_javascript"
 
-# Test 9: JavaScript with Short Option
+# Test 16: JavaScript with Short Option
 run_test "JavaScript with Short Option" "php install.php -j -y" "validate_javascript"
 
 # Run the error handling tests
@@ -225,4 +242,4 @@ if [ $TESTS_FAILED -gt 0 ]; then
 else
   print_message "$GREEN" "All tests passed!"
   exit 0
-fi 
\ No newline at end of file
+fi 
diff --git a/.tests/run-tests.sh b/.tests/run-tests.sh
index 20f16a6..d3fd1b7 100755
--- a/.tests/run-tests.sh
+++ b/.tests/run-tests.sh
@@ -85,7 +85,12 @@ run_test() {
   
   # Run the command
   cd "$test_dir"
-  bash -c "$command" > output.log 2>&1
+  local command_source="$BASE_DIR/../.cursor/commands"
+  if [ -d "$command_source" ]; then
+    env CURSOR_COMMAND_SOURCE="$command_source" CURSOR_COMMANDS_SOURCE="$command_source" bash -c "$command" > output.log 2>&1
+  else
+    bash -c "$command" > output.log 2>&1
+  fi
   local exit_code=$?
   cd "$BASE_DIR"
   
@@ -136,16 +141,28 @@ run_test "All Rules Installation" "php install.php --all --yes" "validate_all"
 # Test 4: Core Rules Installation
 run_test "Core Rules Installation" "php install.php --core --yes" "validate_core"
 
-# Test 5: Help Information
+# Test 5: Skip Commands Option
+run_test "Skip Commands Option" "php install.php --core --yes --commands=skip" "validate_core_without_commands"
+
+# Test 6: Commands Home Option
+run_test "Commands Home Option" 'HOME="$(pwd)/home" php install.php --core --yes --commands=home' "validate_core_home_commands"
+
+# Test 7: Commands Both Option
+run_test "Commands Both Option" 'HOME="$(pwd)/home" php install.php --core --yes --commands=both' "validate_core_both_commands"
+
+# Test 8: Interactive Skip Commands
+run_test "Interactive Skip Commands" 'CURSOR_INSTALLER_INPUT="1,n" php install.php' "validate_core_without_commands"
+
+# Test 9: Help Information
 run_test "Help Information" "php install.php --help" "" 0
 
-# Test 6: Web Stack with Short Option
+# Test 10: Web Stack with Short Option
 run_test "Web Stack with Short Option" "php install.php -w -y" "validate_web_stack"
 
-# Test 7: Python with Short Option
+# Test 11: Python with Short Option
 run_test "Python with Short Option" "php install.php -p -y" "validate_python"
 
-# Test 8: Invalid Option
+# Test 12: Invalid Option
 print_message "$BLUE" "\n=== Running Test: Invalid Option ==="
 echo "Command: php install.php --invalid-option"
 
@@ -162,8 +179,10 @@ if [ $? -ne 0 ]; then
 else
   # Run the command
   cd "$TEST_DIR"
+  set +e
   php install.php --invalid-option > output.log 2>&1
   EXIT_CODE=$?
+  set -e
   cd "$BASE_DIR"
 
   # Display output
@@ -182,7 +201,7 @@ else
   TESTS_TOTAL=$((TESTS_TOTAL + 1))
 fi
 
-# Test 9: Conflicting Options
+# Test 13: Conflicting Options
 print_message "$BLUE" "\n=== Running Test: Conflicting Options ==="
 echo "Command: php install.php --web-stack --python"
 
@@ -199,8 +218,10 @@ if [ $? -ne 0 ]; then
 else
   # Run the command
   cd "$TEST_DIR"
+  set +e
   php install.php --web-stack --python > output.log 2>&1
   EXIT_CODE=$?
+  set -e
   cd "$BASE_DIR"
 
   # Display output
@@ -229,4 +250,4 @@ if [ $TESTS_FAILED -gt 0 ]; then
 else
   print_message "$GREEN" "All tests passed!"
   exit 0
-fi 
\ No newline at end of file
+fi 
diff --git a/.tests/test-javascript-option.sh b/.tests/test-javascript-option.sh
index 3d42941..d17bf72 100755
--- a/.tests/test-javascript-option.sh
+++ b/.tests/test-javascript-option.sh
@@ -13,6 +13,7 @@ NC='\033[0m' # No Color
 BASE_DIR=$(pwd)
 TEMP_DIR="$BASE_DIR/temp"
 INSTALLER_PATH="$BASE_DIR/../install.php"
+COMMAND_SOURCE_DIR="$BASE_DIR/../.cursor/commands"
 
 # Import file maps
 source "$BASE_DIR/file-maps.sh"
@@ -65,7 +66,12 @@ test_javascript_option() {
   # Test --javascript option
   print_message "$BLUE" "Testing: php install.php --javascript --yes"
   cd "$test_dir"
-  php install.php --javascript --yes > output.log 2>&1
+  if [ -d "$COMMAND_SOURCE_DIR" ]; then
+    CURSOR_COMMAND_SOURCE="$COMMAND_SOURCE_DIR" CURSOR_COMMANDS_SOURCE="$COMMAND_SOURCE_DIR" \
+      php install.php --javascript --yes > output.log 2>&1
+  else
+    php install.php --javascript --yes > output.log 2>&1
+  fi
   local exit_code=$?
   cd "$BASE_DIR"
   
@@ -105,7 +111,12 @@ test_javascript_option() {
   fi
   
   cd "$test_dir_short"
-  php install.php -j -y > output.log 2>&1
+  if [ -d "$COMMAND_SOURCE_DIR" ]; then
+    CURSOR_COMMAND_SOURCE="$COMMAND_SOURCE_DIR" CURSOR_COMMANDS_SOURCE="$COMMAND_SOURCE_DIR" \
+      php install.php -j -y > output.log 2>&1
+  else
+    php install.php -j -y > output.log 2>&1
+  fi
   local exit_code_short=$?
   cd "$BASE_DIR"
   
@@ -142,4 +153,4 @@ if [ $? -eq 0 ]; then
 else
   print_message "$RED" "JavaScript option test failed!"
   exit 1
-fi
\ No newline at end of file
+fi
diff --git a/AGENTS.md b/AGENTS.md
index 7305534..2316a12 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -110,6 +110,12 @@ The installer supports tag expressions and presets. Examples:
 
 See `TAG_STANDARDS.md` for the complete tag taxonomy and guidance.
 
+## Maintainer Checklist
+- Before opening a pull request, prepend a new entry to `CHANGELOG.md` describing your changes (latest release first) and never delete prior history.
+- Ensure the summary in `CHANGELOG.md` matches the work being done and that `CURSOR_RULES_VERSION` reflects the next release number.
+- Record key implementation notes in this `AGENTS.md` only when they affect installer behaviour or rule coverage so the instructions stay current.
+- Regenerate project-local `AGENTS.md` files with `--yes` when you need to refresh them after significant rule or command updates.
+
 ## Updating Or Removing
 - To update, re-run the installer with your preferred options (it will copy over updated rules). See `README.md`.
 - To remove rules, delete files from `.cursor/rules` and remove any generated `.cursorignore` files if not needed.
diff --git a/CHANGELOG.md b/CHANGELOG.md
new file mode 100644
index 0000000..f04cc76
--- /dev/null
+++ b/CHANGELOG.md
@@ -0,0 +1,43 @@
+# Changelog
+
+All notable changes to this project are documented in this file. Entries appear in reverse chronological order so the most recent updates are always at the top. Do not overwrite existing content—prepend new releases instead.
+
+## [1.0.8] - 2025-10-24
+### Added
+- Integrated installation of Cursor slash commands, including project/home/both targets and new `--commands` / `--skip-commands` flags.
+- Captured command installation outcomes in generated `AGENTS.md` and `UPDATE.md` files for downstream visibility.
+
+### Changed
+- Bumped `CURSOR_RULES_VERSION` to `1.0.8` in preparation for the next release cycle.
+
+## [1.0.7] - 2025-09-02
+### Changed
+- Streamlined rule bundle organisation and refreshed documentation references to match the markdown migration.
+- Tweaked installer configuration and associated file-mapping tests for the updated structure.
+
+## [1.0.6] - 2025-08-20
+### Changed
+- Updated release metadata to version 1.0.6 in preparation for distribution.
+
+## [1.0.5] - 2025-06-06
+### Added
+- Expanded pull-request review guidance with multi-language support, large-file detection, and improved security assessment coverage.
+
+### Changed
+- Updated installer metadata to version 1.0.5 and refreshed `.cursor/UPDATE.md` with detailed release notes.
+
+## [0.1.0] - 2025-06-01
+### Added
+- Enhanced GitHub Actions workflow and extended automated test coverage for installer scenarios, including ignore-file and tag option handling.
+
+### Changed
+- Updated test utilities and file maps to support the expanded rule set.
+
+## [0.0.2] - 2025-02-28
+### Added
+- Introduced local rule fallback logic to `install.php`, ensuring installation succeeds when remote downloads are unavailable.
+- Added `testing-guidelines.mdc` to the default installation set and documented the new behaviour.
+
+## [0.0.1] - 2025-02-12
+### Changed
+- Improved installer robustness with better piped-input handling, simplified error messaging, and streamlined logic.
diff --git a/docs/prd.md b/docs/prd.md
deleted file mode 100644
index 4ceb5be..0000000
--- a/docs/prd.md
+++ /dev/null
@@ -1,74 +0,0 @@
-# Product Requirements Document: Cursor Rules Installer
-
-## 1. Elevator Pitch
-A PHP-based installation tool that enables developers to easily install cursor rules into their projects with a single curl command. The tool offers both interactive and non-interactive options for selecting rule sets (WebStack, Core, Python, or All), supporting keyboard navigation for a seamless user experience.
-
-## 2. Who is this app for?
-This tool is designed for developers who work with cursor AI software and need to efficiently install cursor rules into their projects. It streamlines the process of integrating these rules, reducing setup time and ensuring consistency across multiple projects.
-
-## 3. Functional Requirements
-- **Installation Method**: Simple curl command that can be executed via PHP
-- **Rule Sets Support**:
-  - WebStack rules
-  - Core rules
-  - Python rules
-  - All rules option
-- **Installation Logic**:
-  - Core rules should be installed when either Python or WebStack are selected
-  - Support for installing all rules at once
-- **Interactive Mode**:
-  - Selection via keyboard up/down arrow navigation
-  - Visual prompts for selection options
-- **Non-Interactive Mode**:
-  - Command-line parameters for automated installation
-  - Support for all rule set options
-- **Technical Specifications**:
-  - PHP 8.3 compatibility
-  - Local testing capability (installing to temporary folder)
-  - GitHub Actions integration for CI/CD testing
-  - Testing coverage for all options, including invalid inputs
-
-## 4. User Stories
-1. **Basic Installation**
-   - As a developer, I want to copy a single curl command from the GitHub repository and execute it to install cursor rules into my project.
-
-2. **Interactive Rule Selection**
-   - As a developer, I want to interactively select which rule sets to install using keyboard navigation so that I can easily choose the appropriate rules for my project.
-
-3. **Automated Installation**
-   - As a developer, I want to specify rule sets via command-line parameters so that I can automate the installation process in scripts or CI/CD pipelines.
-
-4. **Core Rule Integration**
-   - As a developer, I want Core rules to be automatically included when I select either WebStack or Python rules so that I have the necessary foundational rules.
-
-5. **Complete Rules Installation**
-   - As a developer, I want to easily install all available rules with a single option so that I can quickly set up a comprehensive rule set.
-
-## 5. User Interface
-As this is a command-line tool, the UI will consist of:
-
-1. **Installation Command**
-   - A simple, copy-pastable curl command visible in the GitHub repository README.
-
-2. **Interactive Mode Interface**
-   - Clear text prompts showing available options
-   - Visual indicators for currently selected option
-   - Up/down arrow navigation support
-   - Confirmation messages after selection
-
-3. **Command Execution Feedback**
-   - Progress indicators during installation
-   - Success/failure messages
-   - Summary of installed rule sets
-   - Use of common colours to indicate success, notification, warning and error type of messages.
-
-4. **Help Information**
-   - Documentation for command-line parameters
-   - Examples of common usage patterns
-
-## 6. Testing Requirements
-- Local tests that install rules into a temporary folder
-- Test coverage for all rule set combinations
-- Test handling of invalid options
-- GitHub Action for automated testing on push or pull request
-- Validation of PHP 8.3 compatibility
\ No newline at end of file
diff --git a/docs/specs/command-installer-update.md b/docs/specs/command-installer-update.md
new file mode 100644
index 0000000..c8f6dcc
--- /dev/null
+++ b/docs/specs/command-installer-update.md
@@ -0,0 +1,14 @@
+# Command Installer Update
+
+**Date:** 2025-10-24
+
+## Summary
+- Added bundled Cursor slash commands to the installer workflow with interactive and non-interactive selection of install targets (project, home, both, or skip).
+- Expanded automated tests to cover new command options and validation checks for both project and home installations.
+- Refreshed documentation (`AGENTS.md`, `CHANGELOG.md`) and version metadata to reflect the new release (v1.0.8).
+- Removed obsolete docs (`docs/prd.md`, `docs/srs.md`) while replacing project documentation with this concise specification record.
+
+## Notes
+- Installer reads bundled commands from `.cursor/commands` and mirrors them into the chosen destinations.
+- Tests leverage `CURSOR_COMMAND_SOURCE` to provide the bundled command directory during simulated installs.
+- Future updates should keep `COMMAND_FILES` in sync with the files stored under `.cursor/commands`.
diff --git a/docs/srs.md b/docs/srs.md
deleted file mode 100644
index 62278b3..0000000
--- a/docs/srs.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# Software Requirements Specification: Cursor Rules Installer
-
-## System Design
-- **Purpose**: PHP-based installation tool that enables the installation of cursor rules (WebStack, Core, Python) via a single curl command
-- **Components**:
-  - Installation script (PHP)
-  - Rule sets (WebStack, Core, Python, all)
-  - Testing framework
-  - CI/CD integration (GitHub Actions)
-- **Execution Flow**:
-  - User executes curl command to fetch and run the installer
-  - Installer presents options (interactive) or processes parameters (non-interactive)
-  - Selected rule sets are installed to appropriate project directories
-  - Success/failure status is reported to user
-
-## Architecture Pattern
-- **Command Line Application** using PHP
-- **Builder Pattern** for constructing rule set installations
-- **Strategy Pattern** for handling different installation modes (interactive vs. non-interactive)
-- **Factory Pattern** for rule set creation and management
-
-## State Management
-- **Execution State Tracking**:
-  - Command line arguments storage
-  - Selected options tracking
-  - Installation progress monitoring
-  - Error states handling
-- **Stateless Design**:
-  - Each execution is independent
-  - No persistent state between runs
-  - State maintained only during execution lifecycle
-
-## Data Flow
-1. **Input Collection**:
-   - Command line arguments parsing
-   - Interactive option selection
-2. **Validation**:
-   - Verify PHP version compatibility (8.3+)
-   - Validate selected options
-   - Check write permissions to target directories
-3. **Rule Selection Processing**:
-   - Determine rule dependencies (Core + selected rules)
-   - Resolve rule set paths
-4. **Installation Execution**:
-   - Copy rule files to designated locations
-   - Apply necessary file permissions
-5. **Output Generation**:
-   - Installation success/failure reporting
-   - Summary of installed rule sets
-
-## Technical Stack
-- **Languages**:
-  - PHP 8.3+ (primary implementation)
-  - Bash (supporting scripts)
-- **Development Tools**:
-  - PHPUnit (testing)
-  - phpcs, phpmd (code quality)
-- **Deployment Tools**:
-  - GitHub Actions (CI/CD)
-  - bash, zsh or other shell
-
-## Command Interface Design
-- **Interactive Mode Commands**:
-  - Selection mechanism using arrow keys
-  - Enter key for confirmation
-  - Escape key for cancellation
-- **Non-Interactive Parameters**:
-  - `--webstack`: Install WebStack rules
-  - `--python`: Install Python rules
-  - `--core`: Install Core rules
-  - `--all`: Install all rules
-  - `--help`: Display usage information
-  - `--version`: Display version information
-  - `--quiet`: Suppress output except for errors
-  - `--debug`: Enable verbose debugging output
-
-## Database Design ERD
-- **No persistent database required**
-- **File Structure**:
-  - `/.cursor/rules/webstack/`: WebStack rule files
-  - `/.cursor/rules/core/`: Core rule files
-  - `/.cursor/rules/python/`: Python rule files
-  - `/.cursor/tests/`: Test files
-  - `/install.php`: Installer files
-  - `/.tests/`: Temporary installation directory for 
-  - `/docs/`: Documentation folder.
\ No newline at end of file
diff --git a/install.php b/install.php
index 865a1c6..52597d1 100644
--- a/install.php
+++ b/install.php
@@ -20,9 +20,10 @@
 declare(strict_types=1);
 
 // Define constants.
-define('CURSOR_RULES_VERSION', '1.0.6');
+define('CURSOR_RULES_VERSION', '1.0.8');
 define('CURSOR_RULES_DIR', '.cursor/rules');
 define('CURSOR_DIR', '.cursor');
+define('CURSOR_COMMANDS_DIR', '.cursor/commands');
 
 const COLORS = [
     'red' => "\033[0;31m",
@@ -57,6 +58,29 @@
     'drupal-owasp' => 'framework:drupal standard:owasp-top10',
 ];
 
+// Command files bundled with the installer.
+const COMMAND_FILES = [
+    'behat-drevops.md',
+    'drupal-lint.md',
+    'gh-issue-create.md',
+    'gh-issue-resolve.md',
+    'npm-audit-fix.md',
+    'pr-assess.md',
+    'pr-draft.md',
+    'pr-resolve.md',
+    'security-scan.md',
+    'security-verify.md',
+    'session-summary.md',
+    'speckit.analyze.md',
+    'speckit.checklist.md',
+    'speckit.clarify.md',
+    'speckit.constitution.md',
+    'speckit.implement.md',
+    'speckit.plan.md',
+    'speckit.specify.md',
+    'speckit.tasks.md',
+];
+
 // Main function to install cursor rules.
 function install_cursor_rules(array $options = []): bool {
   // Default options.
@@ -74,11 +98,22 @@ function install_cursor_rules(array $options = []): bool {
     'core' => false,
     'yes' => false,
     'help' => false,
+    'commands' => 'auto',
   ];
 
   // Merge options.
   $options = array_merge($default_options, $options);
 
+  // Determine if STDIN is available for interactive prompts.
+  $stdin_available = false;
+  if (function_exists('stream_isatty') && defined('STDIN')) {
+    $stdin_available = @stream_isatty(STDIN);
+  }
+  $scripted_input = getenv('CURSOR_INSTALLER_INPUT');
+  if (!$stdin_available && $scripted_input !== false && $scripted_input !== '') {
+    $stdin_available = true;
+  }
+
   // Show help if requested.
   if ($options['help']) {
     show_help();
@@ -230,9 +265,6 @@ function install_cursor_rules(array $options = []): bool {
       echo "Will filter " . count($rules_to_install) . " rules based on tags\n";
     }
   } else {
-    // Check if STDIN is available for interactive input
-    $stdin_available = function_exists('stream_isatty') ? stream_isatty(STDIN) : false;
-
     // Interactive mode if no specific option is selected and not in auto-yes mode and STDIN is available
     if ($option_count === 0 && !$options['yes'] && $stdin_available) {
       echo "Welcome to Cursor Rules Installer v" . CURSOR_RULES_VERSION . "\n\n";
@@ -249,7 +281,7 @@ function install_cursor_rules(array $options = []): bool {
       $valid_choice = false;
       while (!$valid_choice) {
         echo "\nEnter your choice (1-8): ";
-        $choice = trim(fgets(STDIN));
+        $choice = read_stdin_line();
 
         switch ($choice) {
           case '1':
@@ -296,7 +328,7 @@ function install_cursor_rules(array $options = []): bool {
               echo "  - $preset: $expression\n";
             }
             echo "\nEnter tag preset name or custom tag expression: ";
-            $tag_input = trim(fgets(STDIN));
+            $tag_input = read_stdin_line();
             
             if (array_key_exists($tag_input, TAG_PRESETS)) {
               $tag_expression = TAG_PRESETS[$tag_input];
@@ -349,6 +381,78 @@ function install_cursor_rules(array $options = []): bool {
     }
   }
 
+  // Determine command installation targets.
+  $commands_option = strtolower((string)($options['commands'] ?? 'auto'));
+  $command_targets = [];
+
+  switch ($commands_option) {
+    case 'skip':
+    case 'none':
+    case 'no':
+      $command_targets = [];
+      $commands_option = 'skip';
+      break;
+    case 'home':
+      $command_targets = ['home'];
+      break;
+    case 'project':
+      $command_targets = ['project'];
+      break;
+    case 'both':
+    case 'all':
+      $command_targets = ['home', 'project'];
+      $commands_option = 'both';
+      break;
+    default:
+      // Interactive prompt when auto and we can ask the user.
+      if ($options['yes'] || !$stdin_available) {
+        $command_targets = ['project'];
+        $commands_option = 'project';
+      } else {
+        echo "\nCursor slash commands provide ready-to-use prompts for the Cursor agent.\n";
+        echo "Install slash commands as part of this setup? (Y/n): ";
+        $response = strtolower(read_stdin_line());
+        if ($response === 'n' || $response === 'no') {
+          $command_targets = [];
+          $commands_option = 'skip';
+        } else {
+          echo "\nWhere should the commands be installed?\n";
+          echo "  1) User home directory (~/.cursor/commands)\n";
+          echo "  2) Project directory (" . CURSOR_COMMANDS_DIR . ")\n";
+          echo "  3) Both locations\n";
+          echo "Enter choice (1-3) [default: 2]: ";
+          $location_choice = read_stdin_line();
+          if ($location_choice === '') {
+            $location_choice = '2';
+          }
+          switch ($location_choice) {
+            case '1':
+              $command_targets = ['home'];
+              $commands_option = 'home';
+              break;
+            case '3':
+              $command_targets = ['home', 'project'];
+              $commands_option = 'both';
+              break;
+            case '2':
+            default:
+              $command_targets = ['project'];
+              $commands_option = 'project';
+              break;
+          }
+        }
+      }
+  }
+
+  $command_targets = array_values(array_unique($command_targets));
+  $should_install_commands = count($command_targets) > 0;
+
+  // Persist the normalized command option for later use.
+  $options['commands'] = $commands_option;
+  $commands_temp_dir = null;
+  $command_install_summary = [];
+
+
   // Define possible source directories.
   $possible_source_dirs = [
     __DIR__ . '/.cursor/rules',
@@ -634,6 +738,165 @@ function is_valid_source_dir($dir, $rule_files) {
     // Remove the directory
     @rmdir($temp_dir);
   }
+
+  // Install slash commands if requested.
+  $commands_source_dir = null;
+  if ($should_install_commands) {
+    if ($options['debug']) {
+      echo "Preparing to install slash commands...\n";
+    }
+
+    $commands_source_candidates = [];
+    if (!empty($source_dir)) {
+      $commands_source_candidates[] = dirname($source_dir) . '/commands';
+    }
+    $env_commands_source = getenv('CURSOR_COMMAND_SOURCE') ?: getenv('CURSOR_COMMANDS_SOURCE');
+    if (!empty($env_commands_source)) {
+      $commands_source_candidates[] = rtrim($env_commands_source, DIRECTORY_SEPARATOR);
+    }
+    $commands_source_candidates[] = __DIR__ . '/.cursor/commands';
+    $commands_source_candidates[] = realpath(__DIR__ . '/../.cursor/commands');
+    $commands_source_candidates[] = getcwd() . '/.cursor/commands';
+    $commands_source_candidates = array_values(array_filter(array_unique($commands_source_candidates)));
+
+    foreach ($commands_source_candidates as $candidate) {
+      if ($candidate && is_valid_commands_source_dir($candidate)) {
+        $commands_source_dir = $candidate;
+        if ($options['debug']) {
+          echo "Using commands source: $candidate\n";
+        }
+        break;
+      }
+    }
+
+    if ($commands_source_dir === null) {
+      $commands_temp_dir = sys_get_temp_dir() . '/cursor-commands-' . uniqid();
+      if (!mkdir($commands_temp_dir, 0755, true)) {
+        echo "Warning: Failed to create temporary directory for commands. Skipping command installation.\n";
+        $command_install_summary[] = [
+          'target' => 'all',
+          'status' => 'failed',
+          'details' => 'temporary directory creation failed',
+        ];
+      } else {
+        $commands_github_source = 'https://raw.githubusercontent.com/ivangrynenko/cursor-rules/main/.cursor/commands/';
+        $downloaded_commands = 0;
+        foreach (COMMAND_FILES as $command_file) {
+          $url = $commands_github_source . $command_file;
+          $content = @file_get_contents($url);
+          if ($content === false) {
+            if ($options['debug']) {
+              echo "Failed to download command file: $command_file\n";
+            }
+            continue;
+          }
+
+          $dest_path = $commands_temp_dir . '/' . $command_file;
+          $dest_dir = dirname($dest_path);
+          if (!is_dir($dest_dir) && !mkdir($dest_dir, 0755, true)) {
+            if ($options['debug']) {
+              echo "Failed to create directory for $dest_path\n";
+            }
+            continue;
+          }
+
+          if (file_put_contents($dest_path, $content) !== false) {
+            $downloaded_commands++;
+          }
+        }
+
+        if ($downloaded_commands > 0) {
+          $commands_source_dir = $commands_temp_dir;
+          if ($options['debug']) {
+            echo "Downloaded $downloaded_commands command file(s) to $commands_temp_dir\n";
+          }
+        } else {
+          echo "Warning: Could not download command files from GitHub. Skipping command installation.\n";
+          $command_install_summary[] = [
+            'target' => 'all',
+            'status' => 'failed',
+            'details' => 'download failed',
+          ];
+        }
+      }
+    }
+
+    if ($commands_source_dir !== null) {
+      foreach ($command_targets as $target) {
+        if ($target === 'home') {
+          $home_dir = get_user_home_directory();
+          if ($home_dir === null) {
+            echo "Warning: Could not determine the user home directory. Skipping home command installation.\n";
+            $command_install_summary[] = [
+              'target' => 'home',
+              'status' => 'skipped',
+              'details' => 'home directory unavailable',
+            ];
+            continue;
+          }
+          $destination_commands_dir = rtrim($home_dir, DIRECTORY_SEPARATOR) . DIRECTORY_SEPARATOR . '.cursor/commands';
+        } else {
+          $destination_commands_dir = dirname($options['destination']) . '/commands';
+        }
+
+        $source_real = realpath($commands_source_dir);
+        $dest_real = realpath($destination_commands_dir);
+
+        if ($dest_real !== false && $source_real !== false && $dest_real === $source_real) {
+          if ($options['debug']) {
+            echo "Commands already present at {$destination_commands_dir}; skipping copy.\n";
+          }
+          $command_install_summary[] = [
+            'target' => $target,
+            'status' => 'existing',
+            'details' => 'source and destination are identical',
+          ];
+          continue;
+        }
+
+        if (!is_dir($destination_commands_dir) && !mkdir($destination_commands_dir, 0755, true)) {
+          echo "Warning: Failed to create command directory at {$destination_commands_dir}.\n";
+          $command_install_summary[] = [
+            'target' => $target,
+            'status' => 'failed',
+            'details' => 'destination directory creation failed',
+          ];
+          continue;
+        }
+
+        $copied_commands = copy_directory_recursive($commands_source_dir, $destination_commands_dir);
+        if ($copied_commands >= 0) {
+          if ($options['debug']) {
+            echo "Installed {$copied_commands} command file(s) to {$destination_commands_dir}\n";
+          }
+          $command_install_summary[] = [
+            'target' => $target,
+            'status' => 'installed',
+            'details' => $destination_commands_dir,
+            'count' => $copied_commands,
+          ];
+        } else {
+          echo "Warning: Failed to copy command files to {$destination_commands_dir}.\n";
+          $command_install_summary[] = [
+            'target' => $target,
+            'status' => 'failed',
+            'details' => 'copy operation failed',
+          ];
+        }
+      }
+    }
+  } else {
+    if ($options['debug']) {
+      echo "Skipping slash command installation per user selection.\n";
+    }
+    $command_install_summary[] = [
+      'target' => 'all',
+      'status' => 'skipped',
+      'details' => 'user opted out',
+    ];
+  }
+
+  $command_summary_lines = summarise_command_installation($command_install_summary);
   
   // Handle .cursorignore files installation
   $ignore_files_option = $options['ignore-files'];
@@ -644,7 +907,7 @@ function is_valid_source_dir($dir, $rule_files) {
   } else if ($ignore_files_option === 'ask' || $ignore_files_option === 'a') {
     if (function_exists('stream_isatty') && stream_isatty(STDIN)) {
       echo "\nWould you like to install recommended .cursorignore files? (Y/n): ";
-      $response = strtolower(trim(fgets(STDIN)));
+      $response = strtolower(read_stdin_line());
       $should_install_ignore_files = ($response === '' || $response === 'y' || $response === 'yes');
     } else {
       // Default to yes if we can't ask interactively
@@ -773,6 +1036,14 @@ function is_valid_source_dir($dir, $rule_files) {
       $lines[] = 'For installation methods and options, see `README.md`. For tag taxonomy, see `TAG_STANDARDS.md`.';
       $lines[] = '';
 
+      if (!empty($command_summary_lines)) {
+        $lines[] = '## Slash Commands';
+        foreach ($command_summary_lines as $cmd_line) {
+          $lines[] = "- {$cmd_line}";
+        }
+        $lines[] = '';
+      }
+
       // Bundles present
       $lines[] = '## Installed Bundles';
       $any_bundle_listed = false;
@@ -838,7 +1109,11 @@ function is_valid_source_dir($dir, $rule_files) {
   $update_content = "# Cursor Rules Installation\n\n";
   $update_content .= "**Version:** " . CURSOR_RULES_VERSION . "\n";
   $update_content .= "**Installation Date:** " . date('Y-m-d H:i:s T') . "\n";
-  $update_content .= "**Rules Installed:** " . $copied_count . " files\n\n";
+  $update_content .= "**Rules Installed:** " . $copied_count . " files\n";
+  if (!empty($command_summary_lines)) {
+    $update_content .= "**Commands:** " . implode(' | ', $command_summary_lines) . "\n";
+  }
+  $update_content .= "\n";
   
   if (($options['tags'] || $options['tag-preset']) && $filtered_count > 0) {
     $tag_expression = $options['tags'] ?: (TAG_PRESETS[$options['tag-preset']] ?? '');
@@ -873,6 +1148,10 @@ function is_valid_source_dir($dir, $rule_files) {
   } else {
     echo "Warning: Failed to create UPDATE.md file\n";
   }
+
+  if ($commands_temp_dir !== null && is_dir($commands_temp_dir)) {
+    delete_directory_recursive($commands_temp_dir);
+  }
   
   return true;
 }
@@ -955,6 +1234,241 @@ function evaluate_tag_expression($expression, $tags) {
   return true;
 }
 
+/**
+ * Determine if the provided directory contains command files.
+ *
+ * @param string $dir
+ * @return bool
+ */
+function is_valid_commands_source_dir($dir) {
+  if ($dir === false || !is_dir($dir)) {
+    return false;
+  }
+
+  $found = 0;
+  foreach (COMMAND_FILES as $command_file) {
+    if (file_exists(rtrim($dir, DIRECTORY_SEPARATOR) . DIRECTORY_SEPARATOR . $command_file)) {
+      $found++;
+      if ($found >= 3) {
+        return true;
+      }
+    }
+  }
+
+  return $found > 0;
+}
+
+/**
+ * Recursively copy a directory.
+ *
+ * @param string $source
+ * @param string $destination
+ * @return int Number of files copied, or -1 on failure.
+ */
+function copy_directory_recursive($source, $destination) {
+  if (!is_dir($source)) {
+    return -1;
+  }
+
+  $iterator = new RecursiveIteratorIterator(
+    new RecursiveDirectoryIterator($source, FilesystemIterator::SKIP_DOTS),
+    RecursiveIteratorIterator::SELF_FIRST
+  );
+
+  $copied = 0;
+
+  foreach ($iterator as $item) {
+    $target_path = $destination . DIRECTORY_SEPARATOR . $iterator->getSubPathName();
+
+    if ($item->isDir()) {
+      if (!is_dir($target_path) && !mkdir($target_path, 0755, true)) {
+        return -1;
+      }
+    } else {
+      $target_dir = dirname($target_path);
+      if (!is_dir($target_dir) && !mkdir($target_dir, 0755, true)) {
+        return -1;
+      }
+      if (!copy($item->getPathname(), $target_path)) {
+        return -1;
+      }
+      $copied++;
+    }
+  }
+
+  return $copied;
+}
+
+/**
+ * Recursively delete a directory.
+ *
+ * @param string $directory
+ * @return void
+ */
+function delete_directory_recursive($directory) {
+  if (!is_dir($directory)) {
+    return;
+  }
+
+  $iterator = new RecursiveIteratorIterator(
+    new RecursiveDirectoryIterator($directory, FilesystemIterator::SKIP_DOTS),
+    RecursiveIteratorIterator::CHILD_FIRST
+  );
+
+  foreach ($iterator as $fileinfo) {
+    if ($fileinfo->isDir()) {
+      @rmdir($fileinfo->getPathname());
+    } else {
+      @unlink($fileinfo->getPathname());
+    }
+  }
+
+  @rmdir($directory);
+}
+
+/**
+ * Determine the home directory of the current user.
+ *
+ * @return string|null
+ */
+function get_user_home_directory() {
+  $home = getenv('HOME') ?: ($_SERVER['HOME'] ?? null);
+
+  if (!$home && strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') {
+    $home = getenv('USERPROFILE');
+    if (!$home) {
+      $drive = getenv('HOMEDRIVE');
+      $path = getenv('HOMEPATH');
+      if ($drive && $path) {
+        $home = $drive . $path;
+      }
+    }
+  }
+
+  return $home ?: null;
+}
+
+/**
+ * Convert command installation targets to human-readable labels.
+ *
+ * @param string $target
+ * @return string
+ */
+function command_target_label($target) {
+  switch ($target) {
+    case 'home':
+      return 'home (~/.cursor/commands)';
+    case 'project':
+      return 'project (.cursor/commands)';
+    default:
+      return $target;
+  }
+}
+
+/**
+ * Summarise command installation results into human-readable lines.
+ *
+ * @param array $summary
+ * @return array
+ */
+function summarise_command_installation(array $summary) {
+  $groups = [
+    'installed' => [],
+    'existing' => [],
+    'skipped' => [],
+    'failed' => [],
+  ];
+
+  $notes = [];
+
+  foreach ($summary as $entry) {
+    $status = $entry['status'] ?? '';
+    $target = $entry['target'] ?? '';
+    $details = $entry['details'] ?? '';
+
+    if ($target === 'all') {
+      $notes[] = ucfirst($status) . ($details ? " ({$details})" : '');
+      continue;
+    }
+
+    if (isset($groups[$status])) {
+      $groups[$status][] = command_target_label($target);
+    } else {
+      $notes[] = ucfirst($status) . ' (' . command_target_label($target) . ')';
+    }
+
+    if (in_array($status, ['failed', 'skipped'], true) && $details) {
+      $notes[] = ucfirst($status) . ' ' . command_target_label($target) . ': ' . $details;
+    }
+  }
+
+  $lines = [];
+
+  if (!empty($groups['installed'])) {
+    $lines[] = 'Installed: ' . implode(', ', array_unique($groups['installed']));
+  }
+
+  if (!empty($groups['existing'])) {
+    $lines[] = 'Already present: ' . implode(', ', array_unique($groups['existing']));
+  }
+
+  if (!empty($groups['skipped'])) {
+    $lines[] = 'Skipped: ' . implode(', ', array_unique($groups['skipped']));
+  }
+
+  if (!empty($groups['failed'])) {
+    $lines[] = 'Failed: ' . implode(', ', array_unique($groups['failed']));
+  }
+
+  foreach (array_unique($notes) as $note) {
+    if ($note !== '') {
+      $lines[] = $note;
+    }
+  }
+
+  if (empty($lines)) {
+    $lines[] = 'No commands were installed.';
+  }
+
+  return $lines;
+}
+
+/**
+ * Safely read a trimmed line from STDIN.
+ *
+ * @return string
+ */
+function read_stdin_line() {
+  static $scripted_inputs = null;
+
+  if ($scripted_inputs === null) {
+    $env = getenv('CURSOR_INSTALLER_INPUT');
+    if ($env !== false && $env !== '') {
+      $normalized = str_replace(["\r\n", "\r"], "\n", $env);
+      $normalized = str_replace([',', ';', '|'], "\n", $normalized);
+      $scripted_inputs = explode("\n", $normalized);
+    } else {
+      $scripted_inputs = [];
+    }
+  }
+
+  if (!empty($scripted_inputs)) {
+    $value = array_shift($scripted_inputs);
+    return trim((string) $value);
+  }
+
+  if (!defined('STDIN') || !is_resource(STDIN)) {
+    return '';
+  }
+
+  $line = @fgets(STDIN);
+  if ($line === false) {
+    return '';
+  }
+
+  return trim($line);
+}
+
 /**
  * Display help information.
  */
@@ -974,6 +1488,8 @@ function show_help(): void {
   echo "  --tags=EXPR          Install rules matching tag expression (e.g., \"language:php category:security\")\n";
   echo "  --tag-preset=NAME    Use a predefined tag preset\n";
   echo "  --ignore-files=OPT   Control .cursorignore file installation (yes/no/ask, default: yes)\n";
+  echo "  --commands=OPT       Control slash command installation (project|home|both|skip; default installs to project)\n";
+  echo "  --skip-commands      Skip installing slash commands (alias for --commands=skip)\n";
   echo "\nTag Presets:\n";
   foreach (TAG_PRESETS as $name => $expression) {
     echo "  $name: $expression\n";
@@ -1003,6 +1519,7 @@ function show_help(): void {
     'tags' => false,
     'tag-preset' => false,
     'ignore-files' => 'yes',
+    'commands' => 'auto',
   ];
 
   // Check for command line arguments
@@ -1085,6 +1602,19 @@ function show_help(): void {
             exit(1);
           }
           break;
+        case '--commands':
+          if ($i + 1 < count($_SERVER['argv'])) {
+            $options['commands'] = strtolower($_SERVER['argv'][$i + 1]);
+            $i++;
+          } else {
+            echo "Error: --commands requires a value (project|home|both|skip)\n";
+            exit(1);
+          }
+          break;
+        case '--skip-commands':
+        case '--no-commands':
+          $options['commands'] = 'skip';
+          break;
         default:
           // Check for --destination=DIR format
           if (str_starts_with($arg, '--destination=')) {
@@ -1101,6 +1631,8 @@ function show_help(): void {
               echo "Warning: Invalid value for --ignore-files. Use yes, no, or ask.\n";
               exit(1);
             }
+          } else if (str_starts_with($arg, '--commands=')) {
+            $options['commands'] = strtolower(substr($arg, 11));
           } else {
             echo "Warning: Unknown option '$arg'\n";
             exit(1);
@@ -1123,7 +1655,7 @@ function show_help(): void {
   // Ask about cleanup if not in auto-yes mode and the file still exists
   if ($success && file_exists(__FILE__) && !$options['yes'] && function_exists('stream_isatty') && stream_isatty(STDIN)) {
     echo "\nWould you like to remove the installer file? (Y/n): ";
-    $response = strtolower(trim(fgets(STDIN)));
+    $response = strtolower(read_stdin_line());
     if ($response === '' || $response === 'y' || $response === 'yes') {
       unlink(__FILE__);
       echo "Installer file removed.\n";
@@ -1169,6 +1701,7 @@ function parseArguments() {
     'tags' => false,
     'tag-preset' => false,
     'ignore-files' => 'yes',
+    'commands' => 'auto',
   ];
   
   $option_count = 0;
@@ -1215,6 +1748,8 @@ function parseArguments() {
         echo "  --tags=EXPR         Install rules matching tag expression\n";
         echo "  --tag-preset=NAME   Use a predefined tag preset\n";
         echo "  --ignore-files=OPT  Control .cursorignore file installation (yes/no/ask)\n";
+        echo "  --commands=OPT      Control slash command installation (project|home|both|skip)\n";
+        echo "  --skip-commands     Skip installing slash commands\n";
         exit(0);
 
       case '--yes':
@@ -1247,6 +1782,18 @@ function parseArguments() {
         $options['debug'] = true;
         break;
 
+      case '--commands':
+        if ($i + 1 < $argc) {
+          $options['commands'] = strtolower($argv[$i + 1]);
+          $i++;
+        }
+        break;
+
+      case '--skip-commands':
+      case '--no-commands':
+        $options['commands'] = 'skip';
+        break;
+
       default:
         // Check for parameter=value format
         if (strpos($arg, '=') !== false) {
@@ -1268,6 +1815,9 @@ function parseArguments() {
                 $options['ignore-files'] = $value;
               }
               break;
+            case '--commands':
+              $options['commands'] = strtolower($value);
+              break;
           }
         }
         break;

From f33d5edc0585a64a118a0887ff281e2c704fa85e Mon Sep 17 00:00:00 2001
From: ivangrynenko <2966198+ivangrynenko@users.noreply.github.com>
Date: Fri, 24 Oct 2025 21:30:55 +1100
Subject: [PATCH 2/4] Update .cursor/commands/npm-audit-fix.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
---
 .cursor/commands/npm-audit-fix.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.cursor/commands/npm-audit-fix.md b/.cursor/commands/npm-audit-fix.md
index ba06b2f..98baa52 100644
--- a/.cursor/commands/npm-audit-fix.md
+++ b/.cursor/commands/npm-audit-fix.md
@@ -28,8 +28,8 @@ Before executing the remediation steps, wrap your analysis in <project_analysis>
 Before proceeding, make sure the PHP runtime has access to the same project files as the CLI container. The PHP image in this stack does not mount the module code by default, so you must manually sync the files before attempting any audits or Drupal commands:
 
 **Mandatory Container Sync (must be performed manually by the assistant)**
-- Identify the running PHP pod/container for the target environment. For Lagoon-based stacks use `kubectl get pods -l lagoon.sh/project=the project name,lagoon.sh/service=php` (or the equivalent `kubectl get pod` command provided by the platform). For local Docker Compose environments use `docker compose ps php` to confirm the container name.
-- Determine the CLI container name (typically `the project name` locally or the Lagoon CLI pod). This container has the authoritative Drupal codebase.
+- Identify the running PHP pod/container for the target environment. For Lagoon-based stacks use `kubectl get pods -l lagoon.sh/project=<project-name>,lagoon.sh/service=php` (or the equivalent `kubectl get pod` command provided by the platform). For local Docker Compose environments use `docker compose ps php` to confirm the container name.
+- Determine the CLI container name (typically `<project-name>` locally or the Lagoon CLI pod). This container has the authoritative Drupal codebase.
 - Copy the missing module directories from the CLI container to the PHP container so PHP can load them. Example (Docker): `docker cp $(docker compose ps -q cli):/app/web/modules/. $(docker compose ps -q php):/app/web/modules/` and repeat for any other required paths (e.g. `/app/vendor`, `/app/web/profiles`). Example (Lagoon/Kubernetes): `kubectl cp <cli-pod>:/app/web/modules <php-pod>:/app/web/modules -c php`.
 - Verify inside the PHP container that the expected module (e.g. `upgrade_status`) now exists under `/app/web/modules/contrib`. Do not restart or recreate containers; only manual copying is permitted.
 

From 90462bc258a9475c63bb8d37557dbb850a05633a Mon Sep 17 00:00:00 2001
From: ivangrynenko <2966198+ivangrynenko@users.noreply.github.com>
Date: Fri, 24 Oct 2025 21:31:21 +1100
Subject: [PATCH 3/4] Apply suggestion from @gemini-code-assist[bot]

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
---
 .cursor/commands/gh-issue-resolve.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.cursor/commands/gh-issue-resolve.md b/.cursor/commands/gh-issue-resolve.md
index e22cc19..c0434f6 100644
--- a/.cursor/commands/gh-issue-resolve.md
+++ b/.cursor/commands/gh-issue-resolve.md
@@ -34,7 +34,7 @@ Follow these steps:
 - When coding FrontEnd, use Playwright MCP to validate your work.
 - Document your changes in project documentation (README.md and /docs/ folder)
 - Update CHANGELOG.md file with listing the changes you're making, keep this file up to date and always validate to remove information that does not apply any longer.
-- Check for the linting tools available in the project's CLAUDE.md file.
+- Check for the linting tools available in the project's AGENTS.md file.
 - Use either playwright via MCP, or Unit, or behat to test the changes if you have made changes to the UI. If you are in a Drupal project, login via playwright browser, first execute `ahoy login` command and grab the one-time login URL as Drupal user #1. Then visit that URL to instantly login.
 - Run the full test suite to ensure you haven't broken anything
 - If the tests are failing, fix them, or the functionality.

From eac2b95ae87a8cbc942f6399ed42d913bc419089 Mon Sep 17 00:00:00 2001
From: ivangrynenko <2966198+ivangrynenko@users.noreply.github.com>
Date: Fri, 24 Oct 2025 21:32:11 +1100
Subject: [PATCH 4/4] Apply suggestion from @gemini-code-assist[bot]

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
---
 .cursor/commands/pr-assess.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.cursor/commands/pr-assess.md b/.cursor/commands/pr-assess.md
index 44fc3ea..466caaf 100644
--- a/.cursor/commands/pr-assess.md
+++ b/.cursor/commands/pr-assess.md
@@ -471,7 +471,7 @@ When reviewing, ensure you check:
 
 ## CRITICAL: Self-Improvement Protocol
 
-**MANDATORY**: After EVERY code review session, you MUST update this command file (`/Users/ivan/.claude/commands/pr.md`) with:
+**MANDATORY**: After EVERY code review session, you MUST update this command file (`pr-assess.md`) with:
 
 1. **New Technology Stacks Encountered**:
    - Add specific review criteria for any new frameworks/languages