Troubleshooting, Maintenance, and Common Questions

This chapter is the practical rescue kit. Start here when the project looks intimidating, an import failed, a layout lost fields, or Orbit seems to be making things up.

“My old Character sheets look terrifying now.”

That is usually a presentation problem, not a requirement problem.

You do not need to fill every field. Begin with identity, current Location, motivation, important relationships, and only the mechanics your world uses. Leave the rest blank.

Ask Orbit:

Review my existing Character records. Preserve all authored data. Identify which new LWE fields are genuinely useful for this world, which can remain blank, and whether any legacy fields are missing from the layout. Do not invent filler.

“My original schemas are broken.”

Run:

Diagnose

Then ask for the issue to be classified as one of these:

• Record fails schema
• Missing field in schema
• Layout binding points to a missing field
• Field exists but is not rendered
• Reference target is invalid
• Duplicate file type
• Wrong data shape
• Computed field was written manually
• Migration did not finish

Do not delete the original type until the diagnosis explains exactly why it is unrecoverable.

“Other Fields not in the layout” appeared.

This means data exists in the schema or record but the current layout does not display it. The data is not automatically lost.

Ask Orbit to compare the schema against every $state binding in the layout, then either add the intended fields to the correct tab or confirm that the fields are deliberately hidden. Do not solve it by deleting unknown fields blindly.

“I do not know what needs to be linked.”

Use the canonical ownership table in the previous chapter. Then ask:

Audit references for the foundation and active campaign only. Repair missing required links and meaningful causality links. Do not link records merely because they share a name or could theoretically be related.

At minimum, verify World Clock, World State, World Pulse, root Location, player Characters, Ruleset, Calendar, and Lexicon.

“Orbit keeps hallucinating.”

Check for:

• Duplicate records representing the same person or place
• Conflicting current Locations
• Two active Clocks
• World Pulse pointing to stale records
• Rules repeated differently across Character, Lore, and Power System files
• Missing active Mission or Pressure links
• Hidden truths accidentally placed in public summaries
• Overloaded notes with no structured references

Then correct the canonical owner.

“Setup stopped halfway through.”

Type Status. Setup is resumable and should continue from the recorded checkpoint. Do not restart from phase one unless the profile is genuinely corrupt.

If a batch failed, Orbit should reconcile what already succeeded, retry only the failed portion once, and mark the remaining issue as Failed or Deferred rather than recreating completed records.

“An update created Character-1 or another duplicate.”

Run Diagnose or Migrate. The intended strategy is same-slug in-place migration. A duplicate may be a temporary bridge, but it should have a recorded reason and should not replace the canonical type until parity is proven.

Ask for:

• Record counts on both types
• Reference comparison
• Custom-field comparison
• Layout comparison
• A merge plan
• Creator approval before deletion

“Do I delete Setup files after installation?”

No. Preserve the Setup Profile, Command Router, Update entry points, Version Manifest, Migration Wizard, diagnostics, validation guides, and release tools. They are future-maintenance infrastructure.

Some one-time guides may enter a cleanup queue, but deletion requires explicit approval.

“Can I rename the systems for my genre?”

Yes. Use Re-personalize to change visible terminology, genre language, tone, templates, and Lexicon entries without rewriting canonical slugs or breaking the engine.

The world may call Missions “Contracts,” “Cases,” “Assignments,” or “Community Projects.” The underlying Mission type can remain stable.

“When should I use Ship Update?”

Never! Using Ship Update is a tool for QueenOfHeavens (the creator of this package) for me to use only when I'm intentionally publishing a new engine or package update release. It updates the Version Manifest, installed and target versions, release history, and package-facing Metadata. This allows the user to then update to the latest version via running "Update". Ordinary worldbuilding, Setup, migration, and personal project edits should not silently change the engine version.

“Can I edit schemas and layouts myself?”

Yes, but treat them as code.

• Preserve file-type identity and canonical slugs.
• Keep existing data shapes in mind.
• Add fields before making them required.
• Validate all records against the new schema.
• Confirm every layout binding exists.
• Test desktop and mobile.
• Avoid unrestricted objects that become junk drawers.
• Never write to computed fields.

“How do I know the world is ready?”

Run Validate. The publishing workflow @Missing file should check schemas, records, references, layouts, mobile behavior, setup/update infrastructure, runtime formulas, and representative play.

A good release report should distinguish:

• Automated checks that passed
• Manual UI checks still required
• Known limitations
• Deferred optional work
• Blocking failures

A useful maintenance rhythm

After a major story arc:

1. Resolve or archive finished Missions and Pressures.
2. Review stale World Pulse entries.
3. Advance overdue consequences.
4. Review Faction and NPC independent actions.
5. Consolidate duplicate Memories.
6. Update World State after major changes.
7. Archive records that finished their role.
8. Run Diagnose, then Validate before publishing a major update.

Build clean, build grand, and let finished systems leave the active stage when their work is done. If you have any further questions feel reach to reach out via Discord @QueenOfHeavens.