# 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:///web///`. 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.