## The command

```bash
bin/kamal app exec --interactive --reuse 'bin/rails console'
```

`--reuse` is the part that matters. Without it Kamal starts a fresh container, which works but boots
slower and, more importantly, is not the process serving traffic. With it you are inside the live
container.

For a one-off that does not need a prompt, skip the console entirely:

```bash
bin/kamal app exec 'bin/rails runner "puts Account.count"'
```

## Everything is account scoped

This is the rule the console does not enforce for you. Customer data belongs to an `Account`, and
queries go through it:

```ruby
account = Account.find_by(name: "Acme")
account.projects.count
```

Reaching for a bare model class works and is exactly how you leak one customer's rows into another
customer's view when you paste the result somewhere. Operate through the account.

To act as a signed-in user, create a session rather than stubbing `Current`:

```ruby
Current.session = User.find_by(email_address: "someone@example.com").sessions.create!
```

## Before you run a write

Two habits worth keeping. Read the query back before you run the update, and prefer a scoped
`update!` over `update_all`, which skips validations and callbacks silently.

```ruby
account.projects.where(archived: true).count   # look first
```

## When the console is the wrong tool

Anything you will do more than twice belongs in a rake task in `lib/tasks`, where it can be read,
reviewed and tested. The console is for the one-off and the investigation. A recurring data fix run
by hand at a prompt is a bug report waiting to happen.

Anything that should happen on a schedule belongs in a job instead, enqueued with `perform_later`
and listed in `config/recurring.yml`. Solid Queue runs it inside the same container, so there is no
separate worker host to keep alive and nothing extra to deploy.