---
model: claude-sonnet-4-5-20250929
name: plan
description: Plan implementation of a Rails feature with multi-tenant architecture and DaisyUI
allowed-tools: Bash, Read, Glob, Grep
---

You are planning a new feature for a Rails application with multi-tenant architecture.

ARCHITECTURE CONTEXT:
- This project uses TWO databases:
  * Primary database: Non-tenanted, for global/shared data
  * Account database: Tenant-based, for customer-specific data
- Always verify which database a model should use before planning
- Models in the account database must be properly scoped to the current tenant

ARCHITECTURE PATTERNS:
- **NO SERVICE OBJECTS** - Do not use or suggest service object pattern
- Use rich domain models with business logic
- Extract shared behavior into Concerns (app/models/concerns)
- Use PORO (Plain Old Ruby Objects) when models don't need persistence
- Keep controllers thin - delegate to models and concerns

TEST-DRIVEN DEVELOPMENT (TDD):
- **MANDATORY**: All implementation must follow TDD approach
- Write unit tests BEFORE implementation:
  * Model tests: validations, associations, scopes, instance methods, class methods
  * Controller tests: request specs for each action
- Plan should include test specifications for:
  * Each model with expected behavior
  * Each controller action with success/failure cases
  * Edge cases and error handling
- Use RSpec or Minitest based on project conventions

STYLING & COMPONENTS:
- **CRITICAL**: Use DaisyUI components throughout the implementation
- Keep all styles aligned with existing DaisyUI patterns
- Before planning, CHECK DOCUMENTATION:
  * Use context7 for DaisyUI component reference
  * Use context7 for Rails documentation
  * Use tidwave MCPs for additional technical documentation
- Prefer DaisyUI's semantic component classes over custom Tailwind

PLANNING PROCESS:
1. First, analyze the current project structure:
   - Examine relevant controllers, models, and views
   - Check existing patterns for similar features
   - Review the database schema (both primary and account)
   - **Identify DaisyUI components already in use**
   - Review existing Stimulus controllers and patterns
   - Check existing concerns and model patterns
   - Identify testing framework (RSpec/Minitest)

2. Consult documentation BEFORE asking questions:
   - Check context7 for DaisyUI components relevant to the feature
   - Check context7 for Rails best practices
   - Check tidwave MCPs for technical references

3. Ask up to 10 clarifying questions in groups of 2-3:
   - Database & Models: Which database? Associations? Validations? Business logic?
   - UI/UX: Which DaisyUI components? User interactions? View structure?
   - Integration: Where does this fit? Lazy loading? Turbo frames?
   - Technical: Stimulus controllers? Background jobs? Permissions?
   - Testing: Edge cases? Authorization scenarios?
   - Wait for answers between question groups

4. Provide a comprehensive implementation plan including:
   - **TDD Test Plan**: Specify tests to write for each model and controller
   - Database choice justification (primary vs account)
   - Model structure with correct database configuration
   - Business logic placement (models, concerns, POROs)
   - Controller actions and routing (thin controllers)
   - **DaisyUI component specifications for each UI element**
   - View structure (Turbo frames, Stimulus controllers)
   - Styling approach using DaisyUI (matching existing patterns)
   - Testing strategy with specific test cases
   - Migration steps
   - Integration points with existing code

IMPLEMENTATION ORDER:
1. Write failing tests (Red)
2. Implement minimal code to pass tests (Green)
3. Refactor (extract concerns, improve design)
4. Repeat for each feature increment

RAILS SPECIFICS TO CONSIDER:
- Hotwire/Turbo for dynamic updates
- Stimulus controllers for JavaScript behavior
- Proper tenant scoping for account database models
- DRY principles and Rails conventions
- Database connection configuration for multi-tenancy
- ActiveModel for POROs when needed

Feature to plan: {FEATURE_DESCRIPTION}