rosslh/coolify
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Consolidate AI documentation into .ai/ directory

Browse source 
- Create .ai/ directory as single source of truth for all AI docs
- Organize by topic: core/, development/, patterns/, meta/
- Update CLAUDE.md to reference .ai/ files instead of embedding content
- Remove 18KB of duplicated Laravel Boost guidelines from CLAUDE.md
- Fix testing command descriptions (pest runs all tests, not just unit)
- Standardize version numbers (Laravel 12.4.1, PHP 8.4.7, Tailwind 4.1.4)
- Replace all .cursor/rules/*.mdc with single coolify-ai-docs.mdc reference
- Delete dev_workflow.mdc (non-Coolify Task Master content)
- Merge cursor_rules.mdc + self_improve.mdc into maintaining-docs.md
- Update .AI_INSTRUCTIONS_SYNC.md to redirect to new location

Benefits:
- Single source of truth - no more duplication
- Consistent versions across all documentation
- Better organization by topic
- Platform-agnostic .ai/ directory works for all AI tools
- Reduced CLAUDE.md from 719 to ~320 lines
- Clear cross-references between files
This commit is contained in:
Andras Bacsai 2025-11-18 14:58:59 +01:00
parent 375d8e79b4
commit 3f7c5fbdf9
22 changed files with 739 additions and 1311 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

165
.AI_INSTRUCTIONS_SYNC.md
View file

@ -1,156 +1,41 @@
# AI Instructions Synchronization Guide # AI Instructions Synchronization Guide
This document explains how AI instructions are organized and synchronized across different AI tools used with Coolify. **This file has moved!**
## Overview All AI documentation and synchronization guidelines are now in the `.ai/` directory.
Coolify maintains AI instructions in two parallel systems: ## New Locations
1. **CLAUDE.md** - For Claude Code (claude.ai/code) - **Sync Guide**: [.ai/meta/sync-guide.md](.ai/meta/sync-guide.md)
2. **.cursor/rules/** - For Cursor IDE and other AI assistants - **Maintaining Docs**: [.ai/meta/maintaining-docs.md](.ai/meta/maintaining-docs.md)
- **Documentation Hub**: [.ai/README.md](.ai/README.md)
Both systems share core principles but are optimized for their respective workflows. ## Quick Overview
## Structure All AI instructions are now organized in `.ai/` directory:
### CLAUDE.md
- **Purpose**: Condensed, workflow-focused guide for Claude Code
- **Format**: Single markdown file
- **Includes**:
- Quick-reference development commands
- High-level architecture overview
- Core patterns and guidelines
- Embedded Laravel Boost guidelines
- References to detailed .cursor/rules/ documentation
### .cursor/rules/
- **Purpose**: Detailed, topic-specific documentation
- **Format**: Multiple .mdc files organized by topic
- **Structure**:
- `README.mdc` - Main index and overview
- `cursor_rules.mdc` - Maintenance guidelines
- Topic-specific files (testing-patterns.mdc, security-patterns.mdc, etc.)
- **Used by**: Cursor IDE, Claude Code (for detailed reference), other AI assistants
## Cross-References
Both systems reference each other:
- **CLAUDE.md** → references `.cursor/rules/` for detailed documentation
- **.cursor/rules/README.mdc** → references `CLAUDE.md` for Claude Code workflow
- **.cursor/rules/cursor_rules.mdc** → notes that changes should sync with CLAUDE.md
## Maintaining Consistency
When updating AI instructions, follow these guidelines:
### 1. Core Principles (MUST be consistent)
- Laravel version (currently Laravel 12)
- PHP version (8.4)
- Testing execution rules (Docker for Feature tests, mocking for Unit tests)
- Security patterns and authorization requirements
- Code style requirements (Pint, PSR-12)
### 2. Where to Make Changes
**For workflow changes** (how to run commands, development setup):
- Primary: `CLAUDE.md`
- Secondary: `.cursor/rules/development-workflow.mdc`
**For architectural patterns** (how code should be structured):
- Primary: `.cursor/rules/` topic files
- Secondary: Reference in `CLAUDE.md` "Additional Documentation" section
**For testing patterns**:
- Both: Must be synchronized
- `CLAUDE.md` - Contains condensed testing execution rules
- `.cursor/rules/testing-patterns.mdc` - Contains detailed examples and patterns
### 3. Update Checklist
When making significant changes:
- [ ] Identify if change affects core principles (version numbers, critical patterns)
- [ ] Update primary location (CLAUDE.md or .cursor/rules/)
- [ ] Check if update affects cross-referenced content
- [ ] Update secondary location if needed
- [ ] Verify cross-references are still accurate
- [ ] Run: `./vendor/bin/pint CLAUDE.md .cursor/rules/*.mdc` (if applicable)
### 4. Common Inconsistencies to Watch
- **Version numbers**: Laravel, PHP, package versions
- **Testing instructions**: Docker execution requirements
- **File paths**: Ensure relative paths work from root
- **Command syntax**: Docker commands, artisan commands
- **Architecture decisions**: Laravel 10 structure vs Laravel 12+ structure
## File Organization
``` ```
/ .ai/
├── CLAUDE.md # Claude Code instructions (condensed) ├── README.md # Navigation hub
├── .AI_INSTRUCTIONS_SYNC.md # This file ├── core/ # Project information
└── .cursor/ ├── development/ # Dev workflows
└── rules/ ├── patterns/ # Code patterns
├── README.mdc # Index and overview └── meta/ # Documentation guides
├── cursor_rules.mdc # Maintenance guide
├── testing-patterns.mdc # Testing details
├── development-workflow.mdc # Dev setup details
├── security-patterns.mdc # Security details
├── application-architecture.mdc
├── deployment-architecture.mdc
├── database-patterns.mdc
├── frontend-patterns.mdc
├── api-and-routing.mdc
├── form-components.mdc
├── technology-stack.mdc
├── project-overview.mdc
└── laravel-boost.mdc # Laravel-specific patterns
``` ```
## Recent Updates ### For AI Assistants
### 2025-10-07 - **Claude Code**: Use `CLAUDE.md` (references `.ai/` files)
- ✅ Added cross-references between CLAUDE.md and .cursor/rules/ - **Cursor IDE**: Use `.cursor/rules/coolify-ai-docs.mdc` (references `.ai/` files)
- ✅ Synchronized Laravel version (12) across all files - **All Tools**: Browse `.ai/` directory for detailed documentation
- ✅ Added comprehensive testing execution rules (Docker for Feature tests)
- ✅ Added test design philosophy (prefer mocking over database)
- ✅ Fixed inconsistencies in testing documentation
- ✅ Created this synchronization guide
## Maintenance Commands ### Key Principles
```bash 1. **Single Source of Truth**: Each piece of information exists in ONE file only
# Check for version inconsistencies 2. **Cross-Reference**: Other files reference the source, don't duplicate
grep -r "Laravel [0-9]" CLAUDE.md .cursor/rules/*.mdc 3. **Organized by Topic**: Core, Development, Patterns, Meta
4. **Version Consistency**: All versions in `.ai/core/technology-stack.md`
# Check for PHP version consistency ## For More Information
grep -r "PHP [0-9]" CLAUDE.md .cursor/rules/*.mdc
# Format all documentation See [.ai/meta/sync-guide.md](.ai/meta/sync-guide.md) for complete synchronization guidelines and [.ai/meta/maintaining-docs.md](.ai/meta/maintaining-docs.md) for documentation maintenance instructions.
./vendor/bin/pint CLAUDE.md .cursor/rules/*.mdc
# Search for specific patterns across all docs
grep -r "pattern_to_check" CLAUDE.md .cursor/rules/
```
## Contributing
When contributing documentation:
1. Check both CLAUDE.md and .cursor/rules/ for existing documentation
2. Add to appropriate location(s) based on guidelines above
3. Add cross-references if creating new patterns
4. Update this file if changing organizational structure
5. Verify consistency before submitting PR
## Questions?
If unsure about where to document something:
- **Quick reference / workflow** → CLAUDE.md
- **Detailed patterns / examples** → .cursor/rules/[topic].mdc
- **Both?** → Start with .cursor/rules/, then reference in CLAUDE.md
When in doubt, prefer detailed documentation in .cursor/rules/ and concise references in CLAUDE.md.

141
.ai/README.md Normal file
View file

@ -0,0 +1,141 @@
# Coolify AI Documentation
Welcome to the Coolify AI documentation hub. This directory contains all AI assistant instructions organized by topic for easy navigation and maintenance.
## Quick Start
- **For Claude Code**: Start with [CLAUDE.md](CLAUDE.md)
- **For Cursor IDE**: Check `.cursor/rules/coolify-ai-docs.mdc` which references this directory
- **For Other AI Tools**: Continue reading below
## Documentation Structure
### 📚 Core Documentation
Essential project information and architecture:
- **[Technology Stack](core/technology-stack.md)** - All versions, packages, and dependencies (Laravel 12.4.1, PHP 8.4.7, etc.)
- **[Project Overview](core/project-overview.md)** - What Coolify is and how it works
- **[Application Architecture](core/application-architecture.md)** - System design and component relationships
- **[Deployment Architecture](core/deployment-architecture.md)** - How deployments work end-to-end
### 💻 Development
Day-to-day development practices:
- **[Workflow](development/development-workflow.md)** - Development setup, commands, and daily workflows
- **[Testing Patterns](development/testing-patterns.md)** - How to write and run tests (Unit vs Feature, Docker requirements)
- **[Laravel Boost](development/laravel-boost.md)** - Laravel-specific guidelines and best practices
### 🎨 Patterns
Code patterns and best practices by domain:
- **[Database Patterns](patterns/database-patterns.md)** - Eloquent, migrations, relationships
- **[Frontend Patterns](patterns/frontend-patterns.md)** - Livewire, Alpine.js, Tailwind CSS
- **[Security Patterns](patterns/security-patterns.md)** - Authentication, authorization, security best practices
- **[Form Components](patterns/form-components.md)** - Enhanced form components with authorization
- **[API & Routing](patterns/api-and-routing.md)** - API design, routing conventions, REST patterns
### 📖 Meta
Documentation about documentation:
- **[Maintaining Docs](meta/maintaining-docs.md)** - How to update and improve this documentation
- **[Sync Guide](meta/sync-guide.md)** - Keeping documentation synchronized across tools
## Quick Decision Tree
**What do you need help with?**
### Running Commands
→ [development/development-workflow.md](development/development-workflow.md)
- Frontend: `npm run dev`, `npm run build`
- Backend: `php artisan serve`, `php artisan migrate`
- Tests: Docker for Feature tests, mocking for Unit tests
- Code quality: `./vendor/bin/pint`, `./vendor/bin/phpstan`
### Writing Tests
→ [development/testing-patterns.md](development/testing-patterns.md)
- **Unit tests**: No database, use mocking, run outside Docker
- **Feature tests**: Can use database, must run inside Docker
- Command: `docker exec coolify php artisan test`
### Building UI
→ [patterns/frontend-patterns.md](patterns/frontend-patterns.md) or [patterns/form-components.md](patterns/form-components.md)
- Livewire components with server-side state
- Alpine.js for client-side interactivity
- Tailwind CSS 4.1.4 for styling
- Form components with built-in authorization
### Database Work
→ [patterns/database-patterns.md](patterns/database-patterns.md)
- Eloquent ORM patterns
- Migration best practices
- Relationship definitions
- Query optimization
### Security & Auth
→ [patterns/security-patterns.md](patterns/security-patterns.md)
- Team-based access control
- Policy and gate patterns
- Form authorization (canGate, canResource)
- API security
### Laravel-Specific Questions
→ [development/laravel-boost.md](development/laravel-boost.md)
- Laravel 12 patterns
- Livewire 3 best practices
- Pest testing patterns
- Laravel conventions
### Version Numbers
→ [core/technology-stack.md](core/technology-stack.md)
- **Single source of truth** for all version numbers
- Don't duplicate versions elsewhere, reference this file
## Navigation Tips
1. **Start broad**: Begin with project-overview or CLAUDE.md
2. **Get specific**: Navigate to topic-specific files for details
3. **Cross-reference**: Files link to related topics
4. **Single source**: Version numbers and critical data exist in ONE place only
## For AI Assistants
### Important Patterns to Follow
**Testing Commands:**
- Unit tests: `./vendor/bin/pest tests/Unit` (no database, outside Docker)
- Feature tests: `docker exec coolify php artisan test` (requires database, inside Docker)
- NEVER run Feature tests outside Docker - they will fail with database connection errors
**Version Numbers:**
- Always use exact versions from [technology-stack.md](core/technology-stack.md)
- Laravel 12.4.1, PHP 8.4.7, Tailwind 4.1.4
- Don't use "v12" or "8.4" - be precise
**Form Authorization:**
- ALWAYS include `canGate` and `:canResource` on form components
- See [form-components.md](patterns/form-components.md) for examples
**Livewire Components:**
- MUST have exactly ONE root element
- See [frontend-patterns.md](patterns/frontend-patterns.md) for details
**Code Style:**
- Run `./vendor/bin/pint` before finalizing changes
- Follow PSR-12 standards
- Use PHP 8.4 features (constructor promotion, typed properties, etc.)
## Contributing
When updating documentation:
1. Read [meta/maintaining-docs.md](meta/maintaining-docs.md)
2. Follow the single source of truth principle
3. Update cross-references when moving content
4. Test all links work
5. Run Pint on markdown files if applicable
## Questions?
- **Claude Code users**: Check [CLAUDE.md](CLAUDE.md) first
- **Cursor IDE users**: Check `.cursor/rules/coolify-ai-docs.mdc`
- **Documentation issues**: See [meta/maintaining-docs.md](meta/maintaining-docs.md)
- **Sync issues**: See [meta/sync-guide.md](meta/sync-guide.md)

5
.cursor/rules/application-architecture.mdc → .ai/core/application-architecture.md
View file

@ -1,8 +1,3 @@
---
description: Laravel application structure, patterns, and architectural decisions
globs: app/**/*.php, config/*.php, bootstrap/**/*.php
alwaysApply: false
---
# Coolify Application Architecture # Coolify Application Architecture
## Laravel Project Structure ## Laravel Project Structure

5
.cursor/rules/deployment-architecture.mdc → .ai/core/deployment-architecture.md
View file

@ -1,8 +1,3 @@
---
description: Docker orchestration, deployment workflows, and containerization patterns
globs: app/Jobs/*.php, app/Actions/Application/*.php, app/Actions/Server/*.php, docker/*.*, *.yml, *.yaml
alwaysApply: false
---
# Coolify Deployment Architecture # Coolify Deployment Architecture
## Deployment Philosophy ## Deployment Philosophy

5
.cursor/rules/project-overview.mdc → .ai/core/project-overview.md
View file

@ -1,8 +1,3 @@
---
description: High-level project mission, core concepts, and architectural overview
globs: README.md, CONTRIBUTING.md, CHANGELOG.md, *.md
alwaysApply: false
---
# Coolify Project Overview # Coolify Project Overview
## What is Coolify? ## What is Coolify?

79
.cursor/rules/technology-stack.mdc → .ai/core/technology-stack.md
View file

@ -1,14 +1,10 @@
---
description: Complete technology stack, dependencies, and infrastructure components
globs: composer.json, package.json, docker-compose*.yml, config/*.php
alwaysApply: false
---
# Coolify Technology Stack # Coolify Technology Stack
Complete technology stack, dependencies, and infrastructure components.
## Backend Framework ## Backend Framework
### **Laravel 12.4.1** (PHP Framework) ### **Laravel 12.4.1** (PHP Framework)
- **Location**: [composer.json](mdc:composer.json)
- **Purpose**: Core application framework - **Purpose**: Core application framework
- **Key Features**: - **Key Features**:
- Eloquent ORM for database interactions - Eloquent ORM for database interactions
@ -16,8 +12,8 @@ ### **Laravel 12.4.1** (PHP Framework)
- Queue system for background jobs - Queue system for background jobs
- Event-driven architecture - Event-driven architecture
### **PHP 8.4** ### **PHP 8.4.7**
- **Requirement**: `^8.4` in [composer.json](mdc:composer.json) - **Requirement**: `^8.4` in composer.json
- **Features Used**: - **Features Used**:
- Typed properties and return types - Typed properties and return types
- Attributes for validation and configuration - Attributes for validation and configuration
@ -28,11 +24,11 @@ ## Frontend Stack
### **Livewire 3.5.20** (Primary Frontend Framework) ### **Livewire 3.5.20** (Primary Frontend Framework)
- **Purpose**: Server-side rendering with reactive components - **Purpose**: Server-side rendering with reactive components
- **Location**: [app/Livewire/](mdc:app/Livewire/) - **Location**: `app/Livewire/`
- **Key Components**: - **Key Components**:
- [Dashboard.php](mdc:app/Livewire/Dashboard.php) - Main interface - Dashboard - Main interface
- [ActivityMonitor.php](mdc:app/Livewire/ActivityMonitor.php) - Real-time monitoring - ActivityMonitor - Real-time monitoring
- [MonacoEditor.php](mdc:app/Livewire/MonacoEditor.php) - Code editor - MonacoEditor - Code editor
### **Alpine.js** (Client-Side Interactivity) ### **Alpine.js** (Client-Side Interactivity)
- **Purpose**: Lightweight JavaScript for DOM manipulation - **Purpose**: Lightweight JavaScript for DOM manipulation
@ -40,8 +36,7 @@ ### **Alpine.js** (Client-Side Interactivity)
- **Usage**: Declarative directives in Blade templates - **Usage**: Declarative directives in Blade templates
### **Tailwind CSS 4.1.4** (Styling Framework) ### **Tailwind CSS 4.1.4** (Styling Framework)
- **Location**: [package.json](mdc:package.json) - **Configuration**: `postcss.config.cjs`
- **Configuration**: [postcss.config.cjs](mdc:postcss.config.cjs)
- **Extensions**: - **Extensions**:
- `@tailwindcss/forms` - Form styling - `@tailwindcss/forms` - Form styling
- `@tailwindcss/typography` - Content typography - `@tailwindcss/typography` - Content typography
@ -57,7 +52,7 @@ ## Database & Caching
### **PostgreSQL 15** (Primary Database) ### **PostgreSQL 15** (Primary Database)
- **Purpose**: Main application data storage - **Purpose**: Main application data storage
- **Features**: JSONB support, advanced indexing - **Features**: JSONB support, advanced indexing
- **Models**: [app/Models/](mdc:app/Models/) - **Models**: `app/Models/`
### **Redis 7** (Caching & Real-time) ### **Redis 7** (Caching & Real-time)
- **Purpose**: - **Purpose**:
@ -67,14 +62,14 @@ ### **Redis 7** (Caching & Real-time)
- WebSocket session management - WebSocket session management
### **Supported Databases** (For User Applications) ### **Supported Databases** (For User Applications)
- **PostgreSQL**: [StandalonePostgresql.php](mdc:app/Models/StandalonePostgresql.php) - **PostgreSQL**: StandalonePostgresql
- **MySQL**: [StandaloneMysql.php](mdc:app/Models/StandaloneMysql.php) - **MySQL**: StandaloneMysql
- **MariaDB**: [StandaloneMariadb.php](mdc:app/Models/StandaloneMariadb.php) - **MariaDB**: StandaloneMariadb
- **MongoDB**: [StandaloneMongodb.php](mdc:app/Models/StandaloneMongodb.php) - **MongoDB**: StandaloneMongodb
- **Redis**: [StandaloneRedis.php](mdc:app/Models/StandaloneRedis.php) - **Redis**: StandaloneRedis
- **KeyDB**: [StandaloneKeydb.php](mdc:app/Models/StandaloneKeydb.php) - **KeyDB**: StandaloneKeydb
- **Dragonfly**: [StandaloneDragonfly.php](mdc:app/Models/StandaloneDragonfly.php) - **Dragonfly**: StandaloneDragonfly
- **ClickHouse**: [StandaloneClickhouse.php](mdc:app/Models/StandaloneClickhouse.php) - **ClickHouse**: StandaloneClickhouse
## Authentication & Security ## Authentication & Security
@ -101,7 +96,7 @@ ### **Laravel Horizon 5.30.3**
### **Queue System** ### **Queue System**
- **Backend**: Redis-based queues - **Backend**: Redis-based queues
- **Jobs**: [app/Jobs/](mdc:app/Jobs/) - **Jobs**: `app/Jobs/`
- **Processing**: Background deployment and monitoring tasks - **Processing**: Background deployment and monitoring tasks
## Development Tools ## Development Tools
@ -130,21 +125,21 @@ ### **Git Providers**
- **Gitea**: Self-hosted Git service - **Gitea**: Self-hosted Git service
### **Cloud Storage** ### **Cloud Storage**
- **AWS S3**: [league/flysystem-aws-s3-v3](mdc:composer.json) - **AWS S3**: league/flysystem-aws-s3-v3
- **SFTP**: [league/flysystem-sftp-v3](mdc:composer.json) - **SFTP**: league/flysystem-sftp-v3
- **Local Storage**: File system integration - **Local Storage**: File system integration
### **Notification Services** ### **Notification Services**
- **Email**: [resend/resend-laravel](mdc:composer.json) - **Email**: resend/resend-laravel
- **Discord**: Custom webhook integration - **Discord**: Custom webhook integration
- **Slack**: Webhook notifications - **Slack**: Webhook notifications
- **Telegram**: Bot API integration - **Telegram**: Bot API integration
- **Pushover**: Push notifications - **Pushover**: Push notifications
### **Monitoring & Logging** ### **Monitoring & Logging**
- **Sentry**: [sentry/sentry-laravel](mdc:composer.json) - Error tracking - **Sentry**: sentry/sentry-laravel - Error tracking
- **Laravel Ray**: [spatie/laravel-ray](mdc:composer.json) - Debug tool - **Laravel Ray**: spatie/laravel-ray - Debug tool
- **Activity Log**: [spatie/laravel-activitylog](mdc:composer.json) - **Activity Log**: spatie/laravel-activitylog
## DevOps & Infrastructure ## DevOps & Infrastructure
@ -181,9 +176,9 @@ ### **Monaco Editor**
## API & Documentation ## API & Documentation
### **OpenAPI/Swagger** ### **OpenAPI/Swagger**
- **Documentation**: [openapi.json](mdc:openapi.json) (373KB) - **Documentation**: openapi.json (373KB)
- **Generator**: [zircote/swagger-php](mdc:composer.json) - **Generator**: zircote/swagger-php
- **API Routes**: [routes/api.php](mdc:routes/api.php) - **API Routes**: `routes/api.php`
### **WebSocket Communication** ### **WebSocket Communication**
- **Laravel Echo**: Real-time event broadcasting - **Laravel Echo**: Real-time event broadcasting
@ -192,7 +187,7 @@ ### **WebSocket Communication**
## Package Management ## Package Management
### **PHP Dependencies** ([composer.json](mdc:composer.json)) ### **PHP Dependencies** (composer.json)
```json ```json
{ {
"require": { "require": {
@ -205,7 +200,7 @@ ### **PHP Dependencies** ([composer.json](mdc:composer.json))
} }
``` ```
### **JavaScript Dependencies** ([package.json](mdc:package.json)) ### **JavaScript Dependencies** (package.json)
```json ```json
{ {
"devDependencies": { "devDependencies": {
@ -223,15 +218,15 @@ ### **JavaScript Dependencies** ([package.json](mdc:package.json))
## Configuration Files ## Configuration Files
### **Build Configuration** ### **Build Configuration**
- **[vite.config.js](mdc:vite.config.js)**: Frontend build setup - **vite.config.js**: Frontend build setup
- **[postcss.config.cjs](mdc:postcss.config.cjs)**: CSS processing - **postcss.config.cjs**: CSS processing
- **[rector.php](mdc:rector.php)**: PHP refactoring rules - **rector.php**: PHP refactoring rules
- **[pint.json](mdc:pint.json)**: Code style configuration - **pint.json**: Code style configuration
### **Testing Configuration** ### **Testing Configuration**
- **[phpunit.xml](mdc:phpunit.xml)**: Unit test configuration - **phpunit.xml**: Unit test configuration
- **[phpunit.dusk.xml](mdc:phpunit.dusk.xml)**: Browser test configuration - **phpunit.dusk.xml**: Browser test configuration
- **[tests/Pest.php](mdc:tests/Pest.php)**: Pest testing setup - **tests/Pest.php**: Pest testing setup
## Version Requirements ## Version Requirements

5
.cursor/rules/development-workflow.mdc → .ai/development/development-workflow.md
View file

@ -1,8 +1,3 @@
---
description: Development setup, coding standards, contribution guidelines, and best practices
globs: **/*.php, composer.json, package.json, *.md, .env.example
alwaysApply: false
---
# Coolify Development Workflow # Coolify Development Workflow
## Development Environment Setup ## Development Environment Setup

3
.cursor/rules/laravel-boost.mdc → .ai/development/laravel-boost.md
View file

@ -1,6 +1,3 @@
---
alwaysApply: true
---
<laravel-boost-guidelines> <laravel-boost-guidelines>
=== foundation rules === === foundation rules ===

5
.cursor/rules/testing-patterns.mdc → .ai/development/testing-patterns.md
View file

@ -1,8 +1,3 @@
---
description: Testing strategies with Pest PHP, Laravel Dusk, and quality assurance patterns
globs: tests/**/*.php, database/factories/*.php
alwaysApply: false
---
# Coolify Testing Architecture & Patterns # Coolify Testing Architecture & Patterns
> **Cross-Reference**: These detailed testing patterns align with the testing guidelines in **[CLAUDE.md](mdc:CLAUDE.md)**. Both documents share the same core principles about Docker execution and mocking preferences. > **Cross-Reference**: These detailed testing patterns align with the testing guidelines in **[CLAUDE.md](mdc:CLAUDE.md)**. Both documents share the same core principles about Docker execution and mocking preferences.

171
.ai/meta/maintaining-docs.md Normal file
View file

@ -0,0 +1,171 @@
# Maintaining AI Documentation
Guidelines for creating and maintaining AI documentation to ensure consistency and effectiveness across all AI tools (Claude Code, Cursor IDE, etc.).
## Documentation Structure
All AI documentation lives in the `.ai/` directory with the following structure:
```
.ai/
├── README.md # Navigation hub
├── CLAUDE.md # Main Claude Code instructions
├── core/ # Core project information
├── development/ # Development practices
├── patterns/ # Code patterns and best practices
└── meta/ # Documentation maintenance guides
```
## Required File Structure
When creating new documentation files:
```markdown
# Title
Brief description of what this document covers.
## Section 1
- **Main Points in Bold**
- Sub-points with details
- Examples and explanations
## Section 2
### Subsection
Content with code examples:
```language
// ✅ DO: Show good examples
const goodExample = true;
// ❌ DON'T: Show anti-patterns
const badExample = false;
```
```
## File References
- Use relative paths: `See [technology-stack.md](../core/technology-stack.md)`
- For code references: `` `app/Models/Application.php` ``
- Keep links working across different tools
## Content Guidelines
### DO:
- Start with high-level overview
- Include specific, actionable requirements
- Show examples of correct implementation
- Reference existing code when possible
- Keep documentation DRY by cross-referencing
- Use bullet points for clarity
- Include both DO and DON'T examples
### DON'T:
- Create theoretical examples when real code exists
- Duplicate content across multiple files
- Use tool-specific formatting that won't work elsewhere
- Make assumptions about versions - specify exact versions
## Rule Improvement Triggers
Update documentation when you notice:
- New code patterns not covered by existing docs
- Repeated similar implementations across files
- Common error patterns that could be prevented
- New libraries or tools being used consistently
- Emerging best practices in the codebase
## Analysis Process
When updating documentation:
1. Compare new code with existing rules
2. Identify patterns that should be standardized
3. Look for references to external documentation
4. Check for consistent error handling patterns
5. Monitor test patterns and coverage
## Rule Updates
### Add New Documentation When:
- A new technology/pattern is used in 3+ files
- Common bugs could be prevented by documentation
- Code reviews repeatedly mention the same feedback
- New security or performance patterns emerge
### Modify Existing Documentation When:
- Better examples exist in the codebase
- Additional edge cases are discovered
- Related documentation has been updated
- Implementation details have changed
## Quality Checks
Before committing documentation changes:
- [ ] Documentation is actionable and specific
- [ ] Examples come from actual code
- [ ] References are up to date
- [ ] Patterns are consistently enforced
- [ ] Cross-references work correctly
- [ ] Version numbers are exact and current
## Continuous Improvement
- Monitor code review comments
- Track common development questions
- Update docs after major refactors
- Add links to relevant documentation
- Cross-reference related docs
## Deprecation
When patterns become outdated:
1. Mark outdated patterns as deprecated
2. Remove docs that no longer apply
3. Update references to deprecated patterns
4. Document migration paths for old patterns
## Synchronization
### Single Source of Truth
- Each piece of information should exist in exactly ONE location
- Other files should reference the source, not duplicate it
- Example: Version numbers live in `core/technology-stack.md`, other files reference it
### Cross-Tool Compatibility
- **CLAUDE.md**: Main instructions for Claude Code users (references `.ai/` files)
- **.cursor/rules/**: Single master file pointing to `.ai/` documentation
- **Both tools**: Should get same information from `.ai/` directory
### When to Update What
**Version Changes** (Laravel, PHP, packages):
1. Update `core/technology-stack.md` (single source)
2. Verify CLAUDE.md references it correctly
3. No other files should duplicate version numbers
**Workflow Changes** (commands, setup):
1. Update `development/workflow.md`
2. Ensure CLAUDE.md quick reference is updated
3. Verify all cross-references work
**Pattern Changes** (how to write code):
1. Update appropriate file in `patterns/`
2. Add/update examples from real codebase
3. Cross-reference from related docs
## Documentation Files
Keep documentation files only when explicitly needed. Don't create docs that merely describe obvious functionality - the code itself should be clear.
## Breaking Changes
When making breaking changes to documentation structure:
1. Update this maintaining-docs.md file
2. Update `.ai/README.md` navigation
3. Update CLAUDE.md references
4. Update `.cursor/rules/coolify-ai-docs.mdc`
5. Test all cross-references still work
6. Document the changes in sync-guide.md

156
.ai/meta/sync-guide.md Normal file
View file

@ -0,0 +1,156 @@
# AI Instructions Synchronization Guide
This document explains how AI instructions are organized and synchronized across different AI tools used with Coolify.
## Overview
Coolify maintains AI instructions in two parallel systems:
1. **CLAUDE.md** - For Claude Code (claude.ai/code)
2. **.cursor/rules/** - For Cursor IDE and other AI assistants
Both systems share core principles but are optimized for their respective workflows.
## Structure
### CLAUDE.md
- **Purpose**: Condensed, workflow-focused guide for Claude Code
- **Format**: Single markdown file
- **Includes**:
- Quick-reference development commands
- High-level architecture overview
- Core patterns and guidelines
- Embedded Laravel Boost guidelines
- References to detailed .cursor/rules/ documentation
### .cursor/rules/
- **Purpose**: Detailed, topic-specific documentation
- **Format**: Multiple .mdc files organized by topic
- **Structure**:
- `README.mdc` - Main index and overview
- `cursor_rules.mdc` - Maintenance guidelines
- Topic-specific files (testing-patterns.mdc, security-patterns.mdc, etc.)
- **Used by**: Cursor IDE, Claude Code (for detailed reference), other AI assistants
## Cross-References
Both systems reference each other:
- **CLAUDE.md** → references `.cursor/rules/` for detailed documentation
- **.cursor/rules/README.mdc** → references `CLAUDE.md` for Claude Code workflow
- **.cursor/rules/cursor_rules.mdc** → notes that changes should sync with CLAUDE.md
## Maintaining Consistency
When updating AI instructions, follow these guidelines:
### 1. Core Principles (MUST be consistent)
- Laravel version (currently Laravel 12)
- PHP version (8.4)
- Testing execution rules (Docker for Feature tests, mocking for Unit tests)
- Security patterns and authorization requirements
- Code style requirements (Pint, PSR-12)
### 2. Where to Make Changes
**For workflow changes** (how to run commands, development setup):
- Primary: `CLAUDE.md`
- Secondary: `.cursor/rules/development-workflow.mdc`
**For architectural patterns** (how code should be structured):
- Primary: `.cursor/rules/` topic files
- Secondary: Reference in `CLAUDE.md` "Additional Documentation" section
**For testing patterns**:
- Both: Must be synchronized
- `CLAUDE.md` - Contains condensed testing execution rules
- `.cursor/rules/testing-patterns.mdc` - Contains detailed examples and patterns
### 3. Update Checklist
When making significant changes:
- [ ] Identify if change affects core principles (version numbers, critical patterns)
- [ ] Update primary location (CLAUDE.md or .cursor/rules/)
- [ ] Check if update affects cross-referenced content
- [ ] Update secondary location if needed
- [ ] Verify cross-references are still accurate
- [ ] Run: `./vendor/bin/pint CLAUDE.md .cursor/rules/*.mdc` (if applicable)
### 4. Common Inconsistencies to Watch
- **Version numbers**: Laravel, PHP, package versions
- **Testing instructions**: Docker execution requirements
- **File paths**: Ensure relative paths work from root
- **Command syntax**: Docker commands, artisan commands
- **Architecture decisions**: Laravel 10 structure vs Laravel 12+ structure
## File Organization
```
/
├── CLAUDE.md # Claude Code instructions (condensed)
├── .AI_INSTRUCTIONS_SYNC.md # This file
└── .cursor/
└── rules/
├── README.mdc # Index and overview
├── cursor_rules.mdc # Maintenance guide
├── testing-patterns.mdc # Testing details
├── development-workflow.mdc # Dev setup details
├── security-patterns.mdc # Security details
├── application-architecture.mdc
├── deployment-architecture.mdc
├── database-patterns.mdc
├── frontend-patterns.mdc
├── api-and-routing.mdc
├── form-components.mdc
├── technology-stack.mdc
├── project-overview.mdc
└── laravel-boost.mdc # Laravel-specific patterns
```
## Recent Updates
### 2025-10-07
- ✅ Added cross-references between CLAUDE.md and .cursor/rules/
- ✅ Synchronized Laravel version (12) across all files
- ✅ Added comprehensive testing execution rules (Docker for Feature tests)
- ✅ Added test design philosophy (prefer mocking over database)
- ✅ Fixed inconsistencies in testing documentation
- ✅ Created this synchronization guide
## Maintenance Commands
```bash
# Check for version inconsistencies
grep -r "Laravel [0-9]" CLAUDE.md .cursor/rules/*.mdc
# Check for PHP version consistency
grep -r "PHP [0-9]" CLAUDE.md .cursor/rules/*.mdc
# Format all documentation
./vendor/bin/pint CLAUDE.md .cursor/rules/*.mdc
# Search for specific patterns across all docs
grep -r "pattern_to_check" CLAUDE.md .cursor/rules/
```
## Contributing
When contributing documentation:
1. Check both CLAUDE.md and .cursor/rules/ for existing documentation
2. Add to appropriate location(s) based on guidelines above
3. Add cross-references if creating new patterns
4. Update this file if changing organizational structure
5. Verify consistency before submitting PR
## Questions?
If unsure about where to document something:
- **Quick reference / workflow** → CLAUDE.md
- **Detailed patterns / examples** → .cursor/rules/[topic].mdc
- **Both?** → Start with .cursor/rules/, then reference in CLAUDE.md
When in doubt, prefer detailed documentation in .cursor/rules/ and concise references in CLAUDE.md.

5
.cursor/rules/api-and-routing.mdc → .ai/patterns/api-and-routing.md
View file

@ -1,8 +1,3 @@
---
description: RESTful API design, routing patterns, webhooks, and HTTP communication
globs: routes/*.php, app/Http/Controllers/**/*.php, app/Http/Resources/*.php, app/Http/Requests/*.php
alwaysApply: false
---
# Coolify API & Routing Architecture # Coolify API & Routing Architecture
## Routing Structure ## Routing Structure

5
.cursor/rules/database-patterns.mdc → .ai/patterns/database-patterns.md
View file

@ -1,8 +1,3 @@
---
description: Database architecture, models, migrations, relationships, and data management patterns
globs: app/Models/*.php, database/migrations/*.php, database/seeders/*.php, app/Actions/Database/*.php
alwaysApply: false
---
# Coolify Database Architecture & Patterns # Coolify Database Architecture & Patterns
## Database Strategy ## Database Strategy

5
.cursor/rules/form-components.mdc → .ai/patterns/form-components.md
View file

@ -1,8 +1,3 @@
---
description: Enhanced form components with built-in authorization system
globs: resources/views/**/*.blade.php, app/View/Components/Forms/*.php
alwaysApply: true
---
# Enhanced Form Components with Authorization # Enhanced Form Components with Authorization

5
.cursor/rules/frontend-patterns.mdc → .ai/patterns/frontend-patterns.md
View file

@ -1,8 +1,3 @@
---
description: Livewire components, Alpine.js patterns, Tailwind CSS, and enhanced form components
globs: app/Livewire/**/*.php, resources/views/**/*.blade.php, resources/js/**/*.js, resources/css/**/*.css
alwaysApply: false
---
# Coolify Frontend Architecture & Patterns # Coolify Frontend Architecture & Patterns
## Frontend Philosophy ## Frontend Philosophy

5
.cursor/rules/security-patterns.mdc → .ai/patterns/security-patterns.md
View file

@ -1,8 +1,3 @@
---
description: Security architecture, authentication, authorization patterns, and enhanced form component security
globs: app/Policies/*.php, app/View/Components/Forms/*.php, app/Http/Middleware/*.php, resources/views/**/*.blade.php
alwaysApply: true
---
# Coolify Security Architecture & Patterns # Coolify Security Architecture & Patterns
## Security Philosophy ## Security Philosophy

297
.cursor/rules/README.mdc
View file

@ -1,297 +0,0 @@
---
description: Complete guide to Coolify Cursor rules and development patterns
globs: .cursor/rules/*.mdc
alwaysApply: false
---
# Coolify Cursor Rules - Complete Guide
## Overview
This comprehensive set of Cursor Rules provides deep insights into **Coolify**, an open-source self-hostable alternative to Heroku/Netlify/Vercel. These rules will help you understand, navigate, and contribute to this complex Laravel-based deployment platform.
> **Cross-Reference**: This directory is for **detailed, topic-specific rules** used by Cursor IDE and other AI assistants. For Claude Code specifically, also see **[CLAUDE.md](mdc:CLAUDE.md)** which provides a condensed, workflow-focused guide. Both systems share core principles but are optimized for their respective tools.
>
> **Maintaining Rules**: When updating these rules, see **[.AI_INSTRUCTIONS_SYNC.md](mdc:.AI_INSTRUCTIONS_SYNC.md)** for synchronization guidelines to keep CLAUDE.md and .cursor/rules/ consistent.
## Rule Categories
### 🏗️ Architecture & Foundation
- **[project-overview.mdc](mdc:.cursor/rules/project-overview.mdc)** - What Coolify is and its core mission
- **[technology-stack.mdc](mdc:.cursor/rules/technology-stack.mdc)** - Complete technology stack and dependencies
- **[application-architecture.mdc](mdc:.cursor/rules/application-architecture.mdc)** - Laravel application structure and patterns
### 🎨 Frontend Development
- **[frontend-patterns.mdc](mdc:.cursor/rules/frontend-patterns.mdc)** - Livewire + Alpine.js + Tailwind architecture
- **[form-components.mdc](mdc:.cursor/rules/form-components.mdc)** - Enhanced form components with built-in authorization
### 🗄️ Data & Backend
- **[database-patterns.mdc](mdc:.cursor/rules/database-patterns.mdc)** - Database architecture, models, and data management
- **[deployment-architecture.mdc](mdc:.cursor/rules/deployment-architecture.mdc)** - Docker orchestration and deployment workflows
### 🌐 API & Communication
- **[api-and-routing.mdc](mdc:.cursor/rules/api-and-routing.mdc)** - RESTful APIs, webhooks, and routing patterns
### 🧪 Quality Assurance
- **[testing-patterns.mdc](mdc:.cursor/rules/testing-patterns.mdc)** - Testing strategies with Pest PHP and Laravel Dusk
### 🔧 Development Process
- **[development-workflow.mdc](mdc:.cursor/rules/development-workflow.mdc)** - Development setup, coding standards, and contribution guidelines
### 🔒 Security
- **[security-patterns.mdc](mdc:.cursor/rules/security-patterns.mdc)** - Security architecture, authentication, and best practices
## Quick Navigation
### Core Application Files
- **[app/Models/Application.php](mdc:app/Models/Application.php)** - Main application entity (74KB, highly complex)
- **[app/Models/Server.php](mdc:app/Models/Server.php)** - Server management (46KB, complex)
- **[app/Models/Service.php](mdc:app/Models/Service.php)** - Service definitions (58KB, complex)
- **[app/Models/Team.php](mdc:app/Models/Team.php)** - Multi-tenant structure (8.9KB)
### Configuration Files
- **[composer.json](mdc:composer.json)** - PHP dependencies and Laravel setup
- **[package.json](mdc:package.json)** - Frontend dependencies and build scripts
- **[vite.config.js](mdc:vite.config.js)** - Frontend build configuration
- **[docker-compose.dev.yml](mdc:docker-compose.dev.yml)** - Development environment
### API Documentation
- **[openapi.json](mdc:openapi.json)** - Complete API documentation (373KB)
- **[routes/api.php](mdc:routes/api.php)** - API endpoint definitions (13KB)
- **[routes/web.php](mdc:routes/web.php)** - Web application routes (21KB)
## Key Concepts to Understand
### 1. Multi-Tenant Architecture
Coolify uses a **team-based multi-tenancy** model where:
- Users belong to multiple teams
- Resources are scoped to teams
- Access control is team-based
- Data isolation is enforced at the database level
### 2. Deployment Philosophy
- **Docker-first** approach for all deployments
- **Zero-downtime** deployments with health checks
- **Git-based** workflows with webhook integration
- **Multi-server** support with SSH connections
### 3. Technology Stack
- **Backend**: Laravel 12 + PHP 8.4
- **Frontend**: Livewire 3.5 + Alpine.js + Tailwind CSS 4.1
- **Database**: PostgreSQL 15 + Redis 7
- **Containerization**: Docker + Docker Compose
- **Testing**: Pest PHP 3.8 + Laravel Dusk
### 4. Security Model
- **Defense-in-depth** security architecture
- **OAuth integration** with multiple providers
- **API token** authentication with Sanctum
- **Encrypted storage** for sensitive data
- **SSH key** management for server access
## Development Quick Start
### Local Setup
```bash
# Clone and setup
git clone https://github.com/coollabsio/coolify.git
cd coolify
cp .env.example .env
# Docker development (recommended)
docker-compose -f docker-compose.dev.yml up -d
docker-compose exec app composer install
docker-compose exec app npm install
docker-compose exec app php artisan migrate
```
### Code Quality
```bash
# PHP code style
./vendor/bin/pint
# Static analysis
./vendor/bin/phpstan analyse
# Run tests
./vendor/bin/pest
```
## Common Patterns
### Livewire Components
```php
class ApplicationShow extends Component
{
public Application $application;
protected $listeners = [
'deployment.started' => 'refresh',
'deployment.completed' => 'refresh',
];
public function deploy(): void
{
$this->authorize('deploy', $this->application);
app(ApplicationDeploymentService::class)->deploy($this->application);
}
}
```
### API Controllers
```php
class ApplicationController extends Controller
{
public function __construct()
{
$this->middleware('auth:sanctum');
$this->middleware('team.access');
}
public function deploy(Application $application): JsonResponse
{
$this->authorize('deploy', $application);
$deployment = app(ApplicationDeploymentService::class)->deploy($application);
return response()->json(['deployment_id' => $deployment->id]);
}
}
```
### Queue Jobs
```php
class DeployApplicationJob implements ShouldQueue
{
public function handle(DockerService $dockerService): void
{
$this->deployment->update(['status' => 'running']);
try {
$dockerService->deployContainer($this->deployment->application);
$this->deployment->update(['status' => 'success']);
} catch (Exception $e) {
$this->deployment->update(['status' => 'failed']);
throw $e;
}
}
}
```
## Testing Patterns
### Feature Tests
```php
test('user can deploy application via API', function () {
$user = User::factory()->create();
$application = Application::factory()->create(['team_id' => $user->currentTeam->id]);
$response = $this->actingAs($user)
->postJson("/api/v1/applications/{$application->id}/deploy");
$response->assertStatus(200);
expect($application->deployments()->count())->toBe(1);
});
```
### Browser Tests
```php
test('user can create application through UI', function () {
$user = User::factory()->create();
$this->browse(function (Browser $browser) use ($user) {
$browser->loginAs($user)
->visit('/applications/create')
->type('name', 'Test App')
->press('Create Application')
->assertSee('Application created successfully');
});
});
```
## Security Considerations
### Authentication
- Multi-provider OAuth support
- API token authentication
- Team-based access control
- Session management
### Data Protection
- Encrypted environment variables
- Secure SSH key storage
- Input validation and sanitization
- SQL injection prevention
### Container Security
- Non-root container users
- Minimal capabilities
- Read-only filesystems
- Network isolation
## Performance Optimization
### Database
- Eager loading relationships
- Query optimization
- Connection pooling
- Caching strategies
### Frontend
- Lazy loading components
- Asset optimization
- CDN integration
- Real-time updates via WebSockets
## Contributing Guidelines
### Code Standards
- PSR-12 PHP coding standards
- Laravel best practices
- Comprehensive test coverage
- Security-first approach
### Pull Request Process
1. Fork repository
2. Create feature branch
3. Implement with tests
4. Run quality checks
5. Submit PR with clear description
## Useful Commands
### Development
```bash
# Start development environment
docker-compose -f docker-compose.dev.yml up -d
# Run tests
./vendor/bin/pest
# Code formatting
./vendor/bin/pint
# Frontend development
npm run dev
```
### Production
```bash
# Install Coolify
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
# Update Coolify
./scripts/upgrade.sh
```
## Resources
### Documentation
- **[README.md](mdc:README.md)** - Project overview and installation
- **[CONTRIBUTING.md](mdc:CONTRIBUTING.md)** - Contribution guidelines
- **[CHANGELOG.md](mdc:CHANGELOG.md)** - Release history
- **[TECH_STACK.md](mdc:TECH_STACK.md)** - Technology overview
### Configuration
- **[config/](mdc:config)** - Laravel configuration files
- **[database/migrations/](mdc:database/migrations)** - Database schema
- **[tests/](mdc:tests)** - Test suite
This comprehensive rule set provides everything needed to understand, develop, and contribute to the Coolify project effectively. Each rule focuses on specific aspects while maintaining connections to the broader architecture.

156
.cursor/rules/coolify-ai-docs.mdc Normal file
View file

@ -0,0 +1,156 @@
---
title: Coolify AI Documentation
description: Master reference to all Coolify AI documentation in .ai/ directory
globs: **/*
alwaysApply: true
---
# Coolify AI Documentation
All Coolify AI documentation has been consolidated in the **`.ai/`** directory for better organization and single source of truth.
## Quick Start
- **For Claude Code**: Start with `CLAUDE.md` in the root directory
- **For Cursor IDE**: Start with `.ai/README.md` for navigation
- **For All AI Tools**: Browse `.ai/` directory by topic
## Documentation Structure
All detailed documentation lives in `.ai/` with the following organization:
### 📚 Core Documentation
- **[Technology Stack](.ai/core/technology-stack.md)** - All versions, packages, dependencies (SINGLE SOURCE OF TRUTH for versions)
- **[Project Overview](.ai/core/project-overview.md)** - What Coolify is, high-level architecture
- **[Application Architecture](.ai/core/application-architecture.md)** - System design, components, relationships
- **[Deployment Architecture](.ai/core/deployment-architecture.md)** - Deployment flows, Docker, proxies
### 💻 Development
- **[Development Workflow](.ai/development/development-workflow.md)** - Dev setup, commands, daily workflows
- **[Testing Patterns](.ai/development/testing-patterns.md)** - How to write/run tests, Docker requirements
- **[Laravel Boost](.ai/development/laravel-boost.md)** - Laravel-specific guidelines (SINGLE SOURCE for Laravel Boost)
### 🎨 Code Patterns
- **[Database Patterns](.ai/patterns/database-patterns.md)** - Eloquent, migrations, relationships
- **[Frontend Patterns](.ai/patterns/frontend-patterns.md)** - Livewire, Alpine.js, Tailwind CSS
- **[Security Patterns](.ai/patterns/security-patterns.md)** - Auth, authorization, security
- **[Form Components](.ai/patterns/form-components.md)** - Enhanced forms with authorization
- **[API & Routing](.ai/patterns/api-and-routing.md)** - API design, routing conventions
### 📖 Meta
- **[Maintaining Docs](.ai/meta/maintaining-docs.md)** - How to update/improve documentation
- **[Sync Guide](.ai/meta/sync-guide.md)** - Keeping docs synchronized
## Quick Decision Tree
**What are you working on?**
### Running Commands
→ `.ai/development/development-workflow.md`
- `npm run dev` / `npm run build` - Frontend
- `php artisan serve` / `php artisan migrate` - Backend
- `docker exec coolify php artisan test` - Feature tests (requires Docker)
- `./vendor/bin/pest tests/Unit` - Unit tests (no Docker needed)
- `./vendor/bin/pint` - Code formatting
### Writing Tests
→ `.ai/development/testing-patterns.md`
- **Unit tests**: No database, use mocking, run outside Docker
- **Feature tests**: Can use database, MUST run inside Docker
- Critical: Docker execution requirements prevent database connection errors
### Building UI
→ `.ai/patterns/frontend-patterns.md` + `.ai/patterns/form-components.md`
- Livewire 3.5.20 with server-side state
- Alpine.js for client interactions
- Tailwind CSS 4.1.4 styling
- Form components with `canGate` authorization
### Database Work
→ `.ai/patterns/database-patterns.md`
- Eloquent ORM patterns
- Migration best practices
- Relationship definitions
- Query optimization
### Security & Authorization
→ `.ai/patterns/security-patterns.md` + `.ai/patterns/form-components.md`
- Team-based access control
- Policy and gate patterns
- Form authorization (`canGate`, `canResource`)
- API security with Sanctum
### Laravel-Specific
→ `.ai/development/laravel-boost.md`
- Laravel 12.4.1 patterns
- Livewire 3 best practices
- Pest testing patterns
- Laravel conventions
### Version Numbers
→ `.ai/core/technology-stack.md`
- **SINGLE SOURCE OF TRUTH** for all version numbers
- Laravel 12.4.1, PHP 8.4.7, Tailwind 4.1.4, etc.
- Never duplicate versions - always reference this file
## Critical Patterns (Always Follow)
### Testing Commands
```bash
# Unit tests (no database, outside Docker)
./vendor/bin/pest tests/Unit
# Feature tests (requires database, inside Docker)
docker exec coolify php artisan test
```
**NEVER** run Feature tests outside Docker - they will fail with database connection errors.
### Form Authorization
ALWAYS include authorization on form components:
```blade
<x-forms.input canGate="update" :canResource="$resource" id="name" label="Name" />
```
### Livewire Components
MUST have exactly ONE root element. No exceptions.
### Version Numbers
Use exact versions from `technology-stack.md`:
- ✅ Laravel 12.4.1
- ❌ Laravel 12 or "v12"
### Code Style
```bash
# Always run before committing
./vendor/bin/pint
```
## For AI Assistants
### Important Notes
1. **Single Source of Truth**: Each piece of information exists in ONE location only
2. **Cross-Reference, Don't Duplicate**: Link to other files instead of copying content
3. **Version Precision**: Always use exact versions from `technology-stack.md`
4. **Docker for Feature Tests**: This is non-negotiable for database-dependent tests
5. **Form Authorization**: Security requirement, not optional
### When to Use Which File
- **Quick commands**: `CLAUDE.md` or `development-workflow.md`
- **Detailed patterns**: Topic-specific files in `.ai/patterns/`
- **Testing**: `.ai/development/testing-patterns.md`
- **Laravel specifics**: `.ai/development/laravel-boost.md`
- **Versions**: `.ai/core/technology-stack.md`
## Maintaining Documentation
When updating documentation:
1. Read `.ai/meta/maintaining-docs.md` first
2. Follow single source of truth principle
3. Update cross-references when moving content
4. Test all links work
5. See `.ai/meta/sync-guide.md` for sync guidelines
## Migration Note
This file replaces all previous `.cursor/rules/*.mdc` files. All content has been migrated to `.ai/` directory for better organization and to serve as single source of truth for all AI tools (Claude Code, Cursor IDE, etc.).

59
.cursor/rules/cursor_rules.mdc
View file

@ -1,59 +0,0 @@
---
description: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness.
globs: .cursor/rules/*.mdc
alwaysApply: true
---
# Cursor Rules Maintenance Guide
> **Important**: These rules in `.cursor/rules/` are shared between Cursor IDE and other AI assistants. Changes here should be reflected in **[CLAUDE.md](mdc:CLAUDE.md)** when they affect core workflows or patterns.
>
> **Synchronization Guide**: See **[.AI_INSTRUCTIONS_SYNC.md](mdc:.AI_INSTRUCTIONS_SYNC.md)** for detailed guidelines on maintaining consistency between CLAUDE.md and .cursor/rules/.
- **Required Rule Structure:**
```markdown
---
description: Clear, one-line description of what the rule enforces
globs: path/to/files/*.ext, other/path/**/*
alwaysApply: boolean
---
- **Main Points in Bold**
- Sub-points with details
- Examples and explanations
```
- **File References:**
- Use `[filename](mdc:path/to/file)` ([filename](mdc:filename)) to reference files
- Example: [prisma.mdc](mdc:.cursor/rules/prisma.mdc) for rule references
- Example: [schema.prisma](mdc:prisma/schema.prisma) for code references
- **Code Examples:**
- Use language-specific code blocks
```typescript
// ✅ DO: Show good examples
const goodExample = true;
// ❌ DON'T: Show anti-patterns
const badExample = false;
```
- **Rule Content Guidelines:**
- Start with high-level overview
- Include specific, actionable requirements
- Show examples of correct implementation
- Reference existing code when possible
- Keep rules DRY by referencing other rules
- **Rule Maintenance:**
- Update rules when new patterns emerge
- Add examples from actual codebase
- Remove outdated patterns
- Cross-reference related rules
- **Best Practices:**
- Use bullet points for clarity
- Keep descriptions concise
- Include both DO and DON'T examples
- Reference actual code over theoretical examples
- Use consistent formatting across rules

219
.cursor/rules/dev_workflow.mdc
View file

@ -1,219 +0,0 @@
---
description: Guide for using Task Master to manage task-driven development workflows
globs: **/*
alwaysApply: true
---
# Task Master Development Workflow
This guide outlines the typical process for using Task Master to manage software development projects.
## Primary Interaction: MCP Server vs. CLI
Task Master offers two primary ways to interact:
1. **MCP Server (Recommended for Integrated Tools)**:
- For AI agents and integrated development environments (like Cursor), interacting via the **MCP server is the preferred method**.
- The MCP server exposes Task Master functionality through a set of tools (e.g., `get_tasks`, `add_subtask`).
- This method offers better performance, structured data exchange, and richer error handling compared to CLI parsing.
- Refer to [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for details on the MCP architecture and available tools.
- A comprehensive list and description of MCP tools and their corresponding CLI commands can be found in [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc).
- **Restart the MCP server** if core logic in `scripts/modules` or MCP tool/direct function definitions change.
2. **`task-master` CLI (For Users & Fallback)**:
- The global `task-master` command provides a user-friendly interface for direct terminal interaction.
- It can also serve as a fallback if the MCP server is inaccessible or a specific function isn't exposed via MCP.
- Install globally with `npm install -g task-master-ai` or use locally via `npx task-master-ai ...`.
- The CLI commands often mirror the MCP tools (e.g., `task-master list` corresponds to `get_tasks`).
- Refer to [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc) for a detailed command reference.
## Standard Development Workflow Process
- Start new projects by running `initialize_project` tool / `task-master init` or `parse_prd` / `task-master parse-prd --input='<prd-file.txt>'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to generate initial tasks.json
- Begin coding sessions with `get_tasks` / `task-master list` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to see current tasks, status, and IDs
- Determine the next task to work on using `next_task` / `task-master next` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
- Analyze task complexity with `analyze_project_complexity` / `task-master analyze-complexity --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) before breaking down tasks
- Review complexity report using `complexity_report` / `task-master complexity-report` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
- Select tasks based on dependencies (all marked 'done'), priority level, and ID order
- Clarify tasks by checking task files in tasks/ directory or asking for user input
- View specific task details using `get_task` / `task-master show <id>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to understand implementation requirements
- Break down complex tasks using `expand_task` / `task-master expand --id=<id> --force --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) with appropriate flags like `--force` (to replace existing subtasks) and `--research`.
- Clear existing subtasks if needed using `clear_subtasks` / `task-master clear-subtasks --id=<id>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) before regenerating
- Implement code following task details, dependencies, and project standards
- Verify tasks according to test strategies before marking as complete (See [`tests.mdc`](mdc:.cursor/rules/tests.mdc))
- Mark completed tasks with `set_task_status` / `task-master set-status --id=<id> --status=done` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc))
- Update dependent tasks when implementation differs from original plan using `update` / `task-master update --from=<id> --prompt="..."` or `update_task` / `task-master update-task --id=<id> --prompt="..."` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc))
- Add new tasks discovered during implementation using `add_task` / `task-master add-task --prompt="..." --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
- Add new subtasks as needed using `add_subtask` / `task-master add-subtask --parent=<id> --title="..."` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
- Append notes or details to subtasks using `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='Add implementation notes here...\nMore details...'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
- Generate task files with `generate` / `task-master generate` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) after updating tasks.json
- Maintain valid dependency structure with `add_dependency`/`remove_dependency` tools or `task-master add-dependency`/`remove-dependency` commands, `validate_dependencies` / `task-master validate-dependencies`, and `fix_dependencies` / `task-master fix-dependencies` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) when needed
- Respect dependency chains and task priorities when selecting work
- Report progress regularly using `get_tasks` / `task-master list`
## Task Complexity Analysis
- Run `analyze_project_complexity` / `task-master analyze-complexity --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) for comprehensive analysis
- Review complexity report via `complexity_report` / `task-master complexity-report` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) for a formatted, readable version.
- Focus on tasks with highest complexity scores (8-10) for detailed breakdown
- Use analysis results to determine appropriate subtask allocation
- Note that reports are automatically used by the `expand_task` tool/command
## Task Breakdown Process
- Use `expand_task` / `task-master expand --id=<id>`. It automatically uses the complexity report if found, otherwise generates default number of subtasks.
- Use `--num=<number>` to specify an explicit number of subtasks, overriding defaults or complexity report recommendations.
- Add `--research` flag to leverage Perplexity AI for research-backed expansion.
- Add `--force` flag to clear existing subtasks before generating new ones (default is to append).
- Use `--prompt="<context>"` to provide additional context when needed.
- Review and adjust generated subtasks as necessary.
- Use `expand_all` tool or `task-master expand --all` to expand multiple pending tasks at once, respecting flags like `--force` and `--research`.
- If subtasks need complete replacement (regardless of the `--force` flag on `expand`), clear them first with `clear_subtasks` / `task-master clear-subtasks --id=<id>`.
## Implementation Drift Handling
- When implementation differs significantly from planned approach
- When future tasks need modification due to current implementation choices
- When new dependencies or requirements emerge
- Use `update` / `task-master update --from=<futureTaskId> --prompt='<explanation>\nUpdate context...' --research` to update multiple future tasks.
- Use `update_task` / `task-master update-task --id=<taskId> --prompt='<explanation>\nUpdate context...' --research` to update a single specific task.
## Task Status Management
- Use 'pending' for tasks ready to be worked on
- Use 'done' for completed and verified tasks
- Use 'deferred' for postponed tasks
- Add custom status values as needed for project-specific workflows
## Task Structure Fields
- **id**: Unique identifier for the task (Example: `1`, `1.1`)
- **title**: Brief, descriptive title (Example: `"Initialize Repo"`)
- **description**: Concise summary of what the task involves (Example: `"Create a new repository, set up initial structure."`)
- **status**: Current state of the task (Example: `"pending"`, `"done"`, `"deferred"`)
- **dependencies**: IDs of prerequisite tasks (Example: `[1, 2.1]`)
- Dependencies are displayed with status indicators (✅ for completed, ⏱️ for pending)
- This helps quickly identify which prerequisite tasks are blocking work
- **priority**: Importance level (Example: `"high"`, `"medium"`, `"low"`)
- **details**: In-depth implementation instructions (Example: `"Use GitHub client ID/secret, handle callback, set session token."`)
- **testStrategy**: Verification approach (Example: `"Deploy and call endpoint to confirm 'Hello World' response."`)
- **subtasks**: List of smaller, more specific tasks (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`)
- Refer to task structure details (previously linked to `tasks.mdc`).
## Configuration Management (Updated)
Taskmaster configuration is managed through two main mechanisms:
1. **`.taskmasterconfig` File (Primary):**
* Located in the project root directory.
* Stores most configuration settings: AI model selections (main, research, fallback), parameters (max tokens, temperature), logging level, default subtasks/priority, project name, etc.
* **Managed via `task-master models --setup` command.** Do not edit manually unless you know what you are doing.
* **View/Set specific models via `task-master models` command or `models` MCP tool.**
* Created automatically when you run `task-master models --setup` for the first time.
2. **Environment Variables (`.env` / `mcp.json`):**
* Used **only** for sensitive API keys and specific endpoint URLs.
* Place API keys (one per provider) in a `.env` file in the project root for CLI usage.
* For MCP/Cursor integration, configure these keys in the `env` section of `.cursor/mcp.json`.
* Available keys/variables: See `assets/env.example` or the Configuration section in the command reference (previously linked to `taskmaster.mdc`).
**Important:** Non-API key settings (like model selections, `MAX_TOKENS`, `TASKMASTER_LOG_LEVEL`) are **no longer configured via environment variables**. Use the `task-master models` command (or `--setup` for interactive configuration) or the `models` MCP tool.
**If AI commands FAIL in MCP** verify that the API key for the selected provider is present in the `env` section of `.cursor/mcp.json`.
**If AI commands FAIL in CLI** verify that the API key for the selected provider is present in the `.env` file in the root of the project.
## Determining the Next Task
- Run `next_task` / `task-master next` to show the next task to work on.
- The command identifies tasks with all dependencies satisfied
- Tasks are prioritized by priority level, dependency count, and ID
- The command shows comprehensive task information including:
- Basic task details and description
- Implementation details
- Subtasks (if they exist)
- Contextual suggested actions
- Recommended before starting any new development work
- Respects your project's dependency structure
- Ensures tasks are completed in the appropriate sequence
- Provides ready-to-use commands for common task actions
## Viewing Specific Task Details
- Run `get_task` / `task-master show <id>` to view a specific task.
- Use dot notation for subtasks: `task-master show 1.2` (shows subtask 2 of task 1)
- Displays comprehensive information similar to the next command, but for a specific task
- For parent tasks, shows all subtasks and their current status
- For subtasks, shows parent task information and relationship
- Provides contextual suggested actions appropriate for the specific task
- Useful for examining task details before implementation or checking status
## Managing Task Dependencies
- Use `add_dependency` / `task-master add-dependency --id=<id> --depends-on=<id>` to add a dependency.
- Use `remove_dependency` / `task-master remove-dependency --id=<id> --depends-on=<id>` to remove a dependency.
- The system prevents circular dependencies and duplicate dependency entries
- Dependencies are checked for existence before being added or removed
- Task files are automatically regenerated after dependency changes
- Dependencies are visualized with status indicators in task listings and files
## Iterative Subtask Implementation
Once a task has been broken down into subtasks using `expand_task` or similar methods, follow this iterative process for implementation:
1. **Understand the Goal (Preparation):**
* Use `get_task` / `task-master show <subtaskId>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to thoroughly understand the specific goals and requirements of the subtask.
2. **Initial Exploration & Planning (Iteration 1):**
* This is the first attempt at creating a concrete implementation plan.
* Explore the codebase to identify the precise files, functions, and even specific lines of code that will need modification.
* Determine the intended code changes (diffs) and their locations.
* Gather *all* relevant details from this exploration phase.
3. **Log the Plan:**
* Run `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<detailed plan>'`.
* Provide the *complete and detailed* findings from the exploration phase in the prompt. Include file paths, line numbers, proposed diffs, reasoning, and any potential challenges identified. Do not omit details. The goal is to create a rich, timestamped log within the subtask's `details`.
4. **Verify the Plan:**
* Run `get_task` / `task-master show <subtaskId>` again to confirm that the detailed implementation plan has been successfully appended to the subtask's details.
5. **Begin Implementation:**
* Set the subtask status using `set_task_status` / `task-master set-status --id=<subtaskId> --status=in-progress`.
* Start coding based on the logged plan.
6. **Refine and Log Progress (Iteration 2+):**
* As implementation progresses, you will encounter challenges, discover nuances, or confirm successful approaches.
* **Before appending new information**: Briefly review the *existing* details logged in the subtask (using `get_task` or recalling from context) to ensure the update adds fresh insights and avoids redundancy.
* **Regularly** use `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<update details>\n- What worked...\n- What didn't work...'` to append new findings.
* **Crucially, log:**
* What worked ("fundamental truths" discovered).
* What didn't work and why (to avoid repeating mistakes).
* Specific code snippets or configurations that were successful.
* Decisions made, especially if confirmed with user input.
* Any deviations from the initial plan and the reasoning.
* The objective is to continuously enrich the subtask's details, creating a log of the implementation journey that helps the AI (and human developers) learn, adapt, and avoid repeating errors.
7. **Review & Update Rules (Post-Implementation):**
* Once the implementation for the subtask is functionally complete, review all code changes and the relevant chat history.
* Identify any new or modified code patterns, conventions, or best practices established during the implementation.
* Create new or update existing rules following internal guidelines (previously linked to `cursor_rules.mdc` and `self_improve.mdc`).
8. **Mark Task Complete:**
* After verifying the implementation and updating any necessary rules, mark the subtask as completed: `set_task_status` / `task-master set-status --id=<subtaskId> --status=done`.
9. **Commit Changes (If using Git):**
* Stage the relevant code changes and any updated/new rule files (`git add .`).
* Craft a comprehensive Git commit message summarizing the work done for the subtask, including both code implementation and any rule adjustments.
* Execute the commit command directly in the terminal (e.g., `git commit -m 'feat(module): Implement feature X for subtask <subtaskId>\n\n- Details about changes...\n- Updated rule Y for pattern Z'`).
* Consider if a Changeset is needed according to internal versioning guidelines (previously linked to `changeset.mdc`). If so, run `npm run changeset`, stage the generated file, and amend the commit or create a new one.
10. **Proceed to Next Subtask:**
* Identify the next subtask (e.g., using `next_task` / `task-master next`).
## Code Analysis & Refactoring Techniques
- **Top-Level Function Search**:
- Useful for understanding module structure or planning refactors.
- Use grep/ripgrep to find exported functions/constants:
`rg "export (async function|function|const) \w+"` or similar patterns.
- Can help compare functions between files during migrations or identify potential naming conflicts.
---
*This workflow provides a general guideline. Adapt it based on your specific project needs and team practices.*

59
.cursor/rules/self_improve.mdc
View file

@ -1,59 +0,0 @@
---
description: Guidelines for continuously improving Cursor rules based on emerging code patterns and best practices.
globs: **/*
alwaysApply: true
---
- **Rule Improvement Triggers:**
- New code patterns not covered by existing rules
- Repeated similar implementations across files
- Common error patterns that could be prevented
- New libraries or tools being used consistently
- Emerging best practices in the codebase
- **Analysis Process:**
- Compare new code with existing rules
- Identify patterns that should be standardized
- Look for references to external documentation
- Check for consistent error handling patterns
- Monitor test patterns and coverage
- **Rule Updates:**
- **Add New Rules When:**
- A new technology/pattern is used in 3+ files
- Common bugs could be prevented by a rule
- Code reviews repeatedly mention the same feedback
- New security or performance patterns emerge
- **Modify Existing Rules When:**
- Better examples exist in the codebase
- Additional edge cases are discovered
- Related rules have been updated
- Implementation details have changed
- **Rule Quality Checks:**
- Rules should be actionable and specific
- Examples should come from actual code
- References should be up to date
- Patterns should be consistently enforced
- **Continuous Improvement:**
- Monitor code review comments
- Track common development questions
- Update rules after major refactors
- Add links to relevant documentation
- Cross-reference related rules
- **Rule Deprecation:**
- Mark outdated patterns as deprecated
- Remove rules that no longer apply
- Update references to deprecated rules
- Document migration paths for old patterns
- **Documentation Updates:**
- Keep examples synchronized with code
- Update references to external docs
- Maintain links between related rules
- Document breaking changes
Follow [cursor_rules.mdc](mdc:.cursor/rules/cursor_rules.mdc) for proper rule formatting and structure.

491
CLAUDE.md
View file

@ -2,9 +2,9 @@ # CLAUDE.md
This file provides guidance to **Claude Code** (claude.ai/code) when working with code in this repository. This file provides guidance to **Claude Code** (claude.ai/code) when working with code in this repository.
> **Note for AI Assistants**: This file is specifically for Claude Code. If you're using Cursor IDE, refer to the `.cursor/rules/` directory for detailed rule files. Both systems share core principles but are optimized for their respective workflows. > **Note for AI Assistants**: This file is specifically for Claude Code. All detailed documentation is in the `.ai/` directory. Both Claude Code and Cursor IDE use the same source files in `.ai/` for consistency.
> >
> **Maintaining Instructions**: When updating AI instructions, see [.AI_INSTRUCTIONS_SYNC.md](.AI_INSTRUCTIONS_SYNC.md) for synchronization guidelines between CLAUDE.md and .cursor/rules/. > **Maintaining Instructions**: When updating AI instructions, see [.ai/meta/sync-guide.md](.ai/meta/sync-guide.md) and [.ai/meta/maintaining-docs.md](.ai/meta/maintaining-docs.md) for guidelines.
## Project Overview ## Project Overview
@ -27,7 +27,8 @@ ### Backend Development
### Code Quality ### Code Quality
- `./vendor/bin/pint` - Run Laravel Pint for code formatting - `./vendor/bin/pint` - Run Laravel Pint for code formatting
- `./vendor/bin/phpstan` - Run PHPStan for static analysis - `./vendor/bin/phpstan` - Run PHPStan for static analysis
- `./vendor/bin/pest` - Run Pest tests (unit tests only, without database) - `./vendor/bin/pest tests/Unit` - Run unit tests only (no database, can run outside Docker)
- `./vendor/bin/pest` - Run ALL tests (includes Feature tests, may require database)
### Running Tests ### Running Tests
**IMPORTANT**: Tests that require database connections MUST be run inside the Docker container: **IMPORTANT**: Tests that require database connections MUST be run inside the Docker container:
@ -39,12 +40,14 @@ ### Running Tests
## Architecture Overview ## Architecture Overview
### Technology Stack ### Technology Stack
- **Backend**: Laravel 12 (PHP 8.4) - **Backend**: Laravel 12.4.1 (PHP 8.4.7)
- **Frontend**: Livewire 3.5+ with Alpine.js and Tailwind CSS 4.1+ - **Frontend**: Livewire 3.5.20 with Alpine.js and Tailwind CSS 4.1.4
- **Database**: PostgreSQL 15 (primary), Redis 7 (cache/queues) - **Database**: PostgreSQL 15 (primary), Redis 7 (cache/queues)
- **Real-time**: Soketi (WebSocket server) - **Real-time**: Soketi (WebSocket server)
- **Containerization**: Docker & Docker Compose - **Containerization**: Docker & Docker Compose
- **Queue Management**: Laravel Horizon - **Queue Management**: Laravel Horizon 5.30.3
> **Note**: For complete version information and all dependencies, see [.ai/core/technology-stack.md](.ai/core/technology-stack.md)
### Key Components ### Key Components
@ -256,453 +259,61 @@ ## Important Reminders
## Additional Documentation ## Additional Documentation
This file contains high-level guidelines for Claude Code. For **more detailed, topic-specific documentation**, refer to the `.cursor/rules/` directory (also accessible by Cursor IDE and other AI assistants): This file contains high-level guidelines for Claude Code. For **more detailed, topic-specific documentation**, refer to the `.ai/` directory:
> **Cross-Reference**: The `.cursor/rules/` directory contains comprehensive, detailed documentation organized by topic. Start with [.cursor/rules/README.mdc](.cursor/rules/README.mdc) for an overview, then explore specific topics below. > **Documentation Hub**: The `.ai/` directory contains comprehensive, detailed documentation organized by topic. Start with [.ai/README.md](.ai/README.md) for navigation, then explore specific topics below.
### Architecture & Patterns ### Core Documentation
- [Application Architecture](.cursor/rules/application-architecture.mdc) - Detailed application structure - [Technology Stack](.ai/core/technology-stack.md) - All versions, packages, and dependencies (single source of truth)
- [Deployment Architecture](.cursor/rules/deployment-architecture.mdc) - Deployment patterns and flows - [Project Overview](.ai/core/project-overview.md) - What Coolify is and how it works
- [Database Patterns](.cursor/rules/database-patterns.mdc) - Database design and query patterns - [Application Architecture](.ai/core/application-architecture.md) - System design and component relationships
- [Frontend Patterns](.cursor/rules/frontend-patterns.mdc) - Livewire and Alpine.js patterns - [Deployment Architecture](.ai/core/deployment-architecture.md) - How deployments work end-to-end
- [API & Routing](.cursor/rules/api-and-routing.mdc) - API design and routing conventions
### Development & Security ### Development Practices
- [Development Workflow](.cursor/rules/development-workflow.mdc) - Development best practices - [Development Workflow](.ai/development/development-workflow.md) - Development setup, commands, and workflows
- [Security Patterns](.cursor/rules/security-patterns.mdc) - Security implementation details - [Testing Patterns](.ai/development/testing-patterns.md) - Testing strategies and examples (Docker requirements!)
- [Form Components](.cursor/rules/form-components.mdc) - Enhanced form components with authorization - [Laravel Boost](.ai/development/laravel-boost.md) - Laravel-specific guidelines and best practices
- [Testing Patterns](.cursor/rules/testing-patterns.mdc) - Testing strategies and examples
### Project Information ### Code Patterns
- [Project Overview](.cursor/rules/project-overview.mdc) - High-level project structure - [Database Patterns](.ai/patterns/database-patterns.md) - Eloquent, migrations, relationships
- [Technology Stack](.cursor/rules/technology-stack.mdc) - Detailed tech stack information - [Frontend Patterns](.ai/patterns/frontend-patterns.md) - Livewire, Alpine.js, Tailwind CSS
- [Cursor Rules Guide](.cursor/rules/cursor_rules.mdc) - How to maintain cursor rules - [Security Patterns](.ai/patterns/security-patterns.md) - Authentication, authorization, security
- [Form Components](.ai/patterns/form-components.md) - Enhanced form components with authorization
- [API & Routing](.ai/patterns/api-and-routing.md) - API design and routing conventions
=== ### Meta Documentation
- [Maintaining Docs](.ai/meta/maintaining-docs.md) - How to update and improve AI documentation
- [Sync Guide](.ai/meta/sync-guide.md) - Keeping documentation synchronized
<laravel-boost-guidelines> ## Laravel Boost Guidelines
=== foundation rules ===
# Laravel Boost Guidelines > **Full Guidelines**: See [.ai/development/laravel-boost.md](.ai/development/laravel-boost.md) for complete Laravel Boost guidelines.
The Laravel Boost guidelines are specifically curated by Laravel maintainers for this application. These guidelines should be followed closely to enhance the user's satisfaction building Laravel applications. ### Essential Laravel Patterns
## Foundational Context - Use PHP 8.4 constructor property promotion and typed properties
This application is a Laravel application and its main Laravel ecosystems package & versions are below. You are an expert with them all. Ensure you abide by these specific packages & versions. - Follow PSR-12 (run `./vendor/bin/pint` before committing)
- Use Eloquent ORM, avoid raw queries
- Use Form Request classes for validation
- Queue heavy operations with Laravel Horizon
- Never use `env()` outside config files
- Use named routes with `route()` function
- Laravel 12 with Laravel 10 structure (no bootstrap/app.php)
- php - 8.4.7 ### Testing Requirements
- laravel/fortify (FORTIFY) - v1
- laravel/framework (LARAVEL) - v12
- laravel/horizon (HORIZON) - v5
- laravel/prompts (PROMPTS) - v0
- laravel/sanctum (SANCTUM) - v4
- laravel/socialite (SOCIALITE) - v5
- livewire/livewire (LIVEWIRE) - v3
- laravel/dusk (DUSK) - v8
- laravel/pint (PINT) - v1
- laravel/telescope (TELESCOPE) - v5
- pestphp/pest (PEST) - v3
- phpunit/phpunit (PHPUNIT) - v11
- rector/rector (RECTOR) - v2
- laravel-echo (ECHO) - v2
- tailwindcss (TAILWINDCSS) - v4
- vue (VUE) - v3
- **Unit tests**: No database, use mocking, run with `./vendor/bin/pest tests/Unit`
- **Feature tests**: Can use database, run with `docker exec coolify php artisan test`
- Every change must have tests
- Use Pest for all tests
## Conventions ### Livewire & Frontend
- You must follow all existing code conventions used in this application. When creating or editing a file, check sibling files for the correct structure, approach, naming.
- Use descriptive names for variables and methods. For example, `isRegisteredForDiscounts`, not `discount()`.
- Check for existing components to reuse before writing a new one.
## Verification Scripts - Livewire components require single root element
- Do not create verification scripts or tinker when tests cover that functionality and prove it works. Unit and feature tests are more important. - Use `wire:model.live` for real-time updates
- Alpine.js included with Livewire
## Application Structure & Architecture - Tailwind CSS 4.1.4 (use new utilities, not deprecated ones)
- Stick to existing directory structure - don't create new base folders without approval. - Use `gap` utilities for spacing, not margins
- Do not change the application's dependencies without approval.
## Frontend Bundling
- If the user doesn't see a frontend change reflected in the UI, it could mean they need to run `npm run build`, `npm run dev`, or `composer run dev`. Ask them.
## Replies
- Be concise in your explanations - focus on what's important rather than explaining obvious details.
## Documentation Files
- You must only create documentation files if explicitly requested by the user.
=== boost rules ===
## Laravel Boost
- Laravel Boost is an MCP server that comes with powerful tools designed specifically for this application. Use them.
## Artisan
- Use the `list-artisan-commands` tool when you need to call an Artisan command to double check the available parameters.
## URLs
- Whenever you share a project URL with the user you should use the `get-absolute-url` tool to ensure you're using the correct scheme, domain / IP, and port.
## Tinker / Debugging
- You should use the `tinker` tool when you need to execute PHP to debug code or query Eloquent models directly.
- Use the `database-query` tool when you only need to read from the database.
## Reading Browser Logs With the `browser-logs` Tool
- You can read browser logs, errors, and exceptions using the `browser-logs` tool from Boost.
- Only recent browser logs will be useful - ignore old logs.
## Searching Documentation (Critically Important)
- Boost comes with a powerful `search-docs` tool you should use before any other approaches. This tool automatically passes a list of installed packages and their versions to the remote Boost API, so it returns only version-specific documentation specific for the user's circumstance. You should pass an array of packages to filter on if you know you need docs for particular packages.
- The 'search-docs' tool is perfect for all Laravel related packages, including Laravel, Inertia, Livewire, Filament, Tailwind, Pest, Nova, Nightwatch, etc.
- You must use this tool to search for Laravel-ecosystem documentation before falling back to other approaches.
- Search the documentation before making code changes to ensure we are taking the correct approach.
- Use multiple, broad, simple, topic based queries to start. For example: `['rate limiting', 'routing rate limiting', 'routing']`.
- Do not add package names to queries - package information is already shared. For example, use `test resource table`, not `filament 4 test resource table`.
### Available Search Syntax
- You can and should pass multiple queries at once. The most relevant results will be returned first.
1. Simple Word Searches with auto-stemming - query=authentication - finds 'authenticate' and 'auth'
2. Multiple Words (AND Logic) - query=rate limit - finds knowledge containing both "rate" AND "limit"
3. Quoted Phrases (Exact Position) - query="infinite scroll" - Words must be adjacent and in that order
4. Mixed Queries - query=middleware "rate limit" - "middleware" AND exact phrase "rate limit"
5. Multiple Queries - queries=["authentication", "middleware"] - ANY of these terms
=== php rules ===
## PHP
- Always use curly braces for control structures, even if it has one line.
### Constructors
- Use PHP 8 constructor property promotion in `__construct()`.
- <code-snippet>public function __construct(public GitHub $github) { }</code-snippet>
- Do not allow empty `__construct()` methods with zero parameters.
### Type Declarations
- Always use explicit return type declarations for methods and functions.
- Use appropriate PHP type hints for method parameters.
<code-snippet name="Explicit Return Types and Method Params" lang="php">
protected function isAccessible(User $user, ?string $path = null): bool
{
...
}
</code-snippet>
## Comments
- Prefer PHPDoc blocks over comments. Never use comments within the code itself unless there is something _very_ complex going on.
## PHPDoc Blocks
- Add useful array shape type definitions for arrays when appropriate.
## Enums
- Typically, keys in an Enum should be TitleCase. For example: `FavoritePerson`, `BestLake`, `Monthly`.
=== laravel/core rules ===
## Do Things the Laravel Way
- Use `php artisan make:` commands to create new files (i.e. migrations, controllers, models, etc.). You can list available Artisan commands using the `list-artisan-commands` tool.
- If you're creating a generic PHP class, use `artisan make:class`.
- Pass `--no-interaction` to all Artisan commands to ensure they work without user input. You should also pass the correct `--options` to ensure correct behavior.
### Database
- Always use proper Eloquent relationship methods with return type hints. Prefer relationship methods over raw queries or manual joins.
- Use Eloquent models and relationships before suggesting raw database queries
- Avoid `DB::`; prefer `Model::query()`. Generate code that leverages Laravel's ORM capabilities rather than bypassing them.
- Generate code that prevents N+1 query problems by using eager loading.
- Use Laravel's query builder for very complex database operations.
### Model Creation
- When creating new models, create useful factories and seeders for them too. Ask the user if they need any other things, using `list-artisan-commands` to check the available options to `php artisan make:model`.
### APIs & Eloquent Resources
- For APIs, default to using Eloquent API Resources and API versioning unless existing API routes do not, then you should follow existing application convention.
### Controllers & Validation
- Always create Form Request classes for validation rather than inline validation in controllers. Include both validation rules and custom error messages.
- Check sibling Form Requests to see if the application uses array or string based validation rules.
### Queues
- Use queued jobs for time-consuming operations with the `ShouldQueue` interface.
### Authentication & Authorization
- Use Laravel's built-in authentication and authorization features (gates, policies, Sanctum, etc.).
### URL Generation
- When generating links to other pages, prefer named routes and the `route()` function.
### Configuration
- Use environment variables only in configuration files - never use the `env()` function directly outside of config files. Always use `config('app.name')`, not `env('APP_NAME')`.
### Testing
- When creating models for tests, use the factories for the models. Check if the factory has custom states that can be used before manually setting up the model.
- Faker: Use methods such as `$this->faker->word()` or `fake()->randomDigit()`. Follow existing conventions whether to use `$this->faker` or `fake()`.
- When creating tests, make use of `php artisan make:test [options] <name>` to create a feature test, and pass `--unit` to create a unit test. Most tests should be feature tests.
### Vite Error
- If you receive an "Illuminate\Foundation\ViteException: Unable to locate file in Vite manifest" error, you can run `npm run build` or ask the user to run `npm run dev` or `composer run dev`.
=== laravel/v12 rules ===
## Laravel 12
- Use the `search-docs` tool to get version specific documentation.
- This project upgraded from Laravel 10 without migrating to the new streamlined Laravel file structure.
- This is **perfectly fine** and recommended by Laravel. Follow the existing structure from Laravel 10. We do not to need migrate to the new Laravel structure unless the user explicitly requests that.
### Laravel 10 Structure
- Middleware typically lives in `app/Http/Middleware/` and service providers in `app/Providers/`.
- There is no `bootstrap/app.php` application configuration in a Laravel 10 structure:
- Middleware registration happens in `app/Http/Kernel.php`
- Exception handling is in `app/Exceptions/Handler.php`
- Console commands and schedule register in `app/Console/Kernel.php`
- Rate limits likely exist in `RouteServiceProvider` or `app/Http/Kernel.php`
### Database
- When modifying a column, the migration must include all of the attributes that were previously defined on the column. Otherwise, they will be dropped and lost.
- Laravel 12 allows limiting eagerly loaded records natively, without external packages: `$query->latest()->limit(10);`.
### Models
- Casts can and likely should be set in a `casts()` method on a model rather than the `$casts` property. Follow existing conventions from other models.
=== livewire/core rules ===
## Livewire Core
- Use the `search-docs` tool to find exact version specific documentation for how to write Livewire & Livewire tests.
- Use the `php artisan make:livewire [Posts\\CreatePost]` artisan command to create new components
- State should live on the server, with the UI reflecting it.
- All Livewire requests hit the Laravel backend, they're like regular HTTP requests. Always validate form data, and run authorization checks in Livewire actions.
## Livewire Best Practices
- Livewire components require a single root element.
- Use `wire:loading` and `wire:dirty` for delightful loading states.
- Add `wire:key` in loops:
```blade
@foreach ($items as $item)
<div wire:key="item-{{ $item->id }}">
{{ $item->name }}
</div>
@endforeach
```
- Prefer lifecycle hooks like `mount()`, `updatedFoo()`) for initialization and reactive side effects:
<code-snippet name="Lifecycle hook examples" lang="php">
public function mount(User $user) { $this->user = $user; }
public function updatedSearch() { $this->resetPage(); }
</code-snippet>
## Testing Livewire
<code-snippet name="Example Livewire component test" lang="php">
Livewire::test(Counter::class)
->assertSet('count', 0)
->call('increment')
->assertSet('count', 1)
->assertSee(1)
->assertStatus(200);
</code-snippet>
<code-snippet name="Testing a Livewire component exists within a page" lang="php">
$this->get('/posts/create')
->assertSeeLivewire(CreatePost::class);
</code-snippet>
=== livewire/v3 rules ===
## Livewire 3
### Key Changes From Livewire 2
- These things changed in Livewire 2, but may not have been updated in this application. Verify this application's setup to ensure you conform with application conventions.
- Use `wire:model.live` for real-time updates, `wire:model` is now deferred by default.
- Components now use the `App\Livewire` namespace (not `App\Http\Livewire`).
- Use `$this->dispatch()` to dispatch events (not `emit` or `dispatchBrowserEvent`).
- Use the `components.layouts.app` view as the typical layout path (not `layouts.app`).
### New Directives
- `wire:show`, `wire:transition`, `wire:cloak`, `wire:offline`, `wire:target` are available for use. Use the documentation to find usage examples.
### Alpine
- Alpine is now included with Livewire, don't manually include Alpine.js.
- Plugins included with Alpine: persist, intersect, collapse, and focus.
### Lifecycle Hooks
- You can listen for `livewire:init` to hook into Livewire initialization, and `fail.status === 419` for the page expiring:
<code-snippet name="livewire:load example" lang="js">
document.addEventListener('livewire:init', function () {
Livewire.hook('request', ({ fail }) => {
if (fail && fail.status === 419) {
alert('Your session expired');
}
});
Livewire.hook('message.failed', (message, component) => {
console.error(message);
});
});
</code-snippet>
=== pint/core rules ===
## Laravel Pint Code Formatter
- You must run `vendor/bin/pint --dirty` before finalizing changes to ensure your code matches the project's expected style.
- Do not run `vendor/bin/pint --test`, simply run `vendor/bin/pint` to fix any formatting issues.
=== pest/core rules ===
## Pest
### Testing
- If you need to verify a feature is working, write or update a Unit / Feature test.
### Pest Tests
- All tests must be written using Pest. Use `php artisan make:test --pest <name>`.
- You must not remove any tests or test files from the tests directory without approval. These are not temporary or helper files - these are core to the application.
- Tests should test all of the happy paths, failure paths, and weird paths.
- Tests live in the `tests/Feature` and `tests/Unit` directories.
- **Unit tests** MUST use mocking and avoid database. They can run outside Docker.
- **Feature tests** can use database but MUST run inside Docker container.
- **Design for testability**: Structure code to be testable without database when possible. Use dependency injection and interfaces.
- **Mock by default**: Prefer `Mockery::mock()` over `Model::factory()->create()` in unit tests.
- Pest tests look and behave like this:
<code-snippet name="Basic Pest Test Example" lang="php">
it('is true', function () {
expect(true)->toBeTrue();
});
</code-snippet>
### Running Tests
**IMPORTANT**: Always run tests in the correct environment based on database dependencies:
**Unit Tests (no database):**
- Run outside Docker: `./vendor/bin/pest tests/Unit`
- Run specific file: `./vendor/bin/pest tests/Unit/ProxyCustomCommandsTest.php`
- These tests use mocking and don't require PostgreSQL
**Feature Tests (with database):**
- Run inside Docker: `docker exec coolify php artisan test`
- Run specific file: `docker exec coolify php artisan test tests/Feature/ExampleTest.php`
- Filter by name: `docker exec coolify php artisan test --filter=testName`
- These tests require PostgreSQL and use factories/migrations
**General Guidelines:**
- Run the minimal number of tests using an appropriate filter before finalizing code edits
- When the tests relating to your changes are passing, ask the user if they would like to run the entire test suite
- If you get database connection errors, you're running a Feature test outside Docker - move it inside
### Pest Assertions
- When asserting status codes on a response, use the specific method like `assertForbidden` and `assertNotFound` instead of using `assertStatus(403)` or similar, e.g.:
<code-snippet name="Pest Example Asserting postJson Response" lang="php">
it('returns all', function () {
$response = $this->postJson('/api/docs', []);
$response->assertSuccessful();
});
</code-snippet>
### Mocking
- Mocking can be very helpful when appropriate.
- When mocking, you can use the `Pest\Laravel\mock` Pest function, but always import it via `use function Pest\Laravel\mock;` before using it. Alternatively, you can use `$this->mock()` if existing tests do.
- You can also create partial mocks using the same import or self method.
### Datasets
- Use datasets in Pest to simplify tests which have a lot of duplicated data. This is often the case when testing validation rules, so consider going with this solution when writing tests for validation rules.
<code-snippet name="Pest Dataset Example" lang="php">
it('has emails', function (string $email) {
expect($email)->not->toBeEmpty();
})->with([
'james' => 'james@laravel.com',
'taylor' => 'taylor@laravel.com',
]);
</code-snippet>
=== tailwindcss/core rules ===
## Tailwind Core
- Use Tailwind CSS classes to style HTML, check and use existing tailwind conventions within the project before writing your own.
- Offer to extract repeated patterns into components that match the project's conventions (i.e. Blade, JSX, Vue, etc..)
- Think through class placement, order, priority, and defaults - remove redundant classes, add classes to parent or child carefully to limit repetition, group elements logically
- You can use the `search-docs` tool to get exact examples from the official documentation when needed.
### Spacing
- When listing items, use gap utilities for spacing, don't use margins.
<code-snippet name="Valid Flex Gap Spacing Example" lang="html">
<div class="flex gap-8">
<div>Superior</div>
<div>Michigan</div>
<div>Erie</div>
</div>
</code-snippet>
### Dark Mode
- If existing pages and components support dark mode, new pages and components must support dark mode in a similar way, typically using `dark:`.
=== tailwindcss/v4 rules ===
## Tailwind 4
- Always use Tailwind CSS v4 - do not use the deprecated utilities.
- `corePlugins` is not supported in Tailwind v4.
- In Tailwind v4, you import Tailwind using a regular CSS `@import` statement, not using the `@tailwind` directives used in v3:
<code-snippet name="Tailwind v4 Import Tailwind Diff" lang="diff"
- @tailwind base;
- @tailwind components;
- @tailwind utilities;
+ @import "tailwindcss";
</code-snippet>
### Replaced Utilities
- Tailwind v4 removed deprecated utilities. Do not use the deprecated option - use the replacement.
- Opacity values are still numeric.
| Deprecated | Replacement |
|------------+--------------|
| bg-opacity-* | bg-black/* |
| text-opacity-* | text-black/* |
| border-opacity-* | border-black/* |
| divide-opacity-* | divide-black/* |
| ring-opacity-* | ring-black/* |
| placeholder-opacity-* | placeholder-black/* |
| flex-shrink-* | shrink-* |
| flex-grow-* | grow-* |
| overflow-ellipsis | text-ellipsis |
| decoration-slice | box-decoration-slice |
| decoration-clone | box-decoration-clone |
=== tests rules ===
## Test Enforcement
- Every change must be programmatically tested. Write a new test or update an existing test, then run the affected tests to make sure they pass.
- Run the minimum number of tests needed to ensure code quality and speed.
- **For Unit tests**: Use `./vendor/bin/pest tests/Unit/YourTest.php` (runs outside Docker)
- **For Feature tests**: Use `docker exec coolify php artisan test --filter=YourTest` (runs inside Docker)
- Choose the correct test type based on database dependency:
- No database needed? → Unit test with mocking
- Database needed? → Feature test in Docker
</laravel-boost-guidelines>
Random other things you should remember: Random other things you should remember: