Preview fixtures and sample data

DataMind Oda's browser preview builds its file tree in memory and mounts a fixture over it: a named set of overlay files chosen before the run starts. The fixture decides which sample files and sessions the preview opens with. This page covers how fixtures are defined, what the shipped sample contains and how older sample sessions are kept compatible; starting the preview and choosing its data is on Browser preview.

What a fixture is

• A fixture is a named set of overlay files. The preview mounts its own base files first, then applies the fixture's overlays in order.
• Overlays apply only under the preview's home and workspace directories. They cannot replace the preview's own program files or its configuration.
• The fixture is picked before the preview starts, so the run begins with the sample already in place.

Define a fixture in the manifest

The preview takes the list of fixtures from a manifest named fixtures.json. The manifest has three fields:

• version: the manifest format. It must be 1.
• defaultFixture: the fixture selected by default, or null when there is no default.
• fixtures: the list of fixtures.

Each fixture carries four fields:

• id: the fixture's name: lower-case letters, digits and single dashes. The ids none and webfs are reserved.
• label: a short name for the fixture.
• description: what the fixture is for.
• overlays: the fixture's overlay files, in order. There must be at least one, and each must be a non-empty address.

A manifest that breaks these rules is refused rather than used, and the message says what is wrong:

• preview fixture manifest must use version 1
• preview fixture manifest contains an invalid fixture entry
• preview fixture manifest repeats id "<id>"
• preview fixture manifest defaultFixture does not name a fixture

Other messages the preview prints are collected on Preview diagnostics.

The bundled sample workspace

The sample fixture opens with a small workspace, so the preview has something real to show:

• A guide whose first line is the heading # Preview Workspace; it introduces the other files and ends with the reminder Refresh the preview to restore these image bytes.
• A small script example in src/preview.ts. The tour's write card shows its change: previewStatus moves from 'draft' to 'ready'.
• A task checklist in data/tasks.json, titled Preview verification, with three completed tasks: Inspect tool cards, Open both subagents and Load earlier history.
• A bundled skill named preview-tour, described as Inspect the bundled Preview workspace and its deterministic Session examples. It runs the sample tour: read the workspace files, inspect the tool gallery, open both subagent histories and load the earlier conversation page.

The seeded sample sessions

The sample also seeds sessions, so the preview opens with histories to explore:

• A showcase session that tours the preview. Its cards include preview ready, the updated to-do list Updated todo list: 0 pending, 1 in progress, 2 completed., started subagent preview-follow-up-builder, the failed read Error: ENOENT: no such file, open missing.txt and the closing card ## Preview tour complete.
• The showcase holds more than 50 messages, so its history is paged and the oldest entries sit outside the first page.
• Two subagent histories sit behind it: one runs through 28 checkpoints and then a review turn; the other is started during the showcase.
• The two helper records use fixed descriptors: each says where it came from, that it sits one level under its parent, and whether it is one-shot or continuable. The seeded part of each history is separated from the turns that follow it.

Keep older sample sessions compatible

Session logs change over time, and the sample keeps that history on purpose:

• The showcase conversation ships in two generations: the earlier log format (v2) and the current one (v3). The two files differ only in their version field.
• The earlier file is a predecessor: keep it exactly as written. Never rewrite it and never upgrade it to a newer format.
• Regenerating the sample must reproduce the current file exactly, so it stays in step with the format the preview writes today.
• The sample is deterministic: its sessions run on a sample model rather than a real one, and the provider and model names it reports come from the fixture, so the same conversation appears on every run.
• The session list stored with the sample is written at version 7.

Questions, answered

What sample data comes with the preview?

A small workspace and a prepared showcase session with two subagent histories behind it. The workspace holds a guide, a script example, a task checklist and a preview-tour skill.

How do I restore the sample workspace after changing it?

Refresh the preview. Edits live only in the preview's memory, and a refresh mounts the sample again from its original bytes; the workspace guide carries the same reminder: Refresh the preview to restore these image bytes.

How do I add a fixture of my own?

Add an entry to the fixture manifest: an id, a label, a description and the addresses of its overlays. The preview validates the manifest when it reads it and refuses one that breaks the rules.

What happens if the fixture manifest breaks a rule?

The preview refuses the manifest, and the message names the fault: a version other than 1, an invalid entry, a repeated id, or a default that names no fixture. The four messages are listed above.

Why do two generations of one sample session sit side by side?

To keep an old format honest: the earlier file is a predecessor that is never rewritten or upgraded, while the current generation must match what the preview writes today. The two differ only in their version field.

Why does the sample history have an earlier page?

Because the showcase holds more than 50 messages: the oldest entries do not fit on the first page of its history, and loading the earlier page is part of the tour.

What does the bundled tour skill do?

It runs the sample tour: read the workspace files, inspect the tool gallery, open both subagent histories and load the earlier conversation page. Its description reads Inspect the bundled Preview workspace and its deterministic Session examples.

Do the sample sessions use a real model?

No. They run on a deterministic sample model, and the provider and model names it reports come from the fixture, so the same conversation appears on every run.

Why does one sample card show an error?

The tour includes a failed read on purpose, so a tool card that reports a missing file is shown as well: Error: ENOENT: no such file, open missing.txt.