A venue package carries only the layout, so a hall moved between sites arrives with its configurations and its pinnings to rebuild by hand

A venue package carries a hall's layout: its areas, grades, places, outlines and default modes. It does not carry the hall's configurations, and both the yoyaku_placement_io README and VenueExporter give the same reason, which the schema does not support. The README says configurations reference slots and categories that live outside the venue. The exporter docblock says they reference slots and tariffs this package knows nothing about.

What they actually reference: yoyaku_configuration carries a venue, a key, a label and a weight, and its per-area rows carry the configuration, a section, a subsection number, a mode, a pool capacity and a pool grade. Every reference there is a section or a grade, and the package already exports both keyed by machine key, which is exactly how places re-resolve on import. Neither entity references a slot or a tariff at all.

So a hall with a complete layout and a reduced-capacity one does not survive a round trip. Re-importing gives back the geometry with the configurations to rebuild by hand, and any slot that named one has nothing to name. The export command does warn, and its warning makes the design claim rather than the factual one: it says how a hall is opened for an event is not part of a layout.

That claim is worth reconsidering on its own, because the same capability is what lets a fully configured venue be deployed as data rather than as code. An example or a demo that wants a hall with two layouts has to build it in an install hook today, place by place and setting by setting. With configurations in the manifest it ships a package and imports it, which is shorter, is reviewable as data, and exercises the real importer every time it runs.

The manifest is already versioned for this. Every key is optional and absence means what it always meant, so a version 5 adds configurations and their per-area rows without breaking any package written before it.

Pinnings travel too, and the allotments their held places name with them. A pinning is the venue's and so are the places it holds, but each of those is held under an allotment, which is tenant-level: the same names are set aside in every venue a tenant runs. So the package carries the allotments its pinnings need and no more, since a file naming a tenant's whole list would be describing the tenant rather than the hall, and an import matches each in the tenant by its key and creates only a key that tenant has never had, leaving its own name and color for a key it already has alone. A held place names its seat by the area's key with the row and the position, because a place has no key of its own.

The reason the prose gave for leaving pinnings out was wrong in the same way as the one for configurations, and in the same three places: an allotment does not belong to a resource. Its own definition says it is tenant-level, because the same schools take units in every resource a tenant runs.

And a house that wants less says so, rather than taking a file apart by hand: both commands take a list of what to carry, all by default, none for the layout on its own, or any of the keys. The hall travels whatever the list says, since a file without it would not be a package. On an export the list decides what is written; on an import, what is read, so a file carrying more than a site wants still imports for its hall alone. The export reports what it left out, and the import says how many held places it could not resolve rather than leaving seats nobody was told about.

AI-Generated: Yes (Claude Code was used to check the configuration entities against the reason the module gives for excluding them, and to draft this issue summary. I reviewed it before posting; there is no code on this issue yet.)