Route Coverage Is Bounded—and Should Say So

Single-page applications are not necessarily single-route applications.

The entry page may expose links, redirects, file-based routes, lazy chunks, nested paths, query-dependent states, and authenticated destinations. Capturing one URL can preserve the shell while missing much of the software.

Multi-page capture improves coverage only when traversal itself is controlled and observable.

Normalize before scheduling

Route candidates can differ cosmetically while referring to the same resource. Fragments, trailing slashes, default ports, encoded forms, and repeated query ordering can create duplicate work.

A traversal planner should normalize URLs deterministically before they enter the queue. It should also keep the original discovery evidence so an operator can understand where a candidate came from.

Already-seen routes are ignored; unique candidates are admitted in stable collector order. Deterministic ordering makes the result reproducible when a budget truncates the queue.

Bound the navigation surface

Without policy, a crawler can leave the application, follow calendars indefinitely, enumerate search combinations, or revisit the same state under unlimited query strings.

Useful boundaries include:

• same-origin requirements;
• allowed path prefixes;
• explicit route lists;
• maximum depth;
• maximum page count;
• per-round discovery limits;
• request and navigation timeouts;
• robots policy;
• retry and pacing rules.

The budget is part of the evidence. “Stopped after 50 routes” is materially different from “found all routes.”

Preserve one session when state requires it

Some routes depend on authentication, storage, or navigation history established earlier in the session. Opening every route in a fresh browser can miss those states. Reusing one browser session can preserve them, but it also means route outcomes may depend on prior visits.

The capture should record visit order and outcome so that session continuity is visible rather than accidental.

Explicit operator flows can supplement crawl breadth when a particular sequence matters.

A discovered route is not a successful capture

Each planned visit needs an outcome:

• captured;
• redirected;
• outside policy;
• duplicate after normalization;
• blocked by robots or authorization;
• navigation failed;
• timed out;
• budget-excluded;
• discovered but not yet visited.

Optional route failures may not invalidate the entire workspace. They should still appear in diagnostics and coverage summaries.

Lazy code links coverage to bytes

Visiting a new route may reveal route-local JavaScript, styles, assets, or API responses. The capture can promote those artifacts into the donor inventory and tie them to the visit that exposed them.

This is stronger than scanning source text for possible URLs because it records what the running deployment actually requested.

It is still incomplete for unvisited or computed dynamic imports. Residuals should remain explicit.

Coverage is a claim with a denominator

A useful report can state:

• explicit routes requested;
• candidates discovered;
• unique routes admitted;
• routes successfully visited;
• redirects and failures;
• depth and page budgets used;
• residual candidates;
• route-local artifacts acquired.

The denominator may be “planned routes under this policy,” not “the entire application.” That narrower claim is more useful because another engineer can reproduce it.

KodeCapture treats traversal as a versioned evidence process. The objective is not to make a crawler look exhaustive. It is to preserve which parts of the deployed route surface were actually observed and make the unobserved remainder impossible to confuse with coverage.