Glossary
Definitions used throughout the Sightmap docs and spec. Alphabetical.
A maintainer or contributor task that compares the live .sightmap/ directory against the actual codebase to catch drift — stale routes, missing components, dead memory entries. Audits are typically run before a release or after a large refactor.
Bootstrap
Section titled “Bootstrap”The first generation of a .sightmap/ directory for a project — usually produced by an agent reading the codebase and proposing an initial set of views, components, and requests. The author then curates the output. See Curator vs consumer.
Component
Section titled “Component”A named DOM subtree, identified by one or more CSS selectors. The unit of UI naming Sightmap surfaces to agents. Defined under components: either at the file root (global) or inside a view (scoped). See Components.
Conformance
Section titled “Conformance”The contract a Sightmap SDK implementation honors. Conforming SDKs are validated against the language-agnostic conformance fixtures and the SDK requirements in the schema reference.
Consumer
Section titled “Consumer”A program that reads a sightmap at runtime — typically an agent, a snapshot enricher, or a network-trace tool. Consumers honor the spec; they do not produce sightmap files. Contrast with Curator.
Curator
Section titled “Curator”A human (or human-supervised agent) who authors and maintains the .sightmap/ directory. Curators choose which UI surfaces are worth naming, write memory entries, and keep the file in sync as the app evolves. Contrast with Consumer.
Glossary (this page)
Section titled “Glossary (this page)”Where these terms are defined. If a term is missing, open a Discussion.
Model Context Protocol — the protocol Sightmap-aware tools use to expose sightmap data and authoring actions to agents. The reference MCP server is @sightmap/sightmap mcp.
Memory
Section titled “Memory”Short freeform notes attached to a file, view, component, or request. Memory carries context that isn’t recoverable from the source code: quirks, invariants, “you have to click this twice” lore. See Memory.
Project semver
Section titled “Project semver”The SemVer version of the sightmap/spec repo (currently 0.1.0). Tracks docs, schema clarifications, examples, and tooling cadence. Independent of the spec stream version. See Versioning policy.
Request
Section titled “Request”A named API endpoint described in the sightmap. Carries the route glob, HTTP method, payload shape, and optional memory. Defined under requests:. See Requests.
Selector
Section titled “Selector”A CSS selector (or array of alternatives) that locates a component’s root element. Child selectors are scoped to the matched parent’s subtree. See Selectors.
Sightmap (the file)
Section titled “Sightmap (the file)”A single YAML document under .sightmap/ that conforms to the v1 schema. “A sightmap” can also refer to the whole .sightmap/ directory, depending on context.
.sightmap/ (the directory)
Section titled “.sightmap/ (the directory)”The conventional location for a project’s sightmap files. Lives at the repo root. All *.yaml and *.yml files inside (recursively) are discovered and merged.
Stream version
Section titled “Stream version”The integer in a sightmap file’s version: field — currently 1. Identifies which spec stream the file conforms to. Bumps only on a breaking change to the YAML format. Independent of the project semver. See Versioning policy.
A named screen in the app, identified by a URL route glob. The unit of routing Sightmap matches against the current page. Defined under views:. See Views.