# The Building — how Sightmap works

An interactive tour of how Sightmap works: code is the blueprint, the running app is the building, a sightmap is its wayfinding, and agents are the people moving through it.

The interactive version at https://sightmap.org/building is a scroll-driven 3D scene. This is the same story in text.

## The metaphor

- **Code is the blueprint.** Source files describe every wall: components, routes, API handlers. They are complete and exact, and almost useless to someone standing in the lobby.
- **The running app is the building.** Each view is a floor with its own route. Components are the rooms on that floor. API requests are the service risers running up the core.
- **A sightmap is the wayfinding.** A `.sightmap/` directory names every floor, room, and riser, links each back to its source file, and keeps memory notes for the quirks the drawings never recorded.
- **Users and agents are the people.** Every session is a journey through rooms and floors. Subtext records those journeys against the map, so a replay reads as named components rather than a list of divs.

## Built on top (exploratory)

- **Self-healing tests.** A test written against the map asks the building where a room went when a selector changes; the name stays stable and the run finishes.
- **Trajectories.** Codified journeys: the views a flow visits, the components it touches, and the requests it expects on the way.
- **Web MCP tools.** Tools generated from the map, each backed by a real view and a real request, so an agent walks up to the front desk instead of wandering the halls.

## Next

- [Homepage](https://sightmap.org/)
- [Quickstart](https://docs.sightmap.org/start/quickstart)
- [Documentation](https://docs.sightmap.org)
- [GitHub](https://github.com/sightmap/sightmap)