# Update and manage

A Project keeps its identity while its Builds change. Players follow the project; creators can publish new versions and explain progress through text updates.

> **Defined launch behavior, unavailable in this preview.** Publishing, persistent accounts, project management, updates and Discussion have not been implemented here. This page explains the agreed workflow without claiming these actions currently work.

## Replace an existing build

Prepare and test the new ZIP, with its own [cover](docs-prepare.html#make-a-cover), using [Prepare and test](docs-prepare.html). Every build needs a cover, a replacement too; a sealed build never changes, so a new cover for a live game needs a new build. When publishing becomes available, submit it through an authorized MCP connection against the existing project. Keep existing metadata unless the creator requests changes; explicit publishing-request values take priority over valid metadata inside the package.

The current live build stays available while its replacement is checked. A failure or review flag leaves the live build untouched. A passing replacement publishes automatically after the required assessments. Successful replacement publication sends one follower notification; uploading alone sends nothing. Notification delivery details remain unresolved.

Only the latest approved build is publicly playable in the defined launch workflow. Older builds are retained for recovery, with their existing build notes in Updates. There is no public build/version picker. Do not promise creator rollback controls or a particular recovery procedure; those operations remain unspecified.

## Manage project details

The website's YOU dashboard and inline Manage area are the defined place for creators to manage their own project details and Active setting. New games and replacement files use MCP; website file-upload forms are not the launch publishing channel. Title, type, quick description and description edited there carry over to later builds unless a new submission sets them. When you publish a replacement, keep any packaged demo.json in step with the current project details, or leave those fields out of it.

Active answers whether the creator is currently working on the project, independently of its type or VR capability. Tech Demos, Short Games and Worlds can all be Active. A Short Game can already have its complete loop, menu and ending while development continues to improve or expand it; a World can keep growing. The published build must already offer a polished, worthwhile experience. The `active` metadata field records the creator's explicit answer: `true` for current development, improvements or expansion; `false` otherwise. It is optional in `demo.json`, but an explicit valid answer is required before publishing. Reuse a valid creator answer already available; ask if missing, without a default or inference from recent edits. The badge is shown only while `active` is `true` and the last build or update is less than 60 days old. Badge visibility is separate from the saved answer.

## Post a text update

Creators write standalone updates in YOU → Manage. Published posts appear in the project's Updates tab. No new build is required, and posting a standalone update sends no email. Keep this separate from the notification attached to a successfully published replacement build.

Do not claim these website actions are MCP tools. The set of non-publishing MCP management tools is not specified.

## Discussion and creator replies

Discussion supports Comments and Suggestions, both with +1 votes. Posts appear newest first; vote totals do not determine the default order. Each post can have one editable reply from the creator, displayed beneath it. There are no nested reply threads.

Only Suggestions have creator-set status:

- **Open:** unresolved; it is not a commitment to implement the suggestion.
- **Built in vX:** implemented in the named build.
- **Not planned:** the creator decided against it.

Comments have votes without a status. Actions such as following, voting and posting require sign-in; public play does not require an account in the defined launch workflow.

## Visibility and availability

**Listed** projects appear in Play and public creator profiles. **Unlisted** means link-only visibility. **Hidden** means removed from public availability because of a problem, with a reason for the creator. Visibility is separate from validation: Unlisted is not permission to serve an unchecked build. Public play requires the relevant safety checks and isolated hosting.

The production controls for changing visibility and recovery are not specified here. Do not invent a creator control or promise immediate reinstatement. Lab and phone gameplay remain unreleased independently of project metadata and ordinary phone browsing.

## Get help

The defined project-page help action is **Get help**, available to signed-in users. Send a short description of the problem; the request is associated with the project and build being viewed, the signed-in account and submission time. The defined process also records the submission IP address for 90 days, then deletes it. Retention of request text and account references is not yet specified.

After the request is saved, show an on-screen acknowledgement. An email reply can be sent when needed; there is no automatic receipt email or in-site private support conversation in the launch workflow. Delivery arrangements and response times remain unresolved. This help flow is not working in the preview; do not claim a request has been sent from a prototype interaction.