Validation, Import, and Release Discipline

Treat every change to the System as a release candidate. Craft CDF imports can touch schemas, layouts, computed expressions, references, settings, and many records at once. A preview that looks plausible is not enough; validate before handoff and use the server preview as the final gate.

Start from the latest export

After every successful import, export a fresh CDF before beginning the next wave. That export contains Craft's current fileTypeId values, schema hashes, reference IDs, normalized records, and settings hash. Building from an older workspace risks ID drift and conflicts with server state.

Do not recreate server-assigned identifiers. Preserve them. New file types and records can receive new identities through Craft, but existing ones should keep the identities from the latest export unless the platform itself replaces them.

Local checks

At minimum, parse every JSON file and validate every content record against its File Type schema. Resolve every structured reference. Verify that computed fields are not stored as ordinary content. Check expression syntax, dependency direction, creation-flow graphs, and every layout $state binding. Make sure a StatGrid or control binds to a compatible field type. Check that project settings preserve unknown keys rather than regenerating .craft/project.json from a partial key list.

For handbooks, validate unique chapter IDs, title/content limits, reading order, and real reference IDs for file mentions. For a System, confirm that isClonable remains true and that no setting-specific root map, prelude, or World canon has leaked into the generic project.

Craft validation

If the Craft CLI is authenticated and available, run craft check before push. It uses the platform's validation rules for schemas, expressions, references, settings, and flows. When the CLI is unavailable, the CDF Import Preview is the final server-side gate.

Compare the preview counts with the expected delta. If you expect six type updates and the preview shows twelve, stop. If the server reports an internal error, do not retry blindly. Isolate the new schema, expression, flow, or setting that differs from the last successful baseline.

System test fixtures

Synthetic files beginning with System Test are intentional validation fixtures. Use them to prove formulas and edge cases before populating real game content. They should be unmistakably non-canonical. A World builder can keep them during development and remove or replace them before publication.

Publication and manuals

A System intended for other builders should ship with a Player's Handbook and a Builder's Manual. The Player's Handbook explains the common engine; the Builder's Manual explains how to extend it without breaking the System/World boundary. Project page copy should say clearly that this is the reusable System layer.

Before publishing a release, review every warning rather than chasing a generic world-completeness score. Systems are not Worlds: a missing root map or playable opening can be a deliberate omission, while missing rules, schemas, layouts, instructions, examples, or builder guidance are real defects.

The safest workflow is simple: fresh export, small wave, local validation, expected diff, Import Preview, successful import, fresh export. Repeat.