Build a control panel on Rails

Build a brand-new Ruby on Rails application whose operator control panel is Avo 4 (https://avohq.io, docs at https://docs.avohq.io/4.0/). There is no existing app or schema, so scaffold everything from scratch.

1. Run rails new with the default stack, then generate authentication with Rails' built-in bin/rails generate authentication so operators sign in before they reach anything. Add the avo gem, bundle, run bin/rails generate avo:install, and mount Avo at /avo behind that authentication so only signed-in staff reach the panel.
2. Work out the data this control panel operates on before writing a single migration. A panel like this needs the product's own records to act on plus the levers that steer them, so reason from first principles about the entities involved: the accounts and users the product serves, the feature flags and settings that change behavior, and any plan or subscription the account sits on. Give each account a lifecycle state (active, suspended, closed) modeled as an enum or its own status table, and decide how flags and settings associate, whether they are global or scoped per account. Sketch the associations end to end, then write the migrations. Treat the flags, plan changes, and kill switches the panel promises as behavior your schema has to support, not as a fixed list of tables to copy.
3. Generate an Avo resource per model with bin/rails generate avo:resource, and fill in the API rather than leaving the defaults. Set self.title to whatever reads as the record's name, list the columns worth matching on in self.search, add self.includes for the associations each Index touches so the grid does not run N+1 queries, and match field types to the columns you chose: as: :boolean for a flag or setting toggle so it flips inline from the edit form, as: :select backed by the lifecycle enum for account state, as: :belongs_to for the account a flag or plan hangs off.
4. Turn the panel's verbs into Avo Actions: suspend an account, reset a password or data, purge records, change a plan, extend a trial. Since the app is new, put the real work in the model or a small service object (Account#suspend!, a PlanChange service) and have each action call it rather than editing rows inline. Keep self.confirmation on, write a self.message that names the blast radius, set self.confirm_button_label, and require a reason as a textarea field. Actions run as current_user, so each change is attributable to the operator who ran it.
5. Add filters and scopes so operators can narrow to suspended accounts, accounts on a given plan, or flags that are currently on, and build an Avo dashboard that gathers the flags, limits, and toggles onto one screen with a few metric cards for account state (https://docs.avohq.io/4.0/dashboards.html).
6. Authorize with Pundit so support can flip the safe toggles while suspend, reset, and purge stay with a smaller admin group: policies decide who sees the panel, who can edit a flag, and who can run each destructive action (https://docs.avohq.io/4.0/authorization.html).
7. Seed realistic sample data, a spread of accounts across every lifecycle state, users under them, and a set of flags and settings in mixed on and off positions, so every resource, filter, and dashboard card has something to show on first boot.
8. Boot the app, open /avo, flip one feature flag from the UI with no deploy, then run the suspend-account action and confirm it asks before it fires and moves the account into the suspended state.