The Tugboat preview installs one submodule of thirty, so a reviewer cannot try a booking, its place map, its workflow, its payment or its emails

The Tugboat preview installs the engine and its admin screens: yoyaku plus yoyaku_ui, one of thirty submodules. A reviewer who opens a preview can read seeded resources, slots and tariffs through the admin screens and over JSON:API, and can do nothing else. There is no calendar, no booking page, no cart, no place map, no workflow, no payment and no email. The two modules that exist to be tried, yoyaku_placement_example and yoyaku_orchestra_example, are not installed, and the code they need is not in the built site either: orchestra, kessai, webform and easy_email are require-dev, and the preview asks composer only for yoyaku and admin_toolbar.

What a preview should offer is one seeded concert in a real hall, bookable from end to end: pick places on the map, hold them, pay with the simulator gateway, watch the workflow settle and confirm the order, and read the notification emails it sent.

Most of that already ships. yoyaku_placement_example builds the hall: sections, place grades, places, a concert, a slot and its tariffs. yoyaku_orchestra_example builds the paying workflow, with a form step, a payment wait step, a kessai settle task and the guarantee authorize, release and refund actions, and it already sets the simulator as the default gateway when it installs. kessai_simulator is a complete fake-card gateway (authorize, capture, cancel, refund, card tokens) with a checkout form of its own. The whole chain runs today in BookingWorkflowE2eTest, which pays through SimulatorCheckoutForm and asserts the settlement, so what is missing here is not the machinery.

What is missing:

• The preview has to ask composer for orchestra, kessai, webform and easy_email. They are require-dev, so nothing installs them in a built site.
• Nothing attaches the paying workflow to the hall. Each example seeds a resource of its own, so the concert is not driven by the workflow and the workflow's resource has no places to pick. Neither example can take the wiring on: whatever names both stacks has to declare both, which ModuleBoundariesTest enforces, so the seats demo would pull in orchestra, webform and kessai, or the workflow demo would pull in placement. Today one declares a single dependency and the other six, and either can be installed on its own, which is what an example is for. So the wiring belongs above them both.
• The notifications go nowhere a reviewer can see. The easy_email types ship as optional config in yoyaku_orchestra_order and install themselves as soon as easy_email is present, so what is left is capturing what they send and putting it behind a link, which is what a mail log such as maillog is for.
• The seed in .tugboat/setup.php hand-rolls a court and a conference with slots, tariffs, a few bookings and a front page of its own, which makes it the third place in this codebase that seeds a bookable resource with slots and a page to book it on. Its header also still describes a preview in which the calendar and the UI do not exist yet, and calls the project by the name it had before it moved.

Above them both is the demo recipe on #3621539, which sets up a working calendar in one step. It is the one thing here that may depend on everything, so the concert hall wiring goes there, rather than into a second demo path that would drift from it.

That gives two demos rather than one, and the preview applies the second. yoyaku_demo is the plain calendar of #3621539: the engine, the calendar, one bare bookable resource with a month of slots, and a front page that books it. yoyaku_demo_orchestra demonstrates the Orchestra integration and is named for what it requires rather than for any scenario it seeds, so a later demo of another integration follows the same shape. Its recipe applies the plain one, since a recipe may apply another recipe, and its module depends on the plain module, so the two install and tear down in an order where the front page each of them moved is put back by whichever moved it. A module is needed at all because a resource, a page, and the workflow a resource is driven by, are content rather than configuration, which a recipe cannot create: the plain module owns the front page and the resource field's display, and the other owns the hall wiring and the guide. Everything that is configuration stays in the recipes, including the permission grants and the routing that sends mail to a log.

Payment and the notifications belong to that same demo rather than to demos of their own. Kessai settles through the settle step in yoyaku_orchestra_payment, so the simulator gateway is part of the integration being demonstrated and not a third thing beside it, and the easy_email types the workflow sends are what make a mail log worth opening. It follows that yoyaku_demo_orchestra is also the whole of what the preview installs today, which is a consequence of it being the only integration demo rather than something to name it after: the day a second one exists, there is no single demo left to call the full one.

The seated half is the hall the placement example already builds: four areas, four rows of eight, 128 places, one grade an area, with the Opera Gala running in it. That is enough on purpose, because a closed area is legible on 128 places and invisible on 1,400. What the example has none of is a placement configuration, so nothing in it shows a reduced capacity, a part of an area closed on its own, or one hall opened two ways, which is the more valuable half of the placement model and the part this demo has to add. A configuration records only its deviations, so several of them cost a handful of rows on a hall this size. Once #3622067 lands, the hall and its configurations arrive as a venue package the demo imports rather than as an install hook building them place by place, which is shorter, is reviewable as data, and exercises the importer every time the demo runs.

The slots reach two years out rather than a fortnight, so a site that applied a recipe does not come back to a calendar whose every slot has passed; the preview reseeds on every build, so this is for the site that applies one and returns a month later. Two years is not a round number: AvailabilityController clamps a requested month to 24 months either side of now, so anything seeded past that edge cannot be reached through the feed at all. Dense near and sparse far is what keeps the count sane, daily for the first weeks so the calendar is alive on the day it is opened and a day or two a week out to the edge after that, which is a few hundred rows a resource rather than the 1,460 that two years of daily slots would cost. A rolling horizon kept by cron would be better, and is what recurrence is for, but yoyaku_recur does not exist yet and a demo should not grow a scheduler the engine has not got.

Two things to settle before building. The preview has to serve Drupal at the root, because the workflow's form resume is known to lose its submission under a subdirectory base path. And the simulator gateway must reach nothing but a preview, which is what its own requirements warning says: it reports every payment as successful and collects no money.

AI-Generated: Yes (Claude Code was used to survey what the preview installs against what the module ships, and to draft this issue summary. I reviewed it before posting; there is no code on this issue yet.)