# ChatGPT Work on the web

For a first launch, read [https://answer.cloud/new](https://answer.cloud/new) and follow
its current workflow version. The public prompt is exactly:

> Follow instructions at https://answer.cloud/new to build my website

The [plain-text backup](https://answer.cloud/new.txt) is available if the web reader
cannot retrieve a document format. The first-launch guide contains the complete brief,
bootstrap, guest credential, deployment, recovery, and completion contract. This
reference supplies optional cloud-client execution notes; it does not add sign-in or
plugin installation to that sequence.

## Execute in the available workspace

Inspect the current session's tools. When the client supplies a cloud execution workspace,
create the Astro source there; do not ask the user to install Node.js on their computer
to repair a cloud runtime. Use the template's engine requirements and reuse the project
from the guide's preflight build. An HTTP client can fetch the official template archive
when Git is absent. A Python or Node HTTP client can send the guide's authenticated
JSON-RPC requests when no native MCP connection is available. Python `zipfile` can create
the artifact when a `zip` executable is absent.

Web search, webpage retrieval, connected plugins, shell execution, and browser networking
are separate capabilities. Successfully reading the guide does not prove the workspace
can install dependencies, send authenticated JSON, or PUT binary bytes to signed storage.
Do not change client permissions or evade workspace restrictions. Report the specific
failed capability and preserve the brief and any existing work. Where the client exposes
Work or network settings, describe the available setting accurately rather than assuming
all accounts have the same tools or settings.

Preserve explicitly supplied local or staging origins. A remote workspace generally cannot
reach the user's localhost; report the failed operation and the need for a reachable test
environment instead of silently switching the brief to production.

## Keep session material outside deliverables

Follow the guide's credential and retry rules. An HTTP client should keep the request key,
Bearer token, signed upload URL, and raw session response in private memory or a temporary
private file outside the source and download area. Avoid verbose request logging or
printing authorization headers. Send the MCP token only to the MCP endpoint; the signed
storage URL authenticates the binary upload itself.

A simple standalone site's ZIP contains compiled `dist/` contents at its root. Include
CMS manifests and private templates only when the project uses them; adding CMS is not a
prerequisite for a first launch. Use the guide's same-deployment upload recovery before
starting another deployment, and retain the same reserved site throughout.

## Verify and hand over

Use the current session's HTTP and browser tools to check the live content and submit a
meaningful, non-sensitive question grounded in it. A widget script alone does not prove
chat works. Report precisely which interaction or visual states could not be verified.
Do not describe a local preview or an artifact as a published website.

Provide the verified live URL and a downloadable archive of editable Astro source using
the client's supported file handoff. Include source, package/lock files, public assets,
and any source needed to regenerate CMS templates. Exclude `node_modules`, `.git`,
environment files, build tokens, request keys, signed upload URLs, private session files,
and operational backups. Never offer the entire workspace. Do not promise that workspace
files persist after the session.

Use the public guide's account-setup wording: production publication triggers the setup
email job, whose sending or delivery can lag or fail. A live site alone does not prove
email delivery. The private setup link does not belong in the conversation or archive.
Future edits use saved source and normal authenticated access to the same site.

Workflow version: launch-f4679309a5dc7dc7