# Review and release

A build can generate technically valid HTML containing wrong instructions, a missing download, a public secret or an obsolete route. A deploy can report success while serving an old index or a soft404. Treat source review, artifact review, browser behavior and live host acceptance as separate gates.

This procedure applies to CLI-built static artifacts and the administrator publisher. V2 provides no Git review/approval workflow, external deployment coordinator or sitewide prose fact checker. Choose your reviewer and audience outside the editor. Saving a page is not publication; publishing is not remote host deployment unless your installed deployment process supplies that step.

# Gate map

A failed gate holds its affected release. Do not compensate by deleting safeguards, skipping tests or making private folders publicly readable. Record the reason and continue independent review where useful.

# Review source inputs

Inspect diffs, not only the rendered summary. An explicit title change can move the generated route and section descendants. Hidden sections remain generated/searchable. Dot-prefixed source exclusion is not a substitute for separate private storage. A local image/download may carry unrelated metadata or confidential bytes.

Check that all included content is intended for the reader audience. Editor authentication and assigned sections restrict editing, not public reader access. If reading must be private, verify an external reader gate for the entire output/resources/index. Search prose can disclose hidden content even without a sidebar row.

File-only allowRawHtml changes the authored-content security contract. Treat changes to templates/scripts/raw-HTML policy as engine/security review, not ordinary text. The public showcase keeps pinned engine untouched and deploys no optional editor.

# Examples and claims

Use synthetic names/domains/accounts and no secrets in command lines or logs. A shell snippet with placeholders is a template, not executed production evidence. A config parser accepts syntax, not necessarily working TLS, DNS, cookies or resource access. State that limit beside the example.

For current external provider rules, read its official documentation before publication. Record the checked source/date. The pinned V2 engine determines product behavior; a library’s latest general documentation does not establish every feature exposed through that pin.

# Artifact checks

1. Build into a new dedicated output and confirm it is the output being reviewed.
2. Compare generated route/page inventory with intended content, including home/404.
3. Resolve all internal links, heading anchors, local images/downloads and search targets.
4. Inspect actual copied static files, not just their extensions or names.
5. Confirm no users/runtime/editor/server/dependency files or secrets are served.
6. Retain counts and hashes of the reviewed artifact with the input/build recipe.

V2 search indexes pages and H2-H4 headings. The builder’s “pages” index log includes headings, not a Markdown page total. Avoid false count comparisons. Descriptions are metadata, not a separate search field. The marker uses source metadata fingerprints, not cryptographic content integrity. A badge or index count alone cannot prove freshness.

# Browser acceptance

Inspect pixels, not only element existence. Test the longest real table/value/code sample at 320 and 390px and a desktop width, plus an intermediate layout. Keep qualifications visible with the facts. Recompose wide content rather than reducing normal text or hiding warnings.

A local Chrome emulation check is not physical iPhone/Safari, accessibility certification or every browser. Test your supported devices and assistive-use requirements separately. Record observed versions and limits. Clipboard permissions/network conditions can affect a control without changing the generated text.

# Deployment gate

Keep old files out of the new artifact unless deliberately retained. Synchronizing without deletion can leave removed pages public; deletion in a shared/unverified target can destroy another site. Verify target and dry-run your selected tool before any replacement.

Do not serve the checkout root. The static host needs complete reader output, not Node/editor/users files. V2 editor’s staged two-rename switch can have a gap and restoration failure. It is not guaranteed zero downtime. Follow reported paths and preserve the previous artifact; see Publishing stages.

# Live acceptance and rollback

Open the actual public URL after deployment. Verify current distinctive content, a deep page, search target, media/diagram, vendor resources,404 status and HTTPS/redirect/cache behavior. A committed file or provider success alone is progress, not acceptance. Check a fresh browser and existing cache.

If acceptance fails, identify whether the bad layer is artifact, host mapping, cache or source. Return to a known compatible artifact through the supported host procedure, then verify the live result. A content rollback need not roll back accounts. Account/source restores require coordinated writers and compatibility review.

# Release record

Keep private paths/account details out of public release notes. Record the actual acceptance result, failed gate and remaining caveat. Validation limits describes this handbook’s measured local scope; it is not permission to claim your production environment passed the same checks.