What to build
Graduate lithos import from experimental to a documented, reliable adoption workflow.
Right now the docs explicitly warn that import is experimental and that most resources may be re-created on the next deploy. That is a useful escape hatch, but it is not yet a trustworthy on-ramp for teams with an existing production experience. The graduation target should not be "support every Roblox edge case immediately"; it should be a predictable path where a user can model their existing experience in Lithos, run lithos import, then run lithos diff and see either no changes or a small, well-explained set of changes.
The command already imports a broad slice of live state: experience metadata, configuration, places, social links, developer products, passes, badges, asset aliases, thumbnails, notifications, and spatial voice settings. The missing piece is confidence that imported state lines up with configured resources closely enough to avoid surprise recreation on the first real deploy.
Acceptance criteria
- For the resource types Lithos already imports, a matching or near-matching config does not trigger wholesale delete-and-recreate behavior on the first
diff or deploy after import.
- Any fields or resource types that still cannot be mapped cleanly are surfaced as explicit warnings during import instead of silently degrading into a risky next deploy.
- The import flow has a documented support matrix: what is fully supported, what is lossy, and what remains unsupported.
- The
import docs can remove the experimental warning and replace it with concrete rollout guidance.
- End-to-end tests cover the adoption path: import into empty state, run diff, and verify the resulting plan stays within the documented guarantees.
Out of scope
- Generating a brand-new
lithos.yml or lithos.json from a live experience.
- Perfect one-shot import coverage for every Roblox feature before the experimental label is removed.
- Reworking the entire deploy planner unrelated to import matching.
What to build
Graduate
lithos importfrom experimental to a documented, reliable adoption workflow.Right now the docs explicitly warn that
importis experimental and that most resources may be re-created on the next deploy. That is a useful escape hatch, but it is not yet a trustworthy on-ramp for teams with an existing production experience. The graduation target should not be "support every Roblox edge case immediately"; it should be a predictable path where a user can model their existing experience in Lithos, runlithos import, then runlithos diffand see either no changes or a small, well-explained set of changes.The command already imports a broad slice of live state: experience metadata, configuration, places, social links, developer products, passes, badges, asset aliases, thumbnails, notifications, and spatial voice settings. The missing piece is confidence that imported state lines up with configured resources closely enough to avoid surprise recreation on the first real deploy.
Acceptance criteria
diffordeployafter import.importdocs can remove the experimental warning and replace it with concrete rollout guidance.Out of scope
lithos.ymlorlithos.jsonfrom a live experience.