Epic: the barako expert's path, from taking a client's order to pouring it with BaryoVM

**Rewritten 14 September 2026 as the umbrella for the barako expert's path.** The original map (blueprints, forms, SEO fields, redirects, a media library, a frontend starter, white-labelling) is below; most of it has shipped or is in flight.

## The goal

A barako expert takes a client's order, whatever it is (a site, a newsletter, a magazine, HR, payroll, booking, vehicle tracking; online or offline; on premises, cloud or hybrid; one process or distributed), brews it from the same products, and pours it with BaryoVM. No backend written from scratch, because the backend is the same every time.

**Model it in barakoCMS. Edit it in barakoBrew. Render it with barakoPress. Deploy it anywhere.**

## The path

| Step | What the expert does | Issues |
|---|---|---|
| Take the order | Opens VS Code; the café asks "May I take your order?" and reads the order back as a ticket | #843 |
| Open the café | `barista up`: the API, barakoBrew, barakoPress and Postgres locally, with a tenant | #844, #801 |
| Brew | Configures in barakoBrew, or has Claude Code do it with barista; the same API either way, reviewable as files | #801, #345, #182, #183, #186 |
| Taste | Previews each tenant's site, checks the look against the design, sees runs and services as screens | BaryoDev/barakoPress#20, #27, BaryoDev/barakoBrew#143 |
| Pour | Deploys with BaryoVM: tenant domains, TLS, hybrid and air-gapped installs, later Azure and AWS | BaryoDev/BaryoVM#87, #49, #82 |
| Keep it running | Pulls recorded errors, files tagged tickets, sends agents to fix them | #851, #833 |

## Release trains

- **Train 1, 4.2.0:** rckoronadal.org on the stack (#722).
- **Train 2, 4.3.0:** open the café: barista 0.1, client libraries, config as code, baryo.dev, off-host backups.
- **Train 3, 4.4.0:** workflows that chain, services, barakocms.com.
- **Train 4, 4.5.0:** business systems: computed fields, reports, payments, booking, newsletter.
- **Train 5, 4.6.0:** offline, telemetry, scale; the VS Code extension preview.
- **5.0.0:** the portal and the breaking changes.

---

## The original map
The goal this is all pointing at: an agency takes on a customer, spins up BarakoCMS, models what the customer actually asked for, points a frontend at it, and hands it over. No backend written from scratch, because the backend is the same every time.

Most of it already exists. This issue is the map: what is there, what is missing, and where the gaps are worth taking.

## Already there

| Need | How |
|---|---|
| One deployment, many customers | Multi-tenancy, conjoined on one database |
| Provision a new client | `POST /api/tenants` |
| Model what the customer wants | Content types defined at runtime, no rebuild |
| Who can see what | RBAC with per-field sensitivity |
| Review before publishing | Workflow with pluggable actions |
| Serve it to any frontend | Public delivery API, opt-in per type |
| Navigation | Menus |
| Uploads | Files module, local or S3-compatible |
| Hand the site over | Portability export and import |
| Turn things on per client | Feature flags with per-tenant targeting |

That is a lot of a project already done on day one.

## The gaps

Ordered by how often an agency hits them:

1. **Content type blueprints**: every new site starts from an empty schema. A blog, an events site and a portfolio need roughly the same types every time, and typing them out again is exactly the from-scratch work this is supposed to remove.
2. **Form submissions**: practically every client site has a contact form, and there is nowhere for a submission to go.
3. **SEO fields**: meta title, description, canonical, social image. A client site without these is not finished, and every agency currently invents its own convention.
4. **URL redirects**: a rebuild changes URLs, and the old ones have to keep working. This is a migration blocker, not a nicety.
5. **A media library worth using**: files upload and download over the API, but there is no browsing or picking experience, so choosing an image is not a thing an editor can do.
6. **A frontend starter**: see #94 for the SDK. A working Next.js site wired to the delivery API turns "here is an API" into "here is a site".
7. **White-labelling the admin**: the client logs into this. It should look like their project, not ours.

## Where to start

Blueprints (#1 above) is the highest leverage and the most self-contained: it needs no new storage, just a way to apply a set of content types. Forms and SEO are the next two, and both are natural modules rather than core changes.

Individual issues are filed for each. Comment on this one if you want to take a theme rather than a single issue.