<essential_principles>
Core Philosophy
"The best code is the code you don't write. The second best is the code that's obviously correct."
Vanilla Rails is plenty:
- •Rich domain models over service objects
- •CRUD controllers over custom actions
- •Concerns for horizontal code sharing
- •Records as state instead of boolean columns
- •Database-backed everything (no Redis)
- •Build solutions before reaching for gems
What they deliberately avoid:
- •devise (custom ~150-line auth instead)
- •pundit/cancancan (simple role checks in models)
- •sidekiq (Solid Queue uses database)
- •redis (database for everything)
- •view_component (partials work fine)
- •GraphQL (REST with Turbo sufficient) </essential_principles>
- •Controllers - REST mapping, concerns, Turbo responses
- •Models - Concerns, state records, callbacks, scopes
- •Views & Frontend - Turbo, Stimulus, CSS, partials
- •Architecture - Routing, multi-tenancy, authentication, jobs
- •Code Review - Review code against DHH style
- •General Guidance - Philosophy and conventions
Specify a number or describe your task. </intake>
<routing> | Response | Reference to Read | |----------|-------------------| | 1, "controller" | [controllers.md](./references/controllers.md) | | 2, "model" | [models.md](./references/models.md) | | 3, "view", "frontend", "turbo", "stimulus", "css" | [frontend.md](./references/frontend.md) | | 4, "architecture", "routing", "auth", "job" | [architecture.md](./references/architecture.md) | | 5, "review" | Read all references, then review code | | 6, general task | Read relevant references based on context |After reading relevant references, apply patterns to the user's code. </routing>
<quick_reference>
Naming Conventions
Verbs: card.close, card.gild, board.publish (not set_style methods)
Predicates: card.closed?, card.golden? (derived from presence of related record)
Concerns: Adjectives describing capability (Closeable, Publishable, Watchable)
Controllers: Nouns matching resources (Cards::ClosuresController)
Scopes:
- •
chronologically,reverse_chronologically,alphabetically,latest - •
preloaded(standard eager loading name) - •
indexed_by,sorted_by(parameterized)
REST Mapping
Instead of custom actions, create new resources:
POST /cards/:id/close → POST /cards/:id/closure DELETE /cards/:id/close → DELETE /cards/:id/closure POST /cards/:id/archive → POST /cards/:id/archival
</quick_reference>
<reference_index>
Domain Knowledge
All detailed patterns in references/:
| File | Topics |
|---|---|
| controllers.md | REST mapping, concerns, Turbo responses, API patterns |
| models.md | Concerns, state records, callbacks, scopes, POROs |
| frontend.md | Turbo, Stimulus, CSS architecture, view patterns |
| architecture.md | Routing, auth, jobs, caching, multi-tenancy, config |
| gems.md | What they use vs avoid, and why |
| </reference_index> |
<success_criteria> Code follows DHH style when:
- •Controllers map to CRUD verbs on resources
- •Models use concerns for horizontal behavior
- •State is tracked via records, not booleans
- •No unnecessary service objects or abstractions
- •Database-backed solutions preferred over external services
- •Tests use Minitest with fixtures
- •Turbo/Stimulus for interactivity (no heavy JS frameworks) </success_criteria>