Cline rules for Rails

# Cline and Roo rules

Project rules for Cline and Roo Code in this Rails repository.
Use the project's commands. Do not invent a package manager, and do not run destructive shell commands.

## Tool use

- Read the files you will change before editing them.
- Prefer a focused patch over rewriting a whole file.
- Run the test command from this file after a behavior change, or say why you could not.
- Do not delete generated folders, lockfiles, or migrations unless the task says so.

## Stack

This repository is a Ruby on Rails app. Follow the conventions already in the repo: MVC, migrations, and strong parameters. Do not introduce a second frontend stack.

## Layout

- Controllers stay thin. Business rules live in models or plain objects the project already uses.
- Views and Turbo or Hotwire frames stay with the stack the app already renders.
- Schema changes are migrations. Do not edit `schema.rb` by hand.

## Commands

- Dev server: `bin/rails server`
- Tests: `bin/rails test`
- Migrate: `bin/rails db:migrate`

Use the script the repo already defines when it differs from the command above.

## Conventions

- Use strong parameters. Do not pass `params` straight into `update`.
- Name files the way Zeitwerk expects. Do not fight the autoloader with a custom require.
- Add an index when you query a new column in a hot path.
- Use the existing test style, whether that is Minitest or RSpec.
- Keep credentials in the encrypted credentials store or the env. Do not commit secrets.
- Prefer framework generators' layout over a new folder taxonomy.

## Testing

Add or update tests when behavior changes.

Add a model or request test for the behavior you changed. Cover the forbidden parameter case.

## Style

- Optimize for the next reader over the shortest diff.
- Comment only when the why is non-obvious.
- Name things the way neighboring files already do.
- Do not reformat code you did not change.

## Errors

- Fail at the boundary. Do not swallow errors.
- Use model validations and a 4xx response for bad input. Unexpected errors belong in the Rails logger.

## Scope

- Do the requested task. Do not refactor unrelated code.
- Match the rigor already in the repo. Fix what you touch.
- Ask one clarifying question only when the task cannot be finished without it. Otherwise state the assumption and continue.

## Avoid

- Do not call `update_attribute` to skip validations unless the existing code does that for the same reason.
- Do not introduce callbacks that hide a side effect the caller cannot see.
- Do not query in a loop. Use `includes` when the view walks an association.
- Do not add a SPA framework to a Hotwire app without being asked.

## Done when

- The requested behavior works.
- `bin/rails test` passes, and `db:migrate` applies cleanly when the schema changed.
- The diff stays inside the task.
- You list anything you could not run.