Static generation is only one boundary

Hono JSX generates the initial HTML, article content, and metadata at build time. Delivery still needs explicit decisions about Worker routing, host isolation, cache policies, asynchronous work, and related database writes.

The architecture keeps source and build tooling together while separating each official site's Worker and Assets package.

HTML goes through a Worker

The main site's run_worker_first paths include /, /ja, /ja/*, /en, /en/*, /mcp, /api/*, /healthz, and /assets/ffmpeg-core/*.

Ordinary HTML therefore passes through a Worker, including negotiation for Accept: text/markdown. General images, CSS, and JavaScript under /assets/* use Assets directly. The main site's FFmpeg binaries are an exception routed through the Worker to R2.

Static generation does not imply that ordinary page requests never execute a Worker.

One repository, site-specific deployments

All 14 official sites use separate Workers and dist/sites/<site> packages. The build selects the pages and assets for each host. Canonical URLs, routing, security policy, and bindings stay within the appropriate site boundary.

This reduces the risk of delivering another site's content or unnecessarily sharing configuration. It does not eliminate the need to verify each deployment.

Cache according to content

HTML uses browser revalidation and edge-cache directives. Content-hashed CSS and JavaScript use public, max-age=31536000, immutable. Other general assets use public, max-age=0, must-revalidate; explicitly versioned paths can have their own immutable rules.

XML and text documents generally use shorter caching. Dynamic APIs and negotiated Markdown use no-store. Host-specific protection may also add no-transform to HTML.

max-age=0 is not a ban on storage. Edge retention and stale-while-revalidate are policy mechanisms, not universal guarantees about availability or retention duration.

When matching _headers rules overlap, the build clears an inherited Cache-Control value with ! Cache-Control before setting the specific policy. Content-hashed filenames receive exact-path rules.

Contact acceptance is not email delivery

The contact endpoint validates JSON size and schema, applies rate limits, verifies Turnstile, stores the submission in D1, and queues notification work.

If storage fails, the submission is not accepted. Successful storage and queue submission return HTTP 202. If storage succeeds but queue submission fails, the endpoint can return accepted_email_retry with HTTP 202 while D1 retains a retry-pending state for later processing.

Neither HTTP 202 nor successful storage proves delivery to the email recipient. Queue processing sends through the Email binding, retries according to configuration, and uses a dead-letter queue after the configured limit. Submission IDs and stored status help reduce duplicate sends.

Rate limits and persistent state

Rate Limiting bindings handle short bursts before excessive database work. D1 is used where a persistent user-level time window or quota is required. These layers have different responsibilities.

Related writes with D1.batch

Related SQL statements can be submitted in one D1.batch() call. D1 executes the statements sequentially as a transaction, rolling the batch back on failure.

This database transaction does not atomically include external queue submission or email delivery. Those require their own state and retry handling.

Configuration and release checks

Wrangler configuration identifies the deployment and bindings. Terraform manages selected surrounding infrastructure. Sensitive tokens, contact bodies, and similar private data must not be logged.

Wrangler's --strict option helps detect conflicting remote changes; it does not replace explicit target and configuration checks.

Normal pushes and pull requests do not automatically deploy this repository. Public code and content changes require quality:ci, security:osv, and git diff --check. Rendering and SEO changes additionally require browser inspection and Lighthouse. The same verified commit is then explicitly released and checked in production.

Performance 95+, SEO 100, and CLS below 0.1 are local quality targets. They are not guarantees of real-user Core Web Vitals or search rankings.

Technical references