Fixtures and scenarios

What it is

A fixture is the sample content a section previews against while you develop it — never production content, and never published. Golden scenarios are the raw material fixtures build source: complete, realistic property datasets the kit ships, so every section draws on the same data rather than each author inventing an address, a unit count, or a set of photos of their own. Browse the scenarios for what each one covers and when to reach for it.

Why it works this way

Previewing a section against invented copy proves almost nothing. A layout that looks fine against “123 Main St” and a couple of placeholder sentences can still break the moment it meets a real property: a sparse listing with no floor plan, a headline three times longer than the designer imagined, a hero slot whose one assumed photograph doesn’t exist. Those aren’t hypothetical edge cases to handle later — a generated value can legitimately come back shorter or longer from one run to the next, so a section has to render acceptably across that whole range, not only the length an author happened to preview against.

Golden scenarios exist to make those hard cases a shared vocabulary instead of a private guess. When every section previews against the same handful of realistic datasets, a reviewer comparing two templates’ handling of a sparse property is comparing them under conditions neither author chose for themselves — the comparison is only fair because neither invented their own sample data. A fixture built on a scenario also carries a kind of proof invented copy cannot: a slot bound to a property fact is filled from the scenario by the very same source its declaration names, so previewing that fixture proves the binding as well as the markup drawn around it.

The second reason is more mechanical, but just as load-bearing. A fixture never ships — it exists purely for local preview, so a published deliverable can never carry preview data by construction, not by discipline. That’s also why the scenarios live on their own entry point rather than the package root: dev-only sample data has to stay structurally unreachable from a published renderer’s import graph, not merely unused by convention.

How it works

A section’s fixtures module builds its baseline on one scenario and authors only the handful of slots nothing else can resolve — a slot bound to a fact, or to a computed value, is filled straight from the scenario by the same source its schema declares, so most of a fixture writes itself. The handful an author still has to fill are grounded in that same scenario’s facts rather than invented, and a literal override remains the one escape hatch for a value no scenario produces. A state that needs to look different against a thinner property builds on a different scenario entirely, rather than overriding literals on top of the baseline, so every slot in that state stays grounded in one real, self-consistent set of facts rather than a mix of two. See fixtures.ts for the declaration in full, and AI fill for what actually produces the values a scenario’s generated-copy slots stand in for.

What it is not

Not content: a fixture states sample values, never anything a property owner or agent actually typed. Not tests: a fixture proves a section renders against realistic data, not that it behaves correctly — verifying behavior is a separate step. Not seed data: nothing about a fixture or a scenario ever reaches a production database or a published page.

Where next

• fixtures.ts — the fixtures declaration in full.
• The golden scenarios — what each scenario covers.
• Pick a scenario — building a fixture from one, step by step.
• Preview a section’s states — adding a state for a structural edge case.