Understand builds, checks and release identity
Follow the files from source project to a reviewed release.
What Run and Publish do
Choose Run to build a preview, or use Publish to submit a release. The platform performs these steps for you:
- Read and validate the project and manifest under file and archive limits.
- Apply cross-field manifest checks.
- Resolve SDK, engine and supported library versions.
- Scan project code and bundle the entry.
- Package accepted media and calculate file hashes.
- Write the generated lock and build result.
- For a release, run runtime checks in the platform frame and any required review.
The lock records the SDK build, bundled libraries and file hashes. Its hash identifies the build. Changing the visible version label alone is not a substitute for content identity.
Type checking is separate
The standard build is a bundling and validation gate. Current release and creator-preview paths are not equivalent to a strict TypeScript compilation. When using the assistant, also read any separate type-check result it reports; a build may succeed while that check reports errors.
In the full Studio Code editor, inspect TypeScript diagnostics and fix reported problems. Also read Problems and Console. A successful build alone does not establish that all types passed.
Read the result
For a refused build, inspect findings and their source locations. For a successful build, read warnings and runtime-check outcomes as well. The Studio shows the applicable bundle-size budget and any size warnings. Reduce assets or code when the build says the project is too large.
Never edit the generated lock to resolve a finding. Fix source, declarations or assets and rebuild.
Release distinction
Publishing submits a locked checkpoint. Store text and covers have separate moderation. A built release can still be in review or not approved; it is not automatically discoverable.