Runtime Smoke Is a Contract, Not a Screenshot

A recovered project can compile and still fail at the first meaningful runtime boundary.

It may load a blank page, boot twice, request an unavailable asset, initialize the wrong route, hide a console exception, or depend on a donor server that the candidate does not own.

A screenshot can miss all of those conditions.

Process startup is only the first fact

A development server listening on a port proves that a process started. It does not prove that:

• the expected HTML entry loaded;
• scripts executed in the intended order;
• the application reached a ready state;
• required assets resolved from the candidate;
• captured routes can be opened directly;
• external requests stayed within policy;
• the browser console remained clean;
• the page is owned by the candidate rather than a fallback donor.

Runtime smoke should make those expectations explicit.

The contract names the environment

A useful smoke profile records the command, host, port policy, startup timeout, route set, readiness condition, browser backend, and allowed resource behavior.

This matters because environment failures and candidate regressions need different responses. A missing browser binary is not proof that the recovered source is broken. A route returning the wrong entry document is not merely an environment warning.

Structured outcomes keep those causes separate.

Readiness must match the application

Waiting for load or generic network idleness can be misleading. Interactive applications may keep WebSockets open, poll continuously, render over several frames, or hydrate after the document event.

A bounded smoke check can use increasingly specific signals:

• document readiness;
• stable DOM or animation frames;
• framework hydration evidence;
• an application-provided readiness hook;
• a stable semantic snapshot;
• a calm render loop.

Timeout is a disclosed failure state, not permission to call the application ready.

Resource ownership reveals false greens

A candidate may appear correct because it still loads scripts, APIs, images, or state from the original deployment.

The smoke result should record where executable and required resources came from. Unexpected remote authority can mean the recovery has not yet made the candidate independent.

Some remote services are intentionally retained. That is acceptable when they are declared. The problem is an undeclared dependency being mistaken for recovered behavior.

Smoke and parity answer different questions

Runtime smoke asks whether the candidate can boot and satisfy a small operational contract.

Parity asks whether selected observations match the donor within declared tolerances and exclusions.

A candidate can pass smoke and fail parity because the UI or behavior changed. It can also match one screenshot while failing smoke because console errors or missing routes make the result unstable.

Both layers are useful precisely because neither is stretched into a claim it cannot support.

Failure should produce a next action

A good smoke report distinguishes:

• process failed to start;
• entrypoint not served;
• readiness timed out;
• browser error or page exception;
• required request failed;
• undeclared remote authority observed;
• route did not close;
• evidence unavailable.

The operator should not have to infer the cause from a screenshot and several megabytes of terminal output.

KodeBack uses runtime smoke throughout recovery, not only at the end. A bounded source edit can be followed by the cheapest check that would catch its likely failure, while broader parity remains available for higher-risk transitions.

The objective is not to celebrate that the page opened. It is to establish exactly what opened, under which authority, and how much confidence that observation deserves.