1. Host resolution

What happens when somebody opens an RC project

The current path is cache-first, fail-open and owner/project scoped. Expensive AETHER scans, SARCH crawls and maintenance work are not supposed to execute synchronously before the page can be served.

The RC front door resolves the one-label project hostname to its deployment record. Older deployment records are normalized in memory so missing newer metadata cannot crash HTML delivery.

The edge loads the project cache policy if available. If policy/cache storage is unavailable, RC bypasses RS and continues rather than returning 500.

A fresh cache hit can return immediately. Sleeping projects can return an eligible cached page while the runtime wakes. Otherwise RC reconciles the execution.

4. Static or dynamic response

Static projects read content-addressed files from RC/AETHER. Dynamic projects proxy to the execution’s private port. HTML enhancement is attempted after the creator response exists.

5. Optional enhancements fail open

Default favicon, live-update client, RS visitor bootstrap, watermark, cache writes and activity tracking are optional. A failure in any of them logs a diagnostic and serves the creator response unchanged.

Legacy missing watermark metadata no longer causes TypeError/500.

RS cache read/write failures become BYPASS instead of project failure.

Branding lookup failures fall back to the deterministic RC favicon.

6. Persistence and history

RC Storage writes URL-DB/AETHER data independently. SARCH captures history on its own bounded schedule. AETHER backup jobs run outside the request worker.