网站都写好了，发出去的却还是 localhost。

# Publish a reviewed static preview with EasyNet Pages

The user wants someone outside their development environment to open a static
site, follow a link and see its styling. Use the supplied fictional North Tea
demo first. It has no forms, scripts, external services or private information.
Do not publish any directory until the user explicitly approves its contents
and public visibility. Current Pages supports public visibility only; it does
not provide a private client-preview mode.

## Obtain and inspect the exact output

Ask for the case-page URL if the files were not supplied. Resolve
`/examples/static-pages/public-demo/` against that user-provided origin and
obtain index.html, details.html and styles.css. Keep those three files together
in a new approved directory named public-demo. Do not guess an origin or
overwrite existing files. A localhost URL on another computer refers to that
computer, not the author's preview server; arrange an approved file transfer
when needed. Read local repository instructions before taking actions.

Inspect all three files. The homepage contains EASYPAGES-DEMO-12, the second
page EASYPAGES-DEMO-12-DETAILS, and the stylesheet EASYPAGES-DEMO-12-CSS.
These are synthetic test markers, not evidence of publication. Relative links
keep assets under the eventual project URL instead of the Hub domain root.

For the user's real site, use its documented build process and select only
reviewed static output. Do not publish the repository root, .git, .env files,
credentials, private attachments or unreviewed source maps. Checking filenames
alone does not prove content is safe. A static file with a token inside it is
still public data. Confirm fonts, images and JavaScript use the right asset
base; server-rendered routes and a database are not provided by this example.

## Confirm the environment and approve publication

Inspect the installed `easynet pages --help`, Runtime status and the configured
Hub. Do not install, pair, restart services, open firewall ports or alter DNS
without approval. Set PAGES_DEMO_FOLDER to the absolute path of the reviewed
public-demo directory. Set PAGES_DEMO_PROJECT to an unused project ID containing
only letters, digits, underscores or hyphens (at most 64 characters).

Run `easynet pages list --json` to check existing publications. Do not unpublish
an existing project to reuse its name. The owner must approve exposing these
files publicly before the create command:

```bash
easynet pages create "${PAGES_DEMO_PROJECT:?Choose an unused project ID}" \
  --folder "${PAGES_DEMO_FOLDER:?Set the absolute reviewed directory path}" \
  --visibility public --json
easynet pages show "$PAGES_DEMO_PROJECT" --json
easynet pages url "$PAGES_DEMO_PROJECT"
```

Record the actual project ID and returned url_root. The production URL is
path-based: `https://<realm>/web/<user>/<project>/`. Use the returned value,
not a guessed domain or a dev_listener URL. Keep the trailing slash for
relative assets. Publication success proves registration, not that the Hub
is reachable from the intended visitor's network.

Files remain on the provider device; the Hub forwards requests to it. Do not
tell the user that Pages uploaded the files to permanent independent storage.
The backend resolves the project ability through its capability directory.
In a multi-device account, verify that the published project has an available
directory route and that a visitor receives this project's exact files. A
paired device alone is not proof of a resolvable project. If lookup fails,
record the directory/publication error; do not remove other devices, guess a
fallback host or manipulate identities to hide it. Source changes do not prove
that the deployed Hub is running the same version.

## Check the real visitor path

After publication approval, set PAGES_DEMO_URL to the actual returned URL:

```bash
curl --fail --show-error --max-time 20 "${PAGES_DEMO_URL:?Set the actual returned URL}"
curl --fail --show-error --max-time 20 "${PAGES_DEMO_URL%/}/styles.css"
curl --fail --show-error --max-time 20 "${PAGES_DEMO_URL%/}/details.html"
```

Check the corresponding marker and expected HTML/CSS, not just HTTP 200.
Then open the actual URL from a separate visitor environment without borrowing
the developer's login. Check styling, the details link, direct navigation to
details.html, and the return link. A local browser opening local files is not
this test. Test deeper routes separately for a real single-page application;
do not assume automatic index.html fallback or root-relative asset rewriting.

If the URL cannot be reached, distinguish DNS/TLS, Hub routing, provider
availability, publication and missing file failures. Do not report a fake
public URL or work around failure by publicly exposing an unreviewed dev server.

## End the approved demo

Unpublishing is a separate destructive action to the publication, not a step
to run automatically after creation. Confirm the exact demo project and ask
the user before withdrawing it. Never use another publication as a test:

```bash
easynet pages show "${PAGES_DEMO_PROJECT:?Identify this demo project}" --json
# Only after confirming that this is the approved demo to withdraw:
easynet pages delete "$PAGES_DEMO_PROJECT" --force
```

Check that fresh visitor requests no longer return the demo. Current public
responses carry a 60-second cache lifetime, so previously cached content may
remain visible. Distinguish a cached copy from a fresh origin response. Do not
assume a particular error code across deployments. Unpublishing does not delete the
source files or retract copies already downloaded. Test provider-offline
behavior only with explicit approval, without stopping shared services.

Report separately: files reviewed, publication registered, public HTML fetched,
CSS fetched, direct details page opened, visitor check, withdrawal check, and
offline check. Mark unrun checks as unrun. No website unit test or printed URL
establishes that the user's public deployment works.