Build a CMS on Rails

Build a fresh Ruby on Rails content management system from nothing, with Avo 4 (https://avohq.io, docs at https://docs.avohq.io/4.0/) as the editorial UI. There is no app and no schema yet, so scaffold everything.

1. Generate the application with rails new using the standard defaults and a real database. Set up sign-in with Rails' built-in authentication generator so there is a User to hang editor accounts on. Add the avo gem, bundle, run bin/rails generate avo:install, and mount Avo at /avo so only a signed-in user reaches it.
2. Design the content model from first principles before you write a single migration. A CMS revolves around the writing your public site renders, the people who produce it, and the workflow that moves a piece from idea to live page. Decide which of those deserve their own tables, how they relate (an author has many posts, a post carries tags, standalone pages may stand apart from the blog feed), and where publish state belongs. Model that state as an enum on the record when the transitions are simple, or as its own table when you need history or scheduling. Treat slugs, SEO metadata, cover images, and scheduled-at timestamps as columns you add on purpose, not as an afterthought. Sketch the whole schema, then generate the migrations.
3. Generate an Avo resource per model with bin/rails generate avo:resource and make the API concrete. Set self.title to the human label editors recognize (a post's headline, an author's name), list the columns worth searching in self.search, and eager-load associations through self.includes so Index views stay fast. Match each field to its column: field as: :trix with attachment_key: for the long-form body so writers get a WYSIWYG editor with inline Active Storage uploads, a file field for cover images and a media library, a select mapped to your status enum, a date_time for the publish timestamp, a belongs_to for the author, a tags field for categorization, and textarea or text fields for slug and meta description, hidden from Index where they only add noise. See https://docs.avohq.io/4.0/resources.html.
4. Turn the editorial verbs into Avo Actions rather than console work: publish, unpublish, schedule, archive. Put the real behavior in the model or a small service object (a publish! method that stamps published_at and flips the enum, a scheduler that queues future posts) and have each action call it, so the workflow logic lives in Ruby you can test, not in the admin.
5. Give editors the overview a CMS needs. Add a model scope for published content and surface it as an Avo scope so drafts and scheduled work stay out of the live view, add filters by status and author, and build a dashboard with metric cards for posts published this week, drafts awaiting review, and posts per author (https://docs.avohq.io/4.0/dashboards.html).
6. Authorize with Pundit so roles are enforced, not assumed. Writers create and edit their own drafts, editors publish and manage everyone's work, and the publish action is gated to the editor role so the button is a permission rather than a trust exercise (https://docs.avohq.io/4.0/authorization.html).
7. Seed the database with believable sample content: a handful of authors, a spread of posts across every lifecycle state including a scheduled one, tags, a couple of standalone pages, and cover images, so every screen, scope, filter, and dashboard card has something real to render.
8. Boot the app, sign in, open /avo, write a draft with an inline image, run the publish action, and confirm the post moves to published while the drafts and scheduled pieces stay off the public feed.