Installing, Migrating, and Updating Safely

The Living World Engine supports brand-new projects and existing worlds. Those are different jobs, so the word Setup does not automatically mean “erase everything and install a fresh template.” Setup begins by inspecting the project and deciding which path is safe.

The command you should use

Open Orbit in the World Builder and type one of these exact commands:

Command	Use it for
Setup	Detect the project and choose the correct installation path
Quick Start	Build a lean new-world foundation without configuring every optional system
Update	Apply a newer LWE release to an existing LWE installation
Migrate	Repair or convert overlapping file types and records
Re-personalize	Change genre, terminology, tone, templates, or presentation
Status	See what Setup finished, skipped, deferred, or still needs
Diagnose	Inspect broken schemas, references, layouts, or runtime behavior
Help	Explain the next safe step when a workflow is confusing
Validate	Run the publishing and acceptance checks
Ship Update	Finalize release metadata after you intentionally create a new package version

The Setup entry point @Missing file and Update entry point @Missing file route Orbit into the correct internal procedures.

Installing into a new world

For an empty project, Setup creates or personalizes the foundation, then helps establish the first playable area. It should ask about genre, tone, scale, terminology, calendar, rules, complexity, image policy, and what kind of experience you want.

You do not need to answer with a design document. Something like this is enough:

Dark fantasy kingdom, character-driven, dangerous but not relentlessly miserable. Low starting power, rare divine magic, one main city and surrounding wilderness. I want relationships, factions, pressures, time, and reputation active. Keep succession systems dormant for now.

Setup can turn that into a working foundation and leave optional systems available for later.

Installing into an existing world

For an existing project, Setup should adopt and upgrade in place. It inspects your current file types, records, paths, references, custom fields, and layouts before writing.

The normal strategy is called same-slug in-place migration. That means:

• An existing character type remains the canonical Character type.
• Compatible LWE fields are added to it.
• Your custom fields are preserved.
• Existing records keep their identity and references.
• New fields remain optional until old records can satisfy the schema.
• The layout is merged or rebuilt without intentionally discarding your useful sections.

This is much safer than creating a duplicate type, copying every record, deleting the original, and renaming the copy.

When a duplicate type is acceptable

A temporary bridge may be needed when there is a real platform or schema limitation, a slug truly changed, one type is being split into several, several types are being merged, or the original type identity is damaged. That is an exception—not the default.

Orbit should record why the bridge is necessary and should not delete the old type until record counts, references, custom data, and layouts have been verified.

What “my schemas are broken” may mean

Creators often use that phrase for several different problems:

• Existing records fail a newly imported schema.
• Old fields still exist but no longer appear in the layout.
• References point to deleted or renamed records.
• A field changed from text to reference, or from string to object.
• A layout binds to a field that the schema does not define.
• Duplicate file types now compete for the same purpose.
• Orbit wrote computed fields that should have remained read-only.

Run Diagnose before manually deleting anything. The Diagnostic workflow @Missing file should identify whether the problem is data, schema, layout, reference, or migration state.

Updating LWE later

Type Update. The update system compares the installed version to the package version, reads the Version Manifest, builds a per-type migration plan, preserves authored data, applies changes in bounded phases, and validates the result.

An update should not:

• Re-run fresh setup over a completed world.
• Reset your genre or terminology.
• Replace your Characters with examples.
• Erase custom fields because they are not part of the base package.
• Regenerate every image.
• Delete Setup and migration infrastructure.

The safest habit

Keep a copy of the project before a major migration, read the import preview, and do not approve destructive changes you do not understand. The engine is designed to preserve your work, but no creator should treat deletion warnings like decorative confetti.

When Setup or Update finishes, ask for a plain-language report containing:

• What was created
• What was upgraded in place
• What was adopted or merged
• What was preserved untouched
• What was deferred
• What still needs review
• Whether validation passed

That report is your proof that the project was actually migrated rather than merely made to look busy.