Build a back office on Rails

Scaffold a fresh Ruby on Rails application whose back office runs on Avo 4 (https://avohq.io, docs at https://docs.avohq.io/4.0/). Start from an empty directory and create both.

1. Generate the project with bin/rails new, keeping the default database and asset setup. Create staff login with the built-in authentication generator (bin/rails generate authentication), add the avo gem, run bundle, then bin/rails generate avo:install, and mount Avo at /avo so only a signed-in staff member reaches it.
2. Design the data before writing a single migration. Reason from what running this business actually requires: the transactions or purchases money flows through, the people or accounts behind them, and the records that capture money moving back out such as refunds or credits. For each entity decide its lifecycle, an order that is pending, paid, on hold, or refunded, and model that as an enum when it is a simple status or its own table when a stage carries its own data, then work out how the entities associate. Write the migrations from that plan and run them.
3. Run bin/rails generate avo:resource for every model. On each one, set self.title to the identifier staff quote out loud, add self.search with a ransack query over the columns they look records up by like a reference number or an email, and list the rendered associations in self.includes so the index and detail views do not fire a query per row. Match field types to the columns you created: as: :badge for the status enums, sortable as: :date_time for timestamps, and as: :belongs_to and as: :has_many for the relationships.
4. Turn the operational verbs, issuing a refund, placing an order on hold, correcting an address, changing a plan, into Avo Actions. Since the app is new, put the real logic in model methods or small service objects and have each action call into them behind a confirmation, running as the signed-in admin so who did what is recorded.
5. Add filters and scopes that surface the queues staff work, refunds awaiting approval, orders on hold, accounts flagged for review, and build a dashboard (https://docs.avohq.io/4.0/dashboards.html) with the counts and lists that show the day's operational load at a glance.
6. Gate everything with Pundit policies (https://docs.avohq.io/4.0/authorization.html): support can look up customers and orders, ops can act on them, and only finance can run the money-moving actions. Pair the actions with paper_trail or a small audit table so finance gets the durable trail of who changed what and when.
7. Seed the database with believable sample data, several customers, their orders across every status, and a few refunds, so every screen, filter, and dashboard has something real to show on first boot.
8. Boot the app, sign in, open /avo, look up an order by its number, and run the refund action on it, confirming the status changes and the refund is attributed to you.