Website Development Standard
Sets expectations for deployable, accessible, and monitorable websites.
Applies to: Public websites, internal dashboards, static sites and web applications.
Explanation reviewed 2026-10-01. Catalog identity and source review have separate dates.
Read public MarkdownPurpose and applicability
A local build says nothing about whether public routes, metadata or rollback work after publication. WDS records each stage so configured behavior is not confused with observed runtime.
Public websites, internal dashboards, static sites and web applications.
How it works
Record site identity, routes, metadata, accessibility and asset rules. Name the environment and built snapshot in the deployment record; check public routes/assets after deployment and preserve rollback expectations and monitoring cadence.
Outputs include a site manifest, key-route inventory, accessibility/metadata checks, deployment record and restore note. Published readiness requires production evidence; local and preview checks keep their own scope.
In practice
This site’s committed configuration provides a concrete static publication path: reviewed JSON and approved assets enter Vite, then 22 existing HTML routes are prerendered. The server reads built output. This describes code/configuration, not a new public deployment.
Recorded review of package.json, the prerender script and serving configuration. Canonical files are not runtime inputs.
Source: site/package.jsonRecorded configuration review: 2026-10-01
public/data snapshots + approved public assets
→ pnpm build: Vite build
→ scripts/prerender-city-hall.mjs: 22 existing HTML routes
→ dist: static output
→ Caddy read-only static mount (loopback binding)
Configured: build scripts and static serving.
Observed by this record: repository configuration only.
Not established: current public route success, DNS/tunnel state, deployment time.Adapted checklist with no borrowed pass marks from the source example.
Source: WDS/examples/Example-Deployment-Record.mdEnvironment: preview or production (choose explicitly)
Commit/content snapshot: pending
Build result: pending
Deployed at: pending
Routes/assets checked after deployment: pending
Accessibility and metadata findings: pending
Rollback: restore previous approved build/snapshot
Monitoring: active, manual or intentionally unmanaged (declare)Adopt one part
Start with a bounded surface or record. Complete the relevant adopter checks before extending the claim.
- Inventory one route, its title/description/canonical URL and its public assets.
- Record the build snapshot, serving target, environment and restoration path; check keyboard/focus and narrow layouts locally.
- After an authorized publication, check the public route and copied assets, then record time, scope and monitoring expectations.
Sources and limits
No deployment is performed by this example. The repository’s Caddy mount and loopback binding describe configured behavior; DNS, tunnel availability and public HTTP success require separate observations. Accessibility smoke checks are not a full audit.
These are reviewed public explanations, not the normative specifications. Suite references are relative to the canonical collection; site/ references identify committed website sources and webserver/ references identify serving configuration. Illustrative examples demonstrate record shape; they do not establish compliance. Suite checks and adopter validation are separate.
WDS/WDS.manifest.tomlWDS/Adoption-Guide.mdWDS/Validation-Checklist.mdWDS/Website Development Standard.mdWDS/examples/Example-Deployment-Record.mdWDS/examples/Example-Accessibility-Metadata-Check.mdsite/package.jsonsite/scripts/prerender-city-hall.mjswebserver/Caddyfilewebserver/docker-compose.yml