Arrangements name topologies; variants are modifiers; semantics are rune-locked

Consequences

The first shipment is a rename plus one stable and two provisional additions. data-zone-layout and data-sequence become values of one data-arrange vocabulary; grid lands stable; rail and track land provisional. Theme authors learn one vocabulary with uniform applicability instead of three with different coupling rules.

The provisional tier needs teeth or it is a comment nobody reads. If nothing marks a provisional arrangement as unstable, it becomes stable by adoption and the tier has achieved nothing. Minimally: the theme contract records each arrangement's tier, and a theme using a provisional one is told so at build time. Without that, 5b is strictly worse than the old rule, because it ships guesses with the appearance of a guarantee.

Provisional is not a parking space. An arrangement that sits provisional across several releases with no second consumer is evidence the contract was wrong or the need imagined, and should be removed rather than left to accrete users. Removal is the tier's whole point and has to actually happen.

radial is not a topology. Under rules 1 and 2 a cycle is a ladder whose ends join: stack mode is a vertical ladder, strip is horizontal + wrap, wheel is radial + wrap, grid is a grid. radial is a direction value alongside vertical and horizontal, and wrap is the one genuinely new modifier — it is what distinguishes a cycle from a list.

The rename needs addressable item containers. sequence: is declared rune-level and applied by walking the tree for <ol> elements; arrange is declared per container, which requires that container to be nameable in the layout tree. Five of the six sequence consumers already name theirs through refs — HowTo, Recipe, Timeline, Itinerary — or directly on the tag (Playlist). Steps does not, and WORK-585 closes that gap independently of this decision.

Nesting needs no new machinery. Rule 4 is what makes a theme able to change a playlist from rows to cards. WORK-584 Q1 established that the engine already supports it: every data-rune node gets its own assembly pass from its own config, so a container's topology and its items' inner layout are declared independently as a matter of course. An arrangement vocabulary inherits this rather than having to build it.

Semantic locking needs somewhere to live. Rule 3 requires the engine to distinguish rune-owned from theme-owned modifiers on the same arrangement. ADR-029 draws the equivalent line for containers — a semantic container carries data-section, a presentational group does not, and sections is identity-guarded so a theme cannot cross it. Modifiers need the same treatment, and the two should use one mechanism.

A group-name vocabulary is separable and costs almost nothing. Rule 6 is a documentation page and an agreed list — no engine change and no CSS. Themes can already create named groups through layout (WORK-584 Q1) and already give them shared geometry by declaring a zone layout, which skeleton already styles. It can ship before any arrangement work and is the one part of this decision with an immediate audience, plugin authors included: they have no group name they can rely on today when shipping CSS for their own runes.

Composition changes what rule 5b's "a concrete design that wants it" means. Recorded after the fact, because the justification moved. When this decision was written, an arrangement vocabulary consolidated bespoke CSS — five runes with their own grid, one with its own row — and the gain was tidiness plus a theme's ability to restyle.

SPEC-145 makes it enabling. A composed rune has no block (D2), so it has no selectors of its own, and its appearance is whatever the theme gives the primitives it places. For a first-party composition a theme can reach it by name through contextModifiers (SPEC-145 D16). For a user-authored one it cannot: Lumina will never have heard of wine-tasting-note, and ADR-037 makes user-authored compositions the only way a rune reaches a site from outside this repo. So a vocabulary the theme styles without naming the rune is the only route those runes have to being styled at all.

Rule 4 is the specific case, and it now has a measured consumer. SPEC-155 found playlist composable on every axis but appearance, and the appearance gap is exactly the ladder-of-rows this decision named: 98 lines in lumina/styles/runes/track.css, every selector keyed on .rf-track / .rf-track__*, all of it unreachable once the rune has no block. That satisfies 5b's "at least one concrete design that wants it" with a design that exists rather than a sketch — and 5a's three-implementation bar is separately met for the row/ladder case by track rows, cast's list roster and steps.

This decision still does not authorise building anything. It constrains a later spec. If that spec never comes, nothing is owed — but the thing owed if composition ships without it is now stated: composed runes that only the theme's author can style.

Rules 5a and 5b have been borrowed for a second vocabulary, and that extension should be explicit rather than assumed. Every rule here is written about topologies — rule 1 defines an arrangement as the shape of a container-to-children relationship, and 5a/5b say "a consolidating topology" and "an enabling topology". SPEC-159 applies the same two bars to chrome axes (materiality, variation), which are qualities of a single surface and not relationships at all, and its D8 records walking into 5a's counting trap on the way.

The borrowing is sound and the generalisation is worth stating: 5a and 5b are bars on a theme-facing vocabulary term, whatever the term describes. What transfers is the asymmetry — a term that replaces existing hand-rolled CSS is claiming recurrence and owes instances; a term that enables something nothing can express today has nothing to count and owes a contract, a case and the provisional tier. Nothing in that reasoning depends on the term being a topology. Rule 3's semantic/cosmetic split transfers too, and lands cleanly: chrome is cosmetic by construction, so chrome axes are theme-free and none of them may encode whether something is information.

Which makes the provisional tier's teeth overdue rather than pending. The consequence above — "the provisional tier needs teeth or it is a comment nobody reads" — was written with rail and track in view. SPEC-159 D9 adds two more provisional terms in a different vocabulary, so there are now four queued behind a mechanism that does not exist, and the first shipment of either vocabulary is the one that decides whether 5b is a tier or a disclaimer. Two provisional terms with no build-time signal are a rounding error; four across two vocabularies is a convention.

Rule 2 forbids naming a combination; SPEC-159 Part 3 names combinations deliberately. Both are right, and the reconciliation belongs here. Rule 2's target is the axis: promoting timeline to an arrangement value owes timeline-horizontal and timeline-grouped, because every modifier multiplies through the name. A composite intent sits in a separate layer above the axes, resolving to axis values rather than joining them — so it adds no value to any axis and nothing multiplies. That is rule 6's territory (vocabulary is cheap, mechanism expensive) and the governance follows rule 6's bar, not rule 5's.

The reading generalises, and saying so now costs nothing: a composite arrangement would be allowed on the same terms — a name resolving to ladder plus its modifiers is not a new topology, exactly as keepsake is not a new chrome axis. Nothing proposes one, and the rule that would govern it is already written.

The guard that keeps the layers honest is rule 6's own: "a group name carries no geometry." Its chrome analogue is that a composite intent carries no CSS — if a preset can paint, it has stopped being a name for axis values and become a specification, which is the mechanism SPEC-159's first revision proposed and its rewrite rejected.