name and route are required. url gives the view a representative URL — a concrete address that resolves to it — which tooling uses to navigate to the view (coverage reporting, bulk capture, and probing); a file-level url supplies a default for views that omit their own. description records the view’s purpose, and source links it to a source file. properties, tags, environments, and origins are covered below. See Schema reference for every field.
Route matching
Routes use glob patterns against the URL pathname.*matches exactly one path segment:/users/*matches/users/42, not/users/42/edit.**matches any depth of segments:/admin/**matches/admin,/admin/users, and/admin/users/42/edit.- Literal segments match themselves.
- Matching is case-sensitive. Query strings and fragments are ignored. Trailing slashes are normalized away before matching.
:param segments are normalized to *, so /api/users/:id/orders and /api/users/*/orders are equivalent. See Requests.
Most specific wins
When more than one view route matches a URL, the route with the highest specificity score wins. Declaration order breaks ties between routes with equal scores. Specificity is the sum of per-segment scores:
The root route
/ scores 1 — more specific than any wildcard-only pattern. When two routes score equal, the first declared view wins.
/users/admin matches both routes and resolves to UserAdmin. /users/42 matches only UserProfile.
This specificity rule applies only to views. Every matching request applies. See Requests.
Scoped vs global
Components and requests can live at the file root or nested inside a view.- Global (file root): matched against every view.
- View-scoped (inside a view): matched only when that view is active.
- Additive: a view receives its scoped definitions and all globals. A view-scoped
$refsubsumes a global component with the same name for that view.
URL properties
A:name segment in a view route binds that segment’s value as a property, with no declaration needed. An optional properties list names query-string values, or renames a bound segment, using the same extract object components use:
/shop/p/12345?variant=blue the view carries product_id="12345" and variant="blue". Values are percent-decoded, query keys are case-sensitive, and a repeated key resolves to its first occurrence. An extract: { from: url.path, path: product_id } entry renames the binding, and the original product_id name is no longer produced.
Binding changes what :param produces, never what it matches: the route scores and matches exactly as before. URL properties read only the URL string, so they resolve offline, from a saved session or a coverage report.
A binding name must match ^[a-z][a-z0-9_]*$. A segment like :orgId still matches but binds nothing, and sightmap validate warns route-param-unbound. A declared property that reuses a name the route still binds is an error (route-binding-conflict).
Naming a URL part asks a consumer that scrubs URLs to keep it, but it is not a privacy grant. A consumer must not retain a value its own policy, or the corpus’s
privacy, would withhold.Tags
A view’stags resolve as a union across every view whose route matches the URL, not only the most specific one. A broad /checkout/** view tagged defect therefore tags /checkout/payment too, even when a narrower, untagged view wins identity there. sightmap snapshot prints the resolved set on a tags: line under the view header. See Tags.
Environments and origins
environments and origins on a view name the deploy targets it exists in and the hosts it is served from. They are declarative metadata and never change which URLs the route matches. See Environments and origins.