# Deterministic demo fixtures with TDD

Use when adding a local demo/sample fixture that later integrations will wire against (CLI, Telegram sender, API smoke path).

## Pattern

1. Write the wished-for import/API in a focused test first, even if the package/module does not exist yet.
2. Assert durable behavior, not incidental text:
   - fixed batch/demo id;
   - stable candidate/item ids in order;
   - expected bucket/classification counts;
   - explicit safety invariants such as absence of publish/post language when review and publishing must remain separate.
3. Run the new test and verify RED is the missing module or missing API, not a typo.
4. Implement the smallest deterministic fixture/helper needed to pass.
5. Run the focused test, then the full suite.
6. Add one smoke invocation if the fixture is meant for a future CLI or sender, e.g. import function and print/render output.
7. Document the demo fixture in README or equivalent project docs.

## Example shape

- `build_sample_<domain>_batch()` returns the structured sample object.
- `render_sample_<domain>_batch()` runs the real workflow/render path and returns integration-ready text.

Keep fixture data boring, explicit, and deterministic. Demo fixtures are contracts for later wiring, not miniature content generators.