golden-dataset

Run golden-dataset after completing replace-strategy setup. Phase A designs logical data from DDL constraints and the feature inventory, generates an idempotent seeding tool, and seeds the current test environment. Phase B later maps the same data to the new schema.

Use the two-phase approach: Phase A seeds the current side first since the new schema does not exist yet. Once parity-replace implements the new schema, run golden-dataset --phase b --feature <slug> --target <name> to map and seed the new side per target.

No. The Skill never references or seeds production environments and builds data from scratch with fixed IDs, sequences, UUIDs, and base times. Only non-production existing data may inform design, and only with a masking policy applied.

Non-idempotent or random data breaks current-vs-new comparison because each run produces different values and states. The tool deletes then inserts in FK order with fixed values, so repeated runs always converge to the identical state on both sides.

parity-suite records data shortages in gaps.md, which routes back to this Skill for a Phase A re-run. The design is extended, the tool updated and re-seeded, the dataset version incremented, and affected baselines are flagged for re-capture.

Yes. With dataset_mode: static, the tool generates deterministic static data under dataset_static_paths in the repository instead of a database, so DB-less static sites still support the full Phase A and Phase B workflow.